A healthcare startup can spend months designing a secure mobile workflow, then discover that a jailbroken tester’s phone exposed patient records through screenshots and local caches. At the same time, a debug build of the team’s Electron administration panel might ship with an API key embedded in its bundle. Both incidents involve encryption, but neither is solved by adding one encryption library.
__CAPGO_KEEP_0__ 팀은 데이터가 저장되는 동안 보호되는지, 시스템 간에 데이터가 어떻게 이동하는지, 키가 어디에 존재하는지, 공격자가 애플리케이션 패키지에서 무엇을 학습할 수 있는지, 런타임이 도난을 어떻게 대응하는지, 그리고 서명된 업데이트가 이러한 보장을 유지하는지 결정해야 합니다. 유용한 시작점은 sensitive 데이터, 신뢰 경계, 클라이언트 기능, 그리고 유력한 악용 경로를 매핑하는 앱 위험 평가입니다. 앱 위험 평가 모바일 및 크로스 플랫폼 애플리케이션은 특히 취약한 환경에 노출되어 있습니다. 장치들은 사무실을 떠나고, 빌드는 복사되거나 사이드 로드될 수 있으며, 로컬 파일은 검사될 수 있고, 역 엔지니어링 도구는 널리 사용됩니다. 아래의 섹션들은 저장 및 전송부터 플랫폼 키 보호, 클라이언트 측 비밀성, 준수, 및 릴리스 작업까지 모델을 단계별로 구축합니다.
목차
앱 암호화가 지금보다 더 중요합니다.
- 휴면 중 암호화 versus 전송 중 암호화
- 휴면 중 암호화
- iOS, Android, Code, 및 Electron을 위한 플랫폼 고려 사항
- Platform Considerations for iOS, Android, Capacitor, and Electron
- 키 관리와 클라이언트 측 비밀의 한계
- 규제 및 준수 요구 사항
- 일반적인 실수와 강화된 최선의 관행
- 암호화 계획에 모든 것을 통합하는 방법
앱 암호화가 지금보다 더 중요해진 이유
웹 애플리케이션은 일반적으로 자신의 제어하에 있는 인프라에서敏感한 논리와 비밀 자료를 많이 보관합니다. 모바일 애플리케이션은 장치의 소유자가 아닌 다른 장치로 code, 자산, 구성, 데이터 처리 논리를 전송합니다. Electron 애플리케이션도 유사한 문제를 가지고 있습니다. 왜냐하면 JavaScript, 자원, 패키지 파일은 사용자가 애플리케이션을 실행할 수 있는 경우에 사용자가 검사할 수 있습니다.
보안 경계가 바뀌었다. 클라이언트는 유용하지만 보관소가 아닙니다. 암호화는 정보를 비공개 검사에서 보호하고 훼손된 파일이 덜 유용하게 만드는 데 도움이 될 수 있지만 앱은 plaintext에 접근할 필요가 있습니다. 장치의 공격자가 입력을 관찰하고 메모리를 검사하고 API를 모니터링하거나 실행을 수정할 수 있습니다.
건강 관리 예를 들어보겠습니다. 데이터베이스를 암호화하면 디스크에서 복사된 레코드를 보호할 수 있지만 실행 중인 런타임이 악의적인 프로세스에게 노출된 레코드를 표시하는 것을 막을 수는 없습니다. 네트워크 트래픽을 암호화하면 클리닉의 요청을 백엔드로 전송하는 동안 보호할 수 있지만 앱이 비보호된 캐시에 저장한 후 지역 내보내기 보호하지 못합니다. 미니파이드 JavaScript에서 숨겨진 키는 애플리케이션이 사용해야 하는 경우에 복원할 수 있습니다.
실용적인 규칙: 모든 클라이언트 측 보호는 노출을 줄이는 층으로 다루어야 하며, 장치가 신뢰할 수 있는 것으로 간주하는 것이 아님을 기억해야 합니다.
완전한 설계는 일반적으로 다음과 같은 요소를 포함합니다.
- 휴면 상태 보호데이터베이스, 파일, 캐시, 선호도, 다운로드 문서와 같은 데이터를 보호하기 위해.
- 수송 중 보호요청, 동기화, 업데이트 전달, 서비스 간 통신과 같은 데이터를 보호하기 위해.
- 플랫폼 키 저장소암호화 키가 일반적인 애플리케이션 파일에 남아 있지 않도록 하기 위해.
- Code 및 런타임 보호암호화, 무결성 검사, 디버깅 방지, 적절한 인증서 검증과 같은 보호 기능을 포함합니다.
- 통제된 업데이트 채널signed 릴리즈가 이전 버전에서 빌드된 보안 가정치를 보존해야 하기 때문에.
- 규정 준수 제어 사항에 대한 문서화, 포함하여 소유권, 증거, 모니터링 및 대응 절차.
규정 준수는 압력을 가하지만 엔지니어링의 규율을 향상시킵니다. GDPR, HIPAA, PCI DSS 및 SOC 2는 암호화를 UNIVERSAL CHECKBOX로 만드는 것이 아닙니다. 그들은 팀이 보호하는 것을 이해하고 키가 제어되는 방식, 그리고 보안 장치가 의도한 대로 작동하는지 증명할 수 있는 방법을 이해해야합니다.
암호화된 데이터의 저장과 전송
우편으로 보내는 비밀 문서를 생각해 보세요. 봉인된 편지지로 보호되는 메시지는 사람들 사이를 이동하는 동안 보호됩니다. 받는 사람이 열면, 문서는 여전히 잠금 장치가 있는 파일 서랍에 저장되어야합니다. 암호화된 데이터의 이동과 저장을 보호합니다. 봉인된 편지지와 서랍은 서로 다른 문제를 해결합니다.
장치에 저장된 데이터 암호화
장치에 저장된 데이터 암호화는 장치, 서버 디스크, 백업, 데이터베이스 또는 이동식 볼륨에 저장된 데이터에 적용됩니다. 모바일 플랫폼에서 운영 체제 보호 기능은 장치의 일부를 암호화할 수 있지만 애플리케이션은 여전히 안전한 저장 위치, 접근 제어 및 키 사용을 선택해야합니다. sensitive 애플리케이션 파일은 플랫폼 지원 암호화 및 키를 보호된 저장소에 보관하는 것이 좋습니다. 암호화된 데이터 옆에 키를 작성하는 대신.
인증된 암호화가 여기에서 중요합니다. OWASP는 플랫폼 암호화 API, 하드웨어 백업 키 저장소가 있는 경우, 및 인증 모드인 AES-GCM 또는 AES-CCM과 같은 인증된 암호화가 여기에서 중요합니다. OWASP는 플랫폼 암호화 API, 하드웨어 백업 키 저장소가 있는 경우, 및 인증 모드인 AES-GCM 또는 AES-CCM과 같은데이터 암호화는 애플리케이션의 보안을 강화하는 데 도움이 됩니다. OWASP Mobile Application Security Cheat Sheet는 데이터 암호화의 중요성을 강조합니다.OWASP 모바일 애플리케이션 보안 가이드).
iOS는 Data Protection과 Keychain 서비스를 제공합니다. Android는 Keystore-backed 옵션과 암호화된 파일 관리를 도와주는 라이브러리를 제공합니다. 데스크톱 애플리케이션은 운영 체제 인증 정보와 로컬 접근 제어에 의존합니다. Chromium Embedded Framework 환경에서 작업하는 팀은 CEF 문서 저장에 대한最佳 관행을 검토하여 시프터 자체를 넘어 저장 경계를 조사할 수 있습니다. CEF 문서 저장에 대한最佳 관행 파일을 저장하는 데 사용하는 저장 경계를 조사하는 방법
암호화된 데이터를 전송하는 방법
암호화된 데이터를 전송하는 방법은 애플리케이션 트래픽을 읽거나 수정하는 중간 매체가 데이터를 훼손하지 못하도록 보호합니다. 그러나 TLS는 클라이언트가 서버를 올바르게 인증하고 백엔드가 신뢰할 수 있는 인증서를 제공할 때만 작동합니다. 인증서 확인이 비활성화된 경우, 안전하지 않은 fallback, 또는 의도치 않은 평문 엔드포인트는 의도된 보호를 무력화할 수 있습니다.
Certificate pinning can add another verification layer in selected mobile scenarios, especially where the team controls certificate operations and has a recovery plan for rotation. It isn’t a replacement for correct TLS, and an incorrect pin can block legitimate users. Teams building with Capacitor can examine Capacitor 앱에 대한 SSL 핌닝을 살펴보십시오. 운영상의 이점을 선택하기 전에 __CAPGO_KEEP_0__ 앱에 대한 SSL 핌닝을 살펴보십시오.
실패 모드는 상호 보완적입니다. Transport security는 기기에서 데이터베이스를 복사하는 경우 데이터베이스를 보호하지 않습니다. Storage encryption는 위조된 연결을 통해 제출된 비밀번호를 보호하지 않습니다. 두 경로를 설계하고 평문이 나타나는 지점을 테스트하십시오. 이에는 로그, 스크린샷, 임시 파일, 충돌 보고서, 클립보드 콘텐츠 및 동기화 큐가 포함됩니다.
Code, 데이터 및 앱의 비밀을 보호하십시오.
팀은 종종 단어 '암호화', '가리기' 및 '강화'를 사용하여 동일한 제어를 설명합니다. 그러나 그들은 동일하지 않습니다. 각 제어는 공격자가 취하는 다른 동작을 다룹니다. 이들을 혼동하면 오해의 소지가 있습니다.
가리기 및 최소화 code을 읽기 어려운 것으로 만들 수 있습니다. 애플리케이션을 복제하거나 비즈니스 논리를 이해하는 비용을 높일 수 있지만 비밀을 애플리케이션이 사용해야 하는 경우에 비밀을 사용할 수 없습니다. API 키가 자바스크립트 번들에 있는 경우, 서명 인증서가 아카이브에 있는 경우, 예측 가능한 함수가 재구성한 경우 여전히 추출할 수 있습니다. Hermes 바이트코드 및 Electron asar 기록은 소스 파일보다 더 편리하게 검토할 수 있지만 패키징은 비밀과 다릅니다.
데이터 암호화 사용자 콘텐츠와 로컬 자격 증명을 저장한 채 보호합니다. 플랫폼 암호화 API와 Keychain, Keystore, Secure Enclave, StrongBox, 또는 운영 체제에서 사용할 수 있는 등価 시설에서 키를 보유해야 합니다. OWASP의 암호화 테스트 지침은 소스 code에 비밀번호 또는 키를 넣지 말라고 경고하고, 클라이언트에 남아 있는 비밀을 추출하는 것을 강조합니다.OWASP MASTG 암호화 테스트).
런타임 보호 조건을 찾으십시오. 이는 공격의 가능성을 높이는 조건입니다. Jailbreak 및 root 신호, 디버거 감지, 애플리케이션 무결성 검사, attestation, 및 인증서 검증은 공격을 더 어렵게 하거나 반응 신호를 제공할 수 있습니다. 그러나 신뢰할 수 있는 장치가 없습니다. 결정적인 공격자는 검사를 수정할 수 있고, 합법적인 사용자는 가치 판단을 트리거할 수 있습니다.
| 보호 층 | 보호하는 것 | 막지 않는 것 |
|---|---|---|
| Code 암호화 | 응용 프로그램 논리 읽기 및 편안한 복제 | 앱이 접근할 수 있는 비밀 추출 |
| 데이터 암호화 | 선택한 저장된 데이터의 기밀성과 무결성 | 유효한 해독 후 평문 노출 |
| 런타임 보호 | 일부 조작, 디버깅 및 자동 악용 | 런타임을 제어하는 숙련된 공격자 |
안전한 설계는 서버에 고가치 비밀을 유지하고 클라이언트에 좁은 범위의 자격 증명을 제공하며 오프라인 접근이 필요한 지역 데이터만 암호화합니다. 토큰 저장은 만료, 취소, 갱신 동작 및 플랫폼 결합에 대한 별도의 검토가 필요합니다. 모바일 개발자에게 유용한 보안 토큰 저장 지침 이 지침은 결정 사항을 구현 요구 사항으로 변환하는 데 도움이 됩니다.
순진한 접근 방식은 보안의 외모를 보호하는 대신 비밀의 생애 주기를 보호하지 못합니다. 소스 code에서 값을 XOR하는 것, 키를 여러 파일에 분산하는 것, JavaScript 압축에 의존하는 것은 실행 중인 애플리케이션이 값을 재구성하고 사용해야 함을 변경하지는 않습니다.
iOS, Android, Capacitor, 및 Electron을 위한 플랫폼 고려 사항
암호화 설계는 런타임마다 다른 키 저장소, API, 격리 경계, 복구 메커니즘을 노출하는 각 플랫폼에 따라 다르게 동작합니다. 크로스 플랫폼 추상화는 애플리케이션 code을 단순화할 수 있지만 이러한 차이를 지우지는 못합니다.
자연적인 모바일 플랫폼
iOS에서 Keychain은 보호된 자격 증명 저장소를 제공하며 Secure Enclave 주 애플리케이션 프로세서에서 분리된 특정 키 연산을 수행할 수 있습니다. 애플리케이션은 여전히 사용성 요구 사항에 맞는 접근 제어를 선택해야 하며, 데이터가 장치 인증 후에만 사용할 수 있도록 하거나 사용자가 인증한 후에만 사용할 수 있도록 하는 등이 있습니다.
Android Keystore는 지원되는 장치에서 하드웨어 기반 경로를 제공하며 StrongBox 가능한 경우 더 강력한 분리된 환경을 제공할 수 있습니다. Android 팀은 장치 기능, 백업 동작, 인증 요구 사항 및 진술 신호를 고려해야 합니다. 하드웨어 지원은 일관되지 않기 때문에 애플리케이션은 정의된 대체 정책을 갖추어야 하며, 모든 장치가 동일한 보호를 제공하는 것으로 가정하지 않아야 합니다.
크로스 플랫폼 셸
Capacitor 애플리케이션은 웹 code와 네이티브 플랫폼 기능을 연결하는 브리지를 사용합니다. 이 브리지가 보안 경계이며, 단순히 편의 계층만이 아닙니다. localStorageIndexedDB 및 일반 웹 설정은 기본적으로 암호화된 비밀 저장소로 처리되지 않습니다. 팀은 네이티브 스토리지 플러그인 또는 플랫폼의 보호된 키 시설을 사용하는 네이티브 모듈을 구현해야 합니다.
Electron은 다른 위협 모델을 가지고 있습니다. 렌더러는 웹 콘텐츠를 처리하며, 메인 프로세스는 더 광범위한 권한을 가지고 있으므로敏感한 연산은 노출된 렌더러에서 수행되지 않아야 합니다. Electron의 safeStorage 운영 체제 자격 증명 보호를 사용할 수 있지만, 결과적인 보안은 호스트 운영 체제, 사용자 계정, 데스크톱 구성, 프로세스 격리에 따라 달라집니다. 키는 모바일 플랫폼이 보호된 키를 격리하는 것과 같은 방식으로 자동으로 하드웨어 격리되지 않습니다.
| 플랫폼 | 키 저장소 | API 암호화 | 기본 위협 모델 |
|---|---|---|---|
| iOS | 키 체인과, 지원되는 경우 Secure Enclave | 애플 플랫폼 암호화 및 데이터 보호 | 장치와 앱은 별개이지만, compromized 장치 또는 런타임이 사용을 관찰할 수 있습니다. |
| 안드로이드 | Keystore 및, 지원되는 경우 StrongBox | 안드로이드 플랫폼 암호화 및 Jetpack 보안 구성 요소 | 장치에 따라 하드웨어 및 소프트웨어 기능이 다릅니다 |
| Capacitor | Native storage selected through plugins or custom bridge code | 웹 API와 네이티브 플랫폼 API | 웹 자산은 네이티브 셸 내에서 실행되며 보안 저장소를 자동으로 상속하지 않습니다 |
| Electron | OS 자격 증명 시설을 통해 API safeStorage |
Node 및 Chromium 호환 애플리케이션 API | 렌더러 노출 및 호스트 레벨 접근이 주요 관심사입니다 |
팀은 대상별로 동작을 문서화해야 하며 제품을 "모든 플랫폼에서 암호화"라고 설명하지 않아야 합니다. Capacitor 플랫폼 차이점을 프레임하는 방법
__CAPGO_KEEP_0__
Key Management and the Limits of Client-Side Secrecy Encryption protects data only when key management protects the keys. A useful lifecycle has five stages:generation, distribution, storage, rotation, and revocation
Each stage creates a different failure mode.
The client is weaker than infrastructure for these operations because the user controls the device and can potentially inspect application state. A client-held key can make sense for offline data protected by a user-derived passphrase, provided the product accepts the recovery and usability consequences. It makes far less sense for an API token that grants broad backend access. If an attacker extracts that token, encryption around a local database won’t limit what the token can do remotely.
데이터 암호화 키와 마스터 키를 분리하는velope 암호화는 데이터 키를 사용하여 지역 객체를 암호화할 수 있게 해주며, 서버 측 키 관리 서비스 또는 HSM 백업 시스템은 wrapping 키를 보호합니다.远隔 키 릴리스 디자인은 인증된 장치, 사용자, 정책 결정 또는 attestation 신호가 필요하기 전에 암호화에 필요한 자료를 릴리스할 수 있습니다.이 패턴은 손상된 클라이언트를 안전하게 만들지 않지만, 장치에 영구적으로 존재하는 권한의 양을 줄입니다.
OWASP는 개인 식별 정보, 암호화 자료, 비밀, API 키를 포함한 지역敏感 데이터를 식별합니다. 또한 암호화와 생명 주기 제어를 연결합니다. 암호화 제어는 보안 지역 저장소, 키 회전, 사용 후 제로화와 같은 제어입니다.
높은 가치의 비밀을 팀이 관리하는 시스템에서 유지하고 클라이언트에게 현재 작업에 필요한 최소 권한만 부여하는 것이 원칙입니다.
릴리스 시스템에 대한 키 관리는 업데이트의 서명과 배포에도 적용됩니다. 팀은谁가 패키지를 서명할 수 있는지, 서명 인증서가 어디에 있는지, 접근이 감사되는지, 손상된 서명 인증서가 대체되는지 정의해야합니다. 업데이트의 생명 주기와 애플리케이션 암호화를 연결하는 방법에 대한 지침 규제 및 준수 요구 사항
업데이트를 위한 OTA 보안
Compliance 팀은 일반적으로 “앱이 암호화를 사용한다”는 statement만으로 충분한 증거로 받아들이지 않습니다. 그들은 어떤 데이터가 포함되는지, 어떤 알고리즘과 프로토콜이 활성화되어 있는지, 키를 관리하는 사람들, 접근 제한 방법, 그리고 조직이 구성 변경 감지를 어떻게 감지하는지에 대한 정보를 요청합니다.
GDPR 32조는 암호화를 위험을 줄이는 적절한 기술적 조치로 간주하며, 유럽 연합의 GDPR 텍스트에 반영되어 있습니다. 의무는 위험에 기반을 두고 있으므로 조직은 여전히 개인 데이터와 처리 환경의 성질에 따라 안전장치를 연결해야 합니다. 의료 정보, 식별 데이터 또는 금융 기록을 처리하는 모바일 앱은 지역 저장, 전송, 접근 및 사고 대응에 대한 설명이 필요합니다.
HIPAA의 보안 규칙은 전자 보호 건강 정보에 대한 암호화를 주소할 수 있는 보안 대안으로 대신 처리합니다. 따라서 보호되는 엔티티 또는 비즈니스 협력자는 암호화를 합리적이고 적절한지 여부를 평가하고, 결정서를 작성하고, 암호화를 구현하지 않는 경우 대안적 조치를 적용해야 합니다. HHS 보안 규칙 지침은 통치적 맥락을 제공합니다.
PCI DSS는 저장된 카드 소지자 데이터를 오픈 네트워크를 통해 전송하는 것을 분리합니다. 팀은 암호화 결정이 적용되는 요구 사항과 매핑하고, 필요하지 않은 경우 결제 데이터를 저장하지 않도록 해야 합니다. PCI 보안 표준 council 도서관은 현재의 문구와 범위에 대한 확인을 위한 적절한 장소입니다.
SOC 2 검증자는 제어가 작동하는지 증명하는 증거에 초점을 맞추고 있습니다. 그 증거에는 키 관리 정책, TLS 구성, 암호화 목록, 접근 로그, 변경 승인, 사고 기록, 테스트 결과 및 서명된 릴리즈가 의도한 프로세스를 따르는지 증명하는 증거가 포함될 수 있습니다. 모니터링이 없는 문서 제어가 효과적으로 작동하는지 증명하지 못할 수 있습니다.
공통된 주제는 증명 가능성. 앱 암호화를 구현하는 동안 증거 경로를 만들지 마십시오. 감사 시에.
일반적인 실수와 강화된 최선의 방법
대부분의 암호화 실패는 평범한 엔지니어링 결정으로 시작됩니다. 개발자는 시작 시 토큰이 필요합니다, 팀은 오프라인 검색이 빠르게 느껴지도록 하려합니다, 또는 릴리즈 프로세스가 빠른 방법으로 핫픽스를 배포할 수 있도록 하려합니다. 위험이 발생할 때는 단축된 방법이 신뢰 모델의 영구적인 부분이 됩니다.
최근 모바일 위험 연구에서 60% 이상의 평가된 앱이 sensitive 데이터에 대한 보안되지 않은 또는 outdated 암호화를 사용했다고 보고되었습니다., 한 세트의 앱이 초기화 벡터를 재사용했다고 그리고 20% 사용하는 고정된 정적 값그것은 발견이 질문을 “앱이 암호화하는가?”에서 “실제 사용 시 구현이 비밀성과 무결성을 보장할 수 있는가?”로 바꾸었다.SC World 모바일 앱 위험 보고서)
| 일반적인 실수 | 강화된 실천 |
|---|---|
| API 키 또는 암호화 키를 소스, 바이트코드 또는 패키지에 고정시키는 것 | 고가치 인증서를 서버 측에서 유지하고 장치 범위에 대한 물리적 저장소에서 보호 플랫폼 저장소를 사용하는 것 |
| SQLite 데이터베이스를 암호화하는 동안 평문 캐시, 내보내기, 로그 또는 백업을 남겨두는 것 | Sensitive 데이터의 모든 복사본을 목록하고 임시 항목에 동일한 저장 정책을 적용하는 것 |
| 일반적인 웹 스토리지에 리프레시 토큰을 저장하는 것 | 플랫폼 백업된 인증서 저장소, 토큰 범위 좁히기 및 서버 측 취소 지원 |
| 사용자 정의 암호화 또는 키 오비폴레이션을 작성하는 것 | 인증된 플랫폼 API 및 인증된 암호화 모드를 사용하십시오. |
| 연결성 문제를 해결하기 위해 인증서 검증을 비활성화하십시오. | TLS를 올바르게 구성한 후 테스트된 복구 프로세스를 통해 핌닝을 평가하십시오. |
| 민식화를 비밀 보호로 간주하십시오. | code에서 클라이언트의 비밀을 제거하고 역공학 비용을 높이기 위해 오버스케이프만 사용하십시오. |
| 애플리케이션完整성 검사 및 신호를 생략하십시오. | 적절한 경우 릴리스 식별성을 검증하고 신호를 사용하여 접근을 조정하거나 검토를 트리거하십시오. |
| unsigned 또는 약한 제어된 업데이트를 허용하십시오. | 릴리스 아티팩트를 서명하고 서명 인증서를 보호하고 업데이트 결과를 모니터링하십시오. |
스파이웨어 크루가 Signal 및 WhatsApp 계정에 대한 위조 애플리케이션 및 전화 하부를 악용하는 것을 목표로 한 보고서가 있습니다. H1 2025와 H1 2024의 비교에서 Android 스마트폰 공격이 29% 증가했습니다. (The Register의 CISA와 관련된 보도__CAPGO_KEEP_0__
Turn each hardened practice into an automated release rule. CI can reject known secret patterns, flag custom cryptographic code, verify signing steps, inspect bundle contents, and require security review when storage or transport settings change. The objective is to catch a bad decision before it becomes a shipped dependency.
CI에서 알려진 비밀 패턴을 거부하고, 사용자 지정 암호화 __CAPGO_KEEP_0__를 플래그로 지정하고, 서명 단계를 검증하고, 패키지 내용을 검사하고, 저장 또는 전송 설정이 변경될 때 보안 검토를 요구하여 잘못된 결정을 배포된 의존성으로 변하지 않도록 잡아내세요.
모든 암호화 계획을 통합하세요.
암호화 계획은 엔지니어링 계약처럼 읽혀야 합니다. 앱이 보호하는 내용, 키가 어디에 있는지, 평문이 어떤 구성 요소에 보이는지, 팀이 각 릴리스 후에 제어가 활성화되는지 증명하는 방법을 설명해야 합니다. 시작하세요.데이터 분류
.敏感도와 보존 필요에 따라 레코드, 토큰, 문서, 로그, 캐시, 백업, 분석 필드를 분류하세요. 장치에 저장되지 않는 데이터는 장치 저장소 설계가 필요하지 않습니다.
- 그 다음 저장 및 전송 결정에 대한 문서를 작성하세요: 휴면 상태:
- 인증 암호화를 선택하고, 플랫폼 관리 키 저장소, 보호 파일 위치, 백업 동작, 삭제 또는 제로화 처리를 선택하세요. 수송 중인 프로토콜:
- 키 보관: 기록 생성, 접근, 배포, 회전, 취소, 복구 및緊急 대체 절차.
- Code 및 런타임 제어: __CAPGO_KEEP_0__ 및 런타임 제어:
- 감사 증거: 구성 요소 목록, 접근 로그, 릴리스 승인, 테스트 결과, 사고 기록 및 예외를 캡처.
순서가 중요합니다. 데이터 분류는 보호해야 하는 항목을 결정합니다. 이 결정은 저장소 및 키 보관을 형성합니다. 수송 및 업데이트 제어는 신뢰할 수 있는 서비스와 클라이언트 간의 경로를 보존합니다. Capacitor 및 Electron 팀은 각 대상에 대해 이 검토를 반복해야 합니다. native iOS 키 저장소, Android 하드웨어 백업 옵션, 브라우저 저장소 API, 데스크톱 자격 증명 시설은 동일한 보증을 제공하지 않습니다.
The update channel belongs inside this plan, not after it. A signed release can preserve code integrity, while controlled targeting, rollback protection, and release observability help the team respond when a vulnerable build or configuration reaches users. Review the plan whenever the app adds offline data, changes its storage plugin, introduces a new backend permission, or alters how updates are signed and delivered.
Capgo는 CapacitorJS 및 Electron 애플리케이션에 대한 서명된 라이브 업데이트를 제공하고, JavaScript code 및 자산에 대한 암호화된 번들 지원, 제어된 릴리스 채널, 롤백 보호, 및 장치별 업데이트 관찰성을 제공합니다. 방문 Capgo 제어된 업데이트 경로가 애플리케이션 암호화 및 릴리스 관리 계획을 지원하는 방법을 평가하세요.
