TDE: Enhancing Data Security
Transparent Data Encryption (TDE) is a pivotal element in fortifying the security posture of databases by enhancing the protection of sensitive data at rest. Its foremost purpose is to empower database users to align with pertinent industry standards, ensuring robust safeguards for invaluable information.
Databases inherently house an array of confidential data, ranging from personal and financial records to proprietary trade secrets. Safeguarding this data against unauthorized access is imperative, as its exposure sans encryption exposes it to potential theft, hacking, and consequential financial as well as reputational setbacks for an organization.
TDE introduces an additional layer of security by encrypting data at the storage level, rendering it inaccessible to unauthorized entities lacking the requisite encryption key(s). Even in scenarios where data is illicitly obtained or physically removed from the database, its contents remain inscrutable and unreadable without the associated encryption key. As an indispensable tool, TDE plays a pivotal role in upholding the security and confidentiality of sensitive database information, serving as a cornerstone within comprehensive data security strategies. Its integration is a hallmark of most enterprise-level database solutions, underlining its pivotal role in maintaining competitive parity.
Source Code Inspection
To gain insights into the underlying mechanisms of Transparent Data Encryption (TDE), we will assess the open source implementation provided by CyberTec and juxtapose its feature set against that of EDB. Our exploration commences with the utilization of the "initdb" executable – a pivotal command within PostgreSQL. This command facilitates the initiation of a new database cluster, establishment of the database directory structure, and initialization of the database system catalog.
A focal point of our investigation revolves around the inspection of the "initdb" implementation. Preliminary observations unveiled that the method for retrieving the encryption key necessitates an executable file. This choice of implementation can involve a bash script and any other executables.
There are two methods for passing the key:
By command line - highly unrecommended and saved as plain text in the config file.
Passing key through executables - preferred and good practice
When the "initdb" process is initiated, it checks for a specific flag called "K." If this flag is provided, the program takes a command line input and directs its actions towards tasks related to encryption. It uses the supplied command line input and hands it over to a function called "popen." This function executes the command and returns a result, typically the encryption key, if everything goes smoothly without any errors.
The provided example demonstrates the usage of Google Cloud Key Management Service (KMS) as an alternative to Azure Key Vault. In this context, a similar utility named "crypt" acts as a wrapper for multiple SDKs.
In the scenario of using Google Cloud KMS, when you create a key in Google Cloud KMS, a pair of public and private key components is generated, typically utilizing RSA (although other algorithms can be specified). When a user requests the key for cryptographic operations, the public component is utilized to perform encryption functions. This public component can be retrieved using the GCP command-line tools or APIs. Conversely, for decryption operations, the private component of the key is employed, and it remains securely stored within Google Cloud KMS, safeguarding sensitive data.
Creating GCP Keys
gcloud kms keys create (KEY : --keyring=KEYRING --location=LOCATION) --purpose=PURPOSE [--crypto-key-backend=CRYPTO_KEY_BACKEND] [--default-algorithm=DEFAULT_ALGORITHM] [--destroy-scheduled-duration=DESTROY_SCHEDULED_DURATION] [--import-only] [--labels=[KEY=VALUE,…]] [--next-rotation-time=NEXT_ROTATION_TIME] [--protection-level=PROTECTION_LEVEL; default="software"] [--rotation-period=ROTATION_PERIOD] [--skip-initial-version-creation] [GCLOUD_WIDE_FLAG …]
The above command is used to create a GCP encryption key. It can be wrapped in bashable script to make it executable.
Detailed options for command as per documentation are:
--account : Specifies the Google Cloud Platform user account for the command invocation.
--billing-project : Sets the billing project for quota and billing purposes.
--configuration : Specifies the configuration to use for the command invocation.
--default-algorithm : Sets the default cryptographic algorithm for the key.
--flags-file : Specifies a YAML or JSON file containing flag values.
--flatten : Flattens output resource slices into separate records.
--format : Sets the format for printing command output resources.
--help: Displays detailed help for the command.
--keyring : Specifies the KMS keyring for the key.
--labels : Adds labels to the key.
--location : Sets the Cloud location for the key.
--next-rotation-time : Sets the next automatic rotation time for the key.
--project : Specifies the Google Cloud Platform project for the invocation.
--protection-level : Sets the protection level of the key.
--purpose : Sets the purpose of the key (encryption, signing, etc.).
--quiet: Disables interactive prompts for the command.
--rotation-period : Sets the automatic rotation period for the key.
--skip-initial-version-creation: Skips creating the first version of the key during creation.
--trace-token : Sets the token used for tracing service requests.
--user-output-enabled: Prints user-intended output to the console.
--verbosity : Overrides the default verbosity level for the command.
When the gcloud kms keys create command is run in Google Cloud Platform (GCP), it initiates the process of creating a new cryptographic key within the Google Cloud Key Management Service (KMS). This key can be used for various cryptographic operations such as data encryption and passed with crypt call as bashable script.
Top comments (0)