Microsoft Entra 認証管理操作リファレンス ガイド
「Microsoft Entra 運用リファレンス ガイド」のこのセクションでは、企業のセキュリティ体制に基づいた資格情報のセキュリティ保護と管理、認証 (AuthN) エクスペリエンスの定義、割り当ての委任、使用状況の測定、およびアクセス ポリシーの定義に必要なチェックとアクションについて説明します。
Note
これらの推奨事項は公開日の時点で最新ですが、時間の経過と共に変化する可能性があります。 Microsoft の製品とサービスは時間の経過と共に進化するため、継続的に ID プラクティスを評価する必要があります。
主要な運用プロセス
主要タスクに所有者を割り当てる
Microsoft Entra ID を管理するには、ロールアウト プロジェクトに含まれていない可能性のある重要な運用タスクとプロセスを継続的に実行する必要があります。 環境を最適化するために、これらのタスクを設定することも重要です。 主なタスクと推奨される所有者は次のとおりです。
| タスク | 所有者 |
|---|---|
| Microsoft Entra ID のシングル サインオン (SSO) の構成のライフサイクルを管理する | ID およびアクセス管理 (IAM) の運用チーム |
| Microsoft Entra アプリケーションの条件付きアクセス ポリシーを設計する | InfoSec アーキテクチャ チーム |
| セキュリティ情報イベント管理 (SIEM) システムにサインイン アクティビティをアーカイブする | InfoSec 運用チーム |
| SIEM システムでリスク イベントをアーカイブする | InfoSec 運用チーム |
| セキュリティ レポートについてトリアージおよび調査する | InfoSec 運用チーム |
| リスク イベントについてトリアージおよび調査する | InfoSec 運用チーム |
| Microsoft Entra Identity Protection からのリスクと脆弱性のレポートでフラグが設定されたユーザーをトリアージして調査する | InfoSec 運用チーム |
Note
Microsoft Entra Identity Protection には、Microsoft Entra ID P2 ライセンスが必要です。 要件に適したライセンスを見つけるには、「Microsoft Entra ID Free と Microsoft Entra ID P1 または P2 エディションの一般提供機能の比較」を参照してください。
リストの確認中に、所有者のいないタスクに所有者を割り当て、上記のレコメンデーションに一致しない所有者を持つタスクの所有権を調整する必要があることに気付くことがあります。
所有者に関する推奨資料
資格情報の管理
パスワード ポリシー
パスワードを安全に管理することは、ID およびアクセス管理の最も重要な要素の 1 つであり、攻撃の最大の標的となることがよくあります。 Microsoft Entra ID は、攻撃が成功するのを防ぐために役立ついくつかの機能をサポートしています。
次の表を使用して、対処が必要な問題を軽減するために推奨される解決策を見つけてください。
| 問題点 | 推奨 |
|---|---|
| 脆弱なパスワードから保護するためのメカニズムがない | Microsoft Entra ID のセルフサービス パスワード リセット (SSPR) とパスワード保護を有効にします |
| 漏洩したパスワードを検出するためのメカニズムがない | パスワード ハッシュ同期 (PHS) を有効にして分析情報を取得します |
| AD FS を使用し、管理された認証に移行できない | AD FS エクストラネットの Smart Lockout や Microsft Entra Smart Lockout を有効にする |
| パスワード ポリシーで、長さ、複数の文字セット、有効期限などの複雑なものに基づくルールを使用している | Microsoft のおすすめプラクティスを優先して再度検討し、アプローチをパスワード管理に切り替えて、Microsoft Entra のパスワード保護をデプロイしてください。 |
| ユーザーが多要素認証 (MFA) を使用するように登録されていない | すべてのユーザーのセキュリティ情報を登録して、ユーザーのパスワードと共にユーザーの ID を検証するためのメカニズムとして使用できるようにします |
| パスワードの失効がユーザーのリスクレベルに基づいて行われていない | Microsoft Entra の ID 保護による ユーザー リスク ポリシーをデプロイして、漏洩した認証情報パスワードの SSPR による変更を要求します |
| 識別済み IP アドレスから行われる有害なアクターによる不正認証を防ぐことのできるスマート ロックアウト メカニズムがない | パスワード ハッシュ同期またはパススルー認証 (PTA) のいずれかを含む、クラウドで管理される認証をデプロイします |
パスワード ポリシーに関する推奨資料
セルフサービス パスワード リセット とパスワード保護を有効にする
パスワードを変更またはリセットする必要があるユーザーは、ヘルプ デスクへの問い合わせの量とコストの最大の発生源の 1 つです。 コストに加え、ユーザーのリスクを軽減するためのツールとしてパスワードを変更することは、組織のセキュリティ体制を改善するための基本的な手順です。
次のことを行うために、少なくとも、Microsoft Entra ID のセルフサービス パスワード リセット (SSPR) とオンプレミスのパスワード保護をデプロイすることをお勧めします:
- ヘルプ デスクへの問い合わせをうまくそらす。
- 一時パスワードの使用を置き替える。
- オンプレミスのソリューションに依存している既存のセルフサービスのパスワード管理ソリューションを置き換える。
- 組織内の脆弱なパスワードを排除する。
メモ
Microsoft Entra ID P2 ライセンスを持つ組織の場合は、SSPR を展開し、Microsoft Entra ID 保護リスクベースの条件付きアクセス ポリシーの一部として SSPR を使用することをお勧めします。
強力な認証情報の管理
パスワード自体は、悪意のあるユーザーによる環境へのアクセスを阻止できるほど安全ではありません。 少なくとも、特権アカウントを持つすべてのユーザーが、MFA を有効にする必要があります。 理想的には、統合された登録を有効化し、すべてのユーザーに対して統合された登録エクスペリエンスを使用して多要素認証と SSPR に登録するよう要求する必要があります。 最終的には、予期しない状況によるロックアウトのリスクを軽減するために、回復性を提供する戦略を採用することをお勧めします。
オンプレミスの停止に対する認証の回復性
Microsoft Entra のパスワード ハッシュ同期 (PHS) と Microsoft Entra の多要素認証を使用すると、よりシンプルな管理と漏洩した資格情報の検出が可能になるだけでなく、NotPetya などのサイバー攻撃によってオンプレミスの停止が発生しても、ユーザーはサービスとしてのソフトウェア (SaaS) アプリケーションや Microsoft 365 にアクセスできます。 また、フェデレーションと組み合わせると、PHS を有効にすることもできます。 PHS を有効にすると、フェデレーション サービスが使用できない場合に認証のフォールバックが可能になります。
オンプレミスの組織に障害回復戦略がない場合や、Microsoft Entra ID と統合されていない場合は、Microsoft Entra PHS をデプロイし、PHS を含むディザスター リカバリー計画を定義する必要があります。 Microsoft Entra PHS を有効にすると、オンプレミスの Active Directory が使用できない場合に、ユーザーが Microsoft Entra ID に対して認証を行うことができるようになります。
認証オプションに対する理解を深めるには、「Microsoft Entra ハイブリッド ID ソリューションの適切な認証方法を選択する」を参照してください。
プログラムによる資格情報の使用
PowerShell を使用する Microsoft Entra スクリプトや Microsoft Graph API を使用するアプリケーションには、セキュリティで保護された認証が必要です。 このようなスクリプトやツールを実行する資格情報の管理が不十分な場合は、資格情報の盗難のリスクが高まります。 ハードコーディングされたパスワードまたはパスワード プロンプトに依存するスクリプトまたはアプリケーションを使用している場合は、まず、構成ファイルまたはソース コード内のパスワードを確認してから、それらの依存関係を置き換えて、可能な限り Azure マネージド ID、統合 Windows 認証、または証明書を使用する必要があります。 以前のソリューションに可能性がないアプリケーションの場合は、Azure Key Vault の使用を検討してください。
パスワード資格情報を持つサービス プリンシパルがあることを確認し、それらのパスワード資格情報がスクリプトやアプリケーションによってどのように保護されているかわからない場合は、アプリケーションの所有者に問い合わせて使用パターンの理解を深めてください。
また、パスワード資格情報を持つサービス プリンシパルがある場合は、アプリケーション所有者に連絡して使用パターンを把握することもお勧めします。
認証エクスペリエンス
オンプレミスの認証
統合 Windows 認証 (IWA) を使用したフェデレーション認証や、パスワード ハッシュ同期またはパススルー認証を使用したシームレス シングル サインオン (SSO) のマネージド認証は、オンプレミスのドメイン コントローラーへの通信経路のある企業ネットワーク内の場合は最適なユーザー エクスペリエンスです。 これにより、資格情報プロンプトによる疲労が最小限に抑えられ、ユーザーがフィッシング攻撃の犠牲になるリスクが軽減されます。 PHS または PTA によるクラウドで管理された認証を既に使用していても、オンプレミスで認証するときにユーザーがまだパスワードを入力する必要がある場合は、すぐにシームレス SSO をデプロイする必要があります。 一方で、現在、クラウドで管理された認証に最終的に移行する予定がある場合は、移行プロジェクトの一環としてシームレス SSO を実装する必要があります。
デバイスの信頼のアクセス ポリシー
組織内のユーザーと同様、デバイスは保護対象となる主要なアイデンティティです。 デバイスの ID を使用して、いつでもどこからでもリソースを保護できます。 デバイスを認証し、その信頼の種類を考慮することで、次のようなセキュリティ体制と使用可能性が向上します。
- デバイスが信頼されている場合、多要素認証などを使用して障害を回避する
- 信頼されていないデバイスからのアクセスをブロックする
- Windows 10 デバイスの場合は、オンプレミスのリソースへのシングル サインオンをシームレスに提供します。
この目標は、次のいずれかの方法を使用してデバイス ID を取り込んで Microsoft Entra ID で管理することで実行できます:
- 組織は、Microsoft Intune を使用してデバイスを管理し、コンプライアンス ポリシーを適用し、デバイスの正常性を証明し、デバイスが準拠しているかどうかに基づいて条件付きアクセス ポリシーを設定することができます。 Microsoft Intune では、iOS デバイス、Mac デスクトップ (JAMF 統合経由)、Windows デスクトップ (Windows 10 のモバイル デバイス管理のネイティブな使用、および Microsoft Configuration Manager との共同管理)、および Android モバイル デバイスを管理できます。
- Microsoft Entra ハイブリッド参加では、Active Directory ドメイン参加済みコンピューター デバイスがある環境で、グループ ポリシーまたは Microsoft Configuration Manager を使用した管理を提供します。 組織は、シームレス SSO を使用した PHS または PTA のいずれかを使用して、マネージド環境をデプロイできます。 Microsoft Entra ID に自分のデバイスを取り込むと、クラウドとオンプレミスのリソースでの SSO を使用したユーザーの生産性を最大化でき、同時に条件付きアクセスを使用したクラウドとオンプレミスのリソースへのアクセスをセキュリティで保護することができます。
クラウドに登録されていないドメイン参加済み Windows デバイス、またはクラウドに登録されていても条件付きアクセス ポリシーがないドメイン参加済み Windows デバイスがある場合は、登録されていないデバイスを登録する必要があり、いずれにしても条件付きアクセス ポリシーで制御として Microsoft Entra ハイブリッド参加を使用する必要があります。
MDM または Microsoft Intune を使用してデバイスを管理していても、条件付きアクセス ポリシーでデバイス制御を使用していない場合は、それらのポリシー内のコントロールとして、「デバイスは準拠としてマーク済みである必要がある」を使用することをお勧めします。
デバイスの信頼のアクセス ポリシーに関する推奨資料
Windows Hello for Business
Windows 10 では、Windows Hello for Business によって PC 上のパスワードが強力な 2 要素認証に置き換えられます。 Windows Hello for Business を使用すると、ユーザーにとってより効率的な多要素認証エクスペリエンスを実現し、パスワードへの依存を減らすことができます。 Windows 10 デバイスのロールアウトを開始していない場合、または部分的にデプロイしただけの場合は、Windows 10 にアップグレードして、すべてのデバイスで Windows Hello for Business を有効することをお勧めします。
パスワードレス認証の詳細については、「Microsoft Entra ID でのパスワードレスの環境」を参照してください。
アプリケーションの認証と割り当て
アプリのシングル サインオン
標準化されたシングル サインオンのメカニズムを社内全体に提供することは、最良のユーザー エクスペリエンス、リスクの削減、報告する能力、およびガバナンスにとって不可欠です。 Microsoft Entra ID で SSO をサポートしていても、現時点ではローカル アカウントを使用するように構成されているアプリケーションを使用している場合は、そのようなアプリケーションを Microsoft Entra ID で SSO を使用するように再構成する必要があります。 同様に、Microsoft Entra ID で SSO をサポートしていても、別の ID プロバイダーを使用している何らかのアプリケーションを使用している場合は、そのようなアプリケーションも Microsoft Entra ID で SSO を使用するように再構成する必要があります。 フェデレーション プロトコルはサポートしていなくても、フォーム ベースの認証をサポートしているアプリケーションの場合は、Microsoft Entra アプリケーション プロキシを使用してパスワード保管を使用するようにアプリケーションを構成することをお勧めします。
Note
組織内の管理されていないアプリケーションを検出するメカニズムがない場合は、Microsoft Defender for Cloud Apps などのクラウド アプリケーション セキュリティ ブローカー (CASB) を使用して検出プロセスを実装することをお勧めします。
最後に、Microsoft Entra アプリ ギャラリーがあり、Microsoft Entra ID で SSO をサポートするアプリケーションを使用している場合は、アプリ ギャラリーでアプリケーションを一覧表示することをお勧めします。
シングル サインオンに関する推奨資料
Microsoft Entra ID への AD FS アプリケーションの移行
AD FS から Microsoft Entra ID にアプリを移行すると、セキュリティの機能の追加、より一貫性のある管理容易性、および共同作業エクスペリエンスの向上が可能になります。 Microsoft Entra ID で SSO をサポートしている AD FS に構成されているアプリケーションがある場合は、そのようなアプリケーションを Microsoft Entra ID で SSO を使用するように再構成する必要があります。 Microsoft Entra ID でサポートされていない一般的でない構成の AD FS で構成されたアプリケーションがある場合は、アプリの所有者に問い合わせて、特別な構成がアプリケーションの絶対的な要件であるかどうかを把握する必要があります。 必要でない場合は、Microsoft Entra ID で SSO を使用するようにアプリケーションを再構成する必要があります。
Note
Microsoft Entra Connect Health for AD FS を使用すると、Microsoft Entra ID に移行できる可能性がある各アプリケーションの構成の詳細情報を収集できます。
アプリケーションへのユーザーの割り当て
アプリケーションへのユーザーの割り当てをグループベースでマッピングすることにより、より優れた柔軟性と大規模な管理能力を獲得できます。 グループを使用する利点には、属性ベースの動的メンバーシップ グループとアプリ所有者への委任などがあります。 既にグループを使用して管理している場合は、管理を大幅に改善するために次のアクションを行うことをお勧めします。
- グループ管理とガバナンスをアプリケーション所有者に委任します。
- アプリケーションへのセルフサービス アクセスを許可します。
- ユーザー属性で一貫してアプリケーションへのアクセスを決定できる場合は、動的メンバーシップ グループを定義します。
- Microsoft Entra アクセス レビューを使用して、アプリケーションへのアクセスに使用されるグループに構成証明を実装します。
一方、個々のユーザーに割り当てられているアプリケーションが見つかった場合は、それらのアプリケーションにガバナンスを実装してください。
アプリケーションへのユーザーの割り当てに関する推奨資料
- Microsoft Entra ID でアプリケーションにユーザーとグループを割り当てる
- Microsoft Entra ID でアプリ登録のアクセス許可を委任する
- Microsoft Entra ID のグループの動的メンバーシップ ルール
アクセス ポリシー
ネームド ロケーション
Microsoft Entra ID でネームド ロケーションを使うと、組織内の信頼できる IP アドレス範囲にラベルを付けることができます。 Microsoft Entra ID では、ネームド ロケーションを使用して次のことを実行します:
- リスク イベントの誤判定を防ぎます。 信頼できるネットワークの場所からサインインすることで、ユーザーのサインイン リスクが低下します。
- 場所ベースの条件付きアクセスを構成する。
優先度に基づいて次の表を使用して、組織のニーズに最も合致する推奨される解決策を見つけてください。
| 優先順位 | シナリオ | 推奨 |
|---|---|---|
| 1 | PHS または PTA を使用していて、ネームド ロケーションが定義されていない場合 | ネームド ロケーションを定義して、リスク イベントの検出を改善します |
| 2 | フェデレーションされていて、"insideCorporateNetwork" 要求を使用しておらず、ネームド ロケーションが定義されていない場合 | ネームド ロケーションを定義して、リスク イベントの検出を改善します |
| 3 | 条件付きアクセス ポリシーでネームド ロケーションを使用しておらず、条件付きアクセス ポリシーにリスクまたはデバイス制御がない場合 | 条件付きアクセス ポリシーを、ネームド ロケーションを含めるように構成します |
| 4 | フェデレーションされていて、"insideCorporateNetwork" 要求を使用していて、ネームド ロケーションが定義されていない場合 | ネームド ロケーションを定義して、リスク イベントの検出を改善します |
| 5 | ネームド ロケーションではなく多要素認証で信頼された IP アドレスを使用していて、それらを信頼済みとしてマークしている場合 | ネームド ロケーションを定義して、リスク イベントの検出を改善するためにそれらに信頼済みとしてマークします |
リスクベースのアクセス ポリシー
Microsoft Entra ID は、すべてのサインインとすべてのユーザーのリスクを計算できます。 アクセス ポリシーの条件としてリスクを使用すると、ユーザー エクスペリエンスを向上させることができます。たとえば、認証プロンプトが減ってセキュリティが向上したり、必要なときにのみユーザーにプロンプトが表示されたり、応答と修復を自動化したり、などです。
アクセス ポリシーでのリスクの使用をサポートする Microsoft Entra ID P2 ライセンスを既に所有していても、使用されていない場合は、セキュリティ ポスチャにリスクを追加することを強くお勧めします。
リスクベースのアクセス ポリシーの推奨資料
クライアント アプリケーションのアクセス ポリシー
Microsoft Intune アプリケーション管理 (MAM) を使用すると、ストレージの暗号化、PIN、リモート ストレージのクリーンアップなどのデータ保護制御を Outlook Mobile などの互換性のあるクライアント モバイル アプリケーションにプッシュできます。 さらに、条件付きアクセス ポリシーを作成して、承認済みまたは互換性のあるアプリから Exchange Online などのクラウド サービスへのアクセスを制限できます。
従業員が Office モバイル アプリなどの MAM 対応アプリケーションをインストールすることで、Exchange Online や Microsoft 365 の SharePoint などの会社のリソースにアクセスしていて、組織が BYOD (Bring Your Own Device) もサポートしている場合は、アプリケーションの MAM ポリシーをデプロイすることで、MDM に登録されていない個人所有のデバイスのアプリケーション構成を管理してから、MAM 対応クライアントからのアクセスのみを許可するように条件付きアクセス ポリシーを更新することをお勧めします。
従業員が企業リソースに対して MAM 対応アプリケーションをインストールし、Intune のマネージド デバイスでアクセスを制限する必要がある場合は、個人用デバイスのアプリケーション構成を管理し、MAM 対応クライアントからのアクセスのみを許可するように条件付きアクセス ポリシーを更新するために、アプリケーション MAM ポリシーのデプロイを検討する必要があります。
条件付きアクセスの実装
条件付きアクセスは、組織のセキュリティ体制を向上させるための重要なツールです。 そのため、次のベスト プラクティスに従うことが重要です。
- すべての SaaS アプリケーションに少なくとも 1 つのポリシーが適用されていることを確認します
- ロックアウトのリスクを回避するために、 [すべてのアプリ] フィルターをブロック制御と組み合わせないようにします
- [すべてのユーザー] をフィルターとして使用せず、誤って [ゲスト] を追加しないようにします
- すべての "レガシ" ポリシーを Azure portal に移行します
- ユーザー、デバイス、およびアプリケーションのすべての条件をキャッチします
- ユーザーごとの MFA を使用するのではなく、条件付きアクセス ポリシーを使用して多要素認証を実装する
- 複数のアプリケーションに適用できる重要なポリシーの小さいセットを用意します
- 空の例外グループを定義し、それらをポリシーに追加して例外戦略を設定します
- 多要素認証の制御のない緊急用アカウントを計画する
- 複数の Microsoft 365 クライアント アプリケーション (例: Teams、OneDrive、Outlook など) で一貫性のあるエクスペリエンスを確保するために、 Exchange Online や Microsoft 365 の SharePoint などのサービスに対して同じ一連の制御を実装する
- ポリシーへの割り当ては、個人ではなくグループを使用して実装する必要があります
- ポリシーで使用されている例外グループを定期的にレビューして、ユーザーがセキュリティ体制外にある時間を制限します。 Microsoft Entra ID P2 を所有している場合は、アクセス レビューを使用してプロセスを自動化できます
条件付きアクセスに関する推奨資料
- Microsoft Entra ID での条件付きアクセスのベスト プラクティス
- ID とデバイスのアクセスの構成
- Microsoft Entra 条件付きアクセス設定リファレンス
- 一般的な条件付きアクセス ポリシー
外部からのアクセス
レガシ認証
多要素認証などの強力な資格情報は、レガシ認証プロトコルを使用してアプリを保護できないため、悪意のあるアクターが優先する攻撃ベクトルになります。 アクセスのセキュリティ体制を向上させるには、レガシ認証をロックダウンすることが重要です。
レガシ認証は、アプリで使用される以下のような認証プロトコルを指す用語です。
- 先進認証を使用していない古い Office クライアント (Office 2010 クライアントなど)
- インターネット メッセージ アクセス プロトコル (IMAP)、簡易メール転送プロトコル (SMTP)、ポイント オブ プレゼンス (POP) などのメール プロトコルを使用するクライアント
攻撃者はこれらのプロトコルを使用することを非常に好みます。実際に、ほぼ 100% のパスワードのスプレー攻撃がレガシ認証プロトコルを使用しています。 ハッカーは MFA やデバイス認証などの追加のセキュリティの問題に必要な対話型サインインをサポートしていないため、レガシ認証プロトコルを使用します。
環境でレガシ認証が広く使用されている場合は、レガシ クライアントをできるだけ早く先進認証をサポートするクライアントに移行するように計画する必要があります。 同じトークンで、一部のユーザーが既に先進認証を使用していても、他のユーザーがまだレガシ認証を使用している場合は、次の手順を実行してレガシ認証クライアントをロックダウンする必要があります。
サインイン アクティビティ レポート を使用して、レガシ認証をまだ使用しているユーザーを特定し、修復を計画します。
影響を受けるユーザーに対して先進認証対応のクライアントにアップグレードします。
次の手順ごとにロックダウンするように、カットオーバー期間を計画します。
レガシ認証にハードの依存関係があるレガシ アプリケーションを特定します。 下記の手順 3 を参照してください。
レガシ認証を使用していないユーザーが、より多くの露出を回避するために、ソース (たとえば、Exchange メールボックス) でレガシ プロトコルを無効にします。
残りのアカウント (理想的にはサービス アカウントなどの人間以外の ID) では、認証後に従来のプロトコルを制限するために条件付きアクセスを使用します。
レガシ認証に関する推奨資料
同意の付与
不正な同意の付与攻撃では、攻撃者は、連絡先情報、メール、ドキュメントなどのデータへのアクセスを要求する Microsoft Entra 登録済みのアプリケーションを作成します。 ユーザーは、悪意のある Web サイトにアクセスしたときに、フィッシング攻撃を介して悪意のあるアプリケーションに同意を与える可能性があります。
以下は、Microsoft クラウドサービス用に検証を行うアクセス許可を持つアプリの一覧です。
- アプリまたは委任された *.ReadWrite アクセス許可を持つアプリ
- ユーザーの代わりにメールの読み取り、送信、または管理を行うことができる、委任されたアクセス許可を持つアプリ
- 次のアクセス許可の使用を許可されているアプリケーション：
| リソース | 権限 |
|---|---|
| Exchange Online | EAS.AccessAsUser.All |
| EWS.AccessAsUser.All | |
| Mail.Read | |
| Microsoft Graph API | Mail.Read |
| Mail.Read.Shared | |
| Mail.ReadWrite |
- アプリには、サインインしたユーザーの、完全なユーザー偽装が許可されています。 次に例を示します。
| リソース | 権限 |
|---|---|
| Microsoft Graph API | Directory.AccessAsUser.All |
| Azure REST API | user_impersonation |
このシナリオを回避するには、「Office 365 での不正な同意の付与の検出と修復」に関するページを参照して、不正な許可が付与されたアプリケーションや必要以上の許可が付与されたアプリケーションを特定して修正する必要があります。 次に、セルフサービスを完全に削除し、ガバナンスプロシージャを確立 します。 最後に、アプリのアクセス許可の定期的なレビューをスケジュールし、不要な場合には削除します。
同意の付与に関する推奨資料
ユーザーとグループの設定
次に示すのは、明示的なビジネス ニーズがない場合にロックダウンできるユーザーとグループの設定です。
ユーザー設定
- 外部ユーザー - 外部コラボレーションは、Teams、Power BI、Microsoft 365 のSharePoint、Azure Information Protection などのサービスを使用して、企業の業務の一貫で発生することがあります。 ユーザーが開始した外部コラボレーションを制御するための明示的な制約がある場合は、Microsoft Entra エンタイトルメント管理やヘルプ デスクの利用などの制御された運用を使用して、外部ユーザーを有効にすることをお勧めします。 サービスに対して有機的な外部コラボレーションを許可しない場合は、外部ユーザーの招待からメンバーを完全にブロックすることができます。 また、外部ユーザーの招待で特定のドメインを許可またはブロックすることもできます。
- アプリの登録 - アプリの登録が有効になっている場合、エンド ユーザーはアプリケーション自体をオンボードし、データへのアクセスを許可することができます。 アプリの登録の典型的な例としては、Outlook プラグインを有効にするユーザー、またはメールやカレンダーを読んだりメールを送信したりするための音声アシスタント (Alexa や Siri など) があります。 顧客がアプリの登録を無効にすると決めた場合は、アプリケーションを管理者アカウントに登録する必要があり、多くの場合はプロセスを運用化するプロセスを設計する必要があるため、InfoSec チームと IAM チームは例外 (ビジネス要件に基づいて必要なアプリの登録) の管理に関与する必要があります。
- 管理ポータル - 組織は Azure portal の Microsoft Entra ブレードをロックダウンして、管理者以外が Azure portal 内の Microsoft Entra 管理にアクセスして混乱を招くことができないようにします。 Microsoft Entra 管理ポータルのユーザー設定にアクセスして、アクセスを制限します:
Note
管理者以外は、コマンドラインやその他のプログラム インターフェイスを使用すれば、Microsoft Entra 管理インターフェイスにアクセスできます。
グループ設定
[セルフサービス グループ管理] / [ユーザーはセキュリティ グループを作成できます] / [Microsoft 365 グループ]。 クラウドにグループの最新のセルフサービス イニシアチブがない場合は、この機能を使用する準備が整うまで、顧客はそれを無効にすることを決断することができます。
グループに関する推奨資料
- Microsoft Entra B2B コラボレーションとは
- Microsoft Entra ID を使用したアプリケーションの統合
- Microsoft Entra ID でのアプリ、アクセス許可、同意。
- グループを使って、Microsoft Entra ID のリソースへのアクセスを管理する
- アプリケーション アクセス管理のセルフ サービス化に必要な Microsoft Entra ID の設定
予期しない場所からのトラフィック
攻撃者は世界中のさまざまな場所からやって来ます。 このリスクは、場所が条件である条件付きアクセス ポリシーを使用して管理します。 条件付きアクセス ポリシーの場所の条件によって、サインインするビジネス上の理由がない場所からのアクセスをブロックすることができます。
使用可能な場合は、セキュリティ情報およびイベント管理 (SIEM) ソリューションを使用して、リージョン間のアクセスのパターンを分析および検索します。 SIEM 製品を使用していない場合、または Microsoft Entra ID からの認証情報の取り込みではない場合は、Azure Monitor を使用してリージョン間のアクセスのパターンを特定することをお勧めします。
アクセスの使用状況
アーカイブされ、インシデント対応計画と統合された Microsoft Entra ログ
Microsoft Entra ID のサインイン アクティビティ、監査とリスク イベントへのアクセス権を持つことは、トラブルシューティング、使用状況の分析、およびフォレンジクスの調査を行うために不可欠です。 Microsoft Entra ID は、保有期間が制限されている REST API を介して、これらのソースへのアクセスを提供します。 セキュリティ情報とイベント管理 (SIEM) システム、またはそれと同等のアーカイブ テクノロジは、監査とサポートの長期ストレージの鍵となります。 Microsoft Entra ログの長期ストレージを有効にするには、既存の SIEM ソリューションに追加するか、Azure Monitor を使用する必要があります。 インシデント対応計画および調査の一環として使用できるログをアーカイブしてください。
ログに関する推奨資料
- Microsoft Entra 監査 API リファレンス
- Microsoft Entra サインイン アクティビティ レポート API のリファレンス
- Microsoft Entra レポート API と証明書を使ってデータを取得する
- Microsoft Graph for Microsoft Entra ID 保護
- Office 365 管理アクティビティ API リファレンス
- Microsoft Entra ID Power BI コンテンツ パックの使用方法
まとめ
セキュリティで保護された ID インフラストラクチャには、12 の側面があります。 このリストは、企業のセキュリティ体制に基づいた資格情報のセキュリティ保護と管理、認証エクスペリエンスの定義、割り当ての委任、使用状況の測定、およびアクセス ポリシーの定義に役立ちます。
- 主要タスクに所有者を割り当てる。
- 脆弱なパスワードや漏洩したパスワードを検出し、パスワードの管理と保護を強化し、リソースへのユーザーのアクセスをさらにセキュリティで保護するソリューションを実装します。
- いつでもどこからでもリソースを保護するために、デバイスの ID を管理します。
- パスワードレス認証をデプロイします。
- 組織全体で標準化されたシングル サインオン メカニズムを提供します。
- AD FS から Microsoft Entra ID にアプリを移行して、セキュリティの強化とより一貫性のある管理を可能にします。
- グループを使用して優れた柔軟性と大規模な管理を可能にすることで、アプリケーションにユーザーを割り当てます。
- リスクベースのアクセス ポリシーを構成します。
- レガシ認証プロトコルをロックダウンします。
- 不正な同意の付与を検出して修復します。
- ユーザーとグループの設定をロックダウンします。
- トラブルシューティング、使用状況分析、フォレンジック調査のために Microsoft Entra ログの長期ストレージを可能にします。
次のステップ
ID のガバナンスの運用検査とアクションを開始します。