MetaDefender ICAP 5.13.0：インフラを追加せずに、より多くのトラフィックを処理可能

ネットワークエッジにおけるファイルセキュリティは、処理能力が追いついていなければ機能しません。セキュアWebゲートウェイが（ダウンロード、アップロード、Webコンテンツなどを通じて）通過するすべてのファイルを検査する場合、そのセキュリティ層は「透過的」である必要があります。つまり、ユーザーには目に見えず、負荷がかかっても安定した動作を維持し、コンプライアンス審査の際に問題となるような事態を引き起こさないものでなければなりません。

これらは、トラフィックの増加、アクセスポリシーの厳格化、監査範囲の拡大に伴い、管理がますます困難になる運用上の課題です。MetaDefender ICAP Server .13.0 は、そのうちの3つに直接対応しています。

チームICAP 計測を行う際、しばしば頭を悩ませる問題があります。それは、セキュアゲートウェイを経由してウェブを閲覧するたった1人のユーザーが、数十、あるいは数百ICAP 立て続けに生成してしまう可能性があるということです。画像、スクリプト、ドキュメント、ダウンロードのそれぞれが、サーバーに対して同時に送信される個別のファイル検査リクエストとなるのです。

トラフィックが中程度であれば、ほとんどの導入環境では問題なく処理されます。同時実行数が増加すると、ボトルネックは通常、データベースへの結果の書き込み、ログ出力のフラッシュ、スレッド状態の管理といった周辺処理に見られます。

同時アクセス数が多くなると、同じパイプライン内でリクエストの処理と結果の記録を行うことがボトルネックとなり、需要が最も高まるまさにそのタイミングでスループットが制限されてしまう。

MetaDefender ICAP Server .13.0 では、これらの処理が分離されました。スキャンスレッドは、スキャンが完了した瞬間にデータベースへの書き込みとログ出力を専用のバックグラウンドプロセスに引き継ぎ、直ちに次のリクエストを処理するようになりました。その結果、ハードウェアの追加やスレッドプールの拡大を行うことなく、トラフィックの増加に応じて検査スループットをよりスムーズに拡張できるようになりました。

特に該当する対象：セキュアWebゲートウェイを運用しているチーム。これらの環境では、1つのユーザーセッションから数十件ものファイル検査リクエストが同時に発生する可能性があります。トラフィック量が多いほど、この変更の影響は大きくなります。

SAMLのシングルログアウトは、SSO実装において不備が生じやすい側面の一つです。通常、チームは信頼関係の確立、アサーションの検証、セッションの作成といった認証設定に注力します。一方、ログアウトの側面は軽視されがちであり、表面的には部分的なログアウトが正常に機能しているように見えることがあります。

この違いを理解しておく価値があります。ユーザーが、ローカルセッションのみをクリアするアプリケーションからサインアウトした場合でも、IdPのセッションは有効なまま残ります。そのセッションは、ユーザーに気付かれることなく再利用される可能性があります。ログインページに戻ったユーザーは、認証情報を再入力したりMFAを行ったりすることなく、自動的に再認証されてしまう可能性があります。ワークステーションが共有されている環境や、特権アカウントが使用されている環境では、これはユーザーの意図を超えて存続するアクセス経路となります。

MetaDefender ICAP Server .13.0 では、SAML シングルログアウト（SLO）が完全にサポートされました。サインアウト時、MetaDefender ICAP Server アイデンティティプロバイダーに直接ログアウトリクエストServer 、ソース側でセッションを終了させ、アクセスを再開する前に新たな認証を要求します。また、ログアウト後のリダイレクト動作も設定可能です。

アクセス制御監査やゼロトラストポリシーの対象となるチームにとって、これにより、セッションの終了処理が完全なSAML実装で求められる要件に準拠することになります。