ステージングは本番ではない：独自のアクセス境界を与える

ステージングはテスト環境のように見えるが、そこにはコピーされた本番データベース、有効なメール認証情報、決済キーが置かれていることがある。その時点でタブのラベルは意味を失い、本当の問いは、この配備がどこまで到達でき、誰がそこに到達できるかである。入口の VPN はその問いに答えない。システムへの一つの経路を制限するだけで、システムが外向きに何をできるかについては何も語らないからである。対象から始めて外側へ進もう。

URL ではなく対象から始める

三つの対象は三つの異なる設計を生む。非公開のエンジニアリング環境には身元と経路が要る。顧客受け入れテストには顧客を表すアカウントが要る。公開デモには独自の制御を備えた意図的な公開が要る。対象を先に書き出すことで、プレビュー URL が静かに恒久化するというよくある漂流を防げる。レビューの他のすべてはその答えに依存する。

誰も対象を名指しできないなら、それは文書の穴ではなく最初の所見として扱う。

入口とその背後の面をたどる

与えられた URL を信じる前に名前を解決し、そのうえで管理用の経路を直接尋ねる。

dig +short staging.example.com
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/admin

追加のレコードはしばしば CDN や VPN の入口を迂回する直接オリジンのアドレスを明かし、意図した制御を任意のものにしてしまう。リダイレクトはアプリがどこにいると考えているかを示し、想定外のスキームやホスト名は追跡に値する。ありそうな管理経路を試すと、ページではなく拒否が返るべきである。認証なしの管理経路で 200 が返ることは、レビュー全体が探していた所見である。

環境が何を示すかではなく、何をできるかを確認する

ログインを要求するページでも、バックエンドの権限を伴って配信される。ワークロードがどの身元で動いているかを尋ね、それに付随するポリシーを読む。

aws sts get-caller-identity

その呼び出しは、環境が実際に使っているアカウントとプリンシパルを報告し、それが以後のすべての権限の問いの出発点になる。そこから、その身元がメールを送れるか、金を動かせるか、本番の秘密を読めるか、本番データを書けるかを確認する。共有の本番認証情報は範囲を絞ったステージングの身元に置き換え、存在するならベンダーのサンドボックスを優先する。実在のカードに請求できるテストアカウントは、別のホスト名を持つ本番システムである。

レビューが終わった後も境界を保つ

環境は一度の監査では守られない。担当者の交代を越えて残る所有権によって守られる。誰がアクセスを外し、テストデータを初期化し、配備を退役させるかを割り当て、プレビューには誰かが更新しなければならない有効期限を与える。隔離は、隔離されたものを保守している間だけ役に立つ。次のリリースの後で同じ経路を再確認しよう。機能フラグや新しい連携こそが、拒否された経路を開いた経路に変える道だからである。

許可される流れと拒否される流れの両方で設計を受け入れる。どちらも文書どおりに振る舞うなら境界は存在する。幸福な経路だけを試したなら、それは願望である。