Intégrations

Microsoft Entra ID

Combien de personnes détiennent le rôle d'administrateur général, si des comptes invités existent, et si l'authentification multifacteur est réellement exigée pour se connecter.

Ce qui est vérifié

• Les administrateurs généraux sont peu nombreux et identifiés
• Les comptes invités externes sont connus
• L'authentification multifacteur est exigée pour se connecter, par les paramètres de sécurité par défaut ou une stratégie d'accès conditionnel activée
• Administrateur général est activé au besoin, pas détenu en permanence
• L'authentification héritée est bloquée
• Les rôles d'annuaire sont couverts par une politique MFA
• Une politique exige un appareil conforme ou joint
• Aucun compte activé n'est resté 90 jours sans connexion
• Les secrets et certificats d'application durent deux ans au plus
• Les invitations d'invités sont restreintes et les invités voient peu
• Chaque administrateur a un second facteur enregistré

Ce que l'identifiant peut voir

• Directory.Read.All
• Policy.Read.All
• RoleManagement.Read.Directory

Un administrateur approuve une fois les autorisations de lecture listées sur l'écran de consentement de Microsoft ; seul l'identifiant de votre tenant est conservé, et chaque exécution se connecte avec les identifiants propres de notre application. Chaque autorisation est une autorisation de lecture, rien ne peut donc changer dans le tenant.

Preuve pour

• A.5.15
• A.5.16
• A.5.17
• A.5.18
• A.8.1
• A.8.2
• A.8.5
• A.8.18
• A.8.24

Okta

Vos personnes, pour tenir le registre du personnel à jour, et les états de compte qui signifient que quelqu'un n'a jamais été complètement intégré ou complètement retiré.

Ce qui est vérifié

• Les utilisateurs de l'annuaire sont synchronisés dans le registre du personnel, et quiconque est actif ici mais a disparu d'Okta est nommé
• Aucun compte n'est bloqué à mi-chemin de son intégration
• Les comptes suspendus sont identifiés
• Les comptes verrouillés sont visibles
• Super Administrator est détenu par quelques personnes nommées
• Aucun compte actif n'est resté 90 jours sans connexion
• Chaque super administrateur a un facteur actif enregistré
• Les rôles d'administrateur sont détenus par peu de comptes

Ce que l'identifiant peut voir

• okta.users.read
• okta.roles.read

Un jeton d'API en lecture seule. Il hérite des droits de l'administrateur qui le crée, il est donc créé en tant qu'administrateur en lecture seule.

Preuve pour

• A.5.11
• A.5.16
• A.5.18
• A.8.2
• A.8.5
• A.8.15
• A.8.18

Google Workspace

Vos personnes, pour tenir le registre du personnel à jour, puis la validation en deux étapes sur tout le domaine et qui détient le rôle de super-administrateur.

Ce qui est vérifié

• Les utilisateurs de l'annuaire sont synchronisés dans le registre du personnel, et quiconque est actif ici mais a disparu de Workspace est nommé
• La validation en deux étapes est activée sur tout le domaine
• Les super-administrateurs sont peu nombreux et utilisent tous la validation en deux étapes
• Les comptes suspendus sont identifiés
• Aucun compte actif n'est resté 90 jours sans connexion
• La validation en deux étapes est imposée, pas seulement activée
• Les rôles d'administrateur sont détenus par peu de comptes

Ce que l'identifiant peut voir

• https://www.googleapis.com/auth/admin.directory.user.readonly

Un administrateur se connecte et approuve l'unique portée d'annuaire en lecture seule sur l'écran de consentement de Google ; les vérifications lisent l'annuaire en tant que cet administrateur et ne peuvent rien y changer. Ni compte de service, ni fichier de clé.

Preuve pour

• A.5.11
• A.5.16
• A.5.17
• A.5.18
• A.8.2
• A.8.5

Personio

Vos personnes depuis le système RH, pour tenir le registre du personnel à jour : qui est actif, en congé ou en intégration, et qui est parti.

Ce qui est vérifié

• Les utilisateurs de l'annuaire sont synchronisés dans le registre du personnel, et tout partant dans Personio encore actif ici est nommé
• Le système RH est la source du registre du personnel
• Chaque départ porte une date de fin
• Aucun emploi actif n'a dépassé sa date de fin de contrat
• Chaque emploi actif nomme un responsable

Ce que l'identifiant peut voir

• personio:persons:read

Une intégration personnalisée sous Marketplace, Intégrations connectées, avec l'unique portée de lecture des personnes. L'API de Personio ne prend pas de sous-domaine ; l'identifiant désigne l'entreprise, et rien ici n'écrit dans un dossier RH.

Preuve pour

• A.5.2
• A.5.18
• A.6.5
• A.8.2

Amazon Web Services

MFA et clés d'accès du compte racine, utilisateurs de la console sans MFA, âge des clés d'accès, stratégie de mots de passe du compte, blocage de l'accès public S3 au niveau du compte, couverture CloudTrail, chiffrement RDS, rétention des sauvegardes et Multi-AZ, si un enregistreur AWS Config tourne, si une instance EC2 tourne dans le VPC par défaut, et si GuardDuty est activé.

Ce qui est vérifié

• Le compte racine a l'authentification multifacteur
• Le compte racine n'a aucune clé d'accès
• Toute personne ayant accès à la console utilise l'authentification multifacteur
• Les clés d'accès ont été renouvelées dans les 90 jours
• Une stratégie de mots de passe est définie sur le compte
• L'accès public S3 est bloqué pour tout le compte
• L'activité de l'API est journalisée dans toutes les régions
• Les bases de données sont chiffrées au repos dans la région que vous nommez
• Les bases de données conservent des sauvegardes automatiques au moins une semaine
• Les bases de données survivent à la perte d'une zone de disponibilité
• La configuration des ressources est enregistrée en continu
• Aucune charge de travail ne tourne dans le VPC par défaut
• La détection des menaces est activée
• L'accès administratif complet passe par des rôles, pas par des utilisateurs permanents
• Les instances gérées exécutent un service de synchronisation horaire
• Aucun mot de passe de console ni clé d'accès ne reste inutilisé 90 jours
• Le compte root n'est pas utilisé pour le travail quotidien
• Les nouveaux volumes EBS sont chiffrés par défaut
• Aucun groupe de sécurité n'ouvre SSH, RDP ou un port de base de données à Internet
• Chaque VPC enregistre des journaux de flux
• Les clés KMS gérées par le client tournent automatiquement
• IAM Access Analyzer surveille les ressources partagées hors du compte
• Un plan de sauvegarde est planifié
• Les alarmes CloudWatch portent une action qui atteint quelqu'un
• Les images de conteneurs sont analysées à l'envoi pour les vulnérabilités connues
• AWS dispose d'un contact sécurité à qui écrire
• La capacité est surveillée
• Un plan de sauvegarde copie vers une autre région ou un autre coffre

Ce que l'identifiant peut voir

• arn:aws:iam::aws:policy/SecurityAudit

Un utilisateur IAM détenant une seule stratégie gérée par AWS, SecurityAudit, en lecture seule par construction. Nommer la stratégie plutôt que lister des actions signifie que personne n'assemble une stratégie trop large en devinant, et vous pouvez vérifier que c'est celle qu'AWS publie.

Preuve pour

• A.5.5
• A.5.6
• A.5.7
• A.5.10
• A.5.15
• A.5.16
• A.5.17
• A.5.18
• A.5.23
• A.5.28
• A.5.29
• A.5.30
• A.5.33
• A.6.8
• A.8.2
• A.8.3
• A.8.5
• A.8.6
• A.8.8
• A.8.9
• A.8.12
• A.8.13
• A.8.14
• A.8.15
• A.8.16
• A.8.17
• A.8.18
• A.8.20
• A.8.21
• A.8.22
• A.8.24
• A.8.29

Microsoft Azure

Comptes de stockage autorisant l'accès public aux blobs ou le HTTP en clair, bases SQL sans chiffrement transparent des données, leur rétention de sauvegarde et leur redondance de zone, abonnements dont le journal d'activité n'est expédié nulle part de durable, groupes de sécurité réseau ouvrant SSH ou RDP à Internet, stratégies de cycle de vie du stockage, et quels plans Defender pour le cloud sont actifs.

Ce qui est vérifié

• Les comptes de stockage n'autorisent pas l'accès public aux blobs
• Les comptes de stockage exigent HTTPS et TLS 1.2 ou ultérieur
• Les bases SQL sont chiffrées au repos
• Les bases SQL conservent des sauvegardes à un instant donné au moins une semaine
• Les bases SQL survivent à la perte d'une zone de disponibilité
• L'activité de l'abonnement est journalisée quelque part de durable
• Aucun groupe de sécurité réseau n'ouvre SSH ou RDP à Internet
• Les comptes de stockage ont une stratégie de cycle de vie pour les données vieillissantes
• Defender pour le cloud surveille au moins un type de ressource
• Les Key Vaults ont la suppression réversible et la protection contre la purge
• Les comptes de stockage conservent un temps les blobs supprimés
• Les serveurs SQL auditent les accès
• Aucune règle de pare-feu SQL n'admet tout Internet
• Les groupes de sécurité réseau enregistrent des journaux de flux
• Defender for Cloud a un contact sécurité à notifier
• Azure Policy est affecté sur chaque abonnement
• Un coffre Recovery Services sauvegarde quelque chose

Ce que l'identifiant peut voir

• Reader (Azure role, on each subscription in scope)

L'inscription d'application Entra ID, dotée du rôle intégré Lecteur sur chaque abonnement à lire. Lecteur est en lecture seule par construction, attribué par abonnement, et la même inscription connecte déjà Entra ID et Intune.

Preuve pour

• A.5.5
• A.5.6
• A.5.7
• A.5.10
• A.5.28
• A.5.33
• A.5.36
• A.6.8
• A.8.9
• A.8.10
• A.8.12
• A.8.13
• A.8.14
• A.8.15
• A.8.16
• A.8.20
• A.8.22
• A.8.24

Google Cloud

Buckets lisibles par le public, instances Cloud SQL sans TLS ou ouvertes à Internet, clés de compte de service à renouveler, journalisation d'audit des accès aux données par projet, et règles de pare-feu ouvrant SSH ou RDP au monde entier, ainsi que si chaque instance Cloud SQL effectue des sauvegardes automatiques et s'étend sur plusieurs zones, et si chaque bucket a une règle de cycle de vie.

Ce qui est vérifié

• Aucun bucket Cloud Storage n'est lisible par le public
• Les instances Cloud SQL exigent TLS et ne sont pas ouvertes à Internet
• Les instances Cloud SQL effectuent des sauvegardes automatiques
• Les instances Cloud SQL survivent à la perte d'une zone
• Les buckets Cloud Storage ont une règle de cycle de vie pour les données vieillissantes
• Les clés de compte de service ont été renouvelées dans les 90 jours
• Les journaux d'audit des accès aux données sont activés pour tous les services
• Aucune règle de pare-feu n'ouvre SSH ou RDP à Internet
• Les buckets Cloud Storage conservent les versions des objets
• Les buckets Cloud Storage utilisent l'accès uniforme au niveau du bucket
• Les instances Cloud SQL sont protégées contre la suppression
• Aucune personne ne détient le rôle de base Owner ou Editor
• Aucune machine virtuelle n'a d'adresse publique
• Les sous-réseaux enregistrent des journaux de flux
• Aucun projet ne conserve le réseau par défaut en mode automatique
• Les clés Cloud KMS tournent selon un calendrier
• Google a un contact sécurité pour chaque projet

Ce que l'identifiant peut voir

• roles/iam.securityReviewer (project role)

Une clé de compte de service avec le rôle intégré Security Reviewer sur chaque projet du périmètre. Le rôle est en lecture seule par construction, et chaque projet actif que le compte peut voir est lu ; rien ici n'écrit.

Preuve pour

• A.5.5
• A.5.6
• A.5.10
• A.5.15
• A.5.17
• A.5.18
• A.5.28
• A.6.8
• A.8.2
• A.8.3
• A.8.9
• A.8.10
• A.8.12
• A.8.13
• A.8.14
• A.8.15
• A.8.16
• A.8.20
• A.8.22
• A.8.24

GitHub

Si l'authentification à deux facteurs est exigée, quels dépôts sont publics, si les branches par défaut exigent une revue, combien de temps les alertes Dependabot restent ouvertes, si les fusions exigent des vérifications de statut réussies, et si les déploiements passent par un environnement protégé.

Ce qui est vérifié

• L'authentification à deux facteurs est exigée dans toute l'organisation, ou activée sur le compte
• Les dépôts de code source sont privés
• Les branches par défaut exigent une revue avant fusion
• Les alertes Dependabot sont corrigées dans le délai de remédiation : 14 jours pour critique, 30 pour élevé, 90 pour moyen, 180 pour faible
• Les branches par défaut exigent des tests réussis avant fusion
• Les déploiements en production passent par un environnement protégé
• Chaque dépôt nomme ses propriétaires de code et exécute un workflow à chaque changement
• Personne hors de l'organisation ne peut pousser sans accord

Ce que l'identifiant peut voir

• read:org
• repo (read-only)
• security_events (read-only)
• read:user

Une GitHub App que vous installez sur votre organisation depuis l'écran de GitHub, avec les autorisations en lecture seule listées ; rien n'est collé. Chaque exécution demande à GitHub un jeton valable une heure, aucun jeton à vous n'est donc stocké.

Preuve pour

• A.5.17
• A.5.19
• A.5.20
• A.8.4
• A.8.5
• A.8.8
• A.8.25
• A.8.28
• A.8.29
• A.8.30
• A.8.31
• A.8.32

Snyk

Les problèmes ouverts mesurés contre vos délais de remédiation, si chaque projet est réellement analysé, et si le dernier test d'un projet est trop ancien pour signifier quoi que ce soit.

Ce qui est vérifié

• Les résultats ouverts sont corrigés dans le délai de remédiation : 14 jours pour critique, 30 pour élevé, 90 pour moyen, 180 pour faible
• Chaque projet a été testé, de sorte qu'un projet sans résultat est un projet analysé et non un projet sauté
• Chaque projet a été testé dans les 30 derniers jours
• Aucun secret n'est commité dans un dépôt analysé
• Les problèmes élevés et critiques ignorés sont décidés, pas oubliés
• Les pull requests sont testées avant la fusion

Ce que l'identifiant peut voir

• Viewer (read-only)

Un jeton d'API d'un compte détenant le rôle Viewer sur l'organisation. Rien ici n'écrit.

Preuve pour

• A.5.17
• A.8.8
• A.8.28
• A.8.29

Kandji

Chiffrement du disque et verrouillage de l'écran sur votre parc Apple, et quels appareils ont cessé de se signaler. Lu depuis le MDM que vous exploitez déjà, sans aucun agent de notre part.

Ce qui est vérifié

• Les appareils gérés sont chiffrés au repos
• Les appareils gérés se verrouillent sans surveillance
• Les appareils gérés se sont signalés dans les 30 jours
• Les Mac gérés ont un verrou de récupération ou un mot de passe de firmware
• Les appareils gérés sont supervisés, la gestion ne peut donc pas être retirée
• Les Mac gérés ne portent pas plus d'un administrateur local

Ce que l'identifiant peut voir

• Device List (read)
• Device Details (read)

Un jeton d'API limité, dans les propres paramètres de Kandji, aux deux autorisations de lecture des appareils. Rien ici n'écrit.

Preuve pour

• A.5.9
• A.6.7
• A.7.7
• A.7.9
• A.8.1
• A.8.2
• A.8.7
• A.8.9
• A.8.24

Jamf Pro

FileVault, verrouillage de l'écran et Gatekeeper sur votre parc Mac, et quels appareils ont cessé de se signaler. Lu depuis le MDM que vous exploitez déjà, sans aucun agent de notre part.

Ce qui est vérifié

• Les appareils gérés sont chiffrés au repos, un Mac ne comptant comme chiffré que lorsque chaque compte qu'il héberge l'est
• Les appareils gérés se verrouillent sans surveillance
• Les appareils gérés exécutent une protection des terminaux, lue depuis Gatekeeper
• Les appareils gérés se sont signalés dans les 30 jours
• Les Mac gérés exécutent le pare-feu applicatif
• Aucun Mac géré n'ouvre une session automatiquement au démarrage
• La protection de l'intégrité du système et le démarrage sécurisé complet sont actifs

Ce que l'identifiant peut voir

• Read Computers
• Read Computer Inventory Collection

Un client d'API avec un rôle d'API détenant exactement deux privilèges de lecture, échangé contre un jeton de courte durée. Pas le nom d'utilisateur et le mot de passe de l'API classique, qui seraient un identifiant capable aussi d'effacer un ordinateur portable.

Preuve pour

• A.5.9
• A.6.7
• A.7.7
• A.7.9
• A.8.1
• A.8.5
• A.8.7
• A.8.9
• A.8.19
• A.8.20
• A.8.24

Microsoft Intune

Chiffrement du disque sur vos appareils gérés et lesquels ont cessé de se synchroniser. La même inscription d'application qu'Entra ID, avec une autorisation de lecture supplémentaire.

Ce qui est vérifié

• Les appareils gérés sont chiffrés au repos
• Les appareils gérés se sont signalés dans les 30 jours
• Les appareils gérés respectent leurs stratégies de conformité
• Aucun appareil géré n'est jailbreaké ni rooté
• Un partenaire de défense contre les menaces signale chaque appareil géré comme sûr

Ce que l'identifiant peut voir

• DeviceManagementManagedDevices.Read.All

L'inscription d'application Entra ID avec une autorisation d'application supplémentaire, consentie une fois. Un client qui a connecté Entra ajoute l'autorisation et connecte ceci avec le même ID client et le même secret.

Preuve pour

• A.5.9
• A.6.7
• A.7.7
• A.7.9
• A.8.1
• A.8.7
• A.8.8
• A.8.9
• A.8.19
• A.8.24