당신은 밤늦게 릴리스를 푸시하고, 알림을 훑어보고, 개인 저장소에서 절대 나가지 shouldn't never 한 자격증을 발견한다. 그것은 데이터베이스 패스워드였을 수도 있고, 더 넓은 권한을 가진 클라우드 접근 키였을 수도 있다. 그 문제는 단순히 누군가가 로그인할 수 있는 문제가 아니라, 데이터베이스 보안이 로그인 문제로 다루어지고 있지만 실제로는 저장 라이프 사이클 문제라는 것이다.
That shows up everywhere in real systems. Teams enable encryption once and assume they’re done. They keep backups but never test restore. They create an admin service account for convenience and forget it exists. They lock down production, then leave staging full of copied customer data. If you’re building mobile or web apps, secure database storage has to cover all of it: the primary database, the replicas, the exports, the logs, the backups, and the keys that control the whole thing.
다음 앱에 대한 인증을 해결하는 중이신가요? 인증과 저장소 보안은 다른 실패 모드를 해결하는 것입니다.인증은 누구에게 들어가야 하는지 결정합니다. API security standards for app store compliance.
__CAPGO_KEEP_0__ 앱 스토어 준수에 대한 보안 표준과 일치시키는 것이 중요합니다. 급박함은 이론적이지 않습니다. 2020년 64.2 zettabytes의 데이터 생산량이 보고되었으며 2025년까지 180 zettabytes로 증가할 것으로 예상됩니다.Edge Delta의 데이터 저장소 요약에 따르면.
그 규모에서 보안 저장소는 보강 작업이 아닌 아키텍처가 됩니다.
- 목차
- __CAPGO_KEEP_1__
- __CAPGO_KEEP_4__
- __CAPGO_KEEP_9__
- 마스터 키 및 비밀 관리
- 복원 가능한 백업 및 복구 전략 설계
- 데이터베이스 보안 저장에 대한 개발자 체크리스트
- 자주 묻는 질문
데이터베이스 보안은 단순한 비밀번호만으로 충분하지 않다
비밀번호는 입구를 보호하지만, 자격 증명이 유출되거나 스냅샷이 복사되거나 내부 서비스가 테이블을 읽는 것을 허용하지 않았던 테이블에 접근할 수 있게 되면 데이터를 보호하지 못한다. 따라서 안전한 데이터베이스 저장은 layering이 필요하다.
기존의 모델은 단순했다: 데이터베이스를 방화벽 뒤에 두고, 강력한 비밀번호를 요구하고, 외부로부터 멀리 떨어뜨리면 된다. 그러나 클라우드 시스템, 모바일 백엔드, 현대적인 CI/CD PIPELINE에서 이 모델은 깨진다. 데이터는 서비스 간에 이동한다. 엔지니어는 임시 수출을 생성한다. 분석 작업은 레코드를 복사한다. 백업 시스템은 다른 인프라스트럭처에 복사본을 저장한다. 공격자는 데이터베이스 엔진을 깨트리지 않아도, 키를 훔치거나 API 토큰을 남용하거나, 복제본에 약한 제어를 가진 복제본을 찾으면 된다.
보안은 조용한 경로에서 실패한다
가장 손상된 저장소 실패는 처음에는 드라마틱하지 않다. 보통 보통이다.
- 개발자 편의성이 프로덕션 위험으로 변한다: 공유된 관리자 자격 증명이 스크립트에 의해 재사용되는데, 이는 회전하면 배포가 깨질 것을 고려하여.
- 복제된 데이터베이스가 관리를 벗어난다: 운영 기록이 스테이징으로 복제되어 QA가 버그를 재현할 수 있다.
- 백업이 약점이 된다: 운영에는 강력한 제어가 있지만 복원 버킷이나 스냅샷 정책이 그렇지 않다.
실용적인 규칙: 만약 공격자가 읽을 수 있는 데이터에 공격자가 접근할 수 있는 유일한 요소가 있다면, 보안 저장소가 아니라 단일 실패 지점이 있다.
인증 정보를 악용하는 공격을 견디는 방어가 필요하다
마이크로소프트의 클라우드 지침은 전송 중인 데이터 암호화, 저장 중인 데이터 암호화, 최소 권한 접근 제어, 비인가 활동에 대한 모니터링을 포함하는 클라우드 데이터 보안 최적화 가이드라인을 권장한다. 실제 사고는 종종 유효한 접근 권한을 잘못 사용한 경우에 시작된다.실제로 작동하는 방법은 재미없고 일관적이다. 데이터베이스 파일을 암호화하라. 연결을 암호화하라. 서비스 역할을 분리하라. 관리자 접근 권한을 제거하라. sensitive한 연산을 로그하라. 비정상적인 사용 패턴에 대한 알림을 설정하라. 그 중 하나도 재미없지만 실제로 발생하는 침입을 막는다.
실용적인 방법으로 생각하는 것은 물건 보관함이다. 보관함의 문이 중요하다. 또한 격리 장치, 카메라 footage, 방문자 로그, box를 열 수 있는 사람의 정책이 중요하다. 보안 데이터베이스 저장소도 마찬가지다. 패스워드는 단지 문 앞에 있는 것이다.
A useful way to think about it is a physical vault. The vault door matters. So do compartment locks, camera footage, the visitor log, and the policy for who can open which box. Secure database storage works the same way. Passwords are only the front door.
데이터베이스 위협 모델 이해하기
데이터베이스 보안을 위한 위협 모델을 만들기 전에, 시스템이 실패하는 방법을 먼저 파악해야 합니다. 데이터베이스 저장을 위한 위협 모델은 학술적인 필요성만을 위한 것이 아닙니다. 데이터베이스에 접근할 수 있는 사람, 그들이 데이터를 어떻게 접근할 수 있는지, 그리고 그들이 성공할 경우에 어떤 일이 일어날 수 있는지에 대한 정보를 제공해야 합니다.
_sensitive data_는 종종 복사본, 백업, 로그, 개발 환경 등에 저장되며, 이로 인해 데이터베이스의 primary database 외에 실패가 발생할 수 있습니다. Cloudflare의 cloud data security와 posture management에 대한 개요에서 이러한 점을 언급한 바 있습니다. 데이터베이스 보안을 위한 위협 모델을 만드는 데에는 vendor exposure와 copied datasets와 같은 다양한 시나리오를 포함해야 합니다. 이러한 시나리오는 broader response playbooks, third-party breach response best practices와 같은 broader response playbooks에 포함되어야 합니다.도구보다 asset을 먼저 파악해야 합니다. 데이터베이스 보안을 위한 위협 모델을 만드는 데에는 asset을 먼저 파악해야 합니다. asset은 무엇인지 파악한 후에 도구를 파악해야 합니다.대부분의 앱 팀에서, 중요한 asset은 다음과 같습니다:
고객 기록
고객 기록
고객 기록
- 고객 기록 예를 들어 프로필, 주문 내역, 결제 관련 메타데이터, 또는 건강 관련 콘텐츠.
- 인증 자료 예를 들어 비밀번호 해시, 세션 기록, 갱신 토큰, 또는 API 비밀 정보.
- 운영 데이터 예를 들어 감사 로그, 작업 큐, 관리자 노트, 지원 내보내기.
- 복구 자산 예를 들어 스냅샷, 논리적 덤프, 특정 시점 로그, 암호화 키.
마지막 항목이 팀이 생각하는 것보다 더 중요합니다. 공격자가 백업을 삭제하거나 복호화 키에 접근할 수 있다면, 복구 스토리가 붕괴됩니다.
가장 중요한 3가지 위협 그룹
개발자와 함께 사용하는 간단한 모델은 3개의 그룹이 있습니다.
외부 공격자
이것은 사람들이 가장 먼저 생각하는 그룹입니다. SQL 인젝션, 훔친 API 토큰, 누출된 클라우드 인증서, 노출된 관리자 패널, 취약한 의존성. 공통된 주제는 데이터에 접근할 수 있는 외부 공격자입니다.
질문하기:
- 앱을 통해 데이터베이스를 간접적으로 조회할 수 있나요?
- 스톨른 서버 인증 정보가 여러 서비스가 필요로 하는 것보다 더 많은 서비스를 읽을 수 있나요?
- 복사한 스냅샷이 독립적으로 읽을 수 있나요?
내부 위협
이것은 악의적인 내부자와 권한이 너무 많은 잘못된 의도 없는 직원도 포함합니다. 지원 엔지니어는 티켓을 해결하기 위해 데이터를 내보냅니다. 컨트랙터는 로컬 복사본을 유지합니다. 플랫폼 관리자는 생산 라인에 접근할 수 있지만 그들의 직무에는 필요하지 않습니다.
이것을 도와주는 것은 직무 분리, 역할 기반 접근, 그리고敏感한 읽기 작업을 감시하는 감사 기록입니다.
고객 기록에 접근한 사람, 언제 접근했는지, 왜 접근이 허용되었는지에 대한 정보를 알 수 없다면, 데이터베이스 제어는 더 강력하게 보이지만 실제로는 약합니다.
부주의 노출
이것은 빠르게 움직이는 팀에서 가장 일반적인 범주입니다. 미설정된 저장소 버킷. 스테이징 환경에 라이브 데이터를 시드합니다. 토큰이나 개인 정보를 포함하는 디버그 로그. 복원된 백업을 낮은 보안 환경에 배치하여 디버깅을 위해.
부주의 노출이 왜 강력한 저장소 보안이 작동해야 하는 이유입니다. 하나의 설정으로 해결할 수 없습니다. 데이터 분류, 경계, 검토, 정기적인 청소로 해결합니다.
데이터베이스 보안의 핵심 원칙
보안 데이터베이스 저장은 일반적인 실수들의 연쇄에서 발생하는 위협을 끊는 데 중점을 둡니다. 보안 데이터베이스 저장은 시스템이 변경되는 동안 이러한 연쇄를 끊고 끊기도록 유지해야 합니다.
저는 작업을 네 가지 기둥으로 분류합니다: 암호화, 접근 제어, 감사, 최소화. 백업 및 복구도 중요하지만, 복원된 데이터가 새로운 취약점이 될 수 있기 때문에 운영 처리에 별도의 처리가 필요합니다.
암호화는 훼손된 데이터의 가치를 낮추고
암호화는 시간을 벌고 영향을 줄입니다. someone이 디스크 스냅샷, raw 백업 파일, 또는 내부 네트워크에서 트래픽을 가져오면 암호화된 데이터는 고객 기록으로 변환하기가 훨씬 더 어렵습니다.
암호화는 데이터베이스 파일, 스냅샷, 백업 아티팩트를 보호합니다. 연결된 애플리케이션 서버, 프록시, 데이터베이스 엔진 간의 트래픽은 TLS로 보호됩니다. NIST는 SP 800-111 및 관련 데이터-아트-레스트 권장 사항에서 이러한 제어를 다룹니다. SP 800-111은 데이터-아트-레스트 권장 사항을 포함합니다..
운영상의 트레이드 오프는 이론적인 것과 다릅니다. 암호화는 데이터 경로와 함께 키 관리가 분리되어 유지되는 경우에만 도움이 됩니다.velope 암호화는 건물 주 키와 잠긴 사무실 키와 같이 작동합니다. 키 관리 서비스는 마스터 키를 보호하고, 그 마스터 키는 실제 레코드 또는 파일에 사용되는 임시 데이터 키를 암호화합니다. 이 설계는 회전 중 노출을 제한하고 키 재발급 또는 키 재치환을 수행할 때 모든 것을 다시 작성하지 않고도 더 쉽게 취소하거나 대체할 수 있습니다.
팀은 암호화를 활성화한 후 그만두면 문제가 생깁니다. 키가 어디에 있는지, 누구가 키를 사용할 수 있는지, 키 회전이 예약되어 있는지, 그리고 잊어버린 키 버전이 여전히 이전 백업에 의존하는지 확인해야 합니다.
접근 제어는 폭파 반경을 제한합니다.
권한은 조직도에 따라 결정되지 않아야 합니다.
API 체크아웃을 위한 데이터베이스 역할은 급여 데이터를 읽을 수 없습니다. 배경 작업자는 초기 마이그레이션 시 편리했기 때문에 스키마 변경 권한이 없습니다. 지원 도구는 필터링된 뷰 또는 승인된 절차를 사용하여 대량 테이블 접근 대신 사용해야 합니다.
실용적인 모델은 다음과 같습니다.
- 웹 앱 역할: 사용자 요청에 대한 테이블 뒤의 읽기 및 쓰기 권한이 제한됩니다.
- 작업자 역할: 작업자가 실행하는 작업에 필요한 레코드에 대한 접근 권한이 있습니다.
- 분석 역할: 가공된 데이터 세트에 직접 식별자 제거가 가능한 경우 읽기 전용 접근 권한이 있습니다.
- 데이터베이스 보안 저장소 관리자 역할:
단기 승인 접근 권한과 강력한 로깅 및 검토. 이 기둥은 데이터 변환과 함께 강화될 때 더 강해집니다. 팀이 마스크드 또는 축소된 데이터로 작업할 수 있다면, 전체 생산값 대신 그 버전을 제공하는 것이 좋습니다. 규제된 건강 데이터의 경우 PHI의 비식별화
유용한 접근과 불필요한 노출의 차이입니다. API key security for app store compliance__CAPGO_KEEP_0__ 키 보안을 위한 앱 스토어 준수
특히.
감사 결과 제어가 실제인지 여부를 보여줍니다.
검증할 수 없는 정책은 단순히 희망입니다.
감사 기록은 사건 중 발생하는 질문에 답합니다. 어떤 식별자가 레코드를 읽었는지. 어떤 역할이 권한을 변경했는지. 어떤 수출 작업이 데이터를 이동했는지. 어떤 키가 암호화된 아카이브를 해독했는지. 또한 느린 드리프트를 드러냅니다. 예를 들어, 서비스 계정은 이전에 필요하지 않았던 테이블에 접근하기 시작했습니다.
- 인증 활동: 성공 로그인, 실패 로그인, 토큰 사용, 및 관리자 세션.
- 권한 변경: 허가, 취소, 역할 생성, 정책 편집, 및 스키마 변경.
- Sensitive 접근 패턴: 대량 읽기, 큰 내보내기, 비정상 쿼리 경로, 및 예상 시간 또는 원본 네트워크 외부 접근.
- 키 관리 이벤트: 키 생성, 회전, 암호화 실패 시도, 비활성화 버전, 및 KMS 또는 비밀 저장소의 정책 변경.
로그 보관은 중요합니다. 또한 검토도 중요합니다. 만약 로그가 만료되기 전에誰도 조사하지 못한다면, 또는誰도 권한 변경을 검토하지 않는다면, 감사 시스템은 이론적으로만 존재합니다.
implementation 세부 사항이 너무 추상적이 되기 전에 좋은 설명자입니다:
Sensitive 데이터를 잘 지키는 것은 잘 지키지 못하는 곳에 데이터를 넣지 않는 것입니다.
Minimization은 많은 팀이 가장 적은 엔지니어링 노력으로 가장 큰 보안 승리를 얻는 곳입니다.
더 적은 데이터를 저장하고, 더 적게 보관하고, 복사할 곳이 적은 곳에 저장하세요. 만약 특정 기능이 나이대 범위만 필요하다면, 생년월일을 전부 저장하지 마세요. 만약 지원이 마지막 네 자리만 필요하다면, 전부 노출하지 마세요. 만약 테스트 환경이 실제 개인 데이터가 필요하지 않다면, 생산 백업을 복원하지 마세요.
이것도 운영 방식입니다. 보관 기간이 필요한 경우, 강제로 지키세요. 이전 백업을 삭제하세요. 다운스트림 시스템을 검토하세요._sensitive field가 검색 인덱스, 캐시, 데이터 레이크, 모바일 저장소, ad hoc CSV 파일에 복제될 때마다 위험성이 증가합니다. Capacitor 앱의 경우 Capgo marketing website의 @capgo/capacitor-data-storage-sqlite 그리고 Capgo marketing website의 @capgo/capacitor-fast-sql 암호화된 앱 내부 저장소를 제공할 수 있지만, 여전히 저장하지 말아야 할 데이터를 결정해야 합니다.
이러한 기둥의 목적은 첫 번째 날에 완벽함이 아닌, 키 회전, 직원 변경, 사고 대응, 백업 복원, 제품 성장과 같은 상황에서 저장 시스템이 방어할 수 있는지 여부입니다. 보안 데이터베이스 저장이 성공하거나 실패하는 지점입니다.
실용적인 구현 패턴
암호화 패턴은 시스템마다 하나씩은 아닙니다. 올바른 선택은 무엇을 보호하고, 누구에게 쿼리할 수 있는지, 팀이 지원할 수 있는 복잡도에 따라 달라집니다. 실수는 가장 강력한 sounding 패턴을 선택하고 나서 나쁜 구현을 하는 것입니다.
TDE는 가장 빠른 기본선입니다.
Transparent Data EncryptionTDE, 즉 투명 데이터 암호화는 일반적으로 가장 쉬운 시작점입니다. 데이터베이스 엔진은 디스크에 파일을 암호화하고 엔진이 메모리에 읽어 들일 때 암호문을 해독합니다. 애플리케이션은 일반적으로 code 변경이 필요하지 않습니다.
다음과 같은 강력한 기본선입니다:
- 전체 데이터베이스 보호
- 저장 장치 수준의 준수 요구 사항
- 스냅샷, 디스크 또는 raw 파일 접근으로부터의 위험 감소
TDE는 모든 것을 보호하지 않습니다. 공격자가 유효한 데이터베이스 접근 권한을 얻으면 엔진은 여전히 암호화되지 않은 데이터를 제공합니다. 따라서 TDE는 저장 장치 위반이 아닌 유효한 자격 증명으로의 남용을 방지하는 데 도움이 됩니다.
응용 프로그램 수준의 암호화는 가장 중요한 field를 보호합니다
응용 프로그램 수준의 암호화는 데이터가 데이터베이스에 도달하기 전에 발생합니다. code 선택한 field를 암호화하고 암호문을 저장 장치에 기록합니다. 특히 sensitive 열, chẳng hạn như 정부 ID, 은행 정보, 복구 비밀, 또는 개인 노트와 같은 경우에 잘 작동합니다.
그런 추가 제어는 다음과 같은 대가와 함께 오릅니다:
- 당신은 더 많은 복잡성을 소유하고 있습니다: 키 선택, 암호화 라이브러리, 회전 동작 및 오류 처리.
- 쿼리하기가 더 어려워집니다: 정확한 매치, 부분 검색 및 색인화가 설계 문제가 됩니다.
- 개발자는 discipline이 필요합니다: 이동 스크립트에서 단 하나의 단축키가 모델 전체를 무력화할 수 있습니다.
단순한 가짜 코드 패턴은 다음과 같습니다:
| 단계 | 액션 |
|---|---|
| 1 | 요청에서 평문 field를 읽습니다 |
| 2 | 키 서비스에서 데이터 암호화 키를 요청하거나 wrapped local key를 사용합니다 |
| 3 | 응용 프로그램에서 field를 암호화합니다 |
| 4 | 데이터베이스에 암호문과 메타데이터를 저장하십시오. |
| 5 | 만약 읽기 경로가 승인된 경우에만 암호문을 해독하십시오. |
애플리케이션의 로컬 영속성에 대한 설계 질문은 동일합니다. 장치에 오프라인 토큰이나敏感한 동기화 상태를 저장한다면, 기본적으로 모바일 저장소가 안전하다고 가정하지 마십시오. 플랫폼에 대한 패턴을 사용하십시오. __CAPGO_KEEP_0__에서 discussed된 것과 같은 것들. secure storage for offline tokens in Capacitor.
Envelope 암호화는 두려운 것처럼 들릴 수 있지만, 아이디어는 간단합니다. 데이터를 하나의 키로 암호화한 다음, 그 키를 다른, 더 잘 보호된 키로 암호화합니다.
문서를 작은 safe에 잠그고, 그 작은 safe의 키를 은행 금고에 잠그는 것과 같습니다. 만약 someone이 문서 저장層을 훔친다면, 그들은 여전히 더 높은 보호 수준의 금고 키에 접근해야 합니다. 그 키를 얻기 전에.
일반적인 흐름:
데이터 키를 생성하십시오.
- 해당 레코드, 파일, 또는 batch에 대한 데이터 키를 생성하십시오. 데이터를 그 데이터 키로 암호화하십시오.
- 데이터를 그 데이터 키로 암호화하십시오. with that data key.
- 데이터 키를 Wrap하세요 KMS 또는 HSM에서 Master 키를 사용하세요.
- 암호화된 데이터와 Wrap된 키 메타데이터를 레코드 또는 객체와 함께 저장하세요.
- 권한이 있는 읽기 중에만 unwrap하세요.
Field 조언: Envelope 암호화 사용하여 강력한 격리성을 필요로 하면서도 Master 키를 모든 애플리케이션 서버에 노출하지 않으려면.
이 패턴은 성능과 제어가 균형을 이루는 이유로 일반적입니다. 애플리케이션은 실제 암호화 작업을 위해 짧은 수명 데이터 키를 사용하며, KMS 또는 HSM은 Wrap 및 unwrap을 위해 사용하는 Master 키를 보호합니다.
암호화 패턴 비교
| 패턴 | Implementation 복잡도 | 성능 영향 | __CAPGO_KEEP_0__ |
|---|---|---|---|
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | 서버 및 연결된 저장장치에 대한 인프라 수준 보호 |
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | 높은 민감도 컬럼과 엄격한 분리 필요성 |
| Envelope 암호화 | 중간에서 높은 | 중간 | 강한 키 분리 및 확장 가능한 키 관리가 필요한 시스템 |
실제 규칙은 간단합니다. 강력한 기본선으로 TDE 또는 관리 중인 휴지 상태 암호화를 시작하고, 데이터 민감도 및 위협 모델이 추가 엔지니어링을 정당화하는 경우에만 field-level 또는 envelope 암호화를 추가하세요.
키 및 비밀 관리
침입은 일반적인 비밀 처리 실수로 시작합니다. 프로덕션 데이터베이스는 암호화되어 있으며 백업이 존재하고, 접근 권한은 종이로 제어되는 것처럼 보입니다. 그런 다음 CI 작업이 로그에 토큰을 출력하거나, 엔지니어가 지원 스크립트에 관리자 자격 증명을 재사용하거나, 팀이 생성한 키가 더 이상 활성화되지 않도록 팀이 이동한 후에도 오래된 키가 활성화된 채로 남아 있습니다.
이것이 키 및 비밀 관리가 운영 관행이 아닌 설정 작업이 아닌 이유입니다.
잘못된 키 관리로 암호화된 데이터베이스는 서버 룸에 잠금이 걸린 상태에서 접근 자격 증명이 문에 걸려 있는 것과 같습니다. 정부 지침도 같은 점을 강조합니다. 암호화만으로는 KMS 또는 HSM 기반 키 관리, 최소 권한 접근, 복구 계획을 생략하는 팀이 존재하는 경우에만 격차를 메우지 못합니다. NSA와 파트너의 클라우드 데이터를 안전하게 보호하는 지침.
팀이 이것을 잘못하는 곳
사고 리뷰에서 익숙한 패턴은 다음과 같습니다:
- code 소스코드 내에 있는 비밀: 직접 입력한 인증 정보, 내장된 인증서, 또는 점차적으로 프로덕션 의존성을 갖는 유틸리티 스크립트.
- 복사한 설정 파일 내의 비밀: 노트북 간에 파일을 전달하거나 공유 폴더에 저장하거나 급히 수정하는 동안 커밋하는 파일.
- 강제 제어가 약한 환경 변수: 편리하지만, 빌드 로그, 셸 히스토리, 크래시 리포트, 또는 광범위한 런타임 권한을 통해 노출되는 경우.
- 회전에 대한 소유권이 없습니다: 키가 몇 년 동안 존재하는 이유는 팀이 재발급, 배포, 롤백 계획을 소유하지 않기 때문입니다.
- 고등 권한의 공유 비밀: 응용 프로그램, 엔지니어, 및 자동화에 사용되는 하나의 인증 정보로, 감사 및 제한이 훨씬 더 어려워집니다.
애플리케이션 및 인프라 비밀을 저장하는 방법에 대한 실용적인 참고 자료를 만드는 경우 보안 환경 변수 팀이 임의의 비밀 정보 분산에서 벗어나도록 도울 수 있습니다.
좋은 키 관리 방법
중앙 집중식 정책, 접근 제어, 감사 로그, 예약된 회전이 사용자 정의 하드웨어 제어보다 더 중요할 때 사용하세요. 중앙 집중식 정책, 접근 제어, 감사 로그, 예약된 회전이 사용자 정의 하드웨어 제어보다 더 중요할 때 사용하세요. 위험, 규정 준수 요구 사항, 서명 및 키 보호 규칙이 전용 하드웨어 경계를 정당화할 때 사용하세요. 많은 팀이 HSM을 모든 곳에서 사용할 필요가 없습니다. 그들은 시스템이 암호 해독 작업을 요청할 수 있는 규칙, 인간이 정책을 변경할 수 있는 규칙, 그리고 이러한 작업이 검토되는 방법에 대한 명확한 규칙이 필요합니다. 봉투 암호화는 좋은 정신 모델입니다. 애플리케이션은 암호화 작업을 위해 짧은 수명 데이터 키를 처리합니다. 보관함 키는 KMS 또는 HSM에 머물며 접근이 엄격하게 제한됩니다.
실제 사고를 방지하는 제어가 운영입니다:
키를 일정한 주기로 회전할 수 있는 일정한 주기를 설정하세요:
- 회전은 compromized 키의 유용한 수명을 줄지만, 애플리케이션, 작업, 복원 작업이 이후에도 작동할 수 있는지 확인하세요. __CAPGO_KEEP_0__
- 업무를 분리하십시오: 고객 데이터를 읽는 서비스는 키 정책을 변경하거나 로깅을 비활성화할 수 없어야 합니다.
- _sensitive한 키 이벤트를 로깅하십시오: 키 생성, 회전, 암호화 요청, 접근 실패 시도 및 정책 변경이 모두 표시되어야 합니다.
- 재 암호화 경로를 테스트하십시오: wrapping 키를 회전하는 것이 일반적으로 애플리케이션 데이터를 재 암호화하는 것보다 쉽지만, 두 가지 모두 롤백 단계와 롤백 단계가 필요합니다.
- 기존 비밀을 비활성화하고 폐기하십시오: 시간을 두고 전환 후에陈舊한 자격 증명을 제거하여 quiet backdoor가 되지 않도록 하십시오.
CI/CD는 프로덕션 런타임과 같은 discipline을 deserves합니다. 빌드 시스템은 넓은 접근 권한과 약한 가시성을 가지고 있기 때문에, 비밀 누출의 일반적인 장소입니다. 이에 대해 진지하게 생각하는 팀들은 일반적으로 CI/CD pipeline에서 비밀 관리를 formalize합니다. 관리하는 비밀에 대한 규칙은 단순합니다. 애플리케이션은 __CAPGO_KEEP_0__에서 신뢰할 수 있는 시스템에서 암호화 연산을 요청해야 하며, raw master 키를 환경 내에서 운반하지 않아야 합니다. CI/CD pipeline에서 비밀 관리를 formalize하는 대신, pipeline 자격 증명을 임시 예외로 취급하지 않습니다.
One rule is simple. Application code should request cryptographic operations from trusted systems, not carry raw master keys around the environment.
스택 내에서 가장 강력한 암호화 설계가 의미가 없는 순간이 오면, 개발자, pipeline, 또는 지원 도구가 마스터 키를 잘못된 위치에 복사할 수 있는 순간입니다.
강건한 백업 및 복구 전략 설계
백업은 안전한 데이터베이스 저장에 포함되어야 하며, 별도의 관리 업무가 아닙니다. 만약 프로덕션 환경이 보호되고 백업이 보호되지 않은 경우, 공격자는 더 쉬운 경로를 선택할 것입니다.
Independent storage guidance recommends keeping backup and recovery systems at the same protection level as production because ransomware and malware incidents often leave secure, tested backups as the only viable recovery path, according to Hypertec’s secure data storage guidance.
백업은 자신의 보안 경계를 필요로 합니다.
강건한 백업 설계에는 몇 가지 속성이 있습니다.
- 백업은 전송 중 및 저장 중 암호화됩니다.
- 백업 자격 증명은 프로덕션 자격 증명과 분리됩니다.
- 삭제 및 보존 제어는 일반 앱 접근보다 더 어렵습니다.
- 복원 대상은 약한 제어가 있는 shadow 프로덕션 환경이 아닌 복원 환경으로 변하지 않습니다.
일반적인 실패 모드는 암호화된 백업을 저장하는 동안 프로덕션 역할이 그들을 삭제할 수 있도록 허용하는 것입니다. 또 다른 것은 로깅이 없는 임시 환경으로 복원하는 것입니다. 복구 경로는 주요 경로와 같은 심사에 적합합니다.
실제 제어는 테스트 복원입니다.
테스트되지 않은 백업은 단순히 희망적인 저장소입니다.
복원에 잘 대처하는 팀은 단순히 백업 작업이 완료되었는지 확인하는 것만으로는 충분하지 않습니다. 그들은 복원 작업이 작동하는지, 복원된 데이터가 사용 가능한지, 필요할 때 암호화 키, 연결 설정 및 종속 서비스가 모두 일치하는지 증명합니다.
실용적인 복원 프로그램에는 다음과 같은 요소가 포함됩니다.
- 정기적인 복원 연습 격리된 환경으로
- 응용 프로그램 기능의 검증 데이터베이스 복원 후, 파일 복원만으로는 아닙니다.
- 키 사용 가능성 확인 암호화된 백업이 복원될 수 있도록
- 복원된 시스템에 대한 접근 검토 사고 시敏감데이터가 널리 공개되지 않도록 방지합니다.
백업만으로는 당신을 구하지 못합니다. 성공적인 복원만이 당신을 구합니다.
만약 백업 생성만 테스트하고, 실제로 복원 테스트를 하지 않는다면, 당신은 회복 전략을 검증하지 못했습니다. 단지 파일이 누적되는 장소가 있다는 것을 검증했습니다.
데이터베이스 보안을 위한 개발자 체크리스트
이 체크리스트는 디자인 리뷰, 릴리즈 리뷰, 그리고 사후 인시던트 클린업 시에 팀이 사용하길 원하는 체크리스트입니다.
설계
- _sensitive field_을 명확하게 식별했습니까?: 개인 데이터, 인증 자료, 금융 기록, 보존 규칙에 따라야 하는 모든 것.
- 저장하지 말아야 하는 것을 결정했습니까?: 기능이 필요하지 않은 field, 다운스트림 팀이 피할 수 있는 복사본.
- 데이터가 어디서 살아갈지 매핑했습니까?: 생산, 스테이징, 로그, 내보내기, 분석 시스템, 백업, 클라이언트 디바이스.
구현
- 데이터는 저장 중 및 전송 중 암호화되어 있는가: 데이터베이스, 복제본 및 백업 경로에 대해
- 응용 프로그램 및 서비스 역할은 엄격하게 범위가 지정되어 있는가: 일반 앱 트래픽에 대해 공유 슈퍼 사용자 없음.
- 비밀 키 및 암호화 키는 code와 느슨한 구성 외부에서 처리되는가: 통제된 접근 및 감사 가능성.
- 敏감 정보 접근 및 특권 변경은 중앙 위치에서 로깅되는가: 수정 가능.
운영
- 키 회전 및 비밀 검토는 정상적인 운영의 일부인가: 연간 대소동이 아닌.
- DB 복원 테스트를 정기적으로 수행합니까? 복구 시스템에서 암호화, 애플리케이션 시작, 접근 검토를 포함합니다.
- 데이터 스푸로를 지속적으로 감사합니다. 준비 중인 복사본, 지원 수출, 개발 데이터 세트 및 잊혀진 백업 위치를 포함합니다.
좋은 보안 데이터베이스 저장은 프로젝트 단계가 아닙니다. 반복적인 실천입니다.
자주 묻는 질문
Cloud 제공업체 기본 암호화가 충분합니까?
강한 기본선이지만 완전한 전략이 아닙니다. 기본 암호화는 저장 매체 및 관리 서비스를 보호하지만, 과도한 접근 권한, 복사된 데이터 세트, 약한 백업 제어, 나쁜 키 관리와 같은 문제를 해결하지 않습니다.
암호화가 데이터베이스 성능에 영향을 미칩니까?
일부 경우에 yes. 패턴에 따라 영향이 달라집니다. 인프라 및 데이터베이스 수준 암호화는 일반적으로 더 적은 애플리케이션 복잡성을 가지고 있습니다. field-level 암호화는 선택된 데이터에 더 강한 제어를 제공하지만, 색인, 필터링 및 검색을 복잡하게 만들 수 있습니다. 작업 부하에 대한 측정을 통해 광범위한 배포 전에 측정하세요.
이것은 SQL 및 NoSQL 시스템에 대해 다릅니까?
원칙은 동일합니다. 여전히 암호화, 최소 권한, 감사, 키 관리 및 테스트 복구가 필요합니다. implementation 세부 사항은 문서 저장소, 키-값 저장소 및 관계형 시스템이 다른 접근 모델 및 쿼리 동작을 노출하기 때문에 다릅니다.
토큰화와 암호화는 어떻게 다른가?
암호화는 권한이 있는 시스템이 올바른 키로 암호를 해독할 수 있도록 데이터를 변환합니다. 토큰화는敏感한 값을 대체 값으로 대체하고 원본 데이터를 분리합니다. 토큰화는 앱 워크플로우에서 노출을 줄일 수 있지만 시스템 설계 복잡성을 추가하고 강력한 저장 제어가 필요하지 않습니다.
Capgo는 Capacitor 및 Electron 앱에 빠르게 수정을 배포하는 데 도움이 됩니다. signed web bundle delivery, rollout controls, rollback protection, 및 release observability가 포함됩니다. Storage, auth, 또는 API 오류로 인한 사고 대응 계획이 클라이언트 측 수정을 빠르게 배포하는 데 의존하는 경우 Capgo를 평가하는 것이 가치가 있습니다. Capgo __CAPGO_KEEP_0__
