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.
]} ]} 팀은 데이터가 저장되는 동안 보호되는지, 시스템 간에 데이터가 어떻게 이동하는지, 키가 어디에 저장되는지, 공격자가 애플리케이션 패키지에서 무엇을 알 수 있는지, 런타임이 도난을 어떻게 대응하는지, 그리고 서명된 업데이트가 이러한 보장을 유지하는지 결정해야 합니다. 유용한 시작점은 sensitive 데이터, 신뢰 경계, 클라이언트 기능, 그리고 유력한 악용 경로를 매핑하는 앱 위험 평가입니다. 앱 위험 평가 모바일 및 크로스 플랫폼 애플리케이션은 특히 취약한 환경에 노출되어 있습니다. 장비는 사무실을 떠나고, 빌드는 복사되거나 사이드 로드될 수 있으며, 로컬 파일은 검사될 수 있고, 역 엔지니어링 도구는 널리 사용됩니다. 아래의 섹션은 저장 및 전송부터 플랫폼 키 보호, 클라이언트 측 비밀, 규정 준수, 및 릴리스 작업까지 모델을 단계별로 구축합니다.
목차
앱 암호화가 지금보다 더 중요합니다.
- 휴면 중 암호화 versus 전송 중 암호화
- 휴면 중 암호화
- iOS, Android, Code, 및 Electron을 위한 플랫폼 고려 사항
- Platform Considerations for iOS, Android, Capacitor, and Electron
- 키 관리와 클라이언트 측 비밀의 한계
- 규제 및 준수 요구 사항
- 일반적인 실수와 강화된 최선의 방법
- 암호화 계획에 모든 것을 통합하는 방법
앱 암호화가 지금보다 더 중요해진 이유
웹 애플리케이션은 일반적으로 자신의 제어하에 있는 인프라에서敏感한 논리와 비밀 자료를 많이 보관합니다. 모바일 애플리케이션은 code, 자산, 구성, 데이터 처리 논리를 다른 사람의 장치로 보내야 합니다. Electron 애플리케이션도 유사한 문제를 가지고 있습니다. 왜냐하면 사용자가 애플리케이션을 실행할 수 있기 때문에 JavaScript, 리소스, 패키지 파일을 검사할 수 있습니다.
보안 경계가 바뀌었다. 클라이언트는 보관소가 아닙니다. 암호화는 정보를 비공개 검사에서 보호하고 훼손된 파일이 덜 유용하게 만들 수 있지만 앱은 평문에 접근할 필요가 있습니다. 장치 제어를 하는 공격자는 입력을 관찰할 수 있고 메모리를 검사할 수 있고 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, 또는 의도치 않은 클리어텍스트 엔드포인트는 의도된 보호를 무력화할 수 있습니다.
인증서 핌닝은 특정 모바일 시나리오에서 추가적인 검증 layer를 제공할 수 있습니다. 특히 팀이 인증서 운영을 제어하고 회전 계획이 있는 경우입니다. 그러나 올바른 TLS 대신 인증서 핌닝은 사용자에게 불법적인 차단을 일으킬 수 있는 잘못된 핌을 사용하는 경우가 있습니다. Capacitor으로 빌드하는 팀은 핌닝을 검토할 수 있습니다. Capacitor 앱의 SSL 핌닝 __CAPGO_KEEP_0__의 기능적 이점과 비용을 비교하여 적합한 선택을 하기 전에 핌닝을 사용하는 운영적 이점을 검토할 수 있습니다.
실패 모드는 상호 보완적입니다. 전송 보안은 기기에서 잃어버린 데이터를 복사한 데이터베이스를 보호하지 않습니다. 저장소 암호화는 위조된 연결을 통해 제출된 암호를 보호하지 않습니다. 두 경로를 설계하고 평문이 나타나는 지점을 테스트하세요. 이에는 로그, 스크린샷, 임시 파일, 충돌 보고서, 클립보드 콘텐츠 및 동기화 큐가 포함됩니다.
Code, 데이터 및 앱의 비밀을 보호하는 방법
팀은 종종 단어 '암호화', '가리기' 및 '강화'를 사용하여 동일한 제어를 설명하는 것처럼 사용합니다. 그러나 그들은 아님. 각 하나는 다른 공격자 동작을 다루고 그들을 혼동하면 오해를 불러일으킵니다.
가리기 및 압축 code을 더 읽기 어려운 것으로 만듭니다. 애플리케이션 클론 또는 비즈니스 논리 이해의 비용을 높일 수 있지만 비밀을 애플리케이션이 사용해야 하는 경우 비밀을 사용할 수 없습니다. API 키가 자바스크립트 번들에 있는 경우, 서명 인증서가 아카이브에 있는 경우 또는 예측 가능한 함수로 재구성된 경우 여전히 추출할 수 있습니다. Hermes 바이트코드 및 Electron asar 보관소에서 파일을 검토하는 것은 소스 파일보다 불편할 수 있지만 패키징은 비밀과 다르다.
데이터 암호화 저장된 동안 사용자 콘텐츠와 로컬 자격 증명을 보호합니다. 플랫폼 암호화 API 및 Keychain, Keystore, Secure Enclave, StrongBox, 또는 운영 체제에서 사용할 수 있는 동등한 시설에서 보관하는 키를 사용해야 합니다. OWASP의 암호화 테스트 지침은 소스 코드에 code에 패스워드나 키를 넣지 말라고 경고하고, 클라이언트에 남아 있는 비밀을 추출할 수 있음을 강조합니다.OWASP MASTG 암호화 테스트).
런타임 보호 해킹이나 자동화 공격의 가능성을 높이는 조건을 찾습니다. Jailbreak 및 root 신호, 디버거 감지, 애플리케이션 무결성 검사, attestation, 및 인증서 검증은 공격을 더 어려워지거나 응답 신호를 제공할 수 있습니다. 그러나 신뢰할 수 있는 장치로 만들지는 않습니다. 결정된 공격자는 검사를 수정할 수 있고, 합법적인 사용자는 가치 판단을 트리거할 수 있습니다.
| 보호 층 | 보호하는 것 | __CAPGO_KEEP_0__ 오버플로우 |
|---|---|---|
| Code obfuscation | 앱이 접근할 수 있는 비밀 추출 | __CAPGO_KEEP_0__ |
| 데이터 암호화 | 선택한 저장된 데이터의 기밀성과 무결성 | 유효한 해독 후 평문 노출 |
| 런타임 보호 | 일부 변조, 디버깅 및 자동 악용 | 런타임을 제어하는 숙련된 공격자 |
안전한 설계는 서버에 고가치의 비밀을 보관하고 클라이언트에 좁은 범위의 자격 증명만 제공하며 오프라인 접근이 필요한 데이터만 암호화합니다. 토큰 저장은 만료, 취소, 갱신 동작 및 플랫폼 결합에 대한 별도의 검토가 필요합니다. 모바일 개발자에게 유용한 보안 토큰 저장 지침 그것은 결정 사항을 구현 요구 사항으로 변환하는 데 유용합니다.
간단한 접근 방식은 실패한다. 그것은 비밀의 생애 주기를 보호하는 대신 비밀의 외모를 보호한다. 소스 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 보안을 위한 키 관리에 대한 지침은 애플리케이션 암호화와 업데이트의 생명 주기를 연결하는 데 도움이 될 수 있습니다. 규제 및 준수 영향
업데이트에 대한 OTA 보안을 위한 키 관리에 대한 지침은 애플리케이션 암호화와 업데이트의 생명 주기를 연결하는 데 도움이 될 수 있습니다.
Compliance 팀은 일반적으로 "앱이 암호화를 사용한다"는 statement만으로 충분한 증거로 받아들이지 않는다. 그들은 어떤 데이터가 포함되는지, 활성화된 알고리즘 및 프로토콜, 키를 관리하는 사람, 접근 제한, 그리고 조직이 구성 변경 감지를 어떻게 감지하는지에 대한 정보를 요청한다.
GDPR 32조는 암호화를 위험을 줄이는 적절한 기술적 조치로 간주하며, 유럽 연합의 GDPR 텍스트에 반영되어 있다. 의무는 위험에 기반을 두고 있으므로 조직은 여전히 개인 데이터와 처리 환경의 성질에 따라 안전장치를 연결해야 한다. 의료 정보, 신분 데이터, 또는 금융 기록을 처리하는 모바일 앱은 지역 저장, 전송, 접근, 및 사고 대응에 대한 설명이 필요하다.
HIPAA의 보안 규칙은 전자 보호 건강 정보에 대한 암호화를 주소할 수 있는 보안 대안으로 대신하여 기술적 체크박스로 다루지 않는다. 따라서 보호된 엔티티 또는 비즈니스 협력자는 암호화를 합리적이고 적절한지 여부를 평가하고, 결정서를 작성하고, 암호화를 구현하지 않는 경우 대안적 조치를 적용해야 한다. HHS 보안 규칙 지침은 통치적 맥락을 제공한다.
PCI DSS는 저장된 카드 소지자 데이터를 오픈 네트워크를 통해 전송하는 것을 분리한다. 팀은 암호화 결정이 적용되는 요구 사항에 매핑하고, 결제 데이터를 필요 이상으로 저장하지 않도록 해야 한다. PCI 보안 표준 council 도서관은 현재의 문구와 범위 확인을 위한 적절한 장소이다.
SOC 2 검증자들은 제어가 작동하는지 증명하는 증거에 초점을 맞추고 있습니다. 그 증거는 키 관리 정책, TLS 구성, 암호화 목록, 접근 로그, 변경 승인, 사건 기록, 테스트 결과 및 서명된 릴리스가 의도한 프로세스를 따르는지 증명하는 증거를 포함할 수 있습니다. 모니터링이 없는 문서 제어가 효과적으로 작동하는지 증명하지 못할 수 있습니다.
공통된 주제는 증명 가능성입니다. 앱 암호화를 구현하는 동안 증거 경로를 만들지 마십시오. 감사 시에.
일반적인 실수와 강화된 최선의 방법
대부분의 암호화 실패는 평범한 엔지니어링 결정으로 시작됩니다. 개발자는 시작 시에 토큰이 필요하거나 팀은 오프라인 검색이 빠르게 느껴지도록 하거나 릴리스 프로세스가 빠른 방법으로 핫픽스를 배포할 필요가 있습니다. 단순화된 방법이 신뢰 모델의 영구적인 부분이 될 때 위험성이 발생합니다.
최근의 모바일 위험 연구에 따르면 60% 이상의 평가된 앱은 sensitive 데이터에 대한 보안이 취약하거나 업데이트되지 않은 암호화를 사용했습니다.그리고 약 1/3은 초기화 벡터를 재사용했습니다. 그리고 20% 사용하는 고정된 정적 값그것은 발견이 질문을 “앱이 암호화하는가?”에서 “실제 사용하도록 implementation이 비밀과 무결성을 보장할 수 있는가?”로 바꾸었다.SC World의 모바일 앱 위험 보고서)
| 일반적인 실수 | 고정된 __CAPGO_KEEP_0__ 키 또는 암호화 키를 소스, 바이트코드 또는 패키지에 넣지 마세요 |
|---|---|
| Hardcoding API keys or encryption keys in source, bytecode, or bundles | SQLite 데이터베이스를 암호화하는 동안 평문 캐시, 내보내기, 로그 또는 백업을 남겨두지 마세요 |
| _sensitive 데이터의 모든 복사본을 목록하고 임시 항목에 동일한 저장 정책을 적용하세요 | 일반적인 웹 저장소에 리프레시 토큰을 저장하지 마세요 |
| 플랫폼 백업된 자격 증명 저장소, 토큰 범위를 좁히고 서버 측에서 취소할 수 있도록 지원하세요 | 커스텀 암호화 또는 키 오버플로를 만들지 마세요 |
| Writing custom cryptography or inventing key obfuscation | 인증된 플랫폼 API 및 인증된 암호화 모드를 사용하십시오. |
| 인증서 검증을 비활성화하여 연결성 문제를 해결하십시오. | TLS를 올바르게 구성한 후 테스트된 복구 프로세스를 통해 핌닝을 평가하십시오. |
| 민식화를 비밀 보호로 간주하는 것은 위험합니다. | 클라이언트 code에서 비밀을 제거하고 역공학 비용을 높이기 위해 오버스케이프만 사용하십시오. |
| 애플리케이션完整성 검사 및 신뢰 증명 신호를 생략하십시오. | 적절한 경우 릴리스 식별성을 검증하고 신호를 사용하여 접근을 조정하거나 검토를 트리거하십시오. |
| unsigned 또는 약한 제어된 업데이트를 허용하십시오. | 릴리스 아티팩트에 서명하고 서명 인증서를 보호하고 업데이트의 결과를 모니터링하십시오. |
스파이웨어 조직이 Signal 및 WhatsApp 계정에 대한 위장 애플리케이션과 휴대폰을 악용하는 것을 목표로 한 보고서가 있습니다. 동일한 보고서에서 cited 한 모바일 위협 평가에 따르면 2025년 1분기 Android 스마트폰 공격은 2024년 1분기보다 29% 증가했습니다. (Register의 CISA와 관련된 보도. 암호화가 실패한 것은 아니다. 공격자가 선택하는 장치, 계정, 세션, 또는 업데이트 경로가 암호화된 ciphertext를 우회할 수 있는 layer를 bypass하기 때문이다.
CI에서 알려진 비밀 패턴을 거부하고, 사용자 지정 암호화 code를 플래그로 표시하고, 서명 단계를 검증하고, 패키지 내용을 검사하고, 저장 또는 전송 설정이 변경될 때 보안 검토를 요구하여 자동화된 릴리즈 규칙으로 각 강화된 관행을 변환하라.
모든 암호화 계획을 통합하는 방법
암호화 계획은 엔지니어링 계약과 같은 형태여야 한다. 앱이 보호하는 내용, 키가 저장되는 위치, 플레인텍스트를 볼 수 있는 컴포넌트, 팀이 릴리즈 후 각 제어가 활성화되는지 증명하는 방법을 명시해야 한다.
시작하라 데이터 분류. 기록, 토큰, 문서, 로그, 캐시, 백업, 분석 필드에 따라敏感性와 보존 필요에 따라 분류하라. 장치에 도달하지 않는 데이터는 장치 저장소 설계가 필요하지 않다.
그 다음 저장 및 전송 결정에 대한 문서를 작성하라:
- 휴면 상태: 인증된 암호화, 플랫폼 관리 키 저장소, 보호된 파일 위치, 백업 동작, 삭제 또는 zeroization 처리를 선택하라.
- 수송 중: TLS 구성, 인증서 검증, 엔드포인트 정책, 위협 모델에 따라 pinning이 적절한지 정의하라.
- 키 보관: 기록 생성, 접근, 배포, 회전, 취소, 복구 및緊急 대체 절차.
- Code 및 런타임 제어: 어떤 형태의 암호화, 무결성 검사, 진술, 디버거 감지 및 sensitive-screen 보호가 기여하는지 결정.
- 감사 증거: 구성 요소 목록, 접근 로그, 릴리스 승인, 테스트 결과, 사건 기록 및 예외를 캡처.
순서는 중요합니다. 데이터 분류는 보호해야 하는 것이 무엇인지 결정합니다. 그 결정은 저장소 및 키 보관을 형성합니다. 수송 및 업데이트 제어는 신뢰할 수 있는 서비스와 클라이언트 사이의 경로를 보존합니다. Capacitor 및 Electron 팀은 각 대상에 대해 이 검토를 반복해야 합니다. native iOS 키 저장소, Android 하드웨어 백업 옵션, 브라우저 저장소 API, 데스크톱 자격 증명 시설은 동일한 보장을 제공하지 않습니다.
업데이트 채널은 이 계획 내에 있어야 하며, 그 이후에 있어서는 안 됩니다. 서명된 릴리스는 code 무결성을 보존할 수 있으며, 제어된 대상 지정, 롤백 보호 및 릴리스 관찰성은 팀이 취약한 빌드 또는 구성이 사용자에게 도달했을 때 응답할 수 있도록 도와줍니다. 앱이 오프라인 데이터를 추가하거나 저장소 플러그인을 변경하거나 새로운 백엔드 권한을 도입하거나 업데이트가 서명되고 전달되는 방식이 변경될 때마다 이 계획을 검토해야 합니다.
Capgo는 CapacitorJS 및 Electron 애플리케이션에 대한 서명된 라이브 업데이트를 제공하고 JavaScript code 및 자산에 대한 암호화된 번들 지원, 제어된 릴리스 채널, 롤백 보호 및 장치별 업데이트 관찰성을 제공합니다. 방문하여 Capgo 업데이트 경로를 통해 앱 암호화 및 릴리스 관리 계획을 지원하는지 평가하세요.
