Software Restriction Policies (SRP) cho các máy tính client

Chia sẻ: Rer Erer | Ngày: | Loại File: PDF | Số trang:20

Thêm vào BST

Báo xấu

168
lượt xem 9
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Software Restriction Policies (SRP) cho các máy tính client .Từ khi có Windows XP, các quản trị viên trên toàn thế giới đã có được nhiều tùy chọn để định nghĩa Software Restriction Policies (SRP) cho các máy tính client của họ nhằm mục đích kiểm soát những phần mềm nào được phép, phần mềm nào không được phép chạy. Trên thực tế có quá ít tổ chức bổ sung chức năng này mặc dù nó có thể mang lại một mức bảo mật rất cao nếu được thiết lập đúng cách. Trong phần thứ hai của bài này chúng ta...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Software Restriction Policies (SRP) cho các máy tính client

Software Restriction Policies (SRP) cho các máy tính client
Từ khi có Windows XP, các quản trị viên trên toàn thế giới đã có được nhiều tùy chọn để định nghĩa Software Restriction Policies (SRP) cho các máy tính client của họ nhằm mục đích kiểm soát những phần mềm nào được phép, phần mềm nào không được phép chạy. Trên thực tế có quá ít tổ chức bổ sung chức năng này mặc dù nó có thể mang lại một mức bảo mật rất cao nếu được thiết lập đúng cách. Trong phần thứ hai của bài này chúng ta sẽ xem xét cách bổ sung những gì đã đề cập đến như “các chính sách lọc phần mềm”. Vùng nguy hiểm Trước khi bắt đầu chúng tôi cần phải chỉ ra một số điểm quan trọng trước khi giới thiệu SRP trên các máy tính đó là các bạn nên lập kế hoạch và kiểm tra chúng một cách triệt để. Điều này có thể được thực hiện trong Active Directory (AD) bằng cách cô lập máy tính kiểm tra hoặc đối tượng người dùng trong Organizational Unit (OU), hoặc bằng việc thiết lập sự cho phép “Apply Group Policy” trên Group Policy Object (GPO) đối với máy tính kiểm tra hoặc tài khoản người dùng. SRP thậm chí còn có thể được sử dụng trên các máy tính đứng độc lập nếu bạn không muốn đụng chạm đến môi trường sản xuất một chút nào. Ở đây chúng tôi khuyên bạn nên sử dụng các máy ảo để thực hiện những bài kiểm tra cơ bản và các máy tính ‘như sản
xuất’ cho các bài test cuối cùng. Sau quá trình kiểm tra, SRP nên được thực thi trên người dùng thí điểm trong các nhóm – tốt hơn là sử dụng đến các bước nhỏ hơn là vội vàng lao vào ‘thảm họa’!. Toàn bộ quá trình Các lỗi trong thiết kế hoặc bổ sung của toàn bộ quá trình có thể gây ra một sự thất vọng lớn đối với người dùng, và thậm chí mất cả tiền bạc và năng xuất, vì vậy nên coi chừng khi bạn thực hiện công việc này. Quá trình này cần đến rất nhiều kế hoạch công việc, kiểm tra và có thể là một số bảo trì hàng ngày được đưa vào trong môi trường sản xuất. Danh sách dưới đây cho bạn thấy một một xem xét ngắn gọn về những gì phải có trong đầu khi đưa SRP vào trong môi trường Windows. Khi vô hiệu hóa cài đặt SRP, các quyết định khác phải được thực hiện như trong ví dụ dưới đây: Quyết định giữa người dùng và GPOs máy tính: Các chính sách SRP  nên áp dụng các đối tượng AD gì? Quyết định giữa danh sách đen Blacklisting (BL) và danh sách trắng  Whitelisting (WL) (phương pháp WL được khuyến khích nếu có)
Nếu sử dụng phương pháp BL, bạn phải tạo một danh sách các thành  phần bị từ chối. Nếu sử dụng phương pháp WL, bạn phải tạo một danh sách các thành  phần được sử dụng. Quyết định sử dụng các tùy chọn SRP nào (sự ép buộc, chỉ định các  kiểu file, các ngoại lệ quản trị viên…) Quyết định xem loại nguyên tắc nào sẽ sử dụng (đường dẫn-path,  HASH, chứng chỉ-certificate hay vùng Internet - Internet zone) Khi kiểm tra thiếp lập SRP, các bước khác nhau phải được thực hiện, ví dụ như: Kiểm tra chức năng cơ bản trong thư viện ảo (sử dụng Virtual  PC/Server, Vmware hoặc tương tự như vậy) Kiểm tra chức năng trong môi trường của bạn bằng các máy tính “như  sản xuất” (và các tài khoản người dùng). Kiểm tra với các nhóm nhỏ người dùng dẫn đường trong các bước 5-10  một vài tuần, sau đó tăng lên. Tiếp tục với nhóm dẫn đường tiếp theo sau khi bổ sung thành công cho  những người dùng dẫn đường trước đó.
Bảo đảm kiểm tra tất cả các kiểu khác người dùng khác và các kiểu  máy tính khác nhau mà bạn cần bảo đảm với SRP. Bảo đảm kiểm tra việc cập nhật các kịch bản giống như việc vá hệ điều  hành, nâng cấp các ứng dụng của nhóm thứ ba,… Tập trung vào hiệu suất trên phần cứng khác nhau trong tổ chức của  bạn. Việc bổ sung thêm SRP sẽ ảnh hưởng ít nhiều đến hiệu suất hệ thống, ảnh hưởng này phụ thuộc vào cách nó được bổ sung. Đôi khi các ứng dụng này lại khởi chạy các ứng dụng khác, hãy bảo  đảm rằng điều này được kiểm soát chặt chẽ. Mặc định các shortcut Desktop và Start Menu (.LNK) đều bị khóa, hãy  thay đổi chúng nếu cần thiết. Bảo đảm rằng bất kỳ kịch bản quản trị nào (ví dụ như kịch bản đăng  nhập trong SYSVOL/NETLOGON) cũng đều hoạt động tốt. Trước khi đưa SRP vào, một số thủ tục cần phải được xem xét: Giới thiệu luồng công việc về làm thế nào các ứng dụng, nâng cấp phải  được kiểm tra, cho phép và được đưa vào trên mạng, chính vì vậy mọi người mới biết được về sự cần thiết của các thủ tục.
Bảo đảm rằng nhà quản lý biết các chuyên gia và nhà nghiên cứu SRP  mà họ đồng ý quyết định để giới thiệu nó. Phải có kế hoạch phản hồi thông tin để loại bỏ những SRP GPO nhanh  chóng cho người dùng, nhóm, các máy tính hay trang nào đó,… Đào tạo người dùng: thông báo cho người dùng rằng tại sao SRP là  quan trọng và những thủ tục nào để có được phần mềm mới Các đường dẫn khác đến SRP Việc cấu hình chính sách hạn chế phần mềm Software Restriction Policy cơ bản dựa vào các bước dưới đây: 1. Tạo một User hoặc một Computer GPO và định vị nó trên Site, Domain hoặc OU (hoặc như một chính sách cục bộ) và kích hoạt SRP bên trong Group Policy. Các thiết lập SRP được đặt ở đây (xem hình 1): Computer Configuration| Windows Settings | Security Settings | Software Restriction Policies User Configuration | Windows Settings | Security Settings | Software Restriction Policies
Đầu tiên SRP được đưa vào trong FPO, tùy chọn “New Software Restriction Policies” sẽ được cung cấp. Hình 1 2. Thiết lập Default Security Level. Hình 2 thể hiện mức được thiết lập như thế nào bằng việc kích chuột phải vào mức bạn muốn và chọn “Set as default”. Mức mặc định là ‘Unrestricted’ có nghĩa là tất cả phần mềm có o thể chạy và các nguyên tắc bổ sung cho phần mềm không được phép vô hiệu hóa được tạo ra – điều này cũng được biết đến như danh sách đen Blacklisting.
Mức bảo vệ tốt nhất là ‘Disallowed’ có nghĩa là không có phần o mềm nào có thể chạy và các nguyên tắc bổ sung thêm cho phần mềm được phép được tạo ra – điều này có thể được hiểu đến như là danh sách trắng Whitelisting. Mặc định, hệ thống tạo một số nguyên tắc cho phép hệ điều hành o chạy mà không cần bất kỳ việc khóa không thuận tiện nào. Nếu các nguyên tắc đó được gỡ bỏ hoặc thay đổi không mà suy nghĩ thì sẽ có thể làm cho hệ thống không thể sử dụng được. Hình 2 3. Với Windows Vista và Longhorn chúng ta có thêm một mức mới đó là ‘Basic User’, mức này cho phép các chương trình có thể thực thi như
một người dùng không có quyền truy cập quản trị viên, vì vậy người dùng có thể truy cập vào tài nguyên chỉ bằng chế độ thông thường dành cho người dùng. Các loại file có thể được gỡ bỏ hoặc được bổ sung để hợp với bất kỳ môi trường nào nhưng danh sách kiểu file mặc định chung nhất gồm có: BAT, CMD, COM, EXE, HTA, LNK, MSI, OCX, PIF, REG & SCR và thêm vào đó là: ADE, ADP, BAS, CHM, CPL, CRT, HLP, INF, INS, ISP, MDB, MDE, MSC, MSP, MST, PCD, SHS, URL, VB & WSC. Lưu ý: Trạng thái hộp thoại Designated Files Type Properties có đoạn “in addition to the standard program file types, such as EXE, DLL and VBS” –tôi đã không thể có được toàn bộ danh sách nhưng vẫn còn xác nhận rằng VBS, VBE, JS và JSE sẽ được khóa thậm chí chúng không có trong danh sách. Theo chúng tôi, ở đây nếu tốt hơn sẽ là một danh sách đơn để các quản trị viên trên khắp thế giới có thể thay đổi nếu cần thiết.
Hình 3 4. Thiết lập exceptions đối với Default Security Level. Chúng được biết đến như là các nguyên tắc bổ sung ‘Additional Rules’. Bạn có thể xem thêm phần ‘các nguyên tắc bổ sung ‘Additional Rules’’ để có thêm thông tin chi tiết. 5. Cấu hình ‘Enforcement Properties’. Xem hình 4, gồm có: “All software files”: Chúng ta có tùy chọn để kiểm tra DLL’s o (Dynamic Link Libraries) (Thư viện liên kết động) khi chúng
cũng được thực thi. Điều này không mặc định thiết lập và có sẽ một số ảnh hưởng đến cả hiệu suất và các nhiệm vụ lập kế hoạch/ bổ sung/ bảo trì. “All users except local administrators”: Ở đây chúng ta có thể o chọn nên áp dụng SRP cho các quản trị viên cục bộ hay không. Mặc định tất cả người dùng đều phải bị tìm ra bởi SRP. Tùy chọn chính sách này chỉ liên quan đến các chính sách máy tính. “Enforce certificate rules”: Tùy chọn để chọn xem có nên sử o dụng các nguyên tắc chứng chỉ hay không. Lưu ý rằng: trạng thái trong hộp thoại hình 4 “Certificate rules will negatively impact the performance of your machine” có nghĩa là các nguyên tắc chứng chỉ sẽ ảnh hưởng xấu đến hiệu suất của máy.
Hình 4 6. Cấu hình ‘Trusted Publishers Properties’, cấu hình này được biết đến như các tùy chọn chính sách thẩm định (xem hình 5). Trong hộp thoại này chúng ta có thể chọn ra ai có thể chọn Trusted Publishers đối với các nguyên tắc chứng chỉ.
Hình 5 Các nguyên tắc bổ sung Khi cấu hình các nguyên tắc bổ sung, làm thế nào để nhận ra phần mềm được quyết định. Chúng ta có 4 phương pháp nhận dạng phần mềm khác nhau đó là: 1. Các nguyên tắc HASH
HASH là các dấu tay mật mã được duy trì không quan tâm đến tên file và vị trí. Nó đặc biệt tốt khi sử dụng WL, nhưng cũng không hiệu quả với BL (lý do cho điều này đã được giới thiệu trong nhiều bài báo): MD5 hoặc SHA-1 HASH đưa ra sự xác minh phần mềm file nhị phân ‘ProduKey.exe’, vì vậy nó cho phép một giá trị HASH cụ thể chạy để bảo đảm rằng chỉ phiên bản đó mới có thể thực thi. Mặc dù vậy việc không cho phép HASH cụ thể chỉ ảnh hưởng đến một phiên bản (hoặc sự biên dịch) của ứng dụng và một người dùng thông minh nào đó có thể thay đổi file này khá dễ dàng và nó sẽ được nhận diện như một phần mềm khác. Từ “unknown” rất quan trọng trong vấn đề này – nó thực sự là chìa khóa để quyết định giữa BL và WL – bạn muốn người dùng có thể thực thi phần mềm mà chúng ta không biết không? Không hay có? Nếu người dùng không thể chạy phiên bản cũ của một ứng dụng cụ thể, hãy cho rằng nó đã bị hỏng và gây ra sự hỏng hóc hệ thống của bạn, sử dụng nguyên tắc hạn chế giá trị HASH này sẽ là một quyết định tốt. Các bạn cũng nên lưu ý rằng một phiên bản mới của ứng dụng nhất
định sẽ luôn trả về một giá trị HASH mới được phép hoặc không được phép. 2. Các nguyên tắc chứng chỉ Các nguyên tắc chứng chỉ sử dụng HASH đã đánh dấu và cung cấp sự xác minh phần mềm mạnh, tuy nhiên khi chúng ta tin tưởng vào một chứng chỉ nhất định thì sẽ thực sự tin tưởng vào tất cả các phần mềm được gán với chứng chỉ cụ thể đó. Điều này có thể là một việc tốt hoặc xấu. Nó có thể là tốt cho nếu chúng ta có một ứng dụng từ nhóm thứ ba, ai đó đã đánh dấu tất cả các file quan trọng trong ứng dụng (có thể gồm có các DLL), vì vậy thay vì tạo một số các nguyên tắc HASH thì chúng ta chỉ cần tạo một nguyên tắc đơn đã tin tưởng chứng chỉ và chạy nó. Tuy nhiên liệu chúng ta có nên tin tưởng tuyệt đối vào chứng chỉ số được sử dụng để làm dấu hiệu ở một số công cụ từ Microsoft (hoặc từ các nhóm thứ ba) – bây giờ người dùng có thể chạy tất cả các ứng dụng đã đánh dấu bằng chứng chỉ cụ thể đó… Rõ ràng vấn đề ở đây là làm sao biết được chính xác ứng dụng gì đã được đánh dấu bằng chứng chỉ đó? Không có thông tin đó chúng ta sẽ không thể biết được
những gì được phép. Thay vì cho phép ứng dụng đơn lẻ cần cho người dùng, chúng ta có thể cho phép hàng trăm ứng dụng đến từ các hãng có thể chạy trên hệ thống của chúng ta. Kiểm tra các nguyên tắc chứng chỉ có thể được thực hiện bằng sử dụng các công cụ: File Signing Tool (Signcode.exe) & Certificate Creation Tool (Makecert.exe). 3. Các nguyên tắc đường dẫn Nguyên tắc này là nguyên tắc chung nhất và dễ dàng nhất mà chúng ta có. Nguyên tắc này có thể từ chối hoặc cho phép một file trên một vị trí cụ thể (ví dụ “C:\Scripts\Script.VBS”), một tên file (ví dụ “Script.VBS”), một thư mục (ví dụ “C:\Scripts”), một đường dẫn UNC (ví dụ “\\SERVER\SHARE\File.VBS”) hoặc một đường dẫn registry (“%[Registry Hive]\[Registry Key Name]\[Value Name]%”). Các nguyên tắc này có thể sử dụng trong các biến môi trường ( “%WINDIR%”) và thay thế ‘?’ = một ký tự (ví dụ “\\SERVER??\Share\Script.VBS”) và ‘*’ = một cụm ký tự (ví dụ “*.VBS”).
Nếu bạn đang sử dụng nguyên tắc này, một số thứ cần phải quan tâm đó là: Nếu đường dẫn thư mục được thiết lập thì điều này cũng ảnh o hưởng đến tất cả các thực thi có thể trong các thư mục con. Nếu người dùng có quyền ghi lên thư mục được thiết lập o Unrestricted, thì cũng có thể copy bất kỳ file nào đến thư mục đó và thực thi nó từ đó. Trong thiết kế phải thận trọng đối với vấn đề này, có lẽ bằng cách đưa vào các thiết lập ACL (Access Control List) bởi sử dụng Group Policy. Nếu người dùng có quyền ghi lên lên một thực thi được chỉ định o là Unrestricted thì người dùng này hoàn toàn có thể ghi đè thực thi đó lên người dùng khác để làm hỏng SRP. Nếu một đường dẫn thư mục có các biến môi trường như o %TEMP%, thậm chí một người dùng hạn chế có thể thay đổi các biến môi trường người dùng bằng sử dụng lệnh SET cho đường dẫn khác (SET TEMP=C:\MyFolder) – thì điều này rất có thể dẫn đến việc tình cờ người dùng có thể kiểm soát phần
mềm nào đó có thể được chạy bằng cách copy thực thi hoặc kịch bản đến đường dẫn đó. Như phần trên, người dùng có thể thử thay đổi tên hoặc chuyển các file không được phép – hoặc ghi đè lên các file không bị hạn chế để làm hỏng SRP – điều này giải thích lý do tại sao HASH hay các nguyên tắc chứng chỉ thường được xem là sự lựa chọn tốt nhất. 4. Vùng Internet Các vùng bảo mật Internet Explorer có thể được sử dụng để kiểm soát sự cài đặt phần mềm và chỉ áp dụng cho các gói Windows Installer (.MSI) được chạy từ một trong những vùng Internet mặc định. Các nguyên tắc đó không thường được sử dụng. Khi nhiều nguyên tắc được sử dụng chúng sẽ được đánh giá để phù hợp với những gì ở trên, nguyên tắc mặc định sẽ được đánh giá như nguyên tắc cuối cùng – tương xứng nhất sẽ được ưu tiên. Các hạn chế của SRP
Một số hạn chế của SRP phải được xem xét. Phạm vi của SRP không dành cho tất cả các hệ điều hành như bạn mong đợi. SRP không áp dụng cho các phần dưới đây: Các driver hoặc phần mềm chế độ nhân khác được cài đặt  Bất kỳ chương trình nào được cài đặt bởi tài khoản SYSTEM cục bộ  Các macro bên trong tài liệu Microsoft Office (chúng ta có nhiều cách  để khóa chúng bằng sử dụng các chính sách nhóm) Các chương trình được viết cho ngôn ngữ chung (các chương trình này  sử dụng chính sách bảo mật truy cập mã). Kết luận SRP đòi hỏi phải tốn nhiều thời gian, luồng công việc và các nâng cấp, nhưng bên cạnh đó nó mang đến cho các bạn một mức bảo mật cao hơn so với thiết lập mặc định cho phép. Một số môi trường có thể không phù hợp với SRP nhưng phỏng đoán của chúng tôi là hầu hết các mạng đều có nhiều máy tính và người dùng công nghệ SRP là chính xác. Cần phải tạo quyết định, tìm hiểu và làm việc một cách chăm chỉ để bổ sung chính sách từ chối mặc định này, điều đó cũng là lý do tại sao nó ít khi được
sử dụng… Tuy nhiên có một điều rõ ràng ở đây là khi bổ sung các chính sách theo đúng cách sẽ bảo đảm cho các quản trị viên mạng có thể ngủ ngon hơn.