Prácticas recomendadas para controlar el acceso SSH

En este documento, se describen las prácticas recomendadas para controlar el acceso de acceso mediante 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 que los usuarios accedan cuando lo necesiten y revocar ese acceso cuando ya no lo necesiten. Si tu proceso para revocar el acceso no es confiable o no cubre todos los recursos, es posible que las personas que actúan de mala fe puedan conservar el acceso incluso después de que se debió revocar.

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

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

Usa Acceso al SO para garantizar una evaluación de acceso continua 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 de 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 a la VM. Una clave subida a los metadatos del proyecto le 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 a un usuario privilegios de raíz o privilegios de usuario normales en la VM. Para ello, otorga el rol de IAM Usuario administrador de Acceso al SO o el rol de IAM Usuario de Acceso al SO.

    La gcloud CLI, el cliente SSH integrado en el navegador de la Trusted Cloud 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 cuándo se evalúa el acceso en función de las políticas de IAM:

  • Con las claves de metadatos, el acceso se evalúa una sola 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 permanece válida hasta que quites la clave o borres la VM o el proyecto. Suspender o borrar la cuenta de usuario no tiene efecto en la validez de sus claves.

  • Con el Acceso al SO, el acceso se evalúa cada vez que un usuario intenta establecer una sesión de 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, ya no se podrán usar sus claves para otorgar acceso a SSH.

El uso de claves basadas en metadatos puede exponerte a amenazas de persistencia: los usuarios pueden retener el acceso a SSH por más tiempo del necesario si su clave pública no se quita de los metadatos de forma oportuna y hasta pueden retener 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 no ser suficiente, ya que las claves basadas en metadatos otorgan privilegios de raíz a los usuarios.

Para protegerte contra estas amenazas de persistencia, no permitas que los usuarios usen claves basadas en metadatos. En su lugar, configura tus proyectos para que apliquen el uso de Acceso al SO.

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

El Acceso al SO está controlado por la clave de metadatos enable-oslogin: Si configuras enable-oslogin como TRUE en los metadatos del proyecto o la instancia, se habilita el Acceso al SO. Si lo configuras 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). De manera similar, la modificación de los metadatos a nivel de la instancia requiere el permiso compute.instances.setMetadata en la instancia de VM respectiva.

Los metadatos a nivel de la instancia tienen prioridad sobre los metadatos a nivel del proyecto. Por lo tanto, configurar enable-oslogin como TRUE en los metadatos del proyecto no es suficiente para forzar 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 una instancia de VM en el proyecto pueden anular tu configuración si agregan enable-oslogin=FALSE a los metadatos de la instancia de VM.

Para aplicar un 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 opción Habilitar Acceso al SO para una organización mediante una política de la organización para que se rechacen los intentos de establecer enable-oslogin en false en los metadatos de la instancia o del proyecto.

Otorga roles con privilegios de forma temporal o por VM

Si tienes instancias de VM que ejecutan cargas de trabajo diferentes y que administran diferentes equipos, puedes simplificar la administración de accesos implementando estas VMs en diferentes proyectos deTrusted 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 las que solo diferentes usuarios deben poder acceder a ellas.

Cuando un proyecto contenga una combinación de este tipo de instancias de VM diferentes, evita otorgar roles de forma permanente a los usuarios, como Administrador de instancias de Compute a nivel del proyecto. En su lugar, 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 de solo lectura equivalente a nivel del proyecto. Este rol permite a los usuarios explorar VMs con la consola de Trusted Cloud , pero no les permite publicar claves SSH ni acceder a las VMs.
  • Otorgar a los usuarios Acceso al SO, Administrador de instancias de Compute o otros roles privilegiados solo para VMs individuales o solo a pedido

Suspende las cuentas de usuario cuando estos abandonen la organización

Si suspendes o borras una cuenta de usuario en Cloud Identity o Google Workspace, se revocan automáticamente los permisos de IAM del usuario. Debido a 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 en tu IdP externo y 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 sesiones de navegador nuevas para acceder a los servicios de Google, pero no tiene un impacto inmediato en el Acceso a SO: Mientras la cuenta de usuario de Cloud Identity o Google Workspace del empleado permanezca activa, el Acceso a SO seguirá permitiendo que el usuario se autentique y establezca conexiones SSH.

Para revocar de forma confiable el acceso a 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 los eventos de suspensión del usuario, 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 lo verifica 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 a 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 adjuntes una cuenta de servicio a la VM, a menos que la carga de trabajo requiera acceso a los recursos de Trusted Cloud .
  • Usa una cuenta de servicio de propósito único y solo otórgale acceso a los recursos que necesita la carga de trabajo.
  • Exige que los usuarios soliciten un 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 raíz

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 otorgas a un usuario el rol de usuario administrador de Acceso al SO (roles/compute.osAdminLogin), usas la autorización de claves basada en metadatos en lugar del Acceso al SO o permites que los usuarios modifiquen los metadatos de la VM, otorgas implícitamente al usuario 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 pueden 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 los 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 perfiles POSIX previamente para garantizar nombres de usuario y UIDs 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 al usuario de Linux con 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 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 de invitado también te permite elegir el nombre de usuario que deseas usar. Si eliges un nombre de usuario que usó un compañero de trabajo anteriormente, accederás con la cuenta que se creó inicialmente para tu compañero de trabajo.

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 únicos en todos los Trusted Cloud proyectos
  • una ruta de acceso al directorio principal
  • configuración adicional, como una shell de acceso

Si tu Cuenta de Google no tiene un perfil POSIX cuando accedes por primera vez, el Acceso a SO te crea uno automáticamente.

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

¿Qué sigue?