以下ハンズオンのModule 04の部分です。
英語版。
日本語版はこちら。
全部で4 Module。
Module 01: https://qiita.com/smr1/items/1c2558fdb466795669cc
Module 02: https://qiita.com/smr1/items/975769ee5d0822562aef
Module 03: https://qiita.com/smr1/items/8de42c5504511b067890
Module 04: https://qiita.com/smr1/items/fdd57f3f2bc2acab9633
Catalog
カタログとアクセスパッケージの関係
カタログは、リソースとアクセスパッケージのコンテナーとして機能します。これは、関連するリソースとアクセスパッケージをグループ化するために作成されます。
一方、アクセスパッケージは、リソースとポリシーを1回だけ設定して、アクセスパッケージの存続期間中にアクセスを自動的に管理できます。アクセスパッケージは、カタログという名前のコンテナーに配置する必要があります。
つまり、カタログはアクセスパッケージとリソースを管理するための「箱」のようなもので、アクセスパッケージはその「箱」の中にある特定のリソースへのアクセスを管理するためのツールです。
カタログ作成
Identity Governance > Entitlement Managementから作成する。External Userを対象とするかどうか選択できる。
The types of resources you can add are
- groups
- applications
- SharePoint Online sites
The groups can be cloud-created Microsoft 365 Groups or cloud-created Microsoft Entra security groups. The applications can be Microsoft Entra enterprise applications, including both SaaS applications and your own applications federated to Microsoft Entra ID. The sites can be SharePoint Online sites or SharePoint Online site collections.
カタログに対するロールの割り振り。
アクセスパッケージ
注意しなくちゃいけないのは、上で設定したのは、あくまでこのカタログで対象とするリソースをどれにするか。
カタログで設定した対象をアクセスパッケージで指定できるようになる。だからアクセスパッケージは別途作成しなくちゃいけない。カタログに複数のアクセスパッケージが含まれる。
アクセスパッケージで実際に誰が、何に対してどれくらいの期間、どのようにアクセスを要求できるかとかを設定する。ユーザーの属性に従って、自動的にアクセスパッケージを振ったりもできるらしい。
外部ユーザーをアクセスパッケージで管理する
外部ユーザーの招待もアクセスパッケージを使うのが便利らしい。ゲストユーザーを招待するのは、Access Package経由でもできるのが新しかった。ゲストユーザー = Invitationの送信と考えてしまうのは短絡的だった。
多くのお客様の環境では、まずゲスト ユーザーを contoso テナントに招待した後、ゲストが SharePoint、Teams、サブスクリプション リソース (AppService など) にアクセスできるように、アクセス許可を別途設定していると思います。そして開発プロジェクトが終了した際には、ゲスト ユーザーからアクセス権の剥奪を行います。
該当するユーザーが 1 人の場合は手動でアクセス許可を付与することもできますが、該当するユーザーが 20 人や 30 人と増えるほど、上述した「ゲスト招待」や「アクセス権の付与」、「アクセス権の剥奪」といった 3 つのタスクの負荷は大きくなります。
アクセス パッケージを使用すると...管理者側のタスクは、「ユーザーが要求したパッケージを承認する」フロー 1 つのみとなります。
なるほど。便利。ゲストだから、特定の目的があって、必要な権限も決まっている場合は楽だ。
※参考リンクだと、ゲストユーザーだけでなく、普通に新入社員等通常ユーザーもアクセスパッケージで管理するシナリオが紹介されていた。一般的な権限はアクセスパッケージで設定しておいて、個別の権限はユーザーのRBACを使うというのはありなのかもしれない。
正社員もゲストと同じように、アクセスパッケージによってIDライフサイクルを実現する。
アクセスパッケージの期限が切れたら、自動的に（ゲスト）ユーザーが無効化されるように設定できる。
Terms of use
Terms of useの設定。
定期的に承諾を表示するとか、条件付アクセスを設定して承認しないとアクセスさせないとかもできる。
ログイン時にこんなのが表示される。
Access Review
何に対してのアクセスレビュー。
例えばグループを設定したら、レビュワーをグループオーナーにする。定期的にレビューするか否か。
レビュワーが対応しない場合、アクセス権を自動的に削除できる。
Previlged IdentityManagement
Just in timeによるロール管理を実現。
Azure ADのPrivileged Identity Management（PIM） は、組織内の重要なリソースへのアクセスを管理、制御、監視するためのサービスです1。
以下の主な機能があります12：
Just-In-Timeの特権アクセス：特権操作を実行する必要があるユーザーに対して、必要な時に必要な時間だけ特権アクセスを付与します12。期限付きアクセス権12：開始日と終了日を使用して、特定の期間だけアクセス権をリソースに割り当てます12。
承認要求12：特権ロールをアクティブ化するために承認を要求します12。
多要素認証12：ロールをアクティブ化するために多要素認証を強制します12。
監査履歴のダウンロード12：社内監査または外部監査に使用する監査履歴をダウンロードします12。
対象はEntra role, group, Azure resources。
Roleを人にEligibleでAssignする。
RoleごとにAssignの状況が見れる。以下はEligibleが1人いる状態。
ActivateするときのApproverや通知等の設定をできる。
My RoleからActivateできる。
Group
Azure Resource
ActiveとEligibleの違いについて注意が必要。
- Eligibleはあるロールを要求する承認依頼を出す権限がある。
- Activeはすでにそのロールを持っている。
アクセスパッケージとPIMの違い
どちらもアクセス管理を実現する機能でわからなくなってきたので、Bing Chatに質問してみた。PIMはあくまでも特権管理をJITするものである。
Azure ADのアクセスパッケージとPrivileged Identity Management (PIM)は、どちらもAzure Active Directoryの一部であり、ユーザーのアクセスを管理するための機能ですが、それぞれ異なる目的と機能を持っています。
Azure AD Privileged Identity Management (PIM) は、組織内の重要なリソースへのアクセスを管理、制御、監視するためのサービスです¹。特に、特権アカウントを管理および保護し、管理者によるリソースへのアクセスを検出、制限、監視して必要に応じてジャストインタイムアクセスを提供します³⁴。これにより、組織は、AzureおよびMicrosoft Entraリソースに対するJust-In-Time特権アクセスをユーザーに付与することができ、それらのユーザーが与えられた特権アクセスでどんな操作を実行しているかを監視することもできます¹。
一方、Azure ADのアクセスパッケージ は、特定のユーザーやグループが必要とするリソースへのアクセスを一元化して管理するための機能です。アクセスパッケージを使用すると、ユーザーは必要なリソースへのアクセスを一度にリクエストでき、IT管理者はそのリクエストを一元的に承認、監視、レビューすることができます。これにより、組織は誰がどのリソースにアクセスできるかを効率的に管理することができます。
したがって、これらの機能は、それぞれ異なるアクセス管理のニーズに対応しています。 Azure AD PIMは特権アクセスの管理に重点を置き、Azure ADのアクセスパッケージは一般的なリソースアクセスの管理に焦点を当てています。
Administrative Unit
PIMはデフォルトだとScopeがDirectoryになっているが、Administrative Unit内で利用するとか範囲を制限することもできる。
管理単位を使用すると、組織を任意の単位に分割し、その単位のメンバーのみを管理できる特定の管理者を割り当てることができます。 たとえば、管理単位を使用して、大規模な大学の各学校の管理者にアクセス許可を委任して、アクセスの制御、ユーザーの管理、およびエンジニアリングの学校でのみポリシーを設定することができます。
グループオーナーとAUの違い
グループオーナーとAUはどちらも管理を委任するという意味で違いが判らなくなってきたので、Bing Chatに質問してみた。
Administrative Unit (AU) は、Azure ADのユーザーやグループなどを格納するコンテナの役割を果たします12。これにより、特定のユーザーやグループだけを管理する、いわゆるOU的な管理が可能になります1。管理単位には、ユーザー、グループ、デバイスのみを含めることができ、これらの管理対象に対して特定のロールを持つ管理単位の管理者を設けることができます12。
一方、Group Owner は、特定のグループの所有者を指します。Group Ownerは、そのグループのメンバーシップを管理し、グループの設定を変更する権限を持ちます。Group Ownerは、グループのメンバーを追加、削除、または変更することができます。
AUはグループ跨ぎの管理、テナント管理者にも管理させないという制限付きの管理ができるところが大きな違いなのか。
使いどころがイマイチわからなかったが、こういう要件もありえるのか。
Azure、AzureADの世界では基本的に権限が継承され、下位の階層で拒否することはできません。しかし現実には、「IT部門のメンバーが全体の管理はしているけど、人事部や財務部の範囲は触らせたくない」みたいな要件が散見されます。
制限付き管理単位」を使えば、特定部門の管理権限を特定の人のみに渡すことができ、上記のような設定を無くしシンプルにすることができます。設定ミスによる思わぬ情報公開も避けることができ、とても便利ですね。
Sentinel でEntra IDのログを収集・管理する
LogAnalyticsをデプロイし、SentinelをContent HubからEntra IDに接続する。
データコネクタにEntra IDが表示される。
どのデータをSentinelに流すか設定する。プレビューが多いな。。。
AADのログをKusto Queryで見れるようになる。
Identity Secure Score
Security Posture Management。
Identity管理に関するImprovement Actionsがある。
設定の手順がかなり詳細に書かれていてうれしい。
蛇足だけど、パスワードをNever Expireにするのが推奨されて、おや、と思ったら、パスワードが十分に複雑であれば、Microsoftは定期的に変更しないほうが良いというのが公式な立場らしい。そうなのか（小並感）。