Slide 1

Slide 1 text

All rights reserved by Postman Inc APIセキュリティリスク対策の実践 〜APIライフサイクルを通じた継続的なアプローチ CyLeague Security Tech Forum 2025/04/17 川崎庸市 Postman 株式会社

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

アジェンダ ● Web APIのセキュリティ面の問題 ● Postmanを活用したセキュリティリスク対策 @postman_japan

Slide 4

Slide 4 text

Web API セキュリティ面の問題 @postman_japan

Slide 5

Slide 5 text

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/ 2024年 Postman State of API report

Slide 6

Slide 6 text

● リリース直前にしかセキュリティチェックを行われない ● 脆弱性管理やセキュリティ要件の定期的な見直しが行われない ● 一部の専門家だけの責任になっている(セキュリティは別チームの仕事) ● 仕様や設計にセキュリティ視点が含まれていない ● テスト範囲が偏っている(機能面は厚いがセキュリティ面のテストが弱い) @postman_japan セキュリティ対応における典型的な失敗パターン 担い手・チェックポイントの集中 ❌ セキュリティを1カ所(あるいは後工程)に集めると、抜け漏れ・遅れ・属人化が 発生しやすくなり、システム全体のリスクが増大する

Slide 7

Slide 7 text

組織にとって最も懸念されるAPIセキュリティリスク 組織にとって最も懸念される API セキュリティリスクについて、 最も多く挙げられたのは 「不適切な認証・認可、 またはアクセス制御」 で、他のリスクと大きく差をつけている 2023年 Postman State of API report 2023 Postman state of API report - Greatest Security Risks https://voyager.postman.com/pdf/2023-state-of-the-api-report-postman.pdf

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

OWASP API Security Top 10 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/

Slide 10

Slide 10 text

OWASP API Security Top 10 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/

Slide 11

Slide 11 text

特に認可制御は攻撃リスクが高い @postman_japan オブジェクトレベルの認可の不備 BOLAのイメージ 機能レベルの認可の不備 BFLAのイメージ ● 認可制御はアプリロジックに依存する部分が大きく、適切な設計・実装をしないと、権限管理の不備が発 生しやすい ○ 認可バイパスや権限昇格のリスク(管理者しか見れないものが見れてしまう) ○ 認可ロジックがアプリケーションコード内に分散しやすく、一貫性がなくなる恐れあり ● APIテストでは認可制御のチェックは慎重に ○ 認可が適切に機能するかどうかは、テストが欠かせない

Slide 12

Slide 12 text

APIドリフト問題 - ドキュメントと実装のズレ ● 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 Aug 2024, APIContext社) https://apicontext.com/resources/api-drift-white-paper/

Slide 13

Slide 13 text

󰢏 セキュリティを点ではなく線で考える ● セキュリティをDevOpsプロセスの点ではなく線として設計・実装・運用の中に分散 配置させる(分散: セキュリティの担い手、チェックポイント) ● 継続的にまわすことを考える @postman_japan フェーズ 主要なセキュリティ対策(目的) 設計 脅威モデリング、仕様の明文化(そもそも脆弱な仕様を作らない) 開発 セキュアコーディング、 SAST(開発段階で問題を埋め込まない) テスト セキュリティ面のテスト、コントラクトテスト (仕様違反、脆弱な実装、不具合を早期に発見) 本番運用 WAF/監視/トラフィック制御(攻撃や不正操作をブロック&検知) 保守 SBOM / 脆弱性管理、定期的セキュリティ要件の見直し

Slide 14

Slide 14 text

Postmanを活用した APIセキュリティリスク対策 @postman_japan

Slide 15

Slide 15 text

APIプラットフォーム Postmanの API開発ライフサイクルにおける各ステージでの活用例 定義 設計 開発 テスト セキュリティ デプロイ 監視・観測 ビジネス システム Security ・・・ ドキュメント コード管理 システム設定 モック API Contracts (スキーマ) APIサーバー 開発 API Gateway 開発 トラフィック キャプチャ セキュリティ テスト 要件 Postman コレクション generate パフォーマンス テスト Contracts テスト E2E テスト ソースコード 成果物 commit 自動テスト APIサーバー Build/Deploy API Gateway Build/Deploy CI/CD ・・・ 配布 モニター アラート APM レポート APIカタログ API 開発ポータル trigger integration trigger ユーザー フィードバック Feedback loop UIテスト Stub generate @postman_japan

Slide 16

Slide 16 text

柔軟なテストのしくみ テストスクリプト ● 各APIリクエストにスクリプト( JavaScript)の記述ができる ● リクエスト送信前 (pre-request) とレスポンス受信後(post-response)のフェーズで実行可能 ● 各リクエストには複数のテストを登録でき、それぞれに「合格」「失敗」の結果が出る ● Mochaベースのテストフレームワークで、 AssertionライブラリとしてChai.js利用可能 ● ローコード支援機能としてコードスニペットや AIアシスタント Postbot)の利用が可能 @postman_japan スクリプト 実行フェーズ テスト結果

Slide 17

Slide 17 text

柔軟なテストのしくみ テストスクリプト @postman_japan // ステータスコードが 200であることを確認 pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); // レスポンスが JSONであることを確認 pm.test("Response is in JSON format", function () { pm.response.to.be.json; }); // レスポンスのボディが期待通りの構造と値を持っていることを確認 pm.test("Response has expected contract", function () { const jsonData = pm.response.json(); // idフィールドが数値で値が 1であることを確認 pm.expect(jsonData).to.have.property("id", 1); pm.expect(jsonData.id).to.be.a("number"); // nameフィールドが文字列で "Taro"であることを確認 pm.expect(jsonData).to.have.property("name", "Taro"); pm.expect(jsonData.name).to.be.a("string"); // emailフィールドが文字列で "[email protected]"であることを確認 pm.expect(jsonData).to.have.property("email", "[email protected]"); pm.expect(jsonData.email).to.be.a("string"); }); コントラクトテスト 認可テスト(ユーザーの権限確認) // 不正なトークンを設定 // ヘッダー Authorization: 'Bearer invalidToken' pm.test("Forbidden Check: Should return 403", function () {  // 403 Forbidden エラーチェック pm.expect(response.code).to.eql(403); }); 認証テスト(ユーザーの確認) // 認証が必要なエンドポイントに対して認証トークンなしで送信 pm.test("Unauthorized Check: Should return 401", function () { // 401 Unauthorized エラーチェック pm.expect(response.code).to.eql(401); });

Slide 18

Slide 18 text

柔軟なテストのしくみ テストスクリプト 複数のリクエストを組み合わせてシナリオテスト、 E2Eテストも作れる コレクション APIリクエスト① テスト サンプル APIリクエスト② テスト サンプル APIリクエスト③ テスト サンプル 複数リクエストで構成されたシナリオテストが可能 Request ① POST /regist Request ② GET /get Request ③ POST /unregist スクリプト @postman_japan

Slide 19

Slide 19 text

柔軟なテストのしくみ コレクションランナー 複数のAPIリクエストをまとめて実行可能なコンポーネント @postman_japan 実行 実行結果詳細表示 サマリー結果表示 順番入れ替え可能 実行方法選択 手動 / スケジュール実行 イテレーション数 遅延秒数 データファイル 指定可能 選択 コレクションメニュー コレクションランナー実行方法設定

Slide 20

Slide 20 text

柔軟なテストのしくみ コレクションランナー @postman_japan コレクションランナー実行時に外部データファイル( CSVまたはJSON)からPostman変数にデータ注 入が可能。1イテレーションあたりデータセット数分のテストが実行される データファイル(CSV) コレクションランナー実行方法設定 Postman変数設定 @postman_japan 複数データセットによる Fuzzingテ ストも簡単にできる

Slide 21

Slide 21 text

継続的に API を安全に保つ モニター ● 定期的にコレクションに登録されているテストを実行し、その結果を時系列で確認できる ● テスト失敗でアラート通知設定可能(メール通知、Slack、外部APMサービスなど) ● 複数のリージョンからのテスト実行が可能(有償プラン機能) ● リグレッションテスト、ヘルスチェック、外形監視などの用途に活用可能 @postman_japan イベント 送信 PagerDuty Datadog NewRelic Datadog dashboardイメージ Slack Email Microsoft Teams Splunk

Slide 22

Slide 22 text

継続的に API を安全に保つ Postman CLI & CI/CD PostmanはコレクションはPostman CLI (コマンドラインインターフェース )から実行可能。これを CI/CDに組み 込むことで継続的な APIテストの実行が可能となる # Postmanにログイン postman login --with-api-key {{postman-api-key}} # コレクションのテスト実行 postman collection run {{collection-ID}} # API定義に対してセキュリティ・ガバナンスチェック postman api lint {{api-definition-ID}} Postman CLIでのcollection run実行イメージ GitHub ActionsでのPostmanテストの実行イメージ

Slide 23

Slide 23 text

機密情報を安全に扱う機能 Postman Vault ● シークレットトークン、パスワードなど機密データを安全に Postmanのローカルインスタンスに保存して再 利用できる仕組み。データは Postman Vault 内で暗号化され保存される ● Enterpriseプランかつ Advanced Security Administration アドオンを購入することで外部Vaultインテグレーショ ンの活用も可能 @postman_japan 利用可能なドメインを限定できる {{vault:secret-name}} で環境、認 可設定などワークスペース全体で利 用可能 外部キー管理サービスに格納されたシークレット 情報を Postman 変数として認証などに利用可能 1Password AWS Secret Manager Azure Key Vault HashiCorp Vault

Slide 24

Slide 24 text

一貫性のあるルールを適用 API セキュリティ・ガバナンスチェック ● APIクライアントサイドからのアプローチで、代表的な APIセキュリティチェックとAPIにまつわる 設定の一貫性(ガバナンス)のチェックが可能 ● API lintとして手動もしくはCI/CDなどを通じた継続的確認が可能 @postman_japan APIセキュリティ ● セキュリティ衛生状態 ● 認証と認可の脆弱性 ● クォータの実装 ● 適切なセキュリティヘッダー ● カスタムルールの追加 APIガバナンス ● 全体統制の設定 ○ API文書の整備、テスト実施、API設 定、誤ってトークンを公開していない か、など ● カスタムルールの追加 https://www.postman.com/api-platform/api-security/ https://www.postman.com/api-platform/api-governance/

Slide 25

Slide 25 text

一貫性のあるルールを適用 API セキュリティ・ガバナンスチェック 問題検出内容一覧 検出ルール設定

Slide 26

Slide 26 text

まとめ ● Web APIのセキュリティテストにおける課題 ○ そもそも、セキュリティテストが十分に行われていない ○ 特に認可のミスは重大な攻撃リスクに直結 ○ 設計と実装のズレ(APIドリフト)も大きな懸念 ● よくある失敗パターン ○ セキュリティが特定の人・タイミングに集中(属人化・後付け) ● 求められる対策 ○ セキュリティの責任を一点に集めない ○ 設計〜運用までAPIライフサイクル全体にわたって、各フェーズで適切な対策を講じること ● Postmanでできること ○ 柔軟なテストの仕組みによるセキュリティ検証とその自動化 ○ APIの監視・ドリフト検知による継続的な安全確保 ○ 機密情報の安全管理 ○ 一貫したポリシー適用でチームやプロジェクト横断のセキュリティ・ガバナンスの強化 @postman_japan

Slide 27

Slide 27 text

Postman Connpass グループ API Night(勉強会)& ワークショップ https://postman.connpass.com/ Postman イベントにぜひご参加ください Postman Japan X アカウント @postman_japan @postman_japan

Slide 28

Slide 28 text

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