規制報告 / 監査証跡データレイク(監査・規制報告)
証跡集約・改ざん耐性・マルチアカウント統制・規制報告
可用性 (SLA目標)
S3 / Athena 等マネージドサービスのSLAに準拠(設計目標)
RTO(目標復旧時間)
分析・報告は非リアルタイム(バッチ / オンデマンド想定)
RPO(目標復旧時点)
ほぼ 0 を目標(証跡は集約時に永続化・複製)
概算コスト
月 30,000〜200,000 円程度(証跡量・分析量に依存)
構成概要
- 可用性レベル
- サーバーレス
- コンピューティング
- Lambda
- 想定システム規模
- 大規模(組織横断のマルチアカウント統制)
- コスト感
- ¥¥¥中コスト
使用AWSサービス
- AWS Organizations
- AWS CloudTrail(組織証跡)
- AWS Config
- AWS Security Hub
- Amazon S3 (Object Lock)
- AWS Glue(ETL / 相当)
- Amazon Athena
- Amazon QuickSight(BI / 相当)
- AWS KMS
- AWS Backup
概要
複数アカウントにまたがる監査証跡を集約し、改ざん耐性のあるデータレイクとして保全したうえで、監査・規制報告に活用する構成です。各業務アカウントの CloudTrail / Config / Security Hub の証跡を、監査専用の「ログアーカイブアカウント」へ集約。S3 Object Lock(WORM)と KMS 暗号化で改ざん耐性と機密性を確保します。分析・分析アカウントでは Glue(カタログ / ETL 相当)でデータを整え、Athena で SQL 分析、QuickSight(相当)で監査・規制報告のダッシュボードを作成します。AWS Organizations によるマルチアカウント統制で、職務分離と最小権限を実現することを設計目標とします。改ざん耐性・保持期間は Object Lock 設定・リテンション要件に依存します。
★ 設計のポイント
- ▸CloudTrail 組織証跡 / Config を監査専用アカウントへ集約
- ▸S3 Object Lock(WORM)+ KMS で改ざん耐性と機密性を確保
- ▸Glue / Athena / QuickSight(相当)で規制報告・ダッシュボード化
- ▸AWS Organizations による職務分離・最小権限のマルチアカウント統制
- ▸保持期間・リテンションに基づくデータ保護(設計目標)
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・運用
セキュリティ・統制
データ・分析
バックアップ・保全
コピーしてすぐ使える IaC
規制報告 / 監査証跡データレイク(監査・規制報告)を再現するためのスターターIaCです。事例固有のIP制限、監査、バックアップ、Secret参照は環境に合わせて追加してください。
import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as s3 from "aws-cdk-lib/aws-s3";
import * as kms from "aws-cdk-lib/aws-kms";
import * as cloudtrail from "aws-cdk-lib/aws-cloudtrail";
import * as glue from "aws-cdk-lib/aws-glue";
import * as athena from "aws-cdk-lib/aws-athena";
// 監査証跡の集約:S3 Object Lock(WORM) + KMS、CloudTrail(組織証跡)、Glue/Athena で分析。
export class AuditLakeStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const key = new kms.Key(this, "AuditKey", { enableKeyRotation: true });
// 改ざん耐性(WORM): Object Lock + バージョニング + コンプライアンスモード
const archive = new s3.Bucket(this, "AuditArchive", {
objectLockEnabled: true,
versioned: true,
encryption: s3.BucketEncryption.KMS,
encryptionKey: key,
enforceSSL: true,
blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
objectLockDefaultRetention: s3.ObjectLockRetention.compliance(cdk.Duration.days(3650)),
});
new cloudtrail.Trail(this, "OrgTrail", {
bucket: archive,
encryptionKey: key,
isOrganizationTrail: true,
includeGlobalServiceEvents: true,
managementEvents: cloudtrail.ReadWriteType.ALL,
});
const db = new glue.CfnDatabase(this, "GlueDb", {
catalogId: cdk.Aws.ACCOUNT_ID,
databaseInput: { name: "regulatory-reporting-audit-lake_audit" },
});
new athena.CfnWorkGroup(this, "AuditWg", {
name: "regulatory-reporting-audit-lake-audit",
workGroupConfiguration: {
resultConfiguration: { outputLocation: `s3://${archive.bucketName}/athena-results/` },
enforceWorkGroupConfiguration: true,
},
});
void db;
// NOTE: AWS Config(Recorder/DeliveryChannel)と Security Hub は組織レベルで有効化し、所見をこのレイクへ集約します。
}
}この構成を選ぶ理由
規制報告 / 監査証跡データレイク(監査・規制報告)は、大規模(組織横断のマルチアカウント統制)を想定し、運用負荷の低減とイベント駆動の伸縮性を重視する場合に選びやすい構成です。
選定フロー
業務要件を確認する
監査・規制報告で求められる可用性、RTO/RPO、データ分類を確認する。
運用体制を確認する
チームが AWS Native の運用、監視、権限管理を継続できるかを確認する。
コストと拡張性を比較する
月 30,000〜200,000 円程度(証跡量・分析量に依存)を許容し、将来のスケールやDR要件に対応できるかを判断する。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
最小構成 | 低い | 単純だが手動復旧が多い | 限定的 | PoC、検証、小規模な開始段階 |
規制報告 / 監査証跡データレイク(監査・規制報告)採用 | 中程度 | AWS標準運用で管理可能 | 需要に応じて高く伸縮 | 金融機関の監査証跡集約と内部監査・外部監査対応 |
上位冗長化構成 | 高い | 設計・監視・訓練が増える | 高い | 厳格なSLA、DR、監査要件がある場合 |
採用時のトレードオフ
設計前提の確認が必要
コストと運用負荷のバランス
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
監査・規制報告
重要度
高(証跡の完全性・規制対応の確実性が要件)
DR方式
サーバーレス・S3 の高耐久性(クロスリージョン複製は拡張余地)
接続方式
組織内マルチアカウント連携(証跡の集約 / 内部)
データ分類
機密(監査証跡・構成変更 / セキュリティ所見)
✔ データ活用・統制の設計目標
- •S3 Object Lock による改ざん耐性(WORM)で証跡の完全性を担保する
- •CloudTrail(組織証跡)/ Config による全アカウントの証跡・構成記録
- •KMS による暗号化と、ログアーカイブアカウントの最小権限分離
- •職務分離(監査専用アカウント)とアクセスの監査証跡を確保する
- •保持期間・リテンションポリシーに基づくデータ保護
⚠ 前提条件・留意事項
- •改ざん耐性・保持期間は Object Lock 設定・リテンション要件に依存する
- •規制報告の様式・提出要件は各規制・監督当局に応じた実装が前提
- •記載の可用性・分析性能は設計目標であり、データ量・構成に依存する
✓ メリット
- •Object Lock(WORM)で証跡の改ざん耐性・完全性を確保
- •組織証跡 / Config 集約で全アカウントを横断的に統制
- •Glue / Athena / QuickSight でサーバーレスに分析・報告
- •監査専用アカウント分離で職務分離・最小権限を実現
✗ デメリット
- •規制報告の様式・提出要件に応じた個別実装が必要
- •保持期間・リテンション設計とコストの継続的な管理が必要
- •マルチアカウント・組織統制の設計/運用の難易度が高い
- •分析はバッチ/オンデマンド前提でリアルタイム性は限定的
→ 主なユースケース
- •金融機関の監査証跡集約と内部監査・外部監査対応
- •規制当局への定期報告・オンデマンド照会対応
- •マルチアカウント環境のガバナンス・統制の可視化