セキュリティ

このアプリは、実在する Mac 上の実サービスを、ときには地球の裏側から起動・停止できます。それが理にかなうのは、盗まれた端末・盗聴されたネットワーク・推測されたトークンのどれもが、そのままではサーバの制御に変わらない場合だけです。FrontierStack は、それらのどれも単独では不十分になるよう作られています。本章ではその層を解説し、なぜ Cloudflare トンネル越しにどこからでも安全に Mac へ到達できるのかを説明します。

3.1すべてのリクエストに署名する

最も強力な保護は目に見えません。この端末はペアリング時に自分専用の秘密鍵を生成し、iOS の Keychain に保存しました — 鍵は端末から出ることはなく、このアプリでさえ平文として読み出せません。アプリが Mac に送るすべてのリクエストは、その鍵で署名されます。Mac は承認した端末を公開鍵ごとに許可リストとして保持し、リクエストのたびに、送信元を名乗る端末に対して署名を検証します。

これが FS1 端末ごとのモデルです。Ed25519 署名を用い、署名付きリクエストにはタイムスタンプと一回限りのナンスも含まれるため、捕捉されたリクエストは数秒後でも再送できません。実用上の肝心な点はこうです — 旧来のアプリが頼るような共有秘密、すなわちベアラートークン単体では、ここでは何も制御できません。この端末の秘密鍵がなければ、コピーされたトークンは無力です。

3.2暗号化・ピン留めされた接続

署名は誰が話しているかを証明し、暗号化は何を話すかを守ります。Mac が HTTPS アドレスを広告すると、このアプリは通常の安全な接続と同じく TLS で通信します。ただし一ひねりあります — Mac は自ら生成した自己署名証明書を使うため、その正当性を保証する公的な認証局が存在しません。

代わりに、アプリは証明書のピン留めを使います。ペアリング用の QR コードには、Mac の証明書の正確なフィンガープリントが含まれていました。それ以降、アプリはそのフィンガープリントと完全に一致する証明書を提示する接続だけを受け入れます。中間に割り込んで自前の証明書を差し出す攻撃者は、たとえ「有効な」証明書であっても、ペアリング時にピン留めしたものと一致しないため拒否されます。

3.3どこからでも安全な理由

この 2 つを合わせれば、公開経路 — たとえば Cloudflare トンネル — 越しに Mac へ到達することが、無謀ではなく安全である理由が見えてきます。トンネルは通信を運ぶだけで、偽造はできません。

• 接続は暗号化されピン留めされているため、トンネル（および経路上の誰か）が見るのは、なりすませない証明書宛ての暗号文だけです。
• すべてのリクエストはこの端末の鍵で署名されているため、Mac に届いた何かがあっても、Mac が受け入れるコマンドは発行できません。
• 再送はリクエストごとのタイムスタンプとナンスで防がれるため、捕捉したリクエストの再送は失敗します。

公開経路を存在させるかどうかは Mac が決め、いつでも閉じられます。ここでは何一つネットワークが私的であることに依存していません — 保護は各リクエストとともに運ばれます。

3.4アプリロック

誰かがロックされていないあなたの端末を手に取るだけなら、ネットワークのセキュリティは役に立ちません。アプリロックがその隙を塞ぎます。設定でパスコードを有効にすると、以降アプリは入力するまでロックされ、ワンタップ解除のために Face ID または Touch ID を追加できます。アプリは離れるたびに再ロックします — 別のアプリに切り替えたり端末をロックしたりすれば、戻ったときに再び尋ねられます。

パスコード自体は保存されません。端末で設定したパスコードは、固有のソルトと、意図的に低速な PBKDF2-HMAC-SHA256 検証値によって端末の Keychain 内で保護されます。失敗が続くと待ち時間も段階的に延びます。生体認証は iOS が処理し、アプリには可否だけを伝えます。

Mac のロックのミラーリング。Mac 自体にアプリロックのパスワードが設定されている場合、このアプリはペアリング時にそれを採用し、同じパスワードを要求します。パスワードも Mac の再利用可能な検証値も送られません。端末が受け取るのは、この端末のペアリング身元に暗号学的に結び付けられた低速な検証値です。ミラーリング中は端末側でロックを変更・解除できず、Mac 側で変更します。Face ID／Touch ID は端末ローカルの利便機能として残ります。

アプリがフォアグラウンドを離れるたび、App Lock を有効にしていない場合でも、アプリスイッチャーのスナップショットをデータのないプライバシー画面で覆います。ライブな直接 SSH セッションはバックグラウンド移行またはロック時に閉じ、自動再接続しません。戻ってロック解除後、意図的に接続し直します。

3.5この端末に許可された操作

認証が「これは本当に私の端末か？」に答えるのに対し、権限スコープは「ではどこまでできるか？」に答えます。その判断はここではなく Mac にあります。ペアリング済みの各端末には 4 つのレベル — 読み取り専用・再起動・操作・フルコントロール — のいずれかが割り当てられ、Mac が署名付きリクエストごとにそれを適用します。常に持ち歩く端末は、完全にペアリングされていても低いレベルに安全に留められます。

ボタンが無効だったり操作が拒否されたりするのは、この端末のレベルがそれを許していないからです — Mac で引き上げるか、すでに権限のある端末を使ってください。4 つのレベルとそれぞれが解除する範囲は ペアリング にまとめてあります。

レベルと並んで 2 つの許可があり、どちらも Mac 側で設定します。AI 管理者を許可（既定はオン）は、この電話が AI タブをそもそも使えるかを決めます — 一方の端末にはチャットを許可しつつ別の端末をブロックできます。リモートシェルを許可はフルコントロールのときのみ表示され、既定はオフです。これはこの端末が Shell タブを開き、サーバへ直接到達するために必要です。どちらもバイパスではありません：AI を許可していても、変更にはフルコントロールの「Allow changes」とアプリのロック解除が依然として必要です。

3.6Mac が利用できない間の権限

オフラインになっても、端末が無制限のコントローラに変わることはありません。最後の署名済みインベントリには経過時間を表示します。直接到達性チェックが接続するのは、保存済み SSH エンドポイントと、FrontierStack が観測済みサービスから判断した少数の標準ポートだけです。範囲スキャンやプローブのダウンロードは行いません。直接 SSH は端末専用の 2 本目の Ed25519 鍵を使い、保存済みサーバ身元が欠けている、または変わった場合は拒否します。

Mac がオフラインの間も、サービスの開始・停止・再起動・リロード要求を準備できます。要求はこの端末上で署名され、最長 4 時間で期限切れになり、Mac が戻った後に More → Queued Actions を開いて正確な対象を確認し、明示的に送信するまで何も実行しません。Mac は署名・期限・権限・App Lock を再検証し、受け入れた要求を 1 回だけ実行します。スクリプト、シェルコマンド、サーバ再起動、Fleet Run、デバイス電源、アクセス変更はこのキューでは受け付けません。

3.7端末を失くしたとき

各端末が自分の鍵を持つため、1 台を切り離すのに他は一切変更する必要がありません。Mac でセキュリティ ▸ ペアリング済みモバイル端末を開き、名前で端末を探して失効させます。その鍵は直ちに許可リストから削除されます — 次にその端末が Mac へ通信を試みた瞬間、署名は拒否されます。他の端末はそのまま動き続けます。

Mac 上での失効が決定的な手順です — 端末そのものに手が届かなくても、その端末を止められます。まだ手元にある端末で この端末のペアリング解除を実行すると、まず Mac に端末の失効、登録済み直接 SSH 鍵の削除、プッシュアクセスの停止を依頼します。Mac が後始末を確認できない場合だけ ローカルで忘れる選択肢が現れます。このフォールバックを使った後は、Mac の Paired Devices で失効を完了してください。

本当に手元を離れた電話には、Mac がより強力なワンクリック操作 紛失した電話を保護を用意しています。鍵の失効に加えて、その端末の古いキュー操作を直ちに取り消し、開いているセッションを閉じ、直接アクセス用にサーバへ導入した SSH 鍵を削除し、プッシュ通知を無効化します。その時点でオフラインのサーバは一覧に残るので、復帰後に鍵の削除を完了できます。