Mức độ không an toàn của MongoDB và Cách tránh chúng

Hầu hết các hệ quản trị cơ sở dữ liệu đều có một số kỹ thuật bảo mật dữ liệu của chúng khỏi người ngoài hoặc người hoặc ứng dụng trái phép. Các kỹ thuật này ngăn không cho dữ liệu của bạn bị đọc hoặc sao chép mà không có sự cho phép của người dùng.

MongoDB không có gì khác biệt vì nó có một số mức độ không an toàn. Trong bài đăng trên blog này, chúng tôi sẽ thảo luận về các mức độ không an toàn trong MongoDB và cách tránh chúng để bạn có thể bảo vệ cài đặt MongoDB của mình.

Để đảm bảo an toàn và bảo mật cho MongoDB của bạn, sau đây là một số biện pháp bảo mật chính cần được xem xét nghiêm ngặt:

Xác thực kết nối người dùng.
Ủy quyền / Kiểm soát truy cập dựa trên vai trò.
Mã hóa mạng / Mã hóa truyền tải.
Mã hóa / Mã hóa lưu trữ-at-rest.
Kiểm toán.

Trong bài viết này, chúng ta sẽ xem xét chi tiết các biện pháp bảo mật ở trên, tập trung nhiều vào Xác thực và Ủy quyền.

Xác thực và Ủy quyền

Xác thực và Ủy quyền phải được kích hoạt đồng thời. Tuy nhiên, chúng có thể được sử dụng độc lập với nhau. Xác thực ngăn chặn việc truy cập vào một người không xác định có quyền truy cập mạng vào máy chủ cơ sở dữ liệu sao chép hoặc làm hỏng dữ liệu cơ sở dữ liệu. Xác thực yêu cầu tất cả các máy khách và máy chủ cung cấp thông tin xác thực hợp lệ trước khi chúng có thể kết nối với hệ thống. Mặt khác, ủy quyền ngăn ứng dụng hoặc người dùng đọc, thay đổi hoặc xóa dữ liệu khác với những gì họ phải làm.

Để định cấu hình kiểm soát truy cập Dựa trên vai trò;

Tạo quản trị viên người dùng trước.
Tạo thêm người dùng.
Sau đó, tạo một người dùng MongoDB duy nhất cho mỗi người / ứng dụng truy cập hệ thống.
Bằng cách tuân theo nguyên tắc ít đặc quyền nhất, bạn nên tạo các vai trò xác định các quyền truy cập chính xác cần thiết cho một tập hợp của người dùng.
Sau đó chỉ giao cho người dùng các vai trò mà họ cần thực hiện trong các hoạt động của mình. Người dùng có thể là một ứng dụng khách hoặc một người.

Bạn nên lưu ý rằng một người dùng có thể có các đặc quyền trên các cơ sở dữ liệu khác nhau hoặc nhiều cơ sở dữ liệu. Trong trường hợp đó, thay vì tạo một người dùng nhiều lần trong các cơ sở dữ liệu khác nhau, hãy tạo một người dùng duy nhất có vai trò cấp các đặc quyền cơ sở dữ liệu hiện hành.

Thông thường, hai biện pháp bảo mật này có thể bị nhầm lẫn có nghĩa giống nhau. Trong một số trường hợp, chúng tương tự nhau, nhưng chúng cũng khác nhau.

Điểm tương đồng giữa Xác thực và Ủy quyền

Cả hai đều là một đơn vị duy nhất vì khi bạn bật Xác thực, Cấp quyền sẽ tự động được bật. Ủy quyền được bật đồng thời với Xác thực do đó các kết nối từ người dùng không xác định sẽ không có đặc quyền truy cập dữ liệu cơ sở dữ liệu. Việc ủy quyền cũng yêu cầu tên người dùng phải được Xác thực xác minh để biết những đặc quyền nào áp dụng cho các yêu cầu của kết nối. Do đó, nó cũng không thể được bật độc lập với cái kia.
Cả hai đều giống nhau ở điểm đáng tiếc, cách đặt tên cũ của các tùy chọn cấu hình. Tùy chọn tệp cấu hình để xác thực là security.authorization thay vì xác thực bảo mật như mong đợi. Tuy nhiên, khi bạn sử dụng lệnh, Xác thực là lần đầu tiên được bật và Ủy quyền chỉ được bật dưới dạng hiệu ứng sau. “-Auth” là đối số dòng lệnh để bật xác thực tự động buộc cấp quyền cũng được bật.

Sự khác biệt giữa Xác thực và Ủy quyền

Hai phần này khác nhau vì chúng là hai phần của phần mềm có các chức năng khác nhau.

Xác thực ==Danh tính người dùng, bằng cách kiểm tra thông tin đăng nhập.

Ủy quyền ==Chỉ định và thực thi quyền đối tượng DB và lệnh DB.

Trong quá trình thiết lập ban đầu, Xác thực bị tắt đối với các kết nối máy chủ cục bộ. Tuy nhiên, điều này rất ngắn gọn vì bạn có một cơ hội để tạo người dùng đầu tiên, thì đặc quyền ngoại lệ (đối với Quy tắc Xác thực và Cấp phép trên cùng nhau) sẽ bị loại bỏ.

Cách Kiểm tra xem Xác thực và Cấp phép có được Bật hay không

Các phiên bản đầu tiên của MongoDB có “- auth” được đặt theo mặc định và đây được nhiều người coi là một hành động xấu. Ngay cả trong phiên bản 4.0, nó vẫn bị tắt theo mặc định. Cấu hình trống vẫn tương đương với việc cấp quyền bị tắt mặc dù có cảnh báo khởi động và các giảm mức độ hiển thị khác nhau, chẳng hạn như localhost trở thành thiết bị mạng có giới hạn mặc định duy nhất trong MongoDB v3.6.

Bạn đang không sử dụng Xác thực hay đúng hơn là bạn chưa bật Xác thực nếu các tệp cấu hình mongod không:

Đặt security.authorization thành ‘đã bật’.
Bao gồm một tệp security.keyfile.
Bao gồm cài đặt security.clusterAuthMode buộc bật xác thực.

Để kiểm tra kỹ xem bạn đã bật xác thực và Ủy quyền hay chưa, bạn có thể thử một lớp lót mongo shell nhanh này (không có đối số thông tin xác thực người dùng):

mongo --host : --quiet --eval 'db.adminCommand ({listDatabases:1})'

Phản hồi bạn sẽ nhận được là lỗi "trái phép". Tuy nhiên, mặt khác, nếu bạn nhận được danh sách tên cơ sở dữ liệu, thì điều đó tự động có nghĩa là bạn có triển khai MongoDB không có.

Xác thực Bên ngoài

Như tên cho thấy, xác thực bên ngoài là cho phép người dùng được xác thực trong một dịch vụ bên ngoài. Ngoại lệ, nó không thể được sử dụng cho người dùng hệ thống mongodb __ nội bộ, nhưng sử dụng nó cho bất kỳ tài khoản dịch vụ ứng dụng khách hoặc người dùng thực nào là hoàn toàn phù hợp.

Đơn giản, dịch vụ xác thực bên ngoài sẽ là Kerberos KDC hoặc máy chủ ActiveDirectory hoặc OpenLDAP. Bạn nên lưu ý rằng việc sử dụng xác thực bên ngoài không ngăn bạn có cùng lúc các tài khoản người dùng MongoDB thông thường.

Xác thực Nội bộ

Ngược lại, xác thực nội bộ MongoDB không có nghĩa là ngược lại với xác thực bên ngoài. Điều này là do một nút mongod chạy với xác thực được kích hoạt sẽ không tin tưởng rằng bất kỳ ứng dụng ngang hàng TCP nào là một nút mongod hoặc mongos khác chỉ vì nó giao tiếp giống như một. Thay vào đó, nó yêu cầu người ngang hàng xác thực bằng bằng chứng về bí mật được chia sẻ.

Có hai loại cơ chế xác thực nội bộ trong MongoDB:

Xác thực nội bộ tệp khóa.
SCRAM hoặc x.509 xác thực nội bộ.

Xác thực nội bộ tệp khóa

Đây là cơ chế xác thực nội bộ mặc định trong MongoDB. Thuật ngữ "Khóa" chỉ ra một khóa mã hóa không đối xứng nhưng theo nghĩa thực tế, nó chỉ là một mật khẩu bất kể bạn đã tạo nó như thế nào. Tệp khóa được lưu trong một tệp giống hệt nhau được phân phối cho mỗi nút mongod và mongos trong cụm. Trong trường hợp mật khẩu được sử dụng thành công, một nút mongod sẽ cho phép các lệnh đến từ ứng dụng ngang hàng đã xác thực chạy dưới dạng siêu người dùng “_ _ system”.

Nếu ai đó có bản sao của keyfile, họ có thể chỉ cần tách các ký tự kiểm soát và không in ra khỏi keyfile để tạo chuỗi mật khẩu cho phép họ kết nối với tư cách là người dùng “_ _ system”.

Tuy nhiên, nếu điều đó xảy ra và bạn chạy lệnh dưới đây với tư cách là người dùng mongod (hoặc root) trên một trong các máy chủ MongoDB của mình và thành công, bạn không nên lo lắng vì sẽ không tình cờ bị rò rỉ đặc quyền đọc . Điều này là do mongod sẽ hủy bỏ khi khởi động nếu tệp khóa ở bất kỳ chế độ nào khác ngoài chế độ cho phép tệp 400 (hoặc 600).

mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"

Tuy nhiên, việc vô tình lưu tệp khóa trong kiểm soát nguồn có thể đọc được trên thế giới của bạn có thể cho phép người dùng không phải là DBA (hoặc quản trị viên máy chủ có quyền root) đọc bản sao của tệp khóa. Đây được coi là lỗi bảo mật.

Rủi ro cực kỳ gia tăng khi tệp khóa được phân phối với các nút mongos được sở hữu và chạy với tư cách là một trong những người dùng unix của nhóm ứng dụng thay vì "mongod" hoặc người dùng unix khác thuộc sở hữu của nhóm DBA.

SCRAM hoặc x.509 Xác thực Nội bộ

Cơ chế xác thực nội bộ x.509 thực sự sử dụng khóa cá nhân hoặc khóa công khai không đối xứng và phải được sử dụng kết hợp với TLS / SSL. Cơ chế này có thể được sử dụng cho các kết nối máy khách cũng như xác thực nội bộ.

Cơ chế x.509 hoặc SCRAM có lợi thế hơn cơ chế Keyfile vì trong cơ chế x.509, ít có khả năng một trong các khóa được triển khai với các nút mongod và mongos có thể bị lạm dụng bởi một kẻ xâm nhập có được một bản sao của nó. Tuy nhiên, điều này phụ thuộc vào mức độ nghiêm ngặt của các chứng chỉ x.509 được thiết lập. Để được bảo mật tối đa từ cơ chế này, bạn nên có một nhóm bảo mật chuyên dụng hiểu các khái niệm x.509 và các phương pháp hay nhất. Các phương pháp hay nhất này bao gồm thắt chặt các máy chủ mà nó sẽ hoạt động và có thể thu hồi và chuyển các chứng chỉ.

Mã hóa mạng / Mã hóa truyền tải

Mã hóa mạng ngăn ai đó sao chép dữ liệu đang được truyền qua liên kết mạng ở đâu đó giữa hai máy chủ. Mã hóa mạng đòi hỏi ít hoặc không cần suy nghĩ khi quyết định sử dụng nó vì nó rất quan trọng. Nhưng nếu chẳng hạn, nếu cụm MongoDB của bạn và tất cả các máy khách của nó nằm trong một mạng riêng ảo mà bạn tin rằng không có lỗ hổng trong tường lửa của nó và không có nguy cơ leo thang đặc quyền từ các ứng dụng khác, thì bạn không cần mã hóa mạng.

Để mã hóa mạng, bạn nên định cấu hình MongoDB để sử dụng TLS / SSL cho tất cả các kết nối đi và đến. Mã hóa giao tiếp giữa các thành phần mongod và mongos của triển khai MOngoDB cũng như giữa tất cả các ứng dụng và MongoDB bằng TLS / SSL.

Bắt đầu từ phiên bản 4.0; MongoDB vô hiệu hóa hỗ trợ mã hóa TLS 1.0 trên các hệ thống có sẵn TLS 1.1+ và nó cũng sử dụng các thư viện TLS / SSL gốc sau:

Windows - Kênh Bảo mật (Schannel).
Linux / BSD - OpenSSL.
macOS - Truyền tải an toàn.

Giới hạn Phơi nhiễm Mạng

Bạn nên đảm bảo rằng MongoDB chạy trong môi trường mạng đáng tin cậy và cũng định cấu hình tường lửa hoặc nhóm bảo mật để kiểm soát lưu lượng đến và đi cho các phiên bản MongoDB của bạn. Hơn nữa, hãy cấu hình để chỉ cho phép các máy khách đáng tin cậy truy cập vào các giao diện mạng và các cổng mà trên đó các phiên bản MongoDB có sẵn. Ví dụ:sử dụng danh sách trắng IP để cho phép truy cập từ các địa chỉ IP đáng tin cậy.

Chạy MongoDB với Tùy chọn cấu hình an toàn

MongoDB hỗ trợ mã JavaScript thực thi cho các hoạt động phía máy chủ sau:

mapReduce.
$ ở đâu.
$ Tích lũy.
$ function.

Sử dụng tùy chọn - noscripting trên dòng lệnh để vô hiệu hóa tập lệnh phía máy chủ nếu bạn không sử dụng các thao tác trên. Giữ xác thực đầu vào được bật mặc dù MongoDB cho phép xác thực đầu vào theo mặc định thông qua cài đặt net.wireObjectCheck. Điều này đảm bảo rằng tất cả các tài liệu được lưu trữ bởi mongod intsance là BSON hợp lệ.

Mã hóa / Mã hóa lưu trữ MongoDB-at-rest

Mã hóa bộ nhớ ngăn ai đó lấy được bản sao của các tệp cơ sở dữ liệu bên dưới. Điều này có thể xảy ra khi ai đó đột nhập vào trung tâm dữ liệu của bạn và đánh cắp đĩa cứng của máy chủ. Dữ liệu MongoDB bao gồm các tệp dữ liệu, tệp cấu hình, nhật ký kiểm tra và tệp khóa.

Bắt đầu với MongoDB Enterprise 3.2, bạn có thể mã hóa dữ liệu trong lớp lưu trữ bằng Mã hóa nguyên bản của công cụ lưu trữ WiredTiger-at-rest. Dữ liệu MongoDB phải được mã hóa trên từng máy chủ lưu trữ bằng hệ thống tệp, thiết bị hoặc mã hóa vật lý khi không sử dụng mã hóa tại chỗ của WiredTiger. Ngoài ra, bạn nên thu thập nhật ký vào kho lưu trữ nhật ký trung tâm vì những nhật ký này chứa các lần xác thực DB bao gồm địa chỉ IP nguồn. Tuy nhiên, mã hóa lưu trữ có một chút chi phí hiệu suất.

Kiểm toán

Kiểm toán giúp theo dõi người dùng cơ sở dữ liệu biết cách che dấu vết của họ sau khi thay đổi hoặc thay đổi dữ liệu cơ sở dữ liệu. Về cơ bản, kiểm tra theo dõi quyền truy cập và các thay đổi đối với cấu hình cơ sở dữ liệu và dữ liệu. MongoDB Enterprise có một cơ sở hệ thống kiểm tra có thể ghi lại các sự kiện hệ thống như hoạt động của người dùng và các sự kiện kết nối trên một phiên bản MongoDB.

Những hồ sơ kiểm toán này giúp phân tích pháp y và cho phép quản trị viên xác minh các biện pháp kiểm soát thích hợp. Kiểm toán có giá trị cao đối với một số người dùng nhưng chỉ có thể như vậy, khi một số rủi ro khác được loại bỏ. Ví dụ:kẻ tấn công không thể giành được quyền truy cập gốc Unix trên các máy chủ trong khi chạy các nút mongod trực tiếp.

Tiến lên

Bạn có thể thiết lập bộ lọc để ghi lại các sự kiện cụ thể như sự kiện xác thực. Nhưng hãy cẩn thận vì khi các bộ lọc kiểm tra được tạo ra quá rộng, hiệu suất của nó sẽ nhanh chóng bị nghẹt dẫn đến chi phí hiệu suất cao. Mặc dù, nếu sử dụng kiểm toán một cách thích hợp, sẽ không có nhiều chi phí thực hiện.