Version: April 2025
Applies to: All developers, system integrators, and applications accessing production databases
Aligned with: ISO/IEC 27001:2022 (A.5.16–17, A.8.2, A.8.9), FIPS 140-2

🎯 Purpose
To ensure database credentials are securely stored, retrieved, and isolated from program logic — minimizing the risk of credential exposure and database compromise.

📍 1. Scope
Applies to:
- All applications accessing production databases
- All environments (production, staging, development — especially where sensitive data may exist)
- All developers, engineers, and integrators deploying such systems

🛡️ 2. Secure Storage Requirements
- Credentials must NOT be stored in main code bodies or embedded in plaintext
- Use encryption per FIPS 140-2 (e.g., AES, RSA, ECC)

Permitted storage methods:
- In a separate configuration file (not world-readable/writable)
- On the database server (referenced by a hash or token in code)
- Within a secure authentication service (e.g., LDAP)

❌ Never store credentials in a web server's accessible file tree.

🔑 Database passwords must follow the organization's Password Policy.

⬇️ 3. Retrieval Requirements
- Read credentials just-in-time before DB use
- Purge credentials from memory immediately after use
- Store credentials in a dedicated file or module — separate from app logic
- For interpreted languages, keep credential files outside executable or browsable paths

🚫 4. Credential Sharing Rules
- Each application/function group must use its own unique credentials
- Credential sharing across programs is prohibited

Developers must implement a process to:
- Rotate credentials per policy
- Restrict access on a need-to-know basis
- Enforce least privilege on software-level access

⚖️ 5. Non-Compliance & Sanctions
Violations may result in:
- Training, written warnings, or access suspension
- Termination or legal action if security breaches or compliance failures result

All actions follow HR and cybersecurity enforcement protocols.