Prácticas recomendadas para controlar el acceso de inicio de sesión SSH

En este documento se describen las prácticas recomendadas para controlar el acceso de inicio de sesión SSH a instancias de máquinas virtuales (VM) Linux.

Para gestionar de forma eficaz el acceso SSH a las instancias de VM, debes permitir que los usuarios accedan cuando lo necesiten y revocar ese acceso cuando ya no lo necesiten. Si el proceso para revocar el acceso no es fiable o no abarca todos los recursos, los agentes perniciosos podrían mantener el acceso incluso después de que se les haya revocado.

En las siguientes secciones se incluyen prácticas recomendadas que te ayudarán a revocar el acceso de forma eficaz y a protegerte frente a las amenazas persistentes:

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.

Usar OS Login para asegurar la evaluación continua del acceso en función de las políticas de gestión de identidades y accesos

Las imágenes públicas de Linux de Compute Engine están configuradas para permitir la autenticación con claves públicas SSH. Para autorizar la clave pública de un usuario y concederle permiso para establecer una sesión SSH, puedes usar uno de los dos mecanismos siguientes:

  • Autorización de claves basada en metadatos: como administrador, puedes subir la clave pública de un usuario a los metadatos de una VM o de un proyecto o permitir que los usuarios hagan la subida por sí mismos concediéndoles permiso para modificar los metadatos.

    Una clave pública subida a los metadatos de una sola VM concede al usuario privilegios de superusuario solo en esa VM. Una clave subida a los metadatos del proyecto concede al usuario acceso a todas las VMs del proyecto.

  • Autorización de claves de inicio de sesión en el SO: como usuario, puedes subir una o varias claves públicas a tu perfil de inicio de sesión en el SO, que forma parte de tu cuenta de usuario de Google.

    Como administrador, puedes decidir si quieres conceder a un usuario privilegios de superusuario o de usuario normal en la VM. Para ello, puedes asignarle el rol de gestión de identidades y accesos Usuario administrador de inicio de sesión del SO o el rol de gestión de identidades y accesos Usuario de inicio de sesión del SO.

    La interfaz de línea de comandos de gcloud, el cliente SSH de la consola en el navegador y IAP Desktop detectan automáticamente qué mecanismo estás usando y pueden subir la clave de un usuario en consecuencia. Google Cloud

Una diferencia clave entre los dos mecanismos es cuándo se evalúa el acceso en función de las políticas de gestión de identidades y accesos:

  • Con las claves de metadatos, el acceso se evalúa solo una vez, en el momento de la subida de la clave.

    La clave del usuario está vinculada al ciclo de vida de la VM o del proyecto y sigue siendo válida hasta que elimines la clave o la VM o el proyecto. Suspender o eliminar la cuenta de usuario no afecta a la validez de sus claves.

  • Con el inicio de sesión del SO, el acceso se evalúa cada vez que un usuario intenta establecer una sesión SSH.

    La clave del usuario está vinculada al ciclo de vida de su cuenta de usuario. Si suspendes o eliminas a un usuario en Cloud Identity o Google Workspace, sus llaves ya no se podrán usar para conceder acceso SSH.

Si usas claves basadas en metadatos, puedes exponerte a amenazas persistentes: los usuarios podrían conservar el acceso SSH durante más tiempo del necesario si su clave pública no se elimina de los metadatos a tiempo, e incluso podrían conservar el acceso después de abandonar la organización. Aunque puedes reducir este riesgo rastreando los metadatos con regularidad, puede ser difícil hacerlo en entornos más grandes y puede que no sea suficiente, ya que las claves basadas en metadatos conceden privilegios de administrador a los usuarios.

Para protegerte frente a este tipo de amenazas persistentes, no permitas que los usuarios utilicen claves basadas en metadatos. En su lugar, configura tus proyectos para que se aplique el uso de OS Login.

Usar políticas de organización para aplicar el uso coherente de OS Login

OS Login se controla mediante la clave de metadatos enable-oslogin: si se asigna el valor TRUE a enable-oslogin en los metadatos del proyecto o de la instancia, se habilita OS Login; si se asigna el valor FALSE, se inhabilita.

Para modificar los metadatos a nivel de proyecto, necesitas el compute.projects.setCommonInstanceMetadata permiso en el proyecto. Este permiso forma parte de los roles Administrador de instancias de Compute (roles/compute.instanceAdmin.v1) y Administrador de Compute (roles/compute.admin). Del mismo modo, para modificar los metadatos a nivel de instancia, se necesita el permiso compute.instances.setMetadata en la instancia de VM correspondiente.

Los metadatos a nivel de instancia tienen mayor prioridad que los metadatos a nivel de proyecto. Por lo tanto, definir enable-oslogin como TRUE en los metadatos del proyecto no es suficiente para aplicar el uso de OS Login en todo el proyecto: los usuarios con el rol Administrador de instancias de Compute o un acceso equivalente a una instancia de VM del proyecto pueden anular tu configuración añadiendo enable-oslogin=FALSE a los metadatos de la instancia de VM.

Para asegurar que se usa OS Login de forma coherente, no definas enable-oslogin en TRUE en los metadatos del proyecto. En su lugar, aplica la política de organización Habilitar el inicio de sesión con el SO en una organización para que se rechacen los intentos de definir enable-oslogin como false en los metadatos de la instancia o del proyecto.

Asignar roles con privilegios de forma temporal o por VM

Si tienes instancias de VM que ejecutan diferentes cargas de trabajo y que gestionan distintos equipos, puedes simplificar la gestión del acceso desplegando estas VMs en diferentesGoogle Cloud proyectos y permitiendo que los proyectos usen una red compartida. Sin embargo, usar proyectos independientes no siempre es viable y algunos de tus proyectos pueden contener una combinación de instancias de VM, donde solo diferentes usuarios deberían tener acceso a diferentes instancias de VM.

Cuando un proyecto contenga una combinación de instancias de VM diferentes, no concedas permanentemente a los usuarios roles como Administrador de instancias de Compute a nivel de proyecto. En su lugar, distingue entre el acceso de solo lectura y el acceso con privilegios:

  • Concede a los usuarios el rol Lector de Compute o un rol equivalente de solo lectura en el proyecto. Este rol permite a los usuarios consultar las VMs mediante la consola de Google Cloud , pero no les permite publicar claves SSH ni acceder a las VMs.
  • Concede a los usuarios los roles de inicio de sesión de SO de Compute, administrador de instancias de Compute u otros roles con privilegios solo para VMs concretas o solo cuando sea necesario.

Suspender cuentas de usuario cuando los usuarios abandonen la organización

Si suspendes o eliminas una cuenta de usuario en Cloud Identity o Google Workspace, se revocarán automáticamente los permisos de gestión de identidades y accesos del usuario. Como el inicio de sesión del SO comprueba los permisos de gestión de identidades y accesos de un usuario antes de permitirle establecer una sesión SSH, si se suspende o se elimina una cuenta de usuario, también se revoca el acceso del usuario a las VMs que usan el inicio de sesión del SO.

Si has configurado Cloud Identity o Google Workspace para usar un proveedor de identidades externo para el inicio de sesión único, los empleados tendrán una cuenta de usuario tanto en tu proveedor de identidades externo como en Cloud Identity o Google Workspace. Si inhabilitas o eliminas la cuenta de usuario de un empleado en tu proveedor de identidades externo, se le revocará la capacidad de establecer nuevas sesiones de navegador para acceder a los servicios de Google, pero no tendrá ningún efecto inmediato en el inicio de sesión del SO. Mientras la cuenta de usuario de Cloud Identity o de Google Workspace del empleado siga activa, el inicio de sesión del SO seguirá permitiendo que el usuario se autentique y establezca conexiones SSH.

Para revocar de forma fiable el acceso SSH cuando un usuario abandone la organización, asegúrate de suspender o eliminar su cuenta de usuario de Cloud Identity o Google Workspace. Si usas un IdP externo, configúralo para que propague los eventos de suspensión de usuarios de forma que Inicio de sesión del SO pueda revocar el acceso.

Evita conceder acceso SSH a las VMs que tengan una cuenta de servicio con privilegios

Si una instancia de VM tiene una cuenta de servicio asociada, las aplicaciones que se ejecuten en la VM podrán solicitar credenciales de corta duración al servidor de metadatos de la VM y usar estas credenciales para actuar como la cuenta de servicio.

Tener acceso SSH a una VM te otorga privilegios similares: al igual que una aplicación, puedes solicitar credenciales de corta duración al servidor de metadatos de la VM y actuar como la cuenta de servicio adjunta.

Como tener acceso SSH a una VM con una cuenta de servicio adjunta te permite actuar como la cuenta de servicio, el inicio de sesión del SO requiere que tengas el permiso iam.serviceAccounts.actAs en la cuenta de servicio y comprueba este permiso cada vez que te conectas a la instancia de VM. De esta forma, el inicio de sesión del SO ayuda a mantener la seguridad de la cuenta de servicio e impide que se abuse del acceso SSH para apropiarse de privilegios.

Para reducir aún más los riesgos asociados a las máquinas virtuales que tienen cuentas de servicio con privilegios, puedes usar las siguientes alternativas:

  • No asigne una cuenta de servicio a la VM a menos que la carga de trabajo requiera acceso a los Google Cloud recursos.
  • Usa una cuenta de servicio de un solo uso y concédele acceso solo a los recursos que necesite la carga de trabajo.
  • Pide a los usuarios que soliciten acceso just-in-time en lugar de concederles acceso a la VM y a la cuenta de servicio de forma permanente.

Limitar el uso de privilegios de superusuario

Cuando usas OS Login y asignas a un usuario el rol Usuario de OS Login (roles/compute.osLogin), le asignas privilegios de usuario limitados en la VM. Por el contrario, si asignas a un usuario el rol Usuario administrador de inicio de sesión del SO (roles/compute.osAdminLogin), utilizas la autorización de claves basada en metadatos en lugar de Inicio de sesión del SO o permites que los usuarios modifiquen los metadatos de la VM, estás concediendo implícitamente privilegios de superusuario al usuario en la VM.

Si concedes privilegios de superusuario a los usuarios en una VM, puedes exponerte a riesgos de persistencia: los usuarios pueden abusar de estos privilegios para crear nuevas cuentas de usuario o instalar puertas traseras para mantener el acceso persistente a la VM.

Para reducir este riesgo de persistencia, limita el uso de privilegios de superusuario y concede el rol Usuario de inicio de sesión del SO (roles/compute.osLogin) solo cuando no se necesiten privilegios de superusuario.

Crear perfiles POSIX previamente para asegurar que los nombres de usuario y los UIDs sean coherentes

Cada máquina virtual Linux mantiene una base de datos local de usuarios (/etc/passwd) y grupos (/etc/groups). Cuando te conectas por primera vez a una máquina virtual Linux mediante SSH, el entorno invitado crea automáticamente una cuenta de usuario de Linux y le asigna un UID.

Cuando usas claves basadas en metadatos, el entorno invitado no vincula el usuario de Linux a tu cuenta de usuario de Google y puede asignarte un UID diferente en cada VM a la que te conectes. Si usas protocolos como NFS que asumen que los UIDs son coherentes en un entorno que no los aplica de forma coherente en todas las máquinas, los usuarios podrían, accidentalmente o, en el caso de agentes malintencionados, deliberadamente, acceder de forma remota como otro usuario.

Cuando usas claves basadas en metadatos, el entorno invitado también te permite elegir el nombre de usuario que quieras usar. Si eliges un nombre de usuario que haya usado un compañero anteriormente, iniciarás sesión con la cuenta que se creó inicialmente para ese compañero.

Puedes evitar estas ambigüedades de UID y nombre de usuario usando OS Login: cuando inicias sesión por primera vez en una VM Linux con OS Login, el entorno invitado crea un usuario de Linux basado en el perfil POSIX de tu cuenta de usuario de Google. El perfil POSIX sirve como plantilla para los usuarios de Linux y define lo siguiente:

  • Un nombre de usuario de Linux que sea único para todos los usuarios de la misma cuenta de Cloud Identity o Google Workspace
  • Un UID y un GID únicos en todos los Google Cloud proyectos
  • una ruta de directorio principal
  • configuración adicional, como un shell de inicio de sesión

Si tu cuenta de Google no tiene un perfil POSIX cuando inicias sesión por primera vez, Inicio de sesión con SO creará uno automáticamente.

El nombre de usuario y los UIDs asignados por OS Login son únicos en tu Google Cloud entorno, pero pueden coincidir o no ser coherentes con los nombres de usuario y los UIDs que utilices fuera de Google Cloud. Si necesitas que los nombres de usuario y los UIDs de Inicio de sesión del SO sean coherentes en otros entornos, es mejor que no dependas de la creación automática de perfiles. En su lugar, usa la API Directory para crear previamente perfiles POSIX de OS Login y asignar nombres de usuario, UIDs y GIDs personalizados.

Siguientes pasos