Using CTE with SQL Server on Linux on Red Hat 8
Considerations and Requirements
-
System Requirements:
-
SQL Server 2019. Other versions of SQL Server are not supported with CipherTrust Transparent Encryption.
-
Red Hat 8. Other versions of Red Hat are not supported with CipherTrust Transparent Encryption.
Note
Other database applications may be used instead of MySQL, but Thales has only tested this feature with MySQL.
-
-
CipherTrust Transparent Encryption agent supports manual GuardPoints on a device or folder for both standalone and cluster SQL Server database. Automatic GuardPoints are supported on a standalone SQL Server database. Automatic GuardPoints are supported on a standalone SQL Server database but not for cluster SQL Server databases.
-
The CipherTrust Transparent Encryption resource agent supports GuardPoints created from standard or Live Data Transformation policies. It does not support IDT-Capable GuardPoints or Efficient Storage GuardPoints.
Create a CTE guarded standalone SQL Server database
-
Configure the target database data and log directory location as mssql, type:
-
Guard targeted directory with standard encryption policy using CS1 or CBC keys of either 128aes or 256aes encryption.
Example
Policy Type: Standard
Rule Value Security Rules Action all_ops Effect permit, audit, applykey Key Selection Rule Key aes128 or 256 with CS1 or CBC # secfsd -status guard
Response
-
Create a target SQL Server database on a guarded directory as mssql, type:
-
Verify that data and log files are residing in the newly designated directory:
Expected results: Should see data/log file in a guarded directory:
Convert a baseline SQL Server database to a CTE GuardPoint using Dataxform
-
Shutdown the SQL Server service, type:
-
Create an online policy using CS1 or CBC keys of either 128aes or 256aes encryption.
Example of aes256
Policy Name:
dxf_clear_to_cbc_aes250_onhost
Policy Type: Standard
Rule Value Security Rules Action key_ops Effect permit, applykey Key Selection Rule Key clear_key Data Transformation Key cbc_aes256_onhost -
Add the GuardPoint with the policy
dxf_clear_to_aes256_onhost
to the targeted baseline database data/log directory, type:# secfsd -status guard
Response
-
Run dataxform with the above policy as the root user.
Example
Response
-
Unguard GuardPoints
/u01/app/mssql/dataxform/data
and/u01/app/mssql/dataxform/data
from policydxf_clear_to_aes256_onhost
. -
Guard these GuardPoints again with a standard policy which encrypts using the same open aes256 key policy as
dxf_clear_to_cbc_aes256_onhost
.Response
-
Start the database and then test to see if the data is accessible, type:
Expected results: You should be able to log into your targeted datatransformed database and query system files.
Create a CTE guarded Standalone SQL Server database using LDT
-
Enable the LDT setting in CipherTrust Manager using one of the following methods:
-
Install agent to your targeted database host with LDT enabled Configuring CTE with CipherTrust Manager.
-
Enable LDT on an existing CipherTrust Transparent Encryption installed host using the CM GUI.
-
-
Create a targeted new baseline in the SQL Server database:
Example
-
Create an LDT encryption policy using CS1 or CBC keys of either 128aes or 256aes.
Example
Field Value Name LDT_clear_to_CS1_aes256_onhost_key Expiration Date <target date>
Algorithm AES256 or AES128 Encryption Mode CBC_CS1 or CBC Key Type Cache on Host Automatic Key Rotation Selected Key Version Life Span (days) <target #>
-
Create an online LDT policy using the key created in the previous step.
Example for CBC_CS1 with AES256
Policy Name: LDT_clear_to_CS1_aes256_onhost
Security Rules
Rule Action Order 1 Action key_op Effect Permit, Apply Key Browsing No Rule Action Order 2 Action all_ops Effect Permit, Audit, Apply Key Browsing Yes Rule Action Order 3 Action all_ops Effect Deny, Audit Browsing Yes Key Selection Rule:
Key Description Order 1 Current Key clear_key Transformation Key LDT_clear_to_CS1_aes256_onhost_key Exclusion Rule No -
Stop the SQL Server, type:
-
Guard the new LDT baseline database with the LDT policy created in the previous step.
Response
Wait for the Rekey Status in CipherTrust Manager to display: Rekeyed.
-
Run LDT with the same policy to verify the transformation of the baseline database.
Example:
Response
Expected results:
-
No errors in output
-
rekey_status=rekeyed
Note
Do not start the next step until rekey_status = rekeyed.
-
-
Restart the SQL Server, type:
-
Access the targeted database and query the data, type:
Expected results: You should be able to log into your targeted database and query system files.