AWS シャドウリソース攻撃から情報を守る - Prisma^® Cloudから考えるセキュリティ（3）

クラウド

新山紗友里

メルマガ登録する

メルマガ登録する

クラウドサービス部の新山です。

ラックでは、Prisma^® Cloud（プリズマクラウド）を用いたクラウドセキュリティ統制支援サービスを提供しています。Prisma^® Cloudは、パロアルトネットワークス社が展開する、マルチクラウドやハイブリッドクラウド環境におけるクラウドリソースの設定上の脆弱性や不審な挙動を、業界標準の各種コンプライアンス基準や独自の基準に従い、継続的に監視・可視化するSaaS型のサービスです。

アラートの内容

このアラートは、Amazon EMR Studioで使用しているWorkspaceストレージ用のバケットが、現在のアカウントから管理されていないシャドウリソースを使用していることを検知するものです。

ここでいうシャドウリソースとは、AWSのサービス機能や仕様によって自動生成されるリソースを指します。S3バケット名は一意であるため、悪意のある攻撃者によって既に作成されたリソースを使用している場合、データ操作や情報窃取などのリスクが発生します。

詳細なアラートの条件は、以下の2つを満たしたAmazon EMR Studioを検知します。

S3バケット名が"aws-emr-studio-"で始まる

Amazon EMR StudioのWorkspaceストレージ用のS3バケット名が"aws-emr-studio-"で始まる場合、作成時にWorkspaceストレージ用のS3の場所で「新しいバケットを作成」を選択し、自動生成されたバケットを指定している可能性があります。

こうした自動生成によるS3バケット名は容易に推測されやすいため、悪意のある第三者が予測したバケット名群を対象に総当たりで閲覧可能か確認する「ブルートフォース攻撃」を試みる恐れがあり、誤って外部公開しているバケットが攻撃された場合は情報漏えいする可能性があります。

S3バケットが現在のアカウントから管理されていない

Amazon EMR Studioで使用しているWorkspaceストレージ用のS3バケットが現在のアカウントから管理されているかを確認します。S3バケットが現在のアカウントから管理されていない場合、悪意のある第三者によって作成されたS3バケットの可能性が高く、データ漏えいのリスクだけでなく、データ操作などのリスクがより高まります。

対処方法

現在、AWS側でこのシャドウリソース攻撃に対する脆弱性は修正されています。

既にS3バケットが存在する場合、AWSは新しいバケット名を選択するよう求めており、既に作成されているバケットを使用しないよう、Amazon EMR Studioを作成します。そのため、事前にS3バケットを作成する場合の注意点と、既にAmazon EMR Studioを作成している場合のAmazon EMR Studioの設定とS3バケットの確認をする手順について紹介します。

AWS CloudFormationやCLIでAmazon EMR Studioを作成する際に、アカウント内に存在するS3バケットを確認しないまま「aws-emr-studio-{Account-ID}-{Region}」を指定してしまった場合は特に、設定内容の確認をおすすめします。

新規にS3バケットを作成する際の注意点

Amazon EMR Studioを作成する前に、事前にWorkspaceストレージ用のS3バケットを準備する場合だけでなく、S3バケットを作成する際も同様に注意が必要なことがあります。

S3バケット名は一意であるため、既に使用されているS3バケット名は新たに作成できません。つまり、S3バケット名が既に使用されているかは、全世界の人々が確認できる状況であることを理解する必要があります。そのため、S3バケット作成の際、一意になるよう、命名規則などを設計する必要がありますが、容易に想像できるようなS3バケット名にしないことをおすすめします。

また、S3バケット名から機密情報が推測されるようなものを使用しないことも重要です。事前にS3バケットを作成するだけでなく、容易に想像できるようなS3バケット名にしないこともセキュリティ強化に繋がります。

既存の設定内容の確認

既にAmazon EMR Studioを作成している場合は、設定内容を確認し、Workspaceのストレージに記載のS3バケット名を確認します。

Amazon EMR Studioの設定内容を確認。Workspaceのストレージを確認。

Workspaceのストレージはリンクになっていますが、万が一、第三者のアカウント内のS3バケットだった場合を考慮し、S3サービスを開いてバケットの一覧にAmazon EMR Studioで設定しているS3バケットが存在することを確認します。

もし、管理しているアカウントにS3バケットが存在しない場合は、第三者のアカウント内のバケットである可能性があるため、異なる名前でS3バケットを作成し、Amazon EMR StudioのWorkspaceのストレージの場所を変更する必要があります。

Workspaceのストレージを確認しただけでは、S3バケットが管理下にあるのかわからないため、S3サービスでの確認を行いましょう。確認後、S3バケットに対する権限を必要最低限にするなど、管理下にあってもセキュリティ強化に努めることで重要な資産を守れます。

脆弱性対応について

現在、AWS側でこのシャドウリソース攻撃に対する脆弱性は修正されていると記載しましたが、どのような対応がされているのか検証してみました。

他のアカウントで"aws-emr-studio-{Account ID}-{region}"というバケットを作成している場合、Amazon EMR Studioの作成画面は以下のように、「新しいバケットを作成」が選択できないようになっています。

そのため、現在は悪意のある第三者によって作成されていたS3バケットを使用するリスクは最小限になります。

おわりに

今回はAmazon EMR StudioのWorkspaceのストレージの場所に焦点を当てて事例を紹介しましたが、以下のサービスでも作成時に自動生成されるS3バケットを使用する場合は同様に注意が必要です。

AWS CloudFormation
AWS Glue
Amazon SageMaker
AWS CodeStar
AWS Service Catalog

シャドウリソースを使用する場合は、そのリソースが管理可能なアカウント上に存在するかを確認することでリスクを抑えられます。作成時に自動生成されるS3バケットは便利ですが、その背後にあるリスクもあることを十分理解した上で使用する必要があります。この脆弱性は2024年6月に修正が完了しているので、それ以前に上記リソースを作成している場合は、念のためS3バケットを確認しておくことをおすすめします。

また、今回紹介したアラート以外にも、Prisma^® Cloudでは多数のセキュリティリスクを検知します。そして、ラックの長年にわたるシステム開発とセキュリティのノウハウを集め提供する「クラウドセキュリティ統制支援サービス」では、検知したアラートの対応を支援するサービスも提供しています。AWS含め、パブリッククラウドのセキュリティに不安がありましたら、ぜひラックにご相談ください。