2026 クラウド Mac：バスション（ジャンプホスト）と直接 SSH のアーキテクチャ判断ガイド

分散チームを Apple Silicon のクラウド Mac に接続するセキュリティ設計では、長期的に使える二つのパターンが典型です。一つは SSH をバスション（ジャンプホスト）で終端し転送する方式、もう一つはネットワーク制御を徹底したうえで各 Mac に直接 SSH する方式です。2026 年時点の推奨は単一ではありません。ログと多要素認証を一点に集約したいならバスションが有利で、レイテンシや構成の単純さ、あるいはプロバイダ管理のエッジで攻撃面がすでに絞られているなら直接アクセスが現実的です。本稿ではスコアリング用マトリクス、直接経路向け六項目のチェックリスト、バスション展開の五段階、MacLogin 各リージョンを想定したレイテンシ表、実監査で出る FAQ をまとめます。

ゼロトラスト VPN やエージェント経由で SSH を同じデータプレーンに載せる構成も、機能的にはバスションに近いです。調達や説明責任の観点では別物として扱われることがあるため、図だけでなく「誰がどの経路で認証するか」を文章で残すことが重要です。

誰が「バスション vs 直接 SSH」を文書化すべきか

本番ビルドホストに複数名が触る組織なら、選択を設計書に落としレビューすべきです。単一の Mac mini M4 から始めるスタートアップは、鍵運用を厳格化した直接 SSH でもしばらく持ちこたえます。金融やヘルスケアではバスションでセッション メタデータを集約する方針が一般的です。本決定は鍵ライフサイクルとセットで読んでください。SSH 鍵ローテーションと 2FA ガイドでは Mac 側のユーザー鍵を継続的に更新する手順を説明しています。バスションはその義務を消しません。

マルチリージョン運用では、ファイアウォール変更の承認者と authorized_keys の最終責任者を明確にしてください。直接 SSH は RACI が曖昧だと各ホストのローカル許可リストが崩れやすく、バスションはパッチウィンドウの計画が甘いと全員がログイン不能になります。

インターネット経由の「フラット」SSH が招く痛み

• 認証のばらつき：オンボーディングの速さ優先で広いレンジに 22 番を開けたままになる。
• ログの不統一：macOS ごとに syslog の切り方が違い、SIEM で相関しづらい。
• 請負の入れ替わり：一人外すたびに多数の authorized_keys を編集し、バスション ACL 一箇所では済まない。
• ブラスト半径：流出したノート PC の長期鍵から、署名用証明書の載ったビルド機へ直行できる。

バスションと直接 SSH：判断マトリクス

コンプライアンス層ごとに行を採点し、多く勝つ列を起点にペネトレで裏取りしてください。

観点	バスション / ジャンプ	直接 SSH + ネットワーク制御
集中 MFA	強い——同一ホストでアイデンティティを終端	ホスト単位の PAM または VPN 側 MFA が必要
運用レイテンシ	1 ホップ増（多くは +8〜35 ms RTT）	理論上ホストまで最短
セッション録画	バスション側で標準化しやすい	各 macOS に計装が必要
コストと保守	小さな常時稼働 VM が追加	ジャンプ代はゼロだが FW ルール管理が増える
MacLogin マルチリージョン	ゾーンごと、または共有グローバル	HK/JP/KR/SG/US ノード単位の許可リスト

クラウド Mac への直接 SSH：六ステップ・チェックリスト

1. パスワード無効化：鍵を確認したうえで PasswordAuthentication no。
2. ユーザーの絞り込み：AllowUsers 等で実人数に合わせる。
3. クラウド手前の FW：オフィス出口と CI ランナーの CIDR のみ。ランブックに記載。
4. 認証試行の抑制：MaxAuthTries を下げ、方針が許せば fail2ban 系も。
5. 月次の鍵棚卸し：フィンガープリント台帳。請負離脱は 24 時間以内 に削除。
6. 地理別 RTT 検証：インド・欧州・米国などから、選んだ MacLogin リージョンへ実測。

クラウド Mac へのデータパス上のバスション：五段階ロールアウト

1. ホップのサイジング：同時 SSH が 50 未満かつポートフォワード乱用がなければ 2 vCPU Linux で足りることが多い。
2. バスションで MFA 強制：管理者はハードウェアキー、一般は TOTP など。
3. ProxyJump 設定：ssh -J bastion user@maclogin-host または ~/.ssh/config の ProxyJump。
4. 下流の制限：クラウド Mac の sshd は 22 をバスション帯のみに信頼させる。
5. ログ転送：SOC2 類の証跡なら SIEM へ、90 日以上 保持を目安に。

レイテンシと MacLogin ノードの組み合わせ

下表はクリーンな ISP 経路を想定した目安です。実際はオフィスから mtr で測定してください。Mac が米国、バスションがシンガポールのとき、累積 RTT は 140〜190 ms 増えることもあります。シェル操作は許容でも大きな rsync には効きます。

ユーザー所在地（例）	推奨 MacLogin リージョン	RTT の目安
大中華圏	香港またはシンガポール	15〜55 ms
東京 / ソウル	日本または韓国	8〜35 ms
米国西海岸	米国	12〜40 ms

トポロジを確定する前に 料金ページ でキャパシティとリージョンを確認してください。

監査で見られるのは「成功した認証チェーンが自然人と時刻に結びつくか」です。バスションは sshd ログが一つのホスト名に集まり説明しやすい一方、直接 SSH でも macOS の認証イベントを企業スキーマで SIEM に送れば同等に達成できます。後者は「あとでやる」で永遠に未完になりがちです。バスションのベースライン硬化（MFA・バックアップ・復旧訓練）に約 40 時間、10 台の直接 SSH で FW ドリフト検知と四半期鍵レビューまで含めると 80 時間 を超えることも珍しくありません。

夜間 CI も同じ経路に載せるか別途短寿命証明書を使うかを決めてください。長寿命の CI 鍵だけバスションを迂回すると、避けたかったブラスト半径が戻ります。

よくある質問

バスションと直接の非常用を併用できる？ 可能です。ハードウェアキー限定・極窄の ACL で四半期レビュー。

SSH トンネルはバスションの代わり？ 一部。WireGuard 等は公開面を減らしますが、終端でのポリシーとログは依然必要。

接続ヘルプは？ MacLogin ヘルプ を参照。

自動化もバスション経由にすべき？ はい。人間と同じ制御面を通すか、IdP 発行の短命証明書を使う。長寿命 CI 鍵のバイパスはリスクの再導入です。

Mac mini M4 on MacLogin が両方の SSH 設計に合う理由

Apple Silicon の Mac mini M4 はアイドル電力を抑えつつ OpenSSH 負荷に耐え、多重化された長時間セッション向きです。バスション越しの scp や git にも統合メモリが効きます。香港・日本・韓国・シンガポール・米国のノードでデータ近接とレイテンシを両立できます。

環境ごとに専用ホストを借りると、バスション経由の本番とサンドボックス鍵を分離しやすくなります。CPU とメモリは 料金ページ で調整し、VNC 方針は SSH と分けて文書化すると監査がスムーズです。