Lv.2 초급MongoDB

2026.05.2525분 읽기Lv.2 초급

시리즈MongoDB Atlas 완전 정복 · 파트 3시리즈 허브 보기

MongoDB Atlas 완전 정복 Part 3 — 보안, 네트워크, 접근 제어 완전 해부

Atlas 보안은 MongoDB와 고객의 공동 책임이다. IP Access List·VPC Peering·Private Endpoint 3계층 네트워크 보안, SCRAM·X.509·AWS IAM 인증, 앱별 최소 권한 RBAC, CMK Envelope Encryption·Queryable Encryption, Audit Log Push-based Export, GDPR·PCI DSS·HIPAA 컴플라이언스까지 운영 관점에서 정리한다.

시리즈 구성

• Part 1 | Atlas 개념·구조·왜 쓰는가
• Part 2 | 클러스터 설계 전략
• Part 3 ← 지금 여기 | 보안, 네트워크, 접근 제어 완전 해부
• Part 4 | 성능 최적화 — 인덱싱, 쿼리 튜닝, Auto-scaling
• Part 5 | AI 시대의 Atlas — Vector Search, Stream Processing, RAG 파이프라인

목차

1. Atlas 보안 모델의 큰 그림 — 공동 책임 모델
2. 네트워크 보안 3계층 — IP Access List, VPC Peering, Private Endpoint
3. 인증(Authentication) — 누가 접속하는가
4. 인가(Authorization) — 무엇을 할 수 있는가 (RBAC)
5. 암호화 3단계 — At Rest, In Transit, In Use
6. 감사 로그(Audit Log) — 누가 무엇을 했는가
7. 컴플라이언스 대응 — GDPR, PCI DSS, HIPAA
8. 실수하기 쉬운 보안 함정 TOP 5
9. 보안 설정 최종 체크리스트

1. Atlas 보안 모델의 큰 그림 — 공동 책임 모델

MongoDB Atlas의 보안은 **공동 책임 모델(Shared Responsibility Model)**을 기반으로 한다. MongoDB가 다 해준다고 믿었다가 사고가 나는 경우가 적지 않다. 먼저 책임 경계를 명확히 하자.

Atlas가 아무리 훌륭해도, IP Access List에 0.0.0.0/0(전체 허용)을 등록하거나, 관리자 권한의 DB 사용자를 앱에 그대로 쓰는 순간 보안은 무너진다. 이 파트에서는 고객 책임 영역을 빠짐없이 다룬다.

2. 네트워크 보안 3계층

Atlas의 네트워크 접근 제어는 3가지 방법을 중첩해 사용할 수 있으며, 보안 수준에 따라 조합을 달리한다.

보안 수준이 높아질수록 구성 복잡도도 올라간다. 운영 환경의 보안 요구 수준과 팀 역량을 함께 고려해 선택한다.

2-1. IP Access List — 가장 기본, 하지만 함정이 많다

Atlas의 모든 클러스터는 IP Access List 없이는 연결이 불가능하다. 설정 자체는 쉽지만 운영 중 함정이 많다.

# 특정 IP 허용
atlas accessLists create \
  --type ipAddress \
  --entry "203.0.113.42" \
  --comment "Prod App Server - Seoul DC"

# CIDR 블록 허용 (사무실 네트워크 대역)
atlas accessLists create \
  --type cidrBlock \
  --entry "10.0.1.0/24" \
  --comment "Internal Office Network"

# 현재 접속 IP 빠른 등록 (개발 환경용)
atlas accessLists create --currentIp

절대 하면 안 되는 것:

# 전 세계 모든 IP 허용 — 실수로 등록하는 경우가 많음
atlas accessLists create --entry "0.0.0.0/0"

실무 경고: 0.0.0.0/0 등록은 Atlas UI가 경고를 띄워도 "임시로"라며 그냥 넘기는 경우가 많다. 이 설정이 프로덕션에서 발견되는 사례는 생각보다 훨씬 잦다. 2025년 Atlas Resource Policies를 활용하면 조직 차원에서 와일드카드 IP 등록 자체를 금지할 수 있다.

Resource Policy로 0.0.0.0/0 등록을 조직 전체에서 금지하는 예시:

// Atlas Admin API — 0.0.0.0/0 등록 금지 Policy
{
  "policies": [{
    "body": "forbid(principal, action == atlas:CreateNetworkAccessEntry,
             resource) when { resource.ipAddress == \"0.0.0.0/0\" };"
  }]
}

2-2. VPC Peering — 사설 네트워크 연결

VPC Peering은 앱 서버의 VPC와 Atlas의 VPC를 사설 네트워크로 직접 연결한다. 공인 인터넷을 거치지 않으므로 IP Access List 방식보다 훨씬 안전하다.

VPC Peering의 제약사항 (반드시 숙지):

• CIDR 겹침 불가: 고객 VPC와 Atlas VPC의 CIDR이 겹치면 연결 불가. 처음 Atlas 프로젝트 생성 시 CIDR을 신중히 설정해야 한다.
• 같은 클라우드만: AWS ↔ AWS, GCP ↔ GCP, Azure ↔ Azure만 가능. 크로스 클라우드 Peering 불가.
• M10 이상 Dedicated만 지원 (M0, Flex 불가)

# AWS VPC Peering 설정 (Atlas CLI)
atlas networking peering create aws \
  --accountId 123456789012 \
  --vpcId vpc-0abc123def456 \
  --routeTableCidrBlock "10.0.0.0/16" \
  --region ap-northeast-2

2-3. Private Endpoint — 최고 보안, 프로덕션 표준

Private Endpoint(AWS PrivateLink / Azure Private Endpoint / GCP Private Service Connect)는 현재 MongoDB Atlas 공식 권장 네트워크 보안 방식이다.

VPC Peering과 결정적으로 다른 점은 단방향(One-way) 연결이라는 것이다. 고객 VPC에서 Atlas로 연결은 되지만, Atlas에서 고객 VPC로의 역방향 연결은 원천 차단된다. 이것이 신뢰 경계(Trust Boundary)를 유지하는 핵심이다.

역방향 연결(Atlas → 고객 VPC)은 원천 차단되며, 트래픽은 AWS/Azure/GCP 백본 내부에서만 이동해 인터넷을 경유하지 않는다.

AWS PrivateLink 설정 단계:

# Step 1: Atlas에서 Private Endpoint Service 생성
atlas privateEndpoints aws create \
  --region ap-northeast-2

# 출력된 endpointServiceName 복사 후...

# Step 2: AWS CLI로 VPC Interface Endpoint 생성
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123def456 \
  --subnet-ids subnet-0aaa111 subnet-0bbb222 \
  --service-name com.amazonaws.vpce.ap-northeast-2.vpce-svc-xxxxx \
  --vpc-endpoint-type Interface

# Step 3: Atlas에 Endpoint ID 등록
atlas privateEndpoints aws interfaces create \
  --endpointServiceId <SERVICE_ID> \
  --privateEndpointId vpce-0xxxxxxxxxxxxxxx

멀티 리전 클러스터 사용 시 주의사항: 노드가 있는 각 리전마다 Private Endpoint를 별도로 생성해야 한다. 서울 리전 + 싱가포르 리전에 노드가 있다면, 두 리전 각각에 Endpoint를 만들어야 한다.

VPC Peering vs Private Endpoint 최종 비교:

3. 인증(Authentication) — 누가 접속하는가

네트워크 보안으로 접속 경로를 제한했다면, 다음은 누가 접속하는지 검증하는 인증 단계다.

3-1. 데이터베이스 사용자 (SCRAM 인증)

가장 기본적인 인증 방식. 아이디 + 비밀번호 기반의 SCRAM(Salted Challenge Response Authentication Mechanism)을 사용한다.

// 올바른 연결 문자열 예시 (환경변수로 크리덴셜 분리)
const uri = `mongodb+srv://${process.env.DB_USER}:${process.env.DB_PASS}@cluster0.xxxxx.mongodb.net/`;

DB 사용자 생성 베스트 프랙티스:

# 나쁜 예: 하나의 관리자 계정을 모든 앱이 공유
atlas dbusers create \
  --username admin \
  --role atlasAdmin    # 전체 관리자 권한 (앱에 절대 사용 금지)

# 좋은 예: 앱별 전용 사용자 + 최소 권한
atlas dbusers create \
  --username app-user-read \
  --role "readAnyDatabase"

atlas dbusers create \
  --username app-user-write \
  --role "readWriteAnyDatabase"

atlas dbusers create \
  --username app-user-specific \
  --scope "myDatabase"    # 특정 DB만 접근

3-2. X.509 인증서 인증 (M10+)

비밀번호 대신 클라이언트 인증서로 인증하는 방식. 비밀번호 유출 리스크가 없어 금융, 의료 등 고보안 환경에서 선호된다.

# X.509 인증서 기반 DB 사용자 생성
atlas dbusers create \
  --username "CN=myApp,OU=Engineering,O=MyCompany" \
  --x509Type MANAGED

3-3. AWS IAM 인증 (AWS 환경 권장)

AWS EC2, Lambda, EKS 등 AWS 환경에서는 IAM Role 기반 인증이 가능하다. 비밀번호를 코드에 넣을 필요가 전혀 없어 보안성이 크게 향상된다.

# AWS IAM 인증 예시 (Python)
import boto3
from pymongo import MongoClient

def get_aws_token():
    # STS에서 호출자 신원 확인 (IAM Role 기반)
    sts = boto3.client('sts')
    token = sts.get_caller_identity()
    return token

client = MongoClient(
    "mongodb+srv://cluster0.xxxxx.mongodb.net/",
    authMechanism="MONGODB-AWS"
    # 환경변수 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY 자동 인식
)

3-4. Atlas UI 접근 — MFA와 SSO

Atlas 콘솔 자체의 보안도 중요하다. 특히 조직의 Atlas 관리자 계정이 탈취되면 클러스터 전체가 위험하다.

• MFA(Multi-Factor Authentication): 모든 Atlas UI 계정에 MFA 강제 설정 권장
• Federated Authentication(SSO): Okta, Azure AD, Google Workspace 등 기업 IdP와 연동 가능. 직원 퇴사 시 IdP에서 계정 비활성화하면 Atlas 접근도 자동 차단

// Organization 차원에서 MFA 강제 적용 (Atlas Admin API)
PATCH /orgs/{orgId}/settings
{
  "requireMFAForAccount": true
}

4. 인가(Authorization) — 무엇을 할 수 있는가 (RBAC)

인증이 "누구냐"를 확인한다면, 인가는 "무엇을 할 수 있냐"를 결정한다. Atlas는 두 단계의 RBAC를 제공한다.

4-1. Atlas 플랫폼 RBAC (UI/API 접근 제어)

Atlas 콘솔과 API에 대한 접근 권한을 Organization/Project 레벨로 세분화한다.

Organization 레벨 역할
  Organization Owner          전체 관리 (청구, 멤버, 프로젝트 생성)
  Organization Member         프로젝트 참여 가능, 조직 설정 변경 불가
  Organization Billing Admin  청구 관리만 가능

Project 레벨 역할 (2025년 신규 추가 포함)
  Project Owner                    클러스터 생성/삭제, 보안 설정 전체
  Project Data Access Admin        데이터 읽기/쓰기, 클러스터 삭제 불가
  Project Database Access Admin    (2025 신규) DB 사용자 관리만
  Project Backup Manager           (2025 신규) 백업 관리만
  Project Observability Viewer     (2025 신규) 모니터링 조회만
  Project Read Only                프로젝트 설정 읽기만
  Project Cluster Manager          클러스터 구성 변경 (보안 설정 제외)

2025년 업데이트로 Project Database Access Admin, Project Backup Manager, Project Observability Viewer 역할이 새로 추가되어 더 세밀한 권한 분리가 가능해졌다. DBA에게는 DB 접근만, 백업 팀에는 백업만, 모니터링 팀에는 조회만 권한을 줄 수 있다.

4-2. 데이터베이스 RBAC (데이터 접근 제어)

Atlas가 제공하는 내장 역할과, 직접 만드는 커스텀 역할을 조합해 사용한다.

내장 역할 목록:

커스텀 역할 예시 — 특정 컬렉션만 읽기 허용:

// Atlas Admin API로 커스텀 역할 생성
POST /groups/{groupId}/customDBRoles/roles
{
  "roleName": "readOnlyOrders",
  "actions": [
    {
      "action": "FIND",
      "resources": [
        {
          "db": "ecommerce",
          "collection": "orders"
        }
      ]
    }
  ]
}

실전 권장 패턴 — 앱별 최소 권한:

앱 서버 A (주문 처리)
  DB User: app-orders-rw
  권한: ecommerce.orders (readWrite), ecommerce.products (read)

앱 서버 B (리포팅)
  DB User: app-report-ro
  권한: ecommerce.* (read only)

배치 서버 (정산)
  DB User: batch-settlement
  권한: finance.settlements (readWrite), ecommerce.orders (read)

5. 암호화 3단계 — At Rest, In Transit, In Use

Atlas의 암호화는 At Rest(저장), In Transit(전송), In Use(처리 중) 세 단계로 나뉜다. 각 단계가 무엇을 보호하는지 이해해야 제대로 적용할 수 있다.

5-1. At Rest — 저장 데이터 암호화

기본 암호화 (자동, 무료): Atlas는 모든 클러스터의 스토리지를 기본적으로 클라우드 프로바이더의 AES-256 키로 암호화한다. 별도 설정 없이 자동 적용된다.

CMK (Customer-Managed Keys) — 고객 관리 암호화 키: 기본 암호화로 부족한 엔터프라이즈 환경을 위해, 고객이 직접 KMS 키를 관리하는 방식이다. AWS KMS, Azure Key Vault, GCP Cloud KMS와 연동된다.

CMK를 폐기(Revoke)하면 Atlas 클러스터가 즉시 접근 불가 상태가 된다. 이것이 보안 사고 시 "킬 스위치"로 작동한다. 단, CMK를 실수로 삭제하면 모든 데이터가 영구 손실되므로 키 관리에 극도의 주의가 필요하다.

2025년 신규: Azure Key Vault Secretless 인증: 기존에는 Azure Key Vault 연동 시 정적 클라이언트 시크릿이 필요했다. 2025년부터 단기 OAuth 2.0 토큰을 사용하는 Secretless 인증이 도입되어 시크릿 순환 관리 부담이 사라졌다.

# Azure Key Vault Secretless 설정 (시크릿 없이 연동)
atlas encryption azureKeyVault enable \
  --clientID "" \
  --secret "" \
  --subscriptionID "xxxx" \
  --resourceGroupName "my-rg" \
  --keyVaultName "my-keyvault" \
  --keyIdentifier "https://my-keyvault.vault.azure.net/keys/mykey"

MongoDB Master Key 자동 90일 로테이션: CMK를 사용할 경우, Atlas는 MongoDB Master Key를 자동으로 최소 90일마다 교체한다. Maintenance Window 설정 시간에 맞춰 진행된다.

5-2. In Transit — 전송 데이터 암호화

Atlas는 TLS를 기본 강제 적용한다. TLS 없는 연결은 거부된다. 2025년부터는 TLS 1.3 플릿 전체 적용이 진행 중이다.

# 최소 TLS 버전 강제 설정 (Resource Policy)
# TLS 1.0, 1.1 사용 차단
atlas clusters update myCluster \
  --minimumEnabledTlsProtocol "TLS1_2"

5-3. In Use — 처리 중 데이터 암호화 (Queryable Encryption)

가장 강력한 암호화 방식이다. 데이터가 클라이언트에서 암호화된 채로 서버에 저장되며, 서버(MongoDB Atlas)는 암호문만 보유한다. MongoDB 직원도, 클라우드 프로바이더도 평문 데이터를 볼 수 없다.

// Queryable Encryption 설정 예시 (Node.js)
const { ClientEncryption } = require('mongodb-client-encryption');

const encryptedClient = new MongoClient(uri, {
  autoEncryption: {
    keyVaultNamespace: "encryption.__keyVault",
    kmsProviders: {
      aws: {
        accessKeyId: process.env.AWS_ACCESS_KEY_ID,
        secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
      }
    },
    encryptedFieldsMap: {
      "mydb.users": {
        fields: [
          {
            path: "ssn",
            bsonType: "string",
            queries: { queryType: "equality" }
          },
          {
            path: "creditCard",
            bsonType: "string",
            queries: { queryType: "equality" }
          }
        ]
      }
    }
  }
});

// ssn 필드로 쿼리해도 서버는 암호문만 처리
const user = await db.collection("users").findOne({ ssn: "900101-1234567" });

CSFLE vs Queryable Encryption 비교:

6. 감사 로그(Audit Log) — 누가 무엇을 했는가

"무슨 일이 있었는지" 추적하는 것도 보안의 핵심이다. M10 이상 클러스터에서 Database Auditing을 활성화할 수 있다.

6-1. 감사 로그 활성화

# Atlas CLI로 Auditing 활성화
atlas auditing update \
  --auditFilter '{"atype": {"$in": ["authenticate", "authCheck", "createCollection", "dropCollection", "createIndex", "dropIndex", "createUser", "dropUser", "updateUser"]}}' \
  --auditAuthorizationSuccess false

--auditAuthorizationSuccess false 설정으로 성공한 인증을 제외해 로그 과다를 방지한다.

6-2. 감사해야 할 핵심 이벤트

{
  "atype": {
    "$in": [
      "authenticate",       // 로그인 시도 (성공/실패)
      "authCheck",          // 권한 검사
      "createCollection",   // 컬렉션 생성
      "dropCollection",     // 컬렉션 삭제 (반드시 추적)
      "dropDatabase",       // DB 삭제 (반드시 추적)
      "createIndex",        // 인덱스 생성
      "createUser",         // 사용자 생성
      "dropUser",           // 사용자 삭제
      "updateUser",         // 권한 변경
      "logout"              // 로그아웃
    ]
  }
}

6-3. 외부 시스템으로 로그 전송 (Push-based Log Export)

2025년 업데이트로 Push-based Log Export가 추가되었다. Atlas가 자동으로 로그를 외부 시스템으로 전송한다. SIEM 연동이 훨씬 수월해졌다.

7. 컴플라이언스 대응 — GDPR, PCI DSS, HIPAA

Atlas는 다양한 글로벌 컴플라이언스 인증을 보유하고 있으며, 이를 활용해 규제 준수 부담을 크게 줄일 수 있다.

Atlas가 인증/준수하는 표준:

인증 현황과 적용 범위(리전, 티어)는 MongoDB Trust Center에서 최신 상태를 확인한다. 특히 PCI DSS, FedRAMP 인증 범위는 클라우드 리전과 클러스터 티어에 따라 다를 수 있다.

GDPR 대응 핵심 체크포인트

데이터 주권 요건
  EU 사용자 데이터는 EU 리전(eu-west-1, eu-central-1)에만 저장
  멀티 리전 시 EU 외 리전으로 데이터 복제 금지
  Global Cluster의 Zone 설정으로 데이터 격리

개인정보 암호화
  이름, 이메일, 주소 등 PII 필드에 Queryable Encryption 적용
  데이터 삭제 요청 시 해당 CMK 폐기로 즉시 접근 불가 처리 가능

감사 로그
  개인정보 접근 이벤트 모두 기록
  최소 12개월 보존 권장

PCI DSS 대응 핵심 체크포인트

네트워크 격리
  IP Access List에서 0.0.0.0/0 완전 금지 (Resource Policy로 강제)
  Private Endpoint 필수 적용
  카드 데이터 처리 환경을 별도 Project로 격리

암호화
  CMK 기반 Encryption at Rest 적용
  TLS 1.2 이상 강제 (Resource Policy)
  카드번호 필드에 Queryable Encryption 적용

접근 제어
  최소 권한 원칙(PoLP) 적용된 RBAC
  MFA 강제 적용
  접근 로그 모든 이벤트 기록 및 12개월 보존

8. 실수하기 쉬운 보안 함정 TOP 5

현업에서 실제로 자주 발생하는 Atlas 보안 사고 패턴이다.

함정 1: 0.0.0.0/0 임시 등록 후 방치

"일단 연결부터 확인하자"며 등록한 전체 IP 허용이 그대로 남아있는 경우. 특히 개발 팀원이 로컬에서 테스트하려고 등록한 것이 프로덕션 프로젝트에 남는 경우가 많다.

해결책: Resource Policy로 0.0.0.0/0 등록 자체를 조직 차원에서 금지.

함정 2: 앱에서 atlasAdmin 계정 사용

앱 서버의 환경변수에서 atlasAdmin 계정의 크리덴셜이 발견되는 경우. 해당 크리덴셜이 유출되면 클러스터 전체가 위험해진다.

해결책: 앱별 전용 DB 사용자 생성 + 필요한 DB/컬렉션에만 readWrite 권한 부여.

함정 3: 연결 문자열에 비밀번호 하드코딩

// 절대 금지 — 코드에 크리덴셜 하드코딩
const uri = "mongodb+srv://admin:MyPassword123!@cluster0.xxxxx.mongodb.net/";

코드가 GitHub에 올라가는 순간 끝이다. 실수로 공개 레포에 커밋되는 사례가 매우 많다.

해결책: 환경변수, AWS Secrets Manager, Azure Key Vault, HashiCorp Vault 등 시크릿 관리 도구 사용.

// 올바른 방법 — 환경변수로 분리
const uri = `mongodb+srv://${process.env.MONGO_USER}:${process.env.MONGO_PASS}@cluster0.xxxxx.mongodb.net/`;

// 또는 AWS Secrets Manager 활용
const secret = await secretsManager.getSecretValue({ SecretId: 'prod/mongodb/credentials' }).promise();
const { username, password } = JSON.parse(secret.SecretString);

함정 4: Audit Log 미활성화

"사고가 나도 무슨 일이 있었는지 전혀 알 수 없는" 상태. DB 삭제, 대량 데이터 추출 등이 일어나도 추적 불가.

해결책: M10 이상 모든 프로덕션 클러스터에 Audit Log 즉시 활성화. 최소 dropCollection, dropDatabase, createUser, authenticate 이벤트는 반드시 기록.

함정 5: CMK 키를 하나의 리전에만 생성

AWS KMS 키를 단일 리전 키로 생성했다가, 해당 리전 장애 시 Atlas 클러스터가 완전히 다운되는 경우.

해결책: AWS KMS Multi-Region Key 사용. 키를 여러 리전에 복제해두면 한 리전이 다운돼도 다른 리전의 키로 복구 가능.

9. 보안 설정 최종 체크리스트

네트워크 보안

• IP Access List에 0.0.0.0/0 없음 확인
• 불필요한 IP/CIDR 제거 (퇴직 직원 IP, 임시 IP 등)
• 프로덕션 클러스터 Private Endpoint 설정 완료
• Resource Policy로 와일드카드 IP 등록 금지 적용

인증 & 인가

• 모든 Atlas UI 계정 MFA 활성화
• 앱별 전용 DB 사용자 생성 (공유 계정 사용 금지)
• atlasAdmin 계정 앱 서버에서 사용 안함 확인
• 크리덴셜 코드/설정파일에 하드코딩 없음
• 필요 최소 권한(PoLP) 기반 RBAC 적용

암호화

• 고보안 환경(금융/의료): CMK 활성화 (AWS KMS / Azure KV / GCP KMS)
• Azure KV 사용 시: Secretless 인증으로 전환 (2025년 권장)
• 민감 필드 (주민번호, 카드번호 등): Queryable Encryption 적용
• 최소 TLS 1.2 강제 설정 (Resource Policy)
• CMK 사용 시: AWS Multi-Region Key 또는 AKV 다중 리전 설정

감사 & 모니터링

• M10+ 모든 프로덕션 클러스터 Audit Log 활성화
• dropDatabase, dropCollection, createUser 이벤트 반드시 포함
• 로그 외부 시스템(Datadog / Splunk / S3) 전송 설정
• 비정상 인증 실패 알림 설정 (Atlas Alerts)
• 월 1회 Access List 검토 및 불필요 항목 제거

Part 3 요약

참고 자료

• MongoDB Atlas 보안 문서
• MongoDB Atlas 네트워크 접근 문서
• MongoDB Atlas Private Endpoint 문서
• MongoDB Atlas 데이터베이스 사용자와 역할
• MongoDB Atlas 저장 데이터 암호화 문서
• MongoDB Atlas 감사 로그 문서
• MongoDB Trust Center