要点: 有効なトークンは呼び出し元を示すだけで、すべての操作権限を証明するものではありません。
この記事の用語: 認証：アイデンティティの確認。認可：操作権限の確認。Webhook：外部システムからAPIへ届く通知。
現場の課題
長期API キーは漏えいします。ログイン済み利用者もIDを変えて別資源へアクセスできるかもしれません。Webhookも署名と再送防止がなければ偽造・再実行されます。
単純な対策だけでは不十分な理由
トークンはアイデンティティを示すだけです。APIは操作、テナント、オブジェクトごとに認可し、Webhookは署名、送信時刻、再実行防止を確認します。
処理フロー
Edge
Size・Abuse 上限→アイデンティティ
Issuer・Audience→ポリシー
テナント・オブジェクト アクセス→Audit
Decision・キー ライフサイクル
Size・Abuse 上限→アイデンティティ
Issuer・Audience→ポリシー
テナント・オブジェクト アクセス→Audit
Decision・キー ライフサイクル
アーキテクチャ上の判断
ポリシー集中・Enforcement分散
共通ポリシー テストを使い、データ 担当者 サービスで実行します。
Workload Identity
Environmentの恒久シークレットより短期Machine 認証情報を使います。
WebhookをUntrusted Input扱い
Parse前検証、Delivery ID、送信時刻 Window、冪等性を使います。
さらに深く考える
データ-aware認可
RoleだけでなくMembership、所有責任、State、Field感度を使います。
Break-glassもProduct
Approval、期限、Reason、Scope、Immutable Auditが必要です。
実装手順
- すべてのトークンでIssuer、Audience、Algorithm、期限、鍵の状態を確認します。
- サーバー側で操作、テナント、オブジェクトをまとめて認可します。
- Webhookは受信した受信したバイト列を署名検証し、送信時刻と再実行防止も確認します。
コード例: Webhook Verification Envelope
signed = timestamp + '.' + rawBody
expected = HMAC(activeSecret, signed)
reject unless constantTimeEqual(signature, expected)
reject if abs(now - timestamp) > 5 minutes
reject if deliveryId already processedローテーション中は短いOverlapで二キーを受理し、シークレットや機密生データ Payloadをログしません。
想定しておく障害
- 内部サービスが偽アイデンティティ ヘッダーを信頼します。
- Clock SkewでWebhookを全拒否します。
- 権限取り消し済みキーをキャッシュが許可します。
監視すべきこと
| 指標 | 何が分かるか |
|---|---|
| ポリシー Reason別Deny | AttackとRegressionを検出します。 |
| 認証情報 Age・ローテーション | 孤立した長期アクセスを示します。 |
| Webhook署名・再実行失敗 | 外部連携 エラーとAbuseを分離します。 |
設計の検証方法
- 利用者・テナント・オブジェクト・操作 Matrixを試験します。
- トラフィック中にキーをRotate・権限取り消しします。
- Webhookを改変・再実行します。
本番導入の進め方
認証情報と認可箇所を棚卸しし、判断ログを先に追加します。APIグループごとに共通ポリシーへ移し、トークン寿命を短くし、緊急ローテーションを訓練してから全面強制します。
本番前チェックリスト
- サービス 認証情報は短期・単一Workload Scopeです。
- ローテーションにOverlapと即時権限取り消しがあります。
- Denyと特権変更を改ざん耐性Auditへ残します。
まとめ
API セキュリティは権限を継続的に狭め、各操作を検証するプロセスであり、ログイン処理一つではありません。