Prácticas recomendadas para controlar el acceso SSH

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

Para administrar de manera eficaz el acceso SSH a las instancias de VM, debes permitir el acceso a los usuarios cuando lo necesiten y revocarlo cuando ya no lo necesiten. Si tu proceso para revocar el acceso no es confiable o no abarca todos los recursos, es posible que las personas que actúan de mala fe puedan conservar el acceso incluso después de que se debería haber revocado.

En las siguientes secciones, se incluyen prácticas recomendadas que te ayudan a garantizar la revocación de acceso eficaz y a protegerte contra las amenazas de persistencia:

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.

Usa el Acceso al SO para garantizar la evaluación continua del acceso en función de las políticas de IAM

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 otorgarle permiso para establecer una sesión de SSH, puedes usar uno de los siguientes dos mecanismos:

  • Autorización de clave basada en metadatos: Como administrador, subes la clave pública del usuario a los metadatos de VM o proyecto o permites que los usuarios realicen la carga por su cuenta cuando le otorgas permiso para modificar los metadatos.

    Una clave pública subida a los metadatos de una sola VM otorga al usuario privilegios de raíz solo para esa VM. Una clave subida a los metadatos del proyecto otorga al usuario acceso a todas las VMs del proyecto.

  • Autorización de clave de Acceso al SO: Como usuario, subes una o más claves públicas a tu perfil de Acceso al SO, que es parte de tu cuenta de usuario de Google.

    Como administrador, puedes decidir si otorgar privilegios de administrador raíz o de usuario normal en la VM otorgando el rol de IAM de Administrador de Acceso al SO o el rol de IAM de Usuario de Acceso al SO.

    La gcloud CLI, el Google Cloud cliente SSH integrado en el navegador de la consola y IAP Desktop detectan automáticamente qué mecanismo estás usando y pueden subir la clave de un usuario según corresponda.

Una diferencia clave entre los dos mecanismos es el momento en que se evalúa el acceso en función de las políticas de IAM:

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

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

  • Con el Acceso al SO, se evalúa el acceso 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 borras un usuario en Cloud Identity o Google Workspace, sus claves ya no se podrán usar para otorgar acceso SSH.

El uso de llaves basadas en metadatos puede exponerte a amenazas de persistencia: Es posible que los usuarios conserven el acceso SSH durante más tiempo del necesario si su llave pública no se quita de los metadatos de manera oportuna, y es posible que incluso conserven el acceso después de abandonar la organización. Si bien puedes reducir este riesgo si revisas los metadatos con regularidad, hacerlo puede ser difícil en entornos más grandes y podría ser insuficiente porque las claves basadas en metadatos otorgan privilegios de raíz a los usuarios.

Para ayudar a proteger contra este tipo de amenazas de persistencia, no permitas que los usuarios usen claves basadas en metadatos. En su lugar, configura tus proyectos para que se aplique el uso del Acceso al SO.

Usa políticas de la organización para aplicar el uso coherente del Acceso al SO

El Acceso al SO se controla con la clave de metadatos enable-oslogin: Si se configura enable-oslogin como TRUE en los metadatos del proyecto o la instancia, se habilita el Acceso al SO; si se configura como FALSE, se inhabilita.

Para modificar los metadatos a nivel del proyecto, necesitas el permiso compute.projects.setCommonInstanceMetadata en el proyecto. Este permiso forma parte de los roles de 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 la instancia, se requiere el permiso compute.instances.setMetadata en la instancia de VM respectiva.

Los metadatos a nivel de la instancia tienen mayor prioridad que los metadatos a nivel del proyecto. Por lo tanto, establecer enable-oslogin en TRUE en los metadatos del proyecto no es suficiente para aplicar el uso del Acceso al SO en todo el proyecto: los usuarios con el rol de administrador de instancias de Compute o acceso equivalente a instancias de VM en el proyecto pueden anular tu configuración agregando enable-oslogin=FALSE a los metadatos de la instancia de VM.

Para garantizar el uso coherente del Acceso al SO, no confíes en configurar enable-oslogin como TRUE en los metadatos del proyecto. En su lugar, aplica la política de la organización Habilita el Acceso al SO para una organización con una política de la organización para que se rechacen todos los intentos de establecer enable-oslogin en false en los metadatos del proyecto o la instancia.

Otorga roles con privilegios de forma temporal o por VM

Si tienes instancias de VM que ejecutan diferentes cargas de trabajo y son administradas por diferentes equipos, puedes simplificar la administración de acceso implementando estas VMs en diferentes proyectos deGoogle Cloud y permitiendo que los proyectos usen una red compartida. Sin embargo, usar proyectos separados no siempre es viable, y algunos de tus proyectos pueden contener una combinación de instancias de VM, en la que diferentes instancias de VM solo deberían ser accesibles para diferentes usuarios.

Siempre que un proyecto contenga tal combinación de diferentes instancias de VM, evita otorgar de forma permanente a los usuarios roles como Administrador de instancias de Compute a nivel del proyecto. En cambio, distingue entre el acceso de solo lectura y el acceso con privilegios:

  • Otorga a los usuarios el rol de Visualizador de Compute o un rol equivalente de solo lectura a nivel del proyecto. Este rol permite a los usuarios explorar VMs con la consola de Google Cloud , pero no les permite publicar claves SSH ni acceder a las VMs.
  • Otorga a los usuarios los roles de Acceso al SO de Compute, Administrador de instancias de Compute o cualquier otro rol con privilegios solo para VMs individuales o solo de forma just-in-time.

Suspende las cuentas de usuario cuando los usuarios abandonen la organización

La suspensión o eliminación de una cuenta de usuario en Cloud Identity o Google Workspace revoca automáticamente los permisos de IAM del usuario. Dado que el Acceso al SO verifica los permisos de IAM de un usuario antes de permitirle establecer una sesión de SSH, suspender o borrar una cuenta de usuario también revoca el acceso del usuario a las VMs que usan el Acceso al SO.

Si configuraste Cloud Identity o Google Workspace para usar un IdP externo para el inicio de sesión único, los empleados tienen una cuenta de usuario tanto en tu IdP externo como en Cloud Identity o Google Workspace. Si inhabilitas o borras la cuenta de usuario de un empleado en tu IdP externo, se revoca su capacidad de establecer nuevas sesiones del navegador para acceder a los servicios de Google, pero no se genera un impacto inmediato en el Acceso al SO: Mientras la cuenta de usuario de Cloud Identity o Google Workspace del empleado permanezca activa, el Acceso al SO seguirá permitiendo que el usuario se autentique y establezca conexiones SSH.

Para revocar de forma confiable el acceso SSH cuando un usuario abandona la organización, asegúrate de suspender o borrar su cuenta de usuario de Cloud Identity o Google Workspace. Si usas un IdP externo, configúralo para que propague eventos de suspensión de usuarios de modo que el Acceso al SO pueda revocar el acceso.

Evita otorgar acceso SSH a las VMs que tienen una cuenta de servicio con privilegios

Si una instancia de VM tiene una cuenta de servicio adjunta, las aplicaciones que se ejecutan en la VM pueden solicitar credenciales de corta duración del 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 del servidor de metadatos de la VM y actuar como la cuenta de servicio adjunta.

Dado que tener acceso SSH a una VM con una cuenta de servicio adjunta te permite actuar como la cuenta de servicio, Acceso al SO requiere que tengas el permiso iam.serviceAccounts.actAs en la cuenta de servicio y verifica este permiso cada vez que te conectas a la instancia de VM. De esta manera, el Acceso al SO ayuda a mantener la seguridad de la cuenta de servicio y evita que se abuse del acceso SSH para la elevación de privilegios.

Para mitigar aún más los riesgos asociados con las VMs que tienen cuentas de servicio con privilegios, considera las siguientes alternativas:

  • No conectes una cuenta de servicio a la VM, a menos que la carga de trabajo requiera acceso a recursos de Google Cloud .
  • Usa una cuenta de servicio de propósito único y otórgale acceso solo a los recursos que necesita la carga de trabajo.
  • Exige que los usuarios soliciten acceso justo a tiempo en lugar de otorgarles acceso a la VM y a la cuenta de servicio de forma permanente.

Limita el uso de privilegios de administrador

Cuando usas el Acceso al SO y le otorgas a un usuario el rol de Usuario de Acceso al SO (roles/compute.osLogin), le asignas privilegios de usuario limitados en la VM. En cambio, cuando le otorgas a un usuario el rol de Usuario administrador de Acceso al SO (roles/compute.osAdminLogin), usas la autorización de clave basada en metadatos en lugar del Acceso al SO o permites que los usuarios modifiquen los metadatos de la VM, le otorgas implícitamente privilegios de raíz en la VM.

Otorgar privilegios de raíz a los usuarios en una VM puede exponerte a riesgos de persistencia: Los usuarios podrían abusar de estos privilegios para crear cuentas de usuario nuevas o instalar puertas traseras para mantener el acceso persistente a la VM.

Para ayudar a reducir este riesgo de persistencia, limita el uso de privilegios de raíz y solo otorga el rol de Usuario de Acceso al SO (roles/compute.osLogin) cuando no se requieran privilegios de raíz.

Crea previamente perfiles POSIX para garantizar nombres de usuario y UID coherentes

Cada VM de Linux mantiene una base de datos local de usuarios (/etc/passwd) y grupos (/etc/groups). Cuando te conectas por primera vez a una VM de Linux mediante SSH, el entorno invitado crea un usuario de Linux de forma automática 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 podría asignarte un UID diferente en cada VM a la que te conectes. Si usas protocolos como NFS que suponen UIDs coherentes en un entorno que no aplica UIDs coherentes en todas las máquinas, es posible que los usuarios puedan realizar un acceso remoto como otro usuario, ya sea de forma accidental o, en el caso de que haya personas que actúan de mala fe, de forma deliberada.

Cuando usas claves basadas en metadatos, el entorno invitado también te permite elegir el nombre de usuario que deseas usar. Si eliges un nombre de usuario que ya usó un compañero de trabajo, accederás con la cuenta que se creó inicialmente para él.

Puedes evitar estas ambigüedades de UID y nombre de usuario mediante el acceso a SO: cuando accedes por primera vez a una VM de Linux mediante el acceso al SO, 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 que son únicos en todos los proyectos de Google Cloud
  • Ruta de acceso a un directorio principal
  • configuración adicional, como un shell de acceso

Si tu Cuenta de Google no tiene un perfil POSIX cuando accedes por primera vez, el acceso al SO creará uno automáticamente.

El nombre de usuario y los UID que asigna el Acceso al SO son únicos dentro de tu entorno de Google Cloud, pero pueden superponerse o ser incoherentes con los nombres de usuario y los UID que usas fuera de Google Cloud. Si necesitas que los nombres de usuario y los UID del Acceso al SO sean coherentes en otros entornos, lo mejor es no depender de la creación automática de perfiles. En cambio, usa la API de Directory para crear previamente perfiles POSIX de Acceso al SO y asignar nombres de usuario, UIDs y GIDs personalizados.

¿Qué sigue?