「Connect your TIP with the upload API (Preview) – Microsoft Sentinel」は、TIP（Threat Intelligence Platform）や独自の脅威インテリジェンスフィードを、STIX形式のデータとしてMicrosoft Sentinelへ取り込むための公式手順です。結論として、管理者と開発者がまず確認すべきポイントは、データコネクタなしで取り込めること、Microsoft Entraアプリ登録とMicrosoft Sentinel Contributorロールが必要なこと、APIがプレビューであること、AzureポータルからMicrosoft Defenderポータルへの移行計画も同時に考える必要があることです。公式ドキュメントは2026年5月14日に更新されており、既存のTIP連携やカスタムフィードを運用している組織は、認証・権限・STIX形式・スロットリング制限を事前に点検しておくべきです。(Microsoft Learn)
Microsoft Sentinelのupload APIは何をする機能か
Microsoft Sentinelのupload APIは、TIPや自社開発の脅威インテリジェンス配信基盤から、STIXオブジェクトをMicrosoft SentinelへアップロードするためのAPIです。公式ドキュメントでは、データコネクタをインストールしなくても脅威インテリジェンスを取り込める方法として説明されています。(Microsoft Learn)
ここでいうTIPとは、複数の外部フィード、ISAC、商用インテリジェンス、社内調査結果などを集約し、EDR/XDR、SIEM、ネットワーク機器などに配信するための基盤です。upload APIを使うと、こうしたTIPやカスタムアプリケーションから、Microsoft Sentinelの脅威インテリジェンス機能へ直接データを投入できます。
特に重要なのは、単なるIPアドレスやドメインのリストだけでなく、STIXで表現されるより広い脅威情報を扱える点です。公式APIリファレンスでは、indicator、attack pattern、threat actor、identity、relationshipなどのSTIXドメインオブジェクトがサポート対象として示されています。(Microsoft Learn)
今回の公式情報で押さえるべき変更点
今回の内容は「一般提供開始」ではなく、プレビュー機能の接続手順とAPI仕様の整理として理解するのが適切です。運用中の環境にすぐ強制的な変更が入るというより、今後の脅威インテリジェンス連携を設計・移行するために確認すべき情報が明確になったと捉えるとよいでしょう。
| 観点 | 確認すべき内容 | 実務上の意味 |
|---|---|---|
| 取り込み方式 | データコネクタなしでupload APIへ送信可能 | TIPや自社スクリプトから直接連携しやすくなる |
| データ形式 | STIX 2.0または2.1形式のSTIXオブジェクトを利用 | 既存フィードが独自JSONやCSVの場合は変換処理が必要 |
| 認証 | Microsoft Entra IDのアクセストークンを使用 | アプリ登録、シークレットまたは証明書、トークン取得処理が必要 |
| 権限 | ワークスペースレベルでMicrosoft Sentinel Contributorロールが必要 | リソースグループ単位ではなく、対象ワークスペース単位で権限確認が必要 |
| API状態 | Preview | 本番利用時は仕様変更や制限に備えた設計が必要 |
| 既存API | 以前のupload indicators APIはlegacy扱い | 既存実装がある場合は新APIへの移行計画を検討する |
公式情報では、Microsoft Sentinelの脅威インテリジェンスupload APIはプレビューであり、Azureのプレビュー機能に関する追加条件が適用されると説明されています。また、従来のupload indicators APIはlegacyとして位置付けられています。(Microsoft Learn)
対象になる管理者・開発者
この情報を優先して確認すべきなのは、次のような担当者です。
| 対象者 | 確認すべきポイント |
|---|---|
| Microsoft Sentinel管理者 | ワークスペース、ロール割り当て、Defenderポータル移行計画 |
| Microsoft Defender運用担当者 | 統合セキュリティ運用の中で脅威インテリジェンスをどう使うか |
| TIP管理者 | 出力形式、STIX変換、アップロード頻度、フィード品質 |
| 開発者 | OAuth 2.0認証、APIリクエスト、エラーハンドリング、スロットリング対策 |
| SOCアナリスト | 取り込まれたインジケーターの検索、分析ルール、タグ運用 |
特に、Microsoft Defenderポータル上でMicrosoft Sentinelを利用している、または今後移行する予定がある組織では、単なるAPI接続だけでなく、ポータル移行後の運用導線まで含めて確認する必要があります。公式ドキュメントでは、2027年3月31日以降、Microsoft SentinelはAzureポータルではサポートされず、Microsoft Defenderポータルで利用する形になると案内されています。(Microsoft Learn)
upload APIを使う前提条件
upload APIを使うには、Microsoft Sentinel側とMicrosoft Entra ID側の両方で準備が必要です。公式ドキュメントでは、前提条件として次の3点が示されています。(Microsoft Learn)
| 前提条件 | 内容 | 失敗しやすいポイント |
|---|---|---|
| Sentinelワークスペースへの読み取り・書き込み権限 | STIXオブジェクトを保存するために必要 | 閲覧権限だけでは取り込みに失敗する |
| Microsoft Entraアプリ登録 | API呼び出し用のアプリケーションIDを取得する | テナントの設定により一般ユーザーがアプリ登録できない場合がある |
| Microsoft Sentinel Contributorロール | Entraアプリにワークスペースレベルで付与する | サブスクリプションやリソースグループの権限だけを確認して見落とす |
実務では、最初に「誰の権限でAPIを呼ぶのか」を決めることが重要です。個人ユーザーの資格情報に依存すると、退職・異動・MFA変更・条件付きアクセスの変更で連携が止まる可能性があります。TIP連携や自動投入では、Microsoft Entraアプリを使い、権限を最小限に絞って管理する構成が基本になります。
設定手順の全体像
公式手順では、TIPまたはカスタム脅威インテリジェンスソリューションからMicrosoft SentinelへSTIXオブジェクトを取り込む流れとして、Microsoft Entraアプリの登録、クライアントシークレットの生成、ロール割り当て、TIPまたはカスタムアプリ側の設定が示されています。(Microsoft Learn)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Microsoft Entraアプリを登録する | アプリケーションIDを記録する |
| 2 | クライアントシークレットまたは証明書を準備する | 有効期限とローテーション方法を決める |
| 3 | アプリにMicrosoft Sentinel Contributorロールを付与する | 対象ワークスペースのIAMで割り当てる |
| 4 | TIPまたはカスタムアプリに接続情報を設定する | アプリID、トークン取得、ワークスペースIDを設定する |
| 5 | upload APIへSTIXオブジェクトをPOSTする | レスポンスコードとエラー本文を確認する |
| 6 | Microsoft SentinelのThreat intelligenceページで確認する | 数分後にオブジェクトが流入するか確認する |
最初から全フィードを流すのではなく、まずは検証用ワークスペースや少量のSTIXオブジェクトで接続確認を行うのが安全です。取り込みに成功した後で、本番ワークスペース、分析ルール、タグ運用、インシデント対応フローへ広げていきます。
API実装で確認すべきリクエスト仕様
upload APIを呼び出すには、Microsoft Entra IDで取得したアクセストークンをAuthorizationヘッダーに設定し、JSON形式の本文をPOSTします。公式リファレンスでは、エンドポイント、メソッド、APIバージョン、ヘッダー、リクエスト本文の要素が示されています。(Microsoft Learn)
| 項目 | 仕様 |
|---|---|
| メソッド | POST |
| エンドポイント | https://api.ti.sentinel.azure.com/workspaces/{workspaceId}/threat-intelligence-stix-objects:upload?api-version={apiVersion} |
| APIバージョン | 2024-02-01-preview |
| Authorization | OAuth2 Bearer Token |
| Content-Type | application/json |
| 必須フィールド | sourcesystem、stixobjects |
リクエスト本文では、sourcesystemに送信元システム名を指定し、stixobjectsにSTIXオブジェクトの配列を入れます。ただし、公式リファレンスではMicrosoft Sentinelという値はsourcesystemとして制限されているため、送信元名には自社TIP名やカスタムアプリ名など、実際のソースを識別できる名称を使うべきです。(Microsoft Learn)
STIXオブジェクトで特に確認したい項目
STIX形式では、単に「IPアドレスを送る」だけではなく、オブジェクトの種類、ID、作成日時、更新日時、有効期間、信頼度、ラベル、外部参照などを定義できます。公式リファレンスでは、共通プロパティとしてid、type、created、modified、labels、confidence、object_marking_refs、external_referencesなどが説明されています。(Microsoft Learn)
| 項目 | 実務での使い方 |
|---|---|
id | 同一インジケーターの重複や更新を管理する |
type | indicator、threat actorなどの種類を明確にする |
confidence | アナリストが優先度を判断できるようにする |
labels | Sentinel上ではタグとして活用できるため、分類や検索に使う |
valid_from / valid_until | 古いIoCをいつまで有効とみなすかを管理する |
object_marking_refs | TLPなどの共有制限や取り扱い区分を表現する |
external_references | 元レポートや外部ソースとの対応を残す |
ここを雑に設計すると、取り込み自体は成功しても、SOCアナリストが使いにくいデータになります。たとえば、confidenceが常に空、labelsがソースごとにバラバラ、valid_untilが設定されていない、といった状態では、優先度判断や古いインジケーターの整理が難しくなります。
認証と権限設定で失敗しやすいポイント
upload APIでは、Microsoft Entra IDのOAuth 2.0認証を利用します。公式リファレンスでは、Microsoft Entraアクセストークンが必要であり、MSALを使ってv1.0またはv2.0のアクセストークンを取得できること、APIが受け付けるaudienceとしてAzure管理系の値が示されています。(Microsoft Learn)
実装時に多い失敗は、次のようなものです。
| 症状 | よくある原因 | 確認方法 |
|---|---|---|
| 401 Unauthorizedになる | トークンの取得先、scope、audience、シークレットが誤っている | トークン取得処理とAuthorizationヘッダーを確認する |
| 403相当の権限エラーになる | EntraアプリにMicrosoft Sentinel Contributorロールがない | ワークスペースのAccess control（IAM）を確認する |
| 404になる | workspaceIdが誤っている | SentinelワークスペースIDを再確認する |
| 400 Bad formatになる | JSON本文またはSTIX形式が不正 | sourcesystem、stixobjects、必須プロパティを確認する |
| 一部だけ取り込まれない | STIXオブジェクト単位で検証エラーがある | レスポンス本文のrecordIndexとerrorMessagesを確認する |
開発者は、HTTPステータスコードだけで成否を判断せず、レスポンス本文に含まれるエラーメッセージまでログに残すべきです。公式リファレンスでは、エラー本文にrecordIndexとerrorMessagesが含まれる形式が示されているため、どのSTIXオブジェクトで失敗したのかを追跡できるようにしておくと、運用時の切り分けが速くなります。(Microsoft Learn)
スロットリング制限と送信設計
upload APIにはスロットリング制限があります。公式リファレンスでは、1リクエストあたり100オブジェクト、1分あたり100リクエストが上限として示され、上限を超えるとHTTP 429が返ると説明されています。(Microsoft Learn)
| 制限 | 内容 |
|---|---|
| 1リクエストの上限 | 100オブジェクト |
| 1分あたりの上限 | 100リクエスト |
| スロットリング時 | HTTP 429が返る |
| 最大スループットの目安 | 約10,000オブジェクト/分 |
この制限を踏まえると、TIP側では次のような設計が必要です。
- 100件を超えるSTIXオブジェクトは分割して送信する
- 429が返った場合は即時再試行せず、待機してから再送する
- 同じオブジェクトを何度も送って重複処理を増やさない
- 緊急度の高いフィードと低いフィードを同じキューで混在させない
- 送信成功、失敗、再試行回数をログ化する
特に大規模な商用TIPや複数ソースを束ねている環境では、毎時・毎分の投入量を見積もる必要があります。日次で数十万件のIoCを同期するような設計ではなく、差分投入、期限切れ管理、優先度制御を組み合わせる方が現実的です。
既存のupload indicators API利用者が確認すべきこと
公式リファレンスでは、以前のupload indicators APIはlegacyになったと説明されています。既存実装がすぐに停止するという意味ではありませんが、今後の新規開発や改修では、新しいupload APIを前提に検討するのが自然です。(Microsoft Learn)
既存の連携がある場合は、次の観点で棚卸ししてください。
| 確認項目 | 見るべき内容 |
|---|---|
| 利用中のAPI | legacyのupload indicators APIを呼んでいないか |
| データ形式 | 単純なindicator中心か、STIXドメインオブジェクトまで扱う必要があるか |
| 認証方式 | 個人アカウントや古いシークレットに依存していないか |
| 送信先 | workspaceId、テナント、環境が正しいか |
| エラー処理 | 400、401、404、429、500を分けて処理しているか |
| 運用監視 | 取り込み失敗に気づけるログや通知があるか |
移行時は、「APIのURLだけ変える」発想では不十分です。新APIではSTIXオブジェクトの構造や対応オブジェクトを意識する必要があるため、変換ロジック、項目マッピング、テストデータ、SOC側の見え方まで確認しましょう。
Microsoft Defenderポータル移行との関係
この機能はMicrosoft Sentinelの脅威インテリジェンス連携ですが、Microsoft Defenderポータル上の統合セキュリティ運用とも関係します。公式ドキュメントでは、Microsoft SentinelはMicrosoft DefenderポータルとAzureポータルの両方に適用されると記載されており、さらにAzureポータルでのMicrosoft Sentinelサポート終了に向けた移行計画が案内されています。(Microsoft Learn)
管理者は、API接続だけを見て完了にしないことが重要です。以下のように、Defenderポータル移行後の運用を前提に確認してください。
| 確認領域 | 確認内容 |
|---|---|
| 脅威インテリジェンス画面 | 取り込んだSTIXオブジェクトをどこで確認するか |
| 分析ルール | 取り込んだIoCを検知ルールやハンティングでどう使うか |
| SOC手順書 | Defenderポータル上での確認手順に更新されているか |
| 権限設計 | Defenderポータル利用者とSentinelワークスペース権限が整合しているか |
| 移行タイミング | Azureポータル依存の手順やスクリーンショットが残っていないか |
社内手順書に「AzureポータルでMicrosoft Sentinelを開く」とだけ書かれている場合、将来的に運用現場で混乱しやすくなります。APIの実装と同時に、画面確認、調査手順、教育資料もMicrosoft Defenderポータル前提へ更新しておくと、移行時の手戻りを減らせます。
展開前チェックリスト
本番展開前には、次のチェックリストを使って確認すると抜け漏れを減らせます。
| チェック項目 | 確認済み |
|---|---|
| Microsoft EntraアプリのアプリケーションIDを記録した | □ |
| クライアントシークレットまたは証明書の有効期限を管理している | □ |
| 対象ワークスペースにMicrosoft Sentinel Contributorロールを付与した | □ |
| workspaceIdが正しいことを確認した | □ |
| OAuth 2.0トークン取得処理を検証した | □ |
Content-Type: application/jsonで送信している | □ |
sourcesystemに適切な送信元名を設定した | □ |
| STIX 2.0または2.1として妥当なJSONを送信している | □ |
| 1リクエスト100オブジェクト以内に分割している | □ |
| 429発生時の待機・再試行処理を実装した | □ |
| 400、401、404、429、500の処理を分けている | □ |
| 取り込み後にThreat intelligenceページで確認した | □ |
| 既存のlegacy API利用有無を確認した | □ |
| Defenderポータル移行後の運用手順を確認した | □ |
このチェックリストで特に重要なのは、権限、STIX形式、スロットリングの3つです。権限が不足していれば取り込みは始まりません。STIX形式が崩れていればデータ品質が落ちます。スロットリングを考慮していなければ、大量フィード投入時に連携が不安定になります。
実務でおすすめの展開順序
本番環境で安全に進めるなら、次の順序が現実的です。
| フェーズ | 作業 | 目的 |
|---|---|---|
| 検証 | 少数のSTIXオブジェクトを手動またはスクリプトで送信 | 認証、権限、API疎通を確認する |
| マッピング | TIP項目をSTIXプロパティへ対応付ける | Sentinel上で使いやすいデータに整える |
| 小規模展開 | 1つのフィードだけを定期投入する | スロットリング、エラー、重複を確認する |
| SOC確認 | Threat intelligenceページ、分析ルール、ハンティングで確認 | アナリストが実際に使えるか検証する |
| 本番展開 | 複数フィードへ拡張する | 連携を標準運用に組み込む |
| 継続改善 | 期限切れ、信頼度、タグ、TLPを見直す | ノイズを減らし、検知品質を上げる |
最初から「すべてのIoCをSentinelに入れる」方針にすると、ノイズが増えやすくなります。むしろ、SOCが実際に使うユースケースから逆算して、優先度の高いフィード、信頼度の高いインジケーター、対応アクションが明確なデータから投入する方が効果的です。
管理者・開発者が今すぐ確認すべきこと
今回の公式情報で最も重要なのは、upload APIが単なる取り込み口ではなく、TIP連携をMicrosoft Defenderポータル時代のMicrosoft Sentinel運用に合わせて整理するきっかけになる点です。
管理者は、対象ワークスペース、Microsoft Entraアプリ、Microsoft Sentinel Contributorロール、Defenderポータル移行計画を確認してください。開発者は、STIX 2.0/2.1形式、OAuth 2.0認証、APIバージョン、エラー処理、スロットリング制御を確認してください。SOC運用担当者は、取り込まれた脅威インテリジェンスが分析ルールやハンティングで実際に役立つ形になっているかを確認する必要があります。
次に取るべき行動は明確です。まず既存のTIP連携とカスタムフィードを棚卸しし、legacy APIや手動投入に依存していないかを確認します。そのうえで、検証用ワークスペースに少量のSTIXオブジェクトを送信し、認証、権限、表示、エラー処理、スロットリングを順番に検証しましょう。プレビュー機能であることを前提に、仕様変更に備えたログ、再試行、ロールバック手順まで用意しておくと、本番展開時のリスクを抑えられます。
コメント