DNB -- De Nederlandsche Bank Outsourcing Guidelines¶
Authorised application boundary
Authorised application code is trusted. An authorised app can send out a secret it has copied or encoded. Current content checks do not provide a general guarantee against this disclosure or a malicious authorised app. Memory-read tests and a Ready agent do not prove copied/encoded-secret exfiltration prevention. Enforced NetworkPolicy can restrict destinations, but allowed traffic remains a channel. See Security Model.
Workload identity and direct store-login boundary
In direct mode, OpenBao authenticates the ServiceAccount and namespace, not the injected wrapper. Anyone who can run a pod as the application's ServiceAccount can request a matching audience-bound JWT, log in to any store role bound to that identity, and read the records its policies allow. Node root can steal the projected JWT and do the same. CloudTaser does not bind direct store release to the injected wrapper. This limit remains unresolved. Blocking exec or protecting process memory does not block a separate store login. Port/bootstrap attestation claims do not apply to direct-mode logins.
Use one workload per identity: a dedicated ServiceAccount and exact-record store policy for each app. Restrict who can create or change workloads using that ServiceAccount, including controller templates, through Kubernetes RBAC and admission policy. Namespace access alone is not isolation between apps sharing an SA. Audience checks, shorter JWT lifetimes and source CIDRs limit some replay; they do not establish wrapper identity or stop node root. Confidentiality claims on this page do not cover this credential-acquisition path.
One workload per identity applies on both direct and Port paths. Denial of a second same-identity workload on Port has not been established; a different-ServiceAccount reader test does not prove that denial.
Mapping, not certification
This document maps cloudtaser's technical controls to the named framework's requirements. It is evidence you can present to your auditor, not a cloudtaser certification. Certification is an outcome of your auditor's own review of your deployment (which may use cloudtaser's controls as supporting input).
Third-party audit roadmap: tracked in third-party audit roadmap. Target: Q2 2026. Until the audit completes, cloudtaser ships with deliberately-documented gaps rather than certification claims.
What this document IS / IS NOT¶
This is:
- A mapping of cloudtaser technical controls to framework requirements
- Evidence you can include in your auditor's evidence package
- A starting point for your DPIA / compliance narrative
This is NOT:
- A cloudtaser framework certification
- A substitute for your own audit/attestation/assessment
- Legal advice
Use this to accelerate your audit preparation, not to replace audit evidence.
Framework Overview¶
Full name: DNB Good Practices for Managing Outsourcing Risks / DNB Guidance on Cloud Computing Issued by: De Nederlandsche Bank (DNB -- the Dutch central bank and financial supervisor) Legal basis: Financial Supervision Act (Wet op het financieel toezicht -- Wft), Decree on Prudential Rules (Besluit prudentiele regels Wft -- Bpr), EBA Guidelines on Outsourcing Arrangements Type: Supervisory guidance and good practices for regulated financial institutions
DNB supervises Dutch banks, insurers, and pension funds. Its outsourcing guidelines require financial institutions to maintain control over outsourced activities, particularly cloud computing. All financial institutions must inform DNB about cloud computing initiatives, regardless of materiality. DNB maintains a register of all cloud outsourcing contracts.
Who Must Comply¶
- Dutch banks (supervised under the Wft)
- Insurance companies (supervised under the Wft)
- Pension funds (supervised under the Pensioenwet)
- Payment institutions and electronic money institutions
- Investment firms under DNB supervision
- Their critical and important service providers (including cloud providers)
Key Principles¶
- Mandatory notification: All cloud outsourcing arrangements must be reported to DNB
- Risk analysis required: A comprehensive risk analysis must precede any cloud adoption
- Continued control: The institution must maintain effective control over outsourced activities
- Exit strategy: A viable exit strategy must exist before entering a cloud arrangement
- Data access control: The cloud provider must not have unauthorized access to sensitive data
DNB Requirements and cloudtaser Mapping¶
Outsourcing Risk Analysis¶
DNB requires a mandatory risk analysis before engaging cloud services. The risk analysis must assess:
| DNB Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| Data classification and sensitivity | Identify the sensitivity of data processed in the cloud | cloudtaser-cli target discover identifies workloads that reference Kubernetes Secrets (sensitive data stored in etcd, accessible to the cloud provider). Each represents a data sovereignty risk that can be classified and quantified |
CLI |
| Risk of unauthorized data access | Assess the risk that the cloud provider or third parties access sensitive data | cloudtaser's score reports component checks out of 175; it does not quantify residual risk or certify compliance. Assess the trust boundary, active node enforcement, vector table, readiness and deployment evidence separately | CLI, All |
| Legal and jurisdictional risks | Assess the impact of the provider being subject to non-EU laws | The customer selects the store operator, hosting jurisdiction and legal entity. CloudTaser documents technical delivery/runtime boundaries; it does not resolve legal exposure or establish immunity to compelled disclosure | All |
| Concentration risk | Assess dependency on a single cloud provider | cloudtaser is cloud-agnostic. Secrets are in a portable EU OpenBao, enabling multi-cloud or cloud-switching strategies that reduce concentration risk | Wrapper, Operator |
Data Access Controls¶
| DNB Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| Provider must not access sensitive data | The cloud provider must be technically unable to access sensitive financial data | Active BPF LSM denies covered procfs/ptrace read paths. Unrestricted node root, arbitrary kernel code and separate store logins remain outside that guarantee | Wrapper, eBPF |
| Encryption key control | Encryption keys must remain under the institution's control | The financial institution or its EU delegate operates the EU-hosted OpenBao and controls store policies and key custody. This architecture does not establish that provider/node-root or authorised application access is impossible; assess runtime copies and raw login separately | Wrapper, S3 Proxy |
| Client-side encryption | Data at rest should be encrypted with keys the provider cannot access | S3 proxy provides client-side AES-256-GCM encryption. DB proxy provides transparent database encryption. Encryption keys remain in the EU OpenBao | S3 Proxy, DB Proxy |
| Access logging | All data access must be logged and auditable | OpenBao audit log records all secret fetch operations. eBPF generates security events for all access attempts (blocked and allowed). cloudtaser-cli target audit produces compliance reports |
eBPF, CLI |
Third-Party Provider Risk Management¶
| DNB Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| Provider risk assessment | The institution must assess the cloud provider's security posture | cloudtaser-cli target audit reports workload protection state, component checks and scores as inputs to provider review. These reports do not quantify residual provider risk or replace assessment of identity controls, node integrity and compute substrate |
CLI |
| Contractual safeguards | Contracts must include security requirements and audit rights | No CloudTaser guarantee satisfies contractual safeguards or audit rights. The institution must establish and review those terms with its providers; technical runtime controls do not replace them | All |
| Sub-outsourcing controls | The institution must approve and monitor sub-outsourcing by the provider | No CloudTaser mechanism approves or monitors provider sub-outsourcing. The institution must review sub-processors, access, jurisdiction and contractual obligations, including the chosen store and relay operators | All |
| Regular provider reviews | The institution must regularly review the cloud provider's performance and security | cloudtaser-cli target audit provides ongoing monitoring of protection coverage. Protection scores detect drift. eBPF events detect anomalous access patterns |
CLI, eBPF |
Exit Strategy and Portability¶
| DNB Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| Viable exit strategy | The institution must have a documented plan to exit the cloud arrangement | cloudtaser makes exit strategies simple: secrets are in a portable EU OpenBao, not locked to any provider. Switching providers requires only redeploying the cloudtaser stack on a new cluster | Wrapper, Operator |
| Data portability | Data must be extractable in a standard format | Secrets and encryption keys are in standard OpenBao format. No proprietary formats. Export via standard OpenBao CLI tools | Wrapper |
| Business continuity during transition | Cloud switching must not disrupt operations | cloudtaser works identically across AWS, GCP, and Azure. The same OpenBao configuration and policies apply on any Kubernetes distribution. Parallel deployment enables zero-downtime migration | Operator |
| Reduced vendor lock-in | Minimize dependency on provider-specific services | cloudtaser replaces provider-specific secret management (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) with a cloud-agnostic EU OpenBao. No provider-specific APIs or formats | Wrapper |
Regulatory Access and Audit¶
| DNB Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| DNB access to data | DNB must be able to access outsourced data for supervisory purposes | The EU OpenBao is under EU legal entity control. DNB can access data through the institution, not through the cloud provider. cloudtaser does not impede lawful EU regulatory access | -- |
| Audit rights | The institution and DNB must have audit rights over the cloud provider | cloudtaser-cli target audit produces reports that can be included in audit evidence. eBPF event logs provide forensic evidence for supervisory review |
CLI, eBPF |
| Incident reporting | Security incidents must be reported to DNB | eBPF security events (SECRET_LEAK, PROCMEM_READ, PTRACE_DENIED, etc.) provide the detection data needed for incident reporting |
eBPF |
Component Coverage Matrix¶
| cloudtaser Component | DNB Areas Addressed |
|---|---|
| Operator (webhook injection) | Exit strategy, portability, concentration risk |
| Wrapper (secret delivery) | Data access control, key control, portability, exit strategy |
| eBPF (runtime enforcement) | Data access control, access logging, incident detection, provider review |
| S3 Proxy (client-side encryption) | Data access control, client-side encryption, key control |
| DB Proxy (transparent encryption) | Data access control, client-side encryption, key control |
| CLI (audit, validate, discover) | Risk analysis, provider review, audit evidence, incident reporting |
Alignment with EBA Guidelines¶
DNB's requirements align with the EBA Guidelines on Outsourcing Arrangements (EBA/GL/2019/02), which apply across the EU. cloudtaser's mapping to DNB requirements also satisfies the corresponding EBA requirements:
| EBA Guideline | DNB Equivalent | cloudtaser Coverage |
|---|---|---|
| Section 4 -- Proportionality | Risk analysis | Protection scores quantify risk proportionally |
| Section 9 -- Pre-outsourcing analysis | Outsourcing risk analysis | cloudtaser-cli target discover identifies secret-related risks |
| Section 12 -- Security of data | Data access controls | memfd_secret + eBPF enforcement |
| Section 13 -- Exit strategies | Exit strategy and portability | Cloud-agnostic OpenBao, no vendor lock-in |
| Section 15 -- Monitoring of outsourcing | Regular provider reviews | cloudtaser-cli target audit + protection scores |
Gaps and Limitations¶
| DNB Area | Gap | Mitigation |
|---|---|---|
| Governance framework | cloudtaser does not replace the institution's governance framework for outsourcing | cloudtaser provides technical controls and evidence. Governance frameworks are the institution's responsibility |
| Personnel requirements | DNB requires qualified staff to manage outsourcing relationships | Outside product scope. cloudtaser reduces the need for provider-specific expertise by standardizing secret management |
| Business continuity planning | DNB requires comprehensive BCP for outsourced services | OpenBao high availability and multi-cloud portability support BCP, but planning is the institution's responsibility |
| Full regulatory compliance | DNB has broad requirements beyond data protection | cloudtaser addresses the data sovereignty and secret management aspects. Other DNB requirements (capital adequacy, liquidity, governance) are outside scope |
| Non-secret data | cloudtaser protects secrets and encryption keys. Non-secret data in cloud storage is not directly protected unless encrypted via S3 proxy or DB proxy | Deploy S3 proxy and DB proxy for all sensitive data at rest. Use cloudtaser-protected keys for application-level encryption |
DORA supersedes some DNB requirements
Since January 2025, DORA (Regulation (EU) 2022/2554) directly applies to Dutch financial institutions and supersedes some DNB-specific requirements for ICT risk management and third-party provider risk. cloudtaser's DORA mapping covers these requirements. DNB's outsourcing guidelines remain relevant for areas not covered by DORA.
Audit Evidence¶
cloudtaser produces evidence suitable for DNB supervisory reviews:
# Generate compliance audit report
cloudtaser-cli target audit --secretstore-address https://vault.eu.example.com
# JSON output for regulatory evidence
cloudtaser-cli target audit --secretstore-address https://vault.eu.example.com -o json
The audit report provides:
- Protected vs. unprotected workload inventory (risk analysis evidence)
- Protection scores per workload (residual risk quantification)
- eBPF enforcement coverage per node (data access control evidence)
- EU OpenBao connectivity verification (key control evidence)
- Orphaned Kubernetes Secrets (data in US-controlled storage)