キー

FortressFlag には 2 種類のキーがあり、意図的に正反対の性質を持っています。どちらがどちらかを知り、それぞれをそれにふさわしく扱うことが、知るべきことのほとんどです。

クライアントキー：ffc_、設計上公開

クライアントキーはクライアントプレーン、つまりあなたの iOS、Android、Web アプリを認証します。アプリのすべてのコピーの中に入って出荷され、バイナリやページソースを持つ誰もが読み出せます。設計はそれを前提としています。クライアントキーは：

• 読み取り専用で、1 つのプロジェクトと 1 つの環境にスコープされます
• 単一デバイスの評価済みの値しか取得できません。あなたのルールも、別のデバイスのデータも、管理 API の何も取得できません
• キーごと・デバイスごとにレート制限されます

だから、安心してアプリの設定に入れてください。あなたのクライアントキーを手にした誰かが知りうるのは、1 つの環境の flag キーです。それは、キーが入っていたバイナリからすでに読み出せたものです。ffc_ という接頭辞は、シークレットスキャナーがそれをクライアントキーとして認識し、誰も起こさないために存在します。

サーバーキー：ffs_、正真正銘の秘密

サーバーキーはサーバープレーンを認証します。あなた自身のバックエンドが、ローカル評価のために完全な ruleset（ターゲティングルールを含む）をダウンロードするためのものです。データベースのパスワードとまったく同じように扱ってください。

• シークレットマネージャーか環境変数に保存する
• クライアント側のコード、リポジトリ、ログには決して入れない
• ffs_ という接頭辞は、漏えいスキャナーがそれを誰かを呼び出すべき本物の秘密として分類するためにあります。ffc_ とは正反対で、だからこそ 2 つは接頭辞を共有しません

サーバーキーも 1 つのプロジェクトと 1 つの環境にスコープされ、読み取り専用で、管理 API には到達できません。しかし漏えい時の影響範囲は、flag キーだけでなくあなたのターゲティングルールです。扱いが異なるのはそのためです。

発行、1 回だけの表示、失効

キーは各プロジェクトの SDK キー画面から管理します（Admin と Owner が発行と失効を行い、Developer は一覧を見られます）。

• 発行は、1 つのプロジェクト + 環境に結び付いたキーを作成します。完全なキーが表示されるのは発行時の 1 回だけです。そのときにコピーしてください。以後、一覧には識別に足りる部分しか表示されません。「キーを再表示」はありません。再表示できるキーとは、盗まれうる形で保存されているキーだからです。
• 失効は、キーの次の使用から効きます。アプリのリリースもデプロイも不要です。そして切迫した状況でも安全に行えます。失効したキーを持つ SDK は、壊れるのではなくキャッシュにフォールバックします。

ローテーション

環境ごとに複数の稼働中のキーを持つことは正当で、それがローテーションの手順です。新しいキーを発行し、アプリやサーバーに展開し、それから古いキーを失効させます。ダウンタイムも、flag 配信の空白もなく、両方のキーが動く期間はあなたが制御できます。

次はどこへ

• flag がアプリに届くまで：これらのキーが開く 2 つのプレーン
• 環境とプロジェクト：キーが結び付くスコープ
• ロールと安全性：誰が発行と失効を行えるか