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 copia de seguridad, 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 con instrucciones Deny en Evitar que las cuentas de miembros dejen la organización. en la raíz, que será efectiva 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
Puede utilizar los datos del servicio al que accedió por última vez en IAM para actualizarlos SCPs y restringir el acceso únicamente a los Servicios de AWS que necesite. 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. Puede elegir entre reemplazar Full AWSAccess en el nivel raíz o en todos los niveles. Si adjuntas una lista de permisos específica de un servicio (SCP) en la raíz, se aplicará automáticamente a todas las OUs cuentas incluidas en ella, lo que significa que una única política de nivel raíz determina la lista de servicios permitidos efectiva en toda la organización, como se muestra en el escenario 7. Como alternativa, puede eliminar y reemplazar la opción Completa AWSAccess en cada unidad organizativa y cuenta, lo que le permitirá implementar listas de servicios más detalladas que difieran según las unidades organizativas o las cuentas individuales.
Nota: Confiar únicamente en las instrucciones de autorización y en el deny-by-default modelo implícito puede provocar un acceso no deseado, ya que las instrucciones de autorización más amplias o superpuestas pueden anular las más restrictivas.
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.
Situación 1: impacto de las políticas Deny
Esta sitación demuestra cómo las políticas Deny afectan a las siguientes cuentas en los niveles superiores de la organización. 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 (denegación a nivel de cuenta). La cuenta A no tiene acceso a S3 (denegado desde el nivel de UO).
Situación 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 permisos. 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.
Situación 3: impacto de no incluir una instrucción Allow en el nivel raíz
La omisión de una instrucción «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.
Situación 4: instrucciones Deny por capas y los permisos resultantes
Esta situación muestra una estructura de una unidad organizativa profunda de dos niveles. Tanto la unidad organizativa raíz como la unidad organizativa de cargas de trabajo tienen « AWS acceso total», la unidad organizativa de prueba tiene « AWS acceso total» con «Denegar EC2 acceso» y la unidad organizativa de producción tiene «acceso total». AWS Como resultado, la cuenta D tiene todo el acceso al servicio, excepto EC2 las cuentas E y F, todo el acceso al servicio.
Situación 5: permitir que las políticas a nivel de la unidad organizativa restrinjan el acceso al servicio
Esta situación 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 unidad organizativa y, al mismo tiempo, mantener una autorización más amplia a nivel raíz.
Situación 6: la denegación a nivel raíz afecta a todas las cuentas, independiente de los permisos de nivel inferior
Esta situación demuestra que una política de denegación en el nivel raíz afecta a todas las cuentas de la organización, independiente 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 a nivel raíz. La cuenta D no tiene acceso al servicio porque la unidad organizativa 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.
Escenario 7: políticas de permisos personalizadas a nivel raíz para restringir el acceso a nivel de OU
Este escenario demuestra cómo funcionan las listas de permisos SCPs con un servicio explícito cuando se aplican a nivel raíz dentro de un. AWS Organizations En el nivel raíz de la organización, SCPs se adjuntan dos «Service Allow» personalizados que permiten explícitamente el acceso a un conjunto limitado de AWS servicios: SCP_1 permite IAM y Amazon, y SCP_2 permite EC2 Amazon S3 y Amazon. CloudWatch A nivel de unidad organizativa (OU), la política completa predeterminada permanece adjunta. AWSAccess Sin embargo, debido al comportamiento de intersección, las cuentas A y B correspondientes solo OUs pueden acceder a los servicios permitidos explícitamente por el SCP de nivel raíz. Prevalece la política raíz, más restrictiva, que limita de manera efectiva el acceso únicamente a IAM, S3 y los CloudWatch servicios EC2, independientemente de los permisos más amplios que se concedan en los niveles organizativos más bajos.
