Xác thực người dùng và tên ( User authentication and Names)

Chức năng bảo mật cơ bản trong mô hình bảo mật của Domino là xác thực người dùng ( bao gồm Notes clients, các domino server khác, browser và Internet client, và các chương trình phát triển sử dụng Notes API). Trong phần này tôi sẽ nói với các bạn về phần tổng quan xác thực, đặt tên phân cấp người dùng và máy chủ.

Khi một người dùng được xác định là "xác thực", server dựa trên sự hợp lệ của user name để điều khiển truy cập với Server và Database Access Controll Lists.

Trong phần này tôi cũng giới thiệu tổng quan về phân chia tổ chức của bạn ( Organization) thành các đơn vị chức năng ( Organization Unit - OU). OU Certificate ID được tạo từ ID gốc của tổ chức, sau đó được sử dụng để đăng ký người dùng và server

-----> Phần này có một chút tới kiến thức LDAP hoặc AD

ID file được tạo trong suốt quá trình setup first Domino Server

Bạn có thể không nhận ra trong quá trình cài đặt First Server, là bạn đã cài đặt một hệ thống bảo mật cơ bản.

Sử dụng tên của Organization bạn nhập vào, quá trình cài đặt tạo ra duy nhất một Organization Certificate ( chuỗi 1024 bit bao gồm số và ký tự) cho Organization. Được xác định bởi tên, ví dụ "O=VSD"

Cùng với các thông tin khác, quá trình cài đặt thêm Organization Certificate vào Organization Certifier ID file có tên là CERT.ID

Server Setup sử dụng CERT ID để tạo ID cho server và Administrator

Các thông tin về máy chủ và người dùng được thêm vào mỗi file ID, tất cả các file này được đánh dấu hai thứ từ Organization Certifier:

• Tên của Organization, ví dụ "VSD", được nối thêm vào phần tên của server và tài khoản người dùng ( đôi khi còn được gọi là tên phân biệt - Disinguished name).
• Organization Certificate

Chú ý: trong bài hướng dẫn cài đặt lần trước, tôi đã tạo luôn Organization Unit (OU), nên tên của máy chủ và người dùng có dạng CN=Mail/OU=NN/O=COM, CN=ADMIN/OU=NN/O=COM

Nội dung của file ID

Để xem được nội dung của file ID Server hoặc ID User, bật giao diên Domino Administrator lên, di chuyển tới tab chức năng Configuration, chọn Certification\ ID Properties, chọn file ID cần xem

Tab Your Certificate bạn có thể thấy các certficate được thêm vào file ID.
Hình dưới đây thể hiện các thành phần có trong file ID

Bảng dưới đây mô tả hình ảnh trên

Thành phần	Chức năng
User Name	Tên ( người dùng, máy chủ) để Domino quản lý và kiểm tra bảo mật database
Password	Nhấp vào tab Security Basics, nhấp chuột vào Change Password, để thay đổi mật khẩu. Độ khó của mật khẩu được thiết lập lúc đăng ký, và người dùng có thể thay đổi mật khẩu của họ miễn là mật khẩu đủ mạnh. Nếu mật khẩu không đủ mạnh, bạn sẽ gặp một thông báo là nhập một mật khẩu khác mạnh hơn. Người quản trị có thể yêu cầu ( thông qua cài đặt trong Domino Directory) mật khẩu User ID thay đổi trong khoảng thời gian hoặc người dùng bị khóa bởi máy chủ
Expiration Date	Theo mặc định, certificate của Server ID có thời hạn là 100 năm, User ID có thời hạn là 2 năm. Khi bạn đăng ký hoặc gia hạn ID file, bạn có thể thay đổi các thời hạn khác nhau.
Recovery Password(s)	Đây là một lựa chọn phục hồi lại mật khẩu, được thêm vào bởi người quản trị khi mở User ID file nếu quên mật khẩu. Việc khôi phục này, chỉ áp dụng nới Notes User ID và không áp dụng với Server ID, trong trường hợp khác, bạn có thể cấu hình Notes User ID Vault để nhanh chóng khôi phục lại ID và mật khẩu bị mất.
Notes Certificates	Bao gồm 2 certificate, (Notes Multi-purpose, Notes international encryption) và còn lại là certificate từ Certifier : Một từ Organization Certifier.(CERT.ID) Một từ mọi OU certifier (OU.ID) Mỗi certificate gồm có: Tên của Organization hoặc Organization Unit certifier được sử dụng để cấp phát certificate Tên của người dùng hoặc máy chủ mà certificate được cấp phát Private Key và Public key Chữ ký số của certifier để chứng minh quá trình xác thực của Notes Certificate Ngày hết hạn khi certificate không còn hợp lệ
Public Key	Một khóa mã hóa duy nhất được lưu trữ trong file ID, sử dụng trong suốt quá trình xác thực, mã hóa mail gửi tới các Notes Client khác và được lưu trong mail database của người dùng. Public Key có thể được sao chép, gửi mail từ User Security >Your Certificate, hoặc sao chép từ tài liệu user’s Person trong Domino Directory
Private Key	Một khóa mã hóa duy nhất cho người dùng, và được lưu trữ chỉ trong file User ID. Khóa này không thể xem được. Khóa Private được sử dụng để valid người dùng trong quá trình xác thực, cũng có thể dùng: Giải mã mail đã được mã hóa khớp với Public Key Mã hóa mail gửi tới Notes User. Chú ý : Nếu mất User ID và không có bản backup, tất cả các mail đã được mã hóa sẽ không thể được giải mã bởi vì User ID mới có chứa Private Key mới.
Document Encryption Keys	Các khóa mã hóa sử dụng để mã hóa và giải mã document fields. Ví dụ, HR database cho phép người dùng đọc các thông tin tổng quan về người lao động, nhưng trường Salary được mã hóa và chỉ một số người trong công có chìa khóa mã hóa để mã hóa và giải mã trường này.
Internet Certificates	Một option, chứng chỉ X.509 sử dụng để mã hóa với Web server, xác thực user name, mã hóa mail gửi tới internet user. Chứng chỉ này được thêm vào sau khi người dùng được đăng ký.

.

Server ID file: Có mật khẩu hay không có mật khẩu?

Có hay không mật khẩu cho server id file là một chủ đề lớn cần tranh luận. Theo mặc định, server id file không có mật khẩu, điều này làm giảm khả năng bảo mật. Đặt mật khẩu cho server id file  tạo cho server bảo mật hơn và bảo vệ những databases đã được mã hóa. Nhưng bên cạnh đó, bạn phải luôn thường trực tại server khi bạn khởi động nó, thậm chí Domino server khởi động như windows services ( Khà khà, không chạy đi đâu được, vì phải gõ mật khẩu cho file ID Server, thì domino server mới bật lên được).
Để được tốt nhất cả về sự thuận tiện và bảo mật, bạn cần cài đặt thêm một công cụ của hãng thứ ba để bảo mật quá trình khởi động server mà không ảnh hưởng tới Server ID.
Bạn không nên đặt mật khẩu cho server id trong hai trường hợp sau:

• Sử dụng công cụ Domino Admin từ xa để khởi động lại Domino Server
• Sử dụng tính năng tự động phục hồi máy chủ

Cả hai tính năng này có bộ nhớ cache mật khẩu và sử dụng nó khi server khởi động lại.

Xác nhận và xác thực ( Validation and Authentication)

Nhắc lại mô hình bảo mật tôi giới thiệu trong bài trước, khi người dùng Notes thực hiện kết nối vào Domino Server ( hoặc Domino Server này kết nối vào Domino Server khác), việc đầu tiên xảy ra là quá trình xử lý hai pha, validation và authentication. Tại điểm cuối của quá trình, hai bên trust với nhau, và danh tính của người dùng được xác nhận. Điều này đủ để chuyển qua bước tiếp theo trong mô hình bảo mật, bước "Server access list" để so sánh sự hợp lệ của người dùng và server.
Sau đây tôi sẽ mô tả một cách đơn giản quá trình xử lý hai pha khi đồng chí Admin/VSD/COM kết nối vào máy chủ Mail, áp dụng với tất cả các kết nối (LAN, WAN, dial-up,...).
Mọi thứ cần thiết cần thiết để xác nhận và xác thực đều chứa trong file ID của người dùng hoặc server.


Trong pha xác nhận, MAIL server xác định Public Key của đồng chí ADMIN:

1. Notes client gửi tất cả Notes Certfificates trong file admin.id tới MAIL server, bao gồm cả Admin's personal certificate và tất cả certificate của Organization/Organization Unit.
2. MAIL server tìm kiếm certificate /VSD mà Admin gửi, và tìm một certificate có tên giống như vậy trong file ID mà nó quản lý.
3. Sử dụng Public Key của /VSD cert, MAIL server xác định Admin's persional certificate là hợp lệ bởi vì nó giống với /VSD cert
4. MAIL server kết luận Public Key trong Admin's personal cert là hợp lệ.

Pha xác nhận được lặp lại, nhưng đổi chiều

Trong pha xác thực, MAIL server xác định tính hợp lệ định danh của ADMIN:

1. MAIL server sinh ra một số ngẫu nhiên và mã hóa nó sử dụng Admin Public key và gửi nó cho Notes clients.
2. Sử dụng Private ksy chỉ có trong Admin User ID file, Notes giải mã số và gửi lại cho Mail server.
3. Mail server so sánh số ban đầu với số mà mà Notes gửi. Nếu bằng nhau, thì Notes User ID có Private key giống với Public key sử dụng để giải mã thành công.

Pha xác thực được lặp lại, nhưng đổi chiều.
Trong suốt quá trình cài đặt First Domino server, OU cert được sử dụng để đăng ký Administrator user. Miễn là bạn đăng ký người dùng và máy chủ sử dụng OU cert này, thì quá trình xác nhận và xác thực đều được đảm bảo.
Nếu bạn mất  Organization ID, thì bạn gặp vấn đề lớn rồi đấy. Thậm chí nếu bạn tạo một ID giống hệt với Organization  name, bạn sẽ có một tập các khóa mới. Mọi người dùng và máy chủ mới tạo ra bởi ID mới sẽ không thể xác thực được với server hiện tại. Có hai cách giải quyết vấn đề này:

• Tạo mới Organization cert, đăng ký mới người dùng và máy chủ sử dụng ID này. Sau đó cross certify người dùng và máy chủ hiện đang tồn tại.
• Tạo mới Organization ID với tên giống trước hoặc khác, sau đó recertify Notes và Domino ID file.

Tăng cường bảo mật xác thực

Nếu quá trình xác thực hiện tại chưa làm bạn hài lòng, bạn có thể tăng cường khả năng bảo mật của quá trình xác thực bằng cách bắt server so sánh Public key từ Domino Directory trong suốt quá trình xác thực Public key được gửi từ Notes client hoặc server. Vì thế, trong trường hợp gần như không thể, hách cơ hack user id file để có được Public key, với việc kích hoạt tính năng này, khóa phải khớp với khóa được lưu trong Domino Directory.
Để kích hoạt tính năng so sánh key, bạn xem hình dưới

Chú ý: thiết lập này nhằm ngăn chặn người dùng bên ngoài tổ chức có thể cross-certified để có thể truy cập vào máy chủ. Nó còn ngăn chặn người dùng đã xóa khỏi Domino Directory có thể truy cập.
Thiết lập này ko áp dụng với browser client.

Hệ thống phân cấp OU Cert

Trong quá trình cài đặt First Server đã tạo ra Organization Cert ID, và từ ID này tạo ra Server ID và Admin ID tại gốc trong mô hình phân cấp ( cụ thể ở đây là /VSD)
Không hạn chế nếu bạn đăng ký tất cả user và server sử dụng Organization Certifier ID. Nhưng đôi khi, bạn có hàng trăm người dùng Notes, cách tốt nhất là bạn tạo ra một hệ thống phân cấp, để tiện cho việc quản lý, ví dụ:

Các OU cert được tạo ra từ O cert.

Thuận lợi của việc sử dụng Organizational Unit

Những thuận lợi khi bạn chia nhỏ Organization thành các OU là:
Người dùng trùng tên có thể phân biệt qua OU
Người quản tri tại mức OU có thể sử dụng OU ID để đăng ký người dùng và server bên trong tổ chức của mình
Phân quyền truy cập tới máy chủ và database có thể sử dụng ký tự đại diện (*/UB/QN/VSD).