IPアドレスの固定（IP許可リスト）
認証＋TLS が土台。IP の固定は“もう一枚”で、主に鍵が漏れたときの被害を狭める ― API と DB で効きが違う
接続元 IP の固定（IP 許可リスト）は必須ではありません。通信を守るのは TLS、相手を確かめるのは鍵/トークンで、この土台だけでも多くの API は十分に運用できます。IP の固定はその上に足す“もう一枚”で、主な効果は『鍵が漏れても許可した IP 以外からは弾く』＝被害を狭めること。差が大きいのは高価値な鍵と DB です。
- TLS＋認証（鍵/トークン）が必須の土台 ― IP 固定はその上の任意の一枚
- 効くのは主に『鍵が漏れても他 IP から弾く』＝被害の局所化（認証の代わりではない）
- DB は API より重視される（プライベート接続が上位互換）
「IP を固定する」とは？
「接続元 IP を固定する」とは、①自分（呼び出す側）がいつも同じ送信元 IP アドレスから外に出るようにし、②相手のサービス側の『IP 許可リスト（allowlist）』に『このアドレスからだけ通す』と登録すること。多くのサービスで“任意のオプション”として用意されています（Azure・Google の API キー・OpenAI・Stripe、DB では Neon の上位プランなど）。既定はたいてい『どこからでも（ただし鍵は必須）』です。
大前提として、通信は TLS で暗号化＋接続先の確認がされ、相手は API キー/トークン/mTLS で『誰か』を確認します。これが“土台”で、世界中のほとんどの API はこれだけで運用されています。IP の固定はこの土台を置き換えるものではなく、上に重ねる“もう一枚”（多層防御）です。だから『固定しないと危険』でも『固定すれば安心』でもなく、足すかどうかは費用対効果で選ぶ話になります。
各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。
認証＋TLS で機密性・なりすましは守れる。ただし鍵が漏れれば世界中どこからでも即・悪用されうる。
この図をテキストで読む
構成図「固定しない / オプションで固定 ― 何が変わる？」。ブロック6個、つながり4本。 枠: 固定しない（認証＋TLS のみ）（ブロック3個）、オプションで IP を固定（＋許可リスト）（ブロック3個）。 【ブロック】 - 認証＋TLS（土台）: 誰か＋暗号化 - 送信元はどこでも OK: 鍵が合えば世界中から - 鍵漏洩＝即・無差別に悪用: どこからでも使われる - 認証＋TLS（同じ土台）: ここは変わらない - 許可した IP だけ通す: 認証の手前で一枚 - 鍵漏洩でも他 IP は弾く: 被害を局所化 【流れ】 - 固定しない: 認証＋TLS（土台） → 送信元はどこでも OK → 鍵漏洩＝即・無差別に悪用 - オプションで固定: 認証＋TLS（同じ土台） → 許可した IP だけ通す → 鍵漏洩でも他 IP は弾く
固定しない / オプションで固定 ― 差の一覧
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。2列 × 6行。 【列】 1. 固定しない（認証＋TLS のみ（標準）） 2. オプションで固定（＋IP 許可リスト） 【比較】（観点ごとに） ■ 通信の暗号化・改ざん防止 - 固定しない: TLS で担保 / 差なし - オプションで固定: TLS で担保 / 差なし ■ なりすまし防止（認証） - 固定しない: 鍵 / トークンで担保 - オプションで固定: 同じ / IP は認証の代わりにならない ■ 鍵・パスワードが漏れたとき - 固定しない: どこからでも即・無差別に悪用 - オプションで固定: 許可 IP 以外からは弾く / 被害を局所化（最大の差） ■ 無差別スキャン・総当り - 固定しない: 認証層まで到達 / 弾くのは認証 - オプションで固定: 認証の手前で遮断 / L3/L4 で拒否 ■ 運用コスト・壊れやすさ - 固定しない: 追加なし / 動的 IP でも動く - オプションで固定: 固定の送信元 IP が要る / 静的 egress/NAT の費用＋保守・動的だと事故 ■ 向く相手 - 固定しない: 低〜中価値の公開 API / 多くの SaaS の標準 - オプションで固定: 高価値な鍵・DB・管理系・規制要件 / プライベート接続ならさらに強い
API と DB で温度感が違う
同じ『IP の固定』でも、対象で重みが変わります。ステートレスで公開前提の API は、認証＋TLS が標準ベースラインで、IP 許可リストは任意の上乗せ（OpenAI・Google API キー・Stripe などが提供、Anthropic のように持たない API も）。一方 DB は大量データを抱える高価値な資産なので、『そもそも公衆網に晒さない／接続元を絞る』ことが“事実上の標準”寄りです。実装は2系統 ── ①公開エンドポイント＋IP 許可リスト（Neon の IP Allow・RDS のセキュリティグループ・Cloud SQL の Authorized Networks）と、②公衆網を通らないプライベート接続（PrivateLink / Private Service Connect / プライベート IP）。後者の方が強い隔離で、単なる IP フィルタの上位互換です。
「十分さ」の見極め ― 足すかは天秤で決める
認証＋TLS は“不十分”ではありません（世界中の API がこれで動いています）。IP を足すかどうかは、守る対象の価値 × 鍵が漏れる起きやすさ（＝リスク）と、固定 IP の出口（NAT・静的 IP）を持つ費用・運用（＝コスト）の天秤で決めます。目安は、低〜中価値の公開 API なら土台だけで十分／高価値な鍵・DB・管理系・規制要件なら足す（可能ならプライベート接続へ）。IP に依存して認証を弱めるのは本末転倒です。
「IP は詐称で破られる」は基本ノー ― 弱点は別のところ
TCP＋TLS はサーバからの応答（SYN-ACK）が“本物の IP の持ち主”に返るため、単純な送信元 IP の詐称だけでは接続を最後まで張れません。だから IP 許可リストは L3/L4 の関所として実際に機能します。現実的な弱点は“詐称”ではなく、①共有 IP（同じ出口を使う他人まで暗黙に信頼してしまう）②動的 IP で運用が壊れる③許可ネットワーク内部の乗っ取り／SSRF で許可ホストを踏み台にされる、の 3 つ。だから IP は“信頼の唯一の根拠”にはせず（ゼロトラストの考え方）、あくまで認証の上の一枚として使います。
押さえておきたい用語
- IP 許可リスト（allowlist）
- サービス側に『この送信元アドレスからだけ通す』と登録する設定。多くのサービスで任意。既定は全ネットワーク許可（ただし認証は必須）。
- 送信元 IP を固定（静的 egress）
- 自分側がいつも同じ IP から外に出るようにすること。クラウド/サーバレスは既定で IP が動的なので、NAT ＋固定 IP などの“出口”を用意して固定する。
- 多層防御（defense in depth）
- 1 つの対策に頼らず層を重ねる考え方。認証＋TLS の上に IP 許可リストを足すのがその一例。
- ブラスト半径
- 事故（ここでは鍵漏洩）が起きたときに悪用が及ぶ範囲。IP 固定はこれを狭める（漏れた鍵も許可 IP 外では使えない）。
- プライベート接続
- 公衆インターネットを通らず、専用の経路でつなぐ方式（PrivateLink / Private Service Connect / プライベート IP）。IP 許可リストより強い隔離で、特に DB で推奨。
- mTLS（相互 TLS）
- サーバだけでなくクライアントも証明書で名乗る方式。『どこから』でなく『誰か』を強く縛れるため、IP 固定より本質的な代替になりうる。
- ゼロトラスト
- 『ネットワークのどこにいるか（IP）』だけでは信頼しない考え方。IP は判断材料の一つに格下げし、認証・認可を主役にする。
ここから先へ
この解説とつながりのあるページ