ユーザー アカウントの Microsoft Entra セキュリティ オペレーション

ユーザー ID は、組織とデータを保護するうえで最も重要な観点の 1 つです。 この記事では、アカウントの作成、削除、アカウントの使用状況を監視するためのガイダンスを提供します。 最初の部分は、異常なアカウントの作成と削除を監視する方法について説明します。 2 番目の部分は、異常なアカウントの使用を監視する方法について説明します。

「Microsoft Entra のセキュリティ オペレーションの概要」をまだお読みになっていない場合、お読みになってから先に進むことをお勧めします。

この記事では、一般的なユーザー アカウントについて説明します。 特権アカウントについては、「セキュリティ オペレーション - 特権アカウント」を参照してください。

ベースラインを定義する

異常な動作を発見するには、まず通常で想定内の動作を定義する必要があります。 組織にとって想定内の動作を定義することにより、想定外の動作が発生したときに判断できるようになります。 定義することにより、監視とアラート通知の際に偽陽性のノイズ レベルを低減することもできます。

想定内ものを定義したら、ベースライン監視を実行して想定内容を検証します。 その情報を使用し、ログを監視しながら定義した許容範囲から逸脱した動作を調べます。

通常のプロセス以外で作成されたアカウントのデータ ソースとして、Microsoft Entra 監査ログ、Microsoft Entra のサインイン ログ、ディレクトリ属性を使用します。 次の内容は、組織にとって何が正常で、正常性を定義するために参考になる提案事項です。

• ユーザー アカウントの作成 - 次の事項を評価します。

  • ユーザー アカウントの作成と管理に使用するツールとプロセスの戦略と原則。 たとえば、標準の属性や、ユーザー アカウントの属性に適用される形式はあるでしょうか。

  • アカウントの作成に承認されているソース。 たとえば、Active Directory (AD)、Microsoft Entra ID、Workday のような人事システムから由来するもの。

  • 承認されたソース以外で作成されたアカウントに対するアラート戦略。 ご自身の組織が共同作業している組織の管理されたリストはありますか?

  • ゲスト アカウントのプロビジョニング、ならびにエンタイトルメント管理やその他の正常なプロセス以外で作成されたアカウントに対するアラート パラメーター。

  • 承認されたユーザー管理者ではないアカウントで作成、変更、無効化されたアカウントに対する戦略とアラートのパラメーター。

  • 従業員 ID などの標準の属性がないか、組織の名前付け規則に従っていないアカウントに対する監視とアラート戦略。

  • アカウントの削除と保持の戦略、原則、プロセス。

• オンプレミスのユーザー アカウント - Microsoft Entra Connect と同期されているアカウントに対し、次の事項を評価します。

  • 同期の範囲にあるフォレスト、ドメイン、組織単位 (OU)。 これらの設定を変更できる承認された管理者は誰ですか?また、スコープはどのくらいの頻度で確認されますか?

  • 同期されるアカウントの種類。 たとえば、ユーザー アカウントやサービス アカウントなど。

  • オンプレミスの特権アカウントを作成するプロセス、ならびにこの種類のアカウントの同期を制御する方法。

  • オンプレミスのユーザー アカウントを作成するプロセス、ならびにこの種類のアカウントの同期を管理する方法。

オンプレミスのアカウントのセキュリティ保護と監視の詳細については、「オンプレミスの攻撃から Microsoft 365 の保護」を参照してください。

• クラウド ユーザー アカウント - 次の内容を評価します。

  • Microsoft Entra ID でクラウド アカウントを直接プロビジョニングと管理するプロセス。

  • Microsoft Entra のクラウド アカウントとしてプロビジョニングされるユーザーの種類を決定するプロセス。 たとえば、特権アカウントのみを許可するのか、それともユーザー アカウントも許可するのか。

  • クラウド ユーザー アカウントの作成と管理を想定し、信頼できる個人とプロセスのリストを作成と保守するプロセス。

  • 承認されていないクラウドベースのアカウントに対するアラート戦略を作成と保守するプロセス。

確認先

調査と監視に使用するログ ファイルは次のとおりです。

• Microsoft Entra の監査ログ

• サインイン ログ

• }Microsoft 365 監査ログ

• Azure Key Vault ログ

• 危険なユーザー ログ

• UserRiskEvents ログ

Azure portal から、Microsoft Entra 監査ログを表示したり、コンマ区切り値 (CSV) または JavaScript Object Notation (JSON) ファイルとしてダウンロードしたりできます。 Azure portal には、監視とアラートの自動化を強化できる他のツールと Microsoft Entra ログを統合する方法がいくつかあります:

• Microsoft Sentinel – セキュリティ情報イベント管理 (SIEM) 機能を提供することにより、企業レベルでインテリジェント セキュリティ分析を実現します。

• Sigma ルール - Sigma は、自動化された管理ツールがログ ファイルの解析に使用できるルールとテンプレートを記述するための、進化するオープン標準です。 推奨される検索条件に Sigma テンプレートが存在する場合は、Sigma リポジトリへのリンクを追加しました。 Sigma テンプレートは、Microsoft によって記述、テスト、管理されません。 Sigma リポジトリとテンプレートは、世界中の IT セキュリティ コミュニティによって作成および収集されます。

• Azure Monitor - さまざまな条件に基づいて監視とアラートを自動化します。 ブックを作成または使用して、異なるソースのデータを結合できます。

• SIEM と統合した Azure Event Hubs - Azure Event Hub 統合を介した、Splunk、ArcSight、QRadar、Sumo Logic など、Microsoft Entra ログは他の SIEM と統合できます。

• Microsoft Defender for Cloud Apps – アプリの検出と管理、すべてのアプリとリソースの制御、クラウド アプリのコンプライアンスの確認を行得るようにします。

• Microsoft Entra ID 保護 でワークロード ID をセキュリティで保護 - ログイン動作間とオフラインの侵害インジケーターにおけるワークロード ID のリスクを検出するために使用されます。

監視とアラートの対象の多くは、条件付きアクセス ポリシーの影響を受けます。 条件付きアクセスに関する分析情報とレポート ブックを使用して、1 つまたは複数の条件付きアクセス ポリシーがサインインに及ぼしている影響と、デバイスの状態などのポリシーの結果を確認できます。 このブックは概要を確認し、指定期間にわたる影響を特定できるようにます。 ブックを使用して特定のユーザーのログインを調査することもできます。

この記事の残りの部分では、監視とアラートの対象としてお勧めするものについて説明し、脅威の種類別にまとめています。 特定の事前構築されたソリューションがある場合、テーブルの後にリンクを示すか、サンプルを提供します。 それ以外の場合は、前述のツールを使用してアラートを作成できます。

アカウントの作成

異常なアカウント作成は、セキュリティ上の問題を示している可能性があります。 短命なアカウント、名前付け基準に従っていないアカウント、通常のプロセス以外で作成されたアカウントを調査する必要があります。

短命なアカウント

通常の ID 管理プロセス以外で行われるアカウントの作成と削除は、Microsoft Entra ID で監視する必要があります。 短命なアカウントとは、短期間に作成されて削除されたアカウントを指します。 このようなアカウントの作成と迅速な削除は、不正なアクターがアカウントを作成し、使用してアカウントを削除することにより、検出を回避しようとしている可能性があります。

短命なアカウントのパターンには、承認されていないユーザーやプロセスが、確立されたプロセスとポリシーから外れたアカウントの作成や削除の権限を持っていることを示す可能性があります。 このような動作は、目に見えるマーカーをディレクトリから削除します。

アカウントの作成と削除のデータ軌跡を迅速に発見できなければ、インシデントの調査に必要な情報が存在しなくなる可能性があります。 たとえば、アカウントが削除されたら、ごみ箱から消去される場合があります。 監査ログは 30 日間保持されます。 ただし、ログを Azure Monitor またはセキュリティ情報イベント管理 (SIEM) ソリューションにエクスポートすることにより、より長期的に保持することができます。

特権アカウントと非特権アカウントの両方を監視し、アラートを出す必要があります。 ただし、特権アカウントは管理者アクセス許可を持っているため、監視、アラート、対応のプロセスで優先順位を高くする必要があります。

名前付けポリシーに従っていないアカウント

名前付けポリシーに従っていないユーザー アカウントは、組織のポリシーから逸脱して作成された可能性があります。

ベスト プラクティスは、ユーザー オブジェクトに名前付けポリシーを設定することです。 名前付けポリシーを設定すると、管理が容易になって一貫性を保つことができます。 このポリシーは、承認されたプロセス以外でユーザーが作成されたときに検出できるようにします。 不正なアクターは名前付け基準を認識していない可能性があり、組織のプロセス以外でプロビジョニングされたアカウントを検出しやすくする可能性があります。

組織には、ユーザー アカウントや特権アカウントの作成に使用される特定の形式や属性を持つ傾向があります。 次に例を示します。

• 管理者アカウントの UPN = ADM_firstname.lastname@tenant.onmicrosoft.com

• ユーザー アカウントの UPN = Firstname.Lastname@contoso.com

ユーザー アカウントには、実際のユーザーを識別する属性を持つ場合がよくあります。 たとえば、EMPID = XXXNNN。 組織にとって正常なものを定義するとき、ならびにアカウントが名前付け規則に従わないときにログ エントリのベースラインを定義するときは、次の提案事項を使用します。

• 名前付け規則に従っていないアカウント。 たとえば、nnnnnnn@contoso.com と firstname.lastname@contoso.com。

• 標準の属性が設定されていない、あるいは正しい形式ではないアカウント。 たとえば、有効な従業員 ID がない場合。

解析の詳細については、次の内容を参照してください。

• Microsoft Entra 監査ログ - Azure Monitor ログのテキスト データの解析

• Azure サブスクリプション - Azure PowerShell を使用した Azure 役割の割り当てのリスト

• Microsoft Entra ID - Microsoft Entra 役割の割り当てのリスト

正常のプロセス以外で作成されたアカウント

ユーザーと特権アカウントを作成する標準のプロセスを持つことは、ID のライフサイクルを安全に制御するうえで重要です。 確立されたプロセス以外でユーザーのプロビジョニングとプロビジョニング解除が行われた場合、セキュリティ リスクが発生する可能性があります。 また、確立されたプロセス以外での運用すると、ID 管理上の問題が発生する可能性もあります。 潜在的なリスクには次のものが考えられます。

• ユーザー アカウントと特権アカウントは、組織方針に従うように管理されない場合があります。 正しく管理されていないアカウントに対する攻撃対象領域が広がる可能性があります。

• 不正なアクターが悪意のある目的としてアカウントを作成すると、検出することが難しくなります。 確立されたプロセス以外で有効なアカウントが作成されると、悪意のある目的でアカウントが作成されたり、アクセス許可が変更されたりしても、検出することが難しくなります。

ユーザー アカウントと特権アカウントは、必ず組織方針に従って作成することをお勧めします。 たとえば、正しい名前付け標準、組織の情報、適切な ID ガバナンスの範囲内でアカウントを作成する必要があります。 ID を作成、管理、削除する権限を持つユーザーについて、組織は厳格に管理する必要があります。 このようなアカウントを作成する役割は厳重に管理し、これらのアクセス許可を承認と取得する確立されたワークフローに従った後にのみ、その権限を使用できるようにする必要があります。

異常なログイン

ユーザー認証に失敗することは正常です。 ただし、失敗のパターンやブロックが見られる場合、ユーザーの ID に何かが起こっている兆候である可能性があります。 たとえば、パスワード スプレーやブルート フォース攻撃のとき、あるいはユーザー アカウントが侵害された場合。 パターンが出現したときに監視してアラートを出すことが重要です。 ユーザーと組織のデータを確実に保護できるようになります。

成功すると、すべてがうまくいっているように捉える傾向があります。 ただし、不正なアクターがサービスへのアクセスに成功したことを意味する可能性があります。 成功したログインを監視すると、アクセスして良いユーザーアカウントではないにも関わらず、アクセスされているユーザー アカウントを検知できるようになります。 成功したユーザー認証は、Microsoft Entra ログイン ログの正常なエントリです。 パターンが出現したときに検出するため、監視とアラートを出すことをお勧めします。 ユーザー アカウントと組織のデータを確実に保護することができます。

ログの監視とアラートの戦略を策定して運用するとき、Azure Portal で利用できるツールを検討してください。 Microsoft Entra ID 保護は、ID ベースのリスクの検出、保護、修復を自動化できるようにします。 ID 保護は、リスクの検出とユーザーとログインにリスク スコアを割り当てるため、インテリジェンス主導型機械学習とヒューリスティック システムを使用しています。お客様は、アクセスを許可または拒否するタイミングや、ユーザーがリスクから安全に自己修復できるようにするため、リスク レベルに基づいてポリシーを構成することができます。 次の ID 保護のリスク検出は、現在のリスク レベルを通知します。

詳細については、「ID 保護とは」を参照してください。

注意点

Microsoft Entra ログイン ログ内のデータの監視を構成し、アラートが生成されて組織のセキュリティ ポリシーに準拠していることを確認します。 これに該当するいくつかの例は次のとおりです。

• 認証の失敗: 誰でもパスワードを間違えるときもあります。 ただし、認証に何度も失敗すると、不正なアクターがアクセスを取得しようとしていることを示す可能性があります。 攻撃の強さはさまざまですが、1 時間に数回の試行から、はるかに高い頻度のものまでの範囲に及びます。 たとえば、パスワード スプレーは通常に多数のアカウントに対して簡単なパスワードを狙う一方、ブルート フォースは対象アカウントに対して多数のパスワードが試行されます。

• 認証の割り込み: Microsoft Entra ID の割り込みは、認証を満たすプロセスが挿入されることを表します (条件付きアクセス ポリシーの制御を実施するときなど)。 これは正常なイベントであり、アプリケーションが正しく構成されていないときに発生する可能性があります。 ただし、あるユーザー アカウントに対して多数の割り込みが発生した場合、そのアカウントに何かが発生していることを示している可能性があります。

  • たとえば、ログイン ログでユーザーをフィルター処理し、「ログイン状態 = 割り込み」と「条件付きアクセス = 失敗」が大量に確認されたとします。 さらに掘り下げると、認証の詳細でパスワードは正しいが、強力な認証が必要であることが示される場合があります。 ユーザーが多要素認証 (MFA) を完了していないことを意味しており、ユーザーのパスワードが漏洩し、不正なアクターが MFA を完了できないことを示している可能性があります。

• スマート ロックアウト: Microsoft Entra ID は、認証プロセスになじみのある場所となじみのない場所の概念を導入するスマート ロックアウト サービスを提供しています。 なじみのある場所にアクセスするユーザー アカウントは認証に成功しますが、同じ場所になじみのない不正なアクターは数回の試行後にブロックされます。 ロックアウトされたアカウントを探し、さらに調査します。

• IP の変更: 異なる IP アドレスからユーザーが確認されることは正常です。 ただし、ゼロ トラストは、決して信用せずに常に検証することを提唱しています。 大量の IP アドレスとログインの失敗が確認された場合、侵入の兆候である可能性があります。 複数の IP アドレスから発生する多数の認証失敗のパターンを探します。 仮想プライベート ネットワーク (VPN) 接続は偽陽性を引き起こす可能性があることに注意してください。 課題とは関係なく、IP アドレスの変更を監視することをお勧めします。可能であれば Microsoft Entra ID 保護を使用して、これらのリスクを自動的に検出して軽減することもお勧めします。

• 場所: 一般的に、ユーザー アカウントは地理的に同じ場所にあることを想定します。 従業員や取引関係を持つ場所からログインも想定されます。 ユーザー アカウントが海外の異なる場所から由来し、その地点までの移動に本来かかる時間よりも短時間で所在が検知された場合、そのユーザー アカウントが悪用されていることを示している可能性があります。 VPN は偽陽性を引き起こす可能性があることに注意してください。このため、地理的に離れた場所からログインするユーザー アカウントを監視することをお勧めします。可能であれば、Microsoft Entra ID 保護を使用してこれらのリスクを自動的に検出して軽減することをお勧めします。

このリスク領域については、標準のユーザー アカウントと特権アカウントを監視し、特権アカウントの調査を優先することをお勧めします。 特権アカウントは、すべての Microsoft Entra テナントでも最も重要なアカウントです。 特権アカウントに特化したガイダンスについては、「セキュリティ オペレーション - 特権アカウント]を参照してください。

検出する方法

Microsoft Entra ID 保護と Microsoft Entra のログイン ログを使用し、異常なログインの特徴によって示される脅威を検出に活用します。 詳細については、「Identity 保護とは」を参照してください。 監視とアラートの目的で、Azure Monitor または SIEM にデータをレプリケートすることもできます。 環境の正常性を定義してベースラインを設定するには、次のことを判断します。

• ユーザー ベースで正常と見なされるパラメーター。

• ユーザーがサービス デスクに電話するか、セルフサービス パスワード リセットを実行するまで、一定の期間でパスワードの平均試行回数。

• アラートを出すまでに許容する失敗の試行回数、ならびにその回数がユーザー アカウントと特権アカウントの間で異なるのかどうか。

• アラートを出すまでに許容する MFA の試行回数、ならびにその回数がユーザー アカウントと特権アカウントの間で異なるのかどうか。

• レガシ認証が有効で、使用を中止するためのロードマップの内容。

• 既知のエグレス IP アドレスは組織のものです。

• ユーザー操作する国/地域。

• ネットワークの場所または国/リージョン内にとどまっているユーザーのグループがあるかどうか。

• 組織固有の異常なログインに関連するその他の指標を特定します。 たとえば、週や年内で組織が営業していない日や時間帯など。

環境のアカウントにとって正常な範囲を指定したら、次のリストを考慮して監視してアラートを出すシナリオを決定し、アラートを微調整します。

• Microsoft Entra ID 保護が構成されている場合、監視とアラートを行う必要がありますか?

• 監視してアラートを出すために使用できる特権アカウントに適用されるより厳しい条件はありますか? たとえば、信頼できる IP アドレスからのみ特権アカウントを使用することを必須にすること。

• 設定したベースラインは過度に積極的ですか？ アラート数が多すぎると、無視または見逃されたりする可能性があります。

ID 保護を構成してセキュリティ ベースライン ポリシーをサポートする保護が確実に実行されるようにします。 たとえば、リスクが「高」の場合にユーザーをブロックするなと。 このリスク レベルは、ユーザー アカウントが侵害されていることを高い確度で示します。 サインイン リスク ポリシーとユーザー リスク ポリシーの設定の詳細については、「ID 保護ポリシー」を参照してください。

次の内容では、エントリの影響と重大度に基づいて重要度の高い順にリストされています。

外部ユーザーのログインの監視

失敗した異常なログインの監視

次の内容では、エントリの影響と重大度に基づいて重要度の高い順にリストされています。

成功した異常なログインの監視

単一要素認証のみが必要な中程度の事業影響 (MBI) と高程度の事業影響 (HBI) の用途に対し、定期的に認証を確認することをお勧めします。 それぞれについては、単一要素認証が想定されていたかどうかを判断する必要があります。 さらに、認証の成功の増加、あるいは場所に基づく予期しない時刻の認証の成功を確認します。

次のステップ

これらのセキュリティ オペレーション ガイドの記事を参照してください。

Microsoft Entra のセキュリティ オペレーションの概要

コンシューマー アカウントのためのセキュリティ運用

特権アカウントのセキュリティ オペレーション

Privileged Identity Management のセキュリティ オペレーション

アプリケーションのセキュリティ オペレーション

デバイスのセキュリティ オペレーション

インフラストラクチャのセキュリティ オペレーション