¿Cómo maneja su empresa / organización la propiedad de la cuenta en la nube?

Tom

Aquí hay un buen enlace sobre la jerarquía de roles y permisos de Google Cloud Platform.

Uso de la jerarquía de recursos para el control de acceso | Documentación de gestión de acceso e identidad en la nube
El | Google Cloud Platform

En un nivel alto, dependiendo de qué tan grande sea su organización, puede haber múltiples proyectos para diferentes líneas de negocios o diferentes cargas de trabajo de desarrollo / prueba / producción. Realmente depende de cómo esté estructurada la organización de su empresa. También puede tener múltiples propietarios dentro de un proyecto.

Mejores prácticas que he pegado a continuación desde el enlace de arriba:

• Refleje la estructura de la jerarquía de políticas de IAM en la estructura de su organización. La jerarquía de políticas de IAM debe reflejar cómo está organizada su empresa, ya sea una startup, una PYME o una gran corporación. Un inicio puede comenzar con una jerarquía de política plana sin recursos de la Organización. Cuando más personas comienzan a colaborar en proyectos y aumenta el número de proyectos, puede tener sentido obtener un recurso de la Organización. Se recomienda un recurso de Organización para empresas más grandes con múltiples departamentos y equipos donde cada equipo es responsable de su propio conjunto de aplicaciones y servicios.
• Use proyectos de Cloud Platform para agrupar recursos que comparten el mismo límite de confianza. Por ejemplo, los recursos para el mismo producto o microservicio pueden pertenecer al mismo proyecto de Cloud Platform.
• Establezca políticas a nivel de Organización y a nivel de Proyecto en lugar de a nivel de recursos. Esto se debe a que a medida que se agregan nuevos recursos, es posible que desee que hereden automáticamente las políticas de su recurso principal. Por ejemplo, a medida que se agregan nuevas máquinas virtuales al proyecto mediante el escalado automático, heredan automáticamente la política del proyecto.
• Use el principio de seguridad de menor privilegio para otorgar roles de IAM, es decir, solo otorgue la menor cantidad de acceso necesario a sus recursos.
• Otorgue roles a un grupo de Google en lugar de a usuarios individuales cuando sea posible. Es más fácil agregar y eliminar miembros de un grupo de Google en lugar de actualizar una política de Cloud IAM para agregar o eliminar usuarios.
• Controle la propiedad del grupo de Google utilizado en las políticas de IAM.
• Otorgue roles al menor alcance necesario. Por ejemplo, si un usuario solo necesita acceso para publicar mensajes en un tema Pub / Sub, otorgue la función de editor al usuario para ese tema.
• Recuerde que una política establecida en un recurso hijo no puede restringir el acceso otorgado en su padre. Verifique la política otorgada en cada recurso y comprenda la herencia jerárquica.
• Si necesita otorgar un rol a un usuario o grupo que abarca varios proyectos, establezca ese rol en el nivel de la organización en lugar de establecerlo en el nivel del proyecto.
• Use etiquetas para anotar, agrupar y filtrar recursos.
• Audite sus políticas para garantizar el cumplimiento. Los registros de auditoría en la nube contienen todas las llamadas a setiampolicy para que pueda rastrear cuándo se ha promulgado una política.
• Audite la propiedad y la membresía de los grupos de Google utilizados en las políticas.
• Si desea limitar la creación de proyectos en su organización, cambie la política de acceso de la organización para otorgar el rol de creador de proyectos a un grupo que administre.

Gracias por el a2a!

Trataré de responder la pregunta directamente sin dar toda la historia de Identify Management o Authentication vs Authorization.

Para las organizaciones con las que he trabajado, ninguna de estas empresas usa la cuenta raíz en AWS. Esa es una mala práctica general, y algo que debe evitarse.

Cuenta raíz: la combinación de dirección de correo electrónico / contraseña que utiliza para iniciar sesión en la consola de AWS cuando crea una cuenta o se ocupa de ciertas funciones administrativas, como cerrar la cuenta. Hay claves API asociadas con la cuenta raíz: ELIMINARLAS.

La cuenta raíz se usa para crear la estructura básica para el resto de las entidades de la organización, y todas usarán objetos IAM o STS para acceder a servicios o recursos.

La mayoría de las empresas se beneficiarán al separar los recursos de producción y no producción en dos cuentas de AWS diferentes, con cuentas raíz separadas, y luego utilizar el acceso a cuentas cruzadas a través de roles de IAM cuando sea necesario.

Cada individuo y / o servicio debe usar uno de los siguientes para acceder:

1. Cuenta de usuario de IAM específica para ese usuario o servicio
2. Perfil de instancia o rol de IAM vinculado a un recurso específico. Esto puede otorgar acceso a aplicaciones, instancias de EC2, acceso de servicio cruzado y acceso de cuenta cruzada y es muy flexible.
3. Federación con un sistema de gestión de identidad local como LDAP o AD.

Las organizaciones pueden crear cuentas separadas por otros motivos, como la separación de las funciones de auditoría de seguridad, o para segregar las cargas de trabajo por razones de gobierno / cumplimiento. Si la empresa está compuesta por departamentos con sus propios equipos de TI, esta puede ser otra razón para cuentas separadas.

Resumen: AWS es flexible, elija el método que tenga más sentido para su organización, pero definitivamente aprenda cómo funciona el acceso de cuentas cruzadas para que pueda comprender todas las opciones disponibles para usted.

En mi empresa, soy el tipo que posee la cuenta de facturación, luego, según IAM, apruebo el acceso específico de cada personal a los módulos que necesitan desarrollar / mantener. Por supuesto, el líder técnico puede acceder a todo el proyecto que lidera y el CTO puede acceder a todo el sistema.