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. # Políticas de control de servicios (SCPs) Las políticas de control de servicios (SCPs) son un tipo de política organizacional que puede usar para administrar los permisos en su organización. SCPs ofrecen un control central sobre los permisos máximos disponibles para los usuarios de IAM y las funciones de IAM en su organización. SCPs le ayudan a garantizar que sus cuentas se ajusten a las directrices de control de acceso de su organización. SCPsestán disponibles solo en una organización que tenga [todas las funciones habilitadas](orgs_manage_org_support-all-features.md). SCPs no están disponibles si su organización ha activado únicamente las funciones de facturación unificada. Para obtener instrucciones sobre cómo SCPs activarlas, consulte[Habilitar un tipo de política](enable-policy-type.md). SCPs no conceda permisos a los usuarios de IAM ni a las funciones de IAM de su organización. Una SCP no concede permisos. Una SCP define una barrera de protección de permisos o establece límites a las acciones que pueden llevar a cabo los usuarios de IAM y roles de IAM de la organización. Para conceder permisos, el administrador debe vincular políticas para controlar el acceso, como las políticas basadas en identidades que se vinculan a los usuarios de IAM y roles de IAM, y las políticas basadas en recursos que se vinculan a los recursos de las cuentas. Para obtener más información, consulte [Políticas basadas en identidad y políticas basadas en recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) en la *Guía del usuario de IAM*. Los [permisos efectivos](#scp-effects-on-permissions) son la intersección lógica entre lo que permiten las políticas de SCP y de [control de recursos (RCPs) y lo que permiten las políticas](orgs_manage_policies_rcps.md) basadas en la identidad y en los recursos. **SCPs no afectan a los usuarios ni a las funciones de la cuenta de administración** SCPs no afectan a los usuarios ni a las funciones de la cuenta de administración. Afectan solo a las cuentas de miembro de su organización. Esto también significa que SCPs se aplican a las cuentas de los miembros designadas como administradores delegados. ****Temas en esta página**** + [Probando los efectos de SCPs](#scp-warning-testing-effect) + [Tamaño máximo de SCPs](#scp-size-limit) + [Adscribirse SCPs a diferentes niveles de la organización](#scp-about-inheritance) + [Efectos de las SCP en los permisos](#scp-effects-on-permissions) + [Utilizar los datos de acceso para mejorar SCPs](#data-from-iam) + [Las tareas y entidades no están restringidas por SCPs](#not-restricted-by-scp) + [Evaluación de SCP](orgs_manage_policies_scps_evaluation.md) + [Sintaxis de SCP](orgs_manage_policies_scps_syntax.md) + [Ejemplos de políticas de control de servicios](orgs_manage_policies_scps_examples.md) + [Solución de problemas de políticas de control de servicios (SCPs) con AWS Organizations](org_troubleshoot_policies.md) ## Probando los efectos de SCPs AWS le recomienda encarecidamente que no se fije SCPs en la raíz de su organización sin comprobar exhaustivamente el impacto que la política tiene en las cuentas. En lugar de ello, cree una unidad organizativa en la que pueda mover sus cuentas de una en una, o al menos en incrementos pequeños, a fin de garantizar que no bloquee inadvertidamente a los usuarios de servicios clave. Una forma de determinar si una cuenta utilizará un servicio es examinar los [datos a los que tuvo acceso el servicio por última vez en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). Otra forma consiste en [registrar el AWS CloudTrail uso del servicio a nivel de la API](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html). **nota** No debes eliminar la AWSAccess política **completa** a menos que la modifiques o la sustituyas por una política independiente con acciones permitidas; de lo contrario, todas AWS las acciones de las cuentas de los miembros fallarán. ## Tamaño máximo de SCPs Todos los caracteres de la SCP se contabilizan para calcular su [tamaño máximo](orgs_reference_limits.md#min-max-values). Los ejemplos de esta guía muestran los objetos SCPs formateados con espacios en blanco adicionales para mejorar su legibilidad. Sin embargo, para ahorrar espacio si el tamaño de la política se aproxima al tamaño máximo, puede eliminar todos los espacios en blanco, como espacios y saltos de línea, que estén fuera de las comillas. **sugerencia** Utilice el editor visual para crear la SCP. Este elimina automáticamente el espacio en blanco adicional. ## Adscribirse SCPs a diferentes niveles de la organización Para obtener una explicación detallada de cómo SCPs funciona, consulte[Evaluación de SCP](orgs_manage_policies_scps_evaluation.md). ## Efectos de las SCP en los permisos SCPs son similares a las políticas de AWS Identity and Access Management permisos y utilizan prácticamente la misma sintaxis. Sin embargo, una SCP nunca concede permisos. En cambio, SCPs son controles de acceso que especifican los permisos máximos disponibles para los usuarios de IAM y las funciones de IAM en su organización. Para obtener más información, consulte [Lógica de evaluación de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) en la *Guía del usuario IAM*. + SCPs ***afectan únicamente a los usuarios y roles de IAM*** gestionados por las cuentas que forman parte de la organización. SCPs no afectan directamente a las políticas basadas en recursos. Tampoco afectan a los usuarios ni a los roles de cuentas que no pertenecen a la organización. Por ejemplo, tomemos el caso de un bucket de Amazon S3 que es propiedad de la cuenta A de una organización. La política de bucket (basada en recursos) concede acceso a los usuarios de la cuenta B que no pertenecen a la organización. La cuenta A tiene asociada una SCP. Esa SCP no se aplica a los usuarios externos de la cuenta B. La SCP solo se aplica a los usuarios que administra la cuenta A de la organización. + Una SCP limita los permisos para los usuarios y roles de IAM en las cuentas de miembro, incluido el usuario raíz de la cuenta de miembro. Cada cuenta tiene únicamente los permisos concedidos por ***cada*** elemento principal situado por encima de ella. Si se bloquea un permiso en cualquier nivel por encima de la cuenta, ya sea implícitamente (sin incluirlo en una instrucción de política "`Allow`") o explícitamente (incluyéndolo en una instrucción de política "`Deny`"), el usuario o función de la cuenta afectada no puede usar ese permiso, aunque el administrador de la cuenta asocie la política de IAM `AdministratorAccess` con los permisos \$1/\$1 al usuario. + SCPs afectan únicamente a las cuentas ***de los miembros*** de la organización. No tienen ningún efecto en los usuarios ni en los roles de la cuenta de administración. Esto también significa que SCPs se aplican a las cuentas de los miembros designadas como administradores delegados. Para obtener más información, consulte [Prácticas recomendadas para la cuenta de administración](orgs_best-practices_mgmt-acct.md). + A los usuarios y roles se les deben seguir concediendo permisos con las políticas de permisos de IAM adecuadas. Un usuario sin ninguna política de permisos de IAM no tiene acceso, incluso si la correspondiente SCPs permite todos los servicios y todas las acciones. + Si un usuario o rol tiene una política de permisos de IAM que otorga acceso a una acción que también está permitida por la autoridad correspondiente SCPs, el usuario o rol puede realizar esa acción. + Si un usuario o rol tiene una política de permisos de IAM que concede el acceso a una acción que no está permitida o denegada explícitamente por la entidad correspondiente SCPs, el usuario o rol no podrá realizar esa acción. + SCPs afectan a todos los usuarios y roles de las cuentas asociadas, ***incluido el usuario raíz***. Las únicas excepciones son las descritas en [Las tareas y entidades no están restringidas por SCPs](#not-restricted-by-scp). + SCPs ***no*** afectan a ningún rol vinculado a un servicio. Los roles vinculados al servicio permiten que otros se Servicios de AWS integren AWS Organizations y no se pueden restringir mediante ellos. SCPs + Al deshabilitar el tipo de política SCP en una raíz, todas SCPs se separan automáticamente de todas AWS Organizations las entidades de esa raíz. AWS Organizations las entidades incluyen unidades organizativas, organizaciones y cuentas. Si se vuelve a habilitar SCPs en una raíz, esa raíz solo volverá a ser la `FullAWSAccess` política predeterminada que se adjunta automáticamente a todas las entidades de la raíz. Todos los archivos adjuntos SCPs a AWS Organizations entidades que antes SCPs estaban deshabilitados se pierden y no se pueden recuperar automáticamente, aunque puede volver a adjuntarlos manualmente. + Si existen tanto un límite de permisos (característica avanzada de IAM) como una SCP, entonces ese límite, la SCP y la política basada en identidad deberán permitir la acción. ## Utilizar los datos de acceso para mejorar SCPs Al iniciar sesión con las credenciales de la cuenta de administración, puede ver los [datos de una AWS Organizations entidad o política a los que se accedió por última vez](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) en la **AWS Organizations**sección de la consola de IAM. También puedes usar AWS Command Line Interface (AWS CLI) o la AWS API de IAM para recuperar los datos del servicio a los que se accedió por última vez. Estos datos incluyen información sobre los servicios permitidos a los que los usuarios y roles de IAM de una AWS Organizations cuenta intentaron acceder por última vez y cuándo. Puede utilizar esta información para identificar los permisos no utilizados, de forma que pueda ajustarlos mejor SCPs a fin de cumplir mejor con el principio de [privilegios mínimos](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). Por ejemplo, es posible que tenga una [SCP de lista de denegación](orgs_manage_policies_scps_evaluation.md#how_scps_deny) que prohíba el acceso a tres Servicios de AWS. Todos los servicios que no figuren en la instrucción `Deny` de la SCP se permiten. Los datos del servicio al que se accedió por última vez en IAM indican cuáles Servicios de AWS están permitidos por el SCP pero que nunca se utilizan. Con esa información, puede actualizar la SCP para denegar el acceso a los servicios que no necesite. Para obtener más información, consulte los siguientes temas de la *guía del usuario de IAM*: + [Visualización de los datos del último acceso al servicio de Organizations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html) + [Uso de datos para ajustar los permisos de una unidad organizativa](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-example-scenarios.html#access_policies_access-advisor-reduce-permissions-orgs) ## Las tareas y entidades no están restringidas por SCPs ***No se pueden*** utilizar SCPs para restringir las siguientes tareas: + Cualquier acción realizada por la cuenta de administración + Cualquier acción realizada mediante permisos que adjuntos a un rol vinculado al servicio + Registrarse en el plan Enterprise Support como usuario raíz + Proporcione una funcionalidad de firmante confiable para el contenido CloudFront privado + Configurar DNS inverso para un servidor de correo electrónico de Amazon Lightsail y una instancia de Amazon EC2 como usuario raíz + Tareas en algunos servicios AWS relacionados: + Alexa Top Sites + Alexa Web Information Service + Amazon Mechanical Turk + API de marketing de productos de Amazon # 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](orgs_manage_policies_inheritance_mgmt.md). 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. **Topics** + [¿Cómo SCPs trabajar con Allow](#how_scps_allow) + [¿Cómo SCPs trabajar con Deny](#how_scps_deny) + [Estrategia de uso SCPs](#strategy_using_scps) ## ¿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](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-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 OUs las cuentas que estén por debajo de ese nivel quedarán bloqueadas para que no puedan realizar ninguna acción. 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. ![\[Ejemplo de estructura organizativa con una instrucción Allow asociada en la raíz, la unidad organizativa de producción y la cuenta B\]](http://docs.aws.amazon.com/es_es/organizations/latest/userguide/images/scp_allow_1.png) *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* ![\[Ejemplo de estructura organizativa con una instrucción Allow faltante en la unidad organizativa de producción y su impacto en la cuenta B\]](http://docs.aws.amazon.com/es_es/organizations/latest/userguide/images/scp_allow_2.png) *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. ![\[Ejemplo de estructura organizativa con una instrucción Deny asociada en la unidad organizativa de producción y su impacto en la cuenta B\]](http://docs.aws.amazon.com/es_es/organizations/latest/userguide/images/scp_deny_1.png) *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. `Deny`Las 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. **sugerencia** Puede utilizar los [datos del servicio al que accedió por última vez](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) en [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html) en la *Guía del usuario IAM.* AWS Organizations Cuando se crea, adjunta un SCP AWS gestionado denominado [https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess) a cada raíz, unidad organizativa y cuenta. Esta política permite todos los servicios y acciones. Puede sustituir el **Full AWSAccess** por una política que permita solo un conjunto de servicios, de modo que no Servicios de AWS se permitan los nuevos, a menos que se autoricen explícitamente mediante una actualización. SCPs 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. 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. ------ #### [ JSON ] **** ``` { "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 separar la AWSAccess política **completa** y adjuntar esta en su lugar. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" }, { "Effect": "Deny", "Action":"organizations:LeaveOrganization", "Resource": "*" } ] } ``` ------ 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 «denegar el acceso a EC2», el resultado es que la cuenta B no puede acceder a S3 (denegación a nivel de OU) ni a EC2 (denegación a nivel de cuenta). La cuenta A no tiene acceso a S3 (denegado desde el nivel de UO). ![\[Situación 1: Impacto de las políticas Deny\]](http://docs.aws.amazon.com/es_es/organizations/latest/userguide/images/scp_scenario_1.png) ### 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 2: Las políticas de autorización deben existir en todos los niveles\]](http://docs.aws.amazon.com/es_es/organizations/latest/userguide/images/scp_scenario_2.png) ### Situación 3: Impacto de no incluir una instrucción 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 el acceso a los AWS servicios y acciones de todas las cuentas de los miembros de su organización. ![\[Situación 3: Impacto de no incluir una instrucción Allow en el nivel raíz\]](http://docs.aws.amazon.com/es_es/organizations/latest/userguide/images/scp_scenario_3.png) ### 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 la opción «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. ![\[Situación 4: Instrucciones Deny por capas y los permisos resultantes\]](http://docs.aws.amazon.com/es_es/organizations/latest/userguide/images/scp_scenario_4.png) ### 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 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 a nivel de la unidad organizativa y, al mismo tiempo, mantener una autorización más amplia a nivel raíz. ![\[Situación 5: Permitir que las políticas a nivel de la unidad organizativa restrinjan el acceso al servicio\]](http://docs.aws.amazon.com/es_es/organizations/latest/userguide/images/scp_scenario_5.png) ### 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 tanto de « AWS acceso total» como de «denegación del 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. ![\[Situación 6: la denegación a nivel raíz afecta a todas las cuentas, independiente de los permisos de nivel inferior\]](http://docs.aws.amazon.com/es_es/organizations/latest/userguide/images/scp_scenario_6.png) ### 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\$11 permite IAM y Amazon EC2, y SCP\$12 permite 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 de estas OU solo 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, EC2, S3 y los CloudWatch servicios, independientemente de los permisos más amplios que se concedan en los niveles organizativos inferiores. ![\[Escenario 7: políticas de permisos personalizadas a nivel raíz para restringir el acceso a nivel de OU\]](http://docs.aws.amazon.com/es_es/organizations/latest/userguide/images/scp_scenario_7.png) # Sintaxis de SCP Las políticas de control de servicios (SCPs) utilizan una sintaxis similar a la que utilizan las políticas de permisos AWS Identity and Access Management (IAM) y las políticas [basadas en recursos (como las políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based) de bucket de Amazon S3). Para obtener más información sobre las políticas del IAM y su sintaxis, consulte [Información general de las políticas deI AM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) en la *Guía del usuario IAM*. Una política SCP es un archivo de texto sin formato estructurado de acuerdo con las reglas [JSON](http://json.org). Utiliza los elementos que se describen en este tema. **nota** Todos los caracteres de la SCP se contabilizan para calcular su [tamaño máximo](orgs_reference_limits.md#min-max-values). Los ejemplos de esta guía muestran las imágenes SCPs formateadas con espacios en blanco adicionales para mejorar su legibilidad. Sin embargo, para ahorrar espacio si el tamaño de la política se aproxima al tamaño máximo, puede eliminar todos los espacios en blanco, como espacios y saltos de línea, que estén fuera de las comillas. Para obtener información general sobre SCPs, consulte. [Políticas de control de servicios (SCPs)](orgs_manage_policies_scps.md) ## Resumen de elementos En la siguiente tabla se resumen los elementos de política que puede utilizar. SCPs Algunos elementos de política solo están disponibles para denegar acciones. SCPs En la columna **Efectos admitidos** se muestra el tipo de efecto que se puede utilizar con cada elemento de política SCPs. | Element | Finalidad | Efectos admitidos | | --- | --- | --- | | [Action](#scp-syntax-action) | Especifica el AWS servicio y las acciones que el SCP permite o deniega. | `Allow`, `Deny` | | [Effect](#scp-syntax-effect) | Define si la instrucción SCP [permite](orgs_manage_policies_scps_evaluation.md#how_scps_allow) o [deniega](orgs_manage_policies_scps_evaluation.md#how_scps_deny) el acceso a los usuarios y roles IAM en una cuenta. | `Allow`, `Deny` | | [Instrucción](#scp-syntax-statement) | Sirve como contenedor de elementos de política. Puede incluir varias declaraciones. SCPs | `Allow`, `Deny` | | [Statement ID (Sid) (ID de instrucción)](#scp-syntax-sid) | (Opcional) Proporciona un nombre fácil de recordar para la instrucción. | `Allow`, `Deny` | | [Versión](#scp-syntax-version) | Especifica las reglas de sintaxis del lenguaje que se utilizarán para procesar la política. | `Allow`, `Deny` | | [Condición](#scp-syntax-condition) | Especifica las condiciones que determinan cuándo se aplica la instrucción. | `Allow,``Deny` | | [NotAction](#scp-syntax-action) | Especifica los AWS servicios y las acciones que están exentos del SCP. Se utiliza en lugar del elemento `Action`. | `Allow,``Deny` | | [Resource](#scp-syntax-resource) | Especifica los AWS recursos a los que se aplica el SCP. | `Allow,``Deny` | | [NotResource](#scp-syntax-resource) | Especifica AWS los recursos que están exentos del SCP. Se utiliza en lugar del elemento Resource. | `Allow`, `Deny` | En las siguientes secciones se proporciona más información y ejemplos de cómo se utilizan los elementos de política. SCPs **Topics** + [Resumen de elementos](#scp-elements-table) + [Elementos `Action` y `NotAction`](#scp-syntax-action) + [Elemento `Condition`](#scp-syntax-condition) + [Elemento `Effect`](#scp-syntax-effect) + [`Resource`y `NotResource` elemento](#scp-syntax-resource) + [Elemento `Statement`](#scp-syntax-statement) + [Elemento de ID de instrucción (`Sid`)](#scp-syntax-sid) + [Elemento `Version`](#scp-syntax-version) + [Elementos no compatibles](#scp-syntax-unsupported) ## Elementos `Action` y `NotAction` El valor del `NotAction` elemento `Action` o es una lista (una matriz JSON) de cadenas que identifican AWS los servicios y las acciones que la sentencia permite o deniega. Cada cadena consta de la abreviatura del servicio (como "s3", "ec2", "iam" u "organizaciones"), en letras minúsculas, seguida de un carácter de punto y coma y una acción de ese servicio. Las acciones y las acciones excluidas no distinguen entre mayúsculas y minúsculas. Por lo general, todas deben especificarse con cada palabra con la inicial en mayúsculas y el resto en minúsculas. Por ejemplo: `"s3:ListAllMyBuckets"`. También puede utilizar caracteres comodín tales como el asterisco (\$1) o el signo de interrogación de cierre (?) en una SCP: + Utilice un asterisco (\$1) como carácter comodín como representación de varias acciones que comparten parte de un nombre. El valor `"s3:*"` significa todas las acciones del servicio Amazon S3. El valor `"ec2:Describe*"` coincide solo con las acciones de EC2 que empiezan por "Describe". + Utilice el carácter comodín del signo de interrogación de cierre (?) como representación de un carácter único. Para obtener una lista de todos los servicios y las acciones que admiten tanto en las políticas de permisos de IAM como AWS Organizations SCPs en las políticas de permisos de IAM, consulte [las acciones, los recursos y las claves de condición de AWS los servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actionsconditions.html) en la Guía del *usuario de IAM*. *Para obtener más información, consulte Elementos de la [política JSON de IAM: acción y Elementos](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_action.html) de la [política JSON de IAM: NotAction en la Guía](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notaction.html) del usuario de IAM.* ### Ejemplo de elemento `Action` El siguiente ejemplo muestra una política SCP con una instrucción que permite a los administradores de la cuenta delegar los permisos describe, start, stop y terminate para las instancias EC2 de la cuenta. Este es un ejemplo de una [lista de permitidos](orgs_manage_policies_scps_evaluation.md#how_scps_allow), y es útil cuando las políticas `Allow *` predeterminadas ***no*** se asocian para que, de forma predeterminada, los permisos sean denegados implícitamente. Si la política `Allow *` predeterminada sigue estando asociada al nodo raíz, unidad organizativa o cuenta a la que la siguiente política está asociada, entonces la política no tiene ningún efecto. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeKeyPairs", "ec2:DescribeSecurityGroups", "ec2:DescribeAvailabilityZones", "ec2:RunInstances", "ec2:TerminateInstances", "ec2:StopInstances", "ec2:StartInstances" ], "Resource": "*" } } ``` ------ El siguiente ejemplo muestra cómo puede [denegar el acceso](orgs_manage_policies_scps_evaluation.md#how_scps_deny) a servicios que no desea usar en cuentas asociadas. Se asume que las políticas SCP `"Allow *"` predeterminadas siguen estando asociadas a las unidades organizativas y al nodo raíz. Esta política de ejemplo impide que los administradores de las cuentas asociadas deleguen permisos para los servicios de IAM, Amazon EC2 y Amazon RDS. Cualquier acción desde otros servicios se puede delegar siempre y cuando no exista otra política asociada que la deniegue. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": [ "iam:*", "ec2:*", "rds:*" ], "Resource": "*" } } ``` ------ ### Ejemplo de elemento `NotAction` El siguiente ejemplo muestra cómo se puede utilizar un `NotAction` elemento para excluir los AWS servicios del efecto de la política. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "LimitActionsInRegion", "Effect": "Deny", "NotAction": "iam:*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": "us-west-1" } } } ] } ``` ------ Con esta declaración, las cuentas afectadas se limitan a realizar las acciones especificadas Región de AWS, excepto cuando utilizan acciones de IAM. ## Elemento `Condition` Puede especificar un elemento `Condition` en las instrucciones de Allow y Deny de una SCP. El siguiente ejemplo muestra cómo utilizar un elemento de condición con una sentencia allow en un SCP para permitir que determinados directores accedan a los servicios. AWS ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowServicesForSpecificPrincipal", "Effect":"Allow", "Action":[ "ec2:*", "s3:*", "rds:*", "lambda:*", "cloudformation:*", "iam:*", "cloudwatch:*" ], "Resource":"*", "Condition":{ "StringEquals":{ "aws:PrincipalArn":[ "arn:aws:iam::123456789012:role/specific-role" ] } } } ] } ``` El siguiente ejemplo muestra cómo utilizar un elemento de condición con una instrucción Deny para restringir el acceso a cualquier operación fuera de las regiones `eu-central-1` y `eu-west-1`, excepto a las acciones en los servicios especificados. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAllOutsideEU", "Effect": "Deny", "NotAction": [ "cloudfront:*", "iam:*", "route53:*", "support:*" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "eu-central-1", "eu-west-1" ] } } } ] } ``` ------ Para obtener más información, consulte [Elementos de la política de JSON de IAM: Condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) en la *Guía del usuario de IAM*. ## Elemento `Effect` Cada instrucción debe contener un elemento `Effect`. El valor puede ser `Allow` o `Deny`. Afecta a las acciones enumeradas en la misma instrucción. Para obtener más información, consulte [Elemento de la política de JSON de IAM: Efecto](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_effect.html) en la *Guía del usuario IAM*. ### `"Effect": "Allow"` En el siguiente ejemplo se muestra una SCP con una instrucción que contiene un elemento `Effect` con un valor de `Allow` que permite a los usuarios de la cuenta realizar acciones para el servicio Amazon S3. Este ejemplo es útil en una organización que usa la [estrategia de permitidos](orgs_manage_policies_scps_evaluation.md#how_scps_allow) (donde las políticas `FullAWSAccess` predeterminadas estén desasociadas y, por tanto, los permisos se deniegan implícitamente de forma predeterminada). El resultado es que la instrucción [permite](orgs_manage_policies_scps_evaluation.md#how_scps_allow) los permisos de Amazon S3 en cualquier cuenta asociada: ``` { "Statement": { "Effect": "Allow", "Action": "s3:*", "Resource": "*" } } ``` Tenga en cuenta que aunque esta instrucción utiliza la misma palabra clave con el valor `Allow` que en una política de permisos de IAM, las SCP no conceden en realidad permisos de usuario. En su lugar, SCPs actúan como filtros que especifican los permisos máximos para las cuentas de una organización, unidad organizativa (OU) o cuenta. En el ejemplo anterior, aunque un usuario de la cuenta tuviera la política `AdministratorAccess` administrada asociada, esta SCP limita las acciones de ***todos*** los usuarios de la cuenta afectada a solo las acciones de Amazon S3. ### `"Effect": "Deny"` En una declaración en la que el `Effect` elemento tenga un valor de`Deny`, también puedes restringir el acceso a recursos específicos o definir las condiciones para cuando SCPs estén en vigor. A continuación, se muestra un ejemplo de cómo utilizar una clave de condición en una instrucción de denegación. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringNotEquals": { "ec2:InstanceType": "t2.micro" } } } } ``` ------ Esta instrucción de una SCP establece una medida de seguridad para evitar que las cuentas afectadas (cuando la SCP se adjunte a la propia cuenta o al nodo raíz de la organización o unidad organizativa que contiene la cuenta) lancen instancias Amazon EC2 si estas instancias Amazon EC2 no están establecidas en `t2.micro`. Aunque se adjunte a la cuenta una política de IAM que permita esta acción, la medida de seguridad creada por la SCP la impedirá. ## `Resource`y `NotResource` elemento En las instrucciones cuyo elemento `Effect` tiene el valor `Allow`, puede especificar solamente "\$1" en el elemento `Resource` de una SCP. No puede especificar los nombres de recursos de Amazon (ARNs) de recursos individuales. Puede utilizar caracteres comodín tales como el asterisco (\$1) o el signo de interrogación de cierre (?) en el elemento de recurso: + Utilice un asterisco (\$1) como carácter comodín como representación de varias acciones que comparten parte de un nombre. + Utilice el carácter comodín del signo de interrogación de cierre (?) como representación de un carácter único. En las declaraciones en las que el `Effect` elemento tiene un valor de`Deny`, *puede* especificar un individuo ARNs, como se muestra en el siguiente ejemplo. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAccessToAdminRole", "Effect": "Deny", "Action": [ "iam:AttachRolePolicy", "iam:DeleteRole", "iam:DeleteRolePermissionsBoundary", "iam:DeleteRolePolicy", "iam:DetachRolePolicy", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy", "iam:UpdateAssumeRolePolicy", "iam:UpdateRole", "iam:UpdateRoleDescription" ], "Resource": [ "arn:aws:iam::*:role/role-to-deny" ] } ] } ``` ------ Esta SCP restringe a las cuentas de usuarios y roles IAM para que no puedan realizar cambios en un rol de IAM administrativo común creado en todas las cuentas de la organización. En el siguiente ejemplo se muestra cómo puede utilizar un elemento `NotResource` para excluir Amazon Bedrock del efecto de la política. ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"Statement1", "Effect":"Deny", "Action":[ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "NotResource":[ "arn:aws:bedrock:*::foundation-model/model-to-permit" ] } ] } ``` Para obtener más información, consulte [Elemento de la política de JSON de IAM: Resource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html) en la *Guía del usuario de IAM*. ## Elemento `Statement` Una política SCP consta de uno o varios elementos `Statement`. Solo puede tener una palabra clave `Statement` en una política, pero el valor puede ser una matriz de instrucciones JSON (rodeadas por caracteres [ ]). El siguiente ejemplo muestra una única instrucción que consta de los elementos `Effect`, `Action` y `Resource`. ``` "Statement": { "Effect": "Allow", "Action": "*", "Resource": "*" } ``` El siguiente ejemplo incluye dos instrucciones como una lista de matriz dentro de un elemento `Statement`. La primera instrucción permite todas las acciones, mientras que la segunda deniega todas las acciones de EC2. El resultado es que el administrador de la cuenta puede delegar cualquier permiso, *excepto* los de Amazon Elastic Compute Cloud (Amazon EC2): ``` "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "ec2:*", "Resource": "*" } ] ``` Para obtener más información, consulte [Elementos de la política de JSON de IAM: Instrucción](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_statement.html) en la *Guía del usuario de IAM*. ## Elemento de ID de instrucción (`Sid`) El elemento `Sid` es un identificador opcional que se proporciona para la instrucción de la política. Puede asignar un valor de `Sid` a cada instrucción de una matriz de instrucciones. En el siguiente ejemplo de SCP se incluye una instrucción `Sid` de muestra. ``` { "Statement": { "Sid": "AllowsAllActions", "Effect": "Allow", "Action": "*", "Resource": "*" } } ``` Para obtener más información, consulte [Elementos de la política de JSON de IAM: ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_id.html) en la *Guía del usuario de IAM*. ## Elemento `Version` Todas las SCP deben incluir un elemento `Version` con el valor `"2012-10-17"`. Este es el mismo valor de versión que la versión más reciente de las políticas de permisos de IAM. Para obtener más información, consulte [Elementos de la política de JSON de IAM: Versión](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_version.html) en la *Guía del usuario de IAM*. ## Elementos no compatibles Los siguientes elementos no se admiten en SCPs: + `NotPrincipal` + `Principal` # Ejemplos de políticas de control de servicios Los ejemplos [de políticas de control de servicios (SCPs)](orgs_manage_policies_scps.md) que se muestran en este tema tienen únicamente fines informativos. **Antes de usar estos ejemplos** Antes de utilizar estos ejemplos SCPs en su organización, tenga en cuenta lo siguiente: Las [políticas de control de servicios (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) están pensadas para usarse como barreras de protección generales y no otorgan acceso directo. El administrador debe seguir adjuntando [políticas basadas en la identidad o en los recursos a las entidades principales o los recursos de IAM de sus cuentas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) para poder conceder realmente los permisos. Los permisos efectivos son la intersección lógica entre la política de policy/Resource control del servicio y una política de identidad o la política de policy/Resource control del servicio y una política de recursos. Puede obtener más información sobre los efectos del SCP en los permisos [aquí](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions). Una [política de control de servicios (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), cuando se adjunta a una organización, unidad organizativa o cuenta, ofrece un control centralizado sobre los permisos máximos disponibles para todas las cuentas de su organización, unidad organizativa o cuenta. Como un SCP se puede aplicar en varios niveles de una organización, comprender cómo [SCPs se evalúan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html) puede ayudarle a redactar SCPs los resultados correctos. Las políticas de control de servicios de este repositorio se muestran como ejemplos. No debes adjuntar documentos SCPs sin comprobar exhaustivamente el impacto que la política tiene en las cuentas. Una vez que tenga lista la política que desee implementar, le recomendamos que la pruebe en una organización o unidad organizativa independiente que pueda representar su entorno de producción. Una vez probadas, debe implementar los cambios para que sean más específicos OUs y, posteriormente, implementarlos poco a poco para ampliarlos cada vez más a OUs lo largo del tiempo. Los ejemplos de SCP de este repositorio utilizan una [estrategia de lista de rechazados](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html#strategy_using_scps), lo que significa que también necesitas una AWSAccess política [completa](https://console.aws.amazon.com/organizations/?#/policies/p-FullAWSAccess) u otra política que permita el acceso a las entidades de tu organización para permitir la adopción de medidas. También debes conceder los permisos adecuados a tus directores mediante políticas basadas en la identidad o en los recursos. **sugerencia** Puedes usar los [datos del servicio al que accediste por última vez](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) en [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) para actualizarlos y restringir el acceso SCPs únicamente a los que necesites. Servicios de AWS Para obtener más información, consulte [Visualización de los datos del último acceso al servicio de Organizations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html) en la *Guía del usuario IAM.* ## GitHub repositorio + [Ejemplos de políticas de control de servicios](https://github.com/aws-samples/service-control-policy-examples): este GitHub repositorio contiene ejemplos de políticas para comenzar o perfeccionar el uso de AWS SCPs # Solución de problemas de políticas de control de servicios (SCPs) con AWS Organizations Utilice la información que aparece aquí para ayudarle a diagnosticar y corregir los errores comunes que se encuentran en las políticas de control de servicios (SCPs). Las políticas de control de servicios (SCPs) AWS Organizations son similares a las políticas de IAM y comparten una sintaxis común. Esta sintaxis comienza con las reglas de la [notación de JavaScript objetos](http://www.json.org) (JSON). JSON describe un *objeto* con pares de nombre y valor que componen el objeto. La [gramática de las políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies-grammar.html) se basa en la definición de nombres y valores que tengan significado y puedan ser entendidos por los Servicios de AWS que usan políticas para conceder permisos. AWS Organizations utiliza un subconjunto de la sintaxis y la gramática de IAM. Para obtener más información, consulte [Sintaxis de SCP](orgs_manage_policies_scps_syntax.md). **Topics** + [Más de un objeto de política](#morethanonepolicyblock) + [Más de un elemento Statement](#morethanonestatement) + [El documento de política supera el tamaño máximo](#scptoolong) ## Más de un objeto de política Una SCP debe constar de uno y un solo objeto JSON. Los objetos se indican incluyéndolos en llaves \$1 \$1. Aunque puede anidar otros objetos dentro de un objeto JSON añadiendo llaves (\$1\$1) adicionales en el par exterior, una política solo puede contener un par exterior de llaves \$1 \$1. El ejemplo siguiente es ***incorrecto*** porque contiene dos objetos en el nivel superior (denominados «in*red*»): ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` ------ Sin embargo, podría satisfacer la intención del ejemplo anterior con el uso de la gramática de políticas correcta. En lugar de incluir dos objetos de política completos, cada uno con su propio elemento `Statement`, puede combinar los dos bloques en un único elemento `Statement`. El elemento `Statement` tiene una matriz de dos objetos como su valor, tal y como se muestra en el ejemplo siguiente: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` Este ejemplo no se puede comprimir en una instrucción `Statement` con un solo elemento, porque los dos elementos tienen efectos diferentes. Por lo general, solo puede combinar instrucciones cuando los elementos `Effect` y `Resource` de cada instrucción sean idénticos. ## Más de un elemento Statement Este error podría parecer a simple vista una variante del error de la sección anterior. Sin embargo, es un tipo de error diferente desde el punto de vista sintáctico. En el siguiente ejemplo, solo hay un objeto de política indicado por un único par de llaves \$1 \$1 en el nivel superior. Sin embargo, ese objeto contiene dos elementos `Statement` en su interior. Una SCP debe contener solo un elemento `Statement`, que consta del nombre (`Statement`) que aparece a la izquierda de un carácter de punto y coma, seguido de su valor a la derecha. El valor de un elemento `Statement` debe ser un objeto, identificado por llaves \$1 \$1, que contiene un elemento `Effect`, un elemento `Action` y un elemento `Resource`. El siguiente ejemplo es ***incorrecto*** porque contiene dos elementos `Statement` en el objeto de política: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` ------ Como un objeto de valor puede ser una matriz de varios objetos de valor, puede resolver este problema combinando los dos elementos `Statement` en un elemento con una matriz de objetos, tal y como se muestra en el ejemplo siguiente: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource":"*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` ------ El valor del elemento `Statement` es una matriz de objetos. La matriz del ejemplo se compone de dos objetos, cada uno de los cuales es un valor correcto para un elemento `Statement`. Cada objeto de la matriz está separado por comas. ## El documento de política supera el tamaño máximo El tamaño máximo de un documento de SCP es 5120 bytes. Este tamaño máximo incluye todos los caracteres, incluido el espacio en blanco. Para reducir el tamaño de su SCP, puede eliminar todos los caracteres de espacio en blanco (como espacios y saltos de línea) que estén fuera de las comillas. **nota** Si guarda la política utilizando el Consola de administración de AWS, los espacios en blanco adicionales entre los elementos JSON y fuera de las comillas se eliminan y no se cuentan. Si guardas la política mediante una operación del SDK o la AWS CLI, la política se guardará exactamente como la proporcionaste y no se eliminarán automáticamente los caracteres.