Renforcer la sécurité IAM avec les limites d’autorisations AWS et Snyk

Dans le paysage du cloud en constante évolution, la gestion des autorisations et la mise en place de contrôles de sécurité robustes sont essentielles pour les organisations qui utilisent Amazon Web Services (AWS). AWS Identity and Access Management (IAM) joue un rôle crucial dans la gestion des autorisations d’accès aux ressources AWS. IAM offre un contrôle granulaire des autorisations, tandis que les limites d’autorisations AWS IAM apportent davantage de sécurité et de flexibilité pour affiner les contrôles d’accès.

Une limite d’autorisations AWS est un mécanisme de sécurité qui restreint les autorisations dont peut disposer un principal IAM (utilisateur ou rôle). En définissant une limite d’autorisations, les organisations peuvent établir un cadre d’autorisation cohérent et bien défini qui empêche toute élévation accidentelle ou intentionnelle des privilèges. La définition de limites d’autorisations contribue à réduire le risque d’accès non autorisé aux ressources sensibles et à limiter les conséquences potentielles des incidents de sécurité ou des erreurs humaines.

En bref, les limites d’autorisations sont des garde-fous qui encadrent les autorisations. Toutefois, elles n’accordent pas elles-mêmes d’autorisations. Par exemple, cet utilisateur ne dispose d’aucune autorisation, même s’il possède la limite d’autorisations SecurityAudit :

Avantages et cas d’usage

Les limites d’autorisations IAM sont particulièrement utiles dans les organisations dont l’environnement IAM est distribué ou complexe.

Découvrez ci-dessous quelques cas d’usage où les limites d’autorisations peuvent renforcer la sécurité et l’efficacité opérationnelle :

1. Équipes IAM centralisées dans le cloud : les limites d’autorisations permettent aux équipes ou aux unités opérationnelles de gérer leurs propres entités IAM et les autorisations associées, dans le cadre défini par les politiques de sécurité de l’organisation. Cette délégation des tâches administratives renforce l’agilité et l’autonomie, tout en préservant un cadre de sécurité centralisé. Le cas d’usage principal des limites d’autorisations IAM est celui de l’« administrateur délégué ».

2. Environnements mutualisés : dans les environnements d’infrastructure partagée ou les applications mutualisées, les limites d’autorisations empêchent un locataire d’accéder aux ressources d’un autre. Les organisations peuvent garantir l’isolation et préserver des barrières de sécurité solides en définissant des limites propres à chaque locataire.

3. Séparation des tâches : les limites d’autorisations sont utiles pour séparer et faire respecter les responsabilités au sein de l’organisation. Les administrateurs peuvent empêcher les actions non autorisées en attribuant des limites selon les fonctions, par exemple pour le développement, les tests ou la production.

4. Accès de tiers : les limites d’autorisations apportent un niveau de contrôle supplémentaire lorsque vous accordez un accès à des parties externes, comme des sous-traitants ou des fournisseurs. En définissant une limite qui restreint leur accès aux seules ressources nécessaires, les organisations peuvent réduire les risques liés à l’octroi d’autorisations étendues à des tiers.

Évaluation des limites d’autorisations

Si une entité IAM dispose d’une limite d’autorisations définie, celle-ci est évaluée vers la fin du processus d’évaluation des politiques, comme illustré ici :

L’arbre de décision des autorisations IAM est complexe. Notez que ces diagrammes ne couvrent pas les accès intercomptes et ne détaillent pas entièrement les politiques basées sur les ressources. Chaque colonne représente une source potentielle d’autorisation ou de refus pour les principaux IAM. Les limites d’autorisations se trouvent sur la cinquième voie de l’évaluation des autorisations et peuvent autoriser ou refuser des autorisations.

Il est important de noter que les politiques basées sur les ressources peuvent annuler l’intention des limites d’autorisations IAM. Si une politique basée sur les ressources accorde directement des autorisations au principal à l’origine de la requête, un refus implicite dans une limite d’autorisations n’a aucun impact sur la décision finale. En effet, les politiques basées sur les ressources sont évaluées avant la limite d’autorisations.

Pour maintenir une posture de sécurité robuste, les organisations doivent concevoir et surveiller attentivement les politiques de ressources afin qu’elles respectent les limites de sécurité prévues. Des audits et des examens réguliers, des outils pour les développeurs ainsi que l’intégration des politiques d’autorisations au SCM sont indispensables pour s’assurer que toute dérogation est intentionnelle et respecte le principe du moindre privilège.

Règles Snyk

Snyk est le seul outil de sécurité de l’infrastructure as code (IaC) et la seule suite couvrant le code jusqu’au cloud à évaluer les limites d’autorisations IAM et à inclure les règles suivantes. Les captures d’écran associées à chaque règle proviennent de l’exécution de la CLI Snyk.

Le principal IAM ne possède aucune limite d’autorisations

Cette politique génère des résultats pour les rôles et les utilisateurs IAM auxquels aucune limite d’autorisations n’est attribuée. Une équipe IAM centralisée ou distribuée peut rapidement déterminer si des limites d’autorisations sont utilisées. L’extrait Terraform suivant génère des résultats pour cette règle, car aucun des utilisateurs suivants :

Le principal IAM possède une limite d’autorisations trop permissive

Parmi les rôles et utilisateurs IAM qui possèdent des limites d’autorisations, cette politique repère celles qui pourraient être trop larges. Par exemple, une limite d’autorisations IAM de la forme suivante :

1{
2    "Version": "2012-10-17",
3    "Statement": [{
4        "Effect": "Allow",
5        "Action": “*”,
6        "Resource": "*"
7    }]
8}

ne constitue en réalité aucune limite d’autorisations. Grâce à cette visibilité supplémentaire, les organisations peuvent réduire plus efficacement les autorisations en appliquant le principe du moindre privilège. Le code Terraform suivant génère des résultats pour chaque principal IAM dont les limites d’autorisations sont trop larges :

L’administrateur IAM délégué est mal configuré

Comme indiqué précédemment, les administrateurs IAM délégués représentent le principal cas d’usage des limites d’autorisations. Les équipes IAM centralisées peuvent ainsi autoriser les développeurs à créer leurs propres utilisateurs et rôles pour répondre aux besoins de l’entreprise, tout en gardant un certain contrôle sur les comptes dans lesquels ces utilisateurs et rôles sont créés. Toutefois, ces nouveaux principaux doivent eux aussi disposer de leurs propres limites d’autorisations. Les équipes IAM peuvent l’exiger en utilisant une politique IAM correctement configurée avec des conditions IAM. Nous examinons ici les autorisations des utilisateurs et des rôles qui peuvent créer d’autres principaux, puis évaluons leur politique IAM pour vérifier la présence des conditions appropriées. Ces résultats permettent de repérer les risques potentiels d’élévation des privilèges par les administrateurs délégués.

Une politique de ressources annule la limite d’autorisations

Cette règle Snyk proposée examine les politiques de ressources pour déterminer quels principaux IAM ont accès à la ressource concernée et si le principal devrait y avoir accès, au regard de ses politiques basées sur l’identité et de ses limites d’autorisations. Les organisations peuvent ainsi repérer les éventuelles lacunes de leur posture de sécurité, par exemple les cas où des politiques basées sur les ressources peuvent annuler les limites d’autorisations. Parmi les ressources qui prennent en charge les politiques basées sur les ressources, citons :

• Buckets S3

• Clés KMS

• Tables DynamoDB

• Secrets SecretsManager

Automatisez votre gouvernance de sécurité avec Snyk

Snyk IaC permet aux développeurs de sécuriser leurs configurations à l’aide d’un moteur de politiques unifié, qui assure une visibilité et une gouvernance cohérentes en matière de sécurité, de l’IDE aux environnements cloud en cours d’exécution. En plus des ensembles de règles de sécurité Snyk intégrés pour les autorisations IAM présentées ci-dessus, les équipes peuvent définir des règles personnalisées dans le langage de requête Rego d’OPA et garantir la conformité cloud grâce à des ensembles de règles associés à plus de 10 référentiels pris en charge.

Références

• Limites d’autorisations pour les entités IAM

• Déléguer des responsabilités à l’aide de limites d’autorisations

• Quand et où utiliser les limites d’autorisations IAM

• Logique d’évaluation des politiques

• Services AWS compatibles avec IAM