要点: 有効TokenはIdentity Claimを示しますが、全Object・Operationの許可は示しません。
課題
長期API Key、JWT設定ミス、Tenant越境ID、未検証WebhookによりAuthentication後も重要な認可が残ります。
単純な対策だけでは不十分な理由
JWTは正しい設定でのみ安全です。Issuer、Audience、Algorithm、Key Freshnessを確認します。
Object ID変更によるHorizontal認可漏れをQuery Scopeで防ぎます。
処理フロー
Edge
Size・Abuse Limit→Identity
Issuer・Audience→Policy
Tenant・Object Access→Audit
Decision・Key Lifecycle
Size・Abuse Limit→Identity
Issuer・Audience→Policy
Tenant・Object Access→Audit
Decision・Key Lifecycle
アーキテクチャ上の判断
Policy集中・Enforcement分散
共通Policy Testを使い、Data Owner Serviceで実行します。
Workload Identity
Environmentの恒久Secretより短期Machine Credentialを使います。
WebhookをUntrusted Input扱い
Parse前検証、Delivery ID、Timestamp Window、Idempotencyを使います。
さらに深く考える
Data-aware認可
RoleだけでなくMembership、Ownership、State、Field感度を使います。
Break-glassもProduct
Approval、Expiry、Reason、Scope、Immutable Auditが必要です。
実装手順
- TokenのIssuer、Audience、Algorithm、Expiry、Keyを検証します。
- Action、Tenant、Objectを同時に認可します。
- Raw Body、Timestamp、Replay Protectionで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 processedRotation中は短いOverlapで二Keyを受理し、Secretや機密Raw PayloadをLogしません。
想定すべき障害パターン
- 内部Serviceが偽Identity Headerを信頼します。
- Clock SkewでWebhookを全拒否します。
- Revoke済みKeyをCacheが許可します。
監視すべきシグナル
| シグナル | 確認する理由 |
|---|---|
| Policy Reason別Deny | AttackとRegressionを検出します。 |
| Credential Age・Rotation | 孤立した長期Accessを示します。 |
| Webhook署名・Replay失敗 | Integration ErrorとAbuseを分離します。 |
設計の検証方法
- User・Tenant・Object・Action Matrixを試験します。
- Traffic中にKeyをRotate・Revokeします。
- Webhookを改変・Replayします。
安全なRollout計画
Credentialと認可Checkを棚卸しし、Decision Logを先行します。API単位でPolicy Testへ移行し、Credential寿命を段階短縮して緊急Rotationを訓練します。
本番前チェックリスト
- Service Credentialは短期・単一Workload Scopeです。
- RotationにOverlapと即時Revokeがあります。
- Denyと特権変更を改ざん耐性Auditへ残します。
まとめ
API SecurityはLogin GateではなくAuthorityを継続的に減らす設計です。