ロールと安全性
FortressFlag には 4 つのロールと、1 つの考えを軸に設計された本番環境の安全装置が備わっています。非本番環境で速く動くことは苦もなくできるべきで、本番環境を変えることには適切なロールか、もう 1 人の人が必要であるべきだ、という考えです。
4 つのロール
Section titled “4 つのロール”| Viewer | Developer | Admin | Owner | |
|---|---|---|---|---|
| flag とチームを見る | ✓ | ✓ | ✓ | ✓ |
| 非本番環境を変更する | ✓ | ✓ | ✓ | |
| 本番環境の変更を提案・承認する | ✓ | ✓ | ✓ | |
| 本番環境を直接変更する | ✓ | ✓ | ||
| SDK キーを見る | ✓ | ✓ | ✓ | |
| SDK キーを発行・失効する | ✓ | ✓ | ||
| チーム、プロジェクト、環境を管理する | ✓ | ✓ | ||
| 監査ログを読む・エクスポートする | ✓ | ✓ | ||
| 請求、使用状況、組織ポリシー | ✓ |
表には載せられない注記をいくつか。
- Viewer と Developer は、付与されたプロジェクトだけを見ます。
- 誰も自分より上のロールを付与できません。Admin は Developer を招待できますが、Owner は招待できません。
- 完全なマトリクスはアプリ内で公開されているので、ダッシュボードで見えるものは常にサーバーが実際に強制しているものを反映しています。
本番環境の変更：もう一組の目
Section titled “本番環境の変更：もう一組の目”Developer は本番クラスの環境に直接書き込めません。しかし Admin を待つ必要もありません。Developer は変更（切り替え、ルールの編集）を提案し、もう 1 人の人（別の Developer 以上）がそれをレビューして承認すると、それが適用されます。
この形は意図的なもので、購入者として理解しておく価値があります。
- これはピアレビューであって、階層レビューではありません。2 人の Developer が一緒になれば本番環境を変えられます。要点は、Admin 未満の 1 人だけで本番環境を変えることができない、ということです。
- 自己承認は、例外なく拒否されます。ロールではなく人単位で。Admin であっても自分の提案は承認できません。
- 監査ログは、適用されたすべての提案について両者の名前を記録します。誰が提案し、誰が承認したか。
Admin と Owner は引き続き本番環境に直接書き込めます。提案の経路は、チームの残りのメンバーに安全な入口を用意するためにあります。
スケジュールされた変更
Section titled “スケジュールされた変更”boolean flag の状態はスケジュールできます。金曜 09:00 UTC に holiday-banner をオンにする、のように。変更はすべての読み手に対して、選んだ時刻ちょうどに効きます。そして環境をスケジュールするには、いま書き込むのと同じ権限が必要です。スケジュールとはタイムスタンプ付きの書き込みにすぎず、同じ基準で扱われます。
すべての状態変更は追記専用の監査ログに記録されます。誰が、何を、いつ、どこから、そして変更前後の値。Admin と Owner はアプリ内でフィルターを使って閲覧し、CSV としてエクスポートできます。インシデントレビュー、コンプライアンスの要請、監査人のために。手順は監査ログをエクスポートするを参照してください。
- 本番環境の変更に承認を必須にする：フローを手順ごとに
- 変更をスケジュールする：あとで切り替わるよう設定する
- チームを招待する：ロールは招待の時点で割り当てる