Security model

Ce contenu n’est pas encore disponible dans votre langue.

In short

SpeculaPro holds some of the most sensitive data an institution has: who its customers are, where their money goes, and which of them are under suspicion. Its security is built in layers, so that if one safeguard fails, the next still holds. A bank vault works the same way, with a guarded door, then a locked room, then individual locked boxes, and a logbook of everyone who entered.

 ┌─────────────────────────────────────────────────────────────────────┐
 │ 1. Who are you?        sign-in, MFA, sessions, API keys             │
 │  ┌───────────────────────────────────────────────────────────────┐  │
 │  │ 2. What may you do?   roles and permissions, separation of duty│  │
 │  │  ┌─────────────────────────────────────────────────────────┐  │  │
 │  │  │ 3. Whose data?   tenant isolation enforced by Postgres  │  │  │
 │  │  │  ┌───────────────────────────────────────────────────┐  │  │  │
 │  │  │  │ 4. The data itself   personal data encrypted      │  │  │  │
 │  │  │  └───────────────────────────────────────────────────┘  │  │  │
 │  │  └─────────────────────────────────────────────────────────┘  │  │
 │  └───────────────────────────────────────────────────────────────┘  │
 │ 5. What happened?      append-only audit log                        │
 └─────────────────────────────────────────────────────────────────────┘

The layers

Layer	Question it answers	In plain words	Read more
Authentication	Who are you?	People sign in with a password and an authenticator app, with a passkey, or through your own identity provider with single sign-on; recovery codes cover a lost phone; machines use API keys	Sign-in and MFA, Recovery codes, Passkeys, Single sign-on security, Sessions, API keys
Authorisation	What may you do?	Each person’s roles decide which screens and actions they get. Nobody can approve their own work	Who can see and do what
Tenant isolation	Whose data is this?	The database itself refuses to show one institution another’s data	Tenant isolation
Data protection	What if someone copies the database?	ID numbers, phone numbers and similar fields are encrypted, with a different key per institution	Data protection
Audit	What happened, and who did it?	Every significant action is written to a log that cannot be edited or deleted	Audit log

Plus the basics:

Encryption in transit. SpeculaPro can connect to PostgreSQL, Kafka and Redis over TLS, with certificate checking. You switch it on in production; the production checklist covers each connection. Browsers and API clients reach SpeculaPro over HTTPS through your load balancer or reverse proxy. See Production checklist.
Encryption at rest. Personal data is encrypted by SpeculaPro itself (the data protection layer above). Encrypting the disks and backups underneath is done by your database and storage platform.
Addresses that can’t be faked. The IP address recorded in the audit log and used to limit sign-in attempts is the connecting machine’s, or, behind your own load balancer, the one your proxy wrote, never one a caller writes into a header. Your operator sets this with SP_HTTP_TRUST_PROXY and SP_HTTP_PROXY_HOPS. See Configuration: HTTP server.
Your identity provider, if you want it. Single sign-on with OpenID Connect or SAML 2.0, with signed assertions, PKCE, replay protection and break-glass administrators, and optionally required for everyone. See Single sign-on security.
No secrets in the code. Passwords, keys and connection strings come from settings or your secret manager, never from the source code.

Who can see and do what

Every workspace starts with a set of system roles. They are designed around separation of duties: the person who writes a rule can’t approve it, an analyst can’t close a high-risk case alone, and auditors can look but not touch.

Role	Can typically…	Cannot…
Analyst	See alerts and cases, work cases, view customers (without full personal data), propose suppressions, draft reports	Close cases, see full personal data, approve anything
Senior analyst	Everything an analyst can, plus close cases, view full personal data, manage risk designations	Approve rules, suppressions or reports
MLRO / Compliance officer	Work, close and approve cases; approve rules, suppressions and reports; submit reports; manage lists and designations; read the audit log	Manage users or API keys
Rule author	Write and edit rule versions	Approve rule versions
Rule approver	Approve or reject rule versions	Write rules
Auditor (read-only)	See alerts, cases, customers, rules and the audit log	Change anything
Administrator	Manage users, API keys, settings, webhooks and single sign-on; read the audit log	Work cases or approve rules

Four-eyes rules enforced by the database

For the most sensitive actions, “someone else must approve” is enforced by the database itself, not only by the web app. Each of these records stores who created it and who approved it, and the database rejects any record where the two are the same person:

A rule version cannot be approved by the person who created it.
A suppression cannot be approved by the person who created it.
A high-risk case closure needing approval cannot be approved by the person who closed it.
A regulatory report cannot be approved by the person who wrote it.

SpeculaPro’s own staff

On the hosted service, the people who run SpeculaPro have no standing access to what is inside your workspace. Their console shows a workspace’s name, plan, usage counts and health, not its cases, alerts, customers or transactions. To look inside, a member of staff must ask, and someone in your workspace must approve: for a stated reason, a scope and a limited time. The session is read-only, never shows reports, and every read is in your audit log. See Support access security. A self-hosted installation has no such access at all.

What this means for you

Assign roles deliberately. Give people the smallest role that lets them do their job. Very few people should hold MLRO or administrator.
Keep MFA on. Workspaces require multi-factor authentication by default.
Treat API keys like passwords. See API keys.
On the hosted service, decide your support access policy. Leave full read off unless a case needs it, and read the audit log after each access. See Support access.
Self-hosters: you own the encryption keys and the infrastructure. See Data protection.