MDM 서버 점검은 macOS 27이 아니라 26.4에서 하세요

OS 27의 TLS 변경 사항을 점검하는 방법을 다룬 Apple 문서에는 대부분의 관리자가 그냥 지나치기 쉬운 문장이 하나 있습니다. 테스트 기기가 버전 27 이상을 실행 중인데 연결 오류가 발생한다면, 26.4 이상이면서 27보다 낮은 버전을 실행하는 기기에서 다시 테스트하라는 것입니다. “요구 사항을 충족하지 않는 연결은 차단되며, 이렇게 실패한 연결 때문에 해당 작업 흐름의 후속 연결을 테스트하지 못할 수 있”기 때문입니다.²

새 OS에서 테스트하면 문제 있는 서버 하나만 찾아내고 나머지는 가려집니다. 27에서는 요구 사항을 충족하지 않는 연결이 실패하고, 그 연결에 의존하던 작업 흐름은 거기서 멈춥니다. 뒤에 이어질 단계는 아예 실행되지 않으므로 테스트도 되지 않습니다. 26.4부터 26.x까지는 같은 문제가 경고로 기록되기 때문에, 한 번만 돌려도 요구 사항을 충족하지 않는 서버를 전부 드러낼 수 있습니다.

Apple이 직접 명시한 것은 두 가지입니다. 버전 27 이상에서는 “요구 사항을 충족하지 않는 연결이 차단되고 로그 메시지가 경고 대신 오류로 표시”되며, “영향을 받는 모든 서버를 식별하려면” 26.4 이상 27 미만에서 테스트하라는 것입니다.² 그보다 낮은 버전에서 연결이 실제로 완료된다는 점은 문서에 그대로 적힌 문장이 아니라 해석이지만, 그렇지 않다면 이 권장 사항 자체가 성립하지 않습니다. 26.4에서 연결이 차단된다면 27에서와 똑같이 작업 흐름이 중간에 끊길 테니까요.

변경 사항이 도입된 바로 그 버전에서 테스트하고 싶은 것이 사람의 본능입니다. 그런데 여기서는 그 본능이 불완전한 목록을 만들어 내고, 나머지는 운영 환경에서 하나씩 발견하게 됩니다.

요약

iOS, iPadOS, macOS, watchOS, tvOS, visionOS의 27.0 버전부터, 일부 시스템 프로세스가 MDM, 선언적 기기 관리(Declarative Device Management), 자동 기기 등록(Automated Device Enrollment), 구성 프로파일 설치, 엔터프라이즈 배포를 포함한 앱 설치, 소프트웨어 업데이트에 관여하는 연결에 더 엄격한 TLS 요구 사항을 적용합니다.¹ 서버는 TLS 1.2 이상을 지원해야 하며, ATS 요구 사항을 충족하는 암호화 스위트와 인증서를 사용해야 합니다.¹ SCEP 서버와 콘텐츠 캐싱 서버는 예외입니다.² 여러분이 만든 앱의 자체 네트워킹은 영향을 받지 않습니다. 점검은 위반이 차단이 아니라 경고로 기록되는 26.4~26.x에서, 네트워크 진단 로깅 프로파일(Network Diagnostics Logging Profile)과 sysdiagnose를 사용해 진행하세요.²

실제 적용 범위

이번 변경은 네트워크 트래픽 전반이 아니라, 정해진 시스템 활동 목록에만 적용됩니다.¹

• 모바일 기기 관리(MDM)
• 선언적 기기 관리(DDM)
• 자동 기기 등록(Automated Device Enrollment)
• 구성 프로파일 설치
• 엔터프라이즈 앱 배포를 포함한 앱 설치
• 소프트웨어 업데이트

예외 두 가지는 짚고 넘어갈 가치가 있습니다. 둘 다 모르고 있으면 관리자가 하루를 통째로 쏟아 원인을 찾게 되는 종류의 서버이기 때문입니다. 구성 프로파일을 설치하거나 DDM 자산을 확인하는 도중 SCEP 서버로 향하는 연결, 그리고 앱 설치나 소프트웨어 업데이트용 자산을 요청하는 경우까지 포함한 콘텐츠 캐싱 서버 연결이 그것입니다.²

제목만 보고 이 글에 들어온 개발자를 위해 분명히 해 둘 것이 있습니다. 여러분 앱의 URLSession 트래픽은 이번 이야기의 대상이 아닙니다. 이것은 기기 관리 인프라에 관한 변경입니다. App Transport Security는 앱이 iOS 9.0 및 macOS 10.11 SDK에 링크되기 시작한 시점부터 이미 앱 네트워킹을 관장해 왔습니다.³ 27에서 달라진 점은 일부 시스템 프로세스가 관리 트래픽에도 그에 준하는 요구 사항을 적용하기 시작했다는 것입니다.

대상 플랫폼 목록은 “기업용 Mac 자산”이라는 말에서 연상되는 범위보다 넓습니다. Apple은 iOS, iPadOS, macOS, watchOS, tvOS, visionOS를 모두 지목합니다.² 회의실의 Apple TV도, 디자인 스튜디오의 Vision Pro도 같은 인프라를 거쳐 등록됩니다.

공식 문서가 밝힌 요구 사항

Apple 지원 문서는 서버가 TLS 1.2 이상을 지원하고, ATS 요구 사항을 충족하는 암호화 스위트를 사용하며, ATS 기준을 만족하는 유효한 인증서를 제시해야 한다고 명시합니다.² 세부 사항은 ATS 문서에 있으며, 실제 작업은 그 페이지를 기준으로 삼아야 합니다.³

먼저 기본 서버 신뢰 평가를 통과해야 합니다. 서명이 온전할 것, 만료되지 않았을 것, 이름이 서버의 DNS 이름과 일치할 것, 그리고 클라이언트 OS에 기본 포함되어 있거나 사용자 또는 관리자가 설치한 CA가 발급한 앵커 인증서까지 체인이 이어질 것입니다.³

여기에 더해 ATS는 다음을 요구합니다.³

• 최소 2048비트 RSA 키 또는 최소 256비트 ECC 키로 서명한 인증서
• 최소 256비트 다이제스트의 SHA-2를 사용하는 인증서
• TLS 1.2 이상
• AES-128 또는 AES-256을 사용한 데이터 교환
• ECDHE 키 교환을 통한 순방향 비밀성(perfect forward secrecy)

마지막 두 항목은 이번 변경을 정리한 글에서 좀처럼 언급되지 않습니다. Apple이 점검용으로 공개한 위반 표에도 나오지 않습니다. 로그에 이름이 뜬 문제만 고친 관리자는 암호화 스위트 선택에서 여전히 요구 사항을 충족하지 못할 수 있습니다.

문제가 터지기 전에 점검하기

Apple이 문서화한 절차는 구체적이고, 각 단계에는 그럴 만한 이유가 있습니다.²

테스트 기기는 26.4 이상, 27 미만으로 준비하세요. 이것이 이 글의 핵심입니다. 위반은 경고로 기록되고, 연결은 성공하며, 작업 흐름은 다음 서버로 계속 이어집니다.

네트워크 진단 로깅 프로파일을 설치한 다음 기기를 재시동하세요. 어떤 테스트보다 먼저 설치해야 합니다. 그렇지 않으면 로그 이벤트에 문제 연결을 식별할 만한 상세 정보가 담기지 않습니다.

iPhone이나 iPad에서 자동 기기 등록을 테스트한다면 Mac용 Apple Configurator를 사용해 기기가 설정 지원(Setup Assistant)의 기기 관리 화면에 도달하기 전에 프로파일을 설치하세요. 등록 트래픽은 아주 이른 단계에서 발생하므로, 그 이후에 설치한 프로파일은 이를 놓칩니다.

평소의 작업 흐름을 그대로 실행하세요. 기기를 등록하고, 앱과 프로파일을 설치하고, 여러분의 서버와 통신하는 동작을 전부 돌려 보세요. 목표는 영향받을 가능성이 있는 모든 서버로 트래픽을 발생시키는 것입니다.

sysdiagnose를 수집해 Mac으로 옮기고, 아카이브를 푼 뒤 최상위 디렉터리에서 로그를 필터링합니다.

log show --archive system_logs.logarchive --info \
  -P "p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"

각 이벤트에는 Domain, 연결을 만든 Process, 그리고 어떤 제약을 위반했는지 알려 주는 Warning이 담겨 있습니다. 서버가 여러 요구 사항을 동시에 충족하지 못하면 연결 하나에서 경고가 여러 개 나올 수 있습니다.²

기기가 아니라 구성 조합을 빠짐없이 다루세요. Apple이 제시한 기준을 그대로 가져다 쓰는 편이 좋습니다. 환경(운영, 스테이징, 테스트), 기기 종류, 역할(사용자 그룹, 키오스크, 공용 기기), 등록 방식(자동 기기 등록, 계정 기반, 프로파일 기반, 공유 iPad)입니다.² 구성이 다르면 도달하는 서버도 다르고, 한 구성이 깨끗하게 통과했다는 사실은 다른 구성에 대해 아무것도 보장해 주지 않습니다.

watchOS는 이 방식으로 점검할 수 없습니다. 네트워킹 대부분이 프로세스 밖에서 일어나기 때문에 log 명령이 동작하지 않습니다. iOS에서 테스트하면 Apple Watch 연결까지 충분히 커버될 가능성이 높다는 것이 Apple의 안내입니다.²

위반 내용 읽는 법

Apple은 실패를 두 부류로 나눕니다. 겉보기에 멀쩡한 서버가 걸려 넘어지는 쪽은 두 번째입니다.

일반 ATS 정책 위반은 Warning [ATS violation]으로 기록됩니다.²

이 표에는 쓸모 있는 예외가 하나 들어 있습니다. 신뢰 평가에 실패한 인증서가 자동 등록 프로파일의 앵커 인증서에 포함되어 있다면 별도의 조치가 필요 없습니다.²

FCP v2.1 위반은 Warning [ATS FCPv2.1 violation]으로 기록됩니다.²

마지막 행이 많은 사람을 놀라게 할 항목입니다. 서버가 겉으로 드러난 요구 사항, 즉 최신 암호화 스위트와 유효한 인증서로 TLS 1.2를 협상하는 조건을 다 만족해도 실패할 수 있습니다. TLS용 기능 패키지(Functional Package for TLS)가 확장 마스터 시크릿 확장을 추가로 요구하기 때문입니다. Apple이 제시한 해결책은 TLS 1.3으로 옮기거나, 최소한 TLS 1.2가 EMS를 협상하도록 설정하는 것입니다.²

여기에는 헷갈리지 말아야 할 지점이 하나 있습니다. ATS의 FCP v2.1 준수 모드는 앱이 NSRequiresNIAPTLSPackageVersion을 통해 직접 선택하는 옵션이며, 규제 환경을 위해 존재합니다.³ 이 선택은 여러분 앱의 클라이언트 동작을 규정할 뿐입니다. OS 27의 시스템 프로세스와는 무관하며, 시스템 프로세스는 여러분의 앱이 무엇을 선택했든 상관없이 여러분의 서버에 FCP v2.1 검사를 적용합니다.

27에서 달라지는 것

버전 27 이상에서는 요구 사항을 충족하지 않는 연결이 차단되고, 로그 메시지가 경고가 아니라 오류로 표시됩니다.²

Apple은 상당수 경고에 정확히 대응되는 오류가 없으며, 암호화 스위트와 TLS 버전, 서명 알고리즘 문제의 경우 클라이언트 쪽에 어떤 오류가 나타날지는 “서버가 그 상황을 어떻게 처리하느냐에 따라 달라질 수 있다”고 밝힙니다.² 경고와 오류가 깔끔하게 1:1로 대응하리라 기대하지 마세요.

Apple이 문서에 구체적으로 남긴 오류는 하나뿐이며, 차단된 평문 HTTP를 다룹니다. 리디렉션이 http:// URL로 이어지는 경우도 여기 해당합니다.²

Task . finished with error [-1022] Error Domain=NSURLErrorDomain Code=-1022
"The resource could not be loaded because the App Transport Security policy
requires the use of a secure connection."

수정 후 서버 하나를 검증할 때는 nscurl이 유용합니다. ATS 예외를 여러 조합으로 바꿔 가며 접속해 어떤 요구 사항에서 실패하는지 좁혀 주므로, sysdiagnose 수집 과정을 처음부터 반복할 필요가 없습니다.³

수정 작업은 어떤 모습인가

점검을 마치면 도메인과 위반 항목의 목록이 남습니다. 이를 실제 서버 변경으로 옮기는 작업은 세 갈래로 나뉩니다.

가능한 곳은 TLS 1.3으로 옮기세요. 그러면 여러 위반 유형이 하나씩이 아니라 한꺼번에 해소됩니다. TLS 1.3 암호화 스위트는 모두 순방향 비밀성을 제공하므로 비-PFS 암호화 스위트 경고가 나올 수 없습니다. 확장 마스터 시크릿 요구 사항은 TLS 1.2에만 해당하므로 적용 대상에서 빠집니다. 서명 알고리즘 협상도 설계상 더 엄격합니다. Apple의 해결 방안 항목 역시 가능한 한 TLS 1.3을 협상하도록 서버를 업데이트하고, TLS 1.2를 최소선으로 두라고 안내합니다.²

TLS 1.2에 묶여 있다면 설정 세 가지가 대부분의 무게를 감당합니다. 첫째, 확장 마스터 시크릿 확장을 활성화하세요. 겉보기에 최신인 구성에서 가장 뜻밖에 걸리는 위반입니다. 둘째, 암호화 스위트 목록을 ECDHE 키 교환에 AES-128 또는 AES-256을 쓰는 조합으로 제한하세요. 순방향 비밀성 요구 사항과 대칭키 암호 요구 사항이 한 번에 해결됩니다.³ 셋째, 서버 우선순위 목록에서 rsa_pkcs15_sha1 서명 알고리즘을 제거하세요.

옛 설정에 묶여 있는 경우는 생각보다 흔합니다. TLS를 종료하는 로드 밸런서, 유지보수 계약이 걸린 하드웨어 장비, 임베디드 관리 컨트롤러 중 어느 하나가 최신처럼 보이는 환경에서 낡은 것을 협상하게 만드는 원인일 수 있습니다.

인증서 문제는 별도의 준비 기간이 필요합니다. 2048비트 미만 RSA, 256비트 미만 ECDSA, SHA-256보다 약한 알고리즘으로 해시된 리프 인증서는 모두 설정 변경이 아니라 재발급이 필요합니다. CA 발급 요청, 변경 작업 시간대 확보, 인증서 체인을 관리하는 담당자와의 조율이 뒤따른다는 뜻입니다. 기본 신뢰 평가는 앵커까지 체인 전체를 훑기 때문에 중간 인증서도 함께 확인하세요.³

일손을 덜어 주는 예외가 하나 있습니다. 신뢰 평가에 실패한 인증서가 자동 등록 프로파일의 앵커 인증서에 포함되어 있다면 별도의 조치가 필요 없다고 Apple은 명시합니다.² 티켓을 열기 전에 이 부분부터 확인하세요.

수정 사항은 전체 점검을 다시 돌리지 말고 하나씩 개별로 검증하세요. nscurl은 ATS 예외를 여러 조합으로 바꿔 가며 서버 하나에 접속하므로, 아직 어떤 요구 사항이 실패하는지 정확히 좁혀 줍니다.³ 벤더의 재배포를 기다리는 상황에서 반복할 때마다 sysdiagnose 전 과정을 돌리는 것은 지나치게 느린 순환입니다.

준비 기간이 중요한 이유

Apple은 서버 구성 업데이트가 “특히 외부 벤더가 관리하는 서버라면 상당한 시간이 걸릴 수 있다”고 직접 밝힙니다.²

이 문장이 27이 널리 배포된 뒤가 아니라 지금 점검을 돌려야 하는 이유입니다. 적용 범위에 드는 서버는 여러분 소유가 아닌 경우가 많습니다. MDM 벤더의 엔드포인트, 소프트웨어 배포 파트너, 등록 앞단에 놓인 ID 공급자 같은 것들입니다. 벤더가 TLS 1.2 엔드포인트에 EMS를 켜는 데 분기 단위가 걸린다는 사실을 10월에 아는 것과 8월에 아는 것은 전혀 다른 문제입니다.

점검 결과로 남는 것은 도메인 목록과 그 도메인에 접속한 프로세스 목록입니다. 벤더에게 보낼 것이 바로 이 목록이고, 이 구체성이 우선순위를 끌어올립니다. “귀사 서버가 Apple의 새 요구 사항을 충족하지 못합니다”는 뒤로 밀리기 쉽습니다. “이 도메인의 귀사 엔드포인트가 확장 마스터 시크릿 없이 TLS 1.2를 협상했고, OS 27은 이를 기기 등록 트래픽에서 차단합니다”는 그렇지 않습니다.

이번 릴리스의 다른 변경들과 형태가 같습니다. macOS 27은 교차 팀 컨테이너 접근을 거부하기 전에 더 이상 묻지 않게 되었고, 메뉴 항목 이미지는 이제 어떤 SDK에 링크했는지에 따라 달라집니다. 어느 경우든 플랫폼이 신호를 없애거나 기본값을 조였고, 실패는 전혀 다른 무언가의 모습으로 도착합니다. 여기서 그 “다른 무언가”는 응답 없이 멈춰 버린 기기 등록입니다.

핵심 정리

IT 관리자라면: - 점검은 26.4부터 26.x 사이에서 하세요. 27에서 테스트하면 첫 번째 실패에서 연결이 차단되고, 같은 작업 흐름의 이후 단계가 전부 가려집니다. - 테스트 전에 네트워크 진단 로깅 프로파일을 설치하고 기기를 재시동하세요. 그러지 않으면 로그로 서버를 특정할 수 없습니다. - 기기가 아니라 구성 조합을 기준으로 커버하세요. 환경, 기기 종류, 역할, 등록 방식마다 도달하는 서버가 다릅니다. - 벤더에게는 도메인, 프로세스, 구체적인 위반 항목을 함께 보내세요. 외부 서버의 준비 기간이 전체 일정을 좌우하는 제약입니다.

MDM 및 기기 관리 개발자라면: - SCEP 서버와 콘텐츠 캐싱 서버는 예외입니다. 여기에 점검 노력을 쓰지 마세요. - ATS FCPv2.1 위반은 일반 ATS 정책 위반과 별개이며, EMS 없는 TLS 1.2가 가장 놓치기 쉽습니다. - watchOS에서는 log 명령이 동작하지 않습니다. Watch 연결은 iOS 테스트로 커버하세요.

제목만 보고 들어온 모든 분께: - 여러분 앱의 URLSession 트래픽은 이번에 바뀐 대상이 아닙니다. 이 변경은 관리, 등록, 설치, 업데이트 트래픽을 처리하는 시스템 프로세스에 적용됩니다.

자주 묻는 질문

제 앱의 네트워크 요청에도 영향이 있나요?

아니요. 이번 변경은 MDM, DDM, 자동 기기 등록, 구성 프로파일 설치, 앱 설치, 소프트웨어 업데이트에 관여하는 시스템 프로세스에 적용됩니다.¹ App Transport Security는 iOS 9.0 및 macOS 10.11 SDK 시절부터 앱 네트워킹을 별도로 관장해 왔습니다.³

왜 굳이 낮은 OS 버전에서 점검해야 하나요?

27에서는 실패가 곧 차단이기 때문입니다. Apple은 요구 사항을 충족하지 않는 연결이 차단되며 “이렇게 실패한 연결 때문에 해당 작업 흐름의 후속 연결을 테스트하지 못할 수 있다”고 밝히고, 영향받는 모든 서버를 식별하려면 26.4 이상 27 미만에서 테스트하라고 권장합니다.² 그 버전대에서는 연결이 정상적으로 성공하면서 위반만 경고로 기록됩니다.

예외 대상 서버는 무엇인가요?

구성 프로파일을 설치하거나 DDM 자산을 확인하는 동안의 SCEP 서버, 그리고 앱 설치나 소프트웨어 업데이트 관련 자산을 요청하는 경우까지 포함한 콘텐츠 캐싱 서버입니다.²

제 서버는 유효한 인증서로 TLS 1.2를 씁니다. 그래도 실패할 수 있나요?

그렇습니다. FCP v2.1 검사에는 확장 마스터 시크릿 확장 없이 협상된 TLS 1.2, ClientHello에 알려지지 않은 알고리즘으로 서명된 인증서, rsa_pkcs15_sha1 서명 알고리즘이 포함됩니다.² 여기에 더해 ATS는 AES-128 또는 AES-256과 ECDHE를 통한 순방향 비밀성도 요구합니다.³

제 앱에서 NIAP 준수 모드를 켜면 뭔가 달라지나요?

아니요. 두 가지는 혼동하기 쉽지만 별개입니다. NSRequiresNIAPTLSPackageVersion은 규제 환경을 위해 여러분 앱 자체의 클라이언트 동작을 더 엄격한 FCP 모드로 전환하는 설정입니다.³ OS 27의 시스템 프로세스는 그와 무관하게 관리 트래픽에 자체 요구 사항을 적용합니다.

출처