Secure Database Credential Handling Policy
Database1.0 authentication credentials are a necessary part of authorizing application to connect to internal databases. However, incorrect use, storage and transmission of such credentials could lead to compromise of very sensitive assets and be a springboard to wider compromise within the organization. Purpose
This policy statesestablishes the mandatory requirements for securely storingstoring, retrieving, and retrievingmanaging database authentication credentials (usernames and passwordspasswords) (i.e., database credentials) for useused by a program that will access a database running on one of <Company Name>'s networks.
Softwaresoftware applications running on <Company Name>'s networks may require access to one of the many internal database servers. In order to access these databases, a program must authenticateconnecting to the databaseorganization's bydatabases. presentingImproper acceptablehandling credentials.of If thethese credentials areposes improperlya stored,significant thesecurity credentialsrisk, may be compromisedpotentially leading to aunauthorized database access, compromise of thesensitive database.data, and broader system compromise. The purpose is to prevent credential exposure within source code, configuration files, or insecure storage locations.
2.0 Scope
This policy is directed at all system implementer and/or software engineers who may be coding applications that will access a production database server on the <Company Name> Network. This policy applies to all system implementers, software (programs,engineers, modules,developers, libraries or APIS that will access a <Company Name>, multi-user production database. It is recommended that similar requirements be in place for non-production serversadministrators, and lapany environmentspersonnel since they don’t always use sanitized information.
General
In order to maintain the security of <Company Name>'s internal databases, access by software programs must be granted only after authentication with credentials. The credentials used for this authentication must not resideinvolved in the main,design, development, deployment, or maintenance of software applications (including programs, modules, libraries, scripts, or APIs) that access production databases operating on the organization's networks. While primarily focused on production environments, applying these principles to non-production and lab environments is strongly recommended due to the potential presence of sensitive data.
3.0 Policy Statements
Applications accessing organization databases must authenticate using credentials handled according to the following requirements:
3.1 Credential Storage Prohibitions
* Database credentials (usernames and passwords) **must not** be stored in clear text within the main executing body of thean program'application's source codecode.
* inCredentials clear text. Database credentials **must notnot** be stored in afiles locationor thatlocations candirectly beaccessible accessed throughby a web server.server (e.g., within the web server's document root or browseable directories).
* Credentials **must not** be embedded directly within compiled application binaries where they could be easily extracted.
3.2 Approved Credential Storage Methods
SpecificAcceptable Requirementsmethods for storing database credentials include, but are not limited to:
*
**SecureStorageConfiguration ofFiles:** DataStoring Base User Names and Passwords
Database user names and passwords may be storedcredentials in a separate configuration file separate fromoutside the executing body of the program'application's code.source code and web-accessible directories. This file must have restricted file system permissions (not be world world-readable or writeable.
Databaselimiting access strictly to the application's service account or authorized processes. The credentials maywithin residethis onfile should ideally be encrypted or protected using operating system mechanisms.
* **Secrets Management Systems:** Utilizing dedicated secrets management solutions (e.g., HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) designed for secure storage, retrieval, and rotation of credentials and secrets. This is the databasepreferred server.method.
* In**Environment thisVariables:** case,Passing acredentials hashvia functionsecure numberenvironment identifyingvariables accessible only to the credentialsapplication process, configured through secure deployment mechanisms.
* **Integrated Authentication / Service Accounts:** Leveraging integrated authentication mechanisms (e.g., Windows Authentication for SQL Server, Oracle OS Authentication [carefully configured], Kerberos) where the application authenticates using the operating system identity of its service account, eliminating the need to manage separate database passwords within the application context.
* **Authentication/Entitlement Servers:** Utilizing centralized authentication services (e.g., LDAP, Active Directory) where database access may be storedgranted inbased on user or service authentication managed by the executingcentral bodyserver, ofpotentially reducing the program's code.
Database credentials may be stored as part of an authentication server (i.e., an entitlement directory), such as an LDAP server used for user authentication. Database authentication may occur on behalf of a program as part of the user authentication process at the authentication server. In this case, there is no need for programmaticdirect usecredential ofhandling databaseby credentials.the application itself. (Note: Specific implementation details must be secure).
Database3.3 credentialsSecure mayCredential notRetrieval resideand Handling in the documents tree of a web server. Code
Pass* throughWhen authentication (i.e., Oracle OPS$ authentication) must not allow access to the database based solely upon a remote user's authentication on the remote host.
Passwords or pass phrases used to access a database must adhere to the Password Policy.
Retrieval of Database User Names and Passwords
If stored in a file that is not source code, then database user names and passwordscredentials must be read from thea configuration file or other source, they should be retrieved immediately prior to use.establishing Immediately followingthe database authentication,connection.
* Once the database connection is established, the memory containingvariables holding the user name and password must be released or cleared.
The scope into which you may store databaseclear-text credentials must be physicallysecurely separatedcleared, fromzeroed out, or released as soon as technically feasible within the otherprogramming areaslanguage's ofcapabilities.
* yourSource code,code e.g.,files thededicated solely to retrieving or managing credentials must be in akept separate source file. The file that containsfrom the credentialsmain mustapplication contain no other code but the credentials (i.e., the user namelogic and password)protected with appropriate access controls.
3.4 Credential Uniqueness and anyManagement
* routines,Each distinct application or methods that will be used to access the credentials.
For languages that execute from source code, the credentials' source file must not reside in the same browseable or executable file directory tree in which the executing body of code resides.
Access to Database User Names and Passwords
Every program or every collection of programsservice implementing a singlespecific business function mustshould haveutilize unique database credentials. Sharing of credentials between programsdifferent applications or services is notprohibited.
* allowed.
Database passwords used by programsapplications are considered system-level passwords as defined by the Password Policy.
Developer groupsand must have a process in place to ensure that database passwords are controlled and changed in accordancecomply with the complexity, rotation, and management requirements defined in the organization's Password Policy.
* ThisDevelopment processteams must includeimplement adocumented methodprocesses for securely managing and rotating application database passwords, restricting knowledge of databasethese passwords toon a strict need-to-know basis.
3.5 Pass-Through Authentication
* Database authentication mechanisms that rely solely on remote host authentication without additional database-level checks (e.g., some configurations of Oracle OPS$) are prohibited if they grant broad, unverified access. Implementations must ensure proper user mapping and authorization within the database.
3.6 Secure Coding TechniquesGuidelines
* Development teams must follow organization-approved secure coding guidelines specific to the programming languages and frameworks being used (e.g., Java, C#, Python, Perl). These guidelines should incorporate specific techniques for implementing the requirements of this policypolicy. *(Reference to internal secure coding standard documents should be maintained here).*
[Add4.0 references to your site-specific guidelines for the different coding languages such as Perl, JAVA, C and/or Cpro.]Compliance
4.1 Compliance Measurement
ComplianceThe Measurement
TheIT authority (e.g., Precision Computer teamteam, Information Security, Internal Audit) will verify compliance towith this policy through variousmethods methods,such includingas butcode notreviews, limitedsecurity to,architecture businessreviews, toolconfiguration reports,audits, internalvulnerability scanning, penetration testing, and externalreview audits,of documentation and feedback to the policy owner. processes.
4.2 Exceptions
Exceptions
Any exception to this policy requires formal, documented justification outlining the technical constraints or business necessity, proposed compensating controls, and risk assessment. Exceptions must be approved in advance by the designated IT authority (e.g., Precision Computer team).
4.3 Enforcement
* Applications or code found to be in violation of this policy must be approvedremediated within a defined timeframe (e.g., 90 days) or risk being disabled.
* Violations by the Precision Computer team in advance.
Non-Compliance
An employee found to have violated this policyemployees may beresult subject toin disciplinary action, up to and including termination of employment.
*
A violation of this policyViolations by a temporary worker,workers, contractorcontractors, or vendorvendors may result in the termination of their contract or assignment with <Company Name>.assignment.
5.0 Definitions
Any* program**Credentials:** Authentication information, typically a username and password pair, used to verify identity and grant access.
* **Executing Body (of code):** The primary source code orfiles containing the main application logic, as distinct from separate configuration files or dedicated credential management modules.
* **Hash Function:** A cryptographic function that isconverts foundan input into a fixed-size string of characters (the hash value). Used for integrity checks and password storage (storing the hash, not the password itself), but not directly applicable for storing credentials needed for active authentication by an application.
* **LDAP (Lightweight Directory Access Protocol):** A protocol used for accessing and maintaining distributed directory information services, often used for authentication and authorization.
* **Module:** A self-contained unit of software code that performs a specific task or set of tasks.
* **Secrets Management System:** A dedicated tool or service designed to violatesecurely thisstore, policymanage, mustand becontrol remediatedaccess withinto asensitive 90information daylike period.API keys, passwords, and certificates.
* Password Policy
* Secure Coding Standards/Guidelines
* Data Classification Policy
Credentials
Executing Body
Hash Function
LDAP
Module