Vault credentials: the model

Outcome

By the end of this lesson, you will be able to describe how ZopNight stores cloud credentials and explain the four properties of the vault model.

1. Concept

Every connected cloud account comes with a credential: an AWS role, a Google service account, an Azure service principal. ZopNight has to keep that credential somewhere and use it to talk to your cloud.

Where it keeps it is called the vault, and four things are true of it.

1. It is encrypted, with a key kept somewhere else

Credentials are stored encrypted, using AES-256-GCM. The key that unlocks them is held by a separate service, not alongside the records. A credential is decrypted at the moment it is needed, used for that one call, and dropped from memory.

The choice of cipher is worth one sentence. GCM does two jobs at once: it keeps the credential unreadable without the key, and it makes tampering detectable, so nobody can quietly alter the stored value. It is the current standard for this, and ISO 27001 and SOC 2 Type II auditors accept it.

2. One customer’s credentials cannot reach another

Every organisation’s credentials live in their own space. Nothing in the code can read, decrypt or use organisation A’s credential while acting for organisation B. Two separate mechanisms enforce that.

• In the database. Every credential row is keyed by organisation, and every query filters on it.
• In the service. The gateway works out which organisation the caller belongs to before the request goes anywhere, so a query that crosses organisations cannot be formed.

Software serving many customers from one system has well-known ways of leaking data between them: a query that forgets to filter, an ID somebody can guess and increment, a cache shared by mistake. Each of those is closed here deliberately.

3. You can replace a credential without breaking anything

Customers can rotate a credential at any time without affecting in-flight operations. The rotation flow:

1. Customer creates a new IAM role / service account / SPN in their cloud
2. Customer adds the new credential to ZopNight (via Cloud Accounts UI)
3. The new credential is validated against the cloud provider's auth endpoint
4. If validation passes, the credential is written to the vault
5. The OLD credential is marked deprecated but kept available for 24 hours
6. New discovery runs use the new credential immediately
7. After 24 hours, the old credential is deleted from the vault

The 24-hour overlap exists so that a schedule already running, or a scan already under way, can finish before the old credential vanishes. Replace credentials every quarter and nothing ever goes down.

4. You can revoke one instantly

Revoking marks the credential dead on the spot. Anything that tries to use it afterwards fails, and fails visibly: the account’s permission panel says “Credential revoked” with the time it happened, rather than quietly reporting a smaller estate.

Revoking cannot be undone. You create a new credential and connect it to the same account.

That is deliberate. Revoking is something you do when you think a credential may have got out, not a setting you flip back and forth. Once it is revoked, the assumption is that somebody else may have a copy.

What the customer sees

The vault model is mostly invisible. The Cloud Accounts page shows:

• Account name, provider, and region
• Connection status (active / degraded / revoked)
• Last successful sync timestamp
• A “Rotate credential” action
• A “Revoke credential” action
• A “View Permissions” drawer (covered in L4)

What you never see is the credential itself. You cannot export it, and you cannot read it back after you submit it. If you lose your copy, your cloud provider is the only place to get another. ZopNight can confirm the credential works; it has no way to show it to you.

What ZopNight’s own engineers cannot do

They cannot read it either. The key that decrypts the vault is not reachable from the tools engineers use.

When a production problem genuinely needs credential access, there is a written emergency procedure that requires more than one person to approve, and every use of it is recorded in the security audit trail. That record is part of what SOC 2 evidence consists of.

2. Demo

The credential lifecycle in one timeline:

T+0       Customer creates IAM role in AWS Console
T+1 min   Customer pastes role ARN + external ID into ZopNight Cloud Accounts page
T+1 min   ZopNight calls AWS STS AssumeRole to validate
T+1 min   STS returns temporary credentials: validation passes
T+2 min   The role configuration is encrypted (AES-256-GCM) and stored
T+2 min   A "discovery preview" sync runs to confirm the credential can read
T+5 min   Customer sees the account marked Active in the UI
T+5 min   Permission Visibility drawer populates with Granted/Denied per service
T+6 hr    First scheduled discovery sync runs successfully
T+91 day  Customer rotates: adds new role, old role expires after 24h overlap

Five minutes to active. Six hours to first scheduled sync. Rotation is a 24-hour overlap with no downtime.

3. Hands-on (5 min)

This hands-on is a security-review walkthrough rather than a code task. Open ZopNight Cloud Accounts (or look at the Cloud Accounts page in a screenshot).

1. Click any connected account.
2. Confirm you cannot see the underlying credential value (only an
   identifier: role ARN, service account email, app ID).
3. Note the "Rotate credential" and "Revoke credential" actions.
4. Open the "View Permissions" drawer (covered fully in L4).
5. Check the "Last sync" timestamp. Should be within the last 6 hours.

If any element is missing or behaves unexpectedly, escalate. The
vault model has specific guarantees and any deviation is a bug.

4. Knowledge check

Q1

A Security team asks: “What happens to a credential after rotation?” Most accurate answer:

A. It is immediately deleted
B. It is archived indefinitely in the vault, so that it can be restored if the account is ever reconnected later
C. It is marked deprecated and kept available for 24 hours so in-flight operations can complete, then deleted from the vault
D. It is encrypted again

Q2

A Security team asks: “Can a ZopNight engineer decrypt our credential to help debug?” Most accurate answer:

A. Yes, on request
B. No
C. Only for premium customers
D. Yes, after written consent

Q3

A team revokes a credential by accident. The right recovery procedure is:

A. Create a new credential in the cloud provider and connect it
B. Un-revoke through the UI
C. File a support ticket to restore
D. The credential is unrecoverable, recreate the cloud account

5. Apply

To audit the vault model on your own deployment:

• Cloud Accounts page: confirm credential values are not exposed
• Audit Logs page; filter to credential-related events to see rotation, revocation, and permission changes
• Security review documentation: request the SOC 2 Type II report + ISO 27001:2022 certificate from ZopNight Trust Center

Related lessons

• L2: AWS IAM policy (next)
• L4: Permission Visibility
• T3.M3.3: Audit logging

Glossary terms touched

AES-256-GCM · Vault · Per-org isolation · Credential rotation · Break-glass procedure