Apple의 원격 로그인 안내에는 접근 범위가 모든 사용자와 지정된 사용자만 두 가지로 나뉘어 있습니다. 이 기준만 보더라도 팀 공유 Mac 권한 관리는 공용 비밀번호가 아니라 개인별 신원과 허용 목록으로 설계해야 합니다. Apple의 Remote Login 사용자 제한 안내처럼 계정을 분리하고, CI 계정·관리자 계정·FileVault 해제 권한을 따로 검증해야 합니다.
증상 → 가장 빠른 해결책
공용 관리자 계정으로 접속하고 있다면 즉시 사용을 중단하고, 개인별 표준 계정과 독립된 CI 서비스 계정으로 바꾸어야 합니다. 관리자 작업은 제한된 관리자 계정이나 임시 권한 상승으로 처리하고, 이 경계를 지원하지 못하는 호스트는 프로젝트 전용 원격 Mac으로 전환하는 편이 안전합니다.
이 글은 원격 Mac을 개발팀에 제공하는 기업 IT 책임자를 위한 글입니다.
iOS 빌드 계정과 서명 키를 관리하는 개발 생산성 담당자, 공유 호스트와 전용 호스트를 비교하는 기술 책임자에게도 적합합니다.
SECTION 01공용 관리자 계정이 만드는 감사 공백
공용 계정은 처음에는 운영이 간단해 보입니다. 하지만 문제가 발생하면 누가 어떤 명령을 실행했는지 확인하기 어렵습니다. 비밀번호를 바꾸더라도 이미 복사된 인증 정보와 로그인 세션을 모두 회수했다는 증거를 남기기 어렵습니다.
NIST의 최소 권한 원칙은 사용자나 프로세스가 업무에 필요한 접근만 갖도록 요구합니다. 또한 계정 생성, 변경, 비활성화와 삭제를 감사할 수 있어야 한다고 설명합니다. NIST 접근 통제 기준 AC-2와 AC-6은 공용 관리자 계정보다 개인별 계정과 역할별 권한을 전제로 합니다.
공용 관리자 계정을 계속 사용하면 다음 문제가 동시에 발생합니다.
- 작업자 식별 실패: 터미널 명령, 파일 삭제, 설정 변경의 책임자를 확정하기 어렵습니다.
- 비밀번호 회수 실패: 한 명의 퇴사나 조직 이동 때문에 모든 사용자의 비밀번호를 바꿔야 합니다.
- 권한 범위 과다: 개발, 빌드, 시스템 설정, 인증서 접근이 한 계정에 섞입니다.
- 사고 조사 지연: 로그인 기록이 남아도 실제 사용자를 계정명만으로 구분할 수 없습니다.
- 세션 잔존 위험: 화면 공유나 SSH 세션이 남아 있으면 계정 비활성화만으로 충분하지 않을 수 있습니다.
여러 명이 한 대의 Mac을 원격으로 사용할 때 계정을 하나로 합쳐도 됩니까?
운영 편의만 보면 가능하지만, 기업 보안 기준에서는 적합하지 않습니다. 최소한 사람, 계정, 용도를 일대일로 연결해야 합니다. 개인 개발자는 개인 표준 계정, 자동 빌드는 CI 서비스 계정, 시스템 변경은 제한된 관리자 계정으로 나누어야 합니다.
권한 검토 문서에는 다음 항목을 기록해야 합니다.
- 사용자 이름과 소속
- macOS 로컬 계정 또는 연동 계정
- 사용 목적
- 접근 방식
- 필요한 권한
- 승인자
- 만료일
- 회수 담당자
- 확인할 로그인 기록과 변경 기록
SECTION 02역할별 계정과 최소 권한 경계
팀 공유 Mac 권한 관리는 계정 수를 늘리는 작업이 아닙니다. 계정마다 업무 목적과 실패 범위를 분리하는 작업입니다. 한 계정이 개발과 빌드와 인증서 보관을 모두 맡으면, 어느 한 영역의 사고가 전체 환경으로 확장됩니다.
권장 역할은 다음과 같습니다.
- 개인 표준 계정: 코드 작성, 테스트, 로그 확인, 일반 개발 도구 사용을 담당합니다.
- CI 서비스 계정: 자동 빌드와 테스트만 실행합니다. 대화형 로그인은 기본적으로 막습니다.
- 제한된 관리자 계정: 시스템 설정, 패키지 설치, 사용자 관리처럼 승인된 작업만 처리합니다.
- 비상 복구 계정: 평상시 사용하지 않고, 승인과 사후 검토가 있을 때만 사용합니다.
Platform SSO를 사용하는 환경이라면 계정 생성 시 표준 사용자, 관리자, 특정 그룹 권한을 구분할 수 있습니다. 다만 실제 권한은 macOS 버전, 기기 관리 서비스, 인증 제공자의 지원 범위에 따라 달라질 수 있으므로 배포 전에 반드시 검증해야 합니다. Platform SSO의 계정 생성과 권한 관리 문서도 새 계정에 표준 권한이나 관리자 권한을 적용할 수 있다고 설명합니다.
역할별 선택 기준
| 선택지 | 적합한 용도 | 허용해야 할 권한 | 반드시 남길 증거 | 회수 방식 |
|---|---|---|---|---|
| 개인 표준 계정 | 일반 개발과 테스트 | 사용자 폴더와 허용된 개발 도구 | 계정 목록, 로그인 기록 | 해당 계정 비활성화와 세션 확인 |
| CI 서비스 계정 | 자동 빌드와 테스트 | 프로젝트 작업 공간과 필요한 도구 | 빌드 기록, 키 사용 기록 | 토큰 폐기와 서비스 계정 비활성화 |
| 제한된 관리자 계정 | 승인된 시스템 변경 | 필요한 설정과 설치 작업 | 요청자, 승인자, 작업 결과 | 관리자 그룹 제거 또는 계정 비활성화 |
| 비상 복구 계정 | 장애와 복구 | 복구에 필요한 최소 범위 | 사용 사유, 시작·종료 시각, 결과 | 비밀번호 교체와 사용 기록 검토 |
관리자 권한 요청에는 작업 이유만 적지 말고 대상 호스트, 대상 경로, 필요한 명령, 시작 시각, 만료 시각, 승인자, 실패 시 복구 방법까지 남겨야 합니다. 영구 관리자 권한을 부여하는 대신 작업 단위로 승인하고, 작업이 끝난 뒤 권한이 실제로 사라졌는지 확인해야 합니다.
주의: 관리자 계정과 Secure Token 보유 계정은 같은 의미가 아닙니다. 관리자라는 이유만으로 FileVault 해제, 볼륨 소유권, 시스템 업데이트 승인 권한이 자동으로 동일해진다고 가정하면 안 됩니다.
SECTION 03원격 접속 경로의 신원 연결
원격 Mac에는 보통 웹 콘솔, 화면 공유, SSH가 함께 사용됩니다. 이 세 경로를 하나의 공용 비밀번호로 묶으면 접근 목적과 책임자가 사라집니다.
- 웹 콘솔은 호스트 배정, 계정 개통, 재시작 같은 플랫폼 작업과 연결합니다.
- 화면 공유는 그래픽 환경에서 직접 조작해야 하는 개발과 장애 대응에 사용합니다.
- SSH는 명령 실행, 파일 전송, 자동화 연결에 사용합니다.
Apple은 화면 공유와 Remote Login 모두 특정 사용자만 접근하도록 제한하는 설정을 제공합니다. 화면 공유의 사용자 제한 안내와 SSH 기반 Remote Login 안내를 기준으로 접근 허용 목록을 구성해야 합니다.
팀 공유 Mac에서 개발자에게 관리자 권한을 주지 않으려면 어떻게 해야 합니까?
개발자 계정을 표준 사용자로 만들고, 필요한 설치나 설정 변경만 별도의 승인 절차로 처리해야 합니다. 개발자가 직접 SSH로 관리자 셸에 들어가도록 허용하지 말고, 자동화 작업은 서비스 계정과 제한된 작업 경로를 사용해야 합니다.
다음 순서로 점검하면 됩니다.
- 현재 호스트의 모든 로컬 계정과 연동 계정을 목록화합니다.
- 각 계정의 관리자 그룹 포함 여부를 확인합니다.
- SSH 허용 사용자와 화면 공유 허용 사용자를 따로 기록합니다.
- 개인 계정에는 개인 키를 연결하고, 공용 개인 키를 금지합니다.
- CI 연결은 대화형 셸이 아닌 서비스 계정으로 변경합니다.
- 화면 공유에서 공용 VNC 비밀번호 사용 여부를 확인합니다.
- 퇴사자 계정을 비활성화한 뒤 SSH 키, 화면 공유 권한, 웹 콘솔 권한을 각각 점검합니다.
- 비활성화된 계정으로 다시 로그인할 수 없는지 실제로 테스트합니다.
검수 증거는 계정 목록 하나로 끝내면 안 됩니다. 계정 목록, 접근 허용 목록, SSH 키의 소유자, 로그인 기록, 권한 변경 기록, 비활성화 테스트 결과를 함께 보관해야 합니다. 로그 보관 기간은 조직 정책과 계약 조건에 따라 정하고, 확인하지 않은 기간을 보안 기준처럼 고정해서는 안 됩니다.
SECTION 04CI 계정과 Keychain 격리
iOS CI에서 가장 위험한 혼용은 개발자 로그인 계정과 자동 빌드 계정이 같은 Keychain과 작업 공간을 사용하는 경우입니다. 개발자가 대화형으로 가져온 인증 정보가 CI 프로세스에 노출되거나, CI 로그와 임시 파일에 서명 관련 파일이 남을 수 있습니다.
Apple의 코드 서명 문서는 인증서만으로는 서명할 수 없고 대응하는 개인 키가 필요하다고 설명합니다. 또한 내보낸 서명 자격 증명과 비밀번호를 함께 획득한 사람은 조직을 대신해 서명된 소프트웨어를 배포할 수 있다고 경고합니다. 서명 자격 증명 관리 안내를 기준으로 책임자를 분리해야 합니다.
Keychain도 자동으로 모든 계정 사이에서 안전하게 분리되는 저장소라고 보면 안 됩니다. 앱과 자격 증명은 접근 그룹과 서명 권한에 따라 접근 범위가 달라집니다. Keychain 접근 그룹 문서는 Keychain 항목이 하나의 접근 그룹에 속하며, 같은 그룹에 속한 앱이 항목을 공유할 수 있다고 설명합니다.
iOS CI 서비스 계정과 개발자 계정은 어떻게 나누어야 합니까?
개발자 계정은 코드 수정과 수동 테스트에만 사용하고, CI 서비스 계정은 승인된 저장소와 빌드 작업만 접근하도록 구성해야 합니다. 인증서와 개인 키는 프로젝트 또는 신뢰 수준별로 분리하고, 하나의 개발자 로그인 Keychain을 여러 작업이 공유하지 않도록 해야 합니다.
실무에서는 다음 책임 사슬을 문서화합니다.
- 가져오기: 누가 어떤 자격 증명을 어떤 호스트에 넣었는지 기록합니다.
- 사용: 어떤 프로젝트와 어떤 빌드 작업이 사용했는지 연결합니다.
- 보관: 작업 공간, Keychain, 환경 변수, 임시 파일의 위치를 확인합니다.
- 교체: 만료나 담당자 변경 시 교체할 책임자를 지정합니다.
- 폐기: 퇴사나 유출 의심 시 인증서 폐기, 토큰 취소, 새 키 발급을 함께 진행합니다.
장기 비밀번호를 스크립트에 직접 넣는 방식은 피해야 합니다. 자격 증명은 승인된 비밀 저장소나 기기 관리 체계에서 주입하고, 빌드가 끝난 뒤 임시 파일과 캐시를 검토해야 합니다.
직원이 퇴사했을 때 원격 Mac과 서명 권한을 완전히 회수하려면 무엇을 확인해야 합니까?
먼저 신원 제공자와 웹 콘솔에서 계정을 막습니다. 그 다음 macOS 계정, SSH 키, 화면 공유 허용 목록, CI 토큰, 저장소 접근 토큰, Keychain 항목, 서명 인증서와 개인 키를 각각 확인해야 합니다.
서명 인증서가 유출되었거나 개인 키의 통제가 불분명하면 단순히 Mac 계정을 삭제하는 것으로 끝나지 않습니다. Apple 문서의 절차에 따라 영향을 받은 인증서를 폐기하고 새 서명 자격 증명을 발급해야 합니다. 코드 서명 인증서와 개인 키 안내는 개인 키가 로그인 Keychain에 저장될 수 있다는 점을 설명합니다.
SECTION 05FileVault와 복구 권한 분리
FileVault, Secure Token, 볼륨 소유권은 서로 연결되지만 같은 권한이 아닙니다. Apple Silicon Mac에서는 사용자가 저장 공간을 잠금 해제하려면 Secure Token과 볼륨 소유권 조건이 함께 관여할 수 있습니다. Secure Token, Bootstrap Token과 볼륨 소유권 안내는 이 권한들이 배포 방식과 기기 관리 서비스에 따라 다르게 부여될 수 있다고 설명합니다.
따라서 다음 항목을 하나로 묶어 승인하면 안 됩니다.
- Mac 로그인 가능 여부
- 관리자 그룹 포함 여부
- Secure Token 보유 여부
- 볼륨 소유권 보유 여부
- FileVault 잠금 해제 가능 여부
- 원격 재시작 후 복구 작업 가능 여부
- 시스템 업데이트 승인 가능 여부
공유 Mac이 재시작 후 원격으로 복구되지 않으면 모든 개발자에게 FileVault 권한을 줄 수 있습니까?
그렇게 처리하면 안 됩니다. 복구 편의를 위해 모든 개발자에게 디스크 잠금 해제 권한을 주면, 개발 계정과 저장 공간 보호 계정의 경계가 무너집니다. 복구 키는 담당 조직이 통제하고, 누가 잠금 해제를 수행할 수 있는지 별도 목록으로 관리해야 합니다.
현재 Apple 보안 문서에는 Remote Login이 켜져 있고 네트워크 연결이 가능한 일부 환경에서 재시작 뒤 SSH를 통한 FileVault 잠금 해제가 가능하다고 설명되어 있습니다. 다만 이 기능은 macOS 버전과 배포 조건에 영향을 받으므로 운영 환경에서 직접 검증해야 합니다. FileVault 관리 문서를 기준으로 복구 절차를 시험하십시오.
검수 시에는 다음 질문에 답이 있어야 합니다.
- 누가 디스크를 잠금 해제할 수 있습니까?
- 복구 키는 어디에 보관됩니까?
- 복구 키 사용 기록을 누가 확인합니까?
- 원격 재시작이 실패하면 누가 현장 또는 대체 경로를 담당합니까?
- 시스템 업데이트 승인 권한과 FileVault 잠금 해제 권한이 분리되어 있습니까?
- 퇴사자 계정이 FileVault 사용자 목록에 남아 있지 않습니까?
SECTION 06전용 Mac 전환 판단
공유 Mac은 개발 도구를 여러 명이 함께 사용할 때 유용하지만, 프로젝트 간 신뢰 수준이 다르거나 서명 키를 강하게 격리해야 한다면 한계가 빠르게 드러납니다. 특히 다음 조건이 하나라도 충족되면 공유 호스트를 계속 확장하지 않는 편이 좋습니다.
- 한 프로젝트가 다른 프로젝트의 작업 공간을 읽을 수 있습니다.
- CI 서비스 계정과 개발자 계정의 Keychain을 분리할 수 없습니다.
- 한 사람의 권한을 단독으로 회수할 수 없습니다.
- FileVault 복구 권한을 특정 담당자에게만 제한할 수 없습니다.
- SSH와 화면 공유가 공용 비밀번호에 의존합니다.
- 퇴사자 회수 테스트를 실제로 수행할 수 없습니다.
- 프로젝트별 감사 기록을 분리할 수 없습니다.
반대로 모든 개발자가 개인 표준 계정을 사용하고, CI 계정이 대화형 로그인을 하지 않으며, 프로젝트별 작업 공간과 자격 증명을 분리할 수 있다면 공유 호스트를 유지할 여지가 있습니다. 단, 이 판단은 비용보다 격리 수준을 먼저 봐야 합니다.
현재 사용하는 Mac에서 이 조건을 만족하지 못한다면, 공유 관리자 계정을 더 많이 만드는 대신 프로젝트별 또는 팀별 전용 원격 Mac을 검토하십시오. MACNOX의 한국어 원격 Mac 이용 안내와 요금 및 대여 조건을 비교할 때도 가격만 보지 말고 계정 철회, 호스트 교체, 프로젝트 분리 가능 여부를 함께 확인해야 합니다.
공유 환경이 적합하지 않은 경우에는 전용 Mac이 더 안전하지만, 장기간 고정된 고부하 작업이나 물리 장비 연결이 필요한 조직에는 직접 구매한 Mac이 더 적합할 수 있습니다. 반대로 단기 프로젝트, 신규 CI 검증, 팀별 분리 테스트처럼 사용량이 변하는 상황에서는 필요 기간만 원격 Mac을 할당하는 방식이 운영 부담을 줄일 수 있습니다.
마지막으로 현재 호스트의 계정–사람–용도–자격 증명 매트릭스를 먼저 작성하십시오. 개인 식별, 단일 사용자 권한 회수, 프로젝트별 Keychain 격리 중 하나라도 확인되지 않는다면 공용 관리자 계정을 유지할 이유가 없습니다. 그때는 MACNOX의 원격 Mac 시작 안내를 참고해 공유 호스트를 계속 확장할지, 팀 또는 프로젝트 전용 Mac으로 나눌지 다시 결정하는 것이 안전합니다.