모바일 앱이 폭발적으로 증가하면서 앱 증명은 반드시 필요한 정책이 되었습니다. 앱 개발자는 앱 증명을 통해 앱의 보안을 평가할 수 있고, 안드로이드와 iOS에 적용할 수 있습니다. 보안 전문가가 서버가 실제 정품 애플리케이션과 상호 작용하고 있는지 확인할 수 있는 기업의 남용탐지 시스템의 핵심요소가 되고 있습니다.

App Attestation(앱 증명)이란?

App Attestation(이하 앱 증명)은 무결성 테스트와 측정을 통해 앱의 무결성을 확인합니다. 무결성이 입증되면 암호화 토큰이 제공되고, 인증을 위해 백엔드 서버와 공유됩니다. 앱 개발자는 무결성에 관한 이상 유무를 확인하고, 이를 기준 데이터와 비교하여 앱을 평가하고, 이를 통해 앱 실행환경의 보안과 호환성을 확인할 수 있습니다. 데이터 변조, 안전하지 않은 URL, 허위 사용자, 유해 애플리케이션/기능 등 다양한 영역을 테스트할 수 있습니다. 위험 거래와 사기성 사용으로부터 앱을 보호하며, 사기행위와 인가되지 않은 접속의 가능성을 줄여줍니다. 이러한 접근방식은 앱 자체의 보안기능에 의존하는 것이 아닌 원격 환경과의 연결을 통해 정품임을 증명해야 하는 원격 증명정책을 적용하기 때문에 앱의 보안을 더욱 강화할 수 있습니다.

앱 증명 서비스를 통한 애플/iOS 앱 증명

애플리케이션은 수백만 명의 사용자가 사용하기 때문에 샌드박스 환경에서 테스트하는 것이 중요합니다. 앱 증명에 있어서도 마찬가지입니다. 그런 다음 개발환경을 안전하고, 실행이 유지되는 상태로 유지하면서 기기에서 다수의 키를 생성하고, 증명할 수 있습니다. 개발 중 테스트하려는 경우 앱 증명 환경 자격을 앱의 자격 파일에 추가해야 하며, 값을 ‘production’으로 설정해야 합니다. 하지만, 환경 전반에 키는 서로 독립적임을 알아야 합니다. 시스템에 과부하가 걸리지 않게 하려면, 광범위한 사용자를 대상으로 배포하기 이전에 소규모 사용자를 대상으로 앱 증명 기능을 활성화해보십시오. 이를 통해 앱 업데이트에 대해 어느 정도의 요구사항을 확인할 수 있습니다.

앱 증명에서 고려해야 할 한 가지 활용 사례는 앱의 유효한 인스턴스가 서버에 연결되어 있는지 확인하는 것입니다. 앱은 암호화 키를 생성하고, 어써션(assertion) 개체와 식별자가 확인이 이루어지는 서버에 전달되는 게시를 수행하기 위해 DCAppAttestService의 공유 인스턴스를 사용합니다. 이 키는 프리미엄 콘텐츠 다운로드나 접속과 같은 활동에 대한 어써션 개체를 확인하는 데 사용됩니다. 이를 대신하여 앱이 증명 데이터를 서버와 통신해야 하는 경우, 검증을 위해 무작위 데이터 값을 사용할 수도 있습니다. 이를 일회성 첼린지라고 합니다. 그런 다음 이것은 제공하는 개체에 통합되고, 앱은 이를 서버로 다시 보냅니다. 그렇기 때문에 먼저 키 식별자를 얻고, 백엔드 서비스는 첫 번째 첼린지 문자열에서 작업을 시작합니다. 증명 토큰은 앱 증명 서비스에서 검색이 이루어집니다. 이것은 키 식별자와 함께 디코딩과 파싱이 이루어지는 백엔드 서비스로 전송됩니다. 유효성 검사를 통과하면 서비스는 CredCert(디코딩된 “x5c” 배열의 첫 번째 버퍼) 값을 저장합니다. 이후 두 번째 챌린지 문자열이 생성되며, iOS 앱으로 전송됩니다. 어써션 토큰이 다시 생성되고 디코딩/파싱됩니다. API 호출이 마지막 단계로 이루어집니다.

SafetyNet Attestation API를 통한 안드로이드 앱 증명

SafetyNet Attestation API는 안드로이드 기기에서 작동하며, 앱 개발자가 기기를 평가할 수 있게 해줍니다. 암호를 통해 서명이 이루어진 증명을 제공하고, 기기의 소프트웨어와 하드웨어 환경을 검사합니다. 먼저 nonce라는 호출이 앱에서 서버로 이루어집니다. 런타임 환경을 평가하고, 평가 결과의 서명된 증명이 구글 서버에서 SafetyNet 증명 서비스로 앱까지 공유됩니다. 그런 다음 이것은 확인사항이 포함되어 있는 보고서의 유효성을 검사하고, 생성하는 서버로 전달됩니다. 증명 토큰은 JSON 웹 서명(JSON Web Signature, JWS) 형식입니다. 앱의 합법성을 확인할 때 basicIntegrity 및 ctsProfileMatch 값은 true가 되어야 하며, nounce는 비어 있지 않아야 하고, apkPackageName 및 apkCertificateDigestSha256 값은 안드로이드 앱에서의 값과 동일해야 합니다.

게시자 증명도 하나의 해결책입니다

전 세계의 모든 개발자 팀은 보다 간단하고 철저한 규정준수와 보안조치의 적용을 모색하고 있습니다. 마이크로소프트 365 앱 규정준수 프로그램의 일환으로 이루어지는 게시자 증명은 이를 추진하는 과정입니다. 여기에서 핵심적인 기능은 세부적인 자체 평가입니다. 앱 보안을 평가하는 동안 고객이나 IT 관리자가 자주 묻는 질문을 제공합니다. 더 나은 투명성, 접근의 용이성 및 신속한 평가를 위해 이러한 세부사항을 게시합니다. 이는 팀, 워드, 파워포인트, 아웃룩, 쉐어포인트, 엑셀 등 마이크로소프트 제품과 통합하는 웹 애플리케이션(파트너 센터의 상용 마켓플레이스에서의 SaaS 앱)을 다룹니다. 게시자 증명의 가장 큰 이점은 최적의 적용사례를 기록하고, 공유하여 더 나은 투명성, 시간 절감과 더 나은 규정준수를 달성하는 것입니다. 또한, 아래와 같이 앱 기능의 전체적인 범위(80개 항목의 리스크 요소를 확인)를 살펴보기 때문에 대단히 철저합니다.

• 데이터 처리: 데이터 수집, 저장 및 사용
• 보안: 침해행위로부터 데이터를 보호하기 위한 규칙, 절차 및 프로토콜
• 규정준수: 업계 전반의 표준 및 사양에 대한 준수
• 합법성: 법적 규정에 대한 준수

위의 검사를 통과하지 못하면 앱 증명 요청이 거부됩니다. 승인이 이루어진 이후에도 문서의 잘못된 정보에 대해서는 확인상태를 철회합니다. 이는 시간대에 있어서도 절차를 다시 시작해야하는 연간 게시에 대해 유효합니다. 앱을 업데이트하거나 수정하는 경우 테스트를 다시 수행해야 합니다.

구글 FireBase를 통한 앱 증명

구글 FireBase를 사용하면, 애플 앱에서 앱을 테스트할 수 있습니다. 먼저 App Check를 활성화하고, Xcode 12.5+ 버전으로 FireBase 프로젝트를 설정한 후 액세스를 활성화하기 위해 앱을 등록해야 합니다. 그런 다음 프로젝트의 Podfile에 있는 앱에 App Check 라이브러리를 추가합니다. 이후 AppCheckProviderFactory의 구현을 작성하여 App Check를 초기화해야 합니다. 이를 통해 업데이트된 앱을 최종 사용자에게 배포할 수 있습니다. 여기에서 리퀘스트 지표(Request Metrics) 화면이 가장 중요하며, 이를 통해 검증되었거나 오래된 클라이언트, 알 수 없거나 유효하지 않은 출처와 같은 다양한 범주의 요청을 확인할 수 있습니다. 이러한 지표는 구글 클라우드 콘솔에서 분석할 수 있습니다. 최종적으로 실행을 활성화하려면 FireBase 콘솔의 App Check 섹션을 열고 지표 보기를 확장한 후 ‘Enable’을 클릭하십시오.

AppSealing을 통한 앱 보안 향상하기

애플리케이션 보안이 중요하다는 점은 널리 알려져 있습니다. 하지만, 표준이 충분하지 않으면 이러한 보안이 어려워질 수 있습니다. 애플리케이션 코드의 출처와 위치는 이러한 보안을 더욱 복잡하게 만듭니다. 특히, 내부뿐만 아니라 외부에서 일어날 수 있는 위협에 대처해야 하기 때문에 더욱 그렇습니다. 제3자를 통한 리스크 평가는 통상적으로 애플리케이션 보안에 있어서 충분하지 않은 대응전략입니다. 애플이 아이폰, 아이패드, 맥 제품에서 보안 결함을 발견하고, 사용자가 이러한 소프트웨어를 얼마나 자주 업데이트할 수 있게 하는데 얼마나 관심을 갖고 있는지 잘 알 수 있습니다. 최소의 노력으로 위협에 대한 분석을 할 수 있는 종합적인 애플리케이션 보안 솔루션이 유일한 해결방안이 될 것입니다. 제3자 라이브러리와 호환이 가능하며, 런타임에서 애플리케이션 보안을 테스트할 수 있는 솔루션이 필요한 것입니다. AppSealing은 1억 개 이상의 앱을 보호하며, 150 백만 종 이상의 해킹 벡터를 차단하는 이러한 플랫폼 중 하나입니다. 자세한 정보가 필요하시다면, 지금 모바일 애플리케이션 보안의 선두업체인 저희에게 연락해주십시오!