Posted inSecurity

Bảo mật MongoDB Production: Tăng cường bảo mật Cluster với SCRAM, RBAC và Mã hóa TLS

Security tutorial - IT technology blog
Security tutorial - IT technology blog

So sánh kiến trúc: Cách các đội ngũ bảo mật MongoDB

Các đội ngũ kỹ thuật thường quản lý bảo mật MongoDB theo ba cấp độ trưởng thành riêng biệt:

  • Cô lập chỉ ở cấp chu vi (VPC và quy tắc Firewall): Database chạy mà không bật xác thực, dựa hoàn toàn vào các private subnet, security group và VPN tunnel để ngăn chặn kẻ xâm nhập.
  • Xác thực cơ bản với tài khoản Admin dùng chung: Cơ chế xác thực được bật, nhưng các microservice lại kết nối bằng thông tin đăng nhập quản trị có phạm vi quyền quá rộng như root hoặc dbAdminAnyDatabase qua các kết nối TCP không được mã hóa.
  • Phòng thủ theo chiều sâu (SCRAM-SHA-256, RBAC chi tiết và TLS 1.3): Mỗi service kết nối qua các tài khoản riêng biệt tuân thủ nguyên tắc đặc quyền tối thiểu (least-privilege) bằng xác thực salted challenge-response, đồng thời toàn bộ lưu lượng client-to-node và đồng bộ giữa các replica đều được mã hóa nghiêm ngặt.

Đánh giá các chiến lược bảo mật MongoDB

Mô hình ranh giới bảo mật ảnh hưởng trực tiếp đến tốc độ phát triển, chi phí debug và khả năng khoanh vùng sự cố rò rỉ dữ liệu. Dưới đây là cách ba chiến lược này hoạt động trong môi trường production:

1. Cô lập chỉ ở cấp chu vi

  • Ưu điểm: Không tốn chi phí quản lý thông tin xác thực (credential). Tiết kiệm khoảng 1–3 ms độ trễ bắt tay TLS ban đầu khi connection pool tăng đột biến. Thiết lập môi trường staging cục bộ đơn giản.
  • Nhược điểm: Rất mỏng manh. Một lỗ hổng Server-Side Request Forgery (SSRF) duy nhất hoặc một worker node bị xâm nhập sẽ làm lộ toàn bộ database trên cổng 27017. Hoàn toàn không có audit trail để truy vết truy cập dữ liệu.

2. Xác thực cơ bản với tài khoản quản trị dùng chung

  • Ưu điểm: Thiết lập nhanh chóng. Đáp ứng các tiêu chí tuân thủ ở mức bề mặt và tương thích với các legacy driver cũ mà không cần cấu hình thêm.
  • Nhược điểm: Phạm vi ảnh hưởng khi bị tấn công rất lớn. Nếu một analytics worker bị lộ credential, kẻ tấn công sẽ có quyền ghi vào dữ liệu thanh toán và thông tin người dùng. Lưu lượng nội bộ không được mã hóa cũng khiến thông tin xác thực dễ bị bắt gói tin (packet sniffing) trên các subnet dùng chung.

3. Phòng thủ theo chiều sâu (Tiêu chuẩn Production)

  • Ưu điểm: Cô lập các service bị xâm nhập trong phạm vi collection cụ thể của chúng. Bảo vệ mật khẩu khi truyền tải với 15.000 vòng băm PBKDF2. Đáp ứng các yêu cầu bắt buộc của SOC 2, HIPAA và PCI-DSS 4.0.
  • Nhược điểm: Đòi hỏi quy trình tự động xoay vòng chứng chỉ (certificate rotation) và cấp phát tài khoản database có hệ thống trong pipeline CI/CD của bạn.

Các thành phần cốt lõi của một hệ thống được gia cố bảo mật

Các cơ sở dữ liệu production cần ba lớp bảo mật cơ bản:

  1. Xác thực SCRAM-SHA-256: Thay thế các giao thức cũ như MONGODB-CR và SCRAM-SHA-1. Giao thức này sử dụng 15.000 vòng lặp PBKDF2 kết hợp HMAC-SHA-256, ngăn chặn các cuộc tấn công từ điển ngoại tuyến (offline dictionary attacks) ngay cả khi mã băm mật khẩu bị rò rỉ.
  2. Kiểm soát truy cập dựa trên vai trò (RBAC) chi tiết: Chỉ cấp cho ứng dụng chính xác các quyền hạn vận hành cần thiết, ví dụ như quyền readWrite trên một collection duy nhất, đồng thời khóa các tác vụ quản trị vào các jump host chuyên dụng.
  3. Bắt buộc sử dụng TLS 1.2/1.3: Lập tức ngắt các kết nối TCP không được mã hóa. Bảo vệ toàn bộ truy vấn client-to-server cũng như quá trình đồng bộ nội bộ của replica set giữa các node.

Hướng dẫn triển khai từng bước

Dưới đây là cách cấu hình một standalone node hoặc thành viên replica set mới triển khai để đạt chuẩn production.

Bước 1: Tạo mật khẩu có độ hỗn loạn cao (High-Entropy)

Trước khi chỉnh sửa các file cấu hình, hãy tạo mật khẩu duy nhất có ít nhất 32 ký tự (128+ bit entropy) cho cluster administrator, backup agent và các service ứng dụng. Bạn có thể sử dụng công cụ tạo mật khẩu trên trình duyệt tại toolcraft.app/vi/tools/security/password-generator—công cụ này tạo entropy cục bộ qua Web Crypto API mà không truyền key qua mạng.

Bước 2: Khởi tạo Cluster Administrator

Mở terminal cục bộ trên database host của bạn và kết nối với instance chưa bật xác thực bằng mongosh:

# Kết nối trực tiếp với daemon cục bộ trước khi bật xác thực
mongosh --port 27017

Chuyển sang database admin và tạo user root quản trị bằng SCRAM-SHA-256:

use admin;

db.createUser({
  user: "secAdmin",
  pwd: "Your32CharacterAdminSecretGoesHere!",
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" },
    { role: "clusterAdmin", db: "admin" }
  ],
  mechanisms: ["SCRAM-SHA-256"]
});

Bước 3: Cấp phát user ứng dụng với đặc quyền tối thiểu

Tuyệt đối không dùng chung thông tin đăng nhập quản trị giữa các microservice. Thay vào đó, hãy cô lập từng service vào ngữ cảnh database riêng:

use orders_prod;

db.createUser({
  user: "svc_orders_app",
  pwd: "OrdersApp_SecureSecret_9876!",
  roles: [
    { role: "readWrite", db: "orders_prod" }
  ],
  mechanisms: ["SCRAM-SHA-256"]
});

Đối với các service nặng về đọc như báo cáo thống kê hoặc làm ấm cache (cache-warming), chỉ cấp quyền đọc:

use catalog_prod;

db.createUser({
  user: "svc_analytics_ro",
  pwd: "Analytics_ReadOnlySecret_5432!",
  roles: [
    { role: "read", db: "catalog_prod" }
  ],
  mechanisms: ["SCRAM-SHA-256"]
});

Bước 4: Chuẩn bị chứng chỉ TLS

MongoDB yêu cầu chứng chỉ server và private key chưa mã hóa của nó được gộp chung vào một gói PEM duy nhất:

# Gộp private key và chứng chỉ server vào một file PEM
cat /etc/ssl/certs/mongo-server.key /etc/ssl/certs/mongo-server.crt > /etc/ssl/certs/mongodb.pem

# Giới hạn quyền truy cập file cho người dùng hệ thống mongod
chmod 600 /etc/ssl/certs/mongodb.pem
chown mongodb:mongodb /etc/ssl/certs/mongodb.pem

Bước 5: Áp dụng các chính sách bảo mật trong mongod.conf

Chỉnh sửa file /etc/mongod.conf để bind các interface IP riêng tư cụ thể, bắt buộc sử dụng TLS và thực thi xác thực SCRAM:

net:
  port: 27017
  bindIp: 127.0.0.1,10.0.1.15  # Chỉ bind vào loopback và interface VPC riêng tư
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/certs/mongodb.pem
    CAFile: /etc/ssl/certs/ca.pem
    disabledProtocols: TLS1_0,TLS1_1

security:
  authorization: enabled
  authenticationMechanisms:
    - SCRAM-SHA-256

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

Khởi động lại daemon để áp dụng chính sách mới:

sudo systemctl restart mongod
sudo systemctl status mongod

Bước 6: Kiểm tra kết nối đã xác thực và mã hóa

Xác nhận rằng các yêu cầu kết nối chưa xác thực và TCP thuần túy sẽ bị từ chối. Kết nối bằng chứng chỉ CA và tài khoản ứng dụng:

# Kết nối qua mongosh bằng TLS và SCRAM-SHA-256
mongosh "mongodb://[email protected]:27017/orders_prod" \
  --tls \
  --tlsCAFile /etc/ssl/certs/ca.pem \
  --authenticationMechanism SCRAM-SHA-256 \
  --password "OrdersApp_SecureSecret_9876!"

Đối với application driver (Node.js, Python PyMongo, hoặc Go), sử dụng định dạng URI chuẩn này:

mongodb://svc_orders_app:[email protected]:27017/orders_prod?authSource=orders_prod&authMechanism=SCRAM-SHA-256&tls=true&tlsCAFile=/etc/ssl/certs/ca.pem

Bước 7: Xác minh ranh giới kiểm soát truy cập

Kiểm tra để chắc chắn rằng tài khoản service không thể truy cập vào các namespace quản trị bị hạn chế:

// Đã đăng nhập với tư cách svc_orders_app
use admin;
db.system.users.find(); // Trả về: MongoServerError: not authorized on admin to execute command (code 13)

Hãy kiểm tra định kỳ file /var/log/mongodb/mongod.log để phát hiện các lần xác thực thất bại (code 18) hoặc ngắt kết nối bắt tay TLS. Việc này giúp pipeline audit của bạn sớm phát hiện các cuộc tấn công credential stuffing và các driver bị cấu hình sai.

Share:
Tags: