Microsoft Learnの公式Microsoft Entra「新機能」ページはまだ2026年7月のセクションで更新されていません（2026年6月が最新のまま表示されています）が、MicrosoftはTech Communityブログ記事、M365 Message Center通知、Azure Updates、Microsoft Graph APIドキュメントを通じて新しい発表をリリースし続けています。今週の検出実行で、IDおよびセキュリティチームが把握すべき6つの新しい項目が見つかりました。

新機能の紹介、その重要性、および組織が取るべきアクションを以下に示します。

1. サービスプリンシパルの監査ログプロパティの強化

発表時期： 2026年7月上旬 ステータス： 一般提供 出典： Microsoft Learn

Microsoft Entraは、サービスプリンシパルが作成された際に監査ログで強化されたメタデータをキャプチャするようになり、各作成イベントの由来と意図を理解することが大幅に容易になりました。

新機能

ApplicationManagementカテゴリの「Add service principal」アクティビティに、3つの新しいプロパティが記録されるようになりました：

  • ServicePrincipalProvisioningType — サービスプリンシパルがどのように、なぜ作成されたかを説明する列挙型。値には以下が含まれます：

    • defaultMicrosoft — デフォルトの資格情報またはシステム管理プロセスの一部としてMicrosoftによって作成
    • subscription — テナントが適格なサブスクリプション/SKUを持っているために作成（コマースベースのJITプロビジョニング）
    • managerApplications — 他のサービスプリンシパルを管理する権限を持つMicrosoft管理の「マネージャー」アプリケーションによって作成
    • AzureResourceProvider — サービスオンボーディング中にAzureリソースプロバイダーによって作成（例：Azure Data Explorer）
    • Other — 委任およびアプリ専用フローを含むその他のプロビジョニングメカニズム

  • SubscribedSkus — コマースベースのJITプロビジョニングで作成されたMicrosoftサービスプリンシパルを、その適格性の基となった特定のサブスクリプションとサービスプランにリンクするJSON配列

  • AppOwnerOrganizationId — サービスプリンシパルを所有するアプリケーション登録のホームテナントID

なぜ重要か

サービスプリンシパルの作成イベントは、セキュリティチームにとって長らく盲点でした。新しいSPがテナントに現れた場合、重要な質問は「人間がこれを作成したのか、それともMicrosoftサービスが自動的にプロビジョニングしたのか？」ということです。以前は、この質問に答えるためにMicrosoft Graph API呼び出しのクロスリファレンス、サブスクリプション詳細の確認、場合によっては複数システムにわたるアクティビティログの掘り起こしが必要でした。

これらの新しいプロパティにより、セキュリティチームは、Microsoft主導のプロビジョニング（予期されるプラットフォームの動作）とテナント主導のアクション（調査が必要な場合がある）を即座に区別できます。これは、攻撃者がテナントに永続性を確立するためにサービスプリンシパルを作成する潜在的な侵害シナリオを検出するのに特に重要です。

使用方法

これらのプロパティは、Entra管理センターの監査ログの「Add service principal」イベントのAdditional detailsセクションに表示されます。Microsoft Graph APIクエリおよびLog Analytics AuditLogsテーブルでも利用できます。

必要なロール： セキュリティ管理者、セキュリティリーダー、またはレポートリーダー。

2. より厳格なフェデレーショントークン検証ポリシー — 2026年8月施行

発表時期： 2026年7月9日（MC1303719） 施行時期： 2026年8月中旬 対応期限： 2026年8月11日 出典： M365 Message Center

Microsoft Entraは、internalDomainFederation設定がユーザーのUPNドメインと一致しない場合、フェデレーションサインインをブロックするようにfederatedTokenValidationPolicyのデフォルト動作を変更します。これは、設定ミスや過度に許容的なフェデレーション信頼関係によって引き起こされるクロスドメインフェデレーションサインインを防ぐセキュリティ強化措置です。

変更内容

  • 以前： クロスドメインフェデレーションサインインのブロックには明示的なテナント設定が必要
  • 以後： 2026年8月中旬からクロスドメインサインインはデフォルトでブロック
  • 範囲： internalDomainFederationオブジェクトを持つすべてのフェデレーションドメイン、特に2025年12月以前に設定されたドメイン（2025年12月以降に追加されたドメインは既にこの厳格な動作を持っています）
  • ブロックされたサインインのエラー： AADSTS5000820: Sign-in blocked by Federated Token Validation policy. Contact your administrator for details.

影響を受ける対象

  • フェデレーション認証（AD FSまたはサードパーティIdP）を使用する組織
  • 2025年12月以前にフェデレーションドメインを設定したテナント
  • 実際にクロスドメインフェデレーションサインインが発生している環境のみ影響

対応方法

  1. フェデレーションドメインのインベントリ（PowerShellを使用）：

    Connect-MgGraph -Scopes "Domain.Read.All"
Get-MgDomain | Select-Object Id, AuthenticationType, IsVerified

  2. UPN/フェデレーションドメインの不一致を確認 — ユーザーUPNサフィックスとフェデレーションドメイン名を比較

  3. サインインログでクロスドメインフェデレーションサインインを確認（Entra管理センター > Monitoring & health > Sign-in logs、authentication = federatedでフィルタ）

  4. クロスドメインサインインが必要な場合（強く非推奨）、Microsoft Graph経由でrootDomains = noneを指定したカスタムfederatedTokenValidationPolicyを作成

  5. ヘルプデスクに周知 — クロスドメインフェデレーションが発生していた場合、8月中旬からAADSTS5000820エラーが表示される可能性があります

クラウド専用およびパスワードハッシュ同期組織： アクション不要。

3. Azure Blob Storage SFTPとMicrosoft Entra IDの統合 — 一般提供

発表時期： 2026年7月9日 ステータス： 一般提供 出典： Azure Updates

Azure Blob Storage SFTPがMicrosoft Entra IDベースのIDによるアクセス管理をサポートするようになり、個別のSFTP専用資格情報が不要になりました。

新機能

  • ユーザーはMicrosoft Entra ID IDを使用してAzure Blob Storage SFTPに認証
  • 内部および外部Entra IDの両方をサポート
  • SFTPアクセスに対してConditional Accessポリシー（MFA、デバイスコンプライアンス、ネットワーク制限）を有効化
  • ローカルSFTP資格情報の管理ではなく、Entra IDガバナンスを通じたアクセス管理の一元化

なぜ重要か

SFTPは伝統的に資格情報管理の頭痛の種でした — 各ユーザーに個別の資格情報セットが必要で、IDガバナンスとの統合がなく、条件付きアクセスポリシーも適用できませんでした。Entra ID認証をSFTPに導入することで、Microsoftは資格情報の蔓延を排除し、以前はモダンIDの境界外にあったプロトコルにIDベースのセキュリティコントロールを拡張します。

パートナーやB2Bデータ交換にSFTPを必要とする規制されたワークロードを持つ組織にとって、これはSFTPアクセスが他のすべてのクラウドリソースアクセスと同じガバナンスモデルに従えることを意味します — 完全な監査証跡、条件付きアクセスの実施、Entra IDを通じたライフサイクル管理を備えています。

はじめに

Azure Blob StorageアカウントでSFTPを設定し、Azureロール割り当てを通じてEntra IDベースの権限を割り当てます。ユーザーはローカルSFTPパスワードの代わりにEntra資格情報を使用して認証できるようになります。

4. 新しいEntra IDエージェントセキュリティサービスプラン

発表時期： 2026年7月上旬 出典： M365 Message Center / AdminDroid

Microsoftは、Microsoft Entra IDのAIエージェントセキュリティ機能をサポートするための2つの新しいサービスプランを導入しています：

  • Entra Conditional Access for Agents — AIエージェントIDを特に対象としたConditional Accessポリシーを有効化
  • Entra ID Protection for Agents — Identity Protectionのリスク検出と修復をAIエージェントアカウントに拡張

新機能

これらのサービスプランは以下に含まれます：

  • Microsoft E7ライセンス
  • Microsoft 365 Agentライセンス

AIエージェント向けのConditional AccessとIdentity Protectionを使用したい組織は、更新されたライセンスモデルに移行する必要があります。

なぜ重要か

この発表は、Microsoftのエージェントセキュリティ戦略の商業的枠組みを表しています。AIエージェントを保護するための技術的機能（Agent ID、エージェント向けConditional Access、エージェントリスク検出）は過去数ヶ月間でリリースされてきましたが、ライセンスモデルが今まさに正式化されています。

大規模にAIエージェントを展開する組織にとって、これは以下を意味します：

  • Conditional Accessポリシーは、人間のユーザーと同じ精度でエージェントIDを対象にできる
  • Identity Protectionは、リスクの高いエージェントアクティビティ（侵害されたエージェント資格情報、異常なAPIアクセスパターン）を検出して対応できる
  • ライセンスは、別個のIDセキュリティアドオンを必要とするのではなく、より広範なエージェントプラットフォーム（Microsoft 365 Agent、E7）にバンドルされている

対応方法

  1. 現在のライセンスを確認 — 組織がE7またはMicrosoft 365 Agentライセンスを持っているかを確認
  2. エージェントセキュリティを計画 — AIエージェントを展開する場合、これらのサービスプランの必要性を考慮
  3. Extended Conditional Access for Agent’s user accounts機能を確認（2026年6月にパブリックプレビューとして発表）し、これらのプランがアンロックする技術的機能を理解

5. 新しいアプリケーションでアプリインスタンスロックがデフォルトで有効化

発表時期： 2026年6-7月（MC1300584） ステータス： 一般提供（2026年6月下旬にロールアウト完了） 出典： M365 Message Center、Microsoft Learn

アプリインスタンスロックが、Microsoft Entra IDの新しく作成されたすべてのアプリケーションでデフォルトで有効になりました。これにより、アプリケーションのホームテナント外で機密性の高いサービスプリンシパルプロパティが変更されるのを防ぎます。

保護されるプロパティ

以下のプロパティがデフォルトでロックされます：

  • keyCredentials — トークン署名に使用される証明書ベースの資格情報
  • passwordCredentials — 検証に使用されるパスワードベースの資格情報
  • tokenEncryptionKeyId — トークン暗号化キー参照

ロックされている場合、ホームテナント外からこれらのプロパティを変更しようとすると400 Bad Requestエラーが返され、変更は適用されません。

なぜ重要か

アプリインスタンスロックは、「アプリハイジャック」として知られる攻撃のクラスに対処します — 顧客テナントの管理者がマルチテナントアプリケーションのサービスプリンシパルに資格情報を作成し、それらを使用してアプリケーションを偽装する攻撃です。この手法は、有名なSolarWinds攻撃を含む実際の攻撃で使用されてきました。

すべての新しいアプリケーションでこのロックをデフォルトで有効にすることで、Microsoftは、アプリ開発者がオプトインすることなく、マルチテナントアプリの最も一般的な攻撃経路をブロックします。既存のアプリケーションはこの変更の影響を受けません。

対応方法

  1. 新しいアプリケーション： アクション不要 — ロックは自動的に有効化
  2. 既存のアプリケーション： まだ設定されていない場合、アプリインスタンスロックを手動で有効化することを検討
  3. 自動化/スクリプトの確認： プロビジョニングワークフローがホームテナント外からのサービスプリンシパル資格情報の変更に依存していないことを確認
  4. 更新が必要な場合： 管理者はEntra管理センターまたはMicrosoft Graph経由でアプリごとにロックを無効化可能

PowerShellで既存のアプリケーションに有効化する場合：

Connect-MgGraph -Scopes "Application.ReadWrite.All"
$params = @{
    servicePrincipalLockConfiguration = @{
        isEnabled = $true
        allProperties = $true
    }
}
Update-MgApplication -ApplicationId "<APPLICATION_OBJECT_ID>" -BodyParameter $params

6. Microsoft Graph API 2026年7月ID更新

発表時期： 2026年7月8日 ステータス： パブリックプレビュー 出典： Microsoft Graph新機能

2026年7月のMicrosoft Graph API更新は、パブリックプレビューでいくつかの新しいIDおよびガバナンス機能を導入し、よりプログラマブルで自動化されたID管理を実現します。

プログラマティックなFIDO2パスキー登録

新しいAPIにより、FIDO2パスキーのプログラマティックな登録が可能に：

  • creationOptions関数を使用してWebAuthn資格情報作成オプションを生成
  • publicKeyCredentialプロパティをfido2AuthenticationMethodリソースにPOSTして登録を完了

なぜ重要か： 大規模なユーザーをフィッシング耐性認証にオンボーディングする際、各ユーザーに手動登録を要求するのではなく、パスキーの一括/自動プロビジョニングが可能になります。

アクセスパッケージサジェスチョン

新しいaccessPackageSuggestionリソースタイプと関連メソッド：

  • 関連する人物インサイトと割り当て履歴に基づく推奨アクセスパッケージの発見
  • パーソナライズされた推奨のためのfilterByCurrentUser関数
  • サジェスチョン動作と承認者詳細の可視性を設定するための新しいendUserSettingsリソース

なぜ重要か： Entitlement Managementにインテリジェントな推奨をもたらし、類似ユーザーが持っているアクセスパッケージを発見するのに役立ちます — 過剰プロビジョニングとアクセスギャップの両方を削減します。

ライフサイクルワークフローの強化

  • 進行中またはキューに入ったワークフロー実行をキャンセルする**cancelProcessing**メソッド
  • 自動検疫 — ワークフローが予想より多くのユーザーを処理する場合、lifecycleManagementSettingsのquarantineConfigurationプロパティで設定可能な閾値
  • 検疫状態をクリアする**clearQuarantine**
  • 本番ユーザーに影響を与えずにタスクを検証するプレビュー操作

なぜ重要か： 自動化されたライフサイクルワークフローの信頼性と安全性を向上させます。検疫動作は意図したより多くのユーザーに影響を与える暴走ワークフローを防ぎ、キャンセル機能は管理者に緊急ブレーキを提供します。プレビューモードはリスクなしでテストを可能にします。

アクセスパッケージサブジェクト管理

  • 外部ディレクトリユーザーサブジェクトのライフサイクルを管理するためのaccessPackageSubjectのGetおよびUpdateメソッド
  • 要求者に承認者情報を表示するかどうかを制御するaccessPackageApprovalStageのapproverInformationVisibilityプロパティ
  • Azureリソースロールがアクティブか対象かを示すaccessPackageResourceRoleのtypeプロパティ（アクセスパッケージでPIMベースのロール割り当てを有効化）

なぜ重要か： アクセスパッケージガバナンスのよりきめ細かい制御を提供します — 外部ユーザーライフサイクルの管理から、承認ワークフローでの情報可視性の制御、アクセスパッケージを通じたPIMベースのジャストインタイムアクセスのサポートまで。

大きな絵：2026年のIDセキュリティの成熟

これら6つの発表は、個別に重要であるだけでなく、2026年のIDセキュリティの成熟についてのストーリーを共同で語っています：

  1. 可視性の向上 — サービスプリンシパルの監査ログプロパティの強化は、テナントで何が起きているかを理解するための重要なギャップを埋めます。「誰がこのサービスプリンシパルを作成し、なぜ？」という質問に、フォレンジック調査なしで答えられるようになりました。

  2. セキュリティデフォルトの強化 — デフォルトでのアプリインスタンスロックの有効化と、より厳格なフェデレーショントークン検証はどちらも、明示的なオプトインを必要とせずにMicrosoftがセキュリティのフロアを引き上げていることを表しています。トレンドは明確です：デフォルトでセキュアはオプションではなく標準になりつつあります。

  3. AIエージェントセキュリティの正式化 — エージェント向けのConditional AccessとIdentity Protectionの新しいサービスプランは、Microsoftが人間のIDと同じ厳密さでAIエージェントを管理する商業的および技術的枠組みを構築していることを示しています。

  4. 自動化の拡大 — Graph APIの更新（プログラマティックなパスキー登録、ワークフローのキャンセル/検疫、アクセスパッケージサジェスチョン）は、MicrosoftがIDガバナンスのプログラマビリティに投資していることを示しています — 手動プロセスではなく、コードを通じて大規模にIDを管理することを容易にします。

  5. 従来プロトコルがモダンID時代に参加 — SFTPへのEntra IDベースの認証は、レガシープロトコルをConditional AccessとIDガバナンスの対象に組み込み、長年存在していたギャップを排除します。

今すぐ取るべきアクション

  1. サービスプリンシパルの監査ログを確認 — 過去30日間の「Add service principal」イベントをフィルタし、新しいServicePrincipalProvisioningTypeプロパティを使用して予期しないテナント主導の作成を特定する。

  2. フェデレーション設定を監査 — AD FSまたはサードパーティIdPを使用している場合、2026年8月の施行前にUPNドメインがフェデレーションドメインと一致することを確認。クロスドメインサインインは機能しなくなります。

  3. 既存のマルチテナントアプリでアプリインスタンスロックを有効化 — これは新しいアプリのみのデフォルトですが、既存のマルチテナントアプリケーションでもプロアクティブに有効化すべきです。

  4. エージェントセキュリティライセンスを評価 — AIエージェントがロードマップにある場合（あるべきです）、新しいEntra Conditional Access for AgentsおよびEntra ID Protection for Agentsサービスプランが必要かを確認。

  5. Graph APIプレビュー機能を探索 — 自動化を通じて大規模にIDを管理している場合、プログラマティックなFIDO2登録とライフサイクルワークフロー検疫APIは開発テナントでテストする価値があります。

  6. Azure Blob StorageでSFTPを使用しているか確認 — そうであれば、ガバナンスとセキュリティの向上のために、ローカル資格情報からEntra IDベースの認証への移行を評価。

Kevin KaminskiはBig Hat Group Inc.のオーナーで、AIとクラウドテクノロジーに焦点を当てたMicrosoftパートナー企業です。https://x.com/kkaminsk で彼をフォローして、Microsoft Entraのインサイトをさらに入手してください。