Top Trends in Cybersecurity for 2024 | 
会社のインターネット対応アプリケーションのセキュリティ管理者として、一般的にはCVE、アラート、アップデート、パッチの一定のサイクルを管理する必要がある。 新しいアプリケーション、機能、APIエンドポイントなど、アプリケーションスタックに継続的な変更を加えることは控えめで、To-Doリストは圧倒される可能性がある。 あなたの日に追加の仕事を加えることは理想から遠い。 WAFが助けてくれる。 ほとんどのWAFでは、パッチを展開する準備ができていない場合やパッチが存在しない場合に脆弱性から保護するための仮想パッチとして機能するルールを展開できる。 これらのパッチは、ヘッダ、クエリ、クッキーなどのリクエスト要素ごとに別々のルールになる可能性がある。 しかし、ゼロデイ脆弱性から保護するためのツールとして始まったものは、複雑さとさらなる管理負担を引き起こす可能性がある。 すべてのアプリケーションを追跡することに加えて、WAFのさまざまな要素を管理する必要がある。
時間を節約し、変更を迅速に展開
WAFソリューションには、Security Application Manager (SAM)とSecurity Rules Manager (SRM)という2つの新機能を導入する。 Security Application Managerは、アプリケーションスタック全体にわたるこの複雑なセキュリティ更新ストリームの管理を容易にするポリシーの包括である。 この機能は、異なるソフトウェアスタックやプラットフォームで複数のアプリケーションを実行しており、それぞれに異なるアップデート、パッチ、脆弱性、開発チームがある場合に最も有用である。
SAMを使用すると、1つのルールで動作を複製できる 時間を節約し、より効率的で、より高速である。 今では、それほど多くのルールを管理する必要はない。
SAMはSRMと連携し、悪意のあるトラフィックや不要なトラフィックからアプリケーションを保護する。
以前のバージョンでは、サイトを保護するには、Media Control Centerの異なるセクションで変更が必要だった。 WAFルールを設定するには、Rules EngineでWAFインスタンスのルールを追加し、WAF Instance Managerでプロファイルとアクションを設定し、WAF Profile Managerでポリシーを定義する必要があった。 レート制限を設定するには、ホスト名とパスのマッチング、条件、しきい値、および適用のルールを別のセクションで設定する必要があった。
図1:以前のバージョンでは、以下に示すMedia Control CenterルールビルダとMedia Control Centerセキュリティ内のインスタンスを構成する必要があった。
図2：Media Control Centerのセキュリティ
新しいバージョンでは、SRMとSAMがあるMedia Control CenterのSecurityセクションにすべての設定を配置することで、このアプローチを簡素化した。
図3：セキュリティルールマネージャ。
SRMプラットフォームには、アクセスルール、管理ルール、レートルール、カスタムルールのすべての保護ルールが含まれている。
SAMは、特定のアプリケーションをすべて定義し、それらをどのように保護すべきかを定義する。 保護するアプリケーション、使用するSRMルール、およびルールがトリガーされたときに発生するアクションのタイプを定義する。
このモジュール化されたセキュリティソリューションには、
- 変更をより迅速に展開できる。
- 管理はよりモジュール化されており、直感的である。 特定のホスト名とURLパスに適用するルールを指定できる。
- ルールを一度設定して複数のアプリケーションで使用することで、時間を節約できる。
- 保護の柔軟性が高く、カスタムルールを作成して展開できる。
- デュアルWAFモードなど、旧バージョンのメリットをすべて活用できる。
最後に、WAFプラットフォームはスタンドアロンソリューションとなり、他のCDN構成とは独立して動作する。
新しいWAFの動きを見てみよう。
この例では、仮定の会社のための3つのアプリケーションを保護する:ブログ、フォーラム、およびAPI。 次のドメインを使用する。
- blog.example.com
- forums.example.com
- api.example.com
1つのアクセスルール、1つの管理ルール、および1つのレートルールを作成し、すべてのアプリケーションで共有する。 APIアプリケーションでのみ使用される2番目のレートルールを作成する。
最初のステップは、新しいアクセスルールを作成することである。
このアクセスルールの名前を「All Properties ACL」にした。 そして、HEADを使用してリクエストをブロックするために許可されたHTTPメソッドの下でHEADのチェックを外した。
図4:新しいアクセスルールの作成
次に、新しいレートルールを作成する。
このレートルールを「All Properties RL」と名付け、「IP address and user agent」プロパティに適用し、レート制限を1分あたり50リクエストに設定した。
図5：新しいレートルールの作成
次に、APIアプリケーションにのみ使用される別のレートルールを作成する。
このレートルールを「API RL」と名付け、「IPアドレスとユーザーエージェント」プロパティに適用し、レート制限を1分あたり10リクエストに設定した。
図6：新しいレートルールの作成
最後に、新しい管理ルールを作成する。
このルールを「すべてのプロパティ管理」と名付け、[設定]タブのすべてのデフォルトを受け入れた。 [ポリシー]タブでは、最新のEdgioルールセットを自動的にオプトインして、最新バージョンを自動的に使用するように選択した。
図7:新しい管理規則の作成
SRMでルールを作成したので、SAMで3つの新しいアプリケーションを作成する。 ブログ、フォーラム、APIアプリケーション用にそれぞれ1つのアプリケーション。
新しいアプリケーションごとに、特定のホスト名( blog.example.comなど)を入力し、URL Path(s)をデフォルトのままにして、すべてのパスで一致するようにする。
各SAMのRulesセクションでは、SRMで作成したAll Properties ACLアクセスルール、All Properties Managed管理ルール、およびAll Properties RLレートルールを再使用する。 ルールがトリガーされたときに実行するアクションとしてブロックリクエストを選択する。
図8:[Apply All Properties] ACL Access Rule.
API RLレートルールは、APIアプリケーションにのみ適用する。 これを行うには、APIアプリケーションを編集して、この追加ルールを含める。 ここでは順序が重要なので、API RLルールを上部にドラッグ&ドロップする。
図9: APIレート制限ルールの適用
最後に、SAM構成の最終ビューを表示し、各アプリケーションのアクセスルール、レートルール、および管理ルールを表示する。
図10：Security Application Managerの設定の概要
Security Rules Managerでルールを作成し、Security Application Managerアプリケーションに適用する方法を理解した。 SAMを使用してアプリケーションを保護するために利用できる多くのオプションと機能を検討することをお勧めする。
WAFを含む当社のセキュリティソリューションの詳細については、今日接続しよう。
