Cloud Credential Security: Encryption at Rest Done Right

When you connect a FinOps platform to your cloud accounts, you hand over credentials that can read (and sometimes modify) your entire infrastructure. Access keys, role ARNs, service principal secrets, service account JSON keys — these are the crown jewels of your cloud environment.

How the platform stores those credentials is not a secondary concern. It's the most important security decision you'll make about the integration.

Why Credentials Are High-Value Targets

Cloud credentials are uniquely dangerous because of their blast radius. A compromised database password exposes one database. A compromised AWS access key exposes every resource in the account — EC2 instances, S3 buckets, RDS databases, Lambda functions, IAM policies.

For FinOps platforms specifically, the risk is amplified because:

• Multi-account access: A single FinOps tool typically holds credentials for multiple AWS accounts, Azure subscriptions, or GCP projects
• Cross-cloud exposure: If the platform supports AWS, Azure, and GCP, a breach of the credential store compromises all three clouds simultaneously
• Long-lived credentials: Unlike session tokens, the access keys stored for cost data syncing are often long-lived and rarely rotated

Common Mistakes

These are the credential storage anti-patterns we see most frequently in cloud tools:

1. Plaintext storage. Credentials stored as plain strings in a database or configuration file. If the database is breached, every credential is immediately usable. This is more common than you'd expect, especially in internal tools built by engineering teams without a security review.

2. Shared encryption key. All credentials encrypted with a single static key. If the key is compromised, every credential is decryptable in one operation. The attacker doesn't need to crack anything — they just decrypt the entire table.

3. Weak algorithms. Using DES, 3DES, or AES-128 when AES-256 is available at no performance cost. Or using ECB mode, which leaks patterns in encrypted data.

4. Key in source code. The encryption key hardcoded in the application source, committed to a Git repository. Anyone with repo access has the key.

AES-256-GCM vs AES-256-CBC

Both use AES with a 256-bit key. The difference is the mode of operation.

AES-256-CBC (Cipher Block Chaining) encrypts data in blocks, chaining each block to the previous one. It provides confidentiality but not integrity. An attacker can modify the ciphertext without detection — known as a padding oracle attack.

AES-256-GCM (Galois/Counter Mode) provides both encryption and authentication in a single operation. It produces an authentication tag alongside the ciphertext. Any modification to the encrypted data — even a single bit — is detected during decryption.

GCM wins for credential storage because:

• Tamper detection: If an attacker modifies the encrypted credential in the database, GCM detects it. CBC does not.
• No padding oracle: GCM is a stream cipher mode — no padding, no padding oracle attacks.
• Performance: GCM is parallelizable and typically faster than CBC on modern CPUs with AES-NI instructions.
• Single pass: Encryption + authentication in one operation, vs CBC requiring a separate HMAC step for integrity.

Per-Credential Random Salt

Even with AES-256-GCM, if you encrypt two identical credentials with the same key and IV (initialization vector), you get identical ciphertext. An attacker can identify duplicates without decrypting anything.

The solution: generate a unique random salt for each credential. This salt is used to derive a unique encryption key for that specific credential, even when the master application secret is the same.

The practical impact:

• Two identical AWS access keys stored for different accounts produce completely different ciphertext
• Compromising one credential's encryption provides zero information about any other credential
• Brute-force attacks must be repeated per credential — they can't be parallelized across the dataset

Key Derivation from App Secrets

The encryption key should never be stored directly. Instead, derive it at runtime from the application's secret configuration using a key derivation function (KDF) like PBKDF2 or HKDF.

The derivation chain looks like this:

Application secret + Per-credential salt → KDF → Unique encryption key → AES-256-GCM → Encrypted credential

This means the encryption key exists only in memory during the encryption/decryption operation. It's never written to disk, never logged, never stored in a database.

Credential Rotation Strategies

Encryption at rest is necessary but not sufficient. Credentials also need rotation — and rotation needs to be non-disruptive.

Provider-side rotation: Rotate the actual cloud credentials (access keys, service principal secrets) on a schedule. AWS recommends every 90 days. This limits the exposure window if a credential is compromised.

Encryption-side rotation: When you change the application secret or upgrade the encryption algorithm, all stored credentials need to be re-encrypted. This should be an atomic operation — decrypt with the old key, re-encrypt with the new key, verify, then commit.

Version tagging: Store the encryption version alongside each credential. This allows gradual migration — credentials encrypted with v1 are decrypted with v1 and re-encrypted with v2 on next access, without requiring a bulk migration.

How CLARITY Implements It

CLARITY's credential storage uses what we call the AES-256-GCM v2 scheme:

• Algorithm: AES-256-GCM (authenticated encryption)
• Salt: Cryptographically random, unique per credential, generated at encryption time
• Key derivation: PBKDF2 from application secret + per-credential salt
• Storage format: Version tag + salt + IV + ciphertext + auth tag (all stored together, only decryptable with the application secret)
• At rest: Credentials are never stored in plaintext. Not in the database, not in logs, not in backups.
• In transit: All API communication uses TLS 1.2+. Credentials are decrypted only at the moment of use for cloud API calls.

Because CLARITY is a managed SaaS platform, the application secret is managed through our deployment infrastructure — isolated from the database, rotatable without downtime, and never exposed to customer-facing APIs.

8 Questions to Ask Your FinOps Vendor About Credential Handling

Before connecting your cloud accounts to any FinOps platform, ask these questions:

1. What encryption algorithm do you use for credential storage? Acceptable: AES-256-GCM or AES-256 with separate HMAC. Red flag: "We use the database's built-in encryption."
2. Do you use a unique salt per credential? If the answer is no (or blank stare), identical credentials will have identical ciphertext.
3. Where is the encryption key stored? Acceptable: derived at runtime from a secrets manager. Red flag: in the database, in a config file, or "I'll check with engineering."
4. Can I rotate my cloud credentials without downtime? The platform should handle re-authentication seamlessly.
5. What happens to credentials when I disconnect an account? They should be permanently deleted, not just soft-deleted or flagged inactive.
6. Are credentials visible to your support team? They should not be. Even internal access should only yield encrypted data.
7. Do you log credential values in application logs? This should be a hard no. Check if they mask or redact credentials in error logs.
8. What's your encryption version migration process? When the algorithm is upgraded, how are existing credentials re-encrypted?

Related reading: See our latest security and AI analysis improvements in the CLARITY S52 Release Notes. For understanding how cost accuracy and security intersect, read Multi-Cloud Cost Management: Why 99.7% Accuracy Matters.