CloudTrailとFalcoによるAWS S3のセキュリティ

By 清水 孝郎 - MARCH 23, 2021

SHARE:

本文の内容は、2021年3月23日にAlba Ferriが投稿したブログ(https://sysdig.com/blog/aws-s3-security-cloudtrail-falco/)を元に日本語に翻訳・再構成した内容となっております。

クラウドに移行する際の大きな悩みの一つが、AWS S3のセキュリティにどのようにアプローチするかという事があるのではないでしょうか？企業は、ワークフローをAWSに移行したとしても、データウェアハウスの移行にはまだ慎重になっています。

それはとても理解できます。FacebookやGoDaddy、Pocketなどの企業におけるデータ漏洩については、誰もが耳にしたことがあるでしょう。このような情報漏洩を防ぐためには、情報へのアクセスを限定的かつ制御された方法で適切に行うことが重要です。
gray steel bucket on brown wooden bucketPhoto by Carolyn V on Unsplash

この記事では、AWS S3のセキュリティを強化する方法と、このサービスでCloudTrailの監査イベントを有効にする方法を紹介します。また、CloudtrailでAWS における脅威検知を実行する方法を説明し、また、無料で使用できるSysdig Cloud Connectorを活用して不審な活動を検知して早急に対応することができます。

Amazon S3リソースの保護を行う必要がある理由

ストレージをクラウドに移行する主な利点の1つは、人々がインターネットを介してそのデータにアクセスして使用できることです。クラウド以外の環境ではデータの共有がかなり困難なため、テクノロジーはデータのコラボレーションやマネタイズに最適な環境を提供します。

ただし、クラウドサービスの設定には注意が必要です。設定を誤ると、クラウド上のデータが無防備になってしまう可能性があります。例えば、間違ったボックスにチェックを入れてしまうと、知らないうちにS3リソースのアクセスコントロールが変更され、そのデータが一般にアクセス可能になってしまうことがあります。

だからこそ、継続的にデータを保護し、適切なツールを設定して、インシデントが大きなセキュリティ問題にならないようにする必要があるのです。

Amazon S3リソースへのアクセスコントロールを監視する

デフォルトでは、バケット、オブジェクト、および関連するサブリソースなどのすべてのAmazon S3リソースはプライベートです。これは、リソースの所有者、つまりリソースを作成したAWSアカウントのみがリソースにアクセスできることを意味します。

しかし、Webサイトの静的ファイルのように、データを公開したい場合もあるでしょう。そのために、AWS S3ではリソースオーナーがアクセスを変更するためのアクセスポリシーオプションが用意されています。

アクセスポリシーオプションは、大きく分けて以下のように分類されます：

  • リソースベースのポリシー：リソース（バケットやオブジェクト）に付与するアクセスポリシーをリソースベースポリシーと呼びます。例えば、バケットポリシーやアクセスコントロールリスト（ACL）はリソースベースのポリシーです。
  • ユーザーポリシー：アカウント内のユーザーにもアクセスポリシーを割り当てることができます。

Amazon S3リソースに対するパーミッションを管理するために、リソースベースポリシー、ユーザーポリシー、またはこれら2つの組み合わせを使用することができます。

残念ながら、いくつかのバケットのアクセス制御リスト（ACL）の組み合わせは、あなたのリソースを非常に簡単に公にアクセスできるようにします。ACLの設定ミスは、S3データリークが非常に広範囲に及ぶ最大の理由の1つです。そのため、AWSはACLの使用を推奨していません。

Amazon S3リソースへのアクセスを管理することは、強力なクラウドデータストレージのセキュリティガバナンスの基礎となります。

CloudTrailでS3イベントを記録する

AWS CloudTrailを有効にすると、ListObjects、PutObject、GetObject、DeleteObject、DeleteObjectsなど、AWS S3リソースに対して行われたすべてのリクエストの情報を記録することができます。インフラストラクチャーリソースに対して行われたすべてのアクションは、AWS CloudTrailのレジストリに結果として残ります。

これらの監査ログは、　自社のAWSリソースに関わる不審な活動を検出し、AWS S3のセキュリティを実装するための最初のステップとなります。

では、S3 CloudTrailのイベントを有効にする方法を見ていきましょう。

以下の手順では、すでにCloudTrailをデプロイし、監査イベントを監視していることを前提としています。クラウドセキュリティのためのCloudTrailの使用方法について、カスタマイズされたステップバイステップの説明を提供しているAWSワークショップを試してみることをお勧めします。

CTA：AWSワークショップまたはCTAをご受講ください：今すぐ学習を開始しましょう

最初のステップは、AWSアカウントにS3リソースを作成しましょう。バケットを作成したり、テストファイルをアップロードしたりしてください。

2番目のステップは、CloudTrailでS3リソースのデータイベントを有効にすることです。

そのためには、CloudTrail – Trailsを編集します。

そこから、データイベントのチェックボックスをマークし、イベントソースとしてS3を選択します。


下部では、どのバケットを監査するかを指定できます。すべてのバケットを監査するのか、それともアクセスを制御したいバケットだけを監査するのか。また、それぞれのバケットに対して、読み取りや書き込みのアクセスを区別して指定することもできます。

また、マネジメントイベント、データイベント、APIアクティビティの読み取りと書き込みが有効になっていることを確認してください。


Trailを作成または編集する際、新しいイベントが表示されるまでに最大10分かかることがあります。その間のイベントはバッファされ、失われることはありませんのでご安心ください。

さて、これで設定は完了です。認証されたユーザーがバケット内のデータにアクセスすると、CloudTrailはそのイベントをキャプチャーします。

AWS S3のイベントはどのようなものですか？

パイプラインが機能していることを検証するには、AWS Web Consoleから対象バケットのオブジェクトをリストアップして、イベントが表示されるのを待つだけです。

もう一つの簡単な例は、S3バケットに新しいファイルを追加することです。その場合、結果として発生するCloudTrailイベントはJSON形式で以下のようになります：
{
    "eventVersion": "1.08",
    "eventSource": "s3.amazonaws.com",
    "eventName": "PutObject",
    "awsRegion": "us-east-1",
    "requestParameters": {
        "bucketName": "test-s3-trail",
        "key": "test-folder/test-file3.txt",
    "resources": [
        {
            "type": "AWS::S3::Object",
            "ARN": "arn:aws:s3:::test-s3-trail/test-folder/test-file3.txt"
        },
        {
            "type": "AWS::S3::Bucket",
            "ARN": "arn:aws:s3:::test-s3-trail"
        }
    ],
}
以下に注目してください。
  • eventSourceは、S3からのイベントであることを示します。
  • eventName は、誰かが新しいファイルを追加したことを確認します。
  • bucketName は、どのバケットにファイルが追加されたかを示します。
  • key はファイル名とパスを含みます。

Sysdig Cloud ConnectorによるAWSの脅威検知

インフラが成長すると、イベントや運用の証跡が膨大になり、それらを分析することができなくなることがあります。

これは、CloudTrailがAWSアカウントで発生するすべてのイベントを効率的に記録していることに起因します。そして、これが問題となって、短時間で脅威に対応できず、重大な結果を招いてしまう可能性があるのです。


この問題を解決することこそが、Sysdig Cloud Connectorの目的です。

Sysdig Cloud Connectorは、すべてのCloudTrailエントリをリアルタイムに分析し、それらのイベントを柔軟なセキュリティルールに照らし合わせて評価することで、AWSの脅威を検知します。

Sysdig Cloud Connectorのインストールプロセスは、CloudFormationテンプレートの力を借りて、非常に簡単です。

FalcoルールとSysdig Cloud Connectorによる監査イベントの評価

CloudTrail for AWS S3を有効にし、Sysdig Cloud Connectorをアカウントにインストールすると、異常な動作の検知を開始するために必要なものがすべて揃った状態となります。

ここからは、AWS S3の操作など、問題のあるCloudTrailイベントをFalcoルールで検出する方法を見ていきましょう。

先ほど、新規S3ファイルのCloudTrailイベントがどのようなものかを紹介しました。
{
    "eventVersion": "1.08",
    "eventSource": "s3.amazonaws.com",
    "eventName": "PutObject",
    "awsRegion": "us-east-1",
    "requestParameters": {
        "bucketName": "test-s3-trail",
        "key": "test-folder/test-file3.txt",
    "resources": [
     …
    ],
}
次のFalcoルールは、このようなイベントを検出します。
- list: watched_bucket_events
  items: [CreateBucket, DeleteBucket]
- rule: Operation on buckets
  desc: Detect an operation on buckets.
  condition:
    not jevt.value[/errorCode] exists and
    jevt.value[/eventName] in (watched_bucket_events)
  output:
    Detected an operation on buckets
    ( bucket name=%jevt.value[/requestParameters/bucketName]
    operation=%jevt.value[/eventName],
    object key=%jevt.value[/requestParameters/key],
    requesting user=%jevt.value[/userIdentity/arn],
    requesting IP=%jevt.value[/sourceIPAddress],
    AWS region=%jevt.value[/awsRegion])
  priority: WARNING
  tags:
    - cloud
    - source=cloudtrail
    - aws
    - aws_s3
  source: k8s_audit
jevt.valueとjsonpath形式のクエリーを使って、監査イベントの一部を参照することができます。

これをルールの条件部分で使用します：
condition:
    not jevt.value[/errorCode] exists and
    jevt.value[/eventName] in (watched_bucket_events)
これにより、エラーなしで処理され、S3サービスに関連するイベントがフィルタリングされます。

ルールの出力部分で使用する％jevt.valueについても同じことが言えます：
output:
    Detected an operation on buckets
    ( bucket name=%jevt.value[/requestParameters/bucketName]
  …
この出力は、このルールがセキュリティイベントを生成することになった場合に、コンテキスト情報を提供するために使用されます。

カスタム・ルールをSysdig Cloud Connectorにデプロイする

Sysdig Cloud Connectorは、S3バケットを使用してアクティブなFalcoルールを保存します。

カスタムルールをデプロイするには、ローカルフォルダーをS3バケットと同期させます。ローカルフォルダーがgitリポジトリであれば、ルールの変更点を把握することができるので、ベストプラクティスと言えるでしょう。

ここでは、よりシンプルな方法をとります：

まず、rulesフォルダーを作成します。

ルールを rules フォルダーにコピーします。

親フォルダー（ルールが入っているフォルダー）から、以下のコマンドを実行します：
cc_bucket=$(aws cloudformation list-stack-resources --stack-name CloudConnector --output json | jq '.StackResourceSummaries[] | select(.LogicalResourceId=="CloudConnectorBucket").PhysicalResourceId' | xargs)
echo $cc_bucket
aws s3 sync "./rules/" s3://$cc_bucket/rules --delete
これでrulesフォルダーとS3バケットが同期されます。

この作業を行うためには、マシンにAWS CLIをセットアップする必要があり、トークンには十分な権限が必要であることに留意してください。

Cloud Connectorを再起動すると、新しいルールが追加されていることが確認できます：
task_id=$(aws ecs list-tasks --cluster CloudConnector --output json | jq '.taskArns[0]' | xargs | sed -E 's/.*\/(.+)/\1/')
echo $task_id
AWS_PAGER="" aws ecs stop-task --cluster CloudConnector --task $task_id
1分ほど待ってから、カスタムルールが読み込まれたと表示される新しいログが表示されるまで、このコマンドを実行し続けます。
cc_log_stream=$(aws logs describe-log-streams --log-group-name cloud-connector --order-by LastEventTime --descending | grep -m1 "ecs/CloudConnector/" | sed 's/"\(.*\)".*"\(.*\)",/\2/' | xargs)
echo $cc_log_stream
aws logs filter-log-events --log-group-name cloud-connector --log-stream-names $cc_log_stream --filter-patter "-http-server -console-notifier"
これでテスト用のS3バケットを操作して、CloudWatchのアラートログや、AWS Security Hubの調査結果の中に関連するイベントを確認できるようになりました。

最新の5つのアラートをコマンドラインから確認することができます：

aws logs get-log-events --log-group-name cloud-connector --log-stream-name alerts --no-start-from-head --limit 5

まとめ

クラウドセキュリティはAWSにとって最優先事項であり、それにはAWS S3のセキュリティも含まれます。しかし、それはAWSとあなた、あなたの会社、そしてあなたのDevOpsチームの間で共有される責任でもあります。あなたの組織がS3リソースやAWS環境全般のセキュリティに注意を払わないと、データ漏洩を起こしてしまう可能性があります。

この記事では、S3のアクセスコントロールを強化し、設定ミスを防ぎ、ワークロードを保護するためのヒントを紹介しました。また、AWS CloudTrailがまず取り組むべきセキュリティウォールとなることも紹介しました。

もっとFalcoのことを知りたいという方は：


Sysdig Cloud Connector for CloudTrailを導入してSysdig Secureを活用する事で、AWSにおける脅威検出を実装するために必要なランタイムの可視性を得ることができます。Sysdig Cloud Connector for CloudTrailは、すぐに利用できるFalcoルールを備えているため、セキュリティイベントの調査に必要な設定作業、応答時間、およびリソースを最小限に抑えることができます。

まだSysdigのアカウントをお持ちでない方は、今すぐ登録してトライアルをご利用いただけます。Sysdig Cloud Connectorをこの記事の手順に従って10分以内にデプロイし、安全なAWSアカウントにしましょう！

また、SysdigはAWS Marketplaceにもあります。