Azure のセキュリティに関するベスト プラクティスAzure security best practices

以下に示すのは、Microsoft がお客様と自社の環境から得た教訓に基づいて推奨する、Azure のセキュリティに関する優先度の高いベスト プラクティスです。These are the top Azure security best practices that Microsoft recommends based on lessons learned across customers and our own environments.

Microsoft Tech Community で、これらのベスト プラクティスのビデオ プレゼンテーション を参照できます。You can view a video presentation of these best practices in the Microsoft Tech Community.

1.ユーザー: クラウド セキュリティのための移行の過程についてチームを教育する1. People: Educate teams about the cloud security journey

"チームは、自分たちが進む移行の過程を理解している必要があります。 "The team needs to understand the journey they're on.

内容: セキュリティ担当および IT 担当チームに、クラウド セキュリティのための移行の過程と、対処することになる次のような変化について教育します。What: Educate your security and IT teams on the cloud security journey and the changes they will be navigating including:

  • クラウド上の脅威に対する変化Changes to threats in the cloud
  • 責任共有モデルと、それがセキュリティに与える影響Shared responsibility model and how it impacts security
  • クラウド導入に一般的に付随する、カルチャと役割または責任の変化Cultural and role/responsibility changes that typically accompany cloud adoption

理由: クラウドへの移行は重大な変化であり、セキュリティに関する考え方とアプローチに変化が求められます。Why: Moving to the cloud is a significant change that requires a shift in mindset and approach for security. セキュリティが組織にもたらす結果は変化しませんが、クラウドでこれを実現する最善の方法は多くの場合に変化し、大幅に変化する場合もあります。While the outcomes security provides to the organization won’t change, the best way to accomplish this in the cloud often changes, sometimes significantly.

クラウドへの移行は、多くの点で、一戸建てから高層の高級賃貸マンションへの引っ越しに似ています。In many ways, moving to the cloud is similar to moving from a standalone house into a high-rise luxury apartment building. 基本的なインフラストラクチャ (配管、電気など) を引き続き使用し、同じような活動 (人付き合い、料理、テレビ、インターネットなど) を行いますが、多くの場合、ビルに付属する設備 (ジム、レストランなど) とその提供者および管理者、自分の毎日のルーチンには大きな違いがあります。You still have basic infrastructure (plumbing, electricity, etc.) and perform similar activities (socializing, cooking, TV and Internet, etc.) but there often quite a difference in what comes with the building (gym, restaurants, etc.), who provides and maintains them, and your daily routine.

対象者: セキュリティおよび IT の組織でセキュリティの職責にある全員が、このコンテキストと変化を理解している必要があります (CIO または CISO から技術者まで)。Who: Everyone in the security and IT organization with any security responsibilities should be familiar with this context and the changes (from CIO/CISO to technical practitioners).

方法: クラウド環境への移行時にデプロイおよび運用を適切に行うために必要なコンテキストをチームに提供します。How: Provide teams with the context required to successfully deploy and operate during the transition to the cloud environment. Microsoft は、お客様と自社の IT 組織がクラウドへの移行の過程で得た教訓を公開しています。Microsoft has published lessons learned by our customers and our own IT organization on their journeys to the cloud:

Azure セキュリティ ベンチマーク「GS-3: 組織の役割、責任、責務の整合」も参照してください。Also see the Azure Security Benchmark GS-3: Align organization roles, responsibilities, and accountabilities.

2.ユーザー: クラウド セキュリティ テクノロジについてチームに教育する2. People: Educate teams on cloud security technology

"どこに向かっているのかを皆が理解する必要があります。 "People need to understand where they're going.

内容: 次のようなクラウド リソースのセキュリティ保護に関する技術教育のために、チームの時間を確保します。What: Ensure your teams have time set aside for technical education on securing cloud resources including:

  • クラウド テクノロジとクラウド セキュリティ テクノロジCloud technology and cloud security technology
  • 推奨される構成とベスト プラクティスRecommended configurations and best practices
  • 技術的な詳細情報が必要な場合の確認先Where to learn more technical details as needed

理由: 技術チームは、情報に基づいた適切なセキュリティ上の意思決定を行うために、技術情報にアクセスする必要があります。Why: Technical teams need access to technical information to make sound informed security decisions. 技術チームは実際の職務を通じて新しいテクノロジを学ぶことに優れていますが、多くの場合、クラウドの詳細情報の量は、学習を日常業務に適合させる彼らの能力を上回ります。Technical teams are good at learning new technologies on the job, but the volume of details in the cloud often overwhelms their ability to fit learning into their daily routine.

技術の学習に専念する時間を作ることで、人々がクラウドのセキュリティを評価し、既存のスキルとプロセスをどのように適合させるかを考える能力に自信をつける時間を確保できます。Structuring dedicated time for technical learning helps ensure people have time to build confidence on their ability to assess cloud security and think through how to adapt their existing skills and processes. 軍隊で最も有能な特殊作戦チームでさえ、最高のパフォーマンスを発揮するには訓練と情報が必要です。Even the most talented special operations teams in the military need training and intelligence to perform at their best.

対象者: クラウド テクノロジを直接操作するすべてのロール (セキュリティと IT の部門) に、クラウド プラットフォームとそのセキュリティ保護の方法に関する技術の学習に専念する時間を確保する必要があります。Who: All roles that directly interact with cloud technology (in security and IT departments) should dedicate time for technical learning on cloud platforms and how to secure them.

さらに、セキュリティおよび IT 技術マネージャー (および多くの場合、プロジェクト マネージャー) は、クラウド リソースを保護するための技術的な詳細情報に精通している必要があります (これにより、クラウド イニシアチブをより効果的に主導および調整できるようになります)。Additionally security and IT technical managers (and often project managers) should develop familiarity with some technical details for securing cloud resources (as this will help them more effectively lead and coordinate cloud initiatives).

方法: セキュリティの技術担当者が、クラウド資産をセキュリティで保護する方法に関するトレーニングをマイペースで進められるように時間を確保します。How: Ensure that technical professionals in security have time set aside for self-paced training on how to secure cloud assets. 常に実現できるとは限りませんが、理想的には、熟練したインストラクターとハンズオン ラボが用意された正式なトレーニングにアクセスできるようにします。While not always feasible, ideally provide access to formal training with an experienced instructor and hands-on labs.

重要

ID プロトコルは、クラウドでのアクセス制御に不可欠ですが、オンプレミスのセキュリティでは優先されないことが多いため、セキュリティ チームは、これらのプロトコルとログに確実に精通することに集中する必要があります。Identity protocols are critical to access control in the cloud but often not prioritized in on-premises security, so security teams should ensure to focus on developing familiarity with these protocols and logs.

Microsoft は、技術担当者が Azure リソースのセキュリティを強化し、コンプライアンスをレポートするうえで役立つ広範なリソースを提供しています。Microsoft provides extensive resources to help technical professionals ramp up on securing Azure resources and report compliance:

Azure セキュリティ ベンチマーク「GS-3: 組織の役割、責任、責務の整合」も参照してください。Also see the Azure Security Benchmark GS-3: Align organization roles, responsibilities, and accountabilities

3.プロセス:クラウドのセキュリティに関する意思決定の説明責任を割り当てる3. Process: Assign accountability for cloud security decisions

"セキュリティに関する意思決定は、その説明責任を負う者がいなければ行われません。 "If nobody is accountable for making security decisions, they won’t get made.

内容: エンタープライズ Azure 環境に対して各種類のセキュリティ上の意思決定を行う担当者を指定します。What: Designate who is responsible for making each type of security decision for the enterprise Azure environment.

理由: セキュリティに関する意思決定の担当者を明確にすると、クラウドの導入スピードがアップし、"かつ" セキュリティが向上します。Why: Clear ownership of security decisions speeds up cloud adoption and increases security. だれも意思決定を行う権限を実感しておらず、だれに意思決定を求めるべきかが不明で、情報に基づいた意思決定を調べる動機がないため、通常、欠如によって摩擦が生じます。Lack of typically creates friction because nobody feels empowered to make decisions, nobody knows who to ask for a decision, and nobody is incented to research a well-informed decision. この摩擦によって、ビジネス目標、開発者のタイムライン、IT の目標、セキュリティの保証が頻繁に妨げられ、次のような結果になります。This friction frequently impedes business goals, developer timelines, IT goals, and security assurances, resulting in:

  • セキュリティ承認待ちによるプロジェクトの停滞Stalled projects that are waiting for security approval
  • セキュリティの承認を待つことができなかった安全でないデプロイInsecure deployments that couldn’t wait for security approval

対象者: セキュリティ リーダーが、クラウドに関するセキュリティ上の意思決定を行うことに説明責任を負うチームまたは個人を指定します。Who: Security leadership designates which teams or individuals are accountable for making security decisions about the cloud.

方法: 主要なセキュリティ上の意思決定を行う責任を持つグループ (または個人) を指定します。How: Designate groups (or individuals) that will be responsible for making key security decisions.

これらの所有者と連絡先情報を文書化し、セキュリティ、IT、クラウドの各担当チーム内でこれを広く知らせて、すべてのロールが簡単に連絡できるようにします。Document these owners, their contact information, and socialize this widely within the security, IT, and cloud teams to ensure it's easy for all roles to contact them.

セキュリティ上の意思決定が必要な一般的な領域、説明、通常どのチームが決定を行うかを以下に示します。These are the typical areas where security decisions are needed, descriptions, and which teams typically make the decisions.

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

注意

  • 意思決定者は、この責任が伴うクラウドの領域において適切な教育を受けている必要があります。Ensure decision makers have the appropriate education in their area of the cloud to accompany this responsibility.
  • 記録を残し、組織を長期にわたって導くために、決定事項をポリシーと標準に確実に文書化します。Ensure decisions are documented in policy and standards to provide a record and guide the organization over the long term.

Azure セキュリティ ベンチマーク「GS-3: 組織の役割、責任、責務の整合」も参照してください。Also see the Azure Security Benchmark GS-3: Align organization roles, responsibilities, and accountabilities

4.プロセス:クラウドのインシデント対応 (IR) プロセスを更新する4. Process: Update Incident Response (IR) processes for cloud

"緊急時に緊急時の計画をする時間はありません。 "You don’t have time to plan for a crisis during a crisis.

内容: プロセスを更新し、Azure クラウド プラットフォーム上のセキュリティ インシデントに対応するためにアナリストを準備します (導入済みのネイティブ脅威検出ツールを含む)。What: Update processes and prepare analysts to for responding to security incidents on your Azure cloud platform (including any native threat detection tools you have adopted). プロセスを更新し、チームを準備して、インシデント調査、修復、脅威ハンティング時に最大限のパフォーマンスを発揮できるように、シミュレートされた攻撃を使用して練習します。Update processes, prepare your team, and practice with simulated attacks so they can perform at their best during incident investigation, remediation, and threat hunting.

理由: アクティブな攻撃者は、状況を制御することがすぐに困難になる可能性のある差し迫ったリスクを組織にもたらします。そのため、攻撃に対して迅速に対応する必要があります。Why: Active attackers present an immediate risk to the organization that can quickly become a difficult to control situation, so you must rapidly effectively respond to attacks. 企業のデータ、システム、アカウントをホストしているすべてのクラウド プラットフォームを含む資産全体に対して、このインシデント対応 (IR) プロセスを有効にする必要があります。This incident response (IR) process must be effective for your entire estate including all cloud platforms hosting enterprise data, systems, and accounts.

多くの類似点がある一方で、クラウド プラットフォームには、既存のプロセスを破綻させる可能性のあるオンプレミス システムとの重要な技術的な違いがあります。これは通常、情報が別の形式で利用可能であるためです。While similar in many ways, cloud platforms have important technical difference from on-premises systems that can break existing processes, typically because information is available in a different form. セキュリティ アナリストは、不慣れな環境に対して迅速に対応する必要があり、そのため対応が遅くなる可能性があるという課題を抱えている場合があります (特に、従来のオンプレミス アーキテクチャとネットワークやディスクのフォレンジックア プローチについてのみトレーニングされている場合)。Security analysts may also have challenges rapidly responding to an unfamiliar environment that can slow them down (especially if they are trained only on classic on-premises architectures and network/disk forensics approaches).

対象者: IR プロセスの最新化は、通常、他のグループからの知識と専門知識をサポートするセキュリティ運用部門によって主導されます。Who: Modernizing the IR processes is typically led by Security Operations with support from other groups for knowledge and expertise.

  • "スポンサー" - このプロセス最新化は、通常、セキュリティ運用担当部長 (または同等のスポンサー) によって後援されます。Sponsorship - This process modernization is typically sponsored by the Security Operations director or equivalent.
  • "実行" - 既存のプロセスを適合させる (または、初めて作成する) ことは、次のことを含む共同作業です。Execution - Adapting existing processes (or writing them for the first time) is a collaborative effort involving
    • セキュリティ運用 インシデント管理チームまたはリーダー – プロセスに対する更新と、法律担当およびコミュニケーションや広報担当のチームを含む主要な外部関係者の統合を主導するSecurity Operations incident management team or leadership –leads updates to process and integration of key external stakeholders including legal and communications/public relations teams
    • セキュリティ運用 セキュリティ アナリスト – 技術的なインシデント調査とトリアージに関する専門知識を提供するSecurity Operations security analysts – provide expertise on technical incident investigation and triage
    • 中央 IT 運用 - クラウド プラットフォームに関する専門知識を (直接、クラウドのセンター オブ エクセレンスを通じて、または直接、または外部のコンサルタントを通じて) 提供するCentral IT Operations - Provides expertise on cloud platform (directly, via cloud center of excellence, or via external consultants)

方法: プロセスを更新し、アクティブな攻撃者を見つけたときに何をすればよいかがわかるように、チームを準備します。How: Update processes and prepare your team so they know what to do when they find an active attacker.

  • プロセスとプレイブック: 既存の調査、修復、脅威ハンティングのプロセスを、クラウド プラットフォームのしくみ (新しいまたは異なるツール、データ ソース、ID プロトコルなど) の違いに合わせて調整します。Processes and Playbooks: Adapt existing investigations, remediation, and threat hunting processes to the differences of how cloud platforms work (new/different tools, data sources, identity protocols, etc.).

  • 教育:クラウド全体の変革、プラットフォームのしくみに関する技術的な詳細、新しいまたは更新されたプロセスについてアナリストを教育することで、アナリストがどのような違いがあるかを把握し、必要なものがどこで見つかるかを理解できるようにします。Education: Educate analysts on the overall cloud transformation, technical details of how the platform works, and new/updated processes so that they know what will be different and where to go for what they need.

"主要な対象領域: " リソースのリンクには多くの詳細が記載されていますが、教育および計画の取り組みで重点を置くべき重要な領域は次のとおりです。Key Focus Areas: While there are many details described in the resource links, these are key areas to focus your education and planning efforts:

  • 共有責任モデルとクラウド アーキテクチャ: セキュリティ アナリストにとって Azure は、馴染みのある VM や、オンプレミスとは大きく異なるその他のサービス (Azure SQL Azure Functions など) を含む多くのサービスを提供するソフトウェア定義データセンターです。そこでは、最も価値のあるデータが、基礎になる OS または VM のログではなく、サービス ログまたは専用の脅威検出サービスの中に存在します (Microsoft が運用し、複数の顧客にサービスを提供する)。Shared responsibility model and cloud architectures: To a security analyst, Azure is a software defined datacenter that provides many services including VMs (familiar) and others that are very different from on-premises such as Azure SQL Azure Functions, etc. where the best data is in the service logs or the specialized threat detection services rather than in logs for the underlying OS/VMs (which are operated by Microsoft and service multiple customers). アナリストは、このコンテキストを理解して日常のワークフローに統合し、予想されるデータ、それを取得する場所、それに使用される形式がわかるようにする必要があります。Analysts need to understand and integrate this context into their daily workflows so they know what data to expect, where to get it, and what format it will be in.
  • エンドポイント データ ソース: 多くの場合、直接ディスク アクセスという従来のアプローチとは対照的に、Azure Security Center や EDR システムなどのネイティブ クラウド検出ツールを使用すると、クラウドでホストされているサーバー上の攻撃やマルウェアに関する分析情報やデータの取得が、より高速、簡単、正確に行えるようになります。Endpoint data sources: Getting insights and data for attacks and malware on cloud hosted servers is often faster, easier, and more accurate with native cloud detection tools like Azure Security Center and EDR systems as opposed to traditional approaches of direct disk access. 直接ディスクのフォレンジックは、それが可能であり法的手続きのために必要とされるシナリオに対して利用可能 (Azure でのコンピューター フォレンジック) ですが、これは多くの場合、攻撃を検出して調査するには最も効率の悪い方法です。While direct disk forensics are available for scenarios where it is possible and required for legal proceedings (Computer forensics in Azure), this is often the most inefficient way to detect and investigate attacks.
  • ネットワークと ID のデータ ソース: クラウド プラットフォームの多くの機能では、主に ID を使用して Azure portal へのアクセスなどのアクセス制御が行われます (ただし、ネットワーク アクセス制御も広く使用されています)。Network and Identity data sources: Many functions of cloud platforms primarily use identity primarily for access control such as access to the Azure portal (though network access controls are used extensively as well). このため、アナリストはクラウド ID プロトコルについて理解を深め、インシデントの調査と修復をサポートするために、攻撃者のアクティビティ (および正当なユーザー アクティビティ) について完全で詳細な全体像を把握する必要があります。This requires analysts to develop an understanding of cloud identity protocols to get a full, rich, picture of attacker activity (and legitimate user activity) to support incident investigation and remediation. ID ディレクトリとプロトコルもオンプレミスとは異なり、通常は、オンプレミスでよく見られる LDAP、Kerberos、NTLM、Active Directory ではなく、SAML、OAuth、OIDC とクラウド ディレクトリに基づいています。Identity directories and protocols are also different from on-premises as they are typically based on SAML, OAuth, and OIDC and Cloud directories rather than LDAP, Kerberos, NTLM, and Active Directory that are commonly found on-premises.
  • 実習: シミュレートされた攻撃と対応は、組織内のセキュリティ アナリスト、脅威ハンター、インシデント マネージャー、およびその他の関係者にとって、組織の反射的対応と技術的な準備を確立するのに役立ちます。Practice exercises: simulated attacks and response can help build organizational muscle memory and technical readiness for your security analysts, threat hunters, incident managers, and other stakeholders in your organization. 実際の職務を通じて学び、適応することは、インシデント対応の当然の部分ですが、緊急時に知る必要があることを最小限に抑えるために作業する必要があります。Learning on the job and adapting is a natural part of incident response, but you should work to minimize how much you have to learn in a crisis.

主要リソース:Key Resources:

Azure セキュリティ ベンチマーク「IR-1: 準備 – インシデント対応プロセスを Azure 用に更新する」も参照してください。Also see the Azure Security Benchmark IR-1: Preparation – update incident response process for Azure.

5.プロセス:セキュリティ態勢管理を確立する5. Process: Establish security posture management

"まず、自らを知ること。 "First, know thyself.

内容: 次のようにして、Azure 環境のセキュリティ態勢を積極的に管理するようにします。What: Ensure that you are actively managing the security posture of your Azure environment by:

  • 次に対する責任の明確な所有権を割り当てるAssigning clear ownership of responsibilities for
    • セキュリティ態勢の監視Monitoring security posture
    • 資産に対するリスクの軽減Mitigating risks to assets
  • これらのタスクの自動化と簡略化Automating and simplifying these tasks

理由: セキュリティの検疫に関する一般的なリスクを迅速に特定して修復すると、組織としてのリスクが大幅に軽減されます。Why: Rapidly identifying and remediating common security hygiene risks significantly reduces organizational risk.

ソフトウェア定義というクラウド データセンターの性質のため、広範な資産のインストルメンテーションによって、セキュリティ リスク (ソフトウェアの脆弱性、セキュリティ構成の不備など) を継続的に監視できます。The software defined nature of cloud datacenters enables continuous monitoring of security risk (software vulnerabilities, security misconfigurations, etc.) with extensive asset instrumentation. 開発者と IT チームが VM、データベース、その他のリソースをすばやくデプロイできることで、リソースが安全に構成されて積極的に監視されるようにする必要性も生じます。The speed at which developers and IT team can deploy VMs, databases, and other resources also create a need to ensure resources are configured securely and actively monitored.

これらの新しい機能によって新しい可能性が提供されますが、それらから価値を実現するには、それらを使用するための責任を割り当てる必要があります。These new capabilities offer new possibilities, but realizing value from them requires assigning responsibility for using them. 急速に進化するクラウド運用を継続的に実行するには、人が行うプロセスを可能な限り簡素化し、自動化する必要もあります。Executing consistently on with rapidly evolving cloud operations also requires keeping human processes as simple and automated as possible. セキュリティ原則の「シンプルさを促進する」を参照してください。See the “Drive Simplicity” security principle.

注意

簡素化とオートメーションの目標は、職を排除することではなく、反復的なタスクの負担を人々から取り除くことで、IT チームや DevOps チームとの提携や教育など、より価値の高い、人間のアクティビティに専念できます。The goal of simplification and automation isn’t about getting rid of jobs, but about removing the burden of repetitive tasks from people so they can focus on higher value human activities like engaging with and educating IT and DevOps teams.

対象者: 通常、これは次の 2 セットの責任に分けられます。Who: This is typically divided into two sets of responsibilities:

  • セキュリティ態勢管理 – この新しい機能は、多くの場合、既存の脆弱性管理またはガバナンス機能が進化したものです。Security posture management – This newer function is often an evolution of existing vulnerability management or governance functions. これには、Azure Security Center セキュリティ スコアで保護されたスコアやその他のデータ ソースを使用した全体的なセキュリティ態勢の監視、リスクを軽減するためのリソース所有者との積極的な連携、セキュリティ リーダーへのリスクの報告が含まれます。This includes monitoring overall security posture using Azure Security Center Secure Score and other data sources, actively working with resource owners to mitigate risks, and reporting risk to security leadership.

  • セキュリティ修復: これらのリスクに対処することについての説明責任を、これらのリソースの管理を担当するチームに割り当てます。Security remediation: Assign accountability for addressing these risks to the teams responsible for managing those resources. これは、独自のアプリケーション リソースを管理している DevOps チームか、 中央 IT 運用 のテクノロジ専門チームである必要があります。This should either the DevOps teams managing their own application resources or the technology-specific teams in Central IT Operations:

    • "コンピューティングおよびアプリ リソース:"Compute and Apps Resources:
      • アプリケーション サービス - アプリケーション開発またはセキュリティ チームApp Services - Application Development/Security Team(s)
      • コンテナー - アプリケーション開発またはインフラストラクチャ/IT 運用、あるいはその両方Containers - Application Development and/or Infrastructure/IT Operations
      • VM/スケールセット/コンピューティング - IT/インフラストラクチャ運用VMs/Scale sets/compute - IT/Infrastructure Operations
    • "データおよびストレージ リソース:"Data & Storage Resources:
      • SQL/Redis/Data Lake Analytics/Data Lake Store - データベース チームSQL/Redis/Data Lake Analytics/Data Lake Store - Database Team
      • ストレージ アカウント - ストレージまたはインフラストラクチャ チームStorage Accounts - Storage/Infrastructure Team
    • "ID およびアクセス リソース:"Identity and Access Resources:
      • サブスクリプション - ID チームSubscriptions - Identity Team(s)
      • Key Vault – ID または情報/データ セキュリティ チームKey Vault – Identity or Information/Data Security Team
    • "ネットワーク リソース - ネットワーク セキュリティ チームNetworking Resources - Network Security Team
    • "IoT セキュリティ - IoT 運用チームIoT Security - IoT Operations Team

方法: セキュリティは全員の職務ですが、現在、それがどれだけ重要か、何をどのように行うのかを全員が知っているわけではありません。How: Security is everyone’s job, but not everyone currently knows how important it is, what to do, and how to do it.

  • リソース所有者が可用性、パフォーマンス、コスト、およびその他の成功要因について説明責任を負うのと同様に、セキュリティ リスクについて説明責任を負うようにします。Hold resource owners accountable for the security risk just as they are held accountable for availability, performance, cost, and other success factors.
  • セキュリティ リスクが資産にとって重要である理由、リスクを軽減するために何を行う必要があり、生産性の低下を最小限に抑えてそれを実装する方法についてリソース所有者が明確に理解できるようにサポートします。Support resource owners with a clear understanding of why security risk matters to their assets, what they should do to mitigate risk, and how to implement it with minimal productivity loss.

重要

多くの場合、リソースをセキュリティで保護する理由、対象、方法についての説明は、リソースの種類が異なっても類似していますが、各チームが既に知っていて配慮していることに関連付けることが重要です。The explanations for why, what, and how to secure resources are often similar across different resource types and applications, but it's critical to relate these to what each team already knows and cares about. セキュリティ チームは、チームを成功させることに焦点を合わせた信頼できるアドバイザー兼パートナーとして、IT および DevOps チームと連携する必要があります。Security teams should engage with their IT and DevOps counterparts as a trusted advisor and partner focused on enabling these teams to be successful.

ツール: Azure Security Center のセキュリティ スコアは、さまざまな資産に関する、Azure において最も重要なセキュリティ情報の評価を表します。Tooling: Secure Score in Azure Security Center provides an assessment of the most important security information in Azure for a wide variety of assets. これは、態勢管理の出発点となるものであり、カスタムの Azure ポリシーやその他のメカニズムで必要に応じて補完することができます。This should be your starting point on posture management and can be supplemented with custom Azure policies and other mechanisms as needed.

頻度: Azure セキュリティ スコアを確認する一定の頻度 (通常は月 1 回) を設定し、具体的な改善目標を定めたイニシアティブを計画します。Frequency: Set up a regular cadence (typically monthly) to review Azure secure score and plan initiatives with specific improvement goals. 頻度は必要に応じて増やすことができます。The frequency can be increased as needed.

ヒント

可能な場合は、アクティビティをゲーム化してエンゲージメントを高めます。たとえば、DevOps チーム向けにスコアを最も高める楽しいコンテストや賞を作ります。Gamify the activity if possible to increase engagement, such as creating fun competitions and prizes for the DevOps teams that improve their score the most.

Azure セキュリティ ベンチマーク「GS-2: セキュリティ態勢管理の戦略を定義する」も参照してください。Also see the Azure Security Benchmark GS-2: Define security posture management strategy.

6.テクノロジ: パスワードレス認証または多要素認証 (MFA) を必須にする6. Technology: Require Passwordless or Multi-Factor Authentication (MFA)

"自社のセキュリティは、間違いなく専門の攻撃者が管理者のパスワードを推測したり盗んだりできないものだと言えますか?Are you willing to bet the security of your enterprise that professional attackers can't guess or steal your admin's password?

内容: 重大な影響がある管理者全員に、パスワードレス認証または多要素認証 (MFA) の使用を義務付けます。What: Require all critical impact admins to use passwordless or multi-factor authentication (MFA).

理由: 古い 'スケルトン キー' では現代の泥棒から家を保護できないのと同じように、パスワードでは、現在の一般的な攻撃からアカウントを保護することはできません。Why: Just as antique ‘skeleton keys' won’t protect a house against a modern day burglar, passwords cannot protect accounts against common attacks we see today. 技術的な詳細については、「パスワードは重要ではない」を参照してください。Technical details are described in Your Pa$$word doesn't matter.

かつて MFA は面倒な追加の手順でしたが、現在のパスワードレス アプローチは、Windows Hello やモバイル デバイスでの顔認識などの生体認証アプローチを使用すると、ログオン エクスペリエンスが向上します (パスワードを覚えたり入力したりする必要はありません)。While MFA was once a burdensome extra step, Passwordless approaches today improve the logon experience using biometric approaches like facial recognition in Windows Hello and mobile devices (where you don’t have to remember or type a password). さらに、ゼロ トラスト アプローチを使用すると、信頼されたデバイスが記憶されます。これにより、帯域外の MFA アクションの要求を減らすことができます (「ユーザー サインインの頻度」を参照してください)。Additionally, zero trust approaches remember trusted devices, which reduce prompting for annoying out of band MFA actions (see user sign-in frequency).

対象者: パスワードと多要素の取り組みは、通常、ID とキーの管理またはセキュリティ アーキテクチャあるいはその両方によって主導されます。Who: Password and multi-factor initiative is typically led by Identity and Key Management and/or Security Architecture.

方法: パスワードレスまたは MFA 認証を実装し、その使用方法について管理者をトレーニングします (必要な場合)。また、管理者に対して、記述されたポリシーを使用することに従うように要求します。How: Implement Passwordless or MFA authentication, train administrators on how to use it (as needed), and require admins to follow using written policy. これは、次の 1 つまたは複数のテクノロジによって実現できます。This can be accomplished by one or more of these technologies:

注意

現在、テキスト メッセージ ベースの MFA は攻撃者が比較的安価にバイパスできるため、パスワードレスとより強力な MFA を重視してください。Text Message based MFA is now relatively inexpensive for attackers to bypass, so focus on passwordless & stronger MFA.

Azure セキュリティ ベンチマーク「ID-4: すべての Azure Active Directory ベースのアクセスに強力な認証制御を使用する」も参照してください。Also see the Azure Security Benchmark ID-4: Use strong authentication controls for all Azure Active Directory based access.

7.テクノロジ: ネイティブ ファイアウォールとネットワーク セキュリティを統合する7. Technology: Integrate native firewall and network security

"ネットワーク攻撃に対するシステムとデータの保護を簡略化します。 "Simplify protection of systems and data against network attacks.

内容: Azure Firewall、Azure Web App Firewall (WAF)、および分散型サービス拒否 (DDoS) の緩和策をネットワーク セキュリティ アプローチに統合することによって、ネットワークのセキュリティ戦略とメンテナンスを簡略化します。What: Simplify your network security strategy and maintenance by integrating Azure Firewall, Azure Web App Firewall (WAF), and Distributed Denial of Service (DDoS) mitigations into your network security approach.

理由: わかりやすくすることはセキュリティにとって重要です。そうすることで、混乱、誤りの防止、およびその他の人為的なエラーによるリスクの可能性が軽減されるからです。Why: Simplicity is critical to security as it reduces likelihood of risk from confusion, misconfigurations, and other human errors. セキュリティ原則の「シンプルさを促進する」を参照してください。See the “Drive Simplicity” security principle.

ファイアウォールと WAF は、悪意のあるトラフィックからアプリケーションを保護するための重要な基本セキュリティ制御ですが、そのセットアップとメンテナンスは複雑で、セキュリティ チームの多くの時間と注意を費やすことがあります (カスタムのアフターパーツを車に追加するのと同様)。Firewalls and WAFs are important basic security controls to protect applications from malicious traffic, but their setup and maintenance can be complex and consume a significant amount of the security team’s time and attention (similar to adding custom aftermarket parts to a car). Azure のネイティブ機能を使用すると、ファイアウォール、Web アプリケーション ファイアウォール、分散型サービス拒否 (DDoS) の軽減策などの実装と運用を簡単に行うことができます。Azure’s native capabilities can simplify implementation and operation of Firewalls, Web Application Firewalls, Distributed Denial of Service (DDoS) mitigations, and more.

これにより、Azure サービスのセキュリティの評価、セキュリティ運用の自動化、アプリケーションや IT ソリューションとのセキュリティの統合など、価値の高いセキュリティ タスクにチームの時間と注意を向けることができます。This can free up your team's time and attention for higher value security tasks like evaluating the security of Azure Services, automating security operations, and integrating security with applications and IT solutions.

対象者:Who:

  • "スポンサー": このネットワーク セキュリティ戦略の更新は、通常、セキュリティ リーダーまたは IT リーダーあるいはその両方によって後援されます。Sponsorship: This update of network security strategy is typically sponsored by security leadership and/or IT leadership
  • 実行:これらをクラウド ネットワークのセキュリティ戦略に統合することは、次のことを含む共同作業です。Execution: Integrating these into your cloud network security strategy is a collaborative effort involving
    • セキュリティ アーキテクチャ - クラウド ネットワークおよびクラウド ネットワーク セキュリティのリーダーとのクラウド ネットワーク セキュリティ アーキテクチャを確立します。Security Architecture - Establish cloud network security architecture with cloud network and cloud network security leads.
    • クラウド ネットワークのリーダー (中央 IT 運用) + クラウド ネットワーク セキュリティのリーダー (インフラストラクチャ セキュリティ チーム)Cloud network leads (Central IT Operations) + Cloud Network security leads (Infrastructure security Team)
      • セキュリティ アーキテクトによるクラウド ネットワークのセキュリティ アーキテクチャの確立Establish cloud network security architecture with security architects
      • ファイアウォール、NSG、WAF の機能を構成し、WAF ルールについてアプリケーション アーキテクトと連携するConfigure Firewall, NSG, and WAF capabilities and work with application architects on WAF rules
    • アプリケーション アーキテクト: ネットワーク セキュリティ部門と連携して、可用性を損なうことなくアプリケーションを保護するために WAF のルールセットと DDoS 構成を構築および調整するApplication architects: work with network security to build and refine WAF rulesets and DDoS configurations to protect the application without disrupting availability

方法: 運用を簡略化することを検討している組織には、2 つのオプションがあります。How: Organizations looking to simplify their operations have two options:

  • 既存の機能とアーキテクチャを拡張する: 多くの組織では、既存のファイアウォール機能の使用を拡張することを選択しています。これにより、特にクラウドを初めて導入する場合に、既存の投資を活用してスキルとプロセスを統合できます。Extend existing capabilities and architectures: Many organizations often choose to extend the use of existing firewall capabilities so they can capitalize on existing investments into skills and process integration, particularly as they first adopt the cloud.
  • ネイティブ セキュリティ制御を採用する: ますます多くの組織が、サードパーティの機能を統合する複雑さを避けるために、ネイティブ制御を使用することを希望しています。Embrace native security controls: More and more organizations are starting to prefer using native controls to avoid the complexity of integrating third-party capabilities. これらの組織は一般的に、負荷分散、ユーザー定義ルート、ファイアウォールまたは WAF 自体の構成の誤りや、さまざまな技術チーム間での受け渡しの遅延を回避することを求めています。These organizations are typically seeking to avoid the risk of a misconfiguration in load balancing, user-defined routes, the firewall/WAF itself, and delays in handoffs between different technical teams. このオプションは、コードとしてのインフラストラクチャのアプローチを採用する組織にとって特に魅力的です。組み込み機能はサードパーティの機能よりも簡単に自動化およびインストルメント化できるためです。This option is particularly compelling to organizations embracing infrastructure as code approaches as they can automate and instrument the built-in capabilities more easily than third-party capabilities.

Azure ネイティブ ネットワーク セキュリティ機能に関するドキュメントは次の場所にあります。Documentation on Azure native network security capabilities can be found at:

Azure Marketplace には、多くのサードパーティ製ファイアウォール プロバイダーが含まれています。Azure Marketplace includes many third-party firewall providers.

Azure セキュリティ ベンチマーク「NS-4: 外部ネットワーク攻撃からアプリケーションやサービスを保護する」も参照してください。Also see the Azure Security Benchmark NS-4: Protect applications and services from external network attacks.

8.テクノロジ: ネイティブ脅威検出を統合する8. Technology: Integrate native threat detection

"Azure システムとデータに対する攻撃の検出と対応を簡略化します。 "Simplify detection and response of attacks against Azure systems and data.

内容: セキュリティ運用と SIEM にネイティブの脅威検出機能を組み込むことで、脅威の検出と対応の戦略を簡略化します。What: Simplify your threat detection and response strategy by incorporating native threat detection capabilities into your security operations and SIEM.

理由: セキュリティ運用の目的は、平均応答時間 (MTTA) と修復 (MTTR) のインシデントによって測定される、環境にアクセスするアクティブな攻撃者の影響を軽減することです。Why: The purpose of security operations is to reduce the impact of active attackers who get access to the environment, as measured by mean time to acknowledge (MTTA) and remediate (MTTR) incidents. これには、インシデント対応のすべての要素の精度と速度が必要であるため、ツールの品質とプロセス実行の効率が最重要になります。This requires both accuracy and speed in all elements of incident response, so the quality of tools and the efficiency of process execution are paramount.

クラウド テクノロジの違いと高速な変化のペースにより、オンプレミスの脅威の検出向けに設計された既存のツールとアプローチを使用して脅威の検出を向上させることは困難です。It’s difficult to get high threat detections using existing tools and approaches designed for on-premises threat detection because of differences in cloud technology and its rapid pace of change. ネイティブに統合された検出は、現在の脅威とクラウド プラットフォームの変化に対応できる、クラウド プロバイダーによって維持される業界規模のソリューションを提供します。Natively integrated detections provide industrial scale solutions maintained by the cloud providers that can keep up with current threats and cloud platform changes.

これらのネイティブ ソリューションにより、セキュリティ運用チームは、不慣れなログ データからのアラートの作成、ツールの統合、メンテナンス タスクに時間を消費するのではなく、インシデントの調査と修復に専念できます。These native solutions also enable security operations teams to focus on incident investigation and remediation instead of wasting time trying to create alerts from unfamiliar log data, integrating tools, and maintenance tasks.

対象者: これは通常、セキュリティ運用チームによって主導されます。Who: This is typically driven by the Security Operations team.

  • "スポンサー" - これは通常、セキュリティ運用担当部長 (または同等のスポンサー) によって後援されます。Sponsorship - This is typically sponsored by the Security Operations Director (or equivalent)..
  • "実行" – ネイティブ脅威検出の統合は、以下を含む共同作業です。Execution – Integrating native threat detection is a collaborative effort involving those with:
    • セキュリティ運用 : アラートを SIEM とインシデント調査プロセスに統合し、クラウドのアラートとその意味、ネイティブ クラウド ツールの使用方法についてアナリストを教育します。Security Operations: integrate alerts into SIEM and incident investigation processes, educate analysts on cloud alerts and what they mean, and how to use the native cloud tools.
    • インシデントの準備 : クラウド インシデントを実習に組み込み、チームの準備を進めるための実習を確実に実施するようにします。Incident Preparation: Integrate cloud incidents into practice exercises and ensure practice exercises are conducted to drive team readiness.
    • 脅威インテリジェンス : クラウド攻撃に関する情報を調査して統合し、チームにコンテキストとインテリジェンスの情報を提供します。Threat Intelligence: Research and integrate information on cloud attacks to inform teams with context and intelligence.
    • セキュリティのアーキテクチャ : ネイティブ ツールをセキュリティ アーキテクチャのドキュメントに統合します。Security Architecture: Integrate native tooling into security architecture documentation.
    • ポリシーと標準 : 組織全体でネイティブ ツールを有効にするための標準とポリシーを設定します。Policy and standards: Set standards and policy for enabling native tooling throughout the organization. コンプライアンスについて監視します。Monitor for compliance.
    • インフラストラクチャとエンドポイント / 中央 IT 運用 :検出を構成して有効にし、コード ソリューションとしてオートメーションとインフラストラクチャに統合します。Infrastructure and Endpoint / Central IT Operations: Configure and enable detections, integrate into automation and infrastructure as code solutions.

方法: 使用するすべてのリソースに対して Azure Security Center で脅威検出を有効にし、上で説明したように、各チームにこれらをプロセスに統合してもらいます。How: Enable threat detection in Azure security center for all the resources you are using and have each team integrate these into their processes as described above.

Azure セキュリティ ベンチマーク「LT-1: Azure リソースの脅威検出を有効にする」も参照してください。Also see the Azure Security Benchmark LT-1: Enable threat detection for Azure resources.

9.アーキテクチャ:単一のディレクトリと ID で標準化する9. Architecture: Standardize on a single directory and identity

"複数の ID とディレクトリを処理したい人はいません。 "Nobody wants to deal with multiple identities and directories.

内容: Azure 内のアプリケーションとユーザーごとに 1 つの Azure AD ディレクトリと 1 つの ID で標準化します (すべてのエンタープライズ ID 機能について)。What: Standardize on a single Azure AD directory and single identity for each application and user in Azure (for all enterprise identity functions).

注意

このベスト プラクティスは、具体的にはエンタープライズ リソースに言及しています。This best practice refers specifically to enterprise resources. パートナー アカウントの場合は、Azure AD B2B を使用すると、ディレクトリ内にアカウントを作成して管理する必要がありません。For partner accounts, use Azure AD B2B so you don’t have to create and maintain accounts in your directory. お客様または市民アカウントの場合は、Azure AD B2C を使用して管理します。For customer/citizen accounts, use Azure AD B2C to manage them.

理由: 複数のアカウントと ID ディレクトリを使用すると、生産性の高いユーザー、開発者、IT および ID 管理者、セキュリティ アナリスト、およびその他のロールの日常のワークフローに不要な摩擦や混乱が生じます。Why: Multiple accounts and identity directories create unnecessary friction and confusion in daily workflows for productivity users, developers, IT and Identity Admins, security analysts, and other roles.

複数のアカウントとディレクトリを管理することによって、複数のアカウント間で同じパスワードを再利用したり、攻撃者が対象としている古いまたは破棄されたアカウントの可能性が増えたりするなど、セキュリティに関する不適切な実践の動機も生まれます。Managing multiple accounts and directories also creates an incentive for poor security practices such as reusing the same password across accounts and increases the likelihood of stale/abandoned accounts that attackers can target.

特定のアプリケーションまたはワークロードに対して (LDAP などに基づいて) カスタム ディレクトリを短時間で立ち上げる方がより簡単に見えることがありますが、これにより、設定と管理のための統合とメンテナンスの作業が大幅に増えます。While it sometimes seems easier to quickly stand up a custom directory (based on LDAP, etc.) for a particular application or workload, this creates much more integration and maintenance work to set up and manage. これは、既存のエンタープライズ テナントを使用するのではなく、追加の Azure テナントまたは追加のオンプレミスの Active Directory フォレストを設定するという決定と多くの点で似ています。This is similar in many ways to the decision of setting up an additional Azure tenant or additional on-premises Active Directory Forest vs. using the existing enterprise one. セキュリティ原則の「シンプルさを促進する」も参照してください。See also the “Drive Simplicity” security principle.

対象者: これは、多くの場合、セキュリティ アーキテクチャまたはID とキー管理の担当チームによって行われる、チーム間の作業です。Who: This is often a cross-team effort driven by Security Architecture or Identity and Key Management teams.

  • "スポンサー" - これは通常、ID とキー管理およびセキュリティ アーキテクチャ部門によって後援されます (ただし、一部の組織では、CISO または CIO による後援が必要になる場合があります)。Sponsorship - This is typically sponsored by Identity and Key management and Security Architecture (though some organizations may require sponsorship by CISO or CIO)
  • "実行" – これは次のことを含む共同作業です。Execution – This is a collaborative effort involving:
    • セキュリティのアーキテクチャ : セキュリティと IT アーキテクチャのドキュメントと図に組み込むSecurity Architecture: Incorporates into security and IT architecture documents and diagrams
    • ポリシーと標準 : ポリシーを文書化し、コンプライアンスを監視するPolicy and standards: Document policy and monitor for compliance
    • ID とキーの管理 または 中央 IT 運用 部門が、機能を有効にし、アカウントや教育などを提供して開発者をサポートすることによって、ポリシーを実装Identity and Key Management or Central IT Operations to implement the policy by enabling features and supporting developers with accounts, education, and so on.
    • アプリケーション開発者または 中央 IT 運用 部門あるいはその両方: アプリケーションと Azure サービス構成で ID を使用する (責任は DevOps 導入のレベルによって異なります)Application developers and/or Central IT Operations: Use identity in applications and Azure service configurations (responsibilities will vary based on level of DevOps adoption)

方法: 新しい "グリーンフィールド" 機能 (現在は成長中) で始める実用的なアプローチを採用し、フォローアップの演習として既存のアプリケーションやサービスの "ブラウンフィールド" の課題を解消します。How: Adopt a pragmatic approach that starts with new ‘greenfield’ capabilities (growing today) and then clean up challenges with the ‘brownfield’ of existing applications and services as a follow-up exercise:

  • グリーンフィールド: 今後すべてのエンタープライズ ID で、ユーザーごとに 1 つのアカウントを持つ単一の Azure AD ディレクトリを使用する必要があるという明確なポリシーを確立して実装します。Greenfield: Establish and implement a clear policy that all enterprise identity going forward should use a single Azure AD directory with a single account for each user.

  • ブラウンフィールド: 多くの組織では、複数のレガシ ディレクトリと ID システムを所有しています。Brownfield: Many organizations often have multiple legacy directories and identity systems. 継続的な管理の摩擦コストが、クリーンアップのための投資を超えた場合に対処します。Address these when the cost of ongoing management friction exceeds the investment to clean it up. ID 管理と同期のソリューションでは、これらの問題の一部を軽減できますが、ユーザー、管理者、および開発者にシームレスなエクスペリエンスを提供するセキュリティと生産性の機能が緊密に統合されません。While identity management and synchronization solutions can mitigate some of these issues, they lack deep integration of security and productivity features that enable a seamless experience for users, admins, and developers.

ID の使用を統合するための最適なタイミングは、アプリケーション開発サイクル中の次の場合です。The ideal time to consolidate your use of identity is during application development cycles as you:

  • クラウドのアプリケーションを最新化するModernize applications for the cloud
  • DevOps プロセスを使用してクラウド アプリケーションを更新するUpdate cloud applications with DevOps processes

非常に独立性の高い事業単位である場合や規制要件がある場合、別のディレクトリとすることに合理的な理由がありますが、他のすべての状況では複数のディレクトリを使用しないようにする必要があります。While there are valid reasons for a separate directory in the case of extremely independent business units or regulatory requirements, multiple directories should be avoided in all other circumstances.

Azure セキュリティ ベンチマーク「ID-1: Azure Active Directory を中央 ID および認証システムとして標準化する」も参照してください。Also see the Azure Security Benchmark ID-1: Standardize Azure Active Directory as the central identity and authentication system.

重要

単一アカウント規則の唯一の例外は、特権を持つユーザー (IT 管理者とセキュリティ アナリストを含む) は、標準ユーザー タスクと管理タスクのために別々のアカウントを持つ必要があるということです。The only exception to the single accounts rule is that privileged users (including IT administrators and security analysts) should have separate accounts for standard user tasks vs. administrative tasks.

詳細については、Azure セキュリティ ベンチマークの特権アクセスに関するページを参照してください。For more information, see Azure Security Benchmark Privileged Access.

10.アーキテクチャ:(キーではなく) ID ベースのアクセス制御を使用する10. Architecture: Use identity based access control (instead of keys)

内容: 可能な限り、キーベースの認証ではなく Azure AD ID を使用します (Azure のサービス、アプリケーション、API など)。What: Use Azure AD identities instead of key based authentication wherever possible (Azure Services, Applications, APIs, etc.).

理由: キーベースの認証は、クラウド サービスと API に対する認証に使用できますが、キーを安全に管理する必要があり、適切に実行する (特に大規模に) のは容易ではありません。Why: Key based authentication can be used to authenticate to cloud services and APIs but requires managing keys securely, which is challenging to perform well (especially at scale). セキュリティで保護されたキー管理は、セキュリティの専門家でないで開発者やインフラストラクチャ担当者には困難であり、安全に実行できないことが多く、組織に大きなセキュリティ リスクが生じます。Secure key management is difficult for non-security processionals like developers and infrastructure professionals and they often fail to do it securely, often creating major security risks for the organization.

ID ベースの認証は、秘密のローテーション、ライフサイクル管理、管理委任などの成熟した機能によって、これらの課題の多くを克服します。Identity based authentication overcomes many of these challenges with mature capabilities for secret rotation, lifecycle management, administrative delegation, and more.

対象者: これは、多くの場合、セキュリティ アーキテクチャまたはID とキー管理の担当チームによって行われる、チーム間の作業です。Who: This is often a cross-team effort driven by Security Architecture or Identity and Key management teams.

方法: ID ベースの認証を使用するための組織の基本設定と習慣を設定するには、プロセスに従ってテクノロジを有効にする必要があります。How: Setting an organizational preference and habit for using identity-based authentication requires following a process and enabling technology.

このプロセスの内容は次のとおりです。The process:

  1. 既定の ID ベースの認証および許容される例外を明確に示すポリシーと標準を確立します。Establish policy and standards that clearly outline the default identity-based authentication, as well as acceptable exceptions.
  2. 新しいアプローチを使用する理由、実行する必要があること、およびその方法について、開発者とインフラストラクチャ担当チームを教育します。Educate developers & infrastructure teams on why to use the new approach, what they need to do, and how to do it.
  3. 変更を実用的な方法で実装します。現在および将来採用される新しい "グリーンフィールド" 機能 (新しい Azure サービス、新しいアプリケーション) から始めて、既存の "ブラウンフィールド" 構成のクリーンアップを行います。Implement changes in a pragmatic way – starting with new ‘greenfield’ capabilities being adopted now and in the future (new Azure services, new applications) and then following up with a clean-up of existing ‘brownfield’ configurations.
  4. コンプライアンスを監視し、開発者およびインフラストラクチャ チームと共にフォローアップします。Monitor for compliance and follow up with developer and infrastructure teams to remediate.

テクノロジ: サービスやオートメーションなどの人間以外のアカウントには、マネージド ID を使用します。The technologies: For non-human accounts such as services or automation, use Managed identities. Azure マネージド ID によって、Azure AD 認証をサポートする Azure のサービスとリソースに対して認証を行うことができます。Azure managed identities can authenticate to Azure services and resources that support Azure AD authentication. 認証は事前に定義されたアクセス許可規則によって有効になり、ソース コードまたは構成ファイル内でハードコーディングされた資格情報を使用せずに済みます。Authentication is enabled through pre-defined access grant rules, avoiding hard-coded credentials in source code or configuration files.

マネージド ID をサポートしていないサービスに対しては、Azure AD を使用して、リソース レベルでアクセス許可が制限されたサービス プリンシパルを代わりに作成します。For services that do not support managed identities, use Azure AD to create a Service principals with restricted permissions at the resource level instead. 証明書の資格情報を使用してサービス プリンシパルを構成し、クライアント シークレットにフォールバックすることをお勧めしました。We recommended configuring service principals with certificate credentials and fall back to client secrets. どちらの場合も、Azure Key Vault を Azure マネージド ID と組み合わせて使用し、ランタイム環境 (Azure 関数など) でキー コンテナーから資格情報を取得できるようにすることができます。In both cases, Azure Key Vault can be used in conjunction with Azure managed identities, so that the runtime environment (such as an Azure function) can retrieve the credential from the key vault.

Azure セキュリティ ベンチマーク「ID-2: アプリケーション ID を安全かつ自動的に管理する」も参照してください。Also see the Azure Security Benchmark ID-2: Manage application identities securely and automatically.

11.アーキテクチャ:単一の統合セキュリティ戦略を確立する11. Architecture: Establish a single unified security strategy

"ボートが前進するには、全員が同じ方向に漕ぐ必要があります。 "Everyone needs to row in the same direction for the boat to go forward.

内容: すべてのチームが、エンタープライズ システムとデータを有効にし、セキュリティで保護する単一の戦略に整合しているようにします。What: Ensure all teams are aligned to a single strategy that both enables and secures enterprise systems and data.

理由: 複数のチームが共通の戦略に整合せず、ばらばらに作業した場合、各自のアクションが意図せず相互に悪影響を与え、不要な摩擦が生じて、すべてのユーザーの目標達成速度が低下する可能性があります。Why: When teams work in isolation without being aligned to a common strategy, their individual actions can inadvertently undermine each other’s efforts, creating unnecessary friction that slows down progress against everyone's goals.

多くの組織でこれが一貫して実施されている例の 1 つは、資産のセグメント化です。One example of this that has played out consistently in many organizations is the segmentation of assets:

  • "ネットワーク セキュリティ チーム" は、"フラット ネットワーク" をセグメント化してセキュリティを強化する戦略を (多くの場合、物理サイト、割り当てられた IP アドレスや範囲などに基づいて) 策定します。The network security team develops a strategy for segmenting a ‘flat network’ to increase security (often based on physical sites, assigned IP address addresses/ranges, or similar)
  • それとは別に "ID チーム" は、組織についての理解と知識に基づいて、グループおよび Active Directory 組織単位 (OU) に関する戦略を策定しました。Separately, the identity team developed a strategy for groups and Active Directory Organizational Units (OUs) based on their understanding and knowledge of the organization.
  • "アプリケーション チーム" は、これらのシステムは使用するのが難しいと感じていることがよくあります。ビジネスの運用、目標、リスクについてのインプットと理解が制限された状態で設計されているためです。Application teams often find it difficult to work with these systems because they were designed with limited input and understanding of business operations, goals, and risks.

このような状況が発生した組織では、チームに頻繁にファイアウォールの例外についての競合が発生し、それによる悪影響がセキュリティ (例外は通常承認される) と生産性 (ビジネスに必要なアプリケーション機能のデプロイが遅くなる) の両方に生じます。In organizations where this happens, teams frequently experience conflicts over firewall exceptions, which negatively impact both security (exceptions are usually approved) and productivity (deployment is slowed for application functionality the business needs).

セキュリティで批判的思考を強制することで健全な摩擦を発生させることができますが、この競合で発生するのは、目標を妨げる異常な摩擦だけです。While security can create healthy friction by forcing critical thinking, this conflict only creates unhealthy friction that impedes goals. 詳細については、セキュリティ戦略ガイダンスに関するページにある「適切なレベルのセキュリティ上の摩擦」を参照してください。For more information, see The right level of security friction in the security strategy guidance.

対象者:Who:

  • "スポンサー" - 統合戦略は通常、CIO、CISO、CTO (多くの場合、一部の高レベルの要素に対するビジネス リーダーのサポートを伴う) によって共同で後援され、各チームの代表者によって支持されます。Sponsorship - The unified strategy typically co-sponsored by CIO, CISO, and CTO (often with business leadership support for some high-level elements) and championed by representatives from each team.
  • "実行" – セキュリティ戦略は全員が実装する必要があるため、チーム全体からのインプットを統合して、所有権、賛同、成功の可能性を高める必要があります。Execution – Security strategy must be implemented by everyone, so it should integrate input from across teams to increase ownership, buy-in, and likelihood of success.
    • セキュリティのアーキテクチャ : セキュリティ戦略と結果のアーキテクチャを構築し、チームからのフィードバックを積極的に収集して、さまざまなユーザーのためにプレゼンテーション、ドキュメント、図で文書化します。Security Architecture: Leads the effort to build security strategy and resulting architecture, actively gather feedback from teams, and document it in presentations, documents, and diagrams for the various audiences.
    • ポリシーと標準 : 適切な要素を標準およびポリシーに取り入れ、コンプライアンスを監視します。Policy and standards: Captures the appropriate elements into standards and policy and then monitors for compliance.
    • すべてのテクニカル IT 担当およびセキュリティ担当チーム: インプットの要件を指定し、エンタープライズ戦略に整合するように実装します。All Technical IT and security teams: Provide input requirements, then align to and implement the enterprise strategy.
    • アプリケーションの所有者と開発者: 適用される戦略に関するドキュメント (理想的には、各自のロールに合わせて調整したガイダンス) を読み、理解します。Application owners and developers: Read and understand strategy documentation that applies to them (ideally, guidance tailored to their role).

方法:How:

すべてのチームからのインプットと積極的な参加を含むクラウドのセキュリティ戦略を構築し、実装します。Build and implement a security strategy for cloud that includes the input and active participation of all teams. プロセス ドキュメントの形式はさまざまですが、常に次のものが含まれる必要があります。While the process documentation format will vary, this should always include:

  • チームからの積極的なインプット: 通常、組織内のユーザーが賛成しない戦略は失敗します。Active input from teams: Strategies typically fail if people in the organization don’t buy into them. 理想的には、すべてのチームを同じ部屋に集めて、戦略を共同で構築します。Ideally, get all teams in the same room to collaboratively build the strategy. 私たちがお客様と一緒に実施しているワークショップでは、多くの場合、組織が事実上縦割りで運用されていることが判明し、それらの会議で互いに初めて顔を合わせることがよくあります。In the workshops we conduct with customers, we often find organizations have been operating in de facto silos and these meetings often result in people meeting each other for the first time. また、包括性が必要とされることもわかりました。一部のチームが招待されていない場合は、通常、すべての参加者が参加するまで (またはプロジェクトが先に進むまで)、この会議を繰り返す必要があります。We also find that inclusiveness is a requirement - if some teams are not invited, this meeting typically has to be repeated until all participants join it (or the project doesn’t move forward).
  • 文書化されていて明確に伝わる: すべてのチームは、セキュリティを統合する理由、セキュリティで重要なこと、セキュリティの成功がどのように見えるかなど、セキュリティ戦略 (理想的にはテクノロジ戦略全体のセキュリティ コンポーネント) を認識している必要があります。Documented and communicated clearly: All teams should have awareness of the security strategy (ideally a security component of the overall technology strategy) including why to integrate security, what is important in security, and what security success looks like. これには、アプリケーション チームと開発チームに固有のガイダンスが含まれている必要があります。そうすることで、ガイダンスの関連性のない部分を読む必要がない、明確な優先順位が示されたガイダンスを手に入れることができます。This should include specific guidance for application and development teams so they can get a clear prioritized guidance without having to read through non-relevant parts of the guidance.
  • 安定していながら柔軟である: 戦略は比較的一貫した安定した状態に保つ必要がありますが、アーキテクチャとドキュメントは、明確にするため、また、クラウドの動的な特性に対応するために、変更が必要になる場合があります。Stable, but flexible: Strategies should remain relatively consistent and stable, but the architectures and the documentation may need changes to add clarity and accommodate the dynamic nature of cloud. たとえば、使用しているサードパーティの次世代ファイアウォールから Azure ファイアウォールに移行した場合でも、悪意のある外部トラフィックをフィルターで除外し、その方法についての図やガイダンスを調整することは、戦略的に一貫して不可欠です。For example, filtering out malicious external traffic would stay consistent as a strategic imperative even if you shift from the use of a third-party next generation firewall to Azure firewall and adjust diagrams/guidance on how to do it.
  • セグメンテーションから開始する: クラウド導入の過程で、チームは大小さまざまな戦略トピックに取り組みますが、どこかから始める必要があります。Start with segmentation: Over the course of cloud adoption, your teams will address many strategy topics large and small, but you need to start somewhere. セキュリティ戦略は、後で変更するのが難しく、ビジネスのインプットと多数の技術チームの両方を必要とする基本的な決定であるため、エンタープライズ資産のセグメンテーションから開始することをお勧めします。We recommend starting the security strategy with enterprise asset segmentation as it’s a foundational decision that would be challenging to change later and requires both business input and many technical teams.

Microsoft では、このビデオと、エンタープライズ セグメンテーションそれに対するネットワーク セキュリティの整合に関するドキュメントで、Azure へのセグメンテーション戦略の適用についてのガイダンスを公開しています。Microsoft has published guidance on applying a segmentation strategy to Azure in this video and documents on enterprise segmentation and aligning network security to it.

クラウド導入フレームワークには、次のことを行うチームを支援するためのガイダンスが含まれています。The cloud adoption framework includes guidance to help your teams with:

Azure セキュリティ ベンチマークのガバナンスと戦略に関するページも参照してください。Also see the Azure Security Benchmark Governance and Strategy.