この記事では、Azure ID 管理とアクセス制御セキュリティのベスト プラクティスのコレクションについて説明します。 これらのベスト プラクティスは、 Microsoft Entra ID のエクスペリエンスと、自分のようなお客様のエクスペリエンスから派生しています。
それぞれのベスト プラクティスについて、次の点を説明します。
- ベスト プラクティスの内容
- そのベスト プラクティスをお勧めする理由
- そのベスト プラクティスを実践しなかった場合に発生する可能性がある事態
- そのベスト プラクティスに代わる対処法
- そのベスト プラクティスを実践する方法
この Azure ID 管理とアクセス制御のセキュリティのベスト プラクティスに関する記事は、この記事の執筆時点に存在するコンセンサスの意見と Azure プラットフォームの機能と機能セットに基づいています。
この記事を書く際の目的は、デプロイ後のセキュリティ体制に関する一般的なロードマップを提供することです。このチェックリストでは、主要な機能とサービスの一部について説明する「ID インフラストラクチャをセキュリティで保護するための 5 つの手順」チェックリストに従います。
意見やテクノロジは時間の経過と同時に変化し、この記事は定期的に更新され、それらの変更が反映されます。
この記事で説明する Azure ID 管理とアクセス制御のセキュリティのベスト プラクティスは次のとおりです。
- ID をプライマリ セキュリティ境界として扱う
- ID 管理の一元化
- 接続されているテナントを管理する
- シングル サインオンの有効化
- 条件付きアクセスを有効にする
- 定期的なセキュリティ強化の計画
- パスワード管理を有効にする
- ユーザーに多要素認証を適用する
- ロールベースのアクセス制御を使用する
- 特権アカウントの露出を低くする
- リソースが配置されている場所を制御する
- ストレージ認証に Microsoft Entra ID を使用する
ID をプライマリ セキュリティ境界として扱う
多くのユーザーは、ID がセキュリティの主要な境界であると考えています。 これは、ネットワーク セキュリティに関する従来の焦点からの変化です。 ネットワーク境界はますます多孔質化し続け、 BYOD デバイスとクラウド アプリケーションが爆発的に爆発する前ほど境界防御を効果的に行うことはできません。
Microsoft Entra ID は、ID とアクセスの管理のための Azure ソリューションです。 Microsoft Entra ID は、Microsoft のマルチテナントのクラウドベースのディレクトリおよび ID 管理サービスです。 これには、主要なディレクトリ サービス、アプリケーション アクセスの管理、および ID 保護の機能が 1 つのソリューションとして統合されています。
次のセクションでは、Microsoft Entra ID を使用した ID とアクセス セキュリティのベスト プラクティスを示します。
ベスト プラクティス: ユーザー ID とサービス ID に関するセキュリティ制御と検出を中心にします。 詳細: Microsoft Entra ID を使用して、コントロールと ID を併置します。
ID 管理の一元化
ハイブリッド ID シナリオでは、オンプレミスとクラウドのディレクトリを統合することをお勧めします。 統合により、IT チームは、アカウントの作成場所に関係なく、1 つの場所からアカウントを管理できます。 統合は、クラウドとオンプレミスの両方のリソースにアクセスするための共通 ID を提供することで、ユーザーの生産性を高めるのにも役立ちます。
ベスト プラクティス: 1 つの Microsoft Entra インスタンスを確立します。 一貫性と単一の権限のあるソースにより、明確さが増し、ヒューマン エラーや構成の複雑さによるセキュリティ リスクが軽減されます。
詳細: 企業アカウントと組織アカウントの権限のあるソースとして、単一の Microsoft Entra ディレクトリを指定します。
ベスト プラクティス: オンプレミスのディレクトリを Microsoft Entra ID と統合します。
詳細: Microsoft Entra Connect を使用して、オンプレミスのディレクトリをクラウド ディレクトリと同期します。
注
Microsoft Entra Connect のパフォーマンスに影響する要因があります。 パフォーマンスの低いシステムがセキュリティと生産性を妨げるのを防ぐために、Microsoft Entra Connect に十分な容量があることを確認します。 大規模または複雑な組織 (100,000 を超えるオブジェクトをプロビジョニングする組織) は、Microsoft Entra Connect の実装を最適化するために 推奨事項 に従う必要があります。
ベスト プラクティス: 既存の Active Directory インスタンスで高い特権を持つ Microsoft Entra ID にアカウントを同期しないでください。
詳細: これらのアカウントを除外する既定の Microsoft Entra Connect 構成 は変更しないでください。 この構成により、敵対者がクラウドからオンプレミスの資産にピボットするリスクが軽減されます (大規模なインシデントが発生する可能性があります)。
ベスト プラクティス: パスワード ハッシュ同期を有効にします。
詳細: パスワード ハッシュ同期は、オンプレミスの Active Directory インスタンスからクラウドベースの Microsoft Entra インスタンスにユーザー パスワード ハッシュを同期するために使用される機能です。 この同期は、以前の攻撃から再生される漏洩した資格情報から保護するのに役立ちます。
Active Directory フェデレーション サービス (AD FS) またはその他の ID プロバイダーとのフェデレーションを使用する場合でも、必要に応じて、オンプレミス サーバーが失敗したり、一時的に使用できなくなったりした場合に備えて、パスワード ハッシュ同期をバックアップとして設定できます。 この同期により、ユーザーはオンプレミスの Active Directory インスタンスへのサインインに使用するのと同じパスワードを使用して、サービスにサインインできます。 また、ユーザーが Microsoft Entra ID に接続されていない他のサービスで同じメール アドレスとパスワードを使用している場合に、同期されたパスワード ハッシュと侵害されたパスワードを比較することで、Id Protection が侵害された資格情報を検出することもできます。
詳細については、「 Microsoft Entra Connect Sync を使用してパスワード ハッシュ同期を実装する」を参照してください。
ベスト プラクティス: 新しいアプリケーション開発では、認証に Microsoft Entra ID を使用します。
詳細: 正しい機能を使用して認証をサポートします。
- 従業員向けの Microsoft Entra ID
- ゲスト ユーザーと外部パートナー向けの Microsoft Entra B2B
- Microsoft Entra External ID を使用して、顧客がアプリケーションを使用する際のプロファイルのサインアップ、サインイン、および管理方法を制御する
オンプレミスの ID をクラウド ID と統合していない組織は、アカウントの管理においてより多くのオーバーヘッドを抱える可能性があります。 このオーバーヘッドによって、ミスやセキュリティ違反の可能性が高まります。
注
重要なアカウントが存在するディレクトリを選択し、使用する管理ワークステーションを新しいクラウド サービスまたは既存のプロセスで管理するかどうかを選択する必要があります。 既存の管理および ID プロビジョニング プロセスを使用すると、一部のリスクが減少する可能性がありますが、攻撃者がオンプレミス アカウントを侵害し、クラウドにピボットするリスクを生み出す可能性もあります。 異なるロール (IT 管理者とビジネス ユニット管理者など) に対して異なる戦略を使用できます。 2 つのオプションがあります。 最初のオプションは、オンプレミスの Active Directory インスタンスと同期されていない Microsoft Entra アカウントを作成することです。 管理者ワークステーションを Microsoft Entra ID に参加させ、Microsoft Intune を使用して管理および修正プログラムを適用できます。 2 つ目のオプションは、オンプレミスの Active Directory インスタンスに同期することで、既存の管理者アカウントを使用することです。 管理とセキュリティのために、Active Directory ドメイン内の既存のワークステーションを使用します。
接続されているテナントを管理する
セキュリティ組織では、リスクを評価し、組織のポリシーと規制要件に従っているかどうかを判断するための可視性が必要です。 セキュリティ組織は、運用環境とネットワークに接続されているすべてのサブスクリプションを ( Azure ExpressRoute または サイト間 VPN 経由で) 可視化する必要があります。 Microsoft Entra ID の グローバル管理者 は、 ユーザー アクセス管理者 ロールへのアクセス権を昇格させ、環境に接続されているすべてのサブスクリプションとマネージド グループを表示できます。
すべての Azure サブスクリプションと管理グループを管理するためのアクセス権の昇格に関するページを参照して、自分とセキュリティ グループが環境に接続されているすべてのサブスクリプションまたは管理グループを確実に表示できるようにします。 リスクを評価した後、この昇格されたアクセス権を削除する必要があります。
シングル サインオンの有効化
モバイルファーストのクラウドファーストの世界では、どこからでもデバイス、アプリ、サービスへのシングル サインオン (SSO) を有効にして、いつでもユーザーの生産性を高めたいと考えています。 複数の ID ソリューションを管理する場合、これは IT だけでなく、複数のパスワードを覚えておく必要があるユーザーの管理上の問題になります。
すべてのアプリとリソースに同じ ID ソリューションを使用することで、SSO を実現できます。 また、ユーザーは同じ資格情報のセットを使用して、必要なリソース (リソースがオンプレミスかクラウドかに関係なく) にサインインしてアクセスできます。
ベスト プラクティス: SSO を有効にします。
詳細: Microsoft Entra ID は 、オンプレミスの Active Directory をクラウドに拡張します。 ユーザーは、ドメインに参加しているデバイス、会社のリソース、仕事を完了するために必要なすべての Web アプリケーションと SaaS アプリケーションに、プライマリの職場または学校アカウントを使用できます。 ユーザーは複数のユーザー名とパスワードのセットを覚える必要はありません。また、組織グループのメンバーシップと従業員としての状態に基づいて、アプリケーション アクセスを自動的にプロビジョニング (またはプロビジョニング解除) できます。 また、ギャラリー アプリまたは Microsoft Entra アプリケーション プロキシを使用して開発および公開した独自のオンプレミス アプリに対して、そのアクセスを制御できます。
SSO を使用して、ユーザーが Microsoft Entra ID の職場または学校アカウントに基づいて SaaS アプリケーション にアクセスできるようにします。 これは、Microsoft SaaS アプリだけでなく、 Google Apps や Salesforce などの他のアプリにも適用されます。 SAML ベースの ID プロバイダーとして Microsoft Entra ID を使用するようにアプリケーションを構成できます。 セキュリティコントロールとして、Microsoft Entra ID は、ユーザーが Microsoft Entra ID を介してアクセスを許可されていない限り、アプリケーションにサインインできるトークンを発行しません。 アクセス権は、直接付与することも、ユーザーがメンバーになっているグループを介して付与することもできます。
ユーザーとアプリケーションの SSO を確立するための共通の ID を作成していない組織は、ユーザーが複数のパスワードを持つ事態によりさらされやすくなります。 これらのシナリオにより、ユーザーがパスワードを再利用したり、脆弱なパスワードを使用したりする可能性が高くなります。
条件付きアクセスを有効にする
ユーザーは、どこからでもさまざまなデバイスとアプリを使用して、組織のリソースにアクセスできます。 IT 管理者は、これらのデバイスがセキュリティとコンプライアンスの標準を満たしているかどうかを確認する必要があります。 リソースにアクセスできるユーザーだけに焦点を当てるだけでは十分ではありません。
セキュリティと生産性のバランスを取るためには、アクセスの制御に関する決定を行う前に、リソースへのアクセス方法を考慮する必要があります。 Microsoft Entra 条件付きアクセスにより、この要件に対処できます。 条件付きアクセスを使用すると、クラウド アプリへのアクセスに関する条件に基づいて、アクセス制御の決定を自動的に行うことができます。
ベスト プラクティス: 会社のリソースへのアクセスを管理および制御します。
詳細: SaaS アプリと Microsoft Entra ID に接続されたアプリのグループ、場所、アプリケーションの秘密度に基づいて、一般的な Microsoft Entra 条件付きアクセス ポリシー を構成します。
ベスト プラクティス: レガシ認証プロトコルをブロックします。
詳細: 攻撃者は、毎日古いプロトコルの弱点を悪用しています (特にパスワード スプレー攻撃)。
レガシ プロトコルをブロックするように条件付きアクセスを構成します。
定期的なセキュリティ強化の計画
セキュリティは常に進化しており、クラウドと ID 管理フレームワークに組み込んで、環境をセキュリティで保護するための新しい方法を定期的に示し、新しい方法を発見することが重要です。
ID セキュリティ スコアは、セキュリティ体制を客観的に測定し、将来のセキュリティ改善の計画に役立つ数値スコアを提供するために Microsoft が公開する推奨されるセキュリティ コントロールのセットです。 また、他の業界のスコアと比較して、時間の経過に伴う独自の傾向を表示することもできます。
ベスト プラクティス: 業界のベスト プラクティスに基づいて、定期的なセキュリティ レビューと改善を計画します。
詳細: ID セキュリティ スコア機能を使用して、時間の経過に伴う改善点をランク付けします。
パスワード管理を有効にする
複数のテナントがある場合、またはユーザーが自分のパスワードを リセットできるようにする場合は、適切なセキュリティ ポリシーを使用して不正使用を防ぐことが重要です。
ベスト プラクティス: ユーザーのセルフサービス パスワード リセット (SSPR) を設定します。
詳細: Microsoft Entra ID のセルフサービス パスワード リセット 機能を使用します。
ベスト プラクティス: SSPR が本当に使用されているかどうか、またその方法を監視します。
詳細: Microsoft Entra ID パスワード リセット登録アクティビティ レポートを使用して、登録しているユーザーを監視します。 Microsoft Entra ID で提供されるレポート機能によって、質問に対する答えをあらかじめ用意されたレポートから得ることができます。 適切にライセンスを付与されている場合は、カスタム クエリを作成することもできます。
ベスト プラクティス: クラウドベースのパスワード ポリシーをオンプレミス インフラストラクチャに拡張する。
詳細: クラウドベースのパスワード変更の場合と同じチェックをオンプレミスのパスワード変更に対して実行することで、組織内のパスワード ポリシーを強化します。 Windows Server Active Directory エージェントの Microsoft Entra パスワード保護 をオンプレミスにインストールして、禁止パスワード リストを既存のインフラストラクチャに拡張します。 オンプレミスでパスワードを変更、設定、またはリセットするユーザーと管理者は、クラウド専用ユーザーと同じパスワード ポリシーに準拠する必要があります。
ユーザーに多要素認証を適用する
すべてのユーザーに対して 2 段階認証を要求することをお勧めします。 これには、組織内の管理者およびアカウントが侵害された場合に重大な影響を及ぼす可能性のあるその他のユーザー (財務担当者など) が含まれます。
2 段階認証を要求するオプションは複数あります。 最適なオプションは、目標、実行している Microsoft Entra エディション、ライセンス プログラムによって異なります。 ユーザーが最適なオプションを判断するために 2 段階認証を要求する方法を参照してください。 ライセンスと価格の詳細については、 Microsoft Entra ID と Microsoft Entra 多要素認証 の価格に関するページを参照してください。
2 段階認証を有効にするオプションと利点を次に示します。
オプション 1: Microsoft Entra セキュリティの既定値を使用して、すべてのユーザーとログイン方法に対して MFA を有効にする
利点: このオプションを使用すると、次の厳格なポリシーを使用して、環境内のすべてのユーザーに対して MFA を簡単かつ迅速に適用できます。
- 管理者アカウントと管理ログオン メカニズムにチャレンジします
- すべてのユーザーに Microsoft Authenticator 経由の MFA チャレンジを要求します
- レガシ認証プロトコルを制限します。
この方法はすべてのライセンス レベルで使用できますが、既存の条件付きアクセス ポリシーと併用することはできません。 詳細については、Microsoft Entra のセキュリティの既定値に関するページを参照してください。
オプション 2: ユーザーの状態を変更して多要素認証を有効にする。
利点: これは、2 段階認証を必要とする従来の方法です。
クラウドでの Microsoft Entra 多要素認証と Azure Multi-Factor Authentication Server の両方で機能します。 この方法を使用すると、ユーザーはサインインするたびに 2 段階認証を実行するよう求められ、条件付きアクセス ポリシーがオーバーライドされます。
多要素認証を有効にする必要がある場所を決定するには、「 組織に適した Microsoft Entra 多要素認証のバージョン」を参照してください。
オプション 3: 条件付きアクセス ポリシーを使用して多要素認証を有効にする。
利点: このオプションを使用すると、 条件付きアクセスを使用して、特定の条件下で 2 段階認証を求められます。 特定の条件としては、異なる場所、信頼されていないデバイス、または危険と見なされるアプリケーションからのユーザーのサインインを指定できます。 2 段階認証を要求する特定の条件を定義すると、要求のメッセージがユーザーに繰り返し表示されないようにすることができます。このようなメッセージは、不快なユーザー エクスペリエンスとなり得ます。
これは、ユーザーの 2 段階認証を有効にするうえで最も柔軟性の高い手段です。 条件付きアクセス ポリシーを有効にする方法は、クラウド内の Microsoft Entra 多要素認証に対してのみ機能します。これは、Microsoft Entra ID のプレミアム機能です。 この方法の詳細については、「 クラウドベースの Microsoft Entra 多要素認証をデプロイする」を参照してください。
オプション 4: リスクベースの条件付きアクセス ポリシーを評価して、条件付き アクセス ポリシーで多要素認証を有効にする。
利点: このオプションを使用すると、次のことが可能になります。
- 組織の ID に影響する潜在的な脆弱性を検出します。
- 組織の ID に関連する検出された疑わしいアクションに対する自動応答を構成します。
- 疑わしいインシデントを調査し、適切なアクションを実行して解決します。
この方法では、Microsoft Entra ID Protection のリスク評価を使用して、すべてのクラウド アプリケーションのユーザーおよびサインインのリスクに基づいて 2 段階認証が要求されるかどうかを判断します。 この方法を使用するには、Microsoft Entra ID P2 ライセンスが必要です。 この方法の詳細については、 Microsoft Entra ID Protection を参照してください。
注
オプション 2 (ユーザーの状態を変更することで多要素認証を有効にする) では、条件付きアクセス ポリシーをオーバーライドします。 オプション 3 および 4 では条件付きアクセス ポリシーを使用するため、オプション 2 をそれらと共に使用することはできません。
2 段階認証など、ID 保護のレイヤーを追加しない組織は、資格情報の盗難攻撃の影響を受けやすくなります。 資格情報盗用攻撃はデータの侵害につながる可能性があります。
ロールベースのアクセス制御を使用する
クラウド リソースのアクセス管理は、クラウドを使用するすべての組織にとって重要です。 Azure ロールベースのアクセス制御 (Azure RBAC) は、Azure リソースにアクセスできるユーザー、そのユーザーがそれらのリソースに対して実行できること、およびそのユーザーがアクセスできる領域を管理するのに役立ちます。
Azure で特定の機能を担当するグループまたは個々のロールを指定すると、セキュリティ リスクを引き起こした人間や自動化のエラーにつながる混乱を回避できます。 データ アクセスにセキュリティ ポリシーを適用する組織では、 知る必要性 と 最小限の特権 のセキュリティ原則に基づいてアクセスを制限することが不可欠です。
セキュリティ チームは、リスクを評価して修復するために、Azure リソースを可視化する必要があります。 セキュリティ チームが運用上の責任を負う場合は、ジョブを実行するための追加のアクセス許可が必要です。
Azure RBAC を使用して、特定のスコープでユーザー、グループ、アプリケーションにアクセス許可を割り当てることができます。 ロール割り当てのスコープには、サブスクリプション、リソース グループ、または単独のリソースを指定できます。
ベスト プラクティス: チーム内で職務を分離し、職務を遂行するために必要なユーザーへのアクセス権のみを付与します。 すべてのユーザーに Azure サブスクリプションまたはリソースに無制限のアクセス許可を付与する代わりに、特定のスコープで特定のアクションのみを許可します。
詳細: Azure の Azure 組み込みロール を使用して、ユーザーに特権を割り当てます。
注
特定のアクセス許可によって不要な複雑さと混乱が生じ、何かを壊すのを恐れずに修正するのが難しい "レガシ" 構成に蓄積されます。 リソース固有のアクセス許可は避けてください。 代わりに、エンタープライズ全体のアクセス許可には管理グループを使用し、サブスクリプション内のアクセス許可にはリソース グループを使用します。 ユーザー固有のアクセス許可は使用しないでください。 代わりに、Microsoft Entra ID のグループにアクセス権を割り当てます。
ベスト プラクティス: リスクを評価して修復できるように、Azure の責任を持つセキュリティ チームに Azure リソースを表示するアクセス権を付与します。
詳細: セキュリティ チームに Azure RBAC セキュリティ閲覧者 ロールを付与します。 責任の範囲に応じて、ルート管理グループまたはセグメント管理グループを使用できます。
- すべてのエンタープライズ リソースを担当するチームのルート管理グループ
- 範囲が制限されたチームのセグメント管理グループ (一般的には規制またはその他の組織の境界が原因)
ベスト プラクティス: 運用上の直接的な責任を持つセキュリティ チームに適切なアクセス許可を付与します。
詳細: Azure の組み込みロールで適切なロールの割り当てを確認します。 組み込みロールが組織の特定のニーズを満たしていない場合は、 Azure カスタム ロールを作成できます。 組み込みロールと同様に、サブスクリプション、リソース グループ、およびリソース スコープでユーザー、グループ、サービス プリンシパルにカスタム ロールを割り当てることができます。
ベスト プラクティス: Microsoft Defender for Cloud に、それを必要とするセキュリティ ロールへのアクセス権を付与します。 Defender for Cloud を使用すると、セキュリティ チームはリスクをすばやく特定して修復できます。
詳細: これらのニーズを持つセキュリティ チームを Azure RBAC セキュリティ管理者 ロールに追加すると、セキュリティ ポリシーの表示、セキュリティ状態の表示、セキュリティ ポリシーの編集、アラートと推奨事項の表示、アラートと推奨事項の無視を行うことができます。 これは、責任の範囲に応じて、ルート管理グループまたはセグメント管理グループを使用して行うことができます。
Azure RBAC などの機能を使用してデータ アクセス制御を適用しない組織は、ユーザーに必要以上の特権を付与している可能性があります。 これにより、ユーザーが必要ではない種類のデータ (ビジネスへの影響が大きいなど) にアクセスできるようにすることで、データの侵害につながる可能性があります。
特権アカウントの露出を低くする
特権アクセスのセキュリティ保護は、ビジネス資産を保護するための重要な最初のステップです。 セキュリティで保護された情報またはリソースへのアクセス権を持つユーザーの数を最小限に抑えることで、悪意のあるユーザーがこのようなアクセス権を手にしたり、権限のあるユーザーの不注意で機微なリソースのセキュリティが損なわれたりする可能性が抑えられます。
特権アカウントとは、IT システムを管理するアカウントです。 サイバー攻撃では、組織のデータやシステムへのアクセス手段を得るために、このようなアカウントが標的にされます。 特権アクセスを保護するには、悪意のあるユーザーにさらされる危険からアカウントとシステムを分離する必要があります。
サイバー攻撃者に対する特権アクセスをセキュリティで保護するために、ロードマップを作成して従うことをお勧めします。 Microsoft Entra ID、Microsoft Azure、Microsoft 365、およびその他のクラウド サービスで管理または報告される ID とアクセスをセキュリティで保護するための詳細なロードマップの作成については、 Microsoft Entra ID でのハイブリッドデプロイとクラウドデプロイの特権アクセスのセキュリティ保護に関するページを参照してください。
次に、 Microsoft Entra ID でのハイブリッドおよびクラウドデプロイの特権アクセスのセキュリティ保護に関するベスト プラクティスを示します。
ベスト プラクティス: 特権アカウントへのアクセスを管理、制御、監視する。
詳細: Microsoft Entra Privileged Identity Management を有効にします。 Privileged Identity Management を有効にすると、特権アクセス ロールが変更されたという電子メール通知を受け取ります。 これらの通知により、ディレクトリ内の高い特権ロールに追加されたユーザーが早期に警告されます。
ベスト プラクティス: すべての重要な管理者アカウントが Microsoft Entra アカウントで管理されていることを確認します。 詳細: 重要な管理者ロール (hotmail.com、live.com、outlook.com などの Microsoft アカウント) からコンシューマー アカウントを削除します。
ベスト プラクティス: すべての重要な管理者ロールが、管理特権を侵害するフィッシングやその他の攻撃を回避するために、管理タスク用に個別のアカウントを持っていることを確認します。
詳細: 管理タスクの実行に必要な特権が割り当てられている別の管理者アカウントを作成します。 Microsoft 365 の電子メールや任意の Web 閲覧など、日常的に使用する生産性向上ツールには、これらの管理者アカウントを使用できないようにします。
ベスト プラクティス: 高い特権を持つロール内のアカウントを特定して分類します。
詳細: Microsoft Entra Privileged Identity Management を有効にした後、グローバル管理者、特権ロール管理者、およびその他の高い特権ロールを持つユーザーを表示します。 これらのロールで不要になったアカウントを削除し、管理者ロールに割り当てられている残りのアカウントを分類します。
- 管理ユーザーに個別に割り当てられ、管理以外の目的 (個人用メールなど) に使用できます。
- 管理ユーザーに個別に割り当てられ、管理目的にのみ指定されている
- 複数のユーザー間で共有される
- 非常時のアクセス シナリオ用
- 自動スクリプト用
- 外部ユーザー用
ベスト プラクティス: "Just In Time" (JIT) アクセスを実装して、特権の公開時間をさらに短縮し、特権アカウントの使用の可視性を高めます。
詳細: Microsoft Entra Privileged Identity Management を使用すると、次のことができます。
- ユーザーが自分の特権 JIT のみを使用するように制限します。
- 権限が自動的に取り消される、短縮された期間のロールを割り当てます。
ベスト プラクティス: 少なくとも 2 つの緊急アクセス アカウントを定義します。
詳細: 緊急アクセス アカウントは、組織が既存の Microsoft Entra 環境で特権アクセスを制限するのに役立ちます。 これらのアカウントは高い特権を持ち、特定の個人には割り当てられません。 緊急アクセスアカウントは、通常の管理アカウントを使用できないシナリオに限定されます。 組織は、緊急アカウントの使用を必要な時間のみに制限する必要があります。
グローバル管理者ロールに割り当てられているアカウントまたは資格のあるアカウントを評価します。 (緊急アクセスを目的とした) *.onmicrosoft.com
ドメインを使用してクラウド専用アカウントが表示されない場合は、それらを作成します。 詳細については、「 Microsoft Entra ID での緊急アクセス管理アカウントの管理」を参照してください。
ベスト プラクティス: 緊急事態が発生した場合の "非常時" プロセスを用意します。
詳細: Microsoft Entra ID でのハイブリッドおよびクラウドデプロイの特権アクセスのセキュリティ保護に関する記事の手順に従います。
ベスト プラクティス: すべての重要な管理者アカウントをパスワードレスにする (優先する) か、多要素認証を必要とします。
詳細: Microsoft Authenticator アプリ を使用して、パスワードを使用せずに Microsoft Entra アカウントにサインインします。
Windows Hello for Business と同様に、Microsoft Authenticator はキーベースの認証を使用して、デバイスに関連付けられ、生体認証または PIN を使用するユーザー資格情報を有効にします。
1 つ以上の Microsoft Entra 管理者ロール (グローバル管理者、特権ロール管理者、Exchange Online 管理者、SharePoint Online 管理者) に永続的に割り当てられているすべてのユーザーに対して、サインイン時に Microsoft Entra 多要素認証を要求します。 管理者アカウントの多要素認証を有効にし、管理者アカウント ユーザーが登録されていることを確認します。
ベスト プラクティス: 重要な管理者アカウントの場合は、運用タスクが許可されていない管理者ワークステーション (閲覧や電子メールなど) を用意します。 これにより、閲覧やメールを使用する攻撃ベクトルから管理者アカウントが保護され、重大なインシデントのリスクが大幅に低下します。
詳細: 管理ワークステーションを使用します。 ワークステーションセキュリティのレベルを選択します。
- 安全性の高い生産性デバイスは、閲覧やその他の生産性タスクに高度なセキュリティを提供します。
- Privileged Access Workstation (PAW) は 、機密性の高いタスクに対するインターネット攻撃や脅威ベクトルから保護された専用のオペレーティング システムを提供します。
ベスト プラクティス: 従業員が組織を離れたときの管理者アカウントのプロビジョニング解除。
詳細: 従業員が組織を離れるときに管理者アカウントを無効または削除するプロセスを用意します。
ベスト プラクティス: 現在の攻撃手法を使用して、管理者アカウントを定期的にテストします。
詳細: Microsoft 365 攻撃シミュレーターまたはサードパーティのオファリングを使用して、組織で現実的な攻撃シナリオを実行します。 これは、実際の攻撃が発生する前に脆弱なユーザーを見つけるのに役立ちます。
ベスト プラクティス: 最も頻繁に使用される攻撃の手法を軽減するための手順を実行します。
詳細: 職場または学校アカウントに切り替える必要がある管理者ロールの Microsoft アカウントを特定する
グローバル管理者アカウントの個別のユーザー アカウントとメール転送を確認する
すべての特権ロールのユーザーと公開されたユーザーに対して多要素認証を要求する
Microsoft 365 セキュリティ スコアを取得する (Microsoft 365 を使用している場合)
Microsoft 365 セキュリティ ガイダンスを確認する (Microsoft 365 を使用している場合)
Microsoft 365 アクティビティ監視を構成する (Microsoft 365 を使用している場合)
特権アクセスをセキュリティで保護しないと、高い特権を持つロールのユーザーが多すぎて、攻撃に対して脆弱である可能性があります。 サイバー攻撃者を含む悪意のあるアクターは、多くの場合、管理者アカウントやその他の特権アクセスの要素を標的にして、資格情報の盗難を使用して機密データやシステムにアクセスします。
リソースが作成される場所を制御する
クラウド オペレーターが組織のリソースを管理するために必要な規則を破らないようにしながら、タスクを実行できるようにすることは非常に重要です。 リソースが作成される場所を制御する組織は、これらの場所をハード コーディングする必要があります。
Azure Resource Manager を使用して、明示的に拒否されるアクションまたはリソースを定義するセキュリティ ポリシーを作成できます。 これらのポリシー定義は、サブスクリプション、リソース グループ、個々のリソースなど、目的のスコープで割り当てます。
注
セキュリティ ポリシーは、Azure RBAC と同じではありません。 実際には、Azure RBAC を使用して、ユーザーがそれらのリソースを作成することを承認します。
リソースの作成方法を制御していない組織は、必要以上に多くのリソースを作成することで、サービスを悪用する可能性があるユーザーの影響を受けやすくなります。 リソース作成プロセスの強化は、マルチテナント シナリオをセキュリティで保護するための重要な手順です。
疑わしいアクティビティを積極的に監視する
アクティブな ID 監視システムは、疑わしい動作をすばやく検出し、さらに調査するためにアラートをトリガーできます。 次の表に、組織が ID を監視するのに役立つ Microsoft Entra 機能を示します。
ベスト プラクティス: 次を識別する方法があります。
詳細: Microsoft Entra ID P1 または P2 異常レポートを使用します。 IT 管理者がこれらのレポートを毎日またはオンデマンドで実行するためのプロセスと手順を用意します (通常はインシデント対応シナリオ)。
ベスト プラクティス: リスクを通知し、ビジネス要件に合わせてリスク レベル (高、中、低) を調整できるアクティブな監視システムを用意します。
詳細: Microsoft Entra ID Protection を使用します。この保護は、現在のリスクに独自のダッシュボードにフラグを設定し、毎日の概要通知を電子メールで送信します。 組織の ID を保護するために、指定されたリスク レベルに達したときに検出された問題に自動的に対応するリスクベースのポリシーを構成できます。
ID システムを積極的に監視していない組織は、ユーザー資格情報が侵害されるリスクがあります。 これらの資格情報を使用して疑わしいアクティビティが行われているという知識がなければ、組織はこの種の脅威を軽減できません。
ストレージ認証に Microsoft Entra ID を使用する
Azure Storage では 、Blob Storage と Queue Storage の Microsoft Entra ID を使用した認証と承認がサポートされています。 Microsoft Entra 認証を使用すると、Azure ロールベースのアクセス制御を使用して、個々の BLOB コンテナーまたはキューのスコープまで、ユーザー、グループ、アプリケーションに特定のアクセス許可を付与できます。
ストレージへのアクセスを認証するには、Microsoft Entra ID を使用することをお勧めします。
次のステップ
Azure を使用してクラウド ソリューションを設計、デプロイ、管理する際に使用するセキュリティのベスト プラクティスについて詳しくは、Azure のセキュリティの ベスト プラクティスとパターン をご覧ください。