Une politique d'authentification et d'autorisation dit à quel point le système doit être certain qu'un utilisateur est celui qu'il prétend être, et ce que chaque rôle peut faire une fois connecté. Elle fixe le niveau d'assurance, les rôles, la matrice de contrôle d'accès basé sur les rôles (RBAC), les limites de session, les règles de mot de passe, l'authentification multifacteur (MFA) par rôle, la fédération par authentification unique (SSO) et les clés d'API. Avec elle, vous décidez qui obtient quel accès, et vous défendez cette décision devant un auditeur.
Une politique écrite à la main glisse vers les valeurs par défaut. Quelqu'un copie un gabarit, garde les délais d'exemple, et personne ne note pourquoi le rôle admin a un accès total. Six mois plus tard, le départ d'un employé n'a pas de responsable, les clés d'API n'ont jamais tourné, et l'audit pose une question à laquelle personne ne sait répondre. Le document se lit bien; il ne décrit juste aucune décision prise.
Quelles sections une politique d'authentification et d'autorisation contient-elle?
Le gabarit gouverné par défaut de Specira produit neuf sections, chacune avec sa stratégie de production, les décisions qu'elle exige et les preuves qu'elle doit citer.
| Section | Profondeur | Comment elle est produite |
|---|---|---|
| Méthode d'authentification | base | Prose synthétisée depuis la découverte |
| Liste des rôles | base | Table à partir d'éléments typés · Role, Description, User Count |
| Matrice RBAC complète | standard | Table à partir d'éléments typés · Role, Entity, Create, Read, Update, Delete |
| Politique de session | standard | Prose synthétisée depuis la découverte |
| Politique de mots de passe | standard | Prose synthétisée depuis la découverte |
| Exigences MFA par rôle | complet | Prose synthétisée depuis la découverte |
| Configuration SSO/OIDC | complet | Prose synthétisée depuis la découverte |
| Gestion des clés API | complet | Prose synthétisée depuis la découverte |
| Prévention de l'escalade de privilèges | complet | Prose synthétisée depuis la découverte |
Comment Specira construit-elle la politique d'authentification et d'autorisation?
L'analyste en sécurité est propriétaire de cet artefact. Avant de poser une seule question, il lit les obligations réglementaires, les contraintes de sécurité et les politiques de gouvernance déjà dans la base de connaissances, pour que le niveau d'assurance qu'il propose soit ancré sur la classification de données la plus élevée qu'une session touche, jamais sur une valeur par défaut. Dans l'exemple, la section 1 (niveaux d'assurance) montre cet ancrage sous forme de tableau, avec la décision consignée contre un approbateur nommé et une date. La section 2 (stratégie d'authentification) traduit les règles d'identifiants en chiffres (longueur du mot de passe, verrouillage, chemin de récupération) et abandonne la rotation périodique comme décision explicite. La section 4 (modèle de permissions) consigne pourquoi le RBAC l'a emporté sur les modèles par relations et par attributs, puis déroule la matrice avec des cellules explicites seulement, sans ligne admin passe-partout.
Le critique Red Team révise chaque tour, donc une politique de session qui contredit une classification de données, ou un chemin de départ sans responsable, est signalé avant d'atteindre le document. Les sections dont les décisions restent ouvertes s'affichent comme des lacunes nommées; Specira n'invente jamais un délai pour remplir une cellule. Chaque ligne porte sa provenance : qui a décidé, quand, et sur quelle preuve, avec les citations de la base de connaissances notées par un score de confiance. La porte d'exportation mesure les décisions résolues, pas les pages écrites, et les décisions reportées sortent listées dans un rapport de lacunes avec les exports DOCX, Markdown et JSON, ou l'envoi vers Confluence, Jira, GitHub ou Linear.
Exemple rendu
Rendu à partir du gabarit gouverné par défaut de Specira sur une entreprise fictive, filigrané, avec ses diagrammes. Document en anglais.
Comment les équipes utilisent-elles la politique d'authentification et d'autorisation?
- ✓Configurer le fournisseur d'identitéLa section SSO nomme le fournisseur, le flux et le comportement à la déconnexion; l'équipe identité configure une fois et arrête de deviner.
- ✓Appliquer la matrice RBAC côté serveurLes développeurs implémentent la matrice cellule par cellule, et « lecture seule » veut dire que le serveur refuse l'écriture, pas que le bouton est caché.
- ✓Répondre aux questions d'auditChaque règle pointe vers la classification, la clause de contrat ou le règlement qui l'a exigée, avec l'approbateur nommé.
- ✓Fermer le chemin de départChaque état du cycle de vie porte un acteur et un délai; le retrait des accès a un responsable avant le premier départ.
À quoi ressemble la politique dans Specira?
Ces écrans montrent la session de découverte où le niveau d'assurance a été débattu, les décisions typées derrière la matrice et la porte d'exportation de cette politique.
Écrans tirés d'un espace de démonstration Specira; compteurs et scores sont des données d'exemple.
Réservez une démo et regardez l'analyste en sécurité ancrer un niveau d'assurance sur votre classification de données en une seule session.
Réserver une démo