ID インフラストラクチャをセキュリティ保護する 5 つのステップFive steps to securing your identity infrastructure

このドキュメントをご覧になっているお客様は、セキュリティの重要性を認識なさっていると思います。If you're reading this document, you're aware of the significance of security. おそらく、既に組織をセキュリティで保護する責任を負っていらっしゃるでしょう。You likely already carry the responsibility for securing your organization. セキュリティの重要性を他の人に理解してもらう必要がある場合は、最新の Microsoft セキュリティ インテリジェンス レポートを読むようご案内ください。If you need to convince others of the importance of security, send them to read the latest Microsoft Security Intelligence report.

このドキュメントは、Azure Active Directory の機能を使用してセキュリティ体制を強化するのに役立ちます。そのために、サイバー攻撃への対策を組織に取り入れる 5 ステップのチェックリストが使用されます。This document will help you get a more secure posture using the capabilities of Azure Active Directory by using a five-step checklist to inoculate your organization against cyber-attacks.

このチェックリストは、重要な推奨アクションを迅速に展開して、組織を直ちに保護するうえで役に立ちます。ここでは、以下の方法について説明されています。This checklist will help you quickly deploy critical recommended actions to protect your organization immediately by explaining how to:

  • 資格情報を強化する。Strengthen your credentials.
  • 攻撃の対象となる領域を減らす。Reduce your attack surface area.
  • 脅威への対応を自動化する。Automate threat response.
  • クラウド インテリジェンスを利用します。Utilize cloud intelligence.
  • エンドユーザー セルフサービスを有効にします。Enable end-user self-service.

このチェックリストの確認時に、どの機能と手順が完了しているかを必ず追跡しておいてください。Make sure you keep track of which features and steps are complete while reading this checklist.

注意

このドキュメントの推奨事項の多くは、Azure Active Directory を ID プロバイダーとして使用するよう構成されたアプリケーションにのみ適用されます。Many of the recommendations in this document apply only to applications that are configured to use Azure Active Directory as their identity provider. シングル サインオンを使用するようアプリを構成すると、資格情報ポリシーや脅威の検出、監査、ログの記録などの機能がこれらのアプリケーションに追加されるという様々な利点があります。Configuring apps for Single Sign-On assures the benefits of credential policies, threat detection, auditing, logging, and other features add to those applications. Azure AD アプリケーション管理は、これらのすべての推奨事項の基盤となります。Azure AD Application Management is the foundation - on which all these recommendations are based.

このドキュメントの推奨事項は、Azure AD テナントの ID セキュリティ構成の自動化された評価である ID セキュリティ スコアと一致しています。The recommendations in this document are aligned with the Identity Secure Score, an automated assessment of your Azure AD tenant’s identity security configuration. 組織は Azure AD ポータルの ID セキュリティ スコア ページを使用して、現在のセキュリティ構成におけるギャップを探し、セキュリティに関する最新の Microsoft のベスト プラクティスに従っていることを確認できます。Organizations can use the Identity Secure Score page in the Azure AD portal to find gaps in their current security configuration to ensure they follow current Microsoft best practices for security. セキュリティ スコア ページで各推奨事項を実装すると、スコアが上がり、進行状況を追跡することができ、さらに他の似た規模の組織や業界と実装を比較するのに役立ちます。Implementing each recommendation in the Secure Score page will increase your score and allow you to track your progress, plus help you compare your implementation against other similar size organizations or your industry.

ID セキュリティ スコア

注意

ここで説明する機能の多くでは、Azure AD Premium サブスクリプションが必要ですが、一部は無料です。Many of the features described here require an Azure AD Premium subscription, while some are free. 詳細については、「Azure Active Directory の価格」と Azure AD デプロイに関するチェックリストをご覧ください。Please review our Azure Active Directory pricing and Azure AD Deployment checklist for more information.

作業を開始する前に、次のことを行います。MFA で特権アカウントを保護しますBefore you begin: Protect privileged accounts with MFA

このチェックリストを読み始める前に、読んでいる間にセキュリティが侵害されないようにしてください。Before you begin this checklist, make sure you don't get compromised while you're reading this checklist. まず、特権アカウントを保護する必要があります。You first need to protect your privileged accounts.

攻撃者に特権アカウントを支配されると、多大な損害が発生する可能性があるので、まず特権アカウントを保護することが重要です。Attackers who get control of privileged accounts can do tremendous damage, so it's critical to protect these accounts first. Azure AD セキュリティの既定値または条件付きアクセスを使用して、すべての管理者に関して Azure AD Multi-Factor Authentication (MFA) を有効にして要求します。Enable and require Azure AD Multi-Factor Authentication (MFA) for all administrators in your organization using Azure AD Security Defaults or Conditional Access. MFA を実装していない場合はすぐに実装してください。If you haven't implemented MFA, do it now! これは非常に重要です。It's that important.

準備はできたでしょうか。All set? それでは、チェックリストの確認に入りましょう。Let's get started on the checklist.

ステップ 1. - 資格情報を強化するStep 1 - Strengthen your credentials

ほとんどのエンタープライズのセキュリティ侵害では、パスワード スプレーや侵害リプレイ、フィッシングなど、いくつかある手法のいずれかによるアカウント侵害が原因です。Most enterprise security breaches originate with an account compromised with one of a handful of methods such as password spray, breach replay, or phishing. 次の動画 (45 分) で、これらの攻撃についてご確認ください。Learn more about these attacks in this video (45 min):

組織で強力な認証が使用されるようにするMake sure your organization uses strong authentication

パスワードの推測、フィッシング、マルウェアによる盗難、または再利用が頻繁に行われることを考えると、何らかの強力な資格情報でパスワードを強化することが非常に重要です。Azure AD Multi-Factor Authentication の詳細をご確認ください。Given the frequency of passwords being guessed, phished, stolen with malware, or reused, it's critical to back the password with some form of strong credential – learn more about Azure AD Multi-Factor Authentication.

ID セキュリティの基本レベルを簡単に有効にするために、Azure AD セキュリティの既定値によりワンクリックでの有効化を使用できます。To easily enable the basic level of identity security, you can use the one-click enablement with Azure AD Security Defaults. セキュリティの既定値により、テナント内のすべてのユーザーに Azure AD MFA が適用され、従来のプロトコル テナント全体からのサインインがブロックされます。Security defaults enforce Azure AD MFA for all users in a tenant and blocks sign-ins from legacy protocols tenant-wide.

攻撃されやすいパスワードを禁止して、従来の複雑さと有効期限にのルールを無効にする。Start banning commonly attacked passwords and turn off traditional complexity, and expiration rules.

多くの組織は、従来の複雑さ (特殊文字、数字、大文字、小文字を要求する) とパスワードの有効期限に関するルールを使用しています。Many organizations use the traditional complexity (requiring special characters, numbers, uppercase, and lowercase) and password expiration rules. Microsoft の調査によると、これらのポリシーは推測されやすいパスワードをユーザーが選択する原因となります。Microsoft's research has shown these policies cause users to choose passwords that are easier to guess.

Azure AD のパスワードの動的禁止機能では、簡単に推測できるパスワードをユーザーが設定するの防ぐために、現在の攻撃者の行動が利用されます。Azure AD's dynamic banned password feature uses current attacker behavior to prevent users from setting passwords that can easily be guessed. この機能はユーザーがクラウドで作成されるときは常に有効ですが、Windows Server Active Directory 用の Azure AD パスワード保護をデプロイするときにハイブリッド組織に対しても使用できるようになっています。This capability is always on when users are created in the cloud, but is now also available for hybrid organizations when they deploy Azure AD password protection for Windows Server Active Directory. Azure AD パスワード保護は、ユーザーがこれらの一般的なパスワードを選択することをブロックし、指定したカスタム キーワードを含むパスワードをブロックするように拡張できます。Azure AD password protection blocks users from choosing these common passwords and can be extended to block password containing custom keywords you specify. たとえば、ユーザーが会社の製品名や地元のスポーツ チームを含むパスワードを選択するのを防止することができます。For example, you can prevent your users from choosing passwords containing your company’s product names or a local sport team.

NIST ガイダンスに基づく次のような先進のパスワード ポリシーを採用することをお勧めします。Microsoft recommends adopting the following modern password policy based on NIST guidance:

  1. パスワードに 8 文字以上を必要とする。Require passwords have at least 8 characters. ユーザーが予測可能なパスワードを選んだり、パスワードをファイルに保存したり、書き留めたりする原因となるため、必ずしも長ければ長いほど良いというわけではありません。Longer isn't necessarily better, as they cause users to choose predictable passwords, save passwords in files, or write them down.
  2. 有効期限のルールを無効にする。このルールは、簡単に推測されるパスワード (Spring2019! など) をユーザーが使用する原因になりますDisable expiration rules, which drive users to easily guessed passwords such as Spring2019!
  3. 文字構成の要件を無効にして、よく攻撃されるパスワードをユーザーが選択するのを防ぐ。これは、文字構成の要件が、パスワードで予測可能な文字置換をユーザーが選択する原因となるためです。Disable character-composition requirements and prevent users from choosing commonly attacked passwords, as they cause users to choose predictable character substitutions in passwords.

Azure AD で直接 ID を作成した場合、PowerShell を使用してユーザーのパスワードの期限切れを防ぐことができます。You can use PowerShell to prevent passwords from expiring for users if you create identities in Azure AD directly. ハイブリッド組織では、ドメイン グループ ポリシー設定または Windows PowerShell を使用してこれらのポリシーを実装する必要があります。Hybrid organizations should implement these policies using domain group policy settings or Windows PowerShell.

資格情報の漏洩から保護し、障害に対する回復力を高めるProtect against leaked credentials and add resilience against outages

組織がパススルー認証またはフェデレーションによるハイブリッド ID ソリューションを使用する場合、次の 2 つの理由から、パスワード ハッシュ同期を有効にする必要があります。If your organization uses a hybrid identity solution with pass-through authentication or federation, then you should enable password hash sync for the following two reasons:

  • Azure AD 管理の資格情報が漏洩したユーザー レポートでは、"闇サイト" で公開されているユーザー名とパスワードのペアについて、警告を受け取れます。The Users with leaked credentials report in the Azure AD management warns you of username and password pairs, which have been exposed on the "dark web." 驚くほど大量のパスワードが、後にセキュリティ侵害されるサードパーティ サイトでのパスワードの再利用、フィッシング、マルウェアによって漏洩しています。An incredible volume of passwords is leaked via phishing, malware, and password reuse on third-party sites that are later breached. Microsoft は、漏洩した資格情報を多数発見しており、それらがお客様の組織の資格情報に一致する場合に、このレポートでお客様に報告します。ただし、そのためには、パスワード ハッシュの同期を有効にしておくか、クラウド専用 ID を所有している必要があります。Microsoft finds many of these leaked credentials and will tell you, in this report, if they match credentials in your organization – but only if you enable password hash sync or have cloud-only identities!
  • (たとえばランサムウェア攻撃で) オンプレミスの障害が発生した場合、パスワード ハッシュ同期を使用するクラウド認証に切り替えることができます。このバックアップ認証方法では、Azure Active Directory による認証が構成されたアプリ (Microsoft 365 など) へのアクセスを継続できます。In the event of an on-premises outage (for example, in a ransomware attack) you can switch over to using cloud authentication using password hash sync. This backup authentication method will allow you to continue accessing apps configured for authentication with Azure Active Directory, including Microsoft 365. この場合、IT スタッフはオンプレミスの停止が解決されるまで、個人のメール アカウントに頼ってデータを共有する必要はありません。In this case, IT staff won't need to resort to personal email accounts to share data until the on-premises outage is resolved.

パスワード ハッシュ同期のしくみについて、詳しくご確認ください。Learn more about how password hash sync works.

注意

パスワード ハッシュ同期を有効にしているときに Azure AD Domain Services を使用すると、Kerberos (AES 256) ハッシュとオプションで NTLM (RC4、ソルトなし) ハッシュも暗号化され、Azure AD と同期されます。If you enable password hash sync and are using Azure AD Domain services, Kerberos (AES 256) hashes and optionally NTLM (RC4, no salt) hashes will also be encrypted and synchronized to Azure AD.

AD FS エクストラネットのスマート ロックアウトを実装するImplement AD FS extranet smart lockout

Azure AD で直接認証されるようアプリケーションを構成している組織は、Azure AD スマート ロックアウトを利用できます。Organizations, which configure applications to authenticate directly to Azure AD benefit from Azure AD smart lockout. Windows Server 2012 R2 で AD FS を使っている場合は、AD FS のエクストラネット ロックアウト保護を実装します。If you use AD FS in Windows Server 2012R2, implement AD FS extranet lockout protection. Windows Server 2016 で AD FS を使っている場合は、エクストラネット スマート ロックアウトを実装します。If you use AD FS on Windows Server 2016, implement extranet smart lockout. AD FS スマート エクストラネット ロックアウトは、ユーザーが Active Directory からロックアウトされないようにしながら、AD FS に対するブルート フォース攻撃を防ぎます。AD FS Smart Extranet lockout protects against brute force attacks, which target AD FS while preventing users from being locked out in Active Directory.

本質的に安全な、より使いやすい資格情報を活用するTake advantage of intrinsically secure, easier to use credentials

Windows Hello を使用して、PC およびモバイル デバイスでパスワードを強力な 2 要素認証に置き換えることができます。Using Windows Hello, you can replace passwords with strong two-factor authentication on PCs and mobile devices. この認証はデバイスに安全に関連付けられた新しい種類のユーザー資格情報で構成され、生体認証または PIN が使用されます。This authentication consists of a new type of user credential that is tied securely to a device and uses a biometric or PIN.

ステップ 2. - 攻撃の対象となる領域を減らすStep 2 - Reduce your attack surface

漏洩したパスワードが広まりやすいことを考えると、組織において攻撃の対象となる領域を最小化することが重要です。Given the pervasiveness of password compromise, minimizing the attack surface in your organization is critical. 安全性が低い旧式のプロトコルの使用をやめ、アクセス エントリ ポイントを制限して、リソースへの管理アクセス権の制御を強化すると、攻撃の対象となる領域を減らせます。Eliminating use of older, less secure protocols, limiting access entry points, and exercising more significant control of administrative access to resources can help reduce the attack surface area.

レガシ認証をブロックするBlock legacy authentication

Azure AD による認証と会社データへのアクセスに、独自の古い方法がアプリで使用されている場合、組織には別のリスクが生じます。Apps using their own legacy methods to authenticate with Azure AD and access company data, pose another risk for organizations. レガシ認証が使用されているアプリは、POP3 クライアント、IMAP4 クライアント、SMTP クライアントなどです。Examples of apps using legacy authentication are POP3, IMAP4, or SMTP clients. レガシ認証アプリでは、ユーザーの代わりに認証が行われ、Azure AD による高度なセキュリティ評価の実行が妨げられます。Legacy authentication apps authenticate on behalf of the user and prevent Azure AD from doing advanced security evaluations. 代わりとなる最新の認証では、多要素認証と条件付きアクセスがサポートされているので、セキュリティ リスクを抑えられます。The alternative, modern authentication, will reduce your security risk, because it supports multi-factor authentication and Conditional Access. 次の 3 つのアクションをお勧めします。We recommend the following three actions:

  1. AD FS を使用している場合はレガシ認証をブロックする。Block legacy authentication if you use AD FS.
  2. 最新の認証を使用するよう SharePoint Online と Exchange Online を設定する。Setup SharePoint Online and Exchange Online to use modern authentication.
  3. Azure AD Premium がある場合は、条件付きアクセス ポリシーを使用してレガシ認証をブロックし、それ以外の場合は、Azure AD セキュリティの既定値を使用します。If you have Azure AD Premium, use Conditional Access policies to block legacy authentication, otherwise use Azure AD Security Defaults.

無効な認証エントリ ポイントをブロックするBlock invalid authentication entry points

侵害想定の考え方を取り入れて、ユーザー資格情報の漏洩が発生した場合にその影響を抑える必要があります。Using the assume breach mentality, you should reduce the impact of compromised user credentials when they happen. 環境内のアプリごとに有効なユース ケースを検討して、どのグループ、ネットワーク、デバイスなどの要素が承認されるかを判断し、残りをブロックします。For each app in your environment consider the valid use cases: which groups, which networks, which devices and other elements are authorized – then block the rest. Azure AD の条件付きアクセスでは、定義した特定の条件に基づいて、承認されたユーザーがどのようにアプリとリソースにアクセスするかを制御できます。With Azure AD Conditional Access, you can control how authorized users access their apps and resources based on specific conditions you define.

さまざまな Azure AD アプリケーションの同意アクセス許可と同意の種類、それらが組織のセキュリティ方針に与える意味を理解することが重要です。It’s important to understand the various Azure AD application consent experiences, the types of permissions and consent, and their implications on your organization’s security posture. 既定では、Azure AD のすべてのユーザーは、Microsoft ID プラットフォームを活用するアプリケーションに組織のデータにアクセスすることを許可できます。By default, all users in Azure AD can grant applications that leverage the Microsoft identity platform to access your organization’s data. ユーザーが自分で同意することを許可すると、Microsoft 365、Azure、その他のサービスと統合する便利なアプリケーションを簡単に入手できますが、慎重に使用し、監視しないとリスクが発生する可能性があります。While allowing users to consent by themselves does allow users to easily acquire useful applications that integrate with Microsoft 365, Azure and other services, it can represent a risk if not used and monitored carefully.

Microsoft では、攻撃の対象となる領域を減らし、このリスクを軽減するために、ユーザーの同意を制限することをお勧めしています。Microsoft recommends restricting user consent to help reduce your surface area and mitigate this risk. また、アプリの同意ポリシー (プレビュー) を使用して、エンドユーザーの同意を、検証された発行元のみと、選択したアクセス許可のみに制限することもできます。You may also use app consent policies (preview) to restrict end-user consent to only verified publishers and only for permissions you select. エンド ユーザーの同意を無効にした場合でも、以前の同意の許可は有効ですが、それより後のすべての同意操作は管理者が実行する必要があります。If end-user consent is restricted, previous consent grants will still be honored but all future consent operations must be performed by an administrator. 制限された場合、ユーザーは、統合された管理者の同意要求ワークフローまたは独自のサポート プロセスを通して管理者の同意を要求できます。For restricted cases, admin consent can be requested by users through an integrated admin consent request workflow or through your own support processes. エンドユーザーの同意を制限する前に、推奨事項を使用して、組織におけるこの変更を計画してください。Before restricting end-user consent, use our recommendations to plan this change in your organization. すべてのユーザーにアクセスを許可するアプリケーションについては、すべてのユーザーの代わりに同意を与え、個人としてまだ同意していないユーザーがアプリにアクセスできるようにすることを検討してください。For applications you wish to allow all users to access, consider granting consent on behalf of all users, making sure users who have not yet consented individually will be able to access the app. シナリオによってはアプリケーションを利用できるユーザーを限定する場合、アプリケーション割り当てと条件付きアクセスを利用し、特定のアプリへのユーザー アクセスを制限してください。If you do not want these applications to be available to all users in all scenarios, use application assignment and Conditional Access to restrict user access to specific apps.

ユーザーの摩擦を減らすために、サポート量を最小限に抑えるために、また、ユーザーが Azure AD 以外の資格情報でアプリケーションに新規登録することを防ぐために、ユーザーが新しいアプリケーションに関する管理者承認を要求できるようにしてください。Make sure users can request admin approval for new applications to reduce user friction, minimize support volume, and prevent users from signing up for applications using non-Azure AD credentials. 同意操作を規制したら、管理者はアプリと同意済みのアクセス許可を定期的に監査します。Once you regulate your consent operations, administrators should audit app and consented permissions on a regular basis.

Azure AD Privileged Identity Management を実装するImplement Azure AD Privileged Identity Management

さらに "侵害想定" に基づくと、セキュリティ侵害されたアカウントが特権ロールで操作され得る確率を最小限に抑える必要があります。Another impact of "assume breach" is the need to minimize the likelihood a compromised account can operate with a privileged role.

Azure AD Privileged Identity Management (PIM) は、以下をサポートしており、アカウントの特権を最小限に抑えるのに役立ちます。Azure AD Privileged Identity Management (PIM) helps you minimized account privileges by helping you:

  • 管理者ロールに割り当てられたユーザーを特定して管理する。Identify and manage users assigned to administrative roles.
  • 削除すべき未使用の特権ロールまたは余計な特権ロールを把握する。Understand unused or excessive privilege roles you should remove.
  • 多要素認証によって特権ロールが保護されるようルールを確立する。Establish rules to make sure privileged roles are protected by multi-factor authentication.
  • 特権タスクを完了するのに十分な期間のみ特権ロールが付与されるようルールを確立する。Establish rules to make sure privileged roles are granted only long enough to accomplish the privileged task.

Azure AD PIM を有効にして管理者ロールが割り当てられたユーザーを表示し、それらのロールの不必要なアカウントを削除します。Enable Azure AD PIM, then view the users who are assigned administrative roles and remove unnecessary accounts in those roles. 残りの特権ユーザーを永続から候補に変更します。For remaining privileged users, move them from permanent to eligible. 最後に、適切な変更制御により、これらの特権ロールにアクセスできる必要がある場合に安全にアクセスできるよう、適切なポリシーを確立します。Finally, establish appropriate policies to make sure when they need to gain access to those privileged roles, they can do so securely, with the necessary change control.

特権アカウントのプロセスをデプロイする一環として、自分自身をロックアウトしてしまった場合でも Azure AD にアクセスできるよう、少なくとも 2 つの緊急アカウントを作成するベスト プラクティスに従ってください。As part of deploying your privileged account process, follow the best practice to create at least two emergency accounts to make sure you still have access to Azure AD if you lock yourself out.

ステップ 3. - 脅威への対応を自動化するStep 3 - Automate threat response

Azure Active Directory には、検出と対応に時間差が生じないよう、攻撃を自動的に遮断する多数の機能が備わっています。Azure Active Directory has many capabilities that automatically intercept attacks, to remove the latency between detection and response. 犯罪者が環境に侵入するために使える時間を減らせれば、コストとリスクを抑えることができます。You can reduce the costs and risks, when you reduce the time criminals use to embed themselves into your environment. 実行できる具体的な手順は以下のとおりです。Here are the concrete steps you can take.

Azure AD Identity Protection を使用してユーザーのリスク セキュリティ ポリシーを実装するImplement user risk security policy using Azure AD Identity Protection

ユーザー リスクは、ユーザーの ID がセキュリティ侵害された確率を示すもので、ユーザーの ID に関連付けられているユーザー リスク検出に基づいて計算されます。User risk indicates the likelihood a user's identity has been compromised and is calculated based on the user risk detections that are associated with a user's identity. ユーザー リスク ポリシーは、特定のユーザーまたはグループに関してリスク レベルを評価する条件付きアクセスポリシーです。A user risk policy is a Conditional Access policy that evaluates the risk level to a specific user or group. 低、中、高のリスクレベルに基づいて、アクセスをブロックしたり、多要素認証を使用して安全なパスワードへの変更を要求したりするよう、ポリシーを構成できます。Based on Low, Medium, High risk-level, a policy can be configured to block access or require a secure password change using multi-factor authentication. Microsoft は、リスクの高いユーザーについて、安全なパスワードへの変更を要求することをお勧めします。Microsoft's recommendation is to require a secure password change for users on high risk.

[ユーザー] が選択された、リスクのフラグが設定されたユーザーを示すスクリーンショット。

Azure AD Identity Protection を使用してサインインのリスク ポリシーを実装するImplement sign-in risk policy using Azure AD Identity Protection

サインイン リスクは、アカウント所有者でないユーザーが ID を使用してサインオンを試みている確率です。Sign-in risk is the likelihood someone other than the account owner is attempting to sign on using the identity. サインイン リスク ポリシーは、特定のユーザーまたはグループに関してリスク レベルを評価する条件付きアクセスポリシーです。A sign-in risk policy is a Conditional Access policy that evaluates the risk level to a specific user or group. リスク レベル (高/中/低) に基づいて、アクセスをブロックしたり、多要素認証を適用したりするよう、ポリシーを構成できます。Based on the risk level (high/medium/low), a policy can be configured to block access or force multi-factor authentication. リスクが中以上のサインインには多要素認証を適用するようにしてください。Make sure you force multi-factor authentication on Medium or above risk sign-ins.

匿名の IP からのサインイン

ステップ 4 - クラウド インテリジェンスを利用するStep 4 - Utilize cloud intelligence

セキュリティ関連イベントの監査とログ、および関連する警告は、効率的な保護戦略に欠かせない構成要素です。Auditing and logging of security-related events and related alerts are essential components of an efficient protection strategy. セキュリティのログやレポートは、疑わしいアクティビティの電子記録となり、外部からネットワークへの侵入または内部からの攻撃が試みられたこと、または成功したことを示すパターンを検出するために役立ちます。Security logs and reports provide you with an electronic record of suspicious activities and help you detect patterns that may indicate attempted or successful external penetration of the network, and internal attacks. 監査機能を使うと、ユーザー アクティビティの監視、規制へのコンプライアンスの文書化、フォレンジック分析の実行などが可能になります。You can use auditing to monitor user activity, document regulatory compliance, do forensic analysis, and more. 警告によってセキュリティ イベントが通知されます。Alerts provide notifications of security events.

Azure AD を監視するMonitor Azure AD

Microsoft Azure のサービスや機能が提供する構成可能なセキュリティ監査およびログのオプションは、セキュリティ ポリシーやセキュリティ メカニズムのギャップを識別してセキュリティ侵害を防止するための対策を講じるうえで役立ちます。Microsoft Azure services and features provide you with configurable security auditing and logging options to help you identify gaps in your security policies and mechanisms and address those gaps to help prevent breaches. Azure のログと監査を使用できるほか、Azure Active Directory ポータルの監査アクティビティ レポートを使用できます。You can use Azure Logging and Auditing and use Audit activity reports in the Azure Active Directory portal.

ハイブリッド環境で Azure AD Connect Health を監視するMonitor Azure AD Connect Health in hybrid environments

Azure AD Connect Health による AD FS の監視では、潜在的な問題に関するより優れた分析情報と、AD FS インフラストラクチャへの攻撃の可視性が得られます。Monitoring AD FS with Azure AD Connect Health provides you with greater insight into potential issues and visibility of attacks on your AD FS infrastructure. Azure AD Connect Health では、詳細、解決手順、関連ドキュメントへのリンクが含まれた警告のほか、認証トラフィックに関するいくつかのメトリックの利用状況分析、パフォーマンスの監視、レポートが提供されます。Azure AD Connect Health delivers alerts with details, resolution steps, and links to related documentation; usage analytics for several metrics related to authentication traffic; performance monitoring and reports.

Azure AD Connect Health

Azure AD Identity Protection イベントを監視するMonitor Azure AD Identity Protection events

Azure AD Identity Protection は、通知、監視、およびレポートのツールであり、組織の ID に影響する潜在的な脆弱性を検出するために使用できます。Azure AD Identity Protection is a notification, monitoring and reporting tool you can use to detect potential vulnerabilities affecting your organization's identities. 感染しているデバイス、匿名の IP アドレス、疑わしいアクティビティに関連した IP アドレス、および不明な場所からのサインイン、漏洩した資格情報、あり得ない移動など、リスク検出を検出します。It detects risk detections, such as leaked credentials, impossible travel, and sign-ins from infected devices, anonymous IP addresses, IP addresses associated with the suspicious activity, and unknown locations. 通知アラートを有効にすると、危険な状態のユーザーのメールや週間ダイジェスト メールが届きます。Enable notification alerts to receive email of users at risk and/or a weekly digest email.

Azure AD Identity Protection で提供される 2 つの重要なレポートを、毎日監視する必要があります。Azure AD Identity Protection provides two important reports you should monitor daily:

  1. リスクの高いサインイン レポートでは、調査する必要があるユーザー サインイン アクティビティが明らかになります。正当な所有者がサインインを実行していない可能性があります。Risky sign-in reports will surface user sign-in activities you should investigate, the legitimate owner may not have performed the sign-in.
  2. リスクの高いユーザー レポートでは、侵害された可能性があるユーザー アカウントが明らかになります。たとえば、リークが検出された資格情報や、あり得ない移動イベントが発生する別の場所からサインインしたユーザーなどです。Risky user reports will surface user accounts that may have been compromised, such as leaked credential that was detected or the user signed in from different locations causing an impossible travel event.

スクリーンショットに、ユーザーとそのリスク レベルがある Azure AD Identity Protection のウィンドウが示されています。

監査アプリと同意されたアクセス許可Audit apps and consented permissions

だまされたユーザーが侵害された Web サイトやアプリに移動することで、それらがユーザーのプロファイル情報やメールなどのユーザー データにアクセスできるようになる可能性があります。Users can be tricked into navigating to a compromised web site or apps that will gain access to their profile information and user data, such as their email. 悪意のあるアクターは、受け取った同意されたアクセス許可を使用して、メールボックスの内容を暗号化し、メールボックス データを回復するための身代金を要求できます。A malicious actor can use the consented permissions it received to encrypt their mailbox content and demand a ransom to regain your mailbox data. ユーザーによって与えられたアクセス許可を管理者が見直し、監視します。あるいは、既定でユーザーが同意を与えられるようになっている場合、それを管理者が無効にします。Administrators should review and audit the permissions given by users or disable the ability of users to give consent by default.

ユーザーによって付与されたアクセス許可を監査するだけでなく、プレミアム環境で危険または望ましくない OAuth アプリケーションを検索する こともできます。In addition to auditing the permissions given by users, you can locate risky or unwanted OAuth applications in premium environments.

ステップ 5 - エンドユーザー セルフサービスを有効にするStep 5 - Enable end-user self-service

できるだけセキュリティと生産性のバランスをとる必要があります。As much as possible you'll want to balance security with productivity. 長期的なセキュリティの基盤を構築するという考え方と同様の方針の運用アプローチに従って、警戒を緩めないままユーザーに権限を与えることで、組織の手間を省くことができます。Along the same lines of approaching your journey with the mindset that you're setting a foundation for security in the long run, you can remove friction from your organization by empowering your users while remaining vigilant.

セルフサービス パスワード リセットを実装するImplement self-service password reset

Azure AD のセルフサービス パスワード リセット (SSPR) では、IT 管理者は簡単に、ユーザーがヘルプ デスクや管理者の手を借りずにパスワードやアカウントのリセットまたはロック解除を行えるようにできます。Azure AD's self-service password reset (SSPR) offers a simple means for IT administrators to allow users to reset or unlock their passwords or accounts without help desk or administrator intervention. このシステムには、ユーザーがいつパスワードをリセットしたかを追跡する詳細なレポートと、誤用または悪用について警告する通知が用意されています。The system includes detailed reporting that tracks when users have reset their passwords, along with notifications to alert you to misuse or abuse.

セルフサービス グループとアプリケーションのアクセスを実装するImplement self-service group and application access

Azure AD を使用すると、セキュリティ グループ、Microsoft 365 グループ、アプリケーション ロール、アクセス パッケージ カタログを使用して、管理者以外のユーザーがリソースへのアクセスを管理できます。Azure AD provides the ability to non-administrators to manage access to resources, using security groups, Microsoft 365 groups, application roles, and access package catalogs. セルフサービス グループ管理を使用すると、グループ所有者は、管理者ロールを割り当てられることなく、自分のグループを管理できます。Self-service group management enables group owners to manage their own groups, without needing to be assigned an administrative role. ユーザーは、自身の依頼の処理に管理者に頼らずに Microsoft 365 グループを作成および管理することもでき、未使用のグループも自動的に期限切れになります。Users can also create and manage Microsoft 365 groups without relying on administrators to handle their requests, and unused groups expire automatically. Azure AD エンタイトルメント管理を使用すると、包括的なアクセス要求ワークフローと自動有効期限を使用して委任と可視化をさらに高めることができます。Azure AD entitlement management further enables delegation and visibility, with comprehensive access request workflows and automatic expiration. 管理者以外のユーザーが所有するグループ、Teams、アプリケーション、および SharePoint Online サイト用に独自のアクセス パッケージを構成する機能を、それらのユーザーに委任することができます。これには、従業員のマネージャーやビジネス パートナー スポンサーの承認者としての構成など、アクセスを承認する必要があるユーザー用のカスタム ポリシーを使用します。You can delegate to non-administrators the ability to configure their own access packages for groups, Teams, applications, and SharePoint Online sites they own, with custom policies for who is required to approve access, including configuring employee's managers and business partner sponsors as approvers.

Azure AD アクセス レビューを実装するImplement Azure AD access reviews

Azure AD アクセス レビューでは、アクセス パッケージとグループ メンバーシップ、エンタープライズ アプリケーションへのアクセス、特権ロールの割り当てを管理して、セキュリティ標準を確実に維持できます。With Azure AD access reviews, you can manage access package and group memberships, access to enterprise applications, and privileged role assignments to make sure you maintain a security standard. ユーザー自身、リソース所有者、その他のレビュー担当者による通常の監視によって、ユーザーが必要なくなったアクセスを長期間にわたって保持しないですみます。Regular oversight by the users themselves, resource owners, and other reviewers ensure that users don't retain access for extended periods of time when they no longer need it.

まとめSummary

ID インフラストラクチャのセキュリティについては多数の側面があります。しかし、この 5 ステップのチェックリストを利用すれば、セキュリティで保護されたより安全な ID インフラストラクチャをすばやく実現できます。There are many aspects to a secure Identity infrastructure, but this five-step checklist will help you quickly accomplish a safer and secure identity infrastructure:

  • 資格情報を強化する。Strengthen your credentials.
  • 攻撃の対象となる領域を減らす。Reduce your attack surface area.
  • 脅威への対応を自動化する。Automate threat response.
  • クラウド インテリジェンスを利用します。Utilize cloud intelligence.
  • セルフヘルプによる、より予測可能で完全なエンドユーザー セキュリティを有効にする。Enable more predictable and complete end-user security with self-help.

Microsoft は、お客様が ID セキュリティの重要性を認識していることを理解しています。ぜひ、このドキュメントを、組織のセキュリティ体制を強化するためのロードマップとしてお役立てください。We appreciate how seriously you take Identity Security and hope this document is a useful roadmap to a more secure posture for your organization.

次のステップNext steps

推奨アクションの計画と展開にサポートが必要な場合は、Azure AD プロジェクト デプロイ計画をヘルプとして参照してください。If you need assistance to plan and deploy the recommendations, refer to the Azure AD project deployment plans for help.

これらの手順を完全に修了したら、Microsoft の ID セキュリティ スコアを使用します。これにより、最新のベスト プラクティスとセキュリティ上の脅威について常に把握し続けることができます。If you're confident all these steps are complete, use Microsoft’s Identity Secure Score, which will keep you up to date with the latest best practices and security threats.