はじめに

自分がこれまで対応したプロジェクトについて問題発生から解決まで行ったものについて紹介します。

記載した内容以外にもプロジェクトとしては課題はいくつもありますが、

今回はテーマ／事象を絞ってまとめています。

プロジェクト

社内セキュリティーをEDR(Endpoint Detection and Response)に刷新するプロジェクトに参加した時の

話になります。

採用したソフトは「CrowdStrike」で決まった状態でプロジェクトが

立ち上がったのでこのソフトを親会社(本店、全国にある支店など)や関連子会社)適用するにあたり、

導入方法の検討に参加しました。

問題発生！！

ソフトの動作検証を行うにあたり検証機へソフトをインストールした

ところ、「ログインできない」というトラブルが発生。

発生原因がつかめないまま、ベンダーを巻き込んでの調査を実施。

専門のエンジニアを社内に呼んで調査や情報取得を実施していただいたが解決できなかった。

事象の切り分けを行う中で、親会社のPCでは発生するが子会社のPCでは

発生しないことが判明し、PCの設定やキッティング内容の調査を実施。

導入しているソフトに違いがあり調査を行った結果、「DeviceLock」という

ソフトがインストールされている環境へのCrowdStrikeのインストールを行うと事象が

発生するということが判明した。

なぜ！！

「CrowdStrike」を採用した目的の一つに情報漏洩防止があった。

そのため、ソフトの機能として外部デバイスの接続制限機能を有していた。

プロジェクトが立ち上がる前にその制御を行っていたソフトが「DeviceLock」であった。

OSの外にある外部デバイス向けの制御機能を持つソフトが同時に

インストールされた状態になると機能の競合が発生し、

結果としてOSに対して想定外の影響を及ぼしていた。

図．機能の競合

対策

事象が発生したら回復手段がないためこと、全国の拠点に対して

配布する予定(約7000台想定)のため、絶対に失敗できない状況にあることから、

インストール用バッチの設計については関係者と何度もレビューを実施。

バッチの中で、DevicelLockに対するインストール有無からインストール前後の

確認について最大限配慮を行い、実装を行った。

設計のポイント：

〇「DevicelLock」に対して無効化を行う際に処理前後の確認は重点的に処理を実装

※「DevicelLock」についてはコマンドによるアンインストールができないため、

　機能の無効化にて対応した

〇少しでも想定どおりにいかない場合はエラーと判断し、処理を中断。

〇実行結果は配布用端末に集約するのため、各判定箇所の判断結果をログに出力

※バッチ内の処理にて対応できないPCは後日、担当者による手動対応を

　実施することにした。

　　図．インストールバッチフロー（概要）

展開作業結果

実際の展開は土日作業でおおよそ二か月かかったが、インストール失敗によるトラブルを

0件に抑えることができました。

他にも多くの課題があり苦労しましたがなんとか無事にプロジェクトを完遂できました。