Managed Device Attestation 살펴보기

♪ ♪ 안녕하세요, 저는 Bob Whiteman입니다 수석 iOS 디바이브 관리 엔지니어입니다 기업 및 교육 환경에서 관리되는 디바이스를 위한 중요한 새로운 보안 기능에 대해 공유하게 되어 기쁩니다 먼저 디바이스의 보안 환경을 검토해 보도록 하죠 사용자들은 웹사이트, 애플리케이션 서버 및 데이타베이스와 같은 조직의 리소스를 액세스해야 합니다 그리고 이 리소스들을 액세스하려는 공격자들도 있습니다 리소스 보호를 위한 전형적 모델은 경계보안입니다 관리자가 인트라넷 주변에 보안 경계를 갖추고 방화벽이나 VPN을 세워 합벅적인 클라이언트를 허용하고 위협을 거부하죠 그러나 이 모델은 현대 조직이 소통하는 방식에 뒤쳐져 있습니다 클라우드 서비스 제공업체는 리소스를 경계 외부에 보관합니다 위협은 경계 내부에서 시작될 수도 있습니다

그리고 위협은 합법적인 클라이언트가 경계를 관통할 수 있도록 스푸핑이 가능합니다

보다 현대적인 보안 모델은 네크워트 경계를 신뢰하지 않습니다 대신 각 리소스는 자체적인 신뢰 평가를 수행합니다 이것이 바로 제로 트러스트 아키텍처의 핵심입니다

신뢰 평가를 함수로 생각해 봅시다 클라이언트에 대한 태세 정보를 입력하면 출력은 액세스를 허용하거나 거부하는 결정을 의미합니다 정확한 신뢰 평가를 얻는 것이 매우 중요합니다 부정 오류는 사용자 활동에 지장을 초래하고 더 심각한 긍정 오류는 공격자가 리소스에 접근할 수 있도록 하죠 정확한 상태 정보를 얻는 것이 관건이라는 것을 뜻합니다 그럼 상태 정보의 일반적인 구성요소에 대해 알아보겠습니다 클라이언트 및 요청 사항의 모든 사용가능한 정보를 사용합니다 누가 요청하는지 어떤 디바이스를 사용중인지, 위치는 어디인지 등등 신뢰 평가를 활용하면 각기 다른 리소스에 접근 시 상태 내의 각기 다른 정보를 사용할 수 있습니다 보안 수준이 낮은 리소스에 접근 시 사용자의 신원만 요구할 수 있으며 중요한 인프라에 접근할 경우, 모든 상태 항목을 평가해야 할 수도 있습니다 어떤 세부 사항이 관련있는 지 결정은 조직에 달려 있습니다

상태의 한 가지 핵심 요소는 사용자의 ID입니다 요청을 수행하는 자가 누구인지 나타내는 것이죠

Apple 디바이스는 사용자 ID를 지원하기 위해 내장된 Kerberos 확장을 포함한 Extensible Single Sign On 기능은 앱, 웹사이트 및 계정에 필요한 사용자 인증을 용이하게 합니다 그리고 새로운 Enrollment Single Sign On 기능은 앱에서 사용자 등록 절차가 이루어지는 도중 및 이후에 사용자 인증을 용이하게 할 수 있습니다 이 세션은 사용자 ID에 관한 것이 아닙니다 디바이스 ID에 관한 것이죠 이 상태의 요소는 무슨 디바이스가 요청을 수행하는 지 나타냅니다

각 MDM 통신에서 디바이스가 보고하는 UDID는 MDM 서버가 관리 중인 디바이스를 파악하는 기본 방법입니다 DeviceInformation 쿼리는 일련번호를 포함한 디바이스의 MDM 서버 속성도 제공합니다 관리되는 디바이스는 종종 MDM 서버를 제외하고 조직 내부의 다른 시스템과 통신합니다 종종 MDM 서버는 다른 시스템에 대한 장치의 ID를 판단하는 클라이언트 인증서로 장치를 구성합니다 이 방법은 기기 식별에 그 동안 큰 도움이 되었지만 디바이스에 명시된 정보를 신뢰하는 것에 국한됩니다 환경이 변화하면서 더 많은 디바이스가 배포되면서 보안 요구 사항도 진화했습니다 이 문제 해결을 위해 디바이스의 ID를 증명하는 강력하고 새로운 방법을 공유하게 되어 기쁩니다 관리되는 디바이스 증명 Managed Device Attestation Managed Device Attestation을 사용하면 디바이스가 요청할 때 디바이스에 대한 강력한 증거를 제공합니다 상태 정보를 개선하기 때문에 이를 기반으로 한 신뢰도 평가가 보다 정확합니다 간단히 말해서, Managed Device Attestation은 합법적인 디바이스가 리소스에 안정적으로 접근하고 공격자는 저지된다는 것을 의미하죠 이 릴리스에서는 iOS 16, iPadOS 16 및 tvOS 16용 Managed Device Attestation을 제공합니다 이 세션에서는 새로운 증명 기능을 한 눈에 살펴보고, 이를 사용시 그 이점을 설명한 후, 구현을 위한 세부 정보를 살펴보겠습니다 첫째, 증명이란 무엇인가요? 증명은 사실을 명시하는 것이죠 주장하는 주체를 신뢰한다면 사실이 참이라고 인정하게 되죠 소프트웨어에서 증명은 암호로 서명된 사실입니다 이는 일반적으로 x.509 인증서입니다 서명인을 신뢰하면 사실이 참인 것을 인정하게 됩니다 Manage Device Attestation의 경우, 사실은 디바이스의 ID 및 기타 속성이며 서명인은 Apple입니다 디바이스 정보의 정확성을 인정하려면 Apple을 신뢰해야 하죠 그러나 Apple이 작성한 모든 코드 라인을 신뢰할 필요는 없습니다 Secure Enclave와 Apple의 제조 기록 및 운영 체제 카탈로그에 액세스하는 Apple의 증명 서버를 신뢰하기만 하면 됩니다 Apple 기기에 데이터를 보관하고 있다면 암묵적으로 이를 신뢰하는 것입니다 관리되는 디바이스에 증명을 가능케 하는 방법은 다음과 같습니다 Managed Device Attestation는 증명 인증서 사용에 두 가지 방법을 제공합니다 MDM 서버에서 증명의 이점을 활용할 수 있도록 Deviceinformation MDM 명령을 개선하였습니다 그리고 ACME 프로필 페이로드를 추가하여 자동 인증서 관리 환경 (ACME) 프로토콜에 대한 지원을 추가했습니다 이는 조직의 인프라 전체에서 증명의 이점을 활용할 수 있도록 합니다

DeviceInformation 증명의 경우, MDM 서버는 Deviceinformation 쿼리를 실행하고 몇 가지 새로운 키를 지정합니다 디아비스는 Apple 서버에서 증명을 가져와 MDM 서버로 반환합니다 그런 다음 MDM 서버가 증명을 평가하죠

그러나 주의해야 할 점은 DeviceInformation 증명은 MDM 서버에 "이 속성을 가진 장치가 존재합니다" 리고 표시합니다 MDM 서버가 현재 통신중인 장치가 동일한 장치인지 증명하지 않는 것이죠 이를 위해, ACME 페이로드 증명이 필요합니다

ACME 페이로드 증명은 가장 디바이스 ID에 대한 가장 강력한 증거를 제공합니다 ACME 페이로드가 포함된 프로필을 설치하면 디바이스가 조직 ACME 서버에서 인증서를 요청합니다 이는 SCEP 페이로드 설치와 매우 유사합니다 디바이스가 ACME 서버에 대한 증명을 제공하죠 이 강력한 디바이스 ID증명을 기반으로 ACME 서버는 조직의 나머지 서버가 신뢰하는 새로운 클라이언트 인증서를 발급합니다 이러한 두 가지 신기능은 증명 인증서를 활용하여 다음과 같은 몇가지를 증명합니다 디바이스가 정품 Apple 하드웨어인 점, 디바이스가 특정 장치인 점, 디바이스가 특정 속성을 보유한다는 점, 디바이스에 개인 키가 할당되었다는 점 그리고 같은 디바이스가 다른 서버들과 통신중이라는 점을 있다는 것을 증명합니다 이 증명이 어떤 혜택을 가져다 줄까요? 증명 보안 기능에 사용되므로 몇 가지 위협과 증명이 이를 경감시키는 방법을 알아보겠습니다

첫째, 침해된 디바이스는 속성에 거짓을 표시하므로 Apple은 속성을 증명합니다 OS가 손상을 입었더라도 이는 증명의 신뢰성에 영향을 미치지 않습니다 Secure Enclave가 손상되지 않기만 하면 되죠 침해된 디바이스는 이미 변경된 오래된 속성의 증명을 제공하기도 합니다 증명 내 nonce는 사실이 최신 상태임을 보장합니다 ACME 페이로드 증명은 다른 위협을 경감시킵니다 침해된 기기는 MDM 서버와 통신할 때 다른 기기의 ID를 전송합니다 따라서 Apple은 장치가 TLS연결을 인증하는 데 사용하는 클라이언트 ID와 연결된 방식으로 장치 ID를 증명합니다 이는 MDM 서버 및 기타 조직 서버에 통신 중인 장치를 증명합니다

또는 공격자가 합법적인 장치에서 개인 키를 추출하여 요청하는 데 사용하여 합법적인 장치를 스푸핑하면, Apple은 개인 키 내보내기 또는 가져오기에 대해 예외적으로 강력한 보호 기능이 있는 Secure Enclave로 개인 키가 보호됨을 증명합니다 마지막으로 공격자가 인증서 요청을 가로채 인증기관이 다른 장치에 대한 인증서를 발급하도록 할 경우, Apple 은 인증서 요청에 연결하는 방식으로 장치의 ID를 증명하므로, 인증 기관은 합법적인 장치에만 인증서를 발급합니다 증명은 여러 위협을 경감하는 보안 이점을 제공합니다 그럼 여러분의 환경에서는 어떻게 사용해야 할까요? Managed Device Attestation을 구현하는 방법에 대해 자세히 알아보죠 우선, DeviceInformation명령에 대한 향상된 기능을 꼽을 수 있습니다 MDM 서버는 관리되는 장치에 이 명령실행을 실행할 수 있습니다 이 요청에는 서버에게 필요한 속성 목록이 포함됩니다 새로운 속성을 추가했습니다, DevicePropertiesAttestation 이를 쿼리 배열에 추가하는 것은 MDM 서버에 증명을 요청한다는 것을 의미합니다 증명이 최신임을 확인하기 위해 MDM 서버는 DeviceAttestationNonce 키를 사용할 수 있습니다 이는 쿼리 키와 동일한 수준의 요청으로 표시됩니다 이 키는 선택사항입니다 그 값은 최대 크기 32바이트의 데이터 객체입니다 증명 요청의 예시를 하나 보여드리겠습니다 쿼리 배열에는 DevicePropertiesAttestation 키가 포함됩니다 그리고 32바이트의 논스가 있습니다 증명서 획득이 성공적이면 그 응답에 DevicePropertiesAttestation 키가 포함됩니다 그 값은 데이터 개체의 배열입니다 배열의 각 요소는 인증서 체인 내의 인증서입니다 이것이 예시 응답입니다 리프 인증서가 배열의 첫 부분에 나타나고 여기에는 사용자 정의 OID 내의 기기 속성을 포함합니다 처음 두 OID는 장치 식별 속성, 일련번호 및 UID입니다 MDM 등록이 사용자 등록일 경우 이들은 인증서에서 생략됩니다 나머지 OID는 익명이며, 모든 등록 유형에 사용가능합니다 sepOS 버전은 Secure Enclave에서 실행되는 운영체제의 버전을 의미합니다 그리고 논스 OID에 올바른 값이 있으면 인증서가 방금 생성되었음을 증명합니다 MDM 서버가 증명을 수신하면 다음의 순서에 따라 신중하게 검증해야 합니다 인증서 체인이 예상되는 Apple 인증기관에 근거를 두고 있는지 확인합니다 Apple 인증기관은 Apple Private PKI 저장소에 있습니다 리프 인증서의 논스가 지정된 경우 DeviceInformation 요청의 논스와 일치하는지 확인합니다 그런 다음, 나머지 OID를 구문 분석하고 해당값을 평가합니다 새 증명을 생성하면 장치와 Apple 서버에서 상당한 리소스를 사용하므로 새 증명 인증서를 요청할 수 있는 빈도에 대한 비율 제한이 있습니다 현재는 7일마나 하나의 새로운 증명이 가능합니다 새로운 논스를 지정하여 새로운 증명을 요청합니다 논스를 생략하는 것은 신선도가 문제가 되지 않다는 것을 의미해 기기에서 가장 최근의 증명을 대신 반환할 수 있습니다 그리고 논스가 지정되고 캐시된 증명과 일치하는 경우, 캐시된 증명이 반환됩니다 MDM 서버가 증명서 내 논스의 유효성을 검사할 때 일치하지 않는 nonce를 감지하고 이것이 캐싱으로 인해 예상되었는지의 여부를 결정해야 합니다 그러나 비율 제한이 있다고 7일마다 새로운 증명을 요청해서는 안됩니다 그것은 자원 낭비는 물론이고 MDM 서버 장치 속성의 변경 사항을 발견하는 속도만 지연됩니다 대신, OS 버전과 같은 다른 DeviceInformation 속성의 관련 변경 사항을 모니터링하세요 이러한 변경 사항 중 하나가 변경되면 새로운 증명을 요청하십시오 이렇게 하면 비율 제한이 만료될 때까지 기다릴 필요 없이 가능한 한 빨리 증명을 업데이트할 수 있습니다 그리고 디바이스가 침해되고 기타 속성에 대해 거짓된 정보를 담고 있는 경우에 대비해 장치를 정직하게 유지하려면 새로운 증명에 대한 무작위 증명을 종종 요청하십시오 증명 요청에 실패할 수 있습니다 이 경우, 장치는 여전히 응답하지만 일부 정보는 생략됩니다 DevicePropertiesAttestation 필드가 응답에서 생략되었거나 예상되는 OID 또는 해당 값이 생략되었을 수 있습니다 실패에는 여러가지 잠재적 이유가 존재합니다 장치에서 Apple의 증명 서버에 도달하는 네트워크 문제가 발생할 수 있습니다 100% 가동되는 서버는 없으므로 Apple의 증명 서버에 문제가 있을 수도 있습니다 또는 장치 하드웨어 또는 소프트웨어가 손상되었거나 정품 Apple 하드웨어가 아닐 수도 있습니다 이 마지막 세 가지 경우에서 Apple의 증명 서버는 확인 불가능한 속성에 대한 증명서 발급을 거부합니다 증명 실패의 다양한 원인은 무해한 네트워크 결함에서 적극적인 공격에 이르기까지 다양합니다. 불행히도 MDM 서버가 정확한 원인을 알 수 있는 신뢰할 수 있는 방법은 없습니다. 왜냐하면 오류에 대한 정보의 유일한 소스가 거짓말을 하는 장치가 손상된 장치일 수도 있기 때문입니다. 그렇다면 MDM 서버는 실패를 어떻게 해석해야 할까요? 증명이 실패했다고 항상 최악의 상황을 가정할 필요는 없습니다 제로 트러스트 아키텍처의 경우 처리 방법은 다음과 같습니다 조직은 실패하거나 예기치 않게 오래된 증명으로 해당 점수를 낮추는 장치에 대한 신뢰 점수를 계산합니다 신뢰 점수가 하락되면 서비스에 대한 액세스 거부, 수동 조사를 위한 장치에 플래그 지정, 장치를 지우고 인증서를 취소하여 문제를 해결하는 것과 같은 다양한 작업을 트리거하게 됩니다 이는 증명이 실패할 경우 적절한 응답을 보장합니다 그럼 ACME 페이로드 증명의 구현에 대해 알아봅시다 ACME 페이로드 설치에는 여러 단계가 포함됩니다 먼저 프로세스 내 여러 참가자와 각 단계에 대해 설명드리겠습니다 iPhone, iPad 또는 Apple TV부터 시작하죠

대부분의 경우 이것은 MDM 서버에서 관리합니다 ACME 서버 한 대가 있고요 이는 ACME 프로토콜인 RFC 8555를 구현하므로 조직 인증 기관으로부터 클라이언트 인증서를 발급할 수 있습니다 그리고 증명서를 발행하는 Apple의 증명 서버가 있습니다

첫 번째 단계는 MDM 서버가 ACME 페이로드를 포함하는 프로필을 설치하는 것입니다 페이로드는 장치가 생성할 키의 속성, 장치가 요청할 인증서의 속성 및 ACME 서버에서 인증서를 요청하는 방법을 지정합니다 프로필 설치를 시작하기 위해 장치는 요청된 유형의 키를 생성합니다 증명을 사용하려면 키가 하드웨어에 바인딩되어야 합니다 ACME 페이로드는 RSA와 다양한 크기의 키를 지원하지만 하드웨어에 바인딩된 키를 얻으려면 ECSECPrimeRandom을 사용해야 합니다 최선의 선택은 ECSECPrimeRandom 384비트 키입니다 그것이 가장 보안이 높은 하드웨어 바인딩된 키이기 때문이죠 키가 생성되면 장치가 ACME 서버와 초기 연결을 수행합니다

장치는 ACME 서버와 통신하는 나머지 프로세스에 사용할 URL을 지정하는 DirectoryURL을 요청합니다 그런 다음 두 시스템이 계정과 주문을 생성합니다 서버는 device-attest-01 유효성 검사 유형을 제공합니다 그러면 ACME 서버는 nonce를 생성하여 토큰 필드에 있는 장치로 보냅니다 ACME 프로토콜은 처음에 서버 인증서를 발급하는 데 사용되었습니다 그러나 여기에서 우리가 사용하는 검증 유형은 증명을 수신하고 클라이언트 인증서를 발행하기 위한 ACME 프로토콜의 확장을 지정하는 IETF 초안으로 도입되었습니다

증명은 선택사항이죠 페이로드가 증명을 지정하면 장치가 Apple에 증명을 요청합니다 이것은 DeviceInformation 증명과 거의 동일합니다 동일한 OID를 사용하며 장치 식별 OID는 사용자 등록에 생략됩니다 그러나 몇 가지 차이점이 있습니다 nonce는 증명에 포함하기 전에 SHA-256을 사용하여 해시됩니다 nonce는 MDM 서버가 아닌 ACME 서버에서 가져옵니다 그리고 증명 리프 인증서와 일치하는 개인 키는 장치에서 방금 생성한 것입니다 증명 인증서는 개인 키와 일치하지만 해당 인증서는 증명 이외의 용도로 사용할 수 없습니다 따라서 장치는 ACME 서버에서 개인 키와 일치하는 다른 인증서를 요청하고 이 인증서는 TLS에 적합합니다

치는 페이로드의 인증서 요청 속성이 포함된 인증서 서명 요청을 제공합니다 증명 체인을 제공하죠 그리고 ACME 페이로드에서 ClientIdentifier를 제공합니다 일반적으로 이것은 반복 요청을 방지하기 위해 단일 인증서 발급에 적합한 티켓처럼 사용됩니다 ACME 서버는 인증서를 발급하기 전에 이 순서대로 요청을 신중하게 검증해야 합니다 ClientIdentifier의 유효성과 미사용여부를 확인해야 합니다 증명 인증서는 올바른 Apple CA에 연결되어야 합니다 증명 리프 인증서의 공개 키는 CSR과 일치해야 합니다 nonce는 ACME 서버가 이전에 보낸 SHA-256 해시와 일치해야 합니다 그런 다음 ACME 서버는 나머지 OID를 평가할 수 있습니다 그리고 증명이 실패할 수 있다는 것을 명심하세요 DeviceInformation 사례에서 실패한 증명을 검토했듯이 ACME 서버는 인증서를 발급할 때 실패를 신중하게 고려해야 합니다 여기서부터 일사천리로 진행되죠 ACME 서버가 조직 CA에서 클라이언트 인증서를 발급하고 이를 장치로 반환합니다

ACME 서버는 클라이언트 인증서 발급을 위한 최종 권한입니다 SubjectAltName과 같은 CSR의 속성을 존중하거나 무시하도록 선택할 수 있습니다 장치가 키 체인에 인증서를 저장하면 ACME 페이로드 설치가 완료됩니다

자 이 모든 것을 연결해 봅시다 서버는 통신중인 장치가 실제 주장하는 장치인지 어떻게 알 수 있을까요? 장치는 Apple에서 증명을 받을 때, ACME 서버에서 클라이언트 인증서를 받을 때, TLS를 사용하여 다른 서버와 통신할 때 등 여러 가지 방법으로 동일한 개인 키를 사용합니다 키가 하드웨어에 바인딩되어 있기 때문에 이 모든 작업이 동일한 장치에서 수행되었다는 것을 알고 있습니다 그리고 그 장치를 설명하는 증명 인증서가 있죠 이 모두를 결합하여 조직 서버는 이제 액세스 권한을 부여할 때 장치의 ID를 신뢰할 수 있습니다

인증서 및 SCEP 페이로드와 마찬가지로 프로필의 다른 페이로드는 인증서를 사용하기 위해 ACME 페이로드를 참조할 수 있습니다 MDM, Wi-Fi, VPN, Kerberos 및 Safari에 사용가능합니다 이 모든 시스템은 증명의 혜택을 얻습니다

하나의 장치가 동시에 설치된 증명을 사용하는 최대 10개의 ACME 페이로드를 가질 수 있습니다 동일한 장치로 복원하는 경우에도 관리 대상 장치의 백업이 복원되면 하드웨어 바인딩 키는 보존되지 않습니다 그리고 Managed Device Attestation으로 다른 작업을 수행하지 않는 경우 MDM 클라이언트 ID에 ACME 페이로드를 사용하여 MDM 서버가 관리중인 장치를 확인할 수 있습니다 마무리하겠습니다 Managed Device Attestation을 사용하여 다양한 종류의 위협을 수습합니다 DeviceInformation 증명을 활용하여 더 나은 신뢰 평가를 위해 상태의 장치 ID 구성 요소를 개선합니다 그리고 이제 ACME 증명을 사용하여 조직 리소스에 액세스할 때 장치의 ID를 증명할 수 있습니다 Managed Device Attestation의 구현을 기대합니다 우리가 함께하면 장치 배포 시 보안을 향상시킬 수 있습니다 감사합니다, 즐거운 WWDC를 보내시기 바랍니다