こう 聞かれます
- 「本番の
鍵や 秘密の 値を、 どう 管理し、 漏れたら どうしますか」 - 「DB の
パスワードを、 サービスを 止めずに 替えるには、 どうしますか」 - 「公開の
リポジトリに 鍵を push してしまいました。 履歴から 消せば 大丈夫ですか」 (裏から聞く形)
面接官が 見ている点
- 秘密の
値の 置き場、 読める 人、 使える 期間を、 決まった 形で 管理しているか - 鍵を
替える ことを、 特別な 日の 作業ではなく、 いつでも できる 作業に しているか - 漏れた
とき、 消すより 先に 無効に する、という 順番を 分かっているか - 漏れた
あと、 使われた 跡を 調べる ところまで 考えているか
短い答え
- 秘密の
値は 専用の 置き場 (シークレットの 管理の 仕組み) に 集め、 読める 人と 仕組みを、 要る 物だけに 絞ります。 誰が いつ 読んだかも 記録します。 - できるだけ短い
期間で 切れる 鍵を 使い、 長く 使う 鍵は、 新旧の 両方が 効く 期間を 作って、 止めずに 入れ替えられるように して おきます。 - 漏れたら、
まず鍵を 無効に して 新しい 鍵に 替えます。 その あと、 漏れていた 間に 使われた 跡を 記録で 調べます。 履歴から 消すのは 最後で、 それだけでは 足りません。
この
少し 詳しい答え
置き場と、 読める人を絞る
秘密の
読める
短く 切れる鍵を使う
同じ鍵を
止めずに 入れ替える
長く
- 新しい
鍵を 作る。 古い 鍵もまだ 効く ままにしておく - アプリが
新しい 鍵を 読むように して、 全部の 台に 行き渡らせる - 古い
鍵が 使われていない ことを 記録で確かめる - 古い鍵を
無効にする
新旧の
漏れた ときの順番
漏れた
- 無効に
して替える いちばん先です。 公開の 場所に 出た鍵は、 すぐに 拾われて 使われる ことがあります - 使われた
跡を調べる 漏れていた 間に、 その鍵で 何が 読まれ、 何が 作られたかを 記録で 確かめます - 消すリポジトリの
履歴などから 消します。 ただし、 すでに 写し取られた 物は 消せないので、 1 の 代わりには なりません - 再発を防ぐ鍵を
含む変更を push の 前に 止める 検査を 入れる など、 仕組みで防ぎます
話すときは、
よく ある間違い
- 履歴から
消して 終わりにする 写し取られた 鍵は 使えるままです。 先に 無効にします - 古い鍵を
すぐ 無効に してから、 新しい鍵を配る 配り 終えるまでの 間、 サービスが 止まります。 新旧を重ねます - 全員が
本番の 鍵を読める 漏れる 道が 増え、 誰が 漏らしたかも 追えません。 要る 人と 仕組みだけにします - 入れ替えの
手順を、 漏れた ときに 初めて考える 慌てて 手順を 誤ります。 ふだんから 同じ 手順で 替えておきます
深掘りの問い
- 「環境変数に
入れておけば 安全ですか」 コードに 書くよりは よいが、 それだけでは 読める 範囲や 入れ替えの 記録が 無いので、 置き場から 読む形に する、と答えます - 「鍵が
漏れたか どうかに、 どう 気づきますか」鍵を 含む変更の 検査、 ふだんと 違う 場所や 時刻からの 使われ方の 記録で 気づく、と答えます - 「DB の
パスワードを 替える 間、 接続は どうなりますか」 新旧の 両方が 効く 期間を 作り、 接続を 張り直していく、と答えます
