APIゲートウェイポリシーとは何か？
Yuan Bao
December 15, 2022
クラウドネイティブとマイクロサービスアーキテクチャの発展に伴い、APIゲートウェイのトラフィックポータルとしての役割はますます重要になっています。APIゲートウェイは主に、リクエストされたトラフィックを受信し、適切なアップストリームサービスに転送する役割を担っています。APIゲートウェイのポリシーは、トラフィックを管理するためのロジックとルールを決定し、ビジネストラフィックの動作を直接決定します。
APIゲートウェイポリシーとは
APIゲートウェイは通常、すべてのアップストリームサービスの前に配置されます。ユーザーがサービスにリクエストを送信すると、リクエストはまずAPIゲートウェイに到達し、APIゲートウェイは通常、以下のいくつかのことをチェックします：
- リクエストが合法かどうかを確認します。アクセスが禁止されているユーザーリストからのリクエストではありませんか？
- リクエストが認証されているか、アクセスされたコンテンツが許可されているかを確認します。
- リクエストが特定の制限ルール（レート制限など）をトリガーしていないかを確認します。
- どのアップストリームサービスに転送するかを確認します。
この一連のステップを経て、リクエストは拒否されるか、指定されたアップストリームサービスに正しく到達します。この処理ルールをAPIゲートウェイのポリシーと呼びます。これらのルールは、ゲートウェイが稼働中にゲートウェイ管理者によってゲートウェイに継続的に追加されます。ゲートウェイはこれらのルールを受け入れ、対応するトラフィック処理動作を行います。
APIゲートウェイApache APISIXを例にとると、APISIXの設定情報には2種類あります：ゲートウェイ起動時の設定ファイル（config.yamlなど）で、このファイルはゲートウェイが正常に起動するために必要な設定を決定します。さらに、管理者は実行時にAdmin APIを通じて動的にさまざまなルールや設定を作成できます。例えば、Route、Consumer、Pluginなどです。APIゲートウェイのポリシーは、管理者がAdmin APIを通じて動的に作成するさまざまなルールや設定です。
この記事では、4つのAPIゲートウェイのシナリオ、認証と認可、セキュリティ、トラフィック処理、および可観測性について詳しく説明し、各シナリオでAPIゲートウェイポリシーがどのように機能するかを説明します。
認証と認可ポリシー
認証はAPI呼び出し元の身元を確認し、認可は呼び出し元が権限内のリソースにのみアクセスすることを制限します。
例えば、乗客が駅に到着すると、駅に入る前に身分証明書を使用して「認証」を行い、身元を確認します。駅に入った後、乗客はチケットをスタッフに提示して確認し、特定の列車に「認可」されます。認証と認可ポリシーの主な目的は、アップストリームサービスに転送されるすべてのリクエストが合法であり、リクエストが権限の範囲内のリソースにのみアクセスすることを保証することです。いくつかの標準的なポリシーは以下の通りです：
Basic Auth
Basic Access Authenticationポリシーは最もシンプルなアクセス制御技術です。通常、ユーザーのHTTPプロキシはリクエストを送信する際に認証用のリクエストヘッダーを携帯します。これは通常、Authorization: Basic <credentials>で、credentialsにはユーザー認証に必要なユーザーIDとパスワードが含まれ、:で区切られています。この方法は、ログインページやクッキーなどの複雑な設定を必要としません。リクエストヘッダー内のシンプルな認証情報（通常はユーザー名とパスワード）に基づいて認証されるため、設定と使用が簡単です。
以下は、usernameとpasswordを使用した基本認証付きのcURLリクエストの例です：
curl -i -u 'username:password' http://127.0.0.1:8080/hello
ただし、credentials内の情報は送信中に暗号化されず、base64エンコードされるだけです。そのため、通常はHTTPSと併用してパスワードの安全性を確保する必要があります。
このポリシーがゲートウェイに実装されると、認証情報のないリクエストは転送されません。リクエストに正しい認証情報が含まれている場合にのみ転送されます。このポリシーは、最小限のコストでAPIアクセス検証を実装します。
Key Auth
Key Authポリシーは、APIにキーを追加し、キーを使用してリソースへのアクセスを制御することでAPI呼び出しを制限します。正しいキーを持つリクエストのみがリソースにアクセスできます。このキーは通常、リクエストヘッダーまたはクエリに含まれます。このキーは、異なるAPI呼び出し元を区別するためにも使用できます。これにより、異なる呼び出し元に対して異なるポリシーやリソース制御を実装できます。Basic Authと同様に、キーは暗号化されません。リクエストがHTTPSを使用していることを確認して安全性を確保してください。
APISIXのkey-authプラグインを例にとると、このプラグインはAdmin APIを通じて一意のキー値を持つConsumerを作成する必要があります：
curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
"username": "jack",
"plugins": {
"key-auth": {
"key": "jack-key"
}
}
}'
このリクエストは、キー値jack-keyを持つjackという名前のConsumerを作成します。
ルートでプラグインを有効にする際、リクエスト内のキーの位置とフィールド名を設定する必要があります。デフォルトの設定はheaderで、フィールド名はapikeyです。そのため、このルートにリクエストする正しいコードは以下の通りです：
curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'
APISIXがこのリクエストを受信すると、APISIXはキーを解析し、設定されたすべてのキーからConsumer jackをマッチングします。これにより、ゲートウェイはリクエストがjackによって送信されたことを認識します。マッチングするキーが見つからない場合、リクエストは不正と判断されます。
JSON Web Token
JSON Web Token（JWT）は、jsonオブジェクトの形式で情報を安全に伝達する方法を定義するオープンな標準です。JWTポリシーは認証と認可を組み合わせることができます。ユーザーが認可されると、JWTトークンがユーザーに送信され、呼び出し元はその後のすべてのリクエストでこのトークンを携帯して、リクエストが認可されていることを保証します。
APIゲートウェイでは、JWT認証をJWTポリシーを通じてゲートウェイに追加できます。これにより、認証ロジックをビジネスコードから分離し、開発者はビジネスロジックの実装に集中できます。APISIXのjwt-authプラグインを例にとると、このプラグインはConsumerで有効化され、一意のキー、暗号化用の公開鍵と秘密鍵、暗号化アルゴリズム、トークンの有効期限などを設定する必要があります。同時に、ルートでこのプラグインを有効化し、ゲートウェイがトークンを読み取る位置とフィールド（header、query、cookieなど）を設定する必要があります。このプラグインは、APIゲートウェイにトークンを発行するAPIを追加します。リクエストを送信する前に、トークンを発行するAPIにリクエストする必要があります。リクエストを送信する際、設定情報に従って指定された位置にトークンを携帯する必要があります。リクエストがゲートウェイに到達すると、ゲートウェイは設定情報に従ってリクエストの指定された位置からトークンを読み取り、トークンの有効性を検証します。検証が成功すると、リクエストはアップストリームサービスに転送されます。
前の2つのポリシーと比較して、JWTポリシーには有効期限のオプションが含まれています。発行されたトークンは時間の経過とともに期限切れになりますが、Basic AuthとKey Authの有効期限は永続的です（サーバーがパスワードやキーを変更しない限り）。さらに、JWTポリシーは複数のサービス間で共有できるため、シングルサインオン（SSO）シナリオに適しています。
OpenID Connect
OpenID ConnectはOAuth2.0プロトコルに基づく認証と認可の方法で、比較的完全なアプリケーションソリューションを提供します。APIゲートウェイのOpenID Connectポリシーは、アップストリームサービスがIDプロバイダー（IdP）からユーザー情報を取得できるようにし、APIセキュリティを保護します。一般的なIdPにはKeycloak、Ory Hydra、Okta、Auth0などがあります。Apache APISIXを例にとると、ゲートウェイ内のOpenID Connectポリシーのワークフローは以下の通りです：
- クライアントがゲートウェイにリクエストを送信
- ゲートウェイがリクエストを受信後、IdPに認証リクエストを送信
- ユーザーはIdPが提供するページにリダイレクトされ、ログイン認証を完了
- IdPが認証コードとともにゲートウェイにリダイレクト
- ゲートウェイがコードを使用してIdPにAccess Tokenをリクエストし、ユーザー情報を取得
- ゲートウェイはアップストリームにリクエストを転送する際にユーザー情報を携帯
このプロセスにより、認証と認可がビジネスから分離され、アーキテクチャがより細分化されます。
APISIXのその他の認証と認可方法については、API Gateway Authenticationを参照してください。
セキュリティポリシー
APIゲートウェイのセキュリティポリシーは、門番のような役割を果たし、安全なAPIアクセスを確保します。合法的なリクエストをゲートウェイが転送し、不正なリクエストをゲートウェイでブロックします。OWASP API Security Projectによると、API呼び出し元に対する多くの脅威や攻撃が存在します。APIゲートウェイのセキュリティポリシーを使用することで、すべてのAPIリクエストに対してセキュリティ検証を行い、これらのセキュリティ脅威からAPIを保護する上で重要な役割を果たします。
以下は、いくつかの重要なAPIゲートウェイセキュリティポリシーです：
IPアクセス制限
IP制限ポリシーは、特定のクライアントがAPIにアクセスすることを制限します。許可リストまたは拒否リストに特定のIPまたはCIDRを設定することで、悪意のあるアクセスを防止します。このポリシーを適切に設定することで、APIのセキュリティが大幅に向上し、より高いAPIセキュリティガバナンスが可能になります。
URIブロッカー
URIブロッキングポリシーは、一部のURIルールを設定することで、潜在的に危険なAPIリクエストを遮断します。例えば、一部のセキュリティ攻撃はURIパスをスニッフィングして潜在的な脆弱性を検出し、攻撃を行います。Apache APISIXはuri-blockerプラグインを提供し、危険なAPIリクエストをブロックします。uri-blockerプラグインを通じて正規表現を設定することもできます。リクエストがルールに一致する場合、APIゲートウェイはリクエストをブロックします。例えば、root.exe、adminを設定すると、このプラグインは*/root.exeおよび*/adminリクエストをブロックし、APIセキュリティをさらに保護します。
CORS
CORS（Cross-origin resource sharing）は、ブラウザのクロスドメインリクエストに対するセキュリティポリシーです。通常、ブラウザでxhrリクエストを送信する前に、ブラウザはリクエストアドレスと現在のアドレスが同じオリジンにあるかどうかを検証します。同じオリジン内のリクエストは直接送信されます。それ以外の場合、ブラウザはまずOPTIONタイプのクロスドメインプリフライトリクエストを送信します。レスポンスヘッダーにはCORS関連の設定が含まれます。例えば、クロスドメインリクエストで許可されるメソッドやクレデンシャルなどです。ブラウザはこの情報に基づいて正式なリクエストを送信するかどうかを決定します。詳細については、CORSを参照してください。
通常、CORS設定を含むレスポンスはバックエンドサービスによって設定されますが、多くのサービスがある場合、ゲートウェイレベルで一括処理する方が安全で便利です。CORSポリシーは、異なるAPIに対して異なるクロスオリジン解決ポリシーを設定でき、アップストリームサービスはこれらのロジックを処理する必要がなくなります。
CSRF
CSRFは、クロスサイトリクエストフォージェリ攻撃で、認証済みのエンドユーザーに意図しない操作を実行させます。この攻撃は通常、ソーシャルエンジニアリング（メールで悪意のあるリンクを送信）を伴います。ユーザーがリンクをクリックすると、攻撃者はユーザーの認証済みIDを使用してウェブサイトに対して攻撃操作を実行します。ウェブサイトの観点からは、すべての動作は期待通りです。なぜなら、ユーザーはすでにログインしているからです。
通常、ウェブサイトのバックエンドサービスは、このロジックを処理するために追加のミドルウェアを追加する必要があります。また、防止方法にも特定の標準があります。CSRFポリシーを使用することで、この攻撃を防止し、ゲートウェイ層でCSRFセキュリティ処理を行うことで、アップストリームサービスのロジックの複雑さを軽減できます。
トラフィック処理ポリシー
トラフィック処理ポリシーは、主にAPIゲートウェイがトラフィック転送を行う際のアップストリームの負荷が健全な範囲内であることを保証します。同時に、リクエストが転送される前または呼び出し元に返される前に、必要に応じてリクエストを書き換えます。このタイプのポリシーは、主にレート制限、サーキットブレーカー、キャッシング、リライトなどの機能に関連します。
レート制限
リソースが限られている場合、APIが提供できるサービス能力には限界があります。呼び出しがこの限界を超えると、アップストリームサービスがクラッシュし、いくつかの連鎖反応を引き起こす可能性があります。レート制限は、このようなケースを回避し、APIがDDOS（Denial-of-service attack）攻撃を受けるのを効果的に防ぐことができます。
レート制限ポリシーでは、時間ウィンドウと最大許容リクエスト数を設定できます。APIゲートウェイは、最大許容数を超えるリクエストを拒否し、レート制限エラーメッセージを返します。リクエスト数が制限を下回るか、次の時間ウィンドウが開くまで、リクエストは許可されません。
リクエストカウントの変数は、リクエスト内または特定のリクエストヘッダーとして設定できます。例えば、異なるIPに応じて対応する速度制限ポリシーを設定することで、より柔軟性を高めることができます。
サーキットブレーカー
APIサーキットブレーカーポリシーは、アップストリームサービスに対してサーキットブレーカー機能を提供します。このポリシーを使用する場合、ゲートウェイがアップストリームサービスの状態を判断するために、健全な状態と不健全な状態のステータスコードを設定する必要があります。さらに、ブレークまたは健全性を回復するためのリクエストの閾値を設定する必要もあります。アップストリームサービスがゲートウェイに不健全なステータスコードを連続して返すと、ゲートウェイは一定期間アップストリームサービスをブレークします。この期間中、ゲートウェイはアップストリームにリクエストを転送せず、直接エラーを返します。これにより、エラーが発生してもリクエストを受け続けることでアップストリームサービスが「雪崩」状態になるのを防ぎ、ビジネスサービスを保護します。この期間が過ぎると、ゲートウェイは再度アップストリームにリクエストを転送しようとします。それでも不健全なステータスコードが返される場合、ゲートウェイはさらに長い時間（倍増）ブレークを続けます。アップストリームが一定数の健全なステータスコードを返すまで、ゲートウェイはアップストリームサービスが健全に戻ったと判断し、トラフィックをアップストリームノードに転送し続けます。
このポリシーでは、不健全な場合に返す必要があるステータスコードと情報も設定する必要があります。アップストリームサービスが不健全な場合、リクエストはゲートウェイレベルで直接返され、ビジネスサービスの安定性を保護します。
トラフィックスプリッティング
トラフィックスプリッティングポリシーは、トラフィックを異なるアップストリームサービスに比例的に転送することを動的に制御できます。カナリアリリースやブルーグリーンデプロイメントで特に有効です。
カナリアリリースでは、一部のリクエストのみが新しいサービスを使用し、他の部分は古いサービスのままです。新しいサービスが安定している場合、比率を増やし、徐々にすべてのリクエストを新しいサービスに移行してアップグレードを完了します。
ブルーグリーンリリースは、ピーク時にサービスを中断せずに新しいバージョンをリリースする別のリリースモードです。古いバージョンと新しいバージョンのサービスが共存します。通常、本番環境（ブルー）は同一の別のコンテナ（グリーン）にコピーされます。新しい更新をグリーン環境にリリースし、その後グリーンとブルーの両方を本番環境にリリースします。ユーザーがブルーシステムにアクセスしている間に、グリーン環境をテストおよび修復できます。その後、いくつかのロードバランシングポリシーを使用してリクエストをグリーン環境にリダイレクトできます。ブルー環境は、次の更新のためのディザスタリカバリオプションとして待機状態に保つことができます。
APISIXはtraffic-splitプラグインを通じて両方のリリースをサポートし、ビジネスデプロイメントをより便利で信頼性の高いものにします。
レスポンスリライト
現代のマイクロサービスアーキテクチャでは、サービス間で多くの異なるプロトコルが使用され、統一されたレスポンスデータ形式がありません。このトランスコードロジックをそれぞれのサービスで個別に実装すると、冗長なロジックコードが発生し、管理が難しくなります。一部のレスポンスリライトポリシーは、プロトコル変換、リクエストボディのリライト、その他のロジックを処理できます。
APISIXはResponse Rewriteプラグインを提供し、アップストリームサービスから返されるBodyやHeader情報を変更し、レスポンスヘッダーの追加や削除、レスポンスボディを変更するルールの設定などをサポートします。クロスオリジンリクエストのCORSレスポンスヘッダーを設定したり、リダイレクトのためのlocationを設定したりするシナリオで役立ちます。
一方、APISIXはリクエストリライト用にproxy-rewriteを提供します。このプラグインは、アップストリームサービスにプロキシされるリクエストの内容も処理できます。リクエストされたURI、メソッド、リクエストヘッダーなどをリライトでき、多くのシナリオでビジネス処理の利便性を提供します。
フォールトインジェクション
フォールトインジェクションは、意図的にエラーを導入することでシステムの正しい動作を確認するソフトウェアテスト方法です。通常、デプロイ前にテストを行い、本番環境で潜在的な障害がないことを確認します。一部のカオステストシナリオでは、サービスの信頼性を検証するために、サービスにいくつかのエラーを注入する必要があります。
ソフトウェアフォールトインジェクションは、コンパイル時インジェクションと実行時インジェクションに分類されます。コンパイル時インジェクションは、ソフトウェアのコードやロジックを変更することを指します。実行時インジェクションは、実行中のソフトウェア環境にエラーを設定してソフトウェアの動作をテストします。フォールトインジェクションポリシーは、実行時インジェクションを通じてアプリケーションネットワークリクエストにフォールトをシミュレートできます。ポリシーで比率を選択すると、この比率内のリクエストがフォールトロジックを実行します。例えば、遅延時間を返したり、設定されたエラーコードとエラーメッセージを直接呼び出し元に返したりします。これにより、ソフトウェアの適応性が向上し、開発者はリリース前にいくつかの可能なエラー状況を事前に確認し、問題に対して適応的な修正を行うことができます。
プロトコル変換
プロトコル変換クラスのポリシーは、一般的なHTTPリクエストとgRPCなどの標準プロトコル間で変換できます。Apache APISIXはgrpc-transcodeプラグインを提供し、HTTPリクエストをgRPCタイプのサービスにトランスコードして転送できます。レスポンスはHTTP形式でクライアントに返されます。これにより、クライアントはHTTPにのみ集中し、アップストリームのgRPCタイプに注意を払う必要がなくなります。
可観測性ポリシー
可観測性とは、システムの出力データを通じてシステムの動作状態を測定する能力を指します。一部の単純なシステムでは、システムコンポーネントの数が比較的少ないため、エラーが発生したときに各コンポーネントの状態を分析することでバグを見つけることができます。しかし、大規模な分散システムでは、さまざまなマイクロサービスコンポーネントの数が非常に多く、コンポーネントを一つずつチェックするのは現実的ではありません。この場合、システムは可観測性を持つ必要があります。可観測性は、大規模なシステムの可視性を提供し、問題が発生したときにエンジニアが問題を特定するために必要な制御を提供します。
データ収集はアプリケーションコンポーネント内で実装できます。APIゲートウェイはすべてのトラフィックの入口であるため、APIゲートウェイにシステムの可観測性機能を実装することで、システムAPIの使用状況を反映できます。APIゲートウェイの可観測性ポリシーは、すべてのチームに役立ちます：
- エンジニアチームはAPIの問題を監視および解決できます。
- プロダクトチームはAPIの使用状況を理解し、その背後にあるビジネス価値を発見できます。
- セールスおよび成長チームはAPIの使用状況を監視し、ビジネスチャンスを探し、APIが正しいデータを提供していることを確認できます。
可観測性ポリシーは、出力データのタイプに応じて、一般的にTracing、Metrics、Loggingの3つのカテゴリに分類されます。
Tracing
大規模な分散システムでは、サービス間の関係が複雑です。Tracing（リンクトラッキング）は、完全な呼び出しリンク、アプリケーション間の依存関係分析、分散アプリケーション内のリクエスト統計を追跡できます。システムに問題が発生した場合、エンジニアが調査範囲と場所を特定するのに役立ちます。
Tracingポリシーは、APIゲートウェイに他の分散呼び出しリンクトラッキングシステムを統合して、データを収集および記録できます。例えば、ZipkinやSkyWalkingなどのサービスをAPIゲートウェイに統合して、データとサービス間通信を収集します。これにより、エンジニアは特定のセッションや関連するAPI呼び出しに対してどのログを確認すべきかを知ることができ、トラブルシューティングの範囲を検証できます。
Metrics
Metricsとは、サービスの動作中に収集されるソフトウェアの観測データを指します。これらのデータはデフォルトで構造化されており、クエリと視覚化が容易です。これらのデータを分析することで、システムの動作状態を把握できます。
Metricsポリシーは、PrometheusやDatadogなどのサービスをAPIゲートウェイに統合し、システムの監視とアラーム機能を提供できます。このポリシーは、ゲートウェイの動作中にさまざまなAPIゲートウェイインターフェースを通じてデータを収集し、PrometheusやDatadogにデータを報告します。これらのデータを視覚化することで、開発者はゲートウェイの動作状態、APIリクエストの統計情報、その他の統計グラフを確認できます。
Logging
ログは、特定の時間に発生したシステムイベントのテキスト記録です。システムに問題が発生した場合、ログは最初に確認する場所です。エンジニアはログの内容に依存して、システムに何が起こったかとそれに対応する解決策を見つけます。ログの内容は、一般的にAPIリクエストログとゲートウェイの動作ログに分けられます。APIリクエストログは、APIゲートウェイの動作中にすべてのAPIリクエスト記録を記録します。エンジニアはこれらの記録を通じてAPIアクセス情報を把握し、異常なリクエストをタイムリーに発見およびトラブルシューティングできます。ゲートウェイの動作ログには、ゲートウェイの動作中に発生したすべてのイベントの記録が含まれます。APIゲートウェイが異常な場合、トラブルシューティングの重要な根拠として使用できます。
Loggingポリシーは、APIゲートウェイのログをサーバーディスクに保存したり、HTTPログサーバー、TCPログサーバー、UDPログサーバーなどの他のログサーバーにプッシュしたり、Kafka、RocketMQ、Clickhouseなどの他のログシステムにプッシュしたりできます。
まとめ
この記事では、APIゲートウェイで一般的に使用される4つのポリシー、認証と認可、セキュリティ、トラフィック処理、可観測性について紹介しました。APIゲートウェイは、すべてのアップストリームサービスの前にリクエストされたトラフィックを受信し、リクエストがどこにどのように転送されるかを制御し、安全でないリクエストや認可されていないリクエストを直接拒否または制限します。APIゲートウェイポリシーは、これらの動作をすべて設定できます。