AWS開発もアウトバウンドのエンドポイントセキュリティを徹底するべき
AWS開発でプライベートサブネット配下にウェブサーバーやDBなどを配置して、ELBをパブリックサブネットに配置することは定番だと思います。そして、ClientVPN、サイト間VPN、Direct Connectなどによるプライベートサブネットへの接続だけを許可するようにセキュリティグループやネットワークACLの設定を行っても、内部潜伏マルウェアのインジェクションなど、問題が起きたと想定します。内部潜伏のマルウェアからC&Cサーバーなどへ、内部から外部へのアウトバウンドリクエストの遮断を行うことで攻撃側のシナリオを潰す必要があります。CISベンチマークに記載されていませんが、重要です。
AWSのセキュリティグループのアウトバウンドは以下の方法によるフィルタリングしか出来ない。
- （パブリック/プライベート）IPアドレス指定のホワイトリスト
- セキュリティグループ指定のホワイトリスト
- S3のプレフィックスリストid指定のホアウィトリスト
- プロトコルのタイプの指定（httpsやICMPなど）
ネットワークACLのアウトバウンドは、以下の方法によるフィルタリングしか出来ない。
- （パブリック/プライベート）IPアドレス指定のホワイトリスト方式
- （パブリック/プライベート）IPアドレス指定のブラックリスト方式
- プロトコルのタイプの指定（httpsやICMPなど）
つまり、上記の双方の機能を使っても内部から外部へのアウトバウンドのリクエストの「独自ドメイン」をフィルタリングすることは出来ない。
AWSのNATインスタンスを使っても、上記のセキュリティグループとネットワークACLを使うことに変わりはなく、状況は変えられません。また、NATゲートウェイはセキュリティグループを利用できず、アウトバウンドのSSL(https)のみを許可しますが、アウトバウンドのSSL(https)について具体的なURLでフィルタリングすることは出来ません。
つまり、このままでは内部潜伏マルウェアからC&Cサーバーなどへの独自ドメインによるリクエスト遮断が出来ません。
iptablesやプロキシサーバーのSquidやAviatrixなどをを使えば独自ドメインもIPアドレスもフィルタリング出来ますが、Linuxサーバーの維持管理が発生します。マネージドなSaasで維持管理が発生しないほうがいい。このあたりはもう少し突き詰めていきます。
