Cloudflare公式資料では、Tunnelはコネクターから外向きの接続を確立します。この方式でリモートMacへのSSH経路を構成すれば、Mac側の受信ポートをインターネットへ公開せずに接続できます。ただし、TunnelやCloudflare AccessはmacOSのユーザー権限やCI資格情報を代わりに管理しません。まず対話型の運用接続と無人CIを分けて設計し、権限と復旧手順まで確認してから本番投入します（Tunnelの接続方式）。
対象読者
企業IT担当者：遠隔地の社員が使うMacのSSH接続境界を設計する方。
プラットフォームエンジニア：開発者の接続とCIサービスアカウントを分離する方。
セキュリティ担当者：認証ポリシー、Mac側の権限、監査、アクセス撤回を確認する方。
| 導入段階 | 今週の推奨作業 | 次へ進む条件 |
|---|---|---|
| 接続前 | 対象Mac、Tunnelの稼働場所、利用者、CIジョブを棚卸しします。 | 各接続者と用途に責任者が割り当てられていること。 |
| 構築・初回接続 | Tunnel経路、Access認証、macOS SSHアカウントを別々に設定・検証します。 | 対話型接続とCI接続の認証経路を区別できること。 |
| 本番判定 | 失効、切断、再起動、権限変更を演習し、結果と回退手順を記録します。 | 監査証跡と復旧担当が明確であること。 |
接続前に分けて考える認証と権限
まず、SSH接続を一つの認証処理として扱わず、経路、利用者の本人確認、Mac上の操作権限に分解します。Tunnelで外向きの接続を作れても、MacのSSHサービスが停止している、または接続先アカウントの権限が広すぎるといった問題は残ります。
開発者またはCI
│
├─ Cloudflare Access：接続者・接続条件の確認
│
└─ cloudflared / 対応する接続方式
│
Cloudflare Tunnel
│
macOSのSSHサービス
│
Mac上のユーザーと権限
Cloudflare Accessのポリシーは、誰にどのアプリケーションへのアクセスを許可するかを定めるものです。Macのローカルアカウントが使えるか、管理者権限を持つかという判定とは分けて記録します（Accessポリシーの設定項目）。
Appleの案内に沿ってMacの「リモートログイン」を確認し、SSHを受け付けるユーザーを把握してください（Macでリモートログインを有効にする方法）。人員変更のたびに誰がAccessポリシー、Macアカウント、鍵や証明書を更新・撤回するのかも、構築前に決めておきます。
| 接続方式 | 主な用途 | 設計時に確認する点 |
|---|---|---|
| クライアントのcloudflaredを使うSSH | 開発者の対話型ターミナル接続 | クライアント設定、Access認証、Mac側ユーザーの三つをそれぞれ確認します。 |
| Infrastructure Accessを使うSSH | 対象やユーザー名、監査要件を細かく扱いたい接続 | 機能、認証の前提、ログの範囲を公式資料で照合します。 |
| ブラウザー上のSSHターミナル | クライアントソフトの配布を避けたい場合 | ブラウザー方式の制限が、必要な操作や運用に合うか確認します。 |
これらは同じ方式の別名ではありません。たとえばクライアント設定を配布できる組織と、ブラウザー内の接続を求める組織では、端末要件や操作上の制約が異なります。ブラウザーターミナルの対応範囲は、Cloudflareのブラウザーレンダリング資料で必要な操作と照合してください。
Tunnelを配置し、Macまでの経路を作る
Tunnelの実行場所は、接続先MacとSSHサービスにネットワーク上で到達できる位置にします。Mac本体で動かす構成と、Macへ到達できる別の端末で動かす構成があり、後者ではその端末から対象Macまでの経路も管理対象になります。
CloudflareのSSH手順を参照し、選んだホスト名から正しい接続先へルーティングされるよう設定します（SSHクライアント認証とルーティングの手順）。Mac上でTunnelをサービスとして起動する場合は、設定ファイルの位置だけでなく、サービスの実行ユーザーや実行環境から設定を読み込めるかを確認してください（macOSでTunnelをサービスとして実行する方法）。
初回接続には、たとえば次のようなクライアント設定を使います。ホスト名やユーザー名は、組織の実際の設定値に置き換えます。
Host mac-build
HostName <設定済みの接続先ホスト名>
User <Mac上のSSHユーザー>
ProxyCommand cloudflared access ssh --hostname %h
ssh mac-build
接続できないときは、まずTunnelの状態だけで原因を決めないでください。クライアントからTunnelまでの認証、TunnelからMacまでのルーティング、Macのリモートログイン、ローカルユーザー認証の順に切り分けると、ネットワーク経路の問題とアカウント権限の問題を混同しにくくなります。
Accessの許可とMacのSSH権限を個別に確認する
初回接続では、Accessの認証に成功したことをMacへのログイン成功と同一視しないでください。Accessの認証ログには、認証を追跡するための情報が記録されますが、それだけでMac上のコマンド実行やユーザー権限まで確認できるわけではありません（Access認証ログの項目）。
社員ごとに対象Macを分ける場合は、Access側で対象アプリケーションや利用者の条件を設計し、Mac側でも使えるアカウントと権限を絞ります。SSHの対象やユーザー名をより細かく制御したい場合は、Infrastructure AccessのSSH機能が組織の要件を満たすかを評価し、一般的なAccess認証の範囲から推測しないようにします。
チーム共用のMacでは、特に次の境界を記録します。
- Accessポリシーで許可される人と接続先。
- macOS側で有効なSSHユーザーと管理者権限の有無。
- 退職・異動時に無効化するアカウント、鍵、証明書、ポリシー。
- 接続ログとMac上の操作記録の保管場所および確認担当。
CIは対話型接続と分離して試験する
CIでのSSH接続は、開発者の対話型ログインとは別に構成します。人がブラウザーやクライアントで完了する認証フローを、そのまま無人ジョブで使えると仮定せず、CI専用アカウントと資格情報の保管・撤回方法を定めてください。
非本番のパイプラインで、チームが決めた認証方法を使い、接続から必要なビルド工程までを確認します。開発者個人の秘密鍵をRunnerへコピーする運用は避け、資格情報の所有者、更新担当、漏えい時の無効化手順を記録します。
また、SSHが通っただけではCI環境の検収は完了しません。CI Agentの稼働、ビルドの完了、署名を伴う公開工程の成功は、それぞれ別の結果として記録します。Infrastructure Accessを候補にする場合も、無人処理に必要な認証と監査要件が実際の構成で成立するかを先に試験します。
本番投入前に可否を決める検収項目
以下を実行し、結果、担当者、回退方法を証跡として残します。アクセスを取り消した後に新規接続できないことや、Tunnelの切断時にどの担当者が復旧するかを、机上の想定だけでなく実際の環境で確認してください。
- [ ] Tunnelの稼働場所から対象MacのSSHサービスへ到達できることを確認します。
- [ ] Accessで許可されない利用者が接続できず、許可された利用者もMac上の権限を越えられないことを確認します。
- [ ] macOSアカウントの権限変更を行い、既存ポリシーとの組み合わせを再確認します。
- [ ] 利用者のAccess権限やSSH資格情報を撤回し、新たな接続が拒否されることを確認します。
- [ ] Tunnel切断とMac再起動を演習し、検知、担当者への連絡、復旧手順、記録を確認します。
- [ ] 非本番CIで、SSH接続、Agent稼働、ビルド、署名工程を別々に判定します。
- [ ] 設定変更を戻す手順と、緊急時にアクセスを止める責任者を記録します。
| 判定 | 条件 | 次の対応 |
|---|---|---|
| 承認 | 対話型とCIの認証が分離され、権限確認、撤回、復旧の演習記録がそろっている | 対象範囲を限定して本番運用へ進みます。 |
| 期限付き是正 | 接続は成立するが、ログ確認や撤回担当などに未決事項がある | 担当者と是正期限を決め、完了するまで利用範囲を制限します。 |
| 対話型のみ | 人の認証は検証済みだが、無人CIの認証・資格情報が未検証である | CI用途には使わず、対話型保守に限って運用します。 |
| 不承認 | Mac側の権限、切断時の復旧、または緊急撤回を検証できない | 接続を本番に許可せず、設計を見直します。 |
可用率や復旧時間は、対象環境で計測・確認できた証拠がない限り、導入判断の保証値として扱わないでください。Tunnelの稼働状況だけでなく、Macの再起動後にSSHサービスとCI Agentがどう戻るかまで、検収記録に含めます。
よくある質問
TunnelだけでMacへの接続を完結できますか
Tunnelはネットワーク経路を提供しますが、MacのSSHサービス、ローカルユーザー、認証・権限設定は別途必要です。Macに向けた受信ポートを公開しない構成を目指す場合も、Tunnelの実行場所からMacへ到達できるかを確認します。
Accessの利用者を追加すればMacのユーザーも作成されますか
作成されません。Accessの許可対象とmacOSのSSHユーザーは別に管理し、利用開始時と撤回時の担当者・手順を定義します。退職者のAccess権限だけを外しても、残存するMacアカウントや鍵があれば、別の経路からの利用リスクが残ります。
社員ごとに別のMacへ接続先を限定できますか
Accessポリシーで対象を分ける設計に加え、Mac側のアカウント権限も対象ごとに整理します。ユーザー名や対象インフラに対する細かな制御が必要なら、Infrastructure Accessの機能と監査範囲を確認してから方式を決定します。
CIの無人SSHにも同じ設定を使えますか
同じ接続経路を利用できる場合でも、対話型の認証が無人ジョブで成立するとは限りません。CI専用の認証方法、資格情報の保存先、失効手順を設計し、非本番ジョブでビルドや署名まで段階別に検証してください。
導入形態を決め、Mac環境の調達も比較する
Cloudflare Tunnelの構築は、経路、Accessポリシー、Macアカウント、CI資格情報、障害時の復旧を継続管理する必要があります。すでに管理対象のMacがあり、安定した長期運用と物理的な周辺機器接続が必要なら、自社でMacを調達・保守する案も合理的です。反対に、台数や利用期間が定まらない段階では、購入費用に加えて資産管理、保守、構成変更の負担が生じます。
Mac本体を購入する判断材料は、Mac miniの調達案内で確認できます。短期間の検証や一時的なビルド環境が必要で、購入後の保守負担を避けたい場合は、NodeMiniのMacレンタルも候補になります。チームの認証・SSH設計を先に固めたうえで、NodeMiniのサービス情報を参照し、実際に提供される接続方法が運用要件に合うか確認してください。