SEC03-BP05 Definición de las barreras de protección de los permisos para una organización - Pilar de seguridad

SEC03-BP05 Definición de las barreras de protección de los permisos para una organización

Utilice las barreras de protección de permisos para reducir el ámbito de los permisos disponibles que se pueden conceder a las entidades principales. La cadena de evaluación de la política de permisos incluye sus barreras de protección para determinar los permisos efectivos de una entidad principal al tomar decisiones de autorización.  Puede definir barreras de protección mediante un enfoque basado en capas. Aplique algunas barreras de protección de manera generalizada en toda la organización y aplique otras de forma específica a las sesiones de acceso temporal.

Resultado deseado: cuenta con un aislamiento claro de los entornos mediante el uso de Cuentas de AWS separadas.  Las políticas de control de servicios (SCP) se utilizan para definir las barreras de protección de permisos en toda la organización. Las barreras de protección más amplias se establecen en los niveles jerárquicos más cercanos a la raíz de la organización, y las más estrictas se establecen más cerca del nivel de las cuentas individuales.

En los casos en los que se pueden utilizar, las políticas de recursos definen las condiciones que debe cumplir una entidad principal para tener acceso a un recurso. Las políticas de recursos también acotan el conjunto de acciones permitidas cuando corresponde. Los límites de permisos se aplican a entidades principales que administran permisos de las cargas de trabajo y delegan la administración de permisos a los propietarios individuales de las cargas de trabajo.

Patrones comunes de uso no recomendados:

  • Crear Cuentas de AWS de miembros dentro de una organización de AWS, pero no usar SCP para restringir el uso y los permisos disponibles para sus credenciales raíz.

  • Asignar permisos según el principio de privilegio mínimo, pero sin aplicar barreras de protección al conjunto máximo de permisos que se pueden conceder.

  • Confiar en el principio de denegación implícita de AWS IAM para restringir los permisos y esperar que las políticas no concedan un permiso explícito no deseado.

  • Ejecutar varios entornos de carga de trabajo en la misma Cuenta de AWS y, a continuación, recurrir a mecanismos como las VPC, las etiquetas o las políticas de recursos para hacer cumplir los límites de los permisos.

Beneficios de establecer esta práctica recomendada: las barreras de protección de permisos ayudan a generar confianza en que no se van a conceder permisos no deseados, incluso cuando una política de permisos intente hacerlo.  Esto puede simplificar la definición y la administración de los permisos al reducir el ámbito máximo de los permisos que deben tenerse en cuenta.

Nivel de riesgo expuesto si no se establece esta práctica recomendada: medio

Guía para la implementación

Le recomendamos que utilice un enfoque basado en capas para definir las barreras de protección de permisos para su organización. Este enfoque reduce sistemáticamente el conjunto máximo de permisos posibles a medida que se aplican capas adicionales. Esto le ayuda a conceder acceso según el principio de privilegios mínimos, lo que reduce el riesgo de accesos no deseados debidos a una configuración errónea de las políticas.

El primer paso para establecer barreras de protección de permisos es aislar las cargas de trabajo y los entornos en Cuentas de AWS separadas. Las entidades principales de una cuenta no pueden acceder a los recursos de otra cuenta sin un permiso explícito para hacerlo, incluso aunque ambas cuentas se encuentren en la misma organización de AWS o en la misma unidad organizativa (OU). Puede usar las unidades organizativas para agrupar las cuentas que prefiera administrar como una sola unidad.   

El siguiente paso consiste en reducir el conjunto máximo de permisos que puede conceder a las entidades principales dentro de las cuentas de los miembros de su organización. Para ello, puede usar las políticas de control de servicios (SCP), que puede aplicar a una unidad organizativa o a una cuenta. Las SCP pueden aplicar controles de acceso comunes, como restringir el acceso a determinadas Regiones de AWS, ayudar a evitar que se eliminen recursos o deshabilitar acciones de servicio potencialmente arriesgadas. Las SCP que se apliquen a la raíz de su organización solo afectan a las cuentas de los miembros, no a la cuenta de administración.  Las SCP solo controlan las entidades principales de su organización. Las SCP no controlan las entidades principales externas a su organización que accedan a sus recursos.

Si está utilizando AWS Control Tower, puede aprovechar sus controles y zonas de aterrizaje como base para sus barreras de protección de permisos y su entorno de múltiples cuentas. Las zonas de aterrizaje proporcionan un entorno básico seguro y preconfigurado con cuentas independientes para diferentes cargas de trabajo y aplicaciones. Las barreras de protección imponen controles obligatorios en materia de seguridad, operaciones y cumplimiento mediante una combinación de políticas de control de servicios (SCP), reglas de AWS Config y otras configuraciones. Sin embargo, cuando se utilizan las barreras de protección y las zonas de aterrizaje de Control Tower junto con los SCP personalizados de las organizaciones, es fundamental seguir las prácticas recomendadas descritas en la documentación de AWS para evitar conflictos y garantizar un gobierno adecuado. Consulte la guía de AWS Control Tower para AWS Organizations a fin de obtener recomendaciones detalladas sobre la administración de los SCP, las cuentas y las unidades organizativas (OU) en un entorno de Control Tower.

Si sigue estas directrices, podrá aprovechar de forma eficaz las barreras de protección, las zonas de aterrizaje y los SCP personalizados de Control Tower, a la vez que mitigará los posibles conflictos y garantizará el gobierno y el control adecuados de su entorno de múltiples cuentas de AWS.

Otro paso consiste en usar políticas de recursos de IAM para determinar el ámbito de las acciones disponibles que se pueden llevar a cabo con respecto a los recursos que controlan, junto con cualquier condición que deba cumplir la entidad principal activa. El ámbito puede ser tan amplio como para permitir todas las acciones siempre que la entidad principal forme parte de su organización (mediante la clave de condición PrincipalOrgID), o tan detallado como para permitir solo acciones específicas para un rol de IAM específico. Puede adoptar un enfoque similar con las condiciones de las políticas de confianza para un rol de IAM.  Si una política de confianza de recursos o roles nombra explícitamente una entidad principal en la misma cuenta que el rol o el recurso que controla, esa entidad principal no necesita una política de IAM asociada que otorgue los mismos permisos.  Si la entidad principal está en una cuenta diferente a la del recurso, esa entidad principal necesita una política de IAM asociada que otorgue esos permisos.

A menudo, un equipo de carga de trabajo querrá administrar los permisos que requiere su carga de trabajo.  Esto podría exigirles la creación de nuevos roles de IAM y políticas de permisos.  Puede definir el alcance máximo de los permisos que el equipo puede conceder dentro en un límite de permisos de IAM y asociar este documento a un rol de IAM que el equipo pueda utilizar posteriormente para gestionar sus permisos y roles de IAM.  Este método puede proporcionarles la capacidad de completar su trabajo y, al mismo tiempo, mitigar los riesgos de disponer de acceso administrativo a IAM.

Un paso más detallado consiste en implementar técnicas de administración de acceso privilegiado (PAM) y administración de acceso elevado temporal (TEAM).  Un ejemplo de PAM consiste en exigir a las entidades principales que lleven a cabo una autenticación multifactor antes de tomar medidas privilegiadas.  Para obtener más información, consulte Configuring MFA-protected API access. TEAM requiere una solución que administre la aprobación y el plazo en el que se permite que una entidad principal tenga acceso de alto nivel.  Un enfoque consiste en agregar temporalmente la entidad principal a la política de confianza del rol para un rol de IAM que tenga un acceso de alto nivel.  Otro enfoque consiste, en condiciones normales, en reducir los permisos que un rol de IAM concede a una entidad principal mediante una política de sesión y, a continuación, eliminar temporalmente esta restricción durante el periodo de tiempo aprobado. Para obtener más información sobre las soluciones que AWS y determinados socios han validado, consulte Temporary elevated access.

Pasos para la implementación

  1. Aísle las cargas de trabajo y los entornos en Cuentas de AWS separadas.

  2. Use las SCP para reducir el conjunto máximo de permisos que se pueden conceder a las entidades principales dentro de las cuentas de los miembros de su organización.

    1. Al definir las SCP para reducir el conjunto máximo de permisos que se pueden conceder a las entidades principales dentro de las cuentas de los miembros de su organización, puede elegir entre una estrategia de lista de permitidos o de lista de denegaciones. La estrategia de listas de permisos especifica de forma explícita el acceso permitido y bloquea de forma implícita todos los demás accesos. La estrategia de listas de permisos especifica de forma explícita el acceso permitido y permite de forma predeterminada todos los demás accesos. Ambas estrategias tienen sus ventajas y desventajas, y la elección adecuada depende de los requisitos específicos y del modelo de riesgo de su organización. Para obtener más información, consulte Strategy for using SCPs.

    2. Además, revise los ejemplos de políticas de control de servicios para comprender cómo construir los SCP de manera eficaz.

  3. Utilice las políticas de recursos de IAM para acotar y especificar las condiciones para las acciones permitidas en los recursos.  Use las condiciones de las políticas de confianza en roles de IAM para crear restricciones a la hora de asumir roles.

  4. Asigne límites de permisos de IAM a los roles de IAM que los equipos de carga de trabajo puedan usar para administrar sus propios roles y permisos de IAM en las cargas de trabajo.

  5. Evalúe las soluciones de PAM y TEAM en función de sus necesidades.

Recursos

Documentos relacionados:

Ejemplos relacionados:

Herramientas relacionadas: