fbpx

Aqua CSPで出来ること – ファイアウォール

AquaSecurity

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

# Aqua CSPで出来ること - ファイアウォール

AQUA社のAqua Container Security Platform(以下Aqua CSP)は、コンテナとクラウドネイティブアプリケーションへのフルライフサイクルなセキュリティを提供します。
今回はAqua CSPの機能の1つ、ファイアウォールについて説明します。

Aqua CSPのファイアウォール

Aqua CSPのファイアウォールは、Aqua CSPが特定のコンテナファイアウォールポリシーを適用できるコンテナの論理グループです。ファイアウォールサービスに適用されるポリシーには、デフォルトコンテナファイアウォールポリシー、および1つ以上のカスタムコンテナファイアウォールポリシーを含めることが出来ます。多くの場合はデフォルトファイアウォールで、コンテナ同士の通を信可能に出来ます。また、Aqua CSPのサービスネットワークによって、実行中コンテナ間通信の可視化を行うことが出来ます。

Aqua CSPサービスネットワーク

ファイアウォールの必要性

コンテナでサービスを行う例として、以下の組み合わせを考えます。

  • HTTPD
  • アプリケーション
  • DB(MySQL/Postgresql/memcache/Redis)
  • Persistent Volume(以下PV)

この組み合わせの場合、以下のような構成図になります。

コンテナ構成図

この場合、Aqua CSP ファイアウォールでは、以下のように通信を許可します(上記青線部分になります)。

  • HTTPDの通信
    • root以外のユーザ権限でサービス起動する推奨構成の場合は、HTTPDは1024以上のポート番号を使用する必要があります。
    • 外部からの通信はホストに対してポートフォワードすることで行います。そのため、ホストもしくはLBでIP接続制限を行います。
  • アプリケーション の通信
    • 外部からの接続はHTTPDを経由して受信するため、HTTPDからの接続のみ許可すべきです。
    • 外部からアプリケーションへの接続は行わず、プロキシ(HTTPDなど)を経由することをお勧めします。
    • アプリケーションから外部への接続を行うのは、アプリケーションが使用する通信のみに限定することをお勧めします。
  • DBの通信
    • アプリケーションからDBへの接続のみを許可します。接続ポートはDBによって異なります。
    • UNIX Socketによる接続の場合は、アプリケーション/DBが同じPVにsocketファイルを配置する必要があります。この場合、接続ポートの許可は必要ありません。
    • DBから別コンテナへの通信は、別DBとレプリカやクラスタを組む場合のみです。DBからDB以外への通信は許可しません。

Aqua CSP のサービスとファイアウォールの関係

Aqua CSPの「サービス」は、コンテナファイアウォールのポリシーを適用できるコンテナの論理グループです。
ファイアウォールによるフィルタリングは、コンテナファイアウォールポリシー、メンバーシップルール、コンテナファイアウォールポリシーによって決定されます。
Aqua CSPのサービスは、以下のコンポーネントで構成されます。
ファイアウォールによるフィルタリングは、コンテナファイアウォールポリシー、メンバーシップルール、コンテナファイアウォールポリシーによって決定されます。によって決定されます。

  • 制御モード
    Aqua CSPがコンテナファイアウォールのポリシー違反をどのように処理するかを決定します。ポリシー違反時の処理は、コンテナホスト上などに配置されるエンフォーサーが制御します。

    • Enforce(制御)
      実行時に、エンフォーサーはコンテナに適用されるコンテナファイアウォールポリシーを適用し、制御します。
    • Audit Only(監査のみ)
      実行時に、エンフォーサーはコンテナファイアウォールポリシーを適用しませんが、監査ログにイベントを記録します。
  • メンバーンバーシップルール
    • スコープ
      サービスに所属するコンテナを定義します。これは、論理演算子で結合された、1つ以上のコンテナ関連の属性からなる表現です。
    • ルール優先度
      指定されたコンテナがどのサービスに属しているかを判断するために使用されます。0から100までの値を指定でき、100が優先度一番高いものになります。
    • コンテナファイアウォールポリシー
    • サービス内のすべてのコンテナに適用される0個以上のファイアウォールポリシーです。
    • デフォルトコンテナファイアウォールポリシーやカスタムコンテナファイアウォールポリシーの0個以上の組み合わせになります。
  • コンテナファイアウォールポリシー
    • ポリシーが適用されるべきコンテナイメージを定義します。これは、論理演算子で結合された、1つ以上のコンテナ関連の属性からなる表現です。

コンテナファイアウォールポリシー

Aqua CSPは、コンテナファイアウォールポリシーを「サービス(Services)」に登録されたコンテナへ適用します。
デフォルトコンテナファイアウォールポリシーは、すべてのコンテナに適用されます。このデフォルトコンテナファイアウォールポリシーには、独自のルールを追加・変更することが出来ます。多くの場合、予め定義されたファイアウォールポリシーの組み合わせで必要なコンテナファイアウォールを管理することが出来ます。
また、独自にカスタムファイアウォールポリシーを定義することが出来ます。特定のサービスに対してネットワークのルールを追加出来ます。カスタムファイアウォールポリシー単位で、違うルールを定義出来ます。

レイヤ7サービスメッシュとの互換性

Aqua CSPは、Istio/EnvoyおよびConduit/LinkerDプロキシのどちらのサービスメッシュ環境にも展開出来ます。このセキュリティソリューションはサービスメッシュ環境に対して透過的に適用出来ます。コンテナファイアウォールのルールは、EnvoyまたはLinkerDポリシーと並行して適用することが出来ます。

runC環境のためのファイアウォールポリシー

コンテナファイアウォールポリシーは、runCコンテナランタイム環境(CRI-Oとcontainerdをサポート)をサポートします。

Aqua Enforcerでコンテナファイアウォールを保護する

各コンテナホストにAqua Enforcerを展開するとき、コンテナファイアウォールの有効・無効を選択出来ます。コンテナホスト上で実行されているコンテナに対してコンテナファイアウォールポリシーを適用するには、コンテナファイアウォールを有効にする必要があります。

デフォルトコンテナファイアウォールポリシー

デフォルトコンテナファイアウォールポリシーは、Aqua CSPで事前定義されています。これは、デフォルトで各サービスに含まれ、サービスのメンバーでないすべてのコンテナにも適用されます。デフォルトコンテナファイアウォールポリシーは、サービスから削除することも可能です。
デフォルトコンテナファイアウォールポリシーはすべてのIPアドレスおよびポートに関してインバウンド・アウトバウンドの通信を許可します。このルールに対して、追加・変更を行えます。

カスタムファイアウォールポリシーを追加する

追加のコンテナーファイアウォールポリシーを追加して、サービスに適用出来ます。新しいポリシーを追加するには、ポリシーを作成し規則を追加します。サービスページのポリシーセクションで「Add」を押すと、以下の画面が表示されます。「Save Changes」ボタンを押せば新しいコンテナファイアウォールポリシーを追加出来ます。

container firewallポリシーの追加

コンテナファイアウォールポリシーの追加には、以下の項目が必要です。

  • ポリシー名(必須)
  • ポリシーの説明

また1つのポリシーに、以下のアウトバウンド・インバウンドのネットワークポリシーを複数設定可能です。

  • アウトバウンド・インバウンドポート(複数設定、ポート範囲指定可能)
  • 送信先もしくは送信元のIPアドレス/CIDR
  • 上記条件の許可・拒否

アウトバウンドルールでは、クラウドメタデータサービスへのアクセスを許可・拒否するかを選択出来ます。クラウドメタデータサービスは、コンテナがAWS、Azure、GCPで動作している場合に付加されます。

container-firewall-out

サービスにコンテナファイアウォールポリシーを追加

サービスにコンテナファイアウォールポリシーを追加するには、サービスページのコンテナファイアウォールセクションでファイアウォールポリシーを選択し、「Add」を押して以下の設定画面を表示させます。この設定画面で、ルールを追加・削除することが出来ます。また、ルールの優先順位(100～0で、数字の大きい方優先)もこの画面で設定出来ます。

add-firewall-policy

トラフィック監視から、コンテナファイアウォールポリシーを作成。

サービスへの実際のネットワークトラフィックに基づいて、コンテナファイアウォールポリシーを作成出来ます。サービスのネットワークマップビューを開き、一定期間のネットワークトラフィックを記録します。Aqua CSPは、記録された実際のトラフィックから得られた有効なファイアウォール規則のリストを作成することが出来ます。これらの規則を新しいコンテナファイアウォールポリシーとして保存し、変更することが出来ます。 不要なトラフィックはブロックしたほうが良いでしょう。

traffic-to-firewall rule

ネットワークマップ上のブロックされた接続はすべて赤い線で表示されます。

network-map

コンテナ/サービス/ファイアウォールポリシーの関連付け

Aqua CSPのサービスは、Aqua Enforcerがインストール・実行されているホスト上で動作するコンテナを含むことがあります。どの時点でも、コンテナはサービスなしに属することも、1つのサービスに属することも出来ます。

サービスのメンバーシップを評価するために、Aquaは各コンテナの属性(例えばKubernetes名前空間やAquaラベル)を、すべてのサービス定義の範囲で定義されたものと比較します。

  • コンテナ属性がどのサービスのスコープとも一致しない場合、Aquaはデフォルトコンテナファイアウォールポリシーをコンテナに適用します
  • コンテナ属性が1つのサービスのスコープに一致する場合、Aqua CSPはそのサービスのコンテナファイアウォールポリシーをコンテナに適用します。
  • コンテナ属性が複数のサービスのスコープに一致する場合、Aqua CSPは最も高いルール優先順位を持つサービスをそのコンテナに適用します。

コンテナ複数のサービスのメンバーシップに対して品質を提供し、そのサービスが同じルール優先順位を持つ場合、その割当結果は不確定です。ベストプラクティスとして、すべてのサービスに異なるルール優先度が設定されていることを確認してください。
Aqua CSPは、以下のような評価の結果を変える可能性のあるイベント発生時に、サービスメンバーシップを再評価します。

  • コンテナの作成
  • サービスの追加または削除
  • サービス定義の変更(スコープ、ルール優先度など)

AquaCSP-Scope説明図

上の図で、スコープ・ルール優先度、コンテナファイアウォールポリシーについて説明します。スコープとしてScope1~4、ルールとしてA、B、Cを用意します。ルールの優先度は、rule Aが一番高く、rule Cが一番低いものとします。

  • Scope
    • Scope1
      rule Aが適用されます。
    • Scope2
      rule B、rule Cが適用されます。
    • Scope3
      rule Dが適用されます。
    • Scope4
      すべてのコンテナファイアウォールポリシーを削除
  • Container
    • Scope1のみ(Container 1)
      ruleAが適用されます。
    • Scope2のみ(Container2)
      ruleB→ruleCの順にルールが適用されます。
    • Scope3のみ(Container3)
      rule Dが適用されます。
    • Scope4のみ(Container4)
      どのルールも適用されません(どのコンテナとも通信できません)。
    • どのスコープにも含まれない(Container5)
      デフォルトコンテナファイアウォールポリシーが適用されます。
    • Scope1+Scope3、もしくはScope1+Scope3+Scope4(Container6)
      ruleA→ruleDの順にルールが適用されます。
    • Scope1+Scope2+Scope3(Container7)
      ruleA→ruleB→ruleC→ruleDの順にルールが適用されます。
    • Scope1+Scope2
      ruleA→ruleB→ruleCの順にルールが適用されます。
    • Scope2+Scope3
      ruleB→ruleC→ruleDの順にルールが適用されます。
    • Scorp1+Scorp4, Scope2+Scorp4, Scorp3+Scorp4
      それぞれ、ruleA、ruleB→ruleC、ruleCのルールが適用されます。

まとめ

Aqua CSPではコンテナ外からの通信、コンテナ内の通信に関して細かい制御を行うことが可能です。不要なトラフィックを排除することで、アタックによる影響や、意図しない不具合を防ぐことが可能です。
コンテナ構成図

最初に提示した上記のコンテナ構成例では、それぞれのコンテナへのファイアウォールポリシーを変える必要があります。

  • コンテナサービスへのファイアウォールポリシー
    • コンテナサービス内へのプライベートポート(49152–65535)のアウトバウンド通信を許可する。
    • 上記以外のインバウンド・アウトバウンド通信を拒否する。
    • すべてのコンテナの最後のルールとして、このファイアウォールポリシーを設定する。
  • HTTPD
    • 全IPアドレス(0.0.0.0/0)からListenポートへの通信を許可する。
    • 全IPアドレスへのプライベートポートでの通信を許可する。
  • アプリケーション
    • HTTPDからのListenポートへの通信を許可する。
    • DBのListenポートへの接続を許可する(UNIXソケットを使用する場合は許可しない)。
  • DB
    • アプリケーションからのListenポートへの接続を許可する(UNIXソケットを使用する場合は許可しない)。
    • DB間のレプリケーション・クラスタ用ポートへのインバウンド・アウトバウンド接続を許可する。

セキュリティ管理に課題を抱えている、対応法に困っている場合、是非Aqua CSPの導入をご検討ください。

新規CTA