AWS活用、誰もがハマる落とし穴。

〇 アカウントが乗っ取られた！ 初期対応で回避したいAWSの落とし穴。

ITシステムの開発や運用の経験があったとしても、AWS（アマゾン・ウェブ・サービス）の仕様について理解が不十分だったり、思い込みがあったりして落とし穴にはまってしまうことがあります。今回は、AWSアカウントが乗っ取られた際の初期対応に関するヒヤリハットを架空の事例として再現し、どうすれば落とし穴を避けられるかを解説します。

AWSを利用する際、セキュリティ対策が欠かせません。Amazon EC2の仮想サーバー、EC2インスタンスをはじめとするAWSリソースや、AWSを利用する際のアカウントそのものが、他者に乗っ取られないよう、ユーザーとして日ごろから適切な対策を講じておく必要があります。

しかし、それでもAWSアカウントが乗っ取られてしまうことがあるかもしれません。こうした場合、初期対応が非常に重要となります。ここで注意したいのが、初期対応の中にもAWSの落とし穴が潜んでいるということです。この落とし穴にはまってしまうと、初期対応はうまくいったものの、有効な再発防止策を打てない、といった状況に陥りかねません。

そこで今回は、フィクションの事例を交えながらこの落とし穴を解説します。その後、AWSアカウントが乗っ取られた時の初期対応のポイントについても紹介していきます。

落とし穴：サイバー攻撃阻止の措置でヒヤリハット。

AWSアカウントが乗っ取られる。

ある日、技術的な問題を支援するAWSのサービス「AWSサポート」から1通のメールがX社のIT部門に届いた。この部門に所属するA氏は不思議に思いながら、メールを開いて内容を確認した。

メールの本文は英文だったが、「あなたが利用中のAWSアカウント内にある仮想サーバーが、インターネット上の他のサーバーに許可なくアクセスしようとしている、との報告を外部から受けた。AWSの利用規約で禁止されている動きなので、停止措置を講じてほしい。仮想サーバーなどの環境が外部のサイバー攻撃者に侵害されていたり、仮想サーバーが意図せず使用されていたりする可能性がある」といった内容だった。

IT部門のAWSアカウントで利用しているEC2インスタンスは社内システム向けの1台だけだ。EC2インスタンスは、ストレージサービスの「Amazon EBS」にOSをインストールして動かす、いわばAmazon EBS-Backedインスタンスだった。広く一般的に利用されているタイプのインスタンスである。この他、AWSリソース用の仮想プライベートネットワーク「Amazon VPC」も利用している。このEC2インスタンスが稼働しているAWSのデータセンター所在地は東京リージョンだ。

AWSサポートからのメールから、IT部門のAWSアカウントが乗っ取られて、EC2インスタンスが他のサーバーへサイバー攻撃を行っているようだと分かった。A氏はただちにチーム内でこの情報を共有。検討したところ、A氏が対応に当たることになった。しかしA氏はまだ経験が浅い。そこで経験豊富な先輩エンジニアのB氏の支援を受けて、一緒に対応作業を進めることにした。

B氏はA氏に一連の作業の大まかな流れを説明。そのうえで、実態調査に乗り出した。B氏の指示により、利用コストやリソースの使用量を把握・管理できるサービス「AWS Cost Explorer」を開き、これまでに使っているものとは別にEC2インスタンスが立ち上がっていないかをまず確かめることにした。他のサーバーへサイバー攻撃を行える状況にあるIT部門のAWSリソースを特定し、状況を潰すための動きである。

その結果、普段利用している東京リージョン以外に4つのリージョンを利用していることが分かった。その4つのリージョンでは、大量のEC2インスタンスが立ち上がっていた。いずれもAmazon EBS-Backedインスタンスだった。

大量のEC2インスタンスを立ち上げたり、利用したりした覚えは、A氏やB氏を含め部門のメンバーにはなかった。「このままだとサイバー攻撃に使われ続けてしまいかねない。すぐに動きを止めなくちゃ」。そう考えたA氏は、AWSリソースなどの管理機能を提供するAWSマネジメントコンソールの画面から、大量のEC2インスタンスのうちまず1台の状態を「実行中」から「終了」へと変えようとした。

それを見たB氏はすかさず「ちょっと待って」とA氏を制止した。驚いて動きを止めたA氏に対してB氏は制止した理由を説明。そのうえで設定すべき適切な状態を伝えた。

A氏はB氏のアドバイスに沿って、大量のEC2インスタンスの状態を順次、変更していった。その結果、一時的にではあるものの、サイバー攻撃に使われる状況を解消できた。「Bさんが適切な対処方法を教えてくれたことで、今後の原因究明が進まないという落とし穴にはまらずに済みました。ありがとうございます」。A氏はほっと胸をなでおろし、B氏にこうお礼を述べた。

「いえいえ、とんでもない。切迫している状況なので、私もその落とし穴に陥ってしまうかもしれません。さておしゃべりはこれくらいにして次に取りかかりましょう」。B氏はこう応じ、2人は作業を続けた。

＊　このストーリーはフィクションです。

AWSアカウントが乗っ取られたという知らせをきっかけに、身に覚えのない大量のEC2インスタンスが立ち上がっているのを確認したA氏は、サイバー攻撃に使われないように、これらのインスタンスの動きを止める措置を講じようとしました。インスタンスの状態を切り替えようとしたところ、B氏が制止。A氏はB氏のアドバイスを受けて、適切な状態に切り替えたことで、落とし穴を回避できた。そんなヒヤリハット事例でした。

ではB氏はA氏に対してどんなアドバイスをしたのでしょうか。答えは「インスタンスの状態を実行中から終了にするのではなく停止にする」でした。

いったん立ち上げたEC2インスタンスは再起動したり、終了したりできます。このケースで登場したAmazon EBS-Backedインスタンスではさらに停止などの状態に切り替えることが可能です。

インスタンスの停止と終了の大きな違いとは。

この停止という状態は、終了とどう違うのでしょうか。停止の場合、インスタンス上のデータはAmazon EBSに残すことができます。しかし、終了にしてしまうと明示的に設定していない限り、EBSボリューム（EC2インスタンスからは独立していて永続性があるストレージのこと）は削除されてしまうのです。停止と終了はEC2インスタンスの動きを止めるという点で同じですが、データが残るかどうかという点で大きな違いがあるのです。

今回のケースでは、サイバー攻撃に使われる可能性をなくすための措置を講じた後、フォレンジック調査をする必要があるかもしれません。フォレンジック調査とは、どのような攻撃をしたのか、他の利用者にどういった影響を与えてしまったのかなどを調べることを指します。

終了ではなく停止にするのは初期対応が終わった後、ログや使われた攻撃ツールの解析など、インスタンスをより詳しく調査できるようにするためです。ログの解析では、「どのIPアドレスからこのインスタンスにアクセスしてきたか」といった攻撃元IPアドレスを特定したり、インスタンスの起動時刻や攻撃者が通信プロトコルのSSHでログインした時刻を特定したりできます。

この状況でもし終了にしてしまうと、インスタンスのデータは残らないので調査ができなくなる可能性があります。これは初期対応の落とし穴と言えるので、押さえておきましょう。インスタンスを終了にするのは、詳しい調査が全て終わってからにしましょう。

また、乗っ取られたAWSアカウント内で、自分たちが立ち上げたインスタンスがある場合、可能ならばそれらも停止しましょう。サイバー攻撃に悪用されている可能性が捨てきれないからです。

例えば、ファイアウオールとして機能する「セキュリティグループ」の設定でSSHを使って誰でも簡単にアクセスできる状態になっている可能性があります。インスタンス上で稼働しているアプリケーションで使っている認証情報が攻撃者に盗まれている可能性も否定できません。

乗っ取られた時期や場所はCost Explorerの利用料金でつかむ。

落とし穴の解説が一段落しましたので、今回のケースでA氏とB氏がAWS Cost Explorerを使ってどんな確認作業をしたのかを、詳しく解説しましょう。インスタンスなどが乗っ取られた場合、初期対応のはじめの一歩となる作業ですので、落とし穴と合わせて押さえておきましょう。

確認するとよいのが、利用料金の変化です。EC2インスタンスを1台しか運用していなければ、利用料金は少額で一定のままのはずです。しかし、大量のEC2インスタンスが新たに立ち上がれば、その日以降、利用料金が跳ね上がるので、いつからEC2インスタンスが増えたのかを確認できます。Cost Explorerでは利用料金をグラフで表示させることができるので、視覚的に把握できます。

今回のケースを模した日別のグラフを見てみましょう。利用しているサービスごとの料金を、積み上げ棒グラフの形で見ることができます。水色がEC2インスタンスの利用料金、紫色がそれ以外の利用料金です。

画１、利用料金の変化を示すCost Explorerのグラフ表示の例。横軸を時間（日）、縦軸を利用料金にしたうえで、利用しているサービスを切り口に日別の変化を見ている。水色がEC2インスタンスの利用料金、紫色がそれ以外のサービスの利用料金になる。

これを見ると、ある日から利用料金が急増していることが分かります。このグラフ表示では、ディメンション（切り口）を変更できます。そこで、どのリージョンで利用料金が増えているのか、ディメンションを「サービス」から、利用している「リージョン」に変更して見てみましょう。

画２、利用料金の変化を示すCost Explorerのグラフ表示の例。横軸を時間（日）、縦軸を利用料金にしたうえで、利用しているリージョンを切り口に日別の変化を見ている。オレンジ色が東京リージョンの利用料金を、水色や紫、緑、赤はそれ以外のリージョンの利用料金を、それぞれ示している。

棒グラフのうち、ごく薄く見えるオレンジ色が、これまで使ってきた東京リージョンの利用料金です。これに対してある日以降、東京以外のリージョンの利用料金を示す水色や紫、緑、赤といった色が急激に伸びています。このグラフからは、「東京リージョン以外で普段利用していないはずの4つのリージョンが利用されている」と分かるのです。

こうすることで身に覚えがなく停止すべきEC2インスタンスがどこで立ち上がっているのか当たりを付けることができ、停止措置をスムーズに進められるようになります。

インスタンスの停止だけでは不十分。

ここまでは「怪しいリソースの特定・停止」と言える対応でした。これでEC2インスタンスがサイバー攻撃に悪用されるリスクを抑制できたかに見えます。しかし、これだけで十分とは言えません。さらなるリスク抑制策を講じたうえで、再発防止策の検討を進めていく必要があります。そうしなければ、サイバー攻撃者に大量のEC2インスタンスを再起動されかねません。

具体的には、「認証情報のローテーション・削除」を行います。「怪しいリソースの特定・停止」と合わせると、この2つが「EC2インスタンスが乗っ取られた際の初期対応で、講じるべき措置」と言えます。

認証情報のローテーションとは、AWSアカウントやAWSのリソースを利用するために作成済みの認証情報の削除や新しい認証情報の作成をしたうえで、システムなどで使う認証情報を入れ替えることを指します。何者かがEC2インスタンスを起動したのは、第三者が自身のAWSアカウントなどへ不正アクセスできる状態にあったからです。これ以上、不正アクセスをされないように、認証情報のローテーションや削除を行いましょう。

この認証情報については、AWSアカウント内の全ての権限を持つ「ルートユーザー」と、必要な権限が付与された「IAMユーザー」のそれぞれで、ローテーションや削除をしていきます。

まずAWSアカウントのルートユーザーについては、AWSアカウント内で最も強い権限を持ちます。これが乗っ取られると悪用される範囲が広範にわたってしまう可能性があり、最悪の場合、アカウント自体が削除されてしまいます。ですから、通常は一切使用しないようにしましょう。

ルートユーザー関連対策は2つの可能性を考えて講じる。

今回のケースのように、AWSアカウントが乗っ取られている可能性が少しでもある場合、ルートユーザーについては、必ず「AWSマネジメントコンソール経由で侵入されている」「アクセスキーが不正利用されている」といった2つの可能性があると考えて、対策を講じるようにしてください。

「AWSマネジメントコンソール経由で侵入されている」という可能性に対しては、ルートユーザーとしてAWSマネジメントコンソールへログインする際のパスワードを、推測されにくい文字列に変更しましょう。多要素認証 (MFA)によるログインが設定されていない場合には、MFAを設定するようにします。

また「アクセスキーが不正利用されている」とは、API（アプリケーション・プログラミング・インターフェース）などを使ってAWSのリソースにアクセスするための認証情報である「アクセスキー」を使って、サイバー攻撃者が不正にAWSリソースを利用していることを指します。ルートユーザーは、前述の通り非常に強い権限を持つため、ルートユーザーに対するアクセスキーは作成しないようにしましょう。

                                                     （出所：123RF）

もしルートユーザーに対するアクセスキーを作成済みで「有効化」の状態にある場合、「無効化」にしましょう。「削除」にもできますが、初期対応が終わった後に不正利用されていないかどうかを調査するのに利用するため、この場合は「無効化」の措置を講じます。削除は調査完了後にしてください。

IAMユーザーの使用履歴から乗っ取られた可能性を探る。

次にIAMユーザーについて対策を講じていきます。サイバー攻撃者はIAMユーザーに対するアクセスキーを不正利用して、攻撃を行っている可能性もあるからです。

まずAWSマネジメントコンソールでIAMユーザーの一覧を見ることができますので、その画面からIAMユーザーの使用履歴を確認します。具体的には、前述のCost Explorerのグラフ表示でつかんだ、大量のEC2インスタンスが起動された日から使われ始めたIAMユーザーを探し出します。こうして探し出したIAMユーザーは、サイバー攻撃者に乗っ取られた可能性が高いからです。

一覧に複数のIAMユーザーがあったと仮定して、探し出す流れを具体的に説明します。まず使用履歴がないIAMユーザーを調査対象から除外します。「大量のEC2インスタンスが起動された日以前に使われたが、それ以降は使われていない」といったIAMユーザーも調査対象外になります。

「大量のEC2インスタンスが起動された日に、AWSマネジメントコンソールにログインしたものの、アクセスキーは作成していない」という履歴があるIAMユーザーについては「誰がどのような目的でログインしたのか」を確認します。

もし「運用担当ベンダーが担当するシステムの作業目的でログインした」といったことが分かれば、今後のシステム運用で必要なIAMユーザーだと分かります。こうしたIAMユーザーについてはパスワードを変更したりMFAが設定されていなければ設定したりして、不正アクセス対策を講じましょう。

サイバー攻撃者に乗っ取られた可能性が高いIAMユーザーは、大量のEC2インスタンスが起動された日に、アクセスキーが使われた形跡があるものです。「開発や運用の担当者は誰も利用した覚えがない」のにもかかわらず、使われた形跡があれば、悪用されている可能性が高いと判断できます。

この場合、アクセスキーを無効化しましょう。また、AWSマネジメントコンソールへのアクセスが有効になっている場合には念のため、コンソールにログインするためのパスワードを変更したり、MFAを設定したりしておきます。

もし大量のIAMユーザーがあって、その多くが「大量のEC2インスタンスが起動された日」にアクセスキーが使われた形跡がある場合、その1つ1つで、アクセスキーを無効化していきます。これらのうち、AWSマネジメントコンソールへのアクセスが有効になっている場合は、パスワードの変更とMFAの設定を行っていきます。

普段からのログ保管と事象発生後の分析が大切。

こうした不正アクセスの対策を講じた後、今回発生した事象がどのようにして起きたのかを確認・調査する必要があります。そのためにも、普段からログを適切に保管しておくこと、事象発生後に、きちんとログを分析できるようにしておくことが大切です。ログの保管については本連載の第1回、分析方法に関しては本連載の第2回を、それぞれ振り返るとよいでしょう。

本連載の第2回で詳しく解説しているので本記事では触れませんが、原因調査などをする際には、「AWS CloudTrail」を使ったログの確認も非常に重要となります。このサービスには、AWSアカウントのユーザーのアクティビティ（行動履歴）やログが記録されています。そのため、タイミングは状況次第ではありますが、インシデントに関する被害状況の把握や影響の特定には必ずCloudTrailを使って、ログを解析することが大切です。

関連記事：「ログがない！？」、インシデント対応を混乱させかねないAWS活用の落とし穴ログはどう分析する？ 知らないと混乱するAWSのインシデント対応

今回の乗っ取りが発生した原因は、IAMユーザーで作成し、システムに埋め込んでいたアクセスキーの漏洩でした。そこでEC2インスタンスで動作するアプリケーションからAWSリソースにアクセスする必要がある場合、そもそもアクセスキーを使わない方法を採用しましょう。

具体的には、アクセスキーを作成することなく必要な権限を付与できる「IAMロール」を作成し、EC2インスタンスに割り当てるようにしましょう。IAMロールを使えば、アクセスキーは不要なので漏洩のリスクもなくせます。リスクをなくすノウハウの1つとして押さえておきましょう。