【入門編】 APIゲートウェイでのIPホワイトリスト/ブラックリスト制御 – Web APIアーキテクチャ・データ連携実践ガイド

門番は誰に任せる?APIゲートウェイで「住所」をもとにアクセス制御をする話

こんにちは!ネットワークの世界にどっぷり浸かって20年、パケットの旅路を眺めるのが何より好きなエンジニアです。

今日は、Web API開発の現場で避けては通れない「誰がこのAPIを叩いていいのか?」という、言わば「APIの門番」の話をしましょう。

APIを公開すると、世界中の誰からでもアクセスできるようになります。しかし、社内システムや特定のパートナー企業からしか呼び出してはいけないAPIもあるはずですよね。そんなとき、どうやって「怪しい訪問者」を追い返し、「信頼できる訪問者」を通せばいいのでしょうか?

今日は、APIゲートウェイを使った「IPアドレスによるアクセス制限」について、郵便配達に例えて紐解いていきましょう。

—

1. インターネット上の「住所」、IPアドレスとは?

皆さんが誰かに手紙を出すとき、必ず「住所」を書きますよね。インターネットの世界でも同じです。Webサーバーにリクエストを送るとき、送り主には必ず IPアドレス という「デジタルの住所」が割り振られています。

例えば、192.168.1.5 といった数字の並びがそれです。

APIゲートウェイは、いわば「マンションの管理室」です。届いたリクエスト(手紙)の送り主の住所(IPアドレス)をチラッと見て、こう判断します。

  • 「あ、この住所は許可リスト(ホワイトリスト)に入っているな。どうぞ、お入りください!」
  • 「うーん、この住所は知らないぞ。セキュリティのために門前払いだ!」

これが、IPベースのアクセス制御の仕組みです。一歩ずつ、その具体例を見ていきましょう!

—

2. ホワイトリストとブラックリスト、どっちを使うべき?

アクセス制御には大きく分けて2つの戦略があります。

ホワイトリスト(許可リスト)方式

「信頼できる特定の住所からのみ受け入れる」方式です。
「原則拒否、許可された者だけ通す」という姿勢なので、セキュリティレベルは非常に高いです。社内システム同士の連携など、相手が明確な場合に適しています。

ブラックリスト(拒否リスト)方式

「特定の迷惑な住所だけを拒否する」方式です。
「原則許可、悪さをする奴だけ追い出す」という姿勢です。特定の攻撃者や、スパム送信元をピンポイントでブロックする場合に使われます。

基本的には、セキュリティを考えるならホワイトリスト方式を強くおすすめします。 不特定多数からのアクセスを許可した上でブラックリストを運用するのは、穴を見つけるイタチごっこになりがちだからです。

—

3. APIゲートウェイでの設定イメージ(AWS API Gatewayの例)

実際にAPIゲートウェイ(ここではAWSを想定)で、どうやって門番を配置するか見てみましょう。これには「リソースポリシー」という設定を使います。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:region:account-id:api-id/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24"  // このネットワークからのアクセスだけ許可する(ホワイトリスト)
          ]
        }
      }
    }
  ]
}

このように、Condition(条件)の中に IpAddress を指定することで、特定のネットワークセグメントからしかリクエストを受け付けないように制限できます。これだけで、世界中の不特定多数から届く「郵便物」を、指定した相手以外は全て弾くことができるんです。

—

4. 運用上の注意点:IPは「偽装」されることもある?

ここで一つ、ベテランからのアドバイスです。「IP制限をしていれば完璧だ!」と油断してはいけません。

インターネットの世界には、プロキシサーバーやロードバランサーという「中継地点」がたくさんあります。リクエストがそれらを経由すると、APIゲートウェイに届く最後の送信元IPが「中継地点のIP」に書き換わってしまうことがあります。

  • X-Forwarded-For ヘッダー:

リクエストが経由してきた「真の送信元」を記録するヘッダーです。もしAPIの前段にWAF(Web Application Firewall)などを置いている場合は、単にIPを見るだけでなく、このヘッダーの値も踏まえて判定する仕組みが必要です。

ネットワークの構成が変わると、門番のチェックポイントがずれる可能性がある。これこそが、インフラ構築の面白いところであり、苦労するところでもありますね。

—

まとめ:正しい門番を置いて、安全なAPIライフを

APIゲートウェイでのアクセス制御は、以下の3ステップで考えるとシンプルです。

1. 誰からのアクセスを許可するかを決める(ホワイトリスト優先)
2. APIゲートウェイのポリシーでIP範囲を指定する
3. WAF等の前段機器がある場合、IPが正しく伝わっているか確認する

最初は難しく感じるかもしれませんが、パケットを「手紙」、IPアドレスを「住所」としてイメージすれば、少し身近に感じられるはずです。

皆さんの作る素晴らしいAPIが、信頼できる相手とだけ安全に繋がれるよう、ぜひ今日から「門番」の役割をAPIゲートウェイに任せてみてくださいね。それでは、また次のネットワークの深淵でお会いしましょう!

コメント

タイトルとURLをコピーしました