문서 홈 → 애플리케이션 개발 → MongoDB 매뉴얼
저장된 데이터 암호화
이 페이지의 내용
미사용 암호화는 전송 암호화 및 관련 계정, 비밀번호, 암호화 키를 보호하는 우수한 보안 정책과 함께 사용하면 HIPAA, PCI-DSS, FERPA를 비롯한 보안 및 개인정보 보호 표준을 준수하는 데 도움이 될 수 있습니다.
암호화된 스토리지 엔진
버전 3.2에 새로 추가되었습니다.
참고
엔터프라이즈 기능
MongoDB Enterprise에서만 사용할 수 있습니다.
중요
WiredTiger 스토리지 엔진에서만 사용할 수 있습니다.
MongoDB Enterprise 3.2에는
WiredTiger 스토리지 엔진에 대한 네이티브 암호화 옵션이 도입되었습니다. 이 기능을 사용하면 MongoDB가 데이터 파일을 암호화하여
암호 해독 키를 가진 당사자만 데이터를 해독하고 읽을 수
있습니다.
암호화 프로세스
참고
버전 4.0에서 변경됨
Windows용 MongoDB Enterprise에서는 더 이상 미사용 데이터 암호화를 위한 블록 암호로 AES256-GCM을 지원하지 않습니다. 이 사용 방식은 Linux에서만 지원됩니다.
MongoDB Enterprise에서 암호화 기능을 활성화하면 기본적으로 OpenSSL을 통한 AES256-CBC (256비트 고급 암호화 표준, Cipher Block Chaining 모드) 암호화 모드를 사용합니다. AES-256은 대칭 키 방식을 사용하여, 암호화와 해독에 동일한 키를 사용합니다. Linux용 MongoDB Enterprise는 인증된 암호화 AES256-GCM (또는 갈루아/카운터 모드에서 256비트 고급 암호화 표준)도 지원합니다.
암호화된 스토리지 엔진은 기본 운영 체제의 인증된 암호화 제공자를 사용하여 암호화 작업을 수행합니다. 예를 들어, Linux 운영 체제에 MongoDB를 설치할 때는 OpenSSL libcrypto FIPS-140 모듈을 사용합니다.
FIPS 호환 모드에서 MongoDB를 실행하려면 다음 안내를 따르세요.
운영 체제가 FIPS 시행 모드에서 실행되도록 구성합니다.
net.tls.FIPSMode설정을 활성화하도록 MongoDB를 구성합니다.mongod또는mongos을 다시 시작합니다.서버 로그 파일을 확인하여 FIPS 모드가 활성화되어 있는지 확인합니다. FIPS 모드가 활성화된 경우 로그 파일에
FIPS 140-2 mode activated메시지가 나타납니다.
자세한 내용은 FIPS용 MongoDB 구성을 참조하세요.
참고
AES256-GCM 및 파일 시스템 백업
AES256-GCM 암호화 모드를 사용하는 암호화 스토리지 엔진 의 경우 AES256-GCM 에서는 모든 프로세스가 키와 함께 고유한 카운터 블록 값을 사용해야 합니다.
AES256-GCM 암호로 구성된 암호화된 스토리지 엔진 의 경우:
- 핫 백업에서 복원
- 4.2부터 "hot" 백업을 통해 가져온 파일에서 복원하는 경우(즉,
mongod가 실행 중일 때), MongoDB는 시작 시 "더티" 키를 감지하고 데이터베이스 키를 자동으로 롤오버하여 IV(초기화 벡터) 재사용을 방지할 수 있습니다.
- 콜드 백업에서 복원
그러나 "cold" 백업을 통해 가져온 파일에서 복원하는 경우(즉,
mongod가 실행 중이 아닌 경우), MongoDB는 시작 시 "더티" 키를 감지할 수 없으며, IV를 재사용하면 기밀성 및 무결성 보증이 무효화됩니다.4.2부터 콜드 파일 시스템 스냅샷에서 복원한 후 키 재사용을 방지하기 위해 MongoDB는 새로운 명령줄 옵션
--eseDatabaseKeyRollover를 추가합니다.--eseDatabaseKeyRollover옵션으로 시작하면mongod인스턴스는AES256-GCM암호로 구성된 데이터베이스 키를 롤오버하고 종료합니다.
팁
일반적으로 MongoDB Enterprise 4.2+에 파일 시스템 기반 백업을 사용하는 경우 가능하면 "핫" 백업 기능을 사용합니다.
MongoDB Enterprise 버전 4.0 이하에서
AES256-GCM암호화 모드를 사용하는 경우, 데이터 파일의 복사본을 만들거나 파일 시스템 스냅샷("hot" 또는 "cold")에서 복원하지 말고 하지 마세요.
데이터 암호화 프로세스에는 다음이 포함됩니다.
마스터 키를 생성합니다.
각 데이터베이스에 대한 키를 생성합니다.
데이터베이스 키로 데이터를 암호화합니다.
마스터 키로 데이터베이스 키를 암호화합니다.
이 암호화는 스토리지 계층에서 투명하게 일어나며, 모든 데이터 파일은 파일 시스템 관점에서 완전히 암호화됩니다. 데이터는 메모리와 전송 중에만 암호화되지 않은 상태로 존재합니다.
MongoDB의 모든 네트워크 트래픽을 암호화하려면 TLS/SSL (전송 계층 보안/보안 소켓 계층)을 사용할 수 있습니다. See TSS/SSL을 위해 mongod 및 mongos 구성, 클라이언트를 위한 TLS/SSL 구성을 참조하세요.
키 관리
중요
암호화 키의 안전한 관리는 매우 중요합니다.
데이터베이스 키는 서버 내부에 존재하며, 암호화된 형태로만 디스크에 저장됩니다. MongoDB는 어떤 상황에서도 마스터 키를 디스크에 저장하지 않습니다.
마스터 키만 서버 외부(예: 데이터 및 데이터베이스 키와 별도로 보관)에 있으며 외부 관리가 필요합니다. MongoDB의 암호화된 스토리지 엔진은 마스터 키를 관리하기 위해 두 가지 키 관리 옵션을 지원합니다.
Key Management Interoperability Protocol(KMIP)를 통해 타사 키 관리 어플라이언스와 통합합니다. 권장
참고
KMIP를 사용하는 타사 키 관리 어플라이언스와 통합하려면 다음 KMIP 작업을 허용해야 합니다.
생성(
operation_create)(
operation_get) 가져오기(
operation_activate)활성화
키 파일을 통한 로컬 키 관리.
암호화를 위해 MongoDB를 구성하고 두 가지 키 관리 옵션 중 하나를 사용하려면 암호화 구성을 참조하세요.
암호화 및 복제
암호화는 복제의 일부가 아닙니다:
마스터 키와 데이터베이스 키는 복제되지 않습니다.
데이터는 기본적으로 유선을 통해 암호화되지 않습니다.
노드에 동일한 키를 재사용할 수 있지만 MongoDB에서는 각 노드에 대해 개별 키를 사용하고 전송 암호화를 사용할 것을 권장합니다.
자세한 내용은 암호화 키 회전을 참조하세요.
로깅
버전 3.4의 새로운 기능: MongoDB Enterprise에서만 사용 가능
로그 파일은 MongoDB의 암호화된 스토리지 엔진의 일부로 암호화되지 않습니다. 로깅 과 함께 실행되는 mongod 는 구성된 로그 상세도에 따라 일반 작업의 일부로 잠재적으로 민감한 정보를 로그 파일에 출력할 수 있습니다.
MongoDB 3.4 Enterprise는 잠재적으로 security.redactClientLogData 민감한 정보가 프로세스 로그에 mongod 들어가지 않도록 설정을 제공합니다. redactClientLogData 은(는) 로그의 세부 정보를 줄이고 로그 진단을 복잡하게 만들 수 있습니다.
자세한 내용은 로그 편집 매뉴얼 항목에서 확인할 수 있습니다.
애플리케이션 수준 암호화
또한, 애플리케이션 수준 암호화(Application Level Encryption)는 애플리케이션 계층에서 필드별 또는 문서별로 데이터를 암호화하는 기능을 제공합니다.
버전 4.2의 새로운 기능: MongoDB 4.2 시리즈 드라이버는 클라이언트 사이드 필드 수준 암호화 프레임워크를 제공합니다. 자세한 내용은 클라이언트 사이드 필드 수준 암호화를 참조하세요.
전체 문서를 암호화하려면 사용자 지정 암호화 및 암호 해독 루틴을 작성하거나 상용 솔루션을 사용하세요.
MongoDB의 인증 파트너 목록은 파트너 목록 을 참조하세요.