Azure エンタープライズ スキャフォールディング:サブスクリプションの規範的なガバナンスAzure enterprise scaffold: Prescriptive subscription governance

俊敏性と柔軟性を求めてパブリック クラウドを採用する企業がますます増えています。Enterprises are increasingly adopting the public cloud for its agility and flexibility. これらの企業は、収益を生み出したり、ビジネスのリソース使用状況を最適化したりするために、クラウドの強みに依存しています。They rely on the cloud's strengths to generate revenue and optimize resource usage for the business. Microsoft Azure は、企業がさまざまなワークロードやアプリケーションに対応するためにブロックのように組み立てることができる多数のサービスと機能を提供しています。Microsoft Azure provides a multitude of services and capabilities that enterprises assemble like building blocks to address a wide array of workloads and applications.

Microsoft Azure の使用を決定することは、クラウドのメリットを実現する最初のステップに過ぎません。Deciding to use Microsoft Azure is only the first step to achieving the benefit of the cloud. 次のステップは、企業が効果的に Azure を利用するための方法を理解して、次の質問に対応できるように設定する必要があるベースライン機能を特定することです。The second step is understanding how the enterprise can effectively use Azure and identify the baseline capabilities that need to be in place to address questions like:

  • "データの主権に懸念があります。自分のデータとシステムが規制要件を満たすことをどのように保証できるか""I'm concerned about data sovereignty; how can I ensure that my data and systems meet our regulatory requirements?"
  • "各リソースがサポートしているものを把握し、その明細を明らかにして正確に課金できるようにするにはどうすればよいか""How do I know what each resource is supporting so I can account for it and bill it back accurately?"
  • "パブリック クラウドでのデプロイや処理はすべて、セキュリティを最重要として開始されることを確認する必要があります。そのためには何をすべきか""I want to make sure that everything we deploy or do in the public cloud starts with the mindset of security first, how do I help facilitate that?"

ガードレールのない空のサブスクリプションでは見通しが立ちません。The prospect of an empty subscription with no guardrails is daunting. この空のスペースは、Azure への移行の妨げとなる可能性があります。This blank space can hamper your move to Azure.

この記事は、技術者がガバナンスのニーズに対処し、俊敏性のニーズとのバランスを取る際の出発点となります。This article provides a starting point for technical professionals to address the need for governance and balance it with the need for agility. この記事では、組織が安全な方法で Azure 環境を実装および管理する際の指針となるエンタープライズ スキャフォールディングの概念について説明します。It introduces the concept of an enterprise scaffold that guides organizations in implementing and managing their Azure environments in a secure way. こうして提供されるフレームワークが、効果的かつ効率的な管理につながります。It provides the framework to develop effective and efficient controls.

ガバナンスのニーズNeed for governance

Azure に移行する場合、企業内でクラウドを有効に活用するために、早期にガバナンスに対処する必要があります。When moving to Azure, you must address the topic of governance early to ensure the successful use of the cloud within the enterprise. しかし、包括的なガバナンス システムの構築には時間がかかり、煩雑さを伴うため、IT 部門を関与させずに直接プロバイダーに依頼するビジネス グループもあります。Unfortunately, the time and bureaucracy of creating a comprehensive governance system means some business groups go directly to providers without involving enterprise IT. このアプローチでは、リソースが適切に管理されていない場合に、企業がセキュリティ侵害にさらされるおそれがあります。This approach can leave the enterprise open to compromise if the resources are not properly managed. パブリック クラウドの俊敏性、柔軟性、従量課金という特性は、(社内と外部の両方の) 顧客のニーズに速やかに対応する必要があるビジネス グループにとって重要です。The characteristics of the public cloud—agility, flexibility, and consumption-based pricing—are important to business groups that need to quickly meet the demands of customers (both internal and external). ただし、IT 部門はデータとシステムを効果的に保護できるようにする必要があります。But enterprise IT needs to ensure that data and systems are effectively protected.

ビルを建てるとき、スキャフォールディング (足場) は構造の基礎を作るために使用されます。When creating a building, scaffolding is used to create the basis of a structure. スキャフォールディングは概要を示し、より永続的なシステムを実装するためのアンカー ポイントを提供します。The scaffold guides the general outline and provides anchor points for more permanent systems to be mounted. エンタープライズ スキャフォールディングも同様であり、環境を構造化する一連の柔軟な制御と Azure の機能、およびパブリック クラウド上に構築されるサービスのアンカーを提供します。An enterprise scaffold is the same: a set of flexible controls and Azure capabilities that provide structure to the environment, and anchors for services built on the public cloud. エンタープライズ スキャフォールディングは、迅速に提供することに配慮した、ビルダー (IT 部門とビジネス グループ) が新しいサービスを作成して配置するための基盤となります。It provides the builders (IT and business groups) a foundation to create and attach new services keeping speed of delivery in mind.

スキャフォールディングは、さまざまな規模のクライアントとの多数の取り組みの中で収集された実践に基づいています。The scaffold is based on practices we have gathered from many engagements with clients of various sizes. これらのクライアントは、小規模の組織から、クラウドでソリューションの移行と開発を行っている大規模な多国籍企業や独立系ソフトウェア ベンダーまでさまざまです。ワークロードを移行したり、クラウド用ソリューションを開発したりしています。Those clients range from small organizations developing solutions in the cloud to large multinational enterprises and independent software vendors who are migrating workloads and developing cloud-native solutions. エンタープライズ スキャフォールディングは、従来型 IT ワークロードとアジャイル ワークロード (Azure プラットフォームの機能に基づくサービスとしてのソフトウェア (SaaS) アプリケーションの開発など) の両方を柔軟にサポートできるように設計されています。The enterprise scaffold is "purpose-built" to be flexible to support both traditional IT workloads and agile workloads; such as, developers creating software as a service (SaaS) applications based on Azure platform capabilities.

エンタープライズ スキャフォールディングは、Azure 内の新しい各サブスクリプションの基盤として使用することを目的としています。The enterprise scaffold is intended to be the foundation of each new subscription within Azure. エンタープライズ スキャフォールディングにより、管理者は、ビジネス グループや開発者が各自の目標を速やかに達成するのを妨げることなく、組織のガバナンスの最小要件を満たすワークロードを実現できます。It enables administrators to ensure workloads meet the minimum governance requirements of an organization without preventing business groups and developers from quickly meeting their own goals. 私たちの経験から、これがパブリック クラウドの成長を妨げるものではなく、成長の速度を大いに速めることは明らかです。Our experience shows that this greatly speeds, rather than impedes, public cloud growth.

注意

Azure Blueprints と呼ばれる新機能がプレビューとしてリリースされました。これは、サブスクリプションや管理グループにまたがって、共通のイメージ、テンプレート、ポリシー、スクリプトの、パッケージ化、管理、およびデプロイを行えるようにするものです。Microsoft has released into preview a new capability called Azure Blueprints that will enable you to package, manage, and deploy common images, templates, policies, and scripts across subscriptions and management groups. この機能は、参照モデルとしてのスキャフォールディングの目的と、企業へのモデルのデプロイの橋渡しをします。This capability is the bridge between the scaffold's purpose as reference model and deploying that model to your organization.

次の図は、スキャフォールディングのコンポーネントを示しています。The following image shows the components of the scaffold. 基礎は、管理階層とサブスクリプションの確かな計画に依存しています。The foundation relies on a solid plan for the management hierarchy and subscriptions. 柱は、Resource Manager ポリシーと厳密な命名規則で構成されます。The pillars consist of Resource Manager policies and strong naming standards. スキャフォールディングの残りの部分は、安全で管理しやすい環境を実現して結び付ける Azure のコア機能です。The rest of the scaffold are core Azure capabilities and features that enable and connect a secure and manageable environment.

エンタープライズ スキャフォールディング

階層の定義Define your hierarchy

スキャフォールディングの基盤は、サブスクリプションとリソース グループにおける Azure エンタープライズ加入契約の階層とリレーションシップです。The foundation of the scaffold is the hierarchy and relationship of the Azure Enterprise Enrollment through to subscriptions and resource groups. エンタープライズ加入契約は、契約の観点から、企業内での Azure サービスの構造と使用法を定めています。The enterprise enrollment defines the shape and use of Azure services within your company from a contractual point of view. エンタープライズ契約の範囲内で、各企業の構造に合わせて、環境を部門、アカウント、サブスクリプション、リソース グループにさらに分割できます。Within the Enterprise Agreement, you can further subdivide the environment into departments, accounts, subscriptions, and resource groups to match your organization's structure.

階層

Azure サブスクリプションは、すべてのリソースが含まれる基本単位です。An Azure subscription is the basic unit where all resources are contained. また、サブスクリプションによって Azure 内での制限 (コア数、仮想ネットワーク数、その他のリソース数など) が定められます。It also defines several limits within Azure, such as number of cores, virtual networks and other resources. Azure リソース グループを使用すると、サブスクリプション モデルをさらに調整して、リソースを自然なグループに分けることができます。Azure Resource Groups are used to further refine the subscription model and enable a more natural grouping of resources.

企業はそれぞれ異なるので、上の図の階層はその企業での Azure の構造に非常に柔軟に対応します。Every enterprise is different and the hierarchy in the above image allows for significant flexibility in how Azure is organized within your company. 企業の課金、リソース管理、リソース アクセスのニーズを反映するように階層をモデル化することは、パブリック クラウドの運用を開始する際に最初に行う最も重要な決定事項です。Modeling your hierarchy to reflect your company's billing, resource management, and resource access needs is the first and most important decision you make when starting in the public cloud.

部門とアカウントDepartments and Accounts

Azure の加入契約には、次の 3 つの一般的なパターンがあります。The three common patterns for Azure Enrollments are:

  • 機能パターン:The functional pattern:

    機能パターン

  • 部署パターン:The business unit pattern:

    部署パターン

  • 地域パターン:The geographic pattern:

    地域パターン

これらのパターンのそれぞれに役割がありますが、部署パターンが使用されることが増えています。企業のコスト モデルをモデル化する際や、統制範囲を反映する際に柔軟性が高いためです。Though each of these patterns has its place, the business unit pattern is increasingly being adopted for its flexibility in modeling an organization's cost model as well as reflecting span of control. Microsoft Core Engineering and Operations グループによって、連邦、および地方に関してモデル化された部署パターンの効果的なサブセットが作成されました。Microsoft Core Engineering and Operations group has created an effective subset of the business unit pattern modeled on Federal, State, and Local. 詳細については、「Organizing subscriptions and resource groups within the Enterprise (企業におけるサブスクリプションとリソース グループの編成)」を参照してください。For more information, see Organizing subscriptions and resource groups within the Enterprise.

Azure 管理グループAzure management groups

Microsoft は階層をモデル化するための別の方法を提供しています。Azure 管理グループという新しい方法をリリースしました。Microsoft now provides another way to model your hierarchy: Azure management groups. 管理グループは、部門とアカウントよりも柔軟性が非常に高く、最大で 6 レベルまで入れ子にすることができます。Management groups are much more flexible than departments and accounts, and they can be nested up to six levels. 管理グループを使用すると、課金階層とは別に、リソースの効率的な管理のみを目的として階層を作成できます。Management groups let you create a hierarchy that is separate from your billing hierarchy, solely for efficient management of resources. 管理グループは課金階層を正確に反映するように作成できます。多くの企業ではそのように開始しています。Management groups can mirror your billing hierarchy and often enterprises start that way. ただし、管理グループが力を発揮するのは、それらを使用して組織をモデル化し、関連するサブスクリプションをまとめて (請求階層内の場所に関係なく) グループ化し、共通のロール、ポリシー、およびイニシアティブを割り当てる場合です。However, the power of management groups is when you use them to model your organization, grouping together related subscriptions (regardless of their location in the billing hierarchy) and assigning common roles, policies, and initiatives. 次に例をいくつか示します。Some examples include:

  • 運用と非運用。Production vs. nonproduction. 一部の企業は、運用サブスクリプションと非運用サブスクリプションを識別するために管理グループを作成します。Some enterprises create management groups to identify their production and nonproduction subscriptions. このようなお客様は、管理グループによって、ロールとポリシーを簡単に管理できます。Management groups allow these customers to more easily manage roles and policies. たとえば、非運用サブスクリプションでは、開発者は、共同作成者としてアクセスできますが、運用環境では閲覧者としてのみアクセスできます。For example, nonproduction subscription may allow developers "contributor" access, but in production, they have only "reader" access.
  • 内部サービスと外部サービス。Internal services vs. external services. 企業では、多くの場合、内部サービスと顧客向けサービスで要件、ポリシー、ロールが異なります。Enterprises often have different requirements, policies, and roles for internal services versus customer-facing services.

適切に設計された管理グループを Azure のポリシーとイニシアティブと一緒に使用することが、効率的な Azure ガバナンスのバックボーンです。Well-designed management groups are, along with Azure Policy and Initiatives, the backbone of efficient governance of Azure.

SubscriptionsSubscriptions

部門とアカウント (または管理グループ) について決めるときは、Azure 環境をどのように分割すれば企業に合わせられるかを主に考えます。When deciding on your Departments and Accounts (or management groups), you are primarily looking at how you're dividing up your Azure environment to match your organization. しかしながら、サブスクリプションは実際の処理が行われる場所であるため、ここでの決定はセキュリティ、スケーラビリティおよび課金に影響を与えます。Subscriptions, however, are where the real work happens and your decisions here affect security, scalability, and billing. 多くの組織は次のパターンを参考にしています。Many organizations look at the following patterns as their guides:

  • アプリケーション/サービス: サブスクリプションはアプリケーションまたはサービス (アプリケーションのポートフォリオ) を表しますApplication/service: Subscriptions represent an application or a service (portfolio of applications)
  • ライフサイクル: サブスクリプションはサービスのライフサイクル (運用または開発など) を表します。Lifecycle: Subscriptions represent a lifecycle of a service, such as Production or Development.
  • 部門: サブスクリプションは組織内の部門を表します。Department: Subscriptions represent departments in the organization.

最初の 2 つのパターンが最もよく使用されており、どちらも強くお薦めします。The first two patterns are the most commonly used, and both are highly recommended. ライフサイクルのアプローチはほとんどの組織に適しています。The Lifecycle approach is appropriate for most organizations. このケースでは、一般的には 2 つの基本サブスクリプションの使用をお薦めします。In this case, the general recommendation is to use two base subscriptions. "運用" と "非運用" です。リソース グループを使用して、環境をさらに分割します。"Production" and "Nonproduction," and then use resource groups to break out the environments further.

リソース グループResource groups

Azure Resource Manager では、管理、課金、または自然なアフィニティのために、リソースを意味のあるグループに配置できます。Azure Resource Manager enables you to put resources into meaningful groups for management, billing, or natural affinity. リソース グループは、共通のライフサイクルを持つリソースまたは "all SQL servers" や "Application A" などの属性を共有するリソースのコンテナーです。Resource groups are containers of resources that have a common lifecycle or share an attribute such as "all SQL servers" or "Application A".

リソース グループに別のリソース グループを入れ子にすることはできません。また、リソースは 1 つのリソース グループにのみ属することができます。Resource groups can't be nested, and resources can only belong to one resource group. リソース グループのすべてのリソースに対して特定のアクションを適用できます。Some actions can act on all resources in a resource group. たとえば、リソース グループを削除すると、そのリソース グループ内のすべてのリソースが削除されます。For example, deleting a resource group removes all resources within the resource group. サブスクリプションと同じく、リソース グループを作成するときには一般的なパターンがあり、これらは "従来型 IT" ワークロードから "アジャイル IT" ワークロードまでさまざまです。Like subscriptions, there are common patterns when creating resource groups and will vary from "Traditional IT" workloads to "Agile IT" workloads:

  • "従来型 IT" ワークロードは、同じライフサイクル内の項目 (アプリケーションなど) でグループ化するのが最も一般的です。"Traditional IT" workloads are most commonly grouped by items within the same lifecycle, such as an application. アプリケーションでグループ化すると、個々のアプリケーションの管理が可能になります。Grouping by application allows for individual application management.
  • "アジャイル IT" ワークロードは、外部顧客向けのクラウド アプリケーションに集中する傾向があります。"Agile IT" workloads tend to focus on external customer-facing cloud applications. 多くの場合、リソース グループは、デプロイメントのレイヤー (Web 層、アプリケーション層など) と管理のレイヤーを反映します。The resource groups often reflect the layers of deployment (such as a web tier or app tier) and management.

注意

ワークロードを理解すると、リソース グループ戦略の開発に役立ちます。Understanding your workload helps you develop a resource group strategy. これらのパターンをうまく組み合わせることができます。These patterns can be mixed and matched. たとえば、共有サービス リソース グループを "アジャイル" リソース グループと同じサブスクリプションにします。For example, a shared services resource group in the same subscription as "Agile" resource groups.

命名規則Naming standards

スキャフォールディングの最初の柱は一貫性がある命名規則です。The first pillar of the scaffold is a consistent naming standard. 適切に設計された命名規則を使用することで、ポータル、請求書、スクリプトでリソースを識別できるようになります。Well-designed naming standards enable you to identify resources in the portal, on a bill, and within scripts. おそらくオンプレミス インフラストラクチャのための命名規則は既に存在しています。You likely already have existing naming standards for on-premises infrastructure. Azure を環境に追加するときは、それらの命名規則をAzure リソースにも適用する必要があります。When adding Azure to your environment, you should extend those naming standards to your Azure resources.

ヒント

命名規則のヒントFor naming conventions:

  • パターンと実践のガイダンスを確認し、可能であれば採用してください。Review and adopt where possible the Patterns and Practices guidance. このガイダンスは意味のある命名規則を決定する際に役立ち、例も豊富に含まれています。This guidance helps you decide on a meaningful naming standard and provides extensive examples.
  • Resource Manager ポリシーを使用すると、命名規則の適用に役立ちます。Using Resource Manager Policies to help enforce naming standards.

名前を後から変更するのは難しいことに注意してください。ここで数分間かけておけば後で面倒が起きません。Remember that it's difficult to change names later, so a few minutes now will save you trouble later.

よく使用され検索対象にもなるリソースの命名規則は十分に考えてください。Concentrate your naming standards on those resources that are more commonly used and searched for. たとえば、区別しやすいように、すべてのリソース グループが厳しい規則に従う必要があると定めます。For example, all resource groups should follow a strong standard for clarity.

リソース タグResource Tags

リソース タグは命名規則と密接に関連しています。Resource tags are tightly aligned with naming standards. リソースがサブスクリプションに追加されると、課金、管理、運用の目的から、論理的にリソースを分類することが非常に重要になります。As resources are added to subscriptions, it becomes increasingly important to logically categorize them for billing, management, and operational purposes. 詳細については、タグを使用した Azure リソースの整理に関するページを参照してください。For more information, see Use tags to organize your Azure resources.

重要

タグには個人情報が含まれる可能性があり、GDPR 規制の対象になる場合があります。Tags can contain personal information and may fall under the regulations of GDPR. タグの管理は注意深く計画してください。Plan for management of your tags carefully. GDPR に関する全般情報については、Service Trust Portal の GDPR に関するセクションを参照してください。If you're looking for general information about GDPR, see the GDPR section of the Service Trust Portal.

タグは課金や管理以外でも多くの方法で使用されます。Tags are used in many ways beyond billing and management. これらはオートメーションにおいてよく使用されます (後のセクションを参照してください)。They are often used as part of automation (see later section). このため、事前に考慮しておかないと、競合が発生することがあります。This can cause conflicts if not considered up front. 推奨プラクティスは、エンタープライズ レベル (ApplicationOwner、CostCenter など) で一般的なすべてのタグを指定し、オートメーションを使用してリソースをデプロイするときに一貫して適用することです。The recommended practice is to identify all the common tags at the enterprise level (such as ApplicationOwner and CostCenter) and apply them consistently when deploying resources using automation.

Azure のポリシーとイニシアティブAzure Policy and Initiatives

スキャフォールディングの第 2 の柱は、Azure のポリシーとイニシアティブを使用して、サブスクリプションのリソースとサービスに対して (効果的に) 規則を適用して、リスクを管理することです。The second pillar of the scaffold involves using Azure Policy and initiatives to manage risk by enforcing rules (with effects) over the resources and services in your subscriptions. Azure のイニシアティブは、1 つの目標を達成するように設計されたポリシーのコレクションです。Azure Initiatives are collections of policies that are designed to achieve a single goal. その後、ポリシーとイニシアティブをリソース スコープに割り当てて、それらのポリシーの適用を開始します。Policies and initiatives are then assigned to a resource scope to begin enforcement of those policies.

ポリシーとイニシアティブは、前述した管理グループと一緒に使用するとさらに効果的です。Policies and initiatives are even more powerful when used with the management groups mentioned earlier. 管理グループを使用すると、イニシアティブまたはポリシーをサブスクリプションのセット全体に割り当てられるようになります。Management groups enable the assignment of an initiative or policy to an entire set of subscriptions.

Resource Manager ポリシーの一般的な使用法Common uses of Resource Manager policies

ポリシーとイニシアティブは、Azure Toolkit の強力なツールの 1 つです。Policies and initiatives are a powerful tool in the Azure toolkit. ポリシーを使用すると、企業は "従来型 IT" ワークロードを制御できるようになり、基幹業務アプリケーションで必要となる安定性が実現します。その一方で、"アジャイル" ワークロードにも対処できます。たとえば、企業のリスクを高めずにカスタマー アプリケーションを開発することができます。Policies allow companies to provide controls for "Traditional IT" workloads that enable the stability that is needed for line-of-business applications while also allowing "Agile" workloads; such as, developing customer applications without exposing the enterprise to additional risk. ポリシーの最も一般的なパターンは次のとおりです。The most common patterns for policies are:

  • 地域のコンプライアンスとデータの主権。Geo compliance and data sovereignty. Azure が対応するリージョンは世界にまたがり、その数は増え続けています。Azure has an ever-growing list of regions across the world. 多くの場合、企業は、規制要件に対処するために、特定のスコープのリソースが 1 つの地理的リージョンに存在することを保証する必要があります。Enterprises often need to ensure that resources in a specific scope remain in a geographic region to address regulatory requirements.
  • サーバーの公開を回避します。Avoid exposing servers publicly. Azure のポリシーにより、特定のリソースの種類のデプロイを禁止できます。Azure Policy can prohibit the deployment of certain resource types. 一般的には、特定の範囲でパブリック IP の作成を拒否するポリシーを作成して、意図せずにサーバーをインターネットに公開することを避けます。It's common to create a policy to deny the creation of a public IP within a specific scope, avoiding unintended exposure of a server to the internet.
  • コスト管理とメタデータ。Cost management and metadata. 多くの場合、リソース タグは、CostCenter や Owner などのリソースとリソース グループに重要な課金データを追加するために使用されます。Resource tags are often used to add important billing data to resources and resource groups such as CostCenter, Owner, and more. これらのタグは、リソースの正確な課金と管理のために重要です。These tags are invaluable for accurate billing and management of resources. ポリシーによって、デプロイされたすべてのリソースに対してリソース タグの適用が実施され、管理が容易になります。Policies can enforce the application of resources tags to all deployed resource, making it easier to manage.

イニシアティブの一般的な使用方法Common uses of initiatives

企業は、イニシアティブを利用して論理ポリシーをグループ化し、それらを 1 つのエンティティとして追跡することができます。Initiatives provide enterprises the ability to group logical policies and track them as a single entity. イニシアティブによって、企業はアジャイル ワークロードと従来のワークロード両方のニーズに対処できます。Initiatives help the enterprise address the needs of both agile and traditional workloads. 次のようなイニシアティブの一般的な使用方法があります。Common uses of initiatives include:

  • Azure Security Center での監視を有効にします。Enable monitoring in Azure Security Center. これは Azure Policy での既定のイニシアティブであり、イニシアティブとは何かがよくわかる例です。This is a default initiative in the Azure Policy and an excellent example of what initiatives are. これによって、ポリシーで、暗号化されていない SQL データベース、仮想マシン (VM) の脆弱性、一般的なセキュリティ関連ニーズを識別できるようになります。It enables policies that identify unencrypted SQL databases, virtual machine (VM) vulnerabilities, and more common security-related needs.
  • 規制固有のイニシアティブ。Regulatory-specific initiative. 多くの場合、企業は規制要件 (HIPAA など) に共通するポリシーをグループ化して、コントロールやコントロールに対するコンプライアンスを効率的に追跡できるようにします。Enterprises often group policies common to a regulatory requirement (such as HIPAA) so that controls and compliancy to those controls are tracked efficiently.
  • リソースの種類と SKU。Resource types and SKUs. デプロイできるリソースの種類と、デプロイできる SKU を制限するイニシアティブの作成は、コストを管理するために役立ちます。また、これによって、組織は、サポートするためのスキルセットと手順がチームにあるリソースのみを確実にデプロイできます。Creating an initiative that restricts the types of resources that can be deployed as well as the SKUs that can be deployed can help to control costs and ensure your organization is only deploying resources that your team have the skillset and procedures to support.

ヒント

ポリシー定義の代わりにイニシアティブ定義を常に使用することをお勧めします。We recommend you always use initiative definitions instead of policy definitions. イニシアティブをスコープ (サブスクリプションまたは管理グループ) に割り当てた後で、割り当てを変更する必要なく、イニシアティブに簡単にもう 1 つのポリシーを追加できます。After assigning an initiative to a scope, such as subscription or management group, you can easily add another policy to the initiative without having to change any assignments. これにより、適用内容の理解とコンプライアンスの追跡がきわめて容易になります。This makes understanding what is applied and tracking compliance far easier.

ポリシーとイニシアティブの割り当てPolicy and Initiative assignments

ポリシーを作成して、それを論理的なイニシアティブにグループ分けしたら、ポリシーをスコープ (管理グループ、サブスクリプション、またはリソース グループ) に割り当てる必要があります。After the creation of policies and grouping them into logical initiatives you must assign the policy to a scope, whether it is a management group, a subscription or even a resource group. 割り当てによって、ポリシーの割り当てからサブスコープを除外することもできます。Assignments allow you to also exclude a subscope from the assignment of a policy. たとえば、あるサブスクリプション内のパブリック IP の作成を拒否する場合に、保護対象の DMZ に接続するリソース グループを除外する割り当てを作成できます。For example, if you deny the creation of public IPs within a subscription, you could create an assignment with an exclusion for a resource group connected to your protected DMZ.

ポリシーの例をいくつか参照してください。Azure 内でさまざまなリソースにポリシーとイニシアティブを適用できる方法が、この GitHub リポジトリに記載されています。You will find several Policy examples that show how Policy and Initiatives can be applied to various resources within Azure on this GitHub repository.

ID 管理とアクセス管理Identity and access management

パブリック クラウドの使用を開始するにあたり、最初に重要な質問として、「リソースにアクセスできる必要があるのはだれか」、One of the first, and most crucial, questions you ask yourself when starting with the public cloud is "who should have access to resources?" 「このアクセスを制御するにはどうすればよいか」と自問しているかもしれません。and "how do I control this access?" Azure portal とポータルでのリソースへのアクセス制御は、クラウド内の資産の長期的な安全性にとって不可欠です。Controlling access to the Azure portal and resources in the portal is critical to the long-term safety of your assets in the cloud.

リソースへのアクセスをセキュリティで保護するには、まず ID プロバイダーを構成してから、ロールとアクセス権を構成します。To secure access to your resources you will first configure your identity provider and then configure Roles and access. オンプレミスの Active Directory に接続している Azure Active Directory (Azure AD) は、Azure Identity の基盤です。Azure Active Directory (Azure AD), connected to your on-premises Active Directory, is the foundation of Azure Identity. つまり、Azure AD はオンプレミスの Active Directory と同じでは "ありません"。Azure AD テナントは何か、Azure 加入契約とどのように関連しているかを理解することが重要です。That said, Azure AD is not the same as on-premises Active Directory, and it's important to understand what an Azure AD tenant is and how it relates to your Azure enrollment. Azure AD とオンプレミスの Active Directory の基本を確実に学ぶためには、こちらの情報を確認してください。Review the available information to gain a solid foundation on Azure AD and on-premises Active Directory. Active Directory を Azure AD に接続して同期するには、Azure AD Connect ツールをオンプレミスにインストールして構成します。To connect and synchronize your Active Directory to Azure AD, install and configure the Azure AD Connect tool on-premises.

arch.png

Azure が最初にリリースされたときには、サブスクリプションに対するアクセス制御が基本でした (管理者または共同管理者)。When Azure was initially released, access controls to a subscription were basic: Administrator or Co-Administrator. クラシック モデルでのサブスクリプションへのアクセスは、ポータルでのすべてのリソースへのアクセスを意味していました。Access to a subscription in the Classic model implied access to all the resources in the portal. きめ細かく制御することができなかったため、Azure 加入契約に一定レベルの妥当なアクセス制御を提供するためにサブスクリプションが急増しました。This lack of fine-grained control led to the proliferation of subscriptions to provide a level of reasonable access control for an Azure Enrollment. このようにサブスクリプションを急増させる必要はなくなりました。This proliferation of subscriptions is no longer needed. ロールベースのアクセス制御 (RBAC) では、"所有者"、"共同作成者"、"閲覧者" など一般的なアクセス権を提供する標準ロールをユーザーに割り当てることができます。独自のロールを作成することもできます。With role-based access control (RBAC), you can assign users to standard roles that provide common access such as "owner", "contributor" or "reader" or even create your own roles.

ロールベースのアクセスを実装するとき、次を強くお薦めします。When implementing role-based access, the following are highly recommended:

  • サブスクリプションの管理者/共同管理者を制御します。これらのロールは大きな権限を持っているためです。Control the Administrator/Co-Administrator of a subscription as these roles have extensive permissions. Azure クラシック デプロイを管理する必要がある場合は、サブスクリプションの所有者を共同管理者として追加するだけです。You only need to add the Subscription Owner as a Co-administrator if they need to managed Azure Classic deployments.
  • 管理グループを使用して、複数のサブスクリプションにロールを割り当て、サブスクリプション レベルでロールを管理する負荷を減らします。Use management groups to assign roles across multiple subscriptions and reduce the burden of managing them at the subscription level.
  • Azure ユーザーを Active Directory のグループ (アプリケーション X の所有者など) に追加します。Add Azure users to a group (for example, Application X Owners) in Active Directory. 同期されたグループを使用して、アプリケーションが属するリソース グループを管理するための適切な権限をグループのメンバーに付与します。Use the synced group to provide group members the appropriate rights to manage the resource group containing the application.
  • 求められている作業を行うために必要な最小限の特権の付与の原則に従います。Follow the principle of granting the least privilege required to do the expected work.

重要

Azure AD Privileged Identity Management、Azure Multi-Factor Authentication、および条件付きアクセス機能の使用を検討してください。これらによって、セキュリティが強化され、Azure サブスクリプション全体の管理操作の可視性が向上します。Consider using Azure AD Privileged Identity Management, Azure Multi-Factor Authentication and Conditional Access capabilities to provide better security and more visibility to administrative actions across your Azure subscriptions. これらの機能は有効な Azure AD Premium ライセンスで使用でき (機能によって異なる)、アイデンティティをさらに保護して管理します。These capabilities come from a valid Azure AD Premium license (depending on the feature) to further secure and manage your identity. Azure AD PIM により、承認ワークフローの "Just-in-Time" 管理アクセスと、管理者のアクティブ化とアクティビティの完全な監査が可能になります。Azure AD PIM enables "Just-in-Time" administrative access with approval workflow, as well as a full audit of administrator activations and activities. Azure Multi-Factor Authentication はもう 1 つの重要な機能であり、Azure portal へのログインの 2 段階認証を有効にします。Azure Multi-Factor Authentication is another critical capability and enables two-step verification for login to the Azure portal. 条件付きアクセス制御と組み合わせると、セキュリティ侵害のリスクを効果的に管理できます。When combined with Conditional Access Controls you can effectively manage your risk of compromise.

アイデンティティとアクセス制御について計画を立てて準備すること、および Azure Identity Management のベスト プラクティス (リンク) に従うことは、採用できる最適なリスク軽減戦略の 1 つであり、すべてのデプロイにおいて必須と考える必要があります。Planning and preparing for your identity and access controls and following Azure Identity Management best practice (link) is one of the best risk mitigation strategies that you can employ and should be considered mandatory for every deployment.

セキュリティSecurity

従来、クラウド導入の最大の障壁の 1 つは、セキュリティに対する懸念でした。One of the biggest blockers to cloud adoption traditionally has been concerns over security. IT リスク マネージャーとセキュリティ部門は、Azure 内のリソースのセキュリティが既定で保護されており安全であることを保証する必要があります。IT risk managers and security departments need to ensure that resources in Azure are protected and secure by default. Azure には、リソースを保護しながら、リソースに対する脅威を検出して排除するために使用できる機能があります。Azure provides capabilities you can use to protect resources while detecting and eliminating threats against those resources.

Azure Security CenterAzure Security Center

Azure Security Center は、環境全体のリソースのセキュリティ状態についての統一されたビューと、脅威に対する高度な保護を提供します。The Azure Security Center provides a unified view of the security status of resources across your environment in addition to advanced threat protection. Azure Security Center はオープン プラットフォームです。Microsoft のパートナーは、プラグインして機能を強化するソフトウェアを作成できます。Azure Security Center is an open platform that enables Microsoft partners to create software that plugs into and enhance its capabilities. Azure Security Center のベースライン機能 (Free レベル) によって、セキュリティの体制を強化する評価とレコメンデーションが提供されます。The baseline capabilities of Azure Security Center (free tier) provide assessment and recommendations that will enhance your security posture. 有料レベルでは、Just-In-Time 管理アクセスや適応型アプリケーション制御 (ホワイトリスト登録) など役に立つ機能が有効になります。Its paid tiers enable additional and valuable capabilities such as just-in-time admin access and adaptive application controls (whitelisting).

ヒント

Azure Security Center は強力なツールであり、絶えず改善されており、脅威の検出や企業の保護に使用できる新しい機能を取り入れています。Azure Security Center is a powerful tool that is regularly improved with new capabilities you can use to detect threats and protect your enterprise. Azure Security Center は常に有効化しておくことを強くお薦めします。It is highly recommended to always enable Azure Security Center.

Azure のリソース ロックAzure resource locks

組織がサブスクリプションにコア サービスを追加すると、ビジネスの中断を回避することがますます重要になります。As your organization adds core services to subscriptions, it becomes increasingly important to avoid business disruption. よく見られる中断の 1 つは、Azure サブスクリプションに対して実行されたスクリプトやツールの結果として、意図せずに誤ってリソースを削除した場合です。One type of disruption that we often see is unintended consequences of scripts and tools working against an Azure subscription deleting resources mistakenly. リソース ロックを使用すると、変更または削除したときに大きな影響を及ぼす価値の高いリソースに対する操作を制限できます。Resource Locks enable you to restrict operations on high-value resources where modifying or deleting them would have a significant impact. ロックは、サブスクリプションとリソース グループだけでなく、個々のリソースにも適用されます。Locks are applied to a subscription, resource group, or even individual resources. 一般的なユース ケースは、仮想ネットワーク、ゲートウェイ、ネットワーク セキュリティ グループ、キー ストレージ アカウントなど、基盤となるリソースにロックを適用することです。The common use case is to apply locks to foundational resources such as virtual networks, gateways, network security groups, and key storage accounts.

セキュアな DevOps ツールキットSecure DevOps Toolkit

Secure DevOps Kit for Azure (AzSK) は、スクリプト、ツール、拡張機能、オートメーションなどのコレクションです。元は Microsoft の IT チームによって作成され、GitHub でオープン ソースとしてリリースされています。The Secure DevOps Kit for Azure (AzSK) is a collection of scripts, tools, extensions, automations, etc. originally created by Microsoft's own IT team and released as open source via GitHub. AzSK はオートメーションを広範に使用し、セキュリティをネイティブの DevOps ワークフローに円滑に統合して、チームのためにあらゆる Azure サブスクリプションとリソース セキュリティのニーズに対応します。次に示す 6 つの重点分野で、セキュアな DevOps を実現するために役立ちます。AzSK caters to the end-to-end Azure subscription and resource security needs for teams using extensive automation and smoothly integrating security into native DevOps workflows helping accomplish secure DevOps with these six focus areas:

  • サブスクリプションの保護Secure the subscription
  • セキュアな開発の実現Enable secure development
  • セキュリティと CICD の統合Integrate security into CICD
  • 継続的な保証Continuous assurance
  • アラートと監視Alerting and monitoring
  • クラウドのリスク ガバナンスCloud risk governance

Azure DevOps ツールキット

AzSK は、Azure ガバナンス プラン全体の重要な部分を占めるツール、スクリプトおよび情報を豊富に含むセットです。これをスキャフォールディングに組み込むことは、組織のリスク管理目標を達成するために重要です。The AzSK is a rich set of tools, scripts, and information that are an important part of a full Azure governance plan and incorporating this into your scaffold is crucial to supporting your organizations risk management goals.

Azure Update ManagementAzure Update Management

環境の安全を保つためにできる重要なタスクの 1 つは、確実にサーバーに最新の更新プログラムが適用されるようにすることです。One of the key tasks you can do to keep your environment safe is ensure that your servers are patched with the latest updates. これを実現するツールは多数ありますが、Azure が提供する Azure Update Management ソリューションは、重要な OS パッチを識別してロールアウトします。While there are many tools to accomplish this, Azure provides the Azure Update Management solution to address the identification and rollout of critical OS patches. これは、このガイドの後半の「自動化」セクションで説明している Azure Automation を利用しています。It uses Azure Automation, covered in the Automate section later in this guide.

監視とアラートMonitor and alerts

テレメトリの収集と分析は、Azure サブスクリプションで使用しているサービスの、アクティビティ、パフォーマンス メトリック、正常性と可用性に関する見通しを得ることができ、アプリケーションとインフラストラクチャを積極的に管理するために不可欠です。また、すべての Azure サブスクリプションの根本的なニーズです。Collecting and analyzing telemetry that provides line of sight into the activities, performance metrics, health, and availability of the services you are using across your Azure subscriptions is critical to proactively manage your applications and infrastructure and is a foundational need of every Azure subscription. すべての Azure サービスは、テレメトリをアクティビティ ログ、メトリック、診断ログの形式で出力します。Every Azure service emits telemetry in the form of activity logs, metrics, and diagnostic logs.

  • アクティビティ ログには、サブスクリプションのリソースに対して実行されたすべての操作が示されています。Activity logs describe all operations performed on resources in your subscriptions.
  • メトリックは、リソースから生成される数値情報であり、リソースのパフォーマンスと正常性を示します。Metrics are numerical information emitted by a resource that describe the performance and health of a resource.
  • 診断ログは、Azure サービスから出力され、そのサービスの操作に関する豊富なデータを提供します。Diagnostic logs are emitted by an Azure service and provide rich, frequent data about the operation of that service.

これらの情報は複数のレベルで表示して対処することができ、常に改善されています。This information can be viewed and acted on at multiple levels and are continually being improved. Azure では、下の図に示すように Azure リソースの共有コア詳細の監視機能を提供しています。Azure provides shared, core, and deep monitoring capabilities of Azure resources through the services outlined in the diagram below. monitoringmonitoring

共有機能Shared capabilities

  • アラート: Azure リソースのすべてのログ、イベント、メトリックを収集できますが、重大な状態や動作を通知する機能はありません。このデータが役立つのは履歴管理の目的やフォレンジクスのためだけです。Alerts: You can collect every log, event, and metric from Azure resources, but without the ability to be notified of critical conditions and act, this data is only useful for historic purposes and forensics. Azure アラートは、すべてのアプリケーションとインフラストラクチャに対して定義した状態についてプロアクティブに通知します。Azure Alerts proactively notify you of conditions you define across all your applications and infrastructure. 一連の受信者に通知するために、ログ、イベント、メトリックに対して、アクション グループを使用するアラート ルールを作成します。You create alert rules across logs, events, and metrics that use action groups to notify sets of recipients. アクション グループでは、外部アクションを使用して、修復のオートメーションを行う機能も提供されます。たとえば、Webhook を使用して、Azure Automation Runbook や Azure Functions を実行します。Action groups also provide the ability to automate remediation using external actions such as webhooks to run Azure Automation runbooks and Azure Functions.

  • ダッシュボード: ダッシュボードでは、監視ビューを集計して、リソースとサブスクリプションに対するデータを組み合わせることができ、Azure リソースのテレメトリについて企業全体のビューを提供します。Dashboards: Dashboards enable you to aggregate monitoring views and combine data across resources and subscriptions to give you an enterprise-wide view into the telemetry of Azure resources. 独自のビューを作成して構成し、他のユーザーと共有することができます。You can create and configure your own views and share them with others. たとえば、さまざまなタイルを含むダッシュボードを作成して、Azure SQL DB、Azure DB for PostgreSQL、Azure DB for MySQL など、すべての Azure データベース サービスに関する情報を DBA が提供できるようにします。For example, you could create a dashboard consisting of various tiles for DBAs to provide information across all Azure database services, including Azure SQL DB, Azure DB for PostgreSQL and Azure DB for MySQL.

  • メトリックス エクスプローラー: メトリックは、Azure リソースによって生成される数値 (CPU 使用率やディスク I/O など) であり、これにより、リソースの操作やパフォーマンスを洞察できます。Metrics Explorer: Metrics are numerical values generated by Azure resources (such as % CPU or Disk I/O) that provide insight into the operation and performance of your resources. メトリックス エクスプローラーを使用すると、興味があるメトリックを定義し、Log Analytics に送信して集計および分析できます。Using Metrics Explorer, you can define and send the metrics that interest you to Log Analytics for aggregation and analysis.

コアな監視Core monitoring

  • Azure Monitor: Azure Monitor は、Azure リソースを 1 つのソースから監視できるコア プラットフォーム サービスです。Azure Monitor: Azure Monitor is the core platform service that provides a single source for monitoring Azure resources. Azure Monitor の Azure portal インターフェイスは、Application Insights、Log Analytics、ネットワーク監視、管理ソリューション、Service Map といった、詳細な監視機能を含め、Azure 全体のすべての監視機能が一元管理される出発点です。The Azure portal interface of Azure Monitor provides a centralized jump off point for all the monitoring features across Azure including the deep monitoring capabilities of Application Insights, Log Analytics, Network Monitoring, Management Solutions and Service Maps. Azure Monitor を使用すると、クラウド全体の Azure リソースのメトリックとログを視覚化、クエリ、ルーティング、アーカイブし、そのメトリックとログに対してアクションを実行できます。With Azure Monitor you can visualize, query, route, archive, and act on the metrics and logs coming from Azure resources across your entire cloud estate. ポータルに加え、Monitor PowerShell コマンドレット、クロス プラットフォーム CLI、または Azure Monitor REST API でデータを取得できます。In addition to the portal you can retrieve data through the Monitor PowerShell Cmdlets, Cross Platform CLI, or the Azure Monitor REST APIs.

  • Azure Advisor: Azure Advisor では、サブスクリプションと環境全体のテレメトリを常に監視します。また、Azure リソースを最適化して費用を節約し、アプリケーションを構成するリソースのパフォーマンス、セキュリティ、および可用性を向上させる方法のベスト プラクティスに関する推奨を行います。Azure Advisor: Azure Advisor constantly monitors telemetry across your subscriptions and environments and provides recommendations on best practices on how to optimize your Azure resources to save money and improve performance, security, and availability of the resources that make up your applications.

  • サービス正常性: Azure Service Health では、アプリケーションに影響を及ぼす可能性がある Azure サービスの問題を特定します。これは、予定メンテナンス期間を計画する際に役立ちます。Service Health: Azure Service Health identifies any issues with Azure Services that may affect your applications as well as assists you in planning for scheduled maintenance windows.

  • アクティビティ ログ: アクティビティ ログには、サブスクリプションのリソースに対するすべての操作が示されています。Activity log: The activity log describes all operations on resources in your subscriptions. 提供される監査証跡によって、リソースに対する作成、更新、削除の各操作について "何を"、"だれが"、"いつ" を判別できます。It provides an audit trail to determine the 'what', 'who', and 'when' of any create, update, delete operation on resources. アクティビティ ログ イベントがプラットフォームに保存され、クエリで使用できる期間は 90 日です。Activity log events are stored in the platform and are available to query for 90 days. アクティビティ ログを Log Analytics に取り込むと、長期間保存することができ、複数のリソースに対して詳細なクエリと分析を行うことができます。You can ingest activity logs into Log Analytics for longer retention periods and deeper querying and analysis across multiple resources.

詳細なアプリケーション監視Deep application monitoring

  • Application Insights: Application Insights では、アプリケーション固有のテレメトリを収集し、クラウドまたはオンプレミス内のアプリケーションのパフォーマンス、可用性、使用状況を監視できます。Application Insights: Application Insights enables you to collect application-specific telemetry and monitor the performance, availability, and usage of applications in the cloud or on-premises. .NET、JavaScript、JAVA、Node.js、Ruby、Python など、サポートされる複数の言語用の SDK を使用してアプリケーションをインストルメント化します。By instrumenting your application with supported SDKs for multiple languages including .NET, JavaScript, JAVA, Node.js, Ruby, and Python. Application Insights イベントが、インフラストラクチャとセキュリティ監視をサポートする同じ Log Analytics データ ストアに取り込まれると、高機能のクエリ言語を使用し、長期にわたってイベントを相互に関連付けて集計できます。Application Insights events are ingested into the same Log Analytics data store that supports infrastructure and security monitoring to enable you to correlate and aggregate events over time through a rich query language.

詳細なインフラストラクチャ監視Deep infrastructure monitoring

  • Log Analytics: Log Analytics は、Azure の監視において中心的役割を果たします。たとえば、さまざまなソースからテレメトリなどのデータを収集します。また、アプリケーションやリソースの運用を洞察するためのクエリ言語や分析エンジンを提供します。Log Analytics: Log Analytics plays a central role in Azure monitoring by collecting telemetry and other data from a variety of sources and providing a query language and analytics engine that gives you insights into the operation of your applications and resources. Log Analytics のデータは、きわめて高性能のログ検索やビューを通じて直接、対話操作することができるほか、Log Analytics にデータを格納する他の Azure サービス (Application Insights、Azure Security Center など) の分析ツールを使用することもできます。You can either interact directly with Log Analytics data through highly performant log searches and views, or you may use analysis tools in other Azure services that store their data in Log Analytics such as Application Insights or Azure Security Center.

  • ネットワーク監視: Azure のネットワーク監視サービスでは、ネットワーク トラフィック フロー、パフォーマンス、セキュリティ、接続性、ボトルネックについて洞察することができます。Network monitoring: Azure's network monitoring services enable you to gain insight into network traffic flow, performance, security, connectivity, and bottlenecks. よく計画されたネットワーク設計には、Network Watcher や ExpressRoute Monitor など、Azure ネットワーク監視サービスの構成を含める必要があります。A well-planned network design should include configuring Azure network monitoring services such as Network Watcher and ExpressRoute Monitor.

  • 管理ソリューション: 管理ソリューションは、アプリケーションまたはサービスのための、ロジック、分析情報、および事前定義済み Log Analytics クエリのセットがパッケージ化されたものです。Management solutions: Management solutions are packaged sets of logic, insights, and predefined Log Analytics queries for an application or service. これらは Log Analytics を基盤として使用し、イベント データを格納および分析します。They rely on Log Analytics as the foundation to store and analyze event data. サンプルの管理ソリューションには、コンテナー監視と Azure SQL Database 分析が含まれます。Sample management solutions include monitoring containers and Azure SQL Database analytics.

  • Service Map: Service Map では、インフラストラクチャ コンポーネント、そのプロセス、および他のコンピューターや外部プロセスへの相互依存関係に関するグラフィカル ビューが提供されます。Service Map: Service Map provides a graphical view into your infrastructure components, their processes, and interdependencies on other computers and external processes. これにより、Log Analytics 内のイベント、パフォーマンス データ、管理ソリューションが統合されます。It integrates events, performance data, and management solutions in Log Analytics.

ヒント

個々のアラートを作成する前に、Azure Alerts 全体で使用される共有アクション グループのセットを作成して管理します。Before creating individual alerts, create and maintain a set of shared Action Groups that can be used across Azure Alerts. これによって、受信者リスト、通知配信方法 (電子メール、SMS 電話番号)、および外部アクションに対する Webhooks (Azure Automation Runbook、Azure Functions / Logic Apps、ITSM) のライフサイクルを一元的に管理できるようになります。This will enable you to centrally maintain the lifecycle of your recipient lists, notification delivery methods (email, SMS phone numbers) and webhooks to external actions (Azure Automation runbooks, Azure Functions / Logic Apps, ITSM).

コスト管理Cost management

オンプレミス クラウドからパブリック クラウドに移るときに直面する大きな変化の 1 つは、設備投資 (ハードウェアの購入) から営業経費 (使用するサービスの支払) への切り替えです。One of the major changes that you will face when you move from on-premises cloud to the public cloud is the switch from capital expenditure (buying hardware) to operating expenditure (paying for service as you use it). この切り替えには、より慎重なコスト管理も必要です。This switch also requires more careful management of your costs. クラウドのメリットは、不要になったときにシャットダウンするかサイズを変更するだけで、使用するサービスのコストに根本的かつ肯定的な影響を与えられることです。The benefit of the cloud is that you can fundamentally and positively affect the cost of a service you use by merely shutting down or resizing it when it's not needed. 意図的にクラウドにおいてコストを管理することは、推奨されるプラクティスであり、熟練した顧客は日常的に行っています。Deliberately managing your costs in the cloud is a recommended practice and one that mature customers do daily.

コストの視覚化、追跡、および管理を行うためのいくつかのツールが提供されます。Microsoft provides several tools for you to be able to visualize, track, and manage your costs. また、コスト管理を独自のツールとダッシュボードにカスタマイズして統合できるように API の完全なセットも提供されます。We also provide a full set of APIs to enable you to customize and integrate cost management into your own tools and dashboards. これらのツールは Azure portal の機能と外部機能に大まかに分けることができます。These tools are loosely grouped into Azure portal capabilities and external capabilities.

Azure portal の機能Azure portal capabilities

これらは、コストに関する即時性のある情報と、アクションを実行する機能を提供するツールです。These are tools to provide you instant information on cost as well as the ability to take actions.

  • サブスクリプション リソース コスト: ポータルにある Azure コスト分析ビューでは、コストをひとめで確認でき、リソースまたはリソース グループごとの毎日の支出に関する情報を得ることができます。Subscription resource cost: Located in the portal, the Azure Cost Analysis view provides a quick look at your costs and information on daily spend by resource or resource group.
  • Azure Cost Management: この製品は、Microsoft が Cloudyn を買収したことにより生まれました。Azure の支出額および他のパブリック クラウド プロバイダーでの支出を管理および分析することができます。Azure Cost Management: This product is the result of the purchase of Cloudyn by Microsoft and allows you to manage and analyze your Azure spending as well as what you spend on other public cloud providers. Free レベルと有料レベルの両方があり、概要で説明しているように豊富な機能があります。There are both free and paid tiers, with a great wealth of capabilities as seen in the overview.
  • Azure Budgets とアクション グループ: 何にコストがかかるか、それについて何をすべきかを把握するのは、最近まではほぼ手動で行っていました。Azure budgets and action groups: Knowing what something costs and doing something about it until recently has been more of a manual exercise. Azure Budgets とその API が導入されたことにより、コストがしきい値に達したときにアクションを作成できるようになりました (この例を参照してください)。With the introduction of Azure Budgets and its APIs, it's now possible to create actions (as seen in this example) when costs hit a threshold. たとえば、"test" リソース グループが予算の 100% に到達したときにシャットダウン、または [もう 1 つの例]。For example, shutting down a "test" resource group when it hits 100% of its budget, or [another example].
  • Azure Advisor: 何にコストがかかるかを把握しても、戦いは半分しか終わっていません。もう半分は、その情報に対してどうすべきかを把握することです。Azure Advisor Knowing what something costs is only half the battle; the other half is knowing what to do with that information. Azure Advisor では、費用の節約、信頼性の向上、さらにはセキュリティの向上のための処置についてレコメンデーションが提供されます。Azure Advisor provides you recommendations on actions to take to save money, improve reliability or even increase security.

外部のコスト管理ツールExternal cost management tools

  • Power BI Azure Consumption Insights: 組織のために独自の視覚エフェクトを作成しますか。Power BI Azure Consumption Insights: Do you want to create your own visualizations for your organization? その場合は、Power BI 用の Azure Consumption Insights コンテンツ パックをツールとして選択してください。If so, then the Azure Consumption Insights content pack for Power BI is your tool of choice. このコンテンツ パックと Power BI を使用すると、組織を表すためにカスタムの視覚エフェクトを作成し、コストについて詳しい分析を実行し、さらに充実させるために他のデータ ソースを追加することもできます。Using this content pack and Power BI you can create custom visualizations to represent your organization, do deeper analysis on costs and add in other data sources for further enrichment.

  • Consumption API:Consumption API を使用すると、コストと使用状況のデータに加え、予算、予約インスタンス、Marketplace 請求料金に関する情報にもプログラミングでアクセスできます。Consumption API: The consumption APIs give you programmatic access to cost and usage data in addition to information on budgets, reserved instances, and marketplace charges. これらの API にアクセスできるのは、エンタープライズ加入契約と一部の Web Direct サブスクリプションのみです。ただし、これらにより、コスト データを独自のツールとデータ ウェアハウスに統合することができるようになります。These APIs are accessible only for Enterprise Enrollments and some Web Direct subscriptions however they give you the ability to integrate your cost data into your own tools and data warehouses. また、Azure CLI を使用してこれらの API にアクセスすることもできます。You can also access these APIs via the Azure CLI.

長期の成熟したクラウド ユーザーであるお客様の場合は、以下の方法を実行することが強く推奨されます。Customers who are long-term and mature cloud users follow some highly recommended practices:

  • コストを積極的に監視します。Actively monitor costs. 熟達した Azure ユーザーである組織は、絶えずコストを監視して、必要に応じて対処しています。Organizations that are mature Azure users constantly monitor costs and take actions when needed. 組織によっては、分析を実行して使用方法の変更を提案するために専任の担当者を置くところもあります。このような担当者は、数か月間稼働しているのに未使用の HDInsight クラスターを見つけたときに初めて、採算以上の働きをしたことになります。Some organizations even dedicate people to do analysis and suggest changes to usage, and these people more than pay for themselves the first time they find an unused HDInsight cluster that's been running for months.
  • 予約 VM インスタンスを使用します。Use Reserved VM Instances. クラウドにおいてコストを管理するもう 1 つの重要な理念は、ジョブに対して正しいツールを使用することです。Another key tenet for managing costs in the cloud is to use the right tool for the job. 年中無休で維持する必要がある IaaS VM がある場合は、予約 VM インスタンスを使用すると大幅にコストを節約できます。If you have an IaaS VM that must stay on 24x7, then using a Reserved VM Instance will save you significant money. VM のシャットダウンのオートメーションと予約 VM インスタンスの使用の間で適切なバランスを見つけるには、経験と分析が必要です。Finding the right balance between automating the shutdown of VMs and using Reserved VM Instances takes experience and analysis.
  • オートメーションを効果的に使用します。Use automation effectively. 多くのワークロードは毎日実行する必要はありません。Many workloads don't need to run every day. 毎日 4 時間ずつ VM をオフにすると、コストの 15% を節約できます。Turning off a VM for a four-hour period every day can save you 15% of your cost. オートメーションはすぐに効果が得られます。Automation will pay for itself quickly.
  • わかりやすくするためにリソース タグを使用します。Use resource tags for visibility. このドキュメントの別の場所でも説明していますが、リソース タグを使用するとコストを詳しく分析できます。As mentioned elsewhere in this document, using resource tags will allow for better analysis of costs.

コスト管理は、パブリック クラウドを効果的かつ効率的に実行するために重要な原則です。Cost management is a discipline that is core to the effective and efficient running of a public cloud. 成功を収める企業は、過剰に購入して需要が発生することを望むのではなく、コストを管理し、コストを実際の需要に合わせることができます。Enterprises that achieve success can control their costs and match them to their actual demand, rather than overbuying and hoping demand comes.

自動化Automate

クラウド プロバイダーを使用する組織の熟練度を区別する能力がいくつもありますが、その 1 つは、組み込んでいるオートメーションのレベルです。One of the many capabilities that differentiates the maturity of organizations using cloud providers is the level of automation that they have incorporated. オートメーションは決して終わらないプロセスです。組織がクラウドに移行するとき、この部分にこそ、構築のためにリソースと時間を投資する必要があります。Automation is a never-ending process and as your organization moves to the cloud it is any area that you need to invest resources and time in building. リソースの一貫したロールアウト (スキャフォールディングのもう 1 つの主要概念であるテンプレートと DevOps に直接関連している場合) から、問題の修復まで、オートメーションには多くの目的があります。Automation serves many purposes including consistent rollout of resources (where it ties directly to another core scaffold concept, templates and DevOps) to the remediation of issues. オートメーションは、Azure スキャフォールディングの "結合組織" であり、各部分を結び付けます。Automation is the "connective tissue" of the Azure scaffold and links each area together.

Azure Automation、Event Grid、Azure CLI といった Microsoft 製ツールから、Terraform、Jenkins、Chef、Puppet などの多数のサード パーティ製ツールまで、この機能を構築するときに役立つツールがいくつかあります。Several tools can help you build out this capability, from first-party tools such as Azure Automation, Event Grid, and the Azure CLI, to an extensive number of third-party tools such as Terraform, Jenkins, Chef, and Puppet. コア オートメーション ツールには、Azure Automation、Event Grid、Azure Cloud Shell などがあります。Core automation tools include Azure Automation, Event Grid, and the Azure Cloud Shell.

  • Azure Automation はクラウドベースの機能です。これを使用して、(PowerShell または Python で) Runbook を作成し、プロセスのオートメーション、リソースの構成、さらにパッチの適用も実行することができます。Azure Automation Is a cloud-based capability that allows you to author runbooks (in either PowerShell or Python) and allows you automate processes, configure resources, and even apply patches. Azure Automation には、デプロイに不可欠な広範なクロス プラットフォーム機能のセットが含まれますが、範囲が広すぎるためここで詳しく説明することはできません。Azure Automation has an extensive set of cross platform capabilities that are integral to your deployment but are too extensive to be covered in depth here.
  • Event Grid は、Azure 環境内のイベントに対応することができるフル マネージドのイベント ルーティング システムです。Event Grid is a fully managed event routing system that allows you to react to events within your Azure environment. Azure Automation が成熟したクラウド編成の結合組織であるのと同様に、Event Grid は優れたオートメーションの結合組織です。Just as Azure Automation is the connective tissue of mature cloud organizations, Event Grid is the connective tissue of good automation. Event Grid を使用すると、新しいリソースが作成されるたびに管理者に電子メールを送信して、そのリソースをデータベースに記録する、単純なサーバーレス アクションを作成できます。Using Event Grid, you can create a simple serverless action to send an email to an administrator whenever a new resource is created and log that resource to a database. その同じ Event Grid が、リソースが削除されたときに通知し、アイテムをデータベースから削除することができます。That same Event Grid can notify when a resource is deleted and remove the item from the database.
  • Azure Cloud Shell は、Azure でリソースを管理するための、ブラウザーベースのインタラクティブなシェルです。Azure Cloud Shell is an interactive, browser-based shell for managing resources in Azure. これは、PowerShell または Bash に最適な環境を提供します。必要に応じて起動 (および管理) されるため、スクリプトを実行するために一貫性のある環境を得ることができます。It provides a complete environment for either PowerShell or Bash that is launched as needed (and maintained for you) so that you have a consistent environment from which to run your scripts. Azure Cloud Shell では、環境のオートメーションを行うために、既にインストールされている他の重要なツールにアクセスできます。Azure CLITerraform の他にも、コンテナー、データベース (sqlcmd) などを管理するためのツールがますます増加しています。The Azure Cloud Shell provides access to additional key tools -already installed-- to automate your environment including Azure CLI, Terraform and a growing list of additional tools to manage containers, databases (sqlcmd), and more.

オートメーションはフルタイム ジョブであり、またたく間にクラウド チームにおける最も重要な運用タスクの 1 つになろうとしています。Automation is a full-time job, and it will rapidly become one of the most important operational tasks within your cloud team. "オートメーション ファースト" のアプローチを採用する組織は、 Azure を使用して大きな成功を収めます。Organizations that take the approach of "automate first" have greater success in using Azure:

  • コストの管理: 積極的に機会を探し、リソースのサイズ変更、スケールアップ/スケールダウン、未使用リソースのオフを実行するオートメーションを作成します。Managing costs: Actively seeking opportunities and creating automation to resize resources, scale up or down, and turn off unused resources.
  • 運用の柔軟性: オートメーションを (テンプレートと DevOps と組み合わせて) 使用し、一定レベルの再現性を得ることで、可用性の向上やセキュリティの強化につながり、チームがビジネスの問題解決に集中できるようになります。Operational flexibility: With automation (along with templates and DevOps), you gain a level of repeatability that increases availability, increases security, and enables your team to focus on solving business problems.

テンプレートと DevOpsTemplates and DevOps

「自動化」のセクションで強調したように、組織の目標は、ソース管理されたテンプレートとスクリプトを介してリソースをプロビジョニングすること、さらに対話型での環境の構成を最小限にすることです。As highlighted in the Automate section, your goal as an organization should be to provision resources through source-controlled templates and scripts and to minimize interactive configuration of your environments. 継続的なデプロイのための制御された DevOps プロセスと "infrastructure as code" アプローチを組み合わせると、一貫性を保証することができ、環境内での誤差を減らすことができます。This approach of "infrastructure as code" along with a disciplined DevOps process for continuous deployment can ensure consistency and reduce drift across your environments. ほぼすべての Azure リソースは、Azure Resource Manager JSON テンプレートを PowerShell または Azure クロス プラットフォーム CLI と、Hashicorp の Terraform (最上のサポートがあり、Azure Cloud Shell に統合される) などのツールと組み合わせてデプロイできます。Almost every Azure resource is deployable through Azure Resource Manager JSON templates in conjunction with PowerShell or the Azure cross platform CLI and tools such as Terraform from Hashicorp (which has first class support and integrated into the Azure Cloud Shell).

Azure Resource Manager テンプレートを使用する場合のベスト プラクティスなどの記事では、Azure DevOps ツール チェーンを含む Azure Resource Manager テンプレートに DevOps アプローチを適用する場合について、ベスト プラクティスや実例から学んだ内容を説明しています。Article such as Best practices for using Azure Resource Manager templates provide an excellent discussion of best practices and lessons learned for applying a DevOps approach to Azure Resource Manager templates with the Azure DevOps toolchain. 特に運用環境と QA 環境に関しては、時間と労力を費やして、組織の要件に合うテンプレートのコア セットを開発し、DevOps ツール チェーン (Azure DevOps、Jenkins、Bamboo、TeamCity、Concourse など) を使用して継続的デリバリー パイプラインを開発してください。Take the time and effort to develop a core set of templates specific to your organization's requirements, and to develop continuous delivery pipelines with DevOps toolchains (such as Azure DevOps, Jenkins, Bamboo, TeamCity, and Concourse), especially for your production and QA environments. Azure クイック スタート テンプレートの大規模なライブラリが GitHub 上にあり、テンプレートの作成を開始するときに役立ちます。また、Azure DevOps を使用するとクラウドベースの配信パイプラインを迅速に作成できます。There is a large library of Azure Quickstart templates on GitHub that you can use as a starting point for templates, and you can quickly create cloud-based delivery pipelines with Azure DevOps.

運用サブスクリプションまたはリソース グループのベスト プラクティスとしては、RBAC セキュリティを使用して既定で対話型ユーザーを禁止することと、サービス プリンシパルに基づいて自動化された継続的デリバリー パイプラインを使用して、すべてのリソースをプロビジョニングし、すべてのアプリケーション コードを配信することが目標です。As a best practice for production subscriptions or resource groups, your goal should be using RBAC security to disallow interactive users by default and using automated continuous delivery pipelines based on service principals to provision all resources and deliver all application code. 管理者も開発者も Azure portal を使用してリソースを対話形式で構成する必要はありません。No admin or developer should touch the Azure portal to interactively configure resources. このレベルの DevOps では協調が求められますが、Azure スキャフォールディングのすべての概念を使用して、組織の拡大縮小のニーズを満たす、一貫性を備えたセキュアな環境を提供します。This level of DevOps takes a concerted effort and uses all the concepts of the Azure scaffold, providing a consistent and more secure environment that will meet your organization's need to scale.

ヒント

複雑な Azure Resource Manager テンプレートを設計および開発するときは、リンクされたテンプレートを使用して、モノリシック JSON ファイルから複雑なリソースの関係を編成してリファクタリングします。When designing and developing complex Azure Resource Manager templates, use linked templates to organize and refactor complex resource relationships from monolithic JSON files. これにより、リソースを個別に管理できるようになり、テンプレートの内容がわかりやすくなり、テストや再利用を行いやすくなります。This will enable you to manage resources individually and make your templates more readable, testable, and reusable.

Azure は、ハイパースケール クラウド プロバイダーです。Azure is a hyperscale cloud provider. 組織がオンプレミス サーバーからクラウドに移るときに、クラウド プロバイダーと SaaS アプリケーションが使用するのと同じ概念を利用することで、組織がビジネスのニーズに対応する効率の大幅な向上に役立ちます。As you move your organization from on-premises servers to the cloud, relying on the same concepts that cloud providers and SaaS applications use will help your organization react to the needs of the business much more efficiently.

コア ネットワークCore network

Azure スキャフォールディング参照モデルの最後のコンポーネントは、組織がどうやって安全に Azure にアクセスするかという点で重要です。The final component of the Azure scaffold reference model is core to how your organization accesses Azure, in a secure manner. リソースへのアクセスは内部 (企業のネットワーク内) の場合もあれば、外部 (インターネット経由) の場合もあります。Access to resources can be either internal (within the corporation's network) or external (through the internet). 組織のユーザーは誤って不適切な場所にリソースを配置しがちであり、リソースが悪意のあるアクセスにさらされる可能性があります。It is easy for users in your organization to inadvertently put resources in the wrong spot, and potentially open them to malicious access. オンプレミスのデバイスと同様に、企業は Azure ユーザーが正しく判断できるように適切な制御を追加する必要があります。As with on-premises devices, enterprises must add appropriate controls to ensure that Azure users make the right decisions. Microsoft では、サブスクリプション ガバナンスのために、基本的なアクセス制御を提供するコア リソースを特定しました。For subscription governance, we identify core resources that provide basic control of access. コア リソースは以下で構成されます。The core resources consist of:

  • 仮想ネットワークは、サブネットのコンテナー オブジェクトです。Virtual networks are container objects for subnets. 必須ではありませんが、多くの場合、アプリケーションを内部の企業リソースに接続するときに使用されます。Though not strictly necessary, it is often used when connecting applications to internal corporate resources.
  • ユーザー定義ルートを使用すると、サブネット内のルート テーブルを操作して、ネットワーク仮想アプライアンス経由でのトラフィックの送信、またはピアリングした仮想ネットワーク上のリモート ゲートウェイへのトラフィックの送信を行うことができます。User-defined routes allow you to manipulate the route table within a subnet enabling you to send traffic through a network virtual appliance or to a remote gateway on a peered virtual network.
  • 仮想ネットワーク ピアリングでは、2 つ以上の Azure 仮想ネットワークをシームレスに接続し、より複雑なハブとスポークの設計または共有サービス ネットワークを作成できます。Virtual network peering enables you to seamlessly connect two or more Azure virtual networks, creating more complex hub and spoke designs or shared services networks.
  • サービス エンドポイント。Service endpoints. かつて、PaaS サービスはさまざまな方法に依存して、仮想ネットワークからそれらのリソースへのアクセスを保護していました。In the past, PaaS services relied on different methods to secure access to those resources from your virtual networks. サービス エンドポイントを使用すると、接続したエンドポイントのみからの有効な PaaS サービスに対するアクセスを保護することができ、全体のセキュリティが向上します。Service endpoints allow you to secure access to enabled PaaS services from only connected endpoints, increasing overall security.
  • セキュリティ グループは広範な規則のセットであり、これを使用すると、Azure リソースに対するインバウンドおよびアウトバウンド トラフィックを許可または拒否できるようになります。Security groups are an extensive set of rules that provide the ability to allow or deny inbound and outbound traffic to/from Azure resources. セキュリティ グループは、サービス タグ (Azure Key Vault、Azure SQL Database など一般的な Azure サービスを定義) とアプリケーション セキュリティ グループ (Web サーバーやアプリ サーバーなどのアプリケーション構造を定義) を使用して拡張できるセキュリティ規則で構成されます。Security groups consist of security rules that can be augmented with service tags (which define common Azure services such as Azure Key Vault or Azure SQL Database) and application security groups (which define and application structure, such as web servers or app servers).

ヒント

サービス タグとアプリケーション セキュリティ グループをネットワーク セキュリティ グループで使用すると、規則がわかりやすくなるだけではありません —(これは影響を理解するために重要です)—。大きめのサブネット内で極小のセグメント化を効果的に行うことができ、対象が不要に広がらないようにし、柔軟性が高まります。Use service tags and application security groups in your network security groups to not only enhance the readability of your rules—which is crucial to understanding impact—but also to enable effective microsegmentation within a larger subnet, reducing sprawl and increasing flexibility.

Azure 仮想データセンターAzure Virtual Datacenter

Azure では、内部機能だけでなく、充実したパートナー ネットワークからサード パーティ機能も提供され、効果的にセキュリティ体制を整えることができます。Azure provides you both internal capabilities and third-party capabilities from our extensive partner network that enable you to have an effective security stance. さらに重要なのは、Azure 仮想データセンター (VDC) という形で、ベスト プラクティスとガイダンスが提供されることです。More importantly, Microsoft provides best practices and guidance in the form of the Azure Virtual Datacenter (VDC). 1 つのワークロードからハイブリッド機能を使用する複数のワークロードに移るとき、VDC ガイダンスから、Azure 内のワークロードが増大するにつれ拡張する柔軟性の高いネットワークを実現する "レシピ" が提供されます。As you move from a single workload to multiple workloads that use hybrid capabilities, the VDC guidance will provide you with "recipes" to enable a flexible, network that will grow as your workloads in Azure grow.

次の手順Next steps

ガバナンスは Azure の成功に不可欠です。Governance is crucial to the success of Azure. この記事は、エンタープライズ スキャフォールディングの技術的な実装を対象としていますが、広範なプロセスとコンポーネント間の関係だけを取り上げています。This article targets the technical implementation of an enterprise scaffold but only touches on the broader process and relationships between the components. ポリシー ガバナンスのフローはトップダウンであり、その企業が目指していることによって決まります。Policy governance flows from the top down and is determined by what the business wants to achieve. 当然ながら、Azure のガバナンス モデルの作成には IT 部門の担当者が参加しますが、さらに重要なことは、ビジネス グループのリーダーの有力な代表者とセキュリティおよびリスク管理部門も参加することです。Naturally, the creation of a governance model for Azure includes representatives from IT, but more importantly it should have strong representation from business group leaders, and security and risk management. 要するに、エンタープライズ スキャフォールディングとは、ビジネス リスクを軽減して組織の任務や目的を推進することです。In the end, an enterprise scaffold is about mitigating business risk to facilitate an organization's mission and objectives.

ここでは、サブスクリプション ガバナンスについて説明しました。次に、これらの推奨事項を実際に確認してください。Now that you have learned about subscription governance, it's time to see these recommendations in practice. Azure サブスクリプション ガバナンスの実装例をご覧ください。See Examples of implementing Azure subscription governance.