Xây dựng hạ tầng PKI trên nền Windows Server 2008 – Phần 4.2


Xem thêm:
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 1
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 2
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 3
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 4.1
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 4.2
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 5
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 6.1
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 6.2

————-

Xác định các yêu cầu về kỹ thuật

Các vấn đề kỹ thuật ảnh hưởng tới cấu trúc của hệ thống phân cấp CA và nên được xem xét trong suốt quá trình thiết kế PKI bao gồm:

1.   Chỉ định các vai trò quản lý PKI

Active Directory Certificate Services cho phép chỉ định, ủy quyền cho người dùng đảm trách các vai trò quản lý CA trong PKI. Windows Server 2008 hỗ trợ các vai trò sau theo định nghĩa của Common Criteria:

  • CA Administrator: đảm trách việc quản lý cấu hình của máy CA, bao gồm định nghĩa các thiết lập, thuộc tính của CA và chỉ định ai làm Certificate Manager. Vai trò này được giao phó cho người dùng thông qua việc gán giấy phép (permission) Manage CA cho người dùng đó tại CA.
  • Certificate Manager: còn được gọi là CA Officer, đảm trách việc quản lý chứng chỉ, bao gồm thu hồi, cấp phát, xóa bỏ chứng chỉ. Ngoài ra, Certificate Manager có thể trích xuất các khóa bí mật được lưu trữ cho việc khôi phục bởi một key recovery agent. Vai trò này được giao phó cho người dùng thông qua việc gán giấy phép Issue and Manage cho người dùng đó tại CA.
  • Backup Operator: đảm trách việc sao lưu và khôi phục cơ sở dữ liệu và các thiết lập cấu hình của CA. Vai trò này được giao phó cho người dùng thông qua việc gán quyền (user right) Back Up Files and Directories hoặc Restore Files and Directories trong GPO được gán cho CA hoặc trong Local Security Policy của CA.
  • Auditor: đảm trách việc chỉ định các sự kiện nào tại CA sẽ được giám sát và ghi nhận cũng như có quyền xem lại trong mục Security Log các sự kiện liên quan tới hoạt động của quản lý PKI. Vai trò này được giao phó cho người dùng thông qua việc gán quyền Manage Auditing and Security Log trong GPO hoặc trong Local Security Policy của CA.

Mỗi CA có thể có các người dùng khác nhau đảm trách các vai trò trên. Khi tuân thủ việc phân tách vai trò theo Common Criteria thì một người dùng chỉ có thể nắm giữ một trong bốn vai trò.

2.   Giảm thiểu rủi ro CA ngưng hoạt động

Trong thiết kế hạ tầng PKI có thể bao gồm một vài biện pháp để ngăn chặn hoặc giảm thiểu khả năng dịch vụ Certificate Services ngưng hoạt động. Ví dụ, ta có thể gom nhóm (cluster) các máy Windows Server 2008 làm Issuing CA để mang lại độ sẵn sàng cao cho dịch vụ của các CA quan trọng này. Ngoài ra, nếu coi sự cố liên quan tới đĩa cứng là rủi ro lớn nhất thì có sử dụng công nghệ RAID 5 hoặc RAID 0+1 để lưu trữ cơ sở dữ liệu của CA giúp đảm bảo hiệu năng và thời gian khôi phục nhanh nhất trong trường hợp lỗi ổ đĩa. Tương tự, các tập tin chứa nhật ký hoạt động của CA có thể được đặt trên mảng đĩa RAID 1. Cũng cần đảm bảo rằng các phân vùng của ổ đĩa đủ lớn để lưu trữ nhiều chứng chỉ trong tương lai.

Các yêu cầu về phần cứng dành cho offline CA thì thấp hơn Issuing CA. Ví dụ, Hình 1 dưới đây thể hiện hai cấu hình đĩa cứng có thể được áp dụng cho offline CA giúp tăng khả năng phục hồi và giảm thiểu chi phí.

 

Hình 1 – Cấu hình đĩa cứng nên dùng cho offline CA

Ở cấu hình bên trái, có hai mirror set tách biệt, một dùng để chứa hệ điều hành và một dùng để lưu CSDL và nhật ký của CA. Còn ở cấu hình bên phải, chỉ một mirror set gồm hai phân vùng: phân vùng C dành cho hệ điều hành, và phân vùng D dành cho CSDL và nhật ký của CA.

Đối với online CA, hoạt động của Certificate Services phát sinh nhiều dữ liệu cần lưu trên ổ đĩa hơn offline CA. Thường nên kết hợp RAID 1 và RAID 5 hoặc RAID 0+1 như được thể hiện trong Hình 2 dưới đây:

Hình 2 – Cấu hình đĩa cứng nên dùng cho online CA

Ở phía bên trái, có hai hệ thống RAID 1: một cho ổ C chứa hệ điều hành và một cho ổ D chứa các tập tin nhật ký của CA. Còn CSDL của CA được lưu trên hệ thống RAID 5. Cấu hình này mang lại hiệu suất đọc/ghi vào CSDL cao và tăng độ an toàn cho dữ liệu của hệ điều hành và nhật ký của CA.

Ở phía bên phải, vẫn là hai hệ thống RAID 1 chứa hệ điều hành và nhật ký của CA. Còn CSDL của CA được lưu trên hệ thống RAID 0+1. Cấu hình này mang lại tỉ lệ nhập/xuất dữ liệu cao hơn RAID 5 và thường được dùng bởi các CA cần đáp ứng nhu cầu xin cấp chứng chỉ lớn.

3.   Xác định thời gian hiệu lực của chứng chỉ

Mỗi chứng chỉ luôn có một khoảng thời gian hiệu lực nhất định gồm ngày giờ phát hành và ngày giờ hết hạn. Giá trị này là không thể thay đổi sau khi chứng chỉ được cấp. Việc xác định thời gian hiệu lực của chứng chỉ tại mỗi tầng trong hệ thống phân cấp CA là bước chính yếu trong quá trình thiết kế một hạ tầng PKI.

Đầu tiên là cần xác định thời gian hiệu lực của chứng chỉ được cấp cho các đối tượng đầu cuối như người dùng, máy tính, dịch vụ, thiết bị mạng trước. Lý do là vì CA không được phép cấp một chứng chỉ có thời hạn vượt quá thời gian hiệu lực của chứng chỉ của CA. Ví dụ, chứng chỉ của CA có thời hạn là 5 năm, thì chứng chỉ của người dùng phải có thời hạn là dưới 5 năm. Nếu không tuân theo nguyên tắc này thì dẫn đến chứng chỉ của người dùng tuy vẫn còn hiệu lực nhưng lại không thể sử dụng được do thời hạn của chứng chỉ của CA đã hết. Khuyến cáo thường được áp dụng là chứng chỉ của CA có thời hạn gấp đôi thời hạn tối đa của chứng chỉ mà nó cấp cho CA cấp dưới hoặc cho người dùng. Hình 3 dưới đây là ví dụ của một hệ thống CA phân cấp gồm 2 tầng với chứng chỉ được cấp cho người dùng có thời hạn tối đa là 5 năm (thực tế thường là 1 hoặc 2 năm), chứng chỉ của Policy/Issuing CA có thời hạn là 10 năm và 20 năm cho chứng chỉ của Root CA.

Hình 3 – Xác định thời gian hiệu lực của chứng chỉ của CA

Một khuyến cáo khác là nên làm mới (khôi phục lại thời hạn) chứng chỉ của CA khi thời gian hiệu lực của nó trôi qua được một nửa. Đối với cặp khóa công khai – bí mật đi kèm với chứng chỉ của CA thì có 2 phương án xử lý là:

  • Khi thời hạn hiệu lực trôi qua được một nửa thì làm mới lại chứng chỉ nhưng vẫn giữ nguyên cặp khóa cũ. Sau khi nửa thời hạn còn lại trôi qua thì cũng làm mới lại chứng chỉ nhưng kèm với cặp khóa mới.
  • Luôn đổi cặp khóa sau mỗi lần làm mới chứng chỉ. Ví dụ, nếu thời hạn của chứng chỉ là 10 năm thì cứ sau 5 năm sẽ đổi sang cặp khóa mới.

Ngoài ra, cũng không nên chọn chứng chỉ có thời hạn quá lâu vì sẽ làm tăng cơ hội để kẻ tấn công có thể tìm được khóa bí mật dựa trên khóa công khai và các mẫu dữ liệu được mã hóa bởi khóa bí mật. Thường thì chứng chỉ của Root CA không nên có thời hạn lâu hơn 20 năm.

4.   Chọn chiều dài cho khóa

Hạn chế lớn nhất khi xác định chiều dài cho khóa tại mỗi CA nằm ở các ứng dụng sử dụng chứng chỉ do CA cấp. Cụ thể, một số ứng dụng không hỗ trợ khóa có chiều dài lớn hơn một giá trị nào đó. Ví dụ, thiết bị Cisco VPN 3000 không hỗ trợ chứng chỉ của CA có chiều dài khóa lớn hơn 2048 bit.

Trong quá khứ, các khóa có chiều dài dưới 1024 bit (512, 768) từng bị phá mã thành công. Vì vậy mà nên chọn chiều dài cho khóa từ 1024 trở lên là an toàn.

5.   Xác định các điểm phát hành CRL và chứng chỉ của CA

Yêu cầu kỹ thuật cuối cùng cần được thỏa mãn khi thiết kế PKI là xác định các địa chỉ URL cho việc nhận về CRL, chứng chỉ của CA và các OCSP response.

Để xác định trạng thái thu hồi của chứng chỉ thì máy khách có thể sử dụng các URL được lưu trong trường CDP (nếu dùng CRL để kiểm tra) và extension AIA (nếu dùng OCSP kiểm tra). Ngoài ra, một số ứng dụng sử dụng danh sách thu hồi được lưu trên hệ thống tập tin cục bộ hoặc dùng các URL dẫn tới CRL và chứng chỉ của CA được lập trình cứng (hard-code) cho nó.

Tại mỗi CA, các giao thức sau có thể được dùng để định nghĩa các điểm phát hành mà máy khác sẽ truy cập tới khi cần tới chứng chỉ của CA và CRL:

  • HTTP: được dùng cho các điểm phát hành dùng cho nội bộ và bên ngoài. Ưu điểm của HTTP là thời gian trễ thấp từ lúc phát hành tới khi URL đó có thể được dùng. Sau khi phát hành một bản cập nhật của CRL hoặc chứng chỉ của CA bằng HTTP thì ngay lập tức ứng dụng đã có thể tải nó về. Ngoài ra, thì HTTP thường không bị firewall chặn và các máy chạy Windows (nằm trong AD DS hoặc không), MAC OS hay Unix đều dùng được URL dạng này.
  • LDAP: CRL hoặc chứng chỉ của CA được phát hành dùng LDAP URL sẽ hiện diện tại tất cả các domain controller trong forest. Điều này có hai bất lợi là:
    • Mất một khoảng thời gian để CRL và chứng chỉ của CA được sao chép  tới tất cả các domain controller trong forest. Thời gian chính xác phụ thuộc vào độ trễ của mạng và đặc biệt nếu sự sao chép diễn ra giữa các domain controller nằm ở các site khác nhau thì càng lớn.
    • Máy khách không nằm trong AD DS sẽ không thể sử dụng LDAP URL và nếu nó là URL đầu tiên trong danh sách thì phải mất 10 giây để có thể chuyển sang sử dụng URL tiếp theo.

Quyết định sử dụng giao thức nào phụ thuộc vào tần suất phát hành CRL, giao thức đó có được phép đi qua firewall mạng hay không, và hệ điều hành được hỗ trợ. Để độ trễ là thấp nhất, các URL nên được sẵn xếp để giao thức phổ biến nhất trong mạng được dùng để truyền tải CRL và chứng chỉ của CA nằm ở đầu danh sách trong extension CDP.

–manthang

6 comments

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s