条件付きアクセス(Conditional Access、以下CA)は、Microsoft Entra ID(旧Azure AD)が提供するゼロトラストセキュリティの中核機能だ。その中でも「準拠済みデバイスまたはハイブリッド参加デバイスを必要とする」テンプレートは、一見シンプルに見えて、適用した瞬間から想定外の問題を引き起こしやすいことで知られている。
Petri.comが指摘したのは、より本質的な問題だ。Microsoftは「ポリシー」ではなく「デフォルト値」という形で、組織のセキュリティ上の重要な判断を代わりに下している──という構造的な問題である。
「準拠済みデバイス必須」とは何か
CAテンプレートの「準拠済みデバイスまたはハイブリッド参加デバイスを必要とする」とは、端的に言えば「IntuneなどのMDMで管理・コンプライアンス確認ができたデバイスからのみアクセスを許可する」というポリシーだ。
ゼロトラストの観点から見れば、これは理にかなっている。OSのパッチ状態・ディスク暗号化・ウイルス対策の有効性を確認してからリソースへのアクセスを許可する。紙の上では完璧なゼロトラストアーキテクチャだ。
「シンプル」が「複雑」に変わる瞬間
このポリシーを組織全体に適用すると、以下のようなケースで即座に問題が噴出する。
ゲストユーザー・外部パートナー
取引先のユーザーは、自社Intuneに登録されていない。当然「準拠済み」判定は不可能。ゲストアクセスが一切できなくなるケースが頻発する。
BYOD(個人所有デバイス)
国内でも増えているBYOD環境では、個人所有PCやスマートフォンはIntuneに登録されていないことが多い。登録しようとすれば、プライバシー上の問題も生じる。
自動化・サービスアカウント
バッチ処理やRPA、スクリプト実行に使うサービスアカウントは、特定のデバイスから動かない場合がある。デバイスベースの条件を適用すると、既存の自動化処理が軒並み止まる。
緊急アクセス(Break Glass)アカウント
障害時に使う緊急管理アカウントは、このポリシーの例外設定を忘れると、本当に必要なときに使えなくなる。
Microsoftが「ルールブック」を書いている問題
記事が本質的に指摘しているのは、Microsoftがデフォルト設定や推奨テンプレートを通じて、組織のセキュリティポリシーを事実上「代筆」しているという構造だ。
Microsoftの推奨テンプレートは「ベストプラクティス」として提示される。IT担当者はその信頼性を前提に適用しがちだ。しかしそのテンプレートは、あらゆる組織の個別事情を考慮していない。エンタープライズのオンプレミス資産との連携、ゲストユーザーの比率、BYODポリシー、規制対応要件──これらはすべて組織ごとに異なる。
「Microsoftが推奨しているから安全」は正確ではない。「Microsoftの想定する組織に当てはまる場合に限り安全」が正確な表現だ。
実務への影響:IT管理者が今すぐ確認すべき5点
日本のエンタープライズ環境には固有の事情もある。国内の多くの大企業では、レガシーなオンプレミスADとAzure ADのハイブリッド構成が混在している。「ハイブリッド参加デバイス」の条件が正しく機能するかどうかは、ADのドメイン構成やDevice Writeback設定次第であり、一筋縄ではいかない。
以下の点を即座に確認したい。
- ゲストユーザー向けの例外ポリシーが存在するか ─ ゲスト向けに別のCAポリシーを用意し、準拠済みデバイス要件を免除または緩和する設計になっているか
- 緊急アクセスアカウントがCAの対象外になっているか ─ Break Glassアカウントを例外グループに確実に含める
- サービスプリンシパル・マネージドIDへの影響確認 ─ ユーザーIDとワークロードIDのCAポリシーは別々に設計する
- Report-onlyモードでの事前検証 ─ いきなり適用せず、まずReport-onlyで影響範囲をシミュレーションする
- Named Locationsとの組み合わせ ─ 社内IPからのアクセスに条件を緩和するポリシー設計の検討
筆者の見解
条件付きアクセスはゼロトラスト実装の王道であり、「準拠済みデバイス必須」はその中でも特に効果的な制御だ。方向性としては正しい。だからこそ、中途半端な適用が危ない。
Microsoftがテンプレートを提供すること自体は歓迎する。セキュリティ上の「最低水準」を組織全体で引き上げる効果があるからだ。しかし、テンプレートはあくまで「出発点」であり「答え」ではない。
日本のエンタープライズ現場を見ていると、レガシーなセキュリティモデルと最新のゼロトラスト設定が混在した状態が多い。「Microsoft推奨テンプレートを適用したら、翌朝から数百人がTeamsに入れなくなった」という話は珍しくない。それは技術の問題ではなく、自組織のアーキテクチャを理解せずにテンプレートを信じきったことへの代償だ。
Microsoftには、テンプレートの前提条件と対象外ケースをもっと明確にドキュメント化してほしい。「このポリシーはどういう組織には適用できないか」を明示することが、本当の意味でのユーザー支援になる。Microsoftが持つ技術力とエコシステムの強さを考えれば、それは十分できるはずだ──だからこそ「もったいない」と感じる。
ゼロトラストの文脈でこのCAポリシーを使う場合、「適用する・しない」の二択ではなく、「どのユーザー・デバイス・アプリ・リスクレベルの組み合わせに適用するか」という設計思考が不可欠だ。Microsoftのテンプレートはその思考の起点として活用し、自組織の実情に合わせてカスタマイズする──これが正しい付き合い方だ。
出典: この記事は Microsoft Security Without a Rulebook: The Problem with “Require Compliant Device” の内容をもとに、筆者の見解を加えて独自に執筆したものです。