AWS IAM EFFICACE

Connaître vos utilisateurs, ne les ralentissez pas

Ian McKay, ingénieur DevOps chez Kablamo, nous éclaire sur l'utilisation efficace d'AWS IAM :

Lors de la création d'un environnement sécurisé sur AWS, IAM est un élément essentiel de la sécurité offerte par la solution. Il permet de contrôler la manière dont les utilisateurs accèdent aux ressources de calcul et dont les autres services interagissent. Cependant, il peut aussi constituer une faille critique si vos politiques ne sont pas correctement configurées.

Pour les utilisateurs (et parfois les administrateurs), la sécurité est complexe. Elle peut ralentir l'authentification et bloquer l'accès aux ressources nécessaires. De nombreux clients ont rencontré ce problème, créant ainsi des failles de sécurité importantes pour les utilisateurs. Il peut s'agir d'une règle de pare-feu trop restrictive, d'identifiants partagés ou de privilèges excessifs. Il est crucial d'évaluer les risques encourus lorsqu'une entreprise crée de tels raccourcis, car de plus en plus d'entreprises subissent des failles de sécurité majeures qui nuisent gravement à leur réputation.

ÉVALUATION DES POLITIQUES IAM

Pour les développeurs qui découvrent IAM, la logique peut paraître complexe au premier abord, d'autant plus que la documentation Amazon est très fournie.

Voici comment j'explique l'application des règles des politiques IAM :

1. Si une autorisation n'est pas mentionnée, elle n'est pas accordée.

2. Si une autorisation est accordée, l'action est autorisée SAUF si une autre politique la refuse explicitement.

L'ordre d'application des règles n'a pas d'importance.

OUVERTURE DES RÔLES IAM

Prenons l'exemple du rôle fourni par Amazon : ReadOnlyAccess.

Ce rôle confère à un utilisateur un accès en lecture seule à toutes les ressources d'un compte AWS. Ce privilège est généralement accordé pour permettre aux utilisateurs de consulter ces ressources. Bien qu'il ne puisse effectuer aucune modification directe, l'étendue de ce rôle peut révéler involontairement des informations (sauf interdiction explicite).

Par exemple, ce rôle autorise le téléchargement de tous les objets de chaque compartiment du compte. Or, les objets S3 peuvent contenir des informations de configuration, voire des identifiants que le développeur pensait sécurisés. Ce rôle peut également permettre aux utilisateurs d'intercepter des messages SQS, d'obtenir la sortie de la console EC2 ou de récupérer des éléments depuis Kinesis ou DynamoDB.

Si vous recherchez un rôle qui restreint davantage l'accès des utilisateurs à la ressource ci-dessus, le rôle ViewOnlyAccess peut être utilisé, bien que ce rôle puisse s'avérer trop restrictif dans certains environnements.

POLITIQUES IAM CONDITIONNELLES

L'une des fonctionnalités les plus puissantes des politiques IAM est leur capacité à accorder un accès conditionnel aux ressources. Cela permet aux équipes de se séparer des autres charges de travail ou d'empêcher les actions indésirables. Voici quelques exemples :

ACCÈS PAR BALISES

La politique ci-dessous autorise l'exécution de toutes les actions, à condition que la balise « Département » soit définie sur « Finance ». C'est un moyen simple de segmenter les différentes activités de l'entreprise au sein d'un même compte. N'oubliez pas que tous les services ne prennent pas en charge les balises et que les limites globales du compte s'appliquent à tous les utilisateurs.

`{ "Version": "2012-10-17", "Statement": [

{ "Effect": "Allow", "Action": [ "" ], "Resource": "", "Condition": { "StringEquals": { "aws:RequestTag/Department": "Finance" } } }

] }`

RESTRICTION DE TEMPS

La politique ci-dessous autorise l'exécution de toutes les actions uniquement pendant la période indiquée. Ceci est utile lorsque les utilisateurs ne sont autorisés à accéder aux ressources que pendant certaines périodes, comme c'est le cas pour les prestataires.

`{ "Version": "2012-10-17", "Statement": [

{ "Effect": "Allow", "Action": [ "" ], "Resource": "", "Condition": { "DateGreaterThan": { "aws:CurrentTime": "2018-01-01T00:00:00Z" }, "DateLessThan": { "aws:CurrentTime": "2018-02-31T23:59:59Z" } } }

] }`

RESTRICTION BASÉE SUR L'ADRESSE IP

La politique ci-dessous autorise l'exécution de toutes les actions uniquement lorsque la requête provient des adresses IP spécifiées. Cela permet de limiter les appels aux seuls réseaux d'entreprise, offrant ainsi une couche de sécurité supplémentaire. Notez que les appels effectués par les services AWS, comme CloudFormation lors de la création de ressources, ne peuvent pas être restreints de cette manière ; en revanche, l'appel permettant de créer la pile peut l'être.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "*" ], "Resource": "*", "Condition": { "IpAddress": { "aws:SourceIp": [ "1.2.3.4/24" ] } } } ] }

UTILISATION DES LIMITES D'AUTORISATION

Depuis juillet 2018, les limites d'autorisation IAM permettent de restreindre les autorisations maximales pouvant être attribuées à un utilisateur (ou, dans certains cas, à une ressource). Si une limite d'autorisation est définie pour un utilisateur IAM, les autorisations effectives de cet utilisateur correspondent toujours à l'intersection de la limite d'autorisation et de ses stratégies IAM. Voici un exemple de son fonctionnement en pratique :

{ "Version": "2012-10-17", "Statement": [ { "Sid": "SimpleUserPermissions", "Effect": "Allow", "Action": [ "s3:*" ], "Resource": "*" } ] }

La stratégie ci-dessus illustre les autorisations dont un utilisateur peut disposer. Dans ce cas, les utilisateurs peuvent uniquement effectuer des actions S3. Supposons que cette stratégie ait été créée sous le nom SimpleUserPolicy. Au sein de ce compte, une personne est chargée de gérer la création des utilisateurs. La stratégie attribuée à leur utilisateur IAM est la suivante :

`{ "Version": "2012-10-17", "Statement": [ { "Sid": "SimpleUserPermissions", "Effect": "Allow", "Action": [ "s3:" ], "Resource": "" }, { "Sid": "CreateorChangeUser", "Effect": "Allow", "Action": [ "iam:CreateUser", "iam:DeleteUserPolicy", "iam:AttachUserPolicy", "iam:DetachUserPolicy", "iam:PutUserPermissionsBoundary" ], "Resource": "*",

"Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/SimpleUserPolicy" } }

},

{ "Sid": "IAMPermissions", "Effect": "Allow", "Action": [ "iam:Get*", "iam:List*", "iam:Simulate*", "iam:DeleteUser", "iam:UpdateUser", "iam:CreateAccessKey", "iam:CreateLoginProfile" ], "Resource": "*" } ] }`

Cette stratégie accorde L'utilisateur IAM dispose des mêmes autorisations que les autres utilisateurs (grâce à l'instruction SimpleUserPermissions), ainsi que de la possibilité de consulter et de mettre à jour les informations des utilisateurs (via l'instruction IAMPermissions). Il peut également créer des utilisateurs ou modifier leurs politiques (via l'instruction CreateorChangeUser). Cette instruction comporte une condition qui applique une limite d'autorisation au processus de création/mise à jour. L'utilisateur créé doit se voir attribuer la limite d'autorisation SimpleUserPolicy, sans quoi la création de l'utilisateur échouera.

Ainsi, nous garantissons que les autorisations des utilisateurs créés ne dépasseront jamais la limite définie par l'administrateur IAM.

RÉSUMÉ

Les rôles et les politiques IAM constituent un élément essentiel de la sécurité de tout environnement AWS et, correctement configurés, représentent un outil très puissant. Cependant, ces politiques peuvent facilement devenir incontrôlables et avoir des conséquences inattendues. Si vous rencontrez des difficultés pour gérer IAM, contactez-nous pour découvrir comment nous pouvons vous aider à maîtriser la sécurité de votre environnement AWS.