Aller au contenu principal
S'applique à :
Cockpit v2Architecture en couchesMulti-tenant

Cockpit v2 repose sur une conception en couches orientée domaine avec une défense en profondeur : les clients atteignent une bordure sécurisée, les requêtes traversent un pipeline d'authentification et d'autorisation, les services de domaine portent la logique métier, et le matériel de clés est conservé dans une couche de garde protégée. Le diagramme ci-dessous montre la forme de la plateforme.

DuoKey Cockpit — Architecture

A layered, defense-in-depth platform: clients, a secure edge, policy-enforced services, and protected key custody.

1
Clients & protocols
Microsoft 365 / OfficeDKE
Devices & workloadsACMEESTSCEPCMP
KMIP clientsKMIP 2.x
Console & REST / SDK
HTTPS / TLS
2
Secure edge
TLS termination
Rate limiting
Security headers
CORS
3
API & policy layer
Request pipeline
AuthenticationTenant resolutionEntitlement checkAudit
Then
Permission check (RBAC + ABAC)
Request validation
REST API
4
Domain services
Keys
Vaults
PKI
DKE 365
Post-quantum
KMIP
Applications
Access policies
Admin · Tenant · Editions
5
Data & audit
Encrypted database
Cache
Tamper-evident audit
6
Key custody
Software / DuoKey MPC KMS
Securosys HSMFIPS L3
Sepior (Blockdaemon)MPC
Cloud KMS · PKCS#11 HSMs

Comment c'est organisé​

Les responsabilités sont séparées en couches claires, et les dépendances s'écoulent uniquement vers le bas — la couche API et application dépend du domaine, et le domaine est indépendant de la manière dont il est livré ou stocké.

Bordure sécurisée

Terminaison TLS, limitation de débit, en-têtes de sécurité et CORS protègent la plateforme avant que toute requête ne soit traitée.

Couche API & politiques

Chaque requête est authentifiée, liée à son tenant, vérifiée par rapport aux droits de ce tenant, contrôlée en permission et validée avant qu'un gestionnaire ne s'exécute.

Services de domaine

Clés, coffres, PKI, DKE, post-quantique, KMIP, applications et politiques d'accès — la logique métier, maintenue indépendante de la livraison et du stockage.

Données & garde des clés

Un stockage chiffré avec une piste d'audit inviolable, et un matériel de clés conservé en garde logicielle, MPC ou HSM derrière une interface uniforme.

Flux de requête​

Chaque requête parcourt le même chemin : elle est authentifiée (jeton de session ou passkey), résolue vers son tenant, vérifiée par rapport aux droits d'édition de ce tenant, et auditée — puis le gestionnaire effectue un contrôle de permission et valide la requête avant de la déléguer à un service de domaine. Le service lit ou écrit dans le stockage chiffré et, lorsque la cryptographie est impliquée, appelle la couche de garde des clés. Les clés privées ne quittent jamais leur coffre ou leur HSM.

Une seule interface de garde

Les services de domaine parlent à une interface de garde unique et uniforme, de sorte que le même code fonctionne qu'une clé vive dans un coffre logiciel, un service de gestion de clés MPC ou un HSM Securosys. Voir Vaults & HSM.

Multi-tenant​

Cockpit v2 est multi-tenant par construction. Chaque enregistrement appartient exactement à un tenant, le tenant est dérivé de l'identité signée de l'appelant (jamais fournie par le client), et l'isolation est appliquée automatiquement à chaque requête plutôt que laissée à chaque fonctionnalité individuelle. Au sein d'un tenant, les unités organisationnelles fournissent une seconde couche de périmétrage pour les équipes et les départements, et les éditions conditionnent les capacités disponibles.

Les chiffres de performance sont indicatifs

Tout chiffre de débit, de latence ou de capacité cité pour Cockpit v2 est une cible indicative, et non un chiffre garanti. Validez-le dans votre propre environnement avant de vous en servir pour un dimensionnement de capacité.

Secure edgerate limit · CORSAuthenticateJWT · WebAuthnTenantfrom tokenEntitlementsedition gateAuditfail-closedHandlerpermission + validateDomain servicebusiness logic
Every request is secured at the edge, authenticated, bound to its tenant, checked against entitlements and audited — before the handler runs a permission check and validation.