自动化平台需复用可逆服务账号密码的数据库存储最佳实践咨询

Great question—storing reversible credentials safely is a common pain point for automation platforms, and your concern about plaintext is totally valid. Let’s break down the best practices tailored to your scenario:

1. Use Strong Symmetric Encryption with Authenticated Modes #

Since you need to recover the plaintext password, one-way hashing isn’t an option—you’ll need symmetric encryption (same key for encrypting and decrypting). The gold standard here is AES-256-GCM:

• AES-256 is a NIST-approved strong algorithm, resistant to brute-force attacks.
• GCM (Galois/Counter Mode) provides both encryption and integrity verification, so you can detect if the encrypted data has been tampered with.

Example snippet (Python using the cryptography library):

from cryptography.fernet import Fernet
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
import os
import base64

# Generate a secure key (do this once, store it in a KMS, NOT in code!)
salt = os.urandom(16)
kdf = PBKDF2HMAC(
    algorithm=hashes.SHA256(),
    length=32,
    salt=salt,
    iterations=480000,
)
# Derive key from a root secret fetched from your KMS
root_secret = b"your-root-secret-from-kms"
key = base64.urlsafe_b64encode(kdf.derive(root_secret))
fernet = Fernet(key)

# Encrypt password
encrypted_password = fernet.encrypt(b"plaintext-service-password")

# Decrypt password (only when absolutely needed)
decrypted_password = fernet.decrypt(encrypted_password)

2. Separate Encryption Keys from Encrypted Data #

The biggest mistake here is storing the encryption key in the same database as the encrypted passwords. Instead:

• Use a dedicated Key Management Service (KMS) like HashiCorp Vault, AWS KMS, or Azure Key Vault. These services handle secure key storage, rotation, and granular access control.
• If you can’t use a managed KMS, store the key in a separate secure location—like an encrypted config file with restricted filesystem permissions, or a hardware security module (HSM).
• Never hardcode keys in your application code or commit them to version control (Git, etc.).

3. Enforce Least Privilege Access #

Build on your existing role-based account structure with strict access controls:

• Restrict database access to the encrypted password column only to the specific automation service accounts that need to decrypt them. Even DBAs shouldn’t have read access to this column.
• Limit KMS key access to only the service identities that perform decryption operations. Use IAM roles or service accounts to enforce this.
• Log all decryption attempts (who, when, which credential was accessed) and set up alerts for unusual activity (e.g., sudden spikes in decryption requests).

4. Implement Key Rotation #

Keys shouldn’t be static—rotate them regularly (e.g., every 90 days) to limit the impact if a key is compromised:

• When rotating keys, keep the old key active until all existing encrypted data is re-encrypted with the new key.
• Most managed KMS platforms automate rotation out of the box—take advantage of that.
• Avoid reusing keys across different credential types or environments (dev vs. prod).

5. Avoid Storing Credentials Altogether (If Possible) #

Whenever you can, eliminate the need to store reversible passwords:

• Use OAuth 2.0 or service-to-service API keys instead of traditional passwords—many services support this for automated access.
• Use temporary credentials (e.g., AWS STS, Azure AD Managed Identities) that expire after a short window. This way, you never store long-term passwords at all.
• For on-prem systems, consider using SSH keys or certificate-based authentication instead of passwords.

内容的提问来源于stack exchange，提问作者EndOfAll