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 declarativas, 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 Comprensión de la herencia de políticas declarativas.
Dado que puede adjuntar varias políticas de control de servicios (SCP) en diferentes niveles en AWS Organizations, comprender cómo se evalúan las SCP puede ayudar a redactar SCP que produzcan el resultado correcto.
Temas
Cómo funcionan las SCP 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, al habilitar los SCP, se AWS Organizations adjunta una política de SCP AWS administrada denominada FullLawsAccess
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 de las SCP sigue un modelo de denegación por defecto, lo que significa que se niegan todos los permisos que no estén explícitamente permitidos en las SCP. Si las SCP no contienen una declaración de autorización en ninguno de los 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 funcionan las SCP con denegación
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 evalúa una política de denegación aplicable a cualquier nivel de la organización para todas las unidades organizativas y cuentas de los miembros que dependen de ella.
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
Estrategias para utilizar SCP
Al escribir los SCP, puede utilizar una combinación de Deny declaraciones Allow y para permitir las acciones y los 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 a las unidades organizativas, ya que cuando se aplican desde la raíz o OU-level afectan a todas las cuentas de la organización.
sugerencia
Puede utilizar los datos del último acceso al servicio de IAM para actualizar las SCP para 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 adjunta un SCP AWS administrado denominado FullLawsAccess Allow para permitir solo servicios específicos. Puedes elegir entre reemplazar FullLawsAccess en el nivel raíz o en todos los niveles. Si adjuntas un SCP de la lista de servicios permitidos específica para un servicio en la raíz, se aplica automáticamente a todas las unidades organizativas y cuentas incluidas en ella, lo que significa que una sola política a nivel de raíz determina la lista de servicios permitidos efectiva en toda la organización, como se muestra en el escenario 7. Como alternativa, puedes eliminar y reemplazar FulLawsAccess en cada unidad organizativa y cuenta, lo que te permitirá implementar listas de servicios permitidos más granulares que varían según las unidades organizativas o las cuentas individuales.
Nota: Confiar únicamente en las sentencias de permiso y en el modelo implícito de denegación por defecto puede provocar un acceso no deseado, ya que las sentencias de permiso 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 desasociar la política FullAWSAccess y asociar esta en su lugar.
Para demostrar cómo se pueden aplicar varias políticas de control de servicios (SCP) en AWS Organization, tenga presente la siguiente estructura organizativa y la siguientes situaciones.
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 unidad organizativa Sandbox tiene políticas de « AWS acceso total» y de «denegación del acceso a S3», y la cuenta B tiene una política de «denegación del acceso a EC2», la cuenta B no puede acceder a S3 (desde la denegación) ni a EC2 (desde la OU-level denegación a nivel de cuenta). La cuenta A no tiene acceso a S3 (debido a la denegación). OU-level
Situación 2: Las políticas de autorización deben existir en todos los niveles
Esta situación muestra cómo funcionan las políticas de permisos en las SCP. 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 unidad organizativa del entorno de pruebas tiene una política de “Permitir el acceso a EC2”, que solo permite el acceso a los servicios de EC2 de forma explícita, las cuentas A y B solo tendrán acceso a EC2.
Situación 3: Impacto de no incluir una instrucción Allow en el nivel raíz
Cuando la raíz solo tiene una sentencia de denegación sin una sentencia de « AWS acceso total» de permiso, todas las cuentas de los miembros no tienen acceso al servicio. Los SCP requieren un permiso explícito en cada nivel de la ruta. Por lo tanto, un Deny-only SCP en la raíz bloquea todos los servicios, a menos que estén cubiertos por un permiso explícito.
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 el acceso a EC2» y la unidad organizativa de producción tiene «acceso total AWS ». Por ello, la cuenta D tiene todo el acceso a los servicios, excepto la EC2, y las cuentas E y F tienen todo el acceso a los servicios.
Escenario 5: Permita que las políticas vigentes restrinjan el acceso OU-level a los servicios
Esta situación muestra cómo se pueden utilizar las políticas de autorización para restringir el acceso a servicios específicos. La unidad organizativa de prueba tiene una política de “Permitir el acceso a EC2”, lo que significa que solo se permiten los servicios de EC2 para la cuenta D. Por otro lado, la unidad organizativa de producción mantiene el “Acceso total a AWS ”, 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 y, al OU-level mismo tiempo, mantener un permiso más amplio en el nivel raíz.
Escenario 6: la Root-level denegación afecta a todas las cuentas, independientemente 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 de «denegación de 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 personalizadas de permisos a nivel raíz para restringir el acceso OU-level
Este escenario demuestra cómo funcionan los SCP con listas de permisos de servicio explícitas cuando se aplican a nivel raíz dentro de un AWS Organizations. En el nivel raíz de la organización, se adjuntan dos SCP personalizados que permiten el acceso de forma explícita a un conjunto limitado de AWS servicios: SCP_1 permite IAM y Amazon EC2, y SCP_2 permite Amazon S3 y Amazon. CloudWatch A nivel de unidad organizativa (OU), la política completa de AWS Access predeterminada permanece adjunta. Sin embargo, debido al comportamiento en las intersecciones, las cuentas A y B de estas unidades organizativas solo pueden acceder a los servicios permitidos explícitamente por el SCP de nivel raíz. La política raíz, más restrictiva, tiene prioridad y limita de manera efectiva el acceso únicamente a IAM, EC2, S3 y los CloudWatch servicios, independientemente de los permisos más amplios que se concedan en los niveles organizativos inferiores.
