-
App Attest로 앱 보호하기
App Attest를 활용하여 앱을 무단 수정 및 사기로부터 보호하세요. 공격자들이 수정된 앱을 악용하여 데이터를 스푸핑하고 보안 검사를 우회하는 방법과 App Attest가 이러한 위협을 방어하는 방법을 알아보세요. Secure Enclave에 바인딩된 App Attest 키를 생성 및 관리하고, 증명 및 어설션을 검증하며, 사기 지표를 사용하여 악용을 감지하는 방법을 알아보세요. iOS 27에 추가된 새로운 신호들을 포함하여, 모든 Apple 플랫폼에서의 모범 사례를 알아보고 검증을 강화하세요.
챕터
- 0:00 - Introduction
- 1:35 - Protections
- 4:04 - Availability
- 5:02 - Key generation
- 6:12 - Attestation
- 12:10 - Assertion
- 14:58 - Common pitfalls
- 16:27 - Fraud metric
- 19:07 - Next steps
리소스
-
비디오 검색…
안녕하세요, 저는 Manthan입니다 Trust and Safety 팀의 엔지니어입니다 오늘은 App Attest가 앱과 사용자를 보호하는 방법을 알아보겠습니다 여러분은 앱을 빌드하고 배포하여 안전한 환경에서 Apple 플랫폼에서 작동하도록 했습니다 사기꾼들은 항상 앱을 악용할 방법을 찾고 있습니다 원래 의도된 기능을 넘어서 말이죠 변조된 앱 복사본이 서버에 유효해 보이는 요청을 보내 민감한 데이터에 접근하는 공격 시나리오도 있습니다 예를 들어, 학생들이 퀴즈를 풀고 답을 제출하는 퀴즈 감독 앱을 만들었다고 가정해 보세요 사기꾼이 앱을 리버스 엔지니어링하여 조작된 퀴즈 답변을 서버에 제출하는 변조 복사본을 만들 수 있습니다 App Attest는 서버가 변조된 클라이언트의 이러한 요청을 거부하도록 도와줄 수 있습니다 또한 사기꾼이 여러분이 배포하지 않은 콘텐츠를 앱에 추가할 수도 있습니다 소스 코드의 변조된 복사본을 직접 수정하거나 관련 리소스 번들을 수정하고 앱을 재서명하여 변조된 복사본을 기기에서 실행할 수 있습니다 예를 들어 드래곤 슬레이어 게임이 있다고 해봅시다 사기꾼이 치트 메뉴를 삽입해 게임 내 능력을 강화시킵니다 그러면 변조된 게임 앱으로 서버에 조작된 점수를 제출하고 리더보드에서 순위를 높일 수 있습니다 App Attest는 이러한 유형의 위협 시나리오를 해결하도록 설계되었습니다 App Attest가 무엇을 보호하는지 먼저 설명하고 통합 단계와 모범 사례를 안내해 드리겠습니다 일반적인 실수도 짚어보고 사기 지표에 대해서도 의심스러운 증명 활동을 감지하는 강력한 도구와 함께 마무리하겠습니다 먼저 App Attest가 앱을 보호하는 방법부터 시작합니다 App Attest는 앱이 실제 Apple 하드웨어에서 실행되고 있는지 확인하는 데 도움을 줍니다 증명을 발급함으로써 이를 수행하며 이는 암호화된 증거를 제공합니다 사용자 기기에서 실행 중인 앱의 유효성에 대한 것입니다 그런 다음 서버에서 이를 확인할 수 있어 앱이 안전한 Apple 기기에서 실행 중임을 보장받을 수 있습니다 다음으로, 사용자 기기에서 앱이 변조되었는지를 알 수 있도록 도와줍니다 App Attest는 신뢰 당사자에 대한 정보를 제공합니다 앱과 관련된 실행 카테고리 및 번들 버전 정보도 포함됩니다 이 모든 정보로 앱이 변조되었는지 확인할 수 있습니다 앱은 신뢰 당사자 식별자를 통해 고유하게 식별됩니다 이는 Apple 개발자 프로비저닝 프로파일의 팀 식별자와 앱의 번들 식별자를 연결한 것입니다 사기꾼이 앱을 변조하여 팀 식별자와 일치하지 않는 프로비저닝 프로파일로 재서명한다고 해봅시다 App Attest는 사용자 기기의 앱 ID를 표면에 드러내어 무단 변조를 발견할 수 있도록 해줍니다 iOS 27의 새로운 기능으로 사용자 기기에서 앱의 실행 유효성 카테고리를 강조 표시합니다 App Store를 통해 앱을 배포했는데 App Attest가 TestFlight 실행 유효성 카테고리를 표시할 수 있습니다 또한 배포한 앱 버전의 번들 버전도 식별합니다 사기꾼이 알 수 없는 업데이트된 번들 버전으로 앱을 재서명하면 App Attest를 통해 이를 투명하게 확인할 수 있습니다 마지막으로, App Attest를 사용하여 앱에서 서버로 전송되는 페이로드를 보호할 수 있습니다 App Attest는 어설션을 생성할 수 있습니다 이전에 발급된 증명의 암호화 속성을 사용하여 서버는 앱에서 전송된 페이로드의 어설션을 확인하여 전송 중에 페이로드가 변조되지 않았음을 보장합니다 이러한 내용을 바탕으로 App Attest의 작동 방식과 적용 방법을 알아보겠습니다 App Attest의 핵심 구성 요소 각각을 살펴보겠습니다 App Attest를 사용할 수 있는 위치를 확인하는 것부터 시작합니다 App Attest는 모든 Apple 플랫폼에서 지원됩니다 이전에는 지원되지 않았던 macOS 27 이상도 포함됩니다 App Attest는 모든 주요 Apple 운영 체제에서 사용 가능하지만 해당 플랫폼의 모든 앱 유형에서 사용 가능한 것은 아닙니다 App Attest 프레임워크의 isSupported API를 통해 App Attest 사용을 제어하세요 예를 들어 App Attest는 Action 및 SSO 앱 확장에서는 사용 가능하지만 다른 유형의 앱 확장에서는 사용할 수 없습니다 isSupported 응답을 사기 신호로 활용할 수도 있습니다 이를 위험 평가에 통합하여 사용하세요 지원되는 플랫폼에 앱을 배포했는데 특정 사용자로부터 지원되지 않는다는 응답이 급증한다면 변조의 징후일 수 있습니다 App Attest가 지원되지 않을 때 사용자가 계속 진행할 수 있는지 앱 기능을 사용할 수 있도록 허용할지 결정해야 합니다 App Attest 워크플로의 첫 번째 단계인 키 ID 생성으로 넘어가겠습니다 앱은 App Attest를 호출하여 키 ID를 생성하는 것으로 시작합니다 App Attest는 앱을 대신하여 Secure Enclave에 바인딩된 키 쌍을 생성하며 개인 키는 Secure Enclave에 보관됩니다 App Attest는 공개 키의 해시를 앱에 반환합니다 앱은 키 ID를 Keychain에 저장합니다 App Attest 키를 다룰 때 몇 가지 모범 사례를 기억하세요 계정 기반 앱의 경우 사용자당 키 1개를 생성하거나 사용자 기기의 전체 앱에 키 1개를 사용하세요 사용자들 간에 키를 공유하지 마세요 Keychain을 사용하여 앱에서 생성한 키 ID를 저장하세요 키 ID는 앱이 설치된 동안 유지됩니다 앱 업데이트 후에도 유지되지만 사용자가 앱을 재설치하거나 기기를 복원하면 iCloud 백업에서 복원하는 경우를 포함하여 키가 무효화됩니다 키는 기기별로 생성되며 사용자 기기 간에 동기화되지 않습니다 App Attest 키 생성에 대한 설명은 여기까지입니다 이는 증명과 어설션의 기반을 형성합니다 앱이 키 ID를 생성했다면 App Attest에 키 증명을 요청할 수 있습니다 앱은 Keychain에서 키 ID를 가져옵니다 앱은 서버에 키 ID에 대한 증명 수행을 요청합니다 서버는 앱에 챌린지를 발급하여 증명에 포함하도록 응답합니다 앱은 증명 API를 호출합니다 App Attest 프레임워크에서 키 ID와 서버 챌린지를 제공합니다 App Attest는 키 ID에 대한 키 쌍을 가져옵니다 기기의 일부 증명 데이터와 함께 이 증명 데이터는 Secure Enclave에서 파생됩니다 부팅 시 기기의 하드웨어 속성 스냅샷이 포함되어 있습니다 수정할 수 없습니다 Apple 서비스에 서버 요청을 시작하여 기기 데이터를 검증하고 증명을 반환합니다 App Attest는 앱에 증명 객체를 반환합니다 앱은 서버에 증명을 보냅니다 서버는 증명을 검증해야 합니다 이에 대해서는 다음에 설명하겠습니다 저장하고 앱 사용자와 연결하세요 증명을 수집하고 처리할 때 기억해야 할 몇 가지 모범 사례가 있습니다 서버가 증명 시작을 제어하는 것이 중요합니다 이를 통해 앱이 안전한 초당 요청 수 상한 내에서 유지되도록 할 수 있습니다 증명 실패가 발생할 수 있으므로 앱은 나중에 다시 시도해야 합니다 전역 속도 제한에 걸리지 않도록 지수 백오프 방식을 구현하세요 앱에 재시도 로직을 하드코딩하지 마세요 Apple 증명 서버에 대한 제어 불가능한 트래픽 급증을 최소화하기 위해서입니다 앱은 사용자 흐름 외부에서 증명을 수집해야 합니다 백그라운드 작업에서 증명 작업을 수행하세요 마지막으로, 증명은 앱이 아닌 항상 서버에서 검증해야 합니다 앱이 변조되면 증명 검증을 신뢰할 수 없습니다 이제 증명 자체에 대해 살펴보겠습니다 이는 App Attest 증명 API에서 반환되는 객체입니다 증명 구조는 세 가지 섹션으로 구성됩니다 형식, 증명 문, 그리고 인증자 데이터입니다 형식은 Apple 익명화 증명을 식별하는 고정 문자열입니다 다음으로, 증명 문은 암호화 인증서 체인과 영수증을 포함합니다 인증서 체인은 증명된 키가 실제 Apple 하드웨어에서 생성되었음을 증명합니다 개발자 문서를 따라 인증서 체인을 검증하세요 이에는 nonce, 키 ID가 포함되어 있으며 리프 인증서에 포함된 신뢰 당사자 식별자도 포함됩니다 macOS 27 이상에서는 키 접근 제어 속성인 ACL Blob OID도 리프 인증서에 포함됩니다 이는 App Attest 키와 관련된 보안 조건을 나타냅니다 기기에서 증명이 수집될 때 Secure Enclave가 적용한 조건들입니다 키 접근 제어 속성은 모든 플랫폼에서 사용 가능하지만 macOS에서 특히 중요합니다 macOS에서 App Attest는 생성된 각 키를 구성하여 전체 보안 모드와 System Integrity Protection을 요구하는 정책을 적용합니다 전체 보안 모드는 최고 수준의 보안을 보장하고 확인합니다 사용자 기기의 운영 체제 무결성도 검증합니다 System Integrity Protection은 무단 코드 실행을 방지하고 시스템 경로를 보호합니다 두 가지 모두 Mac 기기에서 기본적으로 활성화되어 있습니다 키 접근 제어 속성을 검증하면 사용자 기기에 적용된 보안 조건을 확인할 수 있습니다 증명 문에는 영수증도 포함되어 있습니다 App Store 영수증과 유사한 형식으로 개발자 문서를 따라 파싱하세요 신뢰 당사자 ID, 증명된 키, 그리고 서버 챌린지를 검증해야 합니다 이는 영수증에 포함되어 있습니다 서버는 사기 지표와 연동하기 위해 이 영수증을 저장해야 합니다 마지막으로, 인증자 데이터는 앱과 증명에 대한 정보를 식별합니다 개발자 문서를 따라 인증자 데이터를 언패킹하고 내용을 검증하세요 iOS 27 이상에서는 인증자 데이터 끝에 확장이라는 새로운 구조가 추가됩니다 이는 웹 인증 표준에 따라 형식이 지정됩니다 인증자 모델에 대한 것입니다 확장에 대해 잠시 설명하겠습니다 서버가 인증자 데이터의 이 섹션을 어떻게 처리해야 하는지도 설명합니다 확장은 앱에 대한 추가 보안 속성을 설명합니다 증명 과정에서 기기에서 수집된 속성입니다 두 가지 확장 식별자가 추가되었습니다 실행 유효성 카테고리와 번들 버전입니다 실행 유효성 카테고리는 앱이 예상치 못한 환경에서 실행되고 있는지 파악하는 데 도움을 줍니다 번들 버전은 배포한 앱 버전이 사용자 기기에서 실행되고 있는지 확인하는 데 도움을 줍니다 이러한 속성을 모니터링하고 예상치 못한 값을 확인하여 사용자에 대한 전반적인 위험 평가에 반영하세요 증명에 대한 설명은 여기까지입니다 변조 징후를 감지하는 데 특히 유용합니다 예를 들어, App Attest가 통합된 macOS 앱이 있다고 합시다 사기꾼이 System Integrity Protection을 비활성화하는 시나리오를 생각해보세요 그런 다음 앱을 수정하고 다른 프로비저닝 프로파일로 재서명합니다 그리고 시스템 경로의 App Attest 프레임워크를 수정합니다 서버가 받은 증명은 비활성화된 System Integrity Protection 상태를 키 접근 제어 속성을 통해 표시합니다 수정된 팀 식별자도 포함될 수 있습니다 실행 유효성 카테고리나 번들 버전도 마찬가지입니다 서버는 변조된 앱 복사본과의 통신을 거부할 수 있으며 이를 사용자 위험 평가에 반영할 수 있습니다 서버가 증명을 검증하고 공개 키를 저장했다면 앱은 해당 증명된 키를 사용하여 어설션을 통해 지속적인 통신을 보호할 수 있습니다 앱은 서버와 일부 데이터를 주고받을 준비를 합니다 서버는 앱의 페이로드에 포함할 챌린지를 발급합니다 앱은 키 ID를 가져옵니다 App Attest 프레임워크에서 어설션 API를 호출합니다 키 ID와 서버 챌린지를 제공합니다 App Attest는 인코딩된 어설션 객체를 앱에 반환합니다 앱은 어설션 객체를 페이로드에 포함합니다 그리고 페이로드를 서버에 전송합니다 서버는 어설션을 검증하고 페이로드 내용을 수락하거나 거부합니다 앱이 어설션을 생성할 때 몇 가지 중요한 사항을 염두에 두세요 필요할 때 요청에 따라 생성하세요 어설션은 기기에서 로컬로 생성됩니다 Apple 서버를 거치지 않습니다 앱 생명주기에서 필요한 시점에 생성할 수 있습니다 서버 페이로드에 포함하기 위해서입니다 어설션은 CPU에 영향을 줍니다 어설션 생성에는 암호화 작업이 포함됩니다 어설션을 빠르게 생성하거나 앱 생명주기 내에서 너무 많이 생성하지 않도록 주의하세요 서버는 어설션 내에 포함된 카운터 속성을 검증하여 엄격히 증가하는지 확인해야 합니다 서버는 사용자와 연결된 어설션의 카운터를 추적해야 합니다 이는 재전송 공격 방지 기능을 제공합니다 앱이 어설션을 포함할 때마다 어설션 객체의 카운터 값이 증가해야 합니다 카운터 값이 일정하거나 감소하는 것이 관찰되면 변조된 앱 복사본의 징후일 수 있습니다 서버에 기록된 카운터 값을 인식하지 못하는 복사본입니다 이제 어설션 객체 언패킹에 대해 간략히 설명하겠습니다 어설션은 두 섹션으로 구성된 구조체입니다 서명과 인증자 데이터입니다 개발자 문서를 따라 인증자 데이터를 사용하여 서명을 검증하세요 증명 객체의 서버 챌린지와 공개 키도 사용합니다 증명과 유사하게 어설션 객체의 인증자 데이터는 어설션 시점의 앱에 대한 정보를 식별합니다 iOS 27 이상에서는 인증자 데이터 끝에 새로운 구조가 추가됩니다 확장이라고 합니다 증명 객체의 인증자 데이터에 있는 확장과 동일한 방식으로 처리해야 합니다 어설션에 대한 설명은 여기까지이며 App Attest의 핵심 부분도 마무리됩니다 어설션은 유효한 앱 복사본에서 서버 요청을 보장하는 데 특히 유용합니다 다음으로, 주목할 만한 몇 가지 일반적인 실수를 알아보겠습니다 서버는 앱의 의심스러운 활동 시나리오를 신중하게 처리해야 합니다 기존 사용자에 대한 새로운 증명 처리 사례를 고려해보세요 앱 재설치나 기기 복원 같은 정당한 시나리오에서는 키 교체가 발생할 수 있으므로 새 키를 즉시 거부하지 마세요 이는 또한 사용자의 이전 증명 키를 즉시 무효화하지 말라는 의미입니다 사기 지표와 결합하면 사용자에 대한 서버의 증명 맵을 사기 또는 악용 신호로 사용할 수 있습니다 서버가 증명이나 어설션을 거부하면 앱은 이를 적절히 처리해야 합니다 사용자의 App Attest 관련 기능을 제한하세요 강화된 모니터링과 함께 사용자에게 제한된 접근을 허용하세요 포괄적인 위험 평가 없이 사용자를 직접 차단하지 마세요 잠시 설명할 것이 있습니다 사용자에 대한 위험 평가가 무엇을 의미하는지입니다 이는 비즈니스, 배포하는 앱의 유형에 따라 그리고 앱에서 잠재적인 사기의 영향에 따라 달라집니다 App Attest 기반으로 사용자의 사기 활동이 의심되면 사용자 비활성화 또는 정지에 대한 비즈니스 가이드라인을 따르세요 적절한 평가 없이 사용자를 차단하면 신뢰가 손상될 수 있으며 정당한 사용자에게 영향을 줄 수 있습니다 항상 잘 정의된 위험 평가 프로세스를 따르세요 이제 App Attest의 핵심 흐름에 대해 광범위하고 깊이 있는 이해를 갖추었고 최적으로 상호작용하는 방법도 알게 되었습니다 마지막으로 다룰 App Attest 부분은 사기 지표입니다 의심스러운 증명 활동을 감지하는 도구입니다 변조된 기기는 여전히 증명을 통과하고 브로커 역할을 할 수 있습니다 다른 기기에서 실행 중인 변조된 앱 인스턴스를 대신하여 유효한 증명을 생성합니다 다른 기기에서 실행되는 것들입니다 이러한 변조된 앱은 서버에 변조된 요청을 보낼 수 있습니다 사기 지표는 고유하게 증명된 키의 대략적인 개수를 제공합니다 지난 30일 동안 특정 기기에서 앱과 연결된 키의 수입니다 이를 사용자의 위험 평가 프로파일의 일부로 활용할 수 있습니다 잠재적으로 변조된 기기의 증명과 연결되어 있는지 확인하여 판단하는 데 도움이 됩니다 사기 지표는 서버와 App Attest 데이터 서버 사이에서 접근됩니다 서버는 사용자와 연결된 증명에서 영수증을 검색합니다 그런 다음 App Attest 데이터 서버에 POST 요청을 보냅니다 검색된 영수증을 사용하여 그러면 데이터 서버는 서버에 영수증을 반환합니다 사기 지표가 포함된 영수증으로 이후 영수증 조회에 사용해야 합니다 영수증은 App Store 영수증과 유사하게 구성됩니다 세 가지 섹션으로 구성됩니다 서명, 인증서 체인, 그리고 영수증 페이로드입니다 서명은 영수증 페이로드를 서명합니다 인증서 체인은 Apple 인증 기관에 뿌리를 두고 있습니다 영수증 페이로드에는 정보가 포함됩니다 지표와 연결된 증명된 키에 대한 정보와 사기 지표 자체입니다 개발자 문서를 따라 이 영수증 페이로드의 다양한 부분을 확인하세요 위험 지표 필드는 사기 지표 횟수를 정의합니다 영수증도 갱신해야 합니다 not before 필드는 갱신 가능한 가장 이른 시점을 나타냅니다 만료 시간 필드는 영수증이 만료되는 시점을 나타냅니다 만료 후에는 더 이상 갱신할 수 없습니다 사기 지표를 사용할 때 다음 사항을 고려하세요 App Attest 키 교체와 관련된 사용자 단계는 사기 지표에 영향을 줍니다 예를 들어 앱을 재설치하거나 기기를 복원하면 앱 내에서 키 생성과 재증명이 강제될 수 있습니다 이는 사기 지표에 영향을 줄 수 있습니다 사기 지표를 사용하여 사용자를 앱에서 직접 차단하는 것을 피하세요 사기 지표를 사기 활동 조사 신호로 취급하세요 값을 모니터링하고 기준선을 분석하여 급증을 의심스러운 활동의 지표로 식별하세요 이제 App Attest로 앱의 워크플로를 보호하는 데 필요한 모든 것을 갖추었습니다 사용자를 안전하게 하고 앱을 보안하세요 계속 학습하려면 최신 SDK로 앱을 다시 빌드하여 App Attest API의 최신 기능을 활용하세요 앱에서 영역을 파악하세요 증명의 보안으로 도움을 받을 수 있는 영역입니다 인증 흐름이나 프리미엄 콘텐츠의 민감한 페이로드처럼 어설션으로 강화할 수 있는 부분입니다 서버를 설정하여 증명을 검증하고 영수증을 저장하고 어설션 카운터를 추적하세요 사기 지표를 위험 평가 파이프라인에 통합하세요 App Attest는 앱의 무결성을 검증하는 도구를 제공합니다 앱과 서버 간의 통신을 보호하고 사기 징후를 감지합니다 모두 Apple 하드웨어의 보안을 기반으로 합니다 이제 이러한 보호 기능을 사용자를 위해 활용하세요 시청해 주셔서 감사합니다!
-
-
5:07 - Generate a Secure Enclave–bound key
import DeviceCheck let keyID = try await DCAppAttestService.shared.generateKey() -
6:32 - Attestation API
import DeviceCheck let keyId: String = ... let clientDataHash: Data = ... let attestation = try await DCAppAttestService.shared.attestKey(keyId: keyId, clientDataHash: clientDataHash) -
12:33 - Assertion API
import DeviceCheck let keyId: String = ... let clientDataHash: Data = ... let assertion = try await DCAppAttestService.shared.generateAssertion(keyId: String, clientDataHash: Data)
-
-
- 0:00 - Introduction
The threats App Attest is designed to address — modified copies of your app sending valid-looking requests to your server, such as falsified quiz submissions or injected game cheats.
- 1:35 - Protections
Verify genuine Apple hardware, detect app modifications, and secure payloads with assertions.
- 4:04 - Availability
Where App Attest is available, now including macOS 27 and all major platforms though not every app extension type, and how to gate usage with the isSupported API and treat unexpected unsupported responses as a fraud signal.
- 5:02 - Key generation
Create a Secure Enclave–bound key ID and store it in the keychain.
- 6:12 - Attestation
Request and validate attestations, including the macOS key access control property and new authenticator-data extensions.
- 12:10 - Assertion
Sign payloads with attested keys and validate the assertion counter on your server.
- 14:58 - Common pitfalls
Handle new keys for existing users, degrade gracefully on rejection, and assess risk before blocking.
- 16:27 - Fraud metric
The receipt-based fraud metric — an approximate 30-day count of unique attested keys on a device — and how it fits a risk profile to spot a compromised device acting as a broker.
- 19:07 - Next steps
Steps to adopt App Attest: rebuild against the latest SDKs, identify flows that benefit from attestations and assertions, set up your server to validate and track them, and fold the fraud metric into your risk pipeline.