MuleSoft 入門(8)ポリシーと SLA

December 19, 2019 Minoru Nakanishi

こんにちは、アピリオ中西です。MuleSoft の紹介記事の第8回目となります。

これまで API の実装開発とテストの手法に関して紹介してきましたが、 API は実装したらすぐに運用開始できるというものではありません。API を作成して公開する場合は、「セキュリティ」と「パフォーマンス」という観点から、 API へのアクセスをどのように制御・管理するかという点を考慮しなければなりません。API への悪意ある攻撃を防止し、想定以上のアクセスを制限するためにも、 API 実装に到達する前段階でアクセスを制御する仕組みが必要です。

本ブログシリーズの第2回目で 、Anypoint Platform の API Manager は API を管理保護するための API Gateway/Proxy の定義する機能であることをご紹介しました。API Manager の機能の中でも SLA (Service Level Access)設定 と ポリシー設定は、 API のアクセス制限の肝となりますので、本記事で詳しくご紹介します。

APIインスタンス

API Manager を使って API を管理するには、特定のAPIのバージョン(APIのバージョンについては「MuleSoft 入門(10)Mule API のバージョン管理」を参照してください)に対して API インスタンスを作成する必要があります。下記は API インスタンス の設定画面であり、Exchange に公開された APIアセット と バージョンを選択して作成します。API インスタンスにはユニークな API ID が採番され、この API ID と APIの実装である Mule アプリケーションを紐付けるのが autoDiscovery と呼ばれる仕組みであり、Mule アプリケーション上のグローバル定義に API ID を設定します。

[API インスタンスの定義画面]

API インスタンスに紐付いたアプリケーションが Mule ランタイム上にデプロイされ実行中になると、API Status(画面の左上)が Active になります。

API Gateway とは

API Gateway は、Mule Runtime に含まれる API を管理保護するための機能です。API Manager で 管理する API 定義のインスタンスと API の実装を紐付け、API へのリクエストを検証するレイヤーが API Gateway です。APIの実装面と分離されているので、実装に影響を与えることなく API 制御の設定(API ポリシー)を適用できます。

[API Gateway の概要図]

API Gateway には、API 実装と同じRuntimeで動作する embedded な形式 とAPI 実装とは別にデプロイする API proxy の2種類があります。

[API インスタンスのとうProxy Endpoint の設定例]

API Manager で API インスタンスを設定する際の画面で、 [Managing Type] を [Basic Endpoint] に設定することで embedded  形式を利用できます。後者の [Endpoint with proxy] を選択した場合は、API 実装とは別に proxy を Mule アプリケーションとして準備する必要があります。また、その proxy のデプロイ先と URL も同画面から設定します。embedded proxy は多少のオーバーヘッドが生じる場合がありますが、特別な理由がない場合は embedded 形式 を利用した方が管理/運用の面でもわかりやすくなると思います。

API ポリシー による制御設定

API Gateway において、API にセキュリティやトラフィック制御に関する機能を適用する設定が API ポリシーです。

MuleSoft 社が標準で提供する API ポリシーである「提供ポリシー」と、既存の機能の拡張または新機能を定義するためにユーザ自身が開発してAPIに適用できる「カスタムポリシー」の2種類が存在し、いずれも API Manager から各 API インスタンスに対して適用することができます。

提供ポリシーには一般的な API 管理に必要とされる制御機能がある程度網羅されており、複雑な実装なしに IP 制限やレート制限、クライアント認証、OAuth トークン適用などの機能を API に付与することができます。

何点か、提供ポリシーの例を以下に示します。

カテゴリ
ポリシー
説明
セキュリティ IP ホワイトリスト IP アドレスのリストまたは範囲からのリクエストのみを許可する
セキュリティ JSON 脅威保護 API リクエスト内の悪意ある JSON から保護する
セキュリティ 基本認証: シンプル 1 つのユーザ ID とパスワードを使用して基本認証メカニズムに基づいてアクセスを許可する
セキュリティ Mule OAuth 2.0 アクセストークン適用 有効な OAuth トークンへの API へのアクセスを許可する
サービス品質 レート制限 一定時間内に API が受け入れるリクエスト数を制限する
サービス品質

レート制限 SLA ベース

SLA 層の設定に基づいて、アプリケーションによる API へのリクエスト数を制限する
サービス品質 スパイク制御 一定期間内に処理される要求が設定された最大数を越えないように、API トラフィックを平滑化する
コンプライアンス クライアント ID 適用 承認されたクライアントアプリケーションからのアクセスのみを許可する
変換 ヘッダーの挿入 リクエスト / レスポンスに対して、ヘッダーを追加する

2019年12月時点では、Mule 4 においては合計18種類もの提供ポリシーが標準で用意されています。

詳しくは MuleSoft の公式ドキュメントをご参照ください(リンク:提供ポリシー)。

MuleSoft における API は、3つのレイヤーに分けて API によるアプリケーション・ネットワークを構築することで、柔軟性と再利用性を最大限高めるのがベストプラクティスとされています。そのため、API ポリシーも各レイヤーの API に対して必要なものを取捨選択する必要があります。

もちろんAPIの要件や公開範囲・用途などに応じて必要なポリシーや設定は変わってきますが、「JSON/XML 脅威保護」は外部公開する Experience API レイヤーに適用、「クライアント ID 適用」「IP ホワイトリスト」は不正アクセスを防ぐために全レイヤーに適用といったようにある程度の推奨設定は定義することができます。

SLA 層によるクライアントのアクセス管理

SLA (Service Level Access) は API で定義するユーザアクセスをカテゴリ化するものであり、API Manager で定義します。SLA 層の定義と、SLA ベースのポリシーを組み合わせる事で、API に対して実行できるリクエスト数を制限したり、特定のレベルの API アクセスで承認が必要かどうかを決定したりすることができます。

先述の提供ポリシーの表に記載した「レート制限 SLA ベース」ポリシーは、クライアント ID 認証を利用して各アプリケーションが期間内に実行できるリクエスト数に制限を課すポリシーです。

例えば、以下の表のように、クライアントアプリケーションはどの SLA 層の API アクセスを利用するかによって制限内容が変わります。誰でも利用できる SLA 層はリクエスト制限が厳しく、それ以上の SLA 層の場合は承認プロセスが必要といったような定義が可能です。SLA 層を1つでも定義した場合は、アクセスリクエストの際に SLA を選択する必要があります。

SLA 層
承認方法
制限
Gold 手動承認 1,000 request / 60s
Silver 手動承認 500 request / 60s 
Bronz 自動承認 100 request / 60s および 1,000 request / 1day

この手法により、API を利用しているアプリケーションを SLA 層ごとに管理できるとともに、一日あたりの想定最大リクエスト数などをコントロールすることができます。

クライアント ID 認証を利用する場合は、client_id / client_secret というパラメータの有無で API へのアクセスを制限します。API を利用したいクライアントアプリケーションがアクセスリクエストを行い、承認されると client_id / client_secret パラメータが発行され、API を利用できるようになるという仕組みです。

[SLA の申請/承認管理の例]

なお、SLA の承認状況や API を利用しているクライアントアプリケーションも、API Manager にて一覧管理することができます。

このように、MuleSoft の標準の設定を組み合わせるだけでも幅広い API 管理要件に適応することができます。しかし、各社固有の複雑な要件を満たすことができないような場合は、ユーザ自身が開発する「カスタムポリシー」を利用することができます。次回は、このカスタムポリシーの開発について紹介しようと思います。

 

[MuleSoft入門シリーズ]

MuleSoft入門(1)MuleSoft による API-led なアプリケーションネットワーク

MuleSoft入門(2)ようこそ Anypoint Platform へ

MuleSoft入門(3)Anypoint Studio による API の実装

MuleSoft入門(4)DataWeave によるデータ変換

MuleSoft入門(5)Flow Designer で Mule アプリケーションを開発

MuleSoft入門(6)MUnit による単体テスト

MuleSoft入門(7)API 開発におけるテストの考え方

MuleSoft入門(8)ポリシーと SLA

MuleSoft入門(9)カスタムポリシーの開発

MuleSoft入門(10)Mule API のバージョン管理

MuleSoft入門(11)ランタイムログの自動アーカイブ

著者について

2018年にアピリオに入社し、Salesforce を中心としたクラウドの世界に足を踏み入れました。2019年には MuleSoft のプロジェクトに携わり、API 主導の開発に強い興味と関心を持っています。IT 技術の変遷が激しい今だからこそ、勉強に励んで自分の価値を高めようと絶賛奮闘中です。

Minoru Nakanishi のコンテンツをもっと見る
戻る
MuleSoft 入門(9)カスタムポリシーの開発
MuleSoft 入門(9)カスタムポリシーの開発

MuleSoft のAPI管理は標準のポリシーの組み合わせで幅広い要件をカバーできますが、場合によっては既存機能の拡張や新機能の定義が必要になります。今回は、「カスタムポリシー」の開発手順についてご紹介します。

次へ
MuleSoft入門(7)API開発におけるテストの考え方
MuleSoft入門(7)API開発におけるテストの考え方

今回は API 開発におけるテストについて考えていきます。単に動くだけのサンプルアプリを作るだけであれば、簡易的な検証で十分でしょうが、本番運用に耐えうる堅牢な API を開発するためには、一般的なシステム開発と同...

アピリオまでお気軽にお問合せください

ご質問はこちら