Upgrade to Pro — share decks privately, control downloads, hide ads and more …

APIセキュリティリスク対策の実践 〜APIライフサイクルを通じた継続的なアプローチ / Im...

Yoichi Kawasaki
April 17, 2025
18

APIセキュリティリスク対策の実践 〜APIライフサイクルを通じた継続的なアプローチ / Implementing API security risk countermeasures

Presentation slides for CyLeague Security Tech Forum - DevSecOps最前線
フロントランナーから学ぶ最新トレンドと成功事例

Session title: APIセキュリティリスク対策の実践 〜APIライフサイクルを通じた継続的なアプローチ
Date: 2025/04/17
Session Description:
API活用がビジネスの基盤として浸透する中、Web APIにおけるセキュリティリスクへの対策が急務となっています。APIの安全性を確保するためには、設計段階から運用に至るまで継続的なセキュリティテストとリスク管理が求められます。
本セッションでは、組織が直面するAPIセキュリティリスクの調査結果をもとに、Postmanを活用してAPIライフサイクル全体を通じてどのようにセキュリティを確保し、持続的にリスクを管理していくのか、その実践手法を共有します。

Yoichi Kawasaki

April 17, 2025
Tweet

More Decks by Yoichi Kawasaki

Transcript

  1. • リリース直前にしかセキュリティチェックを行われない • 脆弱性管理やセキュリティ要件の定期的な見直しが行われない • 一部の専門家だけの責任になっている(セキュリティは別チームの仕事) • 仕様や設計にセキュリティ視点が含まれていない • テスト範囲が偏っている(機能面は厚いがセキュリティ面のテストが弱い)

    @postman_japan セキュリティ対応における典型的な失敗パターン 担い手・チェックポイントの集中 ❌ セキュリティを1カ所(あるいは後工程)に集めると、抜け漏れ・遅れ・属人化が 発生しやすくなり、システム全体のリスクが増大する
  2. 認証・認可設定 認証とは、ユーザーが「誰であるか」を確認するプロセスであり、 認可はユーザーが「何を許可されているか」 を 決定するプロセス。APIテストではこの両観点で適切に実装されているかを確認する 認証の確認ポイント(誰であるか?) • 認証なしのアクセス試行 : 認証が必要なエンドポイントに対して、トークンなしのリ

    クエストが拒否されるか • トークンの有効期限の確認: トークンが適切に期限切れとなり、期限切れ後のア クセスが拒否されるか 認可の確認ポイント(何を許可されているか?) • オブジェクトレベルの認可: 他のユーザーが所有するリソースにはアクセスできな い(403 Forbiddenエラーが返る、など)ようになっているか • 機能レベルの認可: ユーザーの役割(例: 管理者、一般ユーザー)に応じて、アク セス可能なエンドポイントや許可されている操作(例: 他人のデータの削除)が制 限されているか
  3. 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/
  4. 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/
  5. 特に認可制御は攻撃リスクが高い @postman_japan オブジェクトレベルの認可の不備 BOLAのイメージ 機能レベルの認可の不備 BFLAのイメージ • 認可制御はアプリロジックに依存する部分が大きく、適切な設計・実装をしないと、権限管理の不備が発 生しやすい ◦

    認可バイパスや権限昇格のリスク(管理者しか見れないものが見れてしまう) ◦ 認可ロジックがアプリケーションコード内に分散しやすく、一貫性がなくなる恐れあり • APIテストでは認可制御のチェックは慎重に ◦ 認可が適切に機能するかどうかは、テストが欠かせない
  6. 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/
  7. 󰢏 セキュリティを点ではなく線で考える • セキュリティをDevOpsプロセスの点ではなく線として設計・実装・運用の中に分散 配置させる(分散: セキュリティの担い手、チェックポイント) • 継続的にまわすことを考える @postman_japan フェーズ

    主要なセキュリティ対策(目的) 設計 脅威モデリング、仕様の明文化(そもそも脆弱な仕様を作らない) 開発 セキュアコーディング、 SAST(開発段階で問題を埋め込まない) テスト セキュリティ面のテスト、コントラクトテスト (仕様違反、脆弱な実装、不具合を早期に発見) 本番運用 WAF/監視/トラフィック制御(攻撃や不正操作をブロック&検知) 保守 SBOM / 脆弱性管理、定期的セキュリティ要件の見直し
  8. 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
  9. 柔軟なテストのしくみ テストスクリプト • 各APIリクエストにスクリプト( JavaScript)の記述ができる • リクエスト送信前 (pre-request) とレスポンス受信後(post-response)のフェーズで実行可能 •

    各リクエストには複数のテストを登録でき、それぞれに「合格」「失敗」の結果が出る • Mochaベースのテストフレームワークで、 AssertionライブラリとしてChai.js利用可能 • ローコード支援機能としてコードスニペットや AIアシスタント Postbot)の利用が可能 @postman_japan スクリプト 実行フェーズ テスト結果
  10. 柔軟なテストのしくみ テストスクリプト @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); });
  11. 柔軟なテストのしくみ テストスクリプト 複数のリクエストを組み合わせてシナリオテスト、 E2Eテストも作れる コレクション APIリクエスト① テスト サンプル APIリクエスト② テスト

    サンプル APIリクエスト③ テスト サンプル 複数リクエストで構成されたシナリオテストが可能 Request ① POST /regist Request ② GET /get Request ③ POST /unregist スクリプト @postman_japan
  12. 柔軟なテストのしくみ コレクションランナー 複数のAPIリクエストをまとめて実行可能なコンポーネント @postman_japan 実行 実行結果詳細表示 サマリー結果表示 順番入れ替え可能 実行方法選択 手動

    / スケジュール実行 イテレーション数 遅延秒数 データファイル 指定可能 選択 コレクションメニュー コレクションランナー実行方法設定
  13. 継続的に 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テストの実行イメージ
  14. 機密情報を安全に扱う機能 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
  15. 一貫性のあるルールを適用 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/
  16. まとめ • Web APIのセキュリティテストにおける課題 ◦ そもそも、セキュリティテストが十分に行われていない ◦ 特に認可のミスは重大な攻撃リスクに直結 ◦ 設計と実装のズレ(APIドリフト)も大きな懸念

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