MongoDB 보안
보안
몽고 DB에서 지원하는 보안은 아래와 같다.
인증
기본적인 방식으로 아래에 기반한다
내가 아는 것을 기반으로 - 패스워드
내게 주어진 것을 기반으로 - 자격
내가 누구인지를 기반으로 - 생체 인식 또는 IP 주소
위의 3가지를 기반으로 제공하는 방식은 아래와 같다.
SCRAM-SHA
MongoDB는 사용자 ID와 솔트 처리된 암호 해시를 저장한다. 클라이언트에서 해당 MongoDB로 인증 요청을 보낼때 비밀번호를 직접 보내지 않고 ID와 솔트 처리된 암호해시를 보내어 서버에서 대조한다. 이러한 해싱처리는 CPU 리소스를 매우 많이 쓰는데 클라이언트에서 해시 라운드 1회, 서버에서 2회 라운드 진행된다. 해시 라운드는 1만 또는 1만 5천 번의 해싱을 의미하며, 로그인은 고의적으로 느리고 CPU 집약적으로 설계되어 브루트 포스 공격을 피하게 되어있기 때문에 기본적으로 굉장히 비용이 높은 방식이고 느린편이다. 로그인 후에는 연결간 인증이 유지된 상태이기 때문에 어지간하면 연결은 유지하며 그 연결을 사용하는게 좀 더 성능 유지하는데 유리하다.
X.509
연결 요청시 MongoDB는 사용자 DB를 확인하여 해당 인증서를 인식하고 신뢰하는지 확인한다. 이러한 인증서는 개인키가 포함되어있지만 서버로 전송되지는 않으며, 클라이언트가 로그인을 요청하고 공개키를 전달하면 서버가 개인 키로 확인할 내용을 제공한다. 이러한 개인키에는 클라이언트에서 입력해야할 비밀번호가 있을 수도 있으며 인증서 자체를 클라이언트 사이드 저장소에 저장해야할 수도 있다.
LDAP
Active Directory/LDAP로 인증을 외부화하는 방식으로 AD 서버에서 사용자 이름과 비밀번호를 확인하는 방식이다. 비밀번호 복잡성/만료를 강제할 수 있으며 로그인을 활성화하기 위해 AD의 가용성에 의존한다. 사용자를 확인할 때 평문 자격 증명을 사용하는데, LDAP를 TLS와 함께 항상 구성하여 전송 중 자격 증명을 보호한다. (네트워크 암호화)
Kerberos
높은 평가를 받고 검증된 시스템으로 X.509와 유사하다. 하지만 새로운 티켓(인증서)이 빈번하게 요청되는데 이러한 인증을 통해 사용자가 MongoDB에 로그인하기 위해 티켓을 얻기 위해 Kerberos 서버에 로그인해야한다. 사용하려면 Kerberos 인프라가 설정되어 있어야 한다.
MONGODB-AWS (Atlas Only)
AWS의 IAM으로 인증
각 인증 사용 사례
인간 사용자
- 항상 개별 로그인을 이용해야한다.
- 중앙 집중식 ID 관리 (LDAP/Kerberos)가 관리가 용이하다.
- SCRAM-SHA는 안전하지만 중앙 집중식이 아니며 더 많은 유지 관리가 필요하다
- X.509는 인증서와 비밀번호가 필요하며 로컬 또는 LDAP 권한 부여가 필요하다.
소프트웨어/서비스 사용자
- 인간이 서비스에 사용하는 자격 증명을 알지 못해야 한다.
- 윈도우 서비스의 경우 Kerberos가 좋은 옵션이다.
- AWS의 Atlas에서는 IAM을 사용할 수 있다.
- 설치 시 무작위 비밀번호 (및 관련 사용자)를 생성할 수 있다.
- 엔드포인트에 비밀번호를 안전하게 저장하는 솔루션을 사용할 수 있다. (예: 기업용 비밀번호 관리 시스템).
권한 종류
크게는 빌트인 role과 커스텀 role이 있다.
built in role
1. Database User Roles
- read : 모든 비 시스템 컬렉션 및 컬렉션 의 데이터를 읽는 기능을 제공한다.
- readWrite : read role에 더해 데이터 변경 권한까지 추가로 기능을 제공한다.
2. Database Administration Roles
- dbAdmin : 스키마 관련 작업, 인덱싱, 통계 수집 등의 관리 작업을 수행하는 기능을 제공한다. 이 역할은 사용자 및 역할 관리에 대한 권한을 부여하지 않는다.
- dbOwner : 데이터베이스 소유자는 데이터베이스에 대한 모든 관리 작업을 수행할 수 있다. readWrite, dbAdmin, userAdmin 역할을 합친 것과 같은 기능을 제공한다.
- userAdmin : 현재 데이터베이스에서 역할과 사용자를 생성하고 수정하는 기능을 제공한다. 이후 userAdmin 역할을 통해 사용자는 자신을 포함한 모든 사용자에게 모든 권한을 부여할 수 있으며 간접적으로도 권한을 제공한다. 수퍼유저 데이터베이스가 범위가 지정된 경우 admin 클러스터에 대한 엑세스도 기능에 포함된다.
3. Cluster Administration Roles
clusterAdmin : 클러스터 관리에 대한 최대 액세스를 제공한다. 이 역할은 clusterManager, clusterMonitor 및 hostManager 역할에서 부여된 권한을 결합한다. 또한, 이 역할은 dropDatabase 작업을 제공한다.
clusterManager : 클러스터에서의 관리 및 모니터링 작업을 제공한다. 이 역할을 가진 사용자는 각각 샤딩 및 복제에 사용되는 config 및 local 데이터베이스에 액세스할 수 있다.
clusterMonitor : 모니터링 도구인 MongoDB Cloud Manager 및 Ops Manager 모니터링 에이전트와 같은 것들에 대한 읽기 전용 액세스를 제공한다.
hostManager : 서버를 모니터링하고 관리할 수 있는 능력을 제공합니다.
4. Backup and Restoration Roles
- backup : 데이터를 백업하는 데 필요한 최소한의 권한을 제공한다. 이 역할은 MongoDB Cloud Manager 백업 에이전트, Ops Manager 백업 에이전트를 사용하거나 mongodump를 사용하여 전체 mongod 인스턴스를 백업하는 데 충분한 권한을 제공한다.
- restore : 시스템 콜렉션을 제외한 컬렉션에 대해 convertToCapped를 제공한다. 시스템 프로필 컬렉션 데이터를 포함하지 않은 경우 및 –oplogReplay 옵션 없이 mongorestore를 실행하여 백업에서 데이터를 복원하는 데 필요한 권한을 제공한다.
5. All-Database Roles
- readAnyDatabase : local 및 config를 제외한 모든 데이터베이스에 대한 읽기 권한과 동일한 읽기 전용 권한을 제공한다. 또한, 이 역할은 클러스터 전체에서 listDatabases 작업을 제공한다.
- readWriteAnyDatabase : local 및 config를 제외한 모든 데이터베이스에 대해 readWrite와 동일한 권한을 제공한다.
- userAdminAnyDatabase : local 및 config를 제외한 모든 데이터베이스에 대해 userAdmin과 동일한 사용자 관리 작업에 대한 액세스를 제공한다.
- dbAdminAnyDatabase : local 및 config를 제외한 모든 데이터베이스에 대해 dbAdmin과 동일한 권한을 제공한다. 또한, 이 역할은 클러스터 전체에서 listDatabases 작업을 제공한다.
7. Superuser Roles
- root : 다음 역할들의 작업 및 모든 리소스에 대한 액세스를 결합한 것을 제공한다. readWriteAnyDatabase, dbAdminAnyDatabase, userAdminAnyDatabase, clusterAdmin, restore, backup 또한 system. 콜렉션에 대한 validate 권한 작업도 제공한다.
custom role
별도의 롤을 설정해서 권한을 부여하는 것으로 세부 권한을 어떻게 부여하느냐에 따라 달라진다.
전송간 암호화
MongoDB은 TLS를 지원한다. TLS는 경우에 따라서 필수로 사용해야할 수도 있고 선택적으로 사용해야할 수도 있다.
- requireTLS: 클라이언트는 TLS를 사용해야 함
- preferTLS: 클라이언트는 TLS를 사용할 수 있으며, 복제 시에는 가능한 경우 TLS를 사용합니다.
- allowTLS: 클라이언트는 TLS를 사용할 수 있음
- disabled: 서버는 TLS를 지원하지 않음
MongoDB 서버는 선택적으로 클라이언트 인증서를 요구할 수 있다.
- 선택적으로 X.509 인증을 제공할 수 있음
- X.509 인증을 사용하지 않을 때 인증서를 요구하는 것은 많은 경우 과도할 수 있다.
- 가능한 경우 항상 네트워크 암호화를 사용하는 것을 권장한다. (Atlas의 기본 설정이며 비활성화할 수 없음)
안전한 보관 암호화
MongoDB가 파일을 안전하게 암호화하여 보관하는 방법에 대한 부분으로 복호화 키를 안전하게 보관하고 관리할 수 있는 방법이 필요하다.
로컬에 이러한 복호화키를 보관하는 것은 안전하다고 판단되지 않으며 외부 키 관리서비스를 쓰는것을 권장한다. 이러한 서비스 사용시 일정 주기로 키를 순환하여 변환한다,
필드 레벨 암호화
개발자가 신경써서 처리해야하는 부분이며 개별 필드는 클라이언트 단에서 암호화/복호화된다. 응용 프로그램에 통합되어 제공되야하며 키의 보관에 보안이 달려있기 때문에 여전히 키는 안전하게 보관 되어야한다.
감사
범죄자를 잡는 것이 아니라 직원을 보호하기 위한 도구이며 디버깅 도구가 아니다. 응용 프로그램의 DB 작업을 감사하는 것으로 사용자가 무엇을 했는지 감사하는 것이 아니라 서비스 요청을 처리하기 위해 응용 프로그램이 수행한 작업을 감사하는 것이다.
모든 성공한 또는 막힌 작업을 기록할 수 있으며 보안이 기본적으로 CRUD 이외의 활동을 방지하는 경우에만 감사한다. MongoDB 쿼리처럼 사용자/시간/작업 등으로 감사 쓰기를 필터링할 수 있다. 감사 파일은 JSON 또는 BSON일 수 있으며 로컬 디스크에 저장된다.