Esta publicación contiene configuraciones prácticas que podrás implementar en IAM, las cuales mejorarán en gran medida la seguridad de tu proyecto. Si no puedes o no deseas hacer todos los cambios, aún es beneficioso implementar un subconjunto de ellos, porque cada una mejora tu seguridad individualmente.
Forzar la autenticación multifactor (MFA)
La autenticación multifactor es un método en el que no solo se utiliza una pieza de información para autenticar a un usuario (por ejemplo, una contraseña), sino que también se necesita al menos una fuente de prueba adicional para establecer que la persona adecuada está accediendo a un sistema.
En Google Cloud Platform, los usuarios se autentican mediante cuentas de Google. Estas pueden ser direcciones de correo electrónico individuales registradas como una cuenta de Google o (más comúnmente) cuentas de un dominio de Google Suite. En el lado de Google Cloud Platform, este no puede exigir que las cuentas de Google que tienen acceso a tu proyecto tengan MFA habilitado. Pero, sí solo se otorga acceso a los usuarios desde su dominio de Google Suite, entonces el administrador del dominio de Google Suite puede configurar MFA en el dominio de Google Suite de una manera que obligue a todos a usarlo. Si necesita dar acceso a personas sin cuentas en su dominio de Google Suite, puede crear cuentas para ellos en su dominio de Google Suite con el único propósito de acceder a su proyecto. De esta manera, puede aplicar la configuración en sus cuentas.
Si combinas ambas reglas, puedes estar segur@ de que tod@s los usuarios que tengan acceso al proyecto en Google Cloud Platform deberán validarse a sí mismos utilizando MFA. Esto hace que sea mucho más difícil vulnerar tu proyecto, incluso si la contraseña de una dirección de correo electrónico se filtra de otra fuente.
Aquí puedes encontrar la información sobre cómo aplicar la autenticación MFA (para dominios de Google Suite, MFA utiliza 2 factores) para dominios de Google Suite: https://support.google.com/a/answer/2548882
Configurar la política de contraseña para usuarios
La configuración de la política de contraseña no está técnicamente dentro de Google Cloud Platform, sino a discreción del Administrador de dominio de Google Suite. Si usted únicamente permite usuarios de su dominio y el dominio está configurado con la política de contraseña correcta, estas dos cosas combinadas darán lugar a la política de contraseña que se aplicará a todos sus usuarios de GCP.
Aquí puede encontrar más información sobre cómo configurar los requisitos de contraseña para su dominio de Google Suite: https://support.google.com/a/answer/139399?hl=en
Dar los privilegios necesarios pero los menos posibles
En general, es una buena práctica otorgar los privilegios mínimos necesarios a todos tus usuarios. Si todos los métodos de protección de cuentas discutidos anteriormente fallan, tus atacantes aún tendrán menos servicios para ingresar o robar información.
La implementación real de este principio variará según tus patrones de uso. Por ejemplo, si los administradores de tu base de datos solo necesitan realizar tareas de administración de Google Cloud SQL, no les otorgue un rol de Editor de proyectos; en su lugar, ofrézcales un rol de administrador de Cloud SQL.
Verifica los roles relacionados con Google Compute Engine
La mayoría de los roles en IAM son fáciles de entender. Incluso tienen descripciones para ayudar a decidir cuál desea usar para un escenario específico. Sin embargo, hay algunas excepciones notables, en las que es bastante difícil decidir qué rol es suficiente para una operación específica. Por ejemplo, los roles relacionados con Google Compute Engine (GCE) están un poco complicados, especialmente porque se han introducido nuevas reglas que están ahora en la etapa beta.
Lo más importante a tener en cuenta es que muchas funciones relacionadas con GCE le otorgan acceso SSH a las instancias mismas. Y, si la instancia está ejecutando Linux, GCE crea la cuenta de una manera que le permite sudo para convertirse en root. Si no desea este "efecto secundario" cuando asigna funciones relacionadas con la CME, debe consultar la documentación para obtener más detalles: https://cloud.google.com/compute/docs/access/
Establecer cuotas
Las cuotas predeterminadas se establecen para cada proyecto recién creado en Google Cloud Platform. Este es un control de seguridad de último recurso para evitar gastos descontrolados inesperados. Por ejemplo, si tiene una secuencia de comandos defectuosa que crea recursos de manera recursiva, solo podrá crearlos hasta los límites de cuota. También puede proteger contra una cuenta comprometida creando muchos recursos nuevos para los propósitos del atacante.
Las cuotas se pueden cambiar en la página Cuotas, pero requiere el permiso serviceusage.quotas.update, que solo se incluye en los siguientes roles predefinidos: Propietario, Editor y Administrador de cuotas. Entonces, si una cuenta comprometida o un script defectuoso no tiene este permiso, entonces el gasto solo puede aumentar hasta los límites de la cuota.
Verificar y rotar las claves de la cuenta de servicio (service account)
Hay otro tipo de cuenta en Google Cloud Platform además de las cuentas de usuario: Cuentas de servicio.
Las cuentas de servicio están destinadas a casos de uso programático. No se pueden usar para acceder a Google Cloud Console porque solo son válidos para el acceso a Google Cloud API. El caso de uso más frecuente es ejecutar aplicaciones o instancias que hereden los derechos de una cuenta de servicio específica, para que puedan acceder a otros servicios en la nube sin autenticación adicional. En otras secciones hablaré más al respecto.
Las cuentas de servicio usan claves para la autenticación. Una cuenta de servicio puede tener varias claves asociadas. Es una buena práctica rotar regularmente las claves de la cuenta de servicio. Esto se puede lograr creando una nueva clave para la cuenta de servicio, luego sobrescribiendo la clave actual con la nueva en todas partes donde se guardó, y luego eliminando la clave anterior asociada con la cuenta de servicio. De esta manera, incluso si una aplicación donde se almacenó la clave se ve comprometida sin su conocimiento, el atacante solo tendrá un período de tiempo limitado para usar la clave.
Más información sobre la seguridad de IAM
Puede encontrar información adicional en la documentación de Google Cloud Platform sobre la seguridad de IAM en esta página: https://cloud.google.com/iam/docs/using-iam-securely
Si su organización es una gran empresa, debe consultar las pautas de seguridad escritas especialmente para clientes más grandes aquí: https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations
Gracias por leer y compartir. Cada me "gusta" ayuda a que seguimos colaborando y compartiendo conocimiento en español. Si te interesa más estos temás, te invito a estar pendiente a este y otros medios:
Twitter: @gelopfalcon
Youtube: https://youtu.be/275XdckjJz0
Facebook: https://www.facebook.com/falconcoach87
Nos vemos pronto!!!
Top comments (0)