에이전트 시대의 앱 보안

안녕하세요, 저는 크리스틴입니다.

안녕하세요, 저는 사브스입니다.

오늘은 에이전트 시대의 보안에 대해 이야기해 보려고 합니다.

지난해 Google은 Android 버그 헌터 프로그램에 200만 달러가 넘는 보상을, 모바일에는 20만 달러가 넘는 보상을 제공했습니다.

오늘날의 에이전트 시대에는 앱 보안이 끊임없이 진화하고 있습니다.

이러한 문제를 빠르고 효과적으로 해결하는 데 도움이 되는 도구에 대해 알아보겠습니다.

Android 보안을 위한 에이전트의 성능을 개선하려면 더 나은 프롬프트가 필요합니다.

상담사가 Google의 도구 모음과 API를 이해하여 앱을 안전하게 보호하는 데 도움이 되는 도구와 워크플로입니다.

오후 4시 30분입니다.

목요일에

출시를 준비 중인데 CI가 빨간색으로 표시되고 오류가 하나만 있습니다. broadcast receiver가 내보내기 플래그 없이 등록되었습니다.

따라서 소규모 팀에서 모든 역할을 담당하든, 대규모 팀에서 출시를 진행하는 동안 보안 검사를 받든, 현실은 동일합니다.

우리는 고품질 기능을 빠르게 제공하는 제품 엔지니어이며, 보안 연구원이 아닙니다.

그렇다면 자연스러운 본능은 무엇일까요?

따라서 이 경고를 에이전트형 도구에 전달하고 에이전트에게 수정을 요청합니다.

하지만 프로젝트 컨텍스트 없이 작동하는 에이전트 도구에는 세 가지 사각지대가 있습니다.

앱이 동적 기능 모듈 또는 멀티 APK 번들로 빌드되었는지 알지 못할 수 있습니다.

배송된 아티팩트가 아닌 파일로 인식합니다.

Kotlin UI에서 KMP 공유 로직을 거쳐 네이티브 C++ JNI 호출로 이어지는 데이터 흐름을 추적하지 못할 수도 있습니다.

하나의 레이어만 표시됩니다.

마지막으로, 최소 SDK 또는 Gradle 빌드 버전을 인식하지 못할 수 있습니다.

그래서 에이전트에게 앱을 가리키고 보안 감사를 요청했습니다.

6개의 발견 사항이 반환되었습니다.

여기서 중요한 점은

모든 기기 하나 하나가 사이버 보안 위협의 대상입니다.

모두 타당한 이유가 있지만, 이 중 하나만 우리가 실제로 시작한 버그입니다.

나머지는 권장사항, 추가 조사 대상, 추측, 적용되지 않을 수 있는 사항이 혼합되어 있습니다.

이제 이를 실제 코드베이스로 확장하면 더 많은 경고가 표시되고, 모든 pull 요청에서 suppress lint를 사용하고 싶어질 것입니다.

변경사항을 병합할 기회를 얻거나 취약점을 완전히 놓칠 수도 있습니다.

이로 인해 실제 취약점이 간과될 수 있습니다.

이 도구는 부주의하지 않고 신중했지만, 신중하다고 해서 유용한 것은 아닙니다.

구체적인 예를 들어 보겠습니다.

예를 들어 에이전트에게 "이 앱에서 내보낸 모든 구성요소의 앱 인텐트 리디렉션을 감사해 줘"라고 요청합니다.

이는 실제 보안 작업이며, 멀티 모듈 앱에서는 큰 작업입니다.

이러한 요청에서 비용이 실제로 발생합니다.

Android 관련 안내가 없으면 에이전트는 이 질문에 대한 전략이 없습니다.

따라서 무차별 대입을 수행합니다.

아무것도 내보내지 않는 모듈을 읽을 수도 있습니다.

인텐트 리디렉션을 악용할 수 있게 만드는 요소를 기본 원칙에서 다시 도출할 수 있습니다.

도달할 수 없는 경로를 따를 수 있습니다.

분석이 아닌 탐색에 비용을 지불하고 있습니다.

기술은 누락된 전략을 제공하는 것입니다.

예를 들어 Android 보안 스킬은 에이전트에게 현재 가이드라인을 따르는 지침을 제공합니다. 이는 보안 연구원이 실제로 따르는 단계와 동일한 순서이며, 에이전트는 추측을 중단합니다.

규칙은 기술에서 제공하므로 규칙을 다시 검색하지 않습니다.

현재 인텐트 보안과 권한이라는 두 가지 보안 기술을 출시했습니다.

인텐트 보안은 다른 앱이 내 앱에 어떤 작업을 시킬 수 있는지에 관한 것입니다.

앱에는 권한과 로그인 세션이 있지만, 웹사이트에는 없습니다.

따라서 내보낸 모든 구성요소와 배포하는 모든 대기 중 인텐트는 누군가가 나를 통해 행동할 수 있는 잠재적인 방법입니다.

이 기술은 이러한 문제를 방지하는 데 도움이 됩니다.

권한 기술은 선언된 권한과 실제로 적용되는 권한 간의 격차를 해소하는 데 도움이 됩니다.

적절한 권한 검사를 작성하는 데 도움이 될 수 있습니다.

와일드 카드 경로가 있는 제공자가 디렉터리 하나가 아닌 전체 데이터베이스를 부여하는지 식별하는 데 도움이 됩니다.

과도한 권한 요청도 감지합니다.

예를 들어 사진 선택 도구로 충분한데 광범위한 액세스 권한을 요청하는 경우입니다.

Android CLI와 함께 사용한 다음 '인텐트 보안 감사'라고 요청합니다.

구성 없음

규칙 조정 없음

따라서 출력은 경고의 벽이 아닙니다.

리뷰입니다.

버그가 있고, 앱에 중요한 이유가 있으며, 해결 방법이 있습니다.

고급 기능 사용 팁을 알려드리겠습니다.

Android CLI를 사용하면 쉽게 찾고 설치할 수 있습니다.

android skills list
android skills add android-intent-security
android skills add android-permissions-security

또한 이 기능은 프로젝트에서 무엇을 찾아야 하는지 정확히 알고 있으므로 앱이 실제로 배포되는 방식을 확인합니다.

최소 SDK를 준수하므로 수정사항이 컴파일되고 실제 파일 경로와 실제 줄 번호가 사용됩니다.

다음은 검토 결과입니다.

정확한 파일과 줄을 가리키고, 실제 위협과 변경사항에 대한 설명을 제공합니다. 단순히 린트가 그렇게 말하는 것이 아닙니다.

사용된 스킬을 인용합니다.

빌드 구성을 읽고 최소 SDK 26을 확인한 후 ContextCompat를 선택하여 수정사항이 적용되도록 하고, 적용할 수 있도록 차이점을 제공합니다.

이 경고는 처음에 살펴본 경고이지만, 이제 권장 수정사항과 추가 이유가 포함되어 있습니다.

따라서 이전 기술은 보안 버그를 포착합니다.

이제 앱 정책 준수라는 또 다른 영역에 대해 이야기해 보겠습니다.

예를 들어 Play 스토어에 앱을 출시하려는 신규 앱 개발자라고 가정해 보겠습니다.

데이터 보안 양식을 작성하는 것은 앱을 출시하는 데 중요한 단계이므로, 앱을 제출하기 전에 올바르게 작성할 수 있도록 가능한 모든 도구를 사용해 보세요.

Play 정책 기술은 코드베이스에 대한 정적 분석을 수행합니다.

기존 Play 스토어 앱을 게시하는 경우 정적 코드 분석을 Play 스토어 선언과 교차 참조할 수도 있습니다.

이 스킬을 실행하면 앱 제출 후가 아닌 제출 전에 잠재적인 Google Play 정책 문제를 파악할 수 있으며 제출 프로세스를 더 빠르게 진행할 수 있습니다.

워크플로는 지금까지 살펴본 다른 기술과 유사합니다. 가져온 다음 '제출하기 전에 이 앱이 Google Play 정책을 준수하는지 감사해 줘'라고 요청합니다.

오른쪽에는 보고서 예시의 스크린샷이 표시되고 아래에는 이를 설치하는 Android CLI 명령어가 표시됩니다.

android skills list
android skills add play-policy-insights

지금까지 살펴본 인텐트 감사, 권한 확인, 규정 준수 검증은 모두 출시 전에 이루어집니다.

이것이 빌드 시간 보안이며 필수적입니다.

하지만 APK가 세상에 공개되어 개발자가 제어할 수 없는 기기에서 실행될 때만 존재하는 위협도 있습니다.

Play Integrity API는 런타임에 자체 코드로는 답할 수 없는 세 가지 질문에 답합니다. 이 앱은 수정되지 않은 정품 빌드인가요?

정품 Android 기기에서 실행되고 있나요?

그리고 Play 사용자 계정인가요?

따라서 Play Integrity API를 사용하여 앱 무결성, 기기 무결성 등에 관한 확인 결과를 반환할 수 있습니다.

앱을 더 빠르고 쉽게 게시할 수 있도록 지원하는 것 외에도 앱의 수익과 평판을 더 쉽게 보호할 수 있도록 지원하고 있습니다.

사기 및 악용으로부터 비즈니스를 보호하세요.

여기에서 볼 수 있는 새로운 'Google Play로 보호됨' 대시보드를 사용하면 무결성, 배포, 수익 창출 방어 기능을 한곳에서 모니터링하고 구성할 수 있습니다.

또한 Play Integrity API의 준비 지연 시간을 줄여 속도가 중요한 사용자 여정 중에 이러한 검사를 사용하여 위협과 위험한 기기를 더 빠르게 차단할 수 있습니다.

지금까지 앱을 안전하게 보호하는 데 도움이 되는 Android 기능과 도구에 대해 알아봤습니다. 그렇다면 사용자는 어떻게 보호할 수 있을까요?

먼저 SMS OTP 보호를 살펴보겠습니다.

앱에 SMS 기반 사용자 인증을 구현하고 인증 코드를 전송한다고 가정해 보겠습니다.

SMS 권한은 OTP와 같은 민감한 정보를 포함한 메시지 데이터에 대한 앱 액세스 권한을 제공합니다.

따라서 앱에 몇 가지 API를 도입하여 이를 구현할 수 있도록 했습니다. 광범위한 SMS 권한을 요청하지 않고도 인증을 위한 SMS OTP 코드를 가져올 수 있습니다.

SMS Retriever API를 사용하면 앱에서 광범위한 SMS 권한 없이도 OTP를 자동으로 인증할 수 있습니다.

앱을 식별하는 11자 해시를 메시지에 추가하면 시스템에서 해당 메시지만 전달합니다.

메시지 형식을 제어할 수 없는 경우 SMS User Consent API를 사용하세요.

시스템에 일회성 프롬프트가 한 번 표시됩니다.

사용자가 허용 또는 거부를 탭하고 허용하면 단일 메시지가 전송됩니다.

광범위한 SMS 권한은 여전히 필요하지 않습니다.

일부 앱은 작업을 완료하기 위해 정확한 위치가 한 번만 필요할 수 있습니다.

기존의 일회성 권한은 사용자 마찰이 크기 때문에 개발자가 더 광범위한 정확한 권한을 요청하는 경우가 있습니다.

따라서 위치 버튼은 앱에 일회성으로 정확한 위치 정보 액세스 권한을 부여하는 간편한 방법을 제공하는 도구입니다.

앱 개발자가 맞춤설정하고 삽입할 수 있는 Android UI 요소입니다.

6월에 알파 위치 버튼 Jetpack 라이브러리의 첫 번째 버전을 출시했습니다.

여기에서 Android 매니페스트에 위치 버튼을 사용 설정하는 데 필요한 권한을 확인할 수 있습니다.

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton"/>

<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

    <application
        android:icon="@mipmap/ic_launcher"
        android:label="LocationButtonSample"
        android:theme="@style/Theme.PinPoint">
        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

표준 위치 정보 액세스 권한을 선언해야 합니다. 즉, 시스템의 원격 렌더링 서비스에 필요한 전용 USE_LOCATION_BUTTON 권한과 함께 onlyForLocationButton 권한 플래그를 추가해야 합니다.

오른쪽에는 이를 구현하는 Jetpack 코드가 있습니다.

...
import androidx.core.locationbutton.compose.LocationButton

@Composable
fun LocationPermissionScreen(onPermissionGranted: () -> Unit, onPermissionDenied: () -> Unit) {
    // Renders the secure system-trusted Location Button composable
    LocationButton(
        // Callback triggered when the user taps the secure button and makes a decision on the permission dialog
        onPermissionResult = { isGranted ->
            if (isGranted) {
                onPermissionGranted()
            } else {
                onPermissionDenied()
            }
        },
...

여기에서 위치 버튼을 만들고 콜백을 초기화하는 것을 볼 수 있습니다.

이 콜백은 사용자가 위치 버튼을 탭하여 권한 부여 또는 거부를 결정할 때 트리거됩니다.

고급 보호 모드는 위험에 노출된 사용자 또는 보안에 민감한 사용자를 위한 기능이지만 누구나 선택할 수 있습니다.

예를 들어 은행 앱의 경우, 일반 사용자는 번거로운 것을 싫어하므로 모든 송금에 추가 다단계 인증을 강제하지 않습니다.

하지만 고급 보호 모드가 사용 설정되어 있으면 앱은 이 사용자가 최대한의 보호를 원한다는 것을 알기 때문에 모든 송금 시 생체 인식 인증을 자동으로 요구할 수 있습니다.

고급 보호 모드는 기기 보호를 강화하기 위해 설계된 사전 정의된 구성 모음을 구현합니다.

여기에서는 앱에 통합하는 방법을 보여줍니다.

권한을 요청하고, 고급 보호 모드를 쿼리하고, 고급 보호 모드 관리자 시스템 서비스를 호출하는 기기 내 기능을 사용하여 사용자가 고급 보호 모드를 사용 설정했는지 확인해야 합니다.

class AdvancedProtectionManager() {
  // Check the current status
  fun isAdvancedProtectionEnabled(): Boolean

  // Be alerted when status changes
  fun registerAdvancedProtectionCallback(executor: Executor,
                                         callback: Callback)

  fun unregisterAdvancedProtectionCallback(callback: Callback)
}

interface Callback() {
  // Called when advanced protection state changes
  fun onAdvancedProtectionChanged(enabled: Boolean)
}

그런 다음 콜백을 등록하여 런타임 변경사항을 수신 대기할 수 있습니다.

오늘 많은 주제를 다루었습니다.

자세히 알아보려면 다음 빠른 링크를 참고하세요.

필요한 URL을 기록할 수 있도록 잠시 멈추겠습니다.

감사합니다.

감사합니다.