この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、re:Invent楽しんでますか？(挨拶
今回は下記セッションのレポートです。
Deploying egress traffic controls in production environments
Private workloads that require access to resources outside of the VPC should be well monitored and managed. There are solutions that can make this easier, but selecting one requires evaluation of your security, reliability, and cost requirements. In this session, learn how Robinhood evaluated, selected, and implemented AWS Network Firewall to shape network traffic, block threats, and detect anomalous activity on workloads that process sensitive financial data. Robinhood engineers share how they selected a deployment model and executed a global network change that brought their traffic fully in line with firewall endpoints.
本番環境でのイーグレストラフィック制御の導入
VPC 外のリソースへのアクセスを必要とするプライベート ワークロードは、十分に監視および管理する必要があります。 これを簡単にするソリューションはありますが、いずれかを選択するには、セキュリティ、信頼性、およびコストの要件を評価する必要があります。 このセッションでは、Robinhood がどのように AWS Network Firewall を評価、選択、実装して、ネットワーク トラフィックを調整し、脅威をブロックし、機密の財務データを処理するワークロードで異常なアクティビティを検出したかを学びます。 Robinhood のエンジニアが、導入モデルをどのように選択し、トラフィックをファイアウォール エンドポイントと完全に一致させるグローバル ネットワークの変更を実行したかを共有します。
Graham Zulauf, Principal Solutions Architect, AWS Houston Hopkins, Sr Staff Security Engineer, Robinhood Kevin Park, Software Engineer, Security, Robinhood
動画
レポート
アジェンダから。なぜegress(アウトバウンド)コントロールが必要なのかについて説明します。また、AWS Network Firewallの簡単な説明をします。途中でヒューストン氏に交代し、RobinHoodでNetwork Firewallを採用するまでの道のりについて話す。本番環境への採用をどのような段階で進めたかに注目してほしい。そしてKevin氏が具体的な実装について説明する。
なぜegressコントロールが必要なのでしょうか？
最近でたLog4jのエクスプロイトの例。軽減するのは困難だが攻撃された後はペイロードをダウンロードしてそのコードを実行するために戻ってくる必要がある。egressコントロールはこの種の攻撃を軽減し防御できる。また、多くのC2はegress通信に依存しているため、その軽減と防御にも役に立つ。Cisco Talosの最近のレポートによるとランサムウェア攻撃の66%がC2、特にCobalt Strikeを利用していた。egressコントロールは攻撃から保護するための重要な方法である。
- Zero-days: Log4j
- C2 frameworks: Cobalt Strike
- Ransomware: Data exfiltration/double extortion
AWS Network Firewallとは何か？
簡単にマネージドでデプロイでき、VPCを保護できるサービス。設定は簡単、数クリックするだけ。オープンソースのアクセスコントロールのルールをインポートしたりできる。ポリシーVPCとすべてのアカウントに適用できる。
クラウドに最適化されていてスケーラビリティが提供される。数十万のコネクションを利用でき自動でHAされ、ユーザーによるサイズ変更やパッチ適用などは必要ない。柔軟なルールエンジンで多くの一般的な方法と互換性がある。
どのように利用するか？AWSマネジメントコンソールでVPCの画面にアクセスする。新しいファイアウォールを作成し、ルールとポリシーを作成し、エンドポイントを展開する。AWS Firewall Managerと連携すれば更にAWS Organizationsと連携してAWSアカウント全体に展開もできる。
Network Firewallのいくつかの細かい機能を見ていく。
- ドメインフィルタリング
- Suricata互換のルールセット
- IDS/IPS
- などなど
可視性の機能もある。CloudWatchやKinesisに繋げてすべてのログを見ることができる。可視化・レポーティング・脅威ハンティングなどに活用できる。
ユースケースはどのようなものがあるか。あとでRobinHoodのメンバーが深く掘り下げるが、East-Westの保護もある。つまりVPC-VPC間の保護。
続いてRobinHoodのセキュリティチームのヒューストン氏から、ここ1年弱のAWS Network Firewallの取り組みについて話す。
RobinHoodではegressコントロールをして可視化・管理する方法を探していた。これまではegressコントロールは各アプリケーションと密接に結合されていた。NACLを書いていた。しかし集計ビューが必要だった。ガードレールのアプローチが好き。業務を止めることなく実施したい。
求めていたegressコントロールの要件。まず第一はNorth-Southの保護。柔軟なルールエンジンが必要だった。TLS、SNIを検査するためにDeep packet inspectionが必要だった。実際にドメインについて確認する必要があった。そして管理が簡単であり、スケーラビリティが確保できるもの。IaCもしたいのでTerraformで利用できること。
Network Firewallを導入したほうがいいかについては触れないが、各ネットワークの制御方法について整理した表がある。一番右側はVPCであり、これは素晴らしいものでこれからも利用していくが、集約したビューが必要だった。他にも管理のコストなどが課題になっていた。
egressコントロールを適用するための我々のアプローチ。最初は非常に単純で、実際に展開してみること。次にブロックと追跡をしてみる。緊急事態では誰がブロックを承認するか、その承認チェーンを確認する。これは必要になる前に早めにやったほうがいい。そして最後に前向きなセキュリティモデルにしていくこと。悪い過去のことを変えるのは素晴らしい。
ここでセキュリティソフトウェアエンジニアのKevin氏に交代。
AWS Network Firewallの導入と実装のプロセスについて説明していく。最高なことは、ゼロダウンタイムで本番導入できたこと。
本題の前に設定したゴールについて。まずegress通信をキャプチャして監視すること。ここでのegress通信は、RobinHoodのネットワークからインターネットに出ていく全てのネットワークトラフィックを意味する。どのIPとポートに到達するかだけでなく、有益な情報を保持し今後の調査に役立てたい。
次に悪い通信はすぐにブロックできるようにする。重要なことはFirewallがエンジニアが操作しなければいけない新しい要素になってしまうこと。各アプリケーションを構築、テスト、展開するエンジニアに対してFirewallを完全に透過的にする必要がある。しかし必ずしもingressの通信は確認する必要がない。つまりすべての侵入を検知することはゴールではない。
より詳細な導入パターンについて見ていきます。検討した1つ目のパターンは集中型モデル。
ここにはAWS Transit Gatewayと右側にSecurity VPCがある。このVPCは1つのNetwork Firewallとインターネットに接続するためのNAT Gatewayがある。複数のVPCがTransit Gatewayに接続してこれを介してインターネットに出る。
この構成の利点は単一のファイアウォールであること。管理が簡単でルールも1箇所。小規模な環境では特に良さそう。
しかし信頼性が必要なケースではマイナスにもなる。Transit Gatewayを維持する必要があり、設定を間違えると単一障害点ともなる。
2つ目のパターンは分散モデル。
これはすでに存在する環境にそれぞれファイアウォールを展開する。この例では2つのKubernetes環境で、2つのAZにまたがるVPCがある。合計で4つのNAT Gatewayが存在し、それに対応してNetwork Firewallも存在する。
多数のNetwork Firewallがあるため、ルールを段階的にロールアウトしていける。開発環境でルールをテストし、本番環境に展開したり、最初に小さいクラスタでテストすることも可能。
欠点はn個のファイアウォールを管理する必要があること。
RobinHoodでは分散モデルを採用することにした。その理由は主にスケーリングのニーズ。NAT Gatewayの最大スループットは45GbpsでNetwork Firewallの最大スループットは100Gbpsだが、RobinHoodではこの45Gbpsの上限に達した。もちろんNATを分割することもできるが、引き続きボトルネックを残したくはない。そのため、分散モデルを採用した。しかし繰り返しになるが、小規模な環境では中央集中型のほうが適していると考えている。
導入方法に入る前に既存の環境がどうなっていたかの話。バージニアリージョンでパブリックとプライベートのサブネットが存在していた。各AZごとにNATが存在していてプライベートのサブネットがNATを向いていた。
Network Firewallを導入する際には新しいサブネットを作成してここにエンドポイントを設置した。新しいサブネットを入れるのはすべての通信をキャプチャするため。NAT Gatewayに到達するためには、必ずNetwork Firewallを通過する必要がある。AZ間のPod間通信でもNetwork Firewallを通過する必要があるが、Network Firewallの帯域は余裕があるので大丈夫。もしNAT Gatewayの外側にNetwork Firewallを設置したら、送信元のKubernetesのIPなどがマスクされ、詳細な調査ができなくなってしまうので内側に設置した。
ただしルートテーブルの設定で気をつける必要があるのは、ネットワークの対称性を維持する必要があること。非対称になるとどこかでパケットをドロップする。以下の図は実際にそうなってしまって失敗した例。パブリックサブネットではVPC内のCIDRをNetwork Firewallに向くように設定し、プライベートサブネットでは内部向けはすべてlocalにしていた。
どう修正するか？より詳細なCIDRを利用してルートを書くこと(ロンゲストマッチ)。
アーキテクチャの定義ができたので展開していく。間違いのないように繰り返し展開するためにRobinHoodではすでにTerraformが大きく利用されていたので、このモジュールを作成した。シンプルに1つだけフラグを提供した。これはNetwork FirewallのON/OFFで、小さなテスト環境で利用したくない場合などの選択肢とした。
しかし先程話したように、すでにたくさんの本番環境があるため、これにどのように導入していくかが課題である。どうするか？事前に必要な環境を作っていった。ルートテーブルなども複製し、terraform applyで切り替えられるようにした。これで慎重に確認して切り替えができた。
そして同時に、このFirewallのフラグはフェイルセーフのフラグとしても役に立つ。もしFirewallが利用できなくなった場合、このフラグをオフにしてバイパスすることができる。これがコマンド一発で安全に実現できる。利用していないルートも、Terraformで自動的にメンテナンスされるようにした。
続いてモニタリング。CloudWatchのログから2つの重要なアラートを生成している。1つはトラフィックが極端に少ない場合は設定を誤っているか、意図的にFirewallを外しているためアラートする。もう1つはNetwork Firewallがパケットをドロップしている場合。つまり帯域の上限に引っかかっているか、ルールに引っかかりドロップしているか。これはすぐに調査したいので携帯を鳴らしている。
次にロギングと可視性。Network Firewallのログは、VPCフローログで取得できるIPやポートなどの情報もあるが、独自のものとしてはTLSなどの情報で、フィンガープリント、SNIドメイン、TLSバージョンなどが確認できる。
再びヒューストン氏に戻りダッシュボードの説明。
これは初期のダッシュボードであり、外部向けの通信や内部向けの通信の割合やドメインなどを確認した。ドメインは許可リストを作成することに活用した。これはポジティブなセキュリティにつながる。
そして調査を深堀りすることができる。時々ヒットするランダムなドメインは何か？ポートはなにか？スクレイパーなのか？悪意はあるのか？
いくつかの発見があった。VPCエンドポイントを使ってパブリック通信を減らした。また、内部サービスのルーティングでインターネットを通っているところも発見して内部を通すようにした。
そして上限と下限を知り、常にアクセスしているドメインを把握した。たまに出てくる知らないドメインは調べる必要がある。
再びケビン氏。
面白かったことは、今回の導入でコストが増加すると思っていたら、コスト削減の機会が増えたこと。SNIドメインの可視化によりいろんな気づきを得て削減につながった。特に巨大なS3へのNAT経由の通信をVPCエンドポイントに置き換えることができたのはよかった。もちろん他のサービスも含む。
まとめとして将来の話。もしシンプルなルートテーブルを維持したいならこの方法を採用してほしい。NAT GatewayとNLBのサブネットを更に分離するといい。NLBとの通信はNetwork Firewallを経由しないことができ、ルートテーブルの柔軟性を高める。ログのノイズも減りegressコントロールに集中できる。また、内部間の通信も直接になるのでNetwork Firewallのコストが最適化される。
感想
AWS Network Firewallをどのようなモチベーションで採用し、検討した結果やハマった内容なども共有された大変参考になる内容でした。
Network Firewallの導入がコスト削減につながったというのも面白い話ですね。是非参考にしてください。
4
