Tóm tắt luận văn Sự phát triển nhanh chóng của các hệ thống và dịch vụ dựa trên địa lý đã tạo ra một nhu cầu cấp thiết cho bài toán bảo mật dữ liệu không gian địa lý, trong đó, điều khiể
CƠ SỞ LÝ THUYẾT
Dữ liệu không gian là gì?
Soon Ae Chun và Vijayalakshmi Atluri [3] đã đƣa ra định nghĩa cho dữ liệu không gian nhƣ sau:
“Dữ liệu không gian (geospatial data) thường bao gồm bản đồ, hình ảnh trên không và vệ tinh, được kết hợp với những thông tin vị trí và đại diện bởi kinh độ, vĩ độ”
Dữ liệu không gian, hay còn gọi là dữ liệu địa lý, là thông tin địa lý về các đối tượng và hiện tượng có vị trí tương đối so với bề mặt Trái Đất Nói cách khác, đây là dữ liệu có tính tham chiếu không gian, giúp mô tả chính xác vị trí và mối quan hệ của các thực thể trên Trái Đất Dữ liệu không gian có nhiều ứng dụng thiết thực trong nhiều lĩnh vực như lập bản đồ, quy hoạch đô thị, quản lý tài nguyên đất đai và hệ thống thông tin địa lý (GIS).
Các đối tượng được nhắc đến ở đây có thể là: đường đi, mảnh đất, độ cao, cây, tòa nhà, con sông… Dữ liệu không gian đƣợc dùng để thể hiện các đối tƣợng bên ngoài thế giới thực; do đó, việc phân loại dữ liệu không gian cũng dựa vào đặc tính của các đối tƣợng ngoài thực tế
Những đặc tính của thế giới thực có thể chia làm hai loại cơ bản: đối tƣợng và hiện tƣợng [1]
Đối tượng: rời rạc và xác định, ví dụ như tòa nhà, đường cao tốc, thành phố, hay công viên…
Hiện tượng: đƣợc phân bố liên tục trên một diện tích lớn, chẳng hạn nhƣ địa hình, nhiệt độ, lượng mưa, cường độ âm thanh và các chỉ số môi trường khác
Tương ứng với hai hình thức cơ bản này sẽ có hai cách tiếp cận để biểu diễn thế giới thực trong cơ sở dữ liệu không gian: mô hình dựa trên đối tƣợng (object – based model) và mô hình dựa trên vùng (field – based model) [1]
Cách tiếp cận dựa trên đối tượng: thế giới thực sẽ đƣợc biểu diễn thông qua mô hình dữ liệu vector (vector data model) Các đối tƣợng không gian đƣợc xác định độc lập và biểu diễn thông qua tọa độ toán học Có nhiều biến thể của mô hình dữ liệu vector, tuy nhiên, các phương pháp và giải thuật sử dụng đều được xây dựng dựa trên hai khái niệm phổ biến và có quan hệ với nhau: (1) phân rã các đối tƣợng không gian thành những thành phần đồ họa cơ bản (điểm, đường, đa giác) và (2) sử dụng các cấu trúc liên kết (topology) hay còn gọi là các mối quan hệ không gian để biểu diễn các đối tƣợng không gian ngoài việc sử dụng tọa độ hình học
Ta sẽ xem xét một vài thành phần đồ họa cơ bản đƣợc sử dụng trong mô hình dữ liệu vector:
Hình 2.1 Ví dụ đơn giản về bản đồ vector o Điểm: đƣợc biểu diễn bằng một cặp tọa độ, là kiểu đơn giản nhất của dữ liệu vector Điểm thường được dùng để biểu diễn những vị trí đơn, ví dụ như giếng, đỉnh núi Ngoài ra, điểm cũng có thể đƣợc dùng để đại diện cho khu vực khi hiển thị ở quy mô nhỏ, chẳng hạn nhƣ thành phố trên bản đồ thế giới nên đƣợc biển diễn bằng điểm thay vì đa giác o Đường hoặc cung: bao gồm một chuỗi các điểm, thường được dùng để biểu diễn con sông, đường bộ, đường sắt, đường mòn và đường địa hình… o Đa giác: đƣợc sử dụng để biếu diễn các đối tƣợng không gian bao phủ trên một vùng xác định của bề mặt Trái Đất Ta có thể sử dụng đa giác để biểu diễn hồ, ranh giới các công viên, tòa nhà, ranh giới thành phố
Cách tiếp cận dựa trên vùng: thế giới thực sẽ đƣợc biểu diễn thông qua mô hình dữ liệu raster (raster data model), mô hình đƣợc dùng để biểu diễn các hiện tƣợng không gian trên một diện tích lớn Kiểu dữ liệu raster bao gồm dòng và cột của các ô, mỗi ô sẽ chứa một giá trị đơn Dữ liệu raster có thể là ảnh hoặc từng pixel chứa giá trị màu Các giá trị được lưu trữ trong mỗi ô có thể là giá trị rời rạc (ví dụ như đất sử dụng) hoặc giá trị liên tục (chẳng hạn như nhiệt độ) Về mặt lưu trữ, dữ liệu raster có thể được lưu dưới nhiều dạng, từ các tập tin cấu trúc chuẩn như TIF, JPEG… đến đối tượng dữ liệu nhị phân (BLOB) được lưu trực tiếp trong hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) Hình bên dưới là một ví dụ về việc sử dụng mô hình dữ liệu raster để biểu diễn các đối tƣợng không gian
Hình 2.2 Ví dụ về dữ liệu raster
Cả hai mô hình biểu diễn dữ liệu không gian bên trên đều có những ƣu và khuyết điểm riêng [1]
Bảng 2.1 Ƣu - khuyết điểm của mô hình dữ liệu vector và raster
Mô hình dữ liệu vector Mô hình dữ liệu raster
Ưu điểm: o Dữ liệu có thể đƣợc biểu diễn ở độ phân giải và dạng gốc mà không cần phải qua thao tác tổng quát hóa o Dữ liệu khi trình bày ở dạng đồ họa thì thường được đánh giá là đáp ứng yêu cầu về thẩm mỹ o Vị trí không gian chính xác của dữ liệu sẽ đƣợc duy trì, không thay đổi o Cho phép mã hóa hiệu quả các quan
Ưu điểm: o Vị trí không gian của mỗi cell thì đƣợc ngầm định là vị trí của nó trong ma trận o Dễ dàng hiện thực các tác vụ che phủ o Các thiết bị đầu ra dựa trên chuẩn raster rất thích hợp với những hệ thống lưới hệ không gian o Kích thước file thường nhỏ hơn so với dạng raster
Khuyết điểm: o Vị trí của mỗi cạnh cần được lưu trữ rõ ràng o Để phân tích hiệu quả, dữ liệu vector phải đƣợc chuyển đổi sang dạng cấu trúc liên kết (tức là các mối quan hệ không gian) Điều này đòi hỏi dữ liệu phải phong phú Bên cạnh đó, các cấu trúc liên kết là tĩnh, do đó bất kỳ sự thay đổi nào trên dữ liệu vector đều phải xây dựng lại các cấu trúc liên kết này o Các giải thuật để xử lý và phân tích dữ liệu rất phức tạp, đòi hỏi phải có sự chuyên sâu o Các dữ liệu liên tục, nhƣ dữ liệu về độ cao thì không thể đƣợc biểu diễn dưới dạng vector o Các thao tác phân tích không gian và lọc trong đa giác không thể thực hiện đƣợc
Khuyết điểm: o Kích thước của ô sẽ quyết định độ phân giải của dữ liệu đƣợc biểu diễn o Việc xử lý các thuộc tính dữ liệu liên quan có thể trở nên cồng kềnh nếu lƣợng dữ liệu lớn Bản đồ raster chỉ phản ánh thuộc tính hoặc đặc trƣng của một khu vực xác định o Đa số dữ liệu đầu vào đều ở dạng vector, do đó dữ liệu phải trải qua quá trình chuyển đổi vector – to – raster Bên cạnh đó, việc tổng quát hóa dữ liệu và lựa chọn kích thước ô không phù hợp có thể dẫn đến việc mất tính toàn vẹn của dữ liệu o Khi biểu diễn dữ liệu cho một vùng, dữ liệu raster đòi hỏi không gian lưu trữ nhiều hơn dạng vector (chỉ lưu ở những điểm cần thiết) o Hầu hết các bản đồ đầu ra của hệ thống lưới thì không đáp ứng được nhu cầu về chất lƣợng
Ngoài mô hình dữ liệu vector và raster, mô hình dữ liệu CAD và TIN (Triangulated Irregular Networks) cũng có thể được sử dụng Tuy nhiên, phạm vi bài viết sẽ chỉ tập trung vào mô hình dữ liệu vector, loại bỏ các mô hình dữ liệu còn lại.
Bảo mật dữ liệu không gian
Bảo mật dữ liệu không gian thường bao gồm ba khía cạnh chính: tính bí mật (confidentiality), tính toàn vẹn (integrity) và điều khiển truy xuất (access control) [6]
Tính bí mật: khi dữ liệu được truyền tải trên mạng, chỉ những người dùng hợp pháp mới có thể hiểu được nội dung truyền tải, với người dùng bất hợp pháp sẽ không hiểu đƣợc nội dung này ngay cả khi họ bắt đƣợc các gói tin trên mạng
Thông thường, để đảm bảo tính bí mật, các gói tin sẽ được mã hóa trước khi đưa lên đường truyền
Tính toàn vẹn: dữ liệu không gian không đƣợc phép bị giả mạo (thêm, xóa hay thay đổi) bởi người dùng bất hợp pháp Để đảm bảo tính toàn vẹn, ta có thể dùng kỹ thuật chữ ký số hoặc chữ ký điện tử
Điều khiển truy xuất: bao gồm hai ý chính (1) xác thực (authentication) và (2) ủy quyền (authorization) Xác thực là việc đảm bảo người dùng đăng nhập là người dùng hợp pháp của hệ thống Có nhiều cách để xác thực người dùng của hệ thống chẳng hạn nhƣ: dựa trên những gì họ biết (tên, mật khẩu truy cập), dựa trên những gì họ có (thẻ xác nhận) hoặc dựa trên bản thân người dùng (dấu vân tay)
Sau khi người dùng đăng nhập thành công vào hệ thống, họ sẽ được phân các quyền tương ứng với các đối tượng không gian mà họ cần truy cập, đây được gọi là giai đoạn ủy quyền Xác thực là điều kiện tiên quyết của ủy quyền
Tính bí mật và tính toàn vẹn cho dữ liệu không gian đã đƣợc đảm bảo bằng các giải pháp hiện có trong lĩnh vực công nghệ thông tin Tuy nhiên, điều khiển truy xuất cho dữ liệu không gian vẫn chƣa có những giải pháp thực sự thỏa đáng Do đó, đề tài này sẽ tập trung vào nghiên cứu vấn đề điều khiển truy xuất cho dữ liệu không gian.
CÁC CÔNG TRÌNH NGHIÊN CỨU LIÊN QUAN
Một số mô hình điều khiển truy xuất cho dữ liệu GIS
3.1.1 Khung điều khiển truy xuất tổng quát
Theo Sandhu R.S [7], khung điều khiển truy xuất tổng quát sẽ bao gồm các thành phần như hình vẽ bên dưới:
Hình 3.1 Khung điều khiển truy xuất tổng quát [7]
Authentication: mô hình xác thực người dùng
Authorization rules: tập các luật phân quyền đƣợc định nghĩa dựa theo mô hình
(hoặc ) Với S (Subject) là đại diện cho người dùng hoặc quá trình muốn truy xuất vào dữ liệu, O (Object) là đối tƣợng dữ liệu mà S muốn truy xuất, P (Privilege hay Permission) đại diện cho các tác vụ xác định mà S có thể thực hiện trên O, và C (Constraint) là những ràng buộc không gian có thể có
Resources: là dữ liệu đích mà người dùng dự định truy xuất vào
PIP: Policy Information Point, có nhiệm vụ tạo mới và chỉnh sửa các luật phân quyền nằm trong Authorization rules để phù hợp với nhu cầu nghiệp vụ
PEP: Policy Enforcement Point, chuyển đổi các yêu cầu nhận được từ phía người dùng sang dạng tương thích với các luật phân quyền được chứa trong Authorization rules, hoặc chuyển đổi các quyết định từ PDP sang dạng người dùng có thể hiểu đƣợc
PDP: Policy Decision Point, tìm các luật phân quyền có liên quan, so sánh với yêu cầu của người dùng (được chuyển từ PEP) và đưa ra quyết định, chuyển quyết định này cho PEP
Cơ chế hoạt động của khung điều khiển có thể tóm lược như sau: trước hết, người dùng phải xác nhận thành công là người dùng hợp lệ của hệ thống; PEP nhận yêu cầu từ phía người dùng và chuyển sang dạng tương thích với các luật phân quyền được đã được định nghĩa từ PIP (ở đây, yêu cầu thường được chuyển sang dạng GeoXACML cho dữ liệu không gian) PEP sẽ chuyển các yêu cầu này cho PDP; PDP sẽ tìm các luật phân quyền có liên quan và so sánh với các yêu cầu này từ đó đƣa ra quyết định (cho phép hoặc từ chối) đồng thời chuyển quyết định ngƣợc lại cho PEP PEP tiếp tục chuyển các quyết định sang định dạng mà người dùng có thể hiểu được và trả kết quả về cho người dùng
Các mô hình được đề xuất trong phần tiếp theo sẽ là sự mở rộng và cải tiến của khung này để hỗ trợ việc truy vấn dữ liệu không gian.
3.1.2 Cơ chế điều khiển truy xuất dựa trên SDE (Spatial Data Engine)
Dữ liệu không gian trong các hệ thống GIS chủ yếu được lưu trữ và quản lý bằng cơ sở dữ liệu Do đặc điểm phức tạp và không có cấu trúc cố định nên dữ liệu không gian không thể lưu trữ trực tiếp trong hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) SDE là công nghệ đƣợc phát triển để quản lý các đặc tính không gian và phi không gian của dữ liệu không gian trong RDBMS Vì vậy, việc điều khiển truy xuất dữ liệu không gian cũng có thể đƣợc thực hiện thông qua SDE [8]
Chức năng chính của SDE là quản lý các dữ liệu không gian phi cấu trúc sang cấu trúc của RDBMS, vì vậy, đây được xem là nơi lý tưởng để đưa ra quyết định lưu trữ dữ liệu không gian trong cơ sở dữ liệu khi xét đến khía cạnh ngữ nghĩa không gian
Trong cơ sở dữ liệu, hầu hết các đối tƣợng không gian trong cùng một lớp bản đồ sẽ được lưu trong cùng một bảng (table) Mỗi đối tượng không gian được đại diện là một dòng (record) của bảng Các thuộc tính không gian của đối tượng được lưu thành từng trường (field) trong dòng và thường được lưu ở dạng BLOB Ta có thể xem SDE như thành phần trung gian có nhiệm vụ chuyển đổi dữ liệu không gian nhị phân sang ý nghĩa hình học và ngƣợc lại Bên cạnh đó, SDE còn cung cấp những hàm Boolean để đánh giá mối quan hệ không gian giữa các đối tƣợng, chẳng hạn nhƣ hàm nằm trong (within), chứa (contains)… và các hàm phân tích không gian nhƣ bao phủ (overlay), đệm (buffer) để tạo dữ liệu không gian mới
Hình 3.2 Cơ chế điều khiển truy xuất dựa trên SDE [8]
Trong hệ thống điều khiển truy xuất dựa trên mô hình dữ liệu không gian (SDE), dữ liệu được bảo vệ là các bảng, trong đó mỗi dòng bảng biểu diễn một đối tượng trong không gian SDE đảm nhiệm vai trò của PEP, PDP và PIP Ngoài ra, thông tin phân quyền cũng được lưu trữ trong cùng cơ sở dữ liệu với dữ liệu không gian, giúp quản lý truy cập hiệu quả hơn.
SDE không có chức năng xác thực người dùng riêng mà hoàn toàn dựa vào cơ chế do cơ sở dữ liệu cung cấp SDE đƣợc ví nhƣ vùng trung gian nằm ở phía server (cùng với RDBMS) cung cấp các API tương tác với cả người dùng và RDBMS Người dùng sẽ gửi các yêu cầu truy cập dữ liệu không gian đến SDE (thông qua các API), tùy thuộc vào yêu cầu nhận từ phía người dùng, SDE sẽ dịch các yêu cầu này sang chuẩn SQL và truy xuất RDBMS (thông qua API) để lấy dữ liệu BLOB Cuối cùng, SDE lại chuyển các dữ liệu nhị phân BLOB sang dạng dữ liệu không gian ngữ nghĩa và trả về cho người dùng
Do SDE không có cơ chế xác thực riêng nên thông tin xác thực người dùng sẽ được lưu trực tiếp trong cơ sở dữ liệu Các bảng lưu thông tin xác thực sẽ chứa dữ liệu người dùng hợp lệ và quyền tương ứng Đối với bản đồ phân lớp, lược đồ của mỗi lớp sẽ có thêm trường người dùng và quyền hạn, có giá trị khi tạo lớp tương ứng với yêu cầu phân quyền Đối với thuộc tính, việc thay đổi lược đồ cũng tương tự như vậy.
Với những đặc điểm trên, việc hiện thực theo cơ chế dựa trên SDE đƣợc đánh giá là khá phức tạp và tốn nhiều chi phí [8]:
Việc duy trì các thông tin phân quyền tốn nhiều chi phí và chính sách phân quyền được đánh giá là thiếu tính linh hoạt Các lược đồ phải mở rộng để lưu thông tin phân quyền, càng nhiều lƣợc đồ phải thay đổi thì chi phí bỏ ra càng lớn
Hiện tại, hầu hết các sản phẩm SDE hiện nay không cung cấp cơ chế điều khiển không gian Ngoài ra, để thêm chức năng phân quyền thì mã nguồn của SDE phải đƣợc thay đổi phù hợp với quyết định phân quyền Hơn nữa, các sản phẩm SDE đều có bản quyền nên không thích hợp cho các công ty vừa và nhỏ Để giảm chi phí hiện thực kể trên, hệ quản trị cơ sở dữ liệu quan hệ đối tƣợng (ORDBMS) ra đời giúp các đối tượng không gian có thể được lưu trữ và quản lý mà không cần thông qua SDE Cơ chế điều khiển truy xuất dựa trên hệ quản trị ORDBMS này sẽ đƣợc giới thiệu ở phần tiếp theo
3.1.3 Cơ chế điều khiển truy xuất dựa trên view
Những trở ngại khi hiện thực cơ chế điều khiển truy xuất dựa trên SDE trong RDBMS sẽ đƣợc tinh chế khi hiện thực bằng cơ chế điều khiển truy xuất dựa trên view trong ORDBMS Cơ chế dựa trên view bao gồm bốn thành phần cơ bản sau: tài khoản cơ sở dữ liệu, đăng nhập cơ sở dữ liệu (xác thực), đặc quyền và views [8]
Hình 3.3 Cơ chế điều khiển truy xuất dựa trên view [8] Để hiện thực cơ chế này, đầu tiên ta sẽ tạo một tập các view (View1, View2, …) từ bảng gốc trong cơ sở dữ liệu không gian, mỗi view sẽ tương ứng với các yêu cầu và giới hạn truy cập khác nhau, bất kể đó là dữ liệu không gian hay phi không gian Sau đó, những view này sẽ đƣợc gán cho các tài khoản cơ sở dữ liệu với những mức bảo mật và đặc quyền truy cập khác nhau Sau khi người dùng được xác thực bằng cơ sở dữ liệu không gian, người dùng sẽ được gán các đặc quyền truy xuất lên những view xác định, các view này đƣợc xem nhƣ là một tập con của toàn bộ tập dữ liệu
XACML và GeoXACML
eXtensible Access Control Markup Language (XACML) là một chuẩn đƣợc định nghĩa bởi tổ chức OASIS (Organization for the Advancement of Structured Information Standards), đây vừa là ngôn ngữ đặc tả chính sách bảo mật, vừa có thể đặc tả các yêu cầu truy xuất và kết quả trả về từ việc đánh giá yêu cầu [15] Ngôn ngữ đặc tả chính sách thường được dùng để mô tả các yêu cầu điều khiển truy xuất với những điểm mở rộng theo chuẩn bao gồm các hàm, kiểu dữ liệu, kết hợp luận lý… Trong khi đó, ngôn ngữ đặc tả yêu cầu truy xuất hoặc kết quả cho phép người dùng định dạng các câu truy vấn để xác định một hành động cụ thể nào đó có đƣợc phép thực hiện hay không Câu trả lời cho yêu cầu này sẽ bao gồm kết quả đánh giá câu truy vấn với những giá trị nhƣ sau:
Cho phép: người dùng có thể thực hiện hành động đã được đánh giá (ví dụ truy xuất, xóa…) trên một nguồn dữ liệu đã xác định trước, với một điều kiện ngữ cảnh xác định
Không cho phép: người dùng không được phép thực hiện hành động đã yêu cầu
Không xác định: giá trị trả về trong trường hợp có lỗi xảy ra trong quá trình đánh giá (thiếu thông tin yêu cầu hoặc chương trình không thể đưa ra quyết định)
Không áp dụng: chương trình không thể đánh giá được yêu cầu truy xuất
So sánh với những ngôn ngữ đặc tả khác, XACML có những lợi thế khiến ngôn ngữ này trở nên phổ biến [15]:
Tính tiêu chuẩn, standard: XACML là chuẩn đƣợc xem xét bởi một cộng đồng lớn các chuyên gia và người dùng Điều này có nghĩa là người dùng không cần phải suy nghĩ về tất cả các vấn đề khó khăn liên quan đến việc thiết kế một ngôn ngữ mới Thêm vào đó, XACML ngày càng đƣợc triển khai rộng rãi hơn Do đó, sẽ dễ dàng hơn để tương thích với các ứng dụng khác bằng cách sử dụng cùng một ngôn ngữ tiểu chuẩn
Tính tổng quát, generic: XACML có thể được sử dụng trong bất kỳ môi trường nào Một chính sách bảo mật có thể đƣợc sử dụng bởi nhiều ứng dụng khác nhau và khi dùng chung một ngôn ngữ, việc quản lý chính sách sẽ trở nên dễ dàng hơn
Tính phân bố, distributed: một chính sách bảo mật có thể tham khảo đến những chính sách khác; vì vậy, những người dùng hoặc các nhóm khác nhau có thể quản lý những phần nhỏ tương ứng của chính sách
Tính mạnh mẽ, powerful: XACML hỗ trợ rất nhiều loại dữ liệu và hàm khác nhau cũng nhƣ các quy định về cách kết hợp kết quả đánh giá của các chính sách khác nhau Bên cạnh đó, đã có những nhóm tiêu chuẩn liên kết với XACML tạo thành các tiêu chuẩn khác (nhƣ SAML và LDAP), từ đó làm tăng khả năng sử dụng cho XACML
Mặc dù XACML có nhiều phiên bản khác nhau, nhƣng hầu hết các phiên bản này sẽ có những thành phần cơ bản sau [15]:
Mỗi chính sách XACML bao gồm một thẻ gốc XML Policy hoặc PolicySet PolicySet có thể chứa các Policy hoặc PolicySet khác, cũng như tham chiếu đến các Policy được lưu trữ từ xa Mỗi Policy thể hiện chính sách kiểm soát truy cập thông qua một tập hợp các Rule.
Vì mỗi Policy hoặc PolicySet có thể có những quyết định khác nhau khi đánh giá yêu cầu truy xuất, vì vậy XACML cần một cách để kết hợp đa quyết định thành một quyết định đơn duy nhất và gọi là giải thuật kết hợp (Combining Algorithm)
XACML cung cấp Policy Combining Algorithm cho PolicySet và Rule
Rule: thành phần quan trọng trong hầu hết các Rule là Condition đƣợc biểu diễn bằng hàm Boolean Kết quả đánh giá của Condition cũng chính là kết quả đánh giá của Rule
Target: Target đƣợc dùng để tìm các chính sách có thể áp dụng để đánh giá yêu cầu truy xuất Các hàm Boolean sẽ đƣợc dùng để so sánh các giá trị đƣợc tìm thấy trong yêu cầu với những giá trị tương ứng trong Target Thông tin chi tiết về thành phần này sẽ đƣợc trình bày trong những phần tiếp theo
Attribute, Attribute Value và Function: Attribute là tên giá trị của kiểu dữ liệu và biểu diễn đặc tính của các đối tƣợng đƣợc yêu cầu truy xuất tạo ra (ví dụ nhƣ Subject, Resource, Action, Environment…) Trong khi đó, Attribute Value thể hiện giá trị của Atrribute, ví dụ tên của người dùng, tên file mà người dùng muốn truy xuất, thời gian truy xuất… XACML cung cấp hai cơ chế để lấy giá trị của các thuộc tính này: AttributeDesignator và AttributeSelector AttributeDesignator đƣợc dùng để xác định một thuộc tính thông qua tên và loại của thuộc tính này;
AttributeSelector cho phép một chính sách tìm kiếm các thuộc tính thông qua các câu truy vấn XPath Sau khi các thuộc tính này đƣợc truy xuất, một hệ thống các hàm (Function) sẽ đƣợc sử dụng để đƣa ra đánh giá Các Function này có thể áp dụng trên bất kỳ giá trị thuộc tính nào, có thể lồng nhau và người dùng cũng có thể tùy chỉnh các Function theo yêu cầu riêng của họ
Phiên bản hiện tại của XACML là 3.0; tuy nhiên, GeoXACML phiên bản đầu tiên đƣợc xây dựng dựa trên XACML 2.0 Vì vậy, phần tiếp theo sẽ trình bày sự khác biệt giữa hai phiên của của XACML và đề xuất phiên bản sẽ sử dụng cho mô hình điều khiển truy xuất của đề tài
3.2.1 Sự khác biệt giữa XACML 2.0 và 3.0
So với phiên bản 2.0, XACML 3.0 có những ƣu điểm có thể kể đến nhƣ sau [16]: đầu tiên, XACML 3.0 hỗ trợ cách biểu diễn thành phần uyển chuyển hơn; Bảng 3.3 trình bày một ví dụ về khả năng biểu diễn của trong XACML 2.0 và 3.0
Bảng 3.3 Khả năng biểu diễn của trong XACML 2.0 và 3.0
Bác sĩ xem thông tin bệnh nhân Có hỗ trợ Có hỗ trợ Bác sĩ hoặc y tá xem thông tin bệnh nhân Có hỗ trợ Có hỗ trợ
Bác sĩ hoặc y tá xem hoặc chỉnh sửa thông tin bệnh nhân
Có hỗ trợ Có hỗ trợ Bác sĩ xem và y tá chỉnh sửa thông tin bệnh nhân Không hỗ trợ Có hỗ trợ
Lý do của sự khác nhau này là cách tổ chức thành phần trong hai phiên bản
Kết luận
Ta trở lại với Bảng 3.1 và 3.2 để nhắc lại về các giới hạn điều khiển truy xuất cho dữ liệu GIS mà mô hình đề xuất sẽ hỗ trợ Bảng 3.4 trình bày một cái nhìn tổng quan về các mô hình điều khiển truy xuất và các ngôn ngữ đặc tả chính sách bảo mật
Bảng 3.4 Mô hình đề xuất với các loại điều kiện ngữ cảnh khác nhau
Người dùng Dữ liệu Object khác
Năm đề xuất Không gian Thời gian Không gian Thời gian Không gian Thời gian
2012 STRoBAC _ (Ro + Ru) (Ro + Ru)
Với ý nghĩa của các ký hiệu nhƣ sau:
: mô hình có hỗ trợ loại điều kiện này
_: mô hình không có hỗ trợ loại điều kiện này
?: không có thông tin rõ ràng là mô hình có hỗ trợ loại điều kiện này hay không
E: trường hợp khẩn cấp, emergency
UD: điều kiện do người dùng tự định nghĩa, user define
Nhƣ đã giới thiệu ở các phần trên, các mô hình điều khiển truy xuất hiện có không thể hỗ trợ một cách toàn diện các yêu cầu giới hạn truy xuất đã nêu ở bảng 3.1; do vậy, mô hình đề xuất của đề tài (STRoBAC) mong muốn có thể hỗ trợ các yêu cầu này Cụ thể là giới hạn truy xuất dựa trên vị trí của người dùng (khía cạnh không gian của người dùng), thời gian người dùng gửi yêu cầu lên hệ thống (khía cạnh thời gian của người dùng), vùng không gian mà dữ liệu mô tả (khía cạnh không gian của dữ liệu), giới hạn truy xuất dựa trên vai trò (role), luật (rule) và các giải thuật kết hợp (khía cạnh không – thời gian của các đối tượng khác) Lưu ý rằng vì giới hạn thời gian nên mô hình STRoBAC trong đề tài không hỗ trợ khía cạnh thời gian của dữ liệu (thời gian dữ liệu mô tả hoặc thời gian dữ liệu được lưu trong cơ sở dữ liệu)
Tóm lại, mô hình đề xuất của đề tài sẽ dựa trên mô hình STRBAC để định nghĩa các thông tin về không – thời gian; đồng thời cách biểu diễn các điều kiện ngữ cảnh của mô hình Or-BAC cũng sẽ đƣợc sử dụng; ngoài ra, đề tài cũng mở rộng GeoXACML dựa trên XACML 3.0 (có hỗ trợ RBAC) để hiện thực mô hình đề xuất
Ngoài ra, một mô hình khác cũng có thể đƣợc đề cập đến là X-STROWL [42]; đây là mô hình có ý tưởng gần với STRoBAC nhưng được phát triển độc lập tại cùng thời điểm
X-STROWL tập trung vào việc tích hợp XACML với OWL ontology cho những suy luận ngữ nghĩa trên phân cấp role và mô tả các ràng buộc ngữ cảnh một cách chung nhất, thay vì đề xuất quy tắc biểu diễn chính sách chung với các ràng buộc không – thời gian nhƣ mô hình của đề tài
Nhƣ vậy, các công thức biểu diễn điều kiện ngữ cảnh cũng nhƣ định nghĩa kiểu dữ liệu và hàm mới là những việc cần làm khi định nghĩa mô hình đề xuất của đề tài, chi tiết hơn về mô hình này sẽ đƣợc trình bày trong phần tiếp theo.
STRoBAC MODEL
Các khái niệm cơ bản
Tương tự như mô hình Or-BAC, STRoBAC có những tập cơ bản sau: S (tập các subject), A (tập các action), O (tập các object), R (tập các role), A (tập các activity), V
(tập các view), và C (tập các context), (org sẽ không đƣợc xem xét trong mô hình) Bất kỳ thực thể nào trong mô hình STRoBAC đều có một hoặc nhiều thuộc tính, các thuộc tính này đƣợc biểu diễn bằng các vị từ liên kết giữa thực thể và giá trị của thuộc tính; những vị từ này sẽ đƣợc dùng để xác định các chính sách bảo mật trong mô hình STRoBAC Ví dụ, nếu s là một subject thì Work_in(s, Department) sẽ trả về true nếu s làm việc trong Department.
Cách thức tổ chức các thành phần
Chúng ta hãy trở lại phần 3.1.7 Organization Based Access Control – OrBAC để nhắc lại về dạng luật tổng quát của chính sách đƣợc mô tả trong mô hình Or-BAC nhƣ sau:
org Org, s S, A, o O, r R, a A, v V, c C Permission(org, r, a, v, c) Empower(org, s, r) Use(org, o, v)
Is_permitted(s, , o) và phần 3.2.4 XACML 3.0 Core và RBAC, giới thiệu về cách mở rộng RBAC cho XACML Cụ thể là các thành phần REA, VEA, AEA, và CEA đƣợc dùng để gán subject cho role, dùng object trong view, gán action vào activity và đánh giá các context giữa subject, action và object Kết hợp hai phần này lại, các vị từ của Or-BAC có thể đƣợc thay thế nhƣ sau:
Empower(org, s, r) đƣợc thay bằng REA(s, r),
Use(org, o, v) đƣợc thay bằng VEA(o, v),
Consider(org, , a ) đƣợc thay bằng AEA(, a),
Hold(org, s, , o, c) đƣợc thay bằng CEA(s, , o, c)
Ngoài ra, dựa vào mô hình RBAC đƣợc trình bày ở tài liệu [10], permission định nghĩa action nào đƣợc thực thi trên object nào; vì vậy, vị từ Permission(org, r, a, v, c) sẽ đƣợc thay bằng sự kết hợp của Permission(p, a, v) và PEA(p, r, c) Trong đó, Permission(p, a, v) định nghĩa permission p đƣợc thực thi activity a trên view v, và PEA(p, r, c) gán permission p cho role r trong điều kiện ngữ cảnh c Hơn nữa, mô hình
STRoBAC không những xem xét các điều kiện ngữ cảnh giữa subject, action và object mà còn xem xét ngữ cảnh khi gán subject cho role, sử dụng object trong view, xem xét dùng action trong activity và gán permission cho role Vì vậy, thành phần context c sẽ đƣợc thêm vào trong mỗi vị từ phía trên, cụ thể nhƣ sau:
REA(s, r, c) trả về true nếu trong ngữ cảnh c, subject s đƣợc gán role r,
VEA(o, v, c) trả về true nếu trong ngữ cảnh c, object o đƣợc sử dụng trong view v,
AEA(, a, c) trả về true nếu trong ngữ cảnh c, action đƣợc xem xét dùng trong activity a,
PEA(p, r, c) trả về true nếu trong ngữ cảnh c, permission p đƣợc gán cho role r
Những phần tiếp theo sẽ trình bày chi tiết hơn về những định nghĩa này.
Định nghĩa role, activity và view
Các role trong mô hình STRoBAC được định nghĩa tương ứng bằng một luật luận lý có vị từ REA đặt ở phần kết luận (vế phải của luật) Ta xem xét lại ví dụ sau “một người làm việc trong Bộ Quốc phòng được phép truy xuất các vị trí phòng thủ quan trọng trên lớp bản đồ nếu ông ấy đang đứng trong văn phòng của mình”, tuy nhiên, ta xét thêm điều kiện ngữ cảnh khi gán role cho subject, chính sách trên trở thành “một nhân viên giữ vai trò Observer (người giám sát) trong Bộ Quốc Phòng được phép truy xuất các vị trí phòng thủ quan trọng trên lớp bản đồ nếu ông ấy đang đứng trong văn phòng của mình; nhân viên có số năm làm việc từ 5 năm trở lên và có thời gian làm việc từ 7 giờ sáng đến 11 giờ sáng sẽ được gán role Observer” Định nghĩa của role Observer trong trường hợp này sẽ đƣợc biểu diễn nhƣ sau:
Work_in(s, DD) Working_years(s, d) (d > 5) Working_time(s, 7, 11)
Trong đó, Working_years(s, d) trả về true nếu d là số năm làm việc của đối tượng s Còn Working_time(s, 7, 11) trả về true nếu thời gian làm việc của s nằm trong khoảng 7 giờ đến 11 giờ sáng Tương tự, activity và view cũng được định nghĩa dựa theo luật gán hành động trong activity và gán đối tượng cho view.
Định nghĩa context
Ngữ cảnh đƣợc xét trong phần này là ngữ cảnh giữa subject, action và object Sử dụng lại ví dụ phía trên với ngữ cảnh thời gian đƣợc thêm vào “thời gian truy xuất của subject phải nằm trong khoảng từ 7 giờ đến 11 giờ sáng”, định nghĩa của ngữ cảnh trong trường hợp này được biểu diễn như sau:
CEA(s, , o, Persional_office&Request_time)
(Personal_office(s, po) Is_located(s, po)) Request_time(s, 7, 11)
Personal_office(s, po) trả về True nếu po là văn phòng cá nhân của s Is_located(s, po) trả về True nếu s đang đứng trong văn phòng của mình Request_time(s, 7, 11) trả về True nếu thời gian gửi truy xuất của s nằm trong khoảng từ 7 giờ đến 11 giờ sáng.
Định nghĩa policy
Bây giờ, các chính sách có thể đƣợc biểu diễn bằng cách thành phần của mô hình STRoBAC đã đƣợc định nghĩa phía trên nhƣ sau:
Trong đó c có thể là c 1 , c 2 , c 3 , c 4 hoặc kết hợp giữa những yếu tố này Ví dụ phía trên đƣợc trình bày đầy đủ nhƣ sau “một nhân viên giữ vai trò Observer (người giám sát) trong Bộ Quốc Phòng được phép truy xuất các vị trí phòng thủ quan trọng trên lớp bản đồ nếu ông ấy đang đứng trong văn phòng của mình và thời gian gửi yêu cầu truy xuất nằm trong khoảng 7 giờ đến 11 giờ sáng; nhân viên có số năm làm việc từ 5 năm trở lên và có thời gian làm việc từ 7 giờ sáng đến 11 giờ sáng sẽ được gán role Observer”
s S, A, o O, REA(s, Observer, Working_time) VEA(o, Specific_Map_Layer)
AEA(, Access) PEA(Access_Specific_Layer, Observer)
CEA(s, , o, Personal_office&Request_time)
Permission(Access_Specific_Layer, Access, Specific_Map_Layer)
Trong đó, vị từ Permission định nghĩa quyền Access_Specific_Layer đƣợc thực thi activity Access trên view Specific_Map_Layer, các ngữ cảnh của VEA, AEA và PEA không đƣợc xét đến trong ví dụ này Ngoài ra, định nghĩa của Is_prohibited, Is_obliged và Is_dispensed cũng được biểu diễn theo cách tương tự
4.6 Định nghĩa khái niệm không – thời gian
Các khái niệm về không – thời gian trong mô hình STRBAC (phần 3.1.5) có thể đƣợc biểu diễn bằng các vị từ của mô hình STRoBAC, một vài vị từ cơ bản đƣợc sử dụng nhƣ sau (tương tự như các vị từ của mô hình Or-BAC): Before_Time, After_Time, Before_Date, After_date, On_Day, Is_Located, Location… Ví dụ, một số khái niệm không – thời gian có thể đƣợc biểu diễn nhƣ sau:
Logical location (vị trí luận lý): các vị từ Location và Is_Located sẽ đƣợc sử dụng để xác định vị trí của subject hoặc subject có nằm trong một vùng xác định cho trước hay không,
Khoảng thời gian không lặp lại là khoảng thời gian xác định cố định như "thời gian giữa ngày 22 tháng 2 năm 2012 đến ngày 28 tháng 2 năm 2012" Trong mô hình STRBAC, khoảng thời gian này được biểu diễn dưới dạng (2012/02/22 … 2012/02/28) Trong mô hình STRoBAC, khoảng thời gian này được biểu diễn dưới dạng After_Date(2012/02/22) & Before_Date(2012/02/28).
Recurring Interval (thời khoảng lặp lại): ví dụ “thời gian giữa 9 giờ sáng đến 5 giờ chiều, trừ khoảng thời gian từ 12 giờ 30 phút chiều đến 1 giờ 30 phút chiều” có thể đƣợc biểu diễn trong mô hình STRBAC nhƣ sau
((09:00:00 … 17:00:00) - (12:30:00 … 13:30:00)) và trong mô hình STRoBAC:
Ngoài ra, dựa theo tài liệu [10], vì thông tin vị trí trong các chính sách bảo mật luôn được biểu diễn dưới dạng vị trí luận lý nên cách biểu diễn vị trí vật lý (vị trí thực, physical location) trong mô hình STRoBAC sẽ không đƣợc xem xét Thêm vào đó, nhƣ đã đề cập ở phần 3.2, XACML và GeoXACML không hỗ trợ đầy đủ các điều kiện ngữ cảnh cần thiết, vì vậy, phần tiếp theo sẽ trình bày cách mở rộng GeoXACML để hỗ trợ cho mô hình STRoBAC đã đề xuất
4.7 Mở rộng GeoXACML để hỗ trợ STRoBAC
Mặc dù GeoXACML là một phần mở rộng của XACML, nhƣng cả hai đều sử dụng cùng một quy trình đánh giá yêu cầu truy xuất của người dùng [17] [18]; vì vậy việc mở rộng GeoXACML phải dựa trên quy trình này để đảm bảo rằng GeoXACML sau khi mở rộng có thể tương thích với những phiên bản trước đó Để hỗ trợ mô hình STRoBAC, một vài thành phần sẽ đƣợc thêm vào trong quy trình, cụ thể là REA, VEA, AEA, CEA và PEA; tuy nhiên, nhƣ đã đề cập ở những phần trên, thành phần PEA trong quy trình sẽ bao gồm VEA và AEA Nhƣ vậy, sơ đồ dòng dữ liệu của quy trình đánh giá yêu cầu truy xuất cho GeoXACML mở rộng có thể được biểu diễn như hình 4.1 bên dưới
Hình 4.1 Sơ đồ dòng dữ liệu cho mô hình STRoBAC
Quy trình bắt đầu bằng những bước cơ bản được thực hiện tương tự như những bước đầu trong quy trình của XACML (1-5) Thành phần Context Handler sẽ đảm nhận nhiệm vụ thu thập tất cả các thông tin cần thiết và trả về cho PDP (23) Cụ thể nhƣ sau, Context
Handler gửi yêu cầu (6) và nhận (19) danh sách các role đƣợc lựa chọn từ RoleEA; tuy nhiên, để đánh giá role nào là role đƣợc lựa chọn, RoleEA cần biết các thông tin về thuộc tính của những role này (7), vì vậy yêu cầu đƣợc gửi một lần nữa từ Context Handler đến
PIP (8) PIP sẽ lấy những thông tin này từ Repository (9) và trả về cho Context Handler
(10) Bên cạnh đó, vì vị từ REA có thêm yếu tố ngữ cảnh c trong phần định nghĩa, do đó
Context Handler cần đánh giá ngữ cảnh trước khi trả các thuộc tính của role về cho RoleEA (11) Tương tự như RoleEA, ContextEA cũng cần các thông tin thuộc tính ngữ cảnh, vì vậy bước 12-15 được thực hiện tương tự như bước 7-10 Sau khi nhận được các thông tin cần thiết (16), ContextEA đánh giá ngữ cảnh và trả kết quả về cho Context
Handler (17) Sau đó, RoleEA nhận các thông tin về role (18) và trả danh sách các role được lựa chọn cho Context Handler (19) Lưu ý rằng các bước tương ứng với
Song song với RoleEA, PermissionEA cũng được thực hiện tương tự ở các bước tương ứng Context Handler yêu cầu PIP cung cấp các thông tin khác cần thiết, chẳng hạn như số lượng yêu cầu truy xuất đã gửi từ file log Sau đó, Context Handler trả toàn bộ thông tin này về PDP Đối với yếu tố ngữ cảnh còn lại trong công thức chung của mô hình STRoBAC, ContextEA đánh giá và trả kết quả cho PDP Các bước cuối cùng trong quy trình được thực hiện tương tự như XACML.
Lưu ý rằng vì quy trình trên được mở rộng nên số bước cần thực hiện để đánh giá một yêu cầu truy xuất sẽ tăng lên và thời gian xử lý có thể dài hơn so với quy trình ban đầu Để giải quyết vấn đề này, chúng ta có thể xem xét việc đánh chỉ mục các chính sách để rút ngắn thời gian tìm chính sách phù hợp với yêu cầu truy xuất; hoặc ta cũng có thể xét đến giải pháp tối ƣu các giải thuật đánh giá ngữ cảnh (đánh giá mối quan hệ không gian giữa các đối tƣợng, hoặc đánh giá các ràng buộc về thời gian) Tuy nhiên, hiệu suất của hệ thống và bài toán tối ƣu không nằm trong khuôn khổ của đề tài luận văn
Tóm lại, mô hình STRoBAC sử dụng khái niệm về không – thời gian từ mô hình STRBAC, áp dụng cách mô tả điều kiện ngữ cảnh của mô hình Or-BAC và các khái niệm về Enablement Authority trong phần mở rộng của RBAC cho XACML; đồng thời, STRoBAC cũng xét thêm các điều kiện ngữ cảnh khi gán role cho subject, xem xét dùng view cho object, activity cho action và gán permission vào role Ngoài ra, GeoXACML sẽ đƣợc mở rộng để hiện thực mô hình STRoBAC, phần tiếp theo sẽ trình bày chi tiết hơn về cách hiện thực mô hình của đề tài.
Mở rộng GeoXACML để hỗ trợ STRoBAC
Mặc dù GeoXACML là một phần mở rộng của XACML, nhƣng cả hai đều sử dụng cùng một quy trình đánh giá yêu cầu truy xuất của người dùng [17] [18]; vì vậy việc mở rộng GeoXACML phải dựa trên quy trình này để đảm bảo rằng GeoXACML sau khi mở rộng có thể tương thích với những phiên bản trước đó Để hỗ trợ mô hình STRoBAC, một vài thành phần sẽ đƣợc thêm vào trong quy trình, cụ thể là REA, VEA, AEA, CEA và PEA; tuy nhiên, nhƣ đã đề cập ở những phần trên, thành phần PEA trong quy trình sẽ bao gồm VEA và AEA Nhƣ vậy, sơ đồ dòng dữ liệu của quy trình đánh giá yêu cầu truy xuất cho GeoXACML mở rộng có thể được biểu diễn như hình 4.1 bên dưới
Hình 4.1 Sơ đồ dòng dữ liệu cho mô hình STRoBAC
Quy trình bắt đầu bằng những bước cơ bản được thực hiện tương tự như những bước đầu trong quy trình của XACML (1-5) Thành phần Context Handler sẽ đảm nhận nhiệm vụ thu thập tất cả các thông tin cần thiết và trả về cho PDP (23) Cụ thể nhƣ sau, Context
Người xử lý gửi yêu cầu (6) và nhận (19) danh sách vai trò được chọn từ RoleEA, tuy nhiên để đánh giá vai trò nào được chọn, RoleEA cần biết thông tin về thuộc tính của từng vai trò này (7) nên yêu cầu được gửi tiếp từ Context Handler đến RoleEA.
PIP (8) PIP sẽ lấy những thông tin này từ Repository (9) và trả về cho Context Handler
(10) Bên cạnh đó, vì vị từ REA có thêm yếu tố ngữ cảnh c trong phần định nghĩa, do đó
Context Handler cần đánh giá ngữ cảnh trước khi trả các thuộc tính của role về cho RoleEA (11) Tương tự như RoleEA, ContextEA cũng cần các thông tin thuộc tính ngữ cảnh, vì vậy bước 12-15 được thực hiện tương tự như bước 7-10 Sau khi nhận được các thông tin cần thiết (16), ContextEA đánh giá ngữ cảnh và trả kết quả về cho Context
Handler (17) Sau đó, RoleEA nhận các thông tin về role (18) và trả danh sách các role được lựa chọn cho Context Handler (19) Lưu ý rằng các bước tương ứng với
Bên cạnh PermissionEA có thể thực hiện đồng thời với RoleEA, còn có các thuộc tính khác có thể được yêu cầu Vì vậy, Context Handler tiếp tục yêu cầu PIP cung cấp thông tin và trả về toàn bộ thông tin cho PDP Thêm vào đó, để đánh giá yếu tố ngữ cảnh cuối cùng trong công thức biểu diễn chính sách chung của mô hình STRoBAC, ContextEA tiến hành đánh giá và trả kết quả về cho PDP Các bước cuối cùng trong quy trình được thực hiện tương tự như XACML.
Lưu ý rằng vì quy trình trên được mở rộng nên số bước cần thực hiện để đánh giá một yêu cầu truy xuất sẽ tăng lên và thời gian xử lý có thể dài hơn so với quy trình ban đầu Để giải quyết vấn đề này, chúng ta có thể xem xét việc đánh chỉ mục các chính sách để rút ngắn thời gian tìm chính sách phù hợp với yêu cầu truy xuất; hoặc ta cũng có thể xét đến giải pháp tối ƣu các giải thuật đánh giá ngữ cảnh (đánh giá mối quan hệ không gian giữa các đối tƣợng, hoặc đánh giá các ràng buộc về thời gian) Tuy nhiên, hiệu suất của hệ thống và bài toán tối ƣu không nằm trong khuôn khổ của đề tài luận văn
Mô hình STRoBAC kế thừa khái niệm không - thời gian từ STRBAC, áp dụng mô tả điều kiện ngữ cảnh theo mô hình Or-BAC, tích hợp các khái niệm về Enablement Authority từ mô hình mở rộng RBAC cho XACML Tuy nhiên, STRoBAC bổ sung các điều kiện ngữ cảnh mới trong quá trình gán role, sử dụng view đại diện cho đối tượng, activity cho hành động và gán quyền vào role GeoXACML sẽ được mở rộng để hiện thực hóa mô hình STRoBAC.
HIỆN THỰC MÔ HÌNH STRoBAC
Sơ lƣợc các mã nguồn mở hỗ trợ hiện thực XACML
Tài liệu [19] cung cấp tên và địa chỉ rất nhiều mã nguồn mở hiện thực XACML, để lựa chọn mã nguồn thích hợp, các tiêu chí sau sẽ đƣợc xem xét:
Phiên bản của XACML đƣợc mã nguồn hỗ trợ,
Mã nguồn có hỗ trợ hiện thực RBAC hay không,
Mã nguồn có cung cấp đầy đủ hướng dẫn sử dụng cho người phát triển hay không,
Những thành phần trong quy trình đánh giá yêu cầu truy xuất mà mã nguồn có thể hỗ trợ (ví dụ nhƣ PDP, PEP, PIP…)
Bảng 5.1 cung cấp một cái nhìn tổng quan về những mã nguồn mở hiện thực XACML dựa theo các tiêu chí đƣợc liệt kê phía trên Trong đó, ký hiệu “?” có nghĩa không có thông tin rõ ràng, “_” là không hỗ trợ và cột “Hướng dẫn sử dụng” biểu diễn mức độ đầy đủ của hướng dẫn (Pdf – Web – txt được sắp xếp theo mức độ đầy đủ giảm dần)
Vì mục đích của phần này là hiện thực mô hình STRoBAC dựa trên XACML 3.0 và GeoXACML; điều này có nghĩa là thành phần chính trong quy trình đánh giá phía trên (PDP) phải đƣợc hỗ trợ hiện thực và phiên bản của XACML đƣợc hỗ trợ phải lớn hơn hay bằng 2.0 Hầu hết các mã nguồn mở không hỗ trợ RBAC, trừ WSO2 và Margrave; tuy nhiên, WSO2 không hỗ trợ hiện thực PDP và Margrave không cung cấp các thông tin rõ ràng về cách hiện thực Đáng chú ý là phần hiện thực của Sun’s XACML, HERAS-AF, XACMLight và Enterprise Java XACML; tuy nhiên, Sun’s XACML chỉ hiện thực XACML phiên bản 1.1 và phần hiện thực của Enterprise Java XACML đã không đƣợc cập nhật trong một thời gian dài cũng như không hỗ trợ hướng dẫn sử dụng rõ ràng
Bảng 5.1 Tổng quan về các mã nguồn mở hiện thực XACML
Năm đề xuất Tên Phiên bản hỗ trợ
Hướng dẫn sử dụng Các thành phần đƣợc hỗ trợ Tham khảo
2004 Sun's XACML 1.1 _ Web PDP + PEP [24]
2010 XEngine _ _ txt PDP (fast and scalable) [26]
2008 XACML Studio 2.0 _ Web creating, editing, importing from XML and exporting to XML policies
2010 HERAS-AF 2.0 _ Pdf PDP, PEP, PIP, PolicyRepository [29]
2011 WSO2 3.0 yes Web PIP, interaction between PEP and PDP [34]
So sánh với XACMLight, HERAS-AF hỗ trợ hiện thực nhiều thành phần hơn và có tài liệu hướng dẫn sử dụng chi tiết hơn; vì vậy, HERAS-AF sẽ đƣợc chọn để hiện thực cho mô hình đề xuất của đề tài Tuy nhiên, mã nguồn HERAS-AF hiện tại chỉ hỗ trợ XACML 2.0, do đó các kiểu dữ liệu, hàm và giải thuật kết hợp mới sẽ đƣợc thêm vào mã nguồn này để hỗ trợ XACML 3.0 cũng nhƣ GeoXACML và các thành phần khác của mô hình STRoBAC Phần tiếp theo
HERAS-AF
Holistic Enterprise-Ready Application Security Architecture Framework (HERAS-AF) là dự án mã nguồn mở đƣợc hỗ trợ bởi Đại học Khoa học ứng dụng Rapperswil, Thụy Sĩ Ngày nay, HERAS-AF XACML Core đã trở thành một bộ máy toàn diện hỗ trợ hiện thực XACML phiên bản 2.0 [29]
HERAS-AF đƣợc xây dựng nhƣ một framework hỗ trợ toàn bộ quá trình phân quyền, trong đó, tất cả yêu cầu truy xuất dữ liệu sẽ bị chặn bởi PEP và sau đó chuyển sang PDP để đánh giá dựa trên các chính sách đã được định nghĩa trước Trong trường hợp yêu cầu truy xuất là hợp lệ, PEP sẽ cho phép người dùng truy xuất đến cơ sở dữ liệu Ngoài ra, thành phần PAP cũng được dùng để quản lý các chính sách [35] Cơ chế này tương tự như cách đánh giá yêu cầu truy xuất của XACML Core Hình 5.1 mô tả kiến trúc của HERAS- AF, trong đó, PEP, PDP, PAP và PIP giữ đúng vai trò nhƣ đã mô tả trong phần quy trình đánh giá yêu cầu truy xuất của XACML
Hình 5.1 Kiến trúc của HERAS-AF [35]
Như đã đề cập trước đó, HERAS-AF hỗ trợ hầu hết các thành phần chính trong kiến trúc Hiện tại, các tác giả của HERAS-AF đang tập trung phát triển HERAS-AF Core để hỗ trợ việc đánh giá yêu cầu truy xuất.
5.2.2 Cách thức tổ chức mã nguồn
Trong những phiên bản đầu tiên, phần hiện thực của HERAS-AF đƣợc chia thành các thành phần nhƣ hình 5.2 sau:
Hình 5.2 Lƣợc đồ thành phần của HERAS-AF
Core: chứa các lớp dữ liệu cần thiết để xây dựng chính sách (policy), tập chính sách (PolicySet), yêu cầu (request) và đáp ứng (response)
PDP: chứa phần hiện thực của PDP và sẽ đƣợc thay đổi tùy theo từng mô hình điều khiển truy xuất
Persistence: chứa nội dung luận lý để giữ các chính sách hoặc tập chính sách trong cơ sở dữ liệu và nạp các chính sách này vào PDP
Bộ định vị là tiến trình tải các quy tắc hoặc tập quy tắc vào bộ nhớ và lập chỉ mục cho các quy tắc này để có thể thực hiện quá trình tìm kiếm nhanh hơn.
Reference Loader: có nhiệm vụ giải quyết vấn đề tham khảo đến những chính sách hoặc tập chính sách được lưu cục bộ hoặc trên các kho lưu trữ từ xa
Tuy nhiên, trong những phiên bản hiện thực sau này, HERAS-AF chỉ phát triển thành phần Core và chuyển thành phần PDP vào Core; lưu ý rằng, trong HERAS-AF, ngữ Evaluatable đƣợc dùng để đề cập đến Policy hoặc PolicySet Phần tiếp theo sẽ mô tả chi tiết mỗi gói dữ liệu trong thành phần Core ở phiên bản mới nhất (1.0.0-M2)
5.2.3 Các gói dữ liệu cơ bản trong HERAS-AF Core
Hình 5.3 mô tả các gói dữ liệu cơ bản trong HERAS-AF Core
Hình 5.3 Lƣợc đồ gói dữ liệu của HERAS-AF Core
Types: gói chứa các lớp dữ liệu định nghĩa kiểu dữ liệu cơ bản sẽ đƣợc sử dụng
Tuy nhiên, do HERAS-AF đƣợc hiện thực bằng ngôn ngữ lập trình Java nên các kiểu dữ liệu này chỉ được sử dụng khi Java không có kiểu dữ liệu tương thích
DataTypeAttribute: chứa các lớp dữ liệu định nghĩa kiểu dữ liệu cho các thuộc tính Mỗi lớp dữ liệu có nhiệm vụ chuyển dữ liệu từ dạng chuỗi sang dạng kiểu dữ liệu tương ứng trong gói Types
Function: đây là gói chứa tất cả các hàm đƣợc định nghĩa trong XACML Core 2.0 specification [18]
Policy: chứa tất cả các lớp dữ liệu hỗ trợ việc xây dựng chính sách hoặc tập chính sách
Context: các lớp dữ liệu hỗ trợ việc xây dựng yêu cầu truy xuất (request) và kết quả trả về (response) sẽ được lưu trong gói này
CombiningAlgorithm: chứa các giải thuật kết hợp của Rule và Policy sẽ đƣợc dùng để đánh giá các kết quả kết hợp
TargetMatcher: các lớp dữ liệu trong gói này có nhiệm vụ tìm các chính sách
(hoặc tập chính sách) có thành phần target phù hợp với thành phần target trong yêu cầu truy xuất
SimplePDP: đây là gói mô phỏng các chức năng cơ bản của PDP và cung cấp cách tạo cũng nhƣ cấu hình PDP theo yêu cầu
Converter: chứa tất cả các lớp chuyển đổi cần thiết giúp chuyển đổi qua lại giữa dạng XML và dạng đối tƣợng của kiểu dữ liệu
API: chứa các interface cần thiết cho việc tìm và truy xuất thuộc tính (ví dụ api của PIP, PolicyRepository)
Utils: chứa các tiện ích khác cần thiết cho Core
To extend HERAS-AF Core, packages such as Types, DataTypeAttribute, Function, Policy, Context, CombiningAlgorithm, TargetMatcher, and SimplePDP should be considered Detailed descriptions of the base data classes in each package are provided in the appendix.
5.2.4 Tạo và đánh giá yêu cầu truy xuất với HERAS-AF
Do HERAS-AF được hiện thực dưới dạng framework và tập trung vào thành phần Core nên để kiểm tra khả năng đánh giá yêu cầu truy xuất của HERAS-AF, trước tiên người dùng cần tạo các chính sách và triển khai những chính sách này Hình 5.4 cho thấy cách tạo một chính sách đơn giản
Hình 5.4 Tạo chính sách trong HERAS-AF
Giả sử hiện tại ta có các chính sách policy1, policy2 và policy3, hình 5.5 cho thấy cách triển khai các chính sách này theo thứ tự
Hình 5.5 Triển khai chính sách với HERAS-AF
Tương tự, người dùng cũng cần tạo một yêu cầu truy xuất như hình 5.6
Hình 5.6 Tạo yêu cầu truy xuất với HERAS-AF Để đánh giá yêu cầu truy xuất này, ta sẽ gọi phương thức evaluate của PDP như sau
Hình 5.7 Đánh giá yêu cầu truy xuất với HERAS-AF
Hình 5.8 mô tả tuần tự quá trình đánh giá yêu cầu truy xuất của phương thức evaluate Đầu tiên, phương thức evaluate của PDP được gọi (1) Sau đó, PDP sẽ gọi hàm khởi tạo của EvaluationContext để tạo một đối tƣợng của lớp này (1.1), đây là đối tƣợng sẽ chứa tất cả các thông tin cần thiết cho việc đánh giá yêu cầu HERAS-AF không hỗ trợ các yêu cầu với nhiều nguồn dữ liệu, do đó nếu yêu cầu truy xuất chứa nhiều hơn một nguồn dữ liệu thì PDP sẽ gọi phương thức create của ResponseCtxFactory để tạo một response và trả kết quả này về cho đối tƣợng đã gọi PDP (1.2 và 1.3); ngƣợc lại, PDP sẽ gọi phương thức evaluateEvaluatableList của PolicyCombiningAlgorithm để đánh giá yêu cầu truy xuất này (1.4) Sau khi nhận đƣợc kết quả đánh giá, PDP sẽ tạo response và trả kết quả cho đối tượng gọi PDP, tương tự như bước 1.2 và 1.3; tuy nhiên, kết quả trong response sẽ chứa kết quả của phương thức evaluateEvaluatableList đã gọi (1.5 và 1.6)
Hình 5.8 Lƣợc đồ tuần tự đánh giá yêu cầu truy xuất của HERAS-AF
Với cách hiện thực này của HERAS-AF, việc đánh giá yêu cầu truy xuất sẽ đƣợc hiện thực toàn bộ trong gói CombiningAlgorithm
5.2.5 HERAS-AF ưu – nhược điểm và khả năng mở rộng
Trở lại bảng 5.1, so với các mã nguồn mở khác, HERAS-AF hỗ trợ nhiều thành phần hơn và cung cấp đầy đủ các hướng dẫn dành cho người sử dụng cũng như người phát triển chương trình Ngoài ra, với cách tổ chức mã nguồn đã được mô tả phía trên, việc mở rộng
HERAS-AF trở nên khá dễ dàng bằng cách thêm hoặc thay đổi phương thức và các lớp dữ liệu phù hợp trong từng gói dữ liệu (package)
Bên cạnh các ƣu điểm trên, tài liệu [35] cung cấp một số nhƣợc điểm cùng cách khắc phục của HERAS-AF Core dành cho XACML phiên bản 2.0 nhƣ sau:
Thay đổi thứ tự đánh chỉ mục: thứ tự đánh chỉ mục hiện tại đƣợc HERAS-AF đề xuất là subject resource action environment và thứ tự này là cố định, không thể thay đổi đƣợc Do đó, để tăng tính uyển chuyển, thứ tự này nên đƣợc cấu hình bởi người quản trị hệ thống
Hot deployment: với cách hiện thực hiện tại của HERAS-AF, sau khi triển khai một chính sách (hoặc tập chính sách, hàm, kiểu dữ liệu) mới, PDP phải đƣợc khởi động lại để những định nghĩa mới này có hiệu lực Điều này cũng đúng cho trường hợp khi cần undeployment một chính sách (hoặc tập chính sách, hàm, kiểu dữ liệu) Do đó, quy trình deployment hoặc undeployment nên đƣợc chuyển sang dạng hot deployment hoặc hot undeployment để giảm thời gian thực thi và việc khởi động lại PDP trở nên không cần thiết
AttributeFinder: với phiên bản hiện tại, AttributeFinder chỉ đƣợc hiện thực giả lập nên không thể lấy đƣợc giá trị các thuộc tính Do đó, AttributeFinder phải đƣợc hiện thực để hỗ trợ PIP có thể truy xuất các thuộc tính bị thiếu
Mở rộng HERAS-AF để hỗ trợ STRoBAC
Do mô hình STRoBAC hỗ trợ kiểm soát truy cập ở cả không gian và thời gian, mã nguồn HERAS-AF cần được bổ sung các kiểu dữ liệu và hàm tương ứng Ngoài ra, các thành phần mới (như RoleEA, ContextEA, PermissionEA) cần được thêm vào cùng các gói dữ liệu tương ứng để đáp ứng quy trình đánh giá yêu cầu của mô hình đề xuất Chi tiết các mở rộng này sẽ được trình bày trong các phần tiếp theo.
Trước tiên, để hỗ trợ mô hình STRoBAC, các thành phần mới phải được thêm vào mã nguồn, cụ thể là RoleEA (đảm nhận nhiệm vụ cung cấp danh sách các role đƣợc lựa chọn), PermissionEA (cung cấp danh sách các permission hợp lệ) và ContextEA (cho phép tạo request/response và đánh giá các điều kiện ngữ cảnh) Nhƣ đã đề cập ở phần 5.2.2 và 5.2.3, với cách tổ chức của HERAS-AF, để thêm phần hiện thực cho các thành phần mới, ta có thể làm theo hai cách: (1) thêm trực tiếp vào HERAS-AF Core dưới dạng các gói dữ liệu hoặc (2) đóng gói các gói này thành một thành phần (component) ngoài và hỗ trợ cho Core Do mã nguồn HERAS-AF đƣợc tổ chức dựa trên quy trình đánh giá yêu cầu truy xuất của XACML và các thành phần đƣợc hiện thực độc lập với nhau, do đó việc thêm các thành phần mới vào mã nguồn được thực hiện tương đối đơn giản bằng cách tạo các thành phần hoặc gói dữ liệu tương ứng với các lớp dữ liệu mới Việc chọn lựa cách (1) hay (2) sẽ đƣợc đề cập chi tiết trong phần hiện thực mở rộng mã nguồn
Ngoài định dạng dữ liệu gốc của XACML 2.0, HERAS-AF mở rộng hỗ trợ định dạng dữ liệu không gian như Point, Polygon, LineString, LinearRing, và định dạng không gian tổng quát Geometry Các định dạng mới mô tả thông tin không gian trong mô hình STRoBAC, hiện thực dưới dạng lớp dữ liệu, bổ sung vào gói Types và DataTypeAttribute trong HERAS-AF Core.
DataTypeAttribute Lưu ý rằng phương thức chính bắt buộc phải được hiện thực trong các lớp dữ liệu này là convertTo, đây là phương thức chuyển dữ liệu từ dạng chuỗi sang dạng kiểu dữ liệu tương ứng trong gói Types
Hình 5.9 Hiện thực kiểu dữ liệu DateTime trong HERAS-AF
Tương tự như kiểu dữ liệu, để đánh giá mối quan hệ không gian giữa hai đối tượng (nằm trong, phủ lấp, nằm kề…) các hàm hỗ trợ không gian (nhƣ within, overlaps, touch…) sẽ được thêm vào trong mã nguồn HERAS-AF và được hiện thực dưới dạng các lớp dữ liệu trong gói Function Tài liệu [36] cung cấp đầy đủ mô tả về ý nghĩa và cách thức hiện thực cho các hàm không gian này Hình 5.10 mô tả một ví dụ về cách hiện thực cho hàm StringEqualFunction
Hình 5.10 Định nghĩa hàm StringEqualFunction trong HERAS-AF
Lưu ý rằng tất cả các hàm được hiện thực trong gói Function sẽ có chung prototype cho phương thức handle, đây là phương thức thực hiện chức năng chính của hàm Với hàm StringEqualFunction, phương thức handle sẽ nhận vào một mảng hai tham số kiểu chuỗi và trả về kết quả cho biết hai chuỗi này có bằng nhau hay không
Nhƣ đã trình bày ở trên, giải thuật đƣợc dùng để kết hợp các kết quả đánh giá yêu cầu truy xuất của Policy thành một kết quả duy nhất cho PolicySet đƣợc gọi là giải thuật kết hợp Dựa vào tài liệu [36], GeoXACML không bổ sung giải thuật kết hợp mới nào vào XACML; XACML phiên bản 3.0 bổ sung thêm hai giải thuật PermitUnlessDeny và DenyUnlessPermit vào phiên bản 2.0 [17] Để hiện thực một giải thuật kết hợp mới, ta chỉ cần hiện thực giải thuật này dưới dạng lớp dữ liệu (dựa trên những giải thuật đã có) và thêm vào gói PolicyCombiningAlgorithm nếu đó là giải thuật dành cho chính sách, hoặc thêm vào gói RuleCombiningAlgorithm nếu đó là giải thuật dành cho luật
Tóm lại, do HERAS-AF đƣợc tổ chức và hiện thực dựa trên quy trình đánh giá yêu cầu truy xuất của XACML nên việc mở rộng mã nguồn này để hỗ trợ cho mô hình đề xuất trở nên khá dễ dàng và thuận tiện Công việc chính của việc mở rộng bao gồm hiện thực các kiểu dữ liệu và hàm mới để hỗ trợ dữ liệu không gian cũng nhƣ hiện thực các thành phần mới đƣợc thêm vào trong mô hình STRoBAC (RoleEA, ContextEA, PermissionEA…) Phần tiếp theo sẽ trình bày chi tiết cho các bước hiện thực.
Hiện thực
Việc hiện thực mô hình STRoBAC sẽ dựa trên phần hiện thực của HERAS-AF [29], do đó mô hình sẽ đƣợc hiện thực trên dự án Maven [37] và dùng ngôn ngữ Java (phiên bản 1.5)
Trước khi hiện thực, ta cần thực hiện một số cài đặt và cấu hình sau:
jre1.5: http://www.oracle.com/technetwork/java/javasebusiness/downloads/java- archive-downloads-javase5-419410.html
Eclipse SDK: http://www.eclipse.org/downloads/ (phiên bản 3.7.2)
Tải và cài đặt Maven: http://www.avajava.com/tutorials/lessons/what-is-maven- and-how-do-i-install-it.html?page=1 (phiên bản 3.0.4)
M2Eclipse: http://www.eclipse.org/m2e/ (hỗ trợ Eclipse làm việc với dự án
Cấu hình các phụ thuộc trong dự án Maven: http://maven.apache.org/guides/ introduction/introduction-to-dependency-mechanism.html
TestNG Eclipse plugin: http://testng.org/doc/eclipse.html (để tạo unit test, cho
Eclipse 3.4 và phiên bản cao hơn)
Tạo hoặc import dự án Maven vào Eclipse: http://www.avajava.com/tutorials/ lessons/how-do-i-import-a-maven-project-into-eclipse.html
Quán lý phụ thuộc (dependency management) đƣợc xem là một trong những điểm vƣợt trội của của dự án Maven Không có nhiều khó khăn khi quản lý phụ thuộc trong một dự án đơn, nhưng khi người dùng bắt đầu làm việc với nhiều module dự án và ứng dụng bao gồm hàng chục hoặc hàng trăm module khác là lúc Maven có thể giúp đỡ người dùng trong việc duy trì mức độ kiểm soát cao và ổn định Vì vậy, sau khi import HERAS- AF vào dự án, những phụ thuộc sau phải đƣợc thêm vào:
Hình 5.11 Cấu hình phụ thuộc cho dự án Maven
Chi tiết hơn về những phụ thuộc này sẽ đƣợc giải thích trong những phần tiếp theo
Sau khi thiết lập môi trường, ta có thể hiện thực phần demo cho mô hình STRoBAC dựa trên hiện thực của HERAS-AF
Java Topology Suite (JTS) framework [38] sẽ đƣợc dùng cho việc hiện thực dữ liệu và hàm không gian Một trong những lý do của việc lựa chọn này là JTS hỗ trợ tất cả các kiểu dữ liệu và hàm không gian Vì vậy, việc hiện thực chính là chuyển đổi giữa kiểu JTS sang kiểu dữ liệu không gian của mô hình Phần hiện thực này đƣợc dựa trên GeoPDP, đề tài luận văn tốt nghiệp của nhóm sinh viên Đại học trường Đại học Bách Khoa, thành phố Hồ Chí Minh [39] Framework JTS sẽ đƣợc sử dụng nhƣ sau
Hình 5.12 Sử dụng JTS cho dữ liệu không gian
Tuy nhiên, đề tài chỉ hiện thực những kiểu dữ liệu không gian cơ bản tương ứng với các lƣợc đồ lớp (phần phụ lục); mỗi kiểu dữ liệu sẽ đƣợc hiện thực theo những hàm chính sau:
Một hàm khởi tạo (constructor) để tạo một đối tƣợng không gian từ kiểu String
Ví dụ, kiểu Polygon có phần hiện thực của hàm khởi tạo nhƣ sau
Hình 5.13 Hàm khởi tạo từ String cho kiểu Polygon
Một hàm khởi tạo một đối tƣợng không gian từ nút JDOM JDOM cung cấp một giải pháp toàn diện dựa trên Java để truy xuất, vận hành và xuất dữ liệu ra dạng
XML từ mã Java [40] Ví dụ, kiểu Point có phần hiện thực của hàm khởi tạo này nhƣ ở hình 5.14
Hàm khởi tạo đối tượng không gian từ nút DOM [41] tương đương với JDOM, nhưng khác ở chỗ sử dụng thư viện org.w3.dom.Element thay vì org.jdom2.Element.
Bên cạnh đó, vì kiểu Geometry là kiểu trừu tƣợng của Point, Polygon và LineString; vì vậy, hàm khởi tạo của Geometry sẽ gọi hàm khởi tạo của các kiểu con, tùy theo giá trị của các thành phần con, ví dụ nhƣ ở hình 5.15
Hình 5.14 Hàm khởi tạo từ JDOM cho kiểu Polygon
Ngoài ra, kiểu Geometry còn được hiện thực các phương thức để kiểm tra mối quan hệ giữa hai đối tượng không gian, ví dụ như phương thức within để kiểm tra một đối tƣợng có nằm trong đối tƣợng còn lại hay không (hình 5.16)
Hình 5.15 Hàm khởi tạo cho kiểu Geometry
Hình 5.16 Phương thức within cho kiểu Geometry
Phần tiếp theo sẽ trình bày cách hiện thực thuộc tính các kiểu dữ liệu
Nhƣ đã đề cập phía trên, GeoXACML chỉ thêm vào XACML một kiểu dữ liệu mới là
Geometry, vì vậy chỉ có một lớp mới đƣợc thêm vào gói dữ liệu DataTypeAttribute
Thuộc tính của Geometry đƣợc xác định bằng chuỗi “urn:ogc:def:dataType: geoxacml:1.0:-geometry” và phương thức convertTo để chuyển đổi từ kiểu String sang
Geometry Phương thức này được hiện thực như sau
Hình 5.17 Phương thức convertTo của lớp GeometryDataTypeAttribute
Các lệnh từ dòng 55 đến 57 sẽ chuyển biến kiểu String thành nút JDOM và sau đó tạo một nút kiểu Geometry
Phần này sẽ trình bày cách hiện thực các hàm không gian để hỗ trợ GeoXACML, phần hiện thực các hàm còn lại (để hỗ trợ XACML phiên bản 3.0) được thực hiện tương tự Các hàm không gian có phần định danh đƣợc xác định bằng chuỗi nhƣ sau [36]:
Contains: urn:ogc:def:function:geoxacml:1.0:geometry-contains
Crosses: urn:ogc:def:function:geoxacml:1.0:geometry-crosses
Disjoint: urn:ogc:def:function:geoxacml:1.0:geometry-disjoint
Equals: urn:ogc:def:function:geoxacml:1.0:geometry-equals
Intersects: urn:ogc:def:function:geoxacml:1.0:geometry-intersect
Overlaps: urn:ogc:def:function:geoxacml:1.0:geometry-overlaps
Touches: urn:ogc:def:function:geoxacml:1.0:geometry-touches
Within: urn:ogc:def:function:geoxacml:1.0:geometry-withinMỗi lớp đại diện hàm không gian được hiện thực một phương thức handle để kiểm tra quan hệ đồ hình giữa hai đối tượng không gian, ví dụ phương thức handle của lớp within ở hình 5.18 Ngoài ra, hàm within đã đƣợc hiện thực cho kiểu Geometry; vì vậy, một cách đơn giản để hiện thực hàm handle cho lớp within là gọi lại phương thức within của Geometry
Hình 5.18 Phương thức handle của lớp within
Vì XACML phiên bản 2.0 có nhiều điểm khác biệt về cấu trúc so với XACML 3.0 nên các thành phần hiện thực Policy trong mã nguồn HERAS-AF cần đƣợc chỉnh sửa và thêm mới Ví dụ thành phần Target chứa một danh sách các thành phần AnyOf thay vì Subject, Resource, Action hay Environement AnyOf đƣợc hiện thực nhƣ sau
Hình 5.19 Hiện thực của lớp AnyOfType
Tương tự, thành phần Match được cũng được thêm vào mã nguồn
Hình 5.20 Hiện thực của lớp MatchType
Những thành phần khác đƣợc thêm vào nhƣ ObligationExpressions và AdviceExpressions với cùng cách hiện thực; hình 5.21 biểu diễn cách hiện thực của ObligationExpressions
Hình 5.21 Hiện thực của lớp ObligationExpressionsType
Tương tự như ObligationExpressions, mỗi thành phần AdviceExpressions sẽ chứa một danh sách các thành phần AdviceExpression với cách hiện thực nhƣ sau
Hình 5.22 Hiện thực của lớp AdviceExpressionType
Một trong những lớp quan trọng phải đƣợc chỉnh sửa là AttributeDesignator Ngoài ra, thành phần Target trong XACML phiên bản 3.0 không chứa Subject (hay Resource, Action và Environment), vì vậy ta không thể dùng lại phương thức SubjectAttribute- Designator (hay các phương thức của những AttributeDesignator khác) Do đó, phương thức handle trong AttributeDesignator sẽ đƣợc chỉnh sửa lại nhƣ hình 5.23 Trong đó, AttributeDesignator sẽ gọi hàm handle của role nếu thuộc tính định danh của category có chứa chuỗi “subject” (tương tự cho các trường hợp còn lại) Lưu ý rằng thuộc tính định danh category là thuộc tính bắt buộc của AttributeDesignator và Policy chỉ chứa các định danh cho role (hay view, activity, environment) tương ứng với định nghĩa của mô hình STRoBAC
Hình 5.23 Hiện thực của lớp AttributeDesignatorType
Phương thức handle của role, view và activity sẽ lấy danh sách các role được chọn lựa và danh sách các permission hợp lệ từ việc đánh giá ngữ cảnh để so sánh với các giá trị đƣợc định nghĩa trong AttributeDesignator Hình 5.24 trình bày cách hiện thực cho hàm REAHandle Dựa theo phương thức này, mỗi role trong danh sách các role được lựa chọn sẽ đƣợc so sánh với các giá trị đƣợc định nghĩa trong AttributeDesignator về category, attribute id và kiểu dữ liệu; nói cách khác, kết quả trả về là một danh sách các role có cùng category, attribute id, kiểu dữ liệu và issuer (nếu có) với
AttributeDesignator Tuy nhiên, vì resource, action và environment chỉ có một chuỗi định danh cho category nên ta không cần kiểm tra thuộc tính này khi so sánh với các giá trị trong AttributeDesignator
Hình 5.24 Hiện thực của phương thức REAHandle
Lớp EvaluationContext trong SimpleCEA có nhiệm vụ lưu tất cả các thông tin cần thiết cho việc đánh giá yêu cầu truy xuất; vì vậy, các thuộc tính tương ứng với thành phần
ĐÁNH GIÁ VÀ KẾT LUẬN
Đánh giá
Nhƣ đã trình bày ở phần kết luận 3.3, mô hình STRoBAC đƣợc đề xuất mong muốn hỗ trợ khía cạnh không – thời gian của người dùng, khía cạnh không gian của dữ liệu, điều khiển truy xuất dựa trên role, rule và các điều kiện ngữ cảnh khác Ta sẽ xem xét lại mô hình đề xuất dựa trên những khía cạnh này
Cụ thể là STRoBAC sử dụng khái niệm không – thời gian từ mô hình STRBAC, do đó, các điều kiện về không – thời gian của người dùng (vị trí của người dùng, thời gian người dùng gửi câu truy vấn) và không gian của dữ liệu (vùng không gian mà dữ liệu mô tả) sẽ được biểu diễn thông qua các vị từ được định nghĩa trước tương tự như trong STRBAC Ngoài ra, mô hình đề xuất còn sử dụng cách thức biểu diễn điều kiện ngữ cảnh của mô hình Or-BAC, khái niệm Enablement Authority đƣợc đề xuất trong mô tả RBAC mở rộng cho XACML, và các điều kiện ngữ cảnh đƣợc định nghĩa thêm khi gán role cho subject, gán view cho object, activity cho action và permission cho role; vì vậy mô hình STRoBAC có thể biểu diễn nhiều loại điều kiện ngữ cảnh khác nhau, đồng thời điều khiển yêu cầu truy xuất dựa trên role, view và activity (tương tự như mô hình Or-BAC)
Cuối cùng, STRoBAC được thực hiện dựa trên phần mở rộng của XACML - một ngôn ngữ đặc tả các chính sách bảo mật, trong đó mỗi chính sách là tập hợp các quy tắc Do đó, các chính sách của STRoBAC cũng được biểu diễn theo dạng này Tóm lại, mô hình STRoBAC hỗ trợ đầy đủ các loại giới hạn truy cập mong đợi đã được đề cập trước đó.
HERAS-AF mở rộng (HERAS-AF+) được phát triển để hỗ trợ XACML 3.0, ràng buộc không-thời gian và mô hình STRoBAC Tuy nhiên, phiên bản hiện tại chỉ hỗ trợ các chính sách dựa trên role/view/activity cơ bản, có xét điều kiện thời gian người dùng gửi yêu cầu truy cập Phần hiện thực này sẽ được hoàn thiện trong tương lai để hỗ trợ đầy đủ các tính năng của mô hình, nằm trong khuôn khổ đề tài nghiên cứu "Phát triển mô hình điều khiển truy xuất cho dữ liệu GIS".
Kết luận
Điểm khởi đầu cho đề tài là sự thiếu kiểm soát các yêu cầu truy xuất đến dữ liệu không gian địa lý, trong khi đây là các dữ liệu quan trọng và có tính nhạy cảm cao (ví dụ thông tin vị trí các tòa nhà quan trọng của chính phủ hay trại quân đội) Các mô hình điều khiểu truy xuất hỗ trợ dữ liệu không gian địa lý hiện tại không cung cấp phương thức để đặc tả và thực thi các chính sách bảo mật cũng nhƣ không hỗ trợ đầy đủ các loại giới hạn cần thiết Đáng chú ý là mô hình STRBAC hỗ trợ cả hai khía cạnh không – thời gian; mô hình Or-BAC hỗ trợ điều khiểu truy xuất dựa trên role, view và activity; và ngôn ngữ
XACML/GeoXACML hỗ trợ đặc tả và thực thi chính sách bảo mật Mô hình của đề tài, STRoBAC, đƣợc đề xuất dựa trên sự phát triển, mở rộng, và kết hợp của những mô hình và ngôn ngữ này
Ngoài những điều kiện ngữ cảnh đƣợc đề cập trong đề tài, những vấn đề sau có thể được xem xét cho việc nghiên cứu sâu hơn đề tài trong tương lai:
Phát triển phần hiện thực của các gói dữ liệu SimpleCEA, SimpleREA và
Mở rộng mô hình STRoBAC để hỗ trợ các giới hạn còn lại đƣợc đề cập trong bảng 3.1 và những điều kiện ngữ cảnh khác (ví dụ truy xuất trong trường hợp khẩn cấp),
Chuẩn hóa cấu trúc của các Policy định nghĩa (hoặc gán) role, view và activity
Quản lý điều khiển truy xuất khi người dùng di chuyển qua các vùng không – thời gian khác nhau,
Mở rộng phần hiện thực để hỗ trợ đầy đủ các chức năng của XACML 3.0 và GeoXACML,
Hiện thực các thành phần khác trong quy trình đánh giá yêu cầu truy xuất của
XACML (cụ thể là PEP, PIP và PAP),
Tích hợp phần hiện thực vào một hệ thống thực tế,
Phát triển phần hiện thực trở thành framework có thể sử dụng chung cho các ứng dụng GIS khác nhau,
Cải tiến tốc độ xử lý yêu cầu truy xuất, ví dụ đánh chỉ mục các Policy trong cơ sở dữ liệu
Cuối cùng, mặc dù GIS không phải là một lĩnh vực mới, nhƣng những nghiên cứu sâu cho việc điều khiển truy xuất dữ liệu GIS vẫn chƣa đƣợc quan tâm đúng mức; vì vậy các nghiên cứu này cần đƣợc đẩy mạnh để bắt kịp tốc độ phát triển nhanh chóng của ứng dụng GIS Kết quả của đề tài sẽ là một trong những động lực cho hướng nghiên cứu còn nhiều thử thách này
Danh mục các công trình khoa học
1 LE Thi Kim Tuyen, TRAN Thi Que Nguyet, DANG Tran Khanh “An Enhanced
Access Control Model for GIS Database Security”, in Proceedings of the 4 th Regional Conference on on Information and Communication Technology, Ho Chi Minh City,
2 LE Thi Kim Tuyen, DANG Tran Khanh, KUONEN Pierre, CHABBI DRISSI
Houda “STRoBAC–Spatial Temporal Role Based Access Control” in Proceedings of the 4 th International Conference on Computational Collective Intelligence Technologies and Applications (ICCCI), Part II, LNAI 7654, Springer-Verlag
Heidelberg, Ho Chi Minh city, Vietnam, 28-30 November 2012, pp 201-211.