ベンチャー企業でゼロからゼロトラストセキュリティを導入した話

# はじめに

弊社では2022年にゼロからゼロトラストセキュリティを全面的に導入していきました。

ベンチャー/大企業問わず、ここまで対応を進めている企業様があまりないらしく、他社の方からこのあたりの話を聞きたいと言われることが多いので、導入に当たっての話を記事化することにしました。
導入の意思決定から実際の設定作業まで私がメインで行ったので、詳細まで把握しています。

インターネット上でも、ベンダー側からの情報は多くあっても実際に導入をした企業側の話は少ないので、そういった観点でも多少は参考になる部分はあるかと思います。

# ゼロトラストセキュリティとは

そもそもゼロトラストとは、これまでの「境界内部は信頼できる領域で、境界外部は信⽤できない領域である」という考え⽅ではなく、「たとえ境界内部であっても無条件に信⽤せず全てにおいて確認し認証・認可を⾏う」という考え⽅に基づいて社内の情報資産を守る概念です。
([独立行政法人 情報処理推進機構「ゼロトラスト移⾏のすゝめ」参照](https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2022/ngi93u0000002ko3-att/000099778.pdf))

ゼロトラストセキュリティとはこの概念に基づいて、具体的に実装されたセキュリティの枠組みや技術のことを指し、以下のようなサービスの組み合わせでゼロトラストを実現していくかたちになります。
以下の例の他にも多くのゼロトラスト向けサービスがあります。

1. IAM(アイデンティティー&アクセス管理)
1. MDM/MAM(端末管理/アプリケーション管理)
1. DLP(情報漏洩防止)
1. CASB(クラウドアクセス セキュリティブローカー) 
1. EDR(エンドポイント検知&対応)
1. SIEM(セキュリティインシデント管理)
1. SASE(セキュアアクセスサービスエッジ)
1. SWG(セキュアWebゲートウェイ)

非常に厄介なのが、<b>「このサービスを導入すればゼロトラストを実現できる」という画一的な基準が存在せず、会社単位で保護すべき情報資産の対象とセキュリティリスク等を斟酌して対応を進めていく必要がある</b>点ですね。

# なぜゼロトラストセキュリティの導入を決めたのか
弊社では長年、EPP(Endpoint Protection Platform、いわゆるセキュリティソフト)と添付ファイルの暗号化 + イントラネットへの情報の隔離 によってセキュリティ対策を行っていました。
まあ、昔ながらのネットワーク境界防御型のセキュリティ対策ですね。

それでもPマークやISO27001(ISMS)の取得/維持のうえでは問題なかったのですが、以下のような弊社の業務実態を考えると、境界防御により担保される情報がほぼない状態となっていました。

* 基本的に現場業務がGoogle Workspaceなどのクラウドサービス経由で行われている
* PCの社外持ち出しが許容されているうえにリモートワーク率が高い
  (出社率は約20~30%)
* 数年前に社内ファイルサーバーを全廃し、クラウドストレージ(Google Drive)に全面移行していた
* 端末管理が導入されておらず、Windows PC紛失時にリモートロックが不可能な状態であった
  (Mac端末のみ OS Xの機能でリモートロックが可能ではあったが、Macは全端末の30%程度)

シード期の企業ならまだしも、弊社は資金調達を行い、IPOを視野に入れた企業として、セキュリティインシデントの発生リスクを最小化する必要がありました。
その点を斟酌して、他の経営陣にリスク状況を説明しつつ、対策予算を取得し、ゼロトラストセキュリティの導入を決定しました。

そして、弊社はゼロトラストの実現に際して、Microsoft 365をベースとしたソリューションを採用し、導入を進めました。

# なぜMicrosoft 365を選定したか
大前提として、ゼロトラストを実現していくためには、保護対象の情報資産の範囲を設定しつつ、上述のサービス群を導入し、それらを連動させていく必要があります。

ゼロトラストの実現にあたって、弊社で必要と思われる各種サービスに関して、各々見積もりを行ったのですが、これらを個別に導入していくよりも、Microsoft 365をベースとしたソリューションを採用したほうが大幅にコストを抑えられる見積もりになったことがMicrosoft 365を選んだ最大の理由です。

弊社の場合は、Microsoft 365 Business Premiumの導入 + Microsoft Sentinel + Microsoft Defender for Cloud Appsの導入で、弊社の情報資産をほぼカバーできる想定となりました。

元々全従業員にMicrosoft 365 Apps for businessを導入していたため、プランアップ等を含めて従業員1人あたり追加で月額約2,000円程度(当時)の追加費用でゼロトラストセキュリティを導入できるという目算となりました。

これらを他社が展開しているサービスを個別に導入した場合、従業員1人当たり月額8,000円〜10,000円前後(当時)の追加費用がかかるという見積もりになったので、Microsoft 365をベースとしたソリューションを採用することにしました。

また、弊社では「[BOTCHAN](https://botchan.chat/)」というチャットボット型のSaaSサービスがメイン事業となっており、「BOTCHAN」をお客様に提供するにあたって、Azureをメインクラウドインフラとして採用しています。
Azure上のDBに顧客情報が格納されるため、「何も信頼しない」のであればゼロトラストで保護すべき情報資産の範囲として、クラウドインフラも含めるべきと判断しました。

その点を斟酌すると、AzureとIAMが共通化されているOfficeを利用したほうがゼロトラストの実現がしやすかったこともこの決定の背景にはあります。

https://qiita.com/lazy-kz/items/7dc9a61ddfa5b2a81632

# 弊社のゼロトラスト構成
弊社では以下のような構成でゼロトラストセキュリティの導入を進めました。

1. まずMicrosoft Entra IDをID管理の中心において、基本的に業務で利用するサービスはEntra IDを経由したシングルサインオン(SSO)で行うようにしました。
合わせてEntra IDはMFA(多要素認証)をポリシーで必須化しつつ、基本はMicrosoft Authenticatorでの生体認証に寄せました。

1. 会社支給端末にはMDM(Microsoft Intune)とEDR(Microsoft Defender for Endpoint)を全台導入しまし、各種セキュリティポリシー(Bitlocker暗号化、スリープ時間等)の強制適用と監視を行うようにしました。
個人所有モバイルデバイスにはIntuneのみ全台に導入し、EDRの導入は任意としました。

1. GitHubやSalesforceなど、Defender for Cloud Appsに接続できるサービスは接続して、操作されている情報の内容ベースで監視できるようにしました。

1. 前述のとおり、弊社のメインサービスである「BOTCHAN」はAzureインフラですが、弊社の運用サービスには「[AI-SCHOLAR](https://ai-scholar.tech/)」など、一部AWSインフラのサービスも存在するため、AWSインフラのサービスに関しては AWS IAM Identity Centerを使ってSSOに対応し、AWS Security Hubを使って情報を収集しつつ、Defender for Cloud Appsへのデータ連携を行なうようにしました。

1. Azure/AWSともに本番環境はDefender for Cloud(CSPM/CWPP)でセキュリティ監視を行うようにしました。

1. 取得可能なすべてのアクティビティデータをSentinelに連携し、多角的な観点からのセキュリティ監視を行なうようにしました。

この構成を図にすると以下のようになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/980999/e70ec23a-0591-db7d-4b89-1c56e8bef8ec.png)

# 導入した結果

ゼロトラストセキュリティの導入によって、メリットとデメリットがあったので、各々述べていきます。

## 導入によるメリット

### 1. セキュリティレベルとオブザーバビリティが飛躍的に上がった
情報セキュリティに関して、リープフロッグ型で一気にレベルアップすることができました。

具体的には従前のセキュリティ体制ではできなかった、以下のようなことが実現できています。

 * 会社のセキュリティポリシーの端末/アカウントレベルでの強制適用/監視
 * 数時間単位での端末レベルでのセキュリティ脆弱性の把握
 * シャドーITの検出/防止/権限除去
 * ファイルの内容レベルでの社外共有状況の把握/強制非公開化
 * SaaSサービスをまたいだアカウント単位での疑わしい行動の把握
 * MITRE ATT&CKに基づいた自社サービスに対する脅威となるアクティビティの検出
 * 端末紛失/盗難時のリモートロック、リモートワイプ
 * IaaSインフラのセキュリティパッチの適用状況のモニタリング

また、個人情報や機密情報のオブザーバビリティも飛躍的に上昇しています。
一番感動したのが、Information ProtectionとDefender for Cloud Appsを利用したGoogle Workspaceまわりのオブザーバビリティ強化ですね。

Google Workspaceでのファイル共有は、この間エイチームさんでも非常に大きな問題になっていたかと思います。

https://www.itmedia.co.jp/news/articles/2312/21/news113.html

ここで問題になった、Google Workspaceでファイルの社外共有が許可されている場合の、管理者側からのセキュリティ制御は非常に難しいものがあります。

なぜなら、従業員側のマイドライブから社外に共有されているファイルに関して、よく使われているGoogle Workspaceのプラン(Business Standard,Enterprise Standard)だと管理者側から状況の把握や細かい制御ができないんですよね。
Enterprise Plusという最上位プランだとできるらしいです。

最上位プラン以外では基本GAS(Google Apps Script)を書くかサードパーティーのツールを使わないとマイドライブからの共有には管理者からの対応ができません。

この点に関して、Information ProtectionとDefender for Cloud Appsの導入によって、Google Workspaceのファイルの公開度や内容に応じて強制非公開化や共有レベルの強制変更設定が可能だったので、それを利用して弊社はGoogle Workspaceのセキュリティを一定水準で担保できるようになりました。

公開ファイルを新規作成できないように設定してありますし、GASを書かなくてもエイチームさんで問題になった「Google Workspace上で社外に公開されている個人情報が含まれたファイル」が無いか画面から確認できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/980999/59ae263a-c07d-514f-f55b-73971d0864b7.png)

私の各種セキュリティ設定よりも前に、エイチームさんと同様のインシデントを起こされていたらアウトだったので、ギリギリセーフでした。

### 2. 端末のキッティングやアカウント管理が楽になった
MDM/MAM(Microsoft Intune)の導入時に、全社員が共通で必要なアプリはセットアップ時に自動でインストールされるようにしたので、キッティングはだいぶ楽になりました。
退職時にもIntuneで自動初期化ができます。

また、SSOによって、退職時にEntra IDを削除するだけで、SSO連携しているほとんどのサービスのアクセスの停止またはアカウント削除ができるようになったので、アカウント管理が結構楽になりました。
退職時の消し忘れによる退職者のログイン事故や無駄なライセンス費用の増加は問題になりがちですよね。

### 3. 外部機関からセキュリティ面を高く評価されるようになった
PマークやISMSの更新審査時に審査員の方から絶賛されました。
また、第三者機関からのセキュリティチェックでも「今まで数年間担当した企業様の中で圧倒的に高いスコアでした」と言われ、非常に高く評価されました。

セキュリティまわりの対応は基本問題発生時に怒られるだけで、きちんと対応していることによって褒められたことがなかったので、褒められるのは新鮮な体験でした(笑)。

取引先から送られてくるセキュリティチェックシートも基本的には自信を持って打ち返すことができるようになりました。

## 導入によるデメリット

### 1. セキュリティ監視の業務量が増える
オブザーバビリティが上がるということは、インシデントとして報告される件数も増えることになります。
人間によるインシデント報告だけではなく、各種サービスからの自動で報告されるインシデントの対応も必要になるので、セキュリティの監視業務が必然的に増えることになります。

そして、弊社だと従業員数が150人程度なこともあって、まだ月10〜20件程度の自動インシデント検出にとどまっているので、インシデント対応の自動化はしていません。
インシデントとして判定されているものの中身を見ないと、本当にインシデントなのか判定が難しいものが多いので、自動化による見落としリスクの方が高いという判断をしています。

大企業であれば文字通り桁違いのインシデント検出数になるはずなので、SOAR(Security Orchestration, Automation and Response)等でインシデント対応の自動化を進めないとセキュリティ監視業務が回らなくなりそうです。
大企業だとSecurity Copilotが活躍しそうですね。

https://www.microsoft.com/ja-jp/security/business/ai-machine-learning/microsoft-security-copilot

### 2. やっぱりお金はかかる
Microsoft Entra IDからの各種サービスへのSSO接続やCASBへの連携対応をしていった際に、「それを実現したかったらプランをアップグレードしろ」というSaaSサービスが意外に多く、当初想定よりも費用がかかってしまいました。

ここはちょっと私の想定が甘かったです。

一部SaaSサービスにおいては月額費用が3~4倍となる見積もりも出されたため、予算を大幅に超えたサービスに関しては現時点でもゼロトラスト対応を実現できていません。
(めちゃくちゃ足元を見られたので、ちょっとそのサービスが嫌いになりました…)

それらのサービスに関しては、パスワードマネージャー(Keeper Security)によるアカウント管理の導入によって、SSOの代替によるゼロトラスト対応を進めています。
合わせて中長期的なサービス自体の代替も検討しています。

### 3. 多少ハレーションは起きる
どんなに頑張ってもセキュリティとユーザビリティに関して多少のトレードオフは発生します。
弊社でもWindows PCのキッティングのやり直しや、ゼロトラストの実現にあたって行ったGoogle Workspaceの「リンクを知っている全員がアクセスできる社外共有」の原則禁止等で多少ハレーションはおきました。

極力既存業務に影響を与えないようにしていたものの、やっぱり影響ゼロにはできませんでしたね。

とはいえ、シンクライアントの導入に比べれば、ユーザビリティの低下は遥かにマシです。
制御や監視が大幅に厳しくなったことに、普通に仕事をしている分には気づかないレベルです。

# 特に大変だったこと
会社のセキュリティルールに則った各種サービスでのセキュリティポリシー作成もなかなかに大変ではありましたが、MDM/MAM(Microsoft Intune)の展開が一番大変でした。

弊社では、業務用スマートフォンを会社支給するのではなく、従業員に通信費(月額5,000円)を支給して個人所有スマホで対応するというルールになっています。
(ここは賛否両論あると思いますが、私の入社前からの運用だったので、所与の条件としました。)

そのため、会社支給端末と合わせるとIntuneの導入が必要な対象としては以下の4パターンがあり、これを全従業員分対応していく必要がありました。

1. 会社が支給しているWindows PC
1. 会社が支給しているMac
1. 個人所有のiPhone
1. 個人所有のAndroid

そして、Windows PCは元々ローカルアカウントでのログインになっており、これをEntra ID + Windows Hello for Businessでのログインに切り替えるために、基本的に全台キッティングごとやり直しました。

弊社だとPC、モバイル端末合わせて対象は250台程度でしたが、それでも全台対応完了までに数ヶ月かかりました。
これは弊社の情シスのメンバーが頑張ってくれました。

大企業で同じ対応をする場合には、数万、数十万台という数字になるはずなので、弊社以上にこの対応が大変になるはずです。

# 最後に

セキュリティ対策にはなんやかんやでお金も時間もかかります。

そして、日本は欧米諸国と比べてもセキュリティに対する投資金額が非常に低い割合になっているというデータには事欠きません。

https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/pdf/001_s01_00.pdf

この問題の背景にはセキュリティに問題意識を持つ人間と、予算の決定権を持っている人間が基本的に異なっており、後者のセキュリティに対する問題意識やセキュリティへの投資意識が低い傾向があることが影響している印象です。

今回弊社ではそれがたまたま一致しただけかなと思っています。

アルコール性肝硬変になってからお酒の飲み過ぎを後悔しても遅いのと同様に、インシデントが発生してからセキュリティ対策の甘さを後悔してももう遅いんですよね。
会社のセキュリティレベルと発生したインシデントの内容によっては、会社/経営陣の損害賠償訴訟案件になります。

https://www.businesslawyers.jp/practices/354

昨今のGenerative AIの急速な発展によって、攻撃者側の攻撃能力も格段に上がっているので、セキュリティ対策の重要性はますます高くなっています。
(Generative AIとセキュリティに関しては別の記事で述べようかなと思います。)

弊社も比較的対応が進んでいる方であるとはいえ、まだまだ対応が必要な領域が残っているので、適宜対応を進めていく方針です。

今回のわたしの記事は以上となります。

この記事が皆様の会社でセキュリティ対策を行ううえで、少しでも参考になれば幸いです。