SEC03-BP05 Definir las barreras de protección de los permisos para su 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 a la hora de 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: disponer de 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.
Antipatrones usuales:
-
Crear Cuentas de AWS de miembros dentro de una AWS Organization
, 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 fundamento 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 aunque 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. Puede usar políticas de control de servicios (SCP) para este propósito, 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 tu 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. Sus SCP no controlan las entidades principales externas a su organización que accedan a sus recursos.
Un paso posterior consiste en usar políticas de recursos de IAM para determinar el ámbito de las acciones disponibles que puede 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 de los roles 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, entonces 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 en un límite de permisos de IAM y asociar este documento a un rol de IAM que el equipo pueda usar posteriormente para administrar sus roles y permisos de IAM. Este enfoque puede proporcionarles la libertad de completar su trabajo y, al mismo tiempo, mitigar los riesgos de disponer de acceso administrativo a IAM.
Una medida más detallada consiste en implementar técnicas de administración de acceso privilegiado (PAM) y administración de acceso de alto nivel temporal (TEAM). Un ejemplo de PAM consiste en exigir a las entidades principales que realicen una autenticación multifactor antes de tomar medidas privilegiadas. Para obtener más información, consulte «Configuring MFA-protected API access». El TEAM requiere una solución que gestione 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 se basa, en condiciones de funcionamiento normales, en reducir los permisos concedidos a una entidad principal por un rol de IAM mediante una política de sesión y, a continuación, en levantar temporalmente esta restricción durante el período de tiempo aprobado. Para obtener más información sobre las soluciones validadas por AWS y socios seleccionados, consulte «Temporary elevated access».
Pasos para la implementación
-
Aísle las cargas de trabajo y los entornos en Cuentas de AWS separadas.
-
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.
-
Le recomendamos que, a la hora de redactar las SCP, adopte un enfoque de lista de permitidos que deniegue todas las acciones excepto las que usted permita, y aquellas condiciones en las que estén permitidas. Comience por definir los recursos que quiera controlar y defina el efecto en Denegar. Utilice el elemento NotAction para denegar todas las acciones excepto las que especifique. Combine esto con una condición NotLike para definir cuándo se permiten estas acciones, si corresponde, como StringNotLike y ArnNotLike.
-
Consulte los ejemplos de políticas de control de servicios.
-
-
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 funciones.
-
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.
-
Evalúe las soluciones de PAM y TEAM en función de sus necesidades.
Recursos
Documentos relacionados:
Ejemplos relacionados:
Herramientas relacionadas: