Identité, ressource et limite

Utiliser la sécurité AWS pour les développeurs

Rahul Singh

Technical Product Manager

Quelle stratégie a priorité ?

La modification qui ne change rien

Chapitre un : refus explicite, ou absence d'autorisation
Ici : une troisième cause

Une requête rencontre une pile de trois vérifications de stratégies, avec un point d'interrogation à l'endroit de la décision.

Quelle stratégie a priorité ?

Jusqu'à trois couches

Stratégie d'identité sur l'appelant
Stratégie de ressource sur la ressource
Limite au-dessus, ne fait que retrancher

Dans votre compte, l'autorisation par l'une suffit

Refusée par toute couche rencontrée

Une requête descend de haut en bas à travers trois vérifications : une stratégie d'identité, une stratégie de ressource et une limite d'autorisations, avant d'aboutir à Autorisé.

Deux emplacements possibles pour une stratégie

Stratégie axée sur l'identité

Jointe à l'appelant
Ce que cette identité peut faire
Un laissez-passer que vous portez

Un rôle en haut porte une stratégie axée sur l'identité, avec un espace en dessous pour le côté ressource de la même requête.

Deux emplacements possibles pour une stratégie

Stratégie axée sur l'identité

Jointe à l'appelant
Ce que cette identité peut faire
Un laissez-passer que vous portez

Stratégie axée sur la ressource

Jointe à la ressource
Qui peut y accéder
Nécessaire pour les appels intercomptes

Un rôle en haut porte une stratégie axée sur l'identité, tandis qu'un compartiment S3 en bas porte une stratégie axée sur la ressource, et une requête circule entre les deux.

Gérée pour vous, ou par vous

Deux types de stratégies d'identité

Gérée par AWS : détenue par AWS
Gérée par le client : détenue par vous

Deux cartes empilées comparent une stratégie gérée par AWS, détenue par AWS et large par défaut, à une stratégie gérée par le client, détenue par vous et ciblée sur la tâche.

Gérée pour vous, ou par vous

Deux types de stratégies d'identité

Gérée par AWS : détenue par AWS
Gérée par le client : détenue par vous

Commodité ou précision

Gérée par AWS : aller vite
Gérée par le client : moindre privilège

Deux cartes empilées comparent une stratégie gérée par AWS, détenue par AWS et large par défaut, à une stratégie gérée par le client, détenue par vous et ciblée sur la tâche.

Une limite plafonne ce qu'accorde une stratégie

Pourquoi un compte en attache une

Les développeurs créent des rôles, personne n'escalade

Limite d'autorisations

Un plafond à ce qu'accorde une stratégie
Effectif : autorisé par les deux

Trois autorisations accordées par une stratégie d'identité passent dans une limite d'autorisations qui n'autorise que les actions S3 ; l'autorisation iam:CreateUser est arrêtée et les deux autres continuent vers les autorisations effectives en dessous.

Une limite plafonne ce qu'accorde une stratégie

Pourquoi un compte en attache une

Les développeurs créent des rôles, personne n'escalade

Limite d'autorisations

Un plafond à ce qu'accorde une stratégie
Effectif : autorisé par les deux

Pourquoi iam:CreateUser n'a rien changé

Ne retranche que, n'accorde jamais

Une limite plafonne ce qu'accorde une stratégie

Pourquoi un compte en attache une

Les développeurs créent des rôles, personne n'escalade

Limite d'autorisations

Un plafond à ce qu'accorde une stratégie
Effectif : autorisé par les deux

Pourquoi iam:CreateUser n'a rien changé

Ne retranche que, n'accorde jamais

Stratégie de session : une session AssumeRole

Une condition restreint l'autorisation

Clé de condition

Restreint une autorisation au contexte de la requête
aws:SourceIp : le réseau d'origine

Une autorisation de lecture d'un objet S3 passe par une bande de condition listant une clé de réseau source et une clé d'étiquette de l'appelant, puis se divise en un chemin autorisé quand le contexte correspond et un chemin refusé sinon.

Une condition restreint l'autorisation

Clé de condition

Restreint une autorisation au contexte de la requête
aws:SourceIp : le réseau d'origine
aws:PrincipalTag : une étiquette sur l'appelant

ABAC : attribute-based access control

Une stratégie, plusieurs principaux

Une table, un locataire à la fois

Une table partagée

DynamoDB : une clé de partition par locataire
Pas une isolation en soi

Un appelant du locataire A passe par une condition sur les clés de tête vers une table DynamoDB partagée, où les lignes du locataire A sont renvoyées et celles des locataires B et C sont bloquées.

Une table, un locataire à la fois

"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

Une table partagée

DynamoDB : une clé de partition par locataire
Pas une isolation en soi

Une condition la restreint

ForAllValues : chaque clé fournie doit correspondre

Une table, un locataire à la fois

"Action": ["dynamodb:Query", "dynamodb:GetItem", "dynamodb:Scan"],
"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

Une table partagée

DynamoDB : une clé de partition par locataire
Pas une isolation en soi

Une condition la restreint

ForAllValues : chaque clé fournie doit correspondre

La faille restante : toute requête ne nomme pas une partition

dynamodb:Scan n'en fournit aucune, donc rien ne peut échouer

Passons à la pratique !

Utiliser la sécurité AWS pour les développeurs