常設キーゼロへ——移行のプレイブック
長期有効な秘密情報をゼロにするのはスイッチではなくプロジェクトだ。私たちが推奨する順序と、各フェーズの落とし穴をここに示す。
何かを動かす前に棚卸しする
見えないものは取り除けない。最初のフェーズは発見だ——すべての静的キー、サービスアカウント、共有シークレットを、それが何に使われ何に到達できるかとともに洗い出す。これは居心地が悪い。それでいい。
その数は誰もが思うより大きいと想定してほしい。『ほんの一握り』のキーしかないと最も自信を持っているチームが、たいてい何百件も抱えている。数字を公開すること。自信は可視性のあとについてくる。
チーム単位ではなく被害範囲単位で切り替える
アルファベット順や手を挙げた人から移行してはいけない。被害範囲順に移行する——資金を動かせる、または機密データを読める認証情報を最初にする。漏洩したときに実際に痛手となるのはそれらだからだ。
それぞれについて、常設キーをオンデマンドのスコープ限定発行に置き換える。エージェントが要求し、数分の認証情報を受け取り、静的キーはローテーションではなく削除される。削除こそ人々が省略しがちな部分だ。省略してはいけない。
ゼロを証明する
目標状態は常設キーゼロであり、それを示せなければならない。発行が一元化されれば、『長期有効な認証情報が何件存在するか』は、肩をすくめる調査ではなく、数字が返るクエリになる。
その数字は監査人が見られるダッシュボードに載るべきだ。主張で終わる移行は静かに後退する移行だ。実際の数字で終わる移行は誠実であり続ける。
- #migration
- #secrets
- #rollout
More field notes
短期認証情報の実践
キーは失効すべきだと誰もが同意する。それから誰かがTTLを1年に設定して、何も壊れないようにする。実際のワークロードに耐える、数分単位の認証情報を作る方法をここに示す。
Priya Nandakumar · Head of Platform
読了時間 7分
デプロイ時ではなく実行時にポリシーを書く
デプロイ時に固めたアクセス判断は、それが重要になる頃には古くなっている。私たちはエージェントが行動する瞬間にポリシーグラフを評価する。それが何をもたらすかをここに示す。
Priya Nandakumar · Head of Platform
読了時間 6分