書籍セキュアAPIについて セキュアAPI - Forkwell Library #129 織茂駿斗@riiimparm #Forkwell_Library Copyright © 3-shake, Inc. All Rights Reserved. 1 

whoami 織茂駿斗 (おりも はやと👼) ID: @riiimparm 株式会社スリーシェイク Sreake事業部 セキュリティ周りの業務支援をしてます 最近はSRE業務にも手を出している AWS, Google Cloud, k8s | Python, Go 個人的によく使うAPI: 自分のドメインに立てているエンドポイント 2 

目次 1. 書籍の構成 2. 各章の説明 3. あわせて読みたい記事 3 

Mission / Vision インフラをシンプルにして イノベーションが起こりやすい世界を作る 本来実現したかった『技術が生み出す価値の享受』『イノベーション』、 その前に立ちはだかる『複雑化・巨大化し続ける技術やプロセス』。 スリーシェイクはこれを社会の課題と捉え、私たちの持つ技術力によって 解決できるよう活動しています。 労苦（Toil）を無くすサービスを 適正な価格で提供し続ける 私たちが考える本当に必要なものは『適切なカルチャー』、 『適切なエンジニア供給と育成』、『適切なITソリューション』。 これらを、あらゆるレイヤーで誰もが恩恵を受けられる適正な価格で 提供し続け、私たちが社会の根幹を担っていくことを使命とします。 Copyright © 3-shake, Inc. All Rights Reserved. 4 

Business 日本のSREをリードする あらゆるサービスを 連携するハブになる インフラ・アプリ・データ・セキュリティ・AI 全方位で顧客の内製化を推進する伴走支援 あらゆるSaaSをノーコードで連携する クラウド型ETL/データパイプラインSaaS 事業者が抱える セキュリティリスクをゼロに 「いいエンジニア」を あなたのチームに セキュリティ対策をワンストップで 実現する脆弱性診断SaaS ハイスキル人材の紹介とHR戦略支援の両輪で エンジニア組織の課題に併走 Copyright © 3-shake, Inc. All Rights Reserved. 5 

01 書籍の構成 Copyright © 3-shake, Inc. All Rights Reserved. 6 

本の紹介 - 概要 セキュアAPI 設計・構築・実装を貫く原則 「決して信頼せず、常に検証する。」 AIが書くコードは動く。だが、動くことと安全であることは違う。 著者：José Haro Peralta 訳者：元内 柊也 / 水元 恭平 / 織茂 駿斗 / 小柳 斉 （株式会社スリーシェイク） 出版社：翔泳社 7/15から発売されています 今日はこの書籍の内容から話していきます！ 表紙の人は「イモツキの民族衣装の山岳民」だそうです 7 

本の紹介 - 著者紹介 José Haro Peralta (ホセ ハロ プロータ) セキュリティ専門家 マイクロサービスや API設計、クラウド、インフラ自動化を支援 microapis.io の創設者で、相談業務、トレーニング、ブログ、ツール開発 microapis.ioとは？ マイクロサービス APIの設計・実装・運用を支援するプロジェクト APIのコンサルティングや教育、ワークショップを提供 自動化された APIセキュリティテストツール ”Fencer”開発者 メインフレームワーク : FastAPIやFlask 本書のコード例も Python(FastAPI) 8 

本の紹介 - 著者紹介 José Haro Peraltaさん著の書籍 「いかにしてマイクロサービスを構築し APIによってそれらを統合・推進するのか」 著者：José Haro Peralta 訳者：株式会社クイープ 出版社：翔泳社 マイクロサービスAPIの概要 REST APIの設計と構築 GraphQL APIの設計と構築 マイクロサービスAPIのセキュリティ、テスト、デプロイ 9 

本の紹介 - 章立て 本書の目次 1 APIセキュリティとは 2 組織とAPIセキュリティの整合 3 APIセキュリティの原則 4 主要なAPI認証・認可の脆弱性 5 API設定と管理における主要な脆弱性 6 設計によるAPIセキュリティ 7 APIの認可と認証 8 API認証と認可の実装 9 安全なAPIインフラ 10 金融グレードAPI 11 APIセキュリティのためのオブザーバビリティ 12 APIセキュリティのテスト 本書は4つほどの観点からセキュリティに切り込んでいます 10 

本の紹介 - 章立て APIセキュリティの考え 方 脆弱性・攻撃の解説 認証認可 高度なAPIセキュリティ 04 認証・認可の脆弱性- 07 APIの認可と認証 09 安全なAPIインフラ- 01 APIセキュリティとは- OWASP Top10 (auth系) セキュア・バイ・デザイン 05 設定と管理の脆弱性- 02 組織とセキュリティの整 合- 06 設計によるセキュリティ L3~L6の対策 - OAuth, OIDC OWASP Top10 (設定・管理) 08 認証と認可の実装 - コード例解説 - 設計上の欠陥 10 金融グレードAPI - FAPI 11 オブザーバビリティ- 脅威モデリング OTel計装 03 セキュリティの原則- 12 セキュリティのテスト シフトレフト / ゼロトラスト - 仕様・Unit Secテスト 11 

内容のレベル セキュリティ 入門 初級 中級 上級 入門 初級 中級 上級 API 12 

本書の位置づけ この本は「網羅的な入門書」 - 入門書でありながら、扱う範囲は広い セキュリティ観点がいくつかありそれらを通して基礎知識をつける - OWASPベースの整理 & 脆弱なコードそのものを見れる - 認証認可の規格について学べる - ここで紹介されている技術を通じてより詳細に踏み込ん でいくことができる 13 

本書の独自のポイント - 脅威モデリングの話から始まる - Pythonベースの脆弱なコード解説 - 金融グレードのセキュリティに言及がある - アプリにとどまらない話(インフラ・オブザーバビリティ) 14 

どんな方におすすめできるか 「APIからのデータ侵害っ て具体的になにが起きて いる？」 「OAuth, OIDCの仕組 み、いまいちわかってな いです」 脆弱性と攻撃事例を、コードつき で理解したい方 仕組みと、トークン・クレームの 内容まで理解したい方 開発現場でのAPI管理、セキュリ ティ対策への姿勢・取り組み方を 知りたい方（インフラ観点含む） 対応章：Chapter 4, 5 対応章：Chapter 7, 8 対応章：Ch.1, 2, 3 「開発チームでのセキュ リティは？」 15 

本書でいうAPIは？ Webのクライアント-サーバーモデルのAPIを前提 主にRESTfulのものを扱う gPRCやGraphQLの話はでてこない ただしセキュリティ原則(1,2,3章) や 認証認可(7,8章) はREST に限らずAPIセキュリティ全般に言える 16 

本書で扱わないこと - サプライチェーンセキュリティ対策 - ブラウザ, ローカルアプリのセキュリティ - LLM組み込みのシステムのAPIセキュリティ - 脆弱性管理 - 一般的なサイバーセキュリティ全般 - セキュリティガバナンス 17 

02 各章の説明 Copyright © 3-shake, Inc. All Rights Reserved. 18 

第1章 APIセキュリティとは Q: APIセキュリティは何を考え始めればいいか (What) APIセキュリティの3軸 設計・実装・インフラ この軸をセキュリティ施策の各所で見ていく セキュア・バイ・デザインとは？ 設計からセキュリティの視点をもっていこうという考え方 ! 開発サイクルで形骸化しがちなセキュリティ対応・観点を再度意識 なぜAPIにセキュリティが大事か (Why) 侵害によるビジネスインパクトが大きい その割に連携促進でセキュリティはおざなりになりがち 19 

第1章 APIセキュリティとは セキュリティのライフサイクル 1. 攻撃ベクトルの特定 2. 脅威モデリング 3. API保護 サニタイズ 不正通信ブロック セグメンテーション この章で展開される話の詳細を後の章で深ぼっていくことになる 20 

第1章 APIセキュリティとは APIはより重要になる、なり続ける - 公開数の増加 - AIエージェントで開発が進むようになった - 組織の平均保有API数 何件でしょうか - 複雑化 - 連携が増えている(APIの目的) - デバイスの増加 - IoTが進んできた - 生成AIの普及、その基盤 - AIの普及とともにAPI保護の重要性も上がる 21 

第1章 APIセキュリティとは APIはより重要になる、なり続ける - 公開数の増加 - AIエージェントで開発が進むようになった - 組織の平均保有API数 600ほど (大企業は1万超) - 複雑化 - 連携が増えている(APIの目的) - デバイスの増加 - IoTが進んできた - 生成AIの普及、その基盤 - AIの普及とともにAPI保護の重要性も上がる 22 

第2章 組織とAPIセキュリティの整合 Q: 組織はいかにセキュリティに取り組んでいけばいいか (How) APIセキュリティ評価 成熟度モデル 簡単なマトリクスなので実践へのフレームワークはNISTやCISのものを 脅威モデリング 「脅威モデリングはチームスポーツである」 API開発に携わるあらゆるロールを集めて現状を整理 STRIDEモデルの紹介 まずはコンポーネント整理を目的に簡単に手を付けること ↓ APIセキュリティプログラムを立てる 分析結果を元に だれかが率先してやらなければいけない 23 

第2章 +α 脅威モデリングは手法が様々 脅威モデリングのフレームワーク - - - STRIDE - 最もポピュラー - 6種類の観点 - 抜け漏れを防ぐのにいい - まずやるならここから PASTA - 攻撃者視点のリスク志向モデル - ビジネスインパクトの考慮がある - 経営陣含めたリスク対応に向いている DREAD - 脅威へのスコアリング - この中で一番定量的 - CVSSのスコアリングに近い 24 

第2章 +α 脅威モデリングもサイクルである 脅威モデリングの活動 1. 私たちは何に取り組んでいるのか 2. 何が問題になる可能性があるか 3. 私たちはどうするつもりか 4. 私たちは十分に仕事をしただろうか システムの変更のたびにこれを回していく まずは手を付けることから 25 

第2章 +α STRIDE - STRIDE STRIDEはあくまで観点 DFD図をベースにすることが多い 26 

第2章 +α STRIDE 先の図に対して 6観点×サービスコンポーネント で分析 27 

ところで API以前のセキュリティに比べてなにを考えなければいけなくなったのでしょう？ 28 

ところで API以前のセキュリティに比べてなにを考えなければいけなくなったのでしょう？ - レスポンスに画面がなくなった - データリソースそのものを返すように - セッションIDを使わなくなった - JWTでのステートレス認可 - モノサーバーに閉じなくなった - 複数のサービスが連携して動くように 29 

ところで API以前のセキュリティに比べてなにを考えなければいけなくなったのでしょう？ - レスポンスに画面がなくなった - データリソースそのものを返すように データ制御が脆弱だとクリティカル - セッションIDを使わなくなった - JWTでのステートレス認可 認可状態の分散(クレーム検証, 失効判定)、観点が増えた - モノサーバーに閉じなくなった - 複数のサービスが連携して動くように ここさえ守ればがなくなった、あちこち守る 30 

第3章 APIセキュリティの原則 Q: 開発現場はいかにセキュリティに取り組んでいけばいいか (How) シフトレフト - より上流で検査できないか? - 検査にパスしないと次に進まないルール ゼロトラスト - 原則をAPIにあてはめる - この視点からは内部APIなんてないといえる シャドーAPI - APIディスカバリを取り入れる 「知っていることは怖くない、恐ろしいのは知らないことだ」 31 

第4章 主要なAPI認証・認可の脆弱性 Q: アプリケーションのどこが危ないのか (Where) OWASPベースでAPI脆弱性解説 - OWASP API Security Top 10 (2023) 解説事項 - BOLA (オブジェクト単位) - BOPLA (プロパティ単位) - BFLA (機能単位) - 機密性の高いビジネスフローへの制限のないアクセス 脆弱なコードを動かしながら習得 - FastAPI - 書籍の対策を手元に実装してハードニング - 動作確認のために一部修正 32 

第5章 API設定と管理における主要な脆弱性 Q: アプリケーションのどこが危ないのか (Where) 引き続き OWASP API Security Top10 (2023) から 解説事項 - 無制限のリソース消費 - DoW - SSRF - 設定ミス - 不適切なインベントリ管理 - APIの安全でない利用 33 

第6章 設計によるAPIセキュリティ Q: 設計段階で気をつけることはなにか (What) パラメータの値設計 - 数値 - 範囲 - 推測性 - 文字列 - インジェクション - 文字列長 - 列挙型 スキーマ - スキーマとモデルが1対多になると危険 - 追加プロパティは避けたい - 入力と出力は異なるスキーマ定義 - Arazzoによるフロー定義で文書を強力に 34 

第6章 +α Arazzoスキーマによるフロー定義 openapi.yaml arazzo.yaml arazzo: 1.0.1 info: ... # Pet Adoption Workflow (Strict) sourceDescriptions: - name: petAdoptionAPI url: ./openapi.yaml type: openapi openapi: 3.0.3 info: ... paths: /pets: get: summary: Search available pets by type parameters: [...] responses: '200': ... # List of matching pets '503': ... # Service temporarily unavailable workflows: - workflowId: pet-adoption-workflow inputs: [...] # petType (cat/dog), ownerId (UUID) フロー組込 /background-checks/{ownerId}: post: summary: Submit a background check for a prospective owner parameters: [...] responses: '201': ... # Background check submitted '504': ... # Gateway timeout components: schemas: Pet: ... # id, name, type [cat, dog] BackgroundCheckResult: ... # status [approved, rejected, pending] steps: - stepId: search-pets operationId: petAdoptionAPI.searchPets parameters: ... # type = $inputs.petType successCriteria: ... # 200 OK ＆ pets配列に要素あり onFailure: - retry: 503エラー時（最大 3回リトライ） - end: 該当ペットなし等で終了 outputs: availablePets: $response.body - stepId: background-check operationId: petAdoptionAPI.submitBackgroundCheck parameters: ... # ownerId = $inputs.ownerId successCriteria: ... # 201 Created ＆ status == 'approved' onFailure: - end: status == 'rejected' で終了 - retry: 504タイムアウト時（最大 2回リトライ） 35 

第7章 APIの認可と認証 Q: APIの認可・認証はどういう形をしているか (What) OAuth (認証コードフロー) OIDC ユーザーデータアクセスを ユーザー が アプリ に委任 ユーザー認証を アプリケーション が IdP に委任 OP (OpenID Provider) 認証  AS 認証 (認可サーバー)  User 委任 委任  User Client   RS (リソースサーバー)  AS RP    UserInfo 36 

第7章 APIの認可と認証 Q: APIの認可・認証はどういう形をしているか (What) OAuth - 4つの委任フロー(v2.1) 認可コード l クライアントクレデンシャル | デバイス認可 | リフレッシュトークン - 認可コードは盗まれないか -> PKCE (必須) - 正規クライアントが使用しているのか -> 送信者制約トークン 送信者制約 レイヤー 検証 メリット / デメリット mTLS L4 cnfとクライアント証明書ハッシュ L4層で信頼 / クライアント証明書管理 DPoP L7 トークンの公開鍵とDPoP Proofの公開鍵 インフラ変更不要 / リソースサーバーの検 証が増える 37 

第7章 APIの認可と認証 Q: APIの認可・認証はどういう形をしているか (What) OIDC - OAuthのフローに標準化されたIDトークンを追加して認証を実現 - IDトークンでユーザー認証結果を表現 - 保護対象はIDトークン, UserInfo ID Token (OIDC) Access Token (OAuth) 主目的 認証 認可 検証場所 RP OpenIDプロバイダー(UserInfo) 検証タイミング 受信直後 利用時 気にするところ 使いまわし・すり替え 正規のRPか 38 

第8章 API認証と認可の実装 Q: APIの認証認可はどういう形をしているか (What) スキーマ定義への認可条件組み込み OAuthサーバー実装 アクセストークン発行・検証 コード例から手を動かしてみる OpenIDプロバイダとの連携 Auth0 (IDaaS) とローカルサーバーをつなぐ Auth0画面操作も 認可の検証を実装 - 署名検証 - RBAC検証 39 

第9章 安全なAPIインフラ Q: インフラでAPIを保護するには (How) APIゲートウェイ - インベントリ管理 - ゾンビ, シャドーAPIの発見、無効化 - JWT検証, mTLS機能 - リクエスト, レスポンスのスキーマ検証(設計の強制) - 共通レスポンスヘッダ - CORS - HSTS - CSP - レートリミット - オブザーバビリティ 乗り換えが簡単でなく, 運用と密結合するためGW選択は慎重に 40 

第9章 安全なAPIインフラ Q: インフラでAPIを保護するには (How) L3 - L6の攻撃保護 - ネットワークセグメントを見直し - (オンプレ, EC2など) - ポート封鎖, プロトコル・サービスOFF, ユーザー制限, FWルール - DoSには製品 L7保護 - WAF - 最近の進化 - プロンプトインジェクション - Bot検知(Silent Challenge) - ルール自動作成 - 振る舞い検知 - IP以外でのレートリミット 41 

第10章 金融グレードAPI Q: 金融グレードのAPIセキュリティとは(What) FAPI(Financial-grade API) - OpenID FoundationのAPIセキュリティ標準 FAPI 1.0: 金融特化 / FAPI 2.0 医療・法律・行政など 攻撃モデルの3目標: - 認可, 認証の安全性(トークン保護) セッション完全性: 改ざん・リプレイ防止 セキュリティプロファイル: - クライアントは常にコンフィデンシャル(2.0ではこれ以外も) - JAR: リクエストをJWTで署名・カプセル化 - PAR: リクエストを事前プッシュしURI化 - 送信者制約 メッセージ署名プロファイル: - 目的: 否認防止(誰が何をしたか証明) - PAR + JARM + イントロスペクション + IDトークン署名 42 

第10章 FAPI +α Q: OAuthでもまだ取りこぼしがある？ (Where) OAuth (認証コードフロー) ユーザーデータアクセスを ユーザー が アプリ に委任 フロントチャネルでの改ざんを防 ぐ -> JAR そもそもフロントチャネルに認可 リクエストを流さない -> PAR 認可リクエスト・レスポンスの 配送を任せていいのか  User - 改ざん URL肥大  AS (認可サーバー) フロントチャネルでのレスポンス 改ざん・漏洩を防ぐ -> JARM —---------------------------------  RS HTTPパラメータの保護 -> JWTで 保護しちゃえばいいじゃない -> JAR/JARM Client  (リソースサーバー) 通信経路をフロントに流さないよ うにしよう -> PAR 43 

第11章 APIセキュリティのためのオブザーバビリティ Q: 今、何が起きているか、誰の仕業か (What / Who) 背景: - 完璧なセキュリティ: 存在しない - 検出の鍵: オブザーバビリティ テレメトリデータ: - ログ: イベント記録 - トレース: trace_idでログを関連付け - メトリクス: 集約データで外れ値検出 (RPS/レイテンシ/エラー率) 計装: - OTel: ベンダー非依存の標準 - ゼロコード計装: コード変更不要 - カスタムスパン: ビジネスロジック層の詳細を手動で記録 - 高カーディナリティを目指そう - 調査時の検索性UP 44 

第11章 APIセキュリティのためのオブザーバビリティ Q: 今、何が起きているか、誰の仕業か (What / Who) 入力ベース攻撃検出: - リクエスト全詳細をログ化 - 機密データ: マスク・除外必須 - WAF連携: インジェクション検知 - stdout + サイドカー: 性能懸念を回避 エンドポイント乱用検出: - 事例: Peloton API(2021) — ユーザー列挙→詳細取得 - 単一ログ検出不可、呼び出し回数パターンが鍵 - エンドポイント単位メトリクス + 発信元情報 - 対応: 検知→調査→レート制限/拒否リスト 45 

第12章 APIセキュリティのテスト Q: APIは本当に安全なのか、それをどう確かめるか (How) テスト戦略の原則 - 起点: 脅威モデル - 優先順位: 効果大・セットアップ小から着手 - ペネトレーションテスト: 高品質・高コスト・低頻度 - 自動テスト: 高速・定型攻撃向き、ビジネスロジックは苦手 手を動かす - Spectral: lint実行 - Schemathesis: ファジング実行 - pytest(アクセス制御): 認証不備/BOLA/RBACの失敗を確認 - pytest(ビジネスフロー): クーポン重複/濫用の失敗を確認 ツールを動かす -> 失敗・検出結果を見る -> 原因を読み解く 46 

第12章 APIセキュリティのテスト Q: APIは本当に安全なのか、それをどう確かめるか (How) 手順: - 自動化が効く層から順に着手 - 下の層ほど人手のテスト設計が必須 - 4層の組み合わせで初めて網羅できる リンター(Spectral) できる 仕様の設計欠陥検出 (未認証/制約なし/管理者権限) できない 実装が仕様通り動くか コントラクトテスト (Schemathesis) 仕様と実装の乖離 不正入力への耐性 ビジネスロジック 認可の妥当性 ユニットテスト(pytest) BOLA/RBAC/ABAC ビジネスフロー悪用の検証 仕様全体の網羅的自動チェック (手動作成が前提) 47 

03 あわせて読みたい Copyright © 3-shake, Inc. All Rights Reserved. 48 

資料・ブログ紹介 Webページセキュリティについて知りたい 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 1章 Webアプリケーションの脆弱性とは 2章 実習環境のセットアップ 3章 Webセキュリティの基礎 ～HTTP、セッション管理、同 一生成元ポリシー 4章 Webアプリケーションの機能別に見るセキュリティバグ 5章 代表的なセキュリティ機能 6章 文字コードとセキュリティ 7章 脆弱性診断入門 8章 Webサイトの安全性を高めるために 9章 安全なWebアプリケーションのための開発マネジメント https://www.sbcr.jp/product/4797393163/ 49 

資料・ブログ紹介 脅威モデリングをはじめたい 脅威モデリング早見表 はじめるならここから - 設計段階でリスクを早めに見つける - STRIDEで脅威を整理 - 対策は「緩和・削除・移転・受容」 https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html 50 

資料・ブログ紹介 OWASP API Security Top 10 2023 OWASP API Security Top 10 2023 - 10の項目を解説 - GraphQLで説明 https://owasp.org/API-Security/editions/2023/en/0x00-header/ 51 

資料・ブログ紹介 JWTのセッション管理の問題を知りたい Stop Using JWTs 発端: JWT をブラウザのユーザーセッション管理に使う な - ブラウザのユーザーセッション - 仕様・ライブラリ - セッション管理と無効化 - パフォーマンスとインフラ規模 https://news.ycombinator.com/item?id=48558147 52 

資料・ブログ紹介 JWTの設計判断をしたい JSON Web Token Cheat Sheet ベストプラクティスとアンチパターン - JWT利用可否と設計上の注意 - 署名方式（公開鍵 vs MAC） - キー／シークレット管理のルール - 典型的な脆弱性と対策 - トークン失効 などなど https://github.com/OWASP/CheatSheetSeries/blob/mas ter/cheatsheets/JSON_Web_Token_Cheat_Sheet.md 53 

資料・ブログ紹介 OAuth2.0とOIDCを比較してみたい OAuth2.0とOpenID Connectはどう違うのか？ - OAuth2.0とOpenIDConnectの違い - 使用する場面でみる違い - トークンの違い - 設計例 https://qiita.com/yngwie6120/items/e481a8a174c6d4f7fc02 54 

資料・ブログ紹介 JWTの保管場所の変遷を知りたい 「JWT を localStorage に置くな」はなぜ言わ れるのか、Cookie 回帰までの時系列整理 - Cookieセッションの時代 - SPA普及でJWT + localStorage - XSSや即時失効の難しさでJWT運用が破綻 - BFFにトークンを隔離する流れ - 最終的にCookieセッションへ回帰 https://zenn.dev/khale/articles/web-session-jwt-cookie-history 55 

ありがとうございました！ Copyright © 3-shake, Inc. All Rights Reserved. 56