Data Perimeter – Cloisonner les comptes et données AWS | Centre d'expertises en cybersécurité

Dans les environnements AWS conséquents, les ressources et utilisateurs sont parfois segmentés en unités au sein d’une organisation. Cela permet de cloisonner les accès et les usages. Il est cependant difficile de contrôler efficacement l’ensemble des ressources au niveau de l’organisation. Le Data perimeter permet d’implémenter des restrictions à l’échelle d’une organisation. Ainsi, malgré la compromission de comptes AWS ou de mauvaises configurations, l’impact s’en trouve réduit.

Cet article explique succinctement différentes politiques implémentant un data perimeter, l’illustre par des exemples et définit les limites actuelles de ces politiques.

L’article est aussi disponible en anglais 🇬🇧

Architecture AWS multi-tenant

À des fins de segmentation des services, une architecture AWS peut être "multitenant", c’est-à-dire composée de plusieurs comptes AWS regroupés en une organisation.

Ci-dessous, un exemple d’architecture multitenant :

Chaque compte AWS fait partie de l’organisation et est structuré dans des Organizational Unit (OU). Un compte dit Management account permet la gestion de l’organisation. Les bonnes pratiques de gestion du Management account de l’organisation sont détaillées ici

Un compte AWS est défini par un compte racine ou "root". Ce compte est responsable de ses ressources et de la facturation liée. Un compte AWS est à distinguer des comptes IAM, permettant des accès AWS (console AWS, instance EC2, etc.) mais restant lié à un compte racine AWS.

La console AWS de l’organisation est disponible ici. Aussi, la commande AWS CLI suivante permet de vérifier si notre compte fait partie d’une organisation (il faut toutefois disposer des droits correspondants) :

$ aws organizations describe-organization

{
    "Organization": {
        "Id": "o-ajdtrvupik",
        "Arn": "arn:aws:organizations::[REDACTED]:organization/o-ajdtrvupik",
        "FeatureSet": "ALL",
        "MasterAccountArn": "arn:aws:organizations::[REDACTED]:account/o-ajdtrvupik/[REDACTED]",
        "MasterAccountId": "[REDACTED]",
        "MasterAccountEmail": "[REDACTED]@acceis.fr",
        "AvailablePolicyTypes": [
            {
                "Type": "SERVICE_CONTROL_POLICY",
                "Status": "ENABLED"
            }
        ]
    }
}

En l’absence des permissions adéquates, la présence du rôle prédéfini AWSServiceRoleForOrganizations dans l’IAM nous indique que notre compte fait partie d’une organisation :

C’est quoi le Data Perimeter ?

Selon Amazon :

Un Data perimeter est un ensemble de permissions Guardrails dans votre environnement AWS que vous utilisez pour vous assurer que seules vos identités de confiance accèdent aux ressources de confiance à partir des réseaux prévus. Les permissions du Data perimeter sont conçus pour servir de limite permanentes afin de protéger vos données sur un large éventail de comptes et de ressources AWS. Ces permissions à l’échelle de l’entreprise ne remplacent pas les contrôles d’accès précis existants. Ils contribuent plutôt à améliorer votre stratégie de sécurité en garantissant que tous les utilisateurs, rôles et ressources de la gestion des identités et des accès (IAM) d’AWS adhèrent à un ensemble de normes de sécurité définies.

Le Data perimeter autorise les accès en fonction des :

trusted identities : IAM principals dans notre organisation AWS
trusted resources : ressources dans notre organisation
trusted network : VPC ou réseau on-premise de notre organisation

Synthétisé dans le schéma suivant :

Le Data perimeter est mis en place à l’aide des permissions guardrails. Les 3 capacités suivantes AWS sont utilisées :

Service Control Policies (SCP) : Politiques définissant des deny ou allow policies au niveau de l’organisation sur les comptes AWS.
Resource control policies : Politiques permettant des restrictions sur les ressources de l’organisation afin d’en contrôler leur accès.
VPC endpoint policies : Politiques qui s’attachent aux VPC endpoints pour contrôler à quelles actions et ressources il est possible d’accéder en utilisant un point de terminaison VPC. Ces politiques ne seront pas détaillées dans cet article car elles se configurent au niveau d’un compte et non de l’organisation, contrairement aux 2 précédentes.

Se prémunir de quels scénarios de menace ?

Le but est d’empêcher l’utilisation et l’accès de nos ressources à l’extérieur de l’organisation. Les accès externes peuvent survenir dans les cas suivants :

Vol ou compromission d’identifiants AWS qui pourraient être réutilisés par des attaquants externes ;
Mauvaises configurations.

Le but est aussi de restreindre l’accès des comptes aux seules ressources de l’organisation.

Il est possible d’imaginer le scénario suivant :

Une entreprise utilise AWS pour héberger une architecture applicative, qui comprend une zone de développement et une zone de mise en production.
Sur AWS cela se manifeste par une organisation AWS avec un Management account et 2 OU, une unité développement et une de production. Chacune de ces OU contient plusieurs comptes AWS membres de l’organisation.
L’unité de développement doit pouvoir mettre à disposition des ressources à celle de production (des Buckets S3 par exemple), mais ne pas pouvoir exposer des ressources hors de ce cadre.

Le but du Data perimeter dans ce scénario est de limiter la fuite de données en cas de mauvaise configuration ou de compromission d’identifiants AWS provenant de l’unité de développement.

Service Control Policies (SCP)

Les SCP sont un type de politique d’organisation qui permet de gérer les permissions au sein de cette organisation.

Les droits effectifs d’un utilisateur sont l’intersection entre ce qui n’est pas limité par les SCP au niveau de l’organisation et les permissions autorisées via l’IAM sur le compte AWS.

Les SCP peuvent être attachés à différents niveaux de l’organisation et sont évaluées de la manière suivante :

Une autorisation explicite du service doit être présente à chaque niveau de l’arborescence de l’organisation : sur le compte racine, les OU et finalement sur le compte membre AWS ;
Une interdiction explicite ne doit pas être présente dans l’arborescence : Une interdiction dans une OU impactera tous les comptes présents dans cette OU malgré les éventuelles autorisations explicites à leur niveau.
Les permissions IAM du compte doivent enfin autoriser l’action.

AWS détaille de manière plus complète l’évaluation des SCP.

Des actions ou entités ne peuvent toutefois pas être limitées par des SCP comme le Management account.

Par défaut un compte ne faisant pas partie du Management account n’a pas les droits pour lister les SCP :

$ aws organizations list-policies --filter SERVICE_CONTROL_POLICY --profil audit

An error occurred (AccessDeniedException) when calling the ListPolicies operation: You don't have permissions to access this resource.

En effet, la permission organizations:ListPolicies est manquante.

Un Management account peut ainsi lister les SCP attachées à une OU particulière :

$ aws organizations list-policies-for-target --target-id <ou_id_ou> --filter SERVICE_CONTROL_POLICY --profil orga

{
    "Policies": [
        {
            "Id": "p-ji4vxdoi",
            "Arn": "arn:aws:organizations::[REDACTED]:policy/o-ajdtrvupik/service_control_policy/p-ji4vxdoi",
            "Name": "Allow S3 & list IAM",
            "Description": "grant full access to S3 bucket and allow to list IAM permissions of user",
            "Type": "SERVICE_CONTROL_POLICY",
            "AwsManaged": false
        }
    ]
}

La SCP configurée ici est la suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "iam:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "forbidIAMCreation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser"
      ],
      "Resource": "*"
    }
  ]
}

On peut la comprendre comme suit :

Autorise toutes les actions avec les services s3 et iam ;
Interdit explicitement toutes les actions de création d’un utilisateur via iam.

En effet, en cas de tentative de création d’un utilisateur, l’erreur suivante est renvoyée :

En l’absence d’autorisations explicite, les services autres que iam et s3 ne sont pas autorisés. Par exemple, il n’est pas possible de lister les instances EC2 :

Une SCP donnant une sécurité supplémentaire consiste à restreindre les IP depuis lesquelles le compte peut réaliser les actions AWS :

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "NotIpAddress": {
        "aws:SourceIp": [ // IP de sortie de l'entreprise
          "x.x.x.x",
          "x.x.x.x"
        ]
      }
    }
  }
}

Toutefois, les SCP ont leurs limites, c’est ce que nous allons voir dans le chapitre suivant.

Resource Control Policies

Pourquoi y a-t-il besoin d’autres politiques en plus des SCP ?

Imaginons que nous voulions éviter des fuites de données. Pour des besoins métiers, les développeurs doivent pouvoir créer des buckets S3 mais avec les contraintes suivantes :

les accès aux Buckets S3 doivent être fait depuis un compte de l’organisation
les accès doivent être fait depuis une IP de l’organisation.

On peut appliquer des SCP sur des comptes AWS ou des OU, mais pas sur des ressources, comme des Buckets S3. En effet, bien que le Bucket S3 soit créé par un certain compte, les restrictions affectant ce compte ne s’appliquent dessus. Si un compte est externe à l’organisation (ou non authentifié) nous ne pouvons pas lui appliquer des SCP. L’accès sera donc permis si le Bucket S3 est mal configuré.

Les Resource Control Policies (RCPs) sont un type de politique d’organisation qui permettent de restreindre les permissions sur les ressources d’un compte.

Ces politiques s’appliquent de la même manière que les SCPs, des restrictions présentent sur une OU ou la racine de l’organisation affectant l’ensemble de l’arborescence.

Un compte de l’organisation peut créer un Bucket S3, accessible publiquement :

La Bucket policy permettant d’autoriser des accès en lecture à tout le monde :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::open-bucket-47684541374684"
        },
        {
            "Sid": "Statement2",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::open-bucket-47684541374684/*"
        }
    ]
}

Les Bucket policies sont un type de ressources-based policies qui sont gérées directement par le compte et s’attachent sur des ressources spécifiques telles que des buckets S3.

En l’absence de RCPs, n’importe qui peut alors lister le Bucket et accéder aux fichiers (l’option --no-sign-request de la cli permet de faire la requête non-authentifiée) :

$ aws s3 ls s3://open-bucket-47684541374684 --no-sign-request
2025-04-11 15:15:21         20 open-file.txt
$ aws s3 cp s3://open-bucket-47684541374684/open-file.txt /tmp/ --no-sign-request
download: s3://open-bucket-47684541374684/open-file.txt to /tmp/open-file.txt

La RCP suivante restreint les opérations sur les Buckets S3, à moins d’y accéder depuis un compte de l’organisation :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "o-[REDACTED]"
        }
      }
    }
  ]
}

Une fois appliquée, les requêtes précédentes ne sont plus possibles :

$ aws s3 ls s3://open-bucket-47684541374684 --no-sign-request

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

La combinaison des différentes politiques (RCP et SCP) est donc très efficace pour contrôler l’exposition des données au sein d’une organisation. Les Resource control policies ne sont toutefois pas supportées par toutes les ressources

Les services supportés sont les suivants :

Amazon S3
AWS Security Token Service
AWS Key Management Service
Amazon SQS
AWS Secrets Manager

Cela ne fait malheureusement que peu de services concernés.

Edge case

URL presigned

Dans le cas où une Ressource control policy est appliquée sur les Buckets d’un compte pour n’autoriser l’accès que depuis des comptes de notre organisation, et où seules les permissions sur AWS S3 sont permises (via SCP), est-il toujours possible de partager des données d’un Bucket S3 à un tiers qui ne fait pas partie de l’organisation ?

Oui, via les presigned URLs :

Un accès est ensuite bien possible pour un tiers :

$ curl "https://open-bucket-70[REDACTED].s3.eu-west-3.amazonaws.com/open-file.txt?response-content-disposition=inline&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Security-Token=IQo[REDACTED]&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIA[REDACTED]%2F20250513%2Feu-west-3%2Fs3%2Faws4_request&X-Amz-Date=20250513T081859Z&X-Amz-Expires=720&X-Amz-SignedHeaders=host&X-Amz-Signature=21de1ac6e[REDACTED]"

My S3 file content!

Pourquoi ce comportement ? Les presigned URLs utilisent les identifiants du compte AWS. Accéder à une presigned URLs revient donc à utiliser le compte qui l’a créée ; l’accès est donc autorisé puisqu’il fait partie de l’organisation et que les SCP et RCP l’y autorisent.

Les SCP mises en place par l’organisation s’appliquent donc. Si une restriction d’IP est mise en place, cette dernière sera effective.

Ressources partagées et cibles externes

AWS recense plusieurs cas de ressources qui ne peuvent pas être restreintes par des conditions comme aws:ResourceOrgID :

Amazon Machine Images (AMIs)
Amazon EBS Snapshots
Amazon RDS Snapshots
AWS Resource Access Manager (AWS RAM)
Amazon CloudWatch Logs Subscription Filters
Amazon EventBridge Targets

Les ressources ci-dessus permettent de partager des données à des comptes externes sans permettre d’appliquer des politiques, comme pour les Buckets S3. Par exemple pour un snaspshot EBS :

Dans ces cas-ci, les fonctionnalités correspondantes doivent donc être restreintes par SCP, puis une exception doit être créée pour un compte IAM privilégié.

Référence

À propos de l’auteur

Article écrit par Alexandre RIPOTEAU alias Vunnm, Ingénieur en Test d’Intrusion chez ACCEIS.

Data Perimeter – Cloisonner les comptes et données AWS