【AWS Summit Japan 2025 Day1】プロアクティブセキュリティとAWS環境への侵入

記事タイトルとURLをコピーする

AWS Summit レポート: プロアクティブセキュリティとAWS環境への侵入

サーバーワークス・スマートオペレーションズ クラウドセキュリティ部クラウドセキュリティ課の野上です。

先日開催された AWS Summit に参加してきましたので、その中でも特に興味深かったセッションについてご紹介したいと思います。

【デモで実演】侵入経路予測でプロアクティブなセキュリティを!

Day1の昼頃に開始されたこのセッション、事前の触れ込みは下記のようなものでした。

【AWS Summitのセッション情報より抜粋】

「脅威の動向から、実際に起こりうるAWS環境へのサイバーインシデントをデモンストレーション形式で実演します。悪意のある攻撃者が、どのように準備し、最初にシステムに侵入し、内部を探索し、最終的にランサムウェアを実行するまでの一連のステップを詳細にお見せします。また、巧妙化する脅威から自社を守るために、AWS利用者が行うべきセキュリティ対策とリスクマネジメントについて解説します。さらに、トレンドマイクロが提供するAIを用いた侵入経路予測機能が、どのように事前に侵入経路を特定し、実際に侵入される前に proactive(先回りした)な改善を可能にするかを紹介します。」

クラウドセキュリティ課の一員として、最新の脅威や、傾向についてより知見を深めたいと考え、聴講させて頂きましたが、 特に、実際に侵入デモが行われた点が大変興味深く、本記事でもその詳細をご紹介します。

(実際の侵入デモではコマンドの詳細や侵入方法を詳しくご紹介頂いておりましたが、セキュリティの観点から詳細は省かせて頂きます)

想定されるシナリオの構成

今回のデモで想定されたシナリオは、以下の図のような構成でした。

再現した構成図

インターネットからアクセス可能な領域(Public Subnet)にPHPサーバーが稼働するEC2インスタンスがあり、社内ネットワークのような隔離された領域(Private Subnet)に配置された保守用サーバーから、このEC2インスタンスやファイル保存サービス(S3)、データベース(RDS)に接続できる環境です。

実際の環境侵入デモ

デモでは、まず攻撃の初期段階として、外部からシステムに不正な接続を確立することが試みられました。

本デモではリバースシェルによって外部公開サーバーへアクセスし、セッションの確立が行われました。

この時点ですでに深刻なセキュリティ問題ですが、想像以上に簡単かつ短時間で侵入されてしまったことに驚きを隠せませんでした。

次に、この接続を利用してSSH接続による保守用サーバーへの侵入が行われました。ネットワークの状態を確認し、そのまま遠隔操作ができるように侵入するという流れです。

(実際にはパスワードの解読などが必要になるため、デモのようにスムーズにはいかないはずですが、もしパスワードが攻撃者に知られてしまえば、そのシステムはほぼ自由に操られてしまうことを示唆していました。)

SSHによる保守サーバーへの侵入

ここからは、さらに高度な攻撃が続きました。AWSサービスを利用するための認証情報を取得し、それを使ってどのような権限があるかを確認する手順です。 EC2からはサーバーを持っている権限がコマンドで確認できるため、それを悪用される形となります。

特に問題だったのは、保守用サーバーに設定されていた「役割(IAMロール)」が、新たなAWSアカウントの利用者(IAMユーザー)や権限(IAMポリシー)を作成できるという、非常に強力な権限を持っていたことです。デモでは、この強力な役割が悪用され、AWS環境全体が攻撃者の意のままに操作されることになります。

さらに、システムのネットワーク構成情報(VPC ID)が特定され、データベース(RDS)に保存されている機密情報も抜き取られてしまいます。 保守用サーバーからRDSへ接続できるため、権限確認時に発行されたトークンを用いて、データベースを確認、sqldumpを用いて情報を窃取されるというような流れとなります。

また、ファイル保存サービス(S3)に保存されているデータの一覧も取得され、その内容が筒抜けになります。

S3,RDSの情報窃取

そして、攻撃者は自らがAWS環境を自由に操作するための「裏口(悪意のあるIAMユーザーとポリシー)」を作成してしまいます。

最終的には、データベースに保存されていた顧客情報などの機密データが窃取され、S3に保存されていた重要なファイルが暗号化されることで、サイバー攻撃が「成功」するという、最悪のシナリオがデモンストレーションされました。

まとめ

今回のデモケースは、AWSが提供する基本的なセキュリティ機能であるセキュリティグループ(SG)の適切な設定や、各システムに与える「役割(IAMロール)」の権限を最小限に抑える(最小権限の原則)といった対策を徹底することで、ある程度は防げた可能性のある事例だったと強く感じました。

また、セッションでは事前にサイバーリスクを予見し事前対処する、プロアクティブセキュリティの考え方重要だと語られており、 AWS環境を安全に運用する上で、今回デモで示されたようなリスクを事前に把握し、必要なセキュリティ設定を適切に施しておくことの重要性を再認識できる、非常に有意義なセッションでした。