共有 SFTP エントリにおける三つの隔離上の落とし穴
実務で危険なのは、書き込み可能な chroot ルート、シェル付きの「SFTP」アカウント、CI と人間の同一鍵運用です。所有者・権限の不変条件が前提で、再帰的 chmod -R 777 はモデルを壊します。
痛み1：chroot およびその祖先は root 所有で、テナントが書き換えできない必要があります。そうでないとサブシステムが拒否したり、シンボリックリンク差し替えのリスクが残ります。
痛み2：ForceCommand internal-sftp が欠けたり、Match の順序が誤っていると、シェル取得・scp・ポートフォワードが残存し得ます。
痛み3：鍵とログがテナントに対応しない。authorized_keys 不備は弱いパスワード運用へ戻りがち。境界ごとにアカウント分離、鍵コメントに責任者、同時セッション上限と整合し inode 枯渇を防ぎます。
SFTP のみとシェル：chroot を採る価値があるとき
小規模で同一信頼域なら「アカウント分割＋パス接頭辞」で足りることがあります。外注・CI ロボットなど境界をまたぐなら chroot が向きます。代償は root が持つ骨格ディレクトリと鍵フローの保守です。
SFTP のみは nologin シェル、ForceCommand internal-sftp、転送オフ、対外向けに scp 禁止と明記します。管理用シェルは別 Match か別ホスト名に分けます。
chroot と原子リリースは補完です。横方向到達を抑え、ステージング＋シンボリックリンクで読み取り一貫性を支えます。権限比較・クライアント選定と併せて設計します。
意思決定表：隔離強度と運用コスト
| 案 | 最も向く場面 | 主なリスク | 最小の制御面 |
|---|---|---|---|
| 共有ディレクトリで chroot なし | 単一信頼域・小チーム | 一つの鍵漏えいからの横展開 | グループ権限、CI 専用アカウント、集約ログ |
| SFTP のみ・chroot なし | 内網開発者、IAM が強い | パス設定ミスによる越境 | 定期 find 監査、既定 umask |
| chroot ＋ internal-sftp | 外注・コンプライアンス分区画 | 所有者誤りでログイン不能 | root 所有チェーン、葉だけ書き込み可 |
| テナントごと独立ホスト | 強い規制や騒がしい隣人 | コストとパッチ面 | イメージ基線、自動パッチ、鍵バックアップ |
五ステップ：OpenSSH Match の骨格
変更前に設定と sshd -T のバックアップを取り、macOS のメジャーアップグレード後は差分を再確認します。
- chroot 親パスを用意し、祖先はすべて root・755・グループ書き込み不可とします。
- jail 内の
upload/はテナント所有とし、chroot ルート自体は書き込み不可にします。 MatchでForceCommand internal-sftp、ChrootDirectory、転送オフ。必要なら jail 外のAuthorizedKeysFileを指定します。sshd -t、reload、sftp -vvvで検証し、ssh実行は拒否されることを確認します。- 詳細な認証ログは一時的に開け、検証後に戻します。
ステップ3後は逆方向テスト（scp・転送）がすべて失敗することを文書化し、認証失敗・ディスク・inode を監視します。
# 片段示例 —— 用户名/路径/组请按实际替换；改前 sshd -t
Match Group sftponly
ChrootDirectory /srv/sftp/%u
ForceCommand internal-sftp
AllowTCPForwarding no
X11Forwarding no
PermitTunnel no
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
# 宿主机侧（jail 外）示意：
# mkdir -p /srv/sftp/vendorA/upload
# chown root:wheel /srv/sftp /srv/sftp/vendorA
# chmod 755 /srv/sftp /srv/sftp/vendorA
# chown vendorA:vendorA /srv/sftp/vendorA/upload
# chmod 750 /srv/sftp/vendorA/upload
chown／chmod を Runbook に残し、一時緩和は巻き戻し期限付き。reload とロールバックも演習します。
引用しやすい数値と不変条件
chroot 祖先は多くの現場で 755、テナントデータは 750 です。chroot ルートへグループ書き込み等を与えないことは OpenSSH の文書でも明確で、公開が必要でもルートからのチェーン全体は緩めません。
ディスククォータは接続数の代替になりません。小ファイル大量で inode が先に枯れるため二指標で監視し、5 GiB超はステージング（原子リリース）で扱い、タイムアウトだけ延ばしません。
外部テナントの鍵は 90 日目安でローテーションし、紛失時は即失効。CI は短命のパイプライン専用鍵とし、公開鍵変更はレビューに載せます。認証ログは最低 30 日、authorized_keys コメントに責任者を記載します。
FAQ、限界、マネージド リモート Mac
- chroot を有効にした途端に切断？ パス所有者と権限、
internal-sftpの強制、鍵ファイルが sshd から読めるかを層ごとに確認します。 - chroot はクライアント側ランサムウェアを防ぐ？ いいえ。主にサーバ側で資格情報が漏えいしたあとの横展開を抑えます。
まとめ：internal-sftp＋ChrootDirectory＋root チェーン＋葉のみ書き込み＋SFTP 専用 Match が再現可能な境界になります。セッション予算・原子リリース・鍵監査と併用してください。
限界：自前 Mac は手編集 sshd・共有パスワードの積み上がり、IaC／監査がないと文書と現物がずれます。
SFTPMAC：マネージド リモート Mac でパス隔離と sshd 基線を再現しやすく、原子リリースと同時転送と併用するのが無難です。