Microsoft は、ほとんどの Microsoft 365 操作を自動化するシステムと制御に多額の投資を行い、サービス担当者によるサーバーと顧客データへの直接アクセスの必要性を意図的に制限しています。 人間がサービスを管理し、ソフトウェアがサービスを運営します。 この構造により、Microsoft は Microsoft 365 を大規模に管理でき、内部と外部の両方の脅威のリスクを最小限に抑えることができます。 Microsoft は、すべてのユーザーが Microsoft 365 サービスと顧客データに対する潜在的な脅威であると仮定して、アクセス制御に取り組みます。 このため、ゼロ スタンディング アクセス (ZSA) 原則は、Microsoft 365 で使用されるアクセス制御構造全体の基礎を築きます。
既定では、Microsoft 担当者は、organizationの Microsoft 365 環境または顧客データに対する永続的な特権アクセスをゼロにします。 堅牢なチェックと承認システムを通じてのみ、サービス チームの担当者は、狭いアクションと時間範囲で特権アクセスを得ることができます。 このシステムを通じて、Microsoft 365 サービス担当者と攻撃者が不正なアクセスを取得したり、Microsoft サービスや顧客に悪意のあるまたは偶発的な損害を与えたりする可能性を大幅に削減します。
アカウントの種類
Microsoft 365 は、サービス チーム アカウント、サービス アカウント、顧客アカウントの 3 つのカテゴリを使用して、すべての組織のミッションとビジネス機能を満たしています。 これらのアカウントの管理は、Microsoft とお客様の間で共有される責任です。 Microsoft は、Microsoft の製品とサービスの運用とサポートに使用されるサービス チームとサービス アカウントの両方を管理します。 顧客は顧客アカウントを管理し、内部アクセス制御要件を満たすようにアカウント アクセスを調整できます。 Microsoft 企業アカウントは、このモデルでは顧客アカウントと見なされ、Microsoft によって管理されます。
Microsoft 管理アカウント
サービス チーム アカウント は、Microsoft 365 サービスを開発および保守する Microsoft 365 サービス チームの担当者によって使用されます。 これらのアカウントには、Microsoft 365 サービスへの永続的な特権アクセス権がありません。 代わりに、指定されたジョブ機能を実行するために、一時的かつ制限された特権アクセスを要求できます。 すべてのサービス チーム アカウントが同じアクションを実行できるわけではありません。 職務の分離は、ロールベースのアクセス制御 (RBAC) を使用して適用されます。 ロールにより、サービス チーム メンバーとそのアカウントは、特定の職務を実行するために必要な最小限のアクセス権しか持たないようにします。 さらに、サービス チーム アカウントは、自分のアクションの承認者として機能できる複数のロールに属することはできません。
サービス アカウント は、自動プロセスを通じて他のサービスと通信するときに認証するために Microsoft 365 サービスによって使用されます。 サービス チーム アカウントには、特定の担当者の職務を実行するために必要な最小限のアクセスのみが付与されるのと同様に、サービス アカウントには、目的に必要な最小限のアクセスのみが付与されます。 さらに、特定のニーズを満たすように複数の種類のサービス アカウントが設計されています。 1 つの Microsoft 365 サービスに複数のサービス アカウントがあり、それぞれが異なる役割を持つ場合があります。
顧客管理のアカウント
顧客アカウント は Microsoft 365 サービスにアクセスするために使用され、各顧客が責任を負う唯一のアカウントです。 お客様は、セキュリティで保護された環境を維持するために、organizationでアカウントを作成して管理する必要があります。 顧客アカウントの管理は、Microsoft Entra ID を介して行うか、オンプレミスの Active Directory (AD) とフェデレーションします。 各顧客には、満たす必要がある一意のアクセス制御要件があり、顧客アカウントは各顧客に個々のニーズを満たす機能を付与します。 顧客アカウントは、顧客organization以外のデータにアクセスできません。
サービス チーム アカウント管理
Microsoft 365 は、Identity Management (IDM) と呼ばれるアカウント管理システムを使用して、ライフサイクル全体を通じてサービス チーム アカウントを管理します。 IDM では、自動検証プロセスと管理承認の組み合わせを使用して、サービス チーム アカウントへのアクセスに関連するセキュリティ要件を適用します。
サービス チーム メンバーは、サービス チーム アカウントを自動的に取得しません。 最初に適格性要件を満たし、承認されたマネージャーから承認を受ける必要があります。 サービス チーム アカウントの資格を得るには、少なくともサービス チームの担当者は、まず雇用前担当者のスクリーニング、クラウドバックグラウンド チェックを経て、すべての標準および必要なロールベースのトレーニングを完了する必要があります。 シナリオによっては、追加の適格性要件が必要になる場合があります。 すべての資格要件が満たされたら、サービス チーム アカウントの要求を行い、承認されたマネージャーによって承認される必要があります。
IDM は、サービス チーム アカウントを維持するために必要な定期的な再画面とトレーニングの追跡も担当します。 Microsoft クラウドの背景チェックは、2 年ごとに完了し、すべてのトレーニング資料を毎年確認する必要があります。 これらの要件のいずれかが有効期限までに満たされない場合、資格は取り消され、サービス チーム アカウントは自動的に無効になります。
さらに、 人事異動と終了により 、サービス チーム アカウントの資格が自動的に更新されます。 人事情報システム (HRIS) で行われた変更により、IDM がアクションを実行します。これは状況によって異なります。 別のサービス チームに転送する担当者には、資格の有効期限が設定されています。 サービス チーム メンバーは、適格性を維持し、新しいマネージャーから承認を受けるために要求を送信する必要があります。 終了した担当者は、すべての資格が自動的に取り消され、最終日にサービス チーム アカウントが無効になります。 アカウント失効の緊急要求は、不本意な終了に対して行うことができます。
既定では、サービス チーム アカウントでは、通常のトラブルシューティングに使用される広範なシステム メタデータへの読み取りアクセスが制限されています。 さらに、ベースライン サービス チーム アカウントは、Microsoft 365 または顧客データへの特権アクセスを要求できません。 特定のタスクと操作を実行するために、サービス チーム メンバーが昇格された特権を要求できるようにするロールにサービス チーム アカウントを追加するには、別の要求を行う必要があります。