Prácticas recomendadas para controlar el acceso SSH

En este documento, se describen las prácticas recomendadas para controlar el acceso de acceso de 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 abarca todos los recursos, es posible que las personas/entidades que actúan de mala fe puedan conservar el acceso, incluso después de que se haya revocado su acceso.

Las siguientes secciones contienen prácticas recomendadas que te ayudan a garantizar una revocación eficaz del acceso y te protegen contra las amenazas de persistencia:

En el documento, se enfocan en 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 incluyen 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 de 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 raíz de usuario solo a la VM. Una clave subida a los metadatos del proyecto otorga a un usuario acceso a todas las VM 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 otorgas a un usuario privilegios de administrador o privilegios de usuario normal en la VM si otorgas el siguiente comando: Usuario administrador de Acceso al SO Rol de IAM o Usuario de Acceso al SO Función de IAM.

    La gcloud CLI, el cliente SSH integrado en el navegador de la consola de Google Cloud 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 cuando 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 permanece válida hasta que quites la clave o borres la VM o el proyecto. Suspender o borrar la cuenta de usuario no afecta 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 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 conservar el acceso SSH durante más tiempo del necesario si su clave pública no se quita de los metadatos de manera oportuna y es posible que incluso conserven el acceso después de salir. la organización. Aunque puedes reducir este riesgo mediante una revisión periódica de los metadatos, puede ser difícil en entornos más grandes y podría no ser suficiente porque las claves basadas en metadatos otorgan privilegios 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 aplicar el uso del 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á controladopor laenable-oslogin clave de metadatos Configuraciónenable-oslogin aTRUE en los metadatos del proyecto o de la instancia habilita el Acceso al SO, lo configura comoFALSE Inhabilita el Acceso al SO.

Para modificar los metadatos a nivel de 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 instancia, se requiere el permiso compute.instances.setMetadata en la instancia de VM respectiva.

Los metadatos de nivel de instancia tienen mayor prioridad que los metadatos a nivel de proyecto. Por lo tanto, configurar enable-oslogin como 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 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 de Acceso al SO, no confíes en configurar enable-oslogin como TRUE en los metadatos del proyecto. En su lugar, aplica Habilita el Acceso al SO para una organización mediante una política de la organización a fin de que cualquier intento de configurar enable-oslogin como false en los metadatos de la instancia o del proyecto se rechazan.

Otorga roles con privilegios de forma temporal o por VM

Si tienes instancias de VM que ejecutan diferentes cargas de trabajo y las administran diferentes equipos, puedes simplificar la administración de acceso si implementas estas VM en diferentes proyectos de Google Cloud y permites 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 distintos usuarios.

Siempre que un proyecto contenga una combinación de diferentes instancias de VM, evita otorgar de forma permanente funciones a los usuarios, 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:

  • 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 Google Cloud, pero no les permite publicar claves de 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 en el momento oportuno

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

La suspensión o la eliminación de una cuenta de usuario en Cloud Identity o Google Workspace revoca de forma automática 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 SSH, suspender o borrar una cuenta de usuario también revoca el acceso del usuario a las VM que usan Acceso al SO.

Si configuraste Cloud Identity o Google Workspace a fin de 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 propagar eventos de suspensión de usuarios a fin de 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 conectada.

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 VM 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 Google 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 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 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 los privilegios de raíz del usuario 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 a fin de mantener el acceso continuo 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 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 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 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 que son únicos en todos los proyectos de Google Cloud
  • una ruta de acceso al directorio principal
  • una 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 dentro de tu entorno de Google Cloud, pero pueden superponerse o ser incoherentes con los nombres de usuario y los UIDs que usas fuera de Google Cloud. Si necesitas que los nombres de usuario y los UIDs de acceso a OS 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 previamente perfiles POSIX de Acceso al SO y asignar nombres de usuario, UID y GID personalizados.

¿Qué sigue?