ストーリー
高橋アーキテクトが真剣な表情で要件書を渡しました。
課題概要
| 項目 | 内容 |
|---|---|
| 対象システム | 個人向けオンラインバンキングシステム |
| 課題数 | 8つ |
| 合計時間 | 90分 |
| 評価基準 | 全課題の成果物を作成し、一貫性のある設計であること |
システム要件
- 個人ユーザーが口座残高の確認・振込・入出金履歴の閲覧を行う
- モバイルアプリ(iOS/Android)とWebブラウザからアクセス
- 外部の決済ネットワーク(全銀システム)と連携
- 法規制: 金融庁のFISC安全対策基準、個人情報保護法
- ユーザー数: 50万人
- 可用性: 99.99%(年間ダウンタイム52分以内)
課題1: DFDを作成しよう(10分)
オンラインバンキングシステムのデータフロー図を作成してください。信頼境界を明確にしてください。
解答例(自分で作成してから確認しよう)
─ ─ ─ 外部境界 ─ ─ ─
┌──────────┐ ┌──────────────┐
│ モバイル │──HTTPS──→ │ 全銀システム │
│ アプリ │ ┌──────────┐ │(決済NW) │
└──────────┘ │ API │──専用線→│ │
┌──────────┐ │ Gateway │ └──────────────┘
│ Web │──HTTPS──→│ + WAF │
│ ブラウザ │ └────┬─────┘
└──────────┘ │
─ ─ ─ ─ ─ ─│─ ─ ─ ─ 内部境界 ─ ─ ─
│
┌──────▼──────┐
│ 認証サーバー │
│ (OIDC/MFA) │
└──────┬──────┘
│
┌────────────────┼────────────────┐
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ 口座 │ │ 振込 │ │ 通知 │
│ サービス │ │ サービス │ │ サービス │
└─────┬─────┘ └─────┬─────┘ └───────────┘
│ │
─ ─ ─ ┼ ─ ─ ─ ─ ─ ─ ─┼─ ─ ─ データ境界 ─ ─
│ │
┌─────▼─────┐ ┌─────▼─────┐
│ 口座DB │ │ 取引DB │
│ (暗号化) │ │ (暗号化) │
└───────────┘ └───────────┘
┌───────────┐
│ 監査ログDB │
│ (WORM) │
└───────────┘
信頼境界:
1. 外部境界: インターネット ↔ API Gateway
2. 内部境界: API Gateway ↔ 内部サービス
3. データ境界: サービス ↔ データベース
4. 決済境界: 内部 ↔ 全銀システム(専用線)
課題2: STRIDE分析を行おう(10分)
主要コンポーネント(API Gateway、振込サービス、口座DB)に対してSTRIDE分析を行い、各コンポーネントで最も重要な脅威を2つずつ特定してください。
解答例(自分で分析してから確認しよう)
API Gateway:
| 脅威 | 説明 | DREAD |
|---|---|---|
| D (DoS) | 大量リクエストによるサービス停止 | 8.2 |
| S (なりすまし) | 盗んだ認証情報でのアクセス | 8.8 |
振込サービス:
| 脅威 | 説明 | DREAD |
|---|---|---|
| T (改ざん) | 振込金額・振込先の改ざん | 9.6 |
| R (否認) | 振込を行ったことの否認 | 7.4 |
口座DB:
| 脅威 | 説明 | DREAD |
|---|---|---|
| I (情報漏洩) | 口座残高・取引履歴の漏洩 | 9.2 |
| T (改ざん) | 残高の不正な変更 | 9.8 |
課題3: 認証・認可アーキテクチャを設計しよう(10分)
金融システムにふさわしい認証・認可アーキテクチャを設計してください。
解答例(自分で設計してから確認しよう)
// 認証設計
const authArchitecture = {
primaryAuth: "OIDC + FIDO2/WebAuthn",
mfa: {
required: true,
methods: [
"TOTP(Google Authenticator)",
"SMS OTP(フォールバック)",
"生体認証(モバイル)",
],
},
sessionManagement: {
accessToken: { type: "JWT", expiry: "5min" }, // 短命
refreshToken: { type: "opaque", expiry: "1hour", storage: "DB" },
absoluteTimeout: "8hours", // 再認証要求
},
stepUpAuth: {
triggers: ["振込実行", "限度額変更", "パスワード変更", "連絡先変更"],
method: "MFA再検証",
},
};
// 認可設計(RBAC + ABAC ハイブリッド)
const authzDesign = {
rbac: {
roles: ["user", "premium_user", "support", "admin", "auditor"],
},
abac: {
policies: [
"振込は本人の口座からのみ可能",
"1日の振込限度額を超える取引は追加承認が必要",
"海外IPからの振込は追加認証が必要",
"深夜帯の高額取引はアラート + 追加認証",
],
},
};
課題4: データ分類と暗号化戦略を策定しよう(10分)
解答例(自分で策定してから確認しよう)
| データ | レベル | 暗号化 | 鍵管理 |
|---|---|---|---|
| 口座番号 | L4 | AES-256-GCM(フィールド暗号化) | HSM |
| 口座残高 | L4 | AES-256-GCM(フィールド暗号化) | HSM |
| 取引履歴 | L3 | DB透過暗号化 + フィールド暗号化 | KMS |
| 個人情報(名前、住所) | L3 | AES-256-GCM | KMS |
| パスワードハッシュ | L4 | Argon2id | N/A |
| 監査ログ | L2 | DB透過暗号化 | KMS |
| APIアクセスログ | L1 | なし | N/A |
課題5: シークレット管理を設計しよう(10分)
解答例(自分で設計してから確認しよう)
| シークレット | 管理ツール | ローテーション | アクセス制御 |
|---|---|---|---|
| DB認証情報 | AWS Secrets Manager | 30日(自動) | 各サービスのみ |
| JWT署名鍵 | AWS KMS | 7日 | 認証サーバーのみ |
| 暗号化マスターキー | AWS CloudHSM | 90日 | 暗号化サービスのみ |
| 全銀接続キー | HSM | 365日(手動) | 振込サービスのみ |
| TLS証明書 | ACM | 自動更新 | ALB |
| TOTP暗号化キー | AWS KMS | 180日 | 認証サーバーのみ |
課題6: 通信保護を設計しよう(10分)
解答例(自分で設計してから確認しよう)
| 経路 | 保護方式 | 備考 |
|---|---|---|
| クライアント → API GW | TLS 1.3 + HSTS preload | 証明書ピンニング(モバイル) |
| API GW → 内部サービス | mTLS | サービスメッシュ(Istio) |
| サービス → DB | TLS + IAM認証 | RDS SSL |
| サービス → 全銀 | 専用線 + 暗号化 | 閉域網通信 |
| サービス → サービス | mTLS | ゼロトラスト |
| 管理者 → 本番環境 | VPN + mTLS + MFA | 踏み台サーバー経由 |
課題7: 監査ログと不正検知を設計しよう(10分)
解答例(自分で設計してから確認しよう)
// 金融システム固有の検出ルール
const financialDetectionRules = [
{
name: "不正振込パターン",
condition: "10分間に3回以上の異なる口座への振込",
action: "口座一時凍結 + 即座にアラート",
severity: "critical",
},
{
name: "残高異常",
condition: "残高が前回のスナップショットと整合しない",
action: "取引停止 + 緊急調査",
severity: "critical",
},
{
name: "深夜の高額取引",
condition: "23:00-6:00 に 100万円以上の振込",
action: "取引保留 + 本人確認",
severity: "high",
},
{
name: "新規端末からの取引",
condition: "過去に利用のないデバイスからの振込操作",
action: "追加認証(MFA + セキュリティ質問)",
severity: "high",
},
{
name: "地理的矛盾",
condition: "短時間で物理的に移動不可能な場所からのアクセス",
action: "セッション無効化 + アラート",
severity: "critical",
},
];
// 監査ログの保存要件(FISC基準)
const auditRetention = {
transactionLog: "10年", // 取引ログは10年保存
authLog: "5年", // 認証ログは5年保存
accessLog: "3年", // アクセスログは3年保存
storage: "WORM(改ざん不可)",
backup: "地理的に離れた2拠点",
};
課題8: DevSecOpsパイプラインを設計しよう(10分)
解答例(自分で設計してから確認しよう)
金融システム向けDevSecOpsパイプライン
[Pre-commit]
├── gitleaks(シークレット検出)
├── ESLint Security
└── コミット署名(GPG必須)
[CI: Build & Test]
├── SAST(Semgrep + SonarQube) ── Critical → 停止
├── SCA(Snyk + npm audit) ── High → 停止
├── SBOM生成(CycloneDX)
├── 単体テスト(カバレッジ90%以上)
└── セキュリティテスト(認証・認可テスト)
[CI: Container]
├── Container Build
├── Trivy(コンテナ脆弱性) ── Critical → 停止
└── Image Signing(cosign)
[Staging]
├── デプロイ
├── DAST(OWASP ZAP full scan) ── High → 停止
├── 負荷テスト
└── ペネトレーションテスト(月次)
[Approval Gate]
├── セキュリティチームの承認(必須)
├── コンプライアンス確認
└── 変更管理チケットの承認
[Production]
├── Blue/Green デプロイ
├── カナリアリリース(5% → 25% → 100%)
├── リアルタイム監視(異常検知)
├── ロールバック体制(即座)
└── 24/7 SOC(Security Operations Center)監視
金融システム固有の要件:
- 全コミットにGPG署名必須
- ペネトレーションテスト: 年2回(外部業者)
- セキュリティチームの承認なしでは本番デプロイ不可
- 24/7 SOC監視体制
達成度チェック
| 課題 | テーマ | 完了 |
|---|---|---|
| 課題1 | DFD作成 | [ ] |
| 課題2 | STRIDE分析 | [ ] |
| 課題3 | 認証・認可設計 | [ ] |
| 課題4 | データ分類・暗号化 | [ ] |
| 課題5 | シークレット管理 | [ ] |
| 課題6 | 通信保護 | [ ] |
| 課題7 | 監査ログ・不正検知 | [ ] |
| 課題8 | DevSecOpsパイプライン | [ ] |
まとめ
この総合演習では、Month 8で学んだ全ての知識を統合しました。
| 領域 | 適用した知識 |
|---|---|
| 脅威分析 | DFD + STRIDE + DREAD |
| 認証認可 | OIDC + MFA + RBAC/ABAC + ゼロトラスト |
| データ保護 | データ分類 + AES-256-GCM + HSM + エンベロープ暗号化 |
| 通信保護 | TLS 1.3 + mTLS + 専用線 |
| シークレット | Secrets Manager + HSM + 自動ローテーション |
| 運用 | 監査ログ + 不正検知 + DevSecOps |
チェックリスト
- 金融システムのDFDと信頼境界を定義できた
- STRIDE分析で重要な脅威を特定できた
- MFA + ステップアップ認証を含む認証設計ができた
- データ分類に基づく暗号化戦略を策定できた
- 全通信経路の保護方式を定義できた
- 金融固有の不正検知ルールを定義できた
- セキュリティ承認ゲートを含むパイプラインを設計できた
次のステップへ
お疲れさまでした。最終演習が完了しました。 最後に卒業クイズに挑戦しましょう。
推定所要時間: 90分