Microsoft 365／Microsoft Entra ID（旧 Azure AD）のテナントを長く運用していると、「P2P Server」というアプリに期限切れのクライアント シークレットや証明書が大量にぶら下がっていて、監視ツールがアラートだらけ……という状況になりがちです。本記事では、この「P2P Server」の期限切れ資格情報をどこまで削除してよいのか、そして安全かつ現実的なクリーンアップ運用について、実務寄りの視点で整理します。
M365／Entra IDで問題になりがちな「P2P Server」の期限切れ資格情報とは
まず前提として、「P2P Server」は Microsoft Entra ID にデバイスや仮想マシンを参加（Azure AD Join／Entra ID Join）させたときなどに、自動的に作成・管理されるアプリケーション／サービス プリンシパルです。管理者が自分でアプリ登録した覚えがなくても、テナント内に存在していて当然の存在です。
運用が長くなると、Microsoft Graph やセキュリティ製品（Defender for Cloud Apps、SIEM、CSPM など）でスキャンした際に、次のような状況がよく見つかります。
- 「P2P Server」サービス プリンシパルの
passwordCredentialsに、期限切れ（Expired）のクライアント シークレットが多数存在する keyCredentials配列に、失効済み証明書が大量に残っている- 監視ツールでは「期限切れのアプリ シークレットがある」としてリスク扱いのアラートが上がり続ける
管理者目線では「この期限切れシークレットや証明書は全部消して良いのか？」「そもそも P2P Server を消したらダメなのか？」が気になるポイントです。本記事のテーマはここにあります。
結論：期限切れのシークレット／証明書は削除してOK（ただし条件付き）
先に結論から整理します。
- 状態が「Expired」のクライアント シークレット／証明書は削除して問題ありません。
- 状態が「Active」の資格情報（シークレット／証明書）は絶対に削除しないことが大前提です。
- P2P Server に紐づく資格情報は、Microsoft によって自動更新（ローテーション）されます。
- 自動更新の結果、古い資格情報は期限切れのまま残る設計になっており、自動では消えません。
- したがって、期限切れのみをクリーンアップしても、アプリの動作には影響しません。
- 必要な資格情報がなくなった場合は、新しい資格情報が自動生成されます（ただし Active が 0 にならないようにするのが安全運用）。
つまり、「期限切れの資格情報を削除する」こと自体は推奨されうるメンテナンスですが、「Active なもの」「アプリ本体」「権限割り当て」には手を触れない、という線引きが重要です。
削除してよい／いけない対象の早見表
| 対象 | 状態 | 削除可否 | 備考 |
|---|---|---|---|
クライアント シークレットpasswordCredentials | Expired（有効期限経過） | 削除してよい | 期限切れのみを選択し、Active が残ることを要確認 |
クライアント シークレットpasswordCredentials | Active（期限内） | 削除禁止 | 削除すると実行中の機能に影響する可能性あり |
証明書keyCredentials | Expired／NotAfter 経過 | 削除してよい | 新しい証明書が存在することを確認してから削除 |
証明書keyCredentials | Active | 削除禁止 | 自動ローテーションの現行キーである可能性が高い |
| P2P Server アプリ（サービス プリンシパル）本体 | — | 削除非推奨 | デバイス参加やバックグラウンド機能に影響しうる |
P2P Server と資格情報のライフサイクルを理解する
P2P Server とは何者か
P2P Server は、Microsoft Entra ID／Azure AD が内部的に使用する、いわゆる「ファーストパーティ アプリ」の一種です。管理者がアプリ登録画面から作成したものではなく、次のような操作に伴って自動的にテナント内に登場します。
- Windows デバイスや仮想マシンを Entra ID に参加させる
- ハイブリッド Azure AD Join 環境でデバイス登録が実行される
- Microsoft が提供する特定のバックグラウンド サービスが動作する
役割の詳細は公開ドキュメントでもそこまで細かく説明されていませんが、少なくとも管理者が独自に権限を付与したり、リダイレクト URL を変更したりする前提のアプリではありません。逆に言えば、「不要だからといって P2P Server 自体を削除する」のは、Microsoft が想定していない使い方と考えた方が安全です。
資格情報の自動ローテーションと「期限切れが残り続ける」理由
P2P Server の資格情報は、以下のようなライフサイクルをたどります。
- デバイス参加などのタイミングで、P2P Server にクライアント シークレットや証明書が発行される。
- 一定期間ごとに、Microsoft 側の制御で新しい資格情報が自動追加される（ローテーション）。
- 古い資格情報は期限切れ（Expired）になっても、自動では削除されない。
この結果、運用年数に比例して、P2P Server にぶら下がる資格情報の数はどんどん増えていきます。特にセキュリティ製品や独自スクリプトで「期限切れのシークレットがあるアプリ」という観点でスキャンをかけると、P2P Server が必ず引っかかる、というわけです。
ここで重要なのは、期限切れの資格情報が残っていても、それ自体はセキュリティ リスクではないという点です。もちろん「どのアプリでどういう資格情報が何個あるか」を把握することは大切ですが、P2P Server のように自動管理されるアプリについては、通常のアプリ登録とは少し違う目線で運用ルールを決める必要があります。
実務で有効なベストプラクティス
ベストプラクティス1：棚卸し方針を明文化する
まずは、「いつ・どのような条件で期限切れ資格情報を削除するか」を、運用ルールとして文書化しておくことをおすすめします。たとえば次のような方針です。
- 半年または一年に一度、テナント全体で期限切れ資格情報の棚卸しを行う。
- その際、P2P Server については期限切れのみ削除対象とし、Active な資格情報には触れない。
- 削除前に、最低 1 件以上の Active な資格情報が残っていることを確認する。
- 変更内容は Change Management（変更管理）チケットや台帳に残す。
ベストプラクティス2：削除対象の判定ルールを決める
削除対象を明確にすると、運用担当者による判断ブレを防げます。例えば、次のような判定基準をルール化できます。
| 項目 | ルール例 | コメント |
|---|---|---|
| 対象アプリ | P2P Server のサービス プリンシパルに限定 | displayName のブレ対策として、アプリ ID／オブジェクト ID も記録する |
| 対象資格情報 | EndDateTime < 現在 のシークレット／証明書 | Active かどうかは EndDateTime で判定 |
| 削除前チェック | 同一アプリで EndDateTime >= 現在 の資格情報が 1 件以上存在すること | Active が 0 にならないようにする安全弁 |
| 削除単位 | 一度に削除するのは数十件〜数百件まで | 大規模テナントでは段階的に実施し、影響をモニタリング |
ベストプラクティス3：監視ルールを「Active が 0 件」にフォーカスさせる
多くの監視ツールは、「期限切れの資格情報が存在するアプリ」を一律でリスク扱いしてしまいます。しかし P2P Server のような自動管理アプリでは、以下のような条件に絞ることで、アラートの質を大きく改善できます。
| 監視条件 | 内容 | ねらい |
|---|---|---|
| パターンA | 期限切れ資格情報が存在し、かつ Active な資格情報数 = 0 | 「今まさに使える資格情報がない」状態だけをアラートにする |
| パターンB | Active な資格情報の有効期限が 30 日未満 | ローテーションが期待通りに動いていない可能性を検知する |
| パターンC | ユーザー作成アプリ（isFallbackPublicClient = false、publisherDomain が自社ドメインなど）における期限切れ資格情報 | P2P Server のような自動管理アプリと、人手で作成したアプリを区別して監視する |
このように、「期限切れが存在すること」ではなく「Active が 0 になること」「ローテーションが機能していないこと」に焦点を当てると、誤検知の嵐から解放され、運用コストが大きく下がります。
ベストプラクティス4：表示名だけに依存しない台帳整備
テナントや生成タイミングによって、「P2P Server」の表示名が微妙に異なるケースがあります。たとえば、
- P2P Server
- P2PServer
- Microsoft P2P Server
などのバリエーションがあり得ます。そのため、運用ドキュメントには必ず次の情報をセットで記録しておきましょう。
- アプリケーション（クライアント）ID
- オブジェクト ID
- テナント内での表示名
- 作成日／最終更新日
こうしておくことで、たとえ表示名が変わったり、多言語環境で別表記になっても、同じアプリを正しく同定できるようになります。
Entra 管理センターで安全にクリーンアップする手順
GUI ベースでの操作に慣れている場合、Entra 管理センターからの削除がもっとも手軽で安全です。ここでは推奨フローを整理します。
前提条件
- 役割：アプリケーション管理者、クラウド アプリケーション管理者、または同等以上の権限
- ブラウザーから Entra 管理センター（entra.microsoft.com）にアクセスできること
ステップ 1：P2P Server アプリを特定
- Entra 管理センターにサインインします。
- [アプリケーション] > [エンタープライズ アプリケーション] を開きます。
- 検索ボックスに「P2P」と入力して検索します。
- 結果から「P2P Server」らしきアプリを選択します。
この時点で、アプリの概要画面から「オブジェクト ID」「アプリケーション ID」を控えておくと、後続の PowerShell 操作やドキュメント化に役立ちます。
ステップ 2：証明書とシークレットの一覧を確認
- P2P Server アプリを開いた状態で、左メニューから [証明書とシークレット] をクリックします。
- [クライアント シークレット] セクションに、現在のシークレット一覧が表示されます。
- [証明書] セクションには、登録されている証明書が表示されます。
ここで、各行の「有効期限」列を見ながら、Expired（過去日付）のものと、将来の日付が設定されている Active のものを区別します。
ステップ 3：期限切れの資格情報だけを削除
- まず Active な資格情報が 1 件以上存在することを確認します。
- 期限切れ（過去日付）のシークレットだけにチェックを入れます。
- [削除] ボタンを押し、確認ダイアログで再度内容を確認してから実行します。
- 証明書についても同様に、期限切れのものだけを選択し、削除します。
操作後、ページを再読み込みして、Active なシークレット／証明書が最低 1 件以上残っていることを必ず確認してください。これが安全運用の最終チェックポイントです。
ステップ 4：変更内容の記録
クリーンアップを行ったら、次のような情報を台帳やチケットに残しておくと、将来のトラブルシュートに役立ちます。
- 作業日時
- 作業者
- 対象テナント ID
- P2P Server のアプリケーション ID／オブジェクト ID
- 削除した資格情報の件数（シークレット何件、証明書何件）
- 作業後に Active な資格情報が残っていることを確認した旨
Microsoft Graph PowerShell で期限切れシークレットのみを一括削除する
大量のテナントや環境をまとめて運用している場合、ポータルのクリック操作では限界があります。その場合は Microsoft Graph PowerShell を使った自動化が便利です。ここでは、期限切れのシークレットのみを削除するスクリプト例を紹介します。
前提条件
- Microsoft Graph PowerShell SDK がインストールされていること
- 権限：
Application.ReadWrite.Allなど、アプリのシークレット削除が可能な権限 - P2P Server のサービス プリンシパルがテナントに存在すること
スクリプト例：期限切れシークレットだけ削除
# 必要な権限例: Application.ReadWrite.All
Connect-MgGraph -Scopes "Application.ReadWrite.All"
# P2P Server のサービス プリンシパル取得（displayName は環境で異なる場合あり）
$sp = Get-MgServicePrincipal -Filter "displayName eq 'P2P Server'"
# 念のため、複数見つかった場合は手動で選択する
if ($sp.Count -gt 1) {
Write-Host "複数の P2P Server が検出されました。対象を絞り込んでください。" -ForegroundColor Yellow
$sp | Select-Object Id, AppId, DisplayName
break
}
# 期限切れのシークレットだけ抽出
$now = Get-Date
$expired = $sp.PasswordCredentials | Where-Object { $_.EndDateTime -lt $now }
if (-not $expired) {
Write-Host "期限切れのシークレットは見つかりませんでした。" -ForegroundColor Green
return
}
# 削除前に Active が残るかどうかを事前確認
$activeCount = ($sp.PasswordCredentials | Where-Object { $_.EndDateTime -ge $now }).Count
if ($activeCount -eq 0) {
Write-Host "Active なシークレットが 0 件です。処理を中止します。" -ForegroundColor Red
return
}
# 期限切れシークレットを個別に削除
foreach ($cred in $expired) {
Write-Host "Removing expired secret: $($cred.KeyId)" -ForegroundColor Cyan
Invoke-MgGraphRequest -Method POST `
-Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$($sp.Id)/removePassword" `
-Body (@{ keyId = $cred.KeyId } | ConvertTo-Json)
}
# 削除後に Active が最低 1 件残っているかを再確認
(Get-MgServicePrincipal -ServicePrincipalId $sp.Id).PasswordCredentials |
Where-Object { $_.EndDateTime -ge $now } |
Measure-Object
上記スクリプトでは、removePassword を使ってシークレットを削除しています。証明書（keyCredentials）の削除は Graph API 上では removeKey になりますが、署名付き “proof” が必要になり運用難度が上がるため、証明書の削除はポータルから行う構成にするのがおすすめです。
ポータル操作と PowerShell 操作の使い分け
| 観点 | Entra 管理センター | Microsoft Graph PowerShell |
|---|---|---|
| 対象件数 | 数件〜数十件の手作業に適する | 数百件〜数千件の一括処理に向く |
| 証跡 | GUI 操作ログ＋スクリーンショットで残しやすい | スクリプトと実行ログを保存すれば再現性が高い |
| 誤操作リスク | 選択ミスに注意が必要 | スクリプトのバグで大量削除のリスクあり |
| 運用コスト | 小規模環境には十分 | 複数テナント・定期実行には必須レベル |
運用でハマりがちな落とし穴とその回避策
落とし穴1：P2P Server 本体を削除してしまう
もっとも避けたいのは、「期限切れ資格情報を削除するつもりが、アプリ／サービス プリンシパル本体を削除してしまう」パターンです。これを行うと、デバイス参加やバックグラウンド ジョブで予期せぬエラーが発生する可能性があります。
回避策：
- 運用手順書に「P2P Server 本体の削除は禁止」と明記する。
- アプリ単位の削除操作は、原則として別プロセス（事前レビュー付き）にする。
- 自動化スクリプトでは、
removePassword/removeKeyのみを使い、Remove-MgServicePrincipal等は使わない方針にする。
落とし穴2：Active な資格情報を削除してしまう
期限切れと Active を見間違えて、Active なシークレットや証明書を削除してしまうと、そのタイミングで動作中の処理に影響が出る可能性があります。特に本番環境では避けたい事故です。
回避策：
- GUI では「有効期限の列でソート」して、過去日付だけを選択する。
- PowerShell では
EndDateTimeを条件に、現在時刻より前だけをフィルタする。 - 削除前に、Active な資格情報の件数をカウントし、0 なら処理中止するロジックを必ず入れる。
落とし穴3：表示名の違いによる誤検出
P2P Server 以外のアプリにも、似たような表示名を持つものが存在する可能性があります。表示名だけでフィルタすると、意図しないアプリの資格情報を削除してしまうリスクがあります。
回避策：
- まずはポータル側で、P2P Server の App ID／オブジェクト ID を控える。
- スクリプトでは、
-Filter "appId eq '{AppId}'"のように、App ID ベースで取得する。 - 複数テナントを扱う場合は、テナントごとの ID 一覧を CSV などで管理する。
落とし穴4：監査証跡が残っていない
後から「いつ誰が何を削除したのか？」を調べたいときに、証跡が残っていないと非常に困ります。特に大規模組織では、セキュリティ監査で指摘されやすいポイントです。
回避策：
- 削除前後の状態を、スクリーンショットや JSON エクスポートで保存する。
- 変更管理ツール（ServiceNow/Jira など）に、作業内容と結果を必ず記録する。
- Graph／ポータル操作が監査ログに残るよう、適切なログ保持ポリシーを設定しておく。
監視・コンプライアンス対応の設計例
最後に、P2P Server を含むアプリ資格情報の監視を、どのように「実務的なルール」に落とし込むかの例を挙げます。
ルール例：自社アプリと自動管理アプリを切り分ける
すべてのアプリを一律に「期限切れ資格情報あり＝アラート」にすると、P2P Server のような自動管理アプリがノイズになってしまいます。そこで、次のような切り分けを行うと効果的です。
- 自社開発／ISV アプリ：期限切れ資格情報は即アラート
- Microsoft ファーストパーティ／自動管理アプリ：Active が 0 件になった場合のみアラート
このように分類することで、監視担当の負担を減らしつつ、本当に対応が必要なリスクだけに集中できます。
ルール例：期限切れ資格情報の「累積量」に上限を設定する
P2P Server については「期限切れがあること」自体は問題ありませんが、「何百件・何千件溜まり続けている」のは、運用上の負債になりがちです。そのため、例えば次のような上限値を決めておくのも一案です。
| 項目 | しきい値例 | 対応方針 |
|---|---|---|
| P2P Server の期限切れシークレット数 | 100 件を超えたら警告 | クリーンアップ作業を計画する（半年に一度など） |
| P2P Server の期限切れ証明書数 | 50 件を超えたら警告 | ポータルから削除し、台帳を更新する |
こうした「上限値」を設けておくと、テナントの“健康状態”を数字で把握しやすくなるため、コンプライアンス報告や社内説明にも使いやすくなります。
まとめ：P2P Server の期限切れ資格情報は「仕様」と割り切りつつ、計画的にクリーンアップする
本記事で取り上げたポイントをあらためて整理すると、次のようになります。
- P2P Server は、デバイスや VM を Entra ID に参加させる際などに自動作成・自動管理されるアプリであり、期限切れ資格情報が溜まるのは仕様どおりの挙動です。
- 期限切れ（Expired）のシークレット／証明書は削除して問題ありませんが、Active な資格情報やアプリ本体は削除しないことが重要です。
- 資格情報は自動ローテーションされるため、期限切れを削除しても機能影響は基本的に発生しません。
- ただし、「Active が 0 件にならない」ことをスクリプトや運用ルールで保証することが、安全運用の鍵です。
- 監視では「期限切れが存在すること」ではなく、「Active 0 件」や「ローテーションしていないこと」にフォーカスすることで、誤検知の嵐を防げます。
- 台帳整備・変更管理・監査ログなどを組み合わせて、いつ誰が何を削除したかを追跡できる状態を維持することが、コンプライアンス上も重要です。
P2P Server や Microsoft Entra ID の内部的なアプリは、「よく分からないから触らない」か「とりあえず全部消す」の両極端になりがちです。しかし、挙動とライフサイクルを理解してしまえば、期限切れ資格情報だけを計画的にクリーンアップしていくという、現実的で安全な運用スタイルを取ることができます。ぜひ自社テナントのルール作りの参考にしてみてください。
コメント