データ漏洩に繋がるAWSの構成不備

私どもVaronis Systems, Inc (NASDAQ: VRNS) は、データセキュリティと分析の先駆者で、データ保護、脅威の検出と対応、およびコンプライアンスに特化したソフトウェアを開発しています。 このコラムでは、サイバーセキュリティ、プライバシー、データ保護についての最新のトレンドや知見、分析情報、事例などを皆様にご紹介していきたいと考えております。

第25回目となる今回は、「データ漏洩に繋がるAWSの構成不備」と題して、Unit 42が発見した公開されたAWS環境の.envファイルを通じたデータ恐喝キャンペーンがどのように起きた技術的背景を説明した後、設定の安全性の確保、アクセス範囲の適正化、異常なアクティビティの監視を含むAWS IAMセキュリティのベストプラクティスを紹介する、Varonis Threat Labsによるブログ記事を紹介します。

8月下旬、AWS環境が公開された.envファイルを通じて侵害されたことが発覚しました。Unit 42の研究者チームは、AWSアクセスキー、データベースやソーシャルメディアアカウントの資格情報、SaaSアプリケーションやメールサービスのAPIキー、さまざまなクラウドサービスのアクセストークンを含むファイルを公開しているデータ恐喝キャンペーンを発見しました。

約11万個のドメインが影響を受け、9万を超える固有の環境変数を露出させる可能性があり、そのうち7千個は組織が使用するクラウドサービスに対応するものでした。 これは何を意味するのでしょうか？

AWSを利用している場合は、設定の安全性を確保し、アクセス許可の範囲を適正化し、異常なアクティビティを監視していることを確認する絶好の機会です。

構成不備が攻撃の扉を開く

脅威アクターは、自動化されたツールを使用してドメインを確認し、重要な情報が含まれた公開された.envファイルをハッキングしました。AWSのアクセスキーを使用して、攻撃者はGetCallerIdentity APIコールを実行し、公開された資格情報に割り当てられたIDやロールを検証しました。

侵害されたAWS環境に入ると、攻撃者は、公開されたAWS IAM (Identity and Access Management) ロールが、すべてのリソースに対する管理者権限を持っていないことに気づきました。ただし、新しいIAMロールを作成し、既存のロールにIAMポリシーをアタッチするアクセス許可は持っていました。これにより、このアクターはlambda-exという新しいロールを作成し、その権限を完全な管理者権限に昇格させることができました。

AWS Lambdaは、ユーザーが提供したアプリケーションコードをオンデマンドで実行するように設計されたサーバーレスコンピューティングプラットフォームです。今回は、ハッカーはこのプラットフォームを使用して、他のドメインで公開されている.envファイルをスキャンするbashスクリプトを配備し、それらのファイルから資格情報を抽出して、以前侵害した公開S3バケットにアップロードしました。

AWS IAMセキュリティのベストプラクティス

.envファイルや.gitファイルを誤って公開してしまうことは、他の調査でも過去に警告している既知の問題であるため、攻撃者がWebクローラーを実行して、ドメインのルートフォルダにあるこのような公開されたファイルを探すことは珍しいことではありません。しかし、このオペレーションの実行規模は、AWSの構成不備が多くの組織にとって依然として広範な問題であることを示唆しています。

ベストプラクティスとして、AWS は、アクセスキーのような長期的な資格情報を持つIAMユーザーの代わりに、AWS Identity and Access Management (IAM) ロールを使用することを推奨しています。ただし、これはすべての組織にとって選択肢ではない可能性があります。

アクセスキーを使用する場合、IAMセキュリティのベストプラクティスでは、侵害されたIAMアクセスキーのセットがAWSアカウント内のコンポーネントにアクセスすることを防ぐために、IAM資格情報を定期的にローテーションすることを推奨しています。

このパターンは、単一のアカウントまたは複数のアカウントでの展開をサポートしています。AWS Organizationsを使用している場合、このソリューションは組織内のすべてのAWSアカウント IDを識別し、アカウントが削除されたり、新しいアカウントが作成されたりすると動的にスケールします。一元化されたAWS Lambda関数は、引き受けられたIAMロールを使用して、選択した複数のアカウントに対してローテーション関数をローカルで実行します。

•    新しいIAMアクセスキーは、既存のキーが90日経過した時点で生成されます。
•    新しいアクセスキーはAWS Secrets Managerにシークレットとして保存されます。リソースベースのポリシーでは、シークレットにアクセスして取得できるのは、指定されたIAMプリンシパルのみです。キーを管理アカウントに保存することを選択した場合、すべてのアカウントのキーが管理アカウントに保存されます。
•    新しいアクセスキーが作成されたAWSアカウントの所有者のメールアドレスに通知が届きます。
•    以前のアクセスキーは、100日後に非アクティブ化され、110日後に削除されます。

Lambda関数とAmazon CloudWatchは、これらのアクションを自動的に実行します。その後、新しいアクセスキーペアを取得し、コードまたはアプリケーションで置き換えることができます。ローテーション、削除、および非アクティブ化の期間はカスタマイズ可能です。

さらに、Varonisのセキュリティ専門家は、潜在的な攻撃に対して、侵入後の横展開や権限の昇格をより困難にするために、以下のヒントを推奨しています：

•    タグ付けを強制するSCPは、攻撃者が自動的に新しいIDを作成することをより困難にします。

IAMユーザーとロールにリソースのタグ付けを強制するAWS Service Control Policy (SCP) はAWS組織で作成されたすべてのIAMユーザーやロールに特定のタグを持たせることを保証できます。 <これは、ガバナンス、コスト配分、管理のような用途に役立ちます。

このような SCP の構成例を以下に示します：

{
        "Version": "2012-10-17",
        "Statement": [{
            "Sid": "EnforceTaggingOnIAMUsersAndRoles",
            "Effect": "Deny",
            "Action": ["iam:CreateUser", "iam:CreateRole", "iam:TagUser", "iam:TagRole"],
            "Resource": "",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestTag/Environment": ["Production", "Development", "Staging"],
                    "aws:RequestTag/Owner": ["Finance", "HR", "Engineering"]
                }
            }
        }, {
            "Sid": "EnforceTaggingOnTagOperations",
            "Effect": "Deny",
            "Action": ["iam:UntagUser", "iam:UntagRole"],
            "Resource": "",
            "Condition": {
                "ForAnyValue:StringEquals": {
                    "aws:TagKeys": ["Environment", "Owner"]
                }
            }
        }]
    }

説明

1. Sid: EnforceTaggingOnIAMUsersAndRoles:
     - このステートメントは、指定されたタグ (`Environment` と `Owner`) が含まれていて、許可された値  (`Production`, `Development`, `Finance`, `Engineering`など) のいずれかを持っていない限り、IAMユーザーまたはロールを作成することを拒否します。

2. Sid: EnforceTaggingOnTagOperations:
     - このステートメントはIAMユーザーとロールから必須タグ (`Environment` と `Owner`) を削除する機能を無効にします。

要点

aws:RequestTag/TagKey: この条件を設定することにより、IAMリソースの作成やタグ付けの際に、必要なタグが存在し、許容可能な値を持つ必要があることが保証されます。

ForAnyValue:StringEquals: この条件は、指定されたタグキーのいずれかが操作中に削除されているかどうかを確認し、削除されている場合はそのアクションを拒否します。

サービスコントロールポリシー (SCP) の適用

このSCPを適用するには、AWS Organizations内の適切な組織単位 (OU) またはルートにアタッチします。そうすると、そのOUまたはルートの下にあるすべてのアカウントにタグ付けポリシーが適用されます。

•    アクセスキーがgitignoreの一部であり、コードベース内で公開されていないことを確認します。
•    CI/CDの一部として、SCMのバックアップを決してS3にアップロードしてはいけません。また、指定したリポジトリーの外部にコードベースをプッシュすることは避けてください。
•    環境変数にボールト以外のストレージを使用することは構いませんが、アクセスキーは指定されたセキュリティ強化された領域（コンテナー）内に配置すべきです。

Varonisがお手伝いできること

通常、.envファイルはEC2インスタンス上にあります。しかし、これは必ずしもそうとは限らず、VaronisのセキュリティチームはS3でもそのファイルを見つけています。Varonisのプラットフォームでは、.envファイルがどこにあっても、AWSのID（IAM）、ストレージ（S3）、データベース（RDS）、コンピュータ（EC2）をスキャンしてシークレットを検出できます。

Privileged Policiesビューは、不審なアクティビティ—この攻撃に見られるような異常なアクセスや権限の昇格など—を検出するのに役立ちます。

さらに、Varonisは、AWSアカウントにおける過剰なアクセス許可や有害な設定の組み合わせを特定し、それらの構成不備を自動的に修正し、露出を削減して機密性の高い資産を保護するお手伝いをします。

参考資料

・オリジナルブログ記事（英文）
https://www.varonis.com/blog/aws-misconfigurations-expose-data

・Leaked Environment Variables Allow Large-Scale Extortion Operation in Cloud Environments（英文）
https://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/

・AWS Organizations と AWS Secrets Manager を使用して IAM ユーザーアクセスキーを大規模に自動的にローテーションする
https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-rotate-iam-user-access-keys-at-scale-with-aws-organizations-and-aws-secrets-manager.html

ブログ記事著者の紹介

Varonis Threat Labs

セキュリティ研究者とデータサイエンティストで構成されるVaronisのチームは、世界で最も優れたサイバーセキュリティ人材を集めたグループです。軍、諜報機関、法人で数十年にわたる経験を持つこのチームは、Varonisの脅威の検出と対応能力の進化を担っています。

（翻訳：跡部 靖夫）