Controle d'acces ISO 27001 : exigences, mesures et mise en oeuvre SaaS

Le controle d’acces est la pratique consistant a s’assurer que seules les personnes autorisees peuvent acceder a des informations, systemes et ressources specifiques — et uniquement dans la mesure ou leur role l’exige. Dans ISO 27001, le controle d’acces couvre plusieurs mesures de l’Annex A et touche pratiquement chaque aspect des operations d’une entreprise SaaS, de l’integration des employes a l’administration des bases de donnees de production en passant par l’authentification des API exposees aux clients.

Pour les entreprises SaaS, le controle d’acces est simultanement le domaine le plus important et le plus complexe a maitriser. Votre produit fonctionne sur une infrastructure cloud geree par des equipes distribuees. Les ingenieurs ont besoin d’acceder aux systemes de production. Les equipes de succes client ont besoin d’acceder aux donnees clients pour le support. Les integrations tierces ont besoin d’identifiants API. Les pipelines CI/CD ont besoin de cles de deploiement. Chacun de ces chemins d’acces doit etre gouverne, surveille et revu.

Ce guide couvre chaque exigence de controle d’acces ISO 27001, les mesures specifiques de l’Annex A qui s’appliquent et des conseils pratiques de mise en oeuvre pour les entreprises SaaS operant sur des plateformes cloud modernes.

Mesures pertinentes de l’Annex A

ISO 27001:2022 a reorganise ses mesures en quatre themes : Organisationnel, Personnel, Physique et Technologique. Le controle d’acces couvre les themes Organisationnel et Technologique. Comprendre quelles mesures s’appliquent — et ce que chacune exige — est le fondement de votre politique de controle d’acces.

Mesures organisationnelles

A.5.15 — Controle d’acces La mesure globale. Elle exige que des regles regissant l’acces a l’information et aux autres actifs associes soient etablies et mises en oeuvre en fonction des exigences commerciales et de securite de l’information. C’est votre politique de controle d’acces — le document qui definit les principes (moindre privilege, besoin d’en connaitre, RBAC) que toutes les autres mesures de controle d’acces mettent en oeuvre.

A.5.16 — Gestion des identites Le cycle de vie complet des identites des utilisateurs doit etre gere. Cela couvre la creation, la maintenance et la suppression des identites numeriques. Pour les entreprises SaaS, cela signifie gerer les identites a travers votre fournisseur d’identite (Okta, Azure AD, Google Workspace), les plateformes cloud, les outils SaaS et les applications internes.

A.5.17 — Informations d’authentification Gestion des informations d’authentification (mots de passe, jetons, certificats, cles) tout au long de leur cycle de vie. Cela inclut l’allocation initiale, le stockage securise, la rotation et la revocation. La mesure exige que les informations d’authentification ne soient pas partagees entre individus et que les identifiants par defaut soient changes immediatement lors du provisionnement.

A.5.18 — Droits d’acces Les droits d’acces doivent etre provisionnes, revus, modifies et supprimes conformement a la politique de controle d’acces. C’est la mesure operationnelle qui met en oeuvre votre modele RBAC. Elle exige un processus defini pour accorder l’acces, un mecanisme pour ajuster l’acces lors des changements de role et un processus defini pour revoquer l’acces lorsqu’il n’est plus necessaire.

Mesures technologiques

A.8.2 — Droits d’acces privilegie L’acces privilegie (comptes administrateur, acces root, superutilisateur de base de donnees) doit etre restreint et controle. Cette mesure exige une autorisation explicite pour l’acces privilegie, la separation des comptes privilegies et des comptes utilisateurs standard, la journalisation des actions privilegiees et la revue periodique des droits d’acces privilegies.

A.8.3 — Restriction d’acces a l’information L’acces a l’information doit etre restreint conformement a la politique de controle d’acces. Cela se traduit par une mise en application technique : controles d’acces aux bases de donnees, regles d’autorisation des applications, permissions du systeme de fichiers, segmentation reseau empechant les chemins d’acces non autorises.

A.8.4 — Acces au code source L’acces en lecture et en ecriture au code source, aux outils de developpement et aux configurations logicielles doit etre controle. Pour les entreprises SaaS, cela signifie la gestion de l’acces aux depots, les regles de protection des branches et les exigences de revue de code.

A.8.5 — Authentification securisee Les mecanismes d’authentification doivent etre adaptes a la sensibilite des systemes et des donnees auxquels on accede. C’est la que les exigences d’authentification multi-facteurs (MFA), d’authentification unique (SSO), d’authentification sans mot de passe et de gestion de session entrent en jeu.

Construire votre politique de controle d’acces

Votre politique de controle d’acces est le document fondateur qui definit les principes, attribue les responsabilites et fixe les exigences que toutes les procedures et mesures techniques subsequentes mettent en oeuvre. Elle doit etre concise, specifique a votre organisation et testable. Pour des conseils sur la structure et la redaction des politiques, consultez notre guide des politiques ISO 27001.

Principes fondamentaux

Toute politique de controle d’acces devrait etablir ces principes :

Principe du moindre privilege. Les utilisateurs se voient accorder les droits d’acces minimaux necessaires pour exercer leurs fonctions. L’acces n’est pas accorde par defaut — il doit etre explicitement demande, justifie et approuve.

Besoin d’en connaitre. L’acces a l’information est restreint aux individus qui en ont besoin pour leur role specifique. Avoir une habilitation de securite ou un grade eleve ne confere pas automatiquement l’acces a toute l’information a ce niveau.

Separation des fonctions. Les fonctions critiques sont reparties entre plusieurs individus pour empecher qu’une seule personne ait un controle de bout en bout sur un processus sensible. En termes SaaS : la personne qui ecrit le code ne devrait pas etre le seul approbateur de ses propres deploiements en production.

Refus par defaut. L’acces est refuse par defaut et explicitement accorde selon les besoins. Cela s’applique aux regles reseau, aux permissions des applications, aux politiques IAM cloud et a l’acces aux depots.

Perimetre de la politique

Definissez exactement ce que la politique de controle d’acces couvre :

• Tous les systemes et environnements de production
• Toute l’infrastructure cloud (comptes et ressources AWS, Azure, GCP)
• Toutes les applications d’entreprise (messagerie, outils de collaboration, systemes RH)
• Tous les depots de code source
• Toutes les bases de donnees contenant des donnees clients ou organisationnelles
• Tous les outils SaaS tiers dans le perimetre du ISMS
• Tous les comptes de service, cles API et identites machines
• Tous les comptes employes, sous-traitants et utilisateurs tiers

Soyez explicite sur ce qui est hors perimetre. Si vous avez des environnements de developpement sandbox intentionnellement exclus du ISMS, indiquez-le clairement.

Provisionnement et desapprovisionnement des utilisateurs

Le cycle de vie des acces — de l’octroi de l’acces initial a sa revocation lorsqu’il n’est plus necessaire — est la ou le controle d’acces fonctionne ou echoue. Les auditeurs testent cela rigoureusement car les erreurs de provisionnement et de desapprovisionnement sont la source la plus courante de droits d’acces excessifs.

Processus de provisionnement

Un processus de provisionnement bien defini comprend :

1. Demande d’acces. Tout acces doit etre formellement demande. La demande doit specifier quel acces est necessaire, pourquoi et pour combien de temps. Pour les entreprises SaaS, cela signifie generalement un ticket dans votre outil de gestion de projet (Jira, Linear, Asana) ou une demande via votre plateforme de gestion des identites.

2. Autorisation. La demande doit etre approuvee par quelqu’un ayant l’autorite d’accorder cet acces — generalement le manager de l’employe et/ou le proprietaire du systeme. L’approbation doit etre documentee (pas un « bien sur, vas-y » verbal).

3. Mise en oeuvre. L’acces est provisionne conformement a la demande approuvee, en utilisant des roles predefinis autant que possible plutot que des permissions personnalisees. La personne mettant en oeuvre l’acces doit verifier que ce qui a ete provisionne correspond a ce qui a ete approuve.

4. Verification. Apres le provisionnement, verifiez que l’utilisateur a le bon acces — ni plus ni moins que ce qui a ete approuve.

5. Documentation. L’enregistrement complet — demande, approbation, mise en oeuvre et verification — doit etre conserve a des fins d’audit.

Mise en oeuvre SaaS : Utilisez votre fournisseur d’identite (Okta, Azure AD, Google Workspace) comme hub central d’acces. Definissez des politiques d’acces basees sur les groupes ou l’ajout d’un utilisateur a un groupe provisionne automatiquement le bon acces a travers les applications connectees. L’integration d’un nouvel employe declenche un flux automatise : les RH creent le dossier de l’employe, le fournisseur d’identite cree le compte et les appartenances aux groupes provisionnent l’acces en fonction du departement et du role.

Controle d’acces base sur les roles (RBAC)

Le RBAC est le modele de gestion des acces le plus pratique pour les entreprises SaaS. Au lieu de gerer les permissions utilisateur par utilisateur, vous definissez des roles qui correspondent aux fonctions professionnelles et attribuez les utilisateurs aux roles.

Definir les roles en fonction des fonctions professionnelles :

• Ingenierie — Developpeur : Acces lecture/ecriture aux depots assignes, acces lecture aux environnements de staging, pas d’acces a la production
• Ingenierie — Developpeur senior : Meme acces que Developpeur plus acces lecture aux journaux et metriques de production
• Ingenierie — DevOps/SRE : Meme acces que Developpeur senior plus acces ecriture aux depots d’infrastructure-as-code et capacites de deploiement en production
• Succes client : Acces lecture aux donnees clients dans le portail de support, pas d’acces direct a la base de donnees
• Finance : Acces aux systemes de facturation, pas d’acces aux systemes d’ingenierie
• Direction : Acces aux tableaux de bord et rapports, pas d’acces direct aux systemes

Principes RBAC pour le SaaS :

• Gardez les roles suffisamment granulaires pour appliquer le moindre privilege mais pas si granulaires que vous ayez un role unique par personne
• Documentez les droits d’acces de chaque role et revoyez-les quand les fonctions professionnelles evoluent
• Utilisez l’acces base sur les groupes dans votre fournisseur d’identite pour mettre en oeuvre techniquement le RBAC
• Quand quelqu’un change de role, revoquez l’acces de l’ancien role et provisionnez l’acces du nouveau role — n’accumulez pas les permissions

Processus de desapprovisionnement

Le desapprovisionnement est le domaine le plus risque du controle d’acces. Un ancien employe ou sous-traitant avec des identifiants actifs constitue un risque de securite serieux et une constatation d’audit garantie.

Declencheurs immediats de desapprovisionnement :

• Fin de contrat d’un employe (volontaire ou involontaire)
• Fin de mission d’un sous-traitant
• Fin d’une relation avec un tiers
• Transfert d’un employe vers un role qui ne necessite pas l’acces actuel

Delai de desapprovisionnement requis : Votre politique doit specifier un delai maximum entre l’evenement declencheur et la suppression de l’acces. Pour les entreprises SaaS, l’attente standard est :

• Depart involontaire : Acces revoque avant ou au moment ou l’employe est notifie, dans le meme jour ouvrable
• Depart volontaire : Acces revoque avant la fin du dernier jour de travail de l’employe
• Changements de role : Acces du role precedent revoque dans les 5 jours ouvrables suivant la date d’effet du changement de role
• Fin de mission sous-traitant : Acces revoque le dernier jour de la mission

Mise en oeuvre SaaS : Integrez votre systeme RH avec votre fournisseur d’identite. Quand les RH traitent un depart, le fournisseur d’identite desactive automatiquement le compte et revoque tous les acces aux applications connectees. Pour les systemes non connectes au fournisseur d’identite (outils anciens, environnements specifiques aux clients), maintenez une checklist de desapprovisionnement et verifiez l’achevement.

Etape critique souvent manquee : Les comptes de service, les identifiants partages et les cles SSH associes a la personne sortante. Si un ancien ingenieur avait acces aux cles SSH de production, ces cles doivent etre tournees. S’il a contribue a des identifiants de comptes de service partages, ces identifiants doivent etre changes. Documentez cela dans votre procedure de desapprovisionnement.

Acces lors d’un changement de role

Les changements de role sont une source significative d’accumulation d’acces — l’accumulation progressive de permissions a mesure que les employes changent d’equipe sans que les anciennes permissions soient revoquees. Au fil du temps, une personne qui a commence en support d’ingenierie et est passee par l’assurance qualite puis la gestion de produit pourrait conserver l’acces des trois roles.

Prevenir l’accumulation d’acces en :

• Traitant les transferts internes comme un evenement de desapprovisionnement/reprovisionnement
• Comparant l’acces actuel de l’utilisateur aux droits d’acces definis du role cible
• Supprimant l’acces qui n’est pas requis pour le nouveau role
• Documentant le changement d’acces avec la meme rigueur que le provisionnement initial

Gestion des acces privilegies

L’acces privilegie — les comptes administrateurs avec des permissions elevees — est la categorie d’acces la plus sensible et fait l’objet du plus grand examen lors des audits ISO 27001. La mesure A.8.2 cible specifiquement l’acces privilegie.

Ce qui constitue un acces privilegie dans le SaaS

• Administrateurs de plateforme cloud : Compte root AWS, administrateurs IAM, administrateurs globaux Azure, administrateurs d’organisation GCP
• Administrateurs de bases de donnees : Superutilisateurs de bases de donnees de production, utilisateurs avec des capacites d’export de donnees
• Gestion de l’infrastructure : Administrateurs de clusters Kubernetes, administrateurs reseau
• Administrateurs du fournisseur d’identite : Super administrateurs Okta, administrateurs globaux Azure AD
• Administrateurs d’applications : Roles d’administration dans les outils SaaS pouvant voir toutes les donnees ou modifier les parametres de securite
• Acces au pipeline CI/CD : Comptes pouvant deployer en production, modifier les configurations de pipeline ou acceder aux secrets de deploiement

Mesures de controle des acces privilegies

Separer les comptes privilegies et les comptes standard. Les administrateurs doivent avoir un compte standard pour le travail quotidien (messagerie, Slack, documents) et un compte privilegie distinct pour les taches administratives. Cela reduit le rayon d’impact si le compte d’usage quotidien est compromis.

Exiger une authentification plus forte pour l’acces privilegie. Si le MFA est requis pour l’acces standard, l’acces privilegie devrait exiger des cles de securite materielles (FIDO2/WebAuthn) plutot que les SMS ou le TOTP. Envisagez d’exiger une reauthentification pour les operations sensibles meme au sein d’une session authentifiee.

Mettre en oeuvre l’acces juste-a-temps (JIT). Au lieu d’un acces privilegie permanent, accordez des permissions elevees temporaires lorsqu’elles sont necessaires pour une tache specifique, avec revocation automatique apres une periode definie.

Mise en oeuvre SaaS : Utilisez des outils comme AWS IAM Identity Center (anciennement SSO) avec des limites de duree de session, HashiCorp Vault pour les secrets dynamiques ou des solutions PAM dediees. Quand un ingenieur a besoin d’un acces a la base de donnees de production pour une session de debogage, il demande un acces JIT via un flux de travail qui accorde des identifiants temporaires de 2 a 4 heures et journalise toutes les activites pendant cette fenetre.

Journaliser toutes les actions privilegiees. Chaque action effectuee avec des identifiants privilegies doit etre journalisee, et ces journaux doivent etre proteges contre la modification par les utilisateurs privilegies eux-memes. Envoyez les journaux vers un SIEM centralise ou un systeme de gestion des journaux ou ils peuvent etre examines.

Revoir l’acces privilegie trimestriellement. L’acces privilegie devrait etre revu plus frequemment que l’acces standard. Les revues trimestrielles sont l’attente minimale. Lors de chaque revue, verifiez que chaque compte privilegie est toujours necessaire, que le niveau d’acces est toujours approprie et que le proprietaire du compte est toujours employe et dans un role qui necessite un acces privilegie.

Le probleme du compte root AWS

Chaque compte AWS a un utilisateur root avec un acces illimite. C’est une preoccupation courante lors des audits.

Bonnes pratiques :

• Activez le MFA sur le compte root en utilisant une cle de securite materielle
• N’utilisez pas le compte root pour les operations quotidiennes
• Stockez les identifiants du compte root dans un emplacement physique securise (coffre-fort ou chambre forte securisee)
• Journalisez et alertez sur toute utilisation du compte root via CloudTrail
• Documentez les circonstances dans lesquelles l’acces au compte root est permis (generalement limite aux actions au niveau du compte que seul root peut effectuer)

Authentification multi-facteurs et authentification unique

Exigences MFA

La mesure A.8.5 exige une authentification securisee adaptee a la sensibilite du systeme accede. Pour les entreprises SaaS, cela se traduit par des exigences MFA dans tout l’environnement.

Ou le MFA devrait etre applique :

• Tous les acces au fournisseur d’identite (non negociable)
• Tous les acces aux consoles de plateforme cloud (AWS, Azure, GCP)
• Tous les acces aux environnements de production
• Toutes les connexions VPN
• Tous les acces aux depots de code
• Tous les acces aux comptes privilegies
• Tous les acces administratifs aux outils SaaS

Hierarchie de robustesse du MFA :

1. Cles de securite materielles (FIDO2/WebAuthn) : Plus resistantes au phishing. Requises pour l’acces privilegie.
2. Applications d’authentification (TOTP) : Acceptables pour l’acces standard. Exemples : Google Authenticator, Authy, 1Password.
3. Notifications push : Acceptables mais vulnerables aux attaques de fatigue MFA. Utilisez la correspondance de numeros si disponible.
4. Codes SMS : Forme la plus faible. Vulnerable au detournement de carte SIM. A eviter pour l’acces aux systemes de production.

Recommandation de politique : Exigez le MFA par application d’authentification au minimum pour tous les acces. Exigez les cles de securite materielles pour l’acces privilegie et l’acces aux systemes contenant des donnees clients.

Authentification unique (SSO)

Le SSO centralise l’authentification via votre fournisseur d’identite et est le moyen le plus efficace d’appliquer des politiques de controle d’acces coherentes dans votre ecosysteme d’outils SaaS.

Avantages pour la conformite ISO 27001 :

• Journaux d’authentification centralises pour toutes les applications connectees
• Application coherente du MFA sur tous les systemes
• Desapprovisionnement simplifie — desactivez le compte IdP et tous les acces connectes sont revoques
• Reduction de la fatigue liee aux mots de passe et des risques de securite associes

Priorites de mise en oeuvre SSO pour les entreprises SaaS :

1. Premier : Acces a la plateforme cloud (AWS IAM Identity Center, Azure AD, GCP Cloud Identity)
2. Deuxieme : Depots de code (GitHub, GitLab, Bitbucket)
3. Troisieme : Outils CI/CD (Jenkins, CircleCI, GitHub Actions)
4. Quatrieme : Outils de communication (Slack, Microsoft Teams)
5. Cinquieme : Tous les outils SaaS restants qui supportent le SSO

La realite de la « taxe SSO » : De nombreux fournisseurs SaaS facturent un prix premium pour l’integration SSO. Budgetisez cela lors de la planification de votre mise en oeuvre ISO 27001. Le cout du SSO est justifie par les benefices de conformite et l’efficacite operationnelle de la gestion centralisee des acces.

Applications qui ne supportent pas le SSO : Maintenez un inventaire documente des applications qui ne peuvent pas etre connectees au SSO. Celles-ci necessitent une gestion de compte individuelle, une application separee du MFA et devraient etre prioritaires dans les checklists de desapprovisionnement car elles ne seront pas automatiquement revoquees lorsque le compte IdP est desactive.

Revues d’acces

La mesure A.5.18 exige que les droits d’acces soient revus a intervalles definis. Les revues d’acces sont un point de controle essentiel de l’audit — les auditeurs demanderont des preuves que les revues ont ete completees dans les delais et que les constatations ont ete remediees.

Frequence des revues

Trimestrielle : Acces privilegie, acces aux environnements de production et acces aux systemes contenant des donnees clients sensibles. C’est la cadence minimale attendue par les auditeurs pour les acces a haut risque.

Semestrielle : Acces aux applications standard, acces aux depots de code et acces aux outils d’entreprise.

Annuelle : Acces a faible risque, systemes informationnels et plateformes de documentation interne.

Votre politique de controle d’acces doit specifier la frequence de revue pour chaque categorie. Ne fixez pas une frequence que vous ne pouvez pas maintenir — un cycle de revue manque est une constatation d’audit.

Comment mener les revues d’acces

Etape 1 : Generer les rapports d’acces. Exportez les listes d’utilisateurs actuels et leurs permissions de chaque systeme en revue. La plupart des fournisseurs d’identite peuvent generer des rapports consolides a travers les applications connectees.

Etape 2 : Distribuer aux examinateurs. Chaque systeme ou application devrait avoir un proprietaire designe qui examine l’acces pour ce systeme. En pratique, cela signifie souvent :

• Les responsables d’ingenierie examinent l’acces a l’infrastructure de production
• Les chefs d’equipe examinent l’acces applicatif de leur equipe
• L’equipe securite examine l’acces privilegie a travers tous les systemes

Etape 3 : Examiner chaque entree. Pour chaque combinaison utilisateur-acces, l’examinateur determine :

• Cette personne est-elle toujours employee ? (Verifier avec les registres RH)
• Son role actuel necessite-t-il cet acces ?
• Le niveau d’acces est-il approprie (pas excessif) ?
• Le compte est-il actif (a-t-il ete utilise recemment) ?

Etape 4 : Remedier aux constatations. Supprimez l’acces qui n’est plus necessaire. Diminuez les permissions excessives. Desactivez les comptes inactifs. Documentez chaque action de remediation.

Etape 5 : Documenter la revue. Conservez le rapport d’acces, les commentaires de l’examinateur, les actions de remediation et la date d’achevement. C’est la preuve que les auditeurs demanderont.

Mise en oeuvre SaaS : Construisez un flux de travail automatise de revue d’acces. Exportez les listes d’utilisateurs de votre fournisseur d’identite et des systemes connectes via API. Presentez-les dans un format structure (tableur, plateforme GRC ou outil personnalise) ou les examinateurs peuvent approuver, signaler ou revoquer chaque entree d’acces. Suivez le pourcentage d’achevement et envoyez des rappels aux examinateurs qui n’ont pas complete leurs revues avant la date limite.

Constatations courantes des revues d’acces

• Comptes orphelins : Comptes appartenant a d’anciens employes ou sous-traitants qui n’ont pas ete correctement desaprovisionnes
• Permissions excessives : Utilisateurs avec un acces au-dela de ce que leur role exige, souvent provenant de changements de role sans nettoyage des acces
• Comptes inactifs : Comptes actifs qui n’ont pas ete utilises depuis 60-90+ jours, suggerant que l’acces est inutile
• Comptes partages : Plusieurs individus utilisant les memes identifiants, violant les exigences de responsabilite et de piste d’audit
• MFA manquant : Comptes qui devraient avoir le MFA applique mais ne l’ont pas

Considerations specifiques au controle d’acces SaaS

Les entreprises SaaS font face a des defis de controle d’acces qui n’existent pas dans les environnements informatiques traditionnels. Vos politiques et procedures doivent les traiter explicitement.

Multi-locataire

Si votre produit est multi-locataire, le controle d’acces doit assurer une isolation stricte entre les locataires. C’est a la fois une exigence de securite et une question de confiance client.

Mesures a mettre en oeuvre :

• Isolation des locataires aux couches application, base de donnees et reseau
• Acces aux donnees clients restreint par contexte de locataire (un ingenieur deboguant le probleme d’un client ne devrait pas pouvoir acceder aux donnees d’un autre client)
• Journalisation d’audit de tous les acces inter-locataires
• Tests reguliers des limites d’isolation des locataires (a inclure dans le perimetre des tests de penetration)

Cles API et authentification service-a-service

Les produits SaaS exposent generalement des API contre lesquelles les clients et partenaires s’authentifient. La gestion de ces identifiants est une responsabilite de controle d’acces.

Gestion des cles API :

• Generez des cles API uniques par client ou integration, pas de cles partagees
• Supportez la rotation des cles sans interruption de service
• Mettez en oeuvre des politiques d’expiration des cles
• Journalisez toute utilisation de cle API et surveillez les comportements anormaux
• Fournissez aux clients la possibilite de revoquer et regenerer leurs propres cles
• N’integrez jamais de cles API dans le code source ou les applications cote client

Authentification service-a-service :

• Utilisez des jetons a courte duree de vie (OAuth 2.0, JWT) plutot que des identifiants a longue duree de vie lorsque possible
• Mettez en oeuvre le TLS mutuel (mTLS) pour la communication interne des services dans les contextes de haute securite
• Tournez les identifiants de service selon un calendrier defini
• Stockez les identifiants de service dans un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), pas dans des variables d’environnement ou des fichiers de configuration

Acces au pipeline CI/CD

Votre pipeline de deploiement a un acces de production par conception — il deploie du code, execute des migrations et gere l’infrastructure. Cela en fait une cible de haute valeur et un domaine critique de controle d’acces.

Mesures de controle d’acces CI/CD :

• Restreignez qui peut modifier les configurations de pipeline (traitez le pipeline-as-code avec les memes mesures que le code applicatif)
• Utilisez des identifiants a courte duree de vie et avec un perimetre limite pour le deploiement (federation OIDC avec AWS, jetons temporaires plutot que des secrets a longue duree de vie)
• Exigez des portes d’approbation pour les deploiements en production (au minimum, revue de code ; idealement, une approbation explicite de deploiement)
• Journalisez toutes les executions de pipeline avec des pistes d’audit completes
• Mettez en oeuvre des regles de protection des branches pour que seule la branche principale puisse declencher des deploiements en production
• Separez les identifiants de pipeline par environnement (le pipeline de staging ne devrait pas avoir les identifiants de production)

Acces aux donnees clients pour le support

Les ingenieurs de support et les equipes de succes client peuvent avoir besoin d’acceder aux donnees clients pour resoudre des problemes. Cet acces doit etre controle, justifie et journalise.

Modele d’acces d’urgence (break-glass) :

• Definissez des criteres clairs pour quand l’acces aux donnees clients est permis (par exemple, ticket de support actif du client)
• Exigez une approbation explicite pour chaque evenement d’acces (d’un chef d’equipe ou via un flux automatise)
• Accordez un acces a duree limitee (automatiquement revoque apres la session de support)
• Journalisez tout acces aux donnees pendant la session
• Anonymisez ou pseudonymisez les donnees dans les environnements hors production pour que le support puisse depanner sans voir les donnees clients reelles

Mise en oeuvre IAM cloud

Pour les entreprises SaaS operant sur les principales plateformes cloud, l’IAM cloud est le mecanisme principal de mise en oeuvre du controle d’acces au niveau de l’infrastructure.

AWS IAM

Structure des comptes : Utilisez AWS Organizations avec des comptes separes pour la production, le staging, le developpement et la securite/audit. Cela fournit des limites strictes au niveau du compte qui empechent les acces inter-environnements accidentels.

Bonnes pratiques IAM pour ISO 27001 :

• N’utilisez jamais le compte root pour les operations. Activez le MFA et restreignez son utilisation.
• Utilisez IAM Identity Center (anciennement SSO) pour federer l’acces depuis votre fournisseur d’identite
• Definissez des politiques IAM en suivant le moindre privilege — commencez sans permissions et ajoutez uniquement ce qui est necessaire
• Utilisez des roles IAM pour les applications et services, pas des utilisateurs IAM avec des cles d’acces a longue duree de vie
• Activez CloudTrail dans toutes les regions pour une journalisation d’audit complete
• Utilisez les Service Control Policies (SCP) pour appliquer des garde-fous a l’echelle de l’organisation
• Mettez en oeuvre des limites de permissions pour limiter les permissions maximales qu’une entite IAM peut avoir

Constatations d’audit AWS courantes :

• Utilisateurs IAM avec des politiques en ligne au lieu de politiques gerees attachees
• Cles d’acces qui n’ont pas ete tournees depuis 90+ jours
• Utilisateurs IAM avec acces a la console mais sans MFA
• Politiques trop permissives utilisant des jokers (par exemple, "Action": "*", "Resource": "*")
• CloudTrail non active dans toutes les regions

Azure IAM

Structure tenant et abonnement : Utilisez les groupes de gestion Azure et les abonnements pour separer les environnements. Azure AD (maintenant Entra ID) sert de fournisseur d’identite.

Mesures cles :

• Utilisez Azure AD Privileged Identity Management (PIM) pour l’acces privilegie JIT
• Mettez en oeuvre des politiques d’acces conditionnel pour l’authentification basee sur le risque
• Activez Azure AD Identity Protection pour la detection automatisee des risques
• Utilisez les identites gerees pour les ressources Azure (elimine la gestion des identifiants pour l’acces service-a-service)
• Configurez les parametres de diagnostic pour diffuser les journaux Azure AD vers votre SIEM

GCP IAM

Hierarchie des ressources : Utilisez les organisations GCP, les dossiers et les projets pour separer les environnements. Cloud Identity ou Google Workspace sert de fournisseur d’identite.

Mesures cles :

• Utilisez Workload Identity Federation pour eviter les cles de comptes de service pour les charges de travail externes
• Mettez en oeuvre les Organization Policies pour appliquer des contraintes a travers les projets
• Utilisez les IAM Conditions pour les decisions d’acces sensibles au contexte
• Activez les journaux d’audit Admin Activity (toujours actifs) et les journaux d’audit Data Access pour les ressources sensibles
• Examinez les suggestions du IAM recommender pour reduire les permissions excessives

Journalisation et surveillance des evenements d’acces

Le controle d’acces est incomplet sans visibilite. Les mesures A.8.15 (Journalisation) et A.8.16 (Activites de surveillance) exigent que les evenements d’acces soient journalises et surveilles pour detecter les anomalies.

Quoi journaliser

Evenements d’authentification :

• Tentatives de connexion reussies et echouees
• Defis et resultats MFA
• Changements et reinitialisation de mots de passe
• Verrouillages de comptes
• Emission et renouvellement de jetons SSO

Evenements d’autorisation :

• Octrois et revocations d’acces
• Changements de permissions
• Attributions et retraits de roles
• Evenements d’escalade de privileges

Evenements administratifs :

• Changements de politiques IAM
• Modifications de groupes de securite
• Changements d’ACL reseau
• Creation ou modification de comptes de service

Evenements d’acces aux donnees :

• Requetes de base de donnees sur des tables sensibles
• Acces aux fichiers dans des emplacements de stockage sensibles
• Appels API qui retournent des donnees clients
• Exports ou telechargements massifs de donnees

Surveillance et alertes

La journalisation est necessaire mais pas suffisante. Vous devez activement surveiller les journaux pour detecter les comportements suspects et repondre aux alertes.

Evenements justifiant une alerte :

• Tentatives de connexion echouees multiples depuis le meme compte ou la meme IP
• Connexion reussie depuis une localisation geographique inhabituelle
• Utilisation d’un compte privilegie en dehors des heures de bureau
• Acces a des donnees sensibles par des comptes qui n’y accedent pas habituellement
• Creation de nouveaux comptes privilegies
• Desactivation du MFA sur un compte quelconque
• Acces depuis des adresses IP hors de vos plages d’entreprise ou VPN

Mise en oeuvre SaaS : Envoyez tous les journaux d’acces vers un SIEM centralise (Datadog, Splunk, Elastic ou une solution cloud-native comme AWS Security Hub, Azure Sentinel ou GCP Chronicle). Definissez des regles d’alerte pour les evenements ci-dessus. Etablissez un processus pour le triage et l’investigation des alertes, avec escalade vers votre processus de reponse aux incidents pour les activites suspectes confirmees.

Protection des journaux

Les journaux d’acces doivent etre proteges contre la falsification. Si un compte privilegie compromis peut modifier ses propres journaux d’acces, les journaux perdent leur valeur probante.

Mesures de protection :

• Stockez les journaux dans un compte ou systeme separe des systemes surveilles
• Appliquez des politiques d’ecriture unique, lecture multiple (WORM) ou d’ajout uniquement au stockage des journaux
• Restreignez la suppression et la modification des journaux a un tres petit nombre de comptes (ou empechezles entierement)
• Surveillez la falsification ou la suppression de journaux comme une alerte de haute priorite

Constatations d’audit courantes en controle d’acces

Comprendre ce que les auditeurs trouvent generalement vous aide a traiter proactivement les lacunes. Voici les constatations de controle d’acces les plus frequentes lors des audits de certification ISO 27001.

Constatation 1 : Desapprovisionnement incomplet

Ce que les auditeurs testent : Ils demandent votre liste d’employes ayant quitte l’entreprise pendant la periode d’audit et la recoupent avec les comptes utilisateurs dans les systemes critiques.

Ce qu’ils trouvent : D’anciens employes avec des comptes actifs dans des systemes non connectes au fournisseur d’identite — souvent des applications anciennes, des outils de developpement ou des comptes de plateforme cloud avec des identifiants locaux.

Comment le prevenir : Maintenez une checklist de desapprovisionnement complete qui couvre chaque systeme dans le perimetre. Automatisez lorsque possible. Pour les systemes qui ne peuvent pas etre automatises, verifiez manuellement l’achevement du desapprovisionnement et documentez la verification.

Constatation 2 : Acces privilegie excessif

Ce que les auditeurs testent : Ils examinent la liste des utilisateurs avec acces privilegie et la comparent a l’organigramme et aux definitions de roles.

Ce qu’ils trouvent : Des ingenieurs qui ont recu un acces administrateur pour un projet specifique il y a des mois et l’ont toujours. Des fondateurs qui ont un acces root a tout malgre leur evolution vers des roles non techniques. Des comptes de service avec des privileges d’administrateur parce que c’etait « plus facile » a configurer.

Comment le prevenir : Mettez en oeuvre des revues trimestrielles d’acces privilegie avec remediation documentee. Utilisez l’acces JIT pour les operations privilegiees afin que l’acces administrateur permanent soit l’exception, pas la norme.

Constatation 3 : Revues d’acces manquantes ou incompletes

Ce que les auditeurs testent : Ils demandent des preuves de revues d’acces completees pour la periode d’audit, correspondant a la frequence indiquee dans votre politique de controle d’acces.

Ce qu’ils trouvent : Des revues censees avoir lieu trimestriellement mais qui n’ont eu lieu que deux fois. Des revues menees mais manquant de documentation des constatations et de la remediation. Des revues couvrant certains systemes mais pas tous les systemes dans le perimetre.

Comment le prevenir : Automatisez la planification des revues d’acces. Programmez des rappels de calendrier avec suffisamment de delai pour completer la revue avant la date limite. Utilisez un modele de revue structure qui capture la date, l’examinateur, les systemes examines, les constatations et les actions de remediation. Consultez notre checklist de certification ISO 27001 pour un calendrier complet des activites recurrentes.

Constatation 4 : Comptes partages

Ce que les auditeurs testent : Ils recherchent des comptes utilises par plusieurs individus, ce qui viole les exigences de responsabilite et de piste d’audit.

Ce qu’ils trouvent : Des comptes « admin » partages pour les outils SaaS qui ne supportent pas le SSO. Des identifiants partages pour les systemes anciens. Des comptes generiques « deploy » utilises par plusieurs ingenieurs.

Comment le prevenir : Eliminez les comptes partages dans la mesure du possible. Lorsque les comptes partages sont techniquement inevitables (certains systemes anciens), mettez en oeuvre des mesures compensatoires : procedures d’enregistrement/desinscription, enregistrement de session et journalisation d’utilisation qui identifie qui a utilise le compte partage a un moment donne.

Constatation 5 : Couverture MFA insuffisante

Ce que les auditeurs testent : Ils verifient que le MFA est applique sur tous les systemes ou votre politique l’exige.

Ce qu’ils trouvent : Des politiques MFA configurees dans le fournisseur d’identite mais avec des exceptions pour certains utilisateurs ou applications. Des comptes de plateforme cloud avec le MFA active sur la console mais pas pour l’acces CLI. Des applications qui supportent le MFA mais ou il n’a jamais ete active.

Comment le prevenir : Auditez l’application du MFA a travers tous les systemes dans le perimetre. Fermez les lacunes d’exception. Pour les systemes qui ne supportent pas le MFA, documentez la limitation et mettez en oeuvre des mesures compensatoires (restrictions IP, exigences VPN, journalisation renforcee).

Questions frequentes

Quelle est la difference entre le controle d’acces dans ISO 27001 et SOC 2 ?

Les exigences sous-jacentes sont presque identiques — les deux referentiels attendent le moindre privilege, le MFA, les revues d’acces, les mesures de provisionnement/desapprovisionnement et la gestion des acces privilegies. La difference reside dans la structure du referentiel. ISO 27001 organise les exigences de controle d’acces a travers des mesures specifiques de l’Annex A. SOC 2 traite le controle d’acces via les criteres communs (principalement CC6.1 a CC6.8). Une entreprise SaaS mettant en oeuvre des mesures de controle d’acces pour un referentiel satisfera la plupart des exigences de l’autre referentiel avec un effort supplementaire minimal.

A quelle frequence les revues d’acces doivent-elles etre menees ?

ISO 27001 ne prescrit pas de frequence specifique — elle exige des revues « a intervalles planifies ». Vous definissez la frequence dans votre politique de controle d’acces. La norme du secteur pour les audits de certification est des revues trimestrielles pour les acces privilegies et sensibles, et des revues semestrielles ou annuelles pour les acces standard. Quelle que soit la frequence que vous definissez, vous devez demontrer une execution coherente.

Avons-nous besoin d’un outil de gestion des acces privilegies (PAM) dedie ?

Pas necessairement. L’exigence est de controler l’acces privilegie — comment vous mettez en oeuvre ce controle depend de vous. Les petites entreprises SaaS peuvent gerer l’acces privilegie via des politiques IAM, des scripts d’acces JIT et des processus manuels documentes. A mesure que vous grandissez, un outil PAM dedie (CyberArk, BeyondTrust, HashiCorp Vault) devient de plus en plus precieux pour centraliser la gestion des identifiants privilegies, mettre en oeuvre l’enregistrement de session et automatiser la rotation des identifiants.

Comment gerer le controle d’acces pour les donnees clients dans un produit SaaS multi-locataire ?

L’isolation des locataires doit etre appliquee au niveau technique — logique applicative, requetes de base de donnees (securite au niveau des lignes ou schema/base de donnees par locataire) et segmentation reseau. L’acces interne aux donnees clients devrait necessiter une justification explicite (ticket de support actif), des octrois d’acces a duree limitee et une journalisation complete. Envisagez de mettre en oeuvre une politique d’acces aux donnees clients separee de votre politique generale de controle d’acces en raison de sa sensibilite et des mesures supplementaires requises.

Quelle est la relation entre notre politique de controle d’acces et notre evaluation des risques ?

Votre evaluation des risques identifie les risques lies aux acces non autorises, aux privileges excessifs et aux defaillances du controle d’acces. La politique de controle d’acces definit les mesures qui traitent ces risques. Les deux devraient etre explicitement lies — chaque exigence de controle d’acces dans votre politique devrait etre tracable vers un risque qu’elle traite, et chaque risque lie aux acces dans votre registre des risques devrait etre tracable vers la mesure qui l’attenuer. Cette tracabilite est quelque chose que les auditeurs recherchent et est documentee dans votre Declaration d’Applicabilite.

Comment GRCTrail peut vous aider

GRCTrail simplifie la mise en oeuvre du controle d’acces ISO 27001 et la conformite continue pour les entreprises SaaS :

• Revues d’acces automatisees qui extraient les listes d’utilisateurs de votre fournisseur d’identite et des systemes connectes, les acheminent vers les examinateurs appropries, suivent l’achevement et conservent les preuves — eliminant le processus de revue base sur des tableurs qui cause des delais manques
• Modeles de politique de controle d’acces adaptes aux entreprises SaaS, couvrant chaque mesure pertinente de l’Annex A avec un langage pratique pour les environnements cloud, les pipelines CI/CD et les architectures multi-locataires
• Tableaux de bord de surveillance continue qui suivent l’application du MFA, les comptes inactifs et l’acces privilegie dans votre environnement, vous alertant des derives avant que votre auditeur ne les trouve

Demarrer avec GRCTrail

Guides connexes

• Qu’est-ce qu’ISO 27001 ? Un guide pratique pour les entreprises SaaS
• Mesures de l’Annex A ISO 27001 : le guide complet
• Politiques ISO 27001 : quelles politiques sont necessaires et comment les rediger
• Checklist de certification ISO 27001
• Guide d’evaluation des risques ISO 27001