本記事は、2024 年 2 月 6 日に米国の Microsoft Entra (Azure AD) Blog で公開されたAuto Rollout of Conditional Access Policies in Microsoft Entra ID を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
Note
サポート チームからの補足: Microsoft マネージド条件付きアクセス ポリシーの自動有効化は、下記ポリシーがレポート専用モードで作成されているテナントにおいて、現在順次進められております。自動有効化をご要望でないお客様は、レポート専用モードを無効状態に変更するようご対応ください。
2023 年 11 月の Microsoft Ignite にて、Microsoft マネージドのポリシーと、お客様テナントにおける多要素認証 (MFA) 関連の条件付きアクセス ポリシー の自動ロールアウトについて発表されました。それ以降、50 万以上のテナントに対してレポート専用ポリシーを展開しています。これらのポリシーは、セキュリティを向上させるための主要な技術の進歩を含む「Secure Future Initiative」の一環です。これにより、将来的に増加すると予想されるサイバー脅威に対してお客様を保護することを目的としています。
このブログでは、これらのポリシーについて改めて詳しく説明し、それらがどのように機能するかを包括的に理解できるようにフォローアップすることを目的としています。
高い権限を持つ管理者アカウントは攻撃を受ける可能性が高いため、これらの役割に対して MFA を実施することで、これらの特権管理機能を保護することが望まれます。このポリシーは、特権を付与された 14 の管理者ロールを対象としており、これらのロールを持つユーザーが Microsoft 管理者ポータルにサインインするときに多要素認証を要求します。このポリシーは、セキュリティの既定値群が有効になっていない Microsoft Entra ID P1 および P2 のテナントを対象としています。
ユーザーごとの MFA とは、ユーザーに個別に有効化ができ、サインインするたびに多要素認証を実行するよう求める機能です (信頼できる IP アドレスからサインインする場合や、信頼できるデバイスに MFA を記憶させる機能がオンになっている場合などを除きます)。Entra ID P1 のライセンスを持つお客様にとって、条件付きアクセスは多くの追加機能を備えた管理者向けの優れたオプションです。条件付きアクセスでは、ユーザー グループ や アプリケーション を個別にポリシーの対象とすることや、リスクやデバイスに基づく さらなる条件、認証強度 との統合、セッション制御、報告専用モード などが含まれています。これにより、MFA を求める対象をより絞り込むことができ、セキュリティの体制を維持しながら、エンドユーザーの負担を低減することが可能です。
このポリシーは、ユーザーごとの MFA を有効にしているユーザーを対象としています。このポリシーにより、これらのユーザーが条件付きアクセスの対象となり、すべてのクラウド アプリケーションで多要素認証を実行する必要が生じます。これにより、組織は条件付きアクセスへの移行を円滑に行い、エンドユーザーの業務に影響を与えずに高いセキュリティ レベルを維持させることができます。
このポリシーは、 Entra ID P1 および P2 のライセンスを持つユーザーを対象としています。セキュリティ既定値群のポリシーが有効でない場合や、ユーザーごとの MFA が有効になっているユーザーが 500 人未満の場合に適用されます。このポリシーが適用されても、エンドユーザーの体験に変化はございません。
このポリシーは、高リスクのサインインを検出した場合にのみ、追加のセキュリティ保護を提供することで、お客様が NIST Zero Trust Maturity Model におけるリスク評価の最適レベルを満たせるよう支援します。ここでいう「高リスクのサインイン」とは、特定の認証リクエストが正規の ID 所有者ではない可能性が非常に高いこと、もしくはそのリクエストがブルートフォース攻撃、パスワード スプレー攻撃、トークン リプレイ攻撃であることを意味しています。サインインのリスクに動的に対応することで、ほとんどのユーザーには意識させないまま、(同時に高いサインイン リスクを持たないユーザーには影響を与えないようにしながら) このポリシーは攻撃をリアルタイムで阻止します。ID Protection が攻撃を検出した場合、ユーザーは MFA で自己修復を促され、Entra ID で再認証され、侵害されたセッションはリセットされます。
リスクの高いサインインについて詳しくはこちら をご覧ください。
このポリシーは、Entra ID P2 テナント上のすべてのユーザーを対象としています。ここでは、セキュリティ既定値群が有効でなく、すべてのアクティブ ユーザーが既に MFA を利用しており、そして各ユーザーに十分なライセンスがある状態を想定しています。すべてのポリシーと同様に、自分自身をロックアウトしないように、緊急アクセス用アカウントやサービス アカウントを除外するようにお気を付けください。
Microsoft が管理する上記の条件付きアクセス ポリシーは、すべての対象テナントでレポート専用モードで作成されています。これらのポリシーは、Microsoft が提案しているもので、それぞれの組織の独自の環境に適用させて使用することができます。管理者は、条件付きアクセスポリシーのブレード 上で、これらのポリシーの表示および確認が可能です。管理者は 緊急アクセス用アカウントやサービス アカウント を除外するといったカスタマイズを行うことが推奨されます。準備が整ったら、ポリシーをオンに切り替えください。さらなるカスタマイズが必要な場合は、管理者はポリシーを複製して調整を行うことも可能です。
Microsoft が管理する条件付きアクセス ポリシーを有効にし、組織のニーズに合わせてカスタマイズすることを今すぐお試しください。多要素認証ポリシーの実装に積極的に取り組むことは、進化するセキュリティの脅威から組織を守る上で非常に重要です。リソースを保護する方法の詳細については、こちら の Microsoft 管理ポリシーのドキュメントを参照ください。
]]>2024/3/12 にかけて、RM64-FSZ の通知や「Action required: Transition from Azure classic administrator roles to RBAC roles 」の件名にて、従来の管理者ロールの廃止についてメール通知が行われ、この廃止に関する内容について多くのお問い合わせをいただいております。
そこで今回は、本廃止に関する概要と対応について、よくある質問形式でおまとめして紹介します。
重要
本情報は 2024/3/14 時点の情報を基に執筆しております。最新情報は Azure ポータル上の RM64-FSZ の通知や新たなアナウンスも合わせてご確認ください。本記事でも追加情報があり次第、順次追記いたします。
この件名のメールは、 Azure クラシック リソースの廃止に伴い、2024/8/31 に Azure の「従来の管理者ロール」が廃止され、 RBAC への移行が必要となる点についてご案内しています。また、 4/3 以降は Azure ポータルから新たに共同管理者(廃止予定のロール)を追加することができなくなる点を追加でご案内しています。
今回の通知内容(従来の管理者の廃止)に関して、お客様側に確認いただきたい点は「共同管理者やサービス管理者など、従来の管理者を利用しているユーザーがいるかどうか」という点です。RBAC のアクセス制御画面より、「従来の管理者」タブを確認することで、現時点で従来の管理者ロールを保有しているユーザー一覧が表示されますので、まずは下記画面にて登録状況をご確認くださいませ。
なお、もしこちらの画面にサービス管理者や共同管理者を持つユーザーが表示されている場合、 8/31 以降は利用ができなくなります。サービス管理者や共同管理者は、 Azure RBAC の「所有者」と同等のアクセス権を保有していますので、もし従来の管理者を利用している場合には、 8/31 の期日より前に余裕をもって適切なユーザーに RBAC の所有者割り当てを追加してください。RBAC 割り当て手順につきましては、公開情報 にてご案内しておりますので、併せてご確認ください。
Q. 「従来の管理者」とは何ですか?
A. こちら に記載されている、アカウント管理者・サービス管理者・共同管理者の 3 つです。後述のクラシック リソースを管理するために使われていたロールです。アカウント管理者とサービス管理者は、アカウントごと・サブスクリプションごとに 1 人登録されており、サブスクリプションのプロパティ画面から確認できます。
Q. 今回廃止対象となるロールはどれですか?
A. サービス管理者と共同管理者については、通知内にて RBAC へ移行するよう案内されておりますため、この 2 つのロールについては対処が必要です。
Q. 4/3 以降共同管理者を追加できなくなるとは具体的にどういうことですか?
A. 共同管理者は、サブスクリプションごとに最大 200 名まで追加することができます。このため、RBAC の追加と同様に、「共同管理者の追加」ボタンから追加することができますが、廃止に先立ち、4/3 以降はこの画面から割り当てを追加することができなくなります。
Q. 公開情報 には共同管理者に関する記載のみのように見えますが、サービス管理者についても対応が必要ですか?
A. はい、本通知では、サービス管理者についても RBAC への移行が必要です。廃止後もサブスクリプションへのアクセスができるよう、共同管理者と同様に「RBAC の所有者ロールを追加する」操作を実施してください。
Q. 共同管理者については削除すればよいと分かりましたが、サービス管理者も削除する必要はありますか?
A. サービス管理者単体では、8/31 以降サブスクリプションの管理ができなくなるため、上記の通り「RBAC の所有者ロールを割り当てる」操作を実施してください。削除については任意ですが、必要に応じて共同管理者と同様に削除することをご検討ください。
なお、共同管理者と同様に削除可能な動作を確認していますので、技術的にサービス管理者の削除は可能ですが、サブスクリプションが孤立(誰も操作できなくなる)状態にならないよう、すべての操作が可能な所有者ロールを持つユーザーがいる状態で適宜サービス管理者の削除を実施ください。手順の詳細は こちらの公開情報 も併せてご確認ください。
Q. サービス管理者と共同管理者はどこから削除できますか?
A. Azure サブスクリプションの [アクセス制御(IAM)] (RBAC を付与するときの画面)を開き、「従来の管理者」タブから確認できます。ユーザーが表示されている場合は、削除したいユーザーにチェックを入れて画面上部の「削除」をクリックします。
Q. サービス管理者を削除したら、プロパティ画面で「サービス管理者:利用できません」と表示されるようになりました。また、「従来の管理者」メニューにも表示されなくなりました。しかし、確認したところまだクラシック リソースを管理する必要があったので元に戻したいです。どうしたらいいですか?
A. アカウント管理者に登録されているユーザーであれば、 4/3 まではサービス管理者を指定することができます。アカウント管理者でサインインのうえ、下記「サービス管理者の変更」ボタンからサービス管理者を再度指定してください。 4/3 以降は追加ができないため、ご注意ください。
Q. 所有者ロールは特権が高いので割り当てたくありません。どうすればいいですか。
A. サブスクリプションに誰もアクセスできなくなってしまうことを防ぐため、すべての操作が可能な所有者ロールを数名割り当てることを強くお勧めします。それ以外のユーザーについては、必ずしも所有者ロールでなくても、ユーザーに実施させたい操作を元に必要なロールを割り当てれば問題ありません。
念のため、ロールを変更した後ユーザーが操作したい内容が問題なく実行できるか事前に確認のうえで RBAC への切り替えをご実施ください。詳細はこちらの公開情報 も併せてご確認ください。
]]>2024 年 1 月 10 日に、メッセージ センターにて [MC705680] として以下の情報公開が行われています。
Note
2024 年 3 月 3 日に When will this happen: の説明が更新されました。当初は 2 月 15 日にクラウド側の変更が行われる予定でしたが、ご利用者様のクライアントへの修正適用の準備期間を踏まえて、変更予定を延長していました。3 月 3 日の週からクラウド側の展開を開始し、4 月末までにはすべてのお客様のテナントに展開が完了する予定です。
Action required: Security hardening of Windows Hello authentication with July 2023 Windows updates
[Updated March 3, 2024]: Starting this week, the change described in this article will begin a gradual roll out. It will reach all customers by end of April.Windows updates released on July 11, 2023 introduced a phased approach to address a vulnerability in the Microsoft Entra ID Windows Hello authentication stack CVE-2023-36871 that could enable an attacker to create long lived authentication artifact from a low privileged process on Entra ID joined machines. This would enable the attacker to move the artifact indefinitely onto other Entra ID joined machines.
To address this vulnerability, Microsoft has introduced protections starting with the July 11, 2023 security updates. We strongly recommend that you update your organization’s devices immediately with Windows updates release in July 2023 or later.
Microsoft plans to fully address this CVE by not accepting Windows Hello authentication requests from machines running Windows security updates released in June 2023 or before. This security hardening will start February 15th, 2024 and will affect authentication/Single Sign On (SSO) on Windows devices that have not been updated with updates released in July 2023 or later.[When will this happen:]
This security hardening will start on February 15th, 2024.
Server-side changes for this security hardening are beginning to roll out starting with the week of March 3, 2024. The new measure is expected to affect 10% of customers by the end of the first week of March, and should reach all customers by the end of April.This security hardening was originally scheduled to start on February, 2024, but was postponed to allow more time for organizations to install the necessary updates for this change.
[How this will affect your organization:]
This security hardening will impact Windows Hello authentication/Single Sign On (SSO).[What you need to do to prepare:]
We strongly recommend that you update immediately your organization’s devices with Windows security updates release in July 2023 or later. Your organization will be at risk of business disruption, and IT administrators are encouraged to take action and install the necessary updates as soon as possible.[Additional information:]
If you have Active Directory Federation Services (ADFS) in your environment, please see CVE-2023-36871 - Security Update Guide - Microsoft - Azure Active Directory Security Feature Bypass Vulnerability to protect your on premises/Enterprise authentication scenarios as well.
要約すると以下の主旨となります。
おそらく多くの方がすでに 2023 年 7 月の月例修正を適用済みの環境でご利用いただいているものと思いますが、この修正を適用済みの場合すでにリスクは解消されており、それ以上クライアントにて何らかの対処を行う必要はないのでご安心ください。メッセージ センターの通知文章より不安を感じられた方もいらっしゃるかもしれませんが、QA 形式で詳細をおまとめいたしますので、不安の解消の一助となりましたら幸いです。
Q. MC705680 の通知内容の動作変化が生じるのはいつからでしょうか。
A. 2024 年 3 月 3 日から展開が開始され 4 月末にかけてすべてのテナントで展開が行われます。
Q. 詳細な動作変更対象の前提情報を教えてください。
A. Microsoft Entra 参加 (旧名 Azure AD Join) もしくは Microsoft Entra ハイブリッド参加 (旧名 Hybrid Azure AD Join) 構成の Windows 10 / 11 クライアントにて、Windows Hello for Business (WHfB) を構成しており、Windows に WHfB の方法 (PIN や生体認証) でログオンしている環境が対象です。以下の環境は考慮の対象外となります。
Q. どのような動作変化が生じるでしょうか。
A. 2023 年 7 月 11 日の月例修正が適用されていない場合、Windows ログオン時に WHfB の方法 (PIN や生態認証) でログオンすると [Windows ログオンに伴う PRT (Primary Refresh Token) の取得もしくは更新] が行えなくなります。
なお、Windows へのログオン自体が行えなくなる、ということは無く、ログオンとデスクトップの表示は変わらず行えます (PRT の取得 / 更新が行えなくなる、という影響のみとなります)。
この結果、デスクトップ上で PRT の利用が行えなくなり、PRT を用いた SSO (ブラウザやアプリ利用時に、ユーザー名/パスワードの入力を必要とせずサインインが完了する) が行えなくなり、合わせて以下のような状況が生じる可能性があります。
2023 年 7 月 11 日の月例修正が適用済みの Windows 10 / 11 クライアントでは、上記の動作が生じることなく、これまで通り PRT の取得 / 更新と利用が可能です。
Q. 具体的に適用しておくべき修正を教えてください。
A. 以下の技術情報の [セキュリティ更新プログラム] の項目にて公開しておりますので、ご参照ください。
Azure Active Directory のセキュリティ機能のバイパスの脆弱性
※ [よく寄せられる質問] の項目には “7 月 12 日以降にリリースされた Windows 更新プログラム” と記載がありますが、[セキュリティ更新プログラム] の項目にある対象修正は 7 月 11 日にリリースされており、こちらの修正が本問題を修正した KB となります。
なお、月例修正は累積型であるため、もし [2023 年 7 月の修正は適用していないが、2024 年 1 月の月例修正は適用済みである] 場合、すでに必要な更新は適用済みのクライアントとなり、改めて後から 2023 年 7 月の修正を適用する必要はありません。現在のクライアントの OS バージョン (ファイル名を指定して実行、より winver を実行した画面から確認可能) と、上記技術情報のセキュリティ更新プログラムの一覧を比較し、より新しい OS バージョンとなっている場合は追加で行うべき対処はありません。
Q. 2023 年 7 月の修正が適用されていない状態のまま、本動作変更を避ける方法はありますか。
A. いいえ、セキュリティの脆弱性に対するアップデートであり、セキュリティ修正を適用しない状態のまま (脆弱性のリスクを維持したまま) でこれまでの運用を継続する方法はございません。
なお、本脆弱性は Windows に WHfB でログオンするご利用シナリオが対象となり、Windows にパスワードでログオンするご利用シナリオは考慮の対象外となります。
Q. WHfB は利用していませんが、AD FS サーバーを運用上利用している場合はどうすれば良いのでしょうか。
A. 前述の脆弱性の技術情報の [よく寄せられる質問] の項目にて公開しておりますので、ご参照ください。
上記内容が皆様の参考となりますと幸いです。
]]>Microsoft Azure の各種リソース操作や情報取得を行う方法として、多くのお客様に、各種 PowerShell モジュール (Az PowerShell, Microsoft Graph PowerShell SDK、Azure CLI etc…) をご利用いただいています!
よくある活用例の 1 つとして、自動実行を目的としたスクリプト ファイルの作成が挙げられます。ここで課題となるのが、認証用のコマンドにどのようにして資格情報を渡すかという点です。いずれの PowerShell モジュールも、最初に認証コマンドを実行しアクセス トークンの取得が必要です。例えば Microsoft Graph PowerShell SDK の認証用コマンド “Connect-MgGraph” では、引数無しで実行すると、以下のようにユーザー認証画面が表示されます。しかし自動実行を想定したスクリプトの場合、ユーザーによるサインイン操作が発生することは不都合です。
こんなシナリオの解決策としては、ワークロード ID の活用が最適です!
ワークロード ID は、ソフトウェア (スクリプト、アプリケーション、サービス、スクリプト、コンテナーなど) に割り当てる ID です。ユーザーに払い出す人間用の ID ではなく、システムやソフトウェア用に払い出す ID とお考えください。Microsoft Entra では、ワークロード ID はアプリケーション (サービス プリンシパル) やマネージド ID を表します。
アプリケーション (サービス プリンシパル) オブジェクトは、Azure における「アプリケーションを表すアカウント」のような存在です。アプリケーション (サービス プリンシパル) オブジェクトは、アプリケーションとしての ID (Client ID) に加えて資格情報 (クライアント シークレット文字列、もしくは証明書) を保有でき、これらの資格情報を利用して Microsoft Entra ID に認証します。アプリケーション (サービス プリンシパル) オブジェクトは、Azure に接続できる環境であればどこからでも利用することが可能です。
マネージド ID もアプリケーション (サービス プリンシパル) オブジェクトに非常に似ていますが、「”Azure リソース専用” のアプリケーション アカウント」とお考えください。アプリケーション (サービス プリンシパル) オブジェクトとの大きな差異としては以下の 2 点が挙げられます。
マネージド ID では、Azure 内部のエンドポイントで Azure リソースに紐づいた ID として Microsoft Entra ID の認証処理を行います。利用者は、Azure 上のリソース (Azure VM や WebApp など) を作成すれば、この ID をすぐに利用でき、資格情報の管理 (有効期限に応じた更新、資格情報漏洩の対策など) が不要という大きなメリットがあります。
マネージド ID の利用をサポートする Azure リソースについては、以下の公開情報をご参照ください。
マネージド ID を使用して他のサービスにアクセスできる Azure サービス (learn.microsoft.com)
それでは、実際に PowerShell スクリプトを実装する際には、以下のうちどの認証方法を選べばいいのでしょうか?
マネージド ID が利用可能なシナリオ (= コマンド実行元がマネージド ID に対応した Azure リソース) である場合は、マネージド ID のご利用が最もおすすめです。
上述のとおり、マネージド ID では資格情報の管理が不要という大きなメリットがあります。そして、管理者側で予めマネージド ID を有効化した Azure リソース上でのみ認証が可能であるため、外部のシステムによる ID の不正利用ができないというセキュリティ面での利点もあります。
マネージド ID が利用できないシナリオでは、次点でアプリケーション (サービス プリンシパル) の資格情報として証明書を利用することがおすすめです。証明書の利用が難しい場合には、クライアント シークレットを利用した方法を検討します。クライアント シークレットを利用する場合、資格情報の取り扱いに十分ご注意ください。マネージド ID ではなくアプリケーション (サービス プリンシパル) を利用する場合、必要に応じて、後述の「ワークロード ID 用の条件付きアクセス」もぜひご活用ください。
以下ではまず、もっともお勧めするマネージド ID を利用した方法についてお知らせします。続いて、アプリケーション (サービス プリンシパル) を利用した認証方法についてもおまとめします。
ここでは以下のシナリオを、一例として紹介します。
Azure VM はマネージド ID に対応した Azure リソースです。かつ、Connect-MgGraph コマンドもマネージド ID に対応しています。そのため、Azure VM 上で Microsoft Graph PowerShell SDK を利用するシナリオではマネージド ID を利用した認証が可能です。マネージド ID には「システム割り当て マネージド ID」と「ユーザー割り当て マネージド ID」の 2 種類がありますが、ここでは「システム割り当て マネージド ID」の利用例を紹介します。これら二つの違いについては、Azure リソースのマネージド ID とは (learn.microsoft.com) の公開情報をご参照ください。
まずは、PowerShell コマンド実行元の Azure VM で「システム割り当て マネージド ID」を有効化します。
「システム割り当て マネージド ID」を有効化した Azure VM 上で、PowrShell を起動し、以下のようにコマンドを実行します。コマンドの引数である -Identity
がマネージド ID を利用するという意味のオプションです。
Connect-MgGraph -Identity |
認証に成功すると、”Welcome To Microsoft Graph!” のメッセージが表示されます。サインインの詳細は、Microsoft Entra ID のサインイン ログから確認できます。特に資格情報を渡さずとも認証が完了しますので、あっという間の出来事ですが、マネージド ID を利用して安全に認証が完了していますのでご安心ください。
この場合は以下のようなシナリオが該当します。
まずは Microsoft Entra ID にアプリケーション (サービス プリンシパル) を新規作成します。
Azure ポータル もしくは Microsoft Entra 管理センター にアクセスします。
以下の画面に進みます。
[+ 新規登録] からアプリを新規登録します。
登録されたアプリの [概要] 欄から、下記の 2 つの項目を控えます。
アプリケーション (サービス プリンシパル) の証明書認証では、証明書に含まれる非対称キー (秘密鍵/公開鍵) ベースの認証処理を行います。証明書は証明機関 (CA) 等で発行することがおすすめですが、自己署名証明書の利用も可能です。証明書の Subject 名などはどのようなものでも構いません。
証明機関 (CA) で証明書のファイル (秘密鍵あり / 秘密鍵なし) を取得ください。Windows 端末上で自己署名証明書を発行する場合の例については、自己署名公開証明書を作成してアプリケーションを認証する (learn.microsoft.com) の公開情報をご参照ください。PowerShell を実行する Windows 端末で、[個人 (/My)] の証明書ストアに秘密鍵を含む証明書をインポートします。証明書の拇印をお手元にお控えください。
Microsoft Entra ID では、以下の手順で秘密鍵を含まない証明書をアップロードします。
証明書を使って、Connect-MgGraph を実行します。上の手順で控えたアプリケーション (クライアント) ID とディレクトリ (テナント) ID、証明書の拇印をここで使用します。
Connect-MgGraph -ClientId "クライアント ID" -TenantId "テナント ID" -CertificateThumbprint "証明書の拇印" |
認証に成功すると、”Welcome To Microsoft Graph!” のメッセージが表示されます。サインインの詳細は、Microsoft Entra ID のサインイン ログから確認できます。この例では証明書の拇印を指定しまましたが、モジュールやコマンドによっては証明書の指定方法が異なる場合もあります。
何らかの理由で、証明書の利用ができない場合は、クライアント シークレットを用いた認証も可能です。この場合、Key Vault など別の仕組みを用いて極力クライアント シークレットをアプリケーション内に埋め込まないようにすることをお勧めします。できる限り、上記のマネージド ID か証明書を用いた方法をご選択ください。
クライアント シークレット文字列を新規作成します。
[アプリの登録] から該当のサービス プリンシパルを選択し、[証明書とシークレット] を開きます。
[クライアント シークレット] タブを開き [+ 新しいクライアント シークレット] を選択します。
任意の説明 (空欄でも構いません) を入力、有効期限を指定のうえ [+ 追加] を押下します。
新しいシークレットが発行されます。[値] の項目に表示される文字列が、クライアント シークレットの値です。この文字列をコピーして控えます。
Note
一度この画面を離れると、シークレット文字列を再表示することはできません。次回以降はマスクされた値のみが表示されるので、ご注意ください。
クライアント シークレットを使って、Connect-MgGraph を実行します。
$Client_Id = "クライアント ID" |
認証に成功すると、”Welcome To Microsoft Graph!” のメッセージが表示されます。サインインの詳細は、Microsoft Entra ID のサインイン ログから確認できます。
アプリケーション (サービス プリンシパル) を利用した認証 (シークレットおよび証明書) のセキュリティ性をより高めたい場合は、ワークロード ID 用の条件付きアクセス (learn.microsoft.com) の活用をおすすめします。”条件付きアクセス” は Microsoft Entra ID の提供するアクセス制御の機能です。アクセス先のリソースや認証時の条件 (IP アドレス、リスクスコア 等) に応じて、アクセスの許可および拒否、条件付き許可 (例: 多要素認証の実行など) を制御することができます。
元々はユーザー認証のみを対象に提供していた機能ですが、Workload Identities Premium ライセンス (有償) を購入いただくことで、アプリケーション (サービス プリンシパル) の認証も制御可能となります。この機能を「ワークロード ID 用の条件付きアクセス」と呼びます。
※ マネージド ID による認証は対象外です。
ワークロード ID 用の条件付きアクセスでは、「IP アドレス ベースの場所情報」ならびに「リスク スコア」に応じて、アクセスの可否 (許可 or ブロック) を構成できます。設定方法は上記の公開情報をご参照ください。
ヒント
アプリケーション (サービス プリンシパル) による認証を利用する IP アドレス範囲が予め分かっている場合に、その他の IP アドレスからのアクセスをブロックとするポリシーを作成します。これにより、指定した場所以外からのアクセスをブロックでき、不正アクセスのリスクを低減いただけます。
Microsoft Graph PowerShell SDK v2.0 (2023/7/5 以降のリリース) の認証用コマンド “Connect-MgGraph” は、アプリケーション (サービス プリンシパル) とマネージド ID の両方に対応しています。
※ 旧バージョンの場合は利用可能な認証オプションが限られます
Az PowerShell モジュールの認証用コマンド “Connect-AzAccount” は、アプリケーション (サービス プリンシパル) およびマネージド ID の両方に対応しています。
Azure CLI の認証用コマンド “az login” も、アプリケーション (サービス プリンシパル) およびマネージド ID の両方に対応しています。
以上の情報がご参考になりましたら幸いです。
]]>本記事は、2024 年 2 月 20 日に米国の Microsoft Entra Blog で公開された Introducing Microsoft Entra License Utilization Insights を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
現在、80 万を超えるお客様が、エンドユーザーの生産性を向上させながらセキュリティを確保し、絶えず変化する脅威に対応するため Microsoft Entra を利用しています。お客様からは、Entra の使用状況についてより透明性を高めたいという要望を頻繁に頂戴しており、特にライセンスに関する要望が多く寄せられています。本日、Microsoft Entra ライセンス利用ポータルのパブリック プレビューを発表できることを嬉しく思います。この新機能は、Premium 機能の現在の利用状況を把握することで、お客様が Entra ID Premium ライセンスを最適化できるようにするものです。
この投稿では、Entra ID Premium ライセンスを最大限に活用するために、この Entra ID ライセンス利用の概要を説明いたします。
Entra ID ライセンス利用ポータルでは、Entra ID P1 および P2 ライセンスの数と、ライセンスの種類に対応する主要機能の利用状況を確認できます。パブリック プレビューでは条件付きアクセスとリスクベースの条件付きアクセスの使用状況を確認いただけますが、一般提供時には、他の SKU (ライセンス) や対応する機能の使用状況も含まれるように拡張される予定です。この機能により、ライセンス数と、ライセンスで利用できる機能の利用状況をより良く把握できるようになります。また、テナントで発生する可能性のある使用過多の問題 (ライセンス違反) に対処するのにも役立ちます。
ライセンスの使用状況と分析情報のポータルは [使用状況と分析情報] ブレード配下にあります。
このポータルでは、Entra ID Premium P1 および P2 ライセンス (該当する場合) に対応する機能について情報を提示します。これらの知見を活用することで、ユーザーを保護し管理するとともに、ライセンス条項を確実に遵守することができます。以下は、Entra ポータルで表示される機能の使用状況のスクリーンショットです:
Entra の利用状況をよりよく把握できるようこの機能を継続的に改善していく所存です。この新しい機能についてのご意見をぜひお聞かせください。
Shobhit Sahay
]]>本記事は、2024 年 1 月 30 日に米国の Microsoft Entra Blog で公開された Introducing More Granular Certificate-Based Authentication Configuration in Conditional Access を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
条件付きアクセスによる高度な証明書ベース認証 (CBA) の新しいオプションのパブリック プレビューを発表できることを嬉しく思います。このオプションは、証明書の発行者やポリシーのオブジェクト識別子 (OID) のプロパティに基づいて、特定のリソースへのアクセスを許可する機能を提供します。
弊社のお客様、特に厳格に規制された業界や政府機関のお客様は、CBA の設定により柔軟性が必要であると要望されていました。すべての Entra ID 連携アプリケーションに同じ証明書を使用することは、必ずしも十分ではありません。リソースによっては、特定の発行者が発行した証明書によるアクセスが必要な場合もありますし、特定の OID のポリシーに基づくアクセスが必要なリソースもあります。
例として、Contoso という企業では、従業員にスマート カードを使用して 3 種類の多要素証明書を従業員に発行しているとします。これらの証明書は、機密、秘密、トップシークレットのような異なるセキュリティ クリアランス レベルに対応しています。Contoso 社は、適切な多要素証明書を持つユーザーのみが、対応する分類のデータにアクセスできるようにする必要があります。
条件付きアクセスの認証強度の機能により、お客様は証明書発行者や OID のポリシーに基づいてアクセスを許可する高度な CBA オプションを使用して、カスタムの認証強度ポリシーを作成できるようになりました。パートナーの Entra ID テナントから多要素認証 (MFA) が信頼されている外部ユーザーの場合、これらのプロパティに基づいてアクセスを制限することもできます。
これにより、12 月に共有した最新の更新 に加えて、CBA に柔軟性が追加されました。私たちは、すべてのお客様に対してフィッシング耐性のある認証機能をより向上させ、米国政府のお客様が「国家のサイバーセキュリティの向上に関する大統領令 14028」を満たすことができるよう、引き続きサポートしていきます。
この新機能の詳細については、認証強度の詳細オプション をご確認ください。
Alex Weinert
]]>本記事は、2024 年 1 月 19 日に米国の Microsoft Entra (Azure AD) Blog で公開された Microsoft Entra’s Top 50 Features of 2023 の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。
2024 年の幕開けとして、昨年 1 年間に Microsoft Entra で提供された主な機能を振り返りたいと思います。弊社は、マルチクラウドの ID およびネットワーク アクセス製品により、あらゆる種類の ID を検証し、あらゆるリソースへのアクセスを保護、管理、統制するために、何千ものお客様にサービスを提供いたしました。Microsoft Entra の最新の進歩の波は、Security Service Edge (SSE)、人工知能 (AI) にまで広がり、分散型 ID、マルチクラウド、人間以外の ID などの他の重要な分野におけるイノベーションを加速しつつ、100 以上の機能を提供しました。以下に、お客様からのフィードバックや市場のニーズに基づき実現した上位 50 の機能をご紹介します。包括的なリストについては、リリース ノート をご参照ください。これらの最新の ID イノベーションを採用することで、デジタル資産の保護を強化し、セキュリティへの投資からより多くの効果を得ることができます。
ID セキュリティ市場は絶えず発展していますが、これは悪意のあるアクターやハッカーによる脅威やリスク、AI の進歩も同様です。こうした変化に対応するため、組織は ID セキュリティに対して積極的かつ包括的なアプローチを取り、信頼できるベンダーと協力して最適なソリューションを提供する必要があります。2023 年が終わっても、ソリューションに対する需要は依然として高く、弊社からは 2024 年に何を計画しているか今後徐々に明らかにしたいと考えています。
よろしくお願いいたします。
Shobhit Sahay
]]>本記事は、2024 年 1 月 16 日に米国の Microsoft Entra (Azure AD) Blog で公開された Visualize Entra Sign-in Logs using an Interactive Map - Microsoft Community Hub を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
Microsoft Sentinel には、Microsoft および Azure サービス、サードパーティのソースやカスタム ログまで、豊富なデータ コネクタが存在します。このデータは、分析してこそ価値をもたらすものです。プロアクティブおよびリアクティブな調査をしていく中で、さまざまなフォーマットでデータを可視化することで、何らかの異常やパターン、貴重な洞察などを得ることができます。
Microsoft Entra のサインインログのような地理的な関連情報を含むデータを扱う場合、データを最大限に活用するためには、適切なツールを通してデータを視覚化することが重要です。そこで、Sentinel と Log Analytics ワークスペースのインタラクティブ マップが活躍します。このブログ記事の執筆時点では、Sentinel や Log Analytics ワークスペースの Logs セクションで直接インタラクティブ マップを使用することはできません。代わりに、Azure Data Explorer のウェブ アプリまたは Kusto Explorerデスクトップ アプリ を使用する必要があります。この記事では、すべての例で Azure Data Explorer を使用した方法をご紹介します。必要なセットアップは、数分しかかからず、簡単なものとなっております。
最初のステップでは、Azure Data Explorer ウェブ アプリにアクセスし、画面左上の Add をクリックし、Connection を選択します。
ここで、接続を求めるウィンドウが表示されます。Sentinel のインスタンス (実際は Log Analytics ワークスペース) に接続するためには、以下の情報が必要になります:
これらの情報は、Sentinel のメニューの[Settings]をクリックし、[Workspace settings]をクリックすると表示されます。
[Workspace settings] をクリックすると、以下のように必要な情報が画面に表示されます。これは、Sentinel を使用せずに Log Analytics ワークスペースに接続している場合も同様です。Log Analytics ワークスペースのページに移動すると、以下のページが開きます。
接続 URI は以下のような形式である必要があります。
https://ade.loganalytics.io/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/microsoft.operationalinsights/workspaces/<workspace-name> |
接続 URI を適切な値で書き変えたら、それを Azure Data Explorer に追加します。表示名も入力し、[Add] をクリックします。接続 URI に指定している Log Analytics ワークスペースが、ウィンドウの下部に表示されているテナントの値と一致していることを確認ください。Log Analytics ワークスペースが Azure Data Explorer にサインインしたテナントとは異なるテナントにある場合は、この画面でテナントを切り替えください。
接続が確立すると、左メニューの [Connections] に表示されるようになります。
テーブルをクエリするには、ワークスペースを選択し、Sentinel の Logs の画面で通常行うようにクエリを入力ください。
インタラクティブ マップを使用するには、経度と緯度のデータが必要が必要になります。国名、州名、都市名に基づくマッピングには対応していません。経度と緯度のフォーマットは 10 進数である必要があります。つまり、41.40338 と 2.17403 の組み合わせは機能しますが、41°24’12.2”N と 2°10’26.5”E の形式では機能しません。Sentinel のほとんどのテーブルには、すでに正しいフォーマットの地理データが含まれています。
インタラクティブ マップを生成するには、”scatterchart with (kind=map) “の後に render 演算子を使用する必要があります。地理空間データの可視化に関連する引数についてのドキュメントは こちら です。ルールの 1 つとして、クエリ出力の最初の 2 列は経度と緯度の値でなければなりません。経度と緯度の特定の列は、クエリを実行した後に手動で選択することもできますが、列の順序を適切に設定することで、余分な作業を省略することができます。
各ロケーションから Entra のサインイン数を取得し、インタラクティブ マップ上に可視化させたデータを表示するには以下のクエリを利用ください。
SigninLogs |
インタラクティブ マップは、拡大するなど自由に動かすことができます。オブジェクトをクリックすると、クエリの出力に基づいた値が表示されます。上記のクエリの例では、その場所からのサインイン数が計算されているため、オブジェクトをクリックするとサインイン数が表示されます。
Azure Data Explorer ページでクエリを実行すると、結果の右側にメニューが表示されます。ここでは、クエリの結果を可視化する際の設定を変更することができます。
円のサイズをサインイン数 (またはクエリ出力に存在する可能性のある他の数値) に比例させるように設定することも可能です。これを行うには、Size のセクションで、まず非表示のトグルを切り替えてサイズの設定を有効にし、円のサイズを決める列名を選択します。
以下が Size のセクションを設定した例になります。円の大きさが変化したことがお分かりいただけると思います。
地理的なデータを可視化することで、他の方法では得られないような知見を得ることが可能です。Azure Data Explorer で接続をセットアップすれば、Entra ID やサインイン ログなど Sentinel のログを検索してインタラクティブな地図上に可視化が可能になるため、調査がより効果的になります。
ご自身のデータを実効力のある知見に変換する方法や、データの可視化の詳細については こちら をご覧ください。
]]>本記事は、2024 年 1 月 8 日に公開された Easily Manage Privileged Role Assignments in Microsoft Entra ID Using Audit Logs の記事を日本語に分かりやすくおまとめしなおした記事となります。ご不明点などございましたら、お気軽にサポートまでお問い合わせをいただけますと幸いです。
Microsoft Entra ID をご利用いただくなかで、必ずどのお客様も利用いただくのが「Microsoft Entra ロール (Azure AD ロール)」です。例えば、どのテナントにも「グローバル管理者」ロールを持つユーザーがおり、テナント内のすべての構成に変更を加えることができます。他にも、「ユーザー管理者」ロールや「ヘルプデスク管理者」ロールなど様々なロールが用意されています。
管理者がユーザー A に対して「xx の操作をユーザー A にも実施させたいな」と考えた時には、その操作に対応するロールをユーザー A に付与することで管理権限を委任することができます。既定で用意された組み込みロール以外にも、カスタム ロールを自身で作成してユーザーやグループに割り当てることも可能です。また、不要になったロールを削除したり、適切ではないロールの割り当てを見直して削除したりすることも可能です。
一方で、このように管理権限を委任するときには、最小権限の原則に従い「委任したい操作内容を含む、最小特権のロールを付与する」よう注意を払う必要があります。
特権ロールを持つユーザーに、「本当にそのロール必要です?」と確認すると、ほとんどの場合は「はい、必要です!」と答えると思います。例えば、グローバル管理者ロールを保持しているユーザー A が、他のユーザーのパスワードをリセットする業務を行っている場合、確かにグローバル管理者ロールであればパスワードのリセットが可能なので、ユーザー A はそのロールを取り上げられては困ると主張すると思います。
しかし、パスワードをリセットする業務にグローバル管理者ロールの権限は強すぎます。より低い権限を持つロールが利用できるにもかかわらず、このようにユーザーは無意識のうちに特定のタスクを実行するために高い権限が必要だと考えてしまうのです。例えばこのシナリオの場合、確かにグローバル管理者ロールを使えば他のユーザーのパスワードをリセットできますが、このユーザーが誰のパスワードをリセットする予定なのかをヒアリングし、Microsoft Entra ID の特権を持つロールとアクセス許可 (プレビュー) の表を確認すれば、「ユーザー管理者」や「ヘルプデスク管理者」などより小さい権限を持つロールに置き換えることができるかもしれません。
このように、管理者ロールを持つユーザーの活動が注意深く監視および監査されないと、本来必要でないロールを割り当て続けてしまうことになります。ロール割り当ての定期的なチェックと新しい役割割り当てに関するアラートの発報は、特権ロールの割り当てを追跡し管理するにあたり非常に重要です。
Microsoft Entra ID における特権とは、ディレクトリ上のリソースの管理を何らかの主体に委任し、資格情報や認証/認可のポリシーの変更、制限付きのデータへのアクセスを行えるようにするアクセス許可のことを指します。Microsoft Entra ロールには、それぞれロールごとに、このアクセス許可の内容が定義されています。ロールを割り当てられたユーザーには、このアクセス許可が付与され、様々な管理操作が可能となります。
まずは、割り当てられているロールにどのような管理権限があるのかを確認することが重要です。すべての組み込みロールに定義されている権限は、こちら で確認できます。
また、 Azure ポータル上でロールを検索し、「説明」メニューを開くことでもアクセス許可一覧を確認できます。この方法であれば、カスタム ロールに定義されているアクセス許可も確認できます。
例えば、特権認証管理者ロールと認証管理者ロールは、名前が似ていますが異なるアクセス許可がいくつかあります。特権認証管理者の方が高い権限を持っており、具体的な権限の違いは こちら にて確認できます。
同様のロール間に違いがあるもう 1 つの例は、エンドユーザーの管理を担うロールです。具体的には、パスワードのリセットができるロールや、機密性の高い属性を編集できるロールなどについてです。これらのロールの違いとニュアンスの詳細は、ここ に概説されています。
ユーザーに本当にロールが必要かどうかを判断するには、ユーザーのアクティビティを監視し、業務を遂行できる最小権限のロールを見つけることが重要です。そのためには Entra ID の監査ログをご利用いただけます。Entra ID の監査ログは、Log Analytics ワークスペースに送信するか、Sentinel のインスタンスに連携することができます。管理者アカウントによって実行された各種イベントを取得する方法としては 2 つあります。1 つ目は、Sentinel の IdentityInfo テーブルを使用する方法です。IdentityInfo テーブルは、User and Entity Behavior Analytics(UEBA)を有効にすることで、Sentinel でのみ使用できます。Sentinel で UEBA を使用していおらず、Logs Analytics ワークスペースを参照している場合は、後述の Log Analytics を利用する場合の項目をご確認ください。
Entra ID の監査ログを Microsoft Sentinel に取り込むには、Microsoft Entra ID データコネクタを有効にし、以下のように監査ログの設定にチェックを入れる必要があります。
IdentityInfo テーブルに、UEBA によって収集されたユーザー情報が格納されます。そのため、ユーザーが割り当てられた Entra ID ロールもここに含まれます。これにより、特権ロールが割り当てられたアカウントの一覧を簡単に取得できます。
以下のクエリを実行すると、アカウントが実行したアクティビティと、そのアカウントに割り当てられたロールの一意のリストが得られます:
AuditLogs |
このクエリを使用すると、Entra ID でタスクを実行したすべてのアカウントの結果が返されますので、着目したい特権操作以外の情報も大量に含まれている可能性があります。特定の Entra ID ロールに絞ってフィルタリングするには、以下のクエリを実行します。例として 3 つのロールの結果を出すようにしていますが、追加で複数のロールを含めていただいて構いません。
let PrivilegedRoles = dynamic(["Global Administrator", |
クエリを実行すると、その結果から、Entra ID テナントで実行されたアクティビティと、それらのアカウントにどのようなロールが割り当てられているかがわかります。以下の例では、上 2 つの結果には何の問題もありません。しかし、3 行目を見ると、グローバル管理者ロールを持つユーザーが、サービス プリンシパルを作成したことがわかります。
サービス プリンシパルを作成する場合、グローバル管理者ロールよりも低い権限で実施できます。したがって、このユーザーにはより低い権限のロールを付与すべきです。付与可能なロールを確認するには、Entra ID で特定のタスクを実行するために必要な最も権限の低いロールが記載されている このリスト を確認ください。
Entra ID の監査ログを Log Analytics ワークスペースに取り込むには、こちら の手順を参照ください。
付与されたロールを含むテーブルはないため、クエリにユーザーの一覧を追加してフィルタリングする必要があります。特定の Entra ID ロールが割り当てられているユーザーの一覧を取得するには、いくつかの方法があります。
簡単な方法は、Entra ID にアクセスし、[ロールと管理者] のブレードを選択することです。そこからロールを選択し、ロールが割り当てられた ID をすべてエクスポートしておきます。特権ユーザーの UPN を取得しておくことが重要です。これはユーザーが持つロールと一緒に、これらの UPN をクエリに追加する必要があるためです。クエリ自体にいくつかロールの例を示していいます。ユーザーが複数のロールを持つ場合は、すべてのロールをクエリに追加ください。
datatable(UserPrincipalName:string, Roles:dynamic) [ |
クエリを実行すると、フィルタリングしたユーザーによって Entra ID テナントで実行されたアクティビティ情報が得られます。以下の例では、上 2 つの結果に問題があるということがわかります。どちらもグローバル管理者ロールを持っていますが、これらの操作にはグローバル管理者ロールは必要なく、グローバル管理者以外のロールでも実施できます。したがって、これらのユーザーにはより低い権限のロールを付与しなおすべきです。どのロールを付与できるかは、このリスト を確認し、Entra ID で特定のタスクを実行するために必要な最も権限の低いロールを確認ください。
上記例の 1 行目に関して、このユーザーがそれでもグローバル管理者ロールを必要とする場合、グローバル管理者にはセキュリティ管理者ロールよりも多くの権限が含まれているため、セキュリティ管理者ロールは冗長になります。セキュリティ管理者ロールを外しても問題ありません。
必要のない権限を持つアカウントをそのままにしておくと、攻撃の対象範囲を必要以上に大きくしておくことになります。Entra ID 監査ログを取り込むことで、不要で過剰なロールを持つユーザーを特定し、適切な代替ロールに割り当て直すことが可能です。
]]>弊社サポートでは、”一度 Microsoft Entra ハイブリッド参加を正しく構成完了したにも関わらず [保留中] と表示される” というご申告を頂戴することがあります。この事象については下記公開情報で解説されています。
上記公開情報をより分かりやすくするため、本ブログを用意しました。
まず、本ブログにて取り扱うデバイス状態についてご説明します。デバイス状態を確認することができるコマンド [dsregcmd /status] の結果が、下図のように表記されている状態が対象です。
AzureADJoined : YES
DomainJoined : YES
DeviceAuthStatus : FAILED. Device is either disabled or deleted.
また、Microsoft Entra ID 上では登録済み欄が [保留中] となっている状態を表します。
お客様によっては、前述の登録済み欄が「日付から保留中に変化した」と誤解される方がいます。しかしながら、登録済み欄は、[保留中] から [日付] に変化することはあっても、[日付] から [保留中] に変化することはありません。
では、何故 Microsoft Entra ハイブリッド参加を正しく構成したにもかかわらず、その後上図のようなデバイス状態となるのでしょうか。それは、一度 Microsoft Entra ハイブリッド参加が構成完了したあとに、Microsoft Entra ID 上から対象のデバイス オブジェクトが何らか削除されたからです。Microsoft Entra ID 上から対象のデバイス オブジェクトが削除された後に、再度 Microsoft Entra Connect によってデバイス情報が同期されると、Microsoft Entra ID の視点では “新たにデバイス オブジェクトが同期された” ことになるため、登録済み欄が [保留中] のデバイス オブジェクトが作成されます。そのため、Microsoft Entra ID 上に対象デバイスが新規に作成されますが、実際の対象デバイス上ではすでに Microsoft Entra ハイブリッド参加の構成が完了しているため、参加処理を改めて開始する動作は発生しません。
つまり、デバイス側は自身を参加済みと認識しており、Microsoft Entra ID 側は参加ステップの開始状態 (デバイスからの参加処理待ち) という状態になるため、登録済み欄は [日付] へ変更することなく、[保留中] のまま残り続けます。
本事象に該当するデバイス オブジェクトの削除が発生する主なシナリオには下記の 2 つがあります。
1 つ目のシナリオ: 管理者ロールを持つユーザーが、Azure ポータルやコマンドなどで、Microsoft Entra ID 上から該当デバイスを削除した場合
2 つ目のシナリオ: オンプレミス AD 上で該当のコンピューターアカウントが Microsoft Entra Connect の同期対象外 OU に移動された後に、Microsoft Entra Connect の同期が行われた場合
一度 Microsoft Entra ハイブリッド参加を正しく構成完了したにも関わらず [保留中] と表示される状態になった場合は、対象デバイスの Microsoft Entra ハイブリッド参加の構成を解除し、その後再構成することで解消します。再構成の手順は下記の弊社ブログをご参照ください。
Microsoft Entra ハイブリッド参加を再構成する (簡易版)
以上、”一度 Microsoft Entra ハイブリッド参加を正しく構成完了したにも関わらず [保留中] と表示される” 事象について解説いたしました。上記内容が皆様の参考となりますと幸いです。ご不明な点等がありましたら、ぜひ弊社サポート サービスをご利用ください。
]]>この記事は、MSOnline / AzureAD モジュール廃止について、1. 概要編、2. 移行導入編、3. インストール・接続編 の続きとして連載しています。4. ではユーザーに関する操作 を、 5. ではグループに関する操作 についておまとめしましたので、今回の 6. では、Microsoft Entra (Azure AD) ロールの管理について情報をまとめました。
まだ Microsoft Graph PowerShell SDK モジュールをインストールしていない場合や、Connect-MgGraph コマンドを使用した接続方法が分からない場合などは、本シリーズの 2. と 3. をご確認ください。
なお、下記にはいくつか簡易的なスクリプトの案内などもございますが、こちらのカスタマイズに関するお問い合わせは承っておりません。あくまでもサンプルとなりますので参考として利用いただき、カスタマイズにつきましてはお客様自身で実施くださいますようお願い申し上げます。
ロールの管理については、Microsoft Entra Premium P2 もしくは Microsoft Entra ID Governance ライセンスをお持ちかどうかで、推奨される Graph API が変わります。この記事をご覧になる前に、まずは Azure ポータルにサインインし、Microsoft Entra ID を開いた下記画面の表示をご確認ください。
上記画面の表示内容によって、下記のように本記事をご利用ください。ライセンスによって推奨する項目が違う理由は、Microsoft Entra ID P2 以上をお持ちの場合、PIM の機能を活用できるためです。P2 ライセンスをお持ちでも Free や P1 ライセンスで提供されている API を利用することは可能ですが、これらの API では PIM で提供される「資格のある割り当て」および「期限付きの割り当て」といった情報を取得できません。このため、P2 ライセンスをお持ちのお客様には、機能をフル活用するために PIM 用の API を利用したロール管理をお勧めします。
表示されているライセンス名 | 確認いただきたい本記事の章と関連する Graph API ドキュメントへのリンク |
---|---|
Microsoft Entra ID Free | ロール管理用 API を利用したロール管理 |
Microsoft Entra ID P1 | ロール管理用 API を利用したロール管理 |
Microsoft Entra ID P2 | PIM 用 API を利用したロール管理 |
以下に、よくあるロール管理コマンドについて紹介いたします。API の詳細について確認されたい場合は、 roleManagement リソースの種類 - Microsoft Graph v1.0 の公開情報の配下に、各 API の詳細について記載がありますのでそちらをご覧ください。
Get-MgRoleManagementDirectoryRoleDefinition コマンドを実行することで、ロール定義の表示名、 ID、テンプレート ID (roledefinitionid)、説明などが表示されます。このコマンドで取得できる TemplateID はどのテナントも同じ共通した値となります。ただし、カスタム ロールはそのテナントに固有のロールとなりますため、ID やテンプレート ID は各テナントで独自の値となります。
以下のコマンドを利用すると、グローバル管理者 (テンプレート ID: 62e90394-69f5-4237-9190-012177145e10) ロールを持つユーザーを一覧することができます。この 62e9 から始まる ID が、グローバル管理者ロールを示しています。この 62e9 から始まる ID は、どのテナントでも共通するテンプレート ID です。そのため、下記コマンドをそのまま実行すれば、下記のようにグローバル管理者ロールを持っているユーザーを取得可能です。
Get-MgRoleManagementDirectoryRoleAssignment -All -Filter "roleDefinitionId eq '62e90394-69f5-4237-9190-012177145e10'" -ExpandProperty "principal" |
なお、この例の場合、PrincipalID にユーザーの ObjectID が表示されておりますが、一見誰にロールが割り当てられているかが分かりにくいと思います。上記コマンドでは ExpandProperty オプションを利用して、 principal の中身 (ロールが割り当てられているユーザーなどの情報が格納されている) を取得していますので、中身を展開するようにコマンドを記載すれば、オブジェクト ID ではない値を表示することが可能です。例えば以下では、グローバル管理者ロールを持つユーザーの UserPrincipalName のみ取得するようなコマンドにしています。
(Get-MgRoleManagementDirectoryRoleAssignment -Filter "roleDefinitionId eq '62e90394-69f5-4237-9190-012177145e10'" -All -ExpandProperty "principal").principal.additionalproperties.userPrincipalName |
上記を実行すると、以下のような結果が返され、誰にロールがあるのかすぐに判断いただけます。
以下のように実行することで何かしらのロールを持っているユーザーを取得できます。まずすべてのロール割り当てを取得し、上記例と同様に UPN のみを取得します。パイプ(|)の左側だけですと、1 人のユーザーが 2 つ以上のロールを保持している場合に、同じ UPN が 2 回以上結果に含まれてしまいます。そのため、Sort-Object にてUPN 一覧を並び替え、重複を排除するために Get-Unique を利用しています。
(Get-MgRoleManagementDirectoryRoleAssignment -All -ExpandProperty Principal).principal.additionalproperties.userPrincipalName | Sort-Object | Get-Unique |
まずはカスタム ロール一覧から、特定のカスタム ロールの ID 取得します。その後、2-1 と同様に ID を指定して実行します。
Get-MgRoleManagementDirectoryRoleDefinition | where {$_.isBuiltIn -eq $false} |
もし、特定のカスタム ロールではなく、カスタム ロールのいずれかを持っているユーザーを一括して抽出したい場合は、下記が便利です。
foreach($a in $customrole){(Get-MgRoleManagementDirectoryRoleAssignment -ExpandProperty "principal" -All | where {$_.roleDefinitionId -eq $a}).principal.additionalproperties.userPrincipalName} |
2-2 のコマンドと似ていますが、違いは「ゲスト ユーザーのみ」に絞り込む点です。2-2 のコマンドを実行すると、何かしらのロールを保持しているユーザーの UPN 一覧を取得できます。ゲスト ユーザーの場合、UPN には #EXT# という値が含まれる特徴があるので、こちらをキーワードにゲスト ユーザーを抽出します。
(Get-MgRoleManagementDirectoryRoleAssignment -All -ExpandProperty Principal).principal.additionalproperties.userPrincipalName | Sort-Object | Get-Unique | where-object {$_ -like "*#EXT#*"} |
PrincipalID に取得したいユーザーの ObjectID を指定します。 Roledefinitionid には、付与したいロールのテンプレート ID を指定します。
$params = @{ |
上記 2-1 のように、Get-MgRoleManagementDirectoryRoleAssignment コマンドを取得して、削除したいロール割り当ての ID を取得します。この ID はテナントごと、割り当てごとに異なるため、事前に割り当て一覧を取得して ID を確認する必要があります。
そのうえで、下記のようにコマンドを実行し、ロールの割り当てを削除します。
Remove-MgRoleManagementDirectoryRoleAssignment -UnifiedRoleAssignmentId oz6hWDLGrkae4JwNQ81_Peq74fvkTYBMiWoJNnv0Wyk-1 |
roleDefinitions を作成する - Microsoft Graph v1.0 の手順を用いて、ロールの定義を作成します。カスタム ロールの名前を displayName、説明を description に記載し、実際に許可したいアクセス権を rolePermissions 内に記載します。
$params = @{ |
上記コマンドを利用したサンプル スクリプトを以下に案内します。改めまして、スクリプトの代理作成やカスタマイズ、スクリプト自体のデバッグなどの支援は弊社サポートでは承っておりませんので、あらかじめご了承ください。下記のようなお問い合わせであればご支援可能ですので、その際は事前に切り分けや動作確認などを実施のうえ、一問一答形式にてお問い合わせを発行ください。
Graph PowerShell コマンドで取得した内容を CSV に出力させたいというご要望がよくございますので、今回は結果を CSV に出力するサンプルを以下に紹介いたします。以下ではオブジェクトに対するロール割り当てを取得し、割り当てられているオブジェクトの表示名、ID、ロールの名前を CSV に出力します。また、後半部分では、下記公開情報にて案内のある「特権としてみなされるロールに対し割り当てを持っているユーザーについて、その数を確認し、多すぎる場合には削減する」旨の推奨メッセージを出しています。
Microsoft Entra ID の特権を持つロールとアクセス許可 (プレビュー) - Microsoft Entra ID
# 全特権ロールの割り当て一覧を取得して、ロール名と併せて CSV に出力する。 |
CSV 結果
表示メッセージの例
User Administrator の管理者数が多すぎます。推奨は 10 人以下(グローバル管理者は 5 人以下)です。現在の数は 11 です。先に出力した CSV を利用して、ロールが割り当てられているユーザーを確認し、削減を検討してください。
PIM を利用したよくあるロール管理コマンドについて以下に紹介いたします。API の詳細について確認されたい場合は、特権 ID 管理 (PIM) API を使用してMicrosoft Entraロールの割り当てを管理する - Microsoft Graph v1.0 の公開情報の配下に、各 API の詳細について記載がありますのでそちらをご覧ください。
アクティブな割り当て (Active Assignments) に関する操作と、資格のある割り当て (Eligible Assignments) で API やコマンドが異なるため、コマンドを探す際にはまず、「今操作したい割り当ての種類はどちらか?」を明確にして、該当する情報を探していくようにすると便利です。
資格のある割り当てとアクティブな割り当てでコマンドが異なるため、2 つコマンドを実行する必要がありますが、下記にて取得可能です。
# 資格のある割り当てを持っているグローバル管理者を取得する。 |
# アクティブな割り当てを持っているグローバル管理者を取得する。 |
1-1 に記載されているコマンドを活用して取得できます。1-1 のコマンドでは -filter オプションの後ろで「グローバル管理者のテンプレート ID を持っている」という条件を記載しておりましたので、この部分を削除すれば何かしらのロールを持っているユーザーを全員取得できます。見やすいようにロールの名前とユーザーの UPN を取得するような構成にしました。
アプリケーションにロールを割り当てている場合、アクティブな割り当てを取得するコマンドを利用すると UPN 部分が空白として表示されます (アプリケーションは UPN を持たないため)。userPrincipalName の代わりに displayName を使用すると、アプリおよびユーザーともに表示名があるため空白なく情報を取得することができます。
# 何かしらの資格のある割り当てを持っているユーザーを取得する。 |
# 何かしらのアクティブな割り当てを持っているユーザーを取得する。 |
何らかの資格のある割り当てをもっているユーザー一覧のみ取得したい場合は、下記を利用できます。
$user = (Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance -All -ExpandProperty Principal).Principal.AdditionalProperties.userPrincipalName |
EndDatetime に指定されている日付をベースに、もうすぐ割り当てが終了を迎えるユーザーとロールの情報を取得することができます。資格のある割り当てとアクティブな割り当てでコマンドが異なりますが、実行方法は同じです。
# 資格のある割り当て |
# アクティブな割り当て |
以下のように実行して割り当てます。PrincipalID には割り当てるユーザーなどの ObjectID を指定し、割り当てたいロールのテンプレート ID を roleDefinitionId に指定します。期限付きにしたい場合は、expiration 内の enddatetime に終了したい日付を記載します。
$params = @{ |
以下のように実行して割り当てることができます。PrincipalID には割り当てるユーザーなどの ObjectID を指定し、割り当てたいロールのテンプレート ID を roleDefinitionId に指定します。期限付きにしたい場合は、expiration 内 enddatetime に終了したい日付を記載します。
$params = @{ |
下記公開情報の例 5. に記載のように PowerShell コマンドを実行すればユーザーが自身でロールのアクティブ化を行うことが可能です。
Microsoft Graph で Privileged Identity Management (PIM) API を使用して Azure AD ロールを割り当てる
下記 principalID にはアクティブ化を行うユーザー自身の ID を指定し、roleDefinitionID には、アクティブ化するロールのテンプレート ID を指定ください。また、理由については justification の項目を利用いただけます。
Connect-MgGraph -Scopes RoleAssignmentSchedule.ReadWrite.Directory |
下記のように実行することで、アクティブ化要求を PowerShell から承認することが可能です。reviewResult にて Approve と記載し、justification には承認する理由を記載してコマンドを実行してください。
なお、このコマンドは beta バージョンのコマンドが利用されておりますので、予告なくコマンドの動作に変更が加わることがございます。運用環境での利用は推奨しておりませんが、利用の際はご留意ください。
Connect-MgGraph -Scope RoleAssignmentSchedule.ReadWrite.Directory,PrivilegedAccess.ReadWrite.AzureAD |
上記コマンドを利用したサンプル スクリプトを以下に案内いたします。改めまして恐れ入りますが、スクリプトの代理作成やカスタマイズ、スクリプト自体のデバッグなどの支援は弊社サポートでは承っておりませんのでご了承ください。今回は、PIM に関するお問い合わせでよくご質問をいただく、Entra ロールと Azure ロールの PIM 設定を一括で変更するスクリプトをそれぞれ記載します。
割り当ての最大期間は「資格のある割り当て」が 1 年、「アクティブな割り当て」が半年になっていますが、以下の例ではこれらを 2 年にするよう全ロールのポリシーを一括で更新します。ポータル上では 2 年の表示がされないため、下記のように - になりますが正しく動作します。
# Azure AD に接続する。 |
下記ハイライト部分をすべて “いいえ” にするスクリプトです。
# サブスクリプション ID とテナント ID を指定する。 |
本記事は、2023 年 12 月 14 日に米国の Azure Active Directory Identity Blog で公開された Introducing New Features of Microsoft Entra Permissions Management - Microsoft Community Hub を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
Microsoft Entra Permissions Management は、組織のマルチクラウド基盤におけるあらゆる ID の権限管理を支援する Cloud Infrastructure Entitlement Management (CIEM) ソリューションです。Permissions Management を使用することで、ID とその権限を継続的に評価、管理、監視し、過去のアクティビティに基づいてアクセス許可の範囲を適切に管理することができます。
本日、Ignite での発表について詳細をお知らせすると共に、Permissions Management の新機能と API を紹介いたします。全体的な権限管理のエクスペリエンスにつながればうれしく思います。
ユーザーは、ServiceNow ポータルからマルチ クラウド環境 (Microsoft Azure、Amazon Web Services (AWS)、Google Cloud Platform (GCP)) に対して、期限付きのオンデマンドのアクセス許可を要求できるようになりました。この統合により、ServiceNow の既存の承認ワークフローにアクセス許可の要求が追加され、組織のゼロ トラスト体制を強化することができ、マルチ クラウド環境で最小特権の原則を実施することが可能になります。詳細については、こちら をご覧ください。
当社は、クラウド ネイティブ アプリケーション保護プログラム (CNAPP) の取り組みを強化しており、そのために Microsoft Defender for Cloud を通じて基本的な権限管理に関する情報を提供しています。この統合により、クラウド環境における過剰なアクセス許可や設定ミスにより発生する可能性のあるセキュリティ侵害が防止されます。これにより、組織はクラウド リソースに最小特権の原則を導入すると共に、Azure、AWS、GCP 全体でアクセス許可に関するリスクを解決するための推奨事項を得ることが可能となります。詳細については、こちら をご覧ください。
Permissions Management をご利用のお客様は、Okta および AWS IAM Identity Center 上の ID を検出できるようになりました。これにより、お客様は、使用している ID プロバイダーやソリューションに関係なく、すべての ID とそのアクセス許可を一元的に把握できるようになります。お客様はけ数回クリックで Okta と AWS IAM Identity Center を構成いただけます。
このレポートでは、Permissions Management における ID とリソース全体の詳細を一覧で確認できます。このレポートは、Permissions Management ページで直接表示するか、Excel 形式でダウンロードするか、PDF としてエクスポートすることも可能です。当該レポートは Microsoft Azure、AWS、GCP を含むサポートされているすべてのクラウド環境で利用可能です。 詳しくはこちら をご覧ください。
パブリック プレビューとして複数の Microsoft Graph API が Permissions Management に導入され、お客様からのフィードバックに基づく主要なユースケースに対応しました。これらの新しい API により、組織は、オンボード済みの AWS アカウント、Azure サブスクリプション、および GCP プロジェクトの情報を棚卸でき、アクセス許可に関する分析情報を SIEM ツールのダッシュボードに組み込んだり、既存のチケット管理システムでアクセスのレビューを行ったりできるようになります。さらに、Permission on Demand API を用いることで、自動化ソリューションや IT サービス管理 (ITSM) ソリューションとの統合により、必要に応じてユーザー ID またはワークロード ID の権限を柔軟に昇格させることが可能となります。詳細については、こちら をご覧ください。
いつものように、皆様のご意見、ご感想、ご提案をお待ちしております!Microsoft Entra (Azure AD) フォーラム で共有するか、以下にコメントを残してください。皆様のご意見をお待ちしております。
Joseph Dadzie, Partner Director of Product Management
Linkedin: @joedadzie
Twitter: @joe_dadzie
本記事は、2023 年 12 月 15 日に米国の Azure Active Directory Identity Blog で公開された Advancing Cybersecurity: The Latest enhancement in Phishing-Resistant Authentication - Microsoft Community Hub を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
本日は、フィッシング耐性のある認証に向けた、いくつかの新たな機能強化をご紹介したいと思います!この機能強化は、国家のサイバー セキュリティの改善に関する大統領令 14028 (Executive Order on Improving the Nation’s Cybersecurity | The White House) に準拠するために不可欠であるだけでなく、デジタル ID を利用するすべての組織とユーザーの安全を確保するうえでますます重要となっています。
全文を読むお時間のない方は以下のまとめをどうぞ。
詳細は以下をご覧ください!
Ignite 2023 で発表 (Identity at Microsoft Ignite: Securing access in the era of AI - Microsoft Community Hub) されたように、2024 年前半には、Microsoft Entra ID のユーザーは、デバイスに紐づくパスキーを Microsoft Authenticator アプリを用いて登録して、サインインに利用できるようになります。これは、費用対効果が高く、フィッシングに強い資格情報で、Authenticator アプリがあれば誰でも利用できる仕組みです!パスキーは FIDO 標準に関連した最新のセキュリティ機能であり、Authenticator との統合により、Authenticator が提供する革新的なセキュリティ機能や高度な機能を活用することができます。
Microsoft Authenticator をさらに強化し、コンプライアンス要件を満たすために、Android 上の Authenticator アプリが FIPS-140 に準拠しました。
Microsoft Authenticator for Android は、バージョン 6.2310.7174 以降、デバイスに紐づくフィッシング耐性のあるパスキー、プッシュ型多要素認証 (MFA)、パスワードレス電話サインイン (PSI)、時間ベースのワンタイム パスコード (TOTP) を使用するすべての Microsoft Entra 認証において、連邦情報処理標準 (FIPS 140-3) に準拠しています。Intune Company Portal を使用している組織の場合は、FIPS 準拠のため、最新バージョンの Authenticator に加えて、Intune Company Portal のバージョン 5.0.6043.0 をインストールください。
iOS 向けの Microsoft Authenticator アプリは、2022 年 12 月に発表されたように、すでに FIPS-140 に準拠しています。Microsoft Authenticator アプリの FIPS 140 準拠の詳細については、こちら をご覧ください。
証明書ベース認証 (CBA) の一般提供開始を発表してからこの 1 年間で、米国政府機関のお客様の Entra ID CBA の利用が 850% 以上増加しました。CBA を活用することで、AD FS などのオンプレミス IdP からの移行を図りながら、PIV/CAC を使用して使い慣れたエンドユーザー体験を提供し続けることができ、お客様はゼロ トラストへの対応をより迅速に進めることが可能となります。
弊社ではクラウド ベースの CBA への投資を継続し、直近で証明書やリソースの種類、ユーザー グループごとに認証ポリシーを調整できる機能を追加しました。ユーザごとに証明書の強度を選択したり、多要素認証やステップアップ認証のためにCBA を他の方法と併用したり、さらにはテナント全体またはユーザー グループごとに高いアフィニティで (強い) 証明書バインドを構成したりできるようになりました。
Microsoft Entra 証明書ベース認証の最新の機能強化の詳細については、こちら をご覧ください。
2023 年夏に、iOS と macOS の Web ブラウザにおける FIDO2 認証のサポートを発表 (Advancing Modern Strong Authentication - Microsoft Community Hub) しました。本日、iOS と macOS でのFIDO2 認証のパブリック プレビューを発表できることを嬉しく思います。このリリースにより、iOS に Microsoft Authenticator をインストールしているユーザー、または macOS に Microsoft Intune Company Portal をインストールしているユーザーは、FIDO2 セキュリティ キーを使用して Microsoft アプリケーションにサインインできるようになります。この機能は現在 iOS で利用可能で、macOS では 2024 年初頭に利用可能になる予定です。
FIDO2 の認証は、「開発するアプリで FIDO2 キーによるパスワードレス認証をサポートする」(開発するアプリで FIDO2 キーを使用してパスワードレス認証をサポートする - Microsoft identity platform | Microsoft Learn) に記載されている要件を満たす、iOS および macOS の MSAL 対応サードパーティ製アプリケーションでも利用できます。
対応プラットフォームについてはこちらをご覧ください。
今月初め、Microsoft は Secure Future Initiative (A new world of security: Microsoft’s Secure Future Initiative - Microsoft On the Issues) を発表しました。このイニシアティブの一環として、条件付きアクセス ポリシーの自動展開 (Automatic Conditional Access policies in Microsoft Entra streamline identity protection | Microsoft Security Blog) を開始します。このイニシアティブは Cybersecurity and Infrastructure Security Agency (CISA) が提唱する “Secure by design, Secure by default” というアプローチに沿ったもので、消費者が日々利用するテクノロジーの安全性と完全性を信頼できるものにすることを目的としています。
サイバー セキュリティの課題には社会として取り組む必要があります。弊社は、政府機関、セキュリティ専門家、およびより広範なコミュニティと緊密に協力しtえサイバー脅威に対する対策強化に取り組んでいます。弊社の目標は、政府機関のお客様に、進化するリスクに先手を打つために必要なツールと知識を提供することです。
サイバー セキュリティの強化に向けた当社の最近のリリースと継続的なコミットメントにより、大統領令の遵守に取り組んでいる米国政府のお客様を含め、当社の幅広いお客様をサポートしてまいります。共に、より安全なデジタルの未来を築いていきましょう。
Alex Weinert
]]>本記事は、2024 年 1 月 2 日に米国の Microsoft Entra Blog で公開された Addressing Data Exfiltration: Token Theft Talk を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。
データ流出の防止について前回に引き続きお話ししたいと思います。以前のブログでは、継続的アクセス評価 (CAE) を使用して 認証セッションをセキュリティで保護するための Microsoft のアプローチ をお話し、テナント制限 v2 を使用して テナント間アクセスを安全に行う 方法について解説しました。本日のトピックは、認証アーティファクトの窃取についてです。
認証アーティファクト (トークンおよび Cookie) が窃取されると、攻撃者は被害者になりすまし、被害者がアクセスできるすべての情報にアクセス出来てしまいます。数年前までトークンの窃取はまれな攻撃であり、ほとんどの場合、企業内のレッド チーム (セキュリティの脆弱性を検証する部門) によって訓練的に行われていました。この理由としては、クッキーの窃取よりも、パスワードの窃取の方が容易だったからです。しかしながら、多要素認証 (MFA) の普及に伴い、アーティファクトの盗難やリプレイを含む実際の攻撃が増えてきています。
詳細に入る前に、Token tactics: How to prevent, detect, and respond to cloud token theft に記載されているとおり、Microsoft ではトークンの窃取に対する第一線の防御策として、エンドポイント保護やデバイス管理、フィッシング耐性のある MFA、ウィルス対策ソフトを用いてデバイスを保護することを推奨しています。
では次に、認証アーティファクトの種類と、窃取の影響を最小限に抑えるためにその種類ごとに推奨される対応手法について説明していきます。すべての認証アーティファクトは、大まかに 2 つの種類に分けることができます。
最も強力なデバイス SSO アーティファクトである プライマリ更新トークン (PRT) を保護することが一番重要になります。幸いなことに、PRT はすべての OS 上で窃取に対して防御策がとられています。保護のレベルは OS の機能によって異なりますが、Windows が最も強力な保護機能を有しています。PRT の保護はポリシーで制御できず、常に有効になっています。
すべてのアーティファクトを今後同様に保護していくことは開発上のロードマップにありますが、これらの機能を提供するには数年かかると想定しています。トークンの窃取に対する包括的な保護を実現するためのさまざまな課題については、この RSA のプレゼン資料 をご覧ください。当面のところは、Entra ID のセキュリティ製品を組み合わせて利用することで、トークンの窃取に対応が可能です。
条件付きアクセスのトークン保護ポリシー を用いることで、盗まれたトークンが再利用されないよう暗号技術に基づく仕組みを用いて保護することが可能です。この機能は、PRT に対する既存の保護に上乗せする形で構築されてます。トークン保護ポリシーが有効な場合、保護されていないサインイン セッションの使用はブロックされます。PRT の保護が常に有効となっていることと組み合わせることで、すべての再利用可能なアーティファクトにこのような暗号技術に基づく保護が適用されます。トークンの保護は、Windows 上の Office 製品と Outlook において現在パブリック プレビュー段階です。ご利用の際は、まずレポート専用モードで開始して、組織への影響を評価ください。
トークン保護のスコープにまだ含まれていないクライアント アプリについては、Entra Global Secure Access の 準拠ネットワークのチェック を有効にすることで保護いただけます。このポリシーにより、認証アーティファクトが常に組織のネットワークから送信されていることを保証できます。つまり、盗まれたトークンが組織のネットワークからのみ利用可能となるため、攻撃の影響範囲を大幅に縮小することが可能です。
ネットワーク構成によっては、条件付きアクセス: 場所によるアクセスのブロック機能 および 継続的アクセス評価 (CAE): 場所ポリシーを厳密に適用する機能 を構成することで、窃取されたアクセス トークンとワークロード (アプリ) Cookie の企業ネットワーク外での利用をブロック可能です。この新しい CAE の強制機能は、許可された IP 範囲外からのアクセスをブロックしますので、盗まれたトークンのネットワーク外部からの使用がブロックされ、攻撃の影響範囲が大幅に縮小します。この機能を利用するには、ユーザーは事前に定義した IP アドレスの範囲から Entra ID とワークロードの両方にアクセスする必要があります。Entra Global Secure Access (GSA) ではユーザーのデバイスの IP アドレスを提示することができるため、Entra GSA を介してデータにアクセスする企業ネットワーク ユーザーに対しては、CAE の場所ポリシーを厳密に適用できます。条件付きアクセス (CA) で ネームド ロケーション を構成する場合は、ユーザーが Entra ID とワークロード (SharePoint Online など) の両方にアクセスする IP アドレスの範囲をネームド ロケーションに必ず含めるよう対応ください。
アーティファクトの窃取を検出するには、Microsoft Entra ID Protection のリスク検出機能を利用して、トークンの窃取が懸念される場合にユーザー リスクを上げるするという方法があります。異常なトークン や トークン発行者の異常、および中間者攻撃の検出が行われた場合は、トークン窃取の可能性があります。それぞれの検出はオフラインで評価されますが、”異常なトークン” の検出はサインイン時にリアルタイムに評価して脅威を捉えられもしますので、その場でサインインを侵害済みであるとしてアラートを上げることもできます。これらの検出を最大限に活用するには、リスクベースのアクセス ポリシー を構成して、トークンの窃取が懸念される場合に、ユーザーに適切なポリシー制御が適用されるようにすることをお勧めします。リスクベースのアクセス ポリシーをトークン窃取の検出に対して適用すると、ユーザーには多要素認証が求められ、それが完了するとパスワードのリセットが求められます。必要であれば、管理者がユーザー トークンの取り消しを行うことも可能です。
継続的アクセス評価 をリスクベースのアクセス ポリシーと組み合わせることで、窃取されたアーティファクトを用いたリソース アクセスをブロックすることが可能です。ユーザー リスクが上昇すると、CAE は CAE に対応したすべての対応ワークロードに通知を行い、リスクベースのアクセス ポリシーを直ちに適用します。
トークン窃取の攻撃が増えるにつれ、Microsoft もそのような攻撃に対する防御を常に強化しています。この分野における新しい更新情報を今後もぜひお楽しみにお待ちください。
Anna Barhudarian
Principal Product Manager, Identity Division
本記事は、2023 年 12 月 13 日に米国の Microsoft Entra (Azure AD) Blog で公開された Enhancements to Microsoft Entra certificate-based authentication の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。
Ignite 2022 では、大統領令 14028 「国家のサイバーセキュリティの向上」 に対する Microsoft のコミットメントの一環として、Microsoft Entra 証明書ベース認証 (CBA) の一般提供開始を発表しました。弊社はこれまで政府機関のお客様と協力してまいりましたが、PIV/CAC カードが連邦政府内で使用される最も一般的な認証方法であるという状況です。PIV/CAC カードを使用している連邦政府組織や、大統領令 14028 の要件に準拠したいとお考えのお客様、加えて Active Directory Federated Server のような連携サーバーから Entra ID の CBA に移行したいお客様にとって、直接 Entra ID に対して認証に X.509 証明書を使用できることは非常に重要です。
それ以来、弊社では多くの新機能を追加し、モバイルを含むすべてのプラットフォームで CBA を利用できるようにし、デバイス上の証明書だけでなく、YubiKey のような外部セキュリティ キーもサポートしました。お客様は、証明書やリソースの種類、ユーザーのグループごとに認証ポリシーをカスタマイズしたり、ユーザーごとに証明書の強度を選択したり、多要素認証やステップアップ認証のために CBA を他の方法と併用することも可能です。加えて、テナント全体またはユーザーのグループごとに証明書のバインドを構成したりするなど、より制御性と柔軟性を向上させることができるようになりました。
Microsoft Entra のプロダクト マネージャーである Vimala Ranganathan より、これらの新機能がフィッシングに強い MFA の実現にどのように活用いただけるかについてご説明します。
ぜひ皆様のご感想をお聞かせください!
Alex Weinert
–
皆さんこんにちは、
Microsoft Entra PM チームの Vimala です。CBA の新機能と機能強化について詳しく説明いたします。
CBA のユーザー名のバインド: CBA は、追加で 3 つのユーザー名のバインドをサポートし、オンプレミスの Active Directory と同等の機能を提供するようになりました。追加された 3 つの証明書バインドは以下のとおりです:
ユーザー名のバインド ポリシーは、Entra ID がユーザから提示された証明書を、Entra ID のユーザー アカウントとどのように一致させるかを管理者がカスタマイズできるようにするものです。既定では証明書の Subject Alternative Name (SAN) 属性の Principal Name をユーザー オブジェクトの UserPrincipalName にマッピングします。管理者は既定の設定をオーバーライドしてカスタムのマッピングを作成できます。
詳しくは ユーザー名バインド ポリシーを構成する をご覧ください。
CBA 認証ポリシー ルール: このルールは、認証の強度を単一要素または多要素のいずれとして扱うかを定めるものです。Entra ID で利用可能な他の認証方式は常に単一要素もしくは多要素のどちらか一方での扱いですが、CBA はどちらとしても扱うことができます。管理者は、認証ポリシー ルールを構成することで、Entra ID が証明書をいつ単一要素または多要素とみなすかを選び、保護のレベルを設定できます。複数のカスタム認証バインドのルールを作成し、証明書の属性 (発行者またはポリシー OID、または発行者と OID の組み合わせ) に基づいて、証明書に関する既定の保護レベルを割り当てることもできます。
詳しくは 認証バインド ポリシーを構成する をご覧ください。
CBA アフィニティ バインド : この設定は、ユーザー認証において証明書を検証する際に使用される証明書の属性に関するものです。先に紹介したように、証明書をユーザー オブジェクトとバインドまたは照合させるにはいくつかの方法かあります。その中には、簡単に再利用が可能なユーザー証明書のプロパティを使用しているものもあります。この再利用の容易さにより、特定のユーザー バインドの方法により高アフィニティ (強い関連付け) か低アフィニティ (弱い関連付け) かが決まります。例えば、SAN Principal Name に基づくユーザー バインド利用すると、これは低アフィニティになります。Issuer + SerialNumber に基づくユーザー バインドは高アフィニティです。Entra ID では、管理者がテナント レベルでアフィニティ バインドを設定したり、カスタム ルールを作成して高アフィニティまたは低アフィニティのマッピングを使用したりすることができ、お客様の多くの潜在的なシナリオをカバーすることが可能です。
詳しくは ユーザー名のバインド ポリシーについて をご覧ください。
第 2 要素としての CBA: この機能により Entra リソースにアクセスするための多要素認証 (MFA) の一要素として CBA がサポートされるようになりました。詳しくは CBA による MFA をご覧ください。
第 1 要素 | 第 2 要素 | MFA |
---|---|---|
単一要素による CBA | パスワードレスの電話によるサインイン (PSI) | 持っているもの + 持っている/知っているもの |
単一要素による CBA | FIDO 2 | 持っているもの + 持っている/知っているもの |
パスワード | CBA (単一要素または多要素) | 知っているもの + 持っているもの |
最後に使用された方法 (MRU) としての CBA: ユーザーが CBA を使用して認証に成功すると、MRU (Most Recently Used: 最後に使用された) の方法として CBA が設定されます。それ以降、サインイン画面でユーザーが自身の UPN を入力して [次へ] をクリックすると、直接 CBA の認証に移動するため、[証明書またはスマート カードを使用する] を選択する必要がなくなります。MRU の方法をクリアするには、証明書の選択画面をキャンセルし、[その他のサインイン方法] をクリックします。ユーザーが利用できる別のメソッドを選択し、認証に成功すれば MRU の方法がクリアされます。詳しくは MRU 方法での CBA をご覧ください。
Windows 端末上で Entra ハイブリッド参加および Entra 参加済みデバイスをご利用のユーザーは、スマート カードで Windows にサインインし、プライマリ更新トークン (PRT) を取得して、Entra リソースにシングル サインオン (SSO) することも可能です。詳しくは Windows スマート カード サインイン をご覧ください。
また、Microsoft Entra CBA の詳細については、http://aka.ms/aadcba および Executive Order 14028 に対する Microsoft のコミットメントをご覧ください。
Azure Active Directory Community にフィードバックをお寄せください!弊社では、証明書失効リスト (CRL) の制限の撤廃、新しい認証局のトラスト ストア、B2B 外部ゲスト ユーザー用のリソース テナントでの CBA サポート、iOS UX の強化など、さらなる機能強化を実現するために鋭意取り組んでおります。
]]>Microsoft Entra 条件付きアクセスは、Microsoft Entra ID が提供する主要機能であり、非常に多くのお客様にご利用いただいています。一方で、条件付きアクセスについて誤解されている方が意外と多いと感じており、弊社サポートにはこの誤解により生じる問題や質問が多く寄せられます。
そこで本記事では、条件付きアクセスとはどういったものであるか、またどのようなコンセプトで提供されているかをイメージできるような情報をお届けします。後半では簡単なシナリオをベースに条件付きアクセスの動作を説明していきますので、本記事が条件付きアクセスへの理解の助けとなればうれしく思います。
条件付きアクセスを一言でいうと、Microsoft 365 のサービスや Salesforce など、クラウド上で提供されているサービスへのアクセスを制御する機能です。条件付きアクセスのよくある利用例 (シナリオ) を以下にいくつか紹介します。
ユーザーの資格情報 (ID/パスワードなど) が攻撃者により推測されたり外部に流出したりすると、それを入手した攻撃者は流出した資格情報を使用して Microsoft 365 などにサインインすることができます。これによりアカウントの乗っ取りが成功し、そのユーザーしか知りえない情報が漏洩したり、アカウントが悪用されたりします。
条件付きアクセスを利用している場合、Microsoft 365 や Salesforce などクラウド上のサービスへのアクセス時に、ID およびパスワードといった資格情報に加えて多要素認証を要求することができます。これにより、電話番号を用いた認証や Microsoft Authenticator を用いた認証、さらにはハードウェア トークンを用いた追加認証などパスワード以外の認証要素 (多要素認証) を求めることができるようになります。こうなることで、仮に ID およびパスワードが攻撃者の手に渡っても、多要素認証を突破できない場合は、条件付きアクセスが Microsoft 365 へのアクセスをブロックしてくれます。つまり、ID およびパスワードが窃取されただけではサインインできなくなるため、セキュリティの強化につながります。この多要素認証の要求が、条件付きアクセスのもっとも一般的な利用シナリオです。
重要な機密情報へのアクセスは、多要素認証を要求するだけでなく、そのユーザーが社内ネットワークにいる場合のみアクセスさせたいというご要望もあると思います。多要素認証だけでなく、このような場所の制御も条件付きアクセスで実現が可能です。例えば、社内ネットワークの出口となるパブリック IP アドレスを Microsoft Entra ID に登録しておけば、その IP アドレスが送信元のアクセスだけを条件付きアクセスでブロックしないように構成できます。これにより、ユーザーが特定のネットワークからのみアクセスできる構成を取ることが可能です。このように場所によるアクセス制御も条件付きアクセスでよく利用されています。
ヒント
社外からのアクセスの場合は多要素認証を要求し、社内ネットワークからのアクセスの場合は多要素認証を要求しないというように、社内からのアクセスの場合は制限を緩めるような構成を取る例をよく見受けられます。しかしながら、このような構成はお勧めできません。というのも、攻撃者が社内ネットワークへの侵入に成功してしまうと、多要素認証が強制されず攻撃者がより行動しやすい状況となるためです。このため、多要素認証は最低限の保護として場所を選ばず強制することをお勧めします。
Note
IP アドレスを利用した制御と聞くと、ファイアウォール製品のようなトラフィック制御をイメージされる方もいるかと思いますが、これは誤りです。条件付きアクセスはトラフィック自体は制御しません。
お使いの Windows PC やモバイル デバイスを Microsoft Entra ID に登録および参加させることで組織で管理している扱いにして利用することが可能です。加えて、Intune などのモバイル デバイス管理サービスを組み合わせるとデバイスに対してポリシーを適用することもできます。条件付きアクセスでは、このようにして会社の管理下にあるデバイスのみアクセスを許可するなどの構成も可能です。
Microsoft Entra には ID Protection という機能があり、ユーザーのパスワードの漏洩や、普段利用していない外国からのアクセス、短時間の間にあり得ない距離を移動してサインインが行われるなどの異常を検知して、アラートを上げることができます。条件付きアクセスではこのアラートを利用して、サービスへのアクセスを動的にブロックしたり、サインインに多要素認証を求めたうえでアカウントのパスワード リセットを要求したりということが可能です。
これまで、条件付きアクセスは Microsoft 365 のサービスや Salesforce など、クラウド上で提供されているサービスへのアクセスを制御する機能であると繰り返し述べてきました。この「クラウド上で提供されているサービスへのアクセスを制御する」というのが重要なポイントであり、条件付きアクセスの制御はこの「クラウド上で提供されているサービスへのアクセス」に適用されます。
例えば 「条件付きアクセスでデスクトップ上の Outlook アプリを開けないようにしたい」 という要望は、条件付きアクセスでは完全に実現することができません。これは、このご要望では保護する対象 (制御の対象) がデスクトップ上の Outlook アプリであり、上述の 「クラウド上で提供されているサービスへのアクセス」 ではないためです。
とはいえこの説明ではイメージがわきにくいと思いますので、簡単ですが条件付きアクセスの制御についてユーザーが Outlook で E メール データを閲覧するシナリオを例に説明します。ユーザーが Outlook で E メールやカレンダーを閲覧しようとする場合、ダウンロード済みのデータを除いて Outlook 上には新着 E メールなどはありません。このためユーザーは Outlook を利用して E メール サーバーにアクセスし、新着 E メールやカレンダー情報を取得します。Office 365 ではこの E メール サーバーに該当するクラウド上のサービスが Office 365 Exchange Online です。
条件付きアクセスの用語としては、Outlook をクライアント アプリと呼び、Office 365 Exchange Online のことをターゲット リソース (単にリソースとも) と呼びます。リソースとはクラウド上にあるデータの保管場所のようなものをイメージいただくと良いと思います。
ここでは例として、Office 365 へのアクセスに対して多要素認証を要求するポリシーを構成している場合を考えます。
上述の流れのように、条件付きアクセスの処理の中では、クライアント アプリ (Outlook) ではなく、そのクライアント アプリがアクセスしようとしている先のクラウド上のサービス (Exchange Online) を意識することが重要です。
裏を返すと、条件付きアクセスを用いて、既に Outlook にダウンロードされた E メール データへのアクセスを制御するということはできません。Outlook にはオフライン アクセスという機能があり、インターネットに接続されていない環境でも、ダウンロード済みの E メールやカレンダーを閲覧可能です。「条件付きアクセスでデスクトップの Outlook アプリを開けないようにしたい」という要望を条件付きアクセスで完全に実現することができないのはこのためです。
なお、クラウド上のサービスである Exchange Online を対象にした条件付きアクセス ポリシーを構成すれば、どのクライアント アプリからのアクセスであっても、そのポリシーが適用されます。Outlook からのアクセスであっても、Teams からであっても、自作の E メール アプリからであっても、Exchange Online (E メールやカレンダー) へのアクセスにはその条件付きアクセス ポリシーが適用されます。これも、条件付きアクセスは、クライアント アプリ (Outlook や Teams) ではなく、そのクライアント アプリがアクセスしようとしている先のクラウド上のサービス (Exchange Online) へのアクセスを制御する機能であるとご理解いただければ納得しやすいかと思います。
条件付きアクセスは上述のように様々なアクセス制御を構成できますが、具体的にポリシーを構成する際は、以下のような点を考慮することをお勧めします。
以上から、ファイアウォールのルール作成のようなイメージで条件付きアクセス ポリシーの作成を行うことはできません。
条件付きアクセス ポリシーを構成する際は、社員の方々 (実際の人間) の「会社のビル」や「会社のビル内の特定のフロア」への入退出の管理をイメージいただくと良いと思います。例えば、ある人が会社のビルに入る場合、入り口のゲートに社員証をかざしたり、守衛の方に社員証を見せるなどすると思います。会社のビルにアクセスする際には基本的にすべての人がこのような最低限の認証を行うはずです。皆が社員証を提示して入館したら、ビル内を基本的に自由に移動できますが、個人情報を扱うフロアに入るには追加の認証 (暗証番号など) が必要となる場合や、機密情報を扱う部屋には数名の限られた人のみ入室できるという場合もあるはずです。社員証を紛失したと報告してきた社員については、既存の社員証を廃止して再度本人確認する必要も生じます。
上記のような例に基づくと以下のような条件付きアクセス ポリシーが導き出されます。
以上のように、まず広く全員をカバーするポリシーを作り、それに加えて、アクセス先の各リソースやシナリオごとに追加の認証や条件を設けるというのがお勧めするポリシーの構成です。会社のビルへの入館やその後の社員の移動、リスクの発生など現実世界の人の動きをイメージいただくとよいと思います。Microsoft Entra という製品名は Entrance (入り口) を模していることもあり、このようなサービスへの入り口とお考えいただければ幸いです。
条件付きアクセスがどのような機能であるかを簡単に説明しました。こちらを参考のうえ、条件付きアクセスをさらに活用いただければと思います。製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供しますので、ぜひ弊社サポート サービスをご利用ください。
本記事と併せて以下の記事も是非ご参照ください。
]]>本記事は、2023 年 11 月 30 日に米国の Microsoft Entra (Azure AD) Blog で公開された What’s new in Microsoft Entra の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。
Microsoft はこのほど、組織のセキュリティ態勢の改善を支援することを目的として、Microsoft Entra 製品ファミリーにさまざまな新しいセキュリティ ツールと機能を導入しました。サイバー攻撃がますます巧妙化し、クラウドベースのサービスやモバイル デバイスの利用が増加する中、組織には自らのセキュリティを管理するための効果的なツールの導入が不可欠となっています。
進化する脅威を先取りし、AI の時代に安全なアクセスを実現するために、今月の Microsoft Ignite では、いくつかの重要な発表を行いました:
詳細は、ブログ「Microsoft Ignite における ID: AI 時代におけるアクセスのセキュリティ保護」をご覧ください。
本日は、過去 2 ヶ月間 (2023 年 10 月~ 11 月) の新機能リリースと、2023 年 11 月の変更管理を発表いたします。また、これらの変更点は リリース ノート や電子メールでもお知らせしています。弊社では、お客様が新しい Entra 管理センター 内でも、非推奨、廃止、およびサービスの破壊的変更を含むライフサイクルの変更を管理しやすくするため、継続して取り組んでおります。
これらの最近のアップデートは、Microsoft Entra の製品エリアごとに整理しておりますので、最新のアップデートをすばやく見つけてアクセスいただけると存じます。これらの新機能が、より良い ID およびアクセス ソリューションの提供につながれば幸いです。
新機能の発表は以下のとおりです。
[お客様によっては対応が必要です]
2023 年 11 月初めに、リスク情報、ライセンス、および使用状況に基づいて、お客様のテナントを自動的に保護する条件付きアクセス ポリシーの展開を 発表 しました。これは、Microsoft マネージド条件付きアクセス ポリシーと呼ばれるもので、お客様を自動的に保護することをお知らせするものです。このポリシーは、Microsoft が作成し、お客様のテナントで有効になるポリシーです。以下のポリシーが対象となる一部のテナントに展開されます:
ポリシー | 対象のユーザー | 生じる動作 |
---|---|---|
Require multifactor authentication for admin portals | 管理者ユーザー | このポリシーは、特権ロールを持つ管理者を対象とし、それら管理者が Microsoft 管理者ポータルにサインインするときに多要素認証を要求します。 |
Require multifactor authentication for per-user multifactor authentication users | “ユーザーごとの MFA” 機能を使用しているユーザー | このポリシーは、”ユーザーごとの MFA” 機能を使用しているユーザーに適用され、すべてのクラウド アプリに多要素認証を要求します。これにより “ユーザーごとの MFA” 機能から条件付きアクセスへの移行を促進します。 |
Require multifactor authentication for high-risk sign-ins | Microsoft Entra ID Premium P2 を十分な数お持ちのお客様 | このポリシーはテナントのすべてのユーザーを対象とし、リスクの高いサインイン時に多要素認証と再認証を要求します。 |
対象となるすべてのテナントに対して、事前に通知の上、これらのポリシーを段階的に展開していきます。テナントでポリシーが表示されるようになったら、90 日以内にポリシーを確認し、カスタマイズするか、無効にするようご対応ください。この 90 日間は、ポリシーはレポート専用モードとなります。つまり、条件付きアクセスはポリシーを適用することなく、ポリシーが仮に適用された場合の結果をログに記録します。詳細については、ブログ「Automatic Conditional Access policies in Microsoft Entra streamline identity protection」を参照ください。
Note
サポート チームによる訳注: Microsoft マネージド条件付きアクセス ポリシーの詳細については、サポート チームより日本語のブログ記事である Microsoft マネージド条件付きアクセス ポリシー を公開しております。併せてご参照ください。
[お客様によっては対応が必要です]
2023 年 6 月、弊社は Azure AD Graph API サービスの非推奨化に関する 3 年にわたる事前通知の期間が完了したことを 発表 しました。このサービスは現在、廃止サイクルに入っており、廃止 (シャットダウン) は段階的に行われる予定です。弊社は、この廃止とMicrosoft Graph への移行に際しお客様を可能な限りサポートするようお約束するとともに、この変更に取り組む中で高い透明性と対話の取り組みを進めて参ることをお約束します。
Azure AD Graph の廃止の第一段階は、2024 年後半に開始される予定です。具体的な日付は、最低 3 ヶ月前に予告し、その後のアップデートで共有します。
この第一段階に入ると、特定の日付以降に作成されたアプリケーションは、Azure AD Graph API (https://graph.windows.net) へのリクエスト時にエラーが生じるようになります。弊社ではこの時点で Microsoft Graph への移行が完了していないアプリケーションがまだ存在する可能性があることも承知しておりますので、この時点以降に作成されたアプリケーションが Azure AD Graph API をしばらくの期間延長して利用できるようにするための オプション設定 を提供する予定です。インストールやセットアップの一環としてアプリケーションを作成および登録するようなソフトウェアをお客様が開発または配布しており、さらにこれらのアプリケーションが Azure AD Graph API にアクセスする必要がある場合は、廃止の影響を避けるために、速やかに移行作業を開始ください。このオプション設定は、アプリケーションの作成後に設定することができ、構成の変更は AuthenticationBehaviors のインターフェイスを通して行います。
この計画の実施時期とオプション設定の構成に関するより詳細なガイダンスは、次回の更新でお知らせする予定です。
Azure AD Graph API を使用しているテナント内のアプリケーションを特定するための新しい機能の提供に取り組んでいます。この機能は、Microsoft Entra の推奨事項 の機能を通じて利用可能になる予定です。この機能は、2024 年初頭に利用可能になる予定です。
[お客様によっては対応が必要です]
2023 年 10 月より、一般公開に際してカスタム セキュリティ属性の監査ログに変更が加えられます。これにより監査ログを確認しているお客様においては日常業務に影響が出る可能性があります。プレビュー中にカスタム セキュリティ属性の監査ログを参照していた場合、監査ログの確認に関わる運用作業が中断されないようにするため、2024 年 2 月まで に以下の対応を実行する必要があります:
詳細については、監査ログの動作に対する変更 を参照ください。
[お客様による対応は不要です]
2024 年 3 月以降、Microsoft Graph のアプリケーション API を使用して作成された新しいアプリケーションでは、アプリケーション登録時の「signInAudience」プロパティの既定値が「AzureADandPersonalMicrosoftAccount」から「AzureADMyOrg」に変更されます。弊社の分析によると、ほとんどの新規アプリケーションでは、アプリケーションがテナント外のユーザーに利用されることはありません。この対応により、アプリケーションの応答速度とセキュリティが向上します。アプリケーションの signInAudience についての詳細は、ドキュメント アプリケーション リソースの種類 - Microsoft Graph v1.0 | Microsoft Learn を参照ください。
[お客様による対応は不要です]
2024 年 3 月以降、Microsoft Graph のアプリケーション API を使用して作成された新しいアプリケーションでは、既定で「アプリ インスタンス ロック」が有効になります。2023 年 9 月よりワークロード ID 用にアプリ インスタンス ロックと呼ばれる機能が提供されました。この機能により、アプリ開発者は、重要なプロパティを改竄しようとする攻撃者からマルチテナント アプリを保護できます。Entra ID ポータルを使用して作成されたアプリケーションは、すでにこの設定が既定で有効になっておりますので、今後は、MS Graph、PowerShell、SDK などの他のアプリ作成機能でも有効になる予定です。詳細については、アプリケーションでアプリ インスタンス プロパティ ロックを構成する方法 - Microsoft identity platform | Microsoft Learn を参照ください。
[お客様による対応は不要です]
本年 6 月に、従来のプロフィール ページが新しいページに置き換えられることを 発表 しました。今後、2024 年 1 月 までに既存のプロフィール ページ (https://account.activedirectory.windowsazure.com/r#/profile) がマイ アカウント (https://www.myaccount.microsoft.com) に置き換えられます。マイ アカウントでは、アカウントの詳細、言語、プライバシー設定、セキュリティ情報などを管理することが可能です。マイ アカウントは数年前から利用可能であり、従来のプロフィール ページのすべての機能を備えています。今回の廃止により、お客様はより良く、より先進的な体験に移行されます。自動的に新しいマイ アカウントに遷移するため、お客様による操作は必要ありません。
新機能の発表は以下のとおりです。
新機能の発表は以下のとおりです。
新機能の発表は以下のとおりです。
新機能の発表は以下のとおりです。
以上の内容が参考になれば幸いです。
Shobhit Sahay
]]>本記事は、2023 年 11 月 15 日に米国の Microsoft Entra (Azure AD) Blog で公開された Identity at Microsoft Ignite: Securing access in the era of AI の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。
デジタルの世界が拡大し続けるにつれ、サイバーセキュリティのリスクと課題も拡大しています。サイバー攻撃のスペシャリストを抱える悪意ある組織が、国家や犯罪組織から資金提供を受ける一方、我々が守るべき ID、エンドポイント、アプリ、データは増え続けています。また、AI の新時代では、悪意のある攻撃者 (内部犯を含む) が組織に損害を与える方法は数えきれないぐらい存在するでしょう。
弊社が Microsoft Entra に追加する機能はすべて、進化する脅威の状況を先取りできるようにするためのものです。すべては、お客様が自身の環境をより容易に安全に保てるようにするという 1 つの原則に帰着します。攻撃からの防御を担当するチームを擁する大企業であれ、IT 部門をまったく持たない中小企業であれ、適切なツールを導入し、適切なポリシーを設定するお手伝いをしたいと考えています。Microsoft Ignite 2023 では、Microsoft Entra の新機能と機能強化を発表しました:
発表:
アクセスを保護するには、テクノロジーだけでなく、ビジネス ポリシーや規制についても深く理解する必要があり、時にこれがセキュリティ専門家に過大な業務を負わせることにつながります。この度、Microsoft Security Copilot が Microsoft Entra に追加され、一般的なタスクの自動化、迅速なトラブルシューティング、複雑なポリシーの解釈、ワークフローの設計を支援できるようになりました。
Microsoft Entra 管理センターでは、Security Copilot に対し、その条件付きアクセス ポリシーが何を行うものなのか、なぜ MFA がトリガーされたのかを、簡単な会話形式で説明してもらうことができます。Security Copilot を使用して、ユーザーがサインインできなかった理由など、ID 関連のトラブルシューティングを行うこともできます。また、組み込みの Security Copilot エクスペリエンスでは、リスクのある各 ID について、リスクの概要、修復手順、推奨ガイダンスが表示され、ID のリスクに迅速に対応できます。ワークフローの作成支援機能を使用して、新入社員のオンボーディングなど、入社、異動、退職のシナリオで ID ガバナンスのライフサイクル ワークフローを構築する際に、より効率的に操作が可能となります。
セキュリティ インシデントを調査する場合、関連するサインイン ログと監査ログについて Security Copilot に尋ねることで、文脈に基づいた分析情報を得ることができます。そして、特定のユーザー、グループ、ワークロード、サインイン、ロール、セキュリティ アラートなどの詳細を取得することも可能です。Security Copilot の プライベート プレビュー に今すぐ登録すると共に、今後のすべての開発に関する最新情報を入手するために、こちらにサインアップ ください。さらに、Microsoft Security Copilot を自社のソリューションで使用したいと考えているセキュリティ パートナーの皆様は、Security Copilot パートナー エコシステム にご登録ください。
Microsoft の Security Service Edge (SSE) ソリューションは 現在プレビュー中 で、Microsoft Entra Internet Access と Microsoft Entra Private Access により、ユーザーとデバイスがどこにいようと、あらゆるアプリケーションやリソースへのアクセスを保護します。
Microsoft の SSE ソリューションと Microsoft Entra 製品群の統合により、あらゆるアプリケーションや Web サイトへのアクセスを許可する前に、ID、デバイス、アプリケーション、さらに今後はネットワークの条件を考慮した、統合された条件付きアクセス ポリシーを適用することが可能になります。これは、アプリケーションがどの ID プロバイダーを使用しているかに関係なく、さらにアプリケーションに変更を加えることなく機能します。
皆様の多くが既にお試しの Microsoft Entra Internet Access は、Microsoft 365 トラフィックを安全に保つための ID 中心のセキュア Web ゲートウェイ (SWG) です。弊社は、2023 年末までにすべてのインターネット アプリとリソースを含むようにパブリック プレビューを拡張し、次のような新しいコア機能を追加する予定です:
Microsoft Entra Private Access は、あらゆる社内アプリケーションやリソースのための、ID を中心としたゼロ トラスト ネットワーク アクセス (ZTNA) です。プライベート プレビューの新機能は以下のとおりです:
当社の SSE ソリューションは、Microsoft のセキュリティ スタックおよびオープン パートナー エコシステム全体にわたる統合を通じて、お客様の既存のセキュリティおよびネットワーク ソリューションと連携が可能です。弊社では、Netskope を始めとするこの分野の他のベンダーと提携し、同じ環境でのシームレスな相互運用を実証中です。お客様の環境のネットワーク トラフィックに対し、最適な SSE ソリューションを柔軟に選択できるようにすることをお約束します。併せて、Internet Access と Private Access の両方について、Windows と Android に対するクロス OS のクライアントサポートが現在パブリックプレビューにあること、また MacOS と iOS のサポートもプライベート プレビューにあることも発表しました。SSE ソリューションは現在、中国とロシアを除く全世界で利用可能であり、将来的には SSE のエッジ ロケーションも提供される予定です。
近日開催予定の Tech Accelerator Ask Microsoft Anything (AMA) セッション に是非参加し、Microsoft の SSE ソリューションに関するあらゆる疑問について製品のエキスパートにご相談ください。
昨年、弊社では約 700 万の既存テナントに対して Microsoft Entra ID (旧 Azure Active Directory) のセキュリティの既定値群を有効にし、これらのテナントにおける侵害の件数を 80% 削減しました。お客様からの好意的なフィードバックに基づき、弊社ではさらに、お客様のリスク情報、現在の使用状況、およびライセンスに基づいて、対象となるテナントに条件付きアクセス ポリシーを自動的に作成することで、より多くの Microsoft Entra ID のお客様が自身を保護できるよう支援してまいります。Microsoft マネージド条件付きアクセス ポリシー が展開されると、リスクが高いと想定されるシナリオにて多要素認証 (MFA) を実施する 3 つのポリシーが作成されます。詳細については、Alex Weinert の最近のブログ記事 Automatic Conditional Access policies in Microsoft Entra streamline identity protection をご覧ください。
しかし、すべての MFA の方法が同等にユーザーを保護するわけではありません。FIDO2 セキュリティ キー、Windows Hello、**Microsoft Entra 証明書ベース認証 (CBA)**、パスキーなど、より効果的な MFA の方法では暗号技術が使用されており、認証にフィッシング耐性が付与されます。Microsoft Entra CBA のプレビューでは、証明書、リソースの種類、ユーザーおよびグループごとに認証ポリシーを調整することが可能です。これらのフィッシングに強い認証方式により、パスワードを完全に排除することが可能になり、パスワードの推測、傍受、フィッシングを防ぐことが可能となります。
Microsoft は、Windows 11 を皮切りに、エコシステム全体でパスキーのサポートに取り組んでいます。Windows Hello を使用して Web サイト、アプリケーション、またはサービスのパスキーを作成すると、顔、指紋、またはデバイスの PIN を使用してデバイスからサインイン可能となります。これにより、企業や政府機関のお客様は、物理的な FIDO2 セキュリティ キーに代わる、フィッシングに強い新たな選択肢を得ることができます。Microsoft Entra ID ユーザーは、まもなく Microsoft Authenticator アプリ にて管理されるパスキーを使用してサインインできるようになります。
最後に、Microsoft Entra ID Protection では、トークンの有効期間が異常に長い場合や、なじみのない場所からトークンが再生された場合などの異常を検出するようになりました。アラートが上がると、条件付きアクセスを用いて直ちにトークンを失効させ、パスワードのリセットやステップアップ MFA などの他の対策とともに、管理者による手動での介入を必要とせずに再認証を強制することができます。また、ユーザーがオンプレミスでパスワードを変更した場合に、Entra ID Protection は 自動的にリスクを修復 できるようになりました。これにより、ハイブリッド組織はユーザー リスク ポリシーをより簡単に利用できるようになります。
Microsoft Entra Permissions Management は、このたび権限リスクに関する分析情報を提供する 2 つの重要な統合機能を備えました。これにより、お客様はよりセキュリティ態勢を改善できるようになります。
Microsoft Defender for Cloud (MDC) 統合 のプレビューは、ID とアクセス許可に関する分析情報を他のクラウド セキュリティ情報と統合し、単一のインターフェイスで表示します。このビューでは、権限リスクに対処するための実用的な推奨事項やアクセス許可のクリープ インデックスが表示され、Azure、Amazon Web Services (AWS)、Google Cloud のクラウド リソースに対して最小権限でのアクセスを簡単に実施できるようになります。
このたび一般提供が開始された 2 つ目の統合 により、ServiceNow のお客様は、ServiceNow ポータルを介してマルチクラウド環境 (Azure、AWS、Google Cloud) に対し、期限付きのオンデマンド許可を要求できるようになりました。IT サービス管理 (ITSM) ソリューションは多くのお客様で利用されているため、ServiceNow の既存の承認ワークフローにアクセス許可要求を追加することで、ゼロ トラストの体制より強化することが可能となります。ユーザーがアクセス承認を要求すると、ServiceNow のプラグインが Permissions Management から最新のデータを取得し、要求されたユーザー権限を要求者のロールに基づく期限付きの承認とともに ServiceNow に送り返します。
包括的な機能を備えた Microsoft Entra という単一の統合ソリューションを採用することで、管理者のアクセス セキュリティを簡素化し、エンドユーザにより良い体験を提供することができます。
Microsoft Entra の製品群は互いに連携し、お客様の ID、デバイス、ネットワーク、およびワークロードのセキュリティを保護してまいります。これは、特定のユーザーの種類に限らず、お客様、パートナー、デジタル ワークロードなど、あらゆる種類に対応が可能です。そして今、Microsoft Entra は SSE ソリューションによって、ID とネットワークのアクセス制御を単一のポリシー エンジンに統合させようと取り組んでいます。
Microsoft Entra の最新のイノベーションにより、すべての人のあらゆるものへのアクセスを簡単に保護できるようになることを願っています。
最近の発表の詳細については、Ignite 2023 での私のセッション Secure access in the AI era: What’s new in Microsoft Entra をご覧ください。
Microsoft のセキュリティ ソリューションの詳細については、当社の Web サイト をご覧ください。セキュリティ ブログ をブックマークしておくと、セキュリティに関する最新情報をチェックできます。また、@MSFTSecurity でサイバーセキュリティに関する最新ニュースや最新情報をフォローください。
]]>今回はよくご質問をいただく Microsoft Entra ID をご利用いただく際に必要となるエンドポイント (URL/IP アドレス) について案内します。Microsoft Entra ID においては認証からアカウント管理、アカウント同期に至るまで複数のサービスを提供しており、ご利用いただく機能によってアクセス先のエンドポイントが異なります。お客様によっては、ネットワーク プロキシにて厳密に接続可能なエンドポイント (URL) 先を制御されている場合があり、そういった制御を行われているお客様では、正常にサービスを利用するために個別にエンドポイント (URL/IP アドレス) への通信を許可する必要があります。
本記事においては、現時点で提供している Microsoft Entra ID の各サービスに関し、必要となるエンドポイントを記載した公開資料へのリンクをまとめます。これにより、「どのエンドポイントに対してアクセス許可をすればいいのかまとめて知りたい!」といったご要望にお応え出来たら幸いです。
Note
サポート チームにて可能な限り迅速かつ網羅的な情報の更新に努めておりますが、本記事にてすべての情報の網羅ができているわけではありません。サービスが利用するエンドポイントはドキュメントの更新とともに変化する可能性があります。正式な案内については各公開情報を参照いただくか、弊社サポート サービスまでお問い合わせください。
まず初めに Microsoft Entra ID を利用いただく際に基本的に必要となるエンドポイントは、Office 365 の URL と IP アドレスの範囲 に記載されている ID 56 , ID 59 そして ID 125 になります。こちらは Microsoft 365 を利用する際に Micorosft Entra ID を利用するシナリオで最低限必要となるエンドポイントをまとめたものです。Microsoft Entra ID をご利用いただく際は、認証を行うクライアントからこれらのエンドポイントについてネットワークの疎通を確保ください。
Entra ID では Microsoft Entra ハイブリッド参加、Microsoft Entra 参加そして Microsoft Entra 登録、という 3 つの方法でデバイスを登録することができます。いずれの方法を利用する場合でも、Microsoft Entra ハイブリッド参加を構成する のページに記載されているエンドポイントを許可ください。
Microsoft Entra ID にて利用規約を利用する場合は、Microsoft Entra の利用規約のよく寄せられる質問 のページにある “Q: 利用規約サービスにはどのエンドポイントが認証に使用されますか?” に記載されているエンドポイントを許可ください。
Microsoft Entra Connect を利用して、ハイブリッド ID ソリューション (オンプレミスからのアカウントの同期) を利用される際に必要な URL と IP アドレスの一覧については上記の「Microsoft Entra ID で基本的に利用されるエンドポイント」の節をご覧ください。また併せて、Microsoft Entra Connect の接続に関する問題のトラブルシューティング のページも参照をお勧めします。開放が必要なネットワーク ポートとプロトコルについては、ハイブリッド ID で必要なポートとプロトコル のページにも説明がありますのでご覧ください。
Microsoft Entra Connect Health Service を利用する場合は、Microsoft Entra Connect Health エージェントのインストール ページに記載されているエンドポイントを許可ください。
Microsoft Entra アプリケーション プロキシ コネクタを利用される際は、アプリケーション プロキシを使用してオンプレミス アプリを追加する ページに記載されているエンドポイントを許可ください。
Microsoft Entra プロビジョニング サービスを利用する場合は、チュートリアル: Microsoft Entra ID の SCIM エンドポイントのプロビジョニング に記載されている IP アドレスの範囲を参照ください。
2024 年 9 月 30 日にサービスの提供終了がアナウンスがされていますが、オンプレミスの MFA サーバーを利用する場合は、Azure Multi-Factor Authentication Server のファイアウォールの要件 に記載されているエンドポイントを許可ください。
Microsoft Entra Private Access 用にアプリ プロキシ コネクタについては、Microsoft Entra Private Access 用にアプリ プロキシ コネクタを構成する方法 に記載されているエンドポイントを許可ください。
Microsoft Entra ID の認証ではないですが、Azure ポータルや一般的なアカウント サービスに必要となるエンドポイントは、ファイアウォールまたはプロキシ サーバーで Azure portal の URL を許可する のページに記載されているエンドポイントを許可ください。
今後、Entra ID をご利用いただく際に本ブログの内容が少しでも参考となりますと幸いです。
]]>今回は、Microsoft Entra ID のエンタイトルメント管理 (アクセス パッケージ) の機能をより活用できる、カスタム拡張機能について紹介します。
今回の記事は、アクセス パッケージを既にご利用いただいており、基本的な操作を理解いただいている方をターゲットとした、中級者向けの案内です。アクセス パッケージを初めて触るお客様や、これから導入を検討されているお客様などで基本的な概要を確認されたい場合、以前公開いたしました以下の記事を先にご覧ください。
今回は、カスタム拡張機能を利用した操作の例を紹介します。次回の記事にて、ライフサイクル ワークフローとこのアクセス パッケージのカスタム拡張機能を利用した上級編シナリオのご紹介を予定しております。まずは本記事にて基本的な手順や利用方法を確認いただければと思います。
アクセス パッケージに対する要求や割り当て期限が迫っている時など特定のイベントについて、事前に設定したカスタム タスクを実行する機能です。アクセス パッケージを作成するときに、任意項目なのでスキップしてしまいがちですが、以下のように「カスタム拡張機能」を指定するよう構成することができます。
たとえば上記スクリーンショットでは、アクセス パッケージの割り当てが行われたことを E メールで通知するようにカスタム拡張機能を構成しています。その他にもカスタム拡張機能の実行のタイミングとして以下を選択可能です。
カスタム拡張機能自体は「カタログ」内に項目があり、以下から新しい拡張機能を作成することができます。また、以下の例では PackageTask1 というロジック アプリにカスタム拡張機能を紐づけ、カスタム拡張機能が呼び出されるとこのロジック アプリが実行される仕組みになっています。
ロジック アプリを呼び出した後、具体的にどんな処理を行わせたいかは、お客様側で自由に記載することができます。また、プログラミング スキルがなくても、以下のようなデザイナーを使って、どのような処理を行いたいかを GUI 上で構成することが可能です。
可能な限り本ブログで機能については解説いたしておりますが、基本的には エンタイトルメント管理でカスタム拡張機能を使用して Logic Apps をトリガーする を参考いただき、まずはお客様側で実装いただけますと幸いです。
アクセス パッケージを割り当てた時に追加で実施したいタスクとして、「割り当てられたユーザーのプロパティ変更」や「割り当てられたユーザーへの E メール送信」などが挙げられます。今回は、アクセス パッケージが割り当てられたら「割り当てられたユーザーの部署 (department 属性) および ExtenrionAttribute1 属性を変更する」、「変更された旨と、パッケージ内のリソース リンクをユーザーに E メール通知する」といった拡張機能を実装してみたいと思います。手順は大きく分けて 4 つあります。
順に以下に案内しておりますが、手順は下記公開情報と同様になりますので、併せて参考となれば幸いです。
エンタイトルメント管理でカスタム拡張機能を使用して Logic Apps をトリガーする
Azure ポータルにサインインし、[Azure Active Directory] - [Identity Governance] - [カタログ] - [新しいカタログ] よりカタログを作成します。名前と説明を入力し、作成ください。カタログはアクセス パッケージに含めることが出来るリソース (グループ、アプリケーション、SPO サイト) を纏めるために利用します。
作成したカタログについて、メニューから [カスタム拡張機能] を選択し [カスタム拡張機能の追加] をクリックします。
カスタム拡張機能に名前と説明を付けます。どのようなカスタム タスクが実行されるかを説明に記載しておくと分かりやすいです。
アクセス パッケージにこの拡張機能を紐づける時、どのようなタイミングでトリガーされるかを指定します。今回は「要求ワークフロー」を指定します。
ロジック アプリの実行中に、アクセス パッケージの割り当て処理などを一時停止するかを指定します。今回は department 属性を正しく変更し E メールが送信できたら処理を再度開始したいので、「起動して待機」を指定します。待機時間などは既定値のままですが、任意に変更できます。
このカスタム拡張機能に紐づけるロジック アプリを作成します。サブスクリプションとリソース グループを選択し、ロジック アプリの名前を指定して、「ロジック アプリの作成」をクリックします。
ロジック アプリのデプロイが完了するのを待機します。以下のように成功メッセージが表示されれば次へ進みます。
最終確認画面で作成をクリックすれば完了です。
下記のように、一覧に表示されていることを確認します。
既存のパッケージ ポリシーを開き、上記で作成したカスタム拡張機能を紐づけます。具体的には、ポリシーの作成/編集画面において、ステージ (いつ実行するか) とカスタム拡張機能 (何を実行するか) を指定します。今回は、「割り当てが付与されたときに customextension1 というタスクを実行する」ようにしました。
今回のロジック アプリでは「割り当てられたユーザーの部署 (department 属性) および ExtenrionAttribute1 属性を変更する」、「変更された旨と、パッケージ内のリソース リンクをユーザーに E メール通知する」という 2 つのタスクを Microsoft Graph API を利用して実現します。呼び出されたロジック アプリで Graph API クエリを実行するためには、ロジック アプリ内で認証を構成する必要があります。Microsoft Entra ID にアプリを作成してクライアント シークレットなどを利用して認証を行うこともできますが、今回はマネージド ID を利用する方法を紹介します。
上記で作成されたロジック アプリにアクセスし、 ID を開くと、マネージド ID の状態が表示されます。既定ではオフになっています。
オンに変更すると、以下のメッセージが表示されるので「はい」を選択します。
システム割り当てマネージド ID が有効化されたことを確認します。
有効になると、マネージド ID のオブジェクト ID が表示されるので確認し、ID を控えます。
Microsoft Entra ID - [エンタープライズ アプリケーション] を開き、「アプリケーションの種類」フィルターを “マネージド ID” にしたうえで先ほどの ID を入力し、アプリがあることを確認します。
グローバル管理者の権限で PowerShell を開き、以下のコマンドを実行して マネージド ID に Graph API の権限を付与します。実際にこのマネージド ID でどのような操作を行わせたいかによって、付与する権限は変わりますが、今回はユーザーのプロパティ更新と E メールの送付をしたいので、ここではそれぞれ必要となる権限である Directory.ReadWrite.All と Mail.Send を付与します。
# グローバル管理者でサインインします。 |
マネージド ID に権限が割り当てられると、以下のように [アクセス許可] タブに権限が表示されますので確認します。
次に、ユーザー管理者ロールをマネージド ID に付与しておきます。Microsoft Entra ID の [ロールと管理者] から「ユーザー管理者」ロールを検索します (ユーザーの属性を編集するために本ロールが必要なためです)。
メンバーの選択の項目をクリックし、マネージド ID と同じ名前のアプリケーションを選択します。
アプリケーションのロール割り当てに関しては、アクティブな割り当てのみがサポートされています。この警告は気にせずに先に進んで問題ありません。
アクティブが選択されていることを確認のうえ、ロールを付与します。
上記までできたら、実際にロジック アプリで、カスタム拡張機能が呼び出されたときにどうするかを記載していきます。
今回は以下のようなアクションを追加していきます。
アクセス パッケージから渡された情報が triggerBody の中に含まれています。渡された情報の中の、「パッケージが割り当てられたターゲットの ObjectID」を取得すると、割り当てられたユーザーを特定することができます。そこで、ここではまず $userID という変数に「パッケージが割り当てられたターゲットの ObjectID」を代入しています。アクセス パッケージの割り当て情報の中の Target 内 ObjectID に記載されているという点を示すために、値にあたる部分は動的なコンテンツとして記載します。
動的なコンテンツの追加は、値のボックスをクリックしたときに表示される選択肢の中から以下を選ぶと、上のように埋め込むことができます。式としては、triggerBody()?[‘Assignment’]?[‘Target’]?[‘ObjectId’] となります。
ユーザーの情報を取得するためには、 ユーザーの取得 - Microsoft Graph v1.0 を使用します。アクセス パッケージが割り当てられたユーザーの情報は、先ほど $userID 属性に格納したので、以下のように記載します。
また、 Add new parameter を開き、認証のチェックをオンにします。
先ほど事前にマネージド ID を構成し権限を割り当てたので、以下のように、システム割り当てマネージド ID を選択します。対象ユーザーの項目には、https://graph.microsoft.com を入力してください。
次に、もう一つ HTTP アクションを追加し、ユーザーを更新するための API を記載します。更新するユーザー情報は、 $userID の変数から利用します。具体的な更新 API は ユーザーを更新する - Microsoft Graph v1.0 に記載がありますので、こちらをもとに必要な情報を埋めていきます。例えば本文内に、「どの部署名に更新したいのか」部署の名前を指定しておきます。今回は、IT という部署に移動したいので以下のように記載します。なお、上記と同様に「認証」のチェックを有効化し、マネージド ID を指定ください。
最後に、E メールをユーザー本人に送付したいので、$mail という変数を作り、事前に取得したユーザー情報の中から Mail 属性の値を取得して格納します。
アクセス パッケージの割り当てによって初めて E メールボックスが作成される場合、アクセス パッケージ割り当て直後にメールを送付するとエラーになる可能性が考えられるため、10 分ほど待機するフローを挿入します。
E メールの送付元となるユーザーを $MailSender という変数に定義します。
E メールの送付は user: sendMail - Microsoft Graph v1.0 の API で実行できますので、以下のように実行します。
本文は以下のように記載し、受信者 (toRecipients) のアドレスに送信先となる $mail を指定します。ここでアクセス パッケージで割り当てたリソース (グループ、アプリケーション、SPO サイト) のリンク先も記載しておきます。
先に記載した HTTP と同様に、認証のチェックをオンに変更し、マネージド ID を指定します。
本文の記載が少々見にくいかと思いますので、以下が参考となりますと幸いです。
{ |
ちなみに、ロジック アプリの記載においては、デバッグやトラブル シューティングをしながら進めることが多いと思います。ロジック アプリの概要画面を確認すると、成功もしくは失敗の一覧が表示されているので、処理状況の確認が可能です。
失敗のログをクリックすると、処理のどこでエラーになったのかも分かります。そのため、たとえば以下の場合だと、 HTTP 3 のアクションを見直せばよいことが分かります。
必要に応じて、Logic Apps 観点のブログ もご確認ください。
ユーザーにアクセス パッケージのリンクへアクセスしてもらいます。要求ポリシーが複数ある場合はどちらか選択します。
必要に応じて、期間や理由を記載のうえパッケージを要求します。
ポリシーの内容にもよりますが、承認などを経てパッケージが割り当てられます。割り当てられると「割り当て」画面にユーザーが表示されます。
パッケージが割り当てられたので、カスタム タスクが発動します。ユーザーの属性が変更されるなどし、最後に以下のような E メールが送付されます。
実行履歴を確認すると、すべて成功しているかどうかなどを確認いただけます。
今回は、アクセス パッケージとカスタム拡張機能を利用したサンプルについて紹介しました。上記内容を参考とし、お客様側のご要件およびご要望に合うカスタム拡張機能を実装いただければ幸いです。
]]>