Identité, ressource et frontière

Sécurité AWS pour les développeurs

Rahul Singh

Technical Product Manager

Quelle stratégie fait foi ?

La modification qui ne change rien

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

Une requête face à une pile de trois contrôles de stratégie, avec un point d'interrogation à la place de la décision.

Quelle stratégie fait foi ?

Jusqu'à trois couches

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

Dans votre compte, l'une ou l'autre suffit à autoriser

Refusée par toute couche rencontrée

Une requête s'écoule de haut en bas via trois contrôles dans l'ordre : stratégie d'identité, stratégie de ressource, puis frontière d'autorisations, avant d'aboutir à Autorisé.

Deux emplacements possibles pour une stratégie

Stratégie basée sur l'identité

Attachée à l'appelant
Ce que cette identité peut faire
Un badge que vous portez

Un rôle en haut porte une stratégie basé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 basée sur l'identité

Attachée à l'appelant
Ce que cette identité peut faire
Un badge que vous portez

Stratégie basée sur la ressource

Attachée à la ressource
Qui peut y accéder
Nécessaire pour les appels inter-comptes

Un rôle en haut porte une stratégie basée sur l'identité tandis qu'un compartiment S3 en bas porte une stratégie basé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 restreinte à 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 restreinte à la tâche.

Une frontière plafonne ce qu'accorde une stratégie

Pourquoi un compte en attache une

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

Frontière d'autorisations

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

Trois autorisations accordées par une stratégie d'identité passent dans une frontière d'autorisations qui n'autorise que les actions S3 ; l'autorisation iam:CreateUser est bloquée et les deux autres continuent vers les autorisations effectives.

Une frontière plafonne ce qu'accorde une stratégie

Pourquoi un compte en attache une

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

Frontière d'autorisations

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

Pourquoi iam:CreateUser n'a rien changé

Ne fait que retrancher, n'accorde jamais

Une frontière plafonne ce qu'accorde une stratégie

Pourquoi un compte en attache une

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

Frontière d'autorisations

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

Pourquoi iam:CreateUser n'a rien changé

Ne fait que retrancher, 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 traverse une bande de condition listant une clé de réseau source et une clé d'étiquette de l'appelant, puis se sépare entre un chemin Autorisé (contexte correspondant) et un chemin Refusé (contexte non correspondant).

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 : contrôle d'accès basé sur les attributs

Une stratégie, de nombreux principaux

Une table, un locataire à la fois

Une table partagée

DynamoDB, une clé de partition par locataire
Pas une isolation à elle seule

Un appelant du locataire A passe par une condition sur les clés de tête vers une table DynamoDB partagée ; les lignes du locataire A sont renvoyées, 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 à elle seule

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 à elle seule

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 ; rien ne peut échouer

Passons à la pratique !

Sécurité AWS pour les développeurs