【ITニュース解説】Compliance before Conditional Access — an Intune enrollment & compliance runway that won't lock out Outlook

システムエンジニアを目指す初心者の皆さんが、企業や組織のIT環境を安全に保つための重要な考え方と、その具体的な実践方法について解説する。今回のテーマは「条件付きアクセスよりコンプライアンスを優先する」というもので、これはデバイスが安全な状態であることを確認してから、そのデバイスからのアクセスを許可するという、セキュリティの基本原則に基づいている。もしデバイスが安全でない状態にもかかわらずアクセスを許してしまうと、情報漏洩や不正アクセスのリスクが高まるため、この考え方は非常に重要となる。

まず、デバイスが安全な状態であるかを確認する「コンプライアンス」と、そのコンプライアンスの状態に基づいてアクセスを制御する「条件付きアクセス」は、異なる役割を持つ。これらは混同されがちだが、セキュリティを考える上でこの違いを理解することが不可欠だ。条件付きアクセスは、デバイスが「準拠している（コンプライアンスに適合している）」という信号を受け取って初めてその効果を発揮する。もしデバイスが適切に管理されておらず、準拠しているかどうかの情報が曖昧な場合、条件付きアクセスは単にメールなどの重要なサービスへのアクセスを遮断してしまうだけになり、セキュリティ向上にはつながらず、ユーザーの業務を妨げる結果となる。

この問題を避けるためには、デバイスを組織のルールに沿って段階的に管理していく手順が求められる。具体的な流れは「デバイスを登録する」「設定を適用する」「コンプライアンスの状態を測定する」「アクセスを制御する」の四つのステップで進めるのが効果的である。

最初のステップは「デバイスの登録」だ。組織内で使用されるデバイスには様々な種類があるため、それぞれのデバイスがどのように管理システムに登録されるかを事前に計画する必要がある。例えば、会社が支給するWindows PCであれば、自動的に設定が適用される「Autopilot」のような仕組みを使うのが効率的だ。一方、社員が個人で持ち込むBYOD（Bring Your Own Device）の場合、ユーザー自身が会社のポータルサイトを通じて登録する手間がかかるため、そのプロセスを明確にしておく必要がある。この計画を事前にしっかり立てておくことで、後からデバイスがなぜ設定を受け取らないのかといった疑問が解消されやすくなる。

次に、デバイス登録を進める上で「Intune（マイクロソフトが提供するデバイス管理サービス）」が正しく機能するための「前提条件」を確認することが非常に重要となる。多くの「Intuneが動かない」というトラブルは、ライセンスの不足や、Intuneの管理対象となるユーザーが正しく設定されていないことが原因で発生する。例えば、利用者がIntuneを使うための適切なライセンスを持っているか、そしてIntuneがどのユーザーやデバイスを管理対象とするかを示す「MDMユーザー範囲」が正しく設定されているかを確認する必要がある。また、いきなり全てのデバイスに適用するのではなく、ごく少数のデバイスとユーザーで構成される「パイロットグループ」で検証を行うこと、そして万が一全てロックアウトされてしまった場合に備えて、どのような状況でもアクセスできる「ブレイクグラスアカウント」を用意しておくことも大切だ。

「設定」「コンプライアンス」「条件付きアクセス」のそれぞれの役割を明確に理解することも重要である。

• 「設定」は、BitLockerによるディスク暗号化やウイルス対策ソフト（Defender）の設定、OSの更新方法など、デバイス自体に変更を加えるポリシーを指す。
• 「コンプライアンス」は、デバイスがこれらの設定や組織の定めるセキュリティ基準を満たしているかを評価し、「準拠している」か「準拠していない」かを判断するもので、デバイス自体に変更を加えることはない。
• 「条件付きアクセス」は、この「準拠している」という信号などを受け取り、サインインを許可するか、多要素認証を要求するか、あるいはブロックするかといったアクセス制御を行う。

ここで特に注意すべきは、「コンプライアンスポリシーが自動的に設定を有効にするわけではない」という点だ。例えば、BitLockerによるディスク暗号化を要求するコンプライアンスポリシーを設定しても、BitLockerを有効にするための設定ポリシーを別途適用していなければ、デバイスはいつまでも非準拠の状態が続き、コンプライアンスポリシーのせいにされてしまうという落とし穴がある。

そのため、最初のコンプライアンスポリシーは、BitLockerの必須化、Secure Bootの有効化、TPMの利用、最低限のOSバージョン、ファイアウォールとアンチウイルスソフトの利用、そしてパスワード要件など、基本的なセキュリティ基準から始めることが推奨される。これらのポリシーも、まずはパイロットグループにのみ適用し、非準拠デバイスに対するアクションは、最初は「非準拠としてマークする」だけに留めるのが賢明だ。いきなりデバイスをリモートでロックしたり、データを消去したりするような破壊的なアクションを設定すると、まだ信頼できない信号に基づいて誤った操作をしてしまうリスクがあるため、避けるべきである。「非準拠」と表示されても、それは設定の適用が完了していないだけの場合が多いということを、サポート担当者にも伝えておくべきだ。

デバイスの状態が期待通りになっているかを具体的に検証することも大切である。Windowsデバイスであれば、「dsregcmd /status」コマンドを使ってAzure AD（現在はEntra ID）への参加状況を確認したり、デバイスの設定画面から会社のIDが接続されているかを確認したりできる。Intuneの管理センターでは、各デバイスのコンプライアンスや構成の状態、管理状況を一目で確認できる。さらに、PowerShellスクリプトを使って、複数のデバイスの参加状態、BitLockerの有効性、Defenderのリアルタイム保護の状態といった情報を自動的に収集し、記録することも可能だ。

単一のデバイスの状態を確認するだけでなく、コンプライアンス全体の傾向を把握することも重要となる。管理センターの画面を毎日目で追うのではなく、毎週定期的にPowerShellスクリプトを使って、管理されているデバイスの一覧とコンプライアンスの状態をCSVファイルとして出力し、保存することを推奨する。これにより、組織全体のデバイスが健康な状態に向かっているのか、あるいは問題が悪化しているのかを客観的に判断できるようになる。

パイロットグループでの検証が成功し、設定が安定したら、いよいよ「条件付きアクセス」の導入段階に進む。パイロットの成功とは、例えばパイロットデバイスの90%以上が7日間連続でコンプライアンスを維持していること、非準拠の主な原因が特定され、対処法が確立されていることなどを指す。この段階で、条件付きアクセスもまずは「レポート専用モード」で、パイロットグループにのみ適用し、実際のアクセスをブロックせずにその影響を3〜7日間監視する。これにより、意図しないアクセスブロックが発生しないかを確認できる。特に、Autopilotのようなデバイス登録プロセス自体が、条件付きアクセスによってブロックされてしまうループ現象が発生することがあるため、登録関連のアプリを条件付きアクセスから除外するなどの注意が必要だ。条件付きアクセスの適用範囲は、コンプライアンスの適用範囲より常に一歩遅れて拡大していくという原則を守ることが、安全な運用には欠かせない。

ライブ環境で稼働しているコンプライアンスポリシーを編集する際には、誤って多数のデバイスを非準拠にしてしまわないよう細心の注意が必要となる。既存のポリシーを直接編集するのではなく、まずはそのポリシーを複製し、「パイロット版」として名前を変更する。そして、このパイロット版ポリシーを少数のパイロットグループにのみ適用し、少なくとも48時間、問題なく動作することを確認してから、本番環境への適用を検討する。この際も、万が一の事態に備えて、以前のポリシーに戻せるよう準備しておくことが重要だ。

最後に、よくある問題とその対処法について簡単に触れておく。デバイスがIntuneに全く表示されない場合は、Intuneの管理対象ユーザー範囲の設定やライセンス不足が原因であることが多い。Autopilotが途中で止まってしまう場合は、ネットワークの問題や、条件付きアクセスが登録アプリをブロックしている可能性がある。BitLockerのコンプライアンスに失敗する場合は、BitLockerを有効にするための設定ポリシーが適用されていないか、デバイスにTPM（Trusted Platform Module）が搭載されていないことが考えられる。これらのトラブルシューティングマップを参考に、基本的な確認から始めることで、迅速に問題解決にあたれるようになる。

このように、デバイスのセキュリティ管理は、急がずに一つ一つのステップを慎重に進めることが成功の鍵となる。特に初心者の皆さんは、焦らずにまずはパイロット環境で十分に検証を行い、理解を深めてから本番環境へ適用するように心がけてほしい。