Security and compliance¶
Credential security¶
| What | Method |
|---|---|
| User passwords | Argon2id hash |
| Connection secrets at rest | AES-256-GCM, with a key derived via HKDF |
| Refresh tokens | SHA-256 hashed, 7-day expiry, rotated on each use |
| Access tokens | Signed JWT, 30-minute expiry |
| Account lockout | 5 consecutive failed logins locks the account for 15 minutes |
Connection secrets — the password field on a data source connection — are never logged and are only ever decrypted in memory when a Worker needs them to open a connection.
Inter-service communication¶
| Boundary | Method |
|---|---|
| UI → Gateway | A session JWT or an API key |
| Gateway → Workers | Mutual TLS in production; both sides present certificates signed by a shared certificate authority. Falls back to plain HTTP only when no TLS environment variables are set (local development) |
| Gateway → PostgreSQL | SSL, with client-certificate authentication supported |
Audit trail¶
Every create, update, delete, login, logout, password change, and encryption-key rotation is recorded in an audit log, with the account, user, action, affected resource, a JSON details blob, the request's IP address, and a timestamp. Audit records are retained for a configurable number of months (12 by default) and then automatically dropped.
Account lockout¶
After 5 consecutive failed login attempts, an account is locked for 15 minutes. A successful login resets the counter. This applies to internal password authentication; Entra ID SSO sign-ins are governed by your organization's own Entra ID conditional access policies instead.
Rate limits¶
| Endpoint area | Limit | Scope |
|---|---|---|
| Sign-in | 5 per minute | Per client IP |
| Running checks | 10 per minute | Per account |
| Everything else | 200 per minute | Per account, or per IP if unauthenticated |
Exceeding a limit returns a "too many requests" response with a
Retry-After header telling the client when to try again.
Soft delete¶
Accounts and users are never hard-deleted through the normal delete action — a deletion timestamp is set instead, and the record is retained for compliance and audit-trail integrity. This also means a deleted account or user can be recovered if the deletion turns out to be a mistake.
Data residency¶
CatalystData does not send your data to any third-party service. Data source credentials and any data read from your connected sources during a check run stay within CatalystData's own infrastructure and are never forwarded elsewhere. If your organization has specific data residency requirements, talk to your CatalystData contact.