エム・クレストの副社長兼エンジニアである小澤一裕です。情報システム部門に配属された新入社員やリスキリングで改めてICTに取り組もうという方々に向けて、知っていると便利なICTに関する情報をお届けしようと考えました。第4回のテーマは「セキュリティソリューションの連携」です。

　セキュリティソフトとセキュリティ機器を組み合わせると、問題のある端末を自動的に遮断するといった連携ができます。しかし、場合によっては多数の端末が遮断され、その結果、問い合わせ窓口がパンクするといった事態が発生し、本当の脅威への対応ができないといった本末転倒なことも起こりえます。今回は、そのようなことを防ぐにはどうしたらいいかという相談に基づいた話になります。

■問い合わせが殺到して本末転倒な事態に

　某法人様では、Aソフトというセキュリティソフトと、Bスイッチというネットワークスイッチを導入していました。

　Bスイッチは、Aソフトと自動連携ができることが特徴でした。具体的には、Aソフトがセキュリティポリシーに反している端末を検知すると、Bスイッチの集中管理ソフトにその端末情報が通知され、集中管理ソフトから該当するBスイッチで当該端末を速やかに遮断することができます。
 
　このような連携を自動で行うこと自体は、セキュリティソリューションとしては問題ありません。目的を果たしているといえます。

　しかし、突然、端末が遮断された利用者は、当然、サポート窓口の担当者に問い合わせます。ウイルス感染のような危機的な事態ならともかく、OSのセキュリティパッチを充当していないといった理由だと、多くの利用者が該当することがあります。差し当たっての危機ではないにも関わらず、問い合わせが殺到し、担当者の業務はパンクします。

　こんなときに攻撃者の侵入といった正真正銘の危機が起こったら、対応できる人がおらず、大変なセキュリティインシデントにつながるかもしれません。本末転倒です。

　そこで、「セキュリティパッチの未充当のような軽微なインシデントであれば、サポート窓口に問い合わせずに利用者が自ら対応し、その後、自動的に端末がネットワークに復帰できるようにしたい」という相談をいただきました。

■解決すべき課題は二つ

　サポート窓口の具体的な負担は何だったのでしょうか。一つは、利用者からの問い合わせそのものです。問い合わせがあったとき、担当者は、管理画面からログなどを確認しなければなりません。単純に手間と時間がかかります。

　もう一つは、遮断された端末の復帰です。遮断された端末を再度ネットワークに参加させるには、遮断された理由になった問題の解決を待って、その後、Bスイッチを手で操作する必要がありました。これも手間と時間がかかります。1件ずつなら大した時間はかからないかもしれませんが、大量に発生するとお手上げです。

　そこで、利用者にまず遮断された理由に気づいてもらい、自分でできることはやってもらった上で、あとは自動的に遮断を解除して端末を復帰する手立てを考えればいいのですが、それには以下の二つ課題がありました。

1.遮断された利用者に遮断理由を知らせたいが、端末がネットワークから遮断されているので、端末には通知できない。
→某法人様のネットワーク外から知らせる方法を考える必要がある。

2.遮断解除は管理者しかできない。
→自動的に復帰操作をする仕組みをつくる必要がある。

■AソフトとBスイッチの情報を連携

　AソフトとBスイッチから情報さえ取得できれば何とかなりそうです。調べたところ、Aソフトのログから端末遮断時のタイムスタンプと遮断理由、IPアドレスが、またBスイッチの集中管理ソフトのAPI機能から遮断IDとタイムスタンプ、IPアドレス、Macアドレスがそれぞれ取得できることが判明しました。またBスイッチの集中管理ソフトのAPIを使えば、遮断IDを指定することで該当端末の遮断解除ができることも分かりました。

　ただし、AソフトとBスイッチのタイムスタンプは誤差があるので完全には一致しません。また某法人様ではDHCPでIPアドレスを割り当てていたので、IPアドレスでは遮断された端末が一致しない可能性もありました。

　とはいえ、タイムスタンプは完全に一致しなくても、せいぜい数秒以内という近い値になるはずなので、許容範囲を設けて範囲内なら同じ時刻とみなすことにしました。

　さらに、短い時間内にIPアドレスが別の端末に振り直されることはほぼあり得ませんので、タイムスタンプが許容範囲内でIPアドレスが一致する場合は同じ端末と判断することにしました。こうした点を踏まえ、情報連携ツールを当社が開発し、それを活用することを決めました。
 
■Google Workspaceを活用して遮断端末リストを公開

　さて、どうやって端末の解除とその理由を利用者に知らせるかですが、それには某法人様が利用していた「Google Workspace」を使うことにしました。スプレッドシートは、APIを使って表を作成できるので、まずは遮断された端末のリストをスプレッドシートに書き出す仕組みをつくりました。

　さらにGoogle Workspaceでは、Google ScriptでデータベースのようなWebページをつくることができるので、その仕組みを使って書き出したスプレッドシートをWebページとして公開しました。もちろん某法人様のアカウントでだけ閲覧可能な状態にしました。

　端末を遮断された利用者は、自分のスマートフォンなどで公開ページを見にいきます。すると自分の端末が遮断された理由が分かるので、それに対処した後、そのページにある遮断解除ボタンをクリックして解除申請します。同時にスプレッドシート上のステータスが解除中から解除申請中に変わります。

　その後、連携ツールがスプレッドシートを定期的に確認し、解除申請中のレコードがあれば、Bスイッチの集中管理ソフトのAPIを使って遮断解除を実行し、スプレッドシートから当該レコードを削除します。

　利用者が何も対処せずに解除申請を行ったとしても、結局Aソフトが検知して再び解除されるだけなので問題はありません。以上で問題は解決しました。
 
　セキュリティソリューションが危険を排除するために端末を自動的に遮断するといった動きをするのは確かに正しいと思いました。しかし、実運用で面倒になることを理解してくれる製品は実はあまりないのではないと、この案件で感じた次第です。