Update starter-series-conditional-access.md

articles/azure-active-directory/starter-series-conditional-access.md

@@ -1,9 +1,9 @@
 ---
 title: "Entra ID 初学者向けシリーズ第 1 弾 - 条件付きアクセス 入門"
-date: 2024-12-27 01:00
+date: 2024-12-28 01:00
 tags:
     - Microsoft Entra
-    - US Identity Blog
+    - Starter series
 ---
 
 # Entra ID 初学者向けシリーズ第 1 弾 - 条件付きアクセス 入門
@@ -16,11 +16,11 @@ tags:
 
 - Microsoft Entra 条件付きアクセスの基本を理解したい方
 - よくあるお問い合わせの事例を通じて実践的な知識を得たい方
-- Microsoft Entra  のサインインログの基本的な分析方法を知りたい方
+- Microsoft Entra  のサインイン ログの基本的な分析方法を知りたい方
 
 **記事概要**
 
-本記事では、Microsoft Entra 条件付きアクセスを初めて学習/導入する方を対象に、基礎的な概念や設定方法を分かりやすく解説します。また、現場でよくある質問や課題を例に、具体的な対応策も紹介します。最後に、サインインログの読み解き方についても簡単に解説します。IT 管理者の方々にとって日々の運用に役立ちましたら嬉しいです！
+本記事では、Microsoft Entra 条件付きアクセスを初めて学習/導入する方を対象に、基礎的な概念や設定方法を分かりやすく解説します。また、現場でよくある質問や課題を例に、具体的な対応策も紹介します。最後に、サインイン ログの読み解き方についても簡単に解説します。IT 管理者の方々にとって日々の運用に役立ちましたら嬉しいです！
 
 ---
 
@@ -44,24 +44,24 @@ tags:
 
 ポリシーの適用条件や制御に具体的に設定できる値については後述します。
 
-より細かい説明については [改めて知る Microsoft Entra 条件付きアクセス](https://jpazureid.github.io/blog/azure-active-directory/review-ca/) の記事もご覧ください:  
+より細かい説明については [改めて知る Microsoft Entra 条件付きアクセス](https://jpazureid.github.io/blog/azure-active-directory/review-ca/) の記事もご覧ください。
 
-## 条件付きアクセスの考え方ポイント
+## 条件付きアクセスの考え方のポイント
 
 初学者にとって押さえておくと躓きにくいポイントと、おすすめの Identity チーム公式ブログをご紹介します。条件付きアクセス初学者の方に是非意識していただきたい考え方はこちらです。
 
-1. 設定した条件に合致したサインインにアクセス権を付与するのではなく、条件に合うサインインに制限をかける (制御する) という考え方  
-2. 制御の対象は、正確にはアプリケーションではなく ”リソース” である
+1. 設定した条件に合致したサインインにアクセス権を付与するのではなく、条件に合うサインインに制限をかける (制御する)  
+2. 制御の対象は、正確にはアプリケーションではなく "リソース" である
 
 ### 条件付きアクセスの考え方のポイント 1
 
 条件付きアクセスは、サインインに対してアクセス権を付与する (アクセスを許可) するという考え方ではなく、設定した条件に合うサインインに制御 (制限) をかけるという考え方です。
 
-条件に合致した場合にサインインに対して適用される制御 (制限) としては、「アクセスのブロック」や「多要素認証を要求する」、「Microsoft Entra ハイブリッド参加済みデバイスが必要など」というものがあります。実際の画面とその考え方は以下の画像のとおりです。
+条件に合致した場合にサインインに対して適用される制御 (制限) としては、「アクセスのブロック」や「多要素認証を要求する」、「Microsoft Entra ハイブリッド参加済みデバイスが必要」というものがあります。実際の画面とその考え方は以下の画像のとおりです。
 
 ![conditional-access-2](starter-series-conditional-access/conditional-access-2.png)
 
-条件付きアクセスは、ポリシーが適用される条件を満たした場合に、アクセスをブロックもしくは制御するためのものあり、条件を満たしたものを許可するというものではありません。ファイアーウォールのルールとは異なり、既定ですべてブロックがあり、そのうえで一部を許可するというイメージではない点に注意ください。ID とパスワードという最低限の認証を突破した後に、条件に合うものに追加の制御 (もしくはブロック) を適用するというイメージです。
+条件付きアクセスは、ポリシーが適用される条件を満たした場合に、アクセスをブロックもしくは制御するためのものあり、条件を満たしたものを許可するというものではありません。ファイアーウォールのルールのような「既定ですべてブロックがあり、そのうえで一部を許可する」というイメージではない点に注意ください。ID とパスワードという最低限の認証を突破した後に、条件に合うものに追加の制御 (もしくはブロック) を適用するというイメージです。
 
 改めて、「アクセスを許可する」というものではなく、「特定の条件を満たした場合に制御が適用される (条件を満たさなかった場合は制御が適用されない)」というイメージになります。
 
@@ -74,9 +74,9 @@ tags:
 
 条件付きアクセスが制御の対象とするのは、「アプリケーション」ではなく「リソース」へのアクセスです。ここで言う「リソース」というのは、Entra ID と連携して動作している Web アプリケーション (Salesforce や自社開発のWeb アプリケーションなど) や、PC 上で動作するクライアント アプリケーションがクラウド上からデータを取得する際のアクセス先 (Web API) とお考え下さい。
 
-例えば Outlook を Windows 上で利用して、Microsoft 365 の E メールを利用している場合、ユーザーは単に Outlook にサインインしているだけと思うはずですが、実際にはインターネット (Microsoft 365) 上から Email のデータを取得してくるにあたり Exchange Online の Web API を利用しています。Outlook は Exchange Online というクラウド上の "リソース" を使用しており、この Exchange Online が条件付きアクセスの適用対象となります。このため、条件付きアクセスの設定画面では、Outlook というリソースは出てきません。
+例えば Outlook クライアントを Windows 上で利用して、Microsoft 365 の E メールを利用している場合、ユーザーは単に Outlook クライアントにサインインしているだけと思うはずですが、実際にはインターネット (Microsoft 365) 上から Email のデータを取得してくるにあたり Exchange Online の Web API を利用しています。Outlook クライアントは Exchange Online というクラウド上の "リソース" を使用しており、この Exchange Online が条件付きアクセスの適用対象となります。このため、条件付きアクセスの設定画面では、Outlook というリソースは出てきません。
 
-他にも例えば、ユーザーが Windows 上で Teams のネイティブ アプリにアクセスしたとします。この時、ユーザーは Teams のネイティブ アプリにだけアクセスしているわけではありません。実際は、Teams のクラウド側の Web サービスに加え、SharePoint Online、Exchange Online、Microsoft Planner という複数の Web API にアクセスをしています。つまり、Teams のクライアントは、それが使用するデータのもととなっている複数のクラウド上の ”リソース” にアクセスしています。Teams はこれらリソースの一つでもアクセスができないと (条件付きアクセスでブロックされると)、正常に動作しません。
+他にも例えば、ユーザーが Windows 上で Teams のネイティブ クライアント アプリにアクセスしたとします。この時、ユーザーは Teams のネイティブ クライアント アプリにだけアクセスしているわけではありません。実際は、Teams のクラウド側の Web サービスに加え、SharePoint Online、Exchange Online、Microsoft Planner という複数の Web API にアクセスをしています。つまり、Teams のクライアントは、それが使用するデータのもととなっている複数のクラウド上の "リソース" にアクセスしています。Teams はこれらリソースの一つでもアクセスができないと (条件付きアクセスでブロックされると)、正常に動作しません。
 
 ![conditional-access-3](starter-series-conditional-access/conditional-access-3.png)
 
@@ -198,6 +198,8 @@ Teams のみをユーザーに利用させたいというお客様は多くい
 
 条件付きアクセスに起因してサインインがブロックされた場合、その概要がサインイン画面に表示されます。この時、「詳細」をクリックするか、画面右下の ... をクリックすると、エラーの詳細を確認可能です。サインイン時のエラー画面にて表示される以下の情報を控えてサインイン ログを検索すると詳細な情報を得ることが出来ます。
 
+なお、これらの情報は弊社サポート チームにとっても重要な情報であるため、サインインに関連した調査を依頼される際には弊社サポートにもこの情報をぜひご提供ください。
+
 - 要求 ID (Request ID): 各サインインの ID
 - 相関 ID (Correlation ID): 一連のサインインを束ねた ID
 - Timestamp: サインインした時刻
@@ -235,7 +237,7 @@ Entra ID のサインイン ログを確認するには以下の手順を実施
 今回の初学者向けシリーズ第 1 弾では条件付きアクセスについて解説しました。特にご注目いただきたい点をまとめると以下のとおりです。
 
 - アクセス権の付与ではなく、特定の条件を満たした場合に制御が適用される (条件を満たさなかった場合は制御が適用されない) というイメージである
-- 条件付きアクセスでの制御の対象はユーザーの目の前で動いているアプリではなく、クラウド上の ”リソース” である
+- 条件付きアクセスでの制御の対象はユーザーの目の前で動いているアプリではなく、クラウド上の "リソース" である
 - ユーザーの目の前で動いているアプリがどのクラウド "リソース" を利用しているかを意識することでポリシーの構成をスムーズに行うことが可能である
 
 # 参考になる資料