Enterprise Agreement 加入契約と Azure Active Directory テナントEnterprise Agreement enrollment and Azure Active Directory tenants

エンタープライズ登録の計画Plan for enterprise enrollment

Enterprise Agreement (EA) 加入契約は、Microsoft と、お客様の組織が Azure を使用する方法との取引関係を表しています。An Enterprise Agreement (EA) enrollment represents the commercial relationship between Microsoft and how your organization uses Azure. これは、お客様のすべてのサブスクリプションにわたる請求の基礎となり、お客様のデジタル資産の管理に影響を及ぼします。It provides the basis for billing across all your subscriptions and affects administration of your digital estate. EA 加入契約は、Azure エンタープライズ ポータルを使用して管理されます。Your EA enrollment is managed via an Azure enterprise portal. 多くの場合、加入契約は組織の階層を表します。これには、部門、アカウント、サブスクリプションなどが含まれます。An enrollment often represents an organization's hierarchy, which includes departments, accounts, and subscriptions. この階層は、組織内のコスト登録グループを表します。This hierarchy represents cost-enrollment groups within an organization.

Azure EA 階層を示す図。

"図 1:Azure EA 加入契約の階層Figure 1: An Azure EA enrollment hierarchy.

  • 部門は、コストを論理グループに分割してから、部門レベルで予算またはクォータを設定するのに役立ちます。Departments help to segment costs into logical groupings and to set a budget or quota at the department level. クォータは強制的には適用されず、レポート目的で使用されます。The quota isn't enforced firmly and is used for reporting purposes.
  • アカウントは、Azure エンタープライズ ポータルでの組織単位です。Accounts are organizational units in the Azure enterprise portal. それらは、サブスクリプションを管理し、レポートにアクセスするために使用できます。They can be used to manage subscriptions and access reports.
  • サブスクリプションは、Azure エンタープライズ ポータルの最小単位です。Subscriptions are the smallest unit in the Azure enterprise portal. これらは、サービス管理者によって管理される Azure サービスのコンテナーです。They're containers for Azure services managed by the service administrator. これらは、組織が Azure サービスがデプロイする場所です。They're where your organization deploys Azure services.
  • EA 加入契約のロールによって、ユーザーは職務的なロールに結び付けられます。EA enrollment roles link users with their functional role. これらのロールは次のとおりです。These roles are:
    • エンタープライズ管理者Enterprise administrator
    • 部門管理者Department administrator
    • アカウント所有者Account owner
    • サービス管理者Service administrator
    • 通知の連絡先Notification contact

設計上の考慮事項:Design considerations:

  • 加入契約には、サブスクリプションの管理を統制する階層型の組織構造があります。The enrollment provides a hierarchical organizational structure to govern the management of subscriptions.
  • 複数の環境を EA アカウント レベルで分離して、包括的な分離をサポートできます。Multiple environments can be separated at an EA-account level to support holistic isolation.
  • 1 つの登録に複数の管理者を任命することができます。There can be multiple administrators appointed to a single enrollment.
  • 各サブスクリプションには、関連付けられたアカウント所有者が必要です。Each subscription must have an associated account owner.
  • 各アカウント所有者は、そのアカウントでプロビジョニングされたサブスクリプションのサブスクリプション所有者になります。Each account owner will be made a subscription owner for any subscriptions provisioned under that account.
  • サブスクリプションは、常に 1 つのアカウントにのみ属することができます。A subscription can belong to only one account at any given time.
  • サブスクリプションは、所定の一連の条件に基づいて一時停止される場合があります。A subscription can be suspended based on a specified set of criteria.

設計上の推奨事項:Design recommendations:

  • すべてのアカウントの種類に認証の種類 Work or school account のみを使用します。Only use the authentication type Work or school account for all account types. Microsoft account (MSA) のアカウントの種類は使用しないでください。Avoid using the Microsoft account (MSA) account type.
  • 通知が適切なグループ メール ボックスに送信されるように、通知の連絡先メール アドレスを設定します。Set up the notification contact email address to ensure notifications are sent to an appropriate group mailbox.
  • 各アカウントに予算を割り当て、予算に関連するアラートを設定します。Assign a budget for each account, and establish an alert associated with the budget.
  • 組織は、職務、部門、地理、マトリックス、チーム構造など、さまざまな構造を持つことがあります。An organization can have a variety of structures, such as functional, divisional, geographic, matrix, or team structure. 組織構造を使用して、組織の構造を加入契約の階層にマップします。Use organizational structure to map your organization structure to your enrollment hierarchy.
  • 事業領域に独立した IT 機能がある場合は、IT の新しい部門を作成します。Create a new department for IT if business domains have independent IT capabilities.
  • サブスクリプションおよび関連する Azure リソースに対する管理者アクセスの急増を防ぐために、登録内のアカウント所有者数を制限し、最小限に抑えます。Restrict and minimize the number of account owners within the enrollment to avoid the proliferation of admin access to subscriptions and associated Azure resources.
  • 複数の Azure Active Directory (Azure AD) テナントが使用されている場合は、アカウント所有者が、アカウントのサブスクリプションがプロビジョニングされているものと同じテナントに関連付けられていることを確認します。If multiple Azure Active Directory (Azure AD) tenants are used, verify that the account owner is associated with the same tenant as where subscriptions for the account are provisioned.
  • 包括的な分離をサポートするために、EA アカウント レベルで Enterprise Dev/Test および運用環境を設定します。Set up Enterprise Dev/Test and production environments at an EA account level to support holistic isolation.
  • 通知アカウントのメール アドレスに送信された通知メールは無視しないでください。Don't ignore notification emails sent to the notification account email address. Microsoft は、EA 全体にわたる重要な連絡をこのアカウントに送信します。Microsoft sends important EA-wide communications to this account.
  • Azure AD で EA アカウントの移動または名前変更を行わないでください。Don't move or rename an EA account in Azure AD.
  • EA ポータルを定期的に監査し、アクセスできるユーザーを確認し、可能な限り Microsoft アカウントを使用しないようにします。Periodically audit the EA portal to review who has access and avoid using a Microsoft account where possible.

Azure AD テナントを定義するDefine Azure AD tenants

Azure AD テナントによって ID とアクセス管理が提供されます。これはセキュリティ態勢の重要な部分です。An Azure AD tenant provides identity and access management, which is an important part of your security posture. Azure AD テナントは、認証および許可されたユーザーが、自身がアクセス許可を持つリソースのみにアクセスできるようにするものです。An Azure AD tenant ensures that authenticated and authorized users have access to only the resources for which they have access permissions. Azure AD からは、Azure にデプロイされたアプリケーションやサービスだけでなく、Azure の外部にデプロイされたサービスやアプリケーション (オンプレミスやサードパーティのクラウド プロバイダーなど) にもこれらのサービスが提供されます。Azure AD provides these services to applications and services deployed in Azure and also to services and applications deployed outside of Azure (such as on-premises or third-party cloud providers).

Azure AD は、Microsoft 365 や Azure Marketplace などの、サービスとしてのソフトウェア アプリケーションでも使用されます。Azure AD is also used by software as a service applications such as Microsoft 365 and Azure Marketplace. オンプレミスの Active Directory を既に使用している組織では、既存のインフラストラクチャを使用し、Azure AD と統合することで認証をクラウドに拡張できます。Organizations already using on-premises Active Directory can use their existing infrastructure and extend authentication to the cloud by integrating with Azure AD. 各 Azure AD ディレクトリには 1 つ以上のドメインがあります。Each Azure AD directory has one or more domains. ディレクトリには複数のサブスクリプションを関連付けることができますが、Azure AD テナントは 1 つだけです。A directory can have many subscriptions associated with it but only one Azure AD tenant.

組織で資格情報を管理する方法、人、アプリケーション、プログラムによるアクセスを制御する方法などの基本的なセキュリティの質問は、Azure AD の設計フェーズで行います。Ask basic security questions during the Azure AD design phase, such as how your organization manages credentials and how it controls human, application, and programmatic access.

設計上の考慮事項:Design considerations:

  • 1 つの加入契約で複数の Azure AD テナントを機能させることができます。Multiple Azure AD tenants can function in the same enrollment.

設計上の推奨事項:Design recommendations:

  • 選択した計画トポロジに基づいて Azure AD のシームレスなシングル サインオンを使用します。Use Azure AD seamless single sign-on based on the selected planning topology.
  • 組織に ID インフラストラクチャがない場合は、まず Azure AD のみの ID デプロイを実装します。If your organization doesn't have an identity infrastructure, start by implementing an Azure-AD-only identity deployment. Azure AD Domain ServicesMicrosoft Enterprise Mobility + Security を使用するこのようなデプロイによって、SaaS アプリケーション、エンタープライズ アプリケーション、デバイスのエンドツーエンドの保護が実現されます。Such deployment with Azure AD Domain Services and Microsoft Enterprise Mobility + Security provides end-to-end protection for SaaS applications, enterprise applications, and devices.
  • 多要素認証を使用すると、セキュリティにもう 1 つの層を加え、認証の 2 つ目のバリアを提供することができます。Multifactor authentication provides another layer of security and a second barrier of authentication. セキュリティを強化するために、すべての特権アカウントに多要素認証条件付きアクセス ポリシーを適用します。Enforce multifactor authentication and conditional access policies for all privileged accounts for greater security.
  • テナント全体でアカウントがロックアウトされないように、緊急アクセス用または非常用のアカウントを計画して実装します。Plan and implement for emergency access or break-glass accounts to prevent tenant-wide account lockout.
  • ID とアクセスの管理には、Azure AD Privileged Identity Management を使用します。Use Azure AD Privileged Identity Management for identity and access management.
  • Dev/Test 環境と運用環境が ID の観点では分離された環境になる場合は、複数のテナントを使用してテナント レベルでそれらを分離します。If dev/test and production are going to be isolated environments from an identity perspective, separate them at a tenant level via multiple tenants.
  • 強力な ID とアクセス管理の理由があり、プロセスが既に整っている場合を除き、新しい Azure AD テナントの作成は避けてください。Avoid creating a new Azure AD tenant unless there's a strong identity and access management justification and processes are already in place.