外部から接続されるサーバーを運用するときは、そこから届く報告の扱いにも注意が必要です。サーバーやソフトウェアの不具合、設定の変化、侵害の可能性などによって、報告が実際の状態を十分に表さない場合があります。

BASTIONでは、DMZのAgentから届く情報の検証と、許可する操作の範囲を限定する設計を重視しています。この記事では、その考え方と運用上の確認点を紹介します。

1. 報告を検証の対象として扱う #

Agentから報告が届いたということだけで、その内容が十分に確かめられたとは限りません。運用環境に応じた確認を行い、判断に利用できる情報かどうかを扱う必要があります。

BASTIONでは、報告の受け取りと防御判断の役割を整理し、検証の結果を踏まえて対応する考え方を採っています。

2. 操作の範囲を限定する #

Agentが利用できる機能や操作対象は、導入環境の要件に合わせて限定します。必要な役割と権限を整理し、既存の運用に与える影響を確認します。

権限を制限することは対策の一つです。それだけで、侵害や誤った操作による影響をすべて防げると考えるものではありません。

3. 情報が得られない状態を区別する #

報告が届かない、内容が古い、確認に必要な情報が足りないといった状態は、問題がないことの証明にはなりません。観測できているかどうかを、判断と合わせて確認します。

不足している情報を把握できるようにし、運用者による確認や対処につなげることを重視します。

4. 正規利用への影響も確認する #

防御のための対応でも、対象を誤れば正規の利用者や業務へ影響します。対応の対象範囲、記録の残し方、運用者が確認・対処する手順を合わせて整理することが重要です。

自動化する範囲と、必要な確認の方法は、導入先の条件に応じて検討します。

5. 運用の記録と防御効果を分ける #

BASTIONでは自社環境の観測と対応履歴を確認しながら改良を進めています。ただし、異常や誤遮断が観測されなかったことだけでは、侵害された場合の防御効果まで確認できたとはいえません。

利用条件に応じた検証を行い、確認できた範囲と未確認の範囲を区別します。

6. 導入時の確認と公開範囲 #

導入にあたっては、取得できる情報、接続条件、許可する操作、運用者の確認手順を整理します。構成や評価の範囲は、対象環境と要件に合わせて個別にお見積もりします。

この記事は設計の考え方を説明するもので、検証アルゴリズム、制御条件、内部の接続構成、顧客の運用情報は掲載していません。現在の機能と検証状況はBASTIONのサービス紹介ページをご覧ください。