はじめに
AWSにおけるアウトバウンド通信の制御について、選択肢がどのようなものがあるのかを語っていきます。
想定するケース
以下のようなケースを想定します。
IntenetGatewayがVPCにアタッチされており、NATGW経由でインスタンスがインターネット方向にアウトバウンド通信をおこなうケースです。
想定するリスク
このケースに置いて想定するリスクは以下です。
・インスタンスがマルウェア等に感染し、攻撃の踏み台にされる。
・利用者が不特定多数の接続先に接続可能であり、情報漏洩やウイルス感染のリスクがある
想定される対策
SG、NACLによる制御
これは言わずもがなの対策ですが、SG、NACLにより、接続可能なIPアドレスを明示的に許可、拒否すべきものをNACLにて遮断しておく対策です。とはいえ、IPアドレスベースで制御不可能なケースが多く、根本的な対策となるかは状況次第です。
ホスト型セキュリティ対策ソフトの導入
こちらは説明するまでもないかもしれませんが、接続元となるホスト側にセキュリティ対策ソフトを導入し、アウトバウンド通信の検査を行うパターンです。割りとオーソドックスな方法かもしれませんね。
プロキシの導入
プロキシサーバを中継として導入し、接続先を管理する方法です。FQDNベースで接続先をコントロールできますし、接続先もログとして残すことができるので、アウトバウンド通信を厳格に管理したい場合によいでしょう。とはいえ、EC2が増えるので、管理コストや拡張性が課題となります。
DNSFirewallの導入
Route53DNSFirewallを利用するケースです。
通常VPC上で名前解決を実施する場合、Route53Resolverに対して問い合わせが行われますが、そこで、特定のドメインについて許可、拒否などのルールを設定することで名前解決による通信制御を行う事が可能です。また、既知のマルウェアやC&Cサーバの通信先のマネージドルールも用意されており、該当の名前解決をブロックすることが可能です。ただし、IPアドレスが明示的に指定されている場合は、本対策では防ぎようがありません。
NetworkFirewallの導入
NetworkFirewallを導入するケースです。IPS、IDS等の機能やシグニチャベースの評価、IPアドレスの制御、送信先ドメインの制御など多数の機能を持ち合わせています。とはいえ他の対策に比べて費用は高くつきます。
比較
選択肢を比較してみる以下の通りになります。
# | 導入サービス | メリット | デメリット |
---|---|---|---|
1 | SG、NACL | 追加のコストがかからない、IPアドレスベースであれば、確実に制御可能 | IPアドレスで制御できない場合意味をなさない |
2 | ホスト型セキュリティ対策ソフトの導入 | 比較的簡単に導入可能、マルウェア対策にもなる | 追加のコストがかかる、製品によって制御できる範囲がバラバラ、管理が手間 |
3 | プロキシの導入 | URLベースでの制御が可能 | OSの管理コストがかかる、拡張性や可用性を担保する必要がある、インスタンスタイプによってはコストが高い |
4 | DNS Firewall | 比較的簡単に導入可能、マルウェア対策にもなる、URLベースでの制御が可能、コストが安い | IPアドレスには対応していない |
5 | Network Firewall | IDS機能や、IPアドレス、ドメインでの制御も可能で高機能 | コストが比較的高い |
まとめ、結局どれを選べばよいか
まず考えるべきは、どこまでのリスクが発生しうるかかと思います。
例えば、マルウェアに感染するようなケースが想定されるのかというところです。
送信元がコンテナであれば、ReadOnlyとすることで、コンテナの書き込みを拒否することで対策が可能かもしれません。また、EC2であれば、マルウェアが混入しないような使い方(特定の宛先に送信しかしていないなど)をしているケースもあるかもしれません。厳格な権限制御をOS側で導入することも手段の一つです。
このケースにおいては、SGや、NACLなどの標準的な対策でも良いのではないかと思います。
必要に応じてホスト型のセキュリティ対策ソフトと組み合わせるのがよいでしょう。
その他、FQDNのみで制御可能なのであれば、安価なDNSFirewallがおすすめです。
このサービスの利用料は非常に安く、かつマネージドルールにおいて、既知のマルウェア等の通信先をブロックする機能も有しているため、利用を検討するのが良いでしょう。
NetoworkFirewallは非常に高機能ですが、同時に効果なので、IDS等の導入が本当に必要なのか、リスクと費用を考慮し、リスクが許容できないものであれ場導入すべきです。
様々な対策がAWS上では可能ですが、かならず、コストがつきまといます。過剰な対策となっていないかを考慮し、必要な対策を見極めましょう。