ケイパビリティベースセキュリティ

リソースへのアクセス権を偽造不可能なトークン (ケイパビリティ) として管理するセキュリティモデル

セキュリティ認可

ケイパビリティベースセキュリティとは

ケイパビリティベースセキュリティは、リソースへのアクセス権を偽造不可能なトークン (ケイパビリティ) として表現し、そのトークンを持つ者だけがリソースにアクセスできるセキュリティモデルである。1966 年に Dennis と Van Horn が提唱した。

ACL (アクセス制御リスト) が「誰がアクセスできるか」をリソース側で管理するのに対し、ケイパビリティは「何にアクセスできるか」をトークン側で管理する。

ACL との比較

ACL モデル:
  リソース (ファイル) → [Alice: 読み取り, Bob: 読み書き]
  アクセス時: 「Alice がファイルにアクセス」→ ACL を確認 → 許可/拒否

ケイパビリティモデル:
  Alice → [ファイルA: 読み取りトークン, ファイルB: 読み書きトークン]
  アクセス時: 「トークンを提示」→ トークンが有効なら許可
観点 ACL ケイパビリティ
管理の主体 リソース側 トークン保持者側
権限の委譲 管理者が設定 トークンを渡すだけ
最小権限 設定が複雑 トークンの粒度で自然に実現
権限の取り消し ACL から削除 トークンの無効化 (困難な場合あり)

実務での具体例

S3 署名付き URL

S3 の署名付き URL は、ケイパビリティの典型例だ。URL 自体がアクセス権を含んでおり、URL を知っている人は誰でもアクセスできる。

const url = await getSignedUrl(s3Client, new GetObjectCommand({
  Bucket: 'my-bucket',
  Key: 'private/report.pdf',
}), { expiresIn: 3600 }); // 1時間有効

// この URL を持つ人は誰でも report.pdf をダウンロードできる
// https://my-bucket.s3.amazonaws.com/private/report.pdf?X-Amz-Signature=...

JWT

JWT はユーザーの権限情報をトークンに含む。トークンを持つリクエストは、サーバーが DB を参照せずに権限を検証できる。

API キー

API キー自体がアクセス権を表す。キーを持つ者は API にアクセスできる。

ケイパビリティの利点

  • 権限の委譲が容易 (トークンを渡すだけ)
  • 最小権限が自然に実現される (必要な権限だけのトークンを発行)
  • 分散システムとの相性が良い (中央の ACL サーバーが不要)

ケイパビリティの課題

権限の取り消し

トークンが配布された後、特定のトークンだけを無効化するのが困難。対策:

  • 短い有効期限 (TTL) を設定する
  • トークンの無効化リスト (ブラックリスト) を管理する
  • リフレッシュトークンで定期的に再発行する

トークンの漏洩

トークンが漏洩すると、漏洩者がアクセス権を得る。HTTPS での通信、トークンの暗号化、短い TTL で影響を限定する。

ケイパビリティベースセキュリティを扱う関連書籍も多い。

関連用語