Answer: column-level security

## Detailed Explanation ### Understanding the Requirements The question presents two key requirements: 1. **Allow salespeople to view all entries in the Customers table** - This means they should be able to see all rows in the table 2. **Prevent salespeople from viewing OR inferring credit card information** - This is a strong security requirement that goes beyond simple visibility control ### Analysis of Each Option #### **A: Data Masking** ❌ - **What it does**: Dynamically masks sensitive data at query time, showing partial or obfuscated values - **Why it's unsuitable**: Data masking is vulnerable to inference attacks. Malicious users can use techniques like: - Brute-force queries with different WHERE clauses - Pattern analysis of masked data - Cross-referencing with other available information - **Microsoft documentation explicitly states**: "Dynamic Data Masking should not be used as an isolated measure to fully secure sensitive data from users running ad-hoc queries on the database. It is appropriate for preventing accidental sensitive data exposure, but will not protect against malicious intent to infer the underlying data." #### **B: Always Encrypted** ❌ - **What it does**: Encrypts data at the column level, keeping it encrypted throughout processing - **Why it's unsuitable**: - Salespeople wouldn't be able to view the encrypted credit card column at all - Requires client-side decryption keys, which salespeople wouldn't have - Overly complex for this specific use case where complete column exclusion is sufficient #### **C: Column-level Security** ✅ - **What it does**: Controls access to specific columns based on user permissions - **Why it's optimal**: - **Prevents both viewing AND inferring**: Salespeople cannot access the credit card column at all, eliminating any possibility of inference - **Allows viewing all entries**: Salespeople can still see all rows in the Customers table, just without the credit card column - **Granular control**: Provides precise column-level access control - **Performance efficient**: No encryption/decryption overhead #### **D: Row-level Security** ❌ - **What it does**: Controls access to specific rows based on user permissions - **Why it's unsuitable**: This controls which rows users can see, not which columns. It doesn't address the credit card column visibility requirement. ### Key Security Consideration The critical distinction here is **preventing inference**. While data masking might seem appealing for allowing partial visibility, it fails the security requirement because: - Users can still run queries that reveal patterns - With enough queries, they could potentially deduce the actual values - Column-level security completely eliminates this risk by denying any access to the sensitive column ### Best Practice Alignment For sensitive financial data like credit card information, the principle of **least privilege** dictates that users should only have access to data they absolutely need for their job functions. Salespeople don't need credit card information for their sales activities, so complete column exclusion via column-level security is the most secure and appropriate solution.