Azure AD サインイン データを利用して問題のサービス プリンシパルを検出する方法
すぐに来るアプリのための春のクリーンタイム
昨年、私は Azure AD 統合アプリケーションを確認してクリーンアップする必要性について書きました。この記事では、Azure AD から CSV ファイルに情報を抽出し、CSV を使用してマイクロソフト リストを作成する方法について説明します。リストへのアクセスを容易にするために、Teams にチャネル タブを作成します。すべては、削除が必要な可能性のある疑わしいアプリを特定するために機能します。このようなレビューは定期的に行うべきだと思います。それはちょうど理にかなっています。
疑わしい可能性があるアプリのアクティビティを監視するもう 1 つの方法は、サインイン データを確認することです。 サービス プリンシパル.その目的は、テナントにサインインしている認識されないサービス プリンシパルを特定し、どのアプリが関係しているかを把握することです。サインインは、次の場所から取得できます。 Microsoft アプリで使用される既知のサービス プリンシパル、サード パーティ製アプリ、またはテナントがグラフと対話するアプリを登録するときに Azure AD によって自動的に作成されるサービス プリンシパル (たとえば、PowerShell スクリプトでグラフ API に対して行われた呼び出しを認証するため)。サービス プリンシパルのサインイン データは、 Azure AD 管理センター (図1)そして今、それは Microsoft Graph List SignIns API.
この更新プログラムが重要な理由は、グラフ経由でサインイン データにアクセスすると、分析のために情報をダウンロードしたり、外部リポジトリに長期間保持するために保存したりできるからです。サインイン データは Azure AD 管理センターに CSV ファイルとしてダウンロードできますが、特に特定のサービス プリンシパルのアクティビティ パターンを調査する場合は、グラフ クエリを使用して情報にアクセスする方が柔軟性があります。
グラフからのサインイン データの取得
グラフと対話するアプリケーションには、データにアクセスするためのアクセス許可の同意が必要です。この場合、同意が必要です。 ディレクトリ.読み取り.すべて そして AuditLog.Read.All アプリケーションのアクセス許可。代理人のアクセス許可も使用でき、この場合、使用するアカウントは Azure AD サインイン ログにアクセスできる管理者ロールを保持している必要があります。
適切にアクセス許可を与えられたアプリケーションは、SignIns API に対してクエリを発行できます。サービスプリンシパルサインインデータを取得するには、アプリケーションによって実行されるクエリで Lambda 修飾子を使用してデータをフィルタリングする必要があります。サインイン データを検索する日付範囲を設定することとは別に、重要なポイントは、 signInEventTypes プロパティを使用して、サービス プリンシパルのサインイン イベントを選択します。1 月 19 日の 17:30 ~ 22:3 のサインイン データを取得するクエリの例を次に示します。
https://graph.microsoft.com/beta/auditLogs/signIns?&$filter=createdDateTime ge 2022-01-19T17:30:00Z and createdDateTime le 2022-01-19T22:30:00Z and signInEventTypes/any(x:x eq 'servicePrincipal')
クエリ (または目的に合ったクエリ) をテストするには、グラフ エクスプローラーを使用して、クエリが返す内容を確認します。
私は単純なPowerShellスクリプトを書いた(GitHubからダウンロード可能) を使用して、過去 7 日間のサービス プリンシパル サインイン データを取得します。データの簡単な概要から、多くのサインインが Office 365 レポートという名前のアプリから取得されていることが明らかになりました。奇妙なことに、私がGitHubに投稿したPowerShellスクリプトで使用されているアプリも、22回のサインインで現れました。情報バリアプロセッサは、Microsoft 365 が情報バリアポリシーに対してユーザーアカウントをチェックして、誰も通信すべきでないときに誰も通信していないことを確認するために使用するアプリです。
$Report | Group SpName | Sort Count -Descending | Select Name, Count Name Count ---- ----- Office 365 Reports 369 Graph Microsoft 365 Groups Membership Report 22 Information Barrier Processor 21 Security and Audit 5 PS-Graph 1
大量のサインイン セットを解決するのは簡単でした。リストに格納されたデータ (図 2) から、サービス プリンシパルは、もともと Cogmotive によって公開された Office 365 Reporting アプリに属していることが明らかになりました (Quadrotech によって取得され、その後 Quest Software によって取得されました)。私は何年もアプリを使用していませんが、サインインは続きました。
時間が経つにつれて、何らかの理由でインストールされたサービスプリンシパルの形でcrudを蓄積するのは簡単です。ISV 製品のテストは古典的な例であり、運用テナントではなくテスト テナントで常にテストを実行する正当な理由です。または、アプリの使用を停止した場合は、アプリ ベンダーが残す可能性のあるサービス プリンシパルやその他のアプリの破片を削除して、クリーンアップすることを忘れないでください。
PowerShell スクリプトで使用されるアプリのサインインが存在するのは、テナント識別子、アプリ識別子、およびアプリ シークレットと共にスクリプトのコピーを共有したためである可能性があります。私はすぐにスクリプトを難読化された資格情報を含むコピーに置き換えましたが、元のコピーを持つ人なら誰でもコードを実行できるように、アプリの秘密を変更できませんでした。今アルerted、私はアプリの秘密を削除しました。私の疑いは、失敗したサインインのバッチがその後アプリで発生したときに確認されました。これは、注意を払わないと潜在的な妥協点を作り出すのがどれほど簡単かを証明するものです。
PowerShell でのサービス プリンシパルの削除
不要なサービス プリンシパルは、Azure AD 管理センターまたは PowerShell のいずれかを使用してクリーンアップできます。私はいつもPowerShellセッションを開いているので、そのルートを選択しました。この例では、表示名を使用してサービス プリンシパルのオブジェクト識別子を見つけます。これが削除する適切なサービス プリンシパルであることを確認したら、オブジェクト識別子を使用して、 Remove-AzureADServicePrincipal コマンドレット。
Get-AzureADServicePrincipal -SearchString "Office 365 Reports" ObjectId AppId DisplayName -------- ----- ----------- 034b71f3-f57a-4bed-84b9-07207ee5998e 507bc9da-c4e2-40cb-96a7-ac90df92685c Office 365 Reports $AppId = (Get-AzureADServicePrincipal -SearchString "Office 365 Reports").ObjectId Remove-AzureADServicePrincipal -ObjectId $AppId
コンテキストの追加
テナントが認識しているサービス プリンシパルの一覧は、組織データに対する何らかの形式の同意 (アクセス許可) を保持している不要なアプリや不要なアプリのレビューに貴重な入力です。テナントにアクティブにサインインしているサービス プリンシパルを知ることで、データにコンテキストを追加すると、アクションの優先順位付けが容易になります。データはそこにあり、利用可能であり、それをどうするかを決めるのはあなた次第です。
このような洞察は簡単には得られません。テクノロジーを知り、舞台裏の見方を理解する必要があります。の知識と経験から利益を得る Office 365 for IT プロフェッショナル Office 365とより広いMicrosoft 365エコシステムをカバーする最高の電子書籍を購読することでチーム。