Secure and Resilient Technology：Identity・分離・復旧を基盤へ組み込む
Firewallの内側を信頼する設計から、利用者・service・device・workload・dataごとに確認し、侵害や障害の影響を限定して復旧できるtechnology architectureへ進みます。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Zero Trustとservice identity
- Failure domain・冗長化・DR
- Security controlとresilience test
体験59 · SECURITY / RESILIENCE（暗黙の信頼を減らす）
社内networkの内側からのリクエストなら、改めて認証・認可を確認しなくてよいか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のtoken伝搬を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
社内networkの内側からのリクエストであれば、改めて認証・認可を確認しなくてよいと思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
network内にいることと、正しいidentityであることは同じでしょうか？
ヒント2を見る
JavaがDBへ強い権限で接続していたら、何が起きるでしょうか？
もっと詳しく：この問いで使う専門用語
- Zero Trustは、場所だけで暗黙に信頼せず、accessごとに検証する考え方です。
- Defense in Depthは、独立した複数の防御を重ねる設計です。
- Resilience Scenarioは、原因・影響対象・刺激・期待応答・回復条件を定めた障害試験です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Zero Trustはnetwork内を自動的に信頼せず、identity、device、workload、request、dataを継続的に評価します。
SecurityとResilienceを別設計にせず、侵害を想定して権限、segmentation、検知、隔離、復旧、証拠を重ねます。
冗長化だけでなく、共通原因障害、data破損、依存先停止、operator errorを含むscenarioで重要業務をtestします。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Zero Trust
場所だけで暗黙に信頼せず、accessごとに検証する考え方です。
内部侵入やcredential奪取後の横移動を抑えるためです。
Next.jsからJava、JavaからDBでもidentityと最小権限を検証します。
Defense in Depth
独立した複数の防御を重ねる設計です。
1つのcontrolが破られても重大事故を防ぐためです。
Auth、API認可、RLS、RPC、constraint、auditを重ねます。
Resilience Scenario
原因、影響対象、刺激、期待応答、回復条件を定めた障害試験です。
『高可用』を実証可能にするためです。
Java成功後通信断、client retry、DB failover、reconciliationを試します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
暗黙の信頼を減らす
network位置はsignalの1つですが、それだけで認可しません。毎回すべてを人手確認するのではなく、identityとpolicyを自動評価します。
| 対象 | 確認 | Control |
|---|---|---|
| User | 本人・risk・MFA | OIDC、phishing-resistant auth |
| Service | workload identity・audience | mTLS、short-lived credential |
| Device | 管理状態・脆弱性 | posture、conditional access |
| Request | scope・resource・context | policy enforcement、rate limit |
| Data | classification・purpose | encryption、masking、row policy |
| Admin | 強い操作・承認 | PAM、JIT、two-person、session audit |
Blast radiusを設計する
- account・project・network・cluster・databaseの境界
- customer面とadmin面の分離
- readとfinancial writeの入口分離
- rate・amount・daily limit
- least privilegeとcredential scope
- queue・pool・connectionの上限
- feature kill switchと部分停止
- tenant・region・providerのfailure domain
Resilience pattern
| Pattern | 守るもの | 失敗時の注意 |
|---|---|---|
| Multi-zone | hardware / zone failure | 共通control plane依存 |
| Multi-region | regional disruption | data consistency、切替、cost |
| Circuit breaker | 依存先連鎖 | 金融commandを安易にfallbackしない |
| Bulkhead | resource枯渇の隔離 | capacity配分 |
| Backup / PITR | data loss・corruption | 復元とLedger照合 |
| Active-passive | 単純な切替 | stale standbyと手順 |
| Graceful degradation | 重要機能継続 | 表示と取引可否を明確化 |
検証しなければarchitectureではない
MinibankではRLS、private schema、token propagation、transaction、idempotencyを確認できます。multi-region failoverやsecret compromise recoveryは未検証として残ります。
- 01Threat / failure scenarioを定義
- 02expected controlと顧客影響を決める
- 03tabletopで人・連絡・判断を確認
- 04game dayでcomponentを実際に停止
- 05RTO・data・Ledger・queueを測定
- 06差異をbacklog・runbook・設計へ反映
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Zero TrustとDefense in Depthの考え方を読んだところで、教材内の参照元で実際のtoken伝搬を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずJavaがtokenをどう転送するかを見て、次にDB側の防御層を見ます。信頼をどこでも暗黙に前提していないかを確かめましょう。
教材の参照元を確認する — Source Trail ↓PostgRESTへのHTTP通信。token伝搬を探します。
services/payment-service/src/main/java/com/minibank/payment/repository/SupabaseRpcClient.javaDB権限・RLS・private schema。
supabase/migrations/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜZero Trustの考え方では、ネットワークの位置ではなくidentityとpolicyを毎回確認するのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Zero Trust」という言葉を使って書いてみましょう。
ヒント2を見る
1つの防御層が破られた時に何が起きるか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Zero Trust、Defense in Depth、Resilience Scenarioの3つを使って、侵害を前提にした設計を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- network内でも暗黙の信頼をしないと説明できる
- 複数の独立した防御層が重ねられていると説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1private network内ならservice間認証は不要ですか？
不要ではありません。workload identity、authorization、暗号化、監査が必要です。
Q2backup成功ログがあれば復旧可能ですか？
証明になりません。restore、整合性検査、業務再開、RTO/RPOを実測します。
Q3金融経路の障害試験で何を確認しますか？
顧客結果、重複なし、Ledger整合性、audit、検知、隔離、復旧、再照合です。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- NIST — SP 800-207 Zero Trust Architecture
network位置を暗黙の信頼根拠にせず、resource・identity・policyを中心にするarchitecture
- 金融庁 — 金融機関のITガバナンスに関する論点・プラクティス
経営戦略、IT戦略、DX戦略、次世代architecture、投資・risk・人材の統合
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
src/lib/security/Next.js security control - 現在の実装 — CURRENT IMPLEMENTATION
services/payment-service/src/main/java/com/minibank/payment/config/Java request・client設定 - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/DB権限・RLS・private schema