" %}
***
### **1.2 Role-Based Access Control (RBAC)**
CAT-BM enforces fine-grained access controls based on user roles defined in the user access token. This includes permission boundaries for deployment operations, audit views, and runtime configurations. Each user role (e.g., Admin, Operator, Auditor) is mapped to a specific set of capabilities within the system.
***
## 2. Infrastructure Security
### 2.1 Cloud Environment
The CAT-BM platform is hosted on Azure AKS, which provides managed Kubernetes with integrated Azure security features, including IAM roles for service accounts (IRSA), VNet isolation, and encrypted storage.
### 2.2 Network Security
* Ingress is controlled using Kubernetes ingress controllers, secured with HTTPS and mutual TLS where applicable.
* Internal communication between services within the AKS cluster is protected using Kubernetes Network Policies, ensuring fine-grained, pod-level traffic controls. For workloads requiring stronger guarantees, a service mesh such as Istio or Linkerd can provide mutual TLS, automatic certificate rotation, and traffic encryption between microservices.
* All Kubernetes control plane communications are secured by AKS, with encryption in transit between worker nodes and the managed control plane. Private AKS endpoints can be enabled to ensure that Kubernetes API access is limited to internal networks via VNet endpoints or VPN/Direct Connect, preventing exposure to the public internet.
* DNS traffic inside the cluster is secured through CoreDNS and VNet DNS resolution, while external service access can be restricted with egress controls, including Kubernetes egress policies, NAT gateways, or Azure Network Firewall.
### 2.3 Database Security
Each environment (DevNet, TestNet, MainNet) uses two Azure Database for PostgreSQL Flexible Server (managed database service) instances: one hosting the Keycloak database and one hosting the validator and participant databases.
Databases are protected through Azure-managed encryption at rest, TLS encryption in transit, role-based access control with least-privilege service accounts, and network access restrictions. High availability is configured with multi-zone synchronous replication and automatic failover (see HA & DR sections). Azure-managed backups with point-in-time recovery protect against data loss. Database activity is logged through PostgreSQL server logs and Azure platform monitoring, providing audit visibility into database access and infrastructure changes.
**Each environment contains two database servers:**
| Server | Database | Purpose |
| ------------------------------------- | ---------------------------------------- | -------------------------------------------- |
| Azure PostgreSQL Server for Keycloak | Keycloak database | Identity and access management data |
| Azure PostgreSQL Server for Validator | Participant database, validator database | Canton validator and participant ledger data |
Separating these workloads across two PostgreSQL servers provides logical isolation of identity infrastructure from ledger infrastructure.
**The following accounts are used for database level access:**
| Server | Database | Account | Used By | Access Level |
| ------------------------------------- | ----------- | ---------------------------------- | -------------------------- | --------------------------------------------------------- |
| Azure PostgreSQL Server for Keycloak | keycloak | keycloakadmin - administrator user | Keycloak service | Read / Write, schema management (non-superuser) |
| Azure PostgreSQL Server for Validator | participant | cnadmin - administrator user | Canton participant service | Read / Write, schema management
(non-superuser)
|
| Azure PostgreSQL Server for Validator | validator | cnadmin - administrator user | Canton validator service | Read / Write, schema management
(non-superuser)
|
{% embed url="" %}
### 2.4 Environment Guardrails
**Objective**: Prevent misconfigurations and enforce data residency using Policy as Code.
* **Policy Enforcement Engine**: Deployed Azure Policy Initiatives to act as automated platform guardrails.
* **Security Baselines**: The Microsoft Cloud Security Benchmark has been applied to the environment.
* **Devnet:** Configured in Audit Mode for visibility.
* **Mainnet**: Configured in Deny Mode to actively block insecure deployments (e.g., blocking Public IPs on Canton nodes, mandating disk encryption).
* **Data Residency Restrictions**: Implemented strict Allowed Locations policies at the Resource Group level. This acts as a geofence, ensuring Canton nodes and data can only be deployed in approved Azure regions (e.g., eastus2).
### 2.5 Compliance & Vulnerability Monitoring
**Continuous Threat Detection**: Activated Microsoft Defender for Cloud across all workload types:
* Defender for Servers (AKS Nodes)
* Defender for Containers (AKS Orchestration/Pods)
* Defender for Open-Source Relational Databases (PostgreSQL)
* Defender for Key Vaults & Storage
**Agentless Vulnerability Scanning**: Enabled Agentless Scanning and MDE (Microsoft Defender for Endpoint) integration. This provides daily CVE discovery on OS and software packages with zero performance impact on the Canton nodes.
**Regulatory Dashboard**: Mapped the environment to the SOC 2 Type II regulatory standard. Real-time compliance scores and exportable auditor reports (PDFs) are now generated automatically.
### 2.6 Open Source Libraries
Software/components/libraries and their licenses used on CatalyX Blockchain Manager can be found in the Open Source Licenses documentation.
{% content-ref url="/pages/LXiaSpN3L7C2QSC5jkRF" %}
[Open Source Licenses](/catalyx-blockchain-manager/canton-network/version-1.11/support-and-resources/open-source-licenses.md)
{% endcontent-ref %}
***
## 3. Key Management and External Wallets
### 3.1 Default Key Storage Model
By default, Canton node-level operational keys are generated and stored within the participant’s database as part of the standard Canton node configuration. This approach is sufficient for many deployments and aligns with Canton’s out-of-the-box security model.
### 3.2 Key Management Service (KMS) Integration
A Key Management Service (KMS) is an external system for generating, storing, and protecting the cryptographic private keys that Canton Validator nodes use for signing transactions and establishing their identity on the network. Instead of keeping these keys inside the validators’s own database, a KMS externalises key storage so that private key material never resides in application infrastructure, giving you hardware-backed, audited, and centrally-managed key custody.
Canton natively supports KMS integration and offers two modes of operation:
* **Encrypted private key storage** — keys remain stored inside Canton’s database but are encrypted at rest using a KMS-managed wrapper key (also referred to as *envelope encryption*).
* **External key storage** — keys are generated and stored entirely within the KMS. Canton never holds the raw private key material; all cryptographic operations are delegated to the KMS.
For more background on how Canton handles these two modes, see the Digital Asset documentation:
{% embed url="" %}
{% embed url="" %}
#### 3.2.1 KMS Configuration in CatalyX Blockchain Manager
CatalyX Blockchain Manager supports environment-level KMS configuration for Validator nodes. When enabled, all **newly created** validators in the environment are provisioned with KMS-backed validator keys. Validators already deployed without KMS are not affected — their configuration remains unchanged.
KMS is **disabled by default** and is opted into via Operator environment variables. For prerequisites, configuration steps, verification guidance, and current scope and limitations, see the dedicated KMS Integration page:
{% content-ref url="/pages/vudcRwhMopLbfG2zle7v" %}
[Key Management Service (KMS)](/catalyx-blockchain-manager/canton-network/version-1.11/validator-management/kms-integration.md)
{% endcontent-ref %}
For detailed guidance on configuring Canton with a specific KMS provider (AWS, GCP, or a custom driver), refer to the Digital Asset documentation:
{% embed url="" %}
### 3.3 Advanced Security Hardening
For deployments requiring stronger key-protection guarantees beyond the standard KMS integration, an Azure KMS driver can be implemented to integrate Canton with Azure Key Vault. In this model:
* Node-level operational keys are generated and stored in Azure Key Vault instead of the participant database
* Keys are managed as customer-managed keys (CMKs)\
Private key material is handled by Azure Key Vault and never exposed in plaintext
* Deployments can leverage FIPS 140-2 compliant cryptographic modules available in Azure Managed HSM
This approach enables centralized key management, stronger isolation of cryptographic material, and alignment with enterprise and regulatory security requirements.
{% embed url="" %}
### 3.4 Integration with Wallet-as-a-Service Providers
Our solution supports integration with Wallet-as-a-Service (WaaS) providers such as Dfns, enabling secure and compliant management of cryptographic keys without requiring organizations to operate their own key infrastructure.
Validators can be registered directly with a WaaS, and subsequent Wallets (external parties) can be created through the WaaS interface. Instead of handling private keys locally, all cryptographic operations (e.g., signing, authentication) are delegated to the WaaS, ensuring that keys never leave the secure environment.
Key storage is managed by the WaaS in a distributed, zero-trust architecture, with an optional configuration to leverage Hardware Security Modules (HSMs) for additional protection and compliance with industry security standards (FIPS 140-2/3, Common Criteria, etc.).
**This approach provides:**
* Enhanced Security: Private keys are never exposed to application code or infrastructure.
* Operational Resilience: WaaS ensures redundancy, access control, and secure recovery.
* Regulatory Compliance: HSM-backed storage satisfies stringent regulatory and audit requirements.
* Seamless Integration: Validators and external parties can be provisioned through the same WaaS API, simplifying lifecycle management.
By offloading key custody and signing operations to a WaaS, organizations gain a secure and scalable way to operate validators and external parties, reducing the risk of compromise while maintaining full control over their operational workflows.
### 3.5 Strict Key Usage Policies
* KMS key policies restrict usage exclusively to the Kubernetes IAM roles associated with the tenant’s Canton workloads.
* No human IAM user is granted direct permissions to perform kms:Decrypt or kms:Sign operations on node operational keys.
### 3.6 Access Control & Monitoring
* All Azure Key Vault operations are fully logged
* Quarterly access reviews are performed as part of the security governance process.
* Multi-factor authentication (MFA) is enforced for all Azure console users, with operational key usage being fully automated and non-interactive.
***
## 4. Privacy Controls
### 4.1 Security Logging & Monitoring
Objective: Ensure comprehensive security monitoring, forensic log retention, and 24/7 incident response readiness.
* **Centralized Log Repository**: Deployed a dedicated Azure Log Analytics Workspace (law-canton-\[env]-law).
* **Retention Policy**: Enforced at 30 days for Mainnet (Production) and 7 days for Devnet/Testnet to meet forensic investigation requirements.
* **Control Plane Audit Trail**: Enabled Azure Activity Logs streaming at the subscription level. This guarantees an immutable record of all infrastructure changes, role assignments, and policy modifications.
* **Data Plane Audit Trail:** Automated Diagnostic Settings for all critical resources.
* **AKS**: Capturing kube-audit and kube-apiserver logs to track internal Kubernetes API interactions.
* **PostgreSQL:** Configured the pgaudit extension to track database sign-ins and query execution.
* **Networking:** Configured to capture flow logs.
* **SIEM & MSSP Integration:** Fully onboarded Microsoft Sentinel. The environment is integrated with the Microsoft Defender Unified Security Operations Platform and is Azure Lighthouse-ready, enabling secure, credential-less 24/7 monitoring by an external MSSP.
### 4.2 User Consent and Access Logs
System access is logged with user context from Keycloak. These logs support compliance with data protection laws and enable investigations and traceability in the event of an incident
***
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-1.11/technical-documentation-canton/security-and-privacy-implementation.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.