Apple MDM에 VPN이 필요한가? 세 가지 접근 요구, 하나의 답
Apple MDM은 APNs와 기기에서 시작하는 HTTPS로 동작하며 LAN 터널을 쓰지 않습니다. VPN을 추가하기 전에 관리, 화면 공유, 사설 앱 접근을 나눠 보세요.
Apple 기기 관리에 암호화가 필요한지는 거의 질문이 되지 않습니다, 필요하기 때문입니다. 진짜 질문은 Mac이나 iPad를 관리할 수 있게 되기 전에 범용 VPN이 필요한지이며, 인터넷으로 관리하는 대부분의 배포에서 답은 아니오입니다. Apple은 기기가 자체 일정에 따라 관리 서비스에 도달하도록 허용하며, 중요한 트래픽은 데스크톱 세션이 아니라 서명된 명령 채널입니다. 그것이 통하는지는 세 가지 조건에 달려 있고, 밖에서 보면 모두 원격 접근처럼 보여서 쉽게 혼동됩니다.
전송 수단을 고르기 전에 요구를 이름 붙이세요
관리 명령과 구성 프로파일이 하나의 요구이고, 대화형 화면 공유가 두 번째이며, 사내 사설 앱에 도달하는 것이 세 번째입니다. 소유자도 인증도 다르고, 허용 가능한 노출도 크게 다른 경우가 많습니다. 이를 한데 묶으면 아무도 방어할 수 없는 공개 포트 목록이 남습니다.
세 가지 요구는 같은 전송 수단을 공유하지 않습니다:
| Need | What actually carries it |
|---|---|
| Management commands and profiles | The enrolled device pulls from a service it can reach; APNs only wakes it |
| Interactive screen sharing | A remote-support tool or private desktop path with its own authentication |
| Private application access | That application's permitted network path, which may well be a VPN |
혼란은 대개 오래된 서버 점검 목록에서 시작됩니다. 과거 OS X Server 문서는 긴 포트 목록을 제시하고, 관리 서비스가 그 안 어딘가에 있다는 이유로 누군가 경계에서 모두 전달해 버립니다. 그것은 관리 아키텍처가 아니며, 공개하려던 제어 평면보다 훨씬 넓게 노출 면을 확장합니다.
푸시 알림이 실제로 하는 일
Apple이 문서화한 흐름에서 관리 서버는 APNs 알림을 보내 기기에 작업이 대기 중임을 알립니다. 그다음 기기는 관리 서버로 연결을 열고 자신의 명령을 요청합니다. 푸시는 초인종이지 터널이 아닙니다, 임의의 페이로드도, 원격 데스크톱 세션도, 다른 앱의 트래픽도 운반하지 않습니다.
따라서 기기는 의도한 서비스에 등록되어 있어야 하고, 예상되는 엔드포인트를 신뢰해야 하며, 관리 서비스와 그 흐름이 의존하는 Apple 서비스 모두에 도달할 수 있어야 합니다. Apple의 네트워크 준비 지침이 그 의존 관계를 나열하며, 이는 흐름에서 협상할 수 있는 부분이 아닙니다. 사내 네트워크 안에만 있는 관리 서버에도 기기가 실제로 쓸 수 있는 지원되는 경로가 필요합니다. MDM이라고 부른다고 해서 도달할 수 없는 엔드포인트가 도달 가능해지지는 않습니다.
허용된 경로를 명시적으로 유지하세요, 중간에 있는 프록시와 TLS 검사 정책도 포함합니다. 예상된 인증서 체인을 깨는 검사 장비는 등록 실패와 똑같이 보입니다.
VPN이 틀린 답일 때
관리 서비스가 올바른 인증서로 인터넷에 공개되어 있고 기기가 모든 연결을 시작한다면, VPN은 제어를 더하지 않고 홉만 하나 더합니다. 기기는 이미 등록 ID로 인증하고, 서버는 이미 어떤 명령을 받을지 결정합니다. 그 앞에 터널을 두면 바뀌는 것은 네트워크 경로이지 신뢰 결정이 아닙니다.
같은 제어 평면은 VPN 프로파일 자체도 전달할 수 있습니다. 이 순서가 중요합니다: 관리되는 VPN 구성은 그저 또 하나의 페이로드로 도착합니다, 그래서 기기는 그 터널을 만드는 프로파일을 받기 전에 터널이 존재할 필요가 없습니다.
VPN이 맞는 답일 때
관리 엔드포인트가 인터넷에서 도달 가능해서는 안 되는 플릿도 있습니다, 그것은 용기 부족이 아니라 정당한 설계입니다. 규제 환경, 작은 사내 IT 팀, 다른 관리 인터페이스까지 호스팅하는 서버가 흔히 그렇게 됩니다. 그 경우 관리 서비스 앞의 보호된 접근 경로는 의도된 아키텍처이지 우회책이 아닙니다.
화면 공유와 사설 앱 접근도 보통 그 선의 같은 쪽에 속합니다. 둘 다 명령 채널보다 훨씬 많은 것을 노출하며, 둘 다 등록 ID에 편승하는 대신 자체 인증을 받을 자격이 있습니다.
복구를 깨는 부트스트랩 함정
제가 설계에서 대비할 실패는 이것입니다: 관리 서비스로 가는 유일한 경로가 VPN을 지나는데, 기기의 VPN 프로파일이나 자격 증명이 만료되었습니다. 기기는 대체 명령을 받으러 서버에 도달할 수 없고, 서버는 올라오지 않을 터널로 아무것도 밀어 넣을 수 없습니다. 복구는 이제 수백 마일 떨어져 있을지 모르는 사용자에게 달려 있습니다.
복구를 위한 두 번째 독립 경로를 유지하세요, 대역 외 관리 채널, 로컬 관리자, 또는 터널 없이도 도달 가능한 관리 서비스 중 하나입니다. 모든 것이 동작할 때 시험해 보세요, 사고 중에는 깨끗한 시험을 할 수 없습니다.
그다음 각 경로가 세 요구 중 무엇을 담당하는지 적고, 어느 것도 담당하지 않는 포트 전달을 제거하세요. 범용 터널 없이 관리할 수 있고, 터널이 망가졌을 때 다시 고칠 수 있는 플릿이야말로 설계할 가치가 있는 결과입니다.