各連携に個別のキーを付与してください。

作成前にスコープを定義する

キーにはそのジョブに必要なアクションとリソースのみを付与してください。監視連携には読み取りアクセスが必要な場合があり、デプロイツールには定義された一連のライフサイクル操作が必要な場合があります。可能な限り請求権限は分離してください。

慎重に開示し、非公開で保管する

実際のキーは安全な作成フローを通じて表示し、保存時に保護し、URL、ブラウザバンドル、ソース管理から除外する必要があります。シークレット自体を公開せずに、所有者、目的、作成時刻を記録してください。

実用的な失効手順の整備

連携ごとに個別の認証情報を発行し、すべてを停止せずに1つだけを取り消せるようにしてください。計画的にローテーションし、古いキーが機能しなくなったことを確認してください。範囲を限定した監査記録で予期しない使用状況を調査してください。

制限をテストしてください

有用な起動テストには、許可された操作、禁止された操作、期限切れまたは失効したキー、キーのリソース境界外のリクエストが含まれます。認証だけでは認可ではありません。

候補キーポリシー

API 契約では、アカウントごとに最大10個の有効な鍵を、名前付きの用途、任意の有効期限、送信元アドレス制限とともに記述しています。スコープは読み取り、サーバー管理、請求、完全な制御を分離します。作成フローではシークレットを一度だけ表示し、適切に保護された検証用表現のみを保持すべきです。

リクエストを公開せずに監査する

有用な監査記録には、パスワードやリクエスト本文全体を保持することなく、キー識別子、ルート、時刻、結果を含めることができます。記録へのアクセスには依然として保護が必要です。機密性の高い運用履歴を無期限に保持するのではなく、保存期間とエクスポートを定義してください。

自動化ごとに個別の認証情報を付与してください

バックアップチェッカー、デプロイワーカー、請求連携は同じフルアクセスキーを共有すべきではありません。キーには用途に応じた名前を付け、最小のスコープを付与し、所有者を記録してください。想定されるグループはread、servers、billing、fullです。正確な操作マッピングは、APIが利用可能になった時点でテストする必要があります。

作成、保存、ローテーション

提案されたアカウントモデルでは最大10個の有効な鍵が許可されます。新しいシークレットは一度だけ表示し、その後は認証に必要なサーバー側の検証子のみを保持してください。クライアント側のコピーはシークレットマネージャーまたは保護されたサービス環境に保存してください。ローテーションは、代替鍵を導入し、依存するワーカーを確認してから古い鍵を取り消すことで行ってください。鍵を公開された URL やブラウザバンドルに置かないでください。

証拠ではなくアクセスを取り消してください

キーを無効化すると、過去の使用に関する限定的なセキュリティ記録は保持しつつ、以降のリクエストは停止されるべきです。認証情報が漏洩した可能性がある場合は、速やかに失効させ、影響を受けたリソースを調査し、関連するシークレットをすべて交換してください。キー一覧には、復元可能な平文のシークレットではなく、安全な識別子と最終使用のメタデータを表示すべきです。

もう少し明確に。