51 lines
2.0 KiB
Markdown
51 lines
2.0 KiB
Markdown
---
|
||
name: defense-in-depth
|
||
description: "Defense in depth: add layered validation/guardrails across a data path (auth, validation, invariants, rate limits, idempotency). Triggers: defense in depth, guardrails, harden, 分层校验, 多道防线, 安全加固."
|
||
---
|
||
|
||
# Defense in Depth（分层校验 / 多道防线）
|
||
|
||
## When to Use
|
||
- Auth/data path changes (permissions, roles, ownership checks)
|
||
- Risky inputs (user input, external APIs, files, SQL, commands)
|
||
- Operations that must be safe under retries/concurrency
|
||
- Incidents where we fixed symptoms but not the root class of bugs
|
||
|
||
## Inputs（required）
|
||
- Data path: entrypoints → core logic → side effects (DB/files/network)
|
||
- Threat model: what could go wrong? who can trigger it?
|
||
- Constraints: latency budgets, backward compatibility, rollout plan
|
||
- Verification: how to prove guardrails work (tests, logs, metrics)
|
||
|
||
## Procedure（default）
|
||
1. **Map the Path**
|
||
- Identify trust boundaries and validation points
|
||
- List invariants that must always hold
|
||
|
||
2. **Layer Guardrails**
|
||
- AuthN/AuthZ checks at boundaries (least privilege)
|
||
- Input validation + normalization (reject early)
|
||
- Business invariants (defensive checks with clear errors)
|
||
- Idempotency / dedup / retry-safety
|
||
- Rate limits / resource bounds (timeouts, size limits)
|
||
- Observability (structured logs, metrics, alerts)
|
||
|
||
3. **Failure Modes**
|
||
- Define what happens on invalid input, partial failures, timeouts
|
||
- Ensure errors are actionable and do not leak sensitive info
|
||
|
||
4. **Verify**
|
||
- Add tests for each guardrail and key edge cases
|
||
- Propose minimal manual verification steps if tests are missing
|
||
|
||
## Output Contract（stable）
|
||
- Path map: trust boundaries + invariants
|
||
- Guardrails: what to add at each layer (with rationale)
|
||
- Risks: what remains and why
|
||
- Verification: exact tests/commands and expected signals
|
||
|
||
## Guardrails
|
||
- Avoid “one big check”; prefer multiple small, well-scoped checks
|
||
- Prefer explicit errors over silent fallback
|
||
- Security checks must not be bypassable via alternate code paths
|