Prácticas recomendadas para controlar el acceso de red con SSH

En este documento, se describen las prácticas recomendadas para controlar el acceso de red con SSH a las instancias de máquina virtual (VM) de Linux.

Para conectarse a una instancia de VM con SSH, un usuario necesita acceso de red a la instancia de VM y credenciales SSH válidas. De forma predeterminada, Compute Engine usa una regla de firewall que no restringe el acceso de red con SSH, pero permite que cualquier persona en Internet se conecte al puerto 22 de las instancias de VM. Si bien es conveniente para los desarrolladores comenzar rápidamente sin considerar los controles de red o seguridad, permitir que los usuarios se conecten desde cualquier dispositivo, red y ubicación conlleva riesgos:

  • Los usuarios pueden conectarse desde dispositivos o redes que no son de confianza.
  • Los agentes maliciosos pueden iniciar ataques de fuerza bruta y, además, intentar comprometer tus instancias de VM.
  • Los agentes maliciosos con acceso a credenciales SSH que se filtraron o no se revocaron a tiempo pueden usar las credenciales para acceder a una VM desde cualquier red.

En las siguientes secciones, se describe cómo puedes reducir el riesgo; para ello, debes limitar las redes, las ubicaciones o los dispositivos desde los que los usuarios pueden establecer una conexión SSH a tus VMs:

En este documento, nos enfocamos en las prácticas que son específicas de Google Cloud o de particular relevancia cuando se usa SSH en Google Cloud. En el documento, no se abarcan las prácticas recomendadas para implementaciones específicas de clientes o servidores SSH.

Reduce la exposición de la red

Permitir que los usuarios establezcan conexiones SSH desde cualquier lugar significa que dependes por completo de los mecanismos de autenticación y autorización de SSH para proteger tus VMs. Puedes reducir el riesgo y establecer una capa adicional de protección; para ello, reduce la exposición de red de las VMs.

Existen varios enfoques para reducir la exposición de red de tus VMs. Para identificar el enfoque que mejor se adapte a tu entorno, debes tener en cuenta una serie de factores, como se ilustra en el siguiente diagrama de flujo:

Reduce la exposición de red

  • Acceso externo: El primer factor que debes tener en cuenta es si la VM solo necesita ser accesible dentro de la red de VPC o si necesitas que la VM sea accesible de manera externa.

    Si el acceso interno a la VPC es suficiente, no es necesario asignar una dirección IP externa a la VM, pero debes decidir cómo administrar el acceso.

  • Tamaño de la red interna: Si el acceso interno a la VPC es suficiente, el segundo factor que se debe considerar es el tamaño de la red interna.

    En redes más pequeñas, podría ser suficiente usar reglas de firewall que permitan la entrada al puerto 22 desde direcciones internas para proteger tus VMs. En redes más grandes, depender solo de las reglas de firewall puede ser demasiado limitante: En esos casos, puedes beneficiarte de usar el reenvío de TCP de Identity-Aware Proxy para aplicar el acceso adaptado al contexto a las VMs.

  • Diseño del perímetro de los Controles del servicio de VPC: El siguiente factor que se debe tener en cuenta es si la instancia de VM forma parte de un perímetro de los Controles del servicio de VPC.

    Si la VM forma parte de un perímetro de servicio, se considera que cualquier acceso a la API que se origina en la VM se originó en el perímetro. Cuando otorgas a un usuario que está ubicado fuera del perímetro acceso SSH a una VM dentro del perímetro, puede copiar datos del perímetro a su estación de trabajo local, o viceversa. Esto puede poner en riesgo la confidencialidad y la integridad de los datos del perímetro.

    Cuando necesites otorgar acceso SSH a una instancia de VM que forma parte de un perímetro de los Controles del servicio de VPC, usa el reenvío de TCP de IAP. IAP detecta si la estación de trabajo del usuario forma parte del mismo perímetro de los Controles del servicio de VPC y bloquea los intentos de acceso desde fuera del perímetro de servicio de forma predeterminada. Para permitir el acceso externo, usa reglas de entrada y configúralas para aplicar el acceso adaptado al contexto.

  • Administración de dispositivos cliente: El último factor que debes tener en cuenta es cómo se administran tus dispositivos cliente, ya que eso determina las formas en que puedes controlar el acceso adaptado al contexto.

    El acceso adaptado al contexto es más eficaz cuando Access Context Manager tiene acceso a un conjunto amplio de indicadores sobre un usuario, el dispositivo y su ubicación; por lo tanto, funciona en conjunto con Chrome Enterprise Premium: Si usas Chrome Enterprise Premium para administrar tus dispositivos, puedes configurar niveles de acceso que controlen el acceso según la posición del dispositivo. Luego, puedes aplicar este nivel de acceso al acceso SSH a través del reenvío de TCP de IAP en combinación con vinculaciones de acceso o condiciones de IAM.

    Si no controlas la configuración de un dispositivo cliente, debes considerarla no administrada y potencialmente no confiable.

    Para permitir el acceso desde dispositivos no administrados, también puedes usar el reenvío de TCP de IAP, pero solo puedes administrar el acceso según la identidad del usuario y la dirección IP del dispositivo. Debido a que Access Context Manager no tiene acceso a ningún indicador del dispositivo, no podrás restringir el acceso según la posición del dispositivo.

Según los factores y con el diagrama de flujo, puedes identificar qué enfoque es el más adecuado para tu entorno para reducir la exposición de red. En las siguientes secciones, se describen estos enfoques con más detalle.

Acceso SSH basado en IAP

La idea de este enfoque es permitir solo el acceso SSH a través del reenvío de TCP de IAP y permitir que IAP controle el acceso según la identidad del usuario.

Recomendamos este enfoque para las instancias de VM en las que se aplica lo siguiente:

  • Se debe poder acceder a la instancia de VM de forma externa o desde una red interna grande.
  • La VM no forma parte de un perímetro de los Controles del servicio de VPC.

De forma predeterminada, una instancia de VM con una dirección IP externa permite el acceso SSH porque los firewalls predeterminados permiten conexiones desde el Internet público hacia el puerto 22, pero este no es un enfoque recomendado. Este enfoque puede aumentar de forma significativa el riesgo de que la VM esté sujeta a ataques como los siguientes:

  • Uso de credenciales sin revocar: Los exempleados cuyo acceso no se revocó por completo podrían seguir accediendo a la VM.
  • Abuso de credenciales válidas: Los agentes maliciosos que poseen credenciales robadas o filtradas pueden usarlas para acceder.
  • Denegación del servicio: Los agentes maliciosos podrían intentar agotar los recursos de la VM inundándola de solicitudes.

Una forma más segura de habilitar el acceso SSH externo a una instancia de VM es usar el reenvío de TCP de IAP. Al igual que un host de bastión o un proxy inverso, el reenvío de TCP de IAP actúa como un intermediario entre el dispositivo cliente y la VM.

El reenvío de TCP de IAP realiza las siguientes cuatro funciones cuando un usuario intenta establecer una conexión SSH:

  • Autenticación: IAP verifica que el usuario tenga una credencial de Google válida.
  • Autorización: IAP verifica las políticas de IAM para verificar que el usuario tenga permiso para conectarse a la VM a través de IAP.
  • Acceso adaptado al contexto: De manera opcional, IAP puede verificar que el usuario, el dispositivo y su ubicación cumplan con ciertos niveles de acceso.
  • Auditoría: Cuando los registros de acceso a los datos están habilitados, IAP registra cada intento exitoso y con errores de conectarse a una instancia de VM.

Cuando actúa como intermediario y realiza estas funciones, IAP elimina la necesidad de asignar una dirección IP externa a la VM y proporciona una capa adicional de seguridad.

Acceso SSH adaptado al contexto basado en IAP

La idea de este enfoque es permitir solo el acceso SSH a través del reenvío de TCP de IAP y permitir que IAP controle el acceso según la identidad del usuario y los factores adicionales.

Recomendamos este enfoque para las instancias de VM en las que se aplica lo siguiente:

  • Se debe poder acceder a la instancia de VM desde fuera de la VPC y las redes que están conectadas a la VPC.
  • La VM no forma parte de un perímetro de los Controles del servicio de VPC.
  • Solo se debe poder acceder a la VM desde ciertos dispositivos, redes o ubicaciones.

Cuando le otorgas a un usuario acceso SSH a una instancia de VM, ya sea directamente o a través de IAP, de forma predeterminada, puede acceder a la instancia de VM desde cualquier dispositivo, red y ubicación. Si bien es conveniente para los usuarios, este nivel de acceso aumenta los riesgos, ya que los usuarios pueden conectarse desde dispositivos vulnerados o redes no confiables.

Para reducir el riesgo, configura el reenvío de TCP de IAP para que los usuarios solo puedan acceder a las instancias de VM desde determinados dispositivos o ubicaciones. Puedes configurar este tipo de acceso adaptado al contexto de dos maneras:

  • Vinculaciones de acceso: Puedes crear un nivel de acceso y asignarlo a un grupo con una vinculación de acceso. Las vinculaciones de acceso son una forma o una política basada en la identidad y se aplican a todos los recursos a los que un usuario intenta acceder, lo que incluye IAP, pero también otras APIs y la consola de Google Cloud.

    El uso de vinculaciones de acceso funciona mejor si deseas asegurarte de que el acceso adaptado al contexto se aplique de forma uniforme en todos los recursos.

  • Condiciones de IAM: Puedes crear un nivel de acceso y asignarlo a vinculaciones de roles de IAM individuales con las condiciones de IAM.

    El uso de vinculaciones de roles de IAM es una forma de política basada en recursos, y el enfoque funciona mejor si deseas aplicar diferentes políticas a distintos conjuntos de VMs.

Los niveles de acceso básicos te permiten limitar el acceso por red o ubicación geográfica. Como suscriptor de Chrome Enterprise Premium, también puedes limitar el acceso según otros atributos, como la seguridad de las credenciales, la configuración del navegador que se usa para la autenticación o la posición del dispositivo.

Acceso SSH basado en los Controles del servicio de VPC

La idea de este enfoque es permitir solo el acceso de SSH a través del reenvío de TCP de IAP y configurar el perímetro de servicio para permitir la entrada de IAP para ciertas identidades de nuestras fuentes.

Recomendamos este enfoque para las instancias de VM que forman parte de un perímetro de los Controles del servicio de VPC.

Otorgar a los usuarios acceso SSH externo a una VM que forma parte de un perímetro de servicio puede ser riesgoso, ya que podría permitir que los usuarios socaven el perímetro de los Controles del servicio de VPC con el robo de datos a través de SSH.

Cuando solo permites el acceso SSH a través del reenvío de TCP de IAP, puedes reducir este riesgo y asegurarte de que todo el acceso SSH esté sujeto a la configuración del perímetro de los Controles del servicio de VPC:

  • Si un usuario intenta conectarse desde fuera del perímetro de servicio (como se ilustra en el ejemplo anterior), el reenvío de TCP de IAP no solo verifica si se le otorga acceso de IAM a la VM, sino que también verifica si la solicitud satisface alguna de las reglas de entrada del perímetro.

  • Si un usuario intenta conectarse desde el perímetro de servicio, el reenvío de TCP de IAP también verifica si se le otorga acceso de IAM a la VM, pero ignora las reglas de entrada de los Controles del servicio de VPC.

    IAP considera que una conexión se origina dentro de un perímetro de servicio si se aplica alguna de las siguientes condiciones:

    • La IP de origen es la dirección IP externa de una VM que forma parte del perímetro de servicio.
    • La conexión se realiza a través del Acceso privado a Google desde una VM que forma parte del perímetro de servicio.
    • La conexión se realiza a través de un extremo de acceso de Private Service Connect que forma parte del perímetro de servicio.

Acceso SSH interno controlado por firewall

La idea de este enfoque es inhabilitar todos los accesos externos y permitir solo el acceso SSH interno de la VPC.

Puedes usar este enfoque para las instancias de VM a las que se aplica lo siguiente:

  • No es necesario que se pueda acceder a la instancia de VM de forma externa.
  • La VM está conectada a una red interna de tamaño pequeño a mediano.
  • La VM no forma parte de un perímetro de los Controles del servicio de VPC.

Para inhabilitar todo los accesos externos, puedes realizar una de las siguientes acciones:

  • Implementar las instancias de VM sin una dirección IP externa.
  • Configurar reglas de firewall para que no se permita el tráfico SSH de entrada desde rangos de IP fuera de la VPC.

Inhabilita el acceso a la consola en serie

Para solucionar problemas de instancias de VM que no funcionan, Compute Engine te permite conectarte a la consola del puerto en serie de una instancia a través de una puerta de enlace SSH, ssh-serialport.googleapis.com. Se puede acceder a esta puerta de enlace de forma pública a través de Internet.

La puerta de enlace SSH accede a la VM a través del hipervisor subyacente en lugar de la red de VPC. Por lo tanto, el acceso a la consola en serie está controlado por las políticas de IAM y no por las reglas de firewall.

Permitir que los usuarios accedan a una consola en serie de la VM puede dejar la VM sobreexpuesta de forma no intencional. Para evitar esta sobreexposición, usa la restricción de la política de la organización compute.disableSerialPortAccess para inhabilitar el acceso a la consola en serie y quita la restricción temporalmente cuando necesites acceso de emergencia al puerto en serie de la VM.

Usa una VM de bastión si necesitas la grabación de la sesión

Cuando actúa como intermediario entre los dispositivos cliente y las VMs, el reenvío de TCP de IAP realiza funciones que suelen realizar los hosts de bastión o los servidores de salto. Estas funciones incluyen las siguientes:

  • Aplicar políticas de acceso de forma centralizada
  • Auditar el acceso

A diferencia de algunos hosts de bastión, el reenvío de TCP de IAP no finaliza las conexiones SSH: Cuando estableces una conexión SSH a una VM a través del reenvío de TCP de IAP, la conexión SSH se encripta de extremo a extremo entre tu cliente y la VM. Como resultado de esta encriptación de extremo a extremo, el reenvío de TCP de IAP no puede inspeccionar el contenido de la sesión de SSH ni proporcionar funciones de grabación de la sesión. Los registros de auditoría de IAP contienen metadatos de conexión, pero no revelan información sobre el contenido de la sesión.

Si necesitas la grabación de la sesión, usa una VM de bastión:

  • Configura la VM de bastión para que finalice las conexiones SSH y registre su contenido. Asegúrate de restringir el uso de la redirección de puertos SSH, ya que podría socavar la eficacia de la grabación de la sesión.
  • Configura reglas de firewall de las VMs de destino para que las conexiones SSH solo se permitan desde la VM de bastión.
  • Permite el acceso a la VM de bastión solo a través del reenvío de TCP de IAP

Usa políticas de firewall para restringir la exposición de SSH

Después de determinar qué forma de limitar la exposición de SSH funciona mejor para tu entorno, debes asegurarte de que todas las VMs y los proyectos estén configurados de manera adecuada. En particular, debes asegurarte de que todos los proyectos usen un conjunto coherente de reglas de firewall que determinen cómo se puede usar SSH.

Para aplicar un conjunto de reglas de firewall en varios proyectos, usa políticas jerárquicas de firewall y aplícalas a las carpetas de tu jerarquía de recursos.

Por ejemplo, para ayudar a imponer que todos los accesos SSH se realicen a través del reenvío de TCP de IAP, aplica una política de firewall que incluya las siguientes dos reglas personalizadas (en orden de prioridad):

  1. Permite la entrada de 35.235.240.0/20 al puerto 22 de las VMs seleccionadas. 35.235.240.0/20 es el rango de IP que usa el reenvío de TCP de IAP.
  2. Rechaza la entrada de 0.0.0.0/0 al puerto 22 de todas las VMs.

¿Qué sigue?