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.
Lógica de evaluación
El objetivo en el momento de la evaluación es decidir si una determinada solicitud debe autorizarse o denegarse. La lógica de evaluación sigue varias reglas básicas:
-
De forma predeterminada, todas las solicitudes para utilizar su recurso procedentes de cualquier persona que no sea usted se deniegan
-
Una instrucción "permitir" anula todas las denegaciones predeterminadas.
-
Una denegación explícita invalida cualquier instrucción "permitir"
-
El orden en que se evalúan las políticas no es importante
El siguiente diagrama de flujo y el debate describen con más detalle cómo se toma la decisión.
![Diagrama de evaluación](images/AccessPolicyLanguage_Evaluation_Flow.gif)
1 |
La decisión comienza con una denegación predeterminada. |
2 |
El código de aplicación evalúa todas las políticas aplicables a la solicitud (en función del recurso, el principal, la acción y las condiciones). El orden en que el código de aplicación evalúa las políticas no es importante. |
3 |
En todas estas políticas, el código de aplicación buscará una instrucción de denegación explícita que se aplique a la solicitud. Aunque solo detecte una, el código de cumplimiento devolverá una decisión de "denegación" y el proceso finalizará (es una denegación explícita; para obtener más información, consulte Denegación explícita). |
4 |
Si no se encuentra ninguna denegación explicita, el código de cumplimiento buscará una instrucción "permitir" que se aplique a la solicitud. Si encuentra alguna, el código de aplicación devolverá una decisión de "permitir" y el proceso se llevará a cabo (el servicio seguirá procesando la solicitud). |
5 |
Si no se detecta ninguna instrucción de "permitir", la decisión final será "denegar" (dado que no había ninguna denegación explícita ni ninguna instrucción de "permitir", se trata de una denegación predeterminada). Para obtener más información, consulte Denegación predeterminada. |
Interacción entre denegaciones explícitas y predeterminadas
En una denegación predeterminada se deniega una política si esta no se aplica directamente a la solicitud. Por ejemplo, si un usuario solicita usar AmazonSNS, pero la política sobre el tema no se refiere en Cuenta de AWS absoluto a la del usuario, esa política se traduce en una denegación predeterminada.
También se deniega una política en una denegación predeterminada si no se cumple una condición de una instrucción. Si se cumplen todas las condiciones de la instrucción, la política dará como resultado una instrucción "permitir" o una denegación explícita, en función del valor del elemento Effect en la política. Las políticas no especifican qué es lo que se debe hacer si no se cumple una condición, por lo que el resultado predeterminado en ese caso es una denegación predeterminada.
Por ejemplo, supongamos que desea evitar las solicitudes que procedan de la Antártida. Puede escribir una política (denominada Policy A1) que permita una solicitud solo si no procede de la Antártida. El siguiente diagrama ilustra esta política.
![Política que permite una solicitud si no procede de la Antártida](images/AccessPolicyLanguage_Allow_Override_1.gif)
Si alguien envía una solicitud desde los Estados Unidos, dicha condición se cumple (la solicitud no procede de la Antártida). Por lo tanto, la solicitud se permite. Pero, si alguien envía una solicitud desde la Antártida, la condición no se cumple y, por lo tanto, la política genera una denegación predeterminada.
Puede convertir el resultado en una denegación explícita reescribiendo la política (denominada Policy A2) como se indica en el siguiente diagrama. Aquí la política deniega de forma explícita una solicitud si procede de la Antártida.
![Política que deniega una solicitud si procede de la Antártida](images/AccessPolicyLanguage_Allow_Override_2.gif)
Si alguien envía una solicitud desde la Antártida, la condición se cumple y, por lo tanto, el resultado de la política es una denegación explícita.
La diferencia entre una denegación predeterminada y una denegación explícita es importante, ya que una denegación predeterminada se puede anular mediante una instrucción "permitir", mientras que una denegación explícita, no. Por ejemplo, supongamos que hay otra política que permite las solicitudes que llegan el 1 de junio de 2010. ¿Cómo afecta esta política al resultado general cuando se asocia a la política que restringe el acceso desde la Antártida? Vamos a comparar el resultado general cuando se asocia la política basada en la fecha (denominada Policy B) a las políticas anteriores A1 y A2. En el escenario 1 se asocia Policy A1 a Policy B y, en el escenario 2, se asocia Policy A2 a Policy B. La figura y la discusión siguientes muestran el resultado que se obtiene cuando llega una solicitud procedente de la Antártida el 1 de junio de 2010.
![Anulación de una denegación predeterminada](images/AccessPolicyLanguage_Allow_Override.gif)
En el escenario 1, Policy A1 devuelve una denegación predeterminada, tal y como se ha descrito anteriormente en esta sección. Policy B devuelve "permitir", ya que la política (por definición) permite las solicitudes que entran el 1 de junio de 2010. El resultado "permitir" de la Policy B anula la denegación predeterminada de la Policy A1 y, por dicho motivo, la solicitud se permite.
En el escenario 2, la Policy A2 devuelve una denegación explícita, tal y como se ha descrito anteriormente en esta sección. De nuevo, la Policy B da como resultado "permitir". La denegación explícita de Policy A2 anula el resultado "permitir" de Policy B y, por dicho motivo, la solicitud se deniega.