AWSファイアウォール入門:種類別の使い分けガイド

防御は一般的に低レイヤーから積み上げていくべきものなので、最下層のインフラから順に上位レイヤーへと見ていきます。

Security Groups

Security Groupsは、主にEC2インスタンスに紐付くElastic Network Interfaceを保護しますが、VPC内のRDSやLambdaなど他のサービスにも適用できます。たとえば不正なSSH接続をブロックする用途に使え、送信元・宛先のポートとIP範囲に基づいてアクセスを制御します。インスタンスを作成する際は必ずSecurity Groupsを定義し、必要最小限のアクセスのみを許可するようにしてください。

Network ACLs

Network ACLはサブネットを保護します。たとえば、バックエンドサーバー以外からデータベースへ不正に接続されることを防ぐ用途に使えます。Security Groupsと同様、送信元・宛先のポートとIP範囲に基づいてアクセスを制御します。システムを機能ごとにサブネットに分割するとき、つまり階層を定義するタイミングでNACLを設定すべきです。サブネットを適切に切っておけば、NACLによってアーキテクチャ上の役割に応じたサブシステム間のアクセスを許可できます。

Kubernetes Network Policies

Kubernetes Network PoliciesはElastic Kubernetes Service上のアプリケーションを保護します。Security GroupsやNACLと同様、送信元・宛先のポートとIP範囲に基づいてアクセスを制御しますが、加えてKubernetesのラベルも利用できるため、より細かい単位で機能ベースのアクセス制御が可能です。ごく単純な構成を除き、Kubernetesサービスを構築する際は必ずNetwork Policyを定義してください。

Network Firewalls

Network Firewallsは組織のネットワーク全体を保護します。たとえばデータを外部に持ち出すトロイの木馬型ボットなどへの対策に有効です。標準的なダウンロード可能なルールセットに基づいてアクセスを制御します。Security GroupsやNACLと同様、これらのルールセットには送信元・宛先のポートとIP範囲によるシグネチャが含まれます。さらにディープパケットインスペクションにも対応しており、ドメイン、URL、プロトコルに基づくブロックも可能です(Network Firewallの手前でTLSが終端されている場合に限ります)。組織全体で一貫した侵入検知・防御ポリシーが必要になったタイミングで、Network Firewallを導入してください。

AWS Shield Standard

AWS Shield StandardはWebアプリやAPIをDDoS攻撃から保護します。呼び出し頻度や送信元といったHTTP(S)トラフィックのパターンに基づいてアクセスを制御します。ビジネスに関わる公開Webアプリには必ずAWS Shield Standardを適用しましょう(無料で、一部のリソースではデフォルトで有効になっています)。

AWS Shield Advanced

AWS Shield AdvancedはStandardと同じ機能に加え、より手厚いモニタリング、攻撃時のコスト補償、そして何より重要な点として、熟練した運用チームによる対応が含まれます。ビジネスクリティカルなWebアプリでは、StandardとAdvancedのコスト差を踏まえてAdvancedの導入を検討してください。

Web Application Firewall

Web Application Firewall(WAF)は、クロスサイトスクリプティング、SQLインジェクション、安全でない直接オブジェクト参照など、OWASPリストに挙げられた脆弱性からWebアプリを保護します。HTTP(S)リクエストのヘッダーやボディ内のパターンによって定義されたシグネチャに基づき、アクセスを検知してブロックします。既知の脆弱性を修正している間の保護策として、自社で管理できない脆弱なアプリケーションを使っている場合、あるいは脆弱性は少ないと考えていても念のため追加の保護を入れておきたい場合に、WAFの導入を検討してください。

Security Groupsで保護されたインスタンス、NACLで保護されたサブネット、Network Firewallで保護されたマルチネットワーク構成。AWS ShieldはDDoSから、WAFはエントリポイントを保護します。

アプリケーションの成長に合わせて異なるファイアウォールをどう導入していくのか、ユースケースをストーリー仕立てでご紹介します。

Patはスタートアップ向けのWebアプリケーション開発を始めたばかり。少々保守的な彼女は、シンプルなPoC(概念実証)として単一のEC2インスタンスを使うことにしました。インスタンスレベルのファイアウォールとしてSecurity Groupを設定し、HTTP/Sリクエストを受け付けるためにポート80と443のみを開放、SSHでの管理用にオフィスのIP範囲からのポート22アクセスのみを許可します。これでインスタンスは、ポート80・443以外への攻撃者のアクセスと、許可されていないIPアドレスからのSSHアクセスから守られました。

この初期段階でも、PoCはすでに多くの攻撃から守られています。とはいえ、ネットワークやアプリケーションが複雑化し、ビジネス上の重要性が増していくにつれ、より多くの防御策が必要になります。

シンプルなPoCから堅牢なn層アプリケーションへと進化させるため、彼女はデータベースを設置し、フロントエンドとバックエンドのサーバーを分離します。各層には別々のサブネットを割り当て、サブネットの入口を守るファイアウォールとしてNetwork Access Control Lists(NACL)を設定。HTTP/Sリクエストはフロントエンドサブネットへ、フロントエンドはバックエンドへ、バックエンドはデータベースへというアクセスのみを許可し、それ以外は遮断します。

スケーラビリティには限界があり、たとえアプリケーションが負荷下で稼働を続けられたとしても、DDoS攻撃を受ければコストが膨らみます。そこで彼女は無料のAWS Shield Standardを導入します。これだけでもDDoS対策としては十分です。さらに先になって、アプリケーションが大きくスケールし主要な収益源となった頃には、AWS Shield Advancedのコストを払う価値も出てくるでしょう。Advancedの最大の魅力は、AWSの熟練した運用チームを利用できる点です。セキュリティ全般に言えることですが、脅威となるのは新たな攻撃手法を編み出す賢い人間であり、それに対抗するには常に賢い人間が適切な防御を講じ続ける必要があるのです。

Patはオーケストレーションと管理を容易にするため、アプリケーションをElastic Kubernetes Serviceに移行します。ここではKubernetes Network Policyによって、どのKubernetesサービスが他のサービスと通信できるかを制限し、サブネットでは実現できないより細かい粒度の機能ベースのアクセス制御を実現します。

アプリケーションのペネトレーションテストを行うと、安全でない直接オブジェクト参照、クロスサイトスクリプティング、SQLインジェクションなど、OWASPリストにあるさまざまな脆弱性が見つかります。そこでPatと開発チームはAWS Web Application Firewallを導入し、同時にアプリ開発チーム内で必要な修正と長期的なセキュリティ対応を優先課題として取り組みます。

そしてついに大きな日が訪れます。Exit!スタートアップは大企業に買収されました。アプリケーションはより大きなアプリケーションportfolioの一部となり、ネットワークも複数のVPCや、異なる組織単位が管理するオンプレミスネットワークを含む複雑なインフラの一部に組み込まれます。これらすべてを保護するため、企業は組織横断で一貫したネットワークポリシーを定めています。AWS Network Firewallが追加され、ポート、IPアドレス、ドメイン、URL、プロトコルで定義された標準的な防御ルールセットによってアクセスを制限します。これによりSecurity GroupsやNetwork ACLと同じ攻撃から守れるだけでなく、ネットワーク内でコードを実行してデータを破壊・流出させるトロイの木馬型ボットや人間のハッカーによる侵入も検知・防止できます。

大規模組織では、リソースとポリシーを一元的に管理する仕組みが欠かせません。システムの強さは最も弱い箇所で決まるからです。組織全体で一貫した保護を維持するため、Network FirewallやWAFなどを一元管理するAWS Firewall Managerが導入されます。

以上で、AWSの数あるファイアウォールを整理できたのではないでしょうか。ご質問があればコメント欄でお気軽にどうぞ。

— —

貴重なコメントをくれた同僚の Dr. Artem Shchodro に感謝します。