KIỂM CHỨNG CƠ CHẾ BẢO MẬT DỰA TRÊN AST

- Danh sách các hình vẽ Hình 2.1: Một họ của các mô hình RBAC.
- Hình 2.2: Mô hình RBAC0 Hình 2.3: Các ví dụ của Role Hierarchies.
- Các mô hình một họ tham chiếu.
- Mô hình cơ sở.
- Mô hình hợp nhất.
- Các mô hình quản lý.
- CÁC MÔ HÌNH ĐIỀU KHIỂN TRUY CẬP.
- Các role cũng có thể có quan hệ kế thừa, theo đó một role kế thừa các permission được gắn cho role khác.
- Những mối quan hệ role – role này có thể được sử dụng để làm cho các chính sách bảo mật bao gồm sự tách rời các công việc và sự ủy thác của người có thẩm quyền.
- Với RBAC, người ta có thể xác định được các mối quan hệ role – permission.
- Các thành tố RBAC có thể đựợc định dạng trực tiếp bởi người sở hữu hệ thống hay gián tiếp bởi các role thích hợp mà người sở hữu hệ thống ủy thác.
- Ngoài ra chính sách điều khiển truy cập có thể gia tăng trong chu kì của hệ thống và ở các hệ lớn điều này là chắc chắn xảy ra.
- Nhân viên bảo mật có thể định dạng được RBAC do đó nó vi phạm những nguyên lí này.
- Về cơ bản, người sở hữu một sub-tree (cây con) của hệ thống file Unix có thể giao permission của sub-tree đó cho một nhóm.
- Tuy nhiên, nhóm Unix có thể được dùng để thực hiện role trong hoàn cảnh cụ thể mặc dù theo khái niệm role của chúng tôi các nhóm không giống nhau.
- Hãy cho rằng permission của nhóm và thành viên nhóm chỉ có thể được nhân viên bảo mật hệ thống thay đổi.
- RBAC có thể được xem như một thành tố kiểm soát truy cập độc lập, cùng tồn tại với MAC và DAC lúc thích hợp.
- (a) Quan hệ giữa các mô hình RBAC (b) Các mô hình RBAC.
- Hình 2.1: Một họ của các mô hình RBAC.
- Các permission có thể áp dụng cho một object hay nhiều object.
- Các permission cá nhân được cho vào một permission chung , do đó chúng có thể được giao với tư cách một đơn vị riêng biệt.
- một user có thể là một thành viên của nhiều role, và một role có thể có nhiều user.
- Tương tự như thế, một role có thể có nhiều permission, và cùng một permission có thể được giao cho nhiều role.
- Permission có thể được user kết hợp các permission từ tất cả các role được kích hoạt trong session đó.
- Mỗi session có thể có một sự kết hợp khác của những role hoạt động.
- Một user là thành viên của một vài role có thể gọi nhiều tập con của chúng mà phù hợp cho công việc đã hoàn thành trong session đó.
- Như vậy, một user là một thành viên của một role quyền lực nhất có thể thông thường giữ role không hoạt động này và rõ ràng kích hoạt nó khi cần thiết.
- Có thể trì hoãn sự xem xét của tất cả các loại của ràng buộc, bao gồm các ràng buộc trên các role đang hoạt động, với RBAC2.
- Hình 2.2: Mô hình RBAC0.
- Còn bây giờ thừa nhận rằng chỉ có một mình nhân viên bảo vệ có thể thay đổi những thành phần này.
- Như những mô hình có liên quan, một user có thể tạo ra một session và chọn để kích hoạt một vài tập con của những role của user.
- các role hoạt động trong một session có thể đuợc thay đổi trong sự thận trọng của user.
- 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].
- Hình 2.5: Mô hình tổng quát của RH (RBAC1).
- 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.
- Có thể gọi các role giống như Test Engine0 như các role riêng tư.
- 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.
- 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.
- 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.
- 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.
- 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..
- 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.
- 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.
- 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.
- 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ế.
- 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ụ, 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 đó.
- 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.
- 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.
- Một hệ thống thứ bậc role có thể được xem như một ràng buộc.
- 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).
- 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).
- 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ể.
- Giả sử một user có thể được gán nhiều nhất một role.
- 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.
- 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.
- Hình 2.6: Mô hình RBAC quản lý.
- Trong các hệ thống lớn số các role có thể là hàng trăm hay hàng nghìn.
- Ở đây chúng tôi chỉ có thể chạm vào một vài vấn đề lớn.
- 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.
- Mô hình quản lý RBAC được minh họa trong Hình 2.6.
- 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ý.
- 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ý.
- 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ó.
- 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.
- 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).
- 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.
- 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..
- 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ó.
- 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.
- 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.
- 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.
- 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.
- Đâ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 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.
- 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 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.
- 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..
- 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.
- 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