Sécurité & Audit
Authentification, autorisation, chiffrement au repos et la piste d'audit inviolable chaînée par hachage dans Cockpit v2.
Authentification
Cockpit v2 authentifie les appelants au moyen d'une pile d'identité en couches, construite sur une cryptographie moderne et éprouvée.
Sessions JWT
Des jetons d'accès de courte durée associés à des jetons de rafraîchissement, afin que les identifiants ne restent en portée que brièvement.
WebAuthn / FIDO2
Authentification par passkey avec vérification complète de la signature côté serveur.
MFA complète
TOTP avec codes de récupération et verrouillage en cas d'échecs répétés.
Vérification des mots de passe compromis
Les mots de passe sont vérifiés auprès de Have I Been Pwned en utilisant la k-anonymité, de sorte que le texte en clair ne quitte jamais le service.
Protection anti-bot
reCAPTCHA v3 ou hCaptcha sur les flux sensibles, configurés en mode fail-closed.
Fédération avec des IdP externes
OIDC, SAML 2.0, LDAP / AD, Azure AD, Okta, Google et Keycloak.
Autorisation
Le contrôle d'accès est appliqué par un moteur de politiques unique qui fournit à la fois le RBAC et le contrôle d'accès basé sur les attributs (ABAC). Les permissions sont hiérarchiques, sont limitées aux unités organisationnelles (OU), et sont conditionnées par l'édition du produit.
| Capacité | Description |
|---|---|
| RBAC + ABAC | Un moteur de politiques unique évalue conjointement les règles basées sur les rôles et sur les attributs. |
| Permissions hiérarchiques | Des permissions granulaires qui s'imbriquent hiérarchiquement, de sorte qu'un octroi parent implique tout ce qui se trouve en dessous. |
| Périmétrage par OU | Les octrois sont limités à une unité organisationnelle et à son sous-arbre. |
| Conditionnement par édition | Les capacités sont activées ou retenues selon l'édition sous licence. |
Le modèle complet des permissions, la hiérarchie des rôles et les dimensions ABAC sont documentés dans Politiques d'accès.
Chiffrement au repos
Les secrets stockés sont protégés par un chiffrement authentifié et un hachage de mot de passe moderne. Toutes les primitives proviennent de bibliothèques cryptographiques bien établies — il n'y a aucune cryptographie maison.
| Aspect | Mécanisme |
|---|---|
| Identifiants stockés | AES-256-GCM, dérivé d'une ENCRYPTION_KEY. |
| Hachage des mots de passe | Hachage de mot de passe robuste et conforme aux standards du secteur. |
| Cryptographie | Bibliothèques cryptographiques éprouvées et conformes aux standards du secteur — aucune cryptographie maison. |
Audit inviolable
La piste d'audit est un différenciateur central de Cockpit v2. Chaque enregistrement d'audit est à la fois signé et chaîné, de sorte que toute insertion, modification ou suppression ultérieure devient détectable.
Chaque enregistrement d'audit est signé en HMAC-SHA256 et, de plus, relié dans une chaîne de hachage SHA-256 sur le journal d'activité. Chaque tenant possède sa propre tête de chaîne, qui est avancée de manière atomique afin que des écritures concurrentes ne puissent ni forker ni entrer en course sur la chaîne.
Comment cela fonctionne
| Propriété | Détail |
|---|---|
| Signature par enregistrement | Chaque enregistrement d'audit porte une signature HMAC-SHA256. |
| Chaîne de hachage | Les enregistrements sont reliés dans une chaîne SHA-256 sur le journal d'activité. |
| Tête de chaîne | Une tête de chaîne par tenant est avancée de manière atomique. |
| Identité de l'appelant en première classe | Les enregistrements portent directement l'identité de l'appelant (email et application). |
Vérifier la chaîne
Une routine de vérification dédiée recalcule la chaîne et signale toute rupture, de sorte que toute insertion, modification ou suppression est mise en évidence.
Audit en fail-closed
L'audit est fail-closed. Une décision allow qui ne peut pas être associée à un enregistrement d'audit forensique durable est refusée plutôt que silencieusement autorisée.
| Paramètre | Comportement |
|---|---|
DKE_FAIL_CLOSED_AUDIT | Active/désactive l'audit fail-closed. Activé par défaut en production. |
Désactiver DKE_FAIL_CLOSED_AUDIT permet aux actions de se poursuivre même lorsque leur enregistrement d'audit forensique ne peut pas être écrit, ce qui affaiblit les garanties d'inviolabilité ci-dessus. Gardez-le activé en production.