Azure の ID 管理とアクセス制御セキュリティのベスト プラクティスAzure Identity Management and access control security best practices

この記事では、Azure の ID 管理とアクセス制御のセキュリティに関するベスト プラクティスについて説明します。In this article, we discuss a collection of Azure identity management and access control security best practices. このベスト プラクティスは、Azure AD に関して Microsoft が蓄積してきたノウハウと、ユーザーの皆様の経験に基づいています。These best practices are derived from our experience with Azure AD and the experiences of customers like yourself.

それぞれのベスト プラクティスについて、次の点を説明します。For each best practice, we explain:

  • ベスト プラクティスの内容What the best practice is
  • そのベスト プラクティスをお勧めする理由Why you want to enable that best practice
  • そのベスト プラクティスを実践しなかった場合に発生する可能性がある事態What might be the result if you fail to enable the best practice
  • そのベスト プラクティスに代わる対処法Possible alternatives to the best practice
  • そのベスト プラクティスを実践する方法How you can learn to enable the best practice

この Azure の ID 管理とアクセス制御のセキュリティに関するベスト プラクティスの記事は、この記事の執筆時点における共通認識と、Azure プラットフォームの機能および機能セットに基づいています。This Azure identity management and access control security best practices article is based on a consensus opinion and Azure platform capabilities and feature sets, as they exist at the time this article was written.

この記事の目的は、いくつかの主要な機能とサービスについて説明されている「ID インフラストラクチャをセキュリティ保護する 5 つのステップ」チェックリストのガイドに従ってデプロイした後の、より堅牢なセキュリティ体制への一般的なロードマップを提供することです。The intention in writing this article is to provide a general roadmap to a more robust security posture after deployment guided by our “5 steps to securing your identity infrastructure” checklist, which walks you through some of our core features and services.

共通認識とテクノロジは時間が経つにつれて変化するため、そのような変化に対応するために、この記事は定期的に更新されます。Opinions and technologies change over time and this article will be updated on a regular basis to reflect those changes.

この記事では、Azure の ID 管理とアクセス制御のセキュリティに関するベスト プラクティスの次のような点について説明します。Azure identity management and access control security best practices discussed in this article include:

  • ID を主要なセキュリティ境界として扱うTreat identity as the primary security perimeter
  • ID 管理を一元化するCentralize identity management
  • 接続済みテナントを管理するManage connected tenants
  • シングル サインオンの有効化Enable single sign-on
  • 条件付きアクセスをオンにするTurn on Conditional Access
  • 日常的なセキュリティ強化を計画するPlan for routine security improvements
  • パスワード管理を有効にするEnable password management
  • ユーザーに多要素認証を適用するEnforce multi-factor verification for users
  • ロールベースのアクセス制御を使用するUse role-based access control
  • 特権アカウントの公開時間を短縮するLower exposure of privileged accounts
  • リソースが配置される場所を制御するControl locations where resources are located
  • ストレージの認証に Azure AD を使用するUse Azure AD for storage authentication

ID を主要なセキュリティ境界として扱うTreat identity as the primary security perimeter

多くの人々は、ID が主要なセキュリティ境界であると考えています。Many consider identity to be the primary perimeter for security. これは、従来重視されていたネットワーク セキュリティからの転換です。This is a shift from the traditional focus on network security. ネットワーク境界は浸透を続けており、その境界による防御の効果は BYOD デバイスとクラウド アプリケーションが急増する前ほどは得られません。Network perimeters keep getting more porous, and that perimeter defense can’t be as effective as it was before the explosion of BYOD devices and cloud applications.

Azure Active Directory (Azure AD) は ID とアクセスを管理するための Azure ソリューションです。Azure Active Directory (Azure AD) is the Azure solution for identity and access management. Azure AD は、マイクロソフトが提供する、マルチテナントに対応したクラウドベースのディレクトリおよび ID 管理サービスです。Azure AD is a multitenant, cloud-based directory and identity management service from Microsoft. これには、主要なディレクトリ サービス、アプリケーション アクセスの管理、および ID 保護の機能が 1 つのソリューションとして統合されています。It combines core directory services, application access management, and identity protection into a single solution.

以降のセクションでは、Azure AD を使用した ID とアクセスのセキュリティに対するベスト プラクティスを示します。The following sections list best practices for identity and access security using Azure AD.

ベスト プラクティス: ユーザー ID とサービス ID に関するセキュリティの制御と検出を一元化します。Best practice: Center security controls and detections around user and service identities. 詳細: Azure AD を使用して、制御と ID を併置します。Detail: Use Azure AD to collocate controls and identities.

ID 管理を一元化するCentralize identity management

ハイブリッド ID のシナリオでは、オンプレミスとクラウドのディレクトリを統合することをお勧めします。In a hybrid identity scenario we recommend that you integrate your on-premises and cloud directories. この統合により、アカウントの作成場所に関係なく、IT チームが 1 つの場所からアカウントを管理できるようになります。Integration enables your IT team to manage accounts from one location, regardless of where an account is created. また、クラウドとオンプレミスの両方のリソースにアクセスするための共通の ID が提供されるので、ユーザーの生産性が向上します。Integration also helps your users be more productive by providing a common identity for accessing both cloud and on-premises resources.

ベスト プラクティス: 単一の Azure AD インスタンスを確立します。Best practice: Establish a single Azure AD instance. 一貫性と単一の権威ソースにより、明確さが増し、ヒューマン エラーや構成の複雑さによるセキュリティ リスクが軽減されます。Consistency and a single authoritative sources will increase clarity and reduce security risks from human errors and configuration complexity. 詳細: 1 つの Azure AD ディレクトリを、企業や組織のアカウントに対する権威ソースとして指定します。Detail: Designate a single Azure AD directory as the authoritative source for corporate and organizational accounts.

ベスト プラクティス: オンプレミスのディレクトリと Azure AD を統合します。Best practice: Integrate your on-premises directories with Azure AD.
詳細: Azure AD Connect を使用して、オンプレミスのディレクトリとクラウドのディレクトリを同期します。Detail: Use Azure AD Connect to synchronize your on-premises directory with your cloud directory.

注意

Azure AD Connect のパフォーマンスに影響を与える要因があります。There are factors that affect the performance of Azure AD Connect. パフォーマンスが他より劣るシステムによってセキュリティや生産性が損なわれないように十分な容量が Azure AD Connect にあることを確認します。Ensure Azure AD Connect has enough capacity to keep underperforming systems from impeding security and productivity. 大規模な組織や複雑な組織 (10 万を超えるオブジェクトをプロビジョニングする組織) では、推奨事項に従ってその Azure AD Connect の実装を最適化する必要があります。Large or complex organizations (organizations provisioning more than 100,000 objects) should follow the recommendations to optimize their Azure AD Connect implementation.

ベスト プラクティス: 既存の Active Directory インスタンスで高い特権を持つ Azure AD にはアカウントを同期しないようにします。Best practice: Don’t synchronize accounts to Azure AD that have high privileges in your existing Active Directory instance. 詳細: このようなアカウントをフィルターで除外する既定の Azure AD Connect の構成を変更しないでください。Detail: Don’t change the default Azure AD Connect configuration that filters out these accounts. この構成により、敵対者がクラウドからオンプレミスの資産にピボットするリスクを軽減します (これは、大きなインシデントになる可能性があります)。This configuration mitigates the risk of adversaries pivoting from cloud to on-premises assets (which could create a major incident).

ベスト プラクティス: パスワード ハッシュ同期をオンにします。Best practice: Turn on password hash synchronization.
詳細: パスワード ハッシュ同期は、オンプレミスの Active Directory インスタンスからクラウドベースの Azure AD インスタンスにユーザー パスワード ハッシュを同期するときに使用する機能です。Detail: Password hash synchronization is a feature used to synch user password hashes from an on-premises Active Directory instance to a cloud-based Azure AD instance. この同期は、前の攻撃から漏洩した資格情報が再生されるのを保護するのに役立ちます。This sync helps to protect against leaked credentials being replayed from previous attacks.

Active Directory フェデレーション サービス (AD FS) または他の ID プロバイダーでフェデレーションを使用する場合でも、オンプレミスのサーバーがエラーになるか一時的に利用不可になった場合のバックアップとしてパスワード ハッシュ同期を設定することもできます。Even if you decide to use federation with Active Directory Federation Services (AD FS) or other identity providers, you can optionally set up password hash synchronization as a backup in case your on-premises servers fail or become temporarily unavailable. この同期により、ユーザーは、オンプレミスの Active Directory インスタンスにサインインするときに使うものと同じパスワードを使用してサービスにサインインできます。This sync enables users to sign in to the service by using the same password that they use to sign in to their on-premises Active Directory instance. また、ユーザーが Azure AD に接続されていない他のサービスと同じ電子メール アドレスおよびパスワードを使用している場合に、Identity Protection では、同期されたパスワード ハッシュを侵害が検知されたパスワードと比較して、侵害された資格情報を検出できます。It also allows Identity Protection to detect compromised credentials by comparing synchronized password hashes with passwords known to be compromised, if a user has used the same email address and password on other services that aren't connected to Azure AD.

詳細については、「Azure AD Connect 同期を使用したパスワード ハッシュ同期の実装」をご覧ください。For more information, see Implement password hash synchronization with Azure AD Connect sync.

ベスト プラクティス: 新しいアプリケーションの開発では、Azure AD を認証に使用します。Best practice: For new application development, use Azure AD for authentication. 詳細: 適切な機能を使用して認証をサポートします。Detail: Use the correct capabilities to support authentication:

  • 従業員に対しては Azure ADAzure AD for employees
  • ゲスト ユーザーと外部のパートナーに対しては Azure AD B2BAzure AD B2B for guest users and external partners
  • 顧客がアプリケーションを使用するときにサインアップ、サインイン、プロファイル管理を行う方法を制御するには Azure AD B2CAzure AD B2C to control how customers sign up, sign in, and manage their profiles when they use your applications

オンプレミスの ID とクラウドの ID を統合していない組織では、アカウント管理の際により多くのオーバーヘッドが発生する可能性があります。Organizations that don’t integrate their on-premises identity with their cloud identity can have more overhead in managing accounts. このオーバーヘッドによって、ミスやセキュリティ違反の可能性が高まります。This overhead increases the likelihood of mistakes and security breaches.

注意

重要なアカウントが存在するディレクトリ、および使用される管理者ワークステーションを新しいクラウド サービスまたは既存のプロセスのどちらで管理するかを、選択する必要があります。You need to choose which directories critical accounts will reside in and whether the admin workstation used is managed by new cloud services or existing processes. 既存の管理および ID プロビジョニング プロセスを使用すると、一部のリスクを軽減できますが、攻撃者がオンプレミスのアカウントを侵害してクラウドにピボットするリスクが発生する可能性もあります。Using existing management and identity provisioning processes can decrease some risks but can also create the risk of an attacker compromising an on-premises account and pivoting to the cloud. 異なるロールには異なる戦略を使用する場合もあります (たとえば、IT 管理者と部署管理者など)。You might want to use a different strategy for different roles (for example, IT admins vs. business unit admins). この場合、2 つの選択肢があります。You have two options. 1 番目のオプションは、オンプレミスの Active Directory インスタンスと同期されない Azure AD アカウントを作成することです。First option is to create Azure AD Accounts that aren’t synchronized with your on-premises Active Directory instance. 管理ワークステーションを Azure AD に参加させると、Microsoft Intune を使用して管理や修正プログラムの適用を行うことができます。Join your admin workstation to Azure AD, which you can manage and patch by using Microsoft Intune. 2 番目のオプションは、オンプレミスの Active Directory インスタンスに同期することによって、既存の管理者アカウントを使用することです。Second option is to use existing admin accounts by synchronizing to your on-premises Active Directory instance. 管理とセキュリティに Active Directory ドメインの既存のワークステーションを使用します。Use existing workstations in your Active Directory domain for management and security.

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

セキュリティ組織では、リスクを評価し、組織のポリシーおよび規制の要件に従っているかどうかを判断するための、可視性が必要です。Your security organization needs visibility to assess risk and to determine whether the policies of your organization, and any regulatory requirements, are being followed. セキュリティ組織が、運用環境とネットワークに (Azure ExpressRoute またはサイト間 VPN 介して) 接続されているすべてのサブスクリプションに対する可視化を備えていることを、確認する必要があります。You should ensure that your security organization has visibility into all subscriptions connected to your production environment and network (via Azure ExpressRoute or site-to-site VPN). Azure AD のグローバル管理者/社内管理者は、自分のアクセス権をユーザー アクセス管理者ロールに昇格させて、環境に接続されているすべてのサブスクリプションとマネージド グループを見ることができます。A Global Administrator/Company Administrator in Azure AD can elevate their access to the User Access Administrator role and see all subscriptions and managed groups connected to your environment.

自分および自分のセキュリティ グループが、環境に接続されたすべてのサブスクリプションまたは管理グループを表示できることを確認するには、「Azure のすべてのサブスクリプションと管理グループを管理する目的でアクセス権限を昇格させる」をご覧ください。See elevate access to manage all Azure subscriptions and management groups to ensure that you and your security group can view all subscriptions or management groups connected to your environment. リスクの評価が済んだら、この昇格されたアクセス権を削除する必要があります。You should remove this elevated access after you’ve assessed risks.

シングル サインオンの有効化Enable single sign-on

モバイルを重視したクラウド中心の世界では、あらゆる場所からデバイス、アプリ、およびサービスへのシングル サインオン (SSO) を可能にして、時間や場所に関係なくユーザーの生産性を向上する必要があります。In a mobile-first, cloud-first world, you want to enable single sign-on (SSO) to devices, apps, and services from anywhere so your users can be productive wherever and whenever. 管理対象の ID ソリューションが複数あると、IT 部門にとって管理上の問題となるだけでなく、複数のパスワードを覚えておく必要があるユーザーにとっても問題です。When you have multiple identity solutions to manage, this becomes an administrative problem not only for IT but also for users who have to remember multiple passwords.

すべてのアプリとリソースで同じ ID ソリューションを使用することにより、SSO が実現されます。By using the same identity solution for all your apps and resources, you can achieve SSO. また、ユーザーは、必要なリソースがオンプレミスまたはクラウドのどちらにあっても、同じ資格情報セットを使用してリソースにサインインしてアクセスできます。And your users can use the same set of credentials to sign in and access the resources that they need, whether the resources are located on-premises or in the cloud.

ベスト プラクティス: SSO を有効にします。Best practice: Enable SSO.
詳細: Azure AD はクラウドに オンプレミス Active Directory を拡張します。Detail: Azure AD extends on-premises Active Directory to the cloud. ユーザーは、主要な職場または学校アカウントを、ドメイン参加済みデバイス、会社のリソース、および作業を完了させるために必要なすべての Web アプリケーションと SaaS アプリケーションに使用することができます。Users can use their primary work or school account for their domain-joined devices, company resources, and all of the web and SaaS applications that they need to get their jobs done. ユーザーは複数のユーザー名とパスワードのセットを覚える必要がなくなり、組織のグループ メンバーシップや従業員としての地位に基づいて、ユーザーのアプリケーション アクセスが自動的にプロビジョニング (またはプロビジョニング解除) されるようにすることができます。Users don’t have to remember multiple sets of usernames and passwords, and their application access can be automatically provisioned (or deprovisioned) based on their organization group memberships and their status as an employee. また、ギャラリー アプリ、または Azure AD アプリケーション プロキシで開発および公開した独自のオンプレミス アプリについてそのアクセスを制御できます。And you can control that access for gallery apps or for your own on-premises apps that you’ve developed and published through the Azure AD Application Proxy.

SSO を使用すると、ユーザーは Azure AD 内の職場または学校アカウントに基づいて SaaS アプリケーションにアクセスできます。Use SSO to enable users to access their SaaS applications based on their work or school account in Azure AD. これは、Microsoft SaaS アプリだけでなく、Google AppsSalesforce などの他のアプリにも当てはまります。This is applicable not only for Microsoft SaaS apps, but also other apps, such as Google Apps and Salesforce. SAML ベースの ID プロバイダーとして Azure AD を使用するように、アプリケーションを構成できます。You can configure your application to use Azure AD as a SAML-based identity provider. セキュリティ コントロールの目的で、Azure AD では、ユーザーに Azure AD を使用するアクセス権が付与されない限り、アプリケーションへのサインインを許可するトークンは発行されません。As a security control, Azure AD does not issue a token that allows users to sign in to the application unless they have been granted access through Azure AD. ユーザーに対してアクセスを直接許可することも、ユーザーがメンバーであるグループを介して許可することもできます。You can grant access directly, or through a group that users are a member of.

SSO を確立するためにユーザーやアプリケーションに共通の ID を作成しない組織では、ユーザーが複数のパスワードを所有するシナリオに陥ります。Organizations that don’t create a common identity to establish SSO for their users and applications are more exposed to scenarios where users have multiple passwords. このようなシナリオでは、ユーザーがパスワードを再利用したり、脆弱なパスワードを使用したりする可能性が高くなります。These scenarios increase the likelihood of users reusing passwords or using weak passwords.

条件付きアクセスをオンにするTurn on Conditional Access

ユーザーはさまざまなデバイスやアプリを使用してどこからでも組織のリソースにアクセスできます。Users can access your organization's resources by using a variety of devices and apps from anywhere. IT 管理者は、これらのデバイスがセキュリティとコンプライアンスの標準を満たしているかどうかを確認する必要があります。As an IT admin, you want to make sure that these devices meet your standards for security and compliance. だれがリソースにアクセスできるかに重点を置くだけでは十分ではなくなっています。Just focusing on who can access a resource is not sufficient anymore.

セキュリティと生産性のバランスを取るためには、アクセスの制御に関する決定を行う前に、リソースへのアクセス方法を考慮する必要があります。To balance security and productivity, you need to think about how a resource is accessed before you can make a decision about access control. Azure AD の条件付きアクセスで、この要件に対処することができます。With Azure AD Conditional Access, you can address this requirement. 条件付きアクセスを使用すると、クラウド アプリへのアクセスに関する条件に基づいて、アクセス制御の決定を自動的に行うことができます。With Conditional Access, you can make automated access control decisions based on conditions for accessing your cloud apps.

ベスト プラクティス: 会社のリソースへのアクセスを管理および制御します。Best practice: Manage and control access to corporate resources.
詳細: グループ、場所、アプリケーションの機密性に基づいて SaaS アプリや Azure AD 接続アプリの共通の Azure AD 条件付きアクセス ポリシーを構成します。Detail: Configure common Azure AD Conditional Access policies based on a group, location, and application sensitivity for SaaS apps and Azure AD–connected apps.

ベスト プラクティス: レガシ認証プロトコルをブロックします。Best practice: Block legacy authentication protocols. 詳細: 攻撃者は、毎日古いプロトコルの弱点を悪用しています (特にパスワード スプレー攻撃)。Detail: Attackers exploit weaknesses in older protocols every day, particularly for password spray attacks. 条件付きアクセスを構成して、レガシ プロトコルをブロックしますConfigure Conditional Access to block legacy protocols.

日常的なセキュリティ強化を計画するPlan for routine security improvements

セキュリティは常に進化しているので、成長を定期的に確認し、環境の新しいセキュリティ保護方法を見つける手段を、クラウドおよび ID 管理フレームワークに組み込むことが重要です。Security is always evolving, and it is important to build into your cloud and identity management framework a way to regularly show growth and discover new ways to secure your environment.

ID セキュリティ スコアは、セキュリティ対策を客観的に測定し、今後のセキュリティ強化の計画に役立つ数値スコアを提供する、Microsoft によって公開されているセキュリティ コントロールのセットです。Identity Secure Score is a set of recommended security controls that Microsoft publishes that works to provide you a numerical score to objectively measure your security posture and help plan future security improvements. また、スコアを他の業界のものと比較したり、自社の過去の傾向と比較することもできます。You can also view your score in comparison to those in other industries as well as your own trends over time.

ベスト プラクティス: 業界のベスト プラクティスに基づいて、日常的なセキュリティのレビューと改善を計画します。Best practice: Plan routine security reviews and improvements based on best practices in your industry. 詳細: ID セキュリティ スコア機能を使用して、過去の改善をランキングします。Detail: Use the Identity Secure Score feature to rank your improvements over time.

パスワード管理を有効にするEnable password management

複数のテナントがある場合、またはユーザーが自分のパスワードをリセットできるようにする場合は、適切なセキュリティ ポリシーを使用して不適切な使用を防止することが重要です。If you have multiple tenants or you want to enable users to reset their own passwords, it’s important that you use appropriate security policies to prevent abuse.

ベスト プラクティス: ユーザーに対してセルフサービス パスワード リセット (SSPR) を設定します。Best practice: Set up self-service password reset (SSPR) for your users.
詳細: Azure AD の セルフサービス パスワード リセット機能を使用します。Detail: Use the Azure AD self-service password reset feature.

ベスト プラクティス: SSPR が実際に使用されているかどうか、またはその使用方法を監視します。Best practice: Monitor how or if SSPR is really being used.
詳細: Azure AD の パスワード リセット登録アクティビティ レポートを使用して、登録しているユーザーを監視します。Detail: Monitor the users who are registering by using the Azure AD Password Reset Registration Activity report. Azure AD で提供されるレポート機能によって、質問に対する答えをあらかじめ用意されたレポートから得ることができます。The reporting feature that Azure AD provides helps you answer questions by using prebuilt reports. 適切にライセンスを付与されている場合は、カスタム クエリを作成することもできます。If you're appropriately licensed, you can also create custom queries.

ベスト プラクティス: オンプレミスのインフラストラクチャにクラウドベースのパスワード ポリシーを拡張します。Best practice: Extend cloud-based password policies to your on-premises infrastructure. 詳細: クラウドベースのパスワード変更と同じチェックを、オンプレミスのパスワード変更に対しても実行することにより、組織内のパスワード ポリシーを強化します。Detail: Enhance password policies in your organization by performing the same checks for on-premises password changes as you do for cloud-based password changes. オンプレミスの Windows Server Active Directory エージェント用に Azure AD パスワード保護をインストールして、禁止パスワード リストを既存のインフラストラクチャに拡張します。Install Azure AD password protection for Windows Server Active Directory agents on-premises to extend banned password lists to your existing infrastructure. オンプレミスのパスワードを変更、設定、またはリセットするユーザーと管理者は、クラウドのみのユーザーと同じパスワード ポリシーに準拠することが必須になります。Users and admins who change, set, or reset passwords on-premises are required to comply with the same password policy as cloud-only users.

ユーザーに多要素認証を適用するEnforce multi-factor verification for users

すべてのユーザーに対して 2 段階認証を要求することをお勧めします。We recommend that you require two-step verification for all of your users. これには、組織内の管理者およびアカウントが侵害された場合に重大な影響を及ぼす可能性のあるその他のユーザー (財務担当者など) が含まれます。This includes administrators and others in your organization who can have a significant impact if their account is compromised (for example, financial officers).

2 段階認証を要求するオプションは複数あります。There are multiple options for requiring two-step verification. 最適なオプションは、目的、実行している Azure AD エディション、およびライセンス プログラムによって異なります。The best option for you depends on your goals, the Azure AD edition you’re running, and your licensing program. 最適なオプションを判断するには、「ユーザーに 2 段階認証を要求する方法」を参照してください。See How to require two-step verification for a user to determine the best option for you. ライセンスと価格の詳細については、Azure ADAzure AD Multi-Factor Authentication の価格に関するページを参照してください。See the Azure AD and Azure AD Multi-Factor Authentication pricing pages for more information about licenses and pricing.

2 段階認証を有効にするオプションと利点を次に示します。Following are options and benefits for enabling two-step verification:

オプション 1:Azure AD セキュリティの既定値を使用して、すべてのユーザーとログイン方法に対して MFA を有効にします。利点: このオプションを使用すると、環境内のすべてのユーザーに対して、次のような厳しいポリシーで MFA を簡単かつ迅速に適用できます。Option 1: Enable MFA for all users and login methods with Azure AD Security Defaults Benefit: This option enables you to easily and quickly enforce MFA for all users in your environment with a stringent policy to:

  • 管理者アカウントと管理ログオン メカニズムにチャレンジしますChallenge administrative accounts and administrative logon mechanisms
  • すべてのユーザーに Microsoft Authenticator 経由の MFA チャレンジを要求しますRequire MFA challenge via Microsoft Authenticator for all users
  • レガシ認証プロトコルを制限します。Restrict legacy authentication protocols.

この方法はすべてのライセンス レベルで使用できますが、既存の条件付きアクセス ポリシーと併用することはできません。This method is available to all licensing tiers but is not able to be mixed with existing Conditional Access policies. 詳細については、Azure AD のセキュリティの既定値に関するページを参照してくださいYou can find more information in Azure AD Security Defaults

オプション 2:ユーザーの状態を変更することで Multi-Factor Authentication を有効にしますOption 2: Enable Multi-Factor Authentication by changing user state.
利点:2 段階認証を要求するための従来の方法です。Benefit: This is the traditional method for requiring two-step verification. これは、クラウド内の Azure AD Multi-Factor Authentication と Azure Multi-Factor Authentication Server の両方に対応します。It works with both Azure AD Multi-Factor Authentication in the cloud and Azure Multi-Factor Authentication Server. この方法を使用すると、ユーザーはサインインするたびに 2 段階認証を実行するよう求められ、条件付きアクセス ポリシーがオーバーライドされます。Using this method requires users to perform two-step verification every time they sign in and overrides Conditional Access policies.

Multi-factor Authentication を有効にする必要がある場合を判断するには、「所属する組織に適しているのはどちらのバージョンの Azure AD MFA であるかを確認しましょう」をご覧ください。To determine where Multi-Factor Authentication needs to be enabled, see Which version of Azure AD MFA is right for my organization?.

オプション 3:条件付きアクセス ポリシーを使用して Multi-Factor Authentication を有効にしますOption 3: Enable Multi-Factor Authentication with Conditional Access policy. 利点:このオプションでは、条件付きアクセスを使用して特定の条件下で 2 段階認証を要求できます。Benefit: This option allows you to prompt for two-step verification under specific conditions by using Conditional Access. 特定の条件としては、異なる場所、信頼されていないデバイス、または危険と見なされるアプリケーションからのユーザーのサインインを指定できます。Specific conditions can be user sign-in from different locations, untrusted devices, or applications that you consider risky. 2 段階認証を要求する特定の条件を定義すると、要求のメッセージがユーザーに繰り返し表示されないようにすることができます。このようなメッセージは、不快なユーザー エクスペリエンスとなり得ます。Defining specific conditions where you require two-step verification enables you to avoid constant prompting for your users, which can be an unpleasant user experience.

これは、ユーザーの 2 段階認証を有効にするうえで最も柔軟性の高い手段です。This is the most flexible way to enable two-step verification for your users. 条件付きアクセス ポリシーを有効にする方法は、クラウド内の Azure AD Multi-Factor Authentication に対してのみ機能します。これは Azure AD の Premium 機能です。Enabling a Conditional Access policy works only for Azure AD Multi-Factor Authentication in the cloud and is a premium feature of Azure AD. この方法の詳細については、「クラウドベースの Azure AD Multi-Factor Authentication をデプロイする」を参照してください。You can find more information on this method in Deploy cloud-based Azure AD Multi-Factor Authentication.

オプション 4: リスクベースの条件付きアクセス ポリシーを評価することによって、条件付きアクセス ポリシーを使用して Multi-Factor Authentication を有効にします。Option 4: Enable Multi-Factor Authentication with Conditional Access policies by evaluating Risk-based Conditional Access policies.
利点:このオプションの利点は次のとおりです。Benefit: This option enables you to:

  • 組織の ID に影響する潜在的な脆弱性を検出します。Detect potential vulnerabilities that affect your organization’s identities.
  • 組織の ID に関連する検出された疑わしいアクションに対する自動応答を構成します。Configure automated responses to detected suspicious actions that are related to your organization’s identities.
  • 疑わしいインシデントを調査し、適切なアクションを実行して解決します。Investigate suspicious incidents and take appropriate action to resolve them.

この方法では、Azure AD Identity Protection のリスク評価を使用して、すべてのクラウド アプリケーションのユーザーおよびサインインのリスクに基づいて 2 段階認証が要求されるかどうかを判断します。This method uses the Azure AD Identity Protection risk evaluation to determine if two-step verification is required based on user and sign-in risk for all cloud applications. この方法では、Azure Active Directory P2 ライセンスが必要です。This method requires Azure Active Directory P2 licensing. この方法の詳細については、「Azure Active Directory Identity Protection」を参照してください。You can find more information on this method in Azure Active Directory Identity Protection.

注意

オプション 2 (ユーザーの状態を変更することで Multi-Factor Authentication を有効にする) では、条件付きアクセス ポリシーをオーバーライドします。Option 2, enabling Multi-Factor Authentication by changing the user state, overrides Conditional Access policies. オプション 3 および 4 では条件付きアクセス ポリシーを使用するため、オプション 2 をそれらと共に使用することはできません。Because options 3 and 4 use Conditional Access policies, you cannot use option 2 with them.

2 段階認証などの新しい ID 保護レイヤーを追加しない組織は、資格情報盗用攻撃を受けやすくなります。Organizations that don’t add extra layers of identity protection, such as two-step verification, are more susceptible for credential theft attack. 資格情報盗用攻撃はデータの侵害につながる可能性があります。A credential theft attack can lead to data compromise.

ロールベースのアクセス制御を使用するUse role-based access control

クラウド リソースに対するアクセスの管理は、クラウドを使用しているすべての組織にとって重要なことです。Access management for cloud resources is critical for any organization that uses the cloud. Azure ロールベースのアクセス制御 (Azure RBAC) は、Azure リソースにアクセスできるユーザー、そのユーザーがそれらのリソースに対して実行できること、およびそのユーザーがアクセスできる領域を管理するのに役立ちます。Azure role-based access control (Azure RBAC) helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.

Azure での特定の機能に対して責任を負うグループまたは個人のロールを指定すると、セキュリティ リスクをもたらすヒューマン エラーやオートメーション エラーにつながる可能性のある混乱を避けるのに役立ちます。Designating groups or individual roles responsible for specific functions in Azure helps avoid confusion that can lead to human and automation errors that create security risks. データ アクセスにセキュリティ ポリシーを適用する組織では、必知事項最小権限のセキュリティ原則に基づいてアクセスを制限することが不可欠です。Restricting access based on the need to know and least privilege security principles is imperative for organizations that want to enforce security policies for data access.

セキュリティ チームは、リスクを評価して修復するため、Azure リソースに対する可視性を必要とします。Your security team needs visibility into your Azure resources in order to assess and remediate risk. セキュリティ チームに運用責任がある場合、それらのジョブを実行するために追加のアクセス許可が必要です。If the security team has operational responsibilities, they need additional permissions to do their jobs.

Azure RBAC を使用して、特定のスコープ内のユーザー、グループ、アプリケーションにアクセス許可を割り当てることができます。You can use Azure RBAC to assign permissions to users, groups, and applications at a certain scope. ロール割り当てのスコープには、サブスクリプション、リソース グループ、または単独のリソースを指定できます。The scope of a role assignment can be a subscription, a resource group, or a single resource.

ベスト プラクティス: チーム内で職務を分離し、職務を実行するために必要なアクセスのみをユーザーに許可します。Best practice: Segregate duties within your team and grant only the amount of access to users that they need to perform their jobs. すべてのユーザーに Azure サブスクリプションまたはリソースで無制限のアクセス許可を付与するのではなく、特定のスコープで特定の操作のみを許可します。Instead of giving everybody unrestricted permissions in your Azure subscription or resources, allow only certain actions at a particular scope. 詳細: Azure で Azure 組み込みロールを使用して、ユーザーに特権を割り当てます。Detail: Use Azure built-in roles in Azure to assign privileges to users.

注意

個別のアクセス許可では、不要な複雑さと混乱が発生し、それが積み重なって、何かを壊してしまう心配なしでは修正するのが難しい "レガシ" 構成になります。Specific permissions create unneeded complexity and confusion, accumulating into a “legacy” configuration that’s difficult to fix without fear of breaking something. リソース固有のアクセス許可は使わないようにします。Avoid resource-specific permissions. 代わりに、エンタープライズ全体のアクセス許可には管理グループを使用し、サブスクリプション内のアクセス許可にはリソース グループを使用します。Instead, use management groups for enterprise-wide permissions and resource groups for permissions within subscriptions. ユーザー固有のアクセス許可は使わないようにします。Avoid user-specific permissions. 代わりに、Azure AD でグループにアクセスを割り当てます。Instead, assign access to groups in Azure AD.

ベスト プラクティス: セキュリティ チームには Azure のリソースを把握するための Azure の責任のアクセス権を付与し、リスクを評価して修復できるようにします。Best practice: Grant security teams with Azure responsibilities access to see Azure resources so they can assess and remediate risk. 詳細: セキュリティ チームには、Azure RBAC の セキュリティ閲覧者ロールを付与します。Detail: Grant security teams the Azure RBAC Security Reader role. 責任の範囲に応じて、ルート管理グループまたはセグメント管理グループを使用できます。You can use the root management group or the segment management group, depending on the scope of responsibilities:

  • すべてのエンタープライズ リソースを担当するチームに対しては ルート管理グループRoot management group for teams responsible for all enterprise resources
  • スコープが限られたチームには セグメント管理グループ (一般に、規制または他の組織的な境界のため)Segment management group for teams with limited scope (commonly because of regulatory or other organizational boundaries)

ベスト プラクティス: 直接的な運用責任を持つセキュリティ チームには、適切なアクセス許可を付与します。Best practice: Grant the appropriate permissions to security teams that have direct operational responsibilities. 詳細: Azure の組み込みロールで、適切なロールの割り当てを確認します。Detail: Review the Azure built-in roles for the appropriate role assignment. 組み込みロールが組織の特定のニーズを満たさない場合は、Azure カスタム ロールを作成することができます。If the built-in roles don't meet the specific needs of your organization, you can create Azure custom roles. 組み込みロールと同様、カスタム ロールは、ユーザー、グループ、サービス プリンシパルに対して、サブスクリプション、リソース グループ、リソースのスコープで割り当てることができます。As with built-in roles, you can assign custom roles to users, groups, and service principals at subscription, resource group, and resource scopes.

ベスト プラクティス:Azure Security Center へのアクセス権を、それを必要とするセキュリティ ロールに付与します。Best practices: Grant Azure Security Center access to security roles that need it. Security Center では、セキュリティ チームはすばやくリスクを特定して修復できます。Security Center allows security teams to quickly identify and remediate risks. 詳細: これらのニーズを持つセキュリティ チームを Azure RBAC セキュリティ管理者に追加し、セキュリティ ポリシーを表示したり、セキュリティ状態を表示したり、セキュリティ ポリシーを編集したり、アラートと推奨事項を表示したり、アラートと推奨事項を無視したりできるようにします。Detail: Add security teams with these needs to the Azure RBAC Security Admin role so they can view security policies, view security states, edit security policies, view alerts and recommendations, and dismiss alerts and recommendations. 責任の範囲に応じて、ルート管理グループまたはセグメント管理グループを使用して、これを行うことができます。You can do this by using the root management group or the segment management group, depending on the scope of responsibilities.

Azure RBAC などの機能を使用したデータ アクセス制御を適用しない組織では、ユーザーに必要以上の権限が付与される可能性があります。Organizations that don’t enforce data access control by using capabilities like Azure RBAC might be giving more privileges than necessary to their users. これにより、ユーザーがアクセスする必要のない種類のデータ (ビジネスへの影響が高いものなど) にアクセスできるようになり、データのセキュリティ侵害につながる恐れがあります。This can lead to data compromise by allowing users to access types of data (for example, high business impact) that they shouldn’t have.

特権アカウントの公開時間を短縮するLower exposure of privileged accounts

特権アクセスのセキュリティ保護は、ビジネス資産を保護するうえで重要な最初のステップです。Securing privileged access is a critical first step to protecting business assets. セキュリティで保護された情報またはリソースへのアクセス権を持つユーザーの数を最小限に抑えることで、悪意のあるユーザーがこのようなアクセス権を手にしたり、権限のあるユーザーの不注意で機微なリソースのセキュリティが損なわれたりする可能性が抑えられます。Minimizing the number of people who have access to secure information or resources reduces the chance of a malicious user getting access, or an authorized user inadvertently affecting a sensitive resource.

特権アカウントとは、IT システムを管理するアカウントです。Privileged accounts are accounts that administer and manage IT systems. サイバー攻撃では、組織のデータやシステムへのアクセス手段を得るために、このようなアカウントが標的にされます。Cyber attackers target these accounts to gain access to an organization’s data and systems. 特権アクセスを保護するには、悪意のあるユーザーにさらされる危険からアカウントとシステムを分離する必要があります。To secure privileged access, you should isolate the accounts and systems from the risk of being exposed to a malicious user.

サイバー攻撃者から特権アクセスを保護するためのロードマップを作成して従うことをお勧めします。We recommend that you develop and follow a roadmap to secure privileged access against cyber attackers. Azure AD、Microsoft Azure、Microsoft 365、およびその他のクラウド サービスで管理または報告される ID とアクセスを保護するための詳細なロードマップの作成については、「Azure AD でのハイブリッドおよびクラウド デプロイ用の特権アクセスをセキュリティで保護する」を確認してください。For information about creating a detailed roadmap to secure identities and access that are managed or reported in Azure AD, Microsoft Azure, Microsoft 365, and other cloud services, review Securing privileged access for hybrid and cloud deployments in Azure AD.

Azure AD でのハイブリッドおよびクラウド デプロイ用の特権アクセスをセキュリティで保護する」に記載されているベスト プラクティスを以下にまとめています。The following summarizes the best practices found in Securing privileged access for hybrid and cloud deployments in Azure AD:

ベスト プラクティス: 特権アカウントへのアクセスを管理、制御、および監視します。Best practice: Manage, control, and monitor access to privileged accounts.
詳細: Azure AD Privileged Identity Management を有効にします。Detail: Turn on Azure AD Privileged Identity Management. Privileged Identity Management を有効にすると、特権アクセス ロールが変更されたという電子メール通知を受け取ります。After you turn on Privileged Identity Management, you’ll receive notification email messages for privileged access role changes. これらの通知は、ディレクトリ内の高度な特権ロールに他のユーザーが追加された場合に早期警告を提供します。These notifications provide early warning when additional users are added to highly privileged roles in your directory.

ベスト プラクティス: すべての重要な管理者アカウントが、マネージド Azure AD アカウントであるようにします。Best practice: Ensure all critical admin accounts are managed Azure AD accounts. 詳細: 重要な管理者ロールから、すべてのコンシューマー アカウントを削除します (hotmail.com、live.com、outlook.com といった Microsoft アカウントなど)。Detail: Remove any consumer accounts from critical admin roles (for example, Microsoft accounts like hotmail.com, live.com, and outlook.com).

ベスト プラクティス: 管理者特権を侵害するフィッシングや他の攻撃を回避するため、すべての重要な管理者ロールが管理タスク用のアカウントを持つようにします。Best practice: Ensure all critical admin roles have a separate account for administrative tasks in order to avoid phishing and other attacks to compromise administrative privileges. 詳細: 管理タスクの実行に必要な特権が割り当てられている管理者アカウントを別に作成します。Detail: Create a separate admin account that’s assigned the privileges needed to perform the administrative tasks. Microsoft 365 の電子メールや任意の Web 閲覧など、日常的に使用する生産性向上ツールには、これらの管理者アカウントを使用できないようにします。Block the use of these administrative accounts for daily productivity tools like Microsoft 365 email or arbitrary web browsing.

ベスト プラクティス: 高度な特権ロールに属するアカウントを識別および分類します。Best practice: Identify and categorize accounts that are in highly privileged roles.
詳細: Azure AD Privileged Identity Management を有効にした後、グローバル管理者、特権ロール管理者、およびその他の高度な特権ロールに属するユーザーを表示します。Detail: After turning on Azure AD Privileged Identity Management, view the users who are in the global administrator, privileged role administrator, and other highly privileged roles. これらのロールで不要になったアカウントを削除し、管理者ロールに割り当てられている残りのアカウントを分類します。Remove any accounts that are no longer needed in those roles, and categorize the remaining accounts that are assigned to admin roles:

  • 管理ユーザーに個別に割り当てられ、管理以外の目的 (たとえば、個人用電子メール) に使用できるIndividually assigned to administrative users, and can be used for non-administrative purposes (for example, personal email)
  • 管理ユーザーに個別に割り当てられ、管理目的にのみ指定されているIndividually assigned to administrative users and designated for administrative purposes only
  • 複数のユーザー間で共有されるShared across multiple users
  • 非常時のアクセス シナリオ用For emergency access scenarios
  • 自動スクリプト用For automated scripts
  • 外部ユーザー用For external users

ベスト プラクティス: "Just-In-Time" (JIT) アクセスを実装して、権限が公開される時間をさらに短縮し、特権アカウントの使用の可視性を向上します。Best practice: Implement “just in time” (JIT) access to further lower the exposure time of privileges and increase your visibility into the use of privileged accounts.
詳細: Azure AD Privileged Identity Management では、次のことが可能です。Detail: Azure AD Privileged Identity Management lets you:

  • ユーザーが自分の権限の JIT のみを利用するよう制限します。Limit users to only taking on their privileges JIT.
  • 権限が自動的に取り消される、短縮された期間のロールを割り当てます。Assign roles for a shortened duration with confidence that the privileges are revoked automatically.

ベスト プラクティス: 少なくとも 2 つの緊急アクセス用アカウントを定義します。Best practice: Define at least two emergency access accounts.
詳細: 緊急アクセス用アカウントは、組織において既存の Azure Active Directory 環境での特権アクセスを制限するのに役立ちます。Detail: Emergency access accounts help organizations restrict privileged access in an existing Azure Active Directory environment. このようなアカウントは高い特権を持っており、特定のユーザーには割り当てられません。These accounts are highly privileged and are not assigned to specific individuals. 緊急アクセス用アカウントは、通常の管理者アカウントを使うことができないシナリオに制限されます。Emergency access accounts are limited to scenarios where normal administrative accounts can’t be used. 組織では、緊急用アカウントの使用を必要な時間だけに制限する必要があります。Organizations must limit the emergency account's usage to only the necessary amount of time.

グローバル管理者ロールが割り当てられているか、その対象であるアカウントを評価します。Evaluate the accounts that are assigned or eligible for the global admin role. *.onmicrosoft.com ドメイン (緊急アクセスが目的) を使用してクラウド専用アカウントが見当たらない場合は、それらを作成します。If you don’t see any cloud-only accounts by using the *.onmicrosoft.com domain (intended for emergency access), create them. 詳しくは、「Azure AD で緊急アクセス用管理者アカウントを管理する」をご覧ください。For more information, see Managing emergency access administrative accounts in Azure AD.

ベスト プラクティス: 緊急事態が発生した場合の "非常時" プロセスを用意します。Best practice: Have a “break glass" process in place in case of an emergency. 詳細: 「Azure AD でのハイブリッドおよびクラウド デプロイ用の特権アクセスをセキュリティで保護する」の手順に従います。Detail: Follow the steps in Securing privileged access for hybrid and cloud deployments in Azure AD.

ベスト プラクティス: すべての重要な管理者アカウントには、パスワードレス (推奨) または Multi-Factor Authentication を要求します。Best practice: Require all critical admin accounts to be password-less (preferred), or require Multi-Factor Authentication. 詳細: Microsoft Authenticator アプリを使用して、パスワードを使用せずに Azure AD アカウントにサインインします。Detail: Use the Microsoft Authenticator app to sign in to any Azure AD account without using a password. Windows Hello for Business のように、Microsoft Authenticator は、キーベースの認証を使用して、デバイスに関連付けられていて生体認証または PIN を使用するユーザー資格情報を有効にします。Like Windows Hello for Business, the Microsoft Authenticator uses key-based authentication to enable a user credential that’s tied to a device and uses biometric authentication or a PIN.

次のような Azure AD 管理者ロールを永続的に割り当てられているすべての個人ユーザーには、サインイン時に Azure AD Multi-factor Authentication を要求します: グローバル管理者、特権ロール管理者、Exchange Online 管理者、SharePoint Online 管理者。Require Azure AD Multi-Factor Authentication at sign-in for all individual users who are permanently assigned to one or more of the Azure AD admin roles: Global Administrator, Privileged Role Administrator, Exchange Online Administrator, and SharePoint Online Administrator. 管理者アカウントの Multi-Factor Authentication を有効にし、管理者アカウントのユーザーが登録していることを確認します。Enable Multi-Factor Authentication for your admin accounts and ensure that admin account users have registered.

ベスト プラクティス: 重要な管理者アカウントには、運用タスク (たとえば、閲覧やメール) を使用できない管理ワークステーションを用意します。Best practice: For critical admin accounts, have an admin workstation where production tasks aren’t allowed (for example, browsing and email). これにより、閲覧やメールを使用する攻撃ベクトルから管理者アカウントが保護され、主要なインシデントのリスクが大幅に低下します。This will protect your admin accounts from attack vectors that use browsing and email and significantly lower your risk of a major incident. 詳細: 管理ワークステーションを使用します。Detail: Use an admin workstation. ワークステーションのセキュリティのレベルを選択します。Choose a level of workstation security:

  • 安全性の高い生産性デバイスでは、閲覧や他の生産性タスクに対する高度なセキュリティが提供されます。Highly secure productivity devices provide advanced security for browsing and other productivity tasks.
  • Privileged Access Workstation (PAW) には、機密性の高いタスクに専用のオペレーティング システムが用意されており、インターネット上の攻撃や脅威ベクトルから保護されます。Privileged Access Workstations (PAWs) provide a dedicated operating system that’s protected from internet attacks and threat vectors for sensitive tasks.

ベスト プラクティス: 従業員が組織を離れるときは、管理者アカウントをプロビジョニング解除します。Best practice: Deprovision admin accounts when employees leave your organization. 詳細: 従業員が組織を離れるときに管理者アカウントを無効化または削除するプロセスを設けます。Detail: Have a process in place that disables or deletes admin accounts when employees leave your organization.

ベスト プラクティス: 最新の攻撃手法を使用して、管理者アカウントを定期的にテストします。Best practice: Regularly test admin accounts by using current attack techniques. 詳細: Microsoft 365 攻撃シミュレーターまたはサードパーティのオファリングを使用して、現実的な攻撃のシナリオを組織内で実行します。Detail: Use Microsoft 365 Attack Simulator or a third-party offering to run realistic attack scenarios in your organization. これは、実際の攻撃が発生する前に脆弱性のあるユーザーを発見するのに役立ちます。This can help you find vulnerable users before a real attack occurs.

ベスト プラクティス: 最も頻繁に使用される攻撃手法を軽減するための対策を講じます。Best practice: Take steps to mitigate the most frequently used attacked techniques.
詳細: 職場または学校アカウントに切り替える必要がある管理者ロールの Microsoft アカウントを特定するDetail: Identify Microsoft accounts in administrative roles that need to be switched to work or school accounts

グローバル管理者アカウントのユーザー アカウントとメール転送を分離するEnsure separate user accounts and mail forwarding for global administrator accounts

管理者アカウントのパスワードが最近変更されたことを確認するEnsure that the passwords of administrative accounts have recently changed

パスワード ハッシュ同期をオンにするTurn on password hash synchronization

すべての特権ロールに属するユーザーおよび露出しているユーザーに多要素認証を要求するRequire Multi-Factor Authentication for users in all privileged roles as well as exposed users

Microsoft 365 のセキュリティ スコアを取得する (Microsoft 365 を使用している場合)Obtain your Microsoft 365 Secure Score (if using Microsoft 365)

Microsoft 365 のセキュリティ ガイダンスを確認する (Microsoft 365 を使用している場合)Review the Microsoft 365 security guidance (if using Microsoft 365)

Microsoft 365 のアクティビティ監視を構成する (Microsoft 365 を使用している場合)Configure Microsoft 365 Activity Monitoring (if using Microsoft 365)

インシデント/緊急時対応計画の所有者を設定するEstablish incident/emergency response plan owners

オンプレミスの特権管理者アカウントをセキュリティで保護するSecure on-premises privileged administrative accounts

特権アクセスをセキュリティで保護しない場合は、高度な特権ロールに属するユーザーが多すぎて攻撃を受けやすくなっている可能性があります。If you don’t secure privileged access, you might find that you have too many users in highly privileged roles and are more vulnerable to attacks. 多くの場合、サイバー攻撃者を含む悪意のあるアクターは、管理者アカウントやその他の特権アクセスの要素をターゲットとして、資格情報盗用を使用して機密データやシステムへのアクセスを取得します。Malicious actors, including cyber attackers, often target admin accounts and other elements of privileged access to gain access to sensitive data and systems by using credential theft.

リソースが作成される場所を制御するControl locations where resources are created

クラウド事業者がタスクを実行できるようにする一方で、組織のリソースの管理に必要な規則に違反しないようにすることが、非常に重要です。Enabling cloud operators to perform tasks while preventing them from breaking conventions that are needed to manage your organization's resources is very important. リソースが作成される場所を制御する必要のある組織では、これらの場所をハード コードする必要があります。Organizations that want to control the locations where resources are created should hard code these locations.

Azure Resource Manager を使用すると、明示的に拒否されるアクションまたはリソースが記述されている定義を含むセキュリティ ポリシーを作成できます。You can use Azure Resource Manager to create security policies whose definitions describe the actions or resources that are specifically denied. サブスクリプション、リソース グループ、個別リソースなど、任意の範囲でポリシー定義を割り当てます。You assign those policy definitions at the desired scope, such as the subscription, the resource group, or an individual resource.

注意

セキュリティ ポリシーは Azure RBAC とは異なります。Security policies are not the same as Azure RBAC. 実際には、Azure RBAC を使用して、ユーザーがこれらのリソースを作成することを許可します。They actually use Azure RBAC to authorize users to create those resources.

リソースの作成方法を制御しないと、ユーザーは必要量より多くのリソースを作成することによってサービスを不正使用する可能性が高くなります。Organizations that are not controlling how resources are created are more susceptible to users who might abuse the service by creating more resources than they need. リソースの作成プロセスを強化することは、マルチテナントのシナリオをセキュリティ保護するための重要な手順です。Hardening the resource creation process is an important step to securing a multitenant scenario.

疑わしいアクティビティを能動的に監視するActively monitor for suspicious activities

アクティブな ID 監視システムでは、疑わしい動作をすばやく検出して、さらなる調査を行うためのアラートをトリガーします。An active identity monitoring system can quickly detect suspicious behavior and trigger an alert for further investigation. 組織による ID の監視に役立つ 2 つの Azure AD 機能を次に示します。The following table lists two Azure AD capabilities that can help organizations monitor their identities:

ベスト プラクティス: 次の動作を識別するための方法を用意します。Best practice: Have a method to identify:

詳細: Azure AD Premium の 異常レポートを使用します。Detail: Use Azure AD Premium anomaly reports. IT 管理者がこれらのレポートを毎日または必要に応じて (通常はインシデント対応シナリオ) 実行するためのプロセスと手順を設けます。Have processes and procedures in place for IT admins to run these reports on a daily basis or on demand (usually in an incident response scenario).

ベスト プラクティス: リスクを通知し、ビジネス要件に合わせてリスク レベル (高、中、低) を調整できるアクティブな監視システムを用意します。Best practice: Have an active monitoring system that notifies you of risks and can adjust risk level (high, medium, or low) to your business requirements.
詳細: Azure AD Identity Protection を使用します。この製品では、独自のダッシュボードで現在のリスクにフラグを設定し、概要の通知を毎日電子メールで送信します。Detail: Use Azure AD Identity Protection, which flags the current risks on its own dashboard and sends daily summary notifications via email. 指定したリスク レベルに達したときに、検出された問題が自動的に対処されるようにリスク ベースのポリシーを構成することで、組織の ID を保護できます。To help protect your organization's identities, you can configure risk-based policies that automatically respond to detected issues when a specified risk level is reached.

ID システムを能動的に監視しないと、ユーザーの資格情報が侵害されるリスクがあります。Organizations that don’t actively monitor their identity systems are at risk of having user credentials compromised. 侵害された資格情報を用いた疑わしい活動が行われていることを把握しないと、この種の脅威を緩和することはできません。Without knowledge that suspicious activities are taking place through these credentials, organizations can’t mitigate this type of threat.

ストレージの認証に Azure AD を使用するUse Azure AD for storage authentication

Azure Storage は、Blob Storage や Queue storage に対する Azure AD での認証と承認をサポートします。Azure Storage supports authentication and authorization with Azure AD for Blob storage and Queue storage. Azure AD 認証では、Azure のロールベースのアクセス制御を使用して、個々の BLOB コンテナーやキューに対する特定のアクセス許可を、ユーザー、グループ、アプリケーションに付与できます。With Azure AD authentication, you can use the Azure role-based access control to grant specific permissions to users, groups, and applications down to the scope of an individual blob container or queue.

ストレージへのアクセスを認証するには Azure AD を使用することをお勧めします。We recommend that you use Azure AD for authenticating access to storage.

次のステップNext step

Azure を使用してクラウド ソリューションを設計、デプロイ、管理するときに使用するセキュリティのベスト プラクティスの詳細については、「Azure セキュリティのベスト プラクティスとパターン」を参照してください。See Azure security best practices and patterns for more security best practices to use when you’re designing, deploying, and managing your cloud solutions by using Azure.