[アップデート]組織内のセキュリティデータをAWS上で一元管理できる！Amazon Security LakeがGA(一般利用開始)されました

みなさん、こんにちは。

明るい笑顔がトレードマーク、ルイボスティーが大好きな芦沢(＠ashi_ssan)です。

昨年のAWS re:Invent 2022で発表されたAmazon Security Lakeという新サービスをご存知でしょうか？

そんなSecurity Lakeが本日GAされました。

4行でわかるAmazon Security Lake

• AWS環境上のフルマネージド型セキュリティデータレイクが固定費なしの従量課金で利用できる（更に、１５日間の無料トライアルが利用可能！）
• CloudTrailログ、Route 53 Resolverクエリログ、Security Hubログ、VPCフローログなどのAWSネイティブサポートされたログ以外にも外部のデータソースの取り込みが可能
• Organizations管理アカウントまたはスタンドアロンAWSアカウントで有効化できる。Organizations配下のメンバーアカウントでは有効化不可。 (2023/6/1 追記)
• 現在、東京リージョンで利用できます。大阪リージョンは対象外。

Amazon Security Lakeとは？

Amazon Security Lakeは、フルマネージド型のセキュリティデータレイクサービスです。

有効化するとAWS環境、SaaSプロバイダー、オンプレミス、3rd PartyソースからのセキュリティデータをAWSアカウント上の専用のデータレイク(S3バケット)に自動保存します。

取り込まれたデータは、Apache Parquet形式 および Open Cybersecurity Schema Framework (OCSF) と呼ばれるオープンソーススキーマに変換されます。

収集できるデータの例としては、AWSでネイティブにサポートされている以下のログや外部のさまざまカスタムソースがあります。

• AWS CloudTrail - Management events
• AWS CloudTrail - Lambda data events
• AWS CloudTrail - S3 data events
• Amazon Route 53 Resolver クエリログ
• AWS Security Hub Findings
• Amazon Virtual Private Cloud (Amazon VPC) フローログ

Preview時の情報になりますが、Amazon Security Lake ではじめる簡易な SIEMというAWSのDeep Diveセミナーで利用された資料にSecurity Lakeのアーキテクチャが公開されていますので、こちらを紹介します。

内部的にはLake Formationを中心としたデータレイクが構成されるようです。このようなソリューションを簡単に手に入れられるのはとても便利ですよね。

その他より詳しい情報については公式ドキュメントもあわせてご覧ください。

前提条件 (2023/6/1 追記)

Security Lakeを有効化できるAWSアカウントの種類は以下の通りです。

• AWS Organizations環境の管理アカウント
• スタンドアロン AWSアカウント

Security LakeはOrganizationsと統合してログ収集を管理するため、始めにOrganizationsの管理者権限を持つアカウントを利用することになります。 残念ながらOrganizations配下のメンバーアカウントからはサービスを有効化できませんので、ご注意ください。

後述する検証ではControl Tower環境を利用しますが、通常のOrganizations環境でも同様の手順で有効化可能です。

有効化してみた

検証環境として、事前に有効化済みのControl Tower（以降CTと略します）環境を利用します。

CT管理アカウントから操作を始めました。

始めに、委任管理者の設定から実行する必要があるようです。

私の検証環境では、AuditアカウントをSecurity Hub、Detective、GuardDutyの委任管理者を設定していますが、嬉しいことにサジェストしてくれていますね。そのまま、Auditアカウントを委任管理者として設定していきます。

委任管理者として設定できました。以降の設定は委任管理者アカウントから実行する必要があるようなので、アカウントをスイッチします。

委任管理者アカウントとして設定したアカウントで、設定を開始します。まずは、収集目標を設定していきます。

ログとイベントソースを選択から、取り込むログのサービスを以下から選択する もしくは この中全てを取得するように設定できます。

• CloudTrail - Management events
• CloudTrail - Lambda data events
• CloudTrail - S3 data events
• VPC flow logs
• Route 53
• Security Hub findings

今回は検証用途なので、データ取り込み量が多そうなCloudTrail - Lambda data events、CloudTrail - S3 data eventsを除外して、それ以外のソースを選択しました。

続いてリージョンを指定します。

今回は東京、バージニア北部の2つを選択しました。

有効化対象のアカウントは、委任管理者アカウント自身と、もう1つメンバーアカウントにしてみます。

サービスアクセス用のロールはデフォルトで作成してくれるもの（AmazonSecurityLakeMetaStoreManager）を使います。

作成されるロールの許可の詳細はこのようになっています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowWriteLambdaLogs",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": [
        "arn:aws:logs:*:{{accountId}}:log-group:/aws/lambda/SecurityLake_Glue_Partition_Updater_Lambda*:*"
      ]
    },
    {
      "Sid": "AllowCreateAwsCloudWatchLogGroup",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup"
      ],
      "Resource": [
        "arn:aws:logs:*:{{accountId}}:/aws/lambda/SecurityLake_Glue_Partition_Updater_Lambda*"
      ]
    },
    {
      "Sid": "AllowGlueManage",
      "Effect": "Allow",
      "Action": [
        "glue:CreatePartition",
        "glue:BatchCreatePartition"
      ],
      "Resource": [
        "arn:aws:glue:*:*:table/amazon_security_lake_glue_db*/*",
        "arn:aws:glue:*:*:database/amazon_security_lake_glue_db*",
        "arn:aws:glue:*:*:catalog"
      ]
    },
    {
      "Sid": "AllowToReadFromSqs",
      "Effect": "Allow",
      "Action": [
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:GetQueueAttributes"
      ],
      "Resource": [
        "arn:aws:sqs:*:{{accountId}}:*"
      ]
    }
  ]
}

ロールアップリージョンを設定すると、提供元リージョンの全てのデータがロールアップリージョンに統合されるようです。

今回は使いません。

ロールアップリージョンを使用する場合は、別途サービスロールを作成する必要がありこちらもデフォルトで作成してくれるもの（AmazonSecurityLakeS3ReplicationRole）を利用できます。

作成されるロールの許可の詳細はこのようになっています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadS3ReplicationSetting",
      "Action": [
        "s3:ListBucket",
        "s3:GetReplicationConfiguration",
        "s3:GetObjectVersionForReplication",
        "s3:GetObjectVersion",
        "s3:GetObjectVersionAcl",
        "s3:GetObjectVersionTagging",
        "s3:GetObjectRetention",
        "s3:GetObjectLegalHold"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::aws-security-data-lake-[[sourceRegions]]*",
        "arn:aws:s3:::aws-security-data-lake-[[sourceRegions]]*/*"
      ]
    },
    {
      "Sid": "AllowS3Replication",
      "Action": [
        "s3:ReplicateObject",
        "s3:ReplicateDelete",
        "s3:ReplicateTags",
        "s3:GetObjectVersionTagging"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::aws-security-data-lake-[[destinationRegions]]*/*"
      ]
    }
  ]
}

ストレージクラスを設定で、Security Lakeのデータを保存するS3バケットのライフサイクルルールが設定できるようです。

今回は検証用途なのでExpire(期限切れ)の設定をしておきました。

最後に設定の確認を行い、作成をクリックします。

Security Lake をオンにしていますというポップアップが表示されるため、しばらく待ちましょう。

無事有効化されました。画面上方に表示されているように、１５日間の無料トライアルが利用できるみたいですね。

ここからはコンソール上でそれぞれの機能を確認してみます。

Security Lakeの各機能をざっと確認してみる

ログ

まずはS3バケットから確認してみましょう。

ログの保存先S3バケットは、サービスを有効化したアカウント(=Security Lakeの委任管理者アカウント)内に有効化したリージョン単位で自動作成されます。ログの保存先アカウントを別途指定することは現時点ではできなさそうです。

ログは以下の形式に正規化されて保存されていました。

s3://aws-security-data-lake-ap-northeast-1-fvaaaaaaaaaaaaasdssdsdd/aws/SH_FINDINGS/1.0/region=ap-northeast-1/accountId=123456789012/eventDay=20230530/

作成時に指定したライフサイクル設定は、「SecurityLake_Generated_Rule_0」という名前でルールが設定されていました。想定通り、5日で有効期限切れになるように設定されています。

ちなみに、S3バケットポリシーのサンプルはこちらです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::aws-security-data-lake-ap-northeast-1-kxthy2ytyuoxaaaaaaaaaaaaa/*",
                "arn:aws:s3:::aws-security-data-lake-ap-northeast-1-kxthy2ytyuoxaaaaaaaaaaaaa"
            ],
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        },
        {
            "Sid": "PutSecurityLakeObject",
            "Effect": "Allow",
            "Principal": {
                "Service": "securitylake.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::aws-security-data-lake-ap-northeast-1-kxthy2ytyuoxaaaaaaaaaaaaa/*",
                "arn:aws:s3:::aws-security-data-lake-ap-northeast-1-kxthy2ytyuoxaaaaaaaaaaaaa"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control",
                    "aws:SourceAccount": "１２３４５６７８９０１２"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:securitylake:ap-northeast-1:１２３４５６７８９０１２:*"
                }
            }
        }
    ]
}

ソース

ここからはSecurity Lakeのコンソール画面を確認していきます。

ソースでは、取得するAWSサービスの有効化/無効化ができるようです。

ソースを選択し有効化をクリックすると、現在Security Lakeが有効になっているリージョンの一覧が表示されます。

Security Lakeを有効化している組織単位でデータソースの有効化/無効化が簡単に行えそうです。

サブスクライバー

サブスクライバーを設定すると、仕様に基づいたデータへのアクセス権限が付与されます。

以下の2種類のサブスクライバーアクセス権をサポートしています。

• データアクセス権
• クエリアクセス権

データアクセス権は、HTTPエンドポイントやSQSキュー経由で新しいオブジェクトがSecurity Lakeのデータレイク(S3)に書き込まれた際に通知するアクセス許可設定を管理します。クエリアクセス権は、Security Lakeが収集したデータに対してAthenaなどを利用してクエリ経由でアクセスする許可設定を管理します。

詳細については、公式ドキュメントを確認してみてください。

本件こちらから設定できますが、サブスクライバーアクセスに関する詳しい設定例は別のエントリで紹介してくれることを期待します。

リージョン

リージョンごとのSecurity Lakeが有効化/無効化などの状態の確認やデータが保存されるS3バケットの情報などが確認できます。

ロギングの停止やリージョンの追加も簡単に行えそうです。

カスタムソース

カスタムソースを利用すると、Security Lakeに外部のカスタムソースからログやイベントを収集できるようです。

コンソールの表記や公式ドキュメントの情報から、ログやイベントの収集はGlue クローラーを利用して実行されるようです。

Glueクロウラーに設定するために作成が必要な、IAMロールの許可設定がこちらです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3WriteRead",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::aws-security-data-lake-{{bucket}}/*"
      ]
    }
  ]
}

カスタムソースを取り込む際のベストプラクティスはこちらのドキュメントにまとまっています。

本件も、実際の追加時の挙動については、続報である外部のカスタムソースを追加してみたブログに期待します。

プレビューからの変更点

AWS Blogにて、プレビュー時からの変更点についても触れられていたのでこちらも紹介します。

具体的な変更点は以下のようです。

• OCSFの最新バージョン(version 1 rc2)のサポート
• CloudTrail管理イベントが認証、アカウント変更、APIアクティビティの3つの異なるOCSFイベントクラスで正規化されるようになった
• AWSコンソール上からIAMロールの自動作成が可能になった
• CloudTrailのデータソースが3つの中(Management event, Data event, Lambda data event)から柔軟に選択できるようになった
• S3のパーティショニングが時間単位から日単位に変更された
• CloudWatchメトリクスの追加
• 15日間の無料トライアルの追加
• サードパーティ統合のサポートを拡大（23の新規パートナーの追加）

詳しくは前述したAWS Blogをご確認ください。

料金

Security Lakeの料金は、以下のような固定利用費のない従量課金となっています。 有効化するデータソースの種類や、組織のデータ保存料金にもよりますが、使い始めやすい料金設定になっているのでは、と思います。

種類	料金
CloudTrailログ	0.75USD /GB
その他のログ(10 TB まで)	0.38USD /GB
その他のログ(次の 20 TB)	0.228USD /GB
その他のログ(次の 20 TB)	0.114USD /GB
その他のログ(50 TB 超)	0.076USD /GB
正規化	0.035USD /GB

対応リージョン

対応リージョンは現時点で以下になります。

• Asia Pacific (Singapore)　[ap-southeast-1]
• Asia Pacific (Sydney)　[ap-southeast-2]
• Asia Pacific (Tokyo) [ap-northeast-1]
• Europe (Frankfurt) [eu-central-1]
• Europe (Ireland) [eu-west-1]
• Europe (London) [eu-west-2]
• South America (Sao Paulo) [sa-east-1]
• US East (N. Virginia) [us-east-1]
• US East (Ohio) [us-east-2]
• US West (Oregon) [us-west-2]

東京リージョンでは利用できますが、大阪リージョンではまだ使えません。

参考

• Amazon Security Lake が一般提供になりました | AWS セキュリティブログ
• Amazon Security Lake とは何ですか? - Amazon セキュリティレイク
• Amazon Security Lake ではじめる簡易な SIEM

最後に

本エントリでは本日GAされたAmazon Security Lakeの概要について確認し、サービスを有効化するところまでの検証を行いました。 外部のデータソースの取り込みや、データレイクへのアクセスの検証は行えていないので続報にご期待ください。

Organizations環境だと管理者側から有効化させる必要があるため、環境によっては有効化のハードルが高いと想定していますが、データソースを限定すれば従量課金でかなりお安く利用開始できそうですので、まずは検証利用から始めてみてはいかがでしょうか？

以上、芦沢(＠ashi_ssan)でした。