一人の建築家の視点から見たアイデンティティとその先へ

  • [アーティクル]

この記事では、Microsoft のプリンシパル テクニカル アーキテクト である Alex Shteynberg が、Microsoft 365 やその他の Microsoft クラウド サービスを採用しているエンタープライズ組織向けの上位の設計戦略について説明します。

筆者について

Alex Shteynberg 写真。

ニューヨーク Microsoft テクノロジ センターのプリンシパル テクニカル アーキテクトです。 私は主に大きな顧客と複雑な要件で働いています。 私の視点や意見は、これらの相互作用に基づいているので、すべての状況に当てはまるとは思わないかもしれません。 しかし、私の経験では、最も複雑な課題を抱えるお客様を支援できれば、すべての顧客を支援できます。

私は通常、毎年100以上の顧客と一緒に働いています。 すべてのorganizationには独自の特性がある一方で、傾向や共通点を見るのは興味深い点です。 たとえば、1 つの傾向は、多くの顧客に対する業界間の関心です。 結局のところ、銀行支店はコーヒーショップとコミュニティセンターでもあり得ます。

私の役割では、お客様が独自のビジネス目標のセットに対処するための最適な技術的ソリューションに到達できるように支援することに重点を置いています。 正式には、ID、セキュリティ、プライバシー、コンプライアンスに焦点を当てています。 私は、これらが私たちが行うすべてのものに触れるという事実が大好きです。 それは私にほとんどのプロジェクトに関与する機会を与えます。 この活動は私を忙しくさせ、この役割を楽しみます。

私はニューヨーク市に住んでいます(最高!) そして本当にその文化、食べ物、そして人々の多様性を楽しんでいます(交通ではありません)。 私はできるときに旅行するのが大好きで、私の生涯の中で世界の大部分を見たいと思っています。 私は現在、野生動物について学ぶためにアフリカへの旅行を研究しています。

ガイドの原則

  • 多くの場合、単純な方が優れています。テクノロジを使用して(ほとんど)何でも実行できますが、そうする必要はありません。 特にセキュリティ領域では、多くのお客様がソリューションをオーバーエンジニアリングしています。 私はこの点を強調するために、Googleのストライプ会議から このビデオ が好きです。
  • People、プロセス、テクノロジ: 技術を最初に行うのではなく、プロセスを強化するための設計。 "完璧な" ソリューションはありません。 ビジネスごとに異なる可能性のあるさまざまなリスク要因と意思決定のバランスを取る必要があります。 ユーザーが後で避けるアプローチを設計する顧客が多すぎます。
  • 最初の 「なぜ」と「方法」に焦点を当てる:100万の質問を持つ迷惑な7歳の子供になる。 正しい質問がわからない場合は、適切な回答を得ることはできません。 多くのお客様は、ビジネス上の問題を定義するのではなく、作業する必要がある方法を想定しています。 取得できるパスは常に複数あります。
  • 過去のベスト プラクティスの長い末尾: ベスト プラクティスが軽い速度で変化していることを認識します。 3 か月以上前にMicrosoft Entraを見た場合は、古くなっている可能性があります。 ここにはすべて、公開後に変更される可能性があります。 今日の "ベスト" オプションは、6 か月後と同じではないかもしれません。

ベースラインの概念

このセクションはスキップしないでください。 クラウド サービスを何年も使用しているお客様でも、これらの記事に戻る必要があることがよくあります。 悲しいかな、言語は正確なツールではありません。 多くの場合、同じ単語を使用して、異なる概念や異なる単語を意味し、同じ概念を意味します。 多くの場合、次の図を使用して、いくつかのベースライン用語と "階層モデル" を確立します。

テナント、サブスクリプション、サービス、データの図。

泳ぐことを学ぶときは、海の真ん中ではなく、プールで始める方が良いです。 私はこの図で技術的に正確にしようとしていません。 これは、いくつかの基本的な概念について説明するモデルです。

図の説明

  • Tenant = Microsoft Entra IDのインスタンス。 これは、階層の "最上位" にあるか、図のレベル 1 にあります。 このレベルは、他のすべてが発生する "境界" であると考えることができます (B2B は別としてMicrosoft Entra)。 すべての Microsoft エンタープライズ クラウド サービスは、これらのテナントの 1 つに含まれています。 コンシューマー サービスは個別です。 "テナント" は、Microsoft 365 テナント、Azure テナント、WVD テナントなどのドキュメントに表示されます。 私は多くの場合、これらのバリエーションが顧客に混乱を引き起こすことがわかります。
  • 図のレベル 2 のサービス/サブスクリプションは、1 つのテナントと 1 つのテナントにのみ属します。 ほとんどの SaaS サービスは 1:1 であり、移行なしでは移動できません。 Azure は異なります。課金やサブスクリプションを別のテナントに移動できます。 Azure サブスクリプションを移動する必要がある多くのお客様がいます。 このシナリオにはさまざまな影響があります。 サブスクリプションの外部に存在するオブジェクトは移動しません。 たとえば、ロールベースのアクセス制御 (Azure RBAC)、Microsoft Entra オブジェクト (グループ、アプリ、ポリシーなど)、一部のサービス (Azure Key Vault、Data Bricks など)。 適切なビジネスニーズなしでサービスを移行しないでください。 移行に役立つ一部のスクリプトは、 GitHub で共有されます。
  • 特定のサービスには通常、何らかの "サブレベル" 境界 (レベル 3 (L3) があります。 この境界は、セキュリティ、ポリシー、ガバナンスなどの分離を理解するのに役立ちます。 残念ながら、私が知っている均一な名前はありません。 L3 の名前の例としては、Azure Subscription = resource があります。CE = インスタンスDynamics 365。Power BI = ワークスペース。Power Apps = 環境。などなど。
  • レベル 4 は、実際のデータが存在する場所です。 この "データ プレーン" は複雑な記事です。 RBAC にMicrosoft Entra IDを使用しているサービスもあれば、使用していないサービスもあります。 委任に関する記事が表示されたら、少し説明します。

多くのお客様 (および Microsoft 従業員) が混乱している、または質問があるその他の概念には、次の問題があります。

  • 誰でも多くのテナントを無償で作成できます。 その中にプロビジョニングされたサービスは必要ありません。 私は数十を持っています。 各テナント名は、Microsoft の世界中のクラウド サービスで一意です (つまり、同じ名前を持つテナントは 2 つありません)。 これらはすべて TenantName.onmicrosoft.com 形式です。 テナントを自動的に作成するプロセス (アンマネージド テナント) もあります。 たとえば、この結果は、ユーザーが他のテナントに存在しないメール ドメインを使用してエンタープライズ サービスにサインアップしたときに発生する可能性があります。
  • マネージド テナントでは、多くの DNS ドメインを それに登録できます。 この結果では、元のテナント名は変更されません。 現在、テナントの名前を変更する簡単な方法はありません (移行以外)。 最近、テナント名は技術的には重要ではありませんが、この現実によって制限されている人もいます。
  • サービスのデプロイをまだ計画していない場合でも、organizationのテナント名を予約する必要があります。 そうしないと、誰かがあなたからそれを取ることができ、それを取り戻す簡単なプロセスはありません(DNS名と同じ問題)。 私はあまりにも頻繁に顧客からこの方法を聞く。 テナント名を指定する必要があるのもディベート記事です。
  • DNS 名前空間を所有している場合は、これらの名前空間をすべてテナントに追加する必要があります。 そうしないと、この名前の アンマネージド テナント が作成され、中断が発生して 管理が中断される可能性があります。
  • DNS 名前空間 (たとえば、contoso.com) は、1 つのテナントにのみ属できます。 この要件は、さまざまなシナリオ (合併や買収中に電子メール ドメインを共有するなど) に影響します。 別のテナントに DNS サブ (div.contoso.com など) を登録する方法がありますが、これは避ける必要があります。 最上位のドメイン名を登録すると、すべてのサブドメインが同じテナントに属していると見なされます。 マルチテナントシナリオでは(次に説明するように)、通常は別のトップレベルドメイン名(contoso.ch や ch-contoso.com など)を使用することをお勧めします。
  • テナントを "所有" する必要があるユーザー テナントを現在所有しているユーザーがわからないお客様をよく見かけます。 この知識不足は重大な赤旗です。 できるだけ早く Microsoft サポートに問い合わせてください。 同様に問題になるのは、サービス所有者 (多くの場合、Exchange 管理者) がテナントを管理するように指定されている場合です。 テナントには、将来必要になる可能性があるすべてのサービスが含まれています。 テナント所有者は、organization内のすべてのクラウド サービスの有効化を決定できるグループである必要があります。 もう 1 つの問題は、テナント所有者グループにすべてのサービスの管理を求められる場合です。 この方法は、大規模な組織ではスケーリングされません。
  • サブ/スーパー テナントの概念はありません。 何らかの理由で、この神話は繰り返し続けます。 この概念は 、Azure Active Directory B2C テナントにも適用されます。 "B2C 環境が XYZ テナントにあります"、または "Azure テナントを Microsoft 365 テナントに移動操作方法" と何度も聞こえます。
  • このドキュメントでは、ほとんどのお客様が使用しているため、主に商用世界中のクラウドに焦点を当てています。 ソブリン クラウドについて知ると便利な場合があります。 ソブリン クラウドには、この議論の範囲外である他の影響があります。

ベースライン ID に関する記事

Microsoft の ID プラットフォームに関するドキュメントは、Microsoft Entra ID。 始めたばかりの人にとっては、多くの場合、圧倒的な気持ちになります。 そのことを学んだ後でも、絶え間ないイノベーションと変化に追いつくのは困難な場合があります。 私の顧客とのやりとりでは、私は多くの場合、ビジネス目標とこれらの懸念に対処するための「良い、より良い、最高の」アプローチ(およびこれらの記事のための人間の「崖のメモ」)の間の「翻訳者」として役立っている自分自身を見つけます。 完璧な答えはめったになく、「正しい」決定はさまざまなリスク要因のバランスです。 次に、私が顧客と話し合う傾向がある一般的な質問と混乱領域がいくつかあります。

プロビジョニング

Microsoft Entra IDは、ID の世界におけるガバナンスの欠如を解決しません。 ID ガバナンス は、クラウドの決定とは無関係に重要な要素である必要があります。 ガバナンス要件は時間の経過とともに変化します。これが、ツールではなくプログラムである理由です。

Microsoft Entra Connect vs. Microsoft Identity Manager (MIM) と他の (サード パーティ製またはカスタム) 今と将来の自分の問題を保存し、Microsoft Entra接続に進む。 このツールには、独特の顧客構成と進行中のイノベーションに対処するために、あらゆる種類のスマートがあります。

より複雑なアーキテクチャに向かう可能性のあるエッジ ケース:

  • 私は、それらの間にネットワーク接続のない複数のADフォレストを持っています。 Cloud Provisioning という新しいオプションがあります。
  • Active Directory を持っていないか、インストールする必要もありません。 Microsoft Entra接続は、LDAP から同期するように構成できます (パートナーが必要な場合があります)。
  • 同じオブジェクトを複数のテナントにプロビジョニングする必要があります。 このシナリオは技術的にはサポートされていませんが、"同じ" の定義によって異なります。

既定の同期規則 (フィルター オブジェクト、 属性の変更、 代替ログイン ID など) をカスタマイズする必要がありますか? 避けてください。 ID プラットフォームは、それを使用するサービスと同じくらい価値があります。 あらゆる種類の構成を行うことができますが、この質問に答えるためには、アプリケーションへの影響を確認する必要があります。 メールが有効なオブジェクトをフィルター処理する場合、オンライン サービスの GAL は不完全です。アプリケーションが特定の属性に依存している場合、これらの属性をフィルター処理すると予測できない効果が生じるなどです。 ID チームの決定ではありません。

XYZ SaaS では Just-In-Time (JIT) プロビジョニングがサポートされていますが、同期が必要なのはなぜですか? 前の段落を参照してください。 多くのアプリケーションでは、機能のために "プロファイル" 情報が必要です。 すべてのメールが有効なオブジェクトが使用できない場合は、GAL を使用できません。 これは、Microsoft Entra IDと統合されたアプリケーションでのユーザー プロビジョニングにも当てはまります。

認証

パスワード ハッシュ同期 (PHS) と パススルー認証 (PTA) と フェデレーション。

通常、フェデレーションに関する情熱的な 議論 があります。 単純な方が通常は優れているため、適切な理由がない限り PHS を使用します。 また、同じテナント内の異なる DNS ドメインに対して異なる認証方法を構成することもできます。

一部のお客様は、主に次の目的でフェデレーション + PHS を有効にします。

私は多くの場合、クライアント認証フローを通じて顧客を歩いて、いくつかの誤解を明らかにします。 結果は次の図のようになります。これは、そこに行く対話型のプロセスほど良くありません。

ホワイトボードの会話の例。

この種類のホワイトボード図面は、認証要求のフロー内でセキュリティ ポリシーが適用される場所を示しています。 この例では、Active Directory フェデレーション サービス (AD FS) を通じて適用されるポリシーは、最初のサービス要求には適用されますが、後続のサービス要求には適用されません。 この動作は、セキュリティ制御を可能な限りクラウドに移行する少なくとも 1 つの理由です。

覚えている限り、 シングル サインオン (SSO) の夢を追い求めてきました。 一部のお客様は、"適切な" フェデレーション (STS) プロバイダーを選択することでシングル サインオンを実現できると考えています。 Microsoft Entra IDは SSO 機能を有効にするために大きく役立ちますが、STS は魔法のような機能はありません。 重要なアプリケーションに引き続き使用される "レガシ" 認証方法が多すぎます。 パートナー ソリューションを使用してMicrosoft Entra IDを拡張すると、これらのシナリオの多くに対処できます。 SSO は戦略と体験です。 アプリケーションの標準に進まないと、そこに到達できません。 この記事に関連するのは、 パスワードレス 認証への旅であり、魔法のような答えもありません。

多要素認証 (MFA) は現在不可欠です (詳細についてはこちらをご覧ください )。 それにユーザー行動分析を追加すると、最も一般的なサイバー攻撃を防ぐソリューションがあります。 コンシューマー サービスでさえ、MFA を必要とするように移行しています。 しかし、私はまだ 最新の認証 アプローチに移行したくない多くの顧客と会っています。 私が聞く最大の議論は、それがユーザーとレガシアプリケーションに影響を与えるということです。 場合によっては、顧客が一緒に移動するのに良いキックが役立つ場合があります - 発表された変更Exchange Online。 多くのMicrosoft Entra レポートを使用して、この移行をお客様に役立てることができるようになりました。

Authorization

Wikipedia ごとに、"承認する" はアクセス ポリシーを定義することです。 多くのユーザーは、オブジェクト (ファイル、サービスなど) へのアクセス制御を定義する機能としてそれを見てみます。 サイバー脅威の現在の世界では、この概念は、さまざまな脅威ベクトルに反応し、それに応じてアクセス制御を迅速に調整できる動的ポリシーに急速に進化しています。 たとえば、通常とは異なる場所から銀行口座にアクセスすると、追加の確認手順が表示されます。 この現実にアプローチするには、ポリシー自体だけでなく、脅威検出とシグナル相関手法のエコシステムを検討する必要があります。

Microsoft Entra IDのポリシー エンジンは、条件付きアクセス ポリシーを使用して実装されます。 このシステムは、動的な意思決定を行うために、他の脅威検出システムからの情報に依存します。 単純なビューは、次の図のようになります。

Microsoft Entra IDのポリシー エンジン。

これらすべてのシグナルを組み合わせると、次のような動的ポリシーが可能になります。

  • デバイスで脅威が検出された場合、データへのアクセスは、ダウンロードする機能なしでのみ Web に削減されます。
  • 異常に大量のデータをダウンロードする場合、ダウンロードしたものは暗号化され、制限されます。
  • アンマネージド デバイスからサービスにアクセスする場合、機密性の高いデータはブロックされますが、別の場所にコピーすることなく、非依存データへのアクセスが許可されます。

この拡張された承認の定義に同意する場合は、追加のソリューションを実装する必要があります。 どのソリューションを実装するかは、ポリシーをどの動的にする必要があり、どの脅威に優先順位を付けるかによって異なります。 このようなシステムの例を次に示します。

Microsoft Entra IDに加えて、さまざまなサービスやアプリケーションには、独自の承認モデルがあります。 これらのモデルの一部については、「委任」セクションの後半で説明します。

監査

Microsoft Entra IDには、詳細な監査とレポート機能があります。 ただし、通常、これらのレポートは、セキュリティ上の決定を行うために必要な情報の唯一のソースではありません。 このテーマの詳細については、「委任」セクションを参照してください。

Exchange がない

焦らないで下さい！ Exchange は非推奨ではありません (または SharePoint など)。 これは依然としてコア サービスです。 つまり、テクノロジ プロバイダーは、かなり長い間、ユーザー エクスペリエンス (UX) を複数のサービスのコンポーネントを包含するように移行してきました。 Microsoft 365 では、簡単な例として、メールへの添付ファイルが SharePoint Online または OneDrive に格納される "最新の添付ファイル" があります。

メールにファイルを添付する。

Outlook クライアントを見ると、Exchange だけでなく、このエクスペリエンスの一部として "接続済み" の多くのサービスを確認できます。 たとえば、Microsoft Entra ID、Microsoft Search、アプリ、プロファイル、コンプライアンス、Microsoft 365 グループなどがあります。

吹き出しを含む Outlook インターフェイス。

今後の機能のプレビューについては、Microsoft 流動フレームワークに関する記事を参照してください。 プレビューでは、Outlook で Teams の会話を直接読んで返信できるようになりました。 実際、 Teams クライアント は、この戦略のより顕著な例の 1 つです。

全体的に見て、Microsoft 365 と Microsoft クラウド内の他のサービスとの間に明確な線を引くのは難しくなっています。 お客様が 1 つのコンポーネントを使用する場合でも、私たちが行うすべての全体にわたるイノベーションの恩恵を受けることができるので、お客様にとって大きなメリットと考えています。 かなりクールで、多くの顧客に大きな影響を与える。

現在、多くの顧客 IT グループが "製品" を中心に構成されていることがわかります。特定の製品ごとにエキスパートが必要なため、オンプレミスの世界にとって論理的です。 しかし、これらのサービスがクラウドに移行したので、Active Directory または Exchange データベースを再びデバッグする必要がないことを嬉しく思います。 自動化 (基本的にはクラウド) は、特定の反復的な手動ジョブを削除します (ファクトリに何が起こったかを確認します)。 ただし、これらのタスクは、サービス間の相互作用、効果、ビジネス ニーズなどを理解するためのより複雑な要件に置き換えられます。 学習する意思がある場合 は、クラウド変換によって有効になる優れた機会があります。 テクノロジに取り組む前に、IT スキルとチーム構造の変化の管理について、お客様とよく話しています。

すべての SharePoint ファンと開発者に対して、"SharePoint Online で XYZ を実行するにはどうすればよいですか? ワークフローには Power Automate (または Flow) を使用します。これははるかに強力なプラットフォームです。 Azure Bot Framework を使用して、500 K 項目リストに適した UX を作成します。 CSOM ではなく Microsoft Graph の使用を開始します。 Microsoft Teams には 、SharePoint だけでなく、より多くの世界も含まれています。 私がリストすることができる他の多くの例があります。 そこには広大で素晴らしい宇宙があります。 ドアを開き、 探索を開始します。

もう 1 つの一般的な効果は、コンプライアンス領域にあります。 このサービス間のアプローチは、多くのコンプライアンス ポリシーを完全に混乱させるようです。 "電子情報開示システムにすべての電子メール通信をジャーナルする必要があります" という状態の組織を見続けています。このステートメントは、電子メールがもはや単なるメールではなく、他のサービスへのウィンドウである場合、実際には何を意味しますか? Microsoft 365 には コンプライアンスに関する包括的なアプローチがありますが、多くの場合、人やプロセスの変更はテクノロジよりもはるかに困難です。

他にも多くの人やプロセスへの影響があります。 私の意見では、この要因は重要で議論の少ない領域です。 おそらく別の記事でもっと。

テナント構造オプション

シングル テナントとマルチテナント

一般に、ほとんどのお客様は運用テナントを 1 つだけ持つ必要があります。 複数のテナントが困難である ( Bing検索を提供する) 理由や、この ホワイト ペーパーを読むには、多くの理由があります。 同時に、私が一緒に働いている多くの企業顧客は、IT の学習、テスト、実験のための別の (小規模) テナントを持っています。 Azure Lighthouse を使用すると、テナント間の Azure アクセスが容易になります。 Microsoft 365 やその他の多くの SaaS サービスには、テナント間シナリオの制限があります。 Microsoft Entra B2B シナリオでは、考慮すべき点がたくさんあります。

多くのお客様は、合併と買収 (M&A) の後に複数の運用テナントを使用して終了し、統合したいと考えています。 今日では、単純ではなく、Microsoft コンサルティング サービス (MCS) またはパートナーとサード パーティ製ソフトウェアが必要になります。 将来、マルチテナントのお客様のさまざまなシナリオに対処するためのエンジニアリング作業が進行中です。

一部のお客様は、複数のテナントを使用することを選択します。 これは慎重な決定であり、ほとんどの場合、ビジネス上の理由が駆動されます。 いくつかの例には、次の理由が含まれます。

  • さまざまなエンティティ間の簡単なコラボレーションが必要ではなく、強力な管理やその他の分離のニーズがあるホールディングタイプの会社構造。
  • 買収後、2 つのエンティティを分離するようにビジネス上の決定が行われます。
  • 顧客の運用環境を変更しない顧客の環境のシミュレーション。
  • 顧客向けソフトウェアの開発。

このようなマルチテナント シナリオでは、多くの場合、テナント間で一部の構成を同じにしておくか、構成の変更とドリフトについて報告する必要があります。 これは、多くの場合、手動による変更からコードとしての構成への移行を意味します。 Microsoft Premiere サポートでは、このパブリック IP に基づいて、次の種類の要件に対するワークショップを提供しています。 https://Microsoft365dsc.com

Multi-Geo

[複数地域] または [複数地域] に設定します。 それが質問です。 Microsoft 365 Multi-Geo を使用すると、データ所在地の要件を満たすために選択した地域の場所に保存 データ をプロビジョニングして格納できます。 この機能には多くの誤解があります。 次の点に注意してください。

  • パフォーマンス上の利点はありません。 ネットワーク設計が正しくないと、パフォーマンスが低下する可能性があります。 Microsoft ネットワークに "近い" デバイスを取得します。必ずしもデータにアクセスするとは限りません。
  • GDPR コンプライアンスのソリューションではありません。 GDPR は、データ主権やストレージの場所に焦点を当てません。 データ主権またはストレージの場所には、他にもコンプライアンス フレームワークがあります。
  • 管理の委任 (下記参照) や 情報バリアは解決されません。
  • マルチテナントと同じではなく、より多くの ユーザー プロビジョニング ワークフローが 必要です。
  • テナント (Microsoft Entra ID) を別の地域に移動しません。

管理の委任

ほとんどの大規模な組織では、職務とロールベースのアクセス制御 (RBAC) の分離が必要な現実です。 私は事前に謝るつもりです。 このアクティビティは、一部の顧客が望むほど単純ではありません。 顧客、法律、コンプライアンス、その他の要件は異なり、世界中で競合する場合があります。 シンプルさと柔軟性は、多くの場合、互いの反対側にあります。 私を間違えないでください、私たちはこの目標でより良い仕事をすることができます。 時間の経過と同時に、大幅な改善が行われています (また、今後も)。 379,230 のドキュメントを読まずに、ビジネス要件に合ったモデルを作成するには、ローカル の Microsoft テクノロジ センター にアクセスしてください。 ここでは、なぜこの方法なのかではなく、考えるべきことについて焦点を当てます。 次の予定は、計画する 5 つの異なる領域と、私が遭遇する一般的な質問の一部です。

Microsoft Entra IDおよび Microsoft 365 管理センター

組み込みロールのリストは長く増え続けています。 各ロールは、特定のアクションの実行を許可するためにグループ化されたロールのアクセス許可の一覧で構成されます。 これらのアクセス許可は、各ロール内の [説明] タブで確認できます。 または、Microsoft 365 管理 センターで、これらのアクセス許可の人間が判読できるバージョンを確認することもできます。 組み込みロールの定義は変更できません。 私は一般的に、これらのロールを3つのカテゴリにグループ化します。

  • グローバル管理者: この "すべての強力な" ロールは、他のシステムと同様に高度に保護する必要があります。 一般的な推奨事項としては、永続的な割り当てがなく、Microsoft Entra Privileged Identity Management (PIM)、強力な認証などが使用されます。 興味深いことに、このロールは既定ですべてにアクセスできるわけではありません。 通常、コンプライアンス アクセスと Azure アクセスに関する混乱が見られ、後で説明します。 ただし、このロールは常にテナント内の他のサービスにアクセス権を割り当てることができます。
  • 特定のサービス管理者: 一部のサービス (Exchange、SharePoint、Power BI など) では、Microsoft Entra IDの高レベルの管理ロールが使用されます。 この動作はすべてのサービスで一貫しているわけではありません。また、後で説明するサービス固有のロールが増えています。
  • 機能: 特定の操作 (ゲスト招待者など) に焦点を当てたロールの長い (増え続ける) リストがあります。 これらのロールの多くは、顧客のニーズに基づいて定期的に追加されます。

すべてを委任することはできません (ただし、ギャップは減少しています)。つまり、グローバル管理者ロールを使用する必要がある場合があります。 このロールのメンバー メンバーシップではなく、コードとしての構成と自動化を考慮する必要があります。

注: Microsoft 365 管理センターにはわかりやすいインターフェイスがありますが、Microsoft Entra管理者エクスペリエンスと比較して機能のサブセットがあります。 どちらのポータルも同じMicrosoft Entraロールを使用するため、変更は同じ場所で行われます。 ヒント: Id 管理に重点を置いた管理 UI が必要な場合は、 を使用します https://aad.portal.azure.com。

名前の内容 ロールの名前から前提を立てないでください。 言語は正確なツールではありません。 目標は、必要なロールを確認する前に委任する必要がある操作を定義することです。 "セキュリティ閲覧者" ロールに誰かを追加しても、すべてのセキュリティ設定が表示されることはありません。

カスタム ロールを作成する機能は、一般的な質問です。 この機能は、現在Microsoft Entraでは制限されていますが (後で説明するように)、機能は時間の経過とともに拡大します。 私はこれらのカスタムロールをMicrosoft Entra IDの関数に適用可能であると考え、(前に説明したように)階層モデルを"ダウン"しない可能性があります。 "カスタム" を扱うたびに、"simple is better" のプリンシパルに戻る傾向があります。

もう 1 つの一般的な質問は、ディレクトリのサブセットにロールをスコープする機能です。 1 つの例として、"EU のユーザー専用ヘルプデスク管理者" のようなものがあります。 管理単位 は、このシナリオに対処することを目的としています。 前に説明したように、これらのスコープはMicrosoft Entra IDの関数に適用可能であると考え、"ダウン" にまたがらない可能性があります。特定のロールは、スコープ (グローバル管理者、サービス管理者など) には意味がありません。

現在、これらのロールはすべて直接メンバーシップ (または PIM を使用する場合は動的割り当て) Microsoft Entra必要です。 つまり、お客様はMicrosoft Entra IDでこれらのロールを直接管理する必要があり、これらのロールはセキュリティ グループメンバーシップに基づいて管理することはできません。 管理者特権で実行する必要があるため、これらのロールを管理するためのスクリプトを作成する必要はありません。 一般的に、ServiceNow などのプロセス システムと API を統合するか、Saviynt などのパートナー ガバナンス ツールを使用することをお勧めします。 時間の経過と同時にこの問題に対処するためのエンジニアリング作業が行われます。

私はPIM Microsoft Entra数回言及しました。 オンプレミスの制御に対応するMicrosoft Identity Manager (MIM) Privileged Access Management (PAM) ソリューションがあります。 また、Privileged Access Workstations (PAW) と Microsoft Entra ID ガバナンスを確認することもできます。 さまざまなサード パーティ製ツールもあります。これにより、Just-In-Time、just-enough、動的なロール昇格を有効にできます。 この機能は、通常、環境をセキュリティで保護するためのより大きな議論の一部です。

場合によっては、外部ユーザーをロールに追加することが必要になることがあります (前のマルチテナント セクションを参照)。 この結果は正常に動作します。 Microsoft Entra B2B は、おそらく別の記事で、顧客を説明するためのもう 1 つの大きく楽しい記事です。

Microsoft Defender XDRと Microsoft 365 Purview コンプライアンス ポータル

Microsoft Defender ポータルのEmail &コラボレーション ロールと、Microsoft 365 Purview コンプライアンス ポータルの Microsoft Purviewソリューションの *ロール グループは、Microsoft Entraロールとは別の "ロール グループ" のコレクションです。 これらの役割グループの中には、Microsoft Entraロールと同じ名前 (セキュリティ閲覧者など) が存在するが、メンバーシップが異なる場合があるため、混乱する可能性があります。 私はMicrosoft Entraロールの使用を好みます。 各役割グループは、1 つ以上の "ロール" で構成され (同じ単語を再利用する意味を参照してください)、Microsoft Entra IDのメンバー (電子メールが有効なオブジェクト) を持ちます。 また、ロールと同じ名前のロール グループを作成することもできます。これは、そのロールが含まれている場合と含まれていない場合があります (この混乱は避けてください)。

ある意味では、これらのアクセス許可は Exchange ロール グループ モデルの進化です。 ただし、Exchange Onlineには独自の役割グループ管理インターフェイスがあります。 Exchange Onlineの一部のロール グループは、Microsoft Entra IDまたはMicrosoft Defender XDRと Microsoft 365 Purview コンプライアンス ポータルからロックおよび管理されますが、同じ名前または類似の名前を持つものもあれば、Exchange Onlineで管理される場合があります (混乱が増します)。 Exchange 管理のスコープが必要な場合を除き、Exchange Online ユーザー インターフェイスを使用しないことをお勧めします。

カスタム ロールを作成することはできません。 ロールは Microsoft によって作成されたサービスによって定義され、新しいサービスが導入されるにつれて増加し続けます。 この動作は、概念的には、Microsoft Entra IDのアプリケーションによって定義されたロールと似ています。 新しいサービスが有効になっている場合、多くの場合、これらのサービスへのアクセスを許可または委任するために新しいロール グループを作成する必要があります (インサイダー リスク管理など)。

これらの役割グループには直接メンバーシップも必要であり、Microsoft Entra グループを含めることはできません。 残念ながら、現在、これらの役割グループは、Microsoft Entra PIM ではサポートされていません。 Microsoft Entraロールと同様に、API や Saviynt などのパートナー ガバナンス製品を使用して、これらの役割グループの管理を推奨する傾向があります。

Microsoft Defender ポータルと Microsoft 365 Purview コンプライアンス ポータルの役割は Microsoft 365 にまたがっており、これらの役割グループを環境のサブセット (Microsoft Entra IDの管理単位と同様) にスコープすることはできません。 多くのお客様が、どのようにサブ委任できるかを尋ねます。 たとえば、「EU ユーザーに対してのみ DLP ポリシーを作成する」などです。現在、Microsoft Defender XDRおよび Microsoft 365 Purview コンプライアンス ポータルで特定の機能に対する権限を持っている場合は、テナントでこの関数の対象となるすべてに対する権限があります。 ただし、多くのポリシーには、環境のサブセットを対象とする機能があります (たとえば、"これらの ラベル をこれらのユーザーのみが使用できるようにする" など)。 適切なガバナンスとコミュニケーションは、競合を回避するための重要なコンポーネントです。 一部のお客様は、Microsoft Defender XDRと Microsoft 365 Purview コンプライアンス ポータルでサブ委任に対処するための "コードとしての構成" アプローチを実装することを選択しています。 一部の特定のサービスでは、サブ委任がサポートされています (次のセクションを参照)。

サービス固有

前述のように、多くのお客様は、より詳細な委任モデルを実現することを検討しています。 一般的な例: "Division X ユーザーと場所に対してのみ XYZ サービスを管理する" (またはその他のディメンション)。 これを行う機能は、各サービスによって異なり、サービスと機能間で一貫性がありません。 さらに、各サービスには個別の一意の RBAC モデルが含まれる場合があります。 これらのモデルのすべてを議論する代わりに(永遠にかかるでしょう)、私は各サービスに関連するリンクを追加しています。 この一覧は完全ではありませんが、作業を開始できます。

  • Exchange Online - (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams - (/microsoftteams/itadmin-readiness)
  • 電子情報開示 - (../compliance/index.yml)
    • アクセス許可のフィルター処理 - (../compliance/index.yml)
    • コンプライアンス境界 - (../compliance/set-up-compliance-boundaryies.md)
    • 電子情報開示 (Premium) - (../compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multi-geo - (../enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

注:

このリンクはドキュメントのルートです。 管理者/委任モデルにはバリエーションを持つ複数の種類のサービスがあります。

  • Power Platform - (/power-platform/admin/admin-documentation)

    • Power Apps - (/power-platform/admin/wp-security)

      注:

      管理者/委任モデルにはバリエーションを持つ複数の型があります。

    • Power Automate - (/power-automate/environments-overview-admin)

    • Power BI - (/power-bi/service-admin-governance)

      注: データ プラットフォームのセキュリティと委任 (Power BI がコンポーネントである) は複雑な領域です。

  • Intune - (/mem/intune/fundamentals/role-based-access-control)

  • Microsoft Defender for Endpoint - (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (../security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps - (/cloud-app-security/manage-admins)

  • Stream - (/stream/assign-administrator-user-role)

  • 情報バリア - (../compliance/information-barriers.md)

アクティビティ ログ

Microsoft 365 には 統合監査ログがあります。 これは非常に 詳細なログですが、名前に読み込みすぎないようにしてください。 これには、セキュリティとコンプライアンスのニーズに必要なものがすべて含まれていない場合があります。 また、 監査 (Premium) に非常に関心があるお客様もいます。

他の API を介してアクセスされる Microsoft 365 ログの例には、次の機能があります。

まず、セキュリティとコンプライアンス プログラムに必要なすべてのログ ソースを特定することが重要です。 また、異なるログには、オンラインリテンション期間の制限が異なっていることにも注意してください。

管理者の委任の観点から見ると、ほとんどの Microsoft 365 アクティビティ ログには RBAC モデルが組み込まれません。 ログを表示するアクセス許可がある場合は、その中のすべてを表示できます。 顧客要件の一般的な例として、"EU ユーザーに対してのみアクティビティのクエリを実行できるようにしたい" (または他のディメンション) があります。 この要件を達成するには、ログを別のサービスに転送する必要があります。 Microsoft クラウドでは、 Microsoft Sentinel または Log Analytics に転送することをお勧めします。

概要図:

セキュリティとコンプライアンス プログラムのログ ソースの図。

この図は、Event Hubs や Azure Storage や Azure Log Analytics にログを送信するための組み込みの機能を表しています。 すべてのシステムに、このすぐに使用できる機能がまだ含まれているわけではありません。 ただし、これらのログを同じリポジトリに送信する方法は他にもあります。 たとえば、「 Microsoft Sentinel を使用した Teams の保護」を参照してください。

すべてのログを 1 つのストレージの場所に結合すると、相互相関、カスタムリテンション期間、RBAC モデルをサポートするために必要なデータによる拡張などの利点が追加されます。 このストレージ システムにデータが入ったら、適切な RBAC モデルを使用して Power BI ダッシュボード (または別の種類の視覚化) を作成できます。

ログを 1 か所のみに送信する必要はありません。 また、Microsoft 365 ログを Power BI のMicrosoft Defender for Cloud Appsまたはカスタム RBAC モデルと統合すると便利な場合もあります。 異なるリポジトリには、さまざまな利点と対象ユーザーがあります。

Microsoft Defender XDRと呼ばれるサービスには、セキュリティ、脅威、脆弱性などの豊富な組み込みの分析システムがあることに言及する価値があります。

多くの大規模な顧客は、このログ データをサード パーティのシステム (SIEM など) に転送したいと考えています。 この結果にはさまざまな方法がありますが、一般的なAzure Event Hubsと Graph は出発点として適しています。

Azure

多くの場合、Microsoft Entra ID、Azure、SaaS の間で高い特権ロールを分離する方法があるかどうかが尋ねられます (例: Microsoft 365 のグローバル管理者ですが、Azure ではありません)。 いやそうではありません。 完全な管理の分離が必要な場合はマルチテナント アーキテクチャが必要ですが、これは (前に説明したように) 非常に 複雑になります 。 これらのサービスはすべて、(階層モデルに示すように) 同じセキュリティ/ID 境界の一部です。

同じテナント内のさまざまなサービス間の関係を理解することが重要です。 Azure、Microsoft 365、Power Platform (多くの場合、オンプレミスおよびサードパーティのクラウド サービス) にまたがるビジネス ソリューションを構築している多くのお客様と協力しています。 1 つの一般的な例:

  1. 一連のドキュメント/イメージなどで共同作業を行いたい (Microsoft 365)
  2. 承認プロセスを通じて各プロセスを送信する (Power Platform)
  3. すべてのコンポーネントが承認されたら、これらの項目を統合成果物 (Azure) Microsoft Graph APIに組み立てて、ここで最高のフレンドになります。 不可能ではありませんが、 複数のテナントにまたがるソリューションを設計する方が非常に複雑です。

Azure Role-Based Access Control (RBAC) を使用すると、Azure のきめ細かいアクセス管理が可能になります。 RBAC を使用すると、ユーザーにジョブの実行に必要なアクセス許可を最も少なくすることで、リソースへのアクセスを管理できます。 このドキュメントの詳細は範囲外ですが、RBAC の詳細については、「 Azure でのロールベースのアクセス制御 (RBAC) とは」 を参照してください。RBAC は重要ですが、Azure のガバナンスに関する考慮事項の一部にすぎません。 クラウド導入フレームワークは、より多くのことを学ぶのに最適な出発点です。 私は友人 のアンドレス・ラヴィネットが、さまざまなコンポーネントをステップバイステップでお客様に歩み寄り、アプローチを決定する方法が好きです。 さまざまな要素の概要ビュー (実際の顧客モデルに到達するプロセスほど適切ではありません) は次のとおりです。

委任された管理のための Azure コンポーネントの概要ビュー。

上の図からわかるように、他の多くのサービスは設計の一部と見なす必要があります ( 例: Azure ポリシー、 Azure Blueprints、 管理グループなど)。

まとめ

この記事は短い要約として始まり、予想以上に長く終わりました。 これで、organizationの委任モデルの作成に関する深い理解を深める準備ができたらと思います。 この会話は、顧客と非常に一般的です。 すべてのユーザーに適したモデルは存在しません。 Microsoft エンジニアリングによるいくつかの計画的な改善を待ってから、お客様間で見られる一般的なパターンを文書化します。 その間、Microsoft アカウント チームと協力して、最寄りの Microsoft テクノロジ センターへの訪問を手配できます。 お会いしましょう。