Aller au contenu

Amazon Web Services

Objectif : lire un compte AWS en lecture seule pour répondre à des questions que la console AWS ne pose pas d'un coup d'œil :

  • de quels services managés dépend une application ;
  • quelles versions arrivent en fin de support imposée par AWS ;
  • quels buckets sont publics ;
  • quelles bases sont mono-AZ.

Le connecteur se règle sur Connecteurs → Cloud → Amazon Web Services. Le résultat se consulte sur deux pages :

Page Menu Contenu
Cloud AWS (/aws/) Inventaire L'inventaire
Analyses AWS (/aws/analyses) Sécurité Les constats d'hygiène et de sécurité

Aucune action sur AWS

InfraRiver n'appelle qu'une liste fermée d'opérations de lecture (Describe, List, Get) et ne lit jamais le contenu : ni ligne de base de données, ni objet d'un bucket, ni valeur de secret.

La liste des fonctions Lambda renvoie, de par AWS, leurs variables d'environnement : InfraRiver les écarte dès l'arrivée de la réponse et ne les conserve ni ne les journalise jamais.

La page de configuration affiche la liste exacte des actions IAM autorisées.

Ce que le connecteur alimente

Où Quoi
Inventaire des serveurs Les instances EC2 (hors instances terminées), rapprochées des serveurs déjà connus par leur nom uniquement — jamais par l'adresse IP, car les plages privées d'un VPC et du réseau interne se recoupent. Deux instances qui portent le même tag Name restent deux serveurs distincts (l'identifiant d'instance est ajouté) ; une instance sans tag Name prend son identifiant comme nom
Fiche d'un serveur Pour une instance EC2, un bloc AWS : instance, type, zone, VPC, namespace et services managés du namespace (avec leur fin de support)
Inventaire AWS (/aws/) Zones (régions lues, lectures impossibles), Namespaces, Ressources (avec une colonne « Constats » : le nombre de constats ouverts de la ressource, qui ouvre les analyses filtrées sur elle) ; compteurs d'inventaire seulement
Analyses AWS (/aws/analyses) Les constats d'hygiène et de sécurité, leurs compteurs et leurs raccourcis
TopoMap Sur la carte d'une application, le double-clic sur un serveur fait sortir son namespace cloud, puis les services managés qui le composent
EOLRIVER Les versions des services managés sont comparées aux cycles de vie publiés (un produit AWS par moteur)

Zones, namespaces, services managés

  • Une zone est une région AWS activée sur le compte. Les régions à lire se limitent par liste (« Régions à inclure » / « à exclure »).
  • AWS n'a pas de namespace : InfraRiver en calcule un, au choix par valeur d'un tag (par défaut la clé Application), par famille de service, par VPC ou par compte. Une ressource sans le tag tombe dans (non tagué), un signal de gouvernance. Un namespace qui porte le même nom qu'une application d'InfraRiver la propose (jamais de lien imposé).
  • Les services lus : bases RDS et clusters Aurora / DocumentDB, DynamoDB, ElastiCache, buckets S3 (chiffrement, versions, exposition publique, taille), volumes EBS (les volumes détachés sont signalés), registres ECR (nombre et taille des images, mutabilité des tags), fonctions Lambda (runtime), clusters EKS, clusters Kafka (MSK), équilibreurs de charge applicatifs et réseau (exposition, écouteurs, instances EC2 placées derrière).
  • Une région ou un service que l'organisation AWS interdit (politique de contrôle de service) ou que le rôle n'a pas le droit de lire s'affiche dans « Lectures impossibles » de la zone ; le reste est lu normalement et rien n'est retiré de ce qui était déjà connu. Lire toutes les régions d'un compte qui en interdit la plupart prend environ une minute : limitez la liste (« Régions à inclure »).
  • La taille d'un bucket vient des métriques de stockage de CloudWatch (stockage standard) ; sans la métrique, elle reste vide.
  • Un bucket est « public » quand sa politique l'est ; il est « privé » quand tout l'accès public est bloqué ; sinon l'exposition est « à vérifier » (les ACL ne sont pas lues).

Fin de support

Un service managé ne se patche pas : AWS impose ses montées de version. Les ressources qui portent une version sont comparées aux dates publiées (par EOLRIVER) :

  • fin du support actif ;
  • fin du support standard ;
  • fin du support étendu payant (RDS).

Pour les fonctions Lambda, la « fin du support actif » est la date de dépréciation du runtime.

Le résultat est la catégorie Hygiène de versions de la page Analyses, et la colonne « Support » de l'onglet Ressources.

Note

Le résultat n'est renseigné que si EOLRIVER est installé et a importé les produits AWS (synchronisation d'EOLRIVER en mode embarqué suffisante).

Analyses (/aws/analyses)

La page Analyses AWS (menu Sécurité) réunit en une seule liste de constats l'hygiène et les risques de sécurité du compte, chacun avec sa gravité (critique, élevée, moyenne, faible), sa catégorie et l'objet concerné.

Catégorie Constats
Hygiène de versions version en fin de support AWS, en support étendu payant, ou en maintenance seulement
Exposition bucket S3 public, base de données accessible publiquement, point d'accès d'un cluster EKS ouvert à Internet
Chiffrement base ou volume EBS non chiffré, cache non chiffré au repos, équilibreur de charge public sans écouteur HTTPS
Résilience base ou cache mono-AZ (plus grave si l'étiquette Environment vaut production), base sans sauvegarde automatique
Gouvernance ressource sans tag de namespace, volume EBS détaché, tags d'image ECR modifiables, registre sans analyse à la publication

Les cartes du haut comptent les constats à traiter par gravité. Une seconde rangée de raccourcis ouvre la liste filtrée :

  • fin de support ;
  • ressources exposées à Internet ;
  • bases et caches mono-AZ ;
  • volumes détachés ;
  • non chiffrés.

Les boutons de catégorie et les filtres de colonne affinent la liste. Les anciennes adresses /aws/?tab=analyses et /aws/?tab=eol renvoient sur cette page.

Accepter un risque

Accepter le risque (droit de gestion des connecteurs) ouvre un formulaire qui demande :

  • une justification (5 caractères au moins) ;
  • une durée : 30 jours, 90 jours, 6 mois ou un an — une date de fin est obligatoire ;
  • un motif : « Risque accepté » ou « Objet de test ».

Le constat passe sous « Acceptés » avec qui, quand et jusqu'à quand ; à l'échéance il revient dans « À traiter ». Rouvrir le remet tout de suite. Chaque acceptation et chaque réouverture est inscrite au journal d'audit.

Ce que l'analyse ne regarde pas

Un constat n'existe que si la donnée a vraiment été lue. Le cadre « Ce que cette analyse ne regarde pas (encore) » liste ce qui manque :

  • zones ou services dont la lecture a été refusée ;
  • buckets dont l'exposition n'a pas pu être déterminée ;
  • fin de support non évaluée ;
  • pour l'instant, les comptes IAM, les groupes de sécurité et le coût.

Warning

Une liste vide n'est donc jamais à lire comme « tout va bien ».

Mettre en place l'accès

  1. Sur la page de configuration, saisissez l'ARN de l'identité d'InfraRiver (utilisateur IAM, ou rôle de la machine) et générez un External ID.
  2. Télécharger le modèle CloudFormation : il crée dans le compte à surveiller le rôle InfraRiverReadOnly, assumable seulement par cette identité avec cet External ID, et qui porte exactement les actions de la liste blanche (rien de plus large qu'un ReadOnlyAccess, qui permettrait de lire des objets).
  3. Si vous venez de créer l'utilisateur IAM, attendez une minute avant de créer le rôle (AWS met un instant à reconnaître un nouvel utilisateur). Renseignez l'ARN du rôle créé, enregistrez, Tester : le test affiche le compte, son alias, le nombre de régions activées et si le rôle est bien en lecture seule (avertissement orange sinon, jamais bloquant).
  4. Cochez Synchronisation automatique puis Synchroniser maintenant.
Champ Type Description
Mode d'authentification Liste Rôle assumé + External ID (recommandé : aucune clé longue durée sur le compte surveillé) ou clés d'accès d'un utilisateur lecture seule.
ARN du rôle à assumer Texte arn:aws:iam::<compte>:role/<nom>
External ID Texte Valeur partagée avec la politique d'approbation du rôle ; le bouton Générer en propose une.
ID de clé d'accès / Clé secrète Texte / mot de passe Mode rôle : identité qui appelle AssumeRole (vide = identifiants de la machine InfraRiver, par exemple son profil d'instance EC2). Mode clés : la clé elle-même. La clé secrète est chiffrée, jamais réaffichée.
URL du point d'accès Texte (avancé) Vide pour AWS ; pour un point d'accès privé (VPC endpoint) ou un simulateur.
Régions à inclure / à exclure Texte Codes séparés par des virgules ; vide = toutes les régions activées.
Regrouper en namespaces par Liste Tag (recommandé), famille de service, VPC ou compte.
Clé de tag du namespace Texte Application par défaut.
Intervalle de synchronisation Nombre (minutes, 15-1440) 360 par défaut.
Synchronisation automatique Case à cocher Décoché : aucun appel vers AWS.

Ce que le connecteur ne fait pas encore

Fonctions pas encore livrées :

  • les comptes IAM et les chemins d'administration, donc les constats d'accès (clés anciennes, comptes sans MFA, droits d'administrateur) ;
  • les dépendances entre ressources ;
  • les vulnérabilités des images ECR ;
  • le coût et la consommation ;
  • le multi-compte (AWS Organizations).

Familles pas encore lues : ECS, groupes de sécurité, files SQS/SNS et secrets.

Qui voit quoi

  • Les rôles qui lisent tout le parc voient tout le compte AWS.
  • Un rôle à périmètre restreint (voir Utilisateurs & permissions) ne voit que les instances EC2 de ses serveurs et les services managés du même namespace (ou ceux du namespace rattaché à une application dont il est membre). Les services sans tag ne sont montrés qu'aux rôles qui voient tout. Cartes, constats et inventaire suivent la même règle, et les problèmes de lecture du compte ne lui sont pas montrés.
  • Sur la page de configuration, l'identifiant de clé d'accès et l'External ID ne s'affichent en clair qu'aux utilisateurs qui peuvent gérer les connecteurs ; un lecteur n'en voit que les quatre derniers caractères.