Microsoft 365 サービス エンジニアのアクセスの制御

  • [アーティクル]

ゼロ スタンディング アクセス (ZSA) は、Microsoft サービス チームの担当者が Microsoft 365 運用環境や顧客データに対する永続的な特権アクセス権を持っていないことを意味します。 Microsoft サービス チーム メンバーが何らかの理由でサービスを更新したり、顧客データにアクセスしたりしたい場合は、ニーズを正当化する要求を送信し、承認されたマネージャーから承認を受ける必要があります。 大規模には、Microsoft 365 サービスを維持するために必要に応じてアクセスを手動で提供および削除することは不可能であるため、Microsoft は必要に応じて特権アクセスを管理するための自動ソリューションを開発しました。

ロックボックス

Microsoft 365 システムと顧客データへのすべてのアクセスは、Just-In-Time (JIT) モデルと Just-Enough-Access (JEA) モデルを使用して、サービス エンジニアに特定の Microsoft 365 サービスとデータへの一時的な特権アクセスを提供するアクセス制御システムである Lockbox によって仲介されます。 さらに、すべての要求とアクションは監査目的でログに記録され、Office 365管理アクティビティ API とセキュリティとコンプライアンス センターを使用してアクセスできます。

Microsoft サービス エンジニアが Microsoft 365 システムに接続したり、顧客データにアクセスしたりする前に、Lockbox を介してアクセス要求を送信する必要があります。 この要求は、特定の条件が満たされている場合にのみ承認できます。

  • サービス エンジニアは、 サービス チーム アカウントの適格性要件を満たしています。
  • これらは、要求の作業に関連付けられている Lockbox ロールに属しています。
  • 要求されたアクセス時間が、許可された最大時間を超えていない
  • 正当なビジネス上の正当な理由があります。
  • アクセスする要求されたリソースは、その作業スコープ内にあり、
  • マネージャーの承認を受ける

すべての条件が満たされ、Lockbox によって検証されると、要求された特定のアクションを実行するための一時的なアクセスが付与されます。 要求の時間が経過すると、アクセスは取り消されます。

ロックボックス フロー。

さらに、顧客がカスタマー ロックボックス 機能をライセンスして有効にした場合、Microsoft サービス エンジニアが顧客データにアクセスしようとする試みは、顧客テナントの管理者によってさらに承認される必要があります。 顧客データにアクセスする必要性は、顧客と Microsoft の両方から発生する可能性があります。 たとえば、お客様によって発生したインシデントでは、問題を解決するためにデータへのアクセスが必要な場合や、特定の更新プログラムを適用するために Microsoft がデータ アクセスを必要とする場合があります。

顧客には、カスタマー ロックボックス要求を開始するためのツールがありません。顧客ロックボックス要求を発生させる必要があるチケットを Microsoft に送信する必要があります。 Microsoft サービス エンジニアによって発行されたカスタマー ロックボックス要求は、Microsoft マネージャーと顧客テナントの承認された管理者によって承認される必要があります。

顧客のロックボックス フロー。

ロックボックスロール

職務の分離と最小限の特権の原則を適用するには、サービス エンジニアは、チームでの役割に対応する Lockbox ロールに属している必要があります。 ロックボックス ロールは、Identity Management ツール内で管理され、Lockbox 要求プロセスを通じてサービス チーム メンバーが承認できる権限とアクションを定義します。 サービス チームの担当者は、Lockbox ロールのメンバーを要求し、管理者の承認を受ける必要があります。 承認された場合、従業員のサービス チーム アカウントは、Active Directory (AD) と Microsoft Entra ID によって適用されるセキュリティ グループに配置されます。

制約付き管理インターフェイス

サービス エンジニアは、セキュリティで保護されたターミナル サービス ゲートウェイ (TSG) とリモート PowerShell を介して、Secure 管理 Workstation (SAW) からのリモート デスクトップという 2 つの管理インターフェイスを使用して管理タスクを実行します。 これらの管理インターフェイス内では、承認された Lockbox 要求とソフトウェア ポリシーに基づくアクセス制御によって、どのアプリケーションが実行され、使用できるコマンドとコマンドレットが大きく制限されます。

リモート デスクトップ

リモート デスクトップを使用してサービスを管理するサービス チーム メンバーは、特にこのユース ケースのために Microsoft によって管理されている SAW、特別に設計および製造されたノート PC から接続する必要があります。 Microsoft はサプライヤーと提携して SAW を構築し、短くて安全なサプライ チェーンを構築します。 SAW は、定義済みの管理タスクに必要な機能を除くすべての機能を制限するように構成された、強化されたオペレーティング システムを使用します。 これらの制限事項には、すべての USB ポートの無効化、厳密なアプリケーション アクセス リスト、電子メール アクセスの削除、インターネット閲覧の制限、非アクティブなスクリーン セーバーロックアウトの適用などがあります。 Microsoft のアクセス制御システムは、SAW マシンを定期的に調べて、最新のセキュリティ制御に準拠していることを確認し、マシンが非準拠であると判断された場合は自動的に無効にします。

サービス エンジニアは、一度に 1 つの TSG への接続のみが許可され、複数のセッションは許可されません。 ただし、TSG を使用すると、Microsoft 365 サービス チーム管理者は複数のサーバーに接続でき、それぞれが同時セッションが 1 つだけであるため、管理者は職務を効果的に実行できます。 サービス チーム管理者は、TSG 自体に対するアクセス許可を持っていません。 TSG は、多要素認証 (MFA) と暗号化の要件を適用するためにのみ使用されます。 サービス チーム管理者が TSG を介して特定のサーバーに接続すると、特定のサーバーは管理者ごとに 1 つのセッション制限を適用します。

Microsoft 365 担当者の使用制限、接続、構成の要件は、Active Directory グループ ポリシーによって確立されます。 これらのポリシーには、次の TSG 特性が含まれます。

  • FIPS 140-2 検証済み暗号化のみを使用する
  • 非アクティブ状態が 15 分後にセッションが切断される
  • セッションは 24 時間後に自動的にサインアウトする

TSG への接続には、別の物理スマート カードを使用した MFA も必要です。 サービス エンジニアは、さまざまなプラットフォームとシークレット管理プラットフォームに対して異なるスマート カードを発行し、資格情報の安全なストレージを確保します。 TSG では、Active Directory グループ ポリシーを使用して、リモート サーバーにログインできるユーザー、許可されるセッションの数、アイドル タイムアウト設定を制御します。

リモート PowerShell

特別に構成された TSG を使用したリモート アクセスに加えて、Service Engineer Operations Lockbox ロールを持つサービス チームの担当者は、リモート PowerShell を使用して運用サーバー上の特定の管理機能にアクセスできます。 このアクセスを使用するには、ユーザーが Microsoft 365 運用環境への読み取り専用 (デバッグ) アクセスを許可されている必要があります。 特権エスカレーションは、Lockbox プロセスを使用して TSG に対して有効にされるのと同じ方法で有効になります。

リモート アクセスの場合、各データセンターには、1 つのアクセス ポイントとして機能する負荷分散された仮想 IP があります。 使用可能なリモート PowerShell コマンドレットは、認証時に取得されたアクセス要求で識別される特権レベルに基づいています。 これらのコマンドレットは、このメソッドを使用して接続しているユーザーがアクセスできる唯一の管理機能を提供します。 リモート PowerShell では、エンジニアが使用できるコマンドの範囲が制限され、ロックボックス プロセスによって付与されるアクセス レベルに基づきます。 たとえば、Exchange Onlineでは、Get-Mailbox コマンドレットを使用できますが、Set-Mailbox コマンドレットは使用できません。

リソース