Wallarmオンプレミスソリューション概要¶
Wallarmは、パートナー企業、大規模エンタープライズ、ならびにセキュリティインフラストラクチャを完全に制御する必要があるあらゆる組織向けに、オンプレミスソリューションを提供します。このデプロイメントモデルにより、WallarmのFiltering NodeとWallarm Cloudコンポーネントの両方をお客様の環境内に完全にホストできます。
本書では、ソリューションのアーキテクチャ、コアコンポーネント、デプロイメントモデルの概要を説明し、Wallarmオンプレミスが組織に適合するかどうかを評価する際の参考にしていただけます。
ソリューションコンポーネントの概要¶
Wallarmのアーキテクチャは、2つの主要コンポーネントを中心に構築されています。
-
受信リクエストを検査し、不正なアクティビティを検出するためにトラフィックフローへ統合されるFiltering Node。
-
Filtering Nodeからのデータを処理し、Wallarm Console UIをホストするWallarm Cloud。Wallarm Console UIは、設定やセキュリティイベントの調査のためのコントロールプレーンです。
オンプレミスソリューションでは、両コンポーネントともにお客様が完全にホストおよび管理します。
オンプレミスソリューションは、インラインおよびアウトオブバンドの両方のNodeデプロイ手法をサポートします。どちらの場合も、Filtering Nodeはトラフィックをインターセプトまたはミラーリングし、メタデータを解析と連携のためにローカルのWallarm Cloudコンポーネントへ送信します。
オンプレミスデプロイメントにおけるFiltering Node¶
Filtering Nodeの標準的なセルフホスト型デプロイメントオプションは、オンプレミス構成で全てサポートされています。通常のデプロイ手順に従ってください。
Filtering NodeはWallarm Cloudとは別のインスタンスにデプロイする必要があります。
オンプレミスデプロイメントにおけるWallarm Cloud¶
Wallarm Cloudコンポーネントは、内部インフラストラクチャ内にデプロイされ、インターネットおよび内部ネットワークの他の部分からファイアウォールで分離された、分離ネットワークセグメント上のセキュアな別個のサーバーに配置する必要があります。
専用のスタンドアロンな仮想または物理サーバー上で動作するよう設計されており、シングルノードおよびクラスターアーキテクチャの両方をサポートします。
デプロイメントレイヤー¶
Wallarm Cloudシステムは、Wallarmのソフトウェアインストーラーでデプロイおよび管理される以下のレイヤーで構成されます。
-
Kubernetesクラスター
-
Kubernetes向け分散ブロックストレージ
-
データベース
-
MinIO
-
構成およびデプロイメントツール
-
約20個のWallarm内部マイクロサービス
デプロイメントアーキテクチャ¶
Wallarm Cloudインスタンスのデプロイと管理方法として、主に以下のアーキテクチャがあります。
-
スタンドアロン - シングルノードのデプロイメントです。テストや評価にのみ適しており、冗長性やフォールトトレランスはありません。
-
クラスター - 本番用途向けに設計された複数ノードのKubernetesデプロイメントです。クラスターには少なくとも3ノードが必要で、1ノードの障害には耐えられますが、複数ノードがダウンするとクォーラムが崩れます。
Wallarm Cloudノードは、クラスターノード間でデータや構成を同期するためにネットワークを使用するため、同一ネットワーク/サブネット内に配置することを推奨します。
クラスター構成では、アクティブなWallarm Cloudノード間のトラフィックを分散するためにネットワークロードバランサーが必要です。サポートされるオプションは次の2つです。
-
Cloudインスタンスのデプロイの一部として提供される組み込みソフトウェアロードバランサー
これを使用するには、同一プライベートサブネット内にVirtual IP（VIP）を割り当てる必要があります。ローカルネットワークは、既存サーバーに対して追加のIPアドレス（ARPおよびRARPプロトコルレベル）を割り当てることをサポートしている必要があります。
-
お客様管理の外部ロードバランサー
単体のバランサーは、TCPおよびUDPレイヤーのロードバランシングとTCPヘルスチェック（Wallarm Cloudノードの状態確認）をサポートする必要があります。
管理ワークステーション¶
Wallarm Cloudコンポーネントのインストールと管理には、専用の管理ワークステーションが必要です。
このマシンはクラスター自体の一部ではなく、インストール、構成、更新、ディザスタリカバリなどの管理タスクのみに使用します。要件はこちらを満たす必要があります。
管理ワークステーションでは、Wallarmのオンプレミス管理ツールwctlを実行し、デプロイおよびメンテナンス時に使用する必要な設定ファイルを保管します。
レイヤーの管理責任¶
次の図は、Wallarm Cloudシステムのどのレイヤーがwctlで管理され、どのレイヤーが顧客による管理を要するかを示しています。
高可用性と自動フェイルオーバー¶
Wallarm Cloudインスタンスをクラスターモードでデプロイした場合、次の挙動が期待できます。
-
単一のWallarm Cloudノードが障害となった場合、システムが障害を検知して復旧するまでの間、最大5分程度のサービス低下が発生する可能性があります（必ず発生するわけではありません）。
-
ノード障害の後、Longhornデータストレージサブシステムはおよそ10分待機してから、生存ノード間でデータのリバランスを開始し、劣化したボリュームを復元します。
-
劣化状態のWallarm Cloudクラスターに新しいノードを追加した後、クラスター内のデータとワークロードのリバランスに30～40分かかる場合があります。この期間中、短時間（1～2分）のサービス低下が発生する可能性があります。
ステージング環境¶
本番適用前に新しいソフトウェアリリースや大きな構成変更を検証するため、Wallarm Cloudコンポーネントのステージングインスタンスを別途用意することを推奨します。
理想的には、ステージング環境は本番環境（ネットワーク、サーバー、ソフトウェア）を反映し、メンテナンスやテスト時の混同を避けるために明確な命名で分離ネットワーク内にデプロイされているべきです。
Filtering NodeとWallarm Cloudの依存関係¶
WallarmのFiltering Nodeコンポーネントの機能は、Wallarm Cloud Is Downで説明されているとおり、Wallarm Cloudコンポーネントの可用性と機能に依存します。
Wallarm Cloudコンポーネントのデプロイを計画する際は、上記の依存関係を考慮し、冗長性や高可用性、監視など、Wallarm API Security全体の正しい動作に影響する側面を適切なレベルで設計することが重要です。
Wallarm API¶
Wallarm Cloudインスタンスは、APIエンドポイント群を公開しており、これを使用して脆弱性、攻撃、インシデントなどの管理をプログラムから実行できます。
オンプレミスのWallarm Cloudデプロイメントでは、次のURLでSwaggerUIインターフェイスを提供します。
ライセンス¶
各オンプレミスのWallarm Cloudインスタンスには、Wallarmから提供されるライセンスキーが必要です。キーには次が定義されます。
-
ライセンスの有効期間
-
有効な製品機能
-
月間APIトラフィック量（RPM）
ライセンスの有効期限が切れる、または月間APIトラフィックが許容RPMを超えた場合：
-
Filtering Nodeは、ライセンス期限前にNodeへアップロードされたルールを使用してトラフィックのフィルタリングを継続します
-
Filtering NodeはAPI攻撃およびセッションをWallarm Cloudへアップロードしなくなるため、新しいイベントはConsole UIに表示されません
-
システムはAPIセッションの分析と新しいAPI Abuse Preventionルールの生成を停止します
Wallarmライセンスの有効期限が近い場合、または現在のRPMがライセンスで許容されたボリュームに近づいている場合、システムは自動的にメール通知を送信します。
オンプレミスソリューションへのアクセスについては、Wallarmの営業チームまでお問い合わせください。
制限事項¶
現在、オンプレミスのWallarmソリューションでは次の機能はサポートされていません。
-
AASM (API Attack Surface Management)機能
この機能はオンプレミス版では利用できませんが、上記の手順に従い、Wallarmのクラウドサービスでアカウントを作成してAASMを有効化できます。
データ保持と自動削除¶
既定で、Wallarm Cloudは公開されているデータ保持ポリシーに従います。
ディスクストレージ容量は通常あらかじめ設定され、容易に変更できないため、潜在的なディスクの逼迫を検知した場合に、データベースから古いユーザーセッション、攻撃、hits、インシデントのデータを自動的に削除するプロセスがあります。
この場合、システム管理者にはメール通知が送信され、追加のディスクストレージ容量の増設を計画して実行するよう促されます。