All docsDocumentation · Reference

AMBA security architecture.

Written for CISOs, sysadmins, and anyone asked to sign off on the security posture.

Principles

AMBA's security posture rests on three principles. Defence in depth. No single control is the last line. Audit everything. Nothing important happens without a traceable record. Fail closed. When a control is uncertain, the system denies rather than permits.

These principles are opinions, not policies. They shape the architecture, which is why they are stated here. Institutions with a security policy that disagrees on one of these should raise the difference during implementation. Most conflicts have a configuration answer.

Authentication

Passwords are hashed with bcrypt at cost factor 12 (4,096 iterations per verification). Plaintext passwords are never persisted, never logged, never included in any API response. Password hashes are stored in the users table and are readable only by the authentication service.

Failed login attempts increment a per-account counter. Five failures in succession lock the account for 15 minutes. The lock counter is per-user, tracked in the database, so it survives across server restarts and horizontal scaling. Successful login resets the counter to zero.

Authorisation (RBAC)

Frontend UI is filtered by role, but the server check is authoritative.

Role checks include row-level context where applicable. A Manager sees only employees in their reporting line; an Employee sees only their own record.

Server-enforced
Every authorisation decision happens on the backend, on every request. Hiding a button on the frontend does not authorise anything; it only hides the button. An attacker calling the API directly is checked identically to a legitimate UI user.

Session and tokens

Session tokens are JWTs signed with an HS256 key held in the server-side environment. Tokens are stored in httpOnly, Secure, SameSite=Lax cookies. Invisible to JavaScript and safe from basic CSRF vectors.

Encryption

Passwords are hashed with bcrypt. Password-reset tokens are stored only as SHA-256 digests.

Audit log

Audit rows include: actor user ID, action type, resource type and ID, before value (for updates), after value, timestamp, IP address, and any additional contextual payload the action provides. Your organisation should define retention requirements based on its policies and applicable law.

Data handling

Review the personal data your organisation needs, who may access it, and how long it should be retained. Confirm your deployment and operational policies against the data-protection requirements that apply to your organisation.

Employee records contain personal information. Your organisation should establish a process for handling access requests, verifying identity and reviewing the data before disclosure.

Your organisation is responsible for assessing breach-notification obligations. Record the applicable deadlines and owners in the compliance calendar; do not assume that AMBA automatically determines or fulfils legal obligations.

Incident response

AMBA IT tracks tickets with priority, ownership and status. Use these records to coordinate operational work and retain the history of actions taken.

Regulatory incident reporting requirements vary. Confirm any required reporting format, recipient and deadline with your compliance team; a ticket record alone does not constitute a statutory filing.

This document describes the AMBA security architecture at a level suitable for an institutional security review.