アプリケーションとサービスApplications and services

アプリケーションとそれらに関連付けられたデータは、クラウド プラットフォーム上で、最終的にはビジネス価値の主要なストアとして機能します。Applications and the data associated with them ultimately act as the primary store of business value on a cloud platform. ID やストレージなどのプラットフォーム コンポーネントはセキュリティ環境の重要な要素ですが、アプリケーションは、以下の理由で、ビジネスに対するリスクの点で並外れて大きな役割を果たします。While the platform components like identity and storage are critical elements of the security environment, applications play an outsize role in risks to the business because:

  • ビジネス プロセスはアプリケーションによってカプセル化され、実行されます。また、サービスは使用可能で、高い整合性と共に提供される必要がありますBusiness Processes are encapsulated and executed by applications and services need to be available and provided with high integrity

  • ビジネス データはアプリケーションのワークロードによって格納と処理が行われ、機密性、整合性、可用性について高いレベルの保証を必要とします。Business Data is stored and processed by application workloads and requires high assurances of confidentiality, integrity, and availability.

このセクションでは、組織または組織の代理で他社によって作成されたアプリケーションと、IaaS VM にインストールされた SaaS または市販のアプリケーションに注目します。This section focuses on applications written by your organization or by others on behalf of your organization vs. SaaS or commercially available applications installed on IaaS VMs.

アプリケーション モデルの図

Azure のような最新のクラウド プラットフォームでは、従来のアプリケーションと最新世代のアプリケーションの両方をホストできますModern cloud platforms like Azure can host both legacy and modern generations of applications

  • レガシ アプリケーションは、サービスとしてのインフラストラクチャ (IaaS) 仮想マシンでホストされ、通常は OS、ミドルウェア、その他のコンポーネントなどの依存関係がすべて含まれています。Legacy applications are hosted on Infrastructure as a Service (IaaS) virtual machines that typically include all dependencies including OS, middleware, and other components.

  • 最新のサービスとしてのプラットフォーム (PaaS) アプリケーションでは、アプリケーションの所有者が、基になっているサーバー オペレーティング システム (OS) を管理し、セキュリティで保護する必要はありません。これらのアプリケーションは場合によっては完全に "サーバーレス" であり、主にサービスとしての機能を使用して構築されています。Modern Platform as a Service (PaaS) applications don’t require the application owner to manage and secure the underlying server operating systems (OSes) and are sometimes fully “Serverless” and built primarily using functions as a service.

    注: 最新アプリケーションの人気のある形式は、Azure App Services でホストされるアプリケーション コードと、コンテナー化されたアプリケーションです (ただしコンテナーは IaaS VM またはオンプレミスでホストすることも可能です)。Notes: Popular forms of modern applications are application code hosted on Azure App Services and containerized applications (though containers can also be hosted on IaaS VMs or on-premises as well).

  • ハイブリッド – ハイブリッド アプリケーションの形態は多数考えられますが、最も一般的なのは、レガシ コンポーネントを置き換えたり、レガシ アプリケーションに追加されたりする最新のサービスを備えた最新アーキテクチャに、レガシ アプリケーションが移行しようとしている、"IaaS プラス" の状態です。Hybrid – While hybrid applications can take many forms, the most common is an “IaaS plus” state where legacy applications are transitioning to a modern architecture with modern services replacing legacy components or being added a legacy application.

アプリケーションをセキュリティで保護するには、3 種類の異なるコンポーネントに対するセキュリティ保証が必要です。Securing an application requires security assurances for three different component types:

  • アプリケーション コード – これは、作成するカスタム アプリケーションを定義するロジックです。Application Code – This is the logic that defines the custom application that you write. このコードのセキュリティについては、オープンソースの任意のスニペットやコードに含まれるコンポーネントを含め、アプリケーション アーキテクチャのすべて世代において、アプリケーションの所有者が責任を負います。The security of this code is the application owners’ responsibility in all generations of application architecture including any open-source snippets or components included in the code. コードをセキュリティで保護するには、アプリケーションの設計と実装に含まれるリスクを特定して軽減し、含まれるコンポーネントのサプライ チェーン リスクも評価する必要があります。Securing the code requires identifying and mitigating risks from the design and implementation of the application as well as assessing supply chain risk of included components. アプリケーションをマイクロサービス アーキテクチャに進化させること、アプリケーション コードのさまざまな側面が、単一のモノリシック コードベースと比較してより小さなサービスに分割されることに注意してください。Note that the evolution of applications into microservices architectures will break various aspects of application code into smaller services vs. a single monolithic codebase.

  • アプリケーション サービス – これらは、データベース、ID プロバイダー、イベント ハブ、IoT デバイス管理などのアプリケーションが使用する、標準化されたさまざまなコンポーネントです。Application Services – These are the various standardized components that the application uses such as databases, identity providers, event hubs, IoT device management, and so on. クラウド サービスの場合、これは以下によって共有される責任です。For cloud services this is a shared responsibility:

    • クラウド プロバイダー – 基盤となるサービスのセキュリティは、クラウド プロバイダーの責任ですCloud Provider - The security of the underlying service is the responsibility of the cloud provider

    • アプリケーション所有者 – サービスで格納され、処理されるすべてのデータを含めて、アプリケーションによって使用されるサービス インスタンスの構成と運用のセキュリティへの影響については、アプリケーション所有者が責任を負います。Application Owner - The application owner is responsible for security implications of the configuration and operation of the service instance(s) used by the application including any data stored and processed on the service.

  • アプリケーション ホスティング プラットフォーム – これは、アプリケーションが実際に実行されて動作するコンピューティング環境です。Application Hosting Platform – This is the computing environment where the application actually executes and runs. オンプレミス、Azure、アマゾン ウェブ サービス (AWS) のようなサードパーティのクラウドでホストされているアプリケーションを利用している企業の場合、この形態は多数考えられますが、だれがセキュリティに責任を負うかに関してはかなりの数のバリエーションがあります。In an enterprise with applications hosted on premises, in Azure and in third-party clouds like Amazon Web Services (AWS), this could take many forms with significant variations on who is responsible for security:

    • レガシ アプリケーションには、通常、物理ハードウェアまたは仮想化されたハードウェアでホストされた完全なオペレーティング システム (とすべてのミドルウェア) が必要です。Legacy Applications typically require a full operating system (and any middleware) hosted on physical or virtualized hardware. 仮想ハードウェアは、オンプレミスでホストすることも、サービスとしてのインフラストラクチャ (IaaS) VM でホストすることもできます。The virtual hardware can be hosted on premises or on Infrastructure as a Service (IaaS) VMs. このオペレーティング システムとインストールされているミドルウェア/その他のコンポーネントは、アプリケーション所有者またはそのインフラストラクチャ チームによって運用され、セキュリティで保護されます。This operating system and installed middleware/other components are operated and secured by the application owner or their infrastructure team(s).
      物理ハードウェアと OS 仮想化コンポーネント (仮想化ホスト、オペレーティング システム、および管理サービス) の責任は以下のように変化があります。The responsibility for the physical hardware and OS virtualization components (virtualization hosts, operating systems, and management services) varies:

      • オンプレミス - アプリケーション所有者またはその組織がメンテナンスとセキュリティを担当します。On premises - The application owner or their organization is responsible for maintenance and security.

      • IaaS – クラウド プロバイダーが、基盤となるインフラストラクチャのメンテナンスとセキュリティを担当し、アプリケーション所有者の組織が、VM の構成、オペレーティング システム、およびそこにインストールされるすべてのコンポーネントを担当します。IaaS – The cloud provider is responsible for maintenance and security of the underlying infrastructure and the application owner’s organization is responsible for the VM configuration, operating system, and any components installed on it.

    • 最新のアプリケーションは、Azure のアプリケーション サービスのようなサービスとしてのプラットフォーム (PaaS) 環境でホストされます。Modern Applications are hosted on Platform as a Service (PaaS) environments such as an Azure application service. ほとんどの種類のアプリケーション サービスでは、基になるオペレーティング システムはアプリケーションの所有者からは抽象化されて、クラウド プロバイダーによってセキュリティで保護されます。In most application service types, the underlying operating system is abstracted from the application owner and secured by the cloud provider. アプリケーション所有者は、提供されているアプリケーション サービス構成のセキュリティを担当します。Application owners are responsible for the security of the application service configurations that are provided to them.

    • コンテナーは、アプリケーションのパッケージ化メカニズムで、その中でアプリケーションが、実行される環境から抽象化されます。Containers are an application packaging mechanism in which applications are abstracted from the environment in which they run. これらのコンテナー化されたアプリケーションは、クラウド プロバイダーによってコンテナー サービスで実行される (最新のアプリケーション) か、組織が管理する (オンプレミスまたは IaaS 内の) サーバーで実行されるかによって、上記のレガシ モデルまたは最新のモデルのいずれかに適合します。These containerized applications fit into either the legacy or modern models above depending on whether they are run on a container service by the cloud provider (Modern Applications) or on a server managed by the organization (on premises or in IaaS). 詳細については、後述のコンテナーのセキュリティに関するセクションを参照してください。See the container security section below for more details.

ビジネス クリティカルなアプリケーションを特定して分類するIdentify and classify business critical applications

ビジネス機能に不可欠なポートフォリオ内のアプリケーションを特定し、それらが分類済みであるようにします。Ensure you have identified and classified the applications in your portfolio that are critical to business functions.

企業組織は通常、大規模なアプリケーション ポートフォリオを所有しているため、脅威モデリングなどの手動かつリソースを大量に消費するタスクのどこに時間と労力を投じるか優先順位を付けることで、セキュリティ プログラムの有効性を高めることができます。Enterprise organizations typically have a large application portfolio, so prioritizing where to invest time and effort into manual and resource-intensive tasks like threat modeling can increase the effectiveness of your security program.

潜在的な影響が大きいアプリケーションや、リスクにさらされる可能性の高いアプリケーションを特定します。Identify applications that have a high potential impact and/or a high potential exposure to risk.

  • 潜在的な影響が大きい – 侵害された場合にビジネスに大きな影響を与えるアプリケーションを特定します。High potential impact – Identify application that would a significant impact on the business if compromised. これは、以下のうち 1 つまたは複数の形態をとることがあります。This could take the form of one or more of:

    • ビジネスに不可欠なデータ – 情報を処理または格納するアプリケーション。これは、機密性、整合性、または可用性の保証が失われた場合は企業または使命に重大な悪影響を及ぼす可能性があります。Business critical data – Applications that process or store information, which would cause significant negative business or mission impact if an assurance of confidentiality, integrity, or availability is lost.

    • 規制対象のデータ – 標準によって規制されている、貨幣調節手段や機密の個人情報を扱うアプリケーション。Regulated data – Applications that handle monetary instruments and sensitive personal information regulated by standards. たとえば、Payment Card Industry (PCI) や Health Information Portability and Accountability Act (HIPAA) です。For example, payment card industry (PCI) and Health Information Portability and Accountability Act (HIPAA).

    • ビジネスに不可欠な可用性 – 組織のビジネス ミッションに不可欠な機能を持つアプリケーション。収益、デバイス、生活や安全性に不可欠なサービス、その他の不可欠な機能を生み出す生産ラインなどです。Business critical availability – Applications whose functionality is critical to organizations business mission such as production lines generating revenue, devices, or services critical to life and safety, and other critical functions.

    • 重要なアクセス – 以下のような技術的手段を通して大きな影響を与える可能性のあるシステムにアクセスできるアプリケーションSignificant Access – Applications which have access to systems with a high potential impact through technical means such as

      • データ/サービスへのアクセスを付与する、格納されている資格情報またはキー/証明書Stored Credentials or keys/certificates that grant access to the data/service

      • アクセス制御リストまたはその他の手段によって付与されたアクセス許可Permissions granted via access control lists or other means

  • 攻撃に対する露出度が高い – オープンなインターネット上の Web アプリケーションのように攻撃者が容易にアクセスできるアプリケーション。High exposure to attacks – Applications that are easily accessible to attackers such as web applications on the open internet. 攻撃者や侵入テスト担当者は、レガシ アプリケーションには修正するのが難しい脆弱性があることが多いと知っているためにそれらを頻繁に標的にしており、レガシ アプリケーションの露出度もより高い可能性があります。Legacy applications can also be higher exposure as attackers and penetration testers frequently target them because they know these legacy applications often have vulnerabilities that are difficult to fix.

DevOps アプローチを採用するAdopt the DevOps approach

組織は、実際的である限りできるだけ迅速に、"ウォーターフォール型" の開発サイクルから、アプリケーションの継続的インテグレーション/継続的デリバリー (CI/CD) の DevOps ライフサイクルに移行する必要があります。Organizations should shift from a ‘Waterfall’ development cycle to DevOps lifecycle of continuous integration, continuous delivery (CI/CD) for applications as fast as is practical. DevOps とは、エンド ユーザーに対する価値の継続的デリバリーを可能にする人員、プロセス、ツールの集まりです。DevOps is the union of people, processes, and tools that enable continuous delivery of value to end users. Dev と Ops の短縮形であるこの用語は、開発分野と運用分野を、共有される効率的な実施方法とツールを使用して共同作業する多部門チームにまとめることを意味します。The contraction of Dev and Ops refers to combining the development and operations disciplines into multi-disciplinary teams that work together with shared and efficient practices and tools.

DevOps モデルは、ウォーターフォール モデルのより長期にわたる計画およびテストのサイクルを待つことなく、セキュリティの懸念に迅速に対処する組織の能力を向上させます。The DevOps model increases the organization’s ability to rapidly address security concerns without waiting for a longer planning and testing cycle of a waterfall model.

DevOps のセキュリティ ガイダンスに従うFollow DevOps security guidance

組織は、ゼロから開始するのではなく、クラウドのアプリケーションをセキュリティで保護するためのガイダンスと自動化を活用する必要があります。Organizations should leverage guidance and automation for securing applications on the cloud rather than starting from zero.

これらのモデルを早期に採用している外部の組織が学んだリソースや課題を利用することで、費やす労力とリソースをより少なくしながら、組織のセキュリティ体制の強化をスピードアップすることができます。Using resources and lessons learned by external organizations that are early adopters of these models can accelerate the improvement of an organization’s security posture with less expenditure of effort and resources.

  • Microsoft は、Azure でのセキュリティで保護された DevOps に向けたツールキットをリリースしてきましたMicrosoft has released a toolkit for Secure DevOps on Azure –
    https://azsk.azurewebsites.net/

  • Organization for Web App Security Project (OWASP) は、DevOps パイプライン セキュリティのガイダンスを公開してきましたOrganization for Web App Security Project (OWASP) has published guidance DevOps Pipeline security
    https://www.owasp.org/index.php/OWASP_AppSec_Pipeline#tab=Main

カスタム実装の代わりにクラウド サービスを使用するUse Cloud services instead of custom implementations

開発者は、データベース、暗号化、ID ディレクトリ、認証などの十分に確立された機能については、それらのカスタム バージョンを作成する代わりに、クラウド プロバイダーから提供されるサービスを使用する必要があります。Developers should use services available from your cloud provider for well-established functions like databases, encryption, identity directory, and authentication instead of writing custom versions of them.

クラウド プロバイダーは、これらの分野で深い専門知識を持つ専任チームによって運用とセキュリティ保護を行っているため、これらのサービスでは、より優れたセキュリティ、信頼性、効率性が提供されます。These services provide better security, reliability, and efficiency because cloud providers operate and secure them with dedicated teams with deep expertise in those areas. これらのサービスを使用することで、開発者が開発時間をビジネス固有の要件に集中できるように、開発者リソースを、有名な "車輪の再発明" から解放することもできます。Using these services also frees your developer resources from reinventing the proverbial wheel so that they can focus development time on your unique requirements for your business. 新しいアプリケーションの開発時にリスクを回避し、既存アプリケーションのリスクや、計画された更新サイクル中、またはセキュリティに重点を置いたアプリケーション更新の際のリスクを軽減するため、この実施方法に従う必要があります。This practice should be followed to avoid risk during new application development as well as to reduce risk in existing applications either during planned update cycle or with a security-focused application update.

いくつかの機能は、セキュリティに影響する可能性があるため、まず優先順位を付ける必要があります。Several capabilities that should be prioritized first because of potential security impact:

  • ID – ユーザー ディレクトリとその他の認証機能は、開発するのが複雑で、セキュリティ保証にとっては非常に重要です。Identity – User directories and other authentication functions are complex to develop and critically important to security assurances. 自社開発の認証ソリューションの使用は避けて、Azure Active Directory (Azure AD)、Azure AD B2BAzure AD B2C、サードパーティ ソリューションのような成熟した機能を優先的に利用し、ユーザー、パートナー、顧客、アプリケーション、サービス、およびその他のエンティティに対する認証とアクセス許可の付与を行います。Avoid using homegrown authentication solutions and favor mature capabilities like Azure Active Directory (Azure AD), Azure AD B2B, Azure AD B2C, or third-party solutions to authenticate and grant permission to users, partners, customers, applications, services, and other entities.

  • データ保護 – 開発者は、クラウド サービスのネイティブ暗号化など、クラウド プロバイダーから提供される確立された機能を使用して、データの暗号化と保護を行う必要があります。Data Protection – Developers should use established capabilities from cloud providers such as native encryption in cloud services to encrypt and protect data. セキュリティ業界では、実世界の攻撃に耐えられなかった、データやパスワードを保護する試みの失敗例が多数見られます。The security world is littered with examples of failed attempts to protect data or passwords that didn’t stand up to real world attacks. 暗号化を直接使用する必要がある場合、開発者は十分に確立された暗号アルゴリズムを呼び出す必要があり、独自のものを作り出そうとしないでください。If direct use of cryptography is required, developers should call well-established cryptographic algorithms and not attempt to invent their own.

  • キー管理 – 認証のためには、キーを直接処理するのではなく ID を使用するのが理想的です (「キーよりも ID 認証を選ぶ」を参照してください)。Key management – Ideally use identity for authentication rather than directly handling keys (see Prefer Identity Authentication over Keys). キーにアクセスする必要があるサービスにアクセスする場合は、アプリケーション コード内で安全にキーを処理しようとせずに、Azure Key Vault または AWS のキー管理サービスなどのキー管理サービスを活用して、これらのキーを管理し、セキュリティで保護します。For situations where accessing services that require access to keys, leverage a key management service like Azure Key Vault or AWS Key Management Service to manage and secure these keys rather than attempting to safely handle keys in application code. Credscan を使用して、アプリケーション コード内で公開されている可能性のあるキーを検出できます。You can use CredScan to discover potentially exposed keys in your application code.

  • アプリケーションの構成 – アプリケーションの構成に一貫性がないと、セキュリティ リスクが生じる可能性があります。Application Configurations – Inconsistent configurations for applications can create security Risks. Azure App Configuration は、アプリケーション設定と機能フラグを一元的に管理するためのサービスを提供します。それが、このリスクを軽減する助けとなります。Azure App Configuration provides a service to centrally manage application settings and feature flags, which helps mitigate this risk.

アプリケーション サービスのネイティブのセキュリティ機能を使用するUse Native Security capabilities in application services

(データ暗号化、ネットワーク トラフィックのフィルター処理、脅威の検出などの機能のために) 外部のセキュリティ コンポーネントを追加するのではなく、クラウドサービスに組み込まれているネイティブのセキュリティ機能を使用します。Use native security capabilities built into cloud services instead of adding external security components (for data encryption, network traffic filtering, threat detection, and other functions).

ネイティブのセキュリティ制御はサービス プロバイダーによってメンテナンスとサポートが行われるので、外部のセキュリティ ツールを統合し、長期にわたってそれらの統合を更新するために必要な労力は、解消されるか低減されます。Native security controls are maintained and supported by the service provider, eliminating or reducing effort required to integrate external security tooling and update those integrations over time. クラウド サービスは急速に進化しています。それにより、外部ツールを維持する負担が大幅に増加しており、ツールがクラウド サービスに遅れずについていけない場合に、それらのツールからセキュリティの可視性と保護が失われるリスクが高まっています。Cloud services evolve rapidly, which greatly increases the burden of maintaining an external tool and increases risk of losing security visibility and protections from these tools if the tool doesn’t keep up with the cloud service.

キーよりも ID 認証を選ぶPrefer Identity Authentication over Keys

使用できる場合は常に、暗号化キーではなく ID サービスで認証します。Always authenticate with identity services rather than cryptographic keys when available.

アプリケーション コードでキーを安全に管理することは困難であり、普通は、機密のアクセス キーを GitHub のようなコード リポジトリに誤って公開するなどのミスにつながります。Managing keys securely with application code is difficult and regularly leads to mistakes like accidentally publishing sensitive access keys to code repositories like GitHub. ID システムは、キー ローテーションや異常の監視などの高度な組み込みメカニズムを使用して、アクセス制御のための安全で使いやすいエクスペリエンスを提供します。Identity systems offer secure and usable experience for access control with built-in sophisticated mechanisms for key rotation, monitoring for anomalies, and more. ほとんどの組織には、ID システムの管理に特化したスキルを持つチームもいて、主要なセキュリティ システムを積極的に管理しているユーザーは (いるとしても) ほとんどいません。Most organizations also have skilled teams dedicated to managing identity systems and few (if any) people actively managing key security systems.

Azure StorageAzure App ServiceAzure Backup などの Azure AD 認証を提供するサービスについては、これを認証と承認のために使用します。For services that offer the Azure AD authentication like Azure Storage, Azure App Service, Azure Backup, use it for authentication and authorization. 開発者の ID の使用をさらに簡素化するため、マネージド ID を利用して、VM や App Services などのリソースに ID を割り当てることもできます。そのようにすると、開発者はアプリケーション内で ID を管理する必要がありません。To further simplify using identities for developers, you can also take advantage of managed identities to assign identities to resources like VMs and App Services so that developers don’t have to manage identities within the application.

セキュリティ バグの量と影響を軽減するためのボトムアップ アプローチBottom-up approach to reduce security bug volume and impact

セキュリティバグのボリュームと影響を軽減するためのボトムアップアプローチを示すイメージ

開発ライフサイクル中にセキュリティ プラクティスとツールを実装することによって、アプリケーション内のセキュリティ バグの数と潜在的な重要度を低減します。Reduce the count and potential severity of security bugs in your application by implementing security practices and tools during the development lifecycle.

セキュリティ バグは、アプリケーションが機密データを開示したり、犯罪者がデータやレコードを改変できるようになったり、データやアプリケーションが顧客や従業員から使用できなくなったりする結果を招く可能性があります。Security bugs can result in an application disclosing confidential data, allowing criminals to alter data/records, or the data/application becoming unavailable for use by customers and employees. アプリケーションは常に、セキュリティ リスクをもたらす可能性のある何らかのロジック エラーを持っているため、組織の評判、収益、利益に対する損失を回避するため、それらを検出、評価、修正することが重要です。Applications will always have some logic errors that can result in security risk, so it is important to discover, evaluate, and correct them to avoid damage to the organization’s reputation, revenue, or margins. アプリケーションのテスト完了後、運用環境での使用中、または侵害発生後に修正するよりも、"シフト レフト" の原則や "プッシュ レフト" の原則と呼ばれることが多い、開発ライフサイクルの早期にこれらを解決するやり方が、容易かつ低コストです。It is easier and cheaper to resolve these earlier in the development lifecycle than it is to correct them after application has completed testing, is in production use, or has been breached frequently called “shift left” or “push left” principle.

アプリケーション リスクの軽減は、セキュリティ プラクティスとツールを開発ライフサイクルに統合することによって実現されます。これは多くの場合、セキュリティ開発ライフサイクル (SDL または SDLC) と呼ばれます。Mitigating application risk is achieved by integrating security practices and tools into the development lifecycle, often called a secure development lifecycle (SDL or SDLC). Microsoft は、入力と出力の検証によって一般的なリスクを軽減し、ファジー テストや攻撃対象領域レビューなどを実行するため、Microsoft のセキュリティ開発ライフサイクルに基づいて、「Develop Secure Apps on Azure (セキュリティで保護されたアプリを Azure で開発する)」というタイトルのホワイトペーパーで多数の推奨事項を公開してきました。Microsoft has published a number of recommendations in a whitepaper entitled Develop Secure Apps on Azure based on Microsoft’s Security Development Lifecycle to mitigate common risks with input and output validation, perform fuzz testing, attack surface reviews, and more.

脅威モデリングを通したトップダウン アプローチTop-down approach through threat modeling

脅威のモデル化によるトップダウンアプローチを示す画像

ビジネスに不可欠なアプリケーションに対して脅威モデリングを実行して、組織に対する潜在的なリスクを検出し、軽減します。Perform threat modeling on your business-critical applications to discover and mitigate potential risks to your organization.

脅威モデリングでは、アプリケーション自体に対するリスクに加え、大規模なシステム内の個々のアプリケーションを評価する場合は特に、アプリケーションが企業にもたらす可能性のあるリスクを特定します。Threat modeling identifies risks to the application itself as well as risks that application may pose to your enterprise particularly when evaluating individual applications in a larger system.

脅威モデリングは、アプリケーションの開発または運用のどの段階でも使用できますが、そのアプリケーション用の現実世界のデータはまだ存在しないため、新機能の設計段階で比類なく有効です。Threat modeling can be used at any stage of application development or production, but it is uniquely effective for the design stages of new functionality because no real-world data yet exists for that application.

脅威モデリングはスキル集約型の課題であるため、セキュリティ上の価値を最大限確保するのと同時に、時間的な投資を最小限にする対策を取ることをお勧めします。Because threat modeling is a skill intensive exercise, we recommend taking measures to minimize time investment while maximizing security value:

  1. リスクに応じた優先順位を付ける - 脅威モデリングはまず、侵害された場合のビジネスへの影響が特大となる、ビジネスに不可欠なアプリケーションに適用しますPrioritize by risk - Apply threat modeling first to business-critical applications that would have an outsize impact on the business if compromised

  2. 範囲を限定する - 多くの手動の労力を投じる前に、連続した細かな段階において脅威モデリングを実行し、すぐに得られる成果と実行可能な軽減策を迅速に特定します。Limit Scope - Perform threat modeling in progressive stages of detail to quickly identify quick wins and actionable mitigations before spending a lot of manual effort:

    1. 下に記載されている単純質問法で開始し (「単純質問法」を参照)、リスクと、基本的な保護が導入されているかどうかをすばやく把握しますStart with simple questions method (See Simple questions method) documented below to quickly get insight into risks and whether basic protections are in place

    2. アプリケーション設計を徐々に評価する – リソースや専門知識を利用できるようになるにつれて、STRIDE 法の高度な脅威のモデリング手法や、既にチームで使用されている類似した別の手法を使用するより高度な分析に移行します。Progressively evaluate Application Design – as resource and expertise are available, move to a more advanced analysis using the STRIDE method Advanced threat modeling techniques or another similar one already used by your team. アーキテクチャ レベルの設計から開始し、時間やリソースの面で許される程度に応じて徐々に詳細さを高めます。Start with the architecture level design and progressively increase detail as time and resources allow:

      1. システム レベルの設計 – アプリケーションと、それらがどのように相互に対話するかを含めますSystem level design – includes applications and how they interact with each other

      2. アプリケーション レベル – アプリケーションのコンポーネントと、それらがどのように相互に対話するかを含めますApplication level – includes components of the application and how they interact with each other

      3. コンポーネント レベル – 個々のコンポーネントがどのように構成されていて、その各要素がどのように相互に対話するかを含めますComponent level – includes how the individual component is composed and how each element of it interacts with each other

  3. 開発ライフサイクルに合わせる – 脅威モデリング アクティビティをアプリケーション開発ライフサイクルに合わせて調整することで、作業を最適化します。Align with Development lifecycle – Optimize your efforts by aligning threat modeling activities with your application development lifecycles.

    1. ウォーターフォール – 大規模なプロジェクトでは、デザイン プロセス中およびアプリケーションに対する重要な更新のときに、脅威モデリングを含める必要があります。Waterfall – ensure major projects should include threat modeling during the design process and during significant updates to the application.

    2. DevOps – 開発チームに過度の負担をかけることなくセキュリティ上の価値が増大する頻度で、脅威モデリング アクティビティをトリガーします。DevOps –Trigger threat modeling activities at a frequency that adds security value without over-burdening the development teams. アプリケーションに対して重要な機能や変更が導入されるとき、および定期的に繰り返し発生する予定表スケジュール (たとえば、ビジネスに不可欠なアプリケーションの場合は毎四半期) が、適切な統合ポイントとなります。Good integration points are during the introduction of significant features or changes to the application and a regular recurring calendar schedule for example, every quarter for business-critical applications.

    3. レガシ アプリケーション – これらのアプリケーションは、通常、組織内でサポート、ソース コードへのアクセス、専門知識が不足しているため、利用可能なアプリケーションの知識や専門知識を使い、ベスト エフォートの原則で脅威モデリングを実行します。Legacy applications – These applications typically lack support, source code access, and/or expertise in the organization, so perform threat modeling on a best effort basis with what application knowledge/expertise you have available.

単純質問法Simple questions method

質問をするこの単純な方法は、セキュリティ専門家や開発者が、STRIDE や OWASP による方法 (「脅威モデリングを通したトップダウン アプローチ」を参照) など、より高度な方法に進む前に脅威モデリングを開始するために設計されています。This simple questioning method is designed to get security professionals and developers started on threat modelling before moving on to a more advanced method like STRIDE or OWASP’s method (see, Top-down approach through threat modeling).

アプリケーションまたはコンポーネントごとに以下の質問をして、回答しますFor each application or component, ask and answer these questions

  • Azure AD、TLS (相互認証を使用)、またはセキュリティ チームによって承認された別の最新セキュリティ プロトコルを使用して接続を認証していますか。Are you authenticating connections using Azure AD, TLS (with mutual authentication), or another modern security protocol approved by your security team? これにより、アプリケーションとデータへの未承認アクセスから保護されますThis protects against unauthorized access to the application and data

    • ユーザーとアプリケーションの間 (該当する場合)Between users and the application (if applicable)

    • 異なるアプリケーション コンポーネントおよびサービスの間 (該当する場合)Between different application components and services (if applicable)

  • アプリケーションでデータの書き込みや変更を行うためのアクセスを持つアカウントを、そうする必要があるアカウントのみに制限していますか。Do you limit which accounts have access to write or modify data in the application to only those required to do so? これにより、未承認のデータ改ざん/変更のリスクが軽減されますThis reduces risk of unauthorized data tampering/alteration

  • Azure Monitor または同様のソリューションによってアプリケーション アクティビティをログに記録し、セキュリティ情報イベント管理 (SIEM) にフィードしていますか。Is the application activity logged and fed into a Security Information and Event Management (SIEM) via Azure Monitor or a similar solution? これは、セキュリティ チームが攻撃を検出して迅速に調査する助けになります。This helps the security team detect attacks and quickly investigate them.

  • ビジネスに不可欠なデータは、セキュリティ チームが承認した暗号化によって保護されていますか。Is business-critical data protected with encryption that has been approved by the security team? これは、保存中のデータの未承認コピーを防ぐ助けとなります。This helps protect against unauthorized copying of data while at rest.

  • 受信および送信ネットワーク トラフィックは TLS を使用して暗号化されますか。Is inbound and outbound network traffic encrypted using TLS? これは、転送中のデータの未承認コピーを防ぐ助けとなります。This helps protect against unauthorized copying of data while in transit.

  • アプリケーションは、Azure の DDoS 保護、Akamai、または類似のサービスを使用して分散型サービス拒否 (DDoS) 攻撃から保護されていますか。Is the application protected against Distributed Denial of Service (DDoS) attacks using services like Azure DDoS protection, Akamai, or similar? これにより、アプリケーションをオーバーロードするように設計された攻撃から保護されるので、アプリケーションは利用できなくなりますThis protects against attacks designed to overload the application so it can’t be used

  • アプリケーションには、その他のアプリケーション、データベース、またはサービスにアクセスするためのサインイン資格情報またはキーが格納されていますか。Does the application store any sign in credentials or keys to access other applications, databases, or services? これは、攻撃がそのアプリケーションを使用して他のシステムを攻撃できるかどうかを識別する助けとなります。This helps identify whether an attack can use your application to attack other systems.

  • アプリケーション制御で、運用中の地域のセキュリティとプライバシーに関する要件を満たすことができていますか。Do the application controls allow you to fulfill security and privacy requirements for the localities you operate in? (これは、ユーザーの非公開データを保護し、コンプライアンスの罰金を回避する助けとなります)(This helps protect user’s private data and avoid compliance fines)

重要: セキュリティは複雑なトピックであり、潜在的なリスクは、スマートに意欲を持つ攻撃者の想像によってのみ制限されます。Important: Security is a complex topic and the potential risks are limited only by the imagination of smart motivated attackers. これらの質問は、攻撃者が簡単に悪用できる、容易に発見可能なギャップを特定する助けとなるよう設計されています。These questions are designed to help identify readily discoverable gaps that are easily exploited by attackers. この方法で安心感や技量を養ってゆくにつれて、高度な脅威モデリング手法へと進み、脅威モデルに対する自分の能力を成長させることを目指せます。As you develop comfort and competencies with this method, you can look to grow your ability to threat model by progressing to advanced threat modelling techniques.

高度な脅威モデリング手法Advanced threat modeling techniques

より包括的な脅威モデルでは、より多くの潜在的リスクを識別できます。評判のよい 2 つの手法は、STRIDE と OWASP ですA more comprehensive threat model can identify more potential risks, two popular techniques are STRIDE and OWASP

  • Microsoft セキュリティ開発ライフサイクルでは、脅威モデリングのプロセスを文書化し、このプロセスを支援する無償ツールをリリースしてきましたMicrosoft Security Development Lifecycle has documented a process of threat modeling in and released a free tool to assist with this process

    • この方法では、潜在的なリスクに対して、アプリケーション コンポーネントと接続/関係を評価します。これが STRIDE という以下の頭字語にマップされます。This method evaluates application components and connections/relationships against potential risks, which map to the STRIDE mnemonic:

      • スプーフィングSpoofing

      • 改ざんTampering

      • 否認Repudiation

      • 情報漏えいInformation Disclosure

      • サービス拒否Denial of Service

      • 特権の昇格Privilege Elevation

    • この方法は、高レベルのアーキテクチャ固有のアプリケーション コンポーネントから、任意のレベルのデザインまで適用できます。This method can be applied to any level of the design from the high level architectural specific application components.

  • OWASP – Open Web Application Security Project (OWASP) は、STRIDE を始めとする方法を参照している、アプリケーション用の脅威モデリング アプローチを文書化してきましたhttps://www.owasp.org/index.php/Application_Threat_ModelingOWASP – The Open Web Application Security Project (OWASP) has documented a threat modeling approach for applications, which refers to STRIDE and other methods https://www.owasp.org/index.php/Application_Threat_Modeling

Web アプリケーション ファイアウォールを使用するUse Web Application Firewalls

Web アプリケーション ファイアウォール (WAF) は、アプリケーションでよく見られるセキュリティ脆弱性を攻撃者が悪用できるリスクを軽減します。Web application firewalls (WAFs) mitigate the risk of an attacker being able to exploit commonly seen security vulnerabilities for applications. 完全ではありませんが、WAF では、Web アプリケーションに最小レベルの基本的セキュリティが提供されます。While not perfect, WAFs provide a basic minimum level of security for web applications.

攻撃者は Web アプリケーションを、クライアント エンドポイントに似た、組織に入るイングレス ポイントのターゲットとするため、WAF は重要な軽減策です。WAFs are an important mitigation as attackers target web applications for an ingress point into an organization similar to a client endpoint. WAF は以下の両方に適していますWAFs are appropriate for both

  • 強力なアプリケーション セキュリティ プログラムを使用していない組織の重要な安全対策として (飛行機内のパラシュートとよく似ています)。Organizations without a strong application security program as it’s a critical safety measure(much like a parachute in a plane. これが、アプリケーションのセキュリティ バグの量と重大度を軽減する、計画済みの唯一の安全メカニズムであってはならないことに注意してください。Note that this shouldn’t be the only planned safety mechanism to reduce the volume and severity of security bugs in your applications. 詳細については、セキュリティ バグの量と影響を軽減することに関するセクションを参照してください。For details, see Reduce security bug volume and impact.

  • アプリケーション セキュリティに投資してきた組織。WAF は有用な追加防御による徹底した軽減策となるためです。Organizations who have invested in application security as WAFs provide a valuable additional defense in-depth mitigation. この場合の WAF は、開発ライフサイクル内のセキュリティの実践では見逃されたセキュリティ バグがあった場合の、最終的な安全メカニズムとして機能します。WAFs in this case act as a final safety mechanism in case a security bug was missed by security practices in the development lifecycle.

Microsoft は、Azure Application Gateway に WAF 機能を搭載しており、多くのベンダーが、これらの機能をスタンドアロンのセキュリティ アプライアンスとして、または次世代ファイアウォールの一部として提供しています。Microsoft includes WAF capabilities in Azure Application Gateway and many vendors offer these capabilities as standalone security appliances or as part of next generation firewalls.

コンテナーのセキュリティに関するベストプラクティスに従うFollow best practices for container security

コンテナーでホストされるアプリケーションでは、一般的なアプリケーションのベストプラクティスに加え、いくつかの特定のガイドラインに従ってこの新しい種類のアプリケーション アーキテクチャを管理する必要がありますApplications hosted in containers should follow general application best practices as well as some specific guidelines to manage this new application architecture type

コンテナー化されたアプリケーションは、すべてのアプリケーションと同じリスクに直面します。また、コンテナー化されたアプリケーションのホストと管理を安全に行うための新しい要件も加わります。Containerized applications face the same risks as any application and also adds new requirements to securely the hosting and management of the containerized applications.

アプリケーション コンテナーのアーキテクチャには、開発者の生産性を高め、DevOps の原則を採用した、抽象化と管理のツール (通常は Kubernetes) の新しいレイヤーが導入されました。Application containers architectures introduced a new layer of abstraction and management tooling (typically Kubernetes) that have increased developer productivity and adoption of DevOps principles.

これは急速に進化している新興の領域ですが、いくつかの重要な教訓が学ばれて、ベスト プラクティスが明らかになってきています。While this is an emerging space that is evolving rapidly, several key lessons learned and best practices have become clear:

  • Kubernetes をインストールおよび管理するのではなく、Kubernetes で管理されたサービスを使用するUse a Kubernetes managed service instead of installing and managing Kubernetes
    Kubernetes は非常に複雑なシステムであり、セキュリティで保護されていない既定の設定がまだ多数あって、市場には Kubernetes のセキュリティ専門家があまりいません。Kubernetes is a very complex system and still has a number of default settings that are not secure and few Kubernetes security experts in the marketplace. これは近年、リリースごとに改善されてきていますが、軽減する必要のあるリスクはまだ多数存在しています。While this has been improving in recent years with each release, there are still a lot of risks that have to be mitigated.

  • コンテナーとコンテナーがつながるサプライ チェーンを検証するValidate container + container supply chain
    アプリケーションに追加されたオープンソース コードがあればそのセキュリティを検証する必要があるのと同様に、アプリケーションに追加するコンテナーも検証する必要があります。Just as you should validate the security of any open-source code added to your applications, you should also validate containers you add to your applications.

    • セキュリティ更新プログラムの適用、バックドアや違法な暗号化コイン マイナーなどの不要なコードのスキャン、セキュリティ脆弱性のスキャン、セキュリティで保護された開発実施方法の適用などのセキュリティ標準に照らして、コンテナーの構築に適用された実施方法が検証されていることを確認します。Ensure that the practices applied to building the container are validated against your security standards like application of security updates, scanning for unwanted code like backdoors and illicit crypto coin miners, scanning for security vulnerabilities, and application of secure development practices.

    • コンテナー レジストリに既知のリスクがないか、使用前や使用中にコンテナーを定期的にスキャンします。Regularly scan containers for known risks in the container registry, before use, or during use.

  • 既知の正常なコンテナーのレジストリを設定するSet up registry of known good containers
    これにより、組織の開発者は、セキュリティ部門によって検証されたコンテナーを、少ない手間で迅速に使用できます。This allows developers in your organization to use containers validated by security rapidly with low friction. さらに、開発者が、手間を回避するのではなく、新しいコンテナーのセキュリティ検証を要求して迅速に取得するためのプロセスを構築し、このプロセスを使用することを促します。Additionally, build a process for developer to request and rapidly get security validation of new containers to encourage developers to use this process vs. working around it.

  • 明示的に必要とされない限り、ルートまたは管理者としてコンテナーを実行しないDon’t run containers as root or administrator unless explicitly required
    以前のバージョンのコンテナーにはルート特権が必要でした (それにより攻撃が容易になります) が、現在のバージョンでは不要になりました。Early versions of containers required root privileges (which makes attacks easier), but this is no longer required with current versions.

  • コンテナーの監視Monitor containers
    コンテナー対応のセキュリティ監視ツールをデプロイして異常な動作を監視し、インシデントを調査できるようにします。Ensure you deploy security monitoring tools that are container aware to monitor for anomalous behavior and enable investigation of incidents.

次のステップNext steps

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