はじめに
セキュリティの SOC 対応を外部委託する際に、どのような 条件付きアクセス で制御すれば良いのかを検討してみました。
今回のようなシチュエーションの場合に、担当者に適切な条件付きアクセスを構成しようとすると、適切な方法が無く 課題にぶつかります。そのような場合の対処策を紹介することが本記事のテーマです。
※条件付きアクセス は、Conditional Access の頭文字をとって CA と略されます。
結論
よくある以下の構成（いわゆる “王道パターン”）
- 全クラウドアプリを ブロック
- Microsoft 管理ポータル だけ 除外
では、一見うまくいくように見えますが、
My Sign-ins（セキュリティ情報）にアクセスできなくなる という問題が発生します。
これを解決するには、
- My Sign-ins のサービスプリンシパルを追加する
- 条件付きアクセスは 1本ではなく 2本に分けて設計する
という構成が必要です。
つまり、「王道パターン」だけでは成立しないケースが存在します。
実環境では、この落とし穴にハマる可能性があります。
Defender / Purview + My Sign-ins を許可したい場合、「全ブロック＋管理ポータル除外」では成立せず、My Sign-ins の サービスプリンシパル 追加と CA 分割設計が必須です。
条件付きアクセス については、以下の 国井さんの記事 が参考になります。
参考：Always on the clock：条件付きアクセスまとめ
https://azuread.net/archives/15100
条件付きアクセス を 初めて実装する場合は、以下の私の記事も参照ください。
セキュリティの既定値群 と 条件付きアクセス の初回利用について
https://qiita.com/carol0226/items/51a70a561b78af567972
想定シナリオ
- SOC を外部委託しており、Defender / Purview だけを触らせたい
- ただし Microsoft 365 および Azure / Entra / Intune などの管理ポータルは触らせたくない
- さらに、担当者自身が認証器（Authenticator や パスキー）を付け替えられる必要がある（My Sign-ins が必要）
まずハマる現象
ありがちな “王道CA” が失敗する
- 全クラウドアプリを ブロック
- 例外として Microsoft 管理ポータル だけを除外
→ これで業務はできますが、My Sign-ins（aka.ms/mysecurityinfo）にアクセスできません。
→
つまり、
「Defender / Purview だけ許可したい」のに、My Sign-ins が使えない
という “設計上の破綻” が起きます。
＝ 運用に必要な認証情報の更新ができない
という状態になります。
セキュリティ情報 (My Sign-ins) とは？
https://aka.ms/mysecurityinfo からアクセスすることができます。
Entra ユーザーのためのアカウント情報を管理する手段として、マイアカウント という機能が提供されていますが、セキュリティ情報 は、マイアカウント内の 1つのページです。
読者の方々も、Microsoft 365 や Entra のユーザーであれば、管理者から案内されてアクセスしたことがあるページだと思います。パスワード や Authenticator、パスキー などを変更するために使ったことがあると思います。
なぜ問題が起きるのか？
- 条件付きアクセスは「ターゲットリソース（クラウドアプリ / ユーザー操作）」単位で制御します
- しかし My Sign-ins（セキュリティ情報）は、テナントによっては CA のターゲットに表示されません
- その結果「全部ブロック→使いたいアプリだけ除外」という王道パターンが成立できません
補足
条件付きアクセスで クラウドアプリ として選択できるのは、テナント内にサービスプリンシパルが存在するものだけです。
My Sign-ins は既定では存在しない場合があるため、選択肢に表示されません。
解決策
この問題は、以下の ステップで解決することができます。
※いずれも設定自体はシンプルですが、発想に気づくのが難しいポイントです。
- 1. My Sign-ins を “CAで選べる状態” にする（サービスプリンシパル追加）
-
2. 条件付きアクセス (CA) の構成
- 2-1. CAポリシー①「Microsoft 管理ポータル + My Sign-ins を使えるようにする」
- 2-2. CAポリシー②「Azure / Entra / Intune を塞ぐ」
1. My Sign-ins を “CAで選べる状態” にする（サービスプリンシパル追加）
条件付きアクセスでは、ターゲットリソース で用意された リソース単位で 許可・ブロック などの制御が行えますが、My Sign-ins（セキュリティ情報） を特定するための リソース が用意されていないテナントが存在します。
そのため、条件付きアクセスの王道設定である、すべてのリソース をブロックし、使わせたいリソースだけを 除外する という方法が使えません。
1-1. 解決のためのヒント
これを解決する方法が見つかりました。
以下の海外の記事にヒントが記載されていました。
参考：Configuring Conditional Access for Guest Users: Allowing Only Office 365 and Essential Apps
上記の記事では Microsoft 365 だけを使わせたいが、セキュリティ情報 (My Sign-ins) も使わせるための方法が説明されています。本件に非常に類似しています。
そして、セキュリティ情報 (My Sign-ins) が従来は存在しなかったが、最近 追加されたことや、追加方法などが説明されています。
この記事の内容を参考に、対処手順をキャプチャ付きで紹介していきます。
1-2. サービスプリンシパルの追加
まず、海外記事にならって サービスプリンシパルの追加を行います。
ですが、海外記事の内容だけだと、どのような影響があるのかや、前後で必要なコマンド類がわかりません。
そこで、以下の Japan Azure Identity Support Blog で解説されている記事が役立ちました。
海外の記事と同じコマンドで サービスプリンシパル (Microsoft Intune Enrollment) を追加する方法や その影響なども解説されており、この内容を見る限りは、My Sign-ins を追加しても問題なさそうであることが判ります。
※ただし、「一度追加した サービスプリンシパル は、削除することができない」と説明されていますので、その点は 認識しておいてください。
Support Blog : Microsoft Intune Enrollment を Entra ID に登録する
https://jpazureid.github.io/blog/azure-active-directory/microsoft-intune-enrollment/
上記の記事を参考に、以下のコマンドを実行していきます。
以下の太字の部分は 上記の記事とは違うので注意してください。
"19db86c3-b2b9-44cc-b339-36da233a3be2" が My Sign-ins のことを示しています。
- Install-Module Microsoft.Graph -Force
- Connect-MgGraph -Scopes "Application.ReadWrite.All"
- New-MgServicePrincipal -AppId "19db86c3-b2b9-44cc-b339-36da233a3be2"
上記の画面のような結果になれば、OK です。
2. 条件付きアクセス (CA) の構成
ロールと条件付きアクセスの組み合わせで実現可能な制御 について、検証した結果を 一覧表にまとめました。
この表を見ていただくと、➂ だと My Sign-ins（セキュリティ情報）が使えなくなってしまうため、➃ の構成が適していることがお分かりいただけると思います。
- ✕ = サインイン時にブロックされる
- ▲ = サインインは可能だが、サービスの入口でブロック（結果 なにも使えない）
- △ = サインインは可能だが 権限のある機能しか使えない
- 〇 = サインインすることができる（サービスによっては、別途 ライセンスが必要）
➀ ロール無し：Security 管理センターにサインインは出来ても、セキュリティに関する操作が行えない
➁ Security ロールを付与：セキュリティに関する業務が行える。しかし不要なサイトにもサインインが可能
➂ (CA) 管理センターのみ：必要な業務のみが行えるが、「セキュリティ情報」にアクセスできない
➃ (CA) 対処策を追加：➂ 対して除外設定を追加して「セキュリティ情報」へのアクセスを確保
| # | ➀ ロール なし |
➁ Security ロール付与 |
③ (CA) Microsoft 管理ポータル のみ |
➃ (CA) Microsoft 管理ポータル 対処策を追加 |
|---|---|---|---|---|
| Microsoft 365 m365.cloud.microsoft |
〇 | 〇 | ✕ | ✕ |
| Microsoft 365 マイアカウント myaccount.microsoft.com |
〇 | 〇 | ✕ | 〇 |
|
セキュリティ情報 (My Sign-ins) aka.ms/mysecurityinfo |
〇 | 〇 | ✕ | 〇 |
| Windows App windows.cloud.microsoft |
〇 | 〇 | ✕ | ✕ |
| Microsoft 365 Copilot Chat copilot.cloud.microsoft |
〇 | 〇 | ✕ | ✕ |
| Copilot Studio copilotstudio.microsoft.com |
〇 | 〇 | ✕ | ✕ |
| Teams teams.microsoft.com |
▲ | ▲ | ✕ | ✕ |
| Outlook.com outlook.cloud.microsoft/mail |
▲ | ▲ | ✕ | ✕ |
| Microsoft Loop loop.cloud.microsoft |
〇 | 〇 | ✕ | ✕ |
| Microsoft Entra エンタープライズアプリ myapps.microsoft.com |
〇 | 〇 | ✕ | ✕ |
| Intune ポータルサイト の Web サイト portal.manage.microsoft.com |
▲ | ▲ | ✕ | ✕ |
| Azure Portal portal.azure.com |
△ | △ | △ | ✕ |
| Microsoft 365 管理センター admin.cloud.microsoft |
▲ | ▲ | ✕ | ✕ |
| Teams 管理センター admin.teams.microsoft.com |
▲ | ▲ | ✕ | ✕ |
| Exchange 管理センター admin.cloud.microsoft/exchange |
△ | △ | ✕ | ✕ |
| Share Point 管理センター go.microsoft.com/fwlink/?linkid=2185219 |
▲ | ▲ | ✕ | ✕ |
| Microsoft 365 Apps 管理センター config.office.com/officeSettings |
▲ | ▲ | ✕ | ✕ |
| Microsoft Entra 管理センター entra.microsoft.com |
△ | △ | △ | ✕ |
| Intune 管理センター intune.microsoft.com |
△ | △ | △ | ✕ |
| Microsoft Defender ポータル security.microsoft.com |
△ | 〇 | 〇 | 〇 |
| Microsoft Purview コンプライアンス ポータル purview.microsoft.com |
△ | 〇 | 〇 | 〇 |
| Power Platform 管理センター admin.powerplatform.microsoft.com |
△ | △ | ✕ | ✕ |
| Microsoft Fabric (Power BI) 管理ポータル app.powerbi.com/admin-portal |
△ | △ | ✕ | ✕ |
| Viva Engage 管理センター engage.cloud.microsoft/admin |
△ | △ | ✕ | ✕ |
上記の ➃ (CA) Microsoft 管理ポータル 対処策を追加 を実現する構成
-
2-1. CAポリシー ①「Microsoft 管理ポータル + My Sign-ins を使えるようにする」
こちらがメインのポリシーです。ただし、このポリシーだけでは Azure Portal , Entra 管理センター , Intune へ不必要にサインインができてしまいます。
-
2-2. CAポリシー ②「Azure / Entra / Intune を塞ぐ」
このポリシーで、不必要なサインインをブロックします。
2-1. CAポリシー ①「Microsoft 管理ポータル + My Sign-ins を使えるようにする」
1．ユーザー または エージェント
対象となる セキュリティグループ を割り当てます。
2．ターゲットリソース
海外の記事を参考にしていますが、若干カスタマイズしています。
以下の エンタープライズアプリ を条件付きアクセスの除外リソースとして追加してください。
| No. | Name | App Id |
|---|---|---|
| 1 | Microsoft 管理ポータル Microsoft Admin Portals |
IDが無いため 名称 Microsoft Admin Portals で検索します |
| 2 | AADReporting | 1b912ec3-a9dd-4c4d-a53e-76aa7adb28d7 |
| 3 | Azure Credential Configuration | ea890292-c8c8-4433-b5ea-b09d0668e1a6 |
| 4 | Microsoft App Access Panel | 0000000c-0000-0000-c000-000000000000 |
| 5 | Microsoft Approval Management | 65d91a3d-ab74-42e6-8a2f-0add61688c74 |
| 6 | Microsoft Invitation Acceptance Portal | 4660504c-45b3-4674-a709-71951a6b0763 |
| 7 | My Profile | 8c59ead7-d703-4a27-9e55-c96a0054c8d2 |
| 8 | My Sign-ins | 19db86c3-b2b9-44cc-b339-36da233a3be2 |
| 9 | Windows Azure Active Directory | 00000002-0000-0000-c000-000000000000 |
ポイント
該当の名称が見当たらない場合は、App Id で検索してみてください。
3．許可 では、アクセスのブロック を設定します。
4．オン にしてから 保存 します。
2-2. CAポリシー ②「Azure / Entra / Intune を塞ぐ」
➀ のポリシーだけでは、Azure Portal , Entra 管理センター , Intune へアクセスできてしまうため、それをブロックするためのポリシーを作成します。
1．ユーザー または エージェント
１つめのポリシーと同じグループを設定します。
2．ターゲットリソース
以下のリソースを探して、対象 として選択します（対象外ではないので注意）
Azure Resource Manager : 797f4846-ba00-4fd7-ba43-dac1f8f63013
3．許可 は、アクセスのブロック を選択します。
4．オン にしてから 保存 します。
以上で、目的のポリシーが構成されました。
実際に動作をみていただくと、一覧表のうち、➃ (CA) 対処策を追加 と同じ結果になることが確認できると思います。
ポイント
この方法で制御した My Sign-ins は、どうも InPrivate（シークレットモード）では、適切に動作しません。
通常のブラウザーセッションを使うことで適切に動作しています。
注意
この My Sign-ins が リソースに追加されて 条件付きアクセスから選べるようになったとしても、実際に 条件付きアクセス で制御されるようになるまでに、１時間くらい待つ必要があるようです。機能するまでは スルーしてしまいます。この点に注意すれば、あとは 意図通りに動作することが確認できると思います。
以上で、
👉 Defender / Purview と My Sign-ins のみにアクセス可能な条件付きアクセス構成
が実現できました！
3. まとめ
本記事では、SOC の外部委託における条件付きアクセス設計について、
「王道パターン」では成立しないケースがある
というポイントを中心に整理しました。
特に、
- 全クラウドアプリをブロック
- Microsoft 管理ポータルのみ除外
という構成では、
My Sign-ins が利用できず、認証情報の更新ができない
という設計上の問題が発生します。
この問題に対しては、
- My Sign-ins のサービスプリンシパルを追加する
- 条件付きアクセスを 2つのポリシーに分けて設計する
という対応により解決できます。
条件付きアクセスはシンプルな仕組みですが、
リソースの扱いによって動作が大きく変わる
ため、今回のような落とし穴に注意することが重要です。
実際の設計では、本記事のような例外パターンも考慮することが必要です。