Azure AD 同意アクセス許可の付与の監査ログの確認
優先度の高いアクセス許可に対する Azure AD の同意アクセス許可の付与を探しています
今週 優先度の高いアクセス許可を持つ Azure AD アプリケーションについて書きましたこれは、Microsoft Graph および攻撃者がデータへのアクセス、更新、および抽出のために悪用する可能性のあるその他のアクセス許可として定義されます。たとえば、アプリが メール.読み取り書き込み アプリケーションのアクセス許可は、テナント内のすべてのメールボックスの読み取りと書き込みを行うことができます。このスクリプトは、Teams チャネルに投稿されるレポートを生成し、管理者が指定されたアクセス許可を保持しているアプリケーションを確認できるようにします。
不法な同意
アプリについて Azure AD から返された情報を調べると、アプリに割り当てられているアクセス許可は把握できますが、Azure AD では、アクセス許可に同意したユーザーと同意した時期はわかりません。これは、攻撃者が 不正な同意の付与は、次の場合に発生するものとして定義されます。
“攻撃者は、連絡先情報、電子メール、ドキュメントなどのデータへのアクセスを要求する Azure 登録アプリケーションを作成します。その後、攻撃者はエンド ユーザーを騙して、フィッシング攻撃のいずれかによって、そのアプリケーションにデータへのアクセスを許可させます。."
個々のユーザーのデータへのアクセスに対する不正な同意の付与は悪いことです。その結果、管理者がアプリケーションに、攻撃者が後で悪用できる優先度の高いアクセス許可に対する同意を与えると、壊滅的な結果を招く可能性があります。
Azure AD 同意アクセス許可付与監査レコードの確認
アプリのアクセス許可に最後に調整が行われた時刻を検出する方法の 1 つは、Azure AD 監査ログで 応募への同意 アクション。セットをフィルター処理して、アプリのサービス プリンシパル識別子に一致するものを検索します。私は記事で説明されているスクリプトでこれをしませんでした、同意チェックがどのように機能するかを探りましょう。
まず、スクリプトが実行され、優先度の高いアクセス許可を持つアプリケーションを検出したとします。そのプロパティは次のようになります。
DisplayName : MalwareExample ServicePrincipalId : 6df52e04-63b2-4007-af69-40430ee5a1d1 Publisher : Office 365 for IT Pros Permissions : Mail.ReadWrite, Mail.Send SPType : Application CreatedDate : 12/09/2022 22:41 RecentApp : True
Azure AD 監査ログをスキャンして、このアプリの同意が付与されたレコードを探すには、次のようなコマンドを使用して、監査レコードが存在するかどうかを確認します。検索は 30 日前にさかのぼります。
[array]$AuditRecords = Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Consent to application' AND result eq 'Success' AND targetResources/any(tr:tr/id eq '$($app.serviceprincipalid)')" -top 1
監査レコードが見つかった場合、次のようになります。
ActivityDateTime : 12/09/2022 21:42:49 ActivityDisplayName : Consent to application AdditionalDetails : {User-Agent, AppId} Category : ApplicationManagement CorrelationId : 005cc13f-9fd5-4b95-89ce-19802a7a785f Id : Directory_005cc13f-9fd5-4b95-89ce-19802a7a785f_72CWK_111329857 InitiatedBy : Microsoft.Graph.PowerShell.Models.MicrosoftGraphAuditActivityInitiator1 LoggedByService : Core Directory OperationType : Assign Result : success ResultReason : TargetResources : {6df52e04-63b2-4007-af69-40430ee5a1d1} UserAgent : AdditionalProperties : {}
同意は、アプリの作成日から 1 分後に付与されたことがわかります。これは疑わしい兆候である可能性がありますが、アプリを作成した直後にアクセス許可を付与した結果である可能性もあります。
ザ 開始者 プロパティは複雑なオブジェクトです。それを解析すると、最終的に誰が同意を与えたかがわかります。
$AuditRecords.InitiatedBy.user.UserPrincipalName Admin@Office365itpros.com
残念ながら、監査ログから見つけることができるのはそれだけです。 Get-MgAuditLogDirectoryAudit コマンドレット。いくつかの追加情報は、Azure AD 管理センターで入手できます (図 1)。

Azure AD は監査データを Office 365 監査ログに送信し、次のようなコマンドを使用して検索することもできます。
[array]$records = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date).AddDays(1) -Formatted -ResultSize 5000 -Operations "Consent to application"
Office 365 監査ログには、90 日間 (Office 365 E3 ライセンスを持つアカウントの場合) または 365 日間 (Office 365 E5 ライセンスを持つアカウント) の情報が格納されます。Azure AD に監査レコードが見つからない場合は、Office 365 監査ログを確認すると結果が得られます。Office 365 監査ログを使用することの欠点は、検索するデータが増え、特定の検索フィルターが使用時のように使用できないため、レコードの検索が遅くなる可能性があることです。 Get-MgAuditLogDirectoryAudit をクリックして、Azure AD 監査レコードを確認します。
監査データは、違法であることが判明した問題のある同意の付与を特定するのに役立つ有用な情報ですが、データが有効になるのは、ユーザーがアプリに付与されたアクセス許可、特に注目度の高いアクセス許可に注意を払う場合のみです。
更新するスクリプト
Azure AD 監査ログをクエリしてアプリの同意付与のレコードを検索する方法がわかったので、簡単に更新できます。 スクリプト をクリックして、コードにチェックを含めます。おそらく最も難しい部分は、Teams に投稿するメッセージの HTML 本文に監査情報を含めるための更新です。スクリプトの更新は、読者のための演習として残しておきます!
重要な点は、Azure アプリを教師なしのままにすべきではないということです。これらのアプリをチェックするためにどのような方法を選択しても、定期的に発生し、誰かが責任を負うことを確認してください。r レポートおよびその他の出力を確認して、問題を検出します。
Office 365 アプリケーションが実際に継続的にどのように動作するかについては、 IT プロフェッショナル向け Office 365 電子ブック。毎月の更新プログラムにより、サブスクライバーは Office 365 エコシステム全体で何が重要かを常に把握できます。
ディスカッション
コメント一覧
まだ、コメントがありません