【APIM連載第2回】Azure API Management 応用編 - ポリシーとセキュリティを極める

第1回ではAzure API Management（APIM）の基本概念とAPI登録方法を学びました。今回は、ポリシー機能を使ったAPI動作の制御、高度なセキュリティ設定、バックエンドサービスとの統合など、本番環境で必要となる実践的なテクニックを詳しく解説します。

本記事を読むことで、APIのセキュリティ強化、パフォーマンス最適化、そして柔軟なAPI管理が可能になります。

この記事を読むとできるようになることは以下の通りです。

ポリシーを使ってAPI動作を柔軟に制御できる
レート制限でAPIを保護できる
IP制限で多層防御を実装できる
バックエンドサービスとの統合パターンを理解できる

※本記事は、第1回の内容を理解していることを前提としています。第1回の内容を理解していると、よりスムーズに理解できます。未読の方は、先に第1回をご覧いただくと理解が深まります。 blog.jbs.co.jp

開発者ポータルの詳細
ポリシーの活用
バックエンドサービスとの統合
まとめ

開発者ポータルの詳細

このセクションでは、以下を学びます。

開発者ポータルの役割と主要機能を理解する
API利用者がどのようにセルフサービスでAPIを利用開始できるかを学ぶ

開発者ポータルの役割

開発者ポータルは、API利用者（開発者）向けのセルフサービスポータルです。主な特徴は以下の通りです。

APIMインスタンス作成時に自動生成される
Azure Portalから「発行」操作を行うことで利用可能になる
一度発行すれば、API利用者が自由にアクセスできる

開発者ポータルにより、API提供者と利用者の間の手動的なやり取りを最小限に抑え、迅速なAPI利用開始が可能になります。

開発者ポータルの公開手順

初めて開発者ポータルを利用する場合は、以下の手順で公開します。

左側のメニューから「開発者ポータル」を選択
「公開」ボタンをクリック　
開発者ポータル公開画面
発行完了後、「ポータルURL」リンクから開発者ポータルにアクセス

本記事ではデフォルトの標準機能とUIを使用して解説します。開発者ポータルはロゴ、色、レイアウトなどのカスタマイズが可能ですが、ここでは扱いません。

なお、カスタマイズが必要な場合は、以下の手順で「開発者ポータル」を開いて操作できます。

では、実際に開発者ポータルの主要機能を見ていきましょう。

API利用者のセルフサービス体験

開発者ポータルを使用することで、API利用者は管理者の介入なしに、すぐにAPIの利用を開始できます。

開発者ポータルは以下の機能が提供されます。

機能	説明
ユーザー登録	セルフサービスでアカウント作成
サインイン	Microsoft Entra ID、GitHub、Googleなど複数の認証方式をサポート
製品へのサブスクリプション	利用したい製品にサブスクライブ
APIキー管理	主キー・副キーの表示、再生成
API一覧表示	公開されているAPIを表示
APIドキュメント	各APIの詳細定義、パラメータ、レスポンス例を表示
インタラクティブコンソール	ブラウザ上でAPIを直接テスト実行

ホーム画面

開発者ポータルのURLhttps://[APIMインスタンス名].developer.azure-api.netを開くと、ホーム画面が表示されます。

ホーム画面には、以下のようなメニューが表示されています。

メニュー	説明
Home	開発者ポータルのトップページ
APIs	公開されているAPI一覧。各APIの詳細定義やドキュメントにアクセス可能
Products	利用可能な製品一覧。製品にサブスクライブしてAPIキーを取得する
Sign In	アカウントを持っているユーザーがサインインする
Sign Up	新規ユーザーがアカウントを作成する

それでは、実際にAPI利用者がどのように開発者ポータルを利用するのか見ていきましょう。

ユーザー登録＆サインイン

APIを利用するには、まず開発者ポータルでアカウントを作成する必要があります。

1, ホーム画面でSign Upボタンをクリック

2, メールアドレス、名前、パスワード等を入力

3, 登録したメールアドレスに確認メールが届く

4, メール内のリンクをクリックして認証完了

アカウント作成後は、以下の方法でサインインできます。

認証方式	説明
メールアドレス＆パスワード	登録時に設定したメールアドレスとパスワードでサインイン
Microsoft Entra ID	組織のMicrosoft Entra IDアカウントでサインイン（要設定）
GitHub	GitHubアカウントでサインイン（要設定）
Google	Googleアカウントでサインイン（要設定）

外部認証プロバイダーの設定について

Microsoft Entra ID、GitHub、Googleなどの外部認証プロバイダーとの連携設定は、Azure Portalの「開発者ポータル」→「ID」から設定できます。設定完了後、サインイン画面に該当する認証ボタンが表示されます。

また、セキュリティ要件に応じて、メールアドレス＆パスワード認証を無効にすることも可能です。

製品へのサブスクライブ&APIキー管理

サインイン後、利用したいAPIが含まれる製品にサブスクライブし、APIキーを取得します。

メニューからProductsを選択
利用したい製品を選択（例: Starter）
サブスクリプション名を入力
Subscribeボタンをクリック

製品の設定により、以下の2つの承認フローがあります。

承認タイプ	説明	利用開始までの時間
自動承認	サブスクライブ後、即座にAPIキーが発行され、アクティブ（利用可能）状態になる	即時
手動承認	管理者が承認するまでAPIキーは発行されない	管理者承認後

サブスクリプション承認後、以下の手順でAPIキーを確認・管理できます。

画面右上のユーザーアイコンをクリック
Profileを選択
SubscriptionsタブでAPIキーを確認

各サブスクリプションには、主キー（Primary Key）と副キー（Secondary Key）の2種類が提供されます。この2つのキーを活用することで、サービスを停止することなく安全にキーローテーションを実施できます。

以下の操作が可能です。

Show keys: マスクされたキーの全体を表示
Regenerate Primary/secondary Key: 新しいキーに再生成（古いキーは無効化される）
Cancel Subscription: サブスクリプションを無効化する

API一覧表示とドキュメント確認

メニューからAPIsを選択すると、公開されているAPIを確認できます。

APIドキュメントで確認できる情報は以下です。

パラメータ
レスポンス例
API定義書（ダウンロード可能）

インタラクティブコンソールでテスト

開発者ポータルでは、ブラウザ上で直接APIをテストできるインタラクティブなコンソールが提供されています。

APIsメニューから利用したいAPIを選択
テストしたい操作（エンドポイント）を選択
Try This operationボタンをクリック
テストコンソールで必要なパラメータを入力
- すでにサブスクリプションキーを取得している場合、「Subscription key」ドロップダウンには自動的に入力されます
SendボタンをクリックしてAPIをリクエスト
レスポンス確認

ポリシーの活用

このセクションでは、以下を学びます。

ポリシーでAPI動作を制御する方法を理解する
ポリシーの実行順序と各セクションの役割を把握する
レート制限、リクエスト・レスポンス変換などの実装方法を学ぶ

ポリシーとは

ポリシーは、APIリクエストとレスポンスの処理フローを制御するXML形式のルールです。APIMの最も強力な機能の1つで、コードを変更することなく、API動作を柔軟に制御できます。

ポリシーで実現できる主な機能は以下です。

カテゴリ	機能例
認証・認可	OAuth 2.0、JWT検証、APIキー検証
トラフィック制御	レート制限、クォータ管理、同時接続数制限
データ変換	リクエスト・レスポンスの書き換え、フォーマット変換
セキュリティ	IP制限、CORS設定、ヘッダーのマスキング
統合	バックエンドURL変更、リトライ、タイムアウト設定

ポリシーの実行順序

ポリシーは4つのセクションで構成され、APIリクエストの処理フローに沿って順次実行されます。

セクション	実行タイミング	主な用途
inbound	クライアントからのリクエスト受信後、バックエンドへ転送前	認証、レート制限、リクエスト変換、ヘッダー追加
backend	バックエンドサービスへのリクエスト送信時	バックエンドURL変更、タイムアウト設定、リトライ
outbound	バックエンドからのレスポンス受信後、クライアントへ返却前	レスポンス変換、ヘッダー追加、データマスキング
on-error	処理中にエラーが発生した場合	エラーログ記録、カスタムエラーレスポンス

ポリシーの設定方法

ポリシーは、Azure PortalのAPIのDesignタブから設定できます。

設定方法はいかです。

XMLエディターで編集: </>アイコンをクリックし、XMLエディターで直接ポリシーを記述

UIから設定: + Add policyボタンをクリックし、専用UIからポリシーを選択（初心者におすすめ）

では、よく利用されるポリシーの実装例を見ていきましょう。

レート制限ポリシー

レート制限は、APIの過度な使用を防ぎ、バックエンドサービスを保護する重要なポリシーです。

基本的なレート制限（全体）では、すべてのリクエストに対して1分間に100回までのアクセスを許可するように設定できます。たとえば次のように記述します。

<inbound>
    <rate-limit calls="100" renewal-period="60" />
</inbound>

サブスクリプションキーごとの制限では、各サブスクリプション（API利用者）ごとに個別の上限を設定できます。たとえば次のように記述します。

<inbound>
    <rate-limit-by-key calls="100" renewal-period="60" 
                       counter-key="@(context.Subscription.Id)" />
</inbound>

パラメータ	説明	例
`calls`	期間内の最大呼び出し回数	`100`
`renewal-period`	制限期間（秒）	`60`（1分）
`counter-key`	レート制限のキー（キーごとに個別カウント）	サブスクリプションID、IPアドレスなど

リクエスト・レスポンス変換ポリシー

APIの入出力を変換することで、バックエンドサービスを変更せずにAPI仕様を調整できます。

カスタムヘッダーの追加や、セキュリティ上削除すべきヘッダーの除去を行います。

<inbound>
    <!-- カスタムヘッダーの追加 -->
    <set-header name="X-Custom-Header" exists-action="override">
        <value>custom-value</value>
    </set-header>
    
    <!-- サブスクリプションキーヘッダーの削除（バックエンドに送信しない） -->
    <set-header name="Ocp-Apim-Subscription-Key" exists-action="delete" />
</inbound>

リクエストにデフォルト値を設定したり、パラメータを追加できます。

<inbound>
    <!-- デフォルトのlimitパラメータを追加 -->
    <set-query-parameter name="limit" exists-action="override">
        <value>10</value>
    </set-query-parameter>
</inbound>

バックエンドのレスポンスにヘッダーを追加できます。

<outbound>
    <!-- レスポンスヘッダーの追加 -->
    <set-header name="X-Powered-By" exists-action="override">
        <value>Azure APIM</value>
    </set-header>
</outbound>

IP制限ポリシー

特定のIPアドレスからのアクセスのみを許可します。

たとえば次のように記述します。

<inbound>
    <ip-filter action="allow">
        <address>203.0.113.10</address>
        <address-range from="198.51.100.0" to="198.51.100.255" />
    </ip-filter>
</inbound>

ベストプラクティスとしては以下のとおりです。

ポリシーのスコープ: 全体、製品、API、操作の各レベルで適切に配置
テスト: 本番環境適用前に開発環境で十分にテスト

バックエンドサービスとの統合

このセクションでは、以下を学びます。

App ServiceをAPIMのバックエンドとして統合する
IP制限で多層防御を実装する

APIMとApp Serviceを統合することで、バックエンドAPIを保護しながら、統一されたAPIゲートウェイとして機能させることができます。

以下はセキュリティアーキテクチャ図です。

────────────────────────────────────────────────────
                      特定クライアント                          
           例: 社内ネットワーク、開発環境など                    
────────────────────────────────────────────────────
                     |
                     | 1. IP制限 (APIM ポリシー)
                     ↓
────────────────────────────────────────────────────
            API Management (APIM)   
            ・サブスクリプションキー認証  
────────────────────────────────────────────────────
                     |
                     | 2. IP制限 (App Service ネットワーク)
                     ↓
────────────────────────────────────────────────────
             App Service (API)      
             ・APIM IPのみ許可        
────────────────────────────────────────────────────

レイヤー	設定場所	保護内容
第1層	APIMポリシー	特定クライアントIPのみ許可
第2層	APIMサブスクリプション	APIキー認証
第3層	App Serviceネットワーク	APIM IPのみ許可

Step 1: App Service（バックエンドAPI）の準備

APIをAzure App Serviceにデプロイ
HTTPSで正常にアクセスできることを確認 https://<appservice-name>.azurewebsites.net
APIのエンドポイントとレスポンスが安定していることを確認

Step 2: APIMにApp ServiceをAPIとして追加

APIM → APIs → + Add API → App Serviceを選択

Browse をクリックし、対象の App Service を選択する
- 画面の案内に従い、API 名、API URL サフィックス、製品（必要に応じて） などの必須項目を入力する

Createをクリック

Step 3: ワイルドカード操作のテスト

選択したWeb AppにOpenAPI定義が関連付けられている場合、API Managementはそれをフェッチしてインポートします。
OpenAPI定義が見つからない場合、API Managementは一般的なHTTP動詞のワイルドカード操作を生成してAPIを公開します。

ワイルドカード操作のテスト手順：

ワイルドカード操作は、バックエンドAPIに直接マップされない場合があります。

例: APIMにインポートされるワイルドカードGET操作は、デフォルトでパス / を使用しますが、このデモで使用するWeb Appには /api/cart/mock エンドポイントしか存在しません。

作成したAPIを選択し、操作を選択
Testタブを開く
Template parametersで、ワイルドカード (*) 名の横にある値を更新
- 例: api/cart/mock と入力
Sendをクリック

テストが成功すると、バックエンドから 200 OK とレスポンスデータが返されます。

Step 4: IP制限の設定（多層防御）

バックエンドサービスを保護するため、APIM側とApp Service側の2つのレイヤーでIP制限を実装します。

Step 4-1: APIM側のIP制限ポリシーの設定

特定のクライアントIPからのみアクセスを許可するポリシーを設定します。

作成したAPIのDesignタブを開く
InboundセクションのCode editor (</>) をクリック
以下のポリシーを追加

<inbound>
    <base />
    <!-- 特定のIPアドレスからのアクセスのみ許可 -->
    <ip-filter action="allow">
        <address>203.0.113.10</address>
    </ip-filter>
</inbound>

APIポリシー（本記事で使用）: API単位で柔軟にIP制限を設定。異なるAPIに異なるIP制限を適用する場合に最適
APIM ネットワーク設定: APIMインスタンス全体にIP制限を適用。すべてのAPIに同じIP制限を適用する場合に適切

Step 4-2: App Service側のIP制限設定

APIMからのアクセスのみを許可するよう、App Serviceのネットワーク設定を行います。

APIMのIPアドレスを取得
- APIM → 概要 → 仮想 IP (VIP) アドレスを確認

App Serviceのネットワーク設定を開く
- App Service → ネットワーク → 受信トラフィックの構成

公衆ネットワークアクセスを制限
- 「公衆ネットワークアクセス」で「選択した仮想ネットワークと IP アドレスから有効」を選択
APIMのIPアドレスを追加
- 手順1で取得したAPIMのIPアドレスを許可リストに追加

これで、APIMからのアクセスのみがApp Serviceに到達できるようになりました。

まとめ

この記事では、Azure API Managementの応用機能として、開発者ポータル、ポリシー、バックエンド統合のポイントを確認しました。特に、セルフサービスでのAPI利用開始やAPIキー管理、ポリシーによるレート制限・変換・IP制限、さらにApp Serviceとの統合と多層防御の考え方を整理しました。