Stockage objet exposé : établir l’accès possible et les lectures observées
Enquêtez sur un stockage objet signalé public : permissions effectives, URL présignées, couverture des logs et lectures établies avant de vérifier le confinement.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Une alerte signale qu’un stockage objet est public. Faut-il annoncer une fuite de tous ses fichiers ? Non : une permission potentielle, une requête autorisée et un contenu effectivement servi sont des constats différents. À l’inverse, aucun résultat dans une recherche de logs ne suffit à garantir qu’aucun accès n’a eu lieu.
Voici une méthode d’investigation indépendante du SIEM et du fournisseur, illustrée par la documentation publique d’Amazon S3. Les comportements propres à AWS sont présentés comme tels. Le guide ne décrit aucun incident client ni aucune capacité d’intégration Seculogik disponible.
1. Délimiter l’alerte et préserver l’état observé
Commencez par identifier le stockage, son propriétaire, les objets ou versions concernés, le point d’accès et la période examinée. Relevez aussi ce qui a produit l’alerte : analyse d’une politique, modification de configuration ou requête réellement réussie. Ces signaux n’apportent pas la même preuve.
AWS documente plusieurs niveaux de blocage de l’accès public dans S3, notamment le compte, le bucket et le point d’accès. Le service combine les restrictions applicables ; une seule option consultée au niveau du bucket ne décrit donc pas tous les contrôles pertinents. Source : AWS, S3 Block Public Access
Notre recommandation : préserver les paramètres et politiques utiles avant modification, avec leur origine et l’heure de collecte. Une copie de la configuration actuelle n’est pas une reconstitution automatique de la configuration passée. Recherchez l’historique disponible pour borner la période d’exposition possible.
Définissez le périmètre avant de compter les fichiers concernés. Une permission portant sur certains objets ou certaines actions ne permet pas de conclure que l’ensemble du stockage était lisible. Si le périmètre reste inconnu, conservez cette incertitude plutôt que d’inventer un total.
2. Distinguer accès anonyme, identité autorisée et lien partagé
AWS évalue les politiques applicables dans le contexte de la requête. Sa documentation distingue les politiques d’identité, celles des ressources et d’autres limites ; un refus explicite peut prévaloir sur une autorisation. Une instruction permissive isolée ne décrit pas nécessairement le résultat final. Source : AWS, évaluation des politiques
Les URL présignées constituent un autre chemin : AWS les décrit comme un accès limité dans le temps utilisant les droits de l’identité qui les a créées. Leur possession permet l’usage prévu lorsque les conditions d’accès sont satisfaites. Une lecture via ce mécanisme ne doit pas être classée automatiquement comme un accès public anonyme. Source : AWS, URL présignées S3
Nous recommandons de qualifier chaque chemin séparément : requête anonyme, application authentifiée, lien présigné ou service intermédiaire. Consignez l’action autorisée, la ressource et les conditions pertinentes. Le droit de lister les objets n’est pas le même contrôle que celui d’en lire le contenu.
Traitez les liens signés comme des éléments sensibles. Dans un commentaire partagé, privilégiez une référence protégée et une description du mécanisme plutôt que l’URL complète. Ne transmettez pas un lien d’accès réel à un service public d’analyse pour vérifier sa réputation.
3. Vérifier si les traces couvrent les opérations recherchées
AWS distingue les événements de gestion CloudTrail des événements de données, qui comprennent les opérations sur les objets S3 comme GetObject. Les événements de données ne sont pas enregistrés par défaut dans les trails et ne figurent pas dans l’historique standard des événements CloudTrail. Une recherche dans cet historique seul peut donc manquer les lectures recherchées. Source : AWS, journalisation CloudTrail pour S3
Les logs d’accès serveur sont une autre source. AWS précise que leur livraison est réalisée au mieux, sans garantie d’exhaustivité ni de ponctualité ; un enregistrement peut arriver tard, manquer ou être dupliqué. Source : AWS, logs d’accès serveur S3
Notre recommandation : dresser un relevé de couverture par source, période, opération et ressource. Vérifiez les sélecteurs, les exclusions, la conservation et les changements de configuration connus. Le fait qu’un dispositif existe aujourd’hui ne prouve pas qu’il couvrait les objets concernés au moment utile.
Séparez la collecte destinée à la suite de l’enquête et les preuves historiques déjà disponibles. Faire activer une journalisation supplémentaire ne recrée pas les événements qui n’ont pas été enregistrés. Toute modification doit être autorisée et son effet sur les volumes et les coûts compris par le responsable.
4. Qualifier ce qui a réellement été servi
Le format textuel des logs d’accès S3 distingue notamment l’opération, l’objet, le statut HTTP, les octets envoyés et la taille de l’objet. Il fournit aussi le type d’authentification et, selon la requête, une référence de version. Un champ indisponible peut être représenté par un tiret. Source : AWS, format des logs d’accès S3
Nous recommandons de construire une chronologie de requêtes pertinentes, en distinguant lecture de contenu, consultation de métadonnées, liste d’objets et tentative refusée. Un succès technique sur une opération ne doit pas devenir, par simplification, le téléchargement d’un fichier entier.
Rapprochez l’opération de son résultat, de l’objet ou de sa version et du volume effectivement documenté lorsqu’il est disponible. Traitez les répétitions et les copies de logs avant de compter : additionner plusieurs traces d’une même requête peut gonfler artificiellement le constat. Ne remplacez pas les octets servis par la taille totale de tous les objets accessibles.
Une réponse servie ne prouve pas qu’un humain a lu le contenu ni qu’il l’a conservé. Une identité ou une adresse technique ne suffit pas non plus à identifier la personne qui contrôlait la requête. Présentez les effets établis et les limites d’attribution séparément.
5. Vérifier le confinement avec un test proportionné
Préservez les éléments utiles dans un emplacement autorisé, sans retarder une mesure urgente pour obtenir un dossier parfait. Faites valider le changement selon le chemin en cause : politique de ressource, identité, partage présigné ou service intermédiaire. Bloquer un chemin ne démontre pas que les autres ont disparu.
Notre recommandation : définir un test avec un objet synthétique et des identités contrôlées, dans un périmètre autorisé. L’objet doit relever des contrôles pertinents pour le problème étudié. Un objet témoin soumis à une autre politique ne valide pas le confinement des objets signalés.
Vérifiez le refus du chemin indésirable et le maintien de l’accès légitime attendu. Un refus généralisé pourrait simplement indiquer une panne ou une indisponibilité du service. Consignez l’heure, le contexte de la requête et le résultat, puis contrôlez les traces générées lorsque la couverture le permet.
Ne téléchargez pas les véritables fichiers sensibles pour prouver l’exposition. Ne réactivez pas un accès public pour reproduire un incident. Si un test réaliste exige davantage de droits ou un environnement particulier, faites définir ce cadre par les responsables habilités plutôt que d’élargir l’exercice au passage.
6. Conclure sans confondre exposition et exfiltration totale
Exemple entièrement fictif : une ancienne politique permettait une lecture non souhaitée sur un périmètre limité. Les traces retrouvées établissent des réponses de lecture pour certains objets, tandis qu’une partie de la période n’est pas couverte. La conclusion doit distinguer le chemin d’accès établi, les objets documentés et l’intervalle non résolu.
Nous recommandons de faire apparaître quatre éléments dans le dossier final :
- Le mécanisme d’accès et la période confirmés, avec les hypothèses restantes.
- Les opérations observées et les données concernées dans la limite des preuves.
- La couverture des sources, les doublons traités et les angles morts.
- La mesure prise, son propriétaire et le contrôle qui en vérifie l’effet.
Évitez aussi bien « tout a été exfiltré » sans preuve que « aucune fuite » sur une période non couverte. Une appréciation des conséquences pour les données relève des responsables habilités, avec les éléments techniques et leurs limites ; le SOC ne doit pas remplacer cette décision par un simple statut de configuration.
Nos ressources gratuites d’investigation peuvent aider à organiser ces constats. L’objectif est un dossier permettant à un autre intervenant de distinguer accès possible, contenu servi et résultat du confinement, sans dépendre d’un voyant public ou privé.