特権アクセス戦略の成功条件Success criteria for privileged access strategy

このドキュメントでは、 特権アクセス戦略の成功条件について説明します。This document describes the success criteria for a privileged access strategy. このセクションでは、特権アクセス戦略の成功の戦略的パースペクティブについて説明します。This section describes strategic perspectives of success for a privileged access strategy. この戦略を採用する方法のロードマップについては、「 迅速な近代化計画 (傾斜)」を参照してください。For a roadmap on how to adopt this strategy, see the rapid modernization plan (RaMP). 実装のガイダンスについては、「 privileged access deployment 」を参照してください。For implementation guidance, see privileged access deployment

ゼロの信頼アプローチを使用して包括的な戦略を実装すると、攻撃者に対して抵抗力を持つ特権アクセスのアクセス制御に対して、"封印" された "封印" を行うことになります。Implementing a holistic strategy using Zero Trust approaches creates a "seal" of sorts over the access control for privileged access that makes it resistant to attackers. この方法は、パスを特権アクセスに限定することによって、選択した数だけを選択し、その承認された経路を厳密に保護および監視することで実現します。This strategy is accomplished by limiting pathways to privileged access only a select few, and then closely protecting and monitoring those authorized pathways.


成功する戦略は、攻撃者が4つの異なるイニシアチブを含む特権アクセスワークフローをインターセプトするために使用できるすべてのポイントに対処する必要があります。A successful strategy must address the all points attackers can use to intercept privileged access workflows including four distinct initiatives:

  • 基礎となるデバイス、オペレーティングシステム、アプリケーション、および id を含む privileged access workflow の Privileged access workflow 要素Privileged Access workflow elements of the privileged access workflow including underlying devices, operating systems, applications, and identities
  • 特権アカウントおよびグループをホストする id システム と、そのアカウントに対する権限を付与するその他のアーティファクトIdentity systems hosting the privileged accounts and the groups, and other artifacts that confer privilege on the accounts
  • 特権アクセスにつながる可能性がある、ユーザーアクセスワークフロー と承認された昇格パスUser access workflow and authorized elevation paths that can lead to privileged access
  • ゼロ信頼アクセスポリシーが適用され、ロールベースのアクセス制御 (RBAC) が特権を付与するように構成されている アプリケーションインターフェイスApplication interfaces where zero trust access policy is enforced and role-based access control (RBAC) is configured to grant privileges


完全なセキュリティ戦略には、アクセス制御の範囲を超える資産保護も含まれます。これには、アプリケーション自体に対する攻撃、基盤となるオペレーティングシステムとハードウェア、アプリケーションやサービスで使用されるサービスアカウント、保存中または転送中のデータに対するデータのバックアップや保護などが含まれます。A complete security strategy also includes asset protections that are beyond the scope of access control, such as data backups and protections against attacks on the application itself, the underlying operating system and hardware, on service accounts used by the application or service, and on data while at rest or in transit. クラウドのセキュリティ戦略の最新化の詳細については、「 セキュリティ戦略の定義」を参照してください。For more information on modernizing a security strategy for cloud, see the article Define a security strategy.

攻撃とは、人間が組織を攻撃するための自動化とスクリプトを利用した攻撃者で構成されます。An attack consists of human attackers leveraging automation and scripts to attack an organization is composed of humans, the processes they follow, and the technology they use. 攻撃者と防御者の両方の複雑さにより、この戦略は、セキュリティ保証が意図せずに解消される可能性があるすべての人間、プロセス、およびテクノロジの方法を防ぐために、マルチファセットにする必要があります。Because of this complexity of both attackers and defenders, the strategy must be multi-faceted to guard against all the people, process, and technology ways that the security assurances could inadvertently be undermined.

持続的な長期成功を保証するには、次の条件を満たす必要があります。Ensuring sustainable long-term success requires meeting the following criteria:

Ruthless の優先順位付けRuthless prioritization

Ruthless の優先順位付けは、既存のプラン、見識、および習慣に合わない場合でも、最も高速な時間で最も効果的なアクションを最初に取得することです。Ruthless prioritization is the practice of taking the most effective actions with the fastest time to value first, even if those efforts don't fit pre-existing plans, perceptions, and habits. この戦略では、多くの主要なサイバーセキュリティインシデントの fiery で学習された一連の手順について説明します。This strategy lays out the set of steps that have been learned in the fiery crucible of many major cybersecurity incidents. これらのインシデントからの学習は、これらの危機が再び行われないようにするために、組織が行う手順を形成します。The learnings from these incidents form the steps we help organizations take to ensure that these crises don't happen again.

セキュリティの専門家は、新しい攻撃のためにネットワークセキュリティやファイアウォールなどの使い慣れた既存のコントロールを最適化することを常に希望していますが、このパスは一貫して障害につながることがあります。While it's always tempting for security professionals to try to optimize familiar existing controls like network security and firewalls for newer attacks, this path consistently leads to failure. Microsoft の検出と応答のチーム (DART) は、約10年間の特権アクセス攻撃に対応しており、これらの従来のセキュリティ手法がこれらの攻撃の検出または停止に失敗することを常に認識しています。Microsoft's Detection and Response Team (DART) has been responding to privileged access attacks for nearly a decade and consistently sees these classic security approaches fail to detect or stop these attacks. ネットワークセキュリティには、必要な基本的なセキュリティ上の予防策が用意されていますが、これらの習慣を解消し、現実世界の攻撃を阻止またはブロックする軽減策に専念することが重要です。While network security provides necessary and important basic security hygiene, it's critical to break out of these habits and focus on mitigations that will deter or block real world attacks.

この戦略で推奨されているセキュリティコントロールは、既存の仮定を Ruthlessly、新しいスキルを習得するように強制する場合でも、優先順位を決定します。Ruthlessly prioritize the security controls recommended in this strategy, even if it challenges existing assumptions and forces people to learn new skills.

セキュリティと生産性のバランスを取るBalance security and productivity

セキュリティ戦略のすべての要素と同様に、特権アクセスでは、生産性とセキュリティの両方の目標が満たされていることを確認する必要があります。As with all elements of security strategy, privileged access should ensure that both productivity and security goals are met.

セキュリティを分散することにより、組織のリスクを生じる極端な方法を回避できます。Balancing security avoids the extremes that create risk for the organization by:

  • セキュリティで保護されたポリシー、経路、システムの外部にユーザーがアクセスするような、過度に厳格なセキュリティを回避します。Avoiding overly strict security that causes users to go outside the secure policies, pathways, and systems.
  • 敵対者が組織を簡単に侵害できるようにすることで、生産性に悪影響を及ぼす脆弱なセキュリティを回避します。Avoiding weak security that harms productivity by allowing adversaries to easily compromise the organization.

セキュリティ戦略の詳細については、 セキュリティ戦略の定義に関する記事を参照してください。For more information about security strategy, see the article Defining a security strategy.

セキュリティ制御による悪影響を最小限に抑えるには、ユーザーワークフローを向上させる、または少なくともユーザーワークフローを妨げることがないように、非表示のセキュリティコントロールに優先順位を付ける必要があります。To minimize negative business impact from security controls, you should prioritize invisible security controls that improve user workflows, or at least don't impede or change user workflows. セキュリティを重視する役割には、セキュリティを保証するために毎日のワークフローを変更する、表示可能なセキュリティ対策が必要になる場合がありますが、この実装を熟考して、ユーザビリティの影響とスコープを可能な限り制限する必要があります。While security sensitive roles may need visible security measures that change their daily workflows to provide security assurances, this implementation should be done thoughtfully to limit the usability impact and scope as much as possible.

この戦略は、3つのプロファイルを定義することで、このガイダンスに従います (後の「単純なペルソナとプロファイルの保持」で詳しく説明します)。This strategy follows this guidance by defining three profiles (detailed later in Keep it Simple - Personas and Profiles)


組織内の強力なパートナーシップStrong partnerships within the organization

セキュリティは、組織内で成功するためのパートナーシップを構築するために機能する必要があります。Security must work to build partnerships within the organization to be successful. "私たちは誰もスマートではありません" という事実に加えて、セキュリティの性質は、他のユーザーのリソースを保護するためのサポート機能になります。In addition to the timeless truth that "none of us is as smart as all of us," the nature of security is to be a support function to protect someone else's resources. セキュリティは、保護するリソース (収益性、稼働時間、パフォーマンスなど) について責任を負うものではありません。セキュリティは、組織にとって重要な知的財産やビジネス機能を保護するのに役立つ 専門家のアドバイスやサービスを提供するサポート機能 です。Security isn't accountable for the resources they help protect (profitability, uptime, performance, etc.), security is a support function that provides expert advice and services to help protect the intellectual property and business functionality that is important to the organization.

セキュリティは、ビジネスおよびミッションの目標をサポートする ために、常にパートナーとして機能 する必要があります。Security should always work as a partner in support of business and mission objectives. セキュリティでは、高いリスクを受け入れることを推奨するといった直接のアドバイスを避けてはなりませんが、セキュリティでは、リソース所有者によって管理される他のリスクや機会と比較して、ビジネス上のリスクに関するアドバイスを常に提示する必要があります。While security should not shy away from giving direct advice like recommending against accepting a high risk, security should also always frame that advice in terms of the business risk relative to other risks and opportunities managed by the resource owners.

セキュリティの一部は、ほとんどの場合、セキュリティ組織内で正常に計画および実行できますが、特権アクセスのセキュリティ保護と同様に、保護するロールを理解し、ワークフローの更新と再設計を行って、セキュリティを確保し、ユーザーが自分の仕事をできるようにするために、ワークフローの更新と再設計を行う必要があります。While some parts of security can be planned and executed successfully mostly within security organization, many like securing privileged access require working closely with IT and business organizations to understand which roles to protect, and help update and redesign workflows to ensure they are both secure and allow people to do their jobs. この概念の詳細については、セキュリティ戦略のガイダンス記事の「 変換、マインドセット、および予測 」を参照してください。For more information on this idea, see the section Transformations, mindsets, and expectations in the security strategy guidance article.

攻撃者が投資収益率を破壊するDisrupt attacker return on investment

防御措置によって攻撃に対する攻撃者の価値提案が確実に中断される可能性があることを保証することで、実践に注力し、攻撃者が攻撃を成功させるためのコストと摩擦を高めることができるようにします。Maintain focus on pragmatism by ensuring that defensive measures are likely to meaningfully disrupt the attacker value proposition of attacking you, increasing cost and friction on the attacker's ability to successfully attack you. 攻撃コストに対する防御措置の影響を評価することで、攻撃者の観点に専念するための正常なリマインダーと、さまざまな軽減オプションの効果を比較するための構造化されたメカニズムが提供されます。Evaluating how defensive measures would impact the adversary's cost of attack provides both a healthy reminder to focus on the attackers perspective as well as a structured mechanism to compare the effectiveness of different mitigation options.

目標は、攻撃者のコストを増加させながら、お客様のセキュリティ投資レベルを最小限に抑えることです。Your goal should be to increase the attackers cost while minimizing your own security investment level:


攻撃を中断する場合は、特権アクセスセッションの要素全体で攻撃のコストを増加させることによって、投資収益率 (ROI) が低下します。Disrupt attacker return on investment (ROI) by increasing their cost of attack across the elements of the privileged access session. この概念の詳細については、「 特権アクセス戦略の成功条件」を参照してください。This concept is described in more detail in the article Success criteria for privileged access strategy.


特権アクセス戦略は包括的なものであり、多層防御を提供する必要がありますが、防御者が、意味のあるセキュリティ値を追加するポイントを超えて、より同じ (よく知られた) 型コントロール (多くの場合、ネットワークファイアウォール/フィルター) を使用している場合は、誤解のコストを避ける必要があります。A privileged access strategy should be comprehensive and provide defense in depth, but must avoid the Expense in depth fallacy where defenders simply pile on more same (familiar) type controls (often network firewalls/filters) past the point where they add any meaningful security value.

攻撃者の ROI の詳細については、短いビデオと詳細な説明を参照してください。 攻撃者が投資収益率を返します。For more information on attacker ROI, see the short video and in-depth discussion Disrupting attacker return on investment.

クリーン ソースの原則Clean source principle

クリーン ソースの原則では、すべてのセキュリティの依存関係がセキュリティ保護されているオブジェクトと同様に信頼できる必要があります。The clean source principle requires all security dependencies to be as trustworthy as the object being secured.

クリーン ソースの原則

オブジェクトを制御しているサブジェクトとは、そのオブジェクトのセキュリティ依存関係のことです。Any subject in control of an object is a security dependency of that object. 敵対者は、対象オブジェクトの制御中に、対象オブジェクトを制御できます。If an adversary can control anything in control of a target object, they can control that target object. この脅威により、すべてのセキュリティ依存関係の保証が、オブジェクト自体の目的のセキュリティレベル以上であることを確認する必要があります。Because of this threat, you must ensure that the assurances for all security dependencies are at or above the desired security level of the object itself. この原則は、さまざまな種類の制御関係に適用されます。This principle applies across many types of control relationships:


原則として、この概念は非常に複雑になりますが、ほとんどの企業は数十年を有機に成長し、互いに何千もの制御関係があり、互いにループバックしたり、相互にループしたりすることがあります。While simple in principle, this concept gets complex easily in the real world as most enterprises grew organically over decades and have many thousands of control relationships recursively that build on each other, loop back on each other, or both. この web コントロールの関係には、攻撃中に攻撃者が検出して移動できる多数のアクセスパスが用意されており、多くの場合、自動化されたツールがあります。This web of control relationships provides many access paths that an attacker can discover and navigate during an attack, often with automated tools.

Microsoft の推奨される特権アクセス戦略は、実際には、このノットの最も重要な部分をまず、ゼロの信頼方法を使用して untangle することを計画しています。これは、変換先へのアクセスを許可する前に、ソースがクリーンであることを明示的に検証することです。Microsoft's recommended privileged access strategy is effectively a plan to untangle the most important parts of this knot first using a Zero Trust approach, by explicitly validating that the source is clean before allowing access to the destination.

どのような場合でも、ソースの信頼レベルは、同期先と同じかそれ以上である必要があります。In all cases, the trust level of the source must be the same or higher than the destination.

  • この原則の唯一の重要な例外は、エンタープライズシナリオで管理されていない個人用デバイスとパートナーデバイスの使用を許可することです。The only notable exception to this principle is allowing the use of unmanaged personal devices and partner devices for enterprise scenarios. この例外により、エンタープライズのコラボレーションと柔軟性が実現し、エンタープライズ資産の低い相対的な価値があるため、ほとんどの組織で許容されるレベルに軽減できます。This exception enables enterprise collaboration and flexibility and can be mitigated to an acceptable level for most organizations because of the low relative value of the enterprise assets. BYOD セキュリティの詳細については、「 byod ポリシーによる公共セクターのセキュリティリスクの軽減方法」を参照してください。For more context on BYOD security, see the blog post How a BYOD policy can reduce security risk in the public sector.
  • この同じ例外は、これらの資産のセキュリティの感度によって、特殊なセキュリティレベルと特権レベルのセキュリティレベルに拡張することはできません。This same exception cannot be extended to specialized security and privileged security levels however because of the security sensitivity of these assets. 一部の PIM/PAM ベンダーは、お客様のソリューションが低レベルのデバイスからのデバイスのリスクを軽減できることを考えているかもしれませんが、インシデント調査の経験に基づいてこれらのアサーションを respectfully ことはありません。Some PIM/PAM vendors may advocate that their solutions can mitigate device risk from lower-level devices, but we respectfully disagree with those assertions based on our experience investigating incidents. 組織内の資産の所有者は、エンタープライズセキュリティレベルのデバイスを使用して特殊なリソースや特権のあるリソースにアクセスするリスクを受け入れることを選択できますが、この構成はお勧めしません。The asset owners in your organization may choose to accept risk of using enterprise security level devices to access specialized or privileged resources, but Microsoft does not recommend this configuration. 詳細については、Privileged Access Management/Privileged Identity Management の中間ガイダンスを参照してください。For more information, see the intermediary guidance for Privileged Access Management / Privileged Identity management.

特権アクセス戦略では、インターフェイスと中継局で受信セッションの条件付きアクセスを使用してゼロ信頼ポリシーを適用することによって、主にこの原則を達成します。The privileged access strategy accomplishes this principle primarily by enforcing Zero Trust policy with Conditional Access on inbound sessions at interfaces and intermediaries. クリーンソースの原則では、まず、オペレーティングシステムのバージョン、セキュリティベースラインの構成、展開に Windows 自動操縦 を使用するなどの要件に基づいて、OEM から新しいデバイスを取得します。The clean source principle starts with getting a new device from an OEM that is built to your security specifications including operating system version, security baseline configuration, and other requirements such as using Windows Autopilot for deployment.

必要に応じて、クリーンソースの原則を拡張して、オペレーティングシステムとアプリケーションのインストールメディアを含むサプライチェーン内の各コンポーネントの厳密なレビューを行うことができます。Optionally, the clean source principle can extend into a highly rigorous review of each component in the supply chain including installation media for operating systems and applications. この原則は高度な攻撃を受ける組織に適していますが、このガイダンスの他のコントロールよりも優先度が低くなります。While this principle would be appropriate for organizations facing highly sophisticated attackers, it should be a lower priority than the other controls in this guidance.

次のステップNext steps