Evaluación de SCP - AWS Organizations

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 exclusión de servicios de IA, las políticas de copia de seguridad o las políticas de etiqueta. Para obtener más información, consulte Descripción de la herencia de políticas de administración.

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.

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, cuando habilita las SCP, AWS Organizations adjunta una política de SCP de AWS administrada llamada FullAWSAccess que permite todos los servicios y acciones. Si esta política se elimina y no se reemplaza en ningún nivel de la organización, todas las OU y cuentas que estén por debajo de ese nivel quedarán bloqueadas y no podrán realizar acciones.

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.

Notas
  • Una declaración de Allow en un SCP permite al elemento Resource para tener solo una entrada de "*".

  • Un registro Allow en una SCP no puede tener un elemento Condition en absoluto.

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 redactar las SCP, puede utilizar una combinación de declaraciones Allow y declaraciones Deny para permitir las acciones y servicios previstos en su organización. Las declaraciones Deny son una forma eficaz de implementar restricciones que deberían aplicarse a una parte más amplia de la organización o de la unidad organizativa, ya que, cuando se aplican a nivel raíz o a nivel de la unidad organizativa, afectan a todas las cuentas que dependen de ella.

Por ejemplo, puede implementar el uso de una política en Evitar que las cuentas de miembros dejen la organización. en el nivel 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 ú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 asocia una SCP administrada por AWS denominada FullAWSAccess a cada raíz, unidad organizativa y cuenta en el momento de su creación. Esta política permite todos los servicios y acciones. Puede sustituir FullAWSAccess por una política que permita solo un conjunto de servicios, de modo que no se permitan nuevos servicios de AWS a menos que se los permita explícitamente mediante la actualización de las SCP. Por ejemplo, si su organización solo quiere permitir el uso de un subconjunto de servicios en su entorno, puede usar una declaración Allow para permitir solo servicios específicos.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" } ] }

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.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" }, { "Effect": "Deny", "Action":"organizations:LeaveOrganization", "Resource": "*" } ] }

Ahora, analice el siguiente ejemplo de estructura organizativa para comprender cómo puede aplicar varias SCP en diferentes niveles de una organización.

En la tabla siguiente se muestran las políticas efectivas de la OU de un entorno aislado.

Escenario SCP en la raíz SCP en la OU de un entorno aislado SCP en la cuenta A Política resultante en la cuenta A Política resultante en la cuenta B y la cuenta C
1 Acceso completo de AWS Acceso completo de AWS + denegar el acceso a S3 Acceso completo de AWS + denegar el acceso a EC2 Sin acceso a S3 ni a EC2 Sin acceso a S3
2 Acceso completo de AWS Permitir acceso de Amazon Elastic Compute Cloud (Amazon EC2) Permitir el acceso a EC2 Solo permitir el acceso a EC2 Solo permitir el acceso a EC2
3 Denegar el acceso a S3 Permitir el acceso a S3 Acceso completo de AWS Sin acceso a los servicios Sin acceso a los servicios

En la tabla siguiente se muestran las políticas efectivas de la OU de cargas de trabajo.

Escenario SCP en la raíz SCP en OU de cargas de trabajo SCP en OU de pruebas Política resultante en la cuenta D Políticas resultantes en OU de producción, cuenta E y cuenta F
1 Acceso completo de AWS Acceso completo de AWS Acceso completo de AWS + denegar el acceso a EC2 Sin acceso a EC2 Acceso completo de AWS
2 Acceso completo de AWS Acceso completo de AWS Permitir el acceso a EC2 Permitir el acceso a EC2 Acceso completo de AWS
3 Denegar el acceso a S3 Acceso completo de AWS Permitir el acceso a S3 Sin acceso a los servicios Sin acceso a los servicios