2.3.1. Cơ chế xác thực trong MongoDB
CHƯƠNG 318. Xác thực là quá trình xác minh danh tính của người dùng. Khi kiểm sốt truy cập được kích hoạt, MongoDB u cầu tất cả các máy khách xác thực để xác định quyền truy cập. CHƯƠNG 319. Mặc dù xác thực và ủy quyền có mối liên hệ
chặt chẽ với nhau, nhưng xác thực khác với ủy quyền. Xác thực giúp xác minh danh tính của người dùng; ủy quyền xác định quyền của người dùng được truy cập và tương tác trong phạm vi tài nguyên giới hạn.
CHƯƠNG 320. 2.3.1.1. Phương thức xác thực
CHƯƠNG 321. Gồm 2 phương thức xác thực:
CHƯƠNG 322. Xác thực với tư cách người dùng: cung cấp tên người dùng, mật khẩu đăng nhập và cơ sở dữ liệu xác thực được liên kết với người dùng đó.
CHƯƠNG 323. Xác thực bằng cách sử dụng mongoshell:
CHƯƠNG 324. Sử dụng các tùy chọn câu lệnh mongo xác thực ( --username, --password và -- authenticationDatabase) khi kết nối với mongob hoặc mongos.
CHƯƠNG 325. Kết nối với mongod hoặc mongos, sau đó chạy lệnh authenticate hoặc phương thức db.auth() dựa trên cơ sở dữ liệu xác thực.
CHƯƠNG 326. Việc xác thực nhiều lần với tư cách khác nhau sẽ không làm mất thông tin đăng nhập của những người dùng đã được xác thực trước đó. Điều này có thể dẫn đến kết nối có nhiều quyền hơn chủ đích của người dùng và khiến các hoạt động trong một phiên logic phát sinh lỗi.
CHƯƠNG 327. 2.3.1.2. Cơ chế xác thực
CHƯƠNG 328. Trước khi có được quyền truy cập vào một hệ thống, người dùng phải xác thực nhận dạng danh tính của mình trong MongoDB. Điều này đảm bảo rằng khơng có ứng dụng nào khác truy cập vào dữ liệu được lưu trữ trong MongoDB mà không được cho phép bởi người có quyền hạn.
CHƯƠNG 329. MongoDB hỗ trợ hai cơ chế xác thực để người dùng xác minh danh tính của họ:
- SCRAM (Mặc định)
- Chứng thư X.509
CHƯƠNG 330. Ngoài ra, MongoDB Enterprise cũng cung cấp hỗ trợ xác thực LDAP proxy và xác thực Kerberos.
CHƯƠNG 331. 2.3.1.2.1. SCRAM
CHƯƠNG 332. Cơ chế xác thực thách thức – phản hồi có Salt (Salted Challenge Response Authentication Mechanism - SCRAM) là cơ chế xác thực mặc định cho MongoDB.
CHƯƠNG 333. SCRAM dựa trên tiêu chuẩn IETF RFC 5802 xác định các phương pháp tốt nhất để triển khai cơ chế này cho việc xác thực người dùng bằng mật khẩu.
CHƯƠNG 334. MongoDB sử dụng SCRAM để xác minh thông tin người dùng đã cung cấp thông qua tên đăng nhâp, mật khẩu và cơ sở dữ liệu xác thực của người dùng. Cơ sở dữ liệu xác thực là cơ sở dữ liệu nơi người dùng được tạo cùng với tên đăng nhập của người dùng, phục vụ cho việc xác minh người dùng.
CHƯƠNG 335. Việc triển khai SCRAM của MongoDB cung cấp:
- Khả năng hiệu chỉnh luồng dữ liệu
- Xác thực máy chủ đối với máy client và ngược lại. MongoDB hỗ trợ 2 cơ chế SCRAM:
a. Bảng 2.3: Cơ chế SCRAM trông MongoDB
CHƯƠNG 336. Cơ chế
SCRAM
CHƯƠNG 337. Mô tả
CHƯƠNG 338. SHA-1 Sử dụng hàm băm SHA-1
Thay đổi số lần lặp của mã SHA -1 CHƯƠNG 339. SHA –
256
Sử dụng hàm băm SHA – 256 ký tự và yêu cầu featureCompatibilityVersion set tới phiên bản 4.0 Thay đổi số lần lặp của mã SHA 256
CHƯƠNG 340. 2.3.1.2.2. Chứng thư X.509
Certificate Authority
CHƯƠNG 341. Để sử dụng trong phát triển phần mềm nói riêng và sản xuất nói chung, việc triển khai MongoDB địi hỏi phải có các chứng chỉ hợp lệ được tạo và ký bởi tổ chức phát hành chứng thực số. Người dùng hoặc tổ chức của họ có thể tạo và duy trì một tổ chức phát hành chứng thực độc lập hoặc sử dụng các chứng thực số được tạo bởi các nhà cung cấp dịch vụ TLS / SSL bên thứ ba. Client x.509 Certificates
CHƯƠNG 342. Để xác thực với máy chủ, máy Client có thể sử dụng chứng thực x.509 thay vì tên người dùng và mật khẩu. Chứng thực số ở bên phía client phải có các thuộc tính sau:
ƯƠ Tổ chức phát hành chứng thực số (CA) phải cấp chứng chỉ xác thực cho cả máy client và máy chủ.
ƯƠ Chứng thư số bên client phải chứa các trường sau: ƯƠ keyUsage =
digitalSignature; extendedKeyUsage = clientAuth;
CHƯƠNG 346. Ứng với mỗi người dùng chỉ tồn tại một chứng thư số duy nhất.
CHƯƠNG 347. Đối tượng Client của X.509 chứa distinguished name (DN) khác với đối tượng Member của X.509. Ít nhất một trong các thuộc tính Organization (O), Organizational Unit (OU),
hoặc Domain Component (DC) trong chứng thư số của client phải khác với các thuộc tính chứng thư số của net.tls.clusterFile và
net.tls.certificateKeyFile bên trong máy chủ.
CHƯƠNG 348. Nếu việc triển khai MongoDB đã được
tlsX509ClusterAuthDNOverride set, thì đối tượng của chứng chỉ
X.509 bên client cũng phải khác với giá trị đó.
- Người dùng và cơ sở dữ liệu $external
CHƯƠNG 349. Để xác thực bằng chứng thư client, trước tiên phải thêm giá trị của subject chứng chỉ máy khách với tư cách là người dùng MongoDB. Với mỗi chứng thư client X.509 tương ứng với một người dùng MongoDB; tức là không thể sử dụng một chứng thư phía client để xác thực nhiều người dùng MongoDB. CHƯƠNG 350. Để sử dụng phiên với người dùng xác thực trong
$external (Kerberos, LDAP, X.509), tên người dùng không được
lớn hơn 10.000 bytes.
- Xác thực
CHƯƠNG 351. Để kết nối và xác thực bằng chứng chỉ client X.509:
ƯƠ Đối với MongoDB 4.2 trở lên, bao gồm các tùy chọn sau cho ứng dụng khách:
CHƯƠNG 353. --tls
CHƯƠNG 354. --tlsCertificateKeyFile
CHƯƠNG 355. --tlsCertificateKeyFilePassword nếu file khóa chứng thư được mã hóa
CHƯƠNG 356. --authenticationDatabase '$external' CHƯƠNG 357. --authenticationMechanism MONGODB-X509
ƯƠ Đối với MongoDB 4.0 trở về trước, bao gồm các tùy chọn sau cho ứng dụng máy khách:
CHƯƠNG 359. --ssl
CHƯƠNG 360. --sslPEMKeyFile
CHƯƠNG 361. --sslPEMKeyPassword nếu --sslPEMKeyFile được mã hóa.
CHƯƠNG 362. --authenticationDatabase '$external' CHƯƠNG 363. --authenticationMechanism MONGODB-X509
2.3.2. Cơ chế ủy quyền trong mongodb
CHƯƠNG 364. MongoDB cung cấp cơ chế kiểm soát truy cập dựa trên vai trò (Role-Based Access Control - RBAC) để quản lý quyền truy cập vào hệ thống MongoDB. Người dùng được cấp một hoặc nhiều role xác định quyền truy cập vào các hoạt động vào tài nguyên cơ sở dữ liệu. Ngoài việc thực thi nhiệm vụ của mỗi role, người dùng khơng có quyền truy cập vào hệ thống.
CHƯƠNG 365. 2.3.2.1. Tính kế thừa
CHƯƠNG 366. Role có thể chứa một hoặc nhiều role đã tồn tại được xác định trước, trong trường hợp đó, role kế thừa tất cả các đặc quyền từ các role khác trong cơ sở dữ liệu. Ngoài ra, role được tạo trên cơ sở dữ liệu với quyền Admin có khả năng kế thừa đặc quyền từ các role khác trong bất kỳ cơ sở dữ liệu nào.
CHƯƠNG 367. 2.3.2.2. Xem quyền của role
CHƯƠNG 368. Người dùng có thể xem các đặc quyền của một role bằng cách đưa ra rolesInfo với các trường showPrivileges và showBuiltinRoles cả được thiết lập thành true. Từ đó có thể gán role cần thiết cho người dùng trong quá trình tạo user và cập nhật người dùng hiện có để gán hoặc thu hồi role.
CHƯƠNG 369. Người dùng được gán với một role nhất định sẽ nhận được tất cả các đặc quyền của role đó. Trong MongoDB, một người dùng có thể có nhiều role. Bằng cách gán các role cho người dùng trong các cơ sở dữ liệu khác nhau, người dùng được tạo trong đó có thể thực thi quyền trên các cơ sở dữ liệu khác.
CHƯƠNG 370. 2.3.2.3. Tính năng kiểm sốt truy cập
CHƯƠNG 371. MongoDB mặc định khơng bật tính năng kiểm sốt truy cập đối với q trình bắt đầu sử dụng. Người dùng có thể bật ủy quyền bằng cách thiết lập cài đặt --auth hoặc security authorization. Ngồi ra, kích hoạt xác thực nội bộ sẽ đồng thời kích hoạt cơ chế ủy quyền bên phía client. Sau khi bật kiểm sốt truy cập sẽ bắt buộc người dùng phải tự xác thực.
mongo--port27017 --authenticationDatabase"admin"-u "myUserAdmin" -p
CHƯƠNG 372. Một role có khả năng cung cấp các đặc quyền để thực hiện hành động được chỉ định trên hệ thống cơ sở dữ liệu. Mỗi đặc quyền được chỉ định rõ ràng trong role hoặc được kế thừa từ một role khác hoặc cả hai. Đặc quyền bao gồm một tài nguyên cụ thể và các hành động được phép trên tài nguyên đó. Tài nguyên có thể là một cơ sở dữ liệu, một set collection hoặc cluster. Nếu tài nguyên là cluster, các liên kết ảnh hưởng đến trạng thái của hệ thống hơn so với một cơ sở dữ liệu hoặc collection cụ thể.
CHƯƠNG 373. Một role chỉ định quyền hoạt động được phép trên vùng tài nguyên.
CHƯƠNG 374. Khi bật kiểm soát truy cập hãy đảm bảo rằng người dùng có role userAdmin hoặc userAdminAnyDatabase trong cơ sở dữ liệu admin. Người dùng này có thể quản lý người dùng và có các vai trị như: tạo người dùng, gán hoặc thu hồi vai trò từ người dùng và tạo hoặc sửa đổi role theo cấu hình của người dùng. CHƯƠNG 375. Quy trình:
CHƯƠNG 376. Bước 1: Khởi động MongoDB khơng có cơ chế kiểm sốt truy cập
CHƯƠNG 377. Bước 2: Kết nối với phiên bản MongoDB CHƯƠNG 378.
CHƯƠNG 379. Bước 3: Tạo người dùng quyền admin CHƯƠNG 380.
CHƯƠNG 381. Bước 4: Khởi động lại phiên bản MongoDB với cơ chế kiểm soát truy cập
CHƯƠNG 382. + Tắt mongod: CHƯƠNG 383.
CHƯƠNG 384. + Thoát khỏi mongo shell.
CHƯƠNG 385. + Khởi động mongod với tính năng kiểm sốt truy cập
CHƯƠNG 386.
CHƯƠNG 387. Bước 5: Kết nối và xác thực với quyền admin
CHƯƠNG 388.
CHƯƠNG 389. Bước 6: Tạo thêm người dùng cho việc triển khai
mongod --port 27017 --dbpath /var/lib/mongodb
mongo --port 27017 use admin
db.createUser( {
user: "myUserAdmin",
pwd: passwordPrompt(), // or cleartext password
roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase" ]
} )
db.adminCommand({ shutdown: 1 })
CHƯƠNG 390. + Sau khi xác thực dưới user administrator, sử dụng db.createUser() để tạo thêm người dùng. Từ đó người dùng có thể thiết lập built-in roles hoặc user-defined role tới người dùng.
CHƯƠNG 391. + Ví dụ: Thêm mới user myTester có quyền readWrite tới cơ sở dữ liệu test và quyền read trong cơ sở dữ liệu
database.
CHƯƠNG 392.
CHƯƠNG 393. Bước 7: Kết nối tới phiên bản và xác thực với quyền người dùng đã được xác thực.
CHƯƠNG 394.
CHƯƠNG 395. Bước 8: Đưa vào file document vào trong cơ sở dữ liệu
CHƯƠNG 396. + Xác thực user myTester và đưa file document vào trong collection của database
CHƯƠNG 397. 2.3.2.4. Quản lý người dùng và role
CHƯƠNG 398. Quản lý người dùng và role của người dùng dựa trên mơ hình ủy quyền của Mongodb. Cơ chế này u cầu q trình bật kiểm sốt truy cập, bạn phải xác thực là người dùng với các đặc quyền bắt buộc được chỉ định trong mỗi phần. Người dùng có quyền admin với role userAdminAnyDatabase hoặc userAdmin bên trong cơ sở dữ liệu cung cấp các quyền được yêu cầu để hiển thị danh sách hoạt động của đối tượng.
Tạo user-defined roles
CHƯƠNG 399. Role cung cấp cho người dùng quyền truy cập vào tài nguyên của MongoDB. MongoDB cung cấp một số vai trị có sẵn mà admin có thể sử dụng để kiểm sốt quyền truy cập vào hệ thống MongoDB. Tuy nhiên, nếu các role này không đáp ứng mơ tả các quyền mong muốn, người dùng có thể tạo các role mới trong một cơ sở dữ liệu cụ thể.
use test db.createUser( {
user: "myTester", pwd:passwordPrompt(),
// or cleartext password roles: [ { role: "readWrite", db: "test" },
{ role: "read", db: "reporting" } ] }
)
mongo --port 27017 -u "myTester" --authenticationDatabase "test" -p
mongo --port 27017 -u myUserAdmin -p 'abc123' -- authenticationDatabase 'admin'
CHƯƠNG 400. Ngoại trừ các role được tạo trong cơ sở dữ liệu admin, một role chỉ có thể chứa các quyền áp dụng cho cơ sở dữ liệu của nó và chỉ có thể kế thừa từ các role khác trong cơ sở dữ liệu của nó. Ngồi ra, role được tạo trong cơ sở dữ liệu admin có thể bao gồm các quyền áp dụng cho chính cơ sở dữ liệu đó, cơ sở dữ liệu khác hoặc cho cluster và có khả năng kế thừa từ các role trong mọi cơ sở dữ liệu khác.
CHƯƠNG 401. Để tạo một role mới sử dụng phương thức db.createRole() chỉ định quyền trong mảng privileges và các role kế thừa trong mảng roles. MongoDB sử dụng kết hợp tên cơ sở dữ liệu và tên role để xác định một role duy nhất. Mỗi role được đặt trong phạm vi cơ sở dữ liệu mà người dùng tạo ra, nhưng MongoDB lưu trữ tất cả thơng tin role đó trong admin.system.roles trong admin.
CHƯƠNG 402. Để tạo một role trong cơ sở dữ liệu cần có: ƯƠ createRole trên database resource.
ƯƠ grantRole trên cơ sở dữ liệu để xác định quyền đối với role mới cũng như xác định role kế thừa nó.
CHƯƠNG 405. Các role userAdmin và userAdminAnyDatabase tích hợp createRole và grantRole trên các tương ứng tài nguyên.
Tạo role để quản lý hoạt động
CHƯƠNG 406. Bước 1: Kết nối tới MongoDB với quyền hợp lý CHƯƠNG 407. + Kết nối tới mongod hoặc mongos với quyền
tương ứng
CHƯƠNG 408. + Quy trình sau myUserAdmin được tạo trong
bật kiểm sốt truy cập
CHƯƠNG 409. Bước 2: Tạo role mới để quản lý hoạt động CHƯƠNG 410. manageOpRole có các quyền hoạt động trên
nhiều cơ sở dữ liệu cũng như trên cluster. Như vậy, bạn phải role trong cơ sở dữ liệu admin.
CHƯƠNG 411.
2.3.3. Cơ chế mã hóa trong mongodb
CHƯƠNG 412. Bất kỳ cơ chế hoạt động nào của cơ sở dữ liệu đều liên quan đến hai dạng dữ liệu: dữ liệu ở trạng thái tĩnh hoặc dữ liệu trạng thái động. Dữ liệu trạng thái động là luồng dữ liệu di chuyển qua các mạng hoặc phần mềm trong khi dữ liệu ở trạng thái tĩnh không di chuyển đến bất kỳ đâu. Cả hai kiểu dữ liệu này đều dễ bị can thiệp từ bên ngoài bởi người dùng ẩn danh, vì vậy mongodb cung cấp cho người dùng giải pháp mã hóa.
CHƯƠNG 413. 2.3.3.1. Mã hóa dữ liệu truyền
CHƯƠNG 414. Dữ liệu di chuyển giữa MongoDB và máy chủ ứng dụng theo hai cách: thông qua Bảo mật lớp truyền tải (TLS) và Lớp cổng bảo mật (SSL).
CHƯƠNG 415. Đây là hai giao thức mã hóa được sử dụng nhiều nhất để bảo mật dữ liệu gửi và nhận giữa hai hệ thống. Về cơ bản, khái niệm này là mã hóa các kết nối đến các cá thể mongod và mongos sao cho lưu lượng mạng chỉ có chính khách hàng đó mới có thể đọc được. use admin db.creat eRole( { role: "manageOpRole", privileges: [
{ resource: { cluster: true }, actions: [ "killop", "inprog" ] },
{ resource: { db: "", collection: "" }, actions: [ "killCursors" ] }
CHƯƠNG 416. TLS/ SSL được sử dụng trong MongoDB với một số chứng thư số dưới dạng tệp PEM được cấp bởi tổ chức phát hành chứng thư số hoặc có thể là chứng thư tự ký. Tiếp theo là sự hạn chế ở kênh truyền được mã hóa nhưng khơng có xác thực đối với danh tính máy chủ do đó dễ bị tấn cơng ở giữa đường truyền từ bên ngoài. Do đó, bạn nên sử dụng các chứng thư của cơ quan đáng tin cậy cho phép MongoDB drivers xác minh danh tính máy chủ.
CHƯƠNG 417. Bên cạnh mã hóa, TLS / SSL có thể được sử dụng trong việc xác thực máy khách và xác thực nội bộ của các thành viên của nhóm bản sao và cụm phân đoạn thơng qua các chứng chỉ.
Cấu hình TLS/ SSL cho Client
CHƯƠNG 418. Có nhiều cài đặt tùy chọn TLS / SSL khác nhau có thể được sử dụng trong cấu hình của các giao thức này.
CHƯƠNG 419. --ssl: Cho phép kết nối TLS / SSL.
CHƯƠNG 420. mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem
CHƯƠNG 421. --sslCAFile: Chỉ định tệp PEM của tổ chức phát
hành chứng thư (CA) để xác minh chứng thư được cung cấp bởi mongod hoặc mongos. Do đó, Mongo shell sẽ xác minh chứng thư do cá thể mongod cấp dựa trên tệp CA được chỉ định và tên máy chủ.
CHƯƠNG 422. Kết nối phiên bản MongoDB yêu cầu chứng thư