Chuyển đến nội dung chính

Bảo mật MongoDB 101: Tính năng cốt lõi mọi nhà phát triển cần biết

Nắm vững xác thực, kiểm soát truy cập dựa trên vai trò (RBAC), PoLP, mã hóa TLS/SSL và CSFLE để xây dựng ứng dụng NoSQL an toàn, hiệu năng cao.
· 10 phút đọc

Khám phá cùng AI

MongoDB cung cấp một khung bảo mật toàn diện dựa trên ba nguyên tắc cốt lõi: xác thực, ủy quyền và mã hóa.

Ba trụ cột này tạo thành một lớp phòng thủ nhiều tầng, đảm bảo một điểm lỗi không làm ảnh hưởng toàn bộ hệ thống. Trụ cột ủy quyền được định hướng bởi nguyên tắc đặc quyền tối thiểu (PoLP), đảm bảo mỗi người dùng hoặc ứng dụng chỉ có đúng các quyền tối thiểu cần thiết để thực hiện nhiệm vụ. 

Triển khai cách tiếp cận toàn diện, nhiều lớp này sẽ củng cố tư thế bảo mật tổng thể và giảm đáng kể nguy cơ phơi bày do cấu hình sai hoặc rò rỉ. 

Kích hoạt cổng đầu tiên: Xác thực

Xác thực là bước bảo mật cơ bản. Nó xác minh danh tính của mọi thực thể cố gắng kết nối. Trong MongoDB, điều này đạt được bằng cách bật các tính năng bảo mật vốn bị tắt theo mặc định để thuận tiện cho phát triển cục bộ.

Theo mặc định, bản triển khai MongoDB của bạn chỉ lắng nghe trên localhost và cho phép truy cập không xác thực. Cấu hình này là có chủ đích, giúp đơn giản tối đa cho thiết lập ban đầu và thử nghiệm cục bộ.

Với mọi môi trường production, hai thiết lập sau cần được nhà phát triển chú ý:

  • Trạng thái xác thực: Xác thực bị tắt theo mặc định. Bạn có thể bật ủy quyền bằng --auth hoặc thiết lập security.authorization. Bật xác thực nội bộ cũng đồng thời bật ủy quyền phía client. Lưu ý, khi đã bật kiểm soát truy cập, người dùng phải tự xác thực.
  • Ràng buộc mạng (bindIp): Theo mặc định, các binary của MongoDB (mongod và mongos) chỉ bind tới localhost. Mặc định an toàn này giới hạn kết nối trong cùng máy. Với môi trường production, bạn phải cấu hình rõ ràng thiết lập bindIp để liệt kê địa chỉ IP của các máy chủ ứng dụng được phép. Nếu cần hỗ trợ IPv6, bạn có thể đặt thiết lập tệp cấu hình net.ipv6 hoặc tùy chọn dòng lệnh --ipv6, khi đó binary cũng sẽ bind tới địa chỉ IPv6 của localhost. Luôn giới hạn điều này với các giao diện mạng đã được cho phép.

2. Cách bật xác thực

Bật xác thực sẽ biến MongoDB từ sân chơi cục bộ thành kho dữ liệu an toàn. Thao tác này được thực hiện bằng cách sửa tệp cấu hình MongoDB của bạn (thường là mongod.conf) và khởi động lại máy chủ.

Thiết lập trong tệp cấu hình: Đặt tùy chọn authorization trong phần security để bật tính năng:

  authorization: enabled

Người dùng đầu tiên: Khi bật xác thực, không ai có thể kết nối cho đến khi bạn tạo người dùng quản trị. Người dùng quan trọng đầu tiên này phải được tạo trong cơ sở dữ liệu admin, cấp cho họ các quyền ban đầu cần thiết để quản trị hệ thống và tạo người dùng khác.

3. Quản lý người dùng và mật khẩu (createUser)

Sau khi bật ủy quyền, mọi truy cập cơ sở dữ liệu đều được kiểm soát bởi người dùng và các vai trò liên kết. Bạn dùng lệnh createUser để định nghĩa các danh tính này.

Cú pháp và vai trò: Khi tạo người dùng, bạn chỉ định tên người dùng, mật khẩu và một mảng roles. Vai trò xác định quyền của họ (ví dụ, readWrite trên một cơ sở dữ liệu cụ thể).

db.createUser(
   {
     user: "appUser",
     pwd: passwordPrompt(),  // This function prompts for a password, which 
                                              // avoids storing the plain-text password in 
                                              // shell history and command logs.
     roles: [ { role: "readWrite", db: "inventory" } ]
   }
)

Chuẩn SCRAM: MongoDB dựa vào Cơ chế Xác thực Đáp ứng Thử thách Có muối (SCRAM) để xử lý mật khẩu an toàn. SCRAM tránh lưu mật khẩu dạng văn bản thuần và thay vào đó dùng băm và salt mạnh về mặt mật mã, giúp chống lại các vector tấn công phổ biến như rainbow table.

4. Tùy chọn xác thực nâng cao

Với các tổ chức có yêu cầu tuân thủ nghiêm ngặt hoặc hạ tầng phức tạp, MongoDB hỗ trợ tích hợp với các hệ thống xác thực cấp doanh nghiệp hiện có:

  • Chứng chỉ client x.509: Cho phép client xác thực bằng chứng chỉ số thay vì mật khẩu, cung cấp một lớp xác minh danh tính vững chắc, thường dùng cho tin cậy giữa máy-với-máy.
  • LDAP/Kerberos: Tích hợp MongoDB với các dịch vụ bên ngoài như Active Directory hoặc OpenLDAP, cho phép người dùng tận dụng thông tin xác thực doanh nghiệp hiện có để truy cập cơ sở dữ liệu.
  • Xác thực OpenID Connect (OIDC) - Workforce và Workloads: Đối với môi trường hiện đại đa đám mây và lai, MongoDB hỗ trợ Liên kết danh tính (Identity Federation) cho cả Workforce (truy cập người dùng qua các IdP như Azure AD, Okta) và Workload (xác thực máy-với-máy bằng danh tính nhà cung cấp đám mây, ví dụ AWS IAM hoặc Google Cloud Service Accounts).

Ủy quyền: Định nghĩa vai trò với RBAC

Xác thực xác nhận ai là người dùng; ủy quyền quyết định điều gì người đó được phép làm. Hệ thống Kiểm soát truy cập dựa trên vai trò (RBAC) của MongoDB là cơ chế cốt lõi để quản lý quyền, đảm bảo người dùng và dịch vụ chỉ tương tác với dữ liệu và lệnh mà họ thực sự cần.

1. Kiểm soát truy cập dựa trên vai trò

Trong mô hình RBAC của MongoDB, quyền được gom nhóm thành các vai trò, và các vai trò này được gán cho người dùng. Thay vì gán hàng trăm quyền riêng lẻ, bạn gán một vai trò (ví dụ, inventoryReader), vốn đã bao gồm tập quyền được định nghĩa (ví dụ, quyền đọc trên inventory.products). Điều này giúp quản lý quyền có thể mở rộng và dễ kiểm toán.

2. Các vai trò dựng sẵn mọi nhà phát triển cần biết

MongoDB cung cấp một bộ vai trò dựng sẵn vững chắc bao phủ hầu hết các mẫu truy cập phổ biến. Dưới đây là một vài ví dụ. Để xem đầy đủ, bạn tham khảo liên kết phía trên.

  • read và readWrite (truy cập cấp cơ sở dữ liệu): Đây là các vai trò phổ biến nhất cho người dùng ứng dụng. Chúng cấp quyền thực hiện thao tác chỉ đọc hoặc đọc/ghi, tương ứng, trên tất cả collection không phải hệ thống trong một cơ sở dữ liệu xác định.
  • dbAdmin: Cấp quyền quản trị cần thiết để quản lý một cơ sở dữ liệu cụ thể, như tạo, xóa, và sửa đổi chỉ mục và collection. Phù hợp cho đội phát triển hoặc script bảo trì cơ sở dữ liệu.
  • clusterAdmin (truy cập vận hành): Vai trò đặc quyền cao này thường dành cho nhân sự vận hành (DevOps/Ops). Nó cấp các quyền cần thiết để quản lý toàn bộ triển khai MongoDB, bao gồm cấu hình replica set, sharding và thực hiện sao lưu. Nhà phát triển ứng dụng hiếm khi cần vai trò này.

3. Áp dụng nguyên tắc đặc quyền tối thiểu

Nền tảng của bảo mật cơ sở dữ liệu hiện đại là nguyên tắc đặc quyền tối thiểu (PoLP). Theo đó, mỗi người dùng (đặc biệt là người dùng ứng dụng) chỉ nên được cấp những quyền tối thiểu cần thiết để thực hiện công việc, và không hơn.

Ví dụ về thực hành tốt: Thay vì dùng một người dùng readWrite toàn cục, hãy tạo người dùng chuyên biệt cho ứng dụng. Ví dụ, nếu dịch vụ inventory của bạn chỉ tương tác với cơ sở dữ liệu app_data, người dùng ứng dụng chỉ nên được cấp quyền readWrite đối với chính cơ sở dữ liệu đó. Sự ngăn vùng này ngăn chặn một dịch vụ bị xâm nhập truy cập trái phép các cơ sở dữ liệu khác (như billing hoặc users).

Ví dụ mã: tạo người dùng theo đặc quyền tối thiểu

Ví dụ này tạo một người dùng (inventory_service) với quyền đọc/ghi bị giới hạn nghiêm ngặt trong cơ sở dữ liệu app_data.

use admin
db.createUser(
   {
     user: "inventory_service",
     pwd: passwordPrompt(),
     roles: [ 
       { role: "readWrite", db: "app_data" }
     ]
   }
)

4. Tạo vai trò tùy chỉnh (khi vai trò dựng sẵn là chưa đủ)

Dù các vai trò dựng sẵn rất mạnh, yêu cầu tuân thủ hoặc logic ứng dụng phức tạp có thể đòi hỏi kiểm soát cực kỳ chi tiết. Khi đó, MongoDB cho phép bạn định nghĩa vai trò tùy chỉnh bằng lệnh db.createRole().

Định nghĩa quyền chi tiết: Vai trò tùy chỉnh cho phép bạn chỉ định chính xác những hành động đặc quyền nào (ví dụ, find, update, insert) có thể được thực hiện trên tài nguyên theo phạm vi cụm, cơ sở dữ liệu hoặc collection. Các tổ chức có thể tận dụng các kỹ thuật như che giấu ở cấp trường để bảo vệ các trường dữ liệu nhạy cảm cao trong một collection vốn dĩ là công khai.

Ví dụ mã: tạo vai trò tùy chỉnh

Ví dụ này tạo một vai trò tùy chỉnh (product_creator) chỉ có thể chèn tài liệu vào collection products trong cơ sở dữ liệu app_data.

use app_data
db.createRole(
   {
     role: "product_creator",
     privileges: [
       {
         resource: { db: "app_data", collection: "products" },
         actions: [ "insert" ]
       }
     ],
     roles: []
   }
)

Bảo vệ dữ liệu toàn diện: Cô lập mạng và mã hóa

Trong khi xác thực và ủy quyền mạnh mẽ kiểm soát truy cập vào cơ sở dữ liệu, bảo mật toàn diện đòi hỏi bảo vệ chính dữ liệu — cả khi dữ liệu di chuyển trên mạng (trong quá trình truyền) và khi lưu trên đĩa (khi lưu trữ).

1. Bảo vệ dữ liệu khi truyền với TLS/SSL

Truyền dữ liệu qua bất kỳ mạng nào, dù nội bộ trong trung tâm dữ liệu hay ra ngoài lên đám mây, đều phải được mã hóa để ngăn nghe lén và tấn công xen giữa (MITM). MongoDB dùng Transport Layer Security/Secure Sockets Layer (TLS/SSL) để mã hóa mọi giao tiếp giữa client (như ứng dụng của bạn) và máy chủ.

Không có TLS/SSL, thông tin xác thực người dùng, tham số truy vấn và kết quả nhạy cảm sẽ được truyền dạng văn bản thuần, rất dễ bị đánh chặn. Bật TLS/SSL đảm bảo dữ liệu được xáo trộn và bảo vệ trong suốt quá trình truyền.

Bật TLS/SSL: Việc này chủ yếu thông qua các thiết lập cấu hình, nơi bạn chỉ định chứng chỉ máy chủ dùng để xác minh danh tính và trao đổi khóa mã hóa:

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
  • net.ssl.mode: requireTLS buộc mọi kết nối đến phải dùng TLS/SSL, từ chối các nỗ lực không an toàn.
  • certificateKeyFile trỏ đến chứng chỉ TLS/SSL và tệp Certificate Authority đã tạo tương ứng.

2. Tường lửa và phân đoạn mạng

Phân đoạn mạng là một lớp phòng thủ quan trọng bằng cách giới hạn các giao diện vật lý hoặc ảo có thể kết nối tới cơ sở dữ liệu. Ngay cả khi kẻ tấn công có được quyền truy cập mạng, họ vẫn phải vượt qua vành đai của bạn.

  • Giới hạn truy cập qua danh sách trắng IP: Sử dụng thiết lập bindIp hoặc cấu hình tường lửa mạng, bạn có thể đưa IP cụ thể vào danh sách cho phép.
  • Thực hành tốt nhất: Máy chủ MongoDB chỉ nên được phơi ra cho máy chủ ứng dụng, bộ cân bằng tải hoặc lớp proxy của bạn. Không bao giờ được truy cập trực tiếp từ internet công cộng. Phân đoạn này đảm bảo cơ sở dữ liệu được che chắn phía sau vành đai bảo mật của hạ tầng ứng dụng.

3. Mã hóa khi lưu trữ (mã hóa của storage engine)

Bảo vệ dữ liệu khi lưu trữ đảm bảo rằng nếu đĩa vật lý hoặc môi trường máy chủ bị xâm phạm, các tệp vẫn không thể đọc được. MongoDB thực hiện điều này qua mã hóa của storage engine.

  • Cách hoạt động: Storage engine WiredTiger có thể cấu hình để mã hóa tất cả tệp dữ liệu, tệp cấu hình và tệp journal trên đĩa. Dữ liệu được mã hóa trong suốt khi ghi và giải mã khi đọc, sử dụng khóa mã hóa do hệ thống quản lý.
  • Lưu ý quan trọng: Dù đây là một lớp bảo mật thiết yếu, mã hóa khi lưu trữ nguyên bản thường là một tính năng của MongoDB Enterprise, và nó dựa vào máy chủ KMIP (Key Management Interoperability Protocol) bên ngoài hoặc tệp khóa cục bộ để quản lý khóa mã hóa.

4. Mã hóa trường phía client (CSFLE): Chuẩn vàng cho nhà phát triển

Trong khi mã hóa khi lưu trữ bảo vệ toàn bộ cơ sở dữ liệu, Mã hóa trường phía client (CSFLE) mang đến cho nhà phát triển khả năng kiểm soát tinh vi đối với dữ liệu nhạy cảm, cho phép họ mã hóa các trường cụ thể trước khi gửi lên cơ sở dữ liệu.

  • Giới thiệu CSFLE: Với CSFLE, việc mã hóa diễn ra trong driver ứng dụng trước khi dữ liệu rời máy chủ ứng dụng. Điều này có nghĩa máy chủ MongoDB không bao giờ thấy dữ liệu nhạy cảm dạng văn bản thuần; nó chỉ lưu ciphertext. Dữ liệu nhạy cảm luôn ở trạng thái mã hóa trên máy chủ, bao gồm trong bộ nhớ, log máy chủ và lưu trữ.
  • Công cụ mạnh nhất của nhà phát triển: CSFLE là chuẩn vàng cho tuân thủ (ví dụ GDPR, HIPAA), vì nó đảm bảo rằng ngay cả khi xảy ra rò rỉ dữ liệu toàn bộ cơ sở dữ liệu, các trường nhạy cảm (như PII hoặc thông tin tài chính) vẫn được mã hóa và bảo vệ. Nhà phát triển phải chủ động quyết định mã hóa những gì, tích hợp logic mã hóa trực tiếp vào mã ứng dụng của họ.

5. Mã hóa khi sử dụng với Queryable Encryption

Queryable Encryption là một bước tiến của CSFLE, giải quyết thách thức truy vấn trên các trường đã mã hóa. Nó cho phép ứng dụng thực hiện truy vấn so sánh bằng (ví dụ, tìm tài liệu nơi một trường đã mã hóa bằng một giá trị nào đó) trực tiếp trên ciphertext. Điều này mang lại mức độ bảo mật của CSFLE trong khi vẫn duy trì tính hữu dụng của dữ liệu, hiệu quả là mã hóa dữ liệu ngay khi đang sử dụng.

Ghi nhật ký kiểm toán: Công cụ hậu kiểm

Các biện pháp bảo mật hướng đến phòng ngừa, còn ghi nhật ký kiểm toán hướng đến trách nhiệm giải trình và phát hiện. Khung kiểm toán tích hợp của MongoDB cung cấp khả năng quan trọng để theo dõi và ghi lại các sự kiện liên quan đến bảo mật, tạo nên bản ghi bất biến thiết yếu cho pháp y, tuân thủ và phát hiện sớm mối đe dọa.

1. Kiểm toán là gì và vì sao quan trọng?

Kiểm toán ghi lại mọi hành động quan trọng thực hiện với cơ sở dữ liệu, tạo ra lịch sử chi tiết. Bao gồm:

  • Sự kiện xác thực: đăng nhập thành công và thất bại.
  • Thay đổi ủy quyền: tạo, sửa, hoặc xóa người dùng và vai trò.
  • Thay đổi cấu hình: sửa đổi tham số hệ thống ảnh hưởng đến bảo mật.

Nhật ký này vô giá với các đội an ninh khi phân tích sau sự cố (công cụ "hậu kiểm") hoặc đáp ứng yêu cầu tuân thủ quy định.

2. Cấu hình và lọc

Bật kiểm toán rất đơn giản, thường chỉ cần một dòng trong tệp cấu hình để kích hoạt hệ thống và chỉ định đích lưu log (file, syslog, hoặc console).

auditLog:
  destination: file
  format: BSON
  path: /var/log/mongodb/audit.bson
  filter: '{ atype: { $in: [ "authenticate", "createRole", "dropUser" ] } }'
  • Lọc: Hệ thống kiểm toán cho phép lọc rất chi tiết bằng cú pháp giống truy vấn. Điều này rất quan trọng để quản lý khối lượng log. Nhà phát triển nên tập trung bộ lọc vào các sự kiện quan trọng liên quan đến bảo mật, như thao tác quản lý người dùng, thay đổi cấu hình bảo mật và các lần thử xác thực.

Tóm tắt và bước tiếp theo

MongoDB cung cấp một bộ tính năng bảo mật toàn diện mà khi triển khai đúng sẽ tạo nên chiến lược phòng thủ nhiều lớp mạnh mẽ. Nhiệm vụ chính của bạn với tư cách nhà phát triển là vượt qua các mặc định dành cho phát triển và triển khai các kiểm soát cốt lõi này.

Trước khi bất kỳ ứng dụng nào lên production, hãy nhớ ba mệnh lệnh bảo mật cốt lõi sau:

  • Mã hóa dữ liệu khi truyền: Dùng TLS/SSL cho mọi kết nối mạng (net.ssl.mode: requireTLS).
  • Mã hóa dữ liệu khi lưu trữ: Đảm bảo các tệp cơ sở dữ liệu trên đĩa được bảo vệ bằng mã hóa ở cấp volume hoặc hệ thống tệp, hoặc mã hóa của storage engine WiredTiger của MongoDB (có trong MongoDB Enterprise) để chống truy cập trái phép vào tệp cơ sở dữ liệu.
  • Mã hóa dữ liệu khi sử dụng: Dùng Mã hóa trường phía client (CSFLE) và Queryable Encryption cho các trường dữ liệu cực kỳ nhạy cảm, đảm bảo dữ liệu vẫn được mã hóa ngay cả khi cơ sở dữ liệu đang chạy.

Bảo mật là một lĩnh vực luôn tiến hóa. Để tìm hiểu sâu và cấu hình nâng cao, hãy sử dụng tài liệu chính thức:

Tôi cũng khuyến nghị bạn xem khóa học Introduction to Using MongoDB for Data Science in Python.

Câu hỏi thường gặp về bảo mật MongoDB

Thiết lập bảo mật quan trọng nhất cho môi trường production là gì?

Xác thực bằng cách thiết lập security.authorization: enabled.

Sự khác biệt giữa xác thực và ủy quyền là gì?

Xác thực xác minh bạn là ai (danh tính), thường bằng tên người dùng và mật khẩu. Ủy quyền quyết định bạn có thể làm gì (quyền hạn), sử dụng RBAC để thực thi đặc quyền tối thiểu.

Mục đích của nguyên tắc đặc quyền tối thiểu (PoLP) là gì?

Nguyên tắc đặc quyền tối thiểu (PoLP) nhằm cấp cho người dùng và hệ thống chỉ đúng mức truy cập tuyệt đối cần thiết cho công việc cụ thể của họ. Trong khi điều này giảm thiểu thiệt hại khi có rò rỉ, nguyên tắc cũng là lớp phòng thủ quan trọng chống lại mối đe dọa nội bộ và lỗi vận hành, đồng thời giúp tổ chức của bạn đáp ứng các yêu cầu tuân thủ nghiêm ngặt. Nó tương đương với việc bạn chỉ đưa cho em bé những món đồ chơi không thể vỡ.

TLS/SSL bảo vệ dữ liệu của tôi như thế nào?

TLS/SSL mã hóa dữ liệu khi truyền, nghĩa là mọi giao tiếp giữa ứng dụng của bạn và máy chủ MongoDB đều được xáo trộn trên mạng.

Lợi ích chính của Mã hóa trường phía client (CSFLE) là gì?

CSFLE mã hóa các dữ liệu nhạy cảm cụ thể (như PII) trong ứng dụng trước khi rời phía client. Điều này đảm bảo dữ liệu vẫn được bảo vệ ngay cả khi chính máy chủ MongoDB, hoặc quản trị viên của nó, bị xâm phạm.

Karen Zhang

Tác giả

Karen Zhang

Karen là một Kỹ sư Dữ liệu đam mê xây dựng các nền tảng dữ liệu có khả năng mở rộng. Cô có kinh nghiệm tự động hóa hạ tầng với Terraform và háo hức chia sẻ những gì mình học được qua các bài blog và hướng dẫn. Karen là một người xây dựng cộng đồng và cô tâm huyết với việc kết nối những chuyên gia dữ liệu.

Chủ đề

Liên quan