![[Secure Database Storage: A Complete Guide for Developers]](/blog-images/secure-database-storage.webp)
밤 늦게 릴리스를 푸시하고 알림을 훑어보면, private repo에 절대 shouldn't 나와야 하는 credential이 나타난다. 그 credential은 database password가 될 수도 있고, cloud access key가 broader permissions를 가지고 있는 경우도 있다. 그 문제는 someone이 로그인할 수 있는 문제가 아니라, storage lifecycle 문제를 해결하지 못했기 때문이다.
실제 시스템에서 이것은 어디서나 나타난다. 팀은 암호화를 한번만 활성화하고, 그 이후로는 끝이라고 생각한다. 백업을 하지만 복원 테스트를 하지 않는다. 편의를 위해 admin service account를 만들고, 그것이 존재하는 것을 잊어버린다. 프로덕션을 잠근 후, 스테이징에 고객 데이터의 복사본이 남아있는 경우도 있다. mobile이나 web 앱을 개발하고 있다면, secure database storage는 primary database, replicas, exports, logs, backups, keys를 모두 포함해야 한다.
만약 당신이 다음 앱의 auth를 해결하고 있다면, remember that authentication과 storage security는 다른 failure mode를 해결한다. Auth는 누구를 허용할지 결정한다. Storage security는 someone이 로그인하거나, data가 예상치 못한 경로를 통해 유출될 때의 피해를 제한한다. 고객을 대면하는 앱을 shipping하는 팀은 storage decision을 adjacent controls와 일치시키는 것이 중요하다. 예를 들어, app store compliance를 위한 __CAPGO_KEEP_0__ security standards와 같은 것들. API security standards for app store compliance.
If you’re also working through 2020년 64.2 제타바이트의 전 세계 데이터 생산량은 2025년까지 180 제타바이트로 증가할 것으로 예상되었습니다. __CAPGO_KEEP_0__에 따르면 Edge Delta의 데이터 저장소 요약. 그 규모에서 보안 저장은 보안 작업이 아닌 아키텍처가 됩니다.
목차
- 데이터베이스 보안은 단순한 비밀번호만으로 충분하지 않다.
- 데이터베이스 위협 모델을 이해하는 방법
- 안전한 데이터베이스 저장소의 핵심 기둥
- __CAPGO_KEEP_1__
- __CAPGO_KEEP_6__에서 팀이 잘못하는 곳
- __CAPGO_KEEP_0__
- __CAPGO_KEEP_1__
- __CAPGO_KEEP_5__
Why Database Security Is More Than Just a Password
비밀번호는 입구를 보호하지만 데이터를 보호하지 못한다. 인증 정보가 유출되거나 스냅샷이 복사되거나 내부 서비스가 표준 권한을 넘어서 테이블을 읽을 때 데이터를 보호하지 못한다. 그래서 안전한 데이터베이스 저장을 층별로 해야 한다.
기존의 생각 방식은 단순했다: 데이터베이스를 방화벽 뒤에 두고 강력한 비밀번호를 요구하고 외부 사람들을 막으면 된다. 그런 모델은 클라우드 시스템, 모바일 백엔드, 현대 CI/CD PIPELINE에서 깨진다. 데이터는 서비스 간에 이동한다. 엔지니어는 임시 수출을 만든다. 분석 작업은 기록을 복제한다. 백업 시스템은 다른 인프라에서 복사본을 저장한다. 공격자는 데이터베이스 엔진을 깨트리지 않아도 키를 훔치거나 API 토큰을 남용하거나 더 약한 제어를 가진 복제본을 찾으면 된다.
보안은 조용한 경로에서 실패한다
가장 손상이 되는 저장 실패는 처음에는 드라마틱하지 않다. 보통이다.
- 개발자 편의성이 프로덕션 위험으로 변한다: 공유된 관리자 인증 정보가 스크립트에 재사용된다. 회전하면 배포가 깨진다.
- 복사된 데이터셋이 규제를 벗어난다: 프로덕션 기록이 스테이징으로 복제되어 버그를 재현하기 위해 QA가 사용한다.
- 백업이 약점이 된다: 프로덕션에는 강력한 제어가 있지만 복원 버킷이나 스냅샷 정책이 약하다.
실용적인 규칙: 만약 공격자가 읽을 수 있는 데이터와 하나의 자격증만이 사이에 있다면, 안전한 저장소가 아니라 단일 취약점이 있습니다.
취약점 방어는 자격증 남용에 견디어야 합니다.
Microsoft의 클라우드 지침은 전송 및 휴면 중 암호화, 최소 권한 접근 제어, 비인가 활동 모니터링을 포함한 클라우드 데이터 보안 최적화 방안을 권고합니다. 그것이 올바른 기준입니다. 실제 사고는 유효한 접근 권한을 잘못 사용하는 경우가 많습니다.실무에서 성공하는 방법은 단조로운 일입니다. 데이터베이스 파일을 암호화하십시오. 연결을 암호화하십시오. 서비스 역할을 분리하십시오. 관리자 권한을 제거하십시오. sensitive한 연산을 로깅하십시오. 비정상적인 사용 패턴에 대한 알림을 설정하십시오. 그 모든 것이 화려하지 않지만 실제 침해를 예방합니다.
이것을 생각하는 유용한 방법은 물리적 금고입니다. 금고 문이 중요합니다. 또한 분리 잠금, 카메라 촬영, 방문 기록, box를 열 수 있는 정책이 중요합니다. 안전한 데이터베이스 저장소도 마찬가지입니다. 암호는 단지 출입문입니다.
데이터베이스 위협 모델 이해하기
데이터 보안을 위한 데이터베이스 저장소 위협 모델을 만들기 전에, 시스템이 실패하는 방법을 매핑하세요. 데이터베이스 저장소 위협 모델은 학술적인 필요가 없습니다. 데이터베이스에 접근할 수 있는 사람, 접근 방법, 성공 시 발생하는 결과를 알려주면 됩니다.
데이터베이스 위협 모델을 만드는 5단계의 프로세스.
보안 데이터는 일반적으로 한 개의 정돈된 프로덕션 데이터베이스에 존재하지 않는다. 현대적인 지침은 보안 정보가 복사본, 백업, 로그 및 개발 환경에 종종 나타나기 때문에 주요 데이터베이스 외에서 실패가 발생하는 것을 고려하여 발견 및 태세 관리를 강조한다. 클라우드 데이터 보안 및 태세 관리에 대한 센트라의 개요. 그 이유는 위험 발생 시 대응을 위한 계획이 포함해야 하기 때문이다. 예를 들어, 제3자 노출 및 복사된 데이터 세트와 같은 시나리오도 포함해야 한다. 이러한 경우에는 더 광범위한 대응 플레이북, 예를 들어 제3자 침해 대응 최선의 방법을 고려해야 한다.
도구보다 자산을 먼저 고려하라
중요한 것은 무엇인지 먼저 나열하고 제품을 나열하라.
대부분의 앱 팀에게는 이러한 중요한 자산이 명확하다:
- 고객 기록 예를 들어 프로필, 주문 내역, 결제 관련 메타데이터 또는 건강 관련 콘텐츠.
- 인증 자료 예를 들어 패스워드 해시, 세션 기록, 리프레시 토큰 또는 API 비밀.
- 운영 데이터 예를 들어 감사 로그, 작업 큐, 관리자 노트 및 지원 수출과 같은 것들.
- 복구 자산 예를 들어 스냅샷, 논리적 덤프, 특정 시점 로그 및 암호화 키와 같은 것들.
그 마지막 항목은 팀이 생각하는 것보다 더 중요합니다. 공격자가 백업을 삭제하거나 복호화 키에 접근할 수 있다면, 복구 스토리가 붕괴됩니다.
가장 중요한 3가지 위협 그룹
개발자와 함께 사용하는 간단한 모델을 사용하여 3개의 그룹을 나눕니다.
외부 공격자
이것은 사람들이 가장 먼저 생각하는 그룹입니다. SQL 인젝션, 훔친 API 토큰, 누출된 클라우드 자격 증명, 노출된 관리자 패널, 취약한 의존성. 공통된 주제는 데이터에 접근할 수 있는 외부자입니다.
질문하기
- 데이터베이스를 앱을 통해 직접 조회할 수 있나요?
- 스텔린 서버 자격 증명이 여러 서비스가 필요로 하는 것보다 더 많은 것을 읽을 수 있나요?
- __CAPGO_KEEP_0__
내부 위협
이것은 악의적인 내부자와 권한이 너무 많은 잘못된 의도 없는 직원도 포함합니다. 지원 엔지니어는 티켓을 해결하기 위해 데이터를 내보냅니다. 계약자는 로컬 복사본을 유지합니다. 플랫폼 관리자는 생산 라인에 접근할 수 있지만 그들의 직업이 그것을 요구하지 않습니다.
역할 기반 접근 권한과 감사 기록이敏감한 읽기를 가시화하는 것이 도움이 됩니다.
데이터베이스 제어가 더 강력하게 보이더라도 고객 기록에 접근한 사람, 언제 접근했는지, 왜 접근이 허용되었는지에 대한 답을 할 수 없다면, 데이터베이스 제어는 약합니다.
실수로 노출
이것은 빠르게 움직이는 팀에서 가장 일반적인 범주입니다. 미설정된 저장소 버킷. 라이브 데이터로 채워진 스테이징 환경. 토큰이나 개인 정보가 포함된 디버그 로그. 복원된 백업을 낮은 보안 환경에 배치하여 문제 해결을 위해.
실수로 노출이 강력한 저장소 보안이 작동해야 하는 이유입니다. 하나의 설정으로 해결하지 않습니다. 데이터 분류, 경계, 검토, 정기적인 청소로 해결합니다.
데이터베이스 보안 저장소의 핵심 원칙
침해가 거의 항상 한 번의 극적인 실패에서 오지 않습니다. 보통은 일상적인 실수들의 연쇄에서 오는 것입니다. 백업이 잘못된 계정으로 복사됩니다. 서비스가 더 많은 권한을 필요로하지 않아도 더 많은 권한을 얻습니다. 오래된 키가 몇 달 동안 활성화된 채로 남아 있는 것은 rotation이 연기된 것을 계속 연기했기 때문입니다. 데이터베이스 보안 저장소는 그 체인을 여러 곳에서 끊고, 시스템이 변할 때도 계속 끊어야 합니다.
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__.
__CAPGO_KEEP_0__
팀들이 암호화 기능을 활성화하고 그 이상으로 멈추면 문제가 생깁니다. 키가 어디에 저장되어 있는지, 누구든지 키를 사용할 수 있는지, 키 회전이 예약되어 있는지, 그리고 잊어버린 키 버전으로 인해 여전히 구형 백업이 의존하는지 확인하세요.
접근 제어는 폭파 반경을 제한합니다.
권한은 조직 차트에 따라서 아니라 애플리케이션 경계를 따라야 합니다.
체크아웃 API의 데이터베이스 역할은 급여 데이터를 읽을 수 없어야 합니다. 배경 작업자는 이전 마이그레이션 시 편리했지만 스키마 변경 권한이 있어서는 안 됩니다. 지원 도구는 필터된 뷰 또는 승인된 절차를 사용하여 넓은 테이블 접근 대신 사용해야 합니다.
실용적인 모델은 다음과 같습니다.
- 웹 앱 역할: 사용자 요청의 뒤에 있는 테이블에 대한 제한된 읽기 및 쓰기 접근 권한.
- 작업자 역할: 작업자가 실행하는 작업에 필요한 레코드에 대한 접근 권한.
- 분석 역할: 편집된 데이터 세트에 직접 식별자가 제거된 경우 가능한 경우에 읽기 전용 접근 권한.
- 비상 사태 관리자 역할: 단기 승인 접근 권한과 강력한 로깅 및 검토.
데이터 변환과 pair 될 때 이柱가 강해집니다. 팀이 마스킹된 데이터 또는 축소된 데이터로 작업할 수 있다면, 전체 프로덕션 값을 제공하는 대신 그 버전을 제공하세요. 규제된 건강 데이터의 경우 PHI의 비식별화 유용한 접근과 불필요한 노출의 차이입니다.
데이터베이스 주변의 비밀은 동일한 discipline을 deserve합니다. 저장소 제어를 강화하는 팀이 CI 로그, 모바일 빌드, 또는 지원 스크립트에 머신 자격 증명을 퍼뜨리면 여전히 공격 경로가 넓습니다. 동일한 운영 습관이 모바일 앱과 백엔드 서비스가 신뢰 경계를 공유할 때도 적용됩니다. API 키 보안을 위한 앱 스토어 준수특히.
감사 결과, 제어가 실제인지 확인합니다.
검증할 수 없는 정책은 단순히 희망입니다.
감사 기록은 사건 중 발생하는 중요한 질문에 답합니다. 어떤 식별자가 레코드를 읽었는지. 어떤 역할이 권한을 변경했는지. 어떤 수출 작업이 데이터를 이동했는지. 어떤 키가 암호화된 아카이브를 해독했는지. 또한 느린 드리프트를 노출합니다. 예를 들어, 서비스 계정은 이전에 필요하지 않은 테이블에 접근하기 시작했습니다.
유용한 감사 범위는 일반적으로 다음을 포함합니다.
- 인증 활동: __CAPGO_KEEP_0__
- 성공 로그인, 실패 로그인, 토큰 사용, 및 관리 세션. 권한 변경:
- 권한 부여, 취소, 역할 생성, 정책 편집, 및 스키마 변경. 敏감한 접근 패턴:
- 대량 읽기, 큰 내보내기, 비정상적인 쿼리 경로, 및 예상 시간이나 원본 네트워크 외부 접근. 키 관리 이벤트:
키 생성, 회전, 암호화 실패 시도, 비활성화된 버전, 및 KMS 또는 비밀 저장소의 정책 변경.
로그가 만료되기 전에 anybody가 조사하지 못하거나, 이미 침해가 발생한 경우에만 권한 변경을 검토하는 경우, 감사 시스템은 이론적으로만 존재합니다.
implementation details가 너무 추상해지기 전에 좋은 설명을 먼저 하세요.
敏감한 데이터를 잘 지키는 것은 잘 지키지 못하는 곳에서 잘 지키는 것입니다.
민감한 데이터를 최소화하는 것은 많은 팀이 최소한의 엔지니어링 노력으로 가장 큰 보안 승리를 얻는 곳입니다. 데이터를 저장하는 곳을 줄이고, 저장하는 시간을 줄이고, 복사하는 곳을 줄입니다. 만약 특정 기능이 연령대만 필요하다면, 생년월일을 전부 저장하지 마세요. 만약 지원이 마지막 네 자리만 필요한 경우, 전체 필드를 노출하지 마세요. 만약 테스트 환경이 실제 개인 데이터가 필요하지 않다면, 생산 백업을 복원하지 마세요.
이것은 또한 운영 절차입니다. 보존 일정은 강제로 적용되어야 합니다. 오래된 내보내기에는 삭제가 필요합니다. 다운스트림 시스템은 검색 인덱스, 캐시, 데이터 레이크, 모바일 저장소 및 임의 CSV 파일에敏感 field가 복제될 때마다 위험이 증가하기 때문에 검토가 필요합니다. Capacitor 앱의 경우 @capgo/capacitor-data-storage-sqlite 그리고 @capgo/capacitor-fast-sql 암호화된 앱 사이드 퍼시스턴스를 제공할 수 있지만 여전히 지역 저장소에 저장하지 않아야 하는 항목이 무엇인지 결정해야 합니다.
이러한 기둥의 목적은 첫 번째 날에 완벽함이 아닌, 키 회전, 직원 변경, 사고 대응, 백업 복원 및 제품 성장 후에도 방어할 수 있는 저장 시스템을 구축하는 것입니다. 보안 데이터베이스 저장은 성공하거나 실패하는 곳입니다.
암호화 구현 방법
각 시스템에 암호화 방법이 하나씩은 없습니다. 올바른 선택은 무엇을 보호하고, 누구에게 쿼리할 수 있고, 팀이 지원할 수 있는 복잡성을 고려해야 합니다. 실수는 가장 강력한 sounding 방법을 선택하고 나서 그것을 나쁘게 구현하는 것입니다.
TDE는 가장 빠른 기본값입니다.
Transparent Data EncryptionTDE, 또는 투명 데이터 암호화는 일반적으로 가장 쉬운 곳에서 시작할 수 있습니다. 데이터베이스 엔진은 디스크에 파일을 암호화하고 엔진이 파일을 메모리에 읽을 때 암호화된 파일을 복호화합니다. 애플리케이션은 일반적으로 code 변경이 필요하지 않습니다.
This is a strong baseline for:
- 전체 데이터베이스 보호
- 저장소 수준의 준수 요구 사항
- 스냅샷, 디스크 또는 원시 파일 접근으로부터의 위험을 줄이는
TDE는 모든 것을 보호하지 않습니다. 유효한 데이터베이스 접근을 얻는 공격자가 있다면 엔진은 여전히 암호화된 데이터를 제공합니다. 따라서 TDE는 저장소 위반이 아닌 합법적인 자격증명을 남용하는 경우에만 도움이 됩니다.
응용 프로그램 수준의 암호화는 가장 중요한 필드를 보호합니다
응용 프로그램 수준의 암호화는 데이터베이스에 데이터가 도달하기 전에 발생합니다. code은 선택한 필드를 암호화하고, 암호화된 데이터를 저장소에 기록합니다. 특히-sensitive 열(예: 정부 ID, 은행 정보, 복구 비밀, 개인 노트 등)과 같은 경우에 잘 작동합니다.
추가 제어는 다음과 같은 비용이 따릅니다:
- 더욱 복잡한 소유 키 선택, 암호화 라이브러리, 회전 동작 및 오류 처리
- 쿼리하기가 더 어려워집니다: 정확한 일치, 부분 검색 및 색인화가 디자인 문제가 됩니다.
- 개발자는 discipline이 필요합니다: 이동 스크립트에서 단 하나의 단축키만으로 모델의 전부를 무력화 시킬 수 있습니다.
간단한 pseudocode 패턴은 다음과 같습니다:
| Step | Action |
|---|---|
| 1 | 요청에서 plaintext field를 읽어라 |
| 2 | 키 서비스에서 데이터 암호화 키를 요청하거나 wrapped local key를 사용하라 |
| 3 | field를 애플리케이션에서 암호화하라 |
| 4 | 데이터베이스에 ciphertext와 metadata를 저장하라 |
| 5 | approvd read paths에서만 ciphertext를 decrypt하라 |
로컬 앱 퍼시스턴스에 대해서도 같은 디자인 질문이 적용됩니다. 장치에 오프라인 토큰이나 sensitive sync 상태를 저장한다면, 모바일 저장소가 기본적으로 안전하다고 가정하지 마세요. 플랫폼에 대한 패턴을 사용하세요. 예를 들어 __CAPGO_KEEP_0__에서 discussed된 offline 토큰의 secure storage에 대해서는 secure storage for offline tokens in Capacitor.
__CAPGO_KEEP_0__
__CAPGO_KEEP_1__
__CAPGO_KEEP_2__
__CAPGO_KEEP_3__
- __CAPGO_KEEP_4__ __CAPGO_KEEP_5__
- __CAPGO_KEEP_6__ __CAPGO_KEEP_7__
- __CAPGO_KEEP_8__ __CAPGO_KEEP_9__
- __CAPGO_KEEP_10__ __CAPGO_KEEP_11__
- 권한이 있는 읽기 중에만 풀어라.
Field 조언: 장기된 마스터 키를 모든 애플리케이션 서버에 노출하지 않고 강력한 격리화를 필요로 할 때 envelope 암호화를 사용하라.
이 패턴은 성능과 제어를 균형을 맞추기 때문에 일반적이다. 애플리케이션은 실제 암호화 작업에 짧은 수명 데이터 키를 사용하며, KMS 또는 HSM은 wrap하고 unwrap하는 데 사용되는 마스터 키를 보호한다.
암호화 패턴 비교
| 패턴 | implementation 복잡도 | 성능 영향 | 최적 |
|---|---|---|---|
| 디스크 또는 볼륨 암호화 | 낮음 | 낮음 | __CAPGO_KEEP_0__ |
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_1__ | __CAPGO_KEEP_1__ | __CAPGO_KEEP_2__ |
| __CAPGO_KEEP_3__ | __CAPGO_KEEP_4__ | __CAPGO_KEEP_5__ | __CAPGO_KEEP_6__ |
| __CAPGO_KEEP_7__ | __CAPGO_KEEP_8__ | __CAPGO_KEEP_9__ | 강력한 키 분리 및 확장 가능한 키 관리가 필요한 시스템 |
실용적인 규칙은 간단합니다. TDE 또는 관리 중인 데이터 암호화와 같은 강력한 기초를 시작하고, 데이터敏감도와 위협 모델이 추가 엔지니어링을 정당화하는 경우만 field-level 또는 envelope 암호화를 추가합니다.
키 및 비밀 관리의 마스터
침해는 일반적인 비밀 처리 실수로 시작합니다. 프로덕션 데이터베이스가 암호화되어 있고 백업이 존재하고, 접근 권한이 종이로 제어되는 것처럼 보입니다. 그런 다음 CI 작업이 로그에 토큰을 출력하거나 엔지니어가 지원 스크립트를 위해 관리자 자격 증명을 재사용하거나 오래된 키가 팀이 생성한 후에 활성화된 지 오래된 팀이 이동한 후에도 활성화된 경우가 있습니다.
이는 키 및 비밀 관리가 운영 관행이며 설정 작업이 아닌 이유입니다.
잘못 관리된 키로 암호화된 데이터베이스는 서버 룸에 열쇠가 문에 걸려 있는 것과 같습니다. 정부 지침은 동일한 점을 강조합니다. 암호화만으로는 KMS 또는 HSM 기반 키 관리, 최소 권한 접근, 복구 계획을 생략하는 팀이 존재할 경우 격차를 닫을 수 없습니다. NSA와 파트너의 클라우드 데이터 보안 지침.
팀이 이것을 잘못하는 경우
사고 검토에서 익숙한 패턴입니다:
- 소스 코드 code: 직접 입력된 자격 증명, 임베디드 인증서 또는 점진적으로 프로덕션 의존성이 된 유틸리티 스크립트.
- 복사된 구성 파일에 있는 비밀 컴퓨터 사이에 파일이 전달되거나, 공유 폴더에 저장되거나, 급히 고쳐야 하는 경우에 커밋된다.
- 강한 제어가 없는 환경 변수: 편리하지만, 빌드 로그, 셸 히스토리, 충돌 보고서, 또는 광범위한 런타임 권한을 통해 노출된다.
- 권한 회전에 대한 소유권이 없다: 키가 몇 년 동안 존재하는 이유는 팀이 재발급, 배포, 롤백 계획을 소유하지 않기 때문이다.
- 공유된 고등 권한 비밀: 응용 프로그램, 엔지니어, 및 자동화가 사용하는 하나의 자격 증명이 있어, 감사 및 제한이 훨씬 더 어렵다.
애플리케이션 및 인프라 비밀을 저장하는 방법을 표준화하는 경우, 보안 환경 변수를 처리하는 데 도움이 되는 실용적인 참고 자료가 필요하다. 팀이 임의의 비밀 분산에서 벗어나기 위해 보안 환경 변수를 처리하는 방법 좋은 키 관리 방법
Use a
Use a __CAPGO_KEEP_0__ 중앙 집중식 정책, 접근 제어, 감사 로그, 및 예약된 회전이 사용자 정의 하드웨어 제어보다 더 중요할 때 사용하세요. __CAPGO_KEEP_0__ 위험, 준수 요구 사항, 또는 서명 및 키 보호 규칙이 전용 하드웨어 경계를 정당화할 때 사용하세요.
많은 팀이 HSM을 모든 곳에서 사용할 필요가 없습니다. 그들은 시스템이 암호 해독 작업을 요청할 수 있는 시스템, 정책을 변경할 수 있는 인간, 그리고 이러한 동작이 검토되는 방법에 대한 명확한 규칙이 필요합니다.
Envelope 암호화는 좋은 정신 모델입니다. 애플리케이션은 암호화 작업을 위해 짧은 수명 데이터 키를 처리합니다. 금고 키는 KMS 또는 HSM에 머물고, 접근이 엄격하게 제한됩니다.
- 실제 사고를 방지하는 제어가 운영됩니다. 안전하게 실행할 수 있는 일정에 따라 키를 회전하세요:
- 회전은 해킹된 키의 유용한 수명을 줄지만, 애플리케이션, 작업, 및 복원 작업이 이후에도 작동할 수 있는 경우에만. 책임을 분리하세요:
- 고객 데이터를 읽는 서비스가 키 정책을 변경하거나 로깅을 비활성화할 수 없도록 하세요. Sensitive 키 이벤트를 로깅하세요: 키 생성, 회전, 암호 해독 요청, 접근 실패, 및 정책 변경이 모두 표시되어야 합니다.
- 테스트 재 암호화 경로: 키를 회전하는 것보다 애플리케이션 데이터를 재 암호화하는 것이 일반적으로 더 어려울 수 있지만 두 가지 모두 롤백 단계와 롤백 단계가 필요합니다.
- 기존 비밀을 의도적으로 비활성화하고 폐기하십시오. 기존 자격 증명을 제거하기 전에 시간을 두고 기존 자격 증명을 제거하여 조용한 백도어가 될 수 있도록 하십시오.
CI/CD는 프로덕션 런타임과 같은 discipline을 deserves. 빌드 시스템은 넓은 접근 권한과 약한 가시성을 가지고 있기 때문에 비밀 누출의 일반적인 장소입니다. 이에 대해 진지하게 생각하는 팀들은 일반적으로 CI/CD pipeline의 비밀 관리를 formalize합니다. pipeline 자격 증명을 임시 예외로 다루지 말고.
한 가지 규칙은 간단합니다. 애플리케이션 code은 신뢰할 수 있는 시스템에서 암호화 연산을 요청해야 하며 환경 내에서 원본 마스터 키를 운반하지 않아야 합니다.
마스터 키를 잘못된 위치에 복사할 수 있는 개발자, pipeline, 또는 지원 도구가 있는 경우, 스택 내의 가장 강력한 암호화 설계는 의미가 없습니다.
강건한 백업 및 복구 전략 설계
백업은 안전한 데이터베이스 저장소의 일부입니다. 프로덕션을 보호하고 백업이 보호되지 않은 경우 공격자는 더 쉬운 경로를 선택할 것입니다.
Independent storage guidance는 백업 및 복구 시스템이 프로덕션과 같은 보호 수준을 유지해야 한다고 권장하며, 랜섬웨어 및 악성 소프트웨어 공격으로 인해 안전하고 테스트된 백업이 유일한 복구 경로로 남아 있는 경우가 많다고 합니다. Hypertec의 안전한 데이터 저장소 지침.
백업은 자신의 보안 경계가 필요합니다.
강건한 백업 설계는 몇 가지 특성을 가집니다:
- 백업은 전송 중 및 휴면 중 암호화됩니다.
- 백업 자격 증명은 생산 자격 증명과 분리됩니다.
- 삭제 및 보존 제어는 일반 앱 접근보다 더 어려운 방해를 받습니다.
- 복원 대상은 약한 제어가 있는 그림 생산 환경이 되지 않습니다.
일반적인 실패 모드는 암호화된 백업을 저장하는 것입니다. 그러나 동일한 손상된 생산 역할이 삭제할 수 있도록 허용합니다. 또 다른 것은 복원하는 데 사용되는 임시 환경에 광범위한 엔지니어 접근 권한이 있고 로깅이 없는 것입니다. 복구 경로가 주 경로와 같은 심도 있는 검토를 deserve합니다.
복원 테스트가 진짜 제어입니다.
테스트되지 않은 백업은 단순히 희망적인 저장소입니다.
복구가 잘되는 팀은 단순히 백업 작업이 완료되었는지 확인하는 것이 아니라 복원 작업이 작동하는지, 복원된 데이터가 사용할 수 있는지, 필요할 때 암호화 키, 연결 설정 및 종속 서비스가 모두 일치하는지 증명합니다.
실용적인 복원 프로그램에는:
- Routine restore drills __CAPGO_KEEP_0__
- Verification of application function 데이터베이스 복구 후에 파일 복원만 하는 것이 아닌 애플리케이션 기능을 검증하는 것입니다.
- Key availability 확인 암호화된 백업을 복호화할 수 있도록 암호화 키가 사용 가능한지 확인합니다.
- 복원된 시스템에 대한 접근 검토 사고 시敏감의 데이터가 널리 공개되지 않도록 하기 위해 복원된 시스템에 대한 접근을 검토합니다.
백업은 당신을 구하지 않습니다. 성공적인 복원은 당신을 구합니다.
백업 생성만 테스트하고 실제로 복원 테스트를 하지 않는다면, 당신은 백업이 생성되는지 확인한 것입니다. 그러나 실제로 복원 테스트를 하지 않으면, 당신은 복원 전략을 검증한 것이 아니라, 파일이 누군가의 저장소에 쌓이는지 확인한 것입니다.
Secure Database Storage에 대한 개발자 체크리스트
이 체크리스트는 디자인 리뷰, 릴리스 리뷰, 사후 사고 정리 시 팀이 사용해야 하는 체크리스트입니다.
설계
- 민감한 field를 명확하게 식별했습니까?: 개인 정보, 인증 자료, 금융 기록 및 보존 규칙에 따라 주어지는 모든 것.
- 저장하지 않을 것인지 결정했습니까?: 필요하지 않은 field 및 다운스트림 팀이 피할 수 있는 복사본.
- 데이터가 어디서 살아갈지 매핑했습니까?: 생산, 스테이징, 로그, 수출, 분석 시스템, 백업 및 클라이언트 장치.
구현
- 데이터가 저장 중 및 전송 중 암호화되었습니까?: 데이터베이스, 복제본 및 백업 경로.
- 응용 프로그램 및 서비스 역할이 단단히 범위가 지정되었습니까?: No normal 앱 트래픽에 공유 슈퍼 사용자가 없습니다.
- 비밀 키가 code 외부에서 처리되고 느슨한 구성에서 처리되는지 여부를 묻습니다. 통제된 접근 및 감사성을 통해.
- 보안 접근 및 특권 변경을 로깅하는지 여부를 묻습니다. 수사관이 쿼리할 수 있는 중앙 장소에서.
운영
- 키 회전 및 비밀 검토가 정상적인 운영에 포함되는지 여부를 묻습니다. 연간 대소동이 아닙니다.
- 정기적으로 복원 테스트를 수행하는지 여부를 묻습니다. 복구된 시스템에서 암호화, 애플리케이션 시작, 및 접근 검토를 포함하여.
- 데이터 스푸로가 지속적으로 감사하는지 여부를 묻습니다. 개발 데이터 세트, 지원 수출, 개발 데이터 세트, 그리고 잊어버린 백업 위치.
안전한 데이터베이스 저장소는 프로젝트 단계가 아닌 반복적인 실천입니다.
자주 묻는 질문
클라우드 제공업체 기본 암호화가 충분한가요
기본 암호화는 저장 매체와 관리 서비스를 보호하는 강력한 기초입니다. 그러나 권한이 과도한 액세스, 복사된 데이터 세트, 약한 백업 제어, 또는 나쁜 키 관리를 해결하지 않습니다.
암호화가 데이터베이스 성능에 영향을 미치나요
때때로 그렇습니다. 영향의 패턴에 따라 달라집니다. 인프라 및 데이터베이스 수준 암호화는 일반적으로 애플리케이션 복잡성을 줄입니다. field-level 암호화는 선택된 데이터에 대한 강력한 제어를 제공하지만 인덱싱, 필터링 및 검색을 복잡하게 만들 수 있습니다. 워크로드에 대한 측정은 광범위한 롤아웃 전에 수행해야 합니다.
이것은 SQL 및 NoSQL 시스템과 다르가요
원칙은 동일합니다. 암호화, 최소 권한, 감사, 키 관리, 테스트된 복구가 필요합니다. 구현 세부 사항은 문서 저장소, 키-값 저장소 및 관계형 시스템이 다른 액세스 모델과 쿼리 동작을 노출하기 때문입니다.
토큰화는 암호화와 어떻게 다르나요
암호화는 권한이 있는 시스템이 올바른 키로 복호화할 수 있도록 데이터를 변환합니다. 토큰화는敏感한 값을 대체 값으로 대체하고 원본 데이터를 분리합니다. 토큰화는 앱 워크플로우에서 노출을 줄일 수 있지만 시스템 설계 복잡성을 추가하고 강력한 저장 제어가 필요하지 않습니다.
Capgo은 Capacitor 및 Electron 앱에 대한 고속 배포를 지원하는 signed 웹 번들 배포, 롤아웃 제어, 롤백 보호 및 릴리스 관찰성을 제공하는 팀을 지원합니다. 저장소, 인증 또는 API 오류로 인한 사고 후 클라이언트 측 수정을 빠르게 배포해야 하는 경우 Capgo 운영적 회복의 일부로 평가하는 것이 __CAPGO_KEEP_0__입니다.
