最近、「JuiceWRLD」と「サカナクション」にはまっております。 どうも、インフラ部門ヘルプデスクオペレーターのオカダです。
今回は、Intuneのデバイスコンプライアンスポリシーについて設定を見直した件について記事を書かせていただきたいと思います。
本記事は、Intuneを導入したばかりの方や、これからIntuneのコンプライアンスポリシーを設定する予定の方々に参考や何かしらのヒントにしていただければと思います。
- ゼロトラストとIntuneの関係性
- コンプライアンスポリシーを見直したきっかけ
- コンプライアンスポリシーを見直した箇所
- Intuneのコンプライアンスポリシーを作成
- ポリシーの準拠判定の挙動について
- まとめ
ゼロトラストとIntuneの関係性
まず、コンプライスポリシーについて書かせていただく前にゼロトラストについてご説明をさせていただきたいと思います。
私たちの部署ではゼロトラストに向けて日就月将（にっしゅうげっしょう）で進めております！ よろしければ、過去の記事を見てください！
ここで改めて、ゼロトラストとIntuneの関係性を簡単におさらいをしたいと思います。
AIを使って用語を解説してもらいました🤖
ゼロトラストとは
ゼロトラストセキュリティモデルは、「信頼せず、常に確認する」という原則に基づいています。これは、内部ネットワークや外部ネットワークに関わらず、すべてのアクセス要求を検証することを意味します。具体的には、ユーザーやデバイスの認証、アクセス権限の確認、データの保護などが含まれます。
Intuneとは
Intuneは、Microsoftが提供するクラウドベースのモバイルデバイス管理（MDM）およびモバイルアプリケーション管理（MAM）ソリューションです。企業がデバイスやアプリケーションを安全に管理し、ユーザーが企業リソースにアクセスできるようにするためのツールです。
ゼロトラストとIntuneの関係性をまとめてみると
ゼロトラストセキュリティモデルは「信頼せず、常に確認する」という原則に基づき、すべてのアクセス要求を厳格に検証します。このモデルは、複雑なIT環境における効果的なセキュリティ戦略で、従来の「信頼できるネットワーク」からの脱却を図ります。Intuneはこの原則に従い、デバイスの状態やコンプライアンスを確認し、信頼できるデバイスのみが企業リソースにアクセスできる仕組みとなります。
つまるところ、Intuneのコンプライアンスポリシーとは
「ゼロトラストの原則に基づく信頼できるデバイス」の指標を決める役割という事になります。
コンプライアンスポリシーを見直したきっかけ
社内での検証や導入を経て、Intune（MDM）がしっかりと浸透してきました。 そこで、次のステップとして、Intuneのコンプライアンスポリシーを活用した 「ゼロトラストの原則に基づく信頼できるデバイス」の準備を進めることにしました。
既に、Intuneを導入した際にコンプライアンスポリシーを設定しておりましたが・・・
しかし、ここでよくあるインフラの課題が浮かび上がります。
このままだと、導入当初のコンプライアンスポリシーでは現状の環境に則しておりません。
そこで、この機会を利用してコンプライアンスポリシーで設定していなかった項目を見直す必要があると感じ、既存のコンプライアンスポリシーを見直してみました。
コンプライアンスポリシーを見直した箇所
導入時の環境が変わった部分としてはMicrosoft Defender for Endpointを導入した事です。
Defender For Endpointを導入した事によって 以下のコンプライスポリシーの設定が可能となりました。
- Microsoft Defender マルウェア対策
- 最新の Microsoft Defender マルウェア対策セキュリティ インテリジェンス
- リアルタイム保護
- デバイスは、次のマシンリスクスコア以下であることが必要
- ファイアウォール
以前までは、上記の項目はサードパーティ製のアンチウィルスソフトの守備範囲でしたが
今は大雑把に言ってしまえば、Microsoft Defender for Endpointの守備範囲となります。
IntuneとDefenderが連携できるのは利点ですが、コンプライアンスポリシーの範囲とするとシビアな運用を求められますが、ゼロトラストセキュリティの理念からすれば避けては通れないので腹を括りましょう。
なお、上記の一部ポリシーを利用するに辺り、Microsoft Defender for EndpointとIntuneの連携が必要ですので、以下の公式サイトを参考に連携を行ってください。
Microsoft Intune で Microsoft Defender for Endpoint を構成する | Microsoft Learn
連携が完了した後は、Intuneの「エンドポイント セキュリティ」>「 Microsoft Defender for Endpoint」の設定は以下のようにしました。（参考画像①）
【Microsoft Defender for Endpointによるエンドポイントセキュリティの構成を実施を許可する】は 「オフ」にしておきます。
この上記の項目は「Intuneに登録していないデバイスに関して管理する機能」なので、不要な場合はオフにしておきます。
Intuneのコンプライアンスポリシーを作成
次に本題のコンプライスポリシーを設定していきます。
以下の項目が守られているのが弊社の「信頼できるデバイス」としてのボーダーラインとなります。
デバイスの正常性 全て【必須】に設定
- BitLocker
- セキュア ブート
- コードの整合性
デバイスが暗号化されており、BIOSの改ざんがされないデバイスを担保する為に設定します。
システム セキュリティ 全て【必須】に設定
- デバイス上のデータ ストレージの暗号化を要求する
- ファイアウォール
- トラステッド プラットフォーム モジュール (TPM)
- ウイルス対策
- スパイウェア対策
- Microsoft Defender マルウェア対策
- 最新の Microsoft Defender マルウェア対策セキュリティ インテリジェンス
- リアルタイム保護
デバイスのセキュリティが動作している事を担保する為に設定を致します。
Microsoft Defender for Endpointの許容できるリスクスコア 【クリア～高】から選択
- デバイスは、次のマシン リスク スコア以下であることが必要
Defenderのデータを利用して、デバイスにマルウェアまたは潜在的な脅威が存在しない事を担保する為に設定。
【クリア～高】はどのくらいのリスクレベルを許容するか設定します。
詳しくは下記の公式サイトを参照してください。
Microsoft Intune で Microsoft Defender for Endpoint を構成する | Microsoft Learn
以上の項目が弊社の「信頼できるデバイス」の基準となります。
上記の項目で準拠していない端末等がございましたら、各ポリシーの原因を調査いたしましょう。
ポリシーの準拠判定の挙動について
ポリシーを作成し展開したら、次は展開状況を確認していきます。
コンプライアンスポリシーの条件を満たしたデバイスは
「準拠している」と判定され、条件を満たしていないデバイスは「準拠していない」へと判定されます。
本稿では、上記の処理は「デバイスの評価」として扱います。
サイドバーの「デバイスのポリシー準拠」を確認して、どのポリシーが「準拠」か「非準拠」も確認できます。
本稿では、上記の処理は「コンプライアンスポリシーの評価」として扱います。
しかし、述べた準拠判定において、以下の挙動が発生する事がございます。
デバイスの評価は「準拠している」と表示されている一方で、コンプライアンスポリシーの評価では「エラー」と表記されていました。🤔
当初は何で、「エラー」判定なのに「準拠していない」に判定にならないのかなっと思っていました。
調べてみると、「猶予期間」という挙動だという挙動だそうです。マニュアルは大事ですね。
Microsoft Intune でデバイスのコンプライアンス ポリシーの結果を監視する | Microsoft Learn
必要情報をまとめてAIに整理してもらうと以下のフローという事になります。🤖
1. 初期状態
- デバイスは最初は [準拠] とマークされる。
2. エラーの報告
- デバイスを対象とするコンプライアンス ポリシーの設定で [エラー] が報告される。
3. エラー後の動作
3.1. 7日以内の動作
- 3日以内のケース
- 3日後、コンプライアンス評価が正常に完了し、設定で [非準拠] と報告される。
- ユーザーは、設定状態が [エラー] に変更された後、最初の 3 日以内にアクセスを継続できるが、設定が [非準拠] に戻るとアクセスが削除される。
- 3日後 [準拠] に戻るケース
- 3日後、コンプライアンスの評価が正常に完了し、設定が [準拠] を返す。
- ユーザーは中断することなくアクセスできる。
- 7日間のアクセス
- ユーザーは条件付きアクセスによって保護されたリソースに 7 日間アクセスできる。
3.2. 7日後の動作
- 7日後も [エラー] の場合
- 7日後も設定の状態が [エラー] の場合、デバイスは [準拠していません] になる。
- ユーザーは保護されたリソースへのアクセスを失う。
- 猶予期間が設定されている場合
- コンプライアンス ポリシーに猶予期間が設定されている場合、デバイスは [猶予期間] とマークされる。
- ユーザーは引き続きアクセスできるが、管理者が指定した猶予期間内に設定が準拠していないと、デバイスは [非準拠] になり、アクセスを失う。
4. 初期状態が [非準拠] の場合
- デバイスは最初は [非準拠] とマークされる。
- 3日後、コンプライアンスの評価が正常に完了し、設定が [準拠] を返す。
- 最初の 3 日間はアクセスできないが、設定で [準拠] が返されると、ユーザーはアクセス可能になる。
このように、デバイスのコンプライアンス状態は、エラーの報告から評価、猶予期間、最終的な準拠状態までのプロセスを経て変化します。
エラーから瞬時に非準拠の状態になってしまう環境は厳しいですね。
Intuneの同期に失敗したりエラーが発生したりすると、業務が即座にストップしてしまい、仕事が進まなくなる可能性があります。また、ゼロトラストモデルの是非にも影響を及ぼすかもしれません。この点については、上記の仕様を把握できたので、少し安心しました。
まとめ
以上が今回のコンプライアンスポリシー設定を見直した件を記事にさせていただきました。
今後は、運用面や技術面でシビアな運用が求められるでしょう。その一方で、強固なセキュリティを得られるという恩恵も享受できます。技術が進化する中で、求められるセキュリティをしっかりと構築していきたいですね。
