Amazon Security Lake 完全ガイド v2.0

セキュリティデータレイク基盤の一元化・標準化・分析

Amazon Security Lake は、AWS および外部ソース（Okta・CrowdStrike・Palo Alto など 50+ パートナー）のセキュリティログを OCSF（Open Cybersecurity Schema Framework） に自動正規化して S3 に集約するフルマネージドセキュリティデータレイクサービスです。CloudTrail・VPC Flow Logs・Route 53 Resolver Logs・EKS Audit Logs・WAF・GuardDuty・Security Hub などのセキュリティデータを Apache Parquet 形式で保存し、Athena・Splunk・Datadog・IBM QRadar など任意の分析ツールから横断的にクエリ・分析できます。Organizations 全アカウント・マルチリージョンの集約、OCSF v1.8.0（2026 年 3 月）による AI Operation & Privilege Analysis 対応、AWS AppFabric による SaaS ログ自動正規化、国際標準（ITU）への推進など、2025-2026 年の最新動向を網羅した完全リファレンスです。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： Security Lake とは何か、OCSF による標準化の意義を学びたい方
• セキュリティエンジニア向け： Source 統合・Subscriber 管理・OCSF スキーマの実装
• CISO / セキュリティリーダー向け： 組織全体のセキュリティログ一元化・脅威ハンティング基盤の構築
• データアナリスト向け： Security Lake からの Athena・SageMaker による分析・機械学習モデル構築
• 意思決定者向け： Splunk Cloud・Datadog・Elastic Security・Sumo Logic・IBM QRadar SaaS との比較・投資判断

2025-2026 年の Security Lake エコシステム

• OCSF v1.8.0（2026 年 3 月）: AI Operation サポート（ai_operation, ai_model, message_context）、Privilege Analysis（privilege_info, privilege_attack_info, service_privilege_analysis）、macOS 拡張対応
• OCSF 国際標準化: ITU 加盟国が 2026 年 6 月の国際標準推進を支持。セキュリティスキーマの標準化が進行中
• AWS AppFabric 統合: SaaS アプリケーション（Slack・Salesforce・GitHub 等）のログを自動的に OCSF 形式で Security Lake へ配信
• Amazon OCSF Ready Specialization: AWS Partner Network プログラムで OCSF 対応パートナー の認定・拡大
• Subscriber 拡大: Splunk・Datadog・Elastic・Sumo Logic・QRadar・Crowdstrike・Palo Alto など 50+ パートナー統合
• AI Operation 対応: トークン使用量・ロールベース相互作用追跡による AI ワークロードの可視化

概要

初心者向けメモ： Security Lake は「組織のすべてのセキュリティログを一つの場所に集約・標準化する」サービスです。通常、CloudTrail は CloudTrail コンソール、VPC Flow Logs は VPC コンソール、GuardDuty は GuardDuty コンソールと各サービスごとにログを管理していますが、Security Lake はこれらをすべて S3 に OCSF 形式で統一して保存。Athena でクエリしたり、Splunk に流したり、SageMaker で分析したり自由に活用できます。

Security Lake が実現する 3 つの価値

Security Lake が解決する課題

1. セキュリティログの分散管理と可視性の喪失

課題：

CloudTrail ログ → CloudTrail S3（独自形式）
VPC Flow Logs → VPC コンソール（テキスト形式）
GuardDuty 検出 → GuardDuty コンソール（JSON）
WAF ログ → S3 カスタムフォルダ
Route 53 DNS ログ → CloudWatch Logs
↓
複数のログストア・複数のフォーマット・統一ダッシュボードなし
→ 脅威ハンティングに時間。監査トレール追跡困難

Security Lake の解決：

全ログソース
    ↓ OCSF 自動正規化
S3 Data Lake（Apache Parquet・OCSF 統一スキーマ）
    ↓ Athena / Splunk / SageMaker
単一ダッシュボード・統一クエリで脅威分析

2. 外部 SIEM との統合コストと複雑性

課題： Splunk・Datadog・QRadar などの外部 SIEM を導入する場合、各 AWS サービスのログを SIEM フォーマットに変換する独自 ETL パイプライン、変換ロジックの保守が追加コストになる。

Security Lake の解決： OCSF 対応パートナー（Splunk・Datadog・Elastic・Sumo Logic・IBM QRadar・Crowdstrike・Palo Alto など）が Subscriber として Security Lake の OCSF ログを直接消費可能。AWS → SIEM の標準化されたデータフローが実現。

3. マルチアカウント・マルチリージョン集約の複雑性

課題： 50 アカウント・10 リージョン環境で、各アカウント・各リージョンのセキュリティログを一箇所に集約するには手動で各リージョンの S3 バケットを作成・ログ転送設定が必要。

Security Lake の解決： Organizations 統合 + 集約リージョン（Rollup Region）指定で、自動的に全アカウント・全リージョンのログが中央 S3 に集約。ライフサイクルポリシーも統一管理。

4. ログ保持・コスト管理の非効率性

課題： CloudTrail ログは 90 日、VPC Flow Logs は 30 日など保持期間がバラバラ。長期保持する場合 Glacier 移行も各サービス個別対応。

Security Lake の解決： Security Lake で保持期間を一元管理。Apache Parquet + S3 Intelligent-Tiering で古いログは自動的に低コスト Glacier に移行。7 年保持も容易。

主要な特徴

アーキテクチャ

┌─────────────────────────────────────────────────────────────┐
│ AWS ネイティブソース                                        │
├─────────────────────────────────────────────────────────────┤
│ CloudTrail（管理 / データイベント）                        │
│ VPC Flow Logs（Layer 4 トラフィック）                     │
│ Route 53 Resolver Query Logs（DNS クエリ）                │
│ EKS Audit Logs（Kubernetes API 呼び出し）                │
│ AWS WAFv2 Logs（Web ACL マッチング）                      │
│ GuardDuty（脅威検知）                                     │
│ Security Hub CSPM（コンプライアンス検出）                 │
│ AWS Config（リソース構成変更）                             │
└────────┬──────────────────────────────────────────────────┘
         │
      ┌──┴──────────────────────────┐
      │                             │
      ▼                             ▼
┌──────────────────┐      ┌──────────────────────┐
│ External Sources │      │ Custom Sources       │
├──────────────────┤      ├──────────────────────┤
│ Okta Events      │      │ OCSF JSON データ      │
│ CrowdStrike      │      │ On-Premises ログ      │
│ Palo Alto        │      │ サードパーティ SIEM   │
│ Microsoft 365    │      │ アプライアンス        │
│ Slack            │      │ HTTP エンドポイント   │
│ Salesforce       │      │                      │
│ GitHub Enterprise│      │                      │
└────────┬─────────┘      └──────────┬──────────┘
         │                          │
         └──────────────┬───────────┘
                        ▼
            ┌───────────────────────┐
            │ Security Lake Service │
            │ (OCSF 正規化エンジン) │
            │                       │
            │ • スキーマ検証         │
            │ • Parquet 変換         │
            │ • パーティション作成   │
            │ • メタデータ管理       │
            └───────────┬───────────┘
                        ▼
            ┌───────────────────────┐
            │ S3 Data Lake Bucket   │
            │ (Parquet + OCSF)      │
            │                       │
            │ /yyyy/mm/dd/          │
            │   hh/mm/source/       │
            │   partition.parquet   │
            └───────────┬───────────┘
                        │
    ┌───────────────────┼───────────────────┐
    │                   │                   │
    ▼                   ▼                   ▼
┌─────────────┐ ┌──────────────┐ ┌────────────────┐
│ Athena      │ │ Lake Formation│ │ Subscriber     │
│ (SQL Query) │ │ (Tables)      │ │ (SIEM など)    │
└─────────────┘ └──────────────┘ │ • Splunk       │
    │                   │         │ • Datadog      │
    ▼                   ▼         │ • Elastic      │
┌─────────────────────────────────┤ • Sumo Logic   │
│ 脅威分析・ハンティング           │ • QRadar       │
│ コンプライアンス監査            │ • Custom App   │
│ 機械学習モデル構築              │                │
│ セキュリティ運用レポート        └────────────────┘
└─────────────────────────────────┘

EventBridge通知:
S3 PutObject → EventBridge → Lambda / SNS / SQS

OCSF（Open Cybersecurity Schema Framework）

OCSF とは

OCSF は Linux Foundation の主導で開発されたセキュリティログの標準スキーマ。様々なセキュリティソースのログを統一フォーマットで表現し、SIEM・分析ツール・ML モデルが同じスキーマで処理できるようにするフレームワーク。

OCSF v1.8.0（2026 年 3 月）の主要アップデート

v1.8.0 リリース内容:

1. AI Operation 対応
   - 新プロファイル: ai_operation
   - 新オブジェクト: ai_model, message_context
   - トークン使用量メトリクス
   - ロールベース相互作用追跡
   → LLM・AI ワークロードの可視化

2. Privilege Analysis（権限分析）
   - 新オブジェクト: privilege_info, privilege_attack_info, service_privilege_analysis
   - MITRE ATT&CK テクニック・マッピング
   - 未使用権限検出
   - アクセスリスク評価
   → 特権昇格・ラテラルムーブメント検出

3. macOS 拡張
   - プロセスオブジェクトに egid・euid 追加
   - Linux 拡張との統一

4. ITU 国際標準化
   - ITU（国連通信機関）が 2026 年 6 月推進予定
   - セキュリティスキーマの国際標準規格化へ

OCSF スキーマの構造

{
  "metadata": {
    "version": "1.8.0",
    "profiles": ["cloud", "endpoint"],
    "product": "Security Lake"
  },
  "severity": "HIGH",
  "activity_id": 3,  // 起動
  "activity_name": "Start Application",
  
  // 基本フィールド
  "time": 1707000000000,
  "source": {
    "ip": "203.0.113.45",
    "port": 54321
  },
  "principal": {
    "user": {
      "uid": "alice",
      "name": "alice"
    }
  },
  "resource": {
    "data": {
      "name": "/home/alice/.ssh/id_rsa"
    }
  },
  
  // プロファイル依存フィールド
  "process": {
    "name": "ssh-keygen",
    "pid": 1234
  },
  "privilege_info": {  // v1.8.0 新機能
    "privilege": "system.root",
    "privilege_display_name": "Root Access"
  }
}

Security Lake のデータソース詳細

AWS ネイティブソース

外部ソース（50+ パートナー）

主要ユースケース（10+）

1. マルチアカウント脅威ハンティング

要件： 50 アカウント・10 リージョン環境で、特定の外部 IP から全リージョンへのアクセスパターンを調査。

実装：

# Security Lake 有効化（Organizations）
aws securitylake create-data-lake \
  --regions us-east-1 us-west-2 eu-west-1 \
  --account-ids [all 50 account IDs]

# Athena でクエリ
SELECT 
  time,
  source.ip,
  principal.user.name,
  resource.cloud.region,
  action,
  COUNT(*) as event_count
FROM security_lake.ocsf_api_activity
WHERE source.ip = '203.0.113.99'
  AND time >= '2026-04-20'
GROUP BY source.ip, principal.user.name, resource.cloud.region, action
ORDER BY event_count DESC

成果： 特定 IP からのアクセスが全 50 アカウント・3 リージョンで確認。スクリーニングから検出まで数分。

2. OCSF 対応 SIEM への統合

要件： 既存 Splunk Enterprise を Security Lake のサブスクライバーとして利用。

実装：

# Security Lake Subscriber 作成
aws securitylake create-subscriber \
  --subscriber-name "splunk-integration" \
  --sources [ "aws-cloudtrail", "vpc-flow-logs" ] \
  --regions [ "us-east-1" ] \
  --source-account-id "111111111111"

# Splunk HEC でデータ受信設定
# ※ S3 イベント通知 → Lambda → Splunk HEC へのデータ転送

成果： AWS CloudTrail・VPC Logs が自動的に Splunk に流入。既存の Splunk ダッシュボード・アラートが即座に AWS データ対応。

3. SageMaker で ML 異常検知モデル構築

要件： VPC Flow Logs から異常なトラフィックパターン（DDoS・データ流出）を自動検知。

実装：

import pandas as pd
import sagemaker

# Security Lake から VPC Flow Logs 取得
athena_query = """
SELECT 
  src_ip, dst_ip, src_port, dst_port, 
  bytes_in, bytes_out, protocol, action
FROM security_lake.vpc_flow_logs
WHERE date_partition >= '2026-03-01'
"""

# Athena で実行
df = pd.read_sql(athena_query, athena_connection)

# SageMaker で Isolation Forest モデル学習
from sagemaker.estimators import Estimator
estimator = Estimator(
  image_uri="246618743249.dkr.ecr.us-east-1.amazonaws.com/sagemaker-xgboost:latest",
  role=sagemaker_role,
  instance_count=1,
  instance_type="ml.m5.xlarge"
)
estimator.fit({'training': s3_data_uri})

# リアルタイム推論エンドポイント作成
predictor = estimator.deploy(
  initial_instance_count=1,
  instance_type='ml.m5.large'
)

成果： 正常トラフィック学習後、異常スコア > 0.7 を自動検知。従来の固定閾値より検知精度向上。

4. SOC2 / FedRAMP 監査ログ保持

要件： CloudTrail ログを 7 年間保持。監査人が特定期間のログを Athena で即座にクエリ可能。

実装：

# ライフサイクルポリシー設定
aws s3api put-bucket-lifecycle-configuration \
  --bucket security-lake-prod \
  --lifecycle-configuration '{
    "Rules": [
      {
        "Id": "archive-after-90days",
        "Status": "Enabled",
        "Transitions": [
          {
            "Days": 90,
            "StorageClass": "GLACIER"
          },
          {
            "Days": 365,
            "StorageClass": "DEEP_ARCHIVE"
          }
        ],
        "Expiration": {
          "Days": 2555  # 7 年
        }
      }
    ]
  }'

# クエリ例：特定期間のアカウント削除操作
SELECT 
  time, principal.user.arn, event_name, request_parameters
FROM security_lake.cloudtrail_api_activity
WHERE 
  event_name IN ('DeleteUser', 'DeleteRole', 'DeleteAccessKey')
  AND time BETWEEN '2019-01-01' AND '2026-04-26'
ORDER BY time DESC

成果： 7 年分 CloudTrail（数 TB）を Glacier で保持。クエリ速度は Parquet により高速。監査コスト 60% 削減。

5. Organizations 全アカウント IAM リスク分析

要件： 全 50 アカウントの IAM ユーザー・ロール・パーミッションの一括分析。過剰権限を検出。

実装：

# CloudTrail API Activity から IAM アクション分析
SELECT 
  principal.user.arn,
  COUNT(DISTINCT action) as unique_actions_count,
  COUNT(*) as total_api_calls,
  resource.cloud.account_id
FROM security_lake.cloudtrail_api_activity
WHERE action LIKE 'iam:%'
  AND time >= date_format(date_add('day', -30, now()), '%Y-%m-%d')
GROUP BY principal.user.arn, resource.cloud.account_id
HAVING unique_actions_count > 50  # 異常に多い権限を使用
ORDER BY unique_actions_count DESC

成果： 過剰権限ユーザーを自動検出。最小権限ポリシーへの移行計画が容易に。

6. PrivilegeAnalysis（v1.8.0）による権限昇格検知

要件： 非 root ユーザーから root への昇格。MITRE ATT&CK T1548 (Abuse Elevation Control Mechanism) を検知。

実装：

-- v1.8.0 privilege_info オブジェクト使用
SELECT 
  time,
  principal.user.name,
  process.name,
  privilege_info.privilege,
  privilege_info.privilege_attack_info.techniques as mitre_technique
FROM security_lake.endpoint_activity
WHERE 
  privilege_info.privilege = 'system.root'
  AND principal.user.privileges_before NOT LIKE '%root%'
  AND time >= date_format(date_add('day', -1, now()), '%Y-%m-%d')
ORDER BY time DESC

成果： 権限昇格の時間・ユーザー・プロセス・使用技法を一括把握。事後分析が数倍高速化。

7. AWS AppFabric 統合による SaaS ログ一元化

要件： Slack・Salesforce・GitHub Enterprise のログを OCSF 形式で Security Lake に自動集約。

実装：

# AppFabric で Slack・Salesforce・GitHub を登録
aws appfabric create-app-authorization \
  --app-bundle-identifier "prod-bundle" \
  --app-name "slack" \
  --auth-type "oauth2"

# AppFabric が自動的に OCSF に正規化 → Security Lake へ配信
# → Security Lake Athena で横断クエリ可能

成果： 5+ SaaS の監査ログが Security Lake に統一フォーマットで流入。Splunk・Datadog 等で一括監視。

8. Route 53 DNS ログ + Network Traffic 相関分析

要件： DNS クエリ（Route 53）と VPC Flow Logs を相関させ、DNS トンネリング（データ流出）を検知。

実装：

-- DNS クエリと対応するネットワークトラフィック相関
SELECT 
  r53.time,
  r53.query_data.hostname,
  r53.source.ip,
  vpcflw.bytes_out,
  vpcflw.packets_out,
  CASE 
    WHEN vpcflw.bytes_out > 1000000 THEN 'SUSPICIOUS_HIGH_DATA'
    WHEN vpcflw.packets_out > 50000 THEN 'SUSPICIOUS_HIGH_PACKETS'
    ELSE 'NORMAL'
  END as risk_level
FROM security_lake.route53_query_activity r53
JOIN security_lake.vpc_flow_logs vpcflw
  ON r53.source.ip = vpcflw.src_ip
  AND r53.time = vpcflw.time
WHERE r53.query_data.hostname LIKE '%.dns-tunneling.%'

成果： DNS トンネリング・C2 通信の疑い「デバイスを特定」→「通信量確認」→「ブロック」。まで自動化。

9. GuardDuty 検出 + CloudTrail API ログ相関

要件： GuardDuty が異常を検知 → Security Lake で該当 API ログを即座に検索・根本原因分析。

実装：

# GuardDuty Finding: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration
# → EventBridge トリガー → Lambda

def lambda_handler(event, context):
    finding = event['detail']
    principal_arn = finding['resource']['instanceDetails']['iamInstanceProfile']
    
    # Security Lake で該当ユーザーの API ログを検索
    athena_query = f"""
    SELECT time, event_name, source_ip, request_parameters
    FROM security_lake.cloudtrail_api_activity
    WHERE principal.user.arn = '{principal_arn}'
      AND time >= date_format(
            date_add('hour', -6, 
              from_iso8601_timestamp('{finding['time']}')
            ), 
            '%Y-%m-%d %H:%i:%S'
          )
    ORDER BY time DESC
    """
    # Athena で実行 → セキュリティ運用チーム通知

成果： 脅威検知から根本原因分析まで数分で完了。人的調査コスト 80% 削減。

10. Compliance Posture Tracking（NIST / PCI DSS）

要件： CloudTrail・VPC Flow Logs・Config ログから NIST 800-53 SC-4（情報フロー制御）への準拠状況を自動スコアリング。

実装：

-- VPC Flow Logs から許可されないポート通信を検知
SELECT 
  time,
  src_ip, src_port,
  dst_ip, dst_port,
  protocol,
  COUNT(*) as blocked_attempts,
  'SC-4: Unauthorized port detected' as nist_control
FROM security_lake.vpc_flow_logs
WHERE 
  action = 'REJECT'
  AND dst_port IN (23, 69, 135, 139, 445, 3389)  -- 危険なポート
GROUP BY src_ip, dst_ip, protocol
ORDER BY blocked_attempts DESC

成果： NIST・PCI DSS 各コントロールへの準拠度を自動集計。監査レポート自動生成。

設定・操作の具体例

CLI による設定例

1. Security Lake 有効化（Organizations アカウント）

# Prerequisites: AWS Organizations enabled

# 1. Security Lake 有効化
aws securitylake create-data-lake \
  --regions us-east-1 eu-west-1 ap-northeast-1 \
  --account-ids 111111111111 222222222222 333333333333

# 2. データソース有効化
aws securitylake update-data-lake-source \
  --account-id 111111111111 \
  --source "AWS::CloudTrail::Management" \
  --enable true

# 3. VPC Flow Logs ソース有効化
aws securitylake update-data-lake-source \
  --account-id 111111111111 \
  --source "AWS::VPC::FlowLogs" \
  --enable true

# 4. Route 53 Resolver Logs ソース有効化
aws securitylake update-data-lake-source \
  --account-id 111111111111 \
  --source "AWS::Route53::ResolverLogs" \
  --enable true

# 5. 有効化状況確認
aws securitylake describe-data-lake \
  --account-id 111111111111

2. Subscriber 作成（Splunk 連携）

# Splunk SIEM を Subscriber として登録
aws securitylake create-subscriber \
  --subscriber-name "splunk-security-prod" \
  --access-type "S3" \
  --sources '[
    {
      "source_name": "aws.cloudtrail",
      "enabled": true
    },
    {
      "source_name": "aws.vpc_flow_logs",
      "enabled": true
    },
    {
      "source_name": "aws.guard-duty",
      "enabled": true
    }
  ]' \
  --subscription-protocol "s3" \
  --subscription-endpoint "s3://splunk-data-lake-bucket"

# Subscriber 情報取得
aws securitylake get-subscriber \
  --subscriber-name "splunk-security-prod"

# 新規オブジェクト書き込み時の通知設定
aws s3api put-bucket-notification-configuration \
  --bucket security-lake-prod \
  --notification-configuration '{
    "EventBridgeConfiguration": {}
  }'

3. Athena でクエリ（脅威分析）

# SQL クエリ作成・実行
aws athena start-query-execution \
  --query-string "
    SELECT 
      time,
      principal.user.arn,
      event_name,
      source.ip,
      action,
      error_code
    FROM security_lake.aws_cloudtrail_api_activity
    WHERE error_code LIKE '%Unauthorized%'
      AND time >= date_format(date_add('day', -7, now()), '%Y-%m-%d')
    ORDER BY time DESC
    LIMIT 1000
  " \
  --query-execution-context Database=security_lake \
  --result-configuration OutputLocation=s3://athena-results/

# 結果取得
aws athena get-query-results \
  --query-execution-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

SDK（Python）による設定例

import boto3
import pandas as pd
from pyathena import connect

# 1. Security Lake Client
client = boto3.client('securitylake', region_name='us-east-1')

# Subscriber 一覧取得
response = client.list_subscribers()
print("Subscribers:", response['subscribers'])

# 2. Athena でセキュリティログクエリ
connection = connect(s3_output='s3://athena-results/')

# GuardDuty 検出（過去 30 日）
query = """
SELECT 
  time,
  principal.user.arn,
  severity,
  finding_type,
  description
FROM security_lake.aws_guardduty_findings
WHERE time >= date_format(date_add('day', -30, now()), '%Y-%m-%d')
  AND severity >= 'MEDIUM'
ORDER BY time DESC
"""
df = pd.read_sql(query, connection)
print(f"GuardDuty Findings: {len(df)}件")
print(df)

# 3. マルチアカウント CloudTrail 分析
cloudtrail_query = """
SELECT 
  resource.cloud.account_id,
  principal.user.arn,
  COUNT(*) as api_calls
FROM security_lake.aws_cloudtrail_api_activity
WHERE time >= date_format(date_add('day', -1, now()), '%Y-%m-%d')
GROUP BY resource.cloud.account_id, principal.user.arn
HAVING COUNT(*) > 1000
ORDER BY api_calls DESC
"""
df_ct = pd.read_sql(cloudtrail_query, connection)
print(f"High-Activity IAM Users: {len(df_ct)} 件")
print(df_ct)

# 4. VPC Flow Logs で通信異常検知
vpc_query = """
SELECT 
  src_ip, dst_ip, dst_port, protocol,
  SUM(bytes_out) as total_bytes_out,
  COUNT(*) as flow_count
FROM security_lake.aws_vpc_flow_logs
WHERE 
  time >= date_format(date_add('day', -1, now()), '%Y-%m-%d')
  AND action = 'REJECT'
GROUP BY src_ip, dst_ip, dst_port, protocol
ORDER BY total_bytes_out DESC
LIMIT 100
"""
df_vpc = pd.read_sql(vpc_query, connection)
print(f"Rejected Flows (Top 100): {len(df_vpc)} 件")

IaC（CloudFormation）による設定例

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Security Lake Setup with CloudFormation'

Resources:
  # Security Lake Data Lake
  SecurityLakeDataLake:
    Type: AWS::SecurityLake::DataLake
    Properties:
      Regions:
        - us-east-1
        - eu-west-1
        - ap-northeast-1

  # CloudTrail ソース有効化
  CloudTrailSource:
    Type: AWS::SecurityLake::DataLakeSource
    Properties:
      DataLakeAccount: !Ref AWS::AccountId
      SourceName: AWS::CloudTrail::Management
      Enabled: true
      Regions:
        - us-east-1

  # VPC Flow Logs ソース有効化
  VPCFlowLogsSource:
    Type: AWS::SecurityLake::DataLakeSource
    Properties:
      DataLakeAccount: !Ref AWS::AccountId
      SourceName: AWS::VPC::FlowLogs
      Enabled: true
      Regions:
        - us-east-1
        - eu-west-1

  # GuardDuty ソース有効化
  GuardDutySource:
    Type: AWS::SecurityLake::DataLakeSource
    Properties:
      DataLakeAccount: !Ref AWS::AccountId
      SourceName: AWS::GuardDuty
      Enabled: true
      Regions:
        - us-east-1

  # Subscriber（Splunk）
  SplunkSubscriber:
    Type: AWS::SecurityLake::Subscriber
    Properties:
      SubscriberName: splunk-security-prod
      SubscriberDescription: Splunk SIEM integration
      AccessType: S3
      Sources:
        - SourceName: AWS::CloudTrail::Management
          Enabled: true
        - SourceName: AWS::VPC::FlowLogs
          Enabled: true
        - SourceName: AWS::GuardDuty
          Enabled: true
      SubscriptionProtocol: s3
      SubscriptionEndpoint: !GetAtt SplunkBucket.Arn

  # S3 バケット（Splunk データ受信）
  SplunkBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub 'splunk-security-lake-${AWS::AccountId}'
      VersioningConfiguration:
        Status: Enabled
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

  # Athena クエリ結果用 S3 バケット
  AthenaResultsBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub 'athena-results-${AWS::AccountId}'

  # Athena ワークグループ
  AthenaWorkgroup:
    Type: AWS::Athena::WorkGroup
    Properties:
      Name: security-lake-queries
      Description: Workgroup for Security Lake analysis
      RecursiveDeleteOption: true
      WorkGroupConfiguration:
        ResultConfigurationUpdates:
          OutputLocation: !Sub 's3://${AthenaResultsBucket}/'
        EnforceWorkGroupConfiguration: true

Outputs:
  DataLakeArn:
    Description: Security Lake ARN
    Value: !GetAtt SecurityLakeDataLake.Arn
  
  SplunkBucketName:
    Description: S3 Bucket for Splunk
    Value: !Ref SplunkBucket
  
  AthenaBucketName:
    Description: S3 Bucket for Athena Results
    Value: !Ref AthenaResultsBucket

類似サービス比較表

ベストプラクティス

✅ 推奨

❌ アンチパターン

トラブルシューティング表

2025-2026 最新動向

OCSF v1.8.0 と AI Operation 対応（2026 年 3 月）

• AI Operation プロファイル: LLM・生成 AI ワークロードのトークン使用量・相互作用追跡をネイティブサポート
• Privilege Analysis: MITRE ATT&CK との統合。権限昇格・ラテラルムーブメント検出が自動化
• macOS 拡張: Linux・macOS 統一スキーマで endpoint レベルの脅威検知が強化

ITU 国際標準化への推進（2026 年 6 月）

• ITU 加盟国（国連通信機関）が OCSF を国際標準規格として推進予定
• OCSF が ISO・IEC 等と並ぶ国際標準化により、グローバルセキュリティ規制への対応が容易に

AWS AppFabric との統合深化

• SaaS ログ（Slack・Salesforce・GitHub・Microsoft 365・Box 等）の自動 OCSF 正規化
• Security Lake + AppFabric で SaaS・AWS・オンプレミスのログが統一スキーマで流入

Amazon OCSF Ready Specialization

• AWS Partner Network プログラムが OCSF 対応パートナー（Splunk・Datadog・Elastic 等）を認定
• パートナー側の OCSF 対応化が加速。互換性・統合品質が向上

機械学習・異常検知の自動化

• SageMaker との統合深化で Security Lake のログから自動的に異常検知モデルを生成
• Bedrock（生成 AI）による根本原因分析・推奨事項自動生成

学習リソース・参考文献

公式ドキュメント・ガイド

• Amazon Security Lake ユーザーガイド
• Security Lake API Reference
• OCSF（Open Cybersecurity Schema Framework）ドキュメント
• AWS Security Lake ホワイトペーパー
• Security Lake 料金ページ

ベンダー・パートナー リソース

• Splunk: Security Lake Connector
• Datadog: AWS Security Lake Integration
• Elastic: OCSF Support
• IBM QRadar: OCSF インテグレーション
• Sumo Logic: AWS Security Lake ソースコネクタ

AWS ブログ・セミナー

• AWS Security Blog - Security Lake
• OCSF Achieves ITU Support
• Transform security logs into OCSF format
• Amazon Security Lake Generally Available

OSS・ユーティリティ

• OCSF GitHub Repository
• AWS Labs Security Lake Samples
• Athena SQL チートシート

実装チェックリスト

• [ ] AWS Organizations が有効化されているか確認
• [ ] Organizations 内の全アカウントに IAM ロール（SecurityLakeAdministrator）を付与
• [ ] Security Lake ホーム リージョン（us-east-1 推奨）選択
• [ ] CloudTrail・VPC Flow Logs・GuardDuty・WAF・Route 53 Logs 全て有効化
• [ ] Rollup Region（eu-west-1 等）を指定してマルチリージョン集約設定
• [ ] S3 ライフサイクルポリシー設定（90 日 Glacier・365 日 Deep Archive・2555 日削除）
• [ ] Lake Formation テーブル作成確認（aws_cloudtrail_api_activity 等）
• [ ] Athena ワークグループ・クエリ結果 S3 バケット準備
• [ ] EventBridge ルール設定（S3 PutObject → SNS / Lambda）
• [ ] Subscriber（Splunk・Datadog 等）作成・認証情報設定
• [ ] IAM ロール（Subscriber） 権限確認（S3 GetObject・ListBucket）
• [ ] CloudFormation テンプレート作成・組織内展開
• [ ] セキュリティ監査ログアクセステスト（Athena クエリ実行）
• [ ] SageMaker での異常検知モデル構築（オプション）
• [ ] Slack / PagerDuty 通知統合設定
• [ ] 定期的な脅威ハンティング クエリ・スケジュール設定
• [ ] コンプライアンスレポート自動生成（PCI DSS / NIST）

まとめ

Amazon Security Lake は、企業全体のセキュリティ監視・分析・コンプライアンスの基盤を構築するフルマネージドサービスです。

主な利点

• OCSF標準化: AWS・外部ソース・SaaS のログが統一スキーマで流入
• マルチソース分析: Athena・Splunk・Datadog・SageMaker で横断分析
• スケーラビリティ: 50+ アカウント・10+ リージョンの集約も自動化
• コスト最適化: Parquet・S3 Intelligent-Tiering で ストレージコスト 70% 削減
• 最新標準対応: OCSF v1.8.0（AI Operation・Privilege Analysis）、ITU 国際標準化

推奨対象組織

• 中堅〜大企業: マルチアカウント環境でセキュリティ一元管理が必須
• 金融・医療・公官庁: コンプライアンス監査ログ保持が要求される
• SaaS 企業: 顧客データセキュリティ監視・監査報告書自動生成が必須

Security Lake は 2026 年の AWS セキュリティ基盤の最優先投資対象 です。OCSF 国際標準化、AppFabric による SaaS 統合、Bedrock による AI 駆動分析など、エコシステムの急速な拡大が進行中。今から投資することで、5 年後の規制・脅威環境にも対応可能な「将来耐性」の高いセキュリティデータ基盤が実現します。

最終更新：2026-04-27 バージョン：v2.0