秘密が効くかは、確かめる側が決める — 入れ替えと失効

秘密が漏れたら、まず無効化かローテーション。これは正しい順序で、GitHub Docs も as a first step you need to revoke and/or rotate that secret と書いています。

では、替えた瞬間に何が止まるのか。答えは確かめる側がいつ確かめるかで決まります。パスワードの変更は、確かめる側が照合に使う記録を書き換える操作です。照合が起きない場面には届きません。

PostgreSQL の CREATE ROLE は LOGIN / NOLOGIN をこう説明します。

These clauses determine whether a role is allowed to log in; that is, whether the role can be given as the initial session authorization name during client connection.

判定は during client connection、接続を開くときです。文書に「パスワード変更は既存のセッションに影響しない」と明示した文は見つけていません。言えるのは、判定が接続時と書かれていることと、次の実演で開いた接続が続いたことまでです。

定期の入れ替えでは、書き換えが確かめる側に届くまでの時間差が問題になります。AWS Secrets Manager は2つの方式を書き分けています。

単一ユーザー方式の節:

When the secret rotates, open database connections are not dropped. While rotation is happening, there is a short period of time between when the password in the database changes and when the secret is updated. During this time, there is a low risk of the database denying calls that use the rotated credentials.

開いた接続が落ちないことは、ここでは性質として書かれています。一方、秘密の更新が追いつくまでの短い間は、新しい接続が拒まれうる。

交互ユーザー方式の節は、入れ替えのたびにどちらのユーザーのパスワードを替えるかを交互にし(alternates which user's password it updates)、こう書きます。

After rotation, both user and user_clone credentials are valid.

新旧が重なる期間を、2人のユーザーで作っています。裏返すと、入れ替え直後もそれまで配っていた資格情報が有効なまま残ります。定期の入れ替えと、漏えい時の失効は別の操作として考える必要があります(教材側の読み)。

鍵でも同じ形です。NIST SP 800-57 Part 1 Rev.5 §5.3.4:

The key pair’s originator and recipient-usage periods typically begin at the same time, but the recipient-usage period may extend beyond the originator-usage period.

署名をやめた後も、検証側はしばらく古い公開鍵で検証してよい。入れ替え後も旧鍵を復号用に保持する、と既存クイズが教えるのと同じ向きです。