2026年9月11日時点で、CISは「CIS Apple macOS 26 Tahoe Benchmark v1.1.0」を公開しています。現行版はCISの公式ベンチマーク一覧で確認できます。だからこそ、あなたはオフィス端末の設定を本番ビルドマシンへそのまま配布せず、先に監査、次に例外整理、その後に隔離ノードで実ビルドを検証し、最後に段階展開してください。
誰がこの判断表を使うべきか
企業IT責任者は、macOS 26の基線を統一しながら本番を止めない運用設計に使えます。
セキュリティ・コンプライアンス責任者は、CISの失敗項目を期限付きの例外記録へ変換できます。
開発生産性の責任者は、加固後の遠隔Macで無人ビルド、署名、再起動復旧まで確認できます。
0日目：4種類のMacを同じポリシーから分離する
最初に、端末を「従業員用オフィスMac」「対話型の開発Mac」「通常のCIノード」「本番署名ノード」に分けます。後ろの2種類は、ログイン方法、Keychain、署名資産、再起動後の復旧責任が異なるため、同じ例外ルールを共有すべきではありません。
CIS Benchmarkの対象版、企業の管理目標、現在のCI構成を並べ、下げてはいけない制御を先に確定します。ノード名、利用アカウント、Remote Loginの入口、署名証明書、復旧担当者が一覧化されるまで、自動修復へ進めないでください。
注意：スキャンの合格率を先に上げると、実際には使われていないアカウントを削除したのか、SSHの経路を壊したのかを後から判別しにくくなります。最初に保存すべきなのは点数ではなく、ルール番号、検出時刻、ノードID、現在の設定です。
1日目：修復前に監査差分を固定する
初回はaudit-onlyで実行し、修復処理を止めます。macOS Security Compliance Projectの基線説明では、基線を要求事項の集合として扱い、CIS Level 1やLevel 2などの出力を区別できます。
各項目について、次の3分類を作ります。
- 直接実行：CIの接続、署名、エージェント復旧を壊さないことを確認済み
- 例外申請：本番フローと衝突し、適用前に責任者の承認が必要
- 補償制御：設定を緩める代わりに、アクセス制限、監視、専用ノードなどでリスクを抑える
mSCPのコンプライアンススクリプト仕様が示すように、検査結果と修復、例外は分けて扱います。失敗を「本当に不適合」「検査スクリプトの誤判定」「別の管理策で同等に制御済み」に分けると、不要な例外を増やさずに済みます。
例外記録に最低限残す項目
「CIで必要」という一文だけでは監査に耐えません。対象のパイプライン、ノード範囲、業務上の理由、リスク所有者、補償制御、再評価日、失効条件を記録します。署名ノードと通常のCIノードを一つの例外として申請するのも避けてください。
2〜3日目：隔離ノードで管理経路を確かめる
本番リリースを担当しないmacOS 26ノードを試験用に割り当て、構成プロファイルと監査スクリプトを先に配布します。MDMまたは構成管理ツールから同じポリシーを再配布し、手作業の変更が設定ドリフトとして検出されるか確認します。
試験では、次の順序を崩さないでください。
- 基線バージョンと対象ノードを記録する
- 構成プロファイルと監査スクリプトを配布する
- SSHによるRemote Loginと必要なアカウントを確認する
- 画面共有またはグラフィカルセッションの管理経路を確認する
- 管理者権限の撤去と再付与を検証する
- FileVaultの解除、復旧キーの保管、再起動後の接続を確認する
- ソフトウェア更新後に同じ監査と接続試験を繰り返す
AppleのRemote Loginに関する仕様では、SSHで接続できるユーザーと許可条件を管理します。アカウントが存在していても、管理ポリシーや許可グループの変更で入口が変わるため、設定値の確認だけでなく実際の接続を記録してください。
4〜7日目：更新とFileVaultを再起動の試験に結び付ける
macOSの更新は、インストール予約、通知、再起動のタイミングによってCIの稼働時間と衝突します。Appleのソフトウェア更新強制設定と宣言型の更新設定を確認し、メンテナンス時間、延期条件、再起動後の管理経路を明文化します。
FileVaultも「ディスクが暗号化されている」という確認だけでは不十分です。AppleのFileVault導入仕様を基に、復旧キーを誰が管理し、再起動後に誰が解除し、解除後にCIエージェントがどのアカウントで起動するかを分離して確認します。
経験則：ホストへSSH接続できたことは、ビルドが復旧した証拠ではありません。Keychainの利用、署名資格情報、エージェントの再登録、キューに残ったジョブの再実行まで完了して、初めて「復旧可能」と判定できます。
7日目以降：本番へ広げる前の比較表
次の表は、適用方式を決めるための比較表です。Level 1やLevel 2を名称だけで選ばず、ノードの役割と復旧要件で判断してください。
| 選択肢 | 適用対象 | 実施条件 | 主なリスク | 判断 |
|---|---|---|---|---|
| そのまま適用 | オフィス端末中心 | 業務アプリと接続経路を別途確認 | CI用の例外が混入する | 本番ビルドには不適 |
| 裁剪して適用 | 通常のCIノード | 監査差分と例外承認を保存 | 例外の期限切れ | 多くの組織で第一候補 |
| 専用基線を作成 | 本番署名ノード | 署名資産と復旧責任を分離 | 管理対象が増える | 重要リリース向け |
| 補償制御を併用 | 直接修復できない項目 | ネットワーク、権限、監視を強化 | 制御の有効性を再評価する必要 | 期限付きで採用 |
段階展開：合格点ではなく失敗原因を観測する
最初は署名を担当しないCIノードへ広げ、未変更ノードを回退先として残します。その後、代表的なパイプラインで依存関係の導入、コンパイル、テスト、アーカイブ、署名を順に実行します。
本番展開の判断は、次の表のように分けると明確です。
| 観測結果 | 次の処置 | 例外の扱い |
|---|---|---|
| 監査合格、実ビルド成功、再起動後も復旧 | 次のノード群へ展開 | 期限を維持して定期確認 |
| 監査合格、署名またはKeychainで失敗 | 展開を停止し原因を特定 | 補償制御を再設計 |
| SSHや画面共有が不安定 | 管理経路を先に修復 | 本番投入を保留 |
| 同じ制御で手動復旧が繰り返される | 変更を回退し試験をやり直す | 例外を恒久化しない |
基線の更新時は、設定差分だけでなく、代表ジョブのログ、再起動試験、復旧時間、回退結果を再取得します。mSCPのクイックガイドは、基線から監査文書や構成出力を作成する流れを示しています。利用した基線ファイルの版と、生成した出力を同じ証拠束に保管してください。
監査終了時に残す3つの成果物
最後に、次の3種類を一つの案件記録へまとめます。
| 成果物 | 含める内容 | 監査で答えられる質問 |
|---|---|---|
| 差分台帳 | ルール番号、状態、検出日時、ノードID | 何が未適用なのか |
| 例外・補償制御表 | 理由、範囲、責任者、期限、代替策 | なぜ適用しなかったのか |
| 運用検証記録 | CIログ、署名結果、再起動、回退、再試行 | 本当に無人運用できるのか |
同じ証拠束には、基線の取得元と変更履歴も入れます。CISやmSCPの公開版が更新された場合、またはmacOS 26のセキュリティ更新で制御の挙動が変わった場合は、例外を自動的に延長せず、再監査の起点にしてください。
FAQ
CIS macOS 26のLevel 1設定をCI用ビルドマシンへそのまま適用できますか？
そのままの一括適用は避けてください。Level 1でも、SSH、グラフィカルなセッション、Keychain、再起動後のエージェント復旧など、無人実行に関係する制御があります。まず監査専用で差分を取得し、各項目を実行、例外、補償制御に分類してから隔離ノードで検証します。
macOS 26のセキュリティ基線でSSHや画面共有が使えなくなることはありますか？
基線の適用だけを根拠に、必ず接続不能になるとは判断できません。Remote Loginの許可、対象アカウント、画面共有の利用条件、MDMの配布状態を個別に確認し、SSH接続と画面セッションを実機で検証してください。AppleのRemote Login仕様と各制御の検査結果を証跡として残します。
FileVaultを強化した後、遠隔Macを再起動した場合はどう復旧しますか？
再起動後に暗号化ボリュームの解除が必要になる構成では、通常のホスト疎通だけで復旧性を証明できません。FileVaultの解除方法、復旧キーの管理、担当者の責任範囲、CIエージェントの自動起動を分けて確認し、非本番ノードで再起動からジョブ再開までを演習します。
CIS BenchmarkでMac Runner用の例外を検討すべき制御はどれですか？
特定のルール番号を一括で除外するのではなく、無人ログイン、SSH、CIエージェント、Keychain、署名用証明書、FileVault、ソフトウェア更新、スリープ設定に影響するかを確認します。例外には対象ノード、パイプライン、リスク所有者、補償制御、失効日を必ず結び付けます。
Macのビルドマシンが基線準拠と無人運用を両立できることはどう証明しますか？
スキャン合格だけでは不十分です。依存関係の導入、コンパイル、テスト、アーカイブ、署名、再起動、エージェント復旧、ジョブ再実行を代表的なパイプラインで確認します。基線バージョン、設定差分、ログ、失敗時の復旧記録を同じ証拠パッケージに保管してください。
結論：まず1台の隔離ノードで証拠を作る
オフィス端末向けの基線を本番ビルドマシンへ横展開すると、SSH、Keychain、FileVault、更新再起動のどこで止まったのかを切り分けにくくなります。先に監査差分と例外期限を整え、隔離した遠隔Macで加固、実ビルド、署名、再起動、回退を確認してから、非署名ノード、本番CIノード、署名ノードの順に広げてください。
自社保有のMacだけでこの試験を始めると、検証用機材の調達、余剰期間の固定費、物理的な回収、故障時の交換待ちが発生します。長期の安定負荷なら購入が合理的な場合もありますが、基線PoCや短期の監査、構成変更前の試験では、VMSPINの遠隔Macを一時的な検証ノードとして使う方が、既存の本番機を止めずに試験範囲を切り出しやすいです。
まずはVMSPINの日本語サービスページで利用形態を確認し、構成と期間が決まった段階で料金ページを比較してください。試験後に本番ノードへ広げない判断も含め、実際のCIログと復旧結果を基準に導入可否を決めるのが安全です。