Security And Privacy Architecture

Why this skill matters for Data Architects

Security and privacy architecture ensures your data platforms protect sensitive data, meet compliance needs, and remain usable by analysts and engineers. As a Data Architect, you design guardrails: who can access what, how data is protected in motion and at rest, and how the network and services are segmented to minimize blast radius. Strong security earns stakeholder trust and keeps delivery friction low.

What you will be able to do

• Design IAM roles and policies with least privilege for data lakes, warehouses, and pipelines.
• Implement row-level and column-level security for multi-tenant or multi-domain analytics.
• Apply encryption in transit (TLS) and at rest (KMS, managed keys) with key rotation plans.
• Mask, tokenize, or anonymize sensitive fields to enable safe analytics and sharing.
• Manage secrets (keys, tokens, passwords) safely throughout pipelines and orchestration.
• Segment networks and data planes to reduce lateral movement and contain incidents.
• Map platform controls to compliance requirements and prepare evidence for audits.
• Run lightweight security reviews and threat modeling early in design.

Who this is for

• Data Architects and Senior Data Engineers designing or evolving analytical platforms.
• Platform Engineers owning data infra, governance, and compliance outcomes.
• Team leads preparing for audits or expanding access to sensitive datasets.

Prerequisites

• Comfort with cloud or on‑prem data platforms (data lake/warehouse concepts).
• Basic networking (VPC/VNet, subnets, security groups/firewalls).
• Familiarity with SQL and role-based access control.

Learning path (practical roadmap)

1. Access foundations: Define identities, roles, and permissions. Draft a least-privilege access matrix for personas (e.g., data engineer, analyst, ML engineer, auditor).
2. Data protection: Enable encryption at rest with managed keys; enforce TLS for all connections; decide on BYOK or managed KMS and rotation timelines.
3. Granular access: Implement RLS/CLS for a representative dataset. Add dynamic data masking for PII.
4. Secrets and configs: Move all credentials to a secrets manager; rotate and test break-glass access.
5. Network boundaries: Place data services in private subnets; restrict ingress/egress; add service endpoints/peering as needed.
6. Compliance mapping: Map implemented controls to required frameworks and define evidence collection (logs, policies, change records).
7. Security review: Run a short threat model and architecture review; capture risks and mitigations; plan regression tests.

Worked examples

1) Least-privilege IAM for a data pipeline

Goal: Allow an ingestion job to write to a raw bucket and put messages on a queue—nothing else.

{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect": "Allow", "Action": ["s3:PutObject", "s3:AbortMultipartUpload"], "Resource": "arn:aws:s3:::company-raw/*"},
    {"Effect": "Allow", "Action": ["sqs:SendMessage"], "Resource": "arn:aws:sqs:us-east-1:123456789012:ingest-events"}
  ]
}

• Scope actions to the minimal set.
• Constrain resources to exact buckets/queues.
• Add explicit denies only for high-risk paths if needed.

2) Row-level security in PostgreSQL

Goal: Analysts only see rows from their assigned region; admins see all.

-- Setup
ALTER TABLE sales ENABLE ROW LEVEL SECURITY;

-- Region-binding to session
CREATE FUNCTION current_region() RETURNS text LANGUAGE sql STABLE AS $$
  SELECT current_setting('app.region', true)
$$;

-- Policy for analysts
CREATE POLICY analyst_region ON sales
  FOR SELECT
  TO role_analyst
  USING (region = current_region());

-- Policy for admins
CREATE POLICY admin_all ON sales
  FOR ALL
  TO role_admin
  USING (true) WITH CHECK (true);

Set the session variable after auth. Combine with column masking for sensitive fields if needed.

3) Encryption at rest with managed keys (AWS S3 SSE-KMS)

# Upload with SSE-KMS and a specific CMK
aws s3 cp file.csv s3://company-raw/2026/01/file.csv \
  --sse aws:kms \
  --sse-kms-key-id arn:aws:kms:us-east-1:123456789012:key/abcd-1234

• Ensure bucket policy enforces kms encryption.
• Rotate CMKs per policy and restrict who can use/administrate keys.

4) Dynamic masking via a view

Goal: Expose emails masked for general analysts, unmasked for PII-reviewers.

CREATE VIEW v_customers AS
SELECT
  customer_id,
  CASE
    WHEN current_user IN (SELECT grantee FROM pii_unmask_group)
      THEN email
    ELSE regexp_replace(email, '(^.).+(@.*$)', '\\1***\\2')
  END AS email,
  country
FROM customers;

Use views/UDFs to centralize masking logic. Consider adding deterministic tokenization for joins.

5) Secrets from a manager (app code sketch)

# Pseudocode
secrets = secret_manager.get("/prod/warehouse/creds")  # runtime fetch
conn = db.connect(
  host=secrets["host"],
  user=secrets["user"],
  password=secrets["password"],
  sslmode="require"
)

• Never check secrets into code or configs.
• Use short-lived credentials when possible.

Drills and quick exercises

• Draft a one-page access matrix for 5 personas and 6 resources, listing allowed actions only.
• Enable TLS-only connections on your warehouse and reject plaintext attempts.
• Implement a minimal RLS policy for a demo table and verify with two roles.
• Store one application password in a secrets manager and rotate it.
• Write a bucket/database policy that explicitly denies public access.
• Map 5 platform controls to 5 compliance requirements and note evidence sources.

Common mistakes and debugging tips

• Over-broad roles: Start with read-only; add write actions per resource. Use access reviews to prune unused permissions.
• Forgetting TLS enforcement: Add parameters/policies that reject non‑TLS connections and test with a failing plaintext attempt.
• RLS bypass via views or owners: Ensure RLS applies to all access paths; set security invoker/definer correctly and test with least-privilege users.
• Static secrets in env vars: Fetch at runtime from a secrets manager; enable rotation and alarms for rotation failures.
• Single flat network: Use private subnets, no public IPs, restrict egress, and broker access via bastion or gateway.
• Encryption without key governance: Document key ownership, rotation cadence, and break-glass. Monitor key usage for anomalies.
• Compliance as a paperwork sprint: Tie each requirement to a real control and a verifiable log/policy/config artifact.

Mini project: Secure analytics landing zone

Build a small but realistic secure analytics setup.

1. Data zones: Create raw, curated, and restricted datasets. Enforce encryption at rest with a managed KMS key.
2. Access: Define IAM roles for ingestion, transformation, analyst, and auditor. Implement least privilege.
3. Granular controls: Add RLS by business unit and dynamic masking for PII columns.
4. Secrets: Move ETL credentials to a secrets manager and prove rotation works.
5. Network: Place compute and storage in private subnets; lock down security groups to needed ports; enforce TLS.
6. Compliance mapping: Map controls to 8–10 requirements (e.g., access control, encryption, logging) and list evidence sources.
7. Review: Run a 30-minute threat model; capture top 3 risks and mitigations.

Subskills

• IAM And Least Privilege Design — Define precise roles and permissions for data personas.
• Row And Column Level Security Concepts — Enforce per-tenant/per-user row filters and column masking.
• Encryption At Rest And In Transit — Apply KMS-managed keys and TLS with rotation and monitoring.
• Tokenization Masking Anonymization — Protect PII while enabling analytics and joins where needed.
• Secrets Management Basics — Store, access, and rotate credentials safely.
• Network Segmentation Concepts — Isolate data planes and restrict traffic paths.
• Compliance Mapping Basics — Connect platform controls to frameworks and audits.
• Security Reviews And Threat Modeling — Identify threats early and plan mitigations.

Next steps

• Implement two drills in your current environment this week.
• Complete the mini project in a sandbox and capture a short design doc.
• Take the skill exam below to validate your understanding. Anyone can take it; logged-in users get saved progress.

Skill exam

When ready, start the Security And Privacy Architecture — Skill Exam. You can retake it; only logged-in users have their progress saved.