Product Infrastructure Security Engineer

Product Infrastructure Security Engineer

When to Use

• Threat-model product features, internal APIs, workers, and customer-facing infrastructure
• Design or review tenant isolation, authorization boundaries, and customer data-plane controls
• Harden product-owned services with secure defaults, service auth, rate limits, audit logs, and encryption
• Review product IaC or runtime changes for cross-tenant data leaks and abuse paths
• Support incidents involving customer workloads, tenant blast radius, or product security regressions

When NOT to Use

• Implement corporate IdP, KMS, PAM, SIEM, or EDR systems → information-security-engineer
• Add CI/CD security gates, SBOMs, or supply-chain controls only → devsecops
• Run SOC alert triage and detection tuning → defensive-security-analyst
• Execute authorized pentests or exploit validation → offensive-security-analyst
• Build general IDP, golden paths, or developer portals → platform-engineer
• Define company-wide security strategy or GRC roadmap → cybersecurity
• Design RAG/copilot/LLM solution architecture → applied-ai-architect-commercial-enterprise

Related skills

Core Workflows

1. Product threat modeling

Scope the product boundary (what attackers and tenants can reach):

1. List actors: customer user, tenant admin, partner integration, internal operator, anonymous 2. Map assets: customer data, credentials, billing, config, audit logs 3. Draw data flows across services and stores 4. Identify trust boundaries (tenant, region, env) 5. Prioritize threats: cross-tenant access, privilege escalation, data exfil, abuse 6. Record mitigations and residual risk owners

See `references/product_threat_model.md` for STRIDE-lite worksheet.

2. Multi-tenant isolation

Isolation goals:

• No cross-tenant read/write on data paths
• Blast radius contained per tenant on compromise
• Strong tenant ID in every authZ decision (never trust client-supplied tenant alone)

Patterns: row-level security, per-tenant keys, namespace isolation, dedicated cells for enterprise tier.

See `references/multi_tenant_isolation.md` for patterns and test cases.

3. Service and API security baselines

Every product service should default to:

• Authenticated internal calls (mTLS or signed service tokens)
• AuthZ at resource level, not only route level
• Input validation and size limits on APIs
• Structured audit logs for security-relevant actions
• No secrets in images; workload identity for cloud APIs

See `references/secure_service_defaults.md` for checklist and anti-patterns.

4. Customer data protection

See `references/customer_data_protection.md` for key hierarchy and deletion workflow.

5. Abuse and resilience

• Rate limits per tenant/user/IP on public and partner APIs
• Idempotency and replay protection on sensitive mutations
• Circuit breakers on dependency calls that handle tenant context
• Quotas on expensive operations (exports, bulk API)

Align with defensive monitoring for anomaly signals.

6. Security design review (product infra)

Review triggers: new data store, new cross-service API, tenancy model change, new integration surface, crypto change.

Review output:

• Findings with severity
• Required controls before launch
• Test plan (isolation tests, negative authZ cases)
• Rollback / feature flag recommendation

See `references/security_design_review.md` for review template.

7. Incident support (product scope)

When customer workloads are affected:

1. Confirm blast radius (which tenants, regions) 2. Preserve tenant-scoped logs and configs 3. Coordinate containment without cross-tenant impact 4. Post-incident: add regression test and detection

Hand off enterprise IR/comms to cybersecurity when required.

When to load references

• Threat modeling → references/product_threat_model.md
• Tenancy → references/multi_tenant_isolation.md
• Service baselines → references/secure_service_defaults.md
• Data and crypto → references/customer_data_protection.md
• Design reviews → references/security_design_review.md

Customer data protection

Table of contents

1. Key hierarchy 2. Deletion 3. Backups

Key hierarchy

• Platform CMK for infrastructure
• Optional per-tenant DEK for regulated tiers
• Envelope encryption: DEK wrapped by CMK; rotate DEKs on tenant offboarding where required

Document which fields are encrypted and at which layer (app vs DB TDE).

Deletion

Account closure workflow:

1. Disable access immediately 2. Mark tenant deleted; stop schedulers 3. Purge or crypto-shred per policy timeline 4. Verify backups and replicas respect retention 5. Audit log retention separate from customer data policy

Backups

• Backups encrypted; restore tested without cross-tenant restore paths
• Restore drills must use synthetic tenant in non-prod

Multi-tenant isolation

Table of contents

1. Patterns 2. Tenant context 3. Isolation tests

Patterns

Pick tiered model: standard on shared; enterprise on dedicated cell.

Tenant context

• Resolve tenant from authenticated identity, not from unvalidated body fields
• Propagate tenant_id in internal RPC metadata
• Reject missing tenant context at data layer (fail closed)

Isolation tests

Automate in CI:

• Cross-tenant read/write negative tests for every resource API
• Fuzz tenant ID in paths and headers
• Chaos: wrong tenant in async job payload must not process

Product threat model

Table of contents

1. Actors 2. STRIDE-lite worksheet 3. Test ideas

Actors

STRIDE-lite worksheet

Test ideas

• Two tenants A/B: A cannot read B's IDs (sequential and UUID)
• Token for tenant A rejected on tenant B hostname/header
• Deleted tenant data unreachable after retention job

Secure service defaults

Table of contents

1. Launch checklist 2. Anti-patterns

Launch checklist

• [ ] No default credentials; bootstrap via sealed secrets
• [ ] Health endpoints do not leak internal state
• [ ] Admin/debug endpoints disabled in prod or behind break-glass
• [ ] CORS and cookie flags correct for product domains
• [ ] SSRF protections on outbound fetch from user URLs
• [ ] Dependency pins; no critical CVEs on release branch
• [ ] Security headers on customer-facing HTTP

Anti-patterns

• Global admin API key shared across services
• Trusting X-Tenant-Id header without signature
• Logging full request bodies with PII
• Shared cache keys without tenant prefix
• Background jobs without tenant scoping

Security design review

Table of contents

1. When required 2. Review template

When required

Mandatory before prod for:

• New customer data store or replication path
• Change to authentication or authorization model
• New external integration or webhook surface
• Material change to encryption or key management
• New privileged operator capability

Review template

# Security design review — [feature]
**Author:** **Reviewers:** **Status:** draft | approved | blocked

## Summary
## Threat model link
## Data classification
## Tenancy impact
## AuthN/AuthZ design
## Crypto and secrets
## Logging and audit
## Abuse/rate limits
## Rollout (flags, migration)
## Open risks
## Test plan (security)
## Sign-off

Block launch on unresolved critical/high without explicit risk acceptance.