Prácticas recomendadas para controlar el acceso a la red SSH

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

Para conectarse a una instancia de VM mediante SSH, un usuario necesita acceso de red a la instancia de VM y credenciales SSH válidas. De forma predeterminada, Compute Engine utiliza una regla de cortafuegos que no restringe el acceso a la red SSH, pero permite que cualquier persona en Internet se conecte al puerto 22 de las instancias de VM. Aunque es una opción cómoda para que los desarrolladores empiecen rápidamente sin tener en cuenta los controles de red o de seguridad, permitir que los usuarios se conecten desde cualquier dispositivo, red y ubicación conlleva riesgos:

  • Es posible que los usuarios se conecten desde dispositivos o redes no fiables.
  • Los agentes perniciosos pueden lanzar ataques de fuerza bruta e intentar poner en riesgo tus instancias de VM.
  • Los atacantes que tengan acceso a credenciales SSH que se hayan filtrado o no se hayan revocado a tiempo pueden usarlas para acceder a una VM e iniciar sesión en ella desde cualquier red.

En las siguientes secciones se describe cómo puedes reducir el riesgo limitando las redes, las ubicaciones o los dispositivos desde los que los usuarios pueden establecer una conexión SSH con tus VMs:

El documento se centra en las prácticas que son específicas de Google Cloud o de especial relevancia cuando se usa SSH en Google Cloud. El documento no abarca las prácticas recomendadas para implementaciones específicas de clientes o servidores SSH.

Reducir la exposición de la red

Si permites que los usuarios establezcan conexiones SSH desde cualquier lugar, dependerás por completo de los mecanismos de autenticación y autorización SSH para proteger tus VMs. Puedes reducir los riesgos y establecer una capa de protección adicional reduciendo la exposición de las máquinas virtuales en la red.

Hay varias formas de reducir la exposición de la red de tus VMs. Para identificar el enfoque que mejor se adapte a tu entorno, debes tener en cuenta varios factores, como se muestra en el siguiente diagrama de flujo:

Reducir la exposición de la red

  • Acceso externo: el primer factor que debes tener en cuenta es si solo se debe poder acceder a la VM desde la red de VPC o si también necesitas que se pueda acceder a ella desde fuera.

    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 gestionar el acceso.

  • Tamaño de la red interna: si el acceso interno de la VPC es suficiente, el segundo factor que debes tener en cuenta es el tamaño de tu red interna.

    En redes más pequeñas, puede ser suficiente con usar reglas de cortafuegos que permitan el acceso al puerto 22 desde direcciones internas para proteger tus VMs. En redes más grandes, depender únicamente de las reglas de cortafuegos puede ser demasiado restrictivo. En esos casos, puedes usar Identity-Aware Proxy TCP-forwarding para implementar obligatoriamente el acceso contextual a las VMs.

  • Diseño del perímetro de Controles de Servicio de VPC: el siguiente factor que debes tener en cuenta es si la instancia de VM forma parte de un perímetro de Controles de Servicio de VPC.

    Si la VM forma parte de un perímetro de servicio, cualquier acceso a la API que se origine en la VM se considera que procede de dentro del perímetro. Si concedes acceso SSH a una VM situada dentro del perímetro a un usuario que se encuentra fuera de él, este podrá copiar datos del perímetro a su estación de trabajo local o viceversa, lo que puede poner en riesgo la confidencialidad y la integridad de los datos del perímetro.

    Cuando necesites conceder acceso SSH a una instancia de VM que forme parte de un perímetro de Controles de 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 Controles de Servicio de VPC y bloquea de forma predeterminada los intentos de acceso desde fuera del perímetro de servicio. Para permitir el acceso externo, usa reglas de entrada y configúralas para aplicar el acceso contextual.

  • Gestión de dispositivos cliente: el último factor que debes tener en cuenta es cómo se gestionan tus dispositivos cliente, ya que determina las formas en las que puedes controlar el acceso contextual.

    El acceso contextual es más eficaz cuando Access Context Manager tiene acceso a un amplio conjunto de señales sobre un usuario, su dispositivo y su ubicación. Por lo tanto, funciona junto con Chrome Enterprise Premium. Si utilizas Chrome Enterprise Premium para gestionar tus dispositivos, puedes configurar niveles de acceso que controlen el acceso en función de la postura del dispositivo. Después, puedes aplicar este nivel de acceso al acceso SSH mediante el reenvío de TCP de IAP en combinación con enlaces de acceso o condiciones de gestión de identidades y accesos.

    Si no controlas la configuración de un dispositivo cliente, debes considerarlo no gestionado y potencialmente no fiable.

    Para permitir el acceso desde dispositivos no gestionados, también puedes usar el reenvío de TCP de IAP, pero solo puedes gestionar el acceso en función de la identidad del usuario y la dirección IP del dispositivo. Como Administrador de contextos de acceso no tiene acceso a ninguna señal de dispositivo, no podrás restringir el acceso en función de la postura del dispositivo.

En función de los factores y con el diagrama de flujo, puedes identificar el enfoque para reducir la exposición de la red que mejor se adapte a tu entorno. En las siguientes secciones se describen estos enfoques con más detalle.

Acceso SSH basado en IAP

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

Recomendamos este enfoque para las instancias de VM que cumplan los siguientes requisitos:

  • 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 Controles de Servicio de VPC.

De forma predeterminada, una instancia de VM con una dirección IP externa permite el acceso SSH porque los cortafuegos predeterminados permiten conexiones desde Internet público al puerto 22, pero no es un enfoque recomendado. Este enfoque puede aumentar significativamente el riesgo de que la VM sea objeto de ataques como los siguientes:

  • Uso de credenciales no revocadas: los antiguos empleados cuyo acceso no se haya revocado por completo podrían seguir accediendo a la VM.
  • Uso inadecuado de credenciales válidas: los agentes maliciosos que tengan credenciales robadas o filtradas pueden usarlas para iniciar sesión.
  • Denegación de servicio: los agentes perniciosos pueden intentar agotar los recursos de la máquina virtual inundándola con 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 bastion o un proxy inverso, IAP TCP-forwarding actúa como intermediario entre el dispositivo cliente y la VM.

IAP TCP-forwarding realiza las cuatro funciones siguientes cuando un usuario intenta establecer una conexión SSH:

  • Autenticación: IAP verifica que el usuario tiene una credencial de Google válida.
  • Autorización: IAP comprueba las políticas de IAM para verificar que se ha concedido permiso al usuario para conectarse a la VM a través de IAP.
  • Acceso contextual: IAP puede verificar de forma opcional que el usuario, su dispositivo y su ubicación cumplen determinados niveles de acceso.
  • Auditoría: cuando se habilitan los registros de acceso a datos, IAP registra cada intento correcto y fallido de conectarse a una instancia de VM.

Al actuar como intermediario y realizar estas funciones, IAP elimina la necesidad de asignar una dirección IP externa a la VM y proporciona una capa de seguridad adicional.

Acceso SSH contextual basado en IAP

La idea de este enfoque es permitir el acceso SSH solo a través del reenvío de TCP de IAP y dejar que IAP controle el acceso en función de la identidad del usuario y otros factores.

Recomendamos este enfoque para las instancias de VM que cumplan los siguientes requisitos:

  • Se debe poder acceder a la instancia de VM desde fuera de la VPC y de las redes conectadas a la VPC.
  • La VM no forma parte de un perímetro de Controles de Servicio de VPC.
  • Solo se debe poder acceder a la VM desde determinados dispositivos, redes o ubicaciones.

Cuando concedes 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. Aunque es una opción cómoda para los usuarios, este nivel de acceso aumenta los riesgos, ya que los usuarios podrían conectarse desde dispositivos vulnerados o redes no fiables.

Para reducir el riesgo, configura el reenvío de TCP de IAP de forma que los usuarios solo puedan acceder a las instancias de VM desde determinados dispositivos o ubicaciones. Puedes configurar el acceso contextual de dos formas:

  • Vinculaciones de acceso: puedes crear un nivel de acceso y asignarlo a un grupo mediante una vinculación de acceso. Los enlaces de acceso son una forma de política basada en la identidad y se aplican a todos los recursos a los que un usuario intenta acceder, lo que incluye la compra en la aplicación, pero también otras APIs y la Google Cloud consola.

    Usar enlaces de acceso es la mejor opción si quieres asegurarte de que el acceso contextual se aplique de forma uniforme en todos los recursos.

  • Condiciones de IAM: puedes crear un nivel de acceso y asignarlo a enlaces de roles de IAM concretos mediante condiciones de IAM.

    El uso de vinculaciones de roles de gestión de identidades y accesos es una forma de política basada en recursos. Este método es el más adecuado si quieres aplicar políticas diferentes a distintos conjuntos de máquinas virtuales.

Los niveles de acceso básicos te permiten limitar el acceso por red o geolocalización. Si tienes una suscripción a Chrome Enterprise Premium, también puedes limitar el acceso en función de otros atributos, como la seguridad de las credenciales, la configuración del navegador que se usa para la autenticación o la postura del dispositivo.

Acceso SSH basado en Controles de Servicio de VPC

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

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

Conceder a los usuarios acceso SSH externo a una VM que forma parte de un perímetro de servicio puede ser arriesgado, ya que podría permitirles eludir el perímetro de Controles de Servicio de VPC filtrando datos a través de SSH.

Si 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 de tu perímetro de Controles de Servicio de VPC:

  • Si un usuario intenta conectarse desde fuera del perímetro de servicio (como se muestra en el ejemplo anterior), el reenvío de TCP de IAP no solo comprueba si el usuario tiene acceso de gestión de identidades y accesos a la VM, sino también si la solicitud cumple alguna de las reglas de entrada del perímetro.

  • Si un usuario intenta conectarse desde dentro del perímetro de servicio, IAP TCP-forwarding también comprueba si el usuario tiene acceso de IAM a la VM, pero ignora las reglas de entrada de Controles de Servicio de VPC.

    IAP considera que una conexión procede del interior de un perímetro de servicio si se cumple 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 de 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 punto final de acceso de Private Service Connect que forma parte del perímetro de servicio.

Acceso SSH interno controlado por cortafuegos

La idea de este enfoque es denegar todo el acceso externo y permitir solo el acceso SSH interno de la VPC.

Puedes usar este método en las instancias de VM que cumplan los siguientes requisitos:

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

Para denegar todo el acceso externo, puedes hacer lo siguiente:

  • Implementa las instancias de VM sin una dirección IP externa.
  • Configura reglas de cortafuegos para que no se permita el tráfico SSH de entrada desde intervalos de IP fuera de la VPC.

Inhabilitar el acceso a la consola en serie

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

La pasarela 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 serie se controla mediante políticas de gestión de identidades y accesos, no mediante reglas de cortafuegos.

Si permites que los usuarios accedan a la consola serie de una VM, puede que la VM quede expuesta sin querer. Para evitar esta sobreexposición, usa la compute.disableSerialPortAccessrestricción de política de organización para inhabilitar el acceso a la consola en serie y levanta la restricción temporalmente cuando necesites acceso de emergencia al puerto serie de la VM.

Usa una VM bastion si necesitas grabar sesiones

Al actuar como intermediario entre los dispositivos cliente y las VMs, el reenvío de TCP de IAP realiza funciones que suelen llevar a cabo los hosts bastion o los servidores de salto. Entre estas funciones, se incluyen las siguientes:

  • Aplicar políticas de acceso de forma centralizada
  • Auditoría de acceso

A diferencia de algunos hosts bastion, el reenvío de TCP de IAP no finaliza las conexiones SSH: cuando estableces una conexión SSH con una VM a través del reenvío de TCP de IAP, la conexión SSH se cifra de extremo a extremo entre tu cliente y la VM. Como resultado de este cifrado de extremo a extremo, IAP TCP-forwarding no puede inspeccionar el contenido de la sesión SSH y no ofrece funciones de grabación de sesiones. Los registros de auditoría de IAP contienen metadatos de conexión, pero no revelan ninguna información sobre el contenido de la sesión.

Si necesitas grabar sesiones, usa una VM bastion:

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

Usar políticas de cortafuegos para restringir la exposición de SSH

Una vez que hayas determinado cómo limitar la exposición de SSH que mejor se adapte a tu entorno, debes asegurarte de que todas las VMs y los proyectos estén configurados correctamente. En concreto, debe asegurarse de que todos los proyectos usen un conjunto coherente de reglas de cortafuegos que determinen cómo se puede usar SSH.

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

Por ejemplo, para asegurarse de que todo el acceso SSH se realiza a través del reenvío de TCP de IAP, aplique una política de cortafuegos que incluya las dos reglas personalizadas siguientes (por orden de prioridad):

  1. Permite el tráfico entrante de 35.235.240.0/20 al puerto 22 de las VMs seleccionadas. 35.235.240.0/20 es el intervalo de IPs que usa IAP para el reenvío de TCP.
  2. Deniega el acceso desde 0.0.0.0/0 al puerto 22 de todas las VMs.

Siguientes pasos