多層防御セキュリティ は何をしますか？
概要
セキュリティは多層的であり、どの単一のレイヤーも失敗する可能性があることを前提とし、機能する最小の権限を付与します。攻撃者はあなたが忘れたレイヤーを見つけます——一つの壁に依存するシステムは、その壁に一つのバグがあれば崩壊しますが、重複する最小権限制御は、単一の障害が発生しても生き残ります。
原則（普遍的なもの）
- 信頼できない入力、シークレット、またはユーザーデータを扱うものは、構築前に脅威モデル化する。 新しい面ごとに軽量なSTRIDEパス（なりすまし、改ざん、否認防止、情報漏洩、サービス拒否、権限昇格）を実施します。モデルと緩和策を記録します（
recording-decisionsを参照）。 - 多層防御。 単一の制御が「唯一の」セキュリティではありません。認証、認可、入力検証、データレイヤーの強制は、それぞれ他のものがバイパスされる可能性があると想定します。
- あらゆる場所で最小権限 — ロール、トークン、サービスアカウント、DB権限。デフォルトはアクセスなし。最小限を付与し、未使用のものを取り消す。
- シークレットはコード、イメージ、またはコミットされた設定に決して存在しない。 ランタイム時にシークレットストアから取得され、ローテーションされ、それを必要とするワークロードにスコープが制限されます。
- 信頼境界ですべての入力を検証する。 すべての外部システムの出力を信頼できないデータとして扱い、決して命令としては扱いません。
- 依存関係のサプライチェーンは攻撃対象領域である。 ロックファイルをコミットして整合性チェックを行い、依存関係をスキャンして更新し、ベースイメージを固定してスキャンします。
- 機密性の高いアクションは監査される — 誰が、いつ、何をしたか — これにより悪用やミスを再現可能にします。
クイックリファレンス
| 対象面 | 最初の質問 |
|---|---|
| ユーザー入力を受け取る新しいエンドポイント | STRIDEモデルは？検証はどこ？機能する最小のロールは？ |
| シークレットを含むもの | シークレットストアにあるか（コード/イメージではなく）？スコープは制限されているか？ローテーション可能か？ |
| 新しい依存関係 | ロックファイルは固定されているか？スキャンされたか？十分にサポートされているか？ |
| 特権を伴う変更 | 監査されているか？アクターはデータレイヤーで認可されているか（アプリ層だけでなく）？ |
スタックの仕組み
最終的な実施レイヤーとしてのRLS、DoS制御としてのGraphQLの深さ/コスト制限、シークレット用のKey Vault、CIでのpnpm audit/Trivy — postgres-postgraphile-rls-and-sqlおよびcloud-delivery-aksを参照。
実施: CIでの依存関係監査 + イメージスキャン + シークレットスキャン（ブロッキング）；脅威モデルと監査カバレッジはレビューアの判断に委ねられます。
完全な根拠: 憲法の第X条および第XIV条、engineering-constitution/references/engineering-constitution.mdにバンドルされています。