【入門編】 API認証におけるBearerトークンの漏洩防止とTLSの強制 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

こんにちは！セキュリティの世界へようこそ。

「暗号理論」や「認証基盤」と聞くと、なんだか難しそうな数式や複雑なシステムを想像してしまいませんか？「APIのセキュリティを担当することになったけれど、何から手をつければいいのかわからない…」と戸惑う新人の開発者やWeb担当者の方も多いはずです。

でも、安心してくださいね！セキュリティの根本にある考え方は、実は「私たちの日常にある防犯の仕組み」とそっくりなんです。

この記事では、Web APIの開発でよく使われる「Bearer（ベアラー）トークン」をテーマに、なぜそれが狙われるのか、そして盗聴を防ぐための「TLS 1.3」と「HSTS」という強力な防犯システムの仕組みを、身近な例えを交えながら一歩ずつ丁寧に紐解いていきます。一緒に楽しく学んでいきましょう！

—

1. Bearerトークンとは？「持っている人が誰でも使えるVIPパス」の危険性

まず、API認証で超メジャーな「Bearerトークン」についてお話しします。

Authorization: Bearer eyJhbGciOiJKV1Qi...

こんな文字列、見たことがありますよね？
「Bearer」という英語は「持参人」という意味があります。つまり、Bearerトークンを一言で例えるなら、「テーマパークの無記名VIPパスポート」です。

なぜ盗まれると危険なのか？

このパスポート（トークン）には、ユーザーの識別情報や権限が詰め込まれています。重要なのは、テーマパークのスタッフ（APIサーバー）は、「そのパスポートを見せられたら、持ち主が誰であれ通過させてしまう」という点です。

もし、このVIPパスポートを泥棒（サイバー攻撃者）に盗み見られたり、コピーされたりしたらどうなるでしょう？
泥棒はあなたのパスポートを使って自由にアトラクション（API）を操作し、個人情報を盗んだり、データを書き換えたりできてしまいます。パスワードの再入力すら求められません。

だからこそ、このパスポートをAPIサーバーに届ける「道中」で、絶対に泥棒に見られないようにする仕組みが必要になるのです。

—

2. 盗聴者からパスポートを守る「TLS 1.3」と暗号化の仕組み

通信の道中でデータを守る防犯システム、それがTLS（Transport Layer Security）です。
WebサイトのURLが https:// で始まるのは、このTLSという装甲車の中に通信を通しているからなんですね。

では、この装甲車の中ではどのように暗号化が行われているのでしょうか？ここで登場するのが「公開鍵暗号（楕円曲線暗号など）」と「共通鍵暗号（AES）」の連携プレーです。

「鍵の共有」と「高速な暗号化」のタッグチーム

1. 公開鍵暗号（楕円曲線暗号 ECC など）＝「開いた南京錠の受け渡し」
通信を始める一番最初（ハンドシェイク）、ブラウザとサーバーは「これから使う秘密の鍵」を安全に共有する必要があります。誰に見られても安全なように、数学的に計算が非常に難しい「公開鍵暗号（特に最近は軽量で頑丈な楕円曲線暗号 ECC が主流です）」を使って、安全に鍵のタネを交換します。

2. 共通鍵暗号（AES）＝「同じ鍵を使った高速な金庫の開閉」
無事に同じ「秘密の鍵」を共有できたら、ここからは処理が圧倒的に早い「共通鍵暗号（AES）」に切り替えます。Bearerトークンを含む実際のデータは、このAESという頑丈な金庫に入れて送受信されます。

なぜ「TLS 1.3」を使うべきなの？

TLSには古いバージョン（TLS 1.0, 1.1, 1.2）が存在します。古いバージョンの装甲車は、鍵の壊し方（脆弱性）が知られていたり、鍵の交換に時間がかかったりします。

最新のTLS 1.3は、古い暗号方式をバッサリと切り捨て、安全で最もスピーディーな仕組みだけを残した「最強の最新型装甲車」です。Bearerトークンを守るためには、古いTLSを無効化し、TLS 1.3（最低でもTLS 1.2）を強制することが鉄則となります。

—

3. 泥棒の罠「HTTPへの連れ出し」を防ぐ「HSTS」

TLS 1.3で通信を暗号化すれば一安心…と言いたいところですが、攻撃者はさらに賢い手を仕掛けてきます。それが中間者攻撃（Man-in-the-Middle : MitM）です。

暗号化されない「普通の道（HTTP）」へ誘い込む攻撃

ユーザーがブラウザの住所欄に example.com とだけ入力してアクセスしたとします。最初は暗号化されていない「HTTP（http://）」で接続しようとしますよね。

攻撃者はこの一瞬を狙います！
通信の途中に割り込み、ユーザーには「普通の道（HTTP）」を通らせ、自分だけがサーバーと「安全な道（HTTPS）」で通信するのです。こうなると、ユーザーが送信したBearerトークンは、攻撃者の目の前を裸（生のテキスト）で通過することになり、あっさり盗まれてしまいます。

[ ユーザー ]  --( 裸のデータ HTTP )-->  [ 攻撃者(悪意ある中間者) ]  --( 暗号化 HTTPS )-->  [ サーバー ]
                                    ↑
                          ここでトークンが丸見えに！

解決策：HSTS（HTTP Strict Transport Security）

この「うっかり普通の道を通ってしまう事故」を防ぐのがHSTSというWebヘッダーの仕組みです。

HSTSを一言で言うなら、サーバーからブラウザに対する「金庫室の壁に刻む強い命令」です。

サーバーがレスポンスで「今後は絶対暗号化してアクセスしてね！」というHSTSヘッダーを返すと、ブラウザはそれを強力に記憶します。次回以降、ユーザーが http:// でアクセスしようとしても、ブラウザが自発的に https:// へ書き換えて接続してくれるようになります。

—

4. 【実務で使える】Webサーバー＆コードでの設定例

仕組みが分かったところで、実際に私たちが運用するサーバーやアプリケーションにこの防犯システムを導入してみましょう！

① NginxでのTLS 1.3設定とHSTSヘッダーの付与

Webサーバーとして広く使われているNginxの設定ファイル（nginx.conf など）の例です。古いTLSを拒否し、HSTSを有効化します。

server {
    listen 443 ssl http2;
    server_name api.example.com;

    # SSL証明書と秘密鍵の設定
    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

    # 【重要】TLS 1.2 と TLS 1.3 のみに制限（古い 1.0 / 1.1 は拒否）
    ssl_protocols TLSv1.2 TLSv1.3;
    
    # 強固な暗号スイート（暗号の組み合わせ）を指定
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # 【重要】HSTS（HTTP Strict Transport Security）ヘッダーの追加
    # max-age=31536000 : 1年間（31536000秒）はこのサイトにHTTPS接続を強制する
    # includeSubDomains : サブドメイン全体にもこのルールを適用する
    # preload : ブラウザの「HSTSプリロードリスト」への登録を許可する
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    location / {
        proxy_pass http://localhost:3000;
    }
}

# HTTP（80番ポート）でアクセスが来たら、即座にHTTPSへリダイレクト（転送）する設定
server {
    listen 80;
    server_name api.example.com;
    
    # 301永久転送で HTTPS へ誘導
    return 301 https://$host$request_uri;
}

② Node.js (Express) アプリケーションでの実装例

アプリケーション側でも、「もしHTTPで通信が来たらエラーにする（あるいはヘッダーを付与する）」ような多層防御を固めておくとより安心です。Node.jsの定番フレームワーク Express では、helmet というセキュリティライブラリを使うのが一般的です。

const express = require('express');
const helmet = require('helmet');

const app = express();

// Helmetミドルウェアを使ってセキュリティヘッダーを自動設定
app.use(
  helmet({
    // HSTSの設定
    hsts: {
      maxAge: 31536000, // 1年間（秒単位）
      includeSubDomains: true, // サブドメインも対象に含める
      preload: true, // プリロードリストへの登録を有効化
    },
  })
);

// Bearerトークンを受け取るAPIエンドポイントの例
app.get('/api/v1/user/profile', (req, res) => {
  // リクエストヘッダーから Authorization を取得
  const authHeader = req.headers['authorization'];

  // トークンが存在しない、または Bearer 形式でない場合は弾く
  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'アクセストークンが必要です' });
  }

  // "Bearer " の後ろのトークン文字列を取り出す
  const token = authHeader.split(' ')[1];

  // (※ここでトークンの検証ロジックを行います)

  res.json({ message: '認証成功！安全な通信でプロファイルデータを返します。' });
});

app.listen(3000, () => {
  console.log('APIサーバーが起動しました（Port: 3000）');
});

—

5. まとめ：安全なAPI運用のためのチェックリスト

最後に、今回学んだ大切なポイントをおさらいしましょう！

1. Bearerトークンは「見せたら誰でも使えるVIPパス」
だからこそ、送信する「道中」の暗号化が何より重要です。
2. TLS 1.3で最強の装甲車を立てる
楕円曲線暗号（ECC）で安全に鍵を交換し、共通鍵暗号（AES）でトークンを爆速・堅牢に暗号化しましょう。
3. HSTSで「普通の道（HTTP）」への迂回を遮断する
Strict-Transport-Security ヘッダーを吐き出して、ブラウザに「常にHTTPSで通信すること」を記憶させましょう。

セキュリティ対策は、何かひとつ大きな壁を作るのではなく、「暗号化 × HSTS × トークン管理」というように、いくつもの小さな防犯対策を重ね合わせていく（多層防御）ことが成功の鍵です。

難しそうに見えた暗号やヘッダーの設定も、役割と理由が分かれば「なるほど、だから必要なんだ！」と納得できますよね。

一歩ずつコードやサーバー設定を見直して、攻撃者が手も足も出ない「安全で信頼されるWebサービス」を一緒に作り上げていきましょう！応援しています！

スポンサーリンク

コメント

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