メインコンテンツにスキップ ナビゲーションにスキップ フッターにスキップ

設定ストレージ

パスキー、マスターパスワード、リカバリーコードによるアンロックに対応したクライアントサイド暗号化設定同期

設定ストレージ

設定ストレージは、デバイス間でCLI設定を同期します。設定はコンテンツ暗号化キー(CEK)を使ってデバイス上で暗号化され、サーバーがこのキーを持つことは一切ありません。これが何を守り、何を守らないかはセキュリティセクションで正確に説明します。

アンロック方法(キースロット)

ストアごとに1つのCEKがあり、LUKSのキースロットと同様に、アンロック方法ごとに個別にラップされます。どのスロットからでも同じキーを開くことができ、データを再暗号化することなくスロットの追加・削除が可能です:

方法内容備考
パスキーPRF拡張機能を備えたWebAuthnパスキー最も強力な選択肢。ハードウェアに紐づく
マスターパスワード任意に選ぶパスワードをPBKDF2-SHA256(60万回のイテレーション)でストレッチングPRF対応ハードウェアなしでも利用可能。ヘッドレスCLIエンロールメントも可能にする
リカバリーコード生成されるRC1-XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX形式のコード作成時に一度だけ表示される。安全な場所に保管すること

どの方法も同じパイプラインに合流します。スロットから得られるシークレットとサーバー側が保持するシークレットを組み合わせてCEKをアンラップします。どちらか一方だけでは不十分であり、スロットのシークレットがサーバーに届くことは一切ありません。3つの方法のうちマスターパスワードが最も弱く、サーバー側はパスワードの推測をオフラインで試すために必要な情報をすべて保持しているため、強力なパスワードが必須です。パスキーとリカバリーコードのスロットにはこの弱点がありません。

スロットはポータルの設定ストレージページで管理します。ハードウェアのみでのアンロックを望む組織は、パスキー必須ポリシーを有効にできます。このポリシーはストア全体でパスキー以外のスロットを拒否し、失効させます。

アンロックはデバイスごとに行われます。新しいデバイスでは一度アンロックすれば、以降の日常的なCLI操作(push/pull)はパスキーに触れることもパスワードを入力することもなく動作します。

前提条件

  • 二要素認証がアカウントで有効になっていること
  • パスキー方式の場合: FIDO2セキュリティキー(例: YubiKey)、iCloud Keychain、Google Password Manager、1Password、DashlaneなどPRFサポート付きのパスキープロバイダー
  • ブラウザ: Chrome 133+、Edge 133+、Firefox 130+、またはSafari 17+

PRFの要件はパスキースロットにのみ適用されます。マスターパスワードとリカバリーコードの方式は、サポートされているブラウザであればどれでも動作します。

セットアップ

  1. サイドバーの設定ストレージに移動し、設定ストレージをセットアップをクリックします
  2. 要件チェックリストがブラウザ、2FA、セッションのステータスを確認します
  3. 最初のロック解除方法を選び、設定ストアを作成 をクリックします。
    • パスキー: プロバイダーが PRF に対応している場合。セキュリティキーに 2 回タッチします（登録と暗号鍵の導出）。
    • マスターパスワード: どのブラウザーでも使えます。Bitwarden など PRF 非対応のパスキープロバイダーでも使えます。
    • 必要に応じて リカバリーコード: 一度だけ表示されるので、ストアを作成する前に保存してください。
  4. セットアップは完了です。CLI はロック解除用のシークレットを OS のキーリングに保存します。

パスキーは後から Config Storage ページで追加できます。認証器を紛失したり非対応だったりしても締め出されないよう、ロック解除方法は 2 つ以上用意してください。

PRFプロバイダー互換性

プロバイダーPRFサポートプラットフォーム
YubiKey / FIDO2セキュリティキー✅Windows 11、macOS、Linux
iCloud Keychain✅macOS 15+、iOS 18+
Google Password Manager✅Android
1Password✅Android、iOS
Dashlane✅クロスプラットフォーム
Bitwarden拡張機能❌代わりにマスターパスワードを使用してください
Windows Hello❌非対応

ヘッドレスCLIエンロールメント

ブラウザを持たないマシン(サーバー、CIランナー、エグゼキュータデーモンなど)は、マスターパスワード方式で既存のストアにエンロールできます:

rdc config remote enable --password
CLIリファレンス： rdc config remote enable

要件:

  • ポータル経由で既にプロビジョニングされたマスターパスワードスロット(プロビジョニング中はブラウザがキーを保持するため、このステップ自体はヘッドレスにはできません)
  • 呼び出しを認証するための、config:enrollスコープ付きのAPIトークン

エンロールメントは読み取り操作です。CLIはスロットの公開KDFパラメータとラップされたキーを取得し、パスワードのシークレットをローカルで導出して、デバイス上でCEKをアンラップします。これによりデバイスは設定を復号・同期できるようになりますが、ストア自体は変更されません。

有効化とオフライン読み取り

rdc config remote enable はアクティブな設定をストアに接続します。ストアが空の場合、有効化によって現在のローカル設定からストアが初期化されます: ローカルのリソースがストアの最初のバージョンとしてプッシュされ、その後プルバックしてラウンドトリップが正しく行われたことを確認します。ストアに既に内容がある場合、有効化は上書きするのではなく既存の内容と整合を取ります(本当の乖離がある場合は--forceを渡さない限り中断します)。

有効化されると、設定は完全な読み取りキャッシュを保持します。ローカル設定と同じ仕組みで保存時暗号化されるため、アカウントサーバーに到達できない場合でもストアを使い続けられます:

  • 読み取りはオフラインでも機能します。 キャッシュされた内容は、キャッシュされたバージョンとタイムスタンプ(cachedVersion / cachedAt)を付与した、古さに関する警告付きでstderrに表示されます。
  • 書き込みにはサーバーが必要で、到達できない場合はフェイルクローズします。 オフライン書き込みキューはありません: サーバーに到達できない書き込みはエラーになり、対象のサーバー名を示します。書き込みコマンドが成功していれば、その変更は必ずサーバー上にあります。
  • 2台のマシンからの同時編集は、プル・リプレイ・リプッシュ方式で解決されます。サーバーは置き換え対象のバージョンの上にしかプッシュを受け付けず、負けた側のプッシュは最新の内容の上でリプレイされるため、他所での同時編集が自分の変更を上書きすることはありません。
  • ローカル設定(remoteブロックを持たない設定)はこれらの影響を受けず、完全にオフラインで動作します。

同期される内容

各リポジトリのネットワークIDを含め、設定内のすべての項目が同期されます。ただし次のデバイスローカルなフィールドは例外です: schemaVersion、version、remote、encryption、renetPath、credentials.masterPasswordVerifier、およびログイン関連のフィールドであるaccount.accountServerとaccount.e2ePublicKey。ログイン・ログアウトはデバイスごとに行われます。

バージョンと復元

サーバーは各設定の直近50バージョンを保持します。

rdc config remote versions
rdc config remote restore <version>
CLIリファレンス： rdc config remote versions · rdc config remote restore

復元は、古い内容を現在のバージョンの上に新しいバージョンとして公開します。バージョン番号が後退することはありません。復元された内容は各デバイスの次回のプル時に反映され、復元操作は監査ログに記録されます。

キーローテーション

ストアのCEKをローテーションすると、新しい世代の下で再ラップされます:

  • ローテーションによりリカバリーコードは常に無効化されるため、ローテーション後に新しいコードを生成して保存してください
  • マスターパスワードスロットは、ローテーションウィザード中にパスワードを再入力した場合にのみ維持されます
  • 古い世代に取り残されたスロットは、わかりにくい復号エラーで失敗するのではなく、失効(stale)として報告されます
  • 他のメンバーの設定トークンは失効し、古い鍵を保持したままのデバイスにはrdc config remote enableでの再有効化が案内されます

メンバー管理

設定ストレージは組織ごとにスコープされます。メンバーはWebポータルで管理されます:

  • メンバーの表示: 設定ストレージ → メンバー
  • メンバーの追加: 現在はCLIのみ（Web UIは計画中）
  • メンバーの削除: メンバーページの削除ボタンをクリック（2FA + 再認証が必要）

安全ガードにより、最後のアクティブメンバーの削除や自分自身の削除が防止されます。

ストア内の設定はさらにチームごとにスコープされますが、このスコープはサーバー側のアクセス制御であり、暗号的な分離ではありません: 組織全体で1つのCEKがすべてのチームの設定を暗号化しており、どのチームをメンバーが読み取れるかはサーバーが強制します。

セキュリティ

保護されるもの。 保存された設定は、サーバーのストレージが侵害された場合や、受動的な運営者に対して機密性を保ちます。すべてのblobはそのストア、設定、チーム、バージョンに紐づけられているため、サーバーはある設定のblobを別のものにすり替えたり、検知されずに改ざんしたりすることはできません。

保護されないもの。 悪意のあるポータルコードを配信する運営者は、ブラウザ内でキーを読み取ることができます。また運営者は、まだ最新バージョンを見ていないデバイスに対して、その最新バージョンを渡さずに留め置くこともできます。

サーバーができることサーバーができないこと
設定ID、チーム、バージョン番号、タイムスタンプ、blobサイズ、設定がコミットするフィールド数とその型、クライアントのIPアドレスを見ることマシン名、リポジトリ名、ストレージ名(これらは秘匿化されています)や、設定の値を見ること
設定とその履歴を拒否・遅延・削除することある設定の内容を別のものとして提供したり、デバイスに検知されずに編集したりすること
まだ新しいバージョンを見ていないデバイスに古いバージョンを提供することCLIに、そのCLIが既に見たものより古いバージョンを提供すること(CLIはこれを拒否します)
マスターパスワードの推測をオフラインで試すことパスキーやリカバリーコードのスロットを開くこと

その他の保護:

  • 分割キー: 復号にはスロットシークレット(デバイス側)とサーバーシークレットの両方が必要です
  • 削除には知識が必要: 設定からコミット済みの値を削除するには、その値を知っていたことを証明する必要があるため、部分的なアクセス権しか持たないエージェントがフィールドを黙って削除することはできません
  • ローテーショントークン: すべてのリクエストが設定トークンをローテーションします。トークンは初回使用時のIPアドレスに紐づけられ、7日で失効します
  • 失効: メンバーを削除すると、そのメンバーのキースロットとトークンが同時に削除されます。既に取得済みの内容はそのデバイスに残りますが、CEKのローテーションによって、そのメンバーが保持していた鍵ではそれ以降のバージョンを開けなくなります

トラブルシューティング

エラー原因修正方法
PRF not supported認証器にPRF拡張機能がないYubiKey、iCloud Keychain、1Password、Dashlaneを使用するか、マスターパスワードスロットを追加してください
X25519 not supportedブラウザバージョンが古すぎるChrome 133+、Edge 133+、Firefox 130+、またはSafari 17+に更新してください
Already configured組織のストアが既に存在する/account/config-storageにアクセスして管理してください
Config storage not configuredサーバーにblobストレージがない管理者に連絡してR2/RustFSを設定してください
Token expired7日間アクティビティがない、またはマシンがネットワークを変更したログインを通じて自動的に更新されます。ログイン情報が保存されていない場合はrdc subscription loginまたはrdc config remote enableを実行してください
Config came back at an older versionサーバーが、このデバイスが既に見たものより古いコピーを返したローカルでは何も変更されていません。再試行し、問題が続く場合は報告してください
Cannot remove last memberストアが永久にロックされる先に別のメンバーを追加してください
Stale slotスロットが直近のキーローテーションより古いスロットを再登録してください(リカバリーコードはローテーションのたびに再生成が必要です)