Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Evaluación de SCP
nota
La información de esta sección no se aplica a los tipos de políticas de administración, incluidas las políticas de respaldo, las políticas de etiquetas, las políticas de aplicaciones de chat o las políticas de exclusión de los servicios de IA. Para obtener más información, consulte Descripción de la herencia de políticas de administración.
Como puede adjuntar varias políticas de control de servicios (SCPs) en diferentes niveles AWS Organizations, comprender cómo SCPs se evalúan puede ayudarle a redactar las SCPs que arrojen el resultado correcto.
¿Cómo SCPs trabajar con Allow
Para que se conceda un permiso a una cuenta específica, debe haber una declaración Allow explícita en cada nivel, desde la raíz hasta cada unidad organizativa situada en la ruta directa a la cuenta (incluida la propia cuenta de destino). Por eso, cuando lo habilita SCPs, AWS Organizations adjunta una política SCP AWS administrada llamada Full AWSAccess
Por ejemplo, veamos la situación que se muestra en las figuras 1 y 2. Para permitir un permiso o un servicio en la cuenta B, la SCP que permita el permiso o el servicio debe estar vinculada a la raíz, a la unidad organizativa de producción y a la propia cuenta B.
La evaluación del SCP sigue un deny-by-default modelo, lo que significa que se deniegan todos los permisos que no SCPs estén explícitamente permitidos en el sistema. Si no hay una declaración de autorización en ninguno de los SCPs niveles, como raíz, unidad organizativa de producción o cuenta B, se deniega el acceso.
Figura 1: Ejemplo de estructura organizativa con una declaración Allow adjunta en la raíz, la OU de producción y la cuenta B
Figura 2: Ejemplo de estructura organizativa con una declaración Allow faltante en la OU de producción y su impacto en la cuenta B
¿Cómo SCPs trabajar con Deny
Si se niega un permiso para una cuenta específica, cualquier SCP desde la raíz hasta cada unidad organizativa situada en la ruta directa a la cuenta (incluida la propia cuenta de destino) puede denegar ese permiso.
Por ejemplo, supongamos que hay una SCP adjunta a la OU de producción que tiene una declaración Deny explícita especificada para un servicio determinado. Resulta que también hay otra SCP conectada a la raíz y a la cuenta B que permite explícitamente el acceso a ese mismo servicio, como se muestra en la figura 3. Como resultado, se negará el acceso al servicio tanto a la cuenta A como a la cuenta B, ya que se aplica una política de denegación a cualquier nivel de la organización para todas las cuentas OUs y las cuentas de los miembros que dependen de él.
Figura 3: Ejemplo de estructura organizativa con una declaración Deny adjunta en la OU de producción y su impacto en la cuenta B
Estrategia de uso SCPs
Al escribir SCPs , puede utilizar una combinación de Deny declaraciones Allow y declaraciones para permitir las acciones y servicios previstos en su organización. DenyLas declaraciones son una forma eficaz de implementar restricciones que deberían aplicarse a una parte más amplia de la organización o OUs porque, cuando se aplican a nivel raíz o de la OU, afectan a todas las cuentas que la integran.
Por ejemplo, puede implementar una política utilizando los Deny estados de cuenta a Evitar que las cuentas de miembros dejen la organización. nivel raíz, lo que será efectivo para todas las cuentas de la organización. Las declaraciones de denegación también admiten un elemento de condición que puede ser útil para crear excepciones.
sugerencia
Puedes usar los datos del servicio al que accediste por última vez en IAM para actualizarlos SCPs y restringir el acceso únicamente a los Servicios de AWS que necesites. Para obtener más información, consulte Visualización de los datos del último acceso al servicio de Organizations en la Guía del usuario IAM.
AWS Organizations Cuando se crea, adjunta un SCP AWS gestionado denominado Full AWSAccessAllow para permitir solo servicios específicos.
Una política que combine las dos declaraciones podría ser como la del ejemplo siguiente, que impide que las cuentas de los miembros salgan de la organización y permite el uso de los servicios AWS deseados. El administrador de la organización puede separar la AWSAccess política completa y adjuntar esta en su lugar.
Para demostrar cómo se pueden aplicar varias políticas de control de servicios (SCPs) en una AWS organización, considere la siguiente estructura organizativa y los escenarios siguientes.
Escenario 1: Impacto de las políticas de denegación
Este escenario demuestra cómo las políticas de denegación en los niveles superiores de la organización afectan a todas las cuentas siguientes. Cuando la OU Sandbox tiene políticas de « AWS acceso total» y «Denegar el acceso a S3», y la cuenta B tiene una política de «denegación de EC2 acceso», el resultado es que la cuenta B no puede acceder a S3 (denegación a nivel de OU) ni EC2 (denegada a nivel de cuenta). La cuenta A no tiene acceso a S3 (denegado a nivel de OU).
Escenario 2: Las políticas de autorización deben existir en todos los niveles
En este escenario se muestra cómo funcionan las políticas de autorización SCPs. Para que un servicio sea accesible, debe haber un permiso explícito en todos los niveles, desde la raíz hasta la cuenta. En este caso, dado que la OU Sandbox tiene una política de «permitir el EC2 acceso», que solo permite el acceso al EC2 servicio de forma explícita, las cuentas A y B solo tendrán EC2 acceso.
Escenario 3: Impacto de no incluir una sentencia Allow en el nivel raíz
La omisión de una declaración de «Permitir» en el nivel raíz de un SCP es un error de configuración crítico que bloqueará de manera efectiva todo acceso a los AWS servicios y acciones de todas las cuentas de los miembros de la organización.
Escenario 4: sentencias de denegación por capas y los permisos resultantes
Este escenario muestra una estructura de OU profunda de dos niveles. Tanto la OU raíz como la de cargas de trabajo tienen « AWS acceso total», la OU de prueba tiene « AWS acceso total» con «Denegar EC2 acceso» y la OU de producción tiene « AWS acceso total». Como resultado, la cuenta D tiene todo el acceso al servicio, excepto EC2 las cuentas E y F, todo el acceso al servicio.
Escenario 5: Permitir que las políticas a nivel de la OU restrinjan el acceso al servicio
Este escenario muestra cómo se pueden utilizar las políticas de autorización para restringir el acceso a servicios específicos. La OU de prueba tiene una política de «permitir el EC2 acceso», lo que significa que solo se permiten EC2 los servicios para la cuenta D. La OU de producción mantiene el « AWS acceso total», por lo que las cuentas E y F tienen acceso a todos los servicios. Esto demuestra cómo se pueden implementar políticas de permisos más restrictivas a nivel de la OU y, al mismo tiempo, mantener una autorización más amplia a nivel raíz.
Escenario 6: La denegación a nivel raíz afecta a todas las cuentas, independientemente de los permisos de nivel inferior
Este escenario demuestra que una política de denegación en el nivel raíz afecta a todas las cuentas de la organización, independientemente de las políticas de autorización en los niveles inferiores. La raíz tiene políticas de « AWS acceso total» y «Denegar el acceso a S3». Si bien la unidad organizativa de prueba tiene una política de «permitir el acceso a S3», prevalece la denegación por parte de S3 en el nivel raíz. La cuenta D no tiene acceso al servicio porque la OU de prueba solo permite el acceso a S3, pero la S3 se deniega en el nivel raíz. Las cuentas E y F pueden acceder a otros servicios, excepto a S3, debido a la denegación explícita en el nivel raíz.
