Microsoft 365 でのアカウント管理
Microsoft は、ほとんどの Microsoft 365 操作を自動化するシステムと制御に多額の投資を行い、サービス担当者によるサーバーと顧客データへの直接アクセスの必要性を意図的に制限してきました。 人間がサービスを管理し、ソフトウェアがサービスを運営します。 この構造により、Microsoft は Microsoft 365 を大規模に管理でき、内部と外部の両方の脅威のリスクを最小限に抑えることができます。 Microsoft は、すべてのユーザーが Microsoft 365 サービスと顧客データに対する潜在的な脅威であると仮定して、アクセス制御に取り組みます。 このため、ゼロ スタンディング アクセス (ZSA) 原則は、Microsoft 365 で使用されるアクセス制御構造全体の基礎を築きます。
既定では、Microsoft 担当者は、organizationの Microsoft 365 環境または顧客データに対する永続的な特権アクセスをゼロにします。 サービス チームの担当者が、狭いアクションと時間範囲で特権アクセスを得ることができるのは、堅牢なチェックと承認のシステムを通じてのみです。 このシステムを通じて、Microsoft は、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 または顧客データへの特権アクセスを要求できません。 サービス チーム アカウントをロールに追加するには、別の要求を行う必要があります。これにより、サービス チーム メンバーは特定のタスクと操作を実行するために昇格された特権を要求できます。