Confidential O&M and data masking

Updated at:
Copy as MD

The Always Confidential database feature enforces a strict separation between data ownership and database administration: data owners control who can access sensitive data, and database administrators (DBAs) manage the database without seeing the plaintext. When a DBA needs to perform O&M operations on encrypted data — such as verifying a data restore — the data department can grant temporary, masked access through a behavior control list (BCL). The DBA sees only masked output, never the underlying plaintext.

Use case

A common scenario: personal data is accidentally deleted from a table. A DBA restores it using data tracking, then needs to verify that the restored rows match the original records. Because the data is encrypted, the DBA cannot read the values directly. With BCL-based authorization, the data department grants the DBA temporary access to masked data, allowing the DBA to verify correctness without exposing the actual plaintext.

Prerequisites

Before you begin, ensure that you have:

  • The person table created as described in Privacy protection

  • Access to the ins_data user account for running decrypt queries

  • The BCL and behavior revocation list (BRL) script files (setGroupIdBCL.sh, genEncdbSQLCommand.sh) and the corresponding key files in the sample/ directory

Grant access, run O&M operations, and revoke access

Step 1: Confirm the DBA has no access

Run the following query as the ins_data user to confirm that the DBA cannot decrypt the data:

SELECT encdb.decrypt(id) FROM person;

Without BCL authorization, the query fails:

WARNING:  -- encdb -- -- Untrusted log -- 4 - src/core/untrusted/src/encdb_untrusted_enclave.cpp,256,encdb_ecall: Select BCL (subject_mekid: 178079820457738240, issuer_mekid: 178079820457738240) from table fail - returned 0xfa030000
ERROR:  encdb_ext_enc_text_decrypt: enc_text decrypt errno:fa030000

Step 2: Grant the DBA masked access via BCL

  1. Get the group ID for the data encryption key (DEK) associated with the column:

    SELECT encdb_get_cc_entry_by_name(encdb.keyname_generate('<user_name>', '<database_name>', '<schema_name>', '<table_name>', '<column_name>'));
  2. Update the BCL with the group ID:

    ./setGroupIdBCL.sh -d <groupid>
  3. Issue the BCL with both the subject signature and the issuer signature:

    ./genEncdbSQLCommand.sh -r BCL_ISSUE --subject_sign --spriv sample/usr_pri_data.pem --spuk sample/usr_puk_data.pem --ipuk sample/usr_puk_data.pem --bcl sample/bcl_data_for_dba_select.txt -c ${cipher_suite}
    ./genEncdbSQLCommand.sh -r BCL_ISSUE --issuer_sign --ipriv sample/usr_pri_data.pem --spuk sample/usr_puk_data.pem --ipuk sample/usr_puk_data.pem --bcl sample/bcl_data_for_dba_select.txt -c ${cipher_suite}

After the BCL is issued, the DBA can run the decrypt query and receive masked output:

SELECT encdb.decrypt(id) FROM person;
       decrypt
--------------------
 11122*********9999
 11122*********8888
(2 rows)

The output preserves the leading and trailing digits while masking the middle portion with asterisks. This allows the DBA to verify data accuracy — for example, confirming that the correct records were restored — without accessing the actual plaintext values.

BCL authorization should be time-limited. Revoke access as soon as the O&M operation is complete.

Step 3: Revoke the DBA's access

After the O&M operations are complete, revoke the BCL using a BRL. You must use the ins_data user to run the following commands:

./genEncdbSQLCommand.sh -r BCL_REVOKE --puk sample/usr_puk_data.pem --pri sample/usr_pri_data.pem --brl sample/brl_data_for_dba_select.txt -c ${cipher_suite}

After revocation, the DBA's decrypt query fails again:

NOTICE:  -- encdb -- -- Enclave log -- 4 - src/core/trusted/src/key_mgmt.cpp,576,encdb_trusted_import_bcl: BCL (aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa) was invalidated by BRL (1dec8190-3fd6-4de1-9ab7-7c1456933b28)
NOTICE:  -- encdb -- -- Enclave log -- 4 - src/core/trusted/src/key_mgmt.cpp,596,encdb_trusted_import_bcl: no BCL authorization
WARNING:  -- encdb -- -- Untrusted log -- 4 - src/core/untrusted/src/encdb_untrusted_enclave.cpp,250,encdb_ecall: Import BCL (subject_mekid: 178079820457738240, issuer_mekid: 178079820457738240) to enclave failed - returned 0xfa020000
ERROR:  encdb_ext_enc_text_decrypt: enc_text decrypt errno:fa020000

Security considerations

  • Masking does not eliminate all risk. The masked output reveals partial values (prefix and suffix digits). If a DBA already knows some of the plaintext data, masked output may be enough to infer the full value. Pair BCL-based access with audit logging to detect and investigate any misuse.

  • Revoke promptly. Grant BCL authorization for the minimum time needed to complete the O&M task. The longer a DBA holds access, the higher the exposure window.

  • Both signatures are required. Issuing a BCL requires both the subject signature and the issuer signature. Omitting either step leaves the BCL inactive.

What's next

  • Privacy protection — set up the person table and column encryption used in this example