Accès sécurisé

Comment nous entrons dans votre compte

Donner accès à un tiers demande de la confiance. Nous lisons les coûts, ce qui est ouvert et la dépense IA. Nous n'écrivons que si vous accordez le rôle des agents.

Commencer gratuitement maintenant AAA Sentinel — Security

Cloud, sécurité et IA. À la connexion nous lisons ; l'écriture est un second rôle, celui des agents.

Exemple illustratif

Cloud

Services d'IA

Par défaut

Nous lisons les coûts, l'inventaire, la dépense IA et si quelque chose est resté ouvert. Rien n'est écrit.

Si vous accordez le rôle

Les agents appliquent ce que vous approuvez : coûts, exposition et dépense IA.

Lecture par défaut

Le rôle AWS, Azure ou GCP, et les clés des services d'IA, se connectent en lecture seule. L'écriture vit dans un second rôle, celui des agents : vous le créez, vous approuvez chaque action. Sans ce rôle, nous n'arrêtons ni ne supprimons rien.

AWS : rôle CloudFormation avec ViewOnlyAccess et SecurityAudit (nous lisons métadonnées et configuration, pas les données de vos bases ni les valeurs de Secrets Manager ou de Parameter Store ; nous ne conservons pas les valeurs des variables d'environnement des fonctions) et Cost Explorer ; en plus, uniquement la lecture de votre export FOCUS et la recherche de traces dans les logs si vous activez les flux
Azure : Service Principal avec Reader et Cost Management Reader (sans Contributor ni Owner)
GCP : Service Account avec des rôles de lecture (Viewer) et la lecture de la facturation dans BigQuery, sans Editor
L'agent autonome (plan Business) requiert un second rôle que vous accordez volontairement
Si vous révoquez le rôle, AAA Sentinel perd immédiatement son accès

Par défaut

Coûts et inventaire
Ce qui est ouvert ou mal configuré
Dépense et usage d'IA

Avec l'agent

Fermer l'exposition que vous approuvez
Allumer et éteindre selon le planning
Agir dans le cloud, la sécurité et l'IA

Chiffrement KMS

Chiffrement KMS des identifiants

Les clés Azure, GCP et des services d'IA sont stockées dans un bucket S3 privé, chiffrées avec AWS KMS et notre propre clé. Pour AWS, nous ne stockons aucune clé : seulement l'ARN du rôle.

Customer Master Key (CMK) alternée automatiquement chaque année par AWS
Chiffrement côté serveur S3 avec KMS (SSE-KMS)
Chiffrement symétrique AES-256
La clé maître ne quitte jamais les HSM d'AWS KMS
Les fonctions qui utilisent les identifiants reçoivent la permission de déchiffrement via IAM ; le bucket bloque tout accès public

Vous générez un identifiant cloud
Client Secret Azure, clé de Service Account GCP ou clé d'API d'IA
Nous fermons l'enveloppe
KMS chiffre l'identifiant. La clé maître ne quitte pas AWS.
Stockée chiffrée dans S3
Bucket privé, versionné et accessible uniquement en HTTPS. La clé maître ne quitte jamais KMS.

ExternalId

Un code unique par organisation

L'attaque confused deputy permet à un tiers malveillant d'assumer un rôle IAM de votre compte en se faisant passer pour un service légitime. Pour l'éviter, votre organisation dispose d'un code aléatoire de 128 bits que votre rôle AWS exige comme ExternalId.

Aléatoire, 128 bits : il n'est dérivé d'aucune donnée de votre organisation
Généré une seule fois et identique pour tous les comptes AWS de votre organisation
Sans le bon ExternalId, AWS rejette tout AssumeRole
Empêche les attaques confused deputy même si l'ARN du rôle fuit
Vous le voyez dans l'assistant de connexion, car il figure dans la politique de confiance de votre rôle

Avec votre code unique

AAA Sentinel demande l'accès avec le code de votre organisation. Votre rôle le reconnaît et le laisse entrer en lecture.

Sans votre code

Un autre compte, même s'il connaissait le nom du rôle, n'a pas votre code. Le cloud refuse l'accès.

Sans cet ExternalId exact, toute tentative d'AssumeRole est rejetée par AWS.

JWT + Cognito

Authentification avec Amazon Cognito (User Pools + Hosted UI) pour les personnes et OAuth2 Client Credentials avec des JWT HS256 d'une heure pour l'API. Les jetons d'API portent votre organisation et ses scopes.

Jetons d'une heure avec rafraîchissement automatique
L'organisation et le rôle sont résolus côté serveur à partir de votre utilisateur, pas de la requête
La session circule dans un cookie httpOnly et est vérifiée par un autorisateur Lambda d'API Gateway
Les jetons d'API (Client Credentials) sont signés en HS256 avec un secret stocké dans Parameter Store (SecureString)
Rate limiting distinct pour les jetons d'API
Si votre organisation exige la MFA, l'API la vérifie à chaque requête, propriétaire compris ; les personnes connectées avec Google ou le SSO de l'entreprise la gèrent dans leur fournisseur d'identité
Restriction des domaines d'e-mail autorisés pour la connexion et les invitations

01
Vous vous connectez
Inscription, accès et récupération passent par Cognito.
02
Nous vérifions qui vous êtes
MFA et domaine e-mail, si votre organisation l'exige.
03
Vous recevez un jeton de session
Signé, de courte durée, avec votre organisation à l'intérieur.
04
Chaque requête porte cette organisation
L'API ne prend jamais le tenant dans le corps de la requête.

Isolation locataire

Isolation des locataires

Les données de chaque organisation sont stockées sous son identifiant d'organisation. Cet identifiant provient de votre session vérifiée, jamais de ce que la requête envoie.

DynamoDB : les tables sont partitionnées par organisation ; celles des analyses et des constats, par compte, et le compte est d'abord vérifié par rapport à votre organisation
L'organisation provient de l'utilisateur authentifié, pas du corps de la requête
Sans session ni jeton signés et vérifiés, aucune organisation n'est résolue
Chaque compte est recherché avec la clé de votre organisation ; en cas d'incohérence, l'accès est refusé et enregistré comme incident de sécurité

Votre organisation

Consulte les constats et les coûts de vos comptes.

Ne voit que les siens

Une autre organisation

Tente de lire les mêmes données.

Bloqué : tenant différent

Chaque organisation ne voit que ses propres lignes. L'organisation provient de la session, jamais de la requête.

Journal d'audit

Chaque action pertinente (analyses, changements de configuration, accès et actions de l'agent) est consignée dans une table DynamoDB dédiée, chiffrée avec KMS et conservée un an. L'application ne fait qu'ajouter des entrées : aucune écriture n'en écrase une autre.

DynamoDB chiffré avec KMS, avec restauration à un instant donné (PITR)
Conservation d'un an ; ensuite chaque entrée expire d'elle-même
Champs : date, organisation, auteur (personne, jeton, agent ou système), action, ressource et résultat
Les actions de l'agent sont consignées avec leur proposition, leur approbation et leur exécution
Vous consultez votre activité et l'exportez en CSV depuis votre profil

Exemple d'enregistrement d'audit

Exemple illustratif

Aujourd'hui, 09:12
Analyse de posture de production
Planifié · lecture seule
Aujourd'hui, 11:40
Ana a approuvé l'arrêt de staging-web-03
Agent · avec permission d'écriture
Aujourd'hui, 16:05
Alerte d'exposition envoyée au canal
Notification · aucun changement dans le cloud

Secrets

Les secrets de la plateforme (signature des jetons d'API, paiements, vérification anti-robots) sont dans AWS Systems Manager Parameter Store en SecureString et sont lus à l'exécution. Les clés Jira et Linear que vous configurez sont stockées dans DynamoDB, chiffré avec notre clé KMS, et l'interface ne les affiche que masquées.

Rotation de la clé maître
AWS fait tourner la clé KMS chaque année
Chiffrement au repos
Parameter Store SecureString et tables chiffrées avec KMS
Sans variables d'env
Chargées en runtime via SDK

Connectez votre compte avec les règles à vue

Lecture à la connexion. Écriture seulement si vous accordez le rôle des agents. Pour voir ce qui est ouvert dans vos comptes, c'est sous Sécurité.

Commencer gratuitement maintenant

Sans carte · Lecture à la connexion · Écriture si vous l'accordez