Kiểm chứng cơ chế bảo mật dựa trên ast

Nói đúng ra, đây là một ràng buộc và hợp lý trong RBAC2. Một trách nhiệm là một nghĩa vụ trên một phần của user để thi hành một hay nhiều nhiệm vụ, nói chung là rất cần thiết cho các hoạt động trơn tru của một tổ chức. Trong trách nhiệm của chúng tôi được xem như một khái niệm nâng cao mà không thuộc trong RBAC0. Chúng tôi đã chọn không kết hợp trách nhiệm trong mô hình nâng cao và cảm nhận sự không kết hợp các khái niệm giống như trách nhiệm trong mô hình điều khiển truy cập yêu cầu nghiên cứu trong tương lai. Một cách tiếp cận là xử lý chúng giống như với các permission. Những cách tiếp cận khác có thể là cơ sở cho mô hinhg điều khiển truy cập mới giống như nhiệm vụ dựa trên sự xác thực [4]. 2.6. Role có cấp bậc (a) (b) (c) Hình 2.3: Các ví dụ của Role Hierarchies (a) Role Hierarchies (b) Quản lý Role Hierarchies (c) Sự riêng tư và phạm vi của RoleHình 2.4: Role Hierarchies cho một dự án Mô hình RBAC1 giới thiệu role có thứ bậc (RH), giống như đã trình bày sơ qua trong Hình 2.1. Chúng cũng được cài đặt thông thường trong hệ thống như các role cung cấp. Role có thứ bậc có một nghĩa tự nhiên cho các role có cấu trúc để phản ánh một tổ chức của permission và trách nhiêm. Ví dụ về role có thứ bậc được thấy trong Hình 2.3. Bởi việc quy ước các role nhiều quyền lực hơn được hiện thị phía trên các sơ đồ và các role ít quyền lực hơn phía dưới sơ đồ. Trong Hình 2.3(a) role của người có chức vụ thấp là Health-care provider. Role là Physician là người có chức cao hơn Health-care provider và do đó thừa kế tất cả các permission từ Health-care provider. Thừa kế của permission nói rõ ra, cho ví dụ, trong Hình 2.3(a), role là Primary-care Physician thừa kế permission từ Physician và Health-care provider. Cả Primary-care Physician và Specialist Physician đều thừa kế permission từ role của Physician, nhưng mỗi loại này sẽ có những permission khác nhau được gán trực tiếp tới chúng. Hình 2.3(b) giải thích đa thừa kế của permission, nơi mà role là Project Supervisor thừa kế cả role của Tester và Programmer. Bằng chứng là, những cấp bậc này thứ tự từng phần. Một thứ tự từng phần là một phản thân, bổ ngữ trực tiếp và không đối xứng. Sự thừa kế là phản thân bởi vì một role thừa kế permission riêng của nó, bổ ngữ trực tiếp là một yêu cầu tự nhiên trong ngữ cảnh này, và quy tắc không đối xứng ngoài các role mà thừa kế từ một cái khác và vì thế sẽ không cần thiết. Công thức định nghĩa của RBAC1 được đưa ra bên dưới. Định nghĩa 2 mô hình RBAC1 có những thành phần sau: U, R, P, S, PA, UA, và user không được thay đổi từ RBAC0, RH R x R là một phần thứ tự trên R gọi là role có cấp bậc hay mối quan hệ role có ưu thế hơn, cũng được viết như , và roles : S2R được thay đổi từ RBAC0 để yêu cầu các role (si) { r | (r’ r)[(user(si), r’)UA]}. Hình 2.5: Mô hình tổng quát của RH (RBAC1) Chú ý rằng một user được cho phép tới thiết lập một session với nhiều sự kết hợp của role người chức vụ thấp tới user là thành viên của nó. Hơn nữa, các permission trong một session được gán trực tiếp tới các role của session cũng tốt như việc được gán tới các role của người cấp bậc thấp tới những cái này. Điều này thỉnh thoảng có ích trong thứ bậc để hạn chế phạm vi của thừa kế. Xem xét thứ bậc của Hình 2.3(b) nơi mà role là Project Supervisor là người cấp cao hơn role của cả Tester và Programmer. Bây giờ giả sử rằng Tester mong muốn giữ một vài permission riêng tư tới role của họ và chống lại sự thừa kế của họ trong thứ bậc tới người điều hành dự án. Tình hình này có thể tồn tại cho lý do chính đáng, cho ví dụ, truy cập tới một công việc chưa hoàn thành trong tiến trình có thể không thích hợp cho một người có chức vụ cao hơn trong khi RBAC có thể hữu ích có thể giống như truy cập tới Tester. Tình hình này có thể được giúp đỡ bởi việc định nghĩa một role là Test Engineer0 mới và liên quan tới nó tới Test Engineer như hiển thị trong Hình 2.3(c). Permission riêng tư của các Test Engineer có thể được gán tới role là Test Engineer0. Test Engineer được gán tới role là Test Engineer0 và thừa kế permission từ role là Test Engineer, mà được thừa kế ở trên trong hệ thống thứ bậc bởi role là Project Supervisor. Permission của Test Engineer0, tuy nhiên, không được thừa kế bởi role là Project Supervisor. Có thể gọi các role giống như Test Engine0 như các role riêng tư. Hình 2.3(c) cũng hiển thị một role riêng tư của Programmer0. Trong một vài hệ thống hiệu quả của các role riêng tư đạt được bởi khối bên trên thừa kế của các permission chắc chắn. Trong một vài trường hợp của hệ thống thứ bậc không mô tả sự phân phối của permission chính xác. Điều này thích hợp để giới thiệu các role riêng tư và giữ nghĩa của hệ thống thứ bậc liên quan xung quanh những role không thay đổi. Hình 2.4 hiển thị, nhiều điểm chung, một hệ thống thừa kế con của các role có thể được xây dựng như thế nào. Hệ thống thứ bậc của Hình 2.4(a) có bốn role công việc, T1, T2, T3, T4, tất cả đều thừa kế permission từ role dự án phổ biến rộng P. Role S ở trên cùng của hệ thống thứ bậc dành cho Project Supervisor. Công việc T3 và T4 là một dự án con với P3 như role dự án con rộng, và S3 như role giám sát dự án con. Role T1’ trong Hình 2.4(c) là một role riêng tư cho những thành viên của những nhiệm vụ T1. Giả sử dự án con trong Hình 2.4(a) gồm có vai trog S3, T3, T4 và P3, yêu cầu một hệ thống thứ bậc con riêng tư trong các permission riêng tư của dự án có thể được chia sẻ ngoài hệ thống thứ bậc bởi S. Trong toàn thể hệ thống cấp bậc con được tái tạo trong dáng vẻ được hiện thị trong Hình 2.4(c). Các permission có thể thừa kế bởi S có thể được gán tới S3, T3, T4 và P3, thích hợp trong khi một trong các quyền riêng tư có thể được gán tới S3, T4, T4 và P3’, cho phép những sự thừa kế của chúng chỉ trong dự án con. Nhưng trước khi thành viên của đội dự án con được gán trực tiếp tới S3’, T3’, T4’, hay P3’. Hình 2.4(c) làm cho nó rõ ràng như các role riêng tư tồn tại trong hệ thống và trợ giúp trong việc truy cập để xem lại tới quyết định sự tự nhiên của các permission riêng tư là gì. 2.7. Các ràng buộc Mô hình RBAC2 giới thiệu khái niệm của ràng buộc được hiển thị trong Hình 2.1(b). Mặc dù được gọi trong mô hình RBAC1 và RBAC2, đây không thực sự một ngụ ý của sự tiến triển. Mỗi ràng buộc hay hệ thống thứ bậc các vai trog có thể được giới thiệu đầu tiên. Điều này được chỉ ra bởi sự liên kết có một không hai giữa RBAC1 và RBAC2 trong Hình 2.1(a). Các ràng buộc là một diện mạo quan trọng của RBAC và thỉnh thoảng tranh luận cho nguồn gốc cho sự thúc đẩy của RBAC. Một ví dụ phổ biến mà các role tháo rời qua lại lẫn nhau, giống như quản lý việc mua và quản lý tài khoản trả. Trong hầu hết các tổ chức (ngoại trừ rất nhỏ) giống như các nhân riêng lẻ sẽ không được phép để là thành viên của cả hai role, bởi vì việc tạo ra một khả năng cho sự gian lận. Đây là một nguyên tắc nổi tiếng và được ưa chuộng được gọi sự ngăn cách các trách nhiệm. Những ràng buộc là một cơ chế quyền lực đặt cấp cao hơn chính sách của tổ chức. Điều chắc chắn là các role được khai báo loại trừ lẫn nhau, ở đó cần quan tâm quá nhiều về nhiệm vụ của từng user riêng biệt tới các role. Những hoạt động sau đó có thể được ủy nhiệm và chuyển giao ngoài sự sợ hãi của sự thỏa hiệp toàn bộ cơ chế các đối tượng của tổ chức. Vì vậy, việc quản lý RBAC được kiểm soát toàn bộ bởi security officer, những ràng buộc là hữu ích cho sự tiện lợi, nhưng hiệu quả cùng lúc có thể lớn hơn giành được bởi sự quan tâm đúng đắn của phần việc của security officer. Tuy nhiên, nếu sự quản lý của RBAC được chuyển giao, những ràng buộc trở thành một cơ cấu bởi security officer có chức vụ cao hơn có thể giới hạn khả năng của user mà có thể thực hiện đặc quyền quản lý. Nó cho phép chief security officer (trưởng nhân viên an ninh) thiết lập ngoài phạm vi rộng của việc chấp nhận và lạm dụng như yêu cầu bắt buộc trên các security officer khác và những user mà tham gian trong việc quản lý RBAC. Với sự quan tâm tới những ràng buộc RBAC có thể được áp dụng tới quan hệ UA và PA và user và các chức năng của vai trong với các session khác nhau. Các ràng buộc được khẳng định mà, được áp dụng tới các quan hệ và các chức năng, trả về một giá trị có thể chấp nhận được hay không thể chấp nhận được. Các ràng buộc có thể được xem như các câu trong một vài ngôn ngữ chính thức thích hợp. Bằng trực giác, các ràng buộc được xem xét tốt hơn theo từng loại của chúng và bản chất Sau đây là định nghĩa bên dưới. Định nghĩa 3: RBAC2 không được thay đổi từ RBAC0 ngoại trừ việc yêu cầu có một tập hợp của các ràng buộc mà quyết định dù giá trị của các thành phần khác nhau của RBAC0 có được chấp nhận hay không. Chỉ các giá trị được chấp nhận sẽ được cho phép. Xem xét việc cài đặt chung gọi cho những ràng buộc đơn giản mà có thể kiểm tra hiệu quả và làm cho có hiệu lực. May mắn thay, trong RBAC các ràng buộc đơn giản có thể đi một cách lâu dài. Hầu như tất cả, các ràng buộc áp dụng liên quan tới trách nhiệm của user có một bản sao mà áp dụng liên quan tới trách nhiệm permission. Vậy thì thảo luận các ràng buộc trên hai thành phần song song. Hầu hết các ràng buộc được đề cập đến trong ngữ cảnh của RBAC là các role loại trừ lẫn nhau. Cũng giống như user được gán nhiều nhất một role trong sự thiết lập loại trừ lẫn nhau. Điều này hỗ trợ những nhiệm vụ tách rời nhau. Sự cung cấp của ràng buộc này yêu cầu ít sự tiến triển. Hai ràng buộc trên permission nhiệm vụ khó nhận sự chuyển giao trong tài liệu. Thực tế là, một ràng buộc loại trừ lẫn nhau trên permission nhiệm vụ có thể cung cấp thêm sự chắc chắn cho các nhiệm vụ tách rời nhau. Hai ràng buộc yêu cầu mà các nhiệm vụ giống nhau được gán tới nhiều nhất một role trong sự thiết lập loại trừ lẫn nhau. Xem xét hai role loại trừ lẫn nhau, quản lý tài khoản và quản lý mua. Sự loại trừ lẫn nhau về mặt UA chỉ định mà một cá nhân riêng lẻ không thể là thành viên của cả 2 role. Sự loại trừ lẫn nhau về mặt PA chỉ định mà các permission giống nhau không thể được gán tới 2 role. Cho ví dụ, permission đưa ra kiểm tra không nên được gán tới cả 2 role. Thông thường như một permission sẽ được gán tới role quản lý các tài khoản. Các ràng buộc loại trừ lẫn nhau trên PA sẽ ngăn chặn permission dù cố ý hay không cố ý, được gán tới role quản lý việc mua. Trực tiếp hơn nữa, các ràng buộc loại trừ trên PA là có ích để giới hạn sự phân phối các permission. Cho ví dụ, điều này có thể không quan trọng khi role A hay role B đưa ra tín hiệu xác thực cho một tài khoản đặc biệt, nhưng có thể yêu cầu chỉ một trong 2 role với permission này. Thông thường thành viên của user trong sự kết hợp khác nhau của các role có thể được cho rằng chấp nhận hay không. Như vậy nó có thể được chấp nhận cho một người dùng là thành viên của role là Programmer và role một Tester trong các dự án khác nhau, nhưng không được chấp nhận để nhận cả 2 role trong cùng một dự án. Tương tự cho việc gán permission. Một ví dụ khác của ràng buộc gán cho user là một role có thể có một số lượng thành viên tối đa. Cho trường hợp, chỉ có một người trong role của chủ tọa của một văn phòng. Tương tự, số lượng của các role tới từng user riêng lẻ có thể được hạn chế. Chúng tôi gọi các yếu tố ràng buộc. Do đó, số các role mà permission được gán có thể có các yếu tố ràng buộc để điều khiển sự phân phối quyền lực của các permission. Nó có thể được chú ý mà các yếu tố ràng buộc tối thiểu có thể khó để cài đặt. Cho ví dụ nếu có một số tối thiểu user của một role, hệ thống có thể làm gì nếu một trong số họ không xuất hiện? Hệ thống hiểu chuyện này đã xảy ra như thế nào? Khái niệm tiên quyết của các role được dựa trên một sự tương thích và thích hợp, nhờ đó một user có thể được gán tới role A chỉ khi nếu một user đã là thành viên của một role B. Cho ví dụ, chỉ những người dùng mà role là thành viên của một dự án có thể được gán tới role của việc testing trong dự án đó. Trong ví dụ này role tiên quyết là người có chức vụ thấp tới một role mới là không có thật. Điều kiện giữa các role không thể so sánh được giống như xảy ra trong thực hành. Hai ràng buộc gán trên permission áp dụng nhiều hơn trên role kết thúc của quan hệ PA. Nó có thể có ích, với sự kiên nhẫn, để yêu cầu permission p được gán tới một role chỉ nếu role đó có permission q rồi. Cho trường hợp, trong nhiều hệ thống permission để đọc một file được yêu cầu permission để đọc một thư mục chứa file được chỉ định. Việc gán các mẫu ngoài permission sẽ không hoàn thành. Các ràng buộc được gán tới user là hiệu quả chỉ nếu phù hợp bên ngoài kiến thức được giữ lại trong việc gán định danh user tới nguời thực sự. Nếu một vài cá nhân riêng lẻ được gán 2 hay nhiều định danh user, sự ngăn cách và các yếu tố điều khiển phá hủy. Phải có sự tương ứng một – một giữa định danh user và người thực sự. Một trách nhiệm tương tự áp dụng tới các ràng buộc permission. Nếu cùng một thao tác được thừa nhận bởi 2 permission khác nhau, hệ thống RBAC không thể thực thi hiệu quả các yếu tố và các ràng buộc riêng biệt. Các ràng buộc có thể được áp dụng tới các session, và chức năng user và các role kết hợp với một session. Nó có thể chấp nhận cho một user là thành viên của 2 role nhưng user không thể hoạt động cả 2 role cùng lúc. Các ràng buộc khác trên các session có thể giới hạn số các session mà user có thể hoạt động cùng lúc. Do đó, số các session mà một permission được gán được giới hạn. Một hệ thống thứ bậc role có thể được xem như một ràng buộc. Ràng buộc này là một permission gán tới role một người có chức vụ thấp phải được gán tới tất cả các role của người có chức vụ cao hơn. Hay tương đương, ràng buộc mà user được gán tới một role của người có chức vụ cao hơn phải được gán tới tất cả các role của người có chức vụ thấp hơn. Trong một số ý nghĩa, RBAC1 là thừa và con của RBAC2. Tuy nhiên, chúng tôi cảm thấy nó thích hợp để đánh giá hiện trạng của hệ thống role có thứ bậc riêng của chúng. Chúng giảm sự ràng buộc chỉ bởi sự giới thiệu thừa của việc gán permission hay gán user. Nó thích hợp hơn để trợ giúp hệ thống thứ bậc trực tiếp hơn gián tiếp bởi cách của gán dư thừa. 2.8. Mô hình hợp nhất RBAC3 là sự kết hợp của RBAC1 và RBAC2 để cung cấp cả hai hệ thống thứ bậc role và các ràng buộc. Có một số kết quả xảy ra bởi đưa ra hai khái niệm đó cùng nhau. Các ràng buộc có thể được áp dụng tới chính các hệ thống role có thứ bậc, như được chỉ ra bởi mũi tên đậm tới RH trong Hình 2.1(b). Hệ thống role thứ bậc được yêu cầu của sự chia ra từng phần. Ràng buộc này là cốt lõi của mô hình. Việc thêm và các ràng buộc có thể giới hạn số các role của người cấp cao (hay người cấp thấp) mà role nhất định có thể có. Hai hay nhiều role có thể được ràng buộc để không có sự phổ biến role của người cấp cao (hay người cấp thấp). Những loại này của các ràng buộc là hữu ích trong hoàn cảnh nơi mà việc xác thực thay đổi hệ thống role có thứ bậc được chuyển giao, nhưng trưởng security officer chuyển toàn bộ các loại trong thay đổi được làm. Sự ảnh hưởng lẫn nhau một cách tế nhị xuất hiện giữa các ràng buộc và các hệ thống cấp bậc. Giả sử role của Test Engineer và Programmer được khai báo loại trừ lẫn nhau trong ngữ cảnh của Hình 2.3(b). Role là Project Supervisor vi phạm sự loại trừ lẫn nhau này. Trong một vài trường hợp như một sự vi phạm một ràng buộc loại trừ lẫn nhau bởi role của một người cấp cao có thể được chấp nhận, trong khi các trường hợp khác là không thể. Chúng tôi cảm thấy các mô hình không nên ngoài một hay các khả năng khác. Một hoàn cảnh giống như xảy ra với các yếu tố ràng buộc. Giả sử một user có thể được gán nhiều nhất một role. Liệu việc gán tới role test engineer trong Hình 2.3(b) có vi phạm ràng buộc này? Nói theo cách khác, các yếu tố ràng buộc chỉ áp dụng trực tiếp tới các thành viên và chúng xúc tiến để các thành viên thừa kế? Hệ thống có cấp bậc trong Hình 2.3(c) miêu tả các ràng buộc có ích trong sự thể hiện của các role riêng tư như thế nào. Trong một vài trường hợp role là Test Engineer0, Programmar0 và Project Supervisor có thể được khai báo loại trừ lẫn nhau. Bởi vì những điều này không phổ biến trong các người cấp cao cho những role này, không có sự xung đột. Trong các role riêng tư chung sẽ không xó các người cấp cao thông thường với nhiều role khác nhau bởi vì chúng là những yếu tố toàn diện nhất trong hệ thống cấp bậc. Sự loại trừ lẫn nhau của các role riêng tư luôn luôn được chỉ rõ ngoài sự xuất hiện của các xung đột. Sự chia sẻ các bản sao của các role riêng tư có thể được riêng tư có thể được khai báo để có một yếu tố ràng buộc toàn diện nhất không của thành viên nào. Với cách này Test Engineer phải được gán tới role là Test Engineer0. Role là Test Engineer phục vụ như một phương tiện của sự chia sẻ permission với role là Project Supervisor. 2.9. Các mô hình quản lý Hình 2.6: Mô hình RBAC quản lý Giả sử rằng tất cả các thành phần của RBAC dưới sự điều khiển trực tiếp của một security officer. Trong các hệ thống lớn số các role có thể là hàng trăm hay hàng nghìn. Việc quản lý các role này và mối tương quan của chúng là một nhiệm vụ rất khó khăn mà thường được tập trung cao và được ủy quyền tới một đội quản lý nhỏ. Bởi vì lợi thế chính của RBAC là việc quản lý các permission dễ dàng hơn, nó là đặc điểm tự nhiên để hỏi RBAC có thể được dùng để quản lý chính RBAC như thế nào? Tin tưởng rằng người dùng RBAC để quản lý RBAC sẽ như là một nhân tố quan trọng trong thành công của RBAC. Ở đây chúng tôi chỉ có thể chạm vào một vài vấn đề lớn. ISO phát triển một số việc quản lý an toàn liên quan tới các chuẩn và tài liệu. Mô hình ISO là hướng đối tượng và bao gồm một hệ thống có thứ bậc dựa trên chính sách ngăn chặn (một thư mục chứa các file và một file chứa các bản ghi) Các role có thể được kết hợp trong hướng tiếp cận ISO. Có một chặng đường dàimô hình truyền thống cho sự truyền bá của các quyền truy cập, nơi mà quyền tới sự truyền bá các quyền được điều khiển bởi các quyền điều khiển đặc biệt. Giữa gần đây nhất và được phát triển nhất của loại mô hình ma trận truy cập của Sandhu [4]. Trong khi thông thường rất khó để phân tích những hậu quả của sự công bằng đơn giản của các quy luật cho sự truyền bá của các quyền, những mô hình này cho biết rằng những nguồn gốc đơn giản có thể được kết hợp tới sản lượng rất mềm dẻo và các hệ thống rất có ý nghĩa. Trong ví dụ của công việc trên việc quản lý RBAC bởi Morlet và Sloman người mà định nghĩa công bằng mô hình phức tạp dựa trên các miền role, người làm chủ, người quản lý và quản trị bảo mật. Trong sự xác thực công việc của họ không được điều khiển hay được ủy nhiệm từ một điểm tập trung, nhưng đúng hơn là sự thương lượng giữa các nhà quản lý độc lập mà chỉ có một trách nhiệm giới hạn trong mỗi người. Mô hình quản lý RBAC được minh họa trong Hình 2.6. Một nửa phần trên của hình này về bản chất giống với Hình 2.1(b). Các ràng buộc trong Hình 2.6 được áp dụng tới tất cả các thành phần. Nửa dưới của Hình 2.6 là ánh xạ của nửa trên cho các role quản lý và các permission quản lý. Nó được mong đợi mà các role quản lý AR và các quyền quản lý AP được tách biệt ra giữa các role thông thường R và các permission P. Mô hình hiển thị các permission có thể được gán tới các role và các permission quản lý có thể chỉ được gán tới các role quản lý. Điều này gắn liền các ràng buộc. Một nửa trên của Hình 2.6 có thể một dãy trong sự tinh tế qua RBAC0, RBAC1, RBAC2, và RBAC3. Nửa dưới có thể dãy đơn giản trong sự tinh tế qua ARBAC0, ARBAC1, ARBAC2, and ARBAC3 nơi mà A chứng tỏ sự quản lý. Nhìn chung sẽ trông đợi mô hình quản lý tới mô hình đơn giản hơn chính mô hình RBAC. Do vậy ARBAC0 có thể được dùng để quản lý RBAC3, nhưng dường như không hợp lý khi dùng ARBAC3 để quản lý RBAC0. Nó cũng quan trọng để nhận ra các ràng buộc có thể cắt cả trên và dưới của Hình 2.6. Chúng tôi xác nhận một ràng buộc gán liền mà các permission có thể được gán tới các role và các permission quản lý có thể tới các role quản lý. Nếu các role quản lý loại trừ lẫn nhau với sự lưu tâm tới các role thông thường, có một vị trí mà người quản lý bảo mật có thể quản lý RBAC nhưng không dùng các đặc quyền của chúng. Làm sao để quản lý sự điều hành của hệ thống có thứ bậc? Một nguyên tắc có thể được xây dựng một cấp độ 2 trong việc quản lý hệ thống có thứ bậc tới việc quản lý cấp độ 1 và trên nó. Chúng tôi cảm thấy chỉ có một cấp độ 2 của hệ thống quản lý có thứ bậc là không cần thiết. Sau đây việc quản lý của quản lý hệ thống có thứ bậc được chuyển tới một security officer. Điều này là chấp nhận được với một tổ chức đơn hay một đơn vị quản lý đơn trong một tổ chức. Vấn đề đặt ra là những đơn vị này ảnh hưởng không trực tiếp được lấy ra trong mô hình. Xác thực sự quản lý trong RBAC có thể được nhìn nhận như khả năng để thay đổi sự gán lên user, gán lên quyền sử dụng và quan hệ hệ thống role có thứ bậc. Trong một mô hình quản lý các permission mà được xác thực các hoạt động quản lý này phải được định nghĩa rõ ràng. Chính xác bản chất các quyền truy cập là sự cài đặt cụ thể, nhưng bản chất chung của chúng là giống nhau. Một trong những vấn đề chính trong mô hình quản lý là phạm vi việc xác thực quản lý được trao cho như thế nào trong các role quản lý. Để minh họa cho việc xem xét này hệ thống có thứ bậc hiển thị trong Hình 2.4(a). Hệ thống quản lý có thứ bậc trong Hình 2.4(b) hiển thị một role của security officer trưởng (CSO) mà người cấp cao hơn tới ba role của security officer SO1, SO2 và SO3. Mối quan tâm tới phạm vi của vấn đề mà các role trong Hình 2.4(a) có thể được được quản lý bởi các role của Hình 2.4(b). Chúng tôi sẽ nói role CSO có thể quản lý tất cả các role trong Hình 2.4(a). Giả sử SO1 quản lý công việc T1. Nhìn chung không muốn SO1 tự động thừa kế các khả năng quản ly role cấp thấp P. Bởi vậy phạm vi của SO1 có thể được giới hạn hoàn toàn tới T1. Đơn giản là, phạm vi của SO2 có thể được giới hạn tới T2. Thừa nhận rằng SO3 có thể quản lý trọn vẹn các dự án con gồm có S3, T3, T4 và P3. Phạm vi của SO3 là giới hạn bởi S3 ở trên đỉnh và P3 ở dưới. Nhìn chung, mỗi role quản lý sẽ được ánh xạ tới một vài tập hợp con của role hệ thống có cấp bậc có trách nhiệm cho ánh xạ này. Có các diện mạo khác của sự quản lý mà cần được phạm vi hóa. Cho ví dụ, SO1 có thể thêm các user tới role T1 nhưng việc di chuyển của chúng yêu cầu CSO tới hành động. Hơn nữa, cần tới phạm vi không chỉ các role một sự quản lý các role, mà lại các permission và user. Điều này quan trọng để điều khiển thay đổi trong chính hệ thống role có cấp bậc. Ví dụ, bởi vì SO3 quản lý các hệ thống có thứ bậc con giữa S3 và P3, SO3 có thể được xác thực tới việc thêm vào các nhiệm vụ truyền thống tới các dự án con. 2.10. Kết luận Như đã trình bày một tập hợp của các mô hình RBAC mà sự thống hóa từ đơn giản tới phức tạp. Các mô hình này cung cấp một cấu trúc phổ biến của sự tham chiếu tới một sự nghiên cứu khác và phát triển trên lĩnh vực này. Chúng tôi đã trình bày một mô hình quản lý nơi mà RBAC có thể được dùng để quản lý chính nó. Sự trợ giúp này trêm vị trí của chúng rằng RBAC có chính sách trung lập hơn một mô hình của chính sách bảo mật cụ thể. Nhiều điều còn lại được làm tới sự nhận thức khả năng của RBAC. Một trong những vấn đề nghiên cứu đáng chú ý trong lĩnh vực này là phát triển tới một sự tiếp cận có hệ thống tới thiết kế và phân tích của các cấu hình RBAC. Như đã đề cập từ trước, có ít sự thảo luận trong tài liệu về các ràng buộc trong ngữ cảnh của RBAC [8, 9, 14]. Một sự phân loại và nguyên tắc phân loại của các ràng buộc có thể hữu ích. Một ký hiệu hình thức cho trạng thái và sự thi hành các ràng buộc. Cùng với một vài biện pháp khó của sự thi hành sẽ được phát triển. Khả năng về lý do của các ràng buộc và phân tích mạng lưới các hiệu ứng của cấu hình một RBAC dưới dạng các đối tượng chính sách cấp cao hơn là một lĩnh vực nghiên cứu mở quan trọng. Khía cạnh của việc quản lý RBAC cần thiết cho công việc tương lai. Phát triển có hệ thống các phương pháp mà đề cập với sự thiết kế và phân tích của hệ thống role có cấp bậc, các ràng buộc, và việc quản lý RBAC trong một sườn thống nhất là một mục tiêu nghiên cứu đầy thử thách. Nhiều trong các vấn đề mở này và các vấn đề được gắn kết vào nhau và sẽ yêu cầu một sự tiếp cận kết hợp với giải quyết của chúng. CHƯƠNG 3. GIỚI THIỆU CÔNG CỤ CDT TRONG ECLIPSE 3.1. Tổng quan Eclipse CDT là một plug-in của Eclipse biến đổi Eclipse tới một khả năng C/C++ IDE. Nó được thiết kế để có thể đưa ra nhiều tính năng Eclipse có được bởi những người phát triển Java tới những người phát triển C/C++, giống như người quản lý các dự án, kết hợp debugging, class wizards, build tự động, kết hợp với JDK. Sự thúc đẩy của CDT và kết hợp với các công cụ chuẩn của C/C++, giống như g++, và GDB dẫn tới sự bắt đầu rất nhiều trong Linux, nơi mà các công cụ đó sẵn sàng được dùng trong việc phát triển C/C++. CDT được cài đặt trên Window để dùng giống như các công cụ khác. Điều này cũng được trông đợi để dùng CDT để làm việc với các công cụ C++ của Microsoft và hấp dẫn hơn phát triển C++ trên Window. 3.2. Cấu trúc của CDT Hình 3.1: Cấu trúc tổng quát CDT Hình 3.2: Cấu trúc chi tiết của CDT 3.3. Các tính năng của CDT Thành phần đầu tiên là DOM AST. Tiện ích này hiển thị AST rất chi tiết và rõ ràng. Với một mã nguồn cho trước có thể sinh ra AST với các node tương ứng với các đoạn mã trong file mã nguồn được cung cấp. Với AST có thể kiểm soát mã nguồn tốt nhất và cho phép định hướng, xây dựng thuật toán duyệt cây hoàn chỉnh. DOM AST có cấu trúc như sau: Hình 3.3: Giao diện DOM AST Trong phần giới thiệu về CDT sẽ không nói tất cả các thành phần của CDT chỉ tập trung vào thành phần quan trọng nhất liên quan tới thuật toán là các API và cụ thể là org.Eclipse.CDT.core.dom.AST. Đây là thành phần quan trọng nhất. Thành phần này cung cấp hầu hết các API cần sử dụng để thực hiện các bước trong thuật toán. Ví dụ: IASTNode: API cung cấp cấu trúc node của mã nguồn với hai phương thức chính là getParent() và getChild() để duyệt cây. Parent Child Child Child getChild() getParent() Hình 3.4: Mô tả cách duyệt cây Ngoài thành phần này có một API khác: IASTStatement (có Superinterfaces là IASTNode) cung cấp các Subinterfaces gồm các thành phần sau: IASTBreakStatement,IASTCaseStatement,IASTCompoundStatement,IASTContinueStatement,IASTDeclarationStatement,IASTDefaultStatement,IASTDoStatement,IASTExpressionStatement,IASTForStatement,IASTGotoStatement,IASTIfStatement,IASTLabelStatement,IASTNullStatement,IASTProblemStatement,IASTReturnStatement,IASTSwitchStatement,IASTWhileStatement,ICPPASTCatchHandler,ICPPASTForStatement,ICPPASTIfStatement,ICPPASTSwitchStatement,ICPPASTTryBlockStatement,ICPPASTWhileStatement. Để bài toán kiểm chứng được phát triển toàn diện cần quan tâm tới các Statement chứa điều kiện như IASTIfStatement, IASTWhileStatement và nhiều Statement khác. Ngoài ra, các biểu thức điều kiện cần API là IASTExpression. Nó duyệt được các biểu thức điều kiện trong các Statement để so sánh với các biểu thức điều kiện quy định sẵn (ảnh hưởng đến dữ liệu nhạy cảm) 3.4. Kết luận Nội dung trên đã trình bày về CDT – một công cụ hữu hiệu trong việc kiểm chứng các mô hình RBAC, các API được cung cấp cho bài toán kiểm chứng Trình bày về cách duyệt cây qua các phương thức được cung cấp, cách lấy ra các điều kiện trong các Statement để so sánh với điều kiện cho trước. CHƯƠNG 4. BÀI TOÁN KIỂM CHỨNG 4.1. Giới thiệu: Mã nguồn của một ngôn ngữ được tổ chức dưới dạng cây. Cây được tổ chức với các node. Node tương ứng với từng thành phần trong ngôn ngữ. Có thể hình dung một cây như sau: Cây mà luôn có một node gốc (root) là node mà không có cha nào cả. Từ node gốc có thể đi đến các node con và từ một node đi lên cha của nó (cha trực tiếp) qua các phương thức tương ứng. Cụ thể, với lệnh if luôn được cấu trúc dưới dạng cây. Với 2 con tương ứng là các điều kiện và các thân của if ifStatement Expression Condition CompoundStatement Hình 4.1: Cấu trúc cây của ifStatement đơn giản 4.2. Khái quát thuật toán Thuật toán duyệt cây như sau: Với tổ chức của AST cần phải duyệt từ trên xuống dưới. Trong quá trình duyệt từ trên xuống nếu nhận được những hàm tác động đến mô hình RBAC hay dữ liệu nhạy cảm cần quan tâm. Ví dụ, có một đoạn mã nguồn mà ảnh hưởng trực tiếp đến dữ liệu nhạy cảm “write (“RBAC.TXT”)” sau khi xác định được node này (thuộc loại node gì?) Sau đó, đi ngược lên trên để tìm điều kiện tương ứng. Phần này chỉ tìm hiểu một số Statement đơn giản là các Statement chứa các điều kiện liên quan đến vấn đề cần kiểm chứng. Khi xác định điều kiện cần xem node ảnh hưởng đến dữ liệu nằm trong các Statement nào? Với Statement là if cần xem xét biểu thức điều kiện của if. Nếu điều kiện của if thuộc một trong những điều kiện đã giới hạn cũng như đã quy định từ trước khi đó bắt đầu xét sâu đến Statement này. Khi kiểm chứng, nếu Statement có điều kiện thỏa mãn với yêu cầu kiểm chứng tiếp tục đi lên trên nếu không thỏa mãn in ra thông báo lỗi luôn. Sau khi đi lên trên, kiểm tra xem tiếp các Statement với các điều kiện đã quy định và cứ tiếp tục như vậy cho đến khi đi đến Statement ngoài cùng thì thôi. Thuật toán sẽ duyệt cây từ dưới lên, lấy cha của node xác định là tác động đến dữ liệu sau khi đi lên trên xác định đâu là các Statement mới khai thác chi tiết. CDT là một công cụ rất quan trọng để kiểm chứng thuật toán. Thuật toán được xây dựng dựa trên kiến trúc của AST. CDT sinh ra AST để có cái nhìn rõ ràng nhất về cấu trúc tổ chức của một mã nguồn C/C++. Trong tương lai, nếu muốn cải tiến thuật toán với công cụ khác là JDT thì tìm hiểu và sử dụng thành thạo công cụ CDT sẽ làm cho công việc dễ dàng và thuận lợi hơn nhiều.  Mô hình dùng để mô tả cách triển khai thuật toán dựa trên AST như sau: Hình 4.2: Mô tả thuật toán kiểm chứng cơ chế bảo mật Với mô hình này, thuật toán được triển khai dựa trên hai thành phần chính là AST và RBAC. Với một cơ chế bảo mật được xây dựng sẵn dựa trên các mô hình của RBAC, một đoạn mã nguồn đưa vào với đặc trưng các mô hình RBAC. Thuật toán được xây dựng phải làm nổi bật rõ ràng nhất những ưu điểm của các mô hình RBAC và có sự kiểm soát mã nguồn một cách chi tiết và toàn diện nhất. 4.3. Những khía cạnh liên quan 4.3.1. Khía cạnh lý thuyết Phần này sẽ đề cập tới những khía cạnh chuyên sâu hơn của thuật toán. Thuật toán đang xây dựng liên quan nhiều đến kiểm chứng cơ chế bảo mật. Do đó, vấn đề an toàn luôn được đặt lên hàng đầu, cần phải xét tất cả những gì có thể liên quan đến hệ thống dữ liệu đang cần bảo mật. Một sự tác động vào cơ chế bảo mật có thể có nhiều con đường khác nhau. Những con đường đó thường tập trung vào: Ghi dữ liệu lên vùng cấm ghi (ví dụ: ghi thêm vào file RBAC.TXT) Xóa những dữ liệu quan trọng (ví dụ: xóa file RBAC.TXT) Cấp phát bộ nhớ cho vùng dữ liệu được giới hạn cấp phát … Trong AST không chỉ quan tâm tới các điều kiện trong các Statement (tuy điều này là quan trọng nhất) mà phải chú ý tới các hàm có thể ảnh hưởng tới dữ liệu được liệt kê sơ bộ ở trên. Thuật toán duyệt cây ở trên đã nắm bắt được các trường hợp trong mã nguồn có thể sinh ra và người viết mã nguồn cố tình vi phạm. Để thuật toán chạy nhanh hơn thì những điều kiện không có trong quy định sẽ được chạy qua mà không cần bất cứ một sự kiểm tra nào. Đây là chỗ hổng để người viết mã nguồn với ý định xấu có thể lợi dụng. Chẳng hạn, với ifStatement nếu chỉ xét một điều kiện thì rất cực đoan nên cần xử lý với nhiều điều kiện. Do chỉ minh họa về mặt công nghệ nên bài toán đưa ra sẽ là một trường hợp rất nhỏ, cần phát triển và cải tiến hơn trong tương lai. Hình 4.3: Cấu trúc của lệnh if phức tạp Sự phức tạp trong mã nguồn có rất nhiều trường hợp. Một điều rất mâu thuẫn là phải chọn giữa tốc độ và sự an toàn. Thuật toán phải đảm bảo được cả hai tính chất này. Do C/C++ là những ngôn ngữ chuyên dụng và phổ biến nên việc nghiên cứu thuận lợi hơn nhưng trong tương lai khi phát triển với Java hay C# thì thuật toán này là nền tảng quan trọng 4.3.2. Khía cạnh thực tiễn Trong thực tiễn, thuật toán cần có tính khả dụng và được triển khai trong lĩnh vực của đời sống. Ngân hàng là một ngành yêu cầu tính bảo mật và an toàn cực kỳ cao. Với đội ngũ nhân viên được phân công với các mục đích và vai trò hết sức chi tiết. Việc xây dựng mô hình RBAC0 không thể đáp ứng được đòi hỏi của ngành này. Vì thế, thuật toán phải được xây dựng trên hướng mở. Tức là, nó không chỉ mang tính chủ quan, cá thể mà phải có tính phổ biến và áp dụng cho tất cả các mô hình RBAC đã nghiên cứu. Điều này đươc thể hiện trong sự phức tạp của AST Hình vẽ dưới đây sẽ cho thấy rất rõ điều này: Điều kiện 2 Điều kiện 1 Liên kết nhiều điều kiện Hình 4.4: Thể hiện phức tạp trên AST 4.4. Ứng dụng thuật toán 4.4.1. Khái quát về ứng dụng Những nghiên cứu của thuật toán ở phần trên cho phép hình dung cách thức thực hiện việc kiểm chứng. Để làm rõ hơn tính lý thuyết của thuật toán cần đưa thuật toán vào thực tế. Phần này xây dựng một bài toán nhỏ nhưng thể hiện đầy đủ khía cạnh mà thuật toán trên đã đề cập. Để tiến hành thuận lợi, chúng tôi lựa chọn mô hình kiểm chứng là mô hình tuy đơn giản nhất nhưng là nền tảng của hầu hết các mô hình của RBAC. 4.4.2. Mục tiêu bài toán: Mục tiêu của bài toán là xây dựng một phương pháp kiểm chứng mô hình đơn giản nhất của RBAC là RBAC0. Có một đoạn mã nguồn cho sẵn (Đoạn mã nguồn này thể hiện rõ mô hình RBAC0 với các Statement và các điều kiện được quy định từ trước) và với một file đầu vào là mô hình RBAC0 thể hiện như sau: File thể hiện mô hình RBAC0 USER ROLE PERMISSION Operate Object ThanhNV Doctor Write RBAC.TXT TanNV Patient Read RBAC.TXT ThangLC Nurse Remove RBAC.TXT Chúng tôi sẽ kiểm chứng đoạn mã đã cho sẵn có điều kiện nào trái với mô hình này không? Với các “dữ liệu nhạy cảm” thì một người với không có quyền hạn có thể thực hiện được không? Ví dụ như “write (“RBAC.TXT”)”. Đây là một ví dụ đơn giản, nó sẽ được mở rộng trong một ứng dụng cụ thể trong thực tế (chẳng hạn Y tế …) 4.4.3. Yêu cầu bài toán: Bài toán phải được xây dựng đáp ứng các yêu cầu sau: Phải kiểm soát được mã nguồn và các biểu thức điều kiện rõ ràng. Phải thể hiện đặc trưng của mô hình RBAC0 Phải có output rõ ràng bắt được các lỗi và cấu trúc chương trình rõ ràng. 4.4.4. Phân tích bài toán Bài toán đang nghiên cứu là một trường hợp trong bài toán lớn. Trên thực tế có thể mở rộng bài toán cho các lĩnh vực nhất định để kiểm soát được sự truy cập của từng người với chức quyền khác nhau vào các dữ liệu quan trọng. Bài toán không chỉ dừng lại ở việc kiểm chứng mô hình RBAC0, mà cao hơn nữa có thể xây dựng để kiểm chứng các mô hình cấp cao hơn để có thể ứng dụng trong những lĩnh vực mà có yêu cầu về sự bảo mật cũng như phân công vai trò nhiệm vụ quan trọng hơn. Việc xây dựng bài toán kiểm chứng các mô hình RBAC dựa trên AST để thực hiện việc kiểm soát những đoạn mã nguồn mà có thể từ dó dẫn đến sự rò rỉ thông tin cũng như đe dọa tới hệ thống các dữ liệu. Với người bình thường thì ảnh hưởng rất hạn chế nhưng với các cơ quan chính phủ hay các lĩnh vực yêu cầu sự bảo mật rất cao như Ngân hàng, Quân sự … thì bài toán xây dựng thực sự hữu ích. Với chỉ một đoạn mã sai không có sự kiểm chứng có thể biến một người dùng bình thường trở thành người kiểm soát hệ thống và làm thay đổi mục đích sử dụng của hệ thống. Error Hình 4.4: Lỗi thể hiện trong đoạn mã Có rất nhiều điểm mà người viết mã nguồn có thể lợi dụng để chèn những đoạn mã “độc” vào mà khó có thể kiểm soát được. 4.5. Kết luận Chương này đã trình bày bài toán kiểm chứng dựa trên AST gồm các phần sau. Giới thiệu cấu trúc một mã nguồn được tổ chức dưới dạng cây như thế nào? Sâu đó khái quát thuật toán sẽ được triển khai. Bằng việc nhìn được cấu trúc mã nguồn qua cây cú pháp trừu tượng – AST , nội dung của chương tập trung vào việc phân tích thuật toán duyệt cây. Không chỉ khái quát hóa thuật toán mà còn đưa ra được những khía cạnh khác liên quan sâu hơn đến thuật toán cả về mặt lý thuyết lẫn thực tiễn để có một cái nhìn sâu hơn và toàn diện hơn về thuật toán đang xây dựng. Chúng tôi đã đưa ra ứng dụng của thuật toán trong một bài toán cụ thể. Cách tiếp cận này thuật toán được nhìn nhận trực quan hơn và cụ thể hơn. Với bài toán được xây dựng đáp ứng đầy đủ những gì mà thuật toán muốn đạt được trong thực tiễn. Trong tương lai, thuật toán được mở rộng với nhiều ngôn ngữ hơn và nhiều dạng mã nguồn hơn. CHƯƠNG 5. THỰC NGHIỆM Trong chương này sẽ xây dựng ứng dụng cụ thể với bài toán được phân tích ở trên gồm có việc cài đặt, xây dựng và triển khai của bài toán. 5.1. Phạm vi ứng dụng Trong khóa luận, chỉ đưa ra một ứng dụng nhỏ để thể hiện được mặt công nghệ của bài toán kiểm chứng. Ứng dụng được chia làm các nhiệm vụ chính sau: Xây dựng đoạn mã ví dụ để kiểm chứng với một file chứa mô hình của RBAC0. Xây dựng chương trình thể hiện thuật toán kiểm chứng trên môi trường Eclipse (Với plug-in là công cụ CDT) 5.2. Thiết kế ứng dụng Cài đặt chương trình: Bài toán được xây dựng dựa trên ngôn ngữ Java (Ngôn ngữ độc lập nền), vì thế sau khi xây dựng có thể triển khai trên môi trường Window, Linux, Unix … Để xây dựng và triển khai bài toán ta cần một số chương trình sau: Cài đặt môi trường chạy cho Java: Cài đặt JDK-1.6 và thiết lập biến môi trường JAVA_HOME: “C:\Program Files\Java\jdk1.6.0\bin”. Cài đặt bộ biên dịch C/C++: MinGW Download MinGW sau đó cài đặt tự động vào C:\MinGW Cài đặt Eclipse: dùng Eclipse (GADIMEDE) Cài đặt công cụ CDT: dùng công cụ CDT 6.0 Sau khi cài đặt thành công các thành phần trên sẽ có kết quả với StartPage của Eclipse như sau: Hình 5.1: Giao diện StartPage sau khi cài CDT Với quá trình cài đặt thêm công cụ CDT vào Eclipse sẽ có một công cụ để phát triển với C/C++. Đặt biệt sau khi cài đặt thành công công cụ này có thêm thành phần DOM AST là thành phần quan trọng nhất của khóa luận. Cấu trúc của thành phần DOM AST như sau: Chọn node AST Mã nguồn DOM AST Hình 5.2: Cấu trúc DOM AST 5.3. Xây dựng và triển khai bài toán 5.3.1. Xây dựng chương trình chính Chương trình chính viết trên Eclipse với ngôn ngữ Java. Do đây là bài toán rất nhỏ nên chỉ thao tác với hai file chính trong Project VisitorAST: “FindAExpressionVisitor.Java” (Thực hiện việc visitor các Expression trong mã nguồn) “GetProject.Java” (Thực hiện hầu hết các thao tác xử lý và chạy chương trình). Để thực hiện được thuật toán cần phải thực hiện rất nhiều bước. Bước 1: Xác định được Project cần kiểm tra. Sau đó, mới bắt đầu thực hiện việc xử lý với Project đó Bước 2: Duyệt một node trong các thành phần của cây. Với công cụ CDT, Eclipse cung cấp một thành phần là DOM AST nhưng vấn đề quan trọng là phải nắm bắt được và thực hiện được việc duyệt được AST. Công cụ này cung cấp rất nhiều API để có thể thực hiện việc duyệt cây này. Ví dụ để duyệt các Expression : shouldVisitExpressions = true ; và hàm override hàm visit của nó @Override public int visit(IASTExpression myExpression) Tất cả những công việc này chúng tôi sẽ triển khai ở một file chứa class riêng để thực hiện. Công việc thực hiện ở file “GetProject.Java” chỉ là gọi các đối tượng của class này và thực hiện câu lệnh accept để bắt đầu tiến hành duyệt các Expression từ trên xuống trong file mã nguồn. Bắt đầu duyệt Bước 3: Thực hiện so sánh các Expression này với các Expression của các Statement đang xét (ví dụ: ifStatement, whileStatement …). Vì có nhiều Statement cần xét nên cần xây dựng một phương thức thể hiện tính đa hình của ngôn ngữ lập trình hướng đối tượng. checkRBAC(ExpressionFunction, object, functionCall) Phương thức này xử lý các trường hợp của Statement và cho kết quả là true hay false. Kết quả trả về này rất quan trọng trong quá trình kiểm tra các điều kiện của mã nguồn tương ứng với các mô hình RBAC0. Để hiển thị được kết quả sau khi kiểm tra có phương thức: treatFunction(functionName, functionCall) Phương thức này sẽ hiển thị các dòng thông báo sau khi kiểm tra thông báo lỗi cũng thấy rất rõ kết quả. 5.3.2. Xây dựng chương trình kiểm tra: Chương trình kiểm tra khá đơn giản là một Project C/C++ tên RBACTest chứa file RBACTest.CPP. File này có nhiệm vụ xây dựng một chương trình thể hiện được mô hình RBAC0 với các biểu thức điều kiện và các hàm tác động đến “dữ liệu nhạy cảm” như đã quy định sẵn trong chương trình chính. Với mục đích chỉ thể hiện về mặt công nghệ nên mã nguồn được xây dựng trước (hard-code) nếu để phát triển lên một cấp cao hơn trong tương lai phải thực hiện với những đoạn mã nguồn không được quy định sẵn và được phát triển với hầu hết các mã nguồn đưa vào. Chương trình kiểm tra nhất thiết phải là “runtime-EclipseApplication” để có thể chạy được chương trình. Với đầu vào là Project RBACTest. Giao diện của chương trình Test như sau: Chạy chương trình Test Hình 5.3: Giao diện chương trình Test Với giao diện này khi chạy, sẽ có kết quả hiển thị ở màn hình console của chương trình chính. Khi chạy thành công sẽ hiển thị thông báo như sau: Hình 5.4: Giao diện khi chạy Test thành công Và kết quả nhận được ở chương trình chính như sau: Hình 5.5: Giao diện kết quả 5.4. Kiểm thử chương trình 5.4.1. Nội dung kiểm thử Chương trình sẽ chạy thử với các yêu cầu kiểm tra khác nhau. Với input (đầu vào): một file RBAC.TXT được cấu trúc theo mô hình RBAC0. File RBAC.TXT có dạng như sau: User Role Permission ThanhNV Root Write (“RBAC.TXT”) TanNV User Read (“PUBLIC.TXT”) TrungND User Write (“DB.TXT”) HungNT Root Remove (“RBAC.TXT”) Và mã nguồn C/C++ được viết theo mô hình mà file RBAC.TXT đã cung cấp. Mã nguồn cụ thể hóa vấn đề role là root sẽ có permission write (“RBAC.TXT”) và điều cần làm là đối chiếu với file RBAC.TXT (như trên) để đưa ra output (đầu ra) để so sánh với output mong muốn đạt được. 1. Với biểu thức điều kiện đơn: Trường hợp lệnh write: Nếu nhập role là user và có quyền write (“RBAC.TXT”) thì output mong muốn là lỗi. Và có thông báo lỗi cụ thể. Dữ liệu nhập vào Output mong muốn: Có lỗi So sánh Output chương trình Hình 5.6(a): kiểm tra với lệnh write(có lỗi) Còn nếu role là root mà permission là write (“RBAC.TXT”) thì không có lỗi xảy ra và output mong muốn là OK. Output mong muốn: Thỏa mãn Dữ liệu nhập vào So sánh Output chương trình Hình 5.6(b) : kiểm tra với lệnh write ( không có lỗi) Trường hợp với lệnh remove: đây là xóa dữ liệu, việc Test cũng như với lệnh write. Với mong muốn output là OK. Output mong muốn: Thỏa mãn Dữ liệu nhập vào Output chương trình So sánh Hình 5.6(c) : kiểm tra với lệnh remove( không có lỗi) Với mong muốn output là có lỗi: Output mong muốn: Có thông báo lỗi Dữ liệu nhập vào So sánh Output chương trình Hình 5.6(d) : kiểm tra với lệnh remove(có lỗi) 2. Với biểu thức điều kiện lồng nhau: Trường hợp lệnh write: output mong muốn là lỗi. Output mong muốn: Có lỗi Dữ liệu nhập vào Output chương trình So sánh Hình 5.7(a): kiểm tra với lệnh write(có lỗi) Nếu output mong muốn là OK. Output mong muốn: Thỏa mãn Dữ liệu nhập vào So sánh Output chương trình Hình 5.7(b) : kiểm tra với lệnh write ( không có lỗi) Trường hợp với lệnh remove: đây là lệnh xóa dữ liệu, việc Test cũng như với lệnh write.Với mong muốn output là OK. Dữ liệu nhập vào Output mong muốn: Thỏa mãn So sánh Output chương trình Hình 5.7(c) : kiểm tra với lệnh remove( không có lỗi) Với mong muốn output là có lỗi: Output mong muốn: Có lỗi Dữ liệu nhập vào So sánh Output chương trình Hình 5.7(d) : kiểm tra chương trình với lệnh remove(có lỗi) 5.4.2. Kết quả Chương trình đã chạy thử và cho kết quả tốt. Khi Test với nhiều input khác nhau, chương trình đã chạy đúng và cho ra output đúng theo thuật toán. Chương trình đã Test tất cả các trường hợp được mô hình RBAC0 mô tả gồm: Trường hợp chỉ có một biểu thức điều kiện trực tiếp. Trường hợp có nhiều biểu thức điều kiện lồng nhau. Test với các lệnh ảnh hưởng trực tiếp đến hệ thống gồm write, remove … Tuy nhiên, nhược điểm lớn nhất của chương trình là giao diện chưa thân thiện. Kết quả chủ yếu chạy trên màn hình console. Tuy đáp ứng được về mặt thuật toán nhưng chương trình cũng mới dừng lại ở việc “hard-code” và kiểm chứng với mô hình RBAC0 chưa mở rộng với các mô hình phức tạp hơn. CHƯƠNG 6. KẾT LUẬN “Kiểm chứng cơ chế bảo mật dựa trên AST” là đề tài nghiên cứu mới. Đã có rất nhiều cơ chế bảo mật được phát triển với những ưu điểm và nhược điểm riêng. Trong các cơ chế bảo mật đáng quan tâm thì nổi bật nhất là RBAC (điều khiển truy cập dựa trên vai trò). RBAC là một mô hình điều khiển truy cập tối ưu, có thể quản lý người dùng và truy cập của họ một cách khoa học nhằm hạn chế tối đa những xâm phạm bất hợp pháp vào tài nguyên của hệ thống. Dựa trên các mô hình của RBAC, cụ thể là RBAC0 đề tài đã xây dựng bài toán kiểm chứng dựa trên cây cú pháp trừu tượng (AST). Sau khi hoàn thành, khóa luận đã đạt được những kết quả sau đây: Đã tìm hiểu chi tiết về các mô hình điều khiển truy cập, đánh giá được điểm mạnh và điểm hạn chế và những ứng dụng cụ thể của từng mô hình, đưa ra ứng dụng của từng mô hình trong thực tiễn. Đã tìm hiểu chuyên sâu về họ các mô hình điều khiển truy cập trên cơ sở vai trò (RBAC), phân tích chi tiết từng mô hình của RBAC và nhấn mạnh vào mô hình nền tảng RBAC0. Đã tìm hiểu bài toán kiểm chứng. Xây dựng mô hình duyệt cây cú pháp trừu tượng (AST), đưa ra thuật toán kiểm chứng hoàn thiện cho các mô hình của RBAC, đưa ra bài toán nhỏ để kiểm chứng mô hình RBAC0. Hoàn thành việc cài đặt và triển khai bài toán trên Eclipse tích hợp công cụ CDT. Đã đưa ra kết quả chạy chương trình hoàn toàn khớp với kết quả mong muốn, chương trình chạy ổn định khớp với thuật toán cả về mặt lý thuyết lẫn thực tiễn. Tuy nhiên do hạn chế về mặt thời gian nghiên cứu, khóa luận khó tránh khỏi những khiếm khuyết kể cả về mặt lý thuyết lẫn việc phân tích và thiết kế công cụ hỗ trợ. Những mặt hạn chế này bao gồm: Mới chỉ tìm hiểu ở mức độ cơ bản bài toán kiểm chứng. Dừng lại ở kiểm chứng mô hình RBAC0 và với mã nguồn C/C++. Vẫn còn “hard-code”, bài toán chưa mở rộng cho nhiều ngôn ngữ và các trường hợp Test chưa nhiều. Giao diện chạy chương trình còn đơn giản, chỉ là console. Chưa tạo giao diện input và output chuyên nghiệp. Trong tương lai, chúng tôi sẽ tiếp tục mở rộng đề tài này theo hướng nghiên cứu chuyên sâu về thuật toán để kiểm chứng với nhiều ngôn ngữ, mở rộng với nhiều mô hình RBAC hơn, không chỉ dừng lại ở RBAC0, tránh tối đa việc “hard-code”. Chương trình sẽ có giao diện chuyên nghiệp hơn và các chức năng sẽ thân thiện hơn với người sử dụng để ứng dụng thực tế trong lĩnh vực cụ thể. Tài liệu tham khảo [1] David F. Ferraiolo, Dennis M. Gilbert, and Nickilyn Lynch. An examination of federal and commercial access control policy needs. In NIST-NCSC National Computer Security Conference, pages 107{116, Baltimore, MD, September 20-23 1993. [2] Common Criteria Editorial Board. Common Criteria for Information Technology Security Evaluation, December 1994. Version 0.9, Preliminary Draft. [3] Imtiaz Mohammed and David M. Dilts. Design for dynamic user-role-based security. [4] Roshan Thomas and Ravi S. Sandhu. Conceptual foundations for a model of task based authorizations. In IEEE Computer Security Foundations Workshop 7. [5] Ravi S. Sandhu. Lattice-based access control models. IEEE Computer, 26(11):9{19, November 1993. [6] Dirk Jonscher. Extending access controls with duties|realized by active mecha- nisms. In B. Thuraisingham and C.E. Landwehr, editors, Database Security VI: Status and Prospects. [7] David Ferraiolo and Richard Kuhn. Role-based access controls. In 15th NIST-NCSC National Computer Security Conference. [8] M.-Y. Hu, S.A. Demurjian, and T.C. Ting. User-role based security in the ADAM object-oriented design and analyses environment. In J. Biskup, M. Morgernstern, and C. Landwehr, editors, Database Security VIII: Status and Prospects. North-Holland, 1995. [9] Matunda Nyanchama and Sylvia Osborn. Access rights administration in role-based security systems. In J. Biskup, M. Morgernstern, and C. Landwehr, editors, Database Security VIII: Status and Prospects. North-Holland, 1995. [10] S. H. von Solms and Isak van der Merwe. The management of computer security profiles using a role-oriented approach. [11] ISO/IEC 10040. Information Technology Open Systems Interconnection { Systems Management Overview. [12] Ravi S. Sandhu. The typed access matrix model. In Proceedings IEEE Com- puter Society Symposium on Research in Security and Privacy. [13] Jonathan D. Mo_ett and Morris S. Sloman. Delegation of authority. In I. Krishnan and W. Zimmer, editors, Integrated Network Management II. [14] Eduardo B. Fernandez, Jie Wu, and Minjie H. Fernandez. User group structures in object-oriented database authorization. In J. Biskup, M. Morgernstern, and C. Landwehr, editors, Database Security VIII: Status and Prospects. North-Holland, 1995. Phụ lục A1: Cài đặt Công cụ CDT 1. Khởi động Eclipse (GANYMEDE): vào Help chọn Software Updates Sẽ hiện ra giao diện sau : Nhấn nút này Ta chọn Add Site như trên thể hiện sẽ đến giao diện sau: Chọn Archive… để đến được vị trí của file CDT-mASTer-6.0.0-I200902031437.zip file này có thể download trên mạng theo địa chỉ: ông cụs/CDT/builds/6.0.0/I.I200902031437/index.html Đến các bước tiếp theo cứ thực hiện như cài đặt một chương trình phần mềm bình thường. 2. Cài đặt MinGW Chỉ cần download file MinGW-5.1.4.exe và tiến hành cài đặt là được Download ở trang: Giao diện khi cài đặt các bước lần lượt như sau: Nhấn vào đây Nhấn vào đây Nhấn vào đây Phụ lục A2: Cấu hình các file để chạy chương trình Test trên C/C++ 1. Thêm vào các thư viện liên quan Cấu hình trong file MANIFEST.MF File này Giao diện tiếp theo khi chọn để cấu hình: Chọn phần này Thêm các thành phần 2. Cấu hình lại các Plug-in Nội dung file plugin.xml phải như sau: <extension point="org.eclipse.ui.actionSets"> <actionSet label="VisitorCPPAST" visible="true" id="VisitorCPPAST.actionSet"> <menu label="Sample &Menu" id="sampleMenu"> <separator name="sampleGroup"> <action label="&Sample Action" icon="icons/tree.gif" class="visitorcppAST.actions.GetProject" công cụtip="Visitor" menubarPath="sampleMenu/sampleGroup" công cụbarPath="sampleGroup" id="visitorcppAST.actions.GetProject">