Uso de AWS Organizations para la seguridad

Influya en el futuro de la arquitectura de referencia de AWS seguridad (AWS SRA) realizando una breve encuesta.

AWS Organizations le ayuda a administrar y gobernar su entorno de forma centralizada a medida que hace crecer y escalar sus recursos de AWS. Al usar AWS Organizations, puede crear nuevas cuentas de AWS mediante programación, asignar recursos, agrupar cuentas para organizar sus cargas de trabajo y aplicar políticas a las cuentas o grupos de cuentas para su control. Una organización de AWS consolida sus cuentas de AWS para que pueda administrarlas como una sola unidad. Tiene una cuenta de administración y cero o más cuentas de miembros. La mayoría de las cargas de trabajo residen en las cuentas de los miembros, excepto algunos procesos gestionados de forma centralizada que deben residir en la cuenta de administración o en las cuentas asignadas como administradores delegados para servicios específicos de AWS. Puede proporcionar herramientas y acceso desde una ubicación central para que su equipo de seguridad gestione las necesidades de seguridad en nombre de una organización de AWS. Puede reducir la duplicación de recursos al compartir los recursos críticos dentro de su organización de AWS. Puede agrupar las cuentas en unidades organizativas de AWS (OUs), que pueden representar diferentes entornos en función de los requisitos y el propósito de la carga de trabajo. AWS Organizations también proporciona varias políticas que le permiten aplicar de forma centralizada controles de seguridad adicionales a todas las cuentas de los miembros de sus organizaciones. Esta sección se centra en las políticas de control de servicios (SCPs), las políticas de control de recursos (RCPs) y las políticas declarativas.

Con AWS Organizations, puede usar SCPsy aplicar barreras de permisos RCPsa nivel de organización, unidad organizativa o cuenta de AWS. SCPs son barreras que se aplican a los directores de la cuenta de una organización, con la excepción de la cuenta de administración (que es una de las razones para no ejecutar cargas de trabajo en esta cuenta). Al conectar un SCP a una OU, el SCP lo heredan el SCP y las cuentas incluidas en esa OU. OUs SCPs no conceda ningún permiso. En su lugar, especifican los permisos máximos para una organización, unidad organizativa o cuenta de AWS. Aún así, debe adjuntar políticas basadas en la identidad o en los recursos a los directores o recursos de sus cuentas de AWS para concederles permisos. Por ejemplo, si un SCP deniega el acceso a todo Amazon S3, el principal afectado por el SCP no tendrá acceso a Amazon S3 aunque se le conceda el acceso de forma explícita a través de una política de IAM. Para obtener más información sobre cómo se evalúan las políticas de SCPs IAM, su función y cómo se concede o deniega el acceso en última instancia, consulte la lógica de evaluación de políticas en la documentación de IAM.

RCPs son barreras que se aplican a los recursos de las cuentas de una organización, independientemente de si los recursos pertenecen a la misma organización. Por ejemplo SCPs, RCPs no afectan a los recursos de la cuenta de administración ni conceden ningún permiso. Al adjuntar un RCP a una OU, el RCP lo hereda el RCP OUs y las cuentas de la OU lo heredan. RCPs proporcionan un control central sobre los permisos máximos disponibles para los recursos de su organización y, actualmente, admiten un subconjunto de servicios de AWS. Cuando diseñe SCPs para usted OUs, le recomendamos que evalúe los cambios mediante el simulador de políticas de IAM. También debe revisar los datos del servicio al que se accedió por última vez en IAM y utilizar AWS CloudTrail para registrar el uso del servicio a nivel de la API a fin de comprender el impacto potencial de los cambios en el SCP.

SCPs y RCPs son controles independientes. Puede optar por habilitar solo SCPs o RCPs usar ambos tipos de políticas juntas en función de los controles de acceso que desee aplicar. Por ejemplo, si quiere impedir que los directores de su organización accedan a recursos ajenos a ella, aplique este control mediante SCPs. Si desea restringir o impedir que las identidades externas accedan a sus recursos, aplique este control mediante RCPs. Para obtener más información y casos de uso de RCPs y SCPs, consulte Uso SCPs y RCPs en la documentación de AWS Organizations.

Puede utilizar las políticas declarativas de AWS Organizations para declarar y aplicar de forma centralizada la configuración que desee para un servicio de AWS determinado a escala en toda la organización. Por ejemplo, puede bloquear el acceso público a Internet a los recursos de Amazon VPC en toda su organización. A diferencia de las políticas de autorización, como SCPs y RCPs, las políticas declarativas se aplican en el plano de control de un servicio de AWS. Las políticas de autorización regulan el acceso a APIs, mientras que las políticas declarativas se aplican directamente a nivel de servicio para garantizar una intención duradera. Estas políticas ayudan a garantizar que la configuración básica de un servicio de AWS se mantenga siempre, incluso cuando el servicio introduzca nuevas funciones o APIs. La configuración básica también se mantiene cuando se añaden nuevas cuentas a una organización o cuando se crean nuevos directores y recursos. Las políticas declarativas se pueden aplicar a toda la organización o a cuentas específicas OUs .

Cada cuenta de AWS tiene un único usuario raíz que tiene permisos completos para todos los recursos de AWS de forma predeterminada.  Como práctica recomendada de seguridad, le recomendamos que no utilice el usuario raíz, excepto para algunas tareas que requieren explícitamente un usuario raíz. Si administra varias cuentas de AWS a través de AWS Organizations, puede deshabilitar de forma centralizada el inicio de sesión root y, a continuación, realizar acciones con privilegios root en nombre de todas las cuentas de los miembros. Tras gestionar de forma centralizada el acceso raíz de las cuentas de los miembros, puede eliminar la contraseña del usuario raíz, las claves de acceso y los certificados de firma, y desactivar la autenticación multifactor (MFA) para las cuentas de los miembros. Las cuentas nuevas que se crean mediante un acceso raíz gestionado de forma centralizada no tienen credenciales de usuario raíz de forma predeterminada. Las cuentas de los miembros no pueden iniciar sesión con su usuario raíz ni recuperar la contraseña de su usuario raíz.

AWS Control Tower ofrece una forma simplificada de configurar y gestionar varias cuentas. Automatiza la configuración de las cuentas en su organización de AWS, automatiza el aprovisionamiento, aplica barreras (que incluyen controles preventivos y de detección) y le proporciona un panel de control para mayor visibilidad. Se adjunta una política de administración de IAM adicional, un límite de permisos, a entidades de IAM específicas (usuarios o roles) y establece los permisos máximos que una política basada en la identidad puede conceder a una entidad de IAM.

AWS Organizations le ayuda a configurar los servicios de AWS que se aplican a todas sus cuentas. Por ejemplo, puede configurar el registro centralizado de todas las acciones realizadas en su organización de AWS mediante AWS CloudTrail e impedir que las cuentas de los miembros inhabiliten el registro. También puede agregar de forma centralizada los datos de las reglas que haya definido mediante AWS Config, de modo que pueda auditar sus cargas de trabajo para comprobar su conformidad y reaccionar rápidamente ante los cambios. Puede utilizar AWS CloudFormation StackSets para gestionar de forma centralizada las CloudFormation pilas de AWS en todas las cuentas y OUs en su organización de AWS, de forma que pueda aprovisionar automáticamente una nueva cuenta para cumplir sus requisitos de seguridad.

La configuración predeterminada de AWS Organizations admite el uso SCPs de listas de denegación. Al utilizar una estrategia de listas rechazadas, los administradores de las cuentas de los miembros pueden delegar todos los servicios y acciones hasta que cree y adjunte un SCP que deniegue un servicio o conjunto de acciones específicos. Las declaraciones de denegación requieren menos mantenimiento que una lista de permitidos, ya que no es necesario actualizarlas cuando AWS agrega nuevos servicios. Las declaraciones de rechazo suelen tener una longitud de caracteres más corta, por lo que es más fácil mantenerlas dentro del tamaño máximo para SCPs. En una declaración en la que el Effect elemento tenga un valor deDeny, también puede restringir el acceso a recursos específicos o definir las condiciones para cuando SCPs estén en vigor. Por el contrario, la instrucción Allow de un SCP se aplica a todos los recursos ("*") y no puede restringirse mediante condiciones. Para obtener más información y ejemplos, consulte Estrategia de uso SCPs en la documentación de AWS Organizations.

Consideraciones sobre el diseño

• Como alternativa, para usarlo SCPs como lista de permitidos, debe reemplazar el FullAWSAccess SCP administrado por AWS por un SCP que permita explícitamente solo los servicios y acciones que desee permitir. Para habilitar un permiso para una cuenta específica, todos los SCP (desde la raíz hasta cada unidad organizativa en la ruta directa a la cuenta e incluso los adjuntos a la propia cuenta) deben permitir ese permiso. Este modelo es de naturaleza más restrictiva y podría ser adecuado para cargas de trabajo delicadas y altamente reguladas. Este enfoque requiere que permita de forma explícita todos los servicios o acciones de IAM en la ruta desde la cuenta de AWS a la OU.

• Lo ideal sería utilizar una combinación de estrategias de listas de rechazos y listas de permitidos. Utilice la lista de permitidos para definir la lista de servicios de AWS permitidos y aprobados para su uso en una organización de AWS y adjunte este SCP a la raíz de su organización de AWS. Si su entorno de desarrollo permite un conjunto de servicios diferente, debe adjuntar el correspondiente SCPs en cada unidad organizativa. A continuación, puede utilizar la lista de denegaciones para definir las barreras empresariales denegando de forma explícita determinadas acciones de IAM.

• RCPs se aplican a los recursos de un subconjunto de servicios de AWS. Para obtener más información, consulte la lista de servicios de AWS compatibles RCPs en la documentación de AWS Organizations. La configuración predeterminada de AWS Organizations admite el uso de listas de denegación RCPs como listas de rechazo. Al activarla RCPs en su organización, se RCPFullAWSAccess adjunta automáticamente una política gestionada por AWS a la raíz de la organización, a todas las unidades organizativas y a todas las cuentas de la organización. No puede separar esta política. Este RCP predeterminado permite que todos los principales y las acciones accedan a la evaluación del RCP. Esto significa que, hasta que comience a crear y adjuntar RCPs, todos sus permisos de IAM actuales seguirán funcionando igual que antes. Esta política gestionada por AWS no concede acceso. A continuación, puede crear una nueva RCPs lista de declaraciones de denegación para bloquear el acceso a los recursos de su organización.