認証コンテキストの活用｜機密リソースだけ追加認証を要求する設定

通常の条件付きアクセスは「誰が・どこから・何のアプリにアクセスするか」で制御しますが、同じSharePoint Onlineの中でも「一般的な社内情報のサイト」と「経営会議の機密資料サイト」では求めるセキュリティレベルが違います。

**認証コンテキスト（Authentication Context）**は、アプリ単位ではなく「リソース単位」でアクセス条件を切り替える仕組みです。

仕組み

認証コンテキストは、条件付きアクセスポリシーと秘密度ラベル（またはSharePointサイト）を紐付ける「中間層」です。

設定の流れ：

1. Entra管理センターで認証コンテキスト（例：「機密アクセス」）を定義
2. 条件付きアクセスポリシーで「認証コンテキスト = 機密アクセス」を条件に設定し、制御（準拠デバイス必須、MFA必須など）を割り当て
3. SharePointサイトまたは秘密度ラベルに「機密アクセス」の認証コンテキストを紐付け

これにより、該当のSharePointサイトにアクセスした時、または該当の秘密度ラベルが付いたファイルを開こうとした時に、追加の認証要求がトリガーされます。

活用例

例1：経営会議サイトへのアクセスに準拠デバイスを要求。 通常のSharePointサイトはどのデバイスからでもアクセス可能だが、経営会議の資料が格納されたサイトだけはIntuneの準拠デバイスからのアクセスに限定。

例2：「極秘」ラベルのファイルにフィッシング耐性MFAを要求。 通常のMFA（Authenticatorプッシュ通知）でサインイン済みでも、「極秘」ラベル付きファイルを開こうとするとFIDO2キーによる追加認証が求められる。

例3：特定のサイトを社内ネットワークからのみアクセス可能にする。 人事情報や給与データが格納されたサイトに「社内ネットワーク限定」の認証コンテキストを設定。

対象を絞ることが成功の条件

多くのサイトに適用すると、運用が破綻します。 追加認証が頻繁に発生し、利用者からの不満と問い合わせが増え、最終的に例外だらけになるためです。

最初の対象は、次のような**「入れる人が限られていて当然」と全員が納得する範囲**に絞ってください。

• 役員会・取締役会の資料サイト
• 人事・給与情報のサイト
• M&A や新規事業など、限られたメンバーだけの案件サイト

適用対象は最初は1〜2サイトで十分です。 運用が回ることを確認してから広げます。

導入時に必ずやること

1. 基本のポリシーを先に整備する

認証コンテキストは、条件付きアクセスの基本ポリシーが整っていることが前提です。全員MFA、管理者の強化、レガシー認証のブロック——これらが未整備の状態で細かい制御から入っても、守りの総量は増えません。

2. レポート専用モードで影響を確認する

いきなり有効にせず、どのユーザーが、どの頻度で条件に該当するかをレポートで確認してください。想定外のユーザーが対象に含まれていることがあります。

3. 緊急用アカウントを除外する

条件付きアクセスの設定ミスで管理者全員が締め出される事故は実際に起きています。除外設定をした緊急用アカウントを用意してから、ポリシーを有効にしてください。

4. 利用者への説明を先に行う

「サインイン済みなのに、また認証を求められた」は、故障と受け取られます。 ヘルプデスクへの問い合わせが集中する典型的なパターンです。

• どのサイト・どのファイルで追加認証が発生するか
• なぜ必要か（そのデータの機密性）
• 何を求められるか（Authenticatorの承認か、FIDO2キーか）

これらを事前に案内しておけば、問い合わせの大半は発生しません。

運用でつまずく点

秘密度ラベルと連携する場合、ラベルが付いていなければ効きません。 「極秘」ラベルに認証コンテキストを紐付けても、実際のファイルにラベルが付与されていなければ、制御は発動しません。ラベルの運用（自動付与のルール、利用者への周知）が先に回っている必要があります。

外部ゲストへの影響を確認してください。 準拠デバイスを要求する設定にすると、社外の協業者は原則としてアクセスできなくなります（相手の端末は自社のIntuneに登録されていないため）。ゲストが参加するサイトに適用する場合は、要求する条件をMFAに留めるなどの調整が必要です。

Officeデスクトップアプリやモバイルアプリでの挙動も確認してください。 ブラウザでは想定どおりでも、アプリ側で認証を求められたときの表示が分かりにくく、利用者が操作に迷うことがあります。導入前に、実際に使われている端末とアプリで試してください。

必要なライセンス

• Entra ID P1以上（条件付きアクセスの利用に必要）
• 秘密度ラベルとの連携にはBusiness Premium / E3以上

いつ導入すべきか

認証コンテキストは「すべてのリソースに同一のセキュリティレベルを適用するのが業務上不合理な場合」に有効です。中小企業では、まず条件付きアクセスの基本ポリシー（全員MFA、管理者強化MFA、国ブロック）を整備した上で、特に機密性の高い情報を扱うサイトやラベルに対して段階的に導入するのが現実的です。

次のような要望が出てきたときが、検討のタイミングです。

• 「役員資料のサイトだけ、もっと厳しくできないか」
• 「取引先と共有しているサイトと、社内機密を同じ扱いにしたくない」
• 「全社に準拠デバイスを必須にしたいが、業務が回らないので機密サイトだけにしたい」

逆に、「セキュリティを強化したい」という漠然とした動機で導入すると、対象が広がって運用が破綻します。 守りたいものが具体的に言えるかどうかが分かれ目です。

まとめ

• 認証コンテキストは、アプリ単位ではなくリソース単位で条件を切り替える仕組み
• 対象は1〜2サイトから。広げすぎると例外だらけになって破綻する
• 前提は基本ポリシー（全員MFA・管理者強化・レガシー認証ブロック）の整備
• レポート専用モードで影響を確認してから有効化する
• 緊急用アカウントを除外してからポリシーを適用する。締め出し事故は実際に起きている
• 「サインイン済みなのに再認証」は故障と受け取られる。事前の説明で問い合わせは大幅に減る
• 秘密度ラベルと連携する場合、ラベルが付いていなければ制御は発動しない
• 準拠デバイスを要求すると、外部ゲストはアクセスできなくなる。ゲスト参加サイトでは条件を調整する
• デスクトップアプリ・モバイルアプリでの挙動を導入前に実機で確認する
• 導入の判断基準は、守りたいものを具体的に言えるか

情シス365では、条件付きアクセスの設計から認証コンテキストの構成まで支援しています。お気軽にご相談ください。