Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Logique d'évaluation
L'objectif au moment de l'évaluation consiste à déterminer si une demande donnée doit être autorisée ou refusée. La logique d'évaluation suit plusieurs règles de base :
-
Par défaut, toutes les demandes d'utilisation de votre ressource ne provenant pas de vous sont refusées.
-
Une autorisation prévaut sur les refus par défaut.
-
Un refus explicite remplace toute autorisation
-
L'ordre dans lequel les politiques sont évaluées n'est pas important.
Le graphique et la discussion ci-dessous décrivent plus en détail comment la décision est prise.
| 1 |
La décision commence par un refus par défaut. |
| 2 |
Le code d'application évalue ensuite toutes les politiques qui s'appliquent à la demande (en se basant sur la ressource, le principal, l'action et les conditions). L'ordre dans lequel le code d'application évalue les politiques n'a pas d'importance. |
| 3 |
Dans toutes ces politiques, le code d'application recherche une instruction de refus explicite susceptible de s'appliquer à la demande. S'il en détecte une, le code de l'application retourne une décision de « refus » et le processus se termine. Il s'agit d'un refus explicite. Pour plus d'informations, veuillez consulter la section . Refus explicite). |
| 4 |
En l'absence de refus explicite, le code d'application recherche des instructions d'« autorisation » pouvant s'appliquer à la demande. S'il en trouve une, il retourne une décision d'« autorisation » et le service continue à traiter la demande. |
| 5 |
Si aucune autorisation n'est détectée, la décision finale est un « refus ». En l'absence d'autorisation ou de refus explicite, nous parlons d'un refus par défaut (pour plus d'informations, consultez la page Refus par défaut). |
Interaction entre les refus explicites et les refus par défaut
Une politique génère un refus par défaut si celle-ci ne s'applique pas directement à la demande. Par exemple, si un utilisateur demande à utiliser AmazonSNS, mais que la politique en question ne fait pas du tout référence Compte AWS à celle de l'utilisateur, cette politique entraîne un refus par défaut.
Une politique génère également un refus par défaut si une condition de l'instruction n'est pas respectée. Si toutes les conditions de l'instruction sont respectées, la politique génère une autorisation ou un refus explicite, selon la valeur de l'élément Effect qu'elle indique. Les politiques ne spécifient pas comment procéder si une condition n'est pas respectée. Le résultat est donc un refus dans ce cas.
Par exemple, supposons que vous souhaitiez refuser les demandes provenant de l'Antarctique. Vous créez une politique appelée Policy A1 qui autorise une demande uniquement si elle ne provient pas de l'Antarctique. Le schéma suivant illustre la politique.
Si une personne envoie une demande depuis les États-Unis, la condition est respectée (la demande ne provient pas de l'Antarctique). Par conséquent, la demande est autorisée. En revanche, si un utilisateur effectue une demande depuis l'Antarctique, la condition n'est pas respectée et la politique génère un refus par défaut.
Vous pouvez convertir ce résultat par un refus explicite. Pour ce faire, réécrivez la politique (nommée Policy A2) comme dans le schéma suivant. Ici, la politique refuse explicitement une demande si elle vient de l'Antarctique.
Si un utilisateur effectue une demande depuis l'Antarctique, la condition est respectée et la politique génère alors un refus explicite.
La distinction entre un refus par défaut et un refus explicite est importante, car un refus par défaut peut être remplacé par une autorisation, ce qui n'est pas le cas d'un refus explicite. Par exemple, prenons le cas d'une autre politique qui autorise les demandes si elles sont reçues le 1er juin 2010. Comment cette politique modifie-t-elle le résultat global lorsqu'elle est associée à la politique qui restreint l'accès depuis l'Antarctique ? Nous allons comparer le résultat global en cas d'association de la politique basée sur la date (que nous appellerons Policy B) avec les politiques précédentes (A1 et A2). Le scénario 1 associe les politiques Policy A1 et Policy B, tandis que le scénario 2 combine les politiques Policy A2 et Policy B. L'illustration et la discussion suivantes montrent les résultats obtenus lorsqu'une demande provient de l'Antarctique le 1er juin 2010.
Dans le scénario 1, la politique Policy A1 génère un refus par défaut, comme décrit plus haut dans cette section. La politique Policy B renvoie une autorisation, car par définition, elle autorise les demandes le 1er juin 2010. L'autorisation de Policy B remplace le refus par défaut de Policy A1 et, par conséquent, la demande est autorisée.
Dans le scénario 2, la politique Policy A2 génère un refus explicite, comme décrit plus haut dans cette section. Ainsi, Policy B génère également une autorisation. Le refus explicite de Policy A2 remplace l'autorisation de Policy B et, par conséquent, la demande est refusée.
