Cloud services keys should not be visible or hardcoded

Data store connection details (databases, queue systems, and more) is a high profile and sought-after piece of sensitive information in hacker communities.

Even if these access detail and connection strings are RBAC protected or minimal-access based or these systems are covered in the internal network, once these are exposed, you still have a tiring job of tracing, locating, rotating and observing the implication of rotating such keys. Keeping them stored safely and securely minimizes your productivity loss.

Not only that, the notion of visible access details (for example passwords), even if inside an internal networks is problematic -- hackers can learn common password patterns, if credentials are machine generated, and develop smart and efficient brute-forcing strategies.

Problem

Data store provider keys (self hosted, self provisioned or dedicated instances) are hardcoded or exposed in configuration files, infrastructure code, or business services.

Fix

Infrastructure

1. Use a cloud-native secret store, such as AWS Secrets Manager
2. Use a dedicated vault product, such as:
   1. CyberArk Vault
   2. Hashicorp Vault

Architecture

1. Prefer a 12-factor architecture
2. Use secret-loading libraries like .env for your specific tech stack

See

• CWE 798 on hardcoding