CIS macOS 26 빌드 머신 기준이 영향을 줄까요? 2026년 기업 예외 목록

CIS Apple macOS 26 Benchmark에는 현재 1.1.0 버전이 공개되어 있습니다. CIS 공식 기준선 페이지에서 확인되는 이 버전은 사무용 맥에 그대로 적용할 출발점이 아니라, 빌드 머신별 영향 검토가 필요한 통제 목록입니다. 이번 주에는 자동 수정을 멈추고 감사 전용 검사를 실행한 뒤, 직접 적용·예외·보완 통제의 세 그룹으로 나누십시오. 실제 빌드와 서명, 재시작 복구를 확인하기 전에는 생산 노드에 배포하지 않는 것이 맞습니다.

마지막 검토: 2026년 9월 11일. 기준 버전은 CIS 공식 페이지와 NIST mSCP 자료를 기준으로 확인해야 하며, 이후 기준선이나 macOS 보안 업데이트가 나오면 다시 검토해야 합니다.

먼저 사무용 맥과 빌드 머신의 경계를 나눕니다

같은 macOS를 사용해도 운영 목적은 다릅니다. 사무용 맥은 사용자의 화면 잠금, 로컬 권한, 화면 공유 정책이 중심입니다. 반면 CI 노드는 무인 실행, 원격 접속, 비밀 저장소, 에이전트 복구가 핵심입니다. 생산 서명 노드는 여기에 배포 인증서와 키체인 접근이라는 추가 위험이 있습니다.

다음 네 종류를 하나의 예외 정책으로 묶지 마십시오.

• 직원이 사용하는 사무용 맥
• 개발자가 직접 로그인하는 대화형 개발 맥
• 테스트와 일반 빌드를 수행하는 CI 노드
• 배포 인증서와 서명을 담당하는 생산 서명 노드

NIST의 mSCP 기준선 구조 설명도 기준선을 조직의 통제 목표에 맞춰 선택하고 조정하는 구조로 설명합니다. 따라서 CIS macOS 26 빌드 머신 기준을 적용할 때는 규칙 묶음의 이름보다 노드의 역할과 복구 책임을 먼저 기록해야 합니다.

적용 전에 작성할 자산 목록

노드 이름만 적은 목록은 부족합니다. 다음 항목을 한 행에 연결해야 감사 결과가 실제 운영 책임으로 이어집니다.

• 노드 식별자와 운영 환경
• 빌드 계정과 관리자 계정
• SSH, 화면 공유, 웹 관리 화면 같은 원격 진입점
• CI 에이전트와 작업 재배정 방식
• 키체인, 서명 인증서, 비밀 값의 위치
• FileVault 복구 담당자
• 재부팅 후 연결을 확인할 담당자
• 기준선 변경을 되돌릴 방법

이 목록이 없으면 같은 실패가 보안 문제인지, 관리 도구 문제인지, CI 에이전트 문제인지 분리하기 어렵습니다.

1단계: 자동 수정보다 감사 결과를 먼저 확보합니다

첫 실행은 audit-only로 제한하십시오. NIST의 mSCP 합규 스크립트 동작 안내는 검사, 수정, 예외 처리를 구분할 수 있도록 설명합니다. 결과에는 규칙 식별자, 검사 시각, 노드 이름, 현재 상태, 사용한 기준선 파일을 함께 보관해야 합니다.

실패 결과는 다음 세 가지로 분류합니다.

1. 실제로 통제가 배치되지 않은 상태
2. 검사 스크립트가 기업의 설정을 잘못 판단한 상태
3. 같은 목적을 가진 보완 통제가 이미 배치된 상태

특히 SSH, CI 에이전트, 키체인, FileVault, 소프트웨어 업데이트, 잠자기 정책을 별도로 표시하십시오. 스캔 점수가 높아도 에이전트가 재시작 뒤 시작되지 않으면 생산 기준을 충족한 것이 아닙니다.

CIS macOS 26 Level 1을 CI 빌드 머신에 바로 적용해도 되나요?

바로 적용하지 않는 편이 안전합니다. Level 1이라는 분류만으로 무인 빌드와 서명에 필요한 예외가 자동으로 결정되지는 않습니다. NIST는 기준선과 통제 수준을 제공하지만, 특정 규칙이 모든 CI 환경에서 장애를 일으킨다고 선언하지 않습니다. 실제 노드에서 해당 규칙과 운영 의존성을 함께 검증해야 합니다.

다음 비교표를 승인 회의의 첫 결정 도구로 사용하십시오.

2단계: 예외를 승인 문서가 아니라 운영 조건으로 만듭니다

예외 사유를 “CI가 필요함”이라고만 쓰면 감사 증거가 되지 않습니다. 각 항목에 다음 내용을 붙이십시오.

• 영향을 받는 규칙과 기준선 버전
• 대상 노드와 계정 범위
• 중단될 수 있는 작업
• 위험 소유자
• 대신 적용한 보완 통제
• 시작일과 만료일
• 재검토 조건
• 실패 시 되돌릴 담당자

예를 들어 원격 로그인이 필요한 노드는 SSH 허용 계정, 허용 네트워크, 키 기반 인증, 관리자 계정 분리를 함께 기록해야 합니다. Apple의 원격 로그인과 SSH 계정 권한 안내는 원격 접속 권한이 사용자 계정 설정과 연결된다는 점을 설명합니다. 그러므로 원격 접속을 전부 끄는 방식은 보안 강화처럼 보여도 CI 복구 경로를 제거할 수 있습니다.

CIS Benchmark에서 Mac Runner 예외가 필요한 항목은 무엇인가요?

미리 정해진 예외 목록을 복사하기보다, 실제 의존성을 기준으로 찾아야 합니다. SSH 접속, 화면 세션, CI 에이전트 시작, 키체인 접근, FileVault 해제, 업데이트 후 재부팅이 영향을 받는지 각각 시험하십시오. 규칙 번호와 기본값은 기준선 버전에 따라 달라질 수 있으므로 CIS Apple macOS 기준선과 변경 기록을 배포 시점에 다시 확인해야 합니다.

예외는 세 종류로 나누면 관리하기 쉽습니다.

• 직접 적용: 빌드와 복구에 영향을 주지 않고 목적을 충족하는 통제
• 기간 제한 예외: 현재 운영 경로와 충돌하지만 대체 설계가 예정된 통제
• 보완 통제 적용: 원래 설정은 유지할 수 없으나 접근 제한과 감사 기록으로 위험을 낮추는 통제

3단계: 격리 노드에서 관리 채널을 시험합니다

생산 서명을 담당하지 않는 macOS 26 노드를 시험 대상으로 선택하십시오. 먼저 MDM 또는 구성 관리 도구로 프로파일과 감사 스크립트를 반복 배포합니다. 수동으로 고친 설정이 다음 배포에서 다시 바뀌는지도 확인해야 합니다. 이 검사가 없으면 기준선 준수 상태와 실제 설정 사이에 구성 표류가 생깁니다.

검증 순서는 다음과 같이 고정하십시오.

1. 기준선 파일과 감사 스크립트의 버전을 기록합니다.
2. 정책을 시험 노드에 배포하고 감사 결과를 저장합니다.
3. SSH와 화면 공유가 의도한 계정에만 열리는지 확인합니다.
4. 관리자 권한 회수 뒤 CI 에이전트가 정상 작동하는지 확인합니다.
5. FileVault 잠금과 해제 절차를 담당자와 함께 재현합니다.
6. 소프트웨어 업데이트와 재시작 뒤 원격 접속 경로를 확인합니다.
7. 정책을 다시 배포해 수동 변경이 사라지는지 확인합니다.

macOS 업데이트는 설치 시점과 재시작 동작에 영향을 줄 수 있습니다. Apple의 업데이트 강제 설치 안내와 업데이트 설정 안내를 함께 확인해, 빌드 중 재시작이 발생하지 않는 창을 운영 정책에 넣어야 합니다.

macOS 26 보안 기준선이 SSH와 화면 공유에 영향을 줄 수 있나요?

영향 가능성은 있지만, 특정 통제가 반드시 장애를 만든다고 단정할 수는 없습니다. 원격 로그인 허용 범위, 사용자 권한, 화면 세션 정책을 시험 노드에서 각각 확인해야 합니다. 원격 복구가 필요한 노드라면 접속 차단 자체보다 승인된 계정과 네트워크 범위를 줄이는 보완 통제가 더 적절할 수 있습니다.

FileVault를 강화한 뒤 원격 맥은 재시작 후 어떻게 복구하나요?

재시작 후 운영체제가 올라오는 것과 CI가 작업을 다시 받는 것은 다른 검증입니다. FileVault 해제 담당자, 복구 키 보관 위치, 원격 로그인 활성화 시점, CI 에이전트 자동 시작을 하나의 절차로 시험해야 합니다. Apple의 FileVault 배포와 복구 안내를 기준으로 조직의 복구 권한을 확인하고, 사람의 수동 개입이 필요한 단계를 문서화하십시오.

주의: 호스트가 온라인이라는 사실만으로 빌드 복구를 증명할 수 없습니다. 의존성 설치, 컴파일, 테스트, 보관, 서명, 작업 재배정까지 완료되어야 무인 운영 검증으로 인정할 수 있습니다.

4단계: 실제 파이프라인을 통과시킨 뒤 회색 배포합니다

이번 글에서는 검증 가능한 VMSPIN 실험 기록이 제공되지 않았으므로, 특정 구성이나 빌드 시간, 서명 성공률을 임의로 제시하지 않습니다. 대신 기업 내부 기록이나 실제 원격 맥 시험 로그로 다음 항목을 채우십시오.

• 기준선 적용 전후의 동일한 의존성 설치 로그
• 대표 프로젝트의 컴파일과 테스트 결과
• 보관과 서명 작업의 성공 여부
• 키체인 접근 실패 로그
• 재시작 뒤 에이전트 연결 시간
• 중단된 작업의 재배정 결과
• 원격 복구에 걸린 실제 시간과 담당자
• 정책 되돌리기 후 재검증 결과

1차 회색 배포는 일반 CI 노드에만 적용합니다. 이후 비서명 생산 노드로 넓히고, 마지막에 생산 서명 노드를 별도로 승인하십시오. 변경하지 않은 노드를 항상 남겨 두어야 장애 때 작업을 되돌릴 수 있습니다.

보안 기준선을 지키면서 무인 빌드가 가능하다는 사실은 어떻게 증명하나요?

스캔 통과율 하나로 증명하지 않습니다. 기준선 감사 결과, 예외 승인서, 실제 파이프라인 로그, 재시작 복구 기록을 같은 노드 식별자에 연결해야 합니다. 같은 테스트를 정책 적용 전후에 실행하고, 실패 원인과 복구 결과를 비교해야 합니다.

5단계: 첫 주 운영에서 기준선과 서비스 상태를 함께 봅니다

회색 배포 뒤에는 다음 신호를 매일 확인하십시오.

• 기준선 통과 상태가 갑자기 바뀌었는지
• 빌드 실패가 특정 노드나 규칙과 연결되는지
• 재시작 후 에이전트가 자동 복귀하는지
• FileVault 복구가 정해진 담당자에게 전달되는지
• 예외가 만료일 없이 남아 있는지
• 수동 변경으로 구성 표류가 생겼는지

같은 통제 때문에 반복적으로 사람이 노드에 접속해야 한다면 배포를 멈추십시오. 해당 통제를 무조건 해제하는 대신 전용 서명 노드 분리, 접근 경로 제한, 별도 복구 절차 같은 보완 통제를 다시 설계해야 합니다.

NIST mSCP는 기준선에서 감사 문서와 구성 출력을 만들 수 있도록 안내합니다. mSCP 빠른 시작 자료를 이용해 기준선 파일, 감사 결과, 구성 출력, 예외 승인서를 한 증거 묶음으로 보관하십시오. 지원되는 기준선과 프로젝트 변경 사항은 mSCP 공개 릴리스 기록에서도 확인할 수 있습니다.

마지막 마일스톤: 생산 승인과 재검토를 분리합니다

생산 승인은 다음 조건을 모두 충족했을 때 진행하십시오.

• 노드 역할별 자산 목록이 완성되어 있습니다.
• 모든 실패 항목이 직접 적용, 예외, 보완 통제로 분류되어 있습니다.
• 예외마다 위험 소유자와 만료 조건이 있습니다.
• SSH와 화면 공유의 승인된 접근 경로가 확인되었습니다.
• FileVault 복구 담당자와 절차가 정해져 있습니다.
• 업데이트와 재시작 뒤 CI 에이전트가 복귀합니다.
• 실제 빌드와 서명 로그를 보관했습니다.
• 변경하지 않은 회귀 노드가 남아 있습니다.

기준선 버전이 바뀌거나 macOS 26 보안 업데이트가 원격 로그인, FileVault, 업데이트 동작을 바꾸면 처음부터 전체 검증을 반복해야 합니다. 이때 기존 예외를 자동으로 연장하지 말고, 새 기준선과 현재 운영 의존성을 다시 대조하십시오.

사무용 맥의 정책을 복사하는 방식은 초기에는 단순해 보이지만, 원격 접속 차단, 업데이트 중 재시작, 키체인 접근 실패, 복구 인력 투입이라는 운영 부담을 남길 수 있습니다. 특히 물리 장비를 직접 보유한 환경은 장비 배치와 교체, 구성 표류를 팀이 계속 관리해야 합니다. 반대로 VMSPIN의 원격 맥을 격리된 시험 노드로 사용하면 구매 전에 실제 기준선 배포와 재시작 복구를 검증할 수 있습니다. 다만 장기간 고정 부하, 물리 포트 의존, 사내망에만 존재하는 비밀 자산이 필요하다면 직접 운영이나 전용 장비가 더 적합할 수 있습니다.

이번 주에는 생산 서명 노드가 아닌 원격 맥 한 대를 기준선 시험 대상으로 정하고, 감사 결과와 실제 파이프라인 로그를 먼저 확보하십시오. VMSPIN의 한국어 원격 맥 이용 경로에서 시험 환경을 준비한 뒤, 검증 결과가 통과할 때만 전체 빌드 노드로 확장하는 순서가 안전합니다. 비용과 기간을 먼저 검토해야 한다면 VMSPIN 요금 안내에서 시험용 임대 조건을 확인할 수 있습니다.