1.1 Xử lý bảo mật bộ thực thi bằng chính sách bảo mật của miền ứng dụng V V Bạn cần kiểm soát (bằng mã lệnh) các quyền được cấp cho các assembly. # # Cấu hình (bằng mã lệnh) chính sách bảo mật của miền ứng dụng mà bạn đã nạp các assembly vào đó. Chính sách bảo mật (security policy) bao gồm bốn mức chính sách: công ty (enterprise), máy (machine), người dùng (user), và miền ứng dụng (application domain). Bộ thực thi quyết định những quyền nào để cấp cho một assembly bằng cách xác định tập quyền được cấp bởi mỗi mức chính sách rồi tính phép giao (phép AND luận lý) c ủa bốn tập quyền. Các quyền nằm trong tập giao là grant-set cuối cùng của assembly. # Ngay cả khi các mức chính sách công ty, máy, hay người dùng chỉ định code group LevelFinal (chỉ thị bộ thực thi không đánh giá các mức chính sách thấp hơn), bộ thực thi luôn sử dụng mức chính sách của miền ứng dụng để tính grant-set của một assembly. Chỉ các mức chinh sách công ty, máy, và người dùng là được cấu hình tĩnh bằng Administrative Tools. Vì miền ứng dụng không tồn tại bên ngoài ngữ cảnh của bộ thực thi nên không thể cấu hình tĩnh chính sách miền ứ ng dụng được. Để cấu hình chính sách bảo mật của một miền ứng dụng, bạn phải tạo một mức chính sách (bằng mã lệnh) rồi gán nó cho miền ứng dụng. Xây dựng một mức chính sách bằng mã lệnh có thể là một công việc lâu dài, tùy thuộc vào độ phức tạp của chính sách bảo mật mà bạn cần diễn tả. Lớp System.Security.Policy.PolicyLevel mô tả một mức chính sách bảo mật. Bên trong m ỗi đối tượng PolicyLevel, bạn phải tạo dựng một cấu trúc phân cấp các code group, định nghĩa các điều kiện thành viên, các tập quyền, và các đặc tính của mỗi code group. Có rất nhiều kiểu được sử dụng để tạo dựng mức chính sách, và thảo luận về các kiểu này là vượt quá phạm vi quyển sách này. Lập trình bảo mật .NET, như đã đề cập trước đây, cung cấp thông tin chi tiế t về mỗi lớp này và trình bày cách xây dựng một mức chính sách bằng mã lệnh. Í Thông thường, bạn sẽ phát triển một công cụ trợ giúp việc tạo một mức chính sách và ghi định nghĩa mức chính sách ra file; sau đó, bạn có thể nạp định nghĩa này từ đĩa khi cần. Lớp PolicyLevel có hai phương thức nhằm đơn giản hóa quá trình này: ToXml đưa một đối tượng PolicyLevel về dạng dễ lưu trữ, và FromXml xây dựng lại một đối tượng PolicyLevel từ dạng đã được lưu tr ữ. Một khi đã có đối tượng PolicyLevel mô tả chính sách bảo mật như mong muốn, bạn có thể gán nó cho một miền ứng dụng. Thu lấy tham chiếu System.AppDomain đến miền ứng dụng mà bạn muốn cấu hình, và truyền đối tượng PolicyLevel cho phương thức AppDomain.SetAppDomainPolicy. Mã lệnh của bạn phải có phần tử ControlDomainPolicy của SecurityPermission thì mới có thể gọi SetAppDomainPolicy. Bạn chỉ có thể gọi SetAppDomainPolicy một lần trên mỗi miền ứng dụng; nếu bạn gọi SetAppDomainPolicy lần thứ hai, nó sẽ ném ngoại lệ System.Security.Policy.PolicyException. Bạn không phải gán đối tượng PolicyLevel cho một miền ứng dụng trước khi nạp các assembly vào miền ứng dụng này. Các assembly được nạp trước khi bạn thiết lậ p chính sách bảo mật miền ứng dụng có các grant-set chỉ dựa trên các mức chính sách: công ty, máy, và người dùng. Chính sách miền ứng dụng chỉ áp dụng cho các assembly được nạp sau khi nó được cấu hình. Thông thường, bạn sử dụng khả năng này để nạp các assembly chia sẻ đáng-tin-cậy vào miền ứng dụng mà không bị ràng buộc bởi chính sách miền ứng dụng. Ứng dụng dưới đây trình bày quá trình tạo một mức chính sách và gán nó cho một miền ứ ng dụng. Mức chính sách này cấp các quyền dựa trên publisher của một assembly— được thể hiện trong các khoản của chứng cứ System.Security.Policy.Publisher. using System; using System.Security; using System.Security.Policy; using System.Security.Cryptography.X509Certificates; public class AppDomainPolicyExample { public static void Main() { // Tạo một miền ứng dụng mới (để nạp các assembly vào đó). AppDomain domain = AppDomain.CreateDomain("modules"); // Nạp các assembly vào miền ứng dụng mà bạn không muốn // bị ràng buộc bởi chính sách bảo mật miền ứng dụng. § // Cấu hình chính sách bảo mật cho đối tượng AppDomain. SetDomainPolicy(domain); // Nạp các assembly vào miền ứng dụng được bảo vệ. § } // Phương thức này cấu hình chính sách bảo mật của đối tượng // AppDomain được truyền cho nó. Chính sách bảo mật sẽ gán các // quyền khác nhau cho mỗi assembly dựa trên publisher của // assembly. Những assembly từ các publisher vô danh không được // cấp quyền nào cả. private static void SetDomainPolicy(AppDomain domain) { // Tạo một PolicyLevel mới cho miền ứng dụng. PolicyLevel policy = PolicyLevel.CreateAppDomainLevel(); // Tạo một FirstMatchCodeGroup mới dùng làm nút gốc của hệ // thống phân cấp code group. Cấu hình group này sao cho // nó trùng khớp với tất cả code. Điều này nghĩa là t ất cả // các assembly đều khởi đầu với một grant-set rỗng cho // mức chính sách miền ứng dụng. policy.RootCodeGroup = new FirstMatchCodeGroup( new AllMembershipCondition(), new PolicyStatement(policy.GetNamedPermissionSet("Nothing")) ); // Tạo tập các code group để xác định các quyền nào sẽ được cấp // cho một assembly do một publisher tạo ra. Vì code group gốc // là một FirstMatchCodeGroup, nên quá trình phân giải chính sách // chỉ so trùng assembly trên các group con cho đến khi tìm thấy // trùng khớp đầu tiên. Mỗi code group được tạo với đặc tính // Exclusive để bảo đảm rằng assembly không lấy thêm quyền // nào từ các code group khác. // Tạ o code group cấp tập quyền FullTrust cho các // assembly được phát hành bởi Microsoft. X509Certificate microsoftCert = X509Certificate.CreateFromCertFile("microsoft.cer"); policy.RootCodeGroup.AddChild(new UnionCodeGroup( new PublisherMembershipCondition(microsoftCert), new PolicyStatement(policy.GetNamedPermissionSet("FullTrust"), PolicyStatementAttribute.Exclusive) )); // Tạo code group cấp tập quyền Internet cho các // assembly được phát hành bởi Litware, Inc. X509Certificate litwareCert = X509Certificate.CreateFromCertFile("litware.cer"); policy.RootCodeGroup.AddChild(new UnionCodeGroup( new PublisherMembershipCondition(litwareCert), new PolicyStatement(policy.GetNamedPermissionSet("Internet"), PolicyStatementAttribute.Exclusive) )); // Tạo code group cấp tập quyền Execution cho các // assembly được phát hành bởi Fabrikam, Inc. X509Certificate fabrikamCert = X509Certificate.CreateFromCertFile("fabrikam.cer"); policy.RootCodeGroup.AddChild(new UnionCodeGroup( new PublisherMembershipCondition(fabrikamCert), new PolicyStatement(policy.GetNamedPermissionSet("Execution"), PolicyStatementAttribute.Exclusive) )); // Thêm một code group sau cùng để bắt tất cả các assembly // không khớp với publisher nào. Gán group này với tập quyền // Nothing. Vì group này là Exclusive nên assembly sẽ không // nhận quyền nào từ các group khác, ngay cả từ các // mức chính sách cao hơn (công ty, máy, và người dùng). policy.RootCodeGroup.AddChild(new UnionCodeGroup( new AllMembershipCondition(), new PolicyStatement(policy.GetNamedPermissionSet("Nothing"), PolicyStatementAttribute.Exclusive) )); // Gán chính sách cho miền ứng dụng. domain.SetAppDomainPolicy(policy); } } 1.2 Xác định người dùng hiện hành có là thành viên của một nhóm Windows nào đó hay không V V Bạn cần xác định người dùng hiện hành của ứng dụng có phải là thành viên của một nhóm người dùng Windows nào đó hay không. # # Thu lấy đối tượng System.Security.Principal.WindowsIdentity mô tả người dùng hiện hành bằng phương thức tĩnh WindowsIdentity.GetCurrent. Kế tiếp, truyền đối tượng WindowsIdentity cho phương thức khởi dựng của lớp System.Security.Principal.WindowsPrincipal để thu lấy đối tượng WindowsPrincipal. Cuối cùng, gọi phương thức IsInRole của đối tượng WindowsPrincipal để xác định người dùng này có nằm trong một nhóm Windows nào đó hay không. Cơ chế RBS của .NET Framework trừu tượng hóa các tính nă ng bảo mật dựa-trên-người- dùng của hệ điều hành nằm dưới thông qua hai giao diện chính sau đây: • System.Security.Principal.IIdentity • System.Security.Principal.IPrincipal Giao diện IIdentity mô tả thực thể mà mã lệnh hiện đang chạy trên danh nghĩa của thực thể này, chẳng hạn một người dùng hoặc tài khoản dịch vụ (service account). Giao diện IPrincipal mô tả IIdentity của thực thể và tập các vai trò mà thực thể này thuộc về. Một vai trò chỉ là một sự phân loại, dùng để nhóm các thực thể với các khả năng bảo mật tương tự nhau, chẳng hạn m ột nhóm người dùng Windows. Để tích hợp RBS với bảo mật người dùng Windows, .NET Framework cung cấp hai lớp sau đây (hiện thực giao diện IIdentity và IPrincipal): • System.Security.Principal.WindowsIdentity • System.Security.Principal.WindowsPrincipal Lớp WindowsIdentity hiện thực giao diện IIdentity và mô tả một người dùng Windows. Lớp WindowsPrincipal hiện thực IPrincipal và mô tả tập các nhóm Windows mà người dùng này thuộc về. Vì .NET RBS là một giải pháp chung được thiết kế sao cho độc lập nền, bạn không thể truy xuất các tính năng và các khả năng của tài khoản người dùng Windows thông qua giao diện IIdentity và IPrincipal, bạn phải sử dụng trực tiếp các đối tượng WindowsIdentity và WindowsPrincipal. Để xác định ngườ i dùng hiện hành có phải là thành viên của một nhóm Windows nào đó hay không, trước tiên bạn phải gọi phương thức tĩnh WindowsIdentity.GetCurrent. Phương thức này trả về một đối tượng WindowsIdentity mô tả người dùng Windows mà tiểu trình hiện đang chạy trên danh nghĩa của người dùng này. Kế tiếp, tạo một đối tượng WindowsPrincipal mới và truyền đối tượng WindowsIdentity cho phương thức khởi dựng. Cuối cùng, gọi phương thứ c IsInRole của đối tượng WindowsPrincipal để kiểm tra xem người dùng này có nằm trong một nhóm (vai trò) cụ thể nào đó hay không. IsInRole trả về true nếu người dùng này là thành viên của nhóm đã được chỉ định, ngược lại trả về false. # Bạn có thể thu lấy tham chiếu IPrincipal đến một đối tượng WindowsPrincipal bằng thuộc tính tĩnh CurrentPrincipal của lớp System.Threading.Thread. Tuy nhiên, kỹ thuật này tùy thuộc vào cấu hình chính sách principal của miền ứng dụng hiện hành; mục 13.14 sẽ thảo luận vấn đề này chi tiết hơn. Phương thức IsInRole có ba phiên bản nạp chồng: • Phiên bản thứ nhất nhận một chuỗi chứa tên của nhóm cần kiểm tra. Tên nhóm phả i có dạng [DomainName]\[GroupName] đối với các nhóm dựa-trên-miền và phải có dạng [MachineName]\[GroupName] đối với các nhóm được định nghĩa cục bộ. Nếu muốn kiểm tra tư cách thành viên của một nhóm Windows chuẩn, bạn hãy sử dụng dạng BUILTIN\[GroupName]. IsInRole thực hiện kiểm tra có phân biệt chữ hoa- thường đối với tên nhóm được chỉ định. • Phiên bản thứ hai nhận một s ố nguyên (int), số này chỉ định một Windows Role Identifier (RID). RID cung cấp một cơ chế để nhận biết các nhóm, không phụ thuộc vào ngôn ngữ (language) và sự bản địa hóa (localization). • Phiên bản thứ ba nhận một thành viên thuộc kiểu liệt kê System.Security.Principal.WindowsBuiltInRole. Kiểu liệt kê này định nghĩa các thành viên mô tả các nhóm Windows có sẵn. Bảng 13.3 liệt kê tên, RID, và giá trị WindowsBuiltInRole cho mỗi nhóm Windows chuẩn. Bảng 13.3 Tên, RID, và giá trị WindowsBuiltInRole của các tài khoản có sẵn Tên tài khoản RID (Hex) Giá trị WindowsBuiltInRole BUILTIN\Account Operators 0x224 AccountOperator BUILTIN\Administrators 0x220 Administrator BUILTIN\Backup Operators 0x227 BackupOperator BUILTIN\Guests 0x222 Guest BUILTIN\Power Users 0x223 PowerUser BUILTIN\Print Operators 0x226 PrintOperator BUILTIN\Replicators 0x228 Replicator BUILTIN\Server Operators 0x225 SystemOperator BUILTIN\Users 0x221 User [ # Lớp WindowsIdentity cung cấp các phương thức khởi dựng nạp chồng cho phép bạn thu lấy đối tượng WindowsIdentity mô tả một người dùng nào đó (khi chạy trên Microsoft Windows Server 2003 trở về sau). Bạn có thể sử dụng đối tượng này và phương pháp được mô tả trong mục này để xác định xem người dùng đó có phải là thành viên của một nhóm Windows nào đó hay không. Nếu bạn sử dụng một trong các phương thức khởi dựng này khi ch ạy trên một phiên bản Windows cũ, nó sẽ ném ngoại lệ System.ArgumentException. Trên các nền Windows trước Windows Server 2003, bạn phải sử dụng mã lệnh nguyên sinh (native code) để thu lấy Windows access token mô tả người dùng cần thiết. Kế đó, bạn có thể sử dụng access token này để tạo đối tượng WindowsIdentity; mục 13.15 sẽ trình bày cách thu lấy Windows access token cho những người dùng cụ thể. Ứng dụ ng WindowsGroupExample dưới đây trình bày cách kiểm tra người dùng hiện hành có là thành viên của một tập các nhóm Windows được nêu tên hay không. Các nhóm này được chỉ định trong các đối số dòng lệnh; bạn nhớ đặt tên máy tính, tên miền, hay BUILTIN (đối với các nhóm Windows chuẩn) vào trước tên nhóm. using System; using System.Security.Principal; public class WindowsGroupExample { public static void Main (string[] args) { // Thu lấy đối tượng WindowsIdentity // mô tả người dùng hiện hành. WindowsIdentity identity = WindowsIdentity.GetCurrent(); // Tạo đối tượng WindowsPrincipal mô tả các khả năng bảo mật // của đối tượng WindowsIdentity được chỉ định. WindowsPrincipal principal = new WindowsPrincipal(identity); // Duyệt qua các đối số dòng lệnh (tên nhóm) và kiểm tra xem // người dùng hiện hành có là thành viên của mỗi nhóm hay không. foreach (string role in args) { Console.WriteLine("Is {0} a member of {1}? = {2}", identity.Name, role, principal.IsInRole(role)); } } } Nếu bạn chạy ví dụ này với tư cách người dùng có tên là nnbphuong81 trên một máy tính có tên là MACHINE bằng lệnh WindowsGroupExample BUILTIN\Administrators BUILTIN\Users MACHINE\Accountants, kết xuất có thể như sau: Is MACHINE\nnbphuong81 a member of BUILTIN\Administrators? = False Is MACHINE\nnbphuong81 a member of BUILTIN\Users? = True Is MACHINE\nnbphuong81 a member of MACHINE\Accountants? = True . sách bảo mật miền ứng dụng. § // Cấu hình chính sách bảo mật cho đối tượng AppDomain. SetDomainPolicy(domain); // Nạp các assembly vào miền ứng dụng được bảo. # Cấu hình (bằng mã lệnh) chính sách bảo mật của miền ứng dụng mà bạn đã nạp các assembly vào đó. Chính sách bảo mật (security policy) bao gồm bốn mức