ガバナンス、リスク、およびコンプライアンスGovernance, risk, and compliance

組織はその規模を問わず、財務、人材、時間といった、使用可能なリソースによる制約を受けます。Organizations of all sizes are constrained by their available resources; financial, people, and time. 組織は満足すべき投資収益率 (ROI) を実現するために、投資する場所に優先順位を付ける必要があります。To achieve an effective return on investment (ROI) organizations must prioritize where they will invest. 組織全体にわたるセキュリティの実装もこの制約を受けるため、セキュリティに関して適切な ROI を実現するには、組織は最初に、セキュリティの優先順位についての理解と定義を行う必要があります。Implementation of security across the organization is also constrained by this, so to achieve an appropriate ROI on security the organization needs to first understand and define its security priorities.

ガバナンス – 組織のセキュリティはどのように監視、監査、報告される予定ですか。Governance – How is the organization’s security going to be monitored, audited, and reported? 組織内でのセキュリティ制御の設計と実装は、話の始まりにすぎません。Design and implementation of security controls within an organization is only the beginning of the story. 組織は物事が実際に機能していることをどのように知るのでしょうか。How does the organization know that things are actually working? 改善はしているでしょうか。Are they improving? 新しい要件はあるでしょうか。Are there new requirements? 必須のレポートはあるでしょうか。Is there mandatory reporting? コンプライアンスと同様に、考慮する必要がある外部の業界、政府機関、または規制基準が存在する可能性もあります。Similar to compliance there may be external industry, government or regulatory standards that need to be considered.

リスク – 個人を特定できる情報、知的財産 (IP)、財務情報を保護しようとしているときに、組織はどのような種類のリスクに直面するのでしょうか。Risk – What types of risks does the organization face while trying to protect identifiable information, Intellectual Property (IP), financial information? 外部や内部の脅威だけでなく、意図しない脅威や悪意による脅威を含め、盗難にあった場合には、だれがこの情報に関心を持ったり利用できたりする可能性があるでしょうか。Who may be interested or could leverage this information if stolen, including external and internal threats as well as unintentional or malicious? リスクの中で忘れられることが多いが非常に重要な考慮事項は、ディザスター リカバリーと事業継続に対処することです。A commonly forgotten but extremely important consideration within risk is addressing Disaster Recovery and Business Continuity.

コンプライアンス – 組織のセキュリティ制御において満たす必要のある条件について、推奨事項を規定したり示したりしている特定の業界、政府機間、または規制による要件が存在しますか。Compliance – Are there specific industry, government, or regulatory requirements that dictate or provide recommendation on criteria that your organization’s security controls must meet? そのような標準、組織、管理、法規制の例として、ISO27001NISTPCI DSS が挙げられます。Examples of such standards, organizations, controls, and legislation are ISO27001, NIST, PCI-DSS.

組織の集団としての役割は、組織のセキュリティ標準をライフサイクルを通じて管理することです。The collective role of organization(s) is to manage the security standards of the organization through their lifecycle:

  • 内部要因 (組織の文化、リスク選好度、資産評価、ビジネスイニシアチブなど) と外部要因 (ベンチマーク、規制標準、脅威環境など) に基づいて、プラクティス、テクノロジ、および構成の組織の標準とポリシーを設定します。Define - Set organizational standards and policies for practices, technologies, and configurations based on internal factors (organizational culture, risk appetite, asset valuation, business initiatives, etc.) and external factors (benchmarks, regulatory standards, threat environment, and more)

  • 改善–これらの標準を継続的に継続的にプッシュして、リスクを軽減するための理想的な状態にします。Improve – Continually push these standards incrementally forward towards the ideal state to ensure continual risk reduction.

  • 維持–組織の標準に準拠した監査と監視によって、策定のセキュリティ体制が自然に低下しないようにします。Sustain – Ensure the security posture doesn’t degrade naturally over time by instituting auditing and monitoring compliance with organizational standards.

セキュリティ ベスト プラクティスへの投資に優先順位を付けるPrioritize security best practices investments

セキュリティのベスト プラクティスは、クラウドプログラムを構築するときに、先を見越してすべてのシステムに完全に適用するのが理想的ですが、ほとんどのエンタープライズ組織で、これは現実的ではありません。Security best practices are ideally applied proactively and completely to all systems as you build your cloud program, but this isn’t reality for most enterprise organizations. ビジネス目標、プロジェクトの制約、およびその他の要因により、組織は、セキュリティリスクと他のリスクとのバランスを取り、任意の時点でベスト プラクティスのサブセットを適用することがよくあります。Business goals, project constraints, and other factors often cause organizations to balance security risk against other risks and apply a subset of best practices at any given point.

できるだけ早期にできるだけ多くのベスト プラクティスを適用し、その後はセキュリティ プログラムを成熟させながら、不足している部分があれば時間をかけて改善に取り組むことをお勧めします。We recommend applying as many as of the best practices as early as possible, and then working to retrofit any gaps over time as you mature your security program. 最初にどれに従事するかの優先順位を付けるときには、以下の考慮事項について評価することをお勧めします。We recommend evaluating the following considerations when prioritizing which to follow first:

  • ビジネスへの影響が大きく、広く公開されるシステム – これらには、明快な本来の価値を含むシステムと、攻撃者にそれらのシステムへの経路を提供するシステムが含まれます。High business impact and highly exposed systems – These include systems with direct intrinsic value as well as the systems that provide attackers a path to them. 詳細については、ビジネス クリティカルなアプリケーションの特定と分類に関するページを参照してください。For more information, see Identify and classify business critical applications.

  • 軽減策の実装は、ベストプラクティスに優先順位を付けることによって簡単に行うことができます。必要なスキル、ツール、および知識を既に持っている (たとえば、レガシアプリケーションを保護するために Web アプリファイアウォール (waf) を実装する) ため、組織は迅速に実行できます。Easiest to implement Mitigations– Identify quick wins by prioritizing the best practices, which your organization can execute quickly because you already have the required skills, tools, and knowledge to do it (for example, implementing a Web App Firewall (WAF) to protect a legacy application).
    優先順位付けによるこの短期的な方法のみを (または過度に) 使用することがないよう注意してください。Be careful not to exclusively use (or overuse) this short-term prioritization method. そのようにすると、プログラムの成長が妨げられて、重大なリスクが長期間にわたって放置され、リスクが高まる可能性があります。Doing so can increase your risk by preventing your program from growing and leaving critical risks exposed for extended periods.

Microsoft は、組織がこれらの意思決定を開始するのに役立つように、Microsoft 自身の環境と、Microsoft のお客様における脅威や軽減策の経験に基づいて、優先順位を付けたセキュリティ イニシアチブの一覧をいくつか提供してきました。Microsoft has provided some prioritized lists of security initiatives to help organizations start with these decisions based on our experience with threats and mitigation initiatives in our own environments and across our customers. Microsoft CISO ワークショップモジュール 4aをご覧ください。See Module 4a of the Microsoft CISO Workshop

接続済みテナントを管理するManage connected tenants

セキュリティ組織が、既存の環境に (ExpressRoute またはサイト間 VPN を介して) 接続されているすべての登録および関連付けられているサブスクリプションを認識し、総合的な企業の一部として監視していることを確認します。Ensure your security organization is aware of all enrollments and associated subscriptions connected to your existing environment (via ExpressRoute or Site-Site VPN) and monitoring as part of the overall enterprise.

Azure のこれらのリソースはエンタープライズ環境の一部であり、セキュリティ組織には、それらに対する可視化が必要です。These azure resources are part of your enterprise environment and security organizations require visibility into them. リスクを評価し、組織のポリシーと該当する規制要件が遵守されているかどうかを識別するために、セキュリティ組織にはこのアクセスが必要です。Security organizations need this access to assess risk and to identify whether organizational policies and applicable regulatory requirements are being followed.

運用環境/ネットワークに接続するすべての Azure 環境で、組織のポリシーと、セキュリティのための IT ガバナンス管理が適用されていることを確認します。Ensure all Azure environments that connect to your production environment/network apply your organization’s policy and IT governance controls for security. Microsoft が提供するツールを使用して、接続されている既存のテナントを検出できます。You can discover existing connected tenants using a tool provided by Microsoft. セキュリティに割り当て可能なアクセス許可に関するガイダンスについては、「環境を管理するための特権の割り当て」セクションを参照してください。Guidance on permissions you may assign to security is in the Assign privileges for managing the environment section.

責任の明確な線引きClear lines of responsibility

Azure における特定の機能を担当する当事者を指定しますDesignate the parties responsible for specific functions in Azure

これらの各機能を担当する窓口を明確に文書化して共有することで、一貫性が得られてコミュニケーションが容易になります。Clearly documenting and sharing the contacts responsible for each of these functions will create consistency and facilitate communication. 多くのクラウド導入プロジェクトを担った Microsoft の経験に基づけば、こうすることで、セキュリティ リスクを生じる人的エラーや自動化エラーにつながるおそれのある混乱が回避されます。Based on our experience with many cloud adoption projects, this will avoid confusion that can lead to human and automation errors that create security risk.

以下の主要な機能を担当するグループ (または個々のロール) を指定します。Designate groups (or individual roles) that will be responsible for these key functions:

グループまたは個々のロールGroup or individual role 担当Responsibility
ネットワークのセキュリティNetwork Security 通常は既存のネットワーク セキュリティ チーム。Typically existing network security team. Azure Firewall、ネットワーク仮想アプライアンス (および関連するルーティング)、WAF、NSG、ASG などの構成とメンテナンス。Configuration and maintenance of Azure Firewall, Network Virtual Appliances (and associated routing), WAFs, NSGs, ASGs, etc.
ネットワーク管理Network Management 通常は既存のネットワーク運用チーム。Typically existing network operations team. 企業全体の仮想ネットワークとサブネットの割り当て。Enterprise-wide virtual network and subnet allocation.
サーバー エンドポイントのセキュリティServer Endpoint Security 通常は IT 運用、セキュリティ、または共同担当。Typically IT operations, security, or jointly. サーバー セキュリティ (修正プログラムの適用、構成、エンドポイントのセキュリティなど) の監視と修復を行う。Monitor and remediate server security (patching, configuration, endpoint security, etc.).
インシデントの監視と対応Incident Monitoring and Response 通常はセキュリティ運用チーム。Typically security operations team. セキュリティ情報イベント管理 (SIEM) コンソールまたはソース コンソールでセキュリティ インシデントの調査と修復を行う。Investigate and remediate security incidents in Security Information and Event Management (SIEM) or source console.
ポリシー管理Policy Management 通常は GRC チームとアーキテクチャ。Typically GRC team + Architecture. ロールベースのアクセス制御 (RBAC)、Azure Security Center、管理者保護戦略、および Azure リソースを管理するための Azure Policy の使用についての指針を定める。Set Direction for use of Role Based Access Control (RBAC), Azure Security Center, Administrator protection strategy, and Azure Policy to govern Azure resources.
ID に関するセキュリティと標準Identity Security and Standards 通常はセキュリティ チームと ID チームの共同担当。Typically Security Team + Identity Team jointly. Azure AD のディレクトリ、PIM/PAM の使用、MFA、パスワード/同期の構成、アプリケーション ID 標準についての指針を定める。Set direction for Azure AD directories, PIM/PAM usage, MFA, password/synchronization configuration, Application Identity Standards.

企業のセグメント化戦略Enterprise segmentation strategy

企業の他の部分から分離できるリソースのグループを識別して、企業内での敵対者の移動を封じ込め (て検知し) ます。Identify groups of resources that can be isolated from other parts of the enterprise to contain (and detect) adversary movement within your enterprise. この統合された企業セグメント化戦略では、すべての技術チームが、ネットワーク、アプリケーション、ID などのアクセス制御を使用して、アクセスを首尾一貫してセグメント化するよう手引きされます。This unified enterprise segmentation strategy will guide all technical teams to consistently segment access using networking, applications, identity, and any other access controls.

明確で単純なセグメント化戦略は、生産性とビジネス運営を可能にするのと同時にリスクを抑える助けとなります。A clear and simple segmentation strategy helps contain risk while enabling productivity and business operations.

企業のセグメント化戦略は、従来の "ネットワークのセグメント化" セキュリティ戦略よりも高いレベルで定義されます。An enterprise segmentation strategy is defined higher than a traditional “network segmentation” security strategy. オンプレミス環境に対する従来のセグメント化アプローチは、さまざまな技術チームによって "ボトムアップ" で開発され、企業のユース ケースやアプリケーション ワークロードに適切に適合していなかったため、目標を達成できないことがよくありました。Traditional segmentation approaches for on premises environments frequently failed to achieve their goals because they were developed “bottom-up” by different technical teams and were not aligned well with business use cases and application workloads. これにより、サポートの問題を引き起こす極度の複雑さが生じる結果となり、多くの場合、広範囲に作成されたネットワーク ファイアウォールの例外によって元の意図が損なわれています。This resulted in overwhelming complexity that generates support issues and often undermines the original purpose with broad network firewall exceptions.

統合された企業のセグメント化戦略を作成すれば、すべての技術チームの利害関係者 (IT、セキュリティ、アプリケーションなど) を導くことができます。ビジネス上のリスクとニーズに基づいて事業単位を構築すれば、セキュリティ上の封じ込めの保証を満たしやすくなり、保証について理解してその持続可能性を支えることになります。Creating a unified enterprise segmentation strategy enables to guide all technical teams stakeholders (IT, Security, Applications, etc.) Business Units that is built around the business risks and needs will increase alignment to and understand and support sustainability of the security containment promises. この明確さと適合によって、セキュリティの脆弱性、運用のダウンタイム、またはその両方につながる可能性がある人的エラーや自動化エラーのリスクも軽減されます。This clarity and alignment will also reduce s the risk of human errors and automation failures that can lead to security vulnerabilities, operational downtime, or both.

ネットワークのマイクロセグメント化でもリスクが軽減されることは保証されますが (詳しくは「ネットワークのセキュリティと封じ込め」セクションで説明)、技術チームの方針を整合させる必要はなくなりません。While network micro-segmentation also offers promise to reduce risk (discussed more in Network Security and Containment section), it doesn’t eliminate the need to align technical teams. マイクロセグメント化は、技術チームの方針を確実に整合させる計画の後に検討する必要があります。そうすることで、オンプレミスのネットワーク作成時のセグメント化戦略を悩ませた社内の競合や混乱が再発するのを回避できます。Micro segmentation should be considered after to and plans to ensure the ensuring technical teams are aligned so you can avoid a recurrence of the internal conflicts that plagued and confusion of the on-premises network generation segmentation strategies.

以下に、封じ込めとセグメント化に関する取り組みの優先順位付けについての、Microsoft の推奨事項を示します ("ゼロトラスト" の原則に基づきます)。Here are Microsoft's recommendations for prioritizing initiatives on containment and segmentation (based on Zero Trust principles). これらの推奨事項は、重要度が最も高い優先順位の順序になっています。These recommendations are listed in priority order by highest importance.

  • 技術チームの方針が単一の企業セグメント化戦略に適合するようにします。Ensure alignment of technical teams to a single enterprise segmentation strategy.

  • ID、デバイス、アプリケーション、および (ネットワーク制御の制限を克服して新しいリソースの保護と新しい攻撃からの保護を行うための) その他のきっかけに焦点を合わせた、"ゼロトラスト" の原則に基づく最新の境界を確立することで、範囲が広がりつつある封じ込めに投資します。Invest in broadening containment by establishing a modern perimeter based on zero trust principles focused on identity, device, applications, and other signals (to overcome limitation of network controls to protect new resources and attack types).

  • マイクロセグメント化戦略について検討し、レガシ アプリケーションのネットワーク制御を強化します。Bolster network controls for legacy applications by exploring micro segmentation strategies.

適切な企業セグメント化戦略は以下の条件を満たしています。A good enterprise segmentation strategy meets these criteria:

  • 操作を可能にします。ビジネスプラクティスやアプリケーションに合わせて、操作の摩擦を最小限に抑えます。Enables Operations – Minimizes operation friction by aligning to business practices and applications

  • リスクを封じ込める – 以下によって攻撃者のコストと困難さを高めますContains Risk - Adds cost and friction to attackers by

    • その他の資産の侵害から、機密性の高いワークロードを分離するIsolating sensitive workloads from compromise of other assets

    • その他のシステムへの足がかりとして使用されないように、露出度の高いシステムを分離するIsolating high exposure systems from being used as a pivot to other systems

  • 監視-セキュリティ操作では、セグメントの整合性 (アカウントの使用状況や予期しないトラフィックなど) の潜在的な違反を監視する必要があります。Monitored – Security Operations should monitor for potential violations of the integrity of the segments (account usage, unexpected traffic, etc.)

自動的に生成された携帯電話の説明のスクリーンショット

セキュリティチームの可視化Security team visibility

セキュリティ チームには、彼らの権限に含まれるすべての技術リソースのセキュリティに関する側面に対する読み取り専用アクセスを提供しますProvide security teams read-only access to the security aspects of all technical resources in their purview

セキュリティ組織は、組織のリスクについて評価やレポート作成を行う職務を実行するため、技術的な環境に対する可視化を必要とします。Security organizations require visibility into the technical environment to perform their duties of assessing and reporting on organizational risk. この可視性が行われないと、セキュリティは、利害 (やその他の優先事項) が対立する可能性のある環境を運用しているグループから提供された情報を頼りにすることが必要になります。Without this visibility, security will have to rely on information provided from groups operating the environment who have a potential conflict of interest (and other priorities).

セキュリティ チームが運用上の役割を持っている場合や、Azure リソースにコンプライアンスを適用する必要がある場合は、追加の特権が別個に付与される可能性があることに注意してください。Note that security teams may separately be granted additional privileges if they have operational responsibilities or a requirement to enforce compliance on Azure resources.

たとえば Azure で、セキュリティ リスクを測定するためのアクセスを提供するセキュリティ閲覧者のアクセス許可を、セキュリティ チームに割り当てます (データ自体へのアクセス権は提供しません)For example in Azure, assign security teams to the Security Readers permission that provides access to measure security risk (without providing access to the data itself)

Azure のセキュリティに対して広範な責任を持つ企業セキュリティ グループについては、以下を使用してこのアクセス許可を割り当てることができます。For enterprise security groups with broad responsibility for security of Azure, you can assign this permission using:

  • ルート管理グループ–すべてのリソースに対するリスクの評価と報告を担当するチーム向けRoot management group – for teams responsible for assessing and reporting risk on all resources

  • セグメント管理グループ–責任の範囲が限られているチーム (通常は、組織の境界や規制要件によって必要)Segment management group(s) – for teams with limited scope of responsibility (typically required because of organizational boundaries or regulatory requirements)

セキュリティ チームには環境への広範なアクセス権 (および悪用される可能性のある脆弱性に対する可視化) が与えられるため、これらは非常に大きな影響を与えるアカウントであると見なし、管理者と同じ保護を適用することを検討する必要があります。Because security will have broad access to the environment (and visibility into potentially exploitable vulnerabilities), you should consider them critical impact accounts and apply the same protections as administrators. Azure でのこれらの制御に関する詳細については、管理についてのページを参照してください。The Administration section details these controls for Azure.

環境を管理するための特権を割り当てるAssign privileges for managing the environment

最小限の特権の原則と運用上のニーズから作成された、明確に文書化された戦略に基づいて、Azure での運用上の役割を持つロールに適切なアクセス許可を付与します。Grant roles with operational responsibilities in Azure the appropriate permissions based on a clearly documented strategy built from the principle of least privilege and your operational needs.

参照モデルに沿った明確なガイダンスを提供することで、リスクが軽減されます。これは、明確さを増すことで、これらのアクセス許可を実装する技術チームにとっての明確さが提供されるためです。Providing clear guidance that follows a reference model will reduce risk because by increasing it provides clarity for your technical teams implementing these permissions. この明確さにより、過剰なアクセス許可の付与のような人的エラーの検出と修正がより容易になり、全体的なリスクが軽減されます。This clarity makes it easier to detect and correct human errors like overpermissioning, reducing your overall risk.

Microsoft では、これらの Microsoft 参照モデルから始めて、組織に適合させることをお勧めします。Microsoft recommends starting from these Microsoft reference models and adapting to your organization.

コアサービスの参照権限を示す画像

コア サービスの参照アクセス許可Core Services Reference Permissions

このセグメントは、組織全体にわたって利用される共有サービスをホストしています。This segment hosts shared services utilized across the organization. これらの共有サービスには、通常、Azure IaaS (サービスとしてのインフラストラクチャ) 仮想マシンでホストされる Active Directory Domain Services、DNS/DHCP、システム管理ツールが含まれます。These shared services typically include Active Directory Domain Services, DNS/DHCP, System Management Tools hosted on Azure Infrastructure as a Service (IaaS) virtual machines.

すべてのリソースにわたるセキュリティの可視化 – セキュリティ チームに対しては、すべての技術環境のセキュリティ属性に対する読み取り専用アクセスを付与します。Security Visibility across all resources – For security teams, grant read-only access to security attributes for all technical environments. このアクセス レベルは、リスク要因を評価し、潜在的な軽減策を特定し、リスクを受け入れる組織の関係者に助言するために必要です。This access level is needed to assess risk factors, identify potential mitigations, and advise organizational stakeholders who accept the risk. 詳細については、「セキュリティチームの可視化」を参照してください。See Security Team Visibility for more details.

一部またはすべてのリソースにわたるポリシー管理 – 外部 (または内部) の規則、標準、およびセキュリティ ポリシーへの準拠の監視と適用を行うには、それらのロールに適切なアクセス許可を割り当てます。Policy management across some or all resources – To monitor and enforce compliance with external (or internal) regulations, standards, and security policy, assign appropriate permission to those roles. 選択するロールとアクセス許可は、組織の文化やポリシー プログラムに期待される事柄によって異なります。The roles and permissions you choose will depend on the organizational culture and expectations of the policy program. Microsoft Cloud Adoption Framework for Azure に関するページを参照してください。See Microsoft Cloud Adoption Framework for Azure.

すべてのリソースにわたる中央の IT 運用 – 仮想マシンやストレージなどのリソースを作成、変更、および削除するために、中央の IT 部門 (多くの場合、インフラストラクチャ チーム) にアクセス許可を付与します。Central IT operations across all resources – Grant permissions to the central IT department (often the infrastructure team) to create, modify, and delete resources like virtual machines and storage.

ネットワーク リソース全体にわたる中央のネットワーク グループ – 一貫性を確保して技術的競合を回避するため、ネットワーク リソースに関する責任は中央の単一ネットワーク組織に割り当てます。Central networking group across network resources – To ensure consistency and avoid technical conflicts, assign network resource responsibilities to a single central networking organization. これらのリソースには、仮想ネットワーク、サブネット、ネットワーク セキュリティ グループ (NSG)、仮想ネットワーク アプライアンスをホストする仮想マシンが含まれている必要があります。These resources should include virtual networks, subnets, Network Security Groups (NSG), and the virtual machines hosting virtual network appliances. 詳細については、ネットワーク管理とセキュリティの一元化に関するページを参照してくださいSee Centralize Network Management And Security for more details

リソース ロールのアクセス許可 – ほとんどのコアサービスでは、その管理に必要な管理者特権はアプリケーション自体 (Active Directory、DNS/DHCP、システム管理ツールなど) を介して付与されるため、Azure リソースに関する追加のアクセス許可は必要ありません。Resource Role Permissions – For most core services, administrative privileges required to manage them are granted via the application itself (Active Directory, DNS/DHCP, System Management Tools, etc.), so no additional Azure resource permissions are required. 実際の組織モデルで、これらのチームが独自の VM、ストレージ、またはその他の Azure リソースを管理する必要がある場合は、これらのアクセス許可をそれらのロールに割り当てることができます。If your organizational model requires these teams to manage their own VMs, storage, or other Azure resources, you can assign these permissions to those roles.

サービス管理者 (非常時アカウント) – サービス管理者ロールは、緊急時 (および必要な場合は初期セットアップ) にのみ使用します。Service admin (Break Glass Account) – Use the service admin role only for emergencies (and initial setup if required). 日常のタスクにはこのロールを使用しないでください。Do not use this role for daily tasks. 詳細については、緊急アクセス ("非常時" アカウント)に関するページを参照してください。See Emergency Access (‘Break Glass’ Accounts) for more details.

自動的に生成された携帯電話の説明のスクリーンショット

セグメント参照のアクセス許可Segment reference permissions

このセグメントのアクセス許可を設計することで、単一の集中管理された IT グループから、大部分は独立した IT チームや DevOps チームまで、幅広い組織モデルに対応する柔軟性を実現するのと同時に、一貫性を提供します。This segment permission design provides consistency while allowing flexibility to accommodate the range of organizational models from a single centralized IT group to mostly independent IT and DevOps teams.

すべてのリソースにわたるセキュリティの可視化 – セキュリティ チームに対しては、すべての技術環境のセキュリティ属性に対する読み取り専用アクセスを付与します。Security visibility across all resources – For security teams, grant read-only access to security attributes for all technical environments. このアクセス レベルは、リスク要因を評価し、潜在的な軽減策を特定し、リスクを受け入れる組織の関係者に助言するために必要です。This access level is needed to assess risk factors, identify potential mitigations, and advise organizational stakeholders who accept the risk. セキュリティチームの可視化」を参照してください。See Security Team Visibility.

一部またはすべてのリソースにわたるポリシー管理 – 外部 (または内部) の規則、標準、およびセキュリティ ポリシーへの準拠の監視と適用を行うには、それらのロールに適切なアクセス許可を割り当てます。Policy management across some or all resources – To monitor and enforce compliance with external (or internal) regulations, standards, and security policy assign appropriate permission to those roles. 選択するロールとアクセス許可は、組織の文化やポリシー プログラムに期待される事柄によって異なります。The roles and permissions you choose will depend on the organizational culture and expectations of the policy program. Microsoft Cloud Adoption Framework for Azure に関するページを参照してください。See Microsoft Cloud Adoption Framework for Azure.

すべてのリソースにわたる IT 運用 – リソースの作成、変更、および削除を行うアクセス許可を付与します。IT Operations across all resources – Grant permission to create, modify, and delete resources. セグメントの目的 (とその結果のアクセス許可) は、組織の構造によって異なります。The purpose of the segment (and resulting permissions) will depend on your organization structure.

  • 一元化された IT 組織によって管理されるリソースを持つセグメントは、中央の IT 部門 (多くの場合、インフラストラクチャ チーム) にこれらのリソースを変更するアクセス許可を付与できます。Segments with resources managed by a centralized IT organization can grant the central IT department (often the infrastructure team) permission to modify these resources.

  • 独立した事業単位または部署 (人事部の IT チームなど) によって管理されるセグメントは、これらのチームに、セグメント内のすべてのリソースに対しするアクセス許可を付与できます。Segments managed by independent business units or functions (such as a Human Resources IT Team) can grant those teams permission to all resources in the segment.

  • アプリケーション チームにはリソース ロール (下記) によってアクセス許可が付与されるため、自律的な DevOps チームのセグメントでは、すべてのリソースわたるアクセス許可を付与する必要はありません。Segments with autonomous DevOps teams don’t need to grant permissions across all resources because the resource role (below) grants permissions to application teams. 緊急の場合には、サービス管理者アカウント (緊急時アカウント) を使用します。For emergencies, use the service admin account (break-glass account).

ネットワーク リソース全体にわたる中央のネットワーク グループ – 一貫性を確保して技術的競合を回避するため、ネットワーク リソースに関する責任は中央の単一ネットワーク組織に割り当てます。Central networking group across network resources – To ensure consistency and avoid technical conflicts, assign network resource responsibilities to a single central networking organization. これらのリソースには、仮想ネットワーク、サブネット、ネットワーク セキュリティ グループ (NSG)、仮想ネットワーク アプライアンスをホストする仮想マシンが含まれている必要があります。These resources should include virtual networks, subnets, Network Security Groups (NSG), and the virtual machines hosting virtual network appliances. ネットワーク管理とセキュリティの一元化に関するページを参照してください。See Centralize Network Management And Security.

リソース ロールのアクセス許可 – 自律的な DevOps チームのセグメントでは、各アプリケーションに関連付けられているリソースを管理します。Resource Role Permissions – Segments with autonomous DevOps teams will manage the resources associated with each application. 実際のロールとそのアクセス許可は、アプリケーションのサイズと複雑さ、アプリケーション チームの規模と複雑さ、および組織とアプリケーション チームの文化によって異なります。The actual roles and their permissions depend on the application size and complexity, the application team size and complexity, and the culture of the organization and application team.

サービス管理者 (非常時アカウント) – サービス管理者ロールは、緊急時 (および必要な場合は初期セットアップ) にのみ使用します。Service Admin (Break Glass Account) – Use the service admin role only for emergencies (and initial setup if required). 日常のタスクにはこのロールを使用しないでください。Do not use this role for daily tasks. 詳細については、緊急アクセス ("非常時" アカウント)に関するページを参照してください。See Emergency Access (‘Break Glass’ Accounts) for more details.

アクセス許可のガイダンスとヒントPermission Guidance and Tips

  • 一貫性を確保し、アプリケーションで今後のサブスクリプションにアクセスできるようにするには、個々のサブスクリプションではなくセグメントの管理グループでアクセス許可を割り当てる必要があります。To drive consistency and ensure application to future subscriptions, permissions should be assigned at management group for the segment rather than the individual subscriptions. 詳細については、きめ細かなカスタム アクセス許可の回避に関するページを参照してください。See Avoid Granular and Custom Permissions for more details.

  • まず組み込みのロールを確認して、適用できるロールがあるかどうかを調べてから、VM やその他のオブジェクトに適切なアクセス許可を付与するカスタム ロールを作成する必要があります。You should first review the built-in roles to see if one is applicable before creating a custom role to grant the appropriate permissions to VMs and other objects. 詳細については、組み込みのロールの使用に関するページを参照してくださいSee Use Built in Roles for more details

  • セキュリティマネージャーグループのメンバーシップは、セキュリティチームが広範な運用責任を持つ小規模なチームや組織に適している場合があります。Security managers group membership may be appropriate for smaller teams/organizations where security teams have extensive operational responsibilities.

管理グループを使用してセグメント化を確立するEstablish segmentation with management groups

管理グループの構造を、企業セグメント化モデルの指針となる単純な設計にまとめます。Structure management groups into a simple design that guides the enterprise segmentation model.

管理グループは、一貫して効率的にリソース (必要に応じて複数のサブスクリプションを含む) を管理する機能を提供します。Management groups offer the ability to consistently and efficiently manage resources (including multiple subscriptions as needed). ただしその柔軟性のため、過度に複雑な設計を作成することも可能です。However, because of their flexibility, it's possible to create an overly complex design. 複雑さがあると混乱が生じて、(Active Directory 用の過度に複雑な組織単位 (OU) およびグループ ポリシー オブジェクト (GPO) の設計で示されているように) 運用とセキュリティの両方が悪影響を受けます。Complexity creates confusion and negatively impacts both operations and security (as illustrated by overly complex Organizational Unit (OU) and Group Policy Object (GPO) designs for Active Directory).

Microsoft では、管理グループ (MG) の最上位レベルを、1 レベルまたは 2 レベルに制限されたシンプルな企業セグメント化戦略に合わせることをお勧めします。Microsoft recommends aligning the top level of management groups (MGs) into a simple enterprise segmentation strategy limited to 1 or 2 levels.

ルート管理グループは注意して使用するUse root management group carefully

ルート管理グループ (MG) は企業の一貫性のために使用しますが、運用中断のリスクを最小限にするために、変更を慎重にテストします。Use the Root Management Group (MG) for enterprise consistency, but test changes carefully to minimize risk of operational disruption.

ルート管理グループを使用すると、すべてのサブスクリプションにわたってポリシー、アクセス許可、タグを適用して、企業全体にわたる一貫性を確保できます。The root management group enables you to ensure consistency across the enterprise by applying policies, permissions, and tags across all subscriptions. ルート管理グループへの割り当てを計画して実装するときには、注意が必要です。Azure 上のすべてのリソースに影響する可能性があり、エラーや予期しない影響が発生した場合はダウンタイムや生産性に対するその他の悪影響が発生する可能性があるためです。Care must be taken when planning and implementing assignments to the root management group because this can affect every resource on Azure and potentially cause downtime or other negative impacts on productivity in the event of errors or unanticipated effects.

ルート管理グループに関するガイダンス:Root management group guidance:

  • 計画に従って、エンタープライズ規模の要素をルート管理グループに対して慎重に選択します。これらの要素は、すべてのリソースに適用されるか、または影響が少ないかを明確にする必要があります。Plan Carefully - Select enterprise-wide elements to the root management group that have a clear requirement to be applied across every resource and/or low impact.

    適切な候補は次のとおりです。Good candidates include:

    • 事業上の明確なリスクや影響のある規制要件 (たとえば、データ主権に関連する制限)。Regulatory requirements with clear business risk/impact (for example, restrictions related to data sovereignty).

    • 慎重に確認された、監査効果のあるポリシー、タグの割り当て、RBAC アクセス許可の割り当てなど、運用に関する潜在的な悪影響がほぼないものNear-zero potential negative impact on operations such as policy with audit effect, Tag assignment, RBAC permissions assignments that have been carefully reviewed.

  • 最初のテスト-(ポリシー、タグ、RBAC モデルなど) を使用して、ルート管理グループのすべてのエンタープライズ規模の変更を慎重にテストします。Test First - Carefully test all enterprise-wide changes on the root management group before applying (policy, tags, RBAC model, etc.) using a

    • テスト ラボ – 実稼働テナントにおける代表的なラボ テナントまたはラボ セグメント。Test Lab - Representative lab tenant or lab segment in production tenant.

    • 実稼働パイロット – サブスクリプション/MG 内のセグメント MG または指定されたサブセット。Production Pilot - Segment MG or Designated subset in subscription(s) / MG.

  • 変更の検証– 必要な効果が得られることを確認します。Validate Changes – to ensure they have the desired effect.

仮想マシン (VM) のセキュリティ更新プログラムと強力なパスワードVirtual Machine (VM) security updates and strong passwords

ポリシーとプロセスによって、仮想マシンに対するセキュリティ更新プログラムの迅速な適用が可能になる (必要とされる) ようにします。Ensure policy and processes enable (and require) rapid application of security updates to virtual machines.

攻撃者は、パブリック クラウドの IP 範囲を常にスキャンして開いている管理ポートを探し、よく使用されるパスワードや修正プログラムが適用されていない脆弱性などの、"苦労しないで済む" 攻撃を試みます。Attackers constantly scan public cloud IP ranges for open management ports and attempt “easy” attacks like common passwords and unpatched vulnerabilities.

Azure Security Center を有効にして、不足しているセキュリティ更新プログラムを特定して適用します。Enable Azure Security Center to identify missing security updates & apply them.

ローカル管理者パスワード ソリューション (LAPS) またはサードパーティ製 Privileged Access Management では、強力なローカル管理者パスワードと、それらへのジャスト イン タイム アクセスを設定できます。Local Admin Password Solution (LAPS) or a third party Privileged Access Management can set strong local admin passwords and just in time access to them.

仮想マシン (VM) のインターネットへの直接接続を削除するRemove Virtual Machine (VM) direct internet connectivity

ポリシーとプロセスで、仮想マシンによるインターネットへの直接接続の制限と監視を必須にしますEnsure policy and processes require restricting and monitoring direct internet connectivity by virtual machines

攻撃者は、パブリック クラウドの IP 範囲を常にスキャンして開いている管理ポートを探し、よく使用されるパスワードや修正プログラムが適用されていない既知の脆弱性などの "苦労しないで済む" 攻撃を試みますAttackers constantly scan public cloud IP ranges for open management ports and attempt “easy” attacks like common passwords and known unpatched vulnerabilities

これは、Azure では 1 つまたは複数の方法で実現できます。This can be accomplished with one or more methods in Azure:

  • 全社的規模での防止 -このガイダンスを通して説明されている参照モデルなどの企業ネットワークとアクセス許可モデルによって、不注意による公開を防止します。Enterprise-wide prevention - Prevent inadvertent exposure with an enterprise network and permission model such as the reference model described throughout this guidance. これによって以下のようにすることで、VM が誤ってインターネットに公開されるリスクが大幅に軽減されますThis significantly reduces the risk of accidental VM internet exposure by

    • ネットワーク トラフィックは既定で、承認されたエグレス ポイントを介してルーティングされるようにしますEnsuring that network traffic is routed through approved egress points by default

    • 例外 (リソースへのパブリック IP アドレスの追加など) は、集中管理されたグループを経由する必要があります (そこで例外要求を慎重に評価し、適切な制御が適用されるようにします)Exceptions (for example, add a public IP address to a resource) must go through a centralized group (which can carefully evaluate exception requests to ensure appropriate controls are applied)

  • Azure Security Centerネットワークの視覚化を使用して公開されている Vm を特定して修復し、インターネットに公開されているリソースをすばやく特定します。Identify and Remediate exposed VMs using the Azure Security Center network visualization to quickly identify internet exposed resources.

  • Azure Security Center でジャストインタイムアクセスを使用して管理ポート(RDP、SSH) を制限するRestrict management ports (RDP, SSH) using Just in Time access in Azure Security Center

インシデント通知の連絡先を割り当てるAssign incident notification contact

セキュリティの連絡先が、Microsoft から Azure インシデントの通知を受け取るようにします。これは通常、使用中のリソースが、侵害されたという通知や、別の顧客を攻撃中であるという通知です。Ensure a security contact receives Azure incident notifications from Microsoft typically a notification that your resource is compromised and/or attacking another customer.

これにより、セキュリティ運用チームは潜在的なセキュリティ リスクに迅速に対応し、それらを修復することができます。This enables your security operations team to rapidly respond to potential security risks and remediate them.

Azure 登録ポータルの管理者連絡先情報に、(直接的に、または内部プロセスを介して迅速に) セキュリティ運用の通知を行う連絡先の情報が含まれているようにしてくださいEnsure administrator contact information in the Azure enrollment portal includes contact information that will notify security operations (directly or rapidly via an internal process)

重要なアクセスを定期的にレビューするRegularly review critical access

ビジネスに重要な影響を与える特権が割り当てられているロールは定期的にレビューします。Regularly review roles that are assigned privileges with a business-critical impact.

定期的なレビュー パターンを設定し、役割の変化に応じて、アクセス許可からアカウントが削除されていることを確認します。Set up a recurring review pattern to ensure that accounts are removed from permissions as roles change. レビューは手動で行うことも、Azure AD アクセスレビューなどのツールを使用して自動化されたプロセスを通じて行うこともできます。You can conduct the review manually or through an automated process by using tools such as Azure AD access reviews.

一般的なリスクを検出して修復するDiscover and remediate common risks

Azure テナントのよく知られているリスクを識別し、それらのリスクを修復して、セキュリティ スコアを使用して進行状況を追跡します。Identity well known risks for your Azure tenants, remediate those risks, and track your progress using Secure Score.

セキュリティの検疫に関する一般的なリスクを特定して修復すると、攻撃者にとってコストが増加するため、組織にとっては全体としてのリスクが大幅に軽減されます。Identifying and remediating common security hygiene risks significantly reduces overall risk to your organization by increasing cost to attackers. 低コストでうまく確立された攻撃ベクトルを取り除くと、攻撃者は高度な攻撃方法やテストされていない攻撃方法を購入して使用するしかなくなります。When you remove cheap and well-established attack vectors, attackers are forced to acquire and use advanced or untested attack methods.

Azure Security Center の Azure セキュリティ スコアは、コンピューター、ネットワーク、ストレージとデータのサービス、およびアプリケーションのセキュリティ体制を監視し、潜在的なセキュリティの問題 (VM がインターネットに接続されている、セキュリティ更新プログラムが不足している、エンドポイントの保護や暗号化が不足している、ベースライン セキュリティ構成から逸脱している、Web アプリケーション ファイアウォール (WAF) が不足しているなど) を検出します。Azure Secure Score in Azure Security Center monitors the security posture of machines, networks, storage and data services, and applications to discover potential security issues (internet connected VMs, or missing security updates, missing endpoint protection or encryption, deviations from baseline security configurations, missing Web Application Firewall (WAF), and more). この機能を有効にして (追加コスト不要) 結果を確認し、記載されている推奨事項に従って、技術的修復の計画と実行を、最も優先順位が高い項目から開始します。You should enable this capability (no additional cost), review the findings, and follow the included recommendations to plan and execute technical remediations starting with the highest priority items.

リスクに対処する際には、進行状況を追跡して、ガバナンスおよびリスク軽減プログラムへの継続的な投資を優先させます。As you address risks, track progress and prioritize ongoing investments in your governance and risk reduction programs.

Azure Blueprints によって自動化を進めるIncrease automation with Azure Blueprints

Azure のネイティブ自動化機能を使用して、ワークロードの一貫性、コンプライアンス、デプロイ速度を向上させます。Use Azure’s native automation capabilities to increase consistency, compliance, and deployment speed for workloads.

デプロイとメンテナンスのタスクを自動化することで、手動のタスク時に人的エラーが生じる機会を限定し、セキュリティとコンプライアンスのリスクを軽減します。Automation of deployment and maintenance tasks reduces security and compliance risk by limiting opportunity to introduce human errors during manual tasks. これにより、IT 運用チームとセキュリティチームの両方が、繰り返される手動のタスクから、開発者の取り組みやビジネス上の取り組みの実現、情報の保護などの高い価値を持つタスクに移行できるようにもなります。This will also allow both IT Operations teams and security teams to shift their focus from repeated manual tasks to higher value tasks like enabling developers and business initiatives, protecting information, and so on.

Azure Blueprint サービスを利用して、組織のポリシーと外部の規制に準拠しているアプリケーション環境を迅速かつ一貫した方法でデプロイできます。Utilize the Azure Blueprint service to rapidly and consistently deploy application environments that are compliant with your organization’s policies and external regulations. Azure Blueprint サービスは、RBAC ロール、ポリシー、リソース (VM、ネットワーク、ストレージなど) などを含む環境のデプロイを自動化します。Azure Blueprint Service automates deployment of environments including RBAC roles, policies, resources (VM/Net/Storage/etc.), and more. Azure Blueprints は、Microsoft が膨大な投資を行っている Azure Resource Manager を基盤としていて、Azure におけるリソースのデプロイを標準化し、望ましい状態のアプローチに基づいてリソースのデプロイとガバナンスを実現します。Azure Blueprints builds on Microsoft’s significant investment into the Azure Resource Manager to standardize resource deployment in Azure and enable resource deployment and governance based on a desired-state approach. Azure Blueprint の組み込みの構成を利用すること、独自の構成を作成すること、またはより小さな範囲用の Resource Manager スクリプトだけを使用することができます。You can use built in configurations in Azure Blueprint, make your own, or just use Resource Manager scripts for smaller scope.

開始テンプレートとして使用するセキュリティとコンプライアンスのブループリント サンプルがいくつか提供されています。Several Security and Compliance Blueprints samples are available to use as a starting template.

ベンチマークを使用してセキュリティを評価するEvaluate security using benchmarks

業界標準のベンチマークを使用して、組織の現在のセキュリティ体制を評価します。Use an industry standard benchmark to evaluate your organizations current security posture.

ベンチマークを使用すると、外部の組織から学ぶことで、セキュリティ プログラムを向上させることができます。Benchmarking allows you to improve your security program by learning from external organizations. ベンチマークでは、現在のセキュリティの状態が他の組織と比較してどのような状態であるかを知ることができ、現在のシステムの、成功につながる要素について外部の検証が提供されるほか、チームのセキュリティ戦略全体を強化する機会として役立つギャップを特定することができます。Benchmarking lets you know how your current security state compares to that of other organizations, providing both external validation for successful elements of your current system as well as identifying gaps that serve as opportunities to enrich your team’s overall security strategy. 現在のセキュリティ プログラムが特定のベンチマークや規制標準に結び付けられていない場合でも、業界内外のドキュメント化された理想的な状態を理解することから恩恵を受けられます。Even if your security program isn’t tied to a specific benchmark or regulatory standard, you will benefit from understanding the documented ideal states by those outside and inside of your industry.

  • たとえば、Center for Internet Security (CIS) は、CIS Control Framework にマップされる Azure 用のセキュリティ ベンチマークを作成してきました。As an example, the Center for Internet Security (CIS) has created security benchmarks for Azure that map to the CIS Control Framework. リファレンスのもう 1 つの例は、実世界の観察に基づいてさまざまな敵対者の戦術と手法を定義している MITRE ATT&CK™ のフレームワークです。Another reference example is the MITRE ATT&CK™ framework that defines the various adversary tactics and techniques based on real-world observations. これらの外部リファレンスの制御マッピングは、導入済みの現在の戦略と、業界の他の専門家が使用する戦略とのギャップを理解するのに役立ちます。These external references control mappings help you to understand any gaps between your current strategy what you have and what other experts in the industry.

ポリシーへの準拠を監査して適用するAudit and enforce policy compliance

セキュリティ チームが環境の監査を行って、組織のセキュリティ ポリシーへの準拠についてレポートを作成していることを確認します。Ensure that the security team is auditing the environment to report on compliance with the security policy of the organization. セキュリティ チームは、これらのポリシーへの準拠を適用することもできます。Security teams may also enforce compliance with these policies.

どの規模の組織にも、セキュリティ コンプライアンスの要件があります。Organizations of all sizes will have security compliance requirements. 業界、政府、および社内のセキュリティ ポリシーをすべて監査し、適用する必要があります。Industry, government, and internal corporate security policies all need to be audited and enforced. ポリシーの監視は、初期構成が正しいことと、および時間が経過しても準拠が継いていることを確認するために不可欠です。Policy monitoring is critical to check that initial configurations are correct and that it continues to be compliant over time.

Azure では、Azure Policy を利用して、コンプライアンスを適用するポリシーを作成および管理できます。In Azure, you can take advantage of Azure Policy to create and manage policies that enforce compliance. Azure Blueprints と同様に、Azure Policy は Azure プラットフォームの基盤となっている Azure Resource Manager 機能に基づいて構築されています (Azure Policy も Azure Blueprints を介して割り当てることができます)。Like Azure Blueprints, Azure Policies are built on the underlying Azure Resource Manager capabilities in the Azure platform (and Azure Policy can also be assigned via Azure Blueprints).

Azure でこれを行う方法の詳細については、チュートリアルの「コンプライアンスを強制するポリシーの作成と管理」 を参照してください。For more information on how to do this in Azure, please review Tutorial: Create and manage policies to enforce compliance.

ID のリスクを監視するMonitor identity Risk

侵害された可能性がある ID に関する警告の ID 関連リスク イベントを監視し、それらのリスクを修復します。Monitor identity related risk events for warning on potentially compromised identities and remediate those risks.

ほとんどのセキュリティ インシデントは、盗まれた ID を使用して攻撃者が最初にアクセスを成功させた後に発生します。Most security incidents take place after an attacker initially gains access using a stolen identity. 多くの場合、これらの ID は低い特権で使われ始めますが、攻撃者はその ID を使用して水平方向に走査し、より高い特権を持つ ID へのアクセスを取得します。These identities can often start with low privileges, but the attackers then use that identity to traverse laterally and gain access to more privileged identities. 攻撃者が最終的なターゲットのデータやシステムへのアクセスを制御するまで、これが必要に応じて繰り返されます。This repeats as needed until the attacker controls access to the ultimate target data or systems.

Azure Active Directory では、アダプティブ機械学習アルゴリズム、ヒューリスティック、および既知の侵害された資格情報 (ユーザー名とパスワードのペア) を使用して、ユーザー アカウントに関連する疑わしいアクションが検出されます。Azure Active Directory uses adaptive machine learning algorithms, heuristics, and known compromised credentials (username/password pairs) to detect suspicious actions that are related to your user accounts. これらのユーザー名とパスワードのペアは、パブリックなダーク Web サイト (侵害されたパスワードを攻撃者がダンプすることが多い場所) を監視し、セキュリティ研究者、法執行機関、Microsoft のセキュリティ チームなどと協力することで入手されています。These username/password pairs come from monitoring public and dark web sites (where attackers often dump compromised passwords) and by working with security researchers, law enforcement, Security teams at Microsoft, and others.

報告されたリスク イベントは、次の 2 つの場所で確認できます。There are two places where you review reported risk events:

また、 Identity Protection リスク イベント API  を使用すると、Microsoft Graph を使ってプログラムからセキュリティの検出にアクセスすることもできます。In addition, you can use the Identity Protection risk events API to gain programmatic access to security detections using Microsoft Graph.

これらのリスクは、報告された各アカウントに手動で対処するか、これらのリスクが高いイベントに対してパスワードの変更を要求するユーザー リスク ポリシーを設定して修復します。Remediate these risks by manually addressing each reported account or by setting up a user risk policy to require a password change for these high risk events.

侵入テストPenetration testing

侵入テストを使用して、セキュリティの防御を検証します。Use Penetration Testing to validate security defenses.

セキュリティの防御を実世界で検証することは、防御の戦略と実装を検証するうえで不可欠です。Real world validation of security defenses is critical to validate your defense strategy and implementation. これは、侵入テスト (1 回のみの攻撃をシミュレート) またはレッド チーム プログラム (お使いの環境をターゲットにする永続的な脅威アクターをシミュレート) によって実現できます。This can be accomplished by a penetration test (simulates a one time attack) or a red team program (simulates a persistent threat actor targeting your environment).

シミュレートされた攻撃の計画と実行については、Microsoft が公開しているガイダンスに従ってください。Follow the guidance published by Microsoft for planning and executing simulated attacks.

不安があるプロトコルを検出して置き換えるDiscover & replace insecure protocols

不安がある従来のプロトコルである SMBv1、LM/NTLMv1、wDigest、署名なしの LDAP バインド、Kerberos の弱い暗号の使用を検出して無効にします。Discover and disable the use of legacy insecure protocols SMBv1, LM/NTLMv1, wDigest, Unsigned LDAP Binds, and Weak ciphers in Kerberos.

認証プロトコルは、ほぼすべてのセキュリティ保証の重要な基盤です。Authentication protocols are a critical foundation of nearly all security assurances. これらの古いバージョンは、ネットワークにアクセスする攻撃者によって悪用される可能性があり、サービスとしてのインフラストラクチャ (IaaS) 上のレガシ システムで広く使用されていることがよくあります。These older versions can be exploited by attackers with access to your network and are often used extensively on legacy systems on Infrastructure as a Service (IaaS).

リスクを軽減する方法を以下に示します。Here are ways to reduce your risk:

  • Azure Sentinel の安全でないプロトコルダッシュボードまたはサードパーティツールでログを確認して、プロトコルの使用状況を検出しますDiscover protocol usage by reviewing logs with Azure Sentinel’s Insecure Protocol Dashboard or third party tools

  • SMBNTLMwdigestのガイダンスに従って、これらのプロトコルの使用を制限または無効にします。Restrict or Disable use of these protocols by following guidance for SMB, NTLM, WDigest

運用が中断されるリスクを軽減するため、パイロットまたはその他のテスト方法を使用して変更を実装することをお勧めします。We recommend implementing changes using pilot or other testing method to mitigate risk of operational interruption.

高度なセキュリティ機能Elevated security capabilities

企業アーキテクチャ内で特別なセキュリティ機能を利用するかどうかを検討します。Consider whether to utilize specialized security capabilities in your enterprise architecture.

これらの対策には、セキュリティを強化し、規制要件を満たせる可能性がありますが、運用や効率に悪影響を及ぼすこともある複雑さが生じる可能性もあります。These measures have the potential to enhance security and meet regulatory requirements, but can introduce complexity that may negatively impact your operations and efficiency.

これらのセキュリティ対策については注意深く検討し、必要に応じて慎重に使用することをお勧めします。We recommend careful consideration and judicious use of these security measures as required:

次のステップNext steps

Microsoft のセキュリティに関するその他のガイダンスについては、マイクロソフトのセキュリティに関するドキュメントを参照してください。For additional security guidance from Microsoft, see Microsoft security documentation.