Legacy Haven University

Full-disk encryption stops a stolen drive. It does not stop a privileged session that already sits on the database. Row-level security (RLS) and column-level encryption split who may open the system from which records and fields that session may read.

CompTIA SecurityX (CAS-005) never uses those two product names. It still tests the job they do: classification, least privilege, subject-object control, encryption of data at rest, and privacy applications. Map the control to the official language. Do not memorize a vendor slogan.

The failure mode: admin rights are not data rights

A database administrator (DBA) can start the service, apply patches, and take backups. That role still does not need every Social Security number in the table.

CAS-005 2.4 designs access, authentication, and authorization as separate decisions. 2.6 then requires you to define the subject-object relationship. The subject is the user, process, device, or service (3.1). The object is the row, the column, or the file. If those two stay glued together, every DBA session becomes a sensitive-data breach waiting for 1.2’s confidentiality risk list: data leak response, privileged-data breach, encryption after the fact.

Treat three planes as different jobs:

Disk encryption lives on the first plane. RLS lives on the second. Column-level encryption lives on the third. Collapse them and you fail a SecurityX design scenario even if the volume is “encrypted.”

Classify first. Then write the policy.

2.3 puts information and data security design before the control list: classification models, data labeling, tagging strategies. 4.2 later uses data classification as a prioritization factor when you cut the attack surface.

Label the crown jewels before you write a row filter.

• Restricted / privileged. Identifiers, payment data, health data. 1.3 names healthcare and financial compliance, PCI DSS, GDPR, CCPA, LGPD, and COPPA as the pressure that makes this label real.
• Internal. Operational records that are not public and are not the crown jewels.
• Public. Marketing copy and other data that can leave the perimeter.

Tag the table and the column, not only the file share. DLP in 2.3 covers data at rest, data in transit, and data discovery. Discovery that cannot see a column tag cannot enforce a later DLP rule in 4.1.

1.1 also names data governance in staging environments: production, development, testing, and quality assurance, plus data life cycle management. A production RLS policy that you never copy into the test clone is not a control. It is a screenshot.

Row-level security: the query engine applies the subject filter

RLS is a policy the database evaluates on every query. After the session authenticates, the engine adds a predicate (a true/false test) that says which rows exist for this subject. A SELECT * from an application service that is bound to Tenant A returns Tenant A’s rows. The same statement from Tenant B does not return Tenant A’s rows.

That is 2.6 continuous authorization applied inside the data store. The network already admitted the session. The table still asks “which objects does this subject get?”

Official access-control models in 2.4 / 2.6 give you the language for the predicate:

• Role-based access control (RBAC). The session carries a role. The policy allows rows that match that role.
• Attribute-based access control (ABAC). The policy reads attributes: tenant id, region, clearance, device posture. 3.1’s conditional-access list (user-to-device binding, geographic location, time-based rules) belongs here, not only at the VPN.
• Mandatory access control (MAC). Labels on the row and labels on the subject must match. The user cannot waive the rule.
• Discretionary access control (DAC). The data owner grants row access. Useful for collaboration. Weak as the only control on privileged data.
• Rule-based access control. A static rule (time window, source network) gates the row set.

2.4 also names policy decision points and policy enforcement points. In an RLS design, the decision point evaluates the subject attributes. The enforcement point is the storage engine that refuses to emit the row.

Do not treat RLS as hiding data from a DBA who can change the policy. A principal that can ALTER POLICY still owns the object. Pair RLS with privileged access management (PAM) and privilege identity management from 3.1. The break-glass DBA uses a checked-out, time-bound role. 4.1 then records that session in application logs and DLP data.

What the official document does not give you. Syntax, default-deny behavior, BYPASS flags, and how a specific engine binds current_user to a tenant column.

Column-level encryption: ciphertext in the field the DBA can still query

Column-level encryption encrypts selected fields before or as they land on disk. The table still has rows. The sensitive column stores ciphertext. A session without the data key reads a blob. A session with the key reads plaintext.

This is 3.8’s data-at-rest use case applied to a field, not to the volume. 3.4 already covers host-based encryption and the self-encrypting drive. Those protect the platter when the host is off. They unwrap when the service account starts. Column-level encryption stays wrapped after the DBA logs in.

Keep the key off the table.

• 2.5: cloud versus customer-managed encryption keys. If the cloud provider holds the only copy, the shared-responsibility line for that column has moved.
• 3.1 secrets management: keys, rotation, deletion. 4.2 repeats key rotation under mitigations.
• 3.7 envelope encryption: a data key encrypts the column. A key-encryption key wraps the data key. Rotate the wrapper without rewriting every row on the same night if the design supports it.
• 3.4 hardware security module (HSM) / trusted platform module (TPM) when the wrapper must not live as a file next to the data files.

3.8 also lists data in use / processing. Column-level encryption does not automatically give you that. Encrypted values that must be decrypted in application memory are still data in use. Homomorphic encryption (3.7) is the official term for compute-on-ciphertext.

3.8 techniques that sit next to column encryption, and are not the same control:

• Tokenization. Replace the live value with a token. The vault holds the map. Useful when a downstream system only needs a stable handle, not the card number (PCI DSS appears in 1.3).
• Data anonymization and data sanitization. 3.8 lists both as use cases. Anonymization is for data that must leave production and never come back as personal data. Sanitization is for media and retired copies. Neither is a substitute for a live production key.
• Obfuscation / cryptographic erase. Official technique names. Obfuscation is not encryption. Cryptographic erase destroys access by destroying the key.

Dynamic data masking belongs to the PM lab title, not to this AM article as a worked example. Masking changes what a session sees. Encryption changes what the store holds. Do not merge them in an exam answer.

Cloud, remanence, and the copy you forgot

2.5 cloud data security considerations: data exposure, data leakage, data remanence, insecure storage resources. RLS on the primary cluster does not follow a snapshot, a replica, a support export, or an analytics clone unless you design that path.

1.2 privacy risk adds data subject rights and data sovereignty. A row filter that works in one region and then replicates plaintext into another region fails the sovereignty requirement even if the application UI looks correct.

2.3 DLP at rest and in transit has to see those copies. 2.6 security boundaries name data perimeters and secure zones. Draw the perimeter around every store that holds the column, not around the application load balancer.

Insecure storage in 2.5 includes object buckets that receive database exports. Encrypt the export with a customer-managed key. Then apply the same subject-object rule to who may decrypt the export. A “secure database” that dumps plaintext to a public bucket is 4.2 insecure configuration plus embedded secrets if the dump script carries a hardcoded key.

What SecurityX will actually ask

The exam will not say “enable RLS on PostgreSQL.” It will give you a design and ask which control matches the requirement.

Use this translation:

Wrong answers on this family of items usually pick full-disk encryption for a live privileged-user threat, or pick encryption when the requirement was only to hide rows from a peer tenant.

Design checklist before you call the data “protected”

1. Classify and tag the table and the sensitive columns (2.3).
2. Write the subject-object rule. Name the subject type: user, process, device, or service (3.1, 2.6).
3. Enforce the row filter at the engine, not only in the application. Application filters fail when someone opens a SQL client.
4. Encrypt the crown-jewel columns with a key the table owner does not store beside the data files (3.8, 2.5, 3.1).
5. Put policy-change rights behind PAM. Log the checkout (3.1, 4.1).
6. Repeat the same rule on replicas, backups, extracts, and staging clones (1.1, 2.5 remanence).
7. Point DLP discovery at the labeled columns (2.3, 4.1).
8. Rotate and delete keys on a defined life cycle (3.1, 4.2).

The companion lab on the calendar implements dynamic data masking and RLS in PostgreSQL. Use that lab for syntax. Use this article for the architecture you must defend on CAS-005.

Study the full SecurityX (CAS-005) objective map at the Legacy Haven University SecurityX guide.