Le Comportement Attendu et l’Erreur 403 Access Denied

Lors d’une interaction avec Amazon S3 (Simple Storage Service) — qu’il s’agisse du téléchargement d’un fichier via un navigateur web, de l’envoi d’artefacts via la CLI AWS, ou de la lecture de fichiers de configuration via une application s’exécutant sur EC2 — le comportement attendu est une transaction rapide et fluide donnant lieu à un statut HTTP 200 OK.

Cependant, l’un des obstacles les plus frustrants et fréquents rencontrés par les administrateurs cloud est l’erreur 403 Access Denied ou l’exception AccessDenied.

Comme AWS applique un modèle de confiance zéro (zero-trust) par défaut (tout accès est refusé à moins d’être explicitement autorisé), toute absence d’autorisation dans la chaîne de sécurité se soldera par un 403. De plus, un refus (Deny) explicite n’importe où dans vos politiques annulera complètement toute autorisation (Allow).

Prérequis

Avant de résoudre le problème, rassemblez le contexte suivant :

  • Le nom exact du Compartiment (Bucket) S3.
  • L’utilisateur IAM, le rôle IAM (si vous utilisez EC2/EKS/Lambda), ou les clés d’accès AWS utilisées pour la requête.
  • Si la requête provient du même compte AWS ou d’une demande inter-comptes (cross-account).
  • Si les objets sont chiffrés avec KMS.

Causes Principales du 403 Access Denied S3

Une erreur 403 Access Denied dans S3 se résume généralement à l’une de ces couches de sécurité interposées :

  1. Autorisations IAM Manquantes : L’utilisateur ou le rôle IAM tentant l’action manque de s3:GetObject (pour télécharger), s3:PutObject (pour envoyer) ou s3:ListBucket.
  2. Conflits de Bucket Policy : Le compartiment S3 possède une Bucket Policy (stratégie .json) à laquelle il manque une déclaration de ressource (Resource statement) ou qui contient un Effect: Deny explicite pour l’utilisateur/l’adresse IP.
  3. Le Blocage de l’Accès Public est Activé : Si vous essayez de rendre un compartiment public pour l’hébergement d’un site web, le paramètre global “Block Public Access” rejettera les requêtes publiques, peu importe ce que dit la Bucket Policy.
  4. Erreurs de Déchiffrement KMS : Si le compartiment utilise AWS KMS (Key Management Service) pour le chiffrement, l’utilisateur IAM a besoin de s3:GetObject et de kms:Decrypt. Si l’autorisation de la clé KMS est manquante, S3 renvoie un 403.
  5. Propriété de l’Objet vs Propriété du Compartiment : Dans les scénarios inter-comptes, le Compte A envoie un fichier au compartiment du Compte B. Le Compte B tente de le lire et obtient un 403 car le Compte A est explicitement propriétaire de l’objet nouvellement créé.

Solution Étape par Étape

1. Identifier Exactement l’Action Autorisée Requise

Tout d’abord, déterminez ce que l’application ou l’utilisateur tente de faire. Si vous téléchargez un fichier via la CLI :

aws s3 cp file.txt s3://mon-compartiment-cloud/

Cela nécessite s3:PutObject. Si vous essayez de voir le contenu du compartiment via aws s3 ls, cela requiert s3:ListBucket.

2. Vérifier les Autorisations Utilisateur/Rôle IAM

Naviguez dans la Console IAM et trouvez l’Utilisateur ou le Rôle rattaché à votre système. Ils doivent posséder une politique autorisant l’accès à l’ARN exact du compartiment.

Une politique IAM correcte permettant la lecture/écriture ressemble à ceci :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::mon-compartiment-cloud"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::mon-compartiment-cloud/*"
            ]
        }
    ]
}

Remarque Cruciale : La ressource arn:aws:s3:::mon-compartiment s’applique au compartiment lui-même (pour ListBucket). La ressource arn:aws:s3:::mon-compartiment/* s’applique aux objets à l’intérieur du compartiment (pour GetObject / PutObject). Confondre ces deux éléments est une cause majeure des erreurs 403 !

3. Vérifier la Politique de Compartiment (Bucket Policy)

Accédez à la Console S3, sélectionnez votre compartiment et cliquez sur l’onglet Permissions (Autorisations). Faites défiler jusqu’à Bucket policy.

Même si votre utilisateur IAM possède des privilèges administrateur complets, un Deny explicite dans la Bucket Policy l’annulera. Par exemple, si vous repérez une politique visant à restreindre l’accès à une IP de VPN spécifique :

{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::mon-compartiment-cloud/*",
    "Condition": {
        "NotIpAddress": {"aws:SourceIp": "203.0.113.0/24"}
    }
}

Si vous testez à partir d’une adresse IP en dehors de cette plage, vous recevrez un 403.

4. Rendre des Objets Publics (Hébergement Web)

Si votre but est d’héberger un site statique ou des images publiques et que vous recevez un 403 :

  1. Allez sur l’onglet Permissions dans S3.
  2. Éditez Block public access (bucket settings) et décochez “Block all public access” (Bloquer tout l’accès public). Enregistrez les modifications.
  3. Ajoutez la Bucket Policy suivante pour autoriser explicitement internet à lire vos objets :
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::mon-compartiment-cloud/*"
        }
    ]
}

5. Vérifier le Chiffrement KMS (Solution Alternative)

Si les autorisations semblent parfaitement correctes, vérifiez si le compartiment utilise des clés KMS gérées par le client (SSE-KMS). Allez dans l’onglet Properties (Propriétés) du compartiment S3. Si le “Default Encryption” (Chiffrement par défaut) est défini pour utiliser une clé KMS personnalisée, votre rôle IAM doit également avoir l’autorisation de la déchiffrer.

Attachez une politique à votre Rôle IAM autorisant :

{
    "Effect": "Allow",
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
    ],
    "Resource": "arn:aws:kms:us-east-1:123456789012:key/votre-id-de-cle-kms"
}

Prévention

  • Respectez le Moindre Privilège : Évitez les politiques larges de type s3:*. Attribuez très précisément s3:GetObject et s3:PutObject aux chemins ARN appropriés.
  • Tirez parti d’AWS Policy Simulator : Utilisez le Simulateur de Politiques IAM de la console AWS. Vous pouvez y entrer un utilisateur, une action S3 et un nom de compartiment, et AWS tracera exactement quelle stratégie globale ou locale bloque ou permet la requête.
  • Appliquez “Bucket Owner Enforced” : Pour contrer les problèmes inter-comptes, activez “Bucket Owner Enforced” sous les paramètres “Object Ownership” dans S3. Cela désactive complètement les Listes de Contrôle d’Accès (ACL) et force la possession de l’objet importé directement vers l’hébergeur racine de l’espace global, simplifiant radicalement les autorisations de lecture asymétrique.

Résumé

  • L’erreur 403 Access Denied sur S3 est typiquement propulsée par des conflits entre les Stratégies IAM, Stratégie S3 globale (Policy), et la vérification des clés KMS.
  • L’effet explicite du composant d’arrêt Deny domine les chartes des privilèges systèmes comme AdministratorAccess.
  • Ayez l’œil bien en face des attributs globaux /* lors de l’application de données aux composants unitaires GetObject.
  • Répudiez immédiatement les blocages publics natifs depuis internet vers la ressource en suspendant manuellement l’état “Block Public Access”.
  • Maintenez solidement un canal kms:Decrypt via la mécanique interne si S3 hérite de l’encryptage.

Articles Connexes