Kiểm chứng hiệu suất các cơ chế bảo mật dựa trên AST trong Eclipse 3.1.1

Giới thiệu

Nhiều tổ chức thích kiểm soát tập trung và duy trì quyền truy cập, không theo ý muốn cá nhân của người quản lí hệ thống lắm mà theo các chỉ dẫn bảo vệ của tổ chức. Một loạt sản phẩm cung cấp trực tiếp một dạng RBAC, các sản phẩm khác hỗ trợ những tính năng có liên quan chặt chẽ, ví dụ nhóm user, những tính năng này được sử dụng để thực hiện các role.

Nền tảng và động lực

Nghiên cứu này cũng đã nhận thấy việc cho phép các quản trị viên cấp hoặc hủy bỏ tư cách thành viên của các user trong các role đang tồn tại mà không cho các quản trị viên này quyền tạo role mới hay thay đổi sự phân chia role – permission là điều đang đựợc mong muốn. Sự tách biệt các nhiệm vụ đạt được bằng cách đảm bảo những role có quan hệ loại trừ lẫn nhau phải đựơc sử dụng tới để hoàn thành một công việc nhạy cảm như yêu cầu một nhân viên kế toán và một quản lí kế toán tham gia vào phát hành một tấm Sec.

Các vai trò và các khái niệm liên quan

DAC cho phép kiểm soát truy cập thực hiên được đối với khách thể (object) dựa trên cơ sở permission hoặc từ chối hoặc cả hai do một user riêng biệt, thường là người sở hữu object đó định dạng. Việc hiểu bắt buộc có nghĩa là các user cá nhân không có sự lựa chọn nào đối với việc permission hoặc user nào được giao đến một role nào, trong khi tùy ý có nghĩa là user được tự đưa ra các quyết định này.

Các mô hình một họ tham chiếu

Câu trả lời phụ thuộc vào định nghĩa chính xác của cái quan niệm “tùy ý” và “bắt buộc” cũng như là bản chất thực và sự định hình các permission, role và user trong một hệ thống RBAC. Hiên tại, cứ cho rằng có một security officer (nhân viên an ninh) là người duy nhất có thẩm quyền định ra các thiết lập và các mối liên hệ của những mô hình này.

Mô hình cơ sở

Mô hình chấp nhận một loạt các cách diễn giải khác nhau cho các permission, ví dụ, từ những hạt rất to và thô (từ những cái sơ lược nhất) ở đó được phép truy cập vào cả một mạng nhỏ, tới những hạt mịn (những cái tinh vi) nơi mà đơn vị truy cập chỉ là một lĩnh vực riêng nào đó của một bản chi nào đó. Sự sắp đặt một role như một phương tiện trung gian cho phép user thực hiện một permission tạo cho sự kiểm soát lớn lên sự định dạng và xem xét truy cập hơn nhiều so với việc để user tiếp cận trực tiếp với permission.

Role có cấp bậc

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. 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.

Các ràng buộ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. 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.

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.

Mô hình hợp nhấ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.

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.

Các mô hình quản lý

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.

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.

Cấu trúc của CDT

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. 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. Để 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.

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).

Những khía cạnh liên quan 1. Khía cạnh lý thuyế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. 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 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.

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.

Ứng dụng thuật toán 1. Khái quát về ứng dụ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.