docs/pages/technology/security_model.rst
.. _security-model:
Security Model
##############
This document is aimed at the following readers:
- Developers who want to contribute to the Nuts node: which security aspects they need to consider and which not.
- Operators who want to deploy the Nuts node: which security aspects are covered by the Nuts node, and which need to be addressed somewhere else.
- Security officers who need to assess the Nuts node: to get a view on how security is handled in the Nuts node.
The Nuts node's security model aims to provide non-repudiation of operations invoked by clients, integrity and confidentiality of data.
It focuses on:
- interactions of users (e.g. system administrators) and client applications with the Nuts node APIs,
- security of assets managed by the Nuts node (e.g. private keys).
It does not cover interactions between Nuts nodes and systems specified by the `Nuts specifications <https://nuts-foundation.gitbook.io/drafts/>`_;
these are covered in the Nuts Start Architecture or respective RFCs.
It also does not cover interactions specified by Nuts use cases.
Threat Model
************
The following are part of the threat model:
- Protecting against accidental (unsafe) misconfiguration of the Nuts node.
- The system should help operators setup safe configuration, by enforcing secure defaults and hard-failing for incorrect (e.g. misspelled) configuration.
- Implemented by:
- Providing secure defaults for configuration.
- Providing "strict mode" which disallows unsafe configuration.
- Protecting against leaking private key material.
- Private keys should be kept secure, since a leak compromises a party's presence on the Nuts network.
- Implemented by:
- Storing keys in a secure storage (e.g. Hashicorp Vault).
- Not allowing private keys to be exported, only to be created and used (signing/encrypting).
- Protecting against repudiation.
- Administrative actions, data alterations and usage of private keys must be accountable.
- Implemented by:
- Writing these events to the audit log.
The following are not part of the threat model:
- Protecting against unauthorized database access.
- If an attacker can inject/modify Nuts node database records (e.g. verifiable credentials), confidentiality of data might be compromised.
- Protecting against arbitrary access to the Nuts node host machine.
- If an attacker has root access, integrity of configuration is lost and the attacker can alter security settings (e.g. inject authorized API client keys).
- Why don't we protect against it:
- In such circumstances, the attacker can use the system as stepping stone to attack other systems, e.g. the key storage or the client application.
This makes mitigation unfeasible: there's always another way the compromised system can be exploited.
- High cost: requires implementation in a language that provides full control over application memory (e.g. C, C++ or Rust).
- Unpractical: requires hardening of host OS to avoid memory dumps/debugging, which is not feasible for all some environments (cloud, Windows).
- Protecting against inspection of the Nuts node process.
- If an attacker can inspect the memory of the Nuts node process, confidentiality might be private keys lost.
- Why don't we protect against it: same reasons as for an attacker with root access.
- Protecting against eavesdropping and tampering of internal network traffic between reverse proxy and Nuts node.
- Why don't we protect against it:
- It's highly dependent on the deployment environment.
- It can still be implemented by the operator.
- Protecting against denial of service (DoS) attacks on interfaces that use HTTP.
- If an attacker can execute expensive operation on HTTP interfaces, it could cause unavailability of the Nuts node.
- Why don't we protect against it:
- It's highly dependent on the deployment environment.
- This is typically handled by existing DoS protection measures (e.g. in reverse proxy) of the operator.
External threats
^^^^^^^^^^^^^^^^
A typical Nuts Node deployment consists of various parts:
- External API clients:
- Remote client application
- Internal API clients:
- Client application and administrative system
- Monitoring system
- Reverse proxy for HTTPS (terminates TLS)
- Nuts Node
- Data stores:
- SQL database
- Private key storage
External actors are remote Nuts nodes and remote applications.
The Nuts node depends on a correct reverse proxy configuration to protect against external threats.
All endpoints that are published by the node always use HTTPS.
The Nuts node itself does not protect against DoS attacks; the proxy infrastructure routing external traffic to the node will have to protect against this.
Internal threats
^^^^^^^^^^^^^^^^
Internal traffic to the Nuts node does not, by default, use TLS to protect against eavesdropping or tampering.
It does allow token authentication to be configured (strongly suggested) to protect against unauthorized access and making sure API operations are accountable.
It's not possible to export private keys from the Nuts Node through the APIs: it only allows usage of keys (signing/encrypting), not exporting them.