この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさま Xin chao.
Amazon Inspector を活用していますか？
組織内のセキュリティガイドライン、あるいはそれに類するものの中に、以下のようなチェック項目を見かけることがあります。
「新たなシステムを稼働させる際には、事前にセキュリティ診断を行い、外部 (＝インターネット) から必要最小限の通信のみが許可されていることを確認すること」
インターネットに公開されているサーバーであれば、そのパブリック IP アドレスに対してポートスキャンを行うことにより、不要なポートがオープンになっていないことを確認することができます。
では、もし、対象となるサーバーが、インターネット経由では接続できないサーバーだったとしたら、どうしたらよいでしょうか？
ガイドラインの対象外にしてほしい... というのが本音かもしれませんが、何らかの方法で、どうしても必要最小限の通信のみが許可されていること (＝つまり今回の場合、インターネットから接続できないこと) を確認しなければならないとしたら？
やりたいこと
今回の目的は、「インターネットから接続できないように構成されている EC2 が、確かにインターネットから接続できない状態であることを確認したエビデンスを残す」 こととします。 また、それほど大規模な環境ではないため、そのための準備や設定変更なども、極力控えたいとします。
ここでは、そもそも論 (つまり、インターネットから接続できないサーバーなのに実施する必要があるのか？ とか AWS の設定を見ればすぐ分かるのでは？ など) は置いておき、あくまで目視以外の方法で何らかのエビデンスを残す方法を試してみます。
診断方法の検討
弊社のブログに、ポートスキャンのみならず、脆弱性診断の分類に関する投稿がありました。
これによれば、 以下のような方法が考えられます。
外部ネットワーク型
インターネットからの診断となるため、対象のサーバーをインターネットから接続できる状態にしなければなりません。 しかし、診断を行うための準備が、セキュリティリスクを高めてしまうことになりかねず、この診断方法は選択しにくいと思います。
内部ネットワーク型
VPC 内部からの診断となるため、対象のサーバーをインターネットから接続できる状態にする必要はありませんが、あくまで VPC 内部に構築した診断元からの診断となるため、それをもってインターネットから接続できないことが確認できるか難しいところです。 さらに、診断を行うための環境を VPC 内部に構築する工数も必要になります。
ホスト型
Amazon Inspector がこれに該当します。 そういえば先日、Amazon Inspector に以下のようなアップデートがありました。
Amazon Inspectorに新しいルールパッケージが追加されてEC2インスタンスに対するネットワークアクセス制御を評価できるようになりました。
端的に表現すると、「実質的に」ポートスキャンのようなことができます。 評価対象のEC2インスタンスに対して、インターネットからアクセス可能なポートが存在しないか評価することができます。
「実質的に」と書きましたが、実際はポートスキャンを行っているわけではなく、Security Groupなどの各種ネットワークリソースの設定を分析しています。
もしかしたら、このアップデートを使えば、インターネットから接続できないことを確認できるのではないか？ と思い試してみました。
試してみた
プライベートサブネット上の EC2 へのネットワーク到達可能性の評価
プライベート (プロテクテッド) サブネット上に配置した EC2 に対し、Amazon Inspector によるネットワーク到達可能性の評価を行います。 EC2 からは NAT ゲートウェイを介してインターネットにアクセスできますが、インターネット側からは EC2 にアクセスできない構成です。 当然ですが、期待値はインターネットから到達可能な通信がないことです。
EC2 には以下のようなセキュリティグループを適用しています。 意図的に TCP 22 (SSH) を全開放 (＝接続元 0.0.0.0/0 に対して許可) にしています。 あらゆる接続元から少なくとも TCP 22 (SSH) は開かれているという状態です。 TCP 3389 (RDP) はメンテナンス接続用で、ソースに特定のパブリック IP アドレスが設定されていますが、プライベート (プロテクテッド) サブネット上の EC2 に対しては無意味なので、評価結果には出てこないはずです。 ネットワーク ACL では、インバウンド・アウトバンド共にすべての通信を許可しています。
Amazon Inspector で、ネットワーク到達可能性のルールパッケージのみの以下のような評価テンプレートを作成し、評価を行いました。
評価テンプレートの作成をはじめとする Amazon Inspector の設定方法については、以下のブログをご参照ください。
評価結果
今回は、エビデンスとしてダウンロードした評価レポートで確認してみます。 評価レポートは、[評価の実行] ページよりダウンロード可能です。
以下の通り、VPC Peering 経由での TCP 22 (SSH) および TCP 80 (HTTP) のネットワーク到達可能性がありと報告されました。 TCP 22 (SSH) が全開放になっているにも関わらず、ネットワーク経路的にインターネットからは接続できないプライベート (プロテクテッド) サブネット上では、インターネット経由でのネットワーク到達可能性はないと評価されています (Amazon Inspector Agent をインストールしない状態で行っているため、Failed が 1 になっています)。
つまり、仮に TCP 22 (SSH) が全開放状態だったとしても、インターネット経由でのネットワーク到達可能性はなしとの評価です。
インターネットからは接続できないというエビデンスが取れたので、これにて終了！ と思いましたが、試しに同じ環境を、パブリックサブネット上に構築したら、ちゃんとインターネットからのネットワーク到達可能性ありと評価されるのか気になったので、そちらも試してみました。
パブリックサブネット上の EC2 へのネットワーク到達可能性の評価
プライベートサブネット上で使用したのと同じ AMI から作成した EC2 インスタンスを、今度はパブリックサブネット上に構築し、同じセキュリティグループを適用したうえで、Amazon Inspector によるネットワーク到達可能性を診断します。 期待値はインターネットから到達可能な通信があることです。
評価結果
プライベート (プロテクテッド) サブネット上の EC2 で報告された VPC Peering 経由でのネットワーク到達可能性に加え、インターネット経由での TCP 22 (SSH) および TCP 3389 (RDP) のネットワーク到達可能性がありと評価されました。 プライベート (プロテクテッド) サブネット上で試した EC2 と全く同じセキュリティグループを適用していますが、パブリックサブネット上では、ネットワーク経路的にインターネットからの接続が可能であるため、インターネット経由でのネットワーク到達可能性がありと評価されています (Amazon Inspector Agent をインストールしない状態で行っているため、やはり Failed が 1 になっています)。
まとめ
Amazon Inspector のネットワーク到達可能性の評価により、プライベートサブネット上の EC2 に対してインターネットから接続できないことを確認できたと言えそうです。 ネットワーク到達可能性は、セキュリティグループの設定だけではなく、VPC や ルートテーブルなどのネットワーク構成も踏まえたうえで検証されるため、今回のようにセキュリティグループが全開放になっていたとしても、プライベート (プロテクテッド) サブネット上の EC2 インスタンスに対しては、インターネットからのネットワーク到達可能性はなしと評価されます。
なお、セキュリティグループについてですが、今回はあえて SSH の全開放など、緩い設定を使用しましたが、最小限の接続許可を与えるのがベストプラクティスとなっていますので、不要なリスクを軽減するためにも、実際の環境構築時は最小限の接続許可になっているか充分ご注意ください。
2
