Essential Eight の管理特権の制限

この記事では、Microsoft ID プラットフォームを使用して管理特権を制限するためのオーストラリアサイバー セキュリティ センター (ACSC) Essential Eight Maturity Model を実現するための方法について詳しくは、こちらの記事をご覧ください。 管理特権の制限に関する ACSC 成熟度モデル ガイドラインは、ACSC Essential8 成熟度モデルに記載されています。

ACSC Essential Eight の管理特権制限ガイドラインを追求する理由

オーストラリアサイバーセキュリティセンター(ACSC)は、サイバーセキュリティの向上に向けたオーストラリア政府の取り組みをリードしています。 ACSC は、オーストラリアのすべての組織に対し、ACSC のサイバー セキュリティ インシデントを軽減するための戦略の基本 8 つの軽減戦略をベースラインとして実装することを推奨しています。 Essential Eight と呼ばれるベースラインは、敵対者がシステムを侵害するのをはるかに困難にする基本的なサイバー セキュリティ対策です。 必須の 8 つの成熟度レベルを使用すると、組織は、今日の相互接続された ICT 環境における一般的な脅威に対するサイバー セキュリティ対策の妥当性を評価できます。

悪意のあるアクターの目標は、特権資格情報 、特にエンタープライズ コントロール プレーンにアクセスできる資格情報にアクセスすることです。 コントロール プレーン アクセスは、エンタープライズ ICT 環境内の価値の高い資産に対する広範なアクセスと制御を提供します。 コントロール プレーン アクセスの例としては、グローバル管理者と、Microsoft Entra ID内の同等の特権、エンタープライズ仮想化インフラストラクチャへの特権アクセスなどがあります。

多層アプローチを使用して特権アクセスを制限すると、敵対者が悪意のあるアクティビティを行うのが難しくなります。 管理特権の制限は、 ACSC のサイバー セキュリティ インシデントを軽減するための戦略に含まれる非常に効果的な制御です。

次の表は、管理特権の制限に関連する ISM コントロールの概要を示しています。

管理特権を制限する: Essential8 要件

特権アクセスを使用すると、管理者は、ID サービス、ビジネス システム、ネットワーク デバイス、ユーザー ワークステーション、ユーザー アカウントなどの主要なアプリケーションとインフラストラクチャの構成を変更できます。 特権アクセスまたは資格情報は、多くの場合、ネットワーク内の多くの異なる資産を制御するベアラーを提供するため、"王国のキー" と呼ばれます。

管理特権の制限に関する必須の 8 つの成熟度レベル 3 を達成するには、次のカテゴリのコントロールが必要です。

• ID ガバナンス: ID ガバナンスは、ユーザー アクセス要件を検証し、不要になったアクセスを削除するプロセスです。
• 最小特権: 最小特権は、システム、アプリケーション、およびデータ リポジトリへのアクセスを、ユーザーとサービスが職務を遂行するために必要なもののみに制限するアクセス制御のアプローチです。
• アカウントの制限: アカウントの制限により、特権を持たない環境への特権資格情報の公開が減ります。
• 管理デバイス: 管理デバイスは、管理アクティビティを実行するために使用されるセキュリティで保護されたオペレーティング環境です。
• ログ記録と監視: 特権アクティビティのログ記録と監視により、侵害の兆候を検出できます。

ID ガバナンス

Identity Governance は、組織の生産性とセキュリティのバランスを取るのに役立ちます。 ID ライフサイクル管理は ID ガバナンスの基盤であり、大規模な効果的なガバナンスには最新の ID ライフサイクル管理インフラストラクチャが必要です。

エンタイトルメント管理 (ML1)

Essential8 成熟度レベル 1 では、システム、アプリケーション、およびデータ リポジトリへの特権アクセスの要求が最初に要求されたときに検証される必要があります。 特権アクセス要求の検証は、エンタイトルメント管理プロセスの一部です。 エンタイトルメント管理は、権限を持つユーザーのみが一連のリソースにアクセスできるように、権限へのユーザー アクセスを管理するプロセスです。 エンタイトルメント管理プロセス内の主要な手順には、アクセス要求、アクセス レビュー、アクセス プロビジョニング、アクセスの有効期限があります。

Microsoft Entraエンタイトルメント管理は、Azure 内のリソースへのアクセスを管理するプロセスを自動化します。 ユーザーは、リソースのバンドルであるアクセス パッケージを使用して、アクセスを委任できます。 Microsoft Entraエンタイトルメント管理の Access パッケージには、セキュリティ グループ、Microsoft 365 グループ、Teams、エンタープライズ アプリケーション、SharePoint Online サイトMicrosoft Entra含めることができます。 アクセス パッケージには、1 つ以上のポリシーが含まれます。 ポリシーは、パッケージにアクセスするための割り当てのルールまたはガードレールを定義します。 ポリシーを使用すると、適切なユーザーのみがアクセスを要求でき、アクセス要求の承認者が割り当てられ、リソースへのアクセスが制限され、更新されていない場合は期限切れになります。

エンタイトルメント管理の詳細については、「エンタイトルメント管理のMicrosoft Entra」を参照してください。

非アクティブなユーザーの管理 (ML2)

Essential8 成熟度レベル 2 では、非アクティブ状態の 45 日後に、システムとアプリケーションへの特権アクセスが自動的に無効になる必要があります。 非アクティブなアカウントは、organizationで不要になったユーザー アカウントまたはシステム アカウントです。 非アクティブなアカウントは通常、サインイン ログを通じて識別できます。これは、長期間サインインに使用されていないことを示します。 最後のサインイン タイムスタンプを使用して、非アクティブなアカウントを検出できます。

最後のサインインは、リソースへのアクセスに対するユーザーの継続的なニーズに関する潜在的な分析情報を提供します。 これは、グループ メンバーシップまたはアプリアクセスがまだ必要かどうか、または削除される可能性があるかどうかを判断するのに役立ちます。 ゲスト ユーザー管理では、ゲスト アカウントがまだテナント内でアクティブであるか、クリーンアップする必要があるかどうかを理解できます。

非アクティブなアカウントを検出するには、Microsoft Graph APIの signInActivity リソースの種類によって公開される lastSignInDateTime プロパティを評価します。 lastSignInDateTime プロパティは、ユーザーが最後にMicrosoft Entra IDへの対話型サインインに成功した時刻を示します。 このプロパティを使用すると、次のシナリオのソリューションを実装できます。

• すべてのユーザーの最終サインイン日時: このシナリオでは、すべてのユーザーの最後のサインイン日のレポートを生成する必要があります。 すべてのユーザーの一覧と、それぞれのユーザーの最後の lastSignInDateTime を https://graph.microsoft.com/v1.0/users?$select=displayName,signInActivity で要求できます。

• ユーザー名: このシナリオでは、特定のユーザーを名前で検索します。これにより、lastSignInDateTime を評価できます。

  • https://graph.microsoft.com/v1.0/users?$filter=startswith(displayName,'markvi')&$select=displayName,signInActivity

• 日付別ユーザー: このシナリオでは、指定した日付より前に lastSignInDateTime を持つユーザーの一覧を要求します。

  • https://graph.microsoft.com/v1.0/users?$filter=signInActivity/lastSignInDateTime le 2019-06-01T00:00:00Z

非アクティブなユーザーの管理の詳細については、「非 アクティブなユーザー アカウントの管理」を参照してください。

最小限の特権

最小限の特権では、システムとアプリケーションへのアクセスが、ユーザーとシステムが職務を遂行するために必要なもののみに制限されている必要があります。 ロールベースのアクセス制御 (RBAC)、特権アクセス管理、Just-In-Time (JIT) アクセスなどの制御を使用して、最小特権を実装できます。

管理者用のアカウントを分離する (ML1)

Essential8 成熟度レベル 1 では、特権ユーザーに、特権アクセスを必要とする職務のみに使用する専用の特権ユーザー アカウントが割り当てられている必要があります。 Microsoft Entra ID、Azure、Microsoft 365 の高レベルの特権を持つアカウントは、オンプレミスの Active Directory ドメインから同期されたアカウントではなく、クラウド専用アカウントである必要があります。 管理アカウントは、電子メール (ライセンスの削除) などの生産性ツールの使用Office 365ブロックする必要があります。

管理アクセスの管理の詳細については、「 ハイブリッドおよびクラウドデプロイの特権アクセスのセキュリティ保護」を参照してください。

管理者に条件付きアクセスを適用する (ML1)

Essential8 成熟度レベル 1 では、特権ユーザーが個別の特権と特権のない運用環境を使用する必要があります。 Azure および Microsoft 365 環境への特権アクセスには、通常のユーザーに適用される標準よりも高いセキュリティ標準が必要です。 ゼロ トラスト戦略をサポートするには、シグナルとセキュリティ属性の組み合わせに基づいて特権アクセスを付与する必要があります。 Azure または Microsoft 365 への特権アクセスを持つアカウントが侵害されると、ビジネス プロセスが大幅に中断される可能性があります。 条件付きアクセスでは、Azure 管理ツールへのアクセスを許可する前に、セキュリティの一定の基準を適用することで、侵害のリスクを軽減できます。

Azure portalおよびコマンド ライン管理ツールへの管理アクセスには、次のコントロールを実装することをお勧めします。

• 多要素認証 (MFA) を要求する
• Microsoft Identity Protection からの高いサインイン リスク レベルでアクセス試行をブロックする
• Microsoft Identity Protection からの高いユーザー リスク レベルでのアクセス試行をブロックする
• Microsoft Entra参加済みデバイスからのアクセスを要求します。これは、デバイスの正常性、更新状態、およびシステム セキュリティの状態に関するIntuneコンプライアンス要件を満たしています

管理者の条件付きアクセスの適用の詳細については、次の記事を参照してください。

• 特権アカウント
• Microsoft Privileged Access モデル

ローカル管理者アカウントの管理 (ML2)

Essential 8 成熟度レベル 2 では、ブレーク グラス アカウント、ローカル管理者アカウント、サービス アカウントの資格情報が長く、一意で予測不可能で管理されている必要があります。 Windows ワークステーション上のアクティブなローカル管理者アカウントは、多くの場合、Windows 環境を横方向に走査するために攻撃者によって使用されます。 このため、ドメインに参加しているシステムのローカル管理者アカウントには、次の制御が推奨されます。

Active Directory 参加済みシステム

Microsoft のローカル管理者パスワード ソリューション (LAPS) は、すべてのコンピューターで同じパスワードで共通のローカル アカウントを使用する問題の解決策を提供します。 LAPS では、ドメイン内のすべてのコンピューターでローカル管理者アカウントに対して異なるローテーションされたランダム パスワードを設定することで、この問題を解決します。 パスワードは Active Directory に格納され、制限付きAccess Control Listsによって保護されます。 ローカル管理者パスワードは、対象ユーザーのみが取得またはリセットできます。

Active Directory 参加済みシステムでのローカル管理者アカウントの管理の詳細については、次の記事を参照してください。

• ローカル管理者パスワード ソリューションを確認してダウンロードする
• Microsoft LAPS を構成する方法について説明します

Microsoft Entra参加済みシステム

windows デバイスに参加してMicrosoft Entra参加を使用してMicrosoft Entra IDすると、Microsoft Entra IDデバイスのローカル Administrators グループに次のセキュリティ原則が追加されます。

• Microsoft Entra グローバル管理者ロール
• Azure AD 参加済みデバイスローカル管理者ロール
• Microsoft Entra参加を実行しているユーザー

ビジネス要件を満たすために、ローカルの Administrators グループのメンバーシップをカスタマイズできます。 ローカル管理者アクセスをワークステーションに制限し、Azure AD 参加済みデバイス ローカル管理者ロールを使用するために PIM の承認を要求することをお勧めします。

Azure portalでは、デバイス設定からデバイス管理者ロールを管理できます。

1. グローバル管理者としてAzure portalにサインインします。
2. [デバイス] > [デバイス設定] のMicrosoft Entra ID >を参照します。
3. [Manage Additional local administrators on all Microsoft Entra joined devices]\(追加のローカル管理者の管理\) Microsoft Entra選択します。
4. [ 割り当ての追加] を選択し、追加する他の管理者を選択し、[追加] を選択 します。

デバイス管理者ロールを変更するには、参加しているすべてのデバイスで追加のローカル管理者Microsoft Entra構成します。

参加済みシステムでのローカル管理者の管理Microsoft Entra詳細については、次の記事を参照してください。

• 参加済みデバイスでローカル管理者Microsoft Entra管理する方法について説明します
• Windows LAPS の概要

サービス アカウントの管理 (ML2)

開発者にとって一般的な課題は、サービス間の通信をセキュリティで保護するために使用されるシークレット、資格情報、証明書、キーの管理です。 Essential8 成熟度レベル 2 では、サービス アカウントの資格情報が長く、一意で、予測不可能で、管理されている必要があります。

Active Directory 参加済みシステム

グループ管理サービス アカウント (gMSA) は、サービスのセキュリティ保護に役立つドメイン アカウントです。 gMSA は、ネットワーク負荷分散またはインターネット インフォメーション サービス (IIS) サーバーの背後にあるシステムなど、1 つのサーバーまたはサーバー ファームで実行できます。 gMSA プリンシパルを使用するようにサービスを構成すると、アカウント パスワード管理は Windows オペレーティング システム (OS) によって処理されます。

gMSA は、管理オーバーヘッドを減らすのに役立つセキュリティが強化された ID ソリューションです。

• 強力なパスワードの設定: 240 バイトのランダムに生成されたパスワード: gMSA パスワードの複雑さと長さは、ブルート フォース攻撃や辞書攻撃による侵害の可能性を最小限に抑えます。
• パスワードを定期的に繰り返す: パスワード管理は Windows OS に移動し、30 日ごとにパスワードが変更されます。 サービス管理者とドメイン管理者は、パスワードの変更をスケジュールしたり、サービスの停止を管理したりする必要はありません。
• サーバー ファームへのデプロイのサポート: 複数のホストが同じサービスを実行する負荷分散ソリューションをサポートするために、gMSA を複数のサーバーにデプロイします。
• 簡略化されたサービス プリンシパル名 (SPN) 管理をサポートする - アカウントを作成するときに、PowerShell で SPN を設定します。

Microsoft Entra参加済みシステム

マネージド ID は、Microsoft Entra認証をサポートするリソースに接続するときにアプリケーションが使用するために、Microsoft Entra IDで自動的にマネージド ID を提供します。 アプリケーションでは、マネージド ID を使用して、資格情報を管理することなくMicrosoft Entra トークンを取得できます。

マネージド ID には、次の 2 種類があります。

• システム割り当て。 サービス プリンシパルは、リソース ID のMicrosoft Entra IDで自動的に作成されます。 サービス プリンシパルは、その Azure リソースのライフサイクルに関連付けられています。 Azure リソースが削除されると、関連付けられているサービス プリンシパルが Azure によって自動的に削除されます。
• ユーザー割り当て。 サービス プリンシパルは、リソース ID のMicrosoft Entra IDで手動で作成されます。 サービス プリンシパルは、それを使用するリソースとは別に管理されます。

システムとアプリケーションへの Just-In-Time アクセス (ML3)

Azure または Microsoft 365 の高い特権ロールのメンバーであるアカウントに永続的な永続的なアクセス権を割り当てないでください。 攻撃者は、エンタープライズ環境での永続化を維持し、システムに広範な損害を与えるために、永続的な特権を持つアカウントを頻繁にターゲットにします。 一時的な特権により、攻撃者は、ユーザーが特権を昇格するのを待つか、特権の昇格を開始するように強制されます。 特権昇格アクティビティを開始すると、攻撃者が損害を与える前に検出および削除される可能性が高くなります。

次の方法を使用して、必要に応じてのみ特権を付与します。

• Just-In-Time アクセス: 特権ロールへのアクセス権を取得するために承認ワークフローを要求するようにMicrosoft Entra Privileged Identity Management (PIM) を構成します。 少なくとも、グローバル管理者、特権認証管理者、特権ロール管理者、条件付きアクセス管理者、Intune管理者の特権Microsoft Entraロールには昇格が必要です。 少なくとも、特権を持つ Azure RBAC ロール (所有者と共同作成者) に昇格が必要です。
• ガラスアカウントを分割する: 緊急アクセス アカウントは、通常の管理アカウントを使用できない緊急または "ガラスを壊す" シナリオに限定されます。 たとえば、Microsoft Entra テナントからロックアウトされているすべての管理者。 強いパスワードを設定し、緊急時にのみ緊急アクセス アカウントを使用してください。 緊急アクセス アカウントの *.onmicrosoft.com ドメインを使用してクラウド専用アカウントを作成し、サインイン時にアラートを生成するように監視を構成します。

アクセス レビュー (ML3)

Essential8 成熟度レベル 3 では、システムとアプリケーションへの特権アクセスは、ユーザーとサービスが職務を遂行するために必要なもののみに制限されている必要があります。 Azure リソースとMicrosoft Entra ロールへの特権アクセスの必要性は、時間の経過と同時に変化します。 古いロールの割り当てに関連するリスクを軽減するには、定期的にアクセスを確認する必要があります。 Microsoft Entraアクセス レビューを使用すると、組織は RBAC グループ メンバーシップ、エンタープライズ アプリケーションへのアクセス、Microsoft Entraロールの割り当てを効率的に管理できます。 ユーザー アクセスを定期的に確認して、適切なユーザーのみが引き続きアクセス権を持っていることを確認できます。

Microsoft Entraアクセス レビューを使用すると、次のようなユース ケースが有効になります。

• 過剰なアクセス権の特定
• グループが新しい目的で使用されるタイミングを識別する
• ユーザーがチームを移動したり退職したりすると、不要なアクセスが削除されます
• リソース所有者とのプロアクティブなエンゲージメントを有効にして、リソースへのアクセス権を持つユーザーを定期的に確認できるようにします。

レビューを必要とするアクセスの種類に応じて、Azure portalのさまざまな領域でアクセス レビューを作成する必要があります。 次の表は、アクセス レビューを作成するための特定のツールを示しています。

Microsoft Entraアクセス レビューの詳細については、次の記事を参照してください。

• Microsoft Entra アクセス レビューの詳細
• Microsoft Entra アクセス レビューを使用してユーザー アクセスを管理する方法について説明します

アカウントの制限

アカウントのセキュリティは、特権アクセスをセキュリティで保護するための重要なコンポーネントです。 エンド ツー エンドのゼロ トラストセキュリティでは、セッションで使用されているアカウントが実際には人間の所有者の管理下にあり、攻撃者が偽装していることを確認する必要があります。

ログイン制限 (ML1)

Windows Active Directory (AD) ドメインの管理者権限を持つユーザー、サービス、またはアプリケーション アカウントは、エンタープライズ セキュリティに対して高いリスクを伴います。 多くの場合、これらのアカウントは、サーバー、データベース、アプリケーションへの広範なアクセスを提供するため、攻撃者の対象となります。 管理者がセキュリティ プロファイルが低いシステムにログインすると、特権資格情報がメモリに格納され、資格情報の盗難ツール (Mimikatz など) を使用して抽出できます。

Essential8 成熟度レベル 1 では、特権ユーザー アカウント (ローカル管理者アカウントを除く) が特権のない運用環境にログオンできないことが必要です。 Microsoft 階層管理モデルは、ドメイン参加済みデバイスにログイン制限を適用して、セキュリティ プロファイルが低いデバイスで特権資格情報が公開されないようにします。 Active Directory ドメインへの管理者アクセス権を持つ管理者は、ワークステーションとエンタープライズ アプリケーションを制御する管理者から分離されます。 高い特権を持つアカウントが安全性の低いリソースにログインできないようにするには、ログオン制限を適用する必要があります。 以下に例を示します。

• Active Directory Enterprise グループと Domain Admins グループのメンバーは、ビジネス アプリケーション サーバーとユーザー ワークステーションにログオンできません。
• Microsoft Entra Global Admins ロールのメンバーは、参加しているワークステーションMicrosoft Entraログオンできません。

ログオン制限は、グループ ポリシーユーザー権利の割り当てまたはMicrosoft Intune ポリシーで適用できます。 特権アカウントが信頼されていないシステムに資格情報を公開しないように、エンタープライズ サーバーとユーザー ワークステーションで次のポリシーを構成することをお勧めします。

• ネットワークからこのコンピューターへのアクセスを拒否する
• バッチ ジョブとしてのログオンを拒否する
• サービスとしてのログオンを拒否する
• ローカルでのログオンを拒否する
• ターミナル サービスを使用してログオンを拒否する

インターネット、電子メール、Web サービスへのアクセスを制限する (ML1)

Essential8 成熟度レベル 1 では、特権アカウント (オンライン サービスへのアクセスを明示的に承認されたアカウントを除く) がインターネット、電子メール、Web サービスにアクセスできないようにする必要があります。 管理アカウントは、電子メール (ライセンスの削除) などの生産性ツールの使用Office 365ブロックする必要があります。 管理アカウントは、特権アクセス デバイスからクラウド管理ポータルにアクセスする必要があります。 特権アクセス デバイスでは、すべての Web サイトを拒否し、許可リストを使用してクラウド管理ポータルへのアクセスを有効にする必要があります。 特権アクセス デバイスからのインターネットと電子メールの制御は、ホスト ベースのファイアウォール、クラウド プロキシ、またはデバイスのプロキシ設定を構成することによって実行できます。

Microsoft Entra 参加済みデバイス

Microsoft Intune構成プロファイルを作成して、特権管理に使用されるデバイスでネットワーク プロキシを構成します。 Azure および Microsoft 365 クラウド サービスの管理に使用される Privileged Access デバイスでは、次の表のプロキシの除外を使用する必要があります。

管理デバイス

システム管理者は、特権を持つオペレーティング環境と特権のないオペレーティング環境を管理するために、個別のデバイスを使用する必要があります。 管理アクティビティは、管理プロセスに関連するすべてのデバイスのクリーンソース原則に従う必要があります。

特権を持つオペレーティング環境と特権のないオペレーティング環境を分離する (ML1)

Essential8 成熟度レベル 1 では、特権ユーザーが個別の特権と特権のない運用環境を使用する必要があります。 さまざまな物理ワークステーションを使用することは、システム管理者の特権を持つオペレーティング環境と特権のないオペレーティング環境を分離するための最も安全なアプローチです。 セキュリティ保証はセッションで強化される可能性があります。これらは常に、元のデバイスの保証の強さによって制限されます。 特権アクセス デバイスを制御する攻撃者は、ユーザーを偽装したり、将来の偽装のためにユーザーの資格情報を盗んだりすることができます。 このリスクは、アカウント、ジャンプ サーバーなどの中継局、およびリソース自体の他の保証を損ないます。

個別の物理ワークステーションを使用して特権と特権のない運用環境を分離できない組織は、リスクベースのアプローチを採用し、多層セキュリティ戦略の防御に従って代替制御を実装する必要があります。 Microsoft では、特権オペレーティング環境を保護するために必要な保証レベルを評価するために、ユーザー ロールと資産を秘密度レベルにマッピングすることをお勧めします。

特権アクセスの秘密度レベルの詳細については、「特権アクセス セキュリティ レベル」を参照してください。

セキュリティで保護された管理 ワークステーション (ML3)

Essential 8 成熟度レベル 3 では、管理アクティビティを実行するために Secure 管理 Workstations を使用する必要があります。 セキュリティで保護された管理 ワークステーション (SAW) は、安全性の低いデバイスでの機密性の高い資格情報の公開に対する効果的な制御です。 特権アカウントを使用して、セキュリティの低いデバイスにサービスをログオンまたは実行すると、資格情報の盗難や特権エスカレーション攻撃のリスクが高まります。 特権資格情報は SAW キーボードにのみ公開し、セキュリティの低いデバイスへのログオンを拒否する必要があります。 SAW は、オンプレミス、Azure、Microsoft 365、サード パーティのクラウド サービスを管理するためのセキュリティで保護されたプラットフォームを提供します。 SAW デバイスは、Microsoft Intuneを使用して管理され、Defender for Endpoint、Windows Hello for Business、Microsoft Entra ID コントロールの組み合わせを使用してセキュリティで保護されます。

次の図は、ソリューション全体と SAW フレームワークを実装するように構成する必要があるさまざまなテクノロジ コンポーネントを含む、高レベルのアーキテクチャを示しています。

Secure 管理 Workstations の詳細については、次の記事を参照してください。

• 特権アクセス デバイスについて学習する
• セキュリティで保護されたワークステーションを展開する方法について説明します
• 特権ワークステーション プロファイルを確認してダウンロードする

中継サーバーとジャンプ サーバーをセキュリティで保護する (ML2)

中間サービスのセキュリティは、特権アクセスをセキュリティで保護するための重要なコンポーネントです。 仲介は、管理者のセッションまたはリモート システムまたはアプリケーションへの接続を容易にするために使用されます。 中継の例としては、仮想プライベート ネットワーク (VPN)、ジャンプ サーバー、仮想デスクトップ インフラストラクチャ (Windows 365と Azure Virtual Desktop を含む)、アクセス プロキシを介したアプリケーションの公開などがあります。 攻撃者は、多くの場合、仲介者をターゲットにして、保存されている資格情報を使用して特権をエスカレートしたり、企業ネットワークへのネットワーク リモート アクセスを取得したり、特権アクセス デバイスの信頼を悪用したりします。

中間の種類によって一意の関数が実行されるため、それぞれに異なるセキュリティ アプローチが必要です。 攻撃者は、攻撃面が大きいシステムを簡単にターゲットにできます。 次の一覧には、特権アクセス中継局で使用できるオプションが含まれています。

• Microsoft Entra Privileged Identity Management (PIM)、Azure Bastion、Microsoft Entra アプリケーション プロキシなどのネイティブ クラウド サービスは、攻撃者に限られた攻撃面を提供します。 パブリック インターネットに公開されている間、顧客 (および攻撃者) は基になるインフラストラクチャにアクセスできなくなります。 SaaS サービスと PaaS サービスの基になるインフラストラクチャは、クラウド プロバイダーによって維持および監視されます。 この小さい攻撃対象領域では、IT 担当者が構成、修正プログラムを適用、監視する必要がある従来のオンプレミス アプリケーションとアプライアンスに対して、使用可能なオプションが制限されます。
• 仮想プライベート ネットワーク (VPN)、リモート デスクトップ、ジャンプ サーバーは、回復性のあるセキュリティ体制を維持するために継続的なパッチ適用、セキュリティ強化、メンテナンスが必要なサービスであるため、重大な攻撃者の機会を提供します。 ジャンプ サーバーには少数のネットワーク ポートしか公開されていない可能性があります。攻撃者は、攻撃を実行するためにパッチが適用されていない 1 つのサービスにのみアクセスする必要があります。
• サード パーティ製Privileged Identity Management (PIM) サービスと Privileged Access Management (PAM) サービスは、オンプレミスまたはサービスとしてのインフラストラクチャ (IaaS) 上の VM として頻繁にホストされ、通常はイントラネット ホストでのみ使用できます。 インターネットに直接公開されるわけではありませんが、1 つの資格情報が侵害されると、攻撃者が VPN または別のリモート アクセス メディア経由でサービスにアクセスできる可能性があります。

特権アクセス中継局の詳細については、「 セキュリティで保護された中継局」を参照してください。

ログ記録と監視

特権アクセス イベントのログ記録 (ML2)

特権アカウントによって実行されるサインインとアクティビティのログ記録は、エンタープライズ環境内の異常な動作を検出するために不可欠です。 Microsoft Entra監査ログとサインイン ログは、アプリケーションとサービスへの特権アクセスに関する貴重な分析情報を提供します。

サインイン ログMicrosoft Entra、サインイン パターン、サインイン頻度、サインイン アクティビティの状態に関する分析情報が提供されます。 サインイン アクティビティ レポートは、Microsoft Entra IDのすべてのエディションで使用できます。 Microsoft Entra ID P1 または P2 ライセンスを持つ組織は、Microsoft Graph APIを通じてサインイン アクティビティ レポートにアクセスできます。

Microsoft Entraアクティビティ ログには、Microsoft Entra IDに記録されたすべてのイベントの監査ログが含まれます。 アプリケーション、グループ、ユーザー、ライセンスに対する変更はすべて、Microsoft Entra監査ログにキャプチャされます。 既定では、Microsoft Entra IDはサインイン ログと監査ログを最大 7 日間保持します。 Microsoft Entra IDは、Microsoft Entra ID P1 または P2 ライセンスがテナントに存在する場合、ログを最大 30 日間保持します。 監査ログとサインイン ログMicrosoft Entra、一元的な収集と関連付けを行うために、Azure Log Analytics ワークスペース (LAW) に転送する必要があります。

一元化されたログ記録の詳細については、次の記事を参照してください。

• Azure 監査ログ
• Azure Sign-In ログ
• データ保持のMicrosoft Entra

セキュリティ侵害の兆候のイベント ログの監視 (ML3)

Essential8 成熟度レベル 3 では、侵害の兆候がないかイベント ログを監視し、侵害の兆候が検出されたときにアクションを実行する必要があります。 特権アクティビティの監視は、システムの侵害を早期に検出し、悪意のあるアクティビティのスコープを含めるために重要です。

特権アクセス イベントの監視

Microsoft Entraサインイン ログをデータ ソースとして使用して、すべての特権アカウント サインイン アクティビティを監視します。 次のイベントを監視します。

特権アカウント管理イベントの監視

特権アカウントの認証規則と特権に対する変更を調査します。特に、変更によってより大きな特権が提供される場合や、Microsoft Entra IDでタスクを実行する機能が提供されている場合。

特権アカウント アクティビティの監視の詳細については、「Microsoft Entra IDの特権アカウントのセキュリティ操作」を参照してください。

未承認の変更と削除からイベント ログを保護する (ML3)

Essential8 成熟度レベル 3 では、イベント ログが未承認の変更と削除から保護されている必要があります。 未承認の変更と削除からイベント ログを保護することで、organizationでセキュリティ インシデントが発生した場合に、ログを信頼できる証拠ソースとして使用できます。 Azure 内では、アプリケーションとサービスへの特権アクセスからのイベント ログを、Log Analytics ワークスペース内に一元的に格納する必要があります。

Azure Monitor は追加専用のデータ プラットフォームですが、コンプライアンスのためにデータを削除するためのプロビジョニングが含まれています。 特権アクティビティからログを収集する Log Analytics ワークスペースは、ロールベースのアクセス制御でセキュリティ保護し、アクティビティの変更と削除を監視する必要があります。

次に、Log Analytics ワークスペースにロックを設定して、データを削除できるすべてのアクティビティ (消去、テーブルの削除、テーブルレベルまたはワークスペース レベルのデータ保持の変更) をブロックします。

イベント ログを完全に改ざん防止するには、Azure Blob Storageの不変ストレージなどの不変ストレージ ソリューションへのログ データの自動エクスポートを構成します。

イベント ログの整合性の保護の詳細については、「 Azure Monitor データ セキュリティ」を参照してください。