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

クラウド中心のアーキテクチャでは、ID がセキュリティ保証の大部分の基礎を提供します。In cloud-focused architecture, identity provides the basis of a large percentage of security assurances. 従来の IT インフラストラクチャでは、外部の脅威からの保護を、インターネット エグレス ポイントのファイアウォールおよびネットワーク セキュリティ ソリューションに依存することが多かったのですが、これらのコントロールは、クラウド プロバイダー ネットワークまたはインターネットをまたいでアクセスされる共有サービスを含むクラウド アーキテクチャでは効果が低くなります。While legacy IT infrastructure often heavily relied on firewalls and network security solutions at the internet egress points for protection against outside threats, these controls are less effective in cloud architectures with shared services being accessed across cloud provider networks or the internet.

これらのサービスがホストされており、さまざまなクラウド リソースが動的にスピン アップおよびスピン ダウンされ、クラウドの顧客が共通のインフラストラクチャを共有する場合があり、従業員とユーザーがどこからでもデータやサービスにアクセスできることが期待されるネットワークを制御しない場合、簡潔なファイアウォール規則を作成するのは困難または不可能です。It is challenging or impossible to write concise firewall rules when you don’t control the networks where these services are hosted, different cloud resources spin up and down dynamically, cloud customers may share common infrastructure, and employees and users expect to be able to access data and services from anywhere. これらすべての機能を有効にするには、クラウド サービスで ID の認証と承認の制御に基づいてアクセスを管理することで、データやリソースを保護したり、どの要求を許可するかを決定したりする必要があります。To enable all these capabilities, you must manage access based on identity authentication and authorization controls in the cloud services to protect data and resources and to decide which requests should be permitted.

さらに、Azure AD のようなクラウドベースの ID ソリューションを使用すれば、多くの顧客のもとで大量のアクセス要求や脅威を観察することで得られた脅威インテリジェンスを応用できるため、従来の ID サービスでは不可能な追加のセキュリティ機能が提供されます。Additionally, using a cloud-based identity solution like Azure AD offers additional security features that legacy identity services cannot because they can apply threat intelligence from their visibility into a large volume of access requests and threats across many customers.

単一のエンタープライズ ディレクトリSingle enterprise directory

常勤従業員および企業リソースの ID を管理するための単一のエンタープライズ ディレクトリを確立するEstablish a single enterprise directory for managing identities of full-time employees and enterprise resources

ID のソースが単一かつ信頼できるものであれば、IT とセキュリティのすべての役割の明確さと一貫性が向上します。A single authoritative source for identities increases clarity and consistency for all roles in IT and Security. これにより、複雑さゆえの人為的なエラーや自動化失敗から生じるセキュリティ リスクが軽減されます。This reduces security risk from human errors and automation failures resulting from complexity. 単一の信頼できるソースを持つことで、ディレクトリに変更を加える必要があるチームは 1 つの場所でそれを実行でき、変更がどこでも効力を有するという確証が得られます。By having a single authoritative source, teams that need to make changes to the directory can do so in one place and have confidence that their change will take effect everywhere.

Azure の場合、単一の Azure Active Directory (Azure AD) インスタンス ディレクトリを、企業や組織のアカウントの信頼できるソースとして指定します。For Azure, designate a single Azure Active Directory (Azure AD) instance directory as the authoritative source for corporate/organizational accounts.

ID システムを同期するSynchronize identity systems

クラウド ID を既存の ID システムと同期するSynchronize your cloud identity with your existing identity systems

クラウドとオンプレミスの間で ID に一貫性があれば、人為的エラーとそれに起因するセキュリティ リスクが減少します。Consistency of identities across cloud and on-premises will reduce human errors and resulting security risk. 両方の環境でリソースを管理するチームは、セキュリティ保証を達成するために、一貫性があって信頼できるソースを必要とします。Teams managing resources in both environment need a consistent authoritative source to achieve security assurances.

Azure の場合は Azure AD Connect を使用して、Azure AD を、既存の信頼できるオンプレミスの Active Directory と同期します。For Azure, synchronize Azure AD with your existing authoritative on premises Active Directory using Azure AD connect. これは Office 365 の移行にも必要なため、Azure に移行する前や、開発プロジェクトが始まる前に実施済みであることはよくあります。This is also required for an Office 365 migration, so it is often already done before Azure migration and development projects begin. オンプレミスの管理者アカウントをクラウド ID プロバイダーと同期することの禁止およびクリティカルな影響があるアカウントの依存関係に関する項目で説明しているように、管理者アカウントは同期から除外する必要があることに注意してください。Note that administrator accounts should be excepted from synchronization as described in Don’t synchronize on-premises admin accounts to cloud identity providers and Critical impact account dependencies.

外部の関係者にはクラウド プロバイダーの ID ソースを使用するUse cloud provider identity source for third parties

ベンダー、パートナー、顧客は、会社のディレクトリに含めるのではなく、従業員以外のアカウントをホストするために設計されたクラウド ID サービスを使用します。Use cloud identity services designed to host non-employee accounts rather than including vendors, partners, and customers in a corporate directory.

これにより、常勤従業員に付与される既定のフル アクセス許可ではなく、適切なレベルのアクセスが外部の関係者に付与されるため、リスクが軽減されます。This reduces risk by granting the appropriate level of access to external entities instead of the full default permissions given to full-time employees. この最小限の特権アプローチ、また、外部アカウントと会社スタッフの明確な区別によって、これらのベクトルからの攻撃の防止と検出が容易になります。This least privilege approach and clear clearly differentiation of external accounts from company staff makes it easier to prevent and detect attacks coming in from these vectors. さらに、これらの ID の管理は外部の機関によって行われるため、関係者の生産性が向上し、企業の人事チームや IT チームに必要な労力が軽減されます。Additionally, management of these identities is done by the external also increases productivity by parties, reducing ingeffort required by company HR and IT teams.

たとえば、これらの機能は、Azure や Office 365 で使用されるものと同じである、Azure AD の ID およびアクセス許可モデルにネイティブに統合されますFor example, these capabilities natively integrate into the same Azure AD identity and permission model used by Azure and Office 365

管理者向けのパスワードレス認証または多要素認証Passwordless Or multi-factor authentication for admins

すべてのユーザーが最終的にはパスワードレス認証または多要素認証 (MFA) を使用するように転換していく必要があります。All users should be converted to use passwordless authentication or multi-factor authentication (MFA) over time. この推奨事項の詳細については、管理者のためのパスワードなし認証または多要素認証に関する管理セクション (管理者向け) を参照してください。The details of this recommendation are in the administration section Passwordless Or multi-factor authentication for admins FOR ADMINS. すべてのユーザーに同じ推奨事項が適用されますが、管理特権を持つアカウントには最初に、また最も厳格に適用する必要があります。The same recommendation applies to all users, but should be applied first and strongest to accounts with administrative privileges.

マネージド ID を使用して Azure 内のリソースへのアクセスを許可することで、アプリケーションによるパスワードの使用を減らすこともできますYou can also reduce use of passwords by applications using Managed Identities to grant access to resources in Azure

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

インターネットに接続するサービスでは、セキュリティで保護されないレガシ プロトコルを無効にします。Disable insecure legacy protocols for internet-facing services.

レガシ認証方法は、クラウドでホストされるサービスにとって最も脅威となる攻撃ベクトルの 1 つです。Legacy authentication methods are among the top attack vectors for cloud-hosted services. 多要素認証が登場する前に開発されたレガシ プロトコルは、パスワード以外の追加要素をサポートしていないため、パスワード スプレー攻撃、辞書攻撃、またはブルート フォース攻撃の主要な標的になっています。Created before multifactor-authentication existed, legacy protocols don’t support additional factors beyond passwords and are therefore prime targets for password spraying, dictionary, or brute force attacks. 例として、Office 365 の顧客に対するパスワード スプレー攻撃のほぼ 100% がレガシ プロトコルを使用しています。As an example nearly 100% of all password spray attacks against Office 365 customers use legacy protocols. また、これらの古いプロトコルには、アカウントのロックアウトやバックオフ タイマーといったその他の攻撃対策が不足していることがよくあります。Additionally, these older protocols frequently lack other attack countermeasures, such as account lockouts or back-off timers. Microsoft のクラウド上で実行されるサービスでレガシ プロトコルをブロックすると、アカウントの侵害成功が 66% 減少したことが確認されています。Services running on Microsoft’s cloud that block legacy protocols have observed a 66% reduction in successful account compromises.

Azure アカウントやその他の Azure AD ベースのアカウントで、レガシ プロトコルをブロックするように条件付きアクセスを構成します。For Azure and other Azure AD-based accounts, configure Conditional Access to block legacy protocols.

最新の認証方法をサポートする新しいクライアント ソフトウェアへの移行を望まないユーザーもいるので、レガシ認証を無効にすることは難しいかもしれません。Disabling legacy authentication can be difficult, as some users may not want to move to new client software that supports modern authentication methods. しかし、レガシ認証から徐々に距離を置くことはできます。However, moving away from legacy authentication can be done gradually. まず、メトリックを使用して認証プロバイダーからログを取り、まだ古いクライアントで認証しているユーザーの数を確認します。Start by using metrics and logging from your authentication provider to determine the how many users still authenticate with old clients. 次に、使用されていない下位レベルのプロトコルをすべて無効にし、レガシ プロトコルを使用していないすべてのユーザーに条件付きアクセスを設定します。Next, disable any down-level protocols that aren’t in use, and set up conditional access for all users who aren’t using legacy protocols. 最後に、アップグレード方法についてユーザーに十分な注意とガイダンスを与えてから、すべてのサービスのすべてのユーザーについてプロトコル レベルでレガシ認証をブロックします。Finally, give plenty of notice and guidance to users on how to upgrade before blocking legacy authentication for all users on all services at a protocol level.

オンプレミスの管理者アカウントをクラウド ID プロバイダーに同期しないDon’t synchronize on-premises admin accounts to cloud identity providers

エンタープライズ ID システムをクラウド ディレクトリと同期するとき、最も高い特権でオンプレミス リソースにアクセスできるアカウントは同期しないでください。Don’t synchronize accounts with the highest privilege access to on premises resources as you synchronize your enterprise identity systems with cloud directories.

これは、クラウド アカウントの侵害に成功した敵対者がオンプレミス資産の完全制御を奪取するリスクを軽減するためです。This mitigates the risk of an adversary pivoting to full control of on-premises assets following a successful compromise of a cloud account. これによって、インシデントのスコープを封じ込めて、大幅な拡大を防ぎます。This helps contain the scope of an incident from growing significantly.

Azure では、既存の Active Directory で高い特権を持つ Azure AD にはアカウントを同期しないようにします。For Azure, don’t synchronize accounts to Azure AD that have high privileges in your existing Active Directory. これは既定の Azure AD Connect 構成では既定でブロックされるため、この構成をカスタマイズしていないことを確認するだけで済みます。This is blocked by default in the default Azure AD Connect configuration, so you only need to confirm you haven’t customized this configuration.

これに関連するものとして、管理セクションには、重大な影響を及ぼすアカウントの依存関係に関するガイダンスがあります。このガイダンスの目的は、オンプレミスからクラウド資産への逆旋回リスクを軽減することです。This is related to the critical impact account dependencies guidance in the administration section that mitigates the inverse risk of pivoting from on-premises to cloud assets.

最新のパスワード保護対策を使用するUse modern password protection offerings

パスワードレスに移行できないアカウントに、最新かつ効果的な保護を提供します (管理者向けのパスワードレス認証または多要素認証)。Provide modern and effective protections for accounts that cannot go passwordless (Passwordless Or multi-factor authentication for admins).

レガシ ID プロバイダーでは、パスワードが複数の文字種で構成され所定の文字数以上であることを主にチェックしていましたが、実際には、このような制御ではパスワードのエントロピが不足して容易にクラッキングを許してしまうことが明らかになっています。Legacy identity providers mostly checked to make sure passwords had a good mix of character types and minimum length, but we have learned that these controls in practice led to passwords with less entropy that could be cracked easier:

現在の ID ソリューションは、パスワード スプレー、侵害リプレイ (他のサイトを侵害して入手したユーザー名とパスワードのペアをテストする手法。 "資格情報スタッフィング" とも呼ばれる)、フィッシング中間者攻撃といった、10 ~ 20 年前には存在さえしなかったタイプの攻撃に対応できる必要があります。Identity solutions today need to be able to respond to types of attacks that didn't even exist one or two decades ago such as password sprays, breach replays (also called “credential stuffing”) that test username/password pairs from other sites’ breaches, and phishing man-in-the-middle attacks. クラウド ID プロバイダーは、これらの攻撃に対する保護の提供に関して他に比肩しない立場にあります。Cloud identity providers are uniquely positioned to offer protection against these attacks. 大量のサインオンを処理するプロバイダーは、高度な異常検出を応用できる、また多様なデータ ソースを利用できるという強みを活かして、他の侵害で企業ユーザーのパスワードが見つかった場合に予防的に企業に通知したり、正当に見える特定のサインインが、予期しないホストや既知の悪意あるホストからのものでないことを検証したりします。Since they handle such large volumes of signons, they can apply better anomaly detection and use a variety of data sources to both proactively notify companies if their users’ passwords have been found in other breaches, as well as validate that any given sign in appears legitimate and is not coming from an unexpected or known-malicious host.

さらに、これらのチェックをサポートするためにパスワードをクラウドに同期することで、一部の攻撃を受けた際の回復性も向上します。Additionally, synchronizing passwords to the cloud to support these checks also add resiliency during some attacks. (Not)Petya 攻撃の影響を受ける顧客は、パスワード ハッシュを Azure AD に同期していた場合、業務を継続できました (対照的に、顧客向けの通信および IT サービスは、パスワードを同期していなかった組織にもほとんど影響しませんでした)。Customers affected by (Not)Petya attacks were able to continue business operations when password hashes were synced to Azure AD (vs. near zero communications and IT services for customers affected organizations that had not synchronized passwords).

Azure の場合、次の手順によって Azure AD で最新の保護を有効にしますFor Azure, enable modern protections in Azure AD by

  1. パスワード ハッシュを同期するように Azure AD Connect を構成しますConfigure Azure AD Connect to synchronize password hashes

  2. これらの問題を自動的に修復するか、レポートに基づいて手動で修復するかを選択します。Choose whether to automatically remediate these issues or manually remediate them based on a report:

    1. 自動施行 -Azure AD Identity Protection のリスク評価を利用して、条件付きアクセスによって高リスクのパスワードを自動的に修復しますAutomatic Enforcement - Automatically remediate high risk passwords with Conditional Access leveraging Azure AD Identity Protection risk assessments

    2. 報告して手動で修復 - レポートを確認し、手動でアカウントを修復しますReport & Manually Remediate - View reports and manually remediate accounts

Identity Protection リスク イベント API を使用して、Microsoft Graph を使ってプログラムからセキュリティの検出にアクセスします。Use the Identity Protection risk events API to gain programmatic access to security detections using Microsoft Graph.

クロスプラットフォームの資格情報管理を使用するUse cross-platform credential management

すべてのプラットフォーム (Windows、Linux、その他) およびクラウド サービスの認証に、単一の ID プロバイダーを使用します。Use a single identity provider for authenticating all platforms (Windows, Linux, and others) and cloud services.

すべての企業資産に対して単一の ID プロバイダーを使用すれば、管理とセキュリティが簡素化され、見落としや人為的ミスのリスクが最小化されます。A single identity provider for all enterprise assets will simplify management and security, minimizing the risk of oversights or human mistakes. 複数の ID ソリューション (または不完全なソリューション) をデプロイした結果、施行不能なパスワード ポリシー、侵害後にリセットされないパスワード、(たいていは安全な方法で保存されていない) パスワードの拡散、退職後の元従業員によるパスワードの保持などの問題が発生する可能性があります。Deploying multiple identity solutions (or an incomplete solution) can result in unenforceable password policies, passwords not reset after a breach, proliferation of passwords (often stored insecurely), and former employees retaining passwords after termination.

たとえば、Azure Active Directory を使用して、Windows、Linux、Azure、Office 365、アマゾン ウェブ サービス (AWS)Google Servicesレガシ オンプレミス アプリケーション (へのリモート アクセス)、およびサードパーティ製のサービス プロバイダーとしてのソフトウェアを認証できます。For example, Azure Active Directory can be used to authenticate Windows, Linux, Azure, Office 365, Amazon Web Services (AWS), Google Services, (remote access to) legacy on-premises applications, and third-party Software as a Service providers.

ユーザーの条件付きアクセスを強制する - ゼロ トラストEnforce conditional access for users - Zero Trust

ゼロ トラスト戦略をサポートするために、重要なセキュリティ属性の測定および施行を、すべてのユーザーの認証に含める必要があります。Authentication for all users should include measurement and enforcement of key security attributes to support a Zero Trust strategy. この推奨事項の詳細は、管理セクションの、管理者向けの条件付きアクセスの施行 (ゼロ トラスト) に関する項目を参照してください。The details of this recommendation are in the administration section Enforce conditional access for ADMINS (Zero Trust). すべてのユーザーに同じ推奨事項が適用されますが、管理特権を持つアカウントに最初に適用する必要があります。The same recommendation applies to all users, but should be applied first to accounts with administrative privileges.

マネージド ID を使用して Azure 内のリソースへのアクセスを許可することで、アプリケーションによるパスワードの使用を減らすこともできます。You can also reduce use of passwords by applications using Managed Identities to grant access to resources in Azure.

ユーザー向けの攻撃シミュレーションAttack simulation for users

ユーザーに対する攻撃を定期的にシミュレートすることで、ユーザーを教育し、必要な能力を身に付けさせます。Regularly simulate attacks against users to educate and empower them.

ユーザーは防御の重要な要素であるため、攻撃を防ぎ、攻撃に耐えるための知識とスキルをユーザーが確実に習得すれば、組織全体のリスクが低減されます。People are a critical part of your defense, so ensure they have the knowledge and skills to avoid and resist attacks will reduce your overall organizational risk.

Office 365 の攻撃シミュレーション機能、またはサードパーティ製の機能をいくつでも使用できます。You can use Office 365 Attack Simulation capabilities or any number of third-party offerings.

Azure で ID のベスト プラクティスを実装するImplementing Identity best practices in Azure

このセクションの推奨事項はそれぞれ、Azure Active Directory を使用して実装できます。Each of the recommendations from this section can be implemented using Azure Active Directory. これらの機能の使用方法の詳細については、以下の記事を参照してください。See the below articles for more information about how to use these features.

単一のエンタープライズ ディレクトリSingle Enterprise Directory

https://docs.microsoft.com/azure/active-directory/hybrid/whatis-hybrid-identity

ID システムを同期するSynchronize Identity Systems

https://docs.microsoft.com/azure/active-directory/connect/active-directory-aadconnect

外部の関係者にはクラウド プロバイダーの ID ソースを使用するUse Cloud Provider Identity Source for Third Parties

https://docs.microsoft.com/azure/active-directory/hybrid/how-to-connect-fed-compatibility

https://docs.microsoft.com/azure/active-directory/b2b/

https://docs.microsoft.com/azure/active-directory-b2c/

レガシ認証をブロックするBlock Legacy Authentication

オンプレミスの管理者アカウントをクラウド ID プロバイダーに同期しないDon’t Synchronize On-Premises Admin Accounts to Cloud Identity Providers

最新のパスワード保護対策を使用するUse Modern Password Protection Offerings

https://docs.microsoft.com/azure/active-directory/identity-protection/overview

https://docs.microsoft.com/azure/active-directory/authentication/concept-password-ban-bad-on-premises

https://docs.microsoft.com/azure/active-directory/reports-monitoring/concept-user-at-risk

https://docs.microsoft.com/azure/active-directory/reports-monitoring/concept-risky-sign-ins

クロスプラットフォームの資格情報管理を使用するUse Cross-Platform Credential Management

https://docs.microsoft.com/azure/virtual-machines/linux/login-using-aad

次のステップNext steps

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