People and access
Summary. TrustBridge manages the people who work with it on behalf of an organization: staff using the management application, partner representatives in the partner portal, approvers, and auditors. A person is invited, sets up a personal key and a second factor when registering, and is given roles that define what they may do. When someone leaves, one action deactivates them, and every session they have ends at once. Events that call for action – an approval that is waiting, a certificate about to expire, a burst of failed sign-ins – reach the people responsible as notifications, with reminders and escalation. Every step is recorded in the security audit log. TrustBridge controls access to itself; it is not an identity provider for other applications.
Terms
- Person – someone who operates TrustBridge; the person and their history remain on record even after their access ends.
- Account – a person's access to one organization, with personal key, second factor, and roles.
- Personal key – the bearer secret a person signs in with; details in Interfaces and integration.
- Second factor – a one-time code from an authenticator app, as defined in RFC 6238 (TOTP).
- Role – a named set of permissions within an organization.
- Incompatible roles – two roles that the same person may not hold at the same time.
- Notification – a message to people about an event, sent through a configured channel.
- Escalation level – a notification to a wider group of recipients when a matter is still open after a set time.
Lifecycle of a person
stateDiagram [*] --> Invited : invitation created Invited --> Lapsed : not redeemed within 72 hours Invited --> Active : registration with key and second factor Active --> Locked : five failed attempts Locked --> Active : after 15 minutes or unlocked Active --> Deactivated : leaves Locked --> Deactivated : leaves Deactivated --> Invited : invited again Lapsed --> [*]
| Step | Who | What happens |
|---|---|---|
| Invitation | someone with the people management role | The invitation names the organization and the roles. It goes to the invitee as a link and a QR code, is valid for 72 hours, and can be used once. |
| Registration | the invitee | They redeem the invitation. Their personal key is created and stored in the credential store of their Windows account. |
| Second factor | the invitee | They scan a QR code with their authenticator app and confirm with the first code. Only then is the account active. |
| Approval key | approvers, together with two people in the security management role | Anyone who is to approve also receives an approval key on dedicated hardware. It is entered in the CA worker's rule set, not in the account. |
| Deactivation | people management | The account is locked, all sessions end, and the personal key is invalidated. If the person is an approver, a change to the rule set removes their approval key. |
| Return | people management | Only through a new invitation. Neither the old key nor the old second factor is restored. |
After deactivation the person remains on record with their name and events, so the security audit log can still answer years later who held which permissions and when. Deactivating a person does not affect system certificates: those belong to systems, not to people.
Sign-in and lockout
People sign in with their personal key and second factor or, in Windows domains, through Kerberos; the flow and its security analysis are in Interfaces and integration. These measures also guard against guessed codes and stolen keys:
| Protection | Setting |
|---|---|
| Account lockout | 15 minutes after five failed attempts |
| Limit per source | Sign-in attempts per network address and hour are capped; above the cap, requests are refused before any key or code is checked |
| Comparison | Codes and keys are compared in constant time |
| Storage | Keys and second-factor secrets are stored only as hashes or encrypted, and never appear in any log |
| Session | 8 hours, sign-out after 30 minutes of inactivity; every new session gets a new identifier |
| Sign-out | ends the session on the server before the application discards it |
Programs don't sign in with an account. They use a client certificate from the organization's own certificate authority; their permissions are tied to the certificate, with no person in between.
Roles
Roles apply per organization. A person can hold several roles, including in more than one organization – as an employee of an operating partner, for example.
| Role | May |
|---|---|
| People management | invite and deactivate people, assign roles, lift a lockout |
| Security management | reset second factors, enter and remove approval keys in the rule set (two people together), set up notifications |
| Request management | propose and cancel orders, file revocation orders, read the inventory |
| Approver | approve orders with their own approval key, where the rule set names that key for the profile class |
| Partner management | change relationship policies; every change takes two people in this role |
| Auditor | read the ledger, security audit log, and connection log, and create extracts |
Incompatible roles. Whoever audits doesn't administer what they audit: the auditor role is
incompatible with people management and with security management. An attempt to give someone an
incompatible role is refused with 409 and noted in the security audit log. The four-eyes principle for
issuance isn't enforced by role management but by the CA worker, through the approval rule of each
profile class; see PKI and certificate lifecycle.
Every assignment, every removal, and every refused attempt is recorded in the security audit log. Permissions are checked on every request, so a removed permission takes effect with the next one.
Resetting a second factor and lifting a lockout
Both give an attacker a way in if the identity of the person asking is not established. TrustBridge therefore requires each of these actions to state how identity was verified, and records it in the security audit log. People management lifts a lockout after a plausible check; security management resets a second factor after a strict check, and all of the person's sessions end. Without details of the check, the call is refused.
The steps are in Lift a person's lockout and Reset a person's second factor.
Notifications
TrustBridge notifies the people responsible as soon as an event calls for action. Content and delivery are defined in templates and channels, not in the program, so new recipients or revised wording don't require a new version.
| Event | Recipients |
|---|---|
| Invitation created | the invitee; the person who invited them, for information |
| Registration completed | the new person; people management |
| Second factor reset | the person concerned; security management |
| Approval waiting | approvers for the profile class |
| Approval completed, certificate issued | the requester |
| Certificate expires in 30 days | the people responsible for the system; request management |
| Certificate revoked | the people responsible for the system; security management |
| Burst of failed sign-ins (five within an hour) | the person concerned; security management |
| Suspected compromise of a CA | information security, operations lead, security management |
| Broken chain in the security audit log | information security, operations lead |
| Property | Setting |
|---|---|
| Channels | email; tickets in ServiceNow or Request Tracker; a webhook to any system; Microsoft Teams and Slack; Signal for critical alerts. Several channels can be used at once. |
| Recipients | a fixed list, everyone with a given role, the people responsible for a certificate, the person who triggered the event, or their manager from the organization's directory |
| Language | the person's language setting, otherwise the organization's default language; templates in German, English, and Slovenian |
| Threads | messages about one matter form a conversation: the reminder and the completion of an approval appear as replies to the first message |
| Escalation | levels at set intervals, for example a reminder after one hour, the manager after four hours, security management after one day; the sequence stops when the matter is closed |
| Limits | per channel and per recipient and hour; identical messages within five minutes are combined; quiet hours per person |
| Critical alerts | are never limited or combined, have a path of their own, and can't be unsubscribed from |
| Channel credentials | only from the secret store, never in a configuration file |
| Content protection | values in templates are escaped; line breaks in subject and recipients are rejected |
| Evidence | sending, failure, escalation, and limiting are recorded in the security audit log, with subject and recipients; of the body, only a hash |
Before going live, any template can be rendered with sample data without sending, and sent to a test address.
Reviewing sign-ins
Every person's sessions and sign-ins are part of the chained security audit log; see Audit and evidence. Auditors analyze them without database access: sessions per person and period, open sessions, failed attempts per source, unusual access, and whether the chain is complete. Every review leaves an entry of its own. More than 50 failed sign-ins from one source within an hour block that source and notify security management; a broken chain is reported to the operations lead immediately.
Which query answers which question is shown in Review sign-ins.
What people and access don't cover
- No identity provider for other applications. Sign-in to ERP, the Database Gateway, or other applications stays with them; TrustBridge supplies a verified partner identity for systems, not a sign-in for people.
- No passwords and no bearer tokens. People sign in with a personal key and second factor or through Kerberos; the reasons are in Interfaces and integration.
- No certificates for people. Certificates belong to systems and services; see Deployment scenarios.
- No HR data management. Managers and departments come from the organization's directory; TrustBridge only reads them for notifications.