AWS開発もアウトバウンドのエンドポイントセキュリティを徹底するべき

AWS開発でプライベートサブネット配下にウェブサーバーやDBなどを配置して、ELBをパブリックサブネットに配置することは定番だと思います。そして、ClientVPN、サイト間VPN、Direct Connectなどによるプライベートサブネットへの接続だけを許可するようにセキュリティグループやネットワークACLの設定を行っても、内部潜伏マルウェアのインジェクションなど、問題が起きたと想定します。内部潜伏のマルウェアからC&Cサーバーなどへ、内部から外部へのアウトバウンドリクエストの遮断を行うことで攻撃側のシナリオを潰す必要があります。CISベンチマークに記載されていませんが、重要です。

AWSのセキュリティグループのアウトバウンドは以下の方法によるフィルタリングしか出来ない。

  1. (パブリック/プライベート)IPアドレス指定のホワイトリスト
  2. セキュリティグループ指定のホワイトリスト
  3. S3のプレフィックスリストid指定のホアウィトリスト
  4. プロトコルのタイプの指定(httpsやICMPなど)

ネットワークACLのアウトバウンドは、以下の方法によるフィルタリングしか出来ない。

  1. (パブリック/プライベート)IPアドレス指定のホワイトリスト方式
  2. (パブリック/プライベート)IPアドレス指定のブラックリスト方式
  3. プロトコルのタイプの指定(httpsやICMPなど)

つまり、上記の双方の機能を使っても内部から外部へのアウトバウンドのリクエストの「独自ドメイン」をフィルタリングすることは出来ない。

AWSのNATインスタンスを使っても、上記のセキュリティグループとネットワークACLを使うことに変わりはなく、状況は変えられません。また、NATゲートウェイはセキュリティグループを利用できず、アウトバウンドのSSL(https)のみを許可しますが、アウトバウンドのSSL(https)について具体的なURLでフィルタリングすることは出来ません。

つまり、このままでは内部潜伏マルウェアからC&Cサーバーなどへの独自ドメインによるリクエスト遮断が出来ません。

iptablesやプロキシサーバーのSquidやAviatrixなどをを使えば独自ドメインもIPアドレスもフィルタリング出来ますが、Linuxサーバーの維持管理が発生します。マネージドなSaasで維持管理が発生しないほうがいい。このあたりはもう少し突き詰めていきます。

コメントをいただくことがしばしばあるため、コメント機能を有効化しました。わからないこと、間違っていること、疑問に思うこと、何でも質問受け付けます。間違っていることは適宜修正させていただきます。お気軽にコメントください。また、正しい回答を出来る方は、正しい回答でぶった斬ってコメントいただけますと幸いです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください