MongoDB Academy · 강의

보안 강화 및 운영 환경 점검 목록

학습자는 인증, RBAC, TLS, 암호화, 모니터링 및 백업 전략을 포함하는 운영 환경 준비 점검 목록을 단계별로 살펴봅니다.

레슨 4/413개 단계

보안 강화 및 운영 환경 점검 목록은(는) CoddyKit의 무료 MongoDB Academy 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 MongoDB Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. MongoDB Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

운영 준비를 위한 사고방식

운영 준비는 기능이 아니라 실제 사용자가 시스템에 처음 접속하기 전에 적용하는 규율의 체크리스트입니다. 모든 기능 테스트를 통과했더라도 보안 강화, 모니터링, 백업 검증을 건너뛴 배포는 운영 준비가 된 것이 아닙니다. 이 마지막 단원에서는 인증, RBAC, TLS, 암호화, 모니터링, 백업, 재해 복구를 포함하여 MongoDB 배포에 필요한 핵심 운영 체크리스트를 살펴봅니다.

체크리스트 1: 인증 활성화

인증이 활성화되어 있고 인증되지 않은 연결이 불가능한지 확인하십시오. 자체 호스팅 MongoDB에서는 mongod.conf에 security.authorization: enabled가 설정되어 있는지 확인하십시오. Atlas에서는 인증이 필수이며 비활성화할 수 없습니다. 자격 증명 없이 연결을 시도하여 테스트하십시오. 연결이 거부되어야 합니다. 운영 애플리케이션 계정의 어떤 사용자에게도 root 또는 __system 역할이 없는지 확인하십시오.

// Verify authentication is required
// (attempt to connect without credentials — should fail)
try {
  const client = new MongoClient('mongodb://localhost:27017')
  await client.connect()
  await client.db('admin').command({ ping: 1 })
  console.log('AUTH MISSING — unauthenticated connections accepted!')
} catch (e) {
  console.log('Good: unauthenticated connections rejected')
}

// List all admin users and their roles
use admin
db.getUsers()  // verify no app user has 'root' role

체크리스트 2: 최소 권한 RBAC

모든 데이터베이스 사용자를 감사하십시오. 각 애플리케이션 서비스에는 액세스해야 하는 데이터베이스에 필요한 역할만 부여해야 합니다. 각 데이터베이스에서 db.getUsers()를 실행하고, 어떤 서비스 계정에도 dbAdminAnyDatabase, readWriteAnyDatabase 또는 root가 부여되어 있지 않은지 확인하십시오. 어떤 서비스가 어떤 사용자로 연결하는지, 어떤 역할을 보유하는지, 그 이유가 무엇인지 기록하는 사용자 액세스 매트릭스를 작성하십시오. 이 매트릭스는 액세스 검토를 위한 단일 기준 정보입니다.

// Audit access matrix
const accessMatrix = [
  { service: 'api-server',       user: 'apiSvc',        roles: [{ role: 'readWrite', db: 'ecommerce' }] },
  { service: 'analytics-job',   user: 'analyticsSvc',  roles: [{ role: 'read', db: 'ecommerce' }] },
  { service: 'backup-agent',    user: 'backupAgent',   roles: [{ role: 'backup', db: 'admin' }] },
  { service: 'monitoring-exp',  user: 'prometheusExp', roles: [{ role: 'clusterMonitor', db: 'admin' }] }
]

// Verify each user's actual roles match the matrix
accessMatrix.forEach(entry => {
  const user = db.getSiblingDB('admin').getUser(entry.user)
  console.log(entry.service, user ? 'OK' : 'MISSING')
})

체크리스트 3: TLS 강제 적용

net.tls.mode: requireTLS가 활성 상태이고 모든 클라이언트 연결이 암호화되는지 확인하십시오. 아직 평문 연결을 시도하는 클라이언트를 나타내는 TLS 핸드셰이크 실패가 있는지 MongoDB 로그를 확인하십시오. Atlas에서는 TLS가 기본적으로 활성화되어 있으며 비활성화할 수 없습니다. 자체 호스팅 배포에서는 db.adminCommand({ sslInfo: 1 })를 실행하거나 db.serverStatus().network를 확인하여 TLS가 활성 상태인지 검증하십시오. 운영 환경에서 TLS가 allowTLS 모드인 배포는 허용하지 마십시오.

// Verify TLS is active on the server
const netStatus = db.adminCommand({ serverStatus: 1 }).network
console.log('TLS connections:', netStatus.serviceExecutorTaskStats)

// Confirm connection string includes TLS
// mongodb+srv:// always uses TLS
// Self-hosted: mongodb://host:27017/?tls=true

// Check mongod.conf programmatically
// grep 'mode: requireTLS' /etc/mongod.conf

체크리스트 4: 네트워크 격리

MongoDB에 공용 인터넷에서 직접 접근할 수 있어서는 안 됩니다. Atlas에서는 IP 액세스 목록에 0.0.0.0/0(모두 허용)이 포함되어 있지 않은지 확인하십시오. VPC 피어링 또는 프라이빗 링크를 사용하여 트래픽을 비공개로 라우팅하십시오. 자체 호스팅 배포에서는 MongoDB를 프라이빗 네트워크 인터페이스에만 바인딩하고(net.bindIp: 127.0.0.1,10.0.0.5), 포트 27017에서 애플리케이션 서버 IP만 허용하도록 방화벽 규칙을 구성하십시오.

# mongod.conf — bind only to localhost and private network interface
net:
  bindIp: 127.0.0.1,10.0.0.5  # never 0.0.0.0 in production
  port: 27017

# Firewall rule (iptables example — block public access to 27017)
# iptables -A INPUT -p tcp --dport 27017 -s 10.0.0.0/8 -j ACCEPT
# iptables -A INPUT -p tcp --dport 27017 -j DROP

체크리스트 5: 백업 및 특정 시점 복구

운영 배포에는 검증되고 테스트된 백업 전략이 있어야 합니다. Atlas에서는 보존 기간 내 어느 초로든 특정 시점 복구를 제공하는 지속적 클라우드 백업을 활성화하십시오. 자체 호스팅 환경에서는 매일 mongodump 스냅샷을 S3에 저장하도록 구성하고 매월 복원을 테스트하십시오. 핵심은 테스트된 백업입니다. 한 번도 복원해 보지 않은 백업은 신뢰할 수 없습니다. 분기마다 재해 복구 훈련을 실행하십시오.

# mongodump — daily backup to S3
mongodump \
  --uri 'mongodb://backupAgent:pass@host:27017/?authSource=admin' \
  --gzip \
  --archive=/tmp/backup-$(date +%Y%m%d).gz

# Upload to S3
aws s3 cp /tmp/backup-$(date +%Y%m%d).gz s3://my-mongo-backups/

# Verify backup integrity — test restore to a separate cluster
mongorestore \
  --uri 'mongodb://host2:27017' \
  --gzip \
  --archive=/tmp/backup-$(date +%Y%m%d).gz \
  --drop

체크리스트 6: 모니터링 및 경고

운영 MongoDB 배포에서는 다음을 모니터링해야 합니다. 하드웨어(CPU, 디스크 I/O, 네트워크), MongoDB 관련 항목(연결 수, opcounters, 캐시 적중률, replication lag, 잠금 비율), 애플리케이션 수준 항목(쿼리 지연 시간 P99, 오류율)입니다. Atlas에는 모니터링과 경고 기능이 기본 제공됩니다. 자체 호스팅 배포에서는 Prometheus(mongodb_exporter)와 Grafana 또는 이에 상응하는 도구를 연동해야 합니다. 임계값을 초과한 후가 아니라 초과하기 전에 alerts를 설정하십시오.

// Key Atlas alerts to configure (examples)
const alerts = [
  { metric: 'DISK_UTILIZATION',       threshold: '80%',  severity: 'WARNING' },
  { metric: 'CPU_SYSTEM_NORMALIZED',  threshold: '70%',  severity: 'WARNING' },
  { metric: 'REPLICATION_LAG',        threshold: '10s',  severity: 'CRITICAL' },
  { metric: 'CONNECTIONS',            threshold: '80%',  severity: 'WARNING' },
  { metric: 'CACHE_DIRTY_BYTES',      threshold: '20%',  severity: 'WARNING' }
]

체크리스트 7: 쿼리 성능 기준선

출시 전에 쿼리 성능 기준선을 설정하십시오. 프로파일러를 수준 1로 활성화하고 MongoDB의 부하 생성기나 k6 같은 도구를 사용하여 대표 부하를 실행한 다음, 각 핵심 엔드포인트의 P95 및 P99 지연 시간을 기록하십시오. 이 기준선을 저장하십시오. 배포할 때마다 부하 테스트를 다시 실행하고 비교하십시오. P99가 20%를 초과하여 악화되면 모든 사용자에게 배포하기 전에 조사를 시작해야 합니다.

// Enable profiler and set slow query threshold
db.setProfilingLevel(1, { slowms: 50 })  // log queries > 50ms

// After load test, query profiler for summary
db.system.profile.aggregate([
  {
    $group: {
      _id: '$ns',
      avgMs:    { $avg: '$millis' },
      maxMs:    { $max: '$millis' },
      count:    { $sum: 1 },
      slowOps:  { $sum: { $cond: [{ $gt: ['$millis', 100] }, 1, 0] } }
    }
  },
  { $sort: { avgMs: -1 } }
])

체크리스트 8: 저장 데이터 암호화

PII, 결제 데이터 또는 건강 정보를 처리하는 애플리케이션은 저장 데이터 암호화가 활성화되어 있는지 확인하십시오. Atlas에서는 보안 설정에서 클라우드 제공업체 KMS 기반 암호화를 활성화하십시오. 자체 호스팅 Enterprise 배포에서는 security.enableEncryption: true가 설정되어 있고 KMIP 키 관리자가 구성되어 있는지 확인하십시오. 어떤 Customer Master Key가 어떤 클러스터를 보호하는지 문서화하고, 잠금 방지를 위해 CMK 자체에도 여러 사람의 액세스 제어가 적용되어 있는지 확인하십시오.

// Verify Atlas encryption at rest is enabled via Atlas Admin API
curl -u 'PUBLIC_KEY:PRIVATE_KEY' --digest \
  'https://cloud.mongodb.com/api/atlas/v1.0/groups/GROUP_ID/encryptionAtRest'
// Response should show: 'awsKms.enabled': true (or azure/gcp equivalent)

// For self-hosted, check mongod.conf
// grep 'enableEncryption' /etc/mongod.conf
// Expected: enableEncryption: true

체크리스트 9: 감사 로깅

감사 로깅을 활성화하여 모든 인증, 권한 부여 실패, 민감한 데이터 액세스 이벤트를 기록하십시오. MongoDB Enterprise와 Atlas는 감사 로그 스트림을 제공하며, 이를 SIEM(Security Information and Event Management) 시스템으로 전달할 수 있습니다. 모든 authenticate 작업, 모든 createUser/dropUser/updateUser 작업, 민감한 collection(users, payments)에 대한 모든 작업을 기록하도록 감사 필터를 구성하십시오. 규정 준수를 위해 감사 로그를 최소 1년간 보존하십시오.

# mongod.conf — enable audit logging (Enterprise)
auditLog:
  destination: file
  format: JSON
  path: /var/log/mongodb/audit.json
  filter: '{
    atype: {
      $in: ["authenticate", "authCheck", "createUser", "dropUser",
            "logout", "createCollection", "dropCollection"]
    }
  }'

체크리스트 10: 런북 및 재해 복구 계획

운영 절차를 런북에 문서화하십시오. 긴급 상황에서 MongoDB에 연결하는 방법, 장애가 발생한 복제본 세트 멤버를 다시 시작하는 방법, 수동 장애 조치를 수행하는 방법, 백업에서 복원하는 방법, 에스컬레이션 경로가 무엇인지 기록해야 합니다. 스테이징 환경에서 이러한 절차를 연습하십시오. 복구 시간 목표(RTO)를 설정하십시오. 즉, 데이터베이스를 얼마나 오래 중단할 수 있는지를 정합니다. 또한 복구 시점 목표(RPO)를 설정하십시오. 즉, 허용 가능한 데이터 손실량을 정합니다. Atlas의 지속적 백업은 수초의 RPO를 제공합니다.

// Runbook checklist (document in your team wiki)
const runbook = {
  emergencyConnect: 'mongosh mongodb+srv://adminUser:***@cluster.mongodb.net',
  checkReplicaStatus: 'rs.status()',
  triggerManualFailover: 'rs.stepDown()  // on current primary',
  viewReplicationLag: 'rs.printSlaveReplicationInfo()',
  restoreFromBackup: 'atlas backups restores start --clusterName prod',
  contactList: ['dba-oncall@company.com', '+1-800-DBA-HELP'],
  rto: '15 minutes',
  rpo: '5 seconds (continuous backup)'
}

빠른 확인

이 단원에서 배운 MongoDB 및 NoSQL 데이터베이스 개념을 이해했는지 확인하십시오.

단원 요약

이 캡스톤의 마지막 수업에서는 프로덕션 준비 상태 점검 목록인 인증, 최소 권한 RBAC, TLS, 네트워크 격리, 백업 및 복구 테스트, 모니터링, 질의 성능 기준선, 저장 데이터 암호화, 감사 로그 기록, 문서화된 운영 절차서를 완성했습니다. 축하합니다. 이제 첫 문서 삽입부터 샤딩 클러스터의 프로덕션 배포까지, 전체 MongoDB 및 NoSQL 데이터베이스 과정을 모두 마쳤습니다. 이 기술을 활용해 훌륭한 무언가를 만들어 보세요!

무료로 시작

AI 튜터와 함께 JavaScript을(를) 배우세요 — 무료

브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.

코스
30
레슨
120

자주 묻는 질문

“보안 강화 및 운영 환경 점검 목록” 강의는 무료인가요?

네 — “보안 강화 및 운영 환경 점검 목록” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 MongoDB Academy 강의 전체를 잠금 해제할 수 있습니다. MongoDB Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

“보안 강화 및 운영 환경 점검 목록”에서 뭘 배우나요?

학습자는 인증, RBAC, TLS, 암호화, 모니터링 및 백업 전략을 포함하는 운영 환경 준비 점검 목록을 단계별로 살펴봅니다. 브라우저에서 직접 실행하는 실습 코드로 MongoDB Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

MongoDB Academy을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 MongoDB Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“보안 강화 및 운영 환경 점검 목록” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 MongoDB Academy 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 MongoDB Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. 요구 사항 분석 및 스키마 설계
  2. 인덱스 전략 및 쿼리 플래너 검증
  3. 확장 계획: 복제 세트에서 샤딩 클러스터까지
  4. 보안 강화 및 운영 환경 점검 목록
← MongoDB Academy(으)로 돌아가기