- 단일 보안 패치를 구성 요소 기반 분석으로 대체하는 세분화된 가시성 시스템 구현.
- OSV 데이터베이스 및 CVE 추적 시스템과의 통합을 통해 특정 취약점을 감사할 수 있는 기능.
- 보안 상태 제공자를 통해 제조업체와 애플리케이션 간의 통신을 표준화하여 OTA 업데이트를 관리합니다.
솔직히 말해서, 요즘 안드로이드 스마트폰의 보안을 유지하는 것은 정말 골칫거리입니다. 생태계가 너무 복잡해지면서 개발자들은 예전에는 보안 패치 수준(SPL)이라는 매우 일반적인 지표에 의존했는데, 이는 마치 뒷문 잠금장치가 아직 고장 났는지도 모른 채 마지막 대대적인 보수 공사 날짜만 보고 집의 보안 여부를 판단하려는 것과 마찬가지였습니다.
이러한 정보 격차를 해소하기 위해 AndroidX 보안 상태 및 보안 상태 제공자 라이브러리가 등장했습니다. 이 도구들은 시스템의 모든 영역에 대한 상세한 가시성을 제공하여 소프트웨어가 공격에 진정으로 탄력적으로 대응할 수 있도록 하고, 앱이 단순한 추측이 아닌 실제 증거에 기반하여 지능적인 결정을 내릴 수 있도록 함으로써 제로 트러스트 모델 을 구축하는 데 획기적인 변화를 가져왔습니다.
단일 패치 시대는 이제 끝났습니다. 세분화된 패치의 시대가 도래했습니다.
단일 SPL에 의존하는 가장 큰 문제는 Project Mainline과 Google Play 시스템 업데이트 덕분에 Android가 이제 부분적으로 업데이트된다는 점입니다. 이러한 혼란을 해결하기 위해 새로운 라이브러리는 보안을 세 가지 핵심 요소로 나눕니다. 핵심 운영 체제 (무선 업데이트), 시스템 모듈 (Google Play를 통해 제공), 그리고 모든 것의 기반이 되는 Linux 커널 입니다. Linux 커널은 월별 릴리스 날짜가 아닌 LTS 버전으로 업데이트됩니다.
각 구성 요소에 대해 세 가지 다른 상태를 확인할 수 있어 상황을 완벽하게 파악할 수 있습니다.
- 장치 SPL(DSPL): 인터넷 연결 없이도 해당 시점에 기기에 설치되어 실행 중인 항목을 보여줍니다.
- 게시된 SPL(PSPL): 이는 안드로이드 보안 게시판에 공식적으로 게시된 최신 버전을 나타냅니다.
- 사용 가능한 SPL(ASPL): 이는 프로세스 간 통신(IPC) 메커니즘을 통해 이미 다운로드된 업데이트가 있는지 또는 설치 준비가 되었는지 여부를 보여줍니다.
취약점 제어 및 CVE 감사
가장 큰 장점 중 하나는 오픈 소스 취약점(OSV) 데이터베이스 와의 통합입니다 . 특정 월의 패치가 특정 취약점을 수정하는지 여부를 추측할 필요가 없어졌습니다. 이제 특정 CVE를 프로그램적으로 추적할 수 있습니다.
이는 핀테크, 은행 또는 의료 애플리케이션에 매우 유용한 정보입니다. 기기에 심각한 블루투스 또는 NFC 취약점이 여전히 존재 하는 경우, 고액 거래나 민감한 데이터 접근을 제한할 수 있기 때문입니다 . 예를 들어, libimagecodec.quram.so에 대한 경계 외 쓰기와 같은 결함은 원격 공격자가 임의 코드를 실행하도록 허용하여, 구형 기기를 기업 네트워크의 백도어 로 악용할 수 있습니다.
기술 및 독감 예방 구현
이를 실행하려면 개발자는 종속성을 추가해야 합니다. androidx.security:security-state:1.1.0 Gradle 파일에 추가하세요. 초기화는 간단하며 Android 컨텍스트가 필요하지만, JSON 형식의 취약점 보고서를 생성자에 직접 전달하면 속도를 향상시킬 수 있습니다. 보안패치상태.
워크플로는 일반적으로 세 가지 유형의 검사로 나뉩니다.
- 동기식 검증: 이 데이터는 앱이 시작될 때 DSPL을 검사하고 필수 기준 날짜와 비교하는 데 사용됩니다.
- 비동기 쿼리: ~을 통해
fetchAvailableSecurityPatchLevel앱은 사용자에게 업데이트가 예정되어 있음을 알리고 설정 페이지로 이동시킬 수 있습니다. - 심층 감사: 와
queryAllAvailableUpdates데이터의 최신성을 분석하고 어떤 업데이트 제공업체가 응답하는지 확인할 수 있습니다.
시스템 버전에 따라 지원 여부가 다를 수 있다는 점에 유의해야 합니다. Android 11 이상 버전에서는 완벽하게 지원되지만, Android 10에서는 공식적인 커널 지원이 없으며, Project Mainline 모듈이 존재하지 않았던 버전 9 이하에서는 시스템이 기본적 으로 유닉스 날짜(1970년 01월 01일) 를 반환합니다.
보안 상태 제공자의 역할과 안드로이드 17의 새로운 기능
이 시스템 전체가 작동하려면 누군가가 업데이트가 있음을 알려야 합니다. 바로 이 부분에서 보안 상태 공급자(Security State Provider, SSP)가 중요한 역할을 하며, 업데이트 클라이언트가 ASPL에 보고하는 방식을 표준화합니다. 이전에는 각 제조업체의 OTA 정보가 독점적인 저장소에 갇혀 있었지만, 이제는 승인된 앱이라면 휴대폰 브랜드와 관계없이 해당 데이터에 접근할 수 있습니다.
또한, 안드로이드 17은 보충 패치 XML 파일(SPL)을 통해 제조업체(OEM)에게 강력한 개선 사항을 도입했습니다 . 이를 통해 제조업체는 글로벌 SPL 릴리스를 기다리지 않고 자체적으로 구현한 보안 수정 사항을 선언할 수 있으므로, 진행 중인 패치 작업이 즉시 인식되고 기기가 보안 강화 후에도 취약한 상태로 표시되지 않도록 보장합니다.
AndroidX 보안 생태계의 다른 도구들
시스템 상태 외에도 다른 핵심 구성 요소들이 있습니다. 보안 암호화 라이브러리는 키를 관리하고 파일이나 SharedPreferences를 암호화하는 데 필수적입니다. JetSec의 일부 버전은 이제 더 이상 사용되지 않지만, 안드로이드의 샌드박스 모델 과 파일 기반 암호화 기능이 이미 매우 강력하기 때문에 민감한 데이터를 과도하게 저장하지 않는 것이 좋습니다 .
또한, 애플리케이션의 서명 ID를 기반으로 신뢰성을 검증하는 과정을 간소화하는 security-app-authenticator 도 주목할 만합니다. 이 라이브러리는 패키지 이름과 ID를 사용하는 XML 방식을 통해 정당한 애플리케이션 만 중요한 시스템 구성 요소와 상호 작용할 수 있도록 보장합니다.
상세한 구성 요소 수준 검사, OSV를 통한 CVE 감사 기능, 그리고 OTA 업데이트의 표준화를 통해 AndroidX 보안 상태는 향상된 모바일 보안의 표준으로 자리매김했습니다. 이러한 도구들을 통합함으로써 핵심 워크플로우의 복원력이 강화되고, 최종 사용자는 디지털 환경의 최신 위협으로부터 항상 보호받을 수 있습니다.