All rights reserved by Postman Inc AWSではじめる Web APIテスト実践ガイド 品質とセキュリティを支えるためのポイント Presentation slides: JAWS DAYS 2025 川崎庸市 Postman 株式会社

テクノロジーエバンジェリスト Postman株式会社 川崎 庸市 / Yoichi Kawasaki @yokawasa @postman_japan

はじめに @postman_japan

API Application Programming Interface APIはインターフェース Web APIはソフトウェアのWebインターフェース @postman_japan

本トークの前提APIスタイル: REST 86%のAPIがWeb APIアーキテクチャスタイルにRESTを採用 @postman_japan REST Webhook GraphQL SOAP Websockets gPRC MQTT AMQP SSE EDI EDA 2023年 API アーキテクチャスタイルの利用率 Source: Postman State of API Report 2023 https://www.postman.com/state-of-api/2023/api-technologies/

本セッションでお話すること ● Web APIの品質・セキュリティを担保するためのチェック項目 ● AWS環境におけるAPIの信頼性向上のためのポイント ● おまけ：Postmanの活用イメージ AWS環境のWeb API セッション概要 https://jawsdays2025.jaws-ug.jp/sessions/A6

Software Design 2025年1月号 第2特集「Web APIテスト 実践ガイド」第 2章「Web APIテスト時のチェック項目」 https://gihyo.jp/magazine/SD/archive/2025/202501

Web APIテストのチェック項目 @postman_japan Web APIの品質、信頼性、セキュリティを担保するためのチェック項目

Web APIテストの目的 APIテストは、インターフェースの品質、信頼性、セキュリティを確保するために行います 機能要件 ● APIコントラクトテスト: APIがコントラクト通りの仕様 で実装されているか ● 機能テスト: APIが期待通りの振る舞いであるかどう か 非機能要件 ● セキュリティテスト: APIを通じたやりとりがセキュア か ● パフォーマンステスト: APIのパフォーマンスに問題 がないか @postman_japan

Web APIテスト実施の現状 ● 回答者のうち6割以上が機能テストと統合テストを実施、45%がパフォーマンステスト を実施 ● セキュリティテストは37%で、APIのセキュリティ脅威が増加する中、この数値は衝撃的に低い 2024 Postman state of API report - Most common API testing practices https://www.postman.com/state-of-api/2024/api-production/

機能面のチェック項目 ● コントラクト ● CRUD操作の一貫性・冪等性 ● APIバージョンの独立性・互換性 ● エラーハンドリング

コントラクトテストとは？ ● コントラクト = API提供者・利用者間で合意した契約 OpenAPI、GraphQL schema、protobuf ) ● コントラクトテストは、 APIがコントラクト通りに振る舞うことを確認するテスト ● API提供者はコード変更のたびにリグレッションテストとして、 API利用者にとっては利用している APIに変 更がないかなど定期的に検証していくのがよいとされている コントラクトテストでのチェック箇所例 ● リクエスト・レスポンスのスキーマ整合性 ● 型と値 ● 必須パラメータ、フィールド ● エンドポイントとHTTPメソッドの動作 ● HTTPステータスコード API利用者・提供者によるコントラクトの利用イメージ

APIドリフト問題 ● APIの記述と運用中のAPIの間に不一致で生じる問題 ● API仕様の更新不足、コミュニケーション不足、 APIの設計・開発・運用プロセスにおけるガバナンス不足 などが主な原因 In our analysis of hundreds of leading APis from some of the largest providers in the field, we discovered that almost 30% of published APIs did not match the APIs in operational use. 公開されているAPIの約30%が、公開されているAPI記述と一致しない 動作をしている The challenges of API Drift - most production APIs don't match their specs APIContext社) https://apicontext.com/resources/api-drift-white-paper/

APIの冪等性 Idempotency) ● 複数回リクエストを送信しても、結果が変わらないことの確認 ● 冪等性が担保されることで、リトライ / 再送処理があったとしてもデータの不整合が防げる ● 冪等性のあるメソッド： GET, PUT, DELETE, HEAD, OPTIONS ○ POSTは冪等性キーIdenpotency-key)の活用することで冪等性をもたせることが可能 同一PUTリクエスト送信で冪等性のチェック 冪等性キーを活用して POSTリクエストの冪等性をチェック 参考: Build Resilient Systems with Idempotent APIs https://dev.to/karishmashukla/building-resilient-systems-with-idempotent-apis-5e5p

APIバージョンごとの独立性・互換性 複数のAPIバージョンがある場合、各バージョンが互いに影響を及ぼさず、バージョンごとに期待通りの動作で あることを確認 確認ポイント ● 独立性: バージョンごとのエンドポイントが併存し て正しく動作するか ● 後方互換性: 変更内容が後方互換性を保ち既 存クライアントに影響を与えないか（メジャー バージョンアップではない後方互換性が期待さ れている場合） APIバージョン管理パターン ● URI ○ /api/v1/user や /api/v2/user ● クエリパラメータ ○ /api/user?v=1 や /api/user?v=2 ● HTTPヘッダ ○ Accept: application/vnd.example.v1+json ● ドメイン/サブドメイン ○ v1.example.com や v2.example.com

エラーハンドリング ● 不正リクエストや異常な入力、例外や障害シナリオに対して コントラクト通りのエラーレスポンスが返却され るか確認（コントラクトテスト） ● タイムアウトやリトライ処理のような回復性機能 もユニット、インテグレーションテストで確認する Shopify API response status and error codes https://shopify.dev/docs/api/usage/response-codes

ネガティブテストもしっかりやる ポジティブテスト（正常系のテスト）は特に言わなくても多くの方が実施するが、 ネガティブテスト（異常系やエッジ ケースのテスト）は見落とされがち ネガティブテストの例 タイプ チェック項目 入力バリデーション（リクエスト本文、ヘッ ダー、パラメータ） ● 不正なデータ型や形式 ● 必須パラメータ不足 ● 重複データ ● 大量、極端に大きい文字列やファイルサイズ 認証・認可 ● 無効なトークン ● 不適切なリソースや権限でのアクセス データの漏洩 / 過剰なデータ露出 / セ キュリティヘッダ ● SQLインジェクション、XSS ● 不正なCORSリクエスト システムリソース制限 ● 異常なリソース消費を生ずるリクエスト（ タイムアウト設定、一度に返却可能なレ コード数の確認など） ● 高頻度なリクエスト（レートリミットの確認）

セキュリティ面のチェック項目 ● 認証・認可設定 ● 無制限のリソース消費 ● データの漏洩 / 過剰なデータ露出防止 ● 入力データのバリデーション（インジェクション / XSS防止） ● HTTPヘッダーのセキュリティ設定

OWASP API Security Top 10 2023 APIに特化した主要なセキュリティリスクのランキングとその対策（ 2023年度版） ● API12023 オブジェクトレベルの認可の不備 BOLA ● API22023 認証の不備 ● API32023 オブジェクトプロパティレベルの認可の不備 ● API42023 無制限のリソース消費 ● API52023 機能レベルの認可の不備 ● API62023 機密性の高いビジネスフローへの無制限なアクセス ● API72023 サーバーサイドリクエストフォージェリ SSRF ● API82023 セキュリティ設定ミス ● API92023 不適切なインベントリ管理 ● API102023 安全でないAPIの利用 OWASP API Security Top 10 2023 https://owasp.org/www-project-api-security/

認証・認可設定 認証とは、ユーザーが「誰であるか」を確認するプロセスであり、 認可はユーザーが「何を許可されているか」 を 決定するプロセス。APIテストではこの両観点で適切に実装されているかを確認する 認証（誰であるか？）の確認ポイント ● 認証なしのアクセス試行 : 認証が必要なエンドポイントに対して、トークンなしのリ クエストが拒否されるか ● トークンの有効期限の確認: トークンが適切に期限切れとなり、期限切れ後のア クセスが拒否されるか 認可（何を許可されているか？） の確認ポイント ● オブジェクトレベルの認可: 他のユーザーが所有するリソースにはアクセスできな い（403 Forbiddenエラーが返る、など）ようになっているか ● 機能レベルの認可: ユーザーの役割（例: 管理者、一般ユーザー）に応じて、アク セス可能なエンドポイントや許可されている操作（例: 他人のデータの削除）が制 限されているか

特に認可制御は攻撃リスクが高い @postman_japan オブジェクトレベルの認可の不備 BOLAのイメージ 機能レベルの認可の不備 BFLAのイメージ OWASP API Security Top 10 2023中の認可の不備 ● API12023 オブジェクトレベルの認可の不備 BOLA ● API32023 オブジェクトプロパティレベルの認可の不備 ● API52023 機能レベルの認可の不備

無制限のリソース消費 APIリクエストに伴うリソース消費が制限されていない場合、攻撃者によるリソースの過剰消費でサービス妨害 やコスト増加を引き起こす可能性がある（「 API42023  Unrestricted Resource Consumption （無制限のリ ソース消費）」）。この問題を防ぐために、 APIリクエストごとの消費リソース とAPIリクエストのレート制限 の2つの 観点で対策されているか確認するようにしましょう 消費リソースの制限 APIリクエストごと) ● 各APIリクエストごとの過剰なリソース消費を抑えるための設定がされているか ● タイムアウト設定、ペイロードサイズ、アップロードファイルサイズ、一回のAPIリクエストで実行可能な命令の数、返却 可能なレコード数、など レート制限 ● 各エンドポイントに適切なリクエスト数の制限（例: 10リクエスト/秒）が設定されている ● 制限を超えたらリクエストが適切に拒否される（HTTP 429 "Too Many Requests"など） レート制限にはAPI全体で固定時間枠ごとの全体リクエスト数を制限する方式、クライアントの IPアドレスやユーザー IDごとにリクエスト数を制限する方式 など様々な方式がある。 API Gatewayのようなレイヤーで一元的に制御するのが一般的

データの漏洩 / 過剰なデータ露出防止 APIを通じたデータの漏洩や過剰なデータ露出がないか必ず確認するようにしましょう ● クエリ文字列 / URLパス: 機密情報（例: セッションID、APIキー） ● APIレスポンス: 必要以上の情報（例 : 内部ID、システムメタデータなど） ● エラーメッセージ: スタックトレースなど内部の手がかりとなる情報 検証方法: 大きく次の２種類のアプローチがあり、それぞれメリット、デメリッ トを持っているが、両方を実施するのが最も効果的 ● 直接リクエスト/レスポンスを検証 ● ログを検証 { "error": "Database connection failed", "details": "Unable to connect to MySQL server at db.internal.example.com:3306. Access denied for user 'api_user'." } 内部の手がかりとなる情報が含まれたエラーメッセージ

HTTPヘッダーのセキュリティ設定 業界で確立された推奨セキュリティヘッダーを設定し、テストでこれらが正しく機能しているかを確認 参考: OWASP REST API Security CheatSheet https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html#security-headers ヘッダー推奨設定 説明 CORS関連ヘッダ Access-Control-Allow-＊) CORSはブラウザが異なるオリジンからのリクエストを制御するための仕組み。許可するオリ ジンやメソッドを最小限に制限し、不要なアクセスを防ぐ Cache-Control: no-store ブラウザーによるキャッシュを指示するために使用されるヘッダー。レスポンスのキャッシュを 禁止し、機密情報の保存を防ぐ Content-Type コンテンツのMIMEタイプを指定。未指定だとブラウザが推測し、スニッフィング攻撃のリスク がある Strict-Transport-Security HSTS HTTPSのみの通信を強制し、盗聴・改ざん・誤った HTTPアクセスを防ぐ。 XContent-Type-Options: nosniff ファイルの内容に基づいた MIMEタイプの推測ではなく Content-Typeで宣言されている MIME タイプの使用をブラウザに指示するヘッダー。不正な実行を防ぐ XFrame-Options: DENY レスポンスを他のサイトにフレーム化できるかどうかを指定するヘッダー。他サイトへの埋め込 みを禁止し、クリックジャッキングを防ぐ。

パフォーマンスのチェック項目 ● 高負荷時の性能 ● 想定される高負荷のパターンにおいて、レイテンシーやエラーレートが許容範囲内か ● 長期安定性 ● 長期間の運用で異常なリソース消費（メモリリークやCPU使用率の異常値）がないか ● スケーラビリティ ● サーバーの数などAPIのリソース増減に応じてパフォーマンスが期待通りに変動（水平スケールなど）するか ● リソース効率 ● CPU、メモリ、ディスクI/O、ネットワーク帯域などAPIサーバのリソースに過剰、無駄な消費がないか ● APIの限界値 ● APIが限界値（最大同時接続数、など）と限界値を超えたときの挙動について確認がとれているか

パフォーマンスはユーザー体験である ソフトウェアやウェブアプリケーションのパフォーマンスはユーザーエクスペリエンスに直結してい るとても重要な要素 Web performance is user experience. As you design and develop a new site, youʼll consider many components of its user experience: layout, hierarchy, intuitiveness, ease of use, and more. Your siteʼs experience determines how much your audience trusts your brand, returns to your site, and shares it with others. Designing for performance, by Lara Callender Hogan, Dec 2014 https://www.oreilly.com/library/view/designing-for-performance/9781491903704/ https://designingforperformance.com/index.html

パフォーマンス計測のための 主要メトリクスと計測内容の例 メトリクス 計測内容 観点 レイテンシ 各APIの平均応答時間、95パーセンタイル （P95）、99パーセンタイル（P99）のレイテンシ が許容範囲内か ユーザー体験に直接影響を与える指標。平均レイテンシだけでな く、P95やP99といった負荷状況での性能を把握してボトルネック 解消のための指針として利用 スループット APIが1秒間に処理可能なリクエスト数（ RPS Requests Per Second） APIのスケーラビリティを測る指標。必要な RPSが達成できない場 合、インフラ拡張やコード最適化などの対策を検討 エラーレート 5xx系、4xx系のエラーレスポンス率 システムの不安定さを示す指標で、 5xxエラーはサーバーサイド の問題を示す。高負荷下でエラーレート（特に 5xx系）が急増して いないか確認 システムリソース 使用状況 APIサーバーのCPU使用率、メモリ消費量、ネッ トワーク帯域の使用状況 API処理の効率性や、ボトルネック特定のために利用

シナリオに応じた負荷増減をシミュレーションする シナリオに応じた負荷の増減をシュミレーションして、安定的に動作するかを確認する。単調な負荷では見えな い問題の発見ができる。ウォームアップの必要性、スケール速度など ランプアップ型 ピーク型 スパイク型 Postmanパフォーマンステスト機能で利用可能な負荷プロファイルの種類（固定以外）

Web APIテスト共通で心がけたいこと ● シフトレフトを心がける（早い時期からテスト実施） ● APIドキュメントを整備する ● APIライフサイクルにわたりテストを実施する（開発時だけではない） ● 優先順位をつけてテストを自動化する ● テストケースを継続的にアップデートする おまけ

Reliable Web API on AWS @postman_japan AWS環境におけるWeb APIの信頼性向上のためのポイント

さまざまなWeb API アーキテクチャの決定要因 REST API WebSockets API RPC API GraphQL API Asynchronous API Transaction Event Driven Batch 公開API 内部API パートナーAPI 物理サーバー デバイス VM コンテナ / K8S Serverless 公開タイプ APIアーキテクチャスタイル ワークロード ホスティングオプション PaaS

AWSでのAPIスタイル/プロトコルのサポート状況 AWSにおいてインターフェースとして活用できるサービスの APIスタイル/ プロトコルサポート状況 AWSサービス API スタイル / プロトコル Amazon API Gateway REST, WebSockets AWS AppSync GraphQL AWS IoT Core MQTT, WebSockets, HTTPS ELB ALB/NLB HTTP/HTTPS, TCP, gRPC AWS Lambda Function URLs) HTTP/HTTPS API GatewayはREST APIとHTTP APIの2種 類あり、どちらも HTTPを基本としている 以降のページで下記サービスを短縮表記とします ● Amazon API Gateway ⇒ API Gateway ● AWS Lambda ⇒ Lambda

インターネットを流れる主要HTTPバージョン ● HTTP/1.1 ○ 1997年に初版、2014年に改訂版発行された標準化されたプロ トコル。ほとんどのHTTPライブラリが1.1をサポート ○ テキスト形式 ● HTTP/2 ○ バイナリ形式（メッセージをフレーム分割） ○ ヘッダー圧縮、同一接続で並行リクエスト（接続多重化）などに より、1.1と比べ効率的な送信を実現 ● HTTP/3 ○ HTTP/2 同様にバイナリ形式 ○ トランスポートにTCPではなくUDPベースのQUICプロトコルを採 用。高速かつセキュアに転送を実現 ○ 主要ブラウザはHTTP/3をサポート。ブラウザ・CDN間での利用 をはじめ全ウェブでの利用シェア拡大中 @postman_japan 全ウェブサイトにおける HTTPバージョン 利用率 2025/02時点) ● HTTP/2 34.6% ● HTTP/3 34.2% 参考情報 https://w3techs.com/technologies/details/ce-http2 https://w3techs.com/technologies/details/ce-http3 HTTP/3 利用率 https://w3techs.com/technologies/details/ce-http3

AWS基盤上でのHTTP/2, HTTP/3サポート現状 2025年2月のサポート状況 ● CloudFront ● API Gateway REST & HTTP APIs) ＊ ● ELB  NLB / ALB ) HTTP/2サポート HTTP/3サポート ● CloudFront（デフォルト無効） ＊ API GatewayはE2EでのHTTP/2は未サポート HTTP/2 HTTP/1.1 client BE バックへの通信は1.1を使用

REST APIサービス構成、代表的なパターン ● API Gateway + Lambda ○ マネージドAPI管理 + サーバーレス構成、小～中規模 ○ リクエストベースの従量課金でコスト最適化 ○ 高トラフィック時のコスト増 ● API Gateway + ECS (on Fargate) ○ マネージドAPI管理 + コンテナ構成、中～大規模 ○ Lambda の制約回避（長時間実行/ファイル処理など）＝ 柔軟なAPI構成可能 ○ Fargate のコスト（稼働時間に応じた料金発生）、コンテナ管理が必要 ● ALB  ECS (on Fargate) / EKS ○ API管理無し or 独自＋コンテナ構成、中～大規模 ○ gRPC / HTTP2シナリオ、高トラフィック時にコスト削減、柔軟なAPI構成可能 ○ API独自管理 ＋ コンテナ管理が必要。EKSの場合は特に柔軟性は高いものの学習コ ストも高い ● Lambda Function URLs ○ 最もシンプルな構成（Lambda 単体で API 提供可能）、小規模・内部用 ○ 低コストでサーバレスのメリットを活かせる。認証機能が弱い（IAM のみ） Amazon API Gateway （マネージド API管理サービス） Lambda Function URLs （シンプルHTTPエンドポイント） ALB （高機能なL7バランサー）

REST APIの基本構成 API Gateway経由でのLambda実行をインターフェースの基本構成として話をすすめます Authentication Cognito) Distribution CloudFront) Firewall AWS WAF NoSQL DynamoDB RDBMS Aurora Cache ElastiCache) Amazon API Gateway AWS Lambda Interface Frontend Backend ・・・ ・・・

API GatewayのAPI信頼性を高めるための機能 ● リクエストバリデーション ● OpenAPIインポート・エクスポート ● レート制限とスロットリング ● 認証・認可機能 ● WAFとの統合 ● ステージング環境の管理 ● データ保護（TLS / HTTPS） ● APIモニタリング・ロギング ● Route53との連携によるフェイルオーバー(複数リージョン対応） ● キャッシュ機能

API Gatewayのリクエストバリデーション ● クエリパラメータ、パスパラメータ、ヘッダー、ボディ に対し てバリデーション機能を提供 ○ ボディのスキーマはOpenAPI または JSON Schemaで定義 可能 ● 不正なリクエストを API Gateway でブロックし、Lambda やバックエンドの負荷を削減できる ● API の仕様を強制 できるため、クライアント側の実装ミスを 減らせる ● OpenAPIを活用することでスキーマバリデーションを一括 で管理しやすくなる ボディのバリデーション用モデル例 JSON Schema)

OpenAPI  REST APIの標準仕様形式 OpenAPI（最新は2024年10月発表の3.1.0）は、RESTful APIのためのAPI記述形式で、HTTP API機能を人間 とコンピュータが理解できるようにするためのプログラム言語に依存しない仕様形式 記述形式：JSON、YAML

OpenAPIでAPIスキーマを一元管理したい OpenAPIでAPIスキーマを一元管理したい理由 ● APIドリフトの防止 ○ API仕様と実際のAPI Gateway側乖離防止 ● OpenAPI/Swaggerエコシステム ○ OpenAPIでAPIスキーマを定義している人が多い ○ ドキュメントやモック自動生成などOpenAPIエコシステム活用が可能 ● バリデーション用スキーマとして活用 ○ OpenAPIでAPI Gatewayのバリデーションスキーマも一括で管理できる 関連付け APIエンドポイント 関連例ソース

OpenAPIでAPIスキーマ管理 - 標準OpenAPIをインポート ● API GatewayはOpenAPI仕様のインポート・エクスポート機能をサポート ● この標準インポート機能で OpenAPIをAPI Gatewayに取り込みAPIスキーマを作成する インポート しかし、標準のOpenAPIをそのままインポートする方式では、 API GatewayのAPIエン ドポイントとAWSリソース(lambdaなど)との関連付けがされない 関連付けされない

OpenAPIでAPIスキーマ管理 - 現実的な方法 現実的なOpenAPIでのAPIスキーマとAWSのAPI関連リソースの管理手法として次の選択肢がある 選択肢 判定 説明 OpenAPIにAPI Gateway拡張 設定を追加して管理 △ OpenAPI にAPI Gateway用拡張のx-amazon-apigateway-*を定義 する（OpenAPIに拡張定義が含まれてしまう） OpenAPIとCloudFormationで 管理 △ OpenAPI の中で API Gateway用拡張の x-amazon-apigateway-integration を定義する必要がある OpenAPIとAWS CDKで管理 ◯ スキーマ用のOpenAPIをピュアに保ちつつAWSリソース定義・構築用の CDKで完全に分離した管理が可能 AWS CDK APIスキーマ生成 参照 関連付け

AsyncAPI - 非同期型APIのための標準仕様形式 AsyncAPI initiative Linux Foundation参加)が推進するイベント駆動型アーキテクチャ、非同期型 APIのため の仕様（最新は2023年12月発表の3.0.0）。OpenAPIの非同期版として標準化を目指す 参考情報 記述形式：JSON、YAML https://www.asyncapi.com

AsyncAPI  SQSやSNSプロトコルもサポート AsyncAPI のBinding（拡張機能）により、特定のプロトコル（例 : MQTT, Kafka, WebSockets, AMQP など）に 依存する設定やオプションを記述が可能 参考情報 ● AMQP ● AMQP 1.0 ● Google Cloud Pub/Sub ● HTTP ● IBM MQ ● JMS ● Kafka ● MQTT ● NATS ● Pulsar ● Redis ● Amazon SNS ● Solace ● Amazon SQS ● STOMP ● WebSockets Binding一覧 https://github.com/asyncapi/bindings/tree/master Amazon SQS BindingでのConsumer記述例

API セキュリティ強化に関するAWSガイドライン API Gatewayセキュリティ対策の多層的アプローチ API セキュリティの優先順位付け https://docs.aws.amazon.com/ja_jp/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/prioritize-api-security.html ● 転送中のデータのセキュリティ ○ 通信は暗号化。SSL/TLS、相互 TLS (mTLS)など ● API認証・認可 ○ ユースケースに応じた適切な認証・認可設定をして攻撃者の不正アクセスを防止 ● アクセス制御 ○ 過剰なリソース消費の制御。スロットリング、レート制限、バーストレート制限 ● プライベートAPI ○ Privateネットワークで安全な接続の実現。AWS PrivateLink、Direct Connectなど ● AWS WAFを使用したファイアーウォール保護 ○ WAFを設置して、SQLインジェクションやXSSなどからAPIを保護

API Gatewayでの認証・認可設定 ● AWS API Gateway では主に IAM、Cognito、Lambda オーソライザー という選択肢がある ● 適切な方式を選択し、それに応じたテストを実施することが重要 方法 対象 特徴 ユースケース IAM ロールとポリ シー AWS サービス、社内 ユーザー ● AWSのネイティブな権限管理 IAM でアクセス制御 ● AWS 内部システムからのアクセス 制御、API 間通信 Amazon Cognito ユーザープール エンドユーザー向け ● Cognitoユーザープールを使用し てOAuth 2.0、OIDC、JWTを活用 した認証認可 ● ソーシャルログイン対応 ● 一般ユーザー向けの認証管理 ● モバイルアプリやWebアプリと連携 するAPI Lambdaオーソライ ザー 外部IDプロバイダーの 利用やカスタム認証が 必要な場合 ● Lambdaで柔軟なカスタム認証ロ ジックを実装可能 ● 外部IDプロバイダーと統合可能 ● Cognito 以外の認証基盤を使用し たい場合（Auth0、Okta、社内の認 証基盤など） ● 独自認証、複雑なアクセス制御 3つの認証・認可方式の概要とユースケース

特に認可制御は攻撃リスクが高い @postman_japan オブジェクトレベルの認可の不備 BOLAのイメージ 機能レベルの認可の不備 BFLAのイメージ OWASP API Security Top 10 2023中の認可の不備 ● API12023 オブジェクトレベルの認可の不備 BOLA ● API32023 オブジェクトプロパティレベルの認可の不備 ● API52023 機能レベルの認可の不備 再掲

認可制御の注意点 認可制御はアプリロジックに大きく依存し、不備が発生しやすい処理であるためテストは慎重に！ ● AWSの機能だけで完結せず、 アプリロジックに依存する部分が大きい ○ ロールベース RBAC、属性ベース ABAC、カスタムルールなどアプリごとに認可方式に違いがある ■ 管理者かどうか（ロール）、開発チーム所属かどうか（属性）、特定ユーザーかどうか（カスタム） ○ IAM、Congito、Lambdaオーソライザー、いづれも細かい制御要件には対応しきれない ● 適切な設計・実装をしないと、 権限管理の不備が発生しやすい ○ 認可バイパスや権限昇格のリスク（管理者しか見れないものが見れてしまう） ○ 認可ロジックがアプリコード内に分散しやすく、一貫性がなくなる恐れあり 認可制御のテスト項目例： ● 正常系: 権限を持つユーザーが適切にリソースへアクセスできるか ● 異常系: 権限を持たないユーザーが不正アクセスできないか ● 境界: 権限変更直後のアクセスが正しく反映されるか

Amazon Verified Permission AVP - 認可サービス きめ細やかな認可（何ができるかを確認）を提供するサービス ● ロールRBAC や属性ABACベースなどのきめ細 やかなアクセス制御を定義できる ○ ポリシーをCedar言語で記述 ● Cognito、IAMロールと組み合わせて高度な認可設 定が可能 ● すべての認可決定を記録し 監査ログとして保存 permit( principal == resource.owner or principal.role == "admin", action in Action::"read", Action::"write"], resource is Account ); ポリシー設定例（本人と管理者がアクセス可能） Amazon API Gateway Lambda Authorizer AVP Policy Store このアクションを許可し てもいい？ ALLOW or DENY GET accounts/A10 アカウントID A10 リソース所有者

スロットリングで過剰アクセスを保護 ● API Gatewayはリクエストに対して 2種類のスロットリングを設定できる ○ レート制限: 1秒あたりの最大リクエスト数 ○ バースト制限: 最大バケットサイズ（同時リクエスト数） ● API Gatewayは3つのレイヤーでスロットリングを適用可能 ○ アカウントレベル: AWSアカウント内（リージョンごと）の全API ○ ステージレベル：ステージレベル（APIごと）ごと ○ APIキーレベル：特定の APIキーを持つクライアントごと ● AWS WAFと組み合わせることで、より高度な DDoS防御も可能 制限を超えたときのステータスコード

AWS WAFでデータ漏洩 / 過剰露出を防止 ● Webアプリをさまざまな攻撃から保護する L7マネージドファイアーウォール ● API Gateway Regional) / ALB / CloudFront などと統合可能 Amazon API Gateway ALB AWS WAF 機能 説明 レートリミット IPベース) DDoS攻撃やブルートフォース攻撃からの防御 IPアドレスフィルタリング 特定のIPアドレスを許可 / 拒否 SQLインジェクション対策 悪意のあるSQLクエリをブロック XSS対策 悪意のあるスクリプトを含むリクエストをブロック ボット対策 自動化されたボットのアクセスを検出・ブロック カスタムルール適用 カスタムルールを設定し、 API GatewayやALBと連携 GeoIPフィルタリング 国・地域ごとのアクセス制限 AWS Managed Rules AWSが管理・提供するルールセットでセキュリティ強化 ● WAFは誤検知する可能性があるので定期的に検知状況を確認すること ● WAFはあくまで第一防衛戦。検査できないリクエストはアプリ側の制御でカバー

AWSでの負荷テスト - ガイダンス・お作法 https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/load-testing/welcome.html ● 負荷テストの基本計画 ○ 何をどう評価する？テスト実行時の注意点・影響 ● 負荷テストで考慮する要素 ○ 機能性、負荷サイズ、特定負荷、オートスケーリング、継続的負荷 ● 考慮点・注意点 ○ コスト、テストデータ、制限（クォータ、帯域）、シナリオ ● ツール選定 ○ k6, vegeta, hey/ab, JMeter, AWS Distributed Load Testing, Artillery ペネトレーションテスト : 許可された AWS サービスでのみ実行可能 https://aws.amazon.com/security/penetration-testing/ DDoSシュミレーションテスト : 事前承認が必要 https://aws.amazon.com/security/ddos-simulation-testing/ こちらもお忘れなく！ AWS 規範ガイダンス「アプリケーションの負荷テスト」

AWS環境特有の特性・制約 アプリの性能？環境の影響？ - AWS環境の特性・制約を知り適切な事前対策を！ ● オートスケーリング ○ スケールイン・アウト、起動遅延、事前スケールアップ、スポットインスタンスの影響 ● Lambdaやサーバーレス環境の特性 ○ コールドスタート、同時実行制限 ● API Gateway / ALB ○ レートリミット/ バーストリミット、同時接続数、HTTP Keep-Aliveの影響 ● ネットワーク・VPC関連 ○ VPCエンドポイントの帯域制限、NAT Gateway / Transit Gatewayの帯域、Egressの通信量とコスト ● データストア ○ RDS/Aurora バーストクレジット枯渇、DynamoDB(ondemand/provisioned)の性能とスロットリング ● CloudFront / CDN ○ キャッシュヒット率、地理的分散・ユーザーとの距離

計測せよ 適切なメトリクスを監視し、API のパフォーマンスやボトルネックを特定しよう ● Cloud Watchでメトリクス監視 ○ API Gateway: 4XX, 5XX, レイテンシ、スロットリング、エラー ○ ALB リクエスト数、ターゲットの応答時間、接続エラー ○ Lambda: 実行時間、スロットリング、エラー ○ DynamoDB / RDS スループット、スロットリング ○ S3 / CloudFront: キャッシュヒット率、リクエスト数 ● XRayでレイテンシ分析 ● API Gateway, Lambda, RDS, S3など呼び出しのレイテンシ可視化 ● 高レイテンシの原因を特定。コールドスタート、 DBクエリ遅延など

Postmanの活用イメージ （AWS環境のWeb API） @postman_japan

All rights reserved by Postman Inc Postman とは？ 全世界3,500 万人以上のユーザーに使われている APIを構 築して利用するための API プラットフォームです。 APIのライフサイクル全般にわたり効率的なコラボレーション を通じて信頼性の高いAPIを実現します。

Postman API Platform Landscape @postman_japan

AWS CDK 監視・アラート （モニター） API設計 APIテスト API ドキュメント APIモック （モックサーバー） セキュリティ ガバナンス APIカタログ APIネットワーク) 共同開発・テスト (コラボレーション) ● コントラクトテスト ● 機能テスト ● パフォーマンステスト ● セキュリティテスト ● シナリオテスト ● リグレッションテスト 手動 or 自動 (継続) 実行 OpenAPI AWS Postman 監視 / モニタリング テスト Postmanコレクションを OpenAPIとして エクスポート 参照 APIスキーマ生成 Postman ＆ API on AWS 連携イメージ [補足] API Gatewayは OpenAPIを直接インポートでき る。CDKを使用することでAPI スキーマ生成とAWSリソース Lambdaなど) の関連付けを 同時に実現できる ● PostmanでWeb APIの信頼性を向上 ● AWSでAPIシステムを安定的かつスケーラブルに運用 APIシステム

Postmanイベント Postman API Night(勉強会)＆ワークショップ https://postman.connpass.com/ Please Follow us - Postman イベント情報 Postman Japan X https://twitter.com/postman_japan @postman_japan

Postman Japan コミュニティ Discord Discord サーバーを開設しました！ Postman のプロダクトアップデートやイベント情報 の配信や、皆さんとの交流の場として活用していき たいと思います。 https://discord.gg/G4SQWDDqVa @postman_japan

まとめ

Web API on AWS 信頼性向上のためのポイントを解説しました ● 一般的なWeb APIの品質・セキュリティを担保するためのチェック項目 ○ 機能 / コントラクト観点 ○ セキュリティ観点 ○ パフォーマンス観点 ● AWS環境におけるAPIの信頼性向上のためのポイント ○ API GatewayのAPI信頼性を高めるための機能 ○ セキュリティ対策の多層的アプローチ ○ パフォーマンス計測のための Tips ● Postman ＆ AWS環境のAPIの連携

ありがとうございました @postman_japan