金融リファレンスアーキテクチャ日本版 v2のSkillsをKiroに読み込ませたら、回答はどう変わるのか試してみた

金融機関のシステムをAWSで設計する際の、FISC安全対策基準に基づく信頼性（可用性・DR）設計のポイントをまとめます。

1. 可用性の確保

マルチAZ構成

• 必須要件: 本番環境は必ず複数のアベイラビリティゾーン（AZ）に配置
• EC2/RDS: マルチAZ配置により単一障害点を排除
• ELB: Application Load BalancerやNetwork Load Balancerでトラフィックを複数AZに分散
• 目標: 99.95%以上の可用性（FISCでは重要システムで要求される水準）

冗長化戦略

• アプリケーション層: Auto Scalingグループで最小2インスタンス以上
• データベース層: RDS Multi-AZまたはAurora（自動フェイルオーバー）
• ストレージ層: S3（99.999999999%の耐久性）、EFS（マルチAZ）

2. DR（災害復旧）対策

リージョン間DR

• マルチリージョン構成: 東京リージョンと大阪リージョンの組み合わせが一般的
• データレプリケーション:
  • RDSクロスリージョンリードレプリカ
  • S3クロスリージョンレプリケーション
  • DynamoDB Global Tables

RTO/RPO目標

• RTO（目標復旧時間）:
  • 基幹系: 4時間以内（FISC基準）
  • 情報系: 1営業日以内
• RPO（目標復旧時点）:
  • 基幹系: データ損失ほぼゼロ（同期レプリケーション）
  • 情報系: 数時間程度

バックアップ戦略

日次バックアップ: 35日保存
週次バックアップ: 13週保存
月次バックアップ: 7年保存（法定要件）

3. FISC特有の要件

遠隔地バックアップ

• 物理的距離: 100km以上離れた別リージョンにバックアップ
• AWS対応: 東京-大阪リージョン間（約400km）で要件クリア

システム分離

• 勘定系と情報系の分離: 別VPC、別アカウント構成も検討
• セグメント分離: サブネット、セキュリティグループによる厳密な制御

運用監視

• CloudWatch: メトリクス監視、ログ集約
• AWS Health Dashboard: AWSインフラの健全性監視
• 24時間365日監視体制: アラート設定と対応手順の整備

4. 具体的なアーキテクチャパターン

アクティブ-スタンバイ（コスト重視）

本番環境（東京リージョン）: フル稼働
DR環境（大阪リージョン）: 最小構成で待機、有事に拡張

アクティブ-アクティブ（可用性重視）

両リージョンで同時稼働
Route 53ヘルスチェックとフェイルオーバールーティング
リージョン間レイテンシー考慮が必要

5. テストと訓練

DR訓練

• 年2回以上の本番切り替え訓練: FISC基準で推奨
• 自動化: AWS Backup、CloudFormation、Systems Managerで復旧手順を自動化
• 訓練環境: 本番同等の環境で実施

フェイルオーバーテスト

# RDSフェイルオーバーのテスト例
aws rds reboot-db-instance \
  --db-instance-identifier mydb \
  --force-failover

6. コンプライアンス文書化

必要なドキュメント

• システム構成図（論理・物理）
• DR手順書（自動・手動両方）
• RTO/RPO達成根拠
• バックアップ・リストア手順
• 障害対応フロー

これらの設計ポイントを具体的なアーキテクチャ図やCloudFormationテンプレートとして作成することも可能です。ご要望があればお知らせください。

サイバー攻撃によるワークロード侵害に備えたAWSでのバックアップと復旧設計についてご説明します。

主要な設計原則

1. 多層防御とイミュータブルバックアップ

• AWS Backup Vault Lockを使用してバックアップを不変化し、削除や変更を防止
• S3 Object Lock (Compliance/Governance Mode) でバックアップデータの改ざんを防止
• MFA Deleteを有効化して、削除操作に多要素認証を要求

2. 隔離されたバックアップアカウント

• バックアップ専用のAWSアカウントを分離
• AWS OrganizationsのSCPでクロスアカウントアクセスを制限
• 本番環境の認証情報が侵害されてもバックアップへのアクセスを防止

3. 自動化されたバックアップ戦略

# バックアップポリシーの例
バックアップ頻度:
  重要データ: 
    - 連続的なポイントインタイムリカバリ (RDS, DynamoDB)
    - 日次スナップショット
    - 週次フルバックアップ
  標準データ:
    - 日次バックアップ
    - 月次アーカイブ

保持期間:
  日次: 30日
  週次: 90日
  月次: 7年 (コンプライアンス要件に応じて)

4. 推奨されるAWSサービス構成

AWS Backup

• 中央集約的なバックアップ管理
• クロスリージョン・クロスアカウントのバックアップコピー
• タグベースのバックアップポリシー

重要なデータストア別の対策

Amazon EC2/EBS:

• AWS Backup + AMI自動作成
• EBSスナップショットの自動リージョン間コピー
• スナップショットの暗号化(KMS)

Amazon RDS:

• 自動バックアップ + ポイントインタイムリカバリ
• クロスリージョンのリードレプリカ
• スナップショットの定期的なテスト復元

Amazon S3:

• バージョニング有効化
• レプリケーション (CRR: Cross-Region Replication)
• S3 Object Lock (WORM: Write Once Read Many)
• S3 Intelligent-Tiering で古いバージョンを自動アーカイブ

Amazon DynamoDB:

• ポイントインタイムリカバリ (PITR)
• On-Demand バックアップ
• AWS Backupとの統合

5. 復旧計画 (Disaster Recovery)

RTO/RPOの定義:
├─ ミッションクリティカル: RTO < 1時間, RPO < 15分
├─ ビジネスクリティカル: RTO < 4時間, RPO < 1時間
└─ 標準: RTO < 24時間, RPO < 24時間

復旧戦略:
1. Pilot Light (最小限の環境を常時稼働)
2. Warm Standby (スケールダウンした環境を常時稼働)
3. Multi-Site Active/Active (複数リージョンで完全稼働)

6. セキュリティ強化策

# 侵害検知と自動対応の例
監視項目:
  - CloudTrail異常アクセスログ
  - GuardDuty脅威検知アラート
  - SecurityHub コンプライアンス違反
  - IAM認証情報の異常使用

自動対応:
  - Lambda関数による自動隔離
  - Systems Managerでの自動パッチ適用
  - EventBridgeルールによるアラート通知

7. 定期的なテストと検証

• 月次: バックアップからの部分復元テスト
• 四半期: 完全なDR訓練 (別リージョンへのフェイルオーバー)
• 年次: 全社的なサイバー攻撃シミュレーション演習
• 継続的: 自動化された復元可能性検証

8. 実装のベストプラクティス

1. Infrastructure as Codeでバックアップ設定を管理
   • AWS CDK/CloudFormation/Terraform
2. 最小権限の原則
   • バックアップ操作用の専用IAMロール
   • 時限的な特権アクセス (AWS IAM Identity Center)
3. 監査とログ
   • CloudTrailでバックアップ/復元操作を記録
   • Config Rulesでコンプライアンス監視
4. 暗号化
   • 転送中/保管中の暗号化 (KMS)
   • カスタマーマネージドキーの使用
   • キーローテーション自動化

9. コスト最適化

• AWS Backup Storage Classes: Cold/Warm storage階層の活用
• S3 Lifecycle policies: 自動アーカイブ (Glacier/Deep Archive)
• スナップショットの重複排除: 増分バックアップの活用

このようなアーキテクチャを実装することで、ランサムウェアや侵害から効果的に保護し、迅速な復旧が可能になります。
具体的な実装サンプル(Terraform、CloudFormation、CDKなど)や、特定のユースケースについて詳しく知りたい場合はお知らせください。

複数アカウントで金融ワークロードを運用する際の、ログ集約とIAMベースラインの設計についてご説明します。

ログ集約の設計

アーキテクチャパターン

1. 集中ログアカウント戦略

   • 専用のログアーカイブアカウントを設置
   • 全ての本番・非本番アカウントからログを集約
   • AWS OrganizationsのOrganization CloudTrailを活用

2. ログの種類と収集方法

各アカウント                    ログアーカウント
├─ CloudTrail      ────────→   S3 (Organization Trail)
├─ VPC Flow Logs   ────────→   S3 + CloudWatch Logs
├─ GuardDuty       ────────→   集約マスター
├─ Config          ────────→   集約アカウント
├─ ALB/NLB Logs    ────────→   S3
└─ App Logs        ────────→   CloudWatch Logs → Kinesis → S3

3. ストレージ設計
   • S3ライフサイクル: 即座の分析用(30日) → IA(90日) → Glacier(7年+)
   • 金融業界の監査要件（通常5-7年）を考慮
   • オブジェクトロック（WORM）で改ざん防止
   • レプリケーションでDR対策

実装例

# Organization CloudTrail設定
OrganizationTrail:
  Type: AWS::CloudTrail::Trail
  Properties:
    IsOrganizationTrail: true
    S3BucketName: !Ref CentralLogBucket
    EnableLogFileValidation: true
    IncludeGlobalServiceEvents: true
    IsMultiRegionTrail: true
    EventSelectors:
      - IncludeManagementEvents: true
        ReadWriteType: All
        DataResources:
          - Type: AWS::S3::Object
            Values: ["arn:aws:s3:::*/sensitive-data/*"]

IAMベースライン設計

1. アカウント構造とIAM戦略

Management Account (Organizations管理)
├─ Security Account (IAM Identity Center, GuardDuty)
├─ Log Archive Account (ログ集約)
├─ Audit Account (監査・コンプライアンス)
├─ Network Account (Transit Gateway, Firewall)
└─ Workload Accounts
   ├─ Production
   ├─ Staging
   └─ Development

2. IAM Identity Center (AWS SSO)

Permission Setsの設計例:

// 最小権限の原則に基づくロール
{
  "PermissionSets": [
    {
      "Name": "SecurityAuditor",
      "SessionDuration": "PT4H",
      "ManagedPolicies": [
        "arn:aws:iam::aws:policy/SecurityAudit",
        "arn:aws:iam::aws:policy/ReadOnlyAccess"
      ],
      "InlinePolicy": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Deny",
            "Action": ["iam:*", "organizations:*"],
            "Resource": "*"
          }
        ]
      }
    },
    {
      "Name": "DeveloperReadOnly",
      "SessionDuration": "PT8H",
      "ManagedPolicies": ["arn:aws:iam::aws:policy/ReadOnlyAccess"],
      "CustomerManagedPolicies": ["AllowAssumeDevRole"]
    }
  ]
}

3. サービスコントロールポリシー (SCP)

基盤的な保護策:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": ["organizations:LeaveOrganization"],
      "Resource": "*"
    },
    {
      "Sid": "DenyDisablingSecurityServices",
      "Effect": "Deny",
      "Action": [
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "config:DeleteConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "config:StopConfigurationRecorder"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RequireMFAForSensitiveOperations",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRole",
        "iam:DeleteUser",
        "s3:DeleteBucket"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    },
    {
      "Sid": "RestrictRegions",
      "Effect": "Deny",
      "NotAction": [
        "cloudfront:*",
        "iam:*",
        "route53:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
        }
      }
    }
  ]
}

4. クロスアカウントアクセス

信頼関係の設計:

// LogアカウントからのS3アクセスを許可
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowLogArchiveAccount",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::LOG-ACCOUNT-ID:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id"
        }
      }
    }
  ]
}

5. 境界ポリシー (Permissions Boundary)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServicesPermissionsBoundary",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "logs:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyPermissionBoundaryDeletion",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteUserPermissionsBoundary",
        "iam:DeleteRolePermissionsBoundary"
      ],
      "Resource": "*"
    }
  ]
}

金融規制対応のチェックリスト

コンプライアンス要件

• ✅ 監査証跡: すべてのAPI呼び出しを記録（CloudTrail）
• ✅ ログ保持: 規制要件に応じた期間（5-7年+）
• ✅ 職務分離: 本番環境への適切なアクセス制御
• ✅ 最小権限: Just-in-time accessの実装
• ✅ 暗号化: 転送中・保管中のデータ暗号化
• ✅ 変更管理: AWS Configによる構成変更追跡

モニタリングとアラート

# GuardDuty findings を Security Hub へ統合
SecurityHub:
  Standards:
    - CIS AWS Foundations Benchmark
    - PCI DSS
    - AWS Foundational Security Best Practices

# 重要イベントのアラート
CloudWatch Alarms:
  - RootAccountUsage
  - UnauthorizedAPICall
  - IAMPolicyChange
  - S3BucketPolicyChange
  - SecurityGroupChange
  - NetworkACLChange

実装の優先順位

1. フェーズ1: 基盤構築（1-2週間）
   • AWS Organizations設定
   • IAM Identity Center導入
   • CloudTrail Organization Trail設定
2. フェーズ2: セキュリティ強化（2-3週間）
   • SCP適用
   • GuardDuty/Config有効化
   • VPC Flow Logs設定
3. フェーズ3: 運用整備（2-4週間）
   • ログ分析パイプライン構築
   • アラート・ダッシュボード整備
   • インシデント対応プロセス確立

具体的な実装コードやTerraform/CloudFormationテンプレートが必要でしたら、お申し付けください。作成いたします。

このサンプル構成について、FISC安全対策基準とAWSガバナンスの観点からレビューします。

重大な問題点

1. 可用性・事業継続性の欠如

問題：

• EC2が同一AZ内に集中（2台とも同じAZ）
• RDSがSingle-AZ構成
• バックアップが同一リージョン内のみ

FISC観点：

• 基準項目「設備基準」違反: データセンター障害時の継続性が確保されていない
• 基準項目「可用性対策」違反: AZ障害で全サービス停止のリスク
• 基準項目「災害対策」違反: リージョン障害時の復旧手段がない

AWSガバナンス観点：

• Well-Architected Framework「信頼性の柱」に反する
• RPO/RTOが金融システムとして不適切

推奨対策：

• EC2を複数AZに分散配置（最低2AZ）
• RDS Multi-AZ構成への変更
• 別リージョンへのクロスリージョンバックアップ（S3 + RDSスナップショット）

2. セキュリティ基準の重大な欠陥

問題：

• RDSが暗号化されていない（個人情報・口座情報が平文保存）
• 管理者アカウントが共有IAMユーザー
• MFA未設定

FISC観点：

• 基準項目「暗号化対策」違反: 預金者情報の暗号化義務に抵触
• 基準項目「アクセス管理」重大違反: 個人識別性のない共有アカウント使用
• 基準項目「多要素認証」違反: 特権アカウントにMFA未適用

AWSガバナンス観点：

• セキュリティの基本原則「最小権限の原則」違反
• 監査証跡の追跡不可能性（誰が何をしたか特定できない）

推奨対策：

• RDS暗号化の有効化（KMS使用、注：既存RDSは暗号化できないため、スナップショット→暗号化コピー→復元が必要）
• 共有IAMユーザーの廃止、個人別IAMユーザーまたはIAM Identity Centerの導入
• 全管理者アカウントへのMFA必須化
• IAMポリシーで最小権限の原則を適用

3. 監査・ログ管理の不備

問題：

• ログがEC2ローカルディスクのみ（改ざんリスク・消失リスク）
• CloudWatch Logs連携なし
• API操作ログ（CloudTrail）への言及なし

FISC観点：

• 基準項目「ログ管理」違反: 改ざん防止策なし、長期保存不可
• 基準項目「証跡管理」違反: 監査証跡の一元管理がない
• 保存期間要件: 金融機関は通常7年以上の保存が必要だが、7日のみ

AWSガバナンス観点：

• セキュリティインシデント発生時の調査が困難
• コンプライアンス要件を満たさない

推奨対策：

• CloudWatch Logsへのログ集約（改ざん防止）
• CloudTrailの有効化（全API操作の記録）
• S3へのログアーカイブ（長期保存、ライフサイクル設定）
• S3バケットのオブジェクトロック設定（WORM）
• ログ保存期間を最低7年に延長

4. バックアップ・復旧計画の不足

問題：

• バックアップ保持期間7日のみ
• 同一アカウント・同一リージョンのみ

FISC観点：

• 基準項目「バックアップ管理」: 保存期間が短すぎる
• 基準項目「災害復旧」: 地域災害時の復旧不可

推奨対策：

• バックアップ保持期間を35日以上に延長
• AWS Backupによる一元管理
• クロスリージョンバックアップ（最低1つの別リージョン）
• クロスアカウントバックアップ（改ざん・誤削除対策）

5. 監視・検知の不足

問題：

• CPU使用率アラームのみ
• セキュリティ監視なし

FISC観点：

• 基準項目「監視体制」: 異常検知の仕組みが不十分
• 基準項目「不正アクセス対策」: 検知機能なし

AWSガバナンス観点：

• 運用の可視性が著しく低い

推奨対策：

• CloudWatch Alarmsの拡充（メモリ、ディスク、ネットワーク、RDSメトリクス）
• AWS GuardDuty有効化（脅威検知）
• AWS Security Hub有効化（セキュリティ態勢の統合管理）
• VPC Flow Logsの有効化

その他の推奨事項

ネットワークセキュリティ

• WAF（AWS WAF）の導入検討
• セキュリティグループの最小権限設定確認
• NACLの適切な設定

アクセス管理

• AWS Configによる構成変更の記録
• AWS Organizations + SCPによる組織全体のガバナンス
• IAM Access Analyzerの有効化

データ保護

• S3バケット作成時の暗号化必須化
• EBSボリュームの暗号化

リスク評価サマリー

結論： この構成は金融機関のオンライン口座照会システムとして本番運用に適さない状態です。最低でも上記「最優先」項目の是正が必須です。

詳細な改善計画書やAWS構成図の作成が必要であれば、お手伝いできます。

金融機関のAWSシステムにおけるFISC安全対策基準を踏まえた信頼性（可用性・DR）設計について、専門的な知識を提供するためにスキルを活用します。金融機関のAWSシステムにおけるFISC安全対策基準を踏まえた信頼性（可用性・DR）設計について、以下の重要なポイントを押さえる必要があります。

1. ビジネス重要度に基づく復旧要件の設定（FISCREL1-BP01）

• FISC実務基準 実74に対応
• システムの重要度に応じてRTO（目標復旧時間）とRPO（目標復旧時点）を定義
• 全てのシステムを最も厳しい要件で設計するのではなく、コンポーネント単位で詳細な復旧要件を適用（FISCREL1-BP02）

2. 災害復旧戦略の選定（FISCREL1-BP03）

RTO/RPOに応じて以下の戦略から選択：

1. Backup & Restore - 最も低コストだが復旧時間は長い
2. Pilot Light - 最小限の環境を常時稼働
3. Warm Standby - スケールダウンした環境を常時稼働
4. Multi-Region Active/Active - 最も高い可用性、低いRTO/RPO

3. マルチロケーション展開（FISCREL3-BP01）

• 複数のアベイラビリティゾーン（AZ）への展開が必須
• 重要システムは複数リージョンの検討（東京・大阪リージョンの活用）
• 自動フェイルオーバーの実装

4. バックアップ戦略（FISCOPS3関連）

• RPOを満たす頻度での継続的または定期的なバックアップ（FISCOPS3-BP04、実39）
• ポイントインタイム復旧のサポート
• データだけでなくインフラ構成もバックアップ（FISCOPS3-BP05、実43）
• ランサムウェア対策として短期保持バックアップの実装（FISCOPS3-BP02）
  • AWS Backup Vault Lockの活用を推奨
• バックアップのライフサイクル管理（FISCOPS3-BP03）

5. バックアップとリカバリのテスト（FISCREL3-BP03）

• 定期的なデータ復旧テストが必須（実106）
• バックアップの整合性とRTO/RPOに対するプロセスの検証
• ポイントインタイム復旧が利用可能な場合は活用

6. 構成ドリフトの管理（FISCREL1-BP04）

• DRサイト/リージョンでの構成ドリフトを防止
• 全ロケーションへのデリバリーパイプライン
• AWS Configによるドリフト検出
• CloudFormationの活用

7. 自動復旧の実装（FISCREL1-BP05、実74）

• あらゆる条件下でシステムが自動的に復旧
• AWS Elastic Disaster Recoveryなどの活用

8. Infrastructure as Code（FISCREL3-BP02、実106）

• 環境を数分で復旧できる自動化の実装
• CloudFormation、CDKなどの活用

9. SDLC環境の分離（FISCREL2関連、実76）

• 開発/テスト/本番環境のマルチアカウント戦略
• BLEA for FSI（金融向けセキュアベースライン）の活用を推奨
• AWS OrganizationsとSCPによるIAM分離
• 本番と非本番間のネットワーク分離

10. 監視とアラート

• 想定トラフィックのベースライン確立（FISCREL2-BP04）
• 異常負荷時の運用対応トリガー
• CloudWatchによる監視

推奨AWSサービス

• DR関連: AWS Resilience Hub, AWS Elastic Disaster Recovery, Route 53, Global Accelerator
• バックアップ: AWS Backup (Vault Lock含む), Amazon RDS (自動バックアップ), DynamoDB (PITR)
• 高可用性: Elastic Load Balancing, Auto Scaling, Multi-AZ構成
• IaC: CloudFormation, CDK
• 監視: CloudWatch, AWS Config

これらは全てFISC安全対策基準の実務基準に紐づいており、金融機関のシステムとして求められる信頼性要件を満たすための必須要素です。

サイバー攻撃からのバックアップと復旧の設計について、金融機関向けのベストプラクティスをまとめた情報を確認します。サイバー攻撃に対するAWSでのバックアップと復旧設計について、金融機関向けのベストプラクティスをご説明します。

基本設計の考え方

従来の「予防重視」から「攻撃されても事業継続し、迅速に復旧する」へという思想転換が必要です。特にランサムウェアやDDoSなど可用性に影響するサイバー攻撃への対策が重要です。

3つの主要な対策

1. 論理的エアギャップバックアップ

設計原則：

• 本番アカウント（Workload Account）で AWS Backup を使用してバックアップを取得
• バックアップをData Bunker アカウント（隔離された専用アカウント）にレプリケート
• AWS Backup Logically Air-gapped Vaultを使用し、保持期間中は管理者権限でも読み取り・変更・削除が不可能な状態を維持

なぜ必要か：

• ランサムウェアに感染したデータが気付かずバックアップにコピーされる可能性があるため
• 攻撃者がバックアップを改ざん・削除することを防ぐため

重要な制約：

• Workload アカウントと Data Bunker アカウントは同じ AWS Organizations 内に配置する必要がある

2. 新規環境へのクロスアカウントリストア

設計原則：

• 本番環境が侵害されている前提で、完全に新しいRestore アカウントに復旧する
• Data Bunker アカウントに直接アクセスせず、AWS Resource Access Manager (RAM) 経由でバックアップボールトを共有
• アプリケーションとインフラは CDK で自動的に再構築
• データベース復元は AWS Step Functions で自動化
• 復旧したデータベースへの再接続は手動で実施（ビジネス影響評価とリスク判断が必要）

手順の流れ：

1. バックアップデータの整合性を評価
2. Restore アカウントにインフラを再構築
3. RAM でバックアップを共有
4. Step Functions でデータベースを復元
5. 手動でアプリケーションを復旧データベースに接続（ECS タスク定義の環境変数を更新し、ECS タスクを再起動）

3. 自動ネットワーク隔離

設計原則：

• Amazon GuardDuty の重大度 9.0 以上（Critical）の検知のみに反応
• EventBridge ルールが Lambda 関数をトリガー
• Lambda が Network ACL を動的に作成し、ワークロードのサブネットに適用
• アベイラビリティゾーン間の通信のみを許可し、その他の全てのインバウンド/アウトバウンドトラフィックをブロック
• 隔離完了時に Amazon SNS 経由で管理者に通知

推奨事項：

• ビジネス影響が大きい場合は、Critical 通知と隔離アクションの間に人間の判断ステップを挿入することを検討

アカウント構成

AWS Organizations
├── Workload Account（本番環境）
│   └── AWS Backup → バックアップ作成
├── Data Bunker Account（隔離されたバックアップ保管）
│   └── Logically Air-gapped Vault
├── Restore Account（復旧先の新環境）
│   └── RAM 経由でバックアップを受け取り復元
└── (Forensic Account)（フォレンジック調査用 - オプション）

規制との関係

この設計は以下に準拠しています：

• 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」 第2.3.3項（データ保護）
• FISC 安全対策基準のサイバーレジリエンス強化基準

ベストプラクティスまとめ

必須事項（MUST）：

• バックアップは必ず隔離された Data Bunker アカウントにレプリケート
• Logically Air-gapped Vault を使用
• 同じ AWS Organizations 内に全アカウントを配置
• 復旧は新規 Restore アカウントへ実施（本番環境へ戻さない）
• Data Bunker への直接アクセスは禁止（RAM 経由のみ）
• 復旧前にバックアップデータの整合性を評価
• インシデント発生時は速やかに隔離し、証拠を保全

推奨事項（SHOULD）：

• 自動隔離は重大度 9.0 以上の Critical 検知のみに限定
• インフラ再構築とデータベース復元を自動化
• ビジネス影響が大きい場合は隔離前に人間の判断を挿入

詳細な手順やCDKサンプルについて知りたい場合は、お知らせください。

複数アカウントで金融ワークロードを運用する際のログ集約とIAMベースラインの設計について、BLEA for FSIの知見を参照してお答えします。複数アカウントで金融ワークロードを運用する際のログ集約とIAMベースラインの設計について、BLEA for FSIのガバナンスベースに基づいて説明します。

ログ集約の設計

基本アーキテクチャ

1. Log Archiveアカウントへの集約
   • AWS Control Towerの標準構成で、専用のLog Archiveアカウントを設置
   • すべてのアカウントのログを集中管理
   • CloudTrail管理イベントログとAWS Config履歴をLog Archiveアカウントに自動集約
2. 集約対象のログ
   • CloudTrail管理イベント: Control Towerが自動で有効化
   • AWS Config設定履歴: Control Towerが自動で有効化
   • CloudTrail S3データイベント: オプション（金融機関では推奨）
     • 個人情報などを扱うS3バケットのアクセスログ
     • FISC実務基準の要件に対応
   • Session Managerログ: ゲストアカウント内に保管（集約未サポート）
3. 集約用S3バケット

バケット名: bleafsi-logbase-shared-log-<account>
保管期間: 1825日（5年）
セキュリティ対策:
- s3:DeleteObject を拒否するバケットポリシー
- 暗号化（KMS CMK）
- パブリックアクセスブロック
- ライフサイクルポリシー

4. アラート・通知
   • 各ゲストアカウントにCloudWatch Logsログ群を配置
   • メトリクスフィルターとEventBridgeルールでセキュリティイベントを検知
   • SNSトピック経由でメール通知（SSL必須）

検知すべきセキュリティイベント

CloudWatch Logsメトリクスフィルター:

• IAMポリシー変更
• 複数回の認証失敗・未認可アクセス
• 新規アクセスキー作成
• ルートユーザーアクティビティ

EventBridgeルール:

• Configルールのコンプライアンス変更
• AWS Healthイベント
• セキュリティグループ変更
• ネットワークACL変更
• CloudTrail設定変更
• Security Hub CRITICAL/HIGH検出結果
• GuardDuty検出結果（重要度4以上）

IAMベースラインの設計

管理者ロールの分離

BLEA for FSIでは、職務分離の観点から4種類の管理者ロールを定義します：

1. SysAdmin（システム管理者）
   • システム全体の管理権限
   • ただし、IAM・課金・CloudTrail・KMS破壊操作は制限
2. IamAdmin（IAM管理者）
   • IAM専用の管理者
   • ユーザー・ロール・ポリシーの管理に特化
3. ReadOnlyAdmin（読み取り専用管理者）
   • 監査・確認用
   • すべてのリソースの閲覧のみ
4. InstanceOps（EC2運用管理者）
   • EC2インスタンスの起動停止など運用作業に特化

IAMベストプラクティス

// すべての特権ロールにMFA必須
Condition: {
  Bool: { "aws:MultiFactorAuthPresent": "true" }
}

// 拒否すべき操作
- 課金情報へのアクセス
- CloudTrail設定の変更・削除
- KMS暗号化キーの破壊的操作

認証方式

• 推奨: AWS IAM Identity Center（旧AWS SSO）
  • Control Tower環境での標準
  • 長期認証情報を避ける
  • すべてのサインインでMFA必須

デプロイ順序

1. Control Towerのセットアップ
2. 組織レベルでのセキュリティサービス有効化
   • Security Hub
   • GuardDuty
   • IAM Access Analyzer
   • 管理アカウントは監査アカウントに委任
3. Log Archiveアカウントにbase-ct-loggingをデプロイ
4. 各ゲストアカウントにbase-ct-guestをデプロイ
   • 手動、またはControl Tower AFC（自動プロビジョニング）で

マルチリージョン対応

• プライマリリージョン: 東京（ap-northeast-1）
• セカンダリリージョン: 大阪（ap-northeast-3）オプション
  • 大阪リージョンではConfig自動修復の一部機能が未対応
  • 大阪リージョンのConfigデータもLog Archiveバケットに集約

FISC対応のポイント

• 5年間のログ保管: FISC実務基準に準拠
• 削除不可設定: バケットポリシーでDeleteObjectを拒否
• 暗号化: KMS CMKによる暗号化
• 監査証跡: ファイル検証を有効化したCloudTrail
• ガードレール: Control Towerコントロールを224個分析し、FISC実務基準にマッピング

この設計により、複数アカウント環境でも一元的なログ管理と統制されたIAM権限管理が実現できます。特に金融ワークロードでは、FISC安全対策基準への準拠が求められるため、このガバナンスベースを基盤として各ワークロード（勘定系、チャネル系など）を展開することが推奨されます。

エグゼクティブサマリー

総合評価：不合格 - 本番稼働不可。本構成は金融機関の口座照会システムとして複数の重大な欠陥を含んでおり、FISC安全対策基準の最低限の要求事項を満たしていません。特に、単一障害点の存在、暗号化の欠如、IAMセキュリティの不備、監査証跡の不足により、可用性、機密性、完全性の3つすべてが脅かされています。

重大な問題（Critical）

1. 【可用性】単一障害点による広範囲障害リスク（RDSのSingle-AZ、EC2が同一AZ、東京のみ）…実104（複数拠点配置）、実74（災害対策）
2. 【機密性】暗号化の完全欠如（RDS未暗号化）…実13（暗号化）、実30（鍵管理）、実69（データ分類）
3. 【完全性・監査】ログの不十分性（ローカルディスクのみ、CloudWatch Logs連携なし）…実63（操作記録）、実10（証跡管理）、実38（記録の保全）
4. 【セキュリティ】IAM管理の重大な欠陥（共有IAMユーザー、MFAなし）…実1・26（アクセス管理）、実27（権限管理）、実11（アクセス履歴）

高リスクの問題（High）

5. 【可用性】バックアップ戦略の不備（RDS自動バックアップのみ・保持7日・同一アカウント／同一リージョン）…実39、実106
6. 【セキュリティ】セキュリティ監視の欠如（CPUアラームのみ）…実16、実18、実46
7. 【ガバナンス】マルチアカウント戦略の欠如…実76、FISCREL2-BP01／BP02

FISC実務基準カバレッジ分析

現状総合カバレッジ：約15%

アクションプランは、フェーズ1（1週間以内：共有IAMユーザーの無効化＋MFA、CloudTrail、RDS暗号化、Security Hub／GuardDuty）、フェーズ2（1〜3か月：RDS Multi-AZ、EC2の2AZ分散、ログ集約、AWS Backup、WAF）、フェーズ3（3〜12か月：Control Tower、大阪DR、IaC化、Vault Lock、DR訓練）の3段階で示されました。