トップ > セキュリティ > AWS で発生したら最悪なセキュリティインシデントを考えてみよう

AWS で発生したら最悪なセキュリティインシデントを考えてみよう

セキュリティ AWS Organizations Well-Architected Framework AWS
記事タイトルとURLをコピーする

セキュリティサービス部 佐竹です。
今回は、AWS Well-Architected Framework の「SEC 10. How do you anticipate, respond to, and recover from incidents? (SEC 10. インシデントの予測、対応、復旧はどのように行いますか?)」の対応に関連して、発生したら最悪と考えられるセキュリティインシデントを考えてみます。

はじめに

ここ何年か、AWS におけるランサムウェア対策のご相談を受けることが増えています。その一環として記載したのが以下のブログでもあります。

blog.serverworks.co.jp

さて、対策はもちろん、これだけでは終わりません。

特に、運用の観点から重要なのは「起きえるインシデント」を予め考えておき、「その対応に備えて検討しておくこと（可能ならば手順化しておくこと）」です。

その中でも特に「最悪の事態を想定しておく」ことが重要です。さて、何故「最悪の事態」を考えておくことが重要でしょうか？

発生したインシデントが想像を超える場合、人間は心理的なショックを受け平常通りの行動ができなくなります。加えて、最悪を想像しない限り対策を設計に入れることもできません。対策が設計に組み込まれれば、手順化や周知などの準備が可能になりますし、ショック状態にもなりにくいわけです。

このため、「最悪の事態」を考えたいというのが、本日の趣旨です。

AWS Well-Architected Framework のセキュリティの柱

AWS には Well-Architected Framework というフレームワークが存在します。これは、クラウドアーキテクトが安全で高性能、障害耐性が高く、効率的なインフラストラクチャを構築するためのベストプラクティス集です。本ブログにおいては、その中でも「セキュリティの柱」に関する話題を取り上げます。

docs.aws.amazon.com

セキュリティの柱は「データとシステムの保護、リスクの制御」に焦点を当てています。

このフレームワークが重要視される背景としては、クラウド利用の拡大に伴い、設定ミスや運用不備によるセキュリティ事故が後を絶たない現状が（残念ながら）あります。AWS の機能をただ使うだけでなく、「どのように安全に使うか」という指針が必要不可欠になります。

SEC 10. インシデントの予測、対応、復旧

セキュリティの柱には多くの項目がありますが、今回フォーカスするのは「SEC 10. インシデントの予測、対応、復旧はどのように行いますか?」です。

docs.aws.amazon.com

SEC 10 の解説を簡単にしてみます。

どんなに成熟した予防的、発見的統制（ガードレールなど）が実装されていても、組織はセキュリティインシデントが発生する可能性をゼロにはできません。そのため、インシデントの潜在的な影響に対応し、緩和するメカニズムを実装する必要があります。

事前に準備しておくことで、いざインシデントが発生した際にチームが効果的に動作し、問題を切り分け、封じ込め、フォレンジックを実行し、運用を既知の正常な状態に復元する能力に強く影響します。

セキュリティインシデントが起こる前にツールとアクセス権を整備し、ゲームデー (実践訓練) を通じてインシデント対応を定期的に実施しておけば、ビジネスの中断を最小限に抑えながら復旧することができます。

プレイブックの重要性と SEC10-BP04

この SEC 10 のベストプラクティスの中に「SEC10-BP04 セキュリティインシデント対応プレイブックを作成し、テストする」があります。

docs.aws.amazon.com

インシデント対応プロセスにおいて、プレイブック（手順書・対応マニュアル）は言わずもがな重要です。セキュリティイベントが発生したときに従うべき規範的なガイダンスと手順が記載されたものです。

この SEC10-BP04 の中には以下の通りの記載があります。引用してご紹介します。

  • 予想されるインシデント: プレイブックは、予測されるインシデントに合わせて作成する必要があります。これには、サービス拒否 (DoS)、ランサムウェア、認証情報の漏えいなどの脅威が含まれます。

ここで「予測されるインシデント」という表記があります。これが、先の「最悪の事態を想定しておく」ことに繋がります。

補足事項

ここから先は、AWS Organizations を利用したマルチアカウント構成を前提として話を進めます。

このため、既に AWS Organizations の知識がある方に向けて記述しています。

blog.serverworks.co.jp

AWS Organizations における OU 構成や SCP について理解されたい方は上記ブログも合わせてご覧ください。

私が考える「最悪のインシデント」とは何か

さて、ここからが本題です。 プレイブックを作るためにも、ゲームデー（訓練）を行うためにも、まずは「想定シナリオ」、「想定セキュリティインシデント」が必要です。

AWS Organizations を利用したマルチアカウント構成を前提とした場合、私が考える「AWS 環境における最悪のインシデント」の1つをご紹介します。

それは、「管理アカウントの Root ユーザーが奪取され、全拒否(DenyAll)の SCP を適用されること」です。

想定される最悪のインシデントの詳細

具体的には以下のような流れです。

  1. 攻撃者が何らかの手法（フィッシング等）で、AWS Organizations の管理アカウント（Management Account）の Root ユーザーの権限を奪取する。
  2. 攻撃者が AWS Organizations の Root （あるいは全 OU）に対して、「全ての操作を拒否する (DenyAll)」Service Control Policy (SCP) を作成し、アタッチする*1。
  3. 攻撃者は管理アカウントの IAM ユーザーやロール全てに、「全ての操作を拒否する (DenyAll)」IAM ポリシーをアタッチする。もしくは IAM ユーザーやロール全てを削除する。
  4. 攻撃者は管理アカウントの Root ユーザーの権限を保持したまま「SCP をデタッチしてほしければ、要求に従え」と、脅迫を行う。

これは、AWS Organizations への Living Off The Land 型の攻撃とも言えるでしょう。

Living Off The Land は直訳すると「その土地の恵みで生きていく」という意味になります。外部から食料や物資を持ち込むのではなく、その場所にある自然資源（狩猟、採集、農業など）だけで生活することを指します。

ですが、サイバーセキュリティの世界では Living Off The Land は「環境寄生型」や「自給自足型」の攻撃を意味します。攻撃者が自分のツール（マルウェア）を持ち込む代わりに、ターゲットのコンピュータ内に最初から備わっている正規のツール（PowerShell やコマンドプロンプトなど）を悪用する手法です。今回は AWS Organizations の正規機能が悪用されるケースを想定しています。

参考：AWSDenyAll

arn:aws:iam::aws:policy/AWSDenyAll

AWS Managed Policy に「AWSDenyAll」というものがあります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAll",
            "Effect": "Deny",
            "Action": [
                "*"
            ],
            "Resource": "*"
        }
    ]
}

このような全ての操作を拒否するポリシーを、AWS Organizations の Root にアタッチされた、という状況を想像してください*2。

AWS Organizations 環境構成図

AWS Organizations 環境構成図

AWS Organizations の Root と OU 構成を踏まえた図にすると、上図の通りです。AWS Organizations Root に「全拒否」のポリシーをアタッチすると、全階層＆全エンティティに同様のポリシー「全拒否」が付与されます。そして、「明示的な拒否」は最も強いため、これにより全メンバーアカウントは全ての権限が Deny されることになります。

なぜこれが「最悪」なのか？

この状況が発生すると、以下のような事態に陥ります。

  1. メンバーアカウントの機能不全
    SCP は管理アカウント以外の全てのメンバーアカウントに影響します。よって「全拒否」のポリシーが適用されると、メンバーアカウント内での API 操作は一切できなくなります。

    • EC2 の起動/停止も、構成変更もできません。ただし既に起動している EC2 インスタンスの OS は利用継続できるでしょう（API Call が拒否されるためインスタンスプロファイルは機能しなくなります）
    • Auto Scaling は機能しなくなるでしょう
    • Lambda 等のサーバレスもおそらく発火しなくなるでしょう
    • CloudTrail や Config、GuardDuty などのセキュリティ監視サービスが有効化されていたとしても、それを閲覧することができなくなります
    • 運用監視ツールもデータを CloudWatch から取得することができず、監視運用が行えなくなる可能性があります。外部からの Ping 監視や HTTP 監視など、AWS の API Call を伴わない監視は動作するでしょう

  2. 「管理アカウント」は SCP の対象外
    SCP は管理アカウント自身には適用されません。つまり、攻撃者が握っている管理アカウントだけは正常に動作し、攻撃者は「SCP をデタッチする権限」を独占します。なお、管理アカウントの IAM ユーザーやロールは、SCP の対象外のため、DenyAll(SCP) の影響を受けません。このため、攻撃者は IAM ユーザーやロールにも「全ての操作を拒否する (DenyAll)」IAM ポリシーをアタッチすることで、完全な AWS アカウントの奪取を実現します。もしくはそれらの入口となりえるリソースを全て削除してしまうでしょう*3。

  3. イミュータブルバックアップの無力化
    「ランサムウェア対策としてバックアップを WORM (Write Once Read Many) で保護しているから大丈夫」と思われるかもしれません。しかし、SCP でアクセス権限そのものが拒否されている場合、そもそもバックアップデータにアクセスすることや、リストア（復元）API の呼び出しすらできません。「データはそこにあるのに取り出せない状態」となってしまう可能性があります。バックアップデータ自体は守られていても、復旧プロセスがロックされるという状況に陥ります。

  4. 組織ごとの放棄が必要
    メンバーアカウント単体の侵害であれば、そのアカウントを切り離して（閉鎖して）、別のアカウントでバックアップから復旧するという「アカウントの乗り換え」が可能です。ですが、管理アカウントを握られている場合、その組織（AWS Organizations）配下の全てのアカウントが人質です。組織ごと放棄するしかありませんが、本番環境のすべてを即座に別組織へ移行（作り直し）することは、現実的に極めて困難です。

いわば、管理アカウントを乗っ取って組織全体をロックし、「解除してほしければ身代金を払え」と要求する、ランサムウェア（恐喝）攻撃が成立してしまうのではないかと想定されます。

私たちができる対策と心構え

少々、怖い話をしたかもしれませんが、不安がらせることが目的ではありません。このリスクを正しく理解し、対策を講じることが目的です。

1. 管理アカウントの保護は最優先事項

既にご存じの通りですが、2024年半ばより、AWS Organizations の管理アカウントのルートユーザーで AWS マネジメントコンソールにサインインする場合、MFA（多要素認証）が AWS により強制的に必須化されました。

aws.amazon.com

これは非常に強力な防壁です。ですが、近年では MFA トークンすら盗み取る高度なフィッシング攻撃も存在します。

リセラーや企業の管理者は、管理アカウントの Root 認証情報を扱う際、フィッシングサイトではないか、端末がマルウェアに感染していないかなど、極めてシビアに管理する必要があります。

2. AWS サポートへのエスカレーションはどうか？

もし万が一、Root ユーザーが奪取され MFA も変更されてしまった場合、ユーザー側でできる技術的な対抗策はほぼなくなってしまうと想像します。

その際は、AWS サポートへの緊急エスカレーションに一縷の望みを託すことになると想定します。しかし、ここでも「銀の弾丸」的な回復は期待できないでしょう。

というのも、AWS サポートに問い合わせたとしても、対応は基本的にはケースバイケースであり、「強制的に SCP を解除できる」という保証がないためです。また、仮に対応が可能だとしても、厳格な本人確認プロセスなどにより、復旧までには致命的なタイムラグが発生することが予想されます。

決して見捨てられるわけではありませんが、完全な回復までには想定できないレベルのタイムラグが発生すると想定されます。そのタイムラグ（つまり RTO）を許容できないビジネスなら、事前対策（MFA 強化等）がより重要となってきます。

またそもそも論としては、もしこの状況に陥ってしまった場合には、通常の AWS サポートケース起票すら不可能になる可能性があります。こうした「通常の連絡手段が絶たれた状態」まで見越して、代替のエスカレーションルートや運用手順を事前に検討しておくことが、より実践的な備えとなります*4。

3. SCP 運用の見直し（理想論として）

現時点の AWS の単体機能では実現できないため、難しい部分もありますが、「SCP の変更操作」に対して、承認フローを組み込むなどの対策も検討の余地があります（例えば、IaC で管理し、Pipeline 上で承認を必須にするなど）。

ただ、管理アカウントの Root ユーザーを奪取された場合はコンソールから直接操作されるため、やはり Root ユーザーの保護が最も重要な点であることに変わりはありません。

管理アカウントのベストプラクティス

AWS は AWS Organizations における管理アカウントのベストプラクティスをドキュメントにまとめ、公開しています。

docs.aws.amazon.com

以下はそのトピックです。

  1. 管理アカウントにアクセスできるユーザーを制限する
  2. 誰がアクセスできるかを確認、追跡する
  3. 管理アカウントは、管理アカウントが必要なタスクにのみ使用してください
  4. 組織の管理アカウントにワークロードをデプロイすることを避ける
  5. 分散化のために管理アカウント外に責任を委任する

やはり「管理アカウント」はいかに普段利用させないか、という観点で運用を実装することが重要であるとわかります。

そして普段、管理アカウントを業務利用されている方は、その保持する権限が「最小特権」のベストプラクティスに則っているかどうか、定期的に権限を見直されてはいかがでしょうか。

Code Spaces 事件 (2014年)

10年以上前の古い事例ではありますが、今回のブログで想定したような「最悪のシナリオ」が似た形で現実となってしまった実例として、以下の事件が挙げられます。

それが2014年6月17日に発生した Code Spaces 事件です。事件の概要を記載します。

かつて存在したコードホスティングサービス「Code Spaces」は、AWS マネジメントコンソールの管理権限を奪取され、攻撃開始から約1日で事業継続不能が確定しました。

攻撃者は12時間ほど継続したとされる DDoS 攻撃の裏で管理コンソールへ侵入し、身代金を要求*5。会社側がコントロールを取り戻そうとパスワードリセットを試みた後、それに気づいた攻撃者が本番データ、バックアップ、構成情報をすべて削除しました。

主要なバックアップと顧客データの大部分が消失したことで、同社は「ビジネスを継続するための財政的・信頼的基盤を失った」とし、事件の翌日には廃業を宣言しました。

  • 補足：当時は1つの AWS アカウントに全リソースを展開するのが基本であり、現在のようなマルチアカウント管理の概念はまだほとんどなかった記憶です（私の見てきた AWS の世界では、ですが）。また、Root ユーザーの MFA の必須化もあまり厳格になされていなかった時代の話としてお読み頂ければと存じます。

詳しくは他社様のブログとなりますが「Code Spaces AWS Security Breach: A Sad Reminder of the Importance of Cloud Environment Password Management」をご参考ください。

まとめ

今回は、AWS Well-Architected Framework の SEC 10 の考えに基づき、マルチアカウント環境における「最悪の想定セキュリティインシデント」をシミュレーションしてみました。

  • 管理アカウントの Root ユーザー奪取 ＋ 全拒否 SCP アタッチ ＝ 組織全体が強制停止させられる
  • バックアップがあっても、権限拒否によりリストア操作すらできなくなる可能性がある
  • 事後対応（AWS サポートへの救済依頼）も確実ではないため、管理アカウントの MFA 管理 (フィッシング対策含む) は組織の生命線である

「そんなこと起きるわけがない」と思考停止するのではなく、「もし起きたらどうするか？」を一度チームで話し合ってみてもいいでしょう。それだけで、防御への意識は大きく変わるはずです。また、他にも「これ以上に最悪な想定インシデントはあるだろうか？」と会話してみてください。

皆さんも「これが起きたら最悪だ」と思う想定シナリオがあれば、ぜひどこかで私まで教えてください。

では、またお会いしましょう。

*1:ここでいう Root とは AWS Organizations の Root であって、アカウントの Root ユーザーではありません

*2:念のため補足ですが、SCP と IAM ポリシーは別ですので、これをそのまま SCP としてアタッチするわけではありません。このような内容を記載した SCP を別途作成し、AWS Organizations Root や OU アタッチすることができます

*3:なお、IAM ユーザーやロールが使える状態であれば、それらでアカウントにログインし、SCP をデタッチして修復するチャンスはあります

*4:なお、ログインできない場合は、恐らくログインせずに利用できる公開問い合わせフォーム等から連絡を試みることになりますが、そこからの本人確認プロセス等にはかなり手こずりそうです

*5:身代金の要求は DDoS を停止してほしかったら、ということであったが、同時にバックドアも仕掛けられていた

佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ

セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。