›
›

Bài giảng An toàn cơ sở dữ liệu - Chương 3: Thiết kế an toàn cơ sở dữ liệu - Trần Thị Lượng

pdf 114 trang ngocly 320
Download
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng An toàn cơ sở dữ liệu - Chương 3: Thiết kế an toàn cơ sở dữ liệu - Trần Thị Lượng", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pdfbai_giang_an_toan_co_so_du_lieu_chuong_3_thiet_ke_an_toan_co.pdf

Nội dung text: Bài giảng An toàn cơ sở dữ liệu - Chương 3: Thiết kế an toàn cơ sở dữ liệu - Trần Thị Lượng

  1. CHƯƠNG 3 THIẾT KẾ AN TOÀN CƠ SỞ DỮ LIỆU Giảng viên Trần Thị Lượng
  2. Mục tiêu  Trình bày các giải pháp được sử dụng để thiết kế một hệ quản trị cơ sở dữ liệu an toàn.  Trình bày một số mẫu nghiên cứu và các sản phẩm DBMS an toàn thương mại.  Trình bày một giải pháp mang tính phương pháp luận nhằm thiết kế cơ sở dữ liệu an toàn 11/23/2015 2
  3. Nội dung 3.1 Giới thiệu 3.2 Thiết kế DBMS an toàn 3.2.1 Các cơ chế an toàn trong các DBMS 3.2.2 Mô hình cấp quyền System R 3.2.3 Các kiến trúc của DBMS an toàn 3.2.4 Thiết kế các cơ sở dữ liệu an toàn 3.2.4.1 Giai đoạn phân tích sơ bộ 3.2.4.2 Giai đoạn phân tích yêu cầu và chọn lựa chính sách an toàn 3.2.4.3 Giai đoạn thiết kế khái niệm 3.2.4.4 Giai đoạn thiết kế logic 3.2.4.5 Giai đoạn thiết kế vật lý 11/23/2015 3
  4. 3.1 Giới thiệu  Thiết kế một DBMS an toàn  Nền tảng của một CSDL an toàn là một DBMS an toàn.  Có nhiều kiến trúc DBMS an toàn khác nhau, phụ thuộc vào những phần không tin cậy của toàn bộ hệ thống.  Thiết kế một CSDL an toàn  Lựa chọn một chính sách an toàn  Thực thi  Kiểm tra 11/23/2015 4
  5. 3. 2 Thiết kế DBMS an toàn 3.2.1 Các cơ chế an toàn trong các DBMS 3.2.2 Mô hình cấp quyền System R 3.2.3 Các kiến trúc của DBMS an toàn 11/23/2015 5
  6. 3.2 Thiết kế DBMS an toàn  CSDL  Việc đảm bảo an toàn cho CSDL được thực hiện cả hai mức: DBMS, OS.  DBMS có thể khai thác các chức năng an toàn bắt buộc ở mức OS 11/23/2015 6
  7. Sự khác nhau giữa các OS và DBMS  Độ chi tiết của đối tượng (Object granularity): Trong OS, độ chi tiết ở mức tệp (file), thiết bị. Trong DBMS, nó chi tiết hơn (ví dụ như: các quan hệ, các hàng, các cột, các trường).  Các tương quan ngữ nghĩa trong dữ liệu (Semantic correlations among data): Trong OS không có, trong CSDL, dữ liệu có ngữ nghĩa và liên quan với nhau thông qua các quan hệ ngữ nghĩa như:  Data  Time  Context  History 11/23/2015 7
  8. Sự khác nhau giữa các OS và DBMS  Siêu dữ liệu (Metadata): Siêu dữ liệu tồn tại trong một DBMS, cung cấp thông tin về cấu trúc của dữ liệu trong CSDL, cấu trúc lưu trữ vật lý của các đối tượng CSDL(quan hệ, thuộc tính, ràng buộc, miền ). Trong OS không có. 11/23/2015 8
  9. Sự khác nhau giữa các OS và DBMS  Các đối tượng logic và vật lý: Các đối tượng trong một OS là các đối tượng vật lý (ví dụ: các file, các thiết bị, bộ nhớ và các tiến trình). Các đối tượng trong một DBMS là các đối tượng logic (ví dụ: các quan hệ, các khung nhìn) và chúng độc lập với các đối tượng của OS. 11/23/2015 9
  10. Sự khác nhau giữa các OS và DBMS  Nhiều loại dữ liệu: Đặc điểm của các CSDL là có rất nhiều kiểu dữ liệu, do đó các CSDL cũng yêu cầu nhiều chế độ truy nhập (ví như chế độ thống kê, chế độ quản trị). Tại mức OS chỉ tồn tại truy nhập vật lý, bao gồm các thao tác trên file như: đọc, ghi và thực hiện.  Các đối tượng động và tĩnh: Các đối tượng được OS quản lý là các đối tượng tĩnh và tương ứng với các đối tượng thực. Trong các CSDL, các đối tượng có thể được tạo ra động (ví dụ các khung nhìn hay các kết quả hỏi đáp) và không có các đối tượng thực tương ứng. 11/23/2015 10
  11. Sự khác nhau giữa các OS và DBMS  Các giao tác đa mức: Trong một DBMS thường có các giao tác liên quan đến dữ liệu ở các mức an toàn khác nhau (ví dụ: select, insert, update, delete), vì một đối tượng trong CSDL có thể chứa các dữ liệu ở các mức an toàn khác nhau. Tại mức OS, một đối tượng chỉ có thể chứa dữ liệu ở một mức an toàn, chỉ có các thao tác cơ bản (ví dụ, đọc, ghi, thực hiện).  Thời gian tồn tại của dữ liệu: Dữ liệu trong một CSDL có thời gian tồn tại dài và DBMS có thể đảm bảo việc bảo vệ từ đầu đến cuối trong suốt thời gian tồn tại của dữ liệu. Nhưng dữ liệu trong một hệ điều hành thường không được lưu trữ một cách an toàn. 11/23/2015 11
  12. Tổng quát các cơ chế an toàn cơ bản của OS và DBMS 11/23/2015 12
  13. 3. 2 Thiết kế DBMS an toàn 3.2.1 Các cơ chế an toàn trong các DBMS 3.2.2 Mô hình cấp quyền System R 3.2.3 Các kiến trúc của DBMS an toàn 11/23/2015 13
  14. 3.2.1 Các cơ chế an toàn trong các DBMS  Mức độ chi tiết khác nhau của truy nhập: DBMS cần bảo đảm kiểm soát truy nhập với các mức độ chi tiết khác nhau, như kiểm soát truy nhập tới: từng quan hệ, các cột, hàng, hay các mục dữ liệu riêng.  Các chế độ truy nhập khác nhau: DBMS phải đưa ra được các chế độ truy nhập cơ bản như: SELECT, INSERT, UPDATE, DELETE. 11/23/2015 14
  15. 3.2.1 Các cơ chế an toàn trong các DBMS  Các kiểu kiểm soát truy nhập khác nhau: Các yêu cầu truy nhập có thể được xử lý, bằng cách sử dụng các kiểu kiểm soát khác nhau:  Các kiểm soát phụ thuộc tên (name): dựa vào tên của đối tượng bị truy nhập.  Các kiểm soát phụ thuộc dữ liệu (data): thực hiện truy nhập phụ thuộc vào các nội dung của đối tượng bị truy nhập (bổ sung tân từ)  Các kiểm soát phụ thuộc ngữ cảnh (Context): dựa vào giá trị của một số biến hệ thống (ví dụ như: ngày, tháng, thiết bị đầu cuối yêu cầu – vị trí người dùng, thời gian).  Các kiểm soát phụ thuộc lược sử (History): quan tâm đến các thông tin về chuỗi câu truy vấn (ví dụ như: các kiểu câu truy vấn, dữ liệu trả lại, profile của người dùng đang yêu cầu, tần suất yêu cầu). 11/23/2015 15
  16. 3.2.1 Các cơ chế an toàn trong các DBMS  Quyền động: DBMS nên hỗ trợ việc sửa đổi các quyền của người dùng trong khi CSDL đang hoạt động. Điều này tương ứng với nguyên tắc đặc quyền tối thiểu, có thể sửa đổi các quyền tuỳ thuộc vào các nhiệm vụ của người dùng (ví dụ sửa quyền user bằng cách thêm hoặc bớt các Role cho user đó).  Bảo vệ đa mức: DBMS nên hỗ trợ bảo vệ đa mức bằng chính sách MAC. 11/23/2015 16
  17. 3.2.1 Các cơ chế an toàn trong các DBMS  Các kênh ngầm (Covert channels):  DBMS không nên để người dùng thu được các thông tin trái phép thông qua các phương pháp truyền thông gián tiếp.  Kênh ngầm là một kênh giao tiếp dựa vào các tài nguyên hệ thống (Không phục vụ cho hoạt động giao tiếp) của các chủ thể (tiến trình) trong hệ thống.  Kênh ngầm yêu cầu hai thực thể hoạt động (active agent), một ở mức cao, một ở mức thấp và một lược đồ mã hoá 11/23/2015 17
  18. 11/23/2015 18
  19. 3.2.1 Các cơ chế an toàn trong các DBMS  Các kiểm soát suy diễn (Inference controls): Các kiểm soát suy diễn nên ngăn chặn người dùng suy diễn dựa vào các thông tin mà họ thu được trong CSDL. Trong một hệ thống CSDL, các vấn đề suy diễn thường liên quan đến việc gộp (aggregation) và gắn kết dữ liệu (data association)  DBMS nên cung cấp một cách thức gán các mức phân loại để gộp thông tin, phản ánh mức nhạy cảm của các mục dữ liệu được gộp. => quản lý chúng dễ dàng hơn.  Giải pháp: Trong một CSDL quan hệ có thể có các giải pháp như: - Kỹ thuật hạn chế câu truy vấn - Kỹ thuật đa thể hiện (polyinstantiation) - Kiểm toán.  Đặc biệt kiểm soát suy diễn trong CSDL thống kê. 11/23/2015 19
  20. 3.2.1 Các cơ chế an toàn trong các DBMS  Đa thể hiện (polyinstantiation): Kỹ thuật này có thể được DBMS sử dụng để ngăn chặn suy diễn, bằng cách cho phép CSDL có nhiều thể hiện cho cùng một mục dữ liệu, mỗi thể hiện có một mức nhạy cảm riêng.  Kiểm toán (Auditing): Các sự kiện liên quan tới an toàn (xảy ra trong khi hệ thống CSDL đang hoạt động) nên được ghi lại và theo một khuôn dạng có cấu trúc, chẳng hạn như: nhật ký hệ thống, vết kiểm toán. 11/23/2015 20
  21. Multilevel Relation and Polyinstantiation (đa thể hiện) EMP-ID NAME SALARY DEPTNO SECURITY CLASS 1 smith 100000 5 S 2 brown 80000 4 C 1 smith null 5 C 11/23/2015 21
  22. 3.2.1 Các cơ chế an toàn trong các DBMS  Các kiểm soát luồng (Flow controls): Các kiểm soát luồng kiểm tra đích của đầu ra, tránh làm lộ thông tin mật.  Không cửa sau (No back door): Truy nhập vào dữ liệu chỉ nên xảy ra thông qua DBMS. Phải đảm bảo không có các đường dẫn truy nhập ẩn.  Hiệu năng hợp lý : Các kiểm soát an toàn làm tăng thời gian hoạt động, do đó cần tối thiểu hoá các kiểm soát để đảm bảo hiệu năng của hệ thống nhưng vẫn đảm bảo được tính an toàn. 11/23/2015 22
  23. 3.2.1 Các cơ chế an toàn trong các DBMS  Nhận xét:  Mặc dù ta nói các đối tượng logic của DBMS không phụ thuộc vào đối tượng OS, tuy nhiên trong một số OS vẫn xảy ra tình trạng những truy nhập trái phép vào file chứa CSDL làm thay đổi độ nhạy cảm của dữ liệu => Cần bảo vệ thêm bằng cách mã hoá file.  Ngoài ra, các cơ chế an toàn làm ảnh hưởng đến hiệu năng của hệ thống, nên người dùng sẵn sàng bỏ qua những cơ chế này, đó cũng là nguyên nhân khiến hệ thống bị xâm nhập 11/23/2015 23
  24. Các cơ chế toàn vẹn trong các DBMS  Các giao tác đúng đắn (Well-formed transactions): việc cập nhật dữ liệu chỉ được thực hiện qua các giao tác đúng đắn (có thể dùng kỹ thuật khoá – lock).  Người dùng được xác thực (Authenticated users): Theo nguyên tắc này, không cho phép người dùng thực hiện các thay đổi trừ khi định danh của họ được xác thực chính xác. Việc xác thực người dùng thuộc trách nhiệm của OS và không cần phải lặp lại trong DBMS. Tuy nhiên để đảm bảo an toàn đầy đủ, cần xác thực lần hai tại mức DBMS.  Đặc quyền tối thiểu (Least privilege): Đây là một nguyên tắc giới hạn người dùng chỉ được làm việc với một tập tối thiểu các đặc quyền và tài nguyên cần thiết để thực hiện nhiệm vụ của mình. 11/23/2015 24
  25. Các cơ chế toàn vẹn trong các DBMS  Nhận xét:  Đặc quyền tối thiểu cũng được áp dụng cho các OS.  Quá trình cài đặt các hệ điều hành như Windows (NT hoặc 2000), tất cả user đều được đăng ký như administrator. Vì nếu không như vậy sẽ có rất nhiều công việc cơ bản mà các user này không được phép thực hiện.  Trong Unix, tất cả các user bình thường có thể làm mọi thứ họ cần mà không cần phải là root. 11/23/2015 25
  26. Các cơ chế toàn vẹn trong các DBMS  Tách bạch nhiệm vụ (Separation of duties): Nguyên tắc này được đưa ra nhằm hạn chế tối đa một cá nhân bất kỳ có thể phá hoại dữ liệu, để đảm bảo toàn vẹn dữ liệu. Tách bạch nhiệm vụ được gắn liền với các kiểm soát trên các chuỗi giao tác.  Tính liên tục của hoạt động (Continuity of operation): nên duy trì các hoạt động của hệ thống sau khi sự cố xảy ra (quan tâm đến các biện pháp an toàn vật lý). 11/23/2015 26
  27. Các cơ chế toàn vẹn trong các DBMS  Dựng lại các sự kiện (Reconstruction of events): Việc dựng lại các sự kiện trong một DBMS phụ thuộc vào các vết kiểm toán, để phát hiện ra các hoạt động sai trái.  Dễ dàng sử dụng an toàn (Ease of safe use): Điều này có nghĩa là các thủ tục an toàn nên đơn giản, phổ biến, dễ sử dụng.  Uỷ quyền (Delegation of authority): DBMS cần hỗ trợ việc gán quyền theo các chính sách bắt buộc, tuỳ ý. Các câu lệnh SQL để uỷ quyền như GRANT/REVOKE. 11/23/2015 27
  28. 3. 2 Thiết kế DBMS an toàn 3.2.1 Các cơ chế an toàn trong các DBMS 3.2.2 Mô hình cấp quyền System R 3.2.3 Các kiến trúc của DBMS an toàn 11/23/2015 28
  29. 3.2.2 Mô mình cấp quyền System R  Hệ thống R là hệ CSDL quan hệ đầu tiên của IBM. Việc bảo vệ được thực hiện tại mức table (bảng). Có 5 chế độ truy nhập vào một table:  Read: đọc các bộ của một bảng. Một user có truy nhập read, có thể định nghĩa các views trên table đó.  Insert: để thêm các bộ vào một bảng.  Delete: để xoá các bộ trong một bảng.  Update: ođể sửa đổi các bộ đang có trong một bảng. Đặc quyền này có thể bị giới hạn chỉ trong một số cột nhất định của bảng.  Drop: để xoá toàn bộ bảng. 11/23/2015 29
  30. 3.2.2 Mô mình cấp quyền System R  Hệ thống R hỗ trợ quản trị quyền phi tập trung: Người tạo ra bảng có mọi đặc quyền trên bảng đó và cso thể grant/revoke (trao/thu hồi) quyền cho các user khác, mỗi quyền là một bộ sau:  s: chủ thể được gán quyền (grantee).  p: đặc quyền được gán (select, update ).  t: tên bảng, trên đó truy nhập được gán.  ts: thời điểm quyền được gán.  g: người gán quyền (grantor).  go {yes,no}: grant option. 11/23/2015 30
  31. 3.2.2 Mô mình cấp quyền System R  Nhận xét:  Tham số go = yes, có nghĩa s có GRANT OPTION, nên có thể gán đặc quyền p cho các user khác.  Tham số: g (grantor) và ts (time), để có thể thực hiện các hoạt động revoke quyền sau này một cách chính xác, bằng cách kiểm tra một loạt các quyền đã được gán. 11/23/2015 31
  32. 3.2.2 Mô mình cấp quyền System R  Các lệnh SQL gán/thu hồi quyền như sau: all rights  grant privileges  on table all but privileges  to user - list with grant option  all rights  revoke  privileges  on table from user - list 11/23/2015 32
  33. 3.2.2 Mô mình cấp quyền System R GRANT privileges ON object TO users [WITH GRANT OPTION] REVOKE [GRANT OPTION FOR] privileges ON object FROM users {CASCADE | RESTRICT 11/23/2015 33
  34. EMPLOYEE EMPID NAME BDATE ADDRESS SEX SALARY DEPTNO GRANT SELECT ON EMPLOYEE TO user3; GRANT SELECT ON EMPLOYEE TO user3 WITH GRANT OPTION; GRANT INSERT ON EMPLOYEE(NAME,SSN) TO user3; GRANT UPDATE ON EMPLOYEE(SALARY) TO user3; REVOKE SELECT ON EMPLOYEE FROM user3 CASCADE; 11/23/2015 34
  35. 3.2.2 Mô mình cấp quyền System R  Thu hồi quyền (Revoke prilvileges):  Nếu một user được gán quyền trên một table với GRANT OPTION, anh ta có thể gán và thu hồi quyền cho các user khác với các quyền anh ta có.  Mô hình quyền System R sử dụng cơ chế thu hồi đệ quy. Chúng ta có thể diễn giải như sau: người dùng x thu hồi đặc quyền p trên bảng t từ người dùng y. Khi đó theo đệ quy, người dùng y sẽ thu hồi các quyền của anh ta có cho những người dùng anh ta đã gán, tiếp tục đến khi thu hồi hết quyền.  Nếu x thu hồi quyền của y, trong khi đó x không gán quyền gì cho y trước đó, thì việc thu hồi quyền này bị loại bỏ. 11/23/2015 35
  36. 3.2.2 Mô mình cấp quyền System R  Thu hồi quyền đệ quy: (Revoke with cascade option) 11/23/2015 36
  37. 3.2.2 Mô mình cấp quyền System R  Views:  Một user muốn taọ các view – khung nhìn trên các table cơ sở, anh ta phải được:  Người sở hữu table trao quyền create View.  Anh ta ít nhất phải có quyền read trên các bảng cơ sở này, mới có quyền tạo các view.  Một view có thể được tạo từ một hoặc nhiều table cơ sở (Join). Ví dụ: Select SV.*, Lop.TenLop From SV, Lop Where MaLop = MaLop;  Người sở hữu của một khung nhìn có các quyền giống như quyền anh ta có trên các bảng cơ sở. 11/23/2015 37
  38. Kiểm soát truy nhập dựa trên Views Example: CREATE VIEW User3-EMPLOYEE AS SELECT EMPID, NAME, DEPTNO FROM EMPLOYEE 11/23/2015 38
  39. 3.2.2 Mô mình cấp quyền System R  Views:  Người sở hữu một khung nhìn (trên các bảng cơ sở, có các quyền với GRANT OPTION) thì anh ta cũng có thể gán các quyền trên view cho những user khác, thậm chí những user này không có quyền truy nhập nào trên các bảng cơ sở.  Sau khi người sở hữu tạo ra một view, anh ta được gán thêm một số quyền trên các bảng cơ sở, thì anh ta cũng được thêm các quyền đó trên view.  Sau khi tạo ra view, những quyền anh ta bị thu hồi trên các bảng cơ sở cũng bị thu hồi trên các khung nhìn. (DEMO trên SQL Server) 11/23/2015 39
  40. 3.2.2 Mô mình cấp quyền System R  Nhận xét:  Ta chú ý, khi owner của một khung nhìn, gán các quyền truy nhập cho những người dùng khác, những người dùng này có thể thu được dữ liêụ của các table cơ sở qua khung nhìn (trong khi họ không có quyền truy nhập hợp pháp vào các table đó). => Đây cũng là điểm yếu dễ gây lộ thông tin mật. 11/23/2015 40
  41. 3.2.2 Mô mình cấp quyền System R  Mở rộng cho mô hình (do Wilms và Linsday, 1982)  Groups: quản lý theo nhóm, giảm khó khăn trong việc phân phối quyền truy nhập.  Thu hồi quyền không cần đệ quy (Non-recursive revoke): làm giảm đi các yêu cầu phải gán lại quyền khi một user (đang có quyền mức cao) bị xoá hoặc bị thay thế. (dùng hai bảng SYSAUTH, SYSCOLAUTH) 11/23/2015 41
  42. 3.2.2 Mô mình cấp quyền System R  Thu hồi quyền không cần đệ quy (Revoke non-cascading) 11/23/2015 42
  43. 3.2.2 Mô mình cấp quyền System R  Mở rộng cho mô hình (do Wilms và Linsday, 1982)  Quyền phủ định: giả sử user1 không cho phép user3 truy nhập vào một table. Tương tự như vậy, user2 gán quyền truy nhập cho user3 vào table đó. Kết quả?  Quyền phủ định thường mạnh hơn quyền khẳng định: Vì vậy, bất kỳ khi nào người dùng có cả 2 quyền (khẳng định và phủ định) trên cùng một đối tượng, người dùng không được phép truy nhập vào đối tượng, ngay cả khi quyền khẳng định được trao ngay sau khi quyền phủ định được trao.  Một khía cạnh khác: Ví dụ  UserA có quyền write trong bảng EMP (quyền khẳng định)  UserA không có quyền write trong cột Salary của EMP (quyền phủ định) => Dẫn đến xung đột => Giải quyết bằng cách UserA không được phép truy nhập vào cột này. 11/23/2015 43
  44. 11/23/2015 44
  45. 11/23/2015 45
  46. 3. 2 Thiết kế DBMS an toàn 3.2.1 Các cơ chế an toàn trong các DBMS 3.2.2 Mô hình cấp quyền System R 3.2.3 Các kiến trúc của DBMS an toàn 11/23/2015 46
  47. 3.2.3 Các kiến trúc của DBMS an toàn  Hai kiến trúc cơ bản:  Kiến trúc chủ thể tin cậy (Trusted Subject): - Giả thiết rằng một DBMS là tin cậy và một OS tin cậy. - Được sử dụng trong nhiều DBMS thương mại (Sybase, Informix, Ingres, Oracle, DEC, Rubix).  Kiến trúc Woods Hole: - Sử dụng DBMS không tin cậy, và một bộ lọc tin cậy. - Gồm 3 kiến trúc:Integrity Lock, Kernelized, và Replicated - Được hỗ trợ bởi các mẫu nghiên cứu (Mitre, SeaView) và các DBMS thương mại (TRUDATA, Oracle). 11/23/2015 47
  48. 3.2.3 Các kiến trúc của DBMS an toàn 11/23/2015 48
  49. Kiến trúc chủ thể tin cậy (Trusted Subject)  DBMS và OS đều tin cậy.  Khi một DBMS tin cậy được sử dụng và hoạt động như là một chủ thể tin cậy đối với OS, thì nó cũng được tin cậy, nó thực hiện các truy nhập vật lý vào CSDL. Hoạt động như là một chủ thể tin cậy của OS có nghĩa là được miễn một hoặc nhiều khía cạnh nào đó trong chính sách an toàn của OS, nói chung, được miễn các kiểm soát bắt buộc.  Trong kiến trúc này, DBMS có trách nhiệm trong việc bảo vệ đa mức các đối tượng của CSDL. 11/23/2015 49
  50. High user Low user Untrusted Untrusted front end front end Trusted DBMS Trusted OS Database 11/23/2015 50
  51. Kiến trúc chủ thể tin cậy (Trusted Subject)  Người dùng kết nối tới DBMS qua các phần mềm untrusted front end (vì họ kết nối qua Internet).  Người dùng được phân loại các mức nhạy cảm khác nhau: High (cao), Low (thấp), và một mức DBMS khác với hai mức trên.  Các chủ thể và đối tượng được gán một nhãn DBMS không giống với mức High và Low.  Chỉ có các chủ thể được gán nhãn DBMS mới được phép thực hiện mã lệnh và truy nhập vào dữ liệu.  Các chủ thể có nhãn DBMS được coi là các chủ thể tin cậy và được miễn kiểm soát bắt buộc của OS 11/23/2015 51
  52. Kiến trúc chủ thể tin cậy (Trusted Subject)  Các đối tượng CSDL được gán nhãn nhạy cảm (ví dụ: các bộ, các giá trị).  Hệ quản trị Sybase tuân theo giải pháp này, với kiến trúc máy khách/máy chủ, Sybase thực hiện gán nhãn mức bản ghi (mức hàng). 11/23/2015 52
  53. Các kiến trúc Woods Hole  Các kiến trúc Woods Hole sử dụng DBMS không tin cậy cùng với một bộ lọc tin cậy và không quan tâm đến OS có tin cậy hay không.  Được phát triển năm 1982 bởi National Research Council  Các kiến trúc Woods Hole được phân loại như sau:  Kiến trúc Integrity Lock  Kiến trúc Kernelized  Kiến trúc Replicated (còn được gọi là kiến trúc Distributed) 11/23/2015 53
  54. High user Low user Untrusted Untrusted front end front end Trusted front end Untrusted DBMS Database 11/23/2015 54
  55. Các kiến trúc Woods Hole  Nhận xét:  Phần mềm front ends và DBMS đều không tin cậy (Không quan tâm OS có tin cậy hay không)  Phần mềm untrusted front-end thực hiện các công việc xử lý trước và sau các câu truy vấn (phân tích, tối ưu hóa, phép chiếu).  Phần mềm trusted front end (TFE) ở giữa thực thi các chức năng an toàn và bảo vệ nhiều mức, vì vậy hoạt động như một TCB (Trusted Computing Base). 11/23/2015 55
  56. Các kiến trúc Woods Hole  Kiến trúc Integrity Lock  Kiến trúc Kernelized  Kiến trúc Replicated (còn được gọi là kiến trúc Distributed) 11/23/2015 56
  57. Kiến trúc Integrity Lock  Khoá toàn vẹn được đề xuất lần đầu tiên tại Viện nghiên cứu của Lực lượng Không quân về An toàn cơ sở dữ liệu [AF83], được dùng để kiểm soát tính toàn vẹn và sự truy nhập cho cơ sở dữ liệu.  Kiến trúc Integrity lock đã có trong hệ quản trị thương mại TRUDATA. 11/23/2015 57
  58. High user Low user Untrusted Untrusted front end front end Trusted filter Cryptographic unit Append stamp Check stamp Store Response Untrusted DBMS 11/23/2015 Database 58
  59. Kiến trúc Integrity Lock  TFE thực thi bảo vệ nhiều mức bằng cách gắn các nhãn an toàn vào các đối tượng CSDL dưới dạng các tem – Stamps.  Một tem là một trường đặc biệt của một đối tượng, lưu thông tin về nhãn an toàn và các dữ liệu điều khiển liên quan khác.  Tem là dạng mã hóa của các thông tin trên, sử dụng một kỹ thuật niêm phong mật mã gọi là Integrity Lock. 11/23/2015 59
  60. Kiến trúc Integrity Lock  TFE có nhiệm vụ tạo và kiểm tra các tem.  TFE sử dụng mật mã khóa bí mật để tạo tem và giải mã các tem. Các tem này có thể tạo ra dựa vào tổng kiểm tra (checksum).  Khóa bí mật chỉ có TFE biết. 11/23/2015 60
  61. Kiến trúc Integrity Lock  Insert dữ liệu: khi người dùng muốn insert một mục dữ liệu, TFE sẽ tính:  Tổng kiểm tra = mức nhạy cảm user + dữ liệu được insert.  Mã hoá tổng kiểm tra này bằng một khoá bí mật K, tạo ra tem, và lưu vào trong CSDL cùng với mục dữ liệu đó (gắn với mục dữ liệu). 11/23/2015 61
  62. Kiến trúc Integrity Lock  Đưa ra dữ liệu: Khi đưa ra dữ liệu trả cho người dùng, TFE nhận được dữ liệu từ DBMS không tin cậy, nó sẽ kiểm tra tem gắn với mục dữ liệu xem có chính xác không:  Giải mã tem gắn với dữ liệu.  So sánh với tem vừa tính được từ dữ liệu và mức nhạy cảm của nó.  So sánh, nếu không khớp chứng tỏ dữ liệu đã bị sửa đổi. 11/23/2015 62
  63. Kiến trúc Integrity Lock  TFE cũng tạo ra các bản ghi kiểm toán có khuôn dạng giống như các bản ghi kiểm toán do hệ điều hành sinh ra  Các cơ chế an toàn không bảo vệ được các tấn công suy diễn và Trojan, do đó TFE cần được trang bị thêm một số chức năng an toàn.  Đối với mỗi câu truy vấn, TFE sẽ tìm các kết quả tương ứng, và chỉ trả về những kết quả mà người dùng được phép. 11/23/2015 63
  64. Kiến trúc Integrity Lock  Một mô hình về khoá toàn vẹn cơ bản được chỉ ra như trên hình vẽ. Dữ liệu Tính nhạy cảm Tổng kiểm tra N/viên an toàn TS 10FB Nhạy cảm Tổng kiểm tra 11/23/2015 64
  65. Các kiến trúc Woods Hole  Kiến trúc Integrity Lock  Kiến trúc Kernelized  Kiến trúc Replicated (còn được gọi là kiến trúc Distributed) 11/23/2015 65
  66. Kiến trúc Kernelized  Đã có trong mẫu thử Sea View và trong hệ quản trị thương mại Oracle.  Sử dụng một OS tin cậy, có trách nhiệm đối với các truy nhập vật lý vào dữ liệu (trong CSDL) và có trách nhiệm tuân theo bảo vệ bắt buộc.  High User (người dùng làm việc ở mức cao) tương tác với một High DBMS, thông qua một TFE, Low User (người dùng làm việc ở mức thấp) tương tác với một Low DBMS cũng thông qua một TFE.  Sau đó, các yêu cầu của họ được chuyển cho OS, và OS lấy lại dữ liệu hợp lệ từ CSDL. 11/23/2015 66
  67. High user Low user Trusted Trusted front end front end High DBMS Low DBMS Trusted OS Database 11/23/2015 67
  68. Kiến trúc Kernelized  Các đối tượng (có các nhãn an toàn giống nhau) của CSDL được lưu giữ trong các đối tượng của OS tin cậy. Vì vậy, OS tin cậy tiến hành kiểm soát an toàn trên các đối tượng lưu giữ này, cần có các quá trình phân tách và khôi phục quan hệ nhiều mức. 11/23/2015 68
  69. Kiến trúc Kernelized  Quá trình phân tách: thực hiện chuyển đổi một quan hệ đa mức (đối tượng CSDL) thành một số quan hệ đơn mức, (chỉ chứa dữ liệu ở một mức an toàn nào đó), được lưu giữ trong các đối tượng OS, thực hiện khi OS lưu giữ các đối tượng CSDL vào các đối tượng của nó.  Quá trình khôi phục: được thực hiện khi OS cần lấy lại dữ liệu được lưu giữ trên các đối tượng của nó để trả về cho người dùng. Để từ các quan hệ đơn mức, sinh ra một khung nhìn đa mức chỉ chứa các dữ liệu mà người dùng yêu cầu, 11/23/2015 69
  70. Các kiến trúc Woods Hole  Kiến trúc Integrity Lock  Kiến trúc Kernelized  Kiến trúc Replicated (còn được gọi là kiến trúc Distributed) 11/23/2015 70
  71. Kiến trúc Replicated (lặp)  Có trong mẫu thử NRL, nhưng chưa có trong DBMS thương mại nào, vì nó rất đắt. 11/23/2015 71
  72. High user Low user Trusted Trusted front end front end High DBMS Low DBMS Database high Database & low data low data 11/23/2015 72
  73. Kiến trúc Replicated (lặp)  Theo giải pháp này, dữ liệu mức thấp được lặp trong CSDL:  Người dùng mức thấp chỉ được phép truy nhập vào CSDL độ ưu tiên thấp, không có khả năng sửa đổi dữ liệu mức cao.  Người dùng mức cao có thể xem và sửa đổi cả dữ liệu mức thấp và mức cao.  Để tuân theo giải pháp này cần có các thuật toán đồng bộ an toàn để đảm bảo tính tương thích lặp và chi phí lặp cũng rất lớn. 11/23/2015 73
  74. 3.2.3 Các kiến trúc của DBMS an toàn  So sánh 4 kiến trúc DBMS an toàn?  Kiến trúc Trusted Subjects (chủ thể tin cậy)  Kiến trúc Integrity Lock  Kiến trúc Kernelized  Kiến trúc Replicated (còn được gọi là kiến trúc Distributed) 11/23/2015 74
  75. Giới thiệu một số hệ quản trị 11/23/2015 75
  76. Sybase Secure Server  Được phân loại vào lớp B1 hoặc B2  Phân biệt một miền TCB với miền User không tin cậy.  Các đối tượng chính: các hàng trong bảng (table rows), là đối tượng nhỏ nhất có thể được gắn một nhãn an toàn.  Các đối tượng phụ: các bảng, CSDL, bao gồm một danh sách cá truy nhập tuỳ ý (ACLs) mà những user hay group hợp pháp được thực hiện. 11/23/2015 76
  77. Sybase Secure Server  Các chủ thể - Subjects là các user và group user, sử dụng ngôn ngữ truy vấn T-SQL.  Các chủ thể có thể được gán các roles như: nhân viên an toàn, nhà quản trị CSDL, người sở hữu CSDL, người dùng bình thương.  Một thủ tục đăng nhập-Logon được sử dụng để tạo kết nối giữa giao diện người dùng và DBMS.  Một user ở một mức an toàn, chỉ có thể kết nối tới một mức an toàn không vượt quá mức an toàn của anh ta. 11/23/2015 77
  78. Sybase Secure Server  Hoạt động của User: là các yêu cầu bằng các lệnh Transact-SQL (Select, Update, Insert, Delete). Bộ phân tích truy vấn SQL và chương trình dịch sẽ chạy các tiến trình của người dùng không tin cậy. Chúng sẽ truyền các lệnh này thành một tập các lệnh dạng nhị phân (dưới dạng một thủ tục-procedure).  Một thủ tục được thực hiện bởi TCB. TCB cũng kiểm tra quyền truy nhập của người dùng đó dựa vào mức an toàn của anh ta và dựa vào các quyền DAC mà anh ta có.  Kiểm toán-Auditing có thể được cấu hình. 11/23/2015 78
  79. Ingres  Các chủ thể là các users và groups.  Tất cả các user trong một group được cung cấp một tập quyền để thực hiện những ứng dụng cụ thể.  Khi thực hiện một ứng dụng, một user phải gõ vào role và password của role đó.  Các đối tượng-Objects là các CSDL, các danh mục liệt kê-catalogues, tables, views, procedures. Ingres sử dụng Grant và Grant Option cho các quyền Select, Insert, Delete, Update và Execute.  Lệnh Auditdb để kiểm tra kiểm toán. 11/23/2015 79
  80. Oracle  Mức phân loại B1 với Unix, A1 với GEMSOS.  Các chủ thể-Subjects có thể được tạo, thay đổi và bị xoá.  Nhà quản trị định nghĩa một role, gán các đặc quyền-privileges cho role đó và sau đó gán role này cho các chủ thể.  Gán các role cho các role, tạo ra phân cấp.  Đặc quyền Connect để kết nối tới CSDL  Đặc quyền Resource để tạo các bảng cơ sở.  Đặc quyền DBA cũng để tạo các user. 11/23/2015 80
  81. Oracle  Các đối tượng là các CSDL, các bảng, khung nhìn, Các đối tượng có các nhãn an toàn, định nghĩa ở mức quan hệ.  Các phép toán: Select, Insert, Update, Delete, Alter, Index và Reference được thực hiện trên các tables. Đối với các View, chỉ có các phép toán: Select, Insert, Update và Delete. Đặc quyền Execute được thực hiện trên các procedures.  Grant option được dùng.  Lệnh Audit để kiểm tra các vết kiểm toán. 11/23/2015 81
  82. 11/23/2015 82
  83. 3. 2. 4 Thiết kế các cơ sở dữ liệu an toàn 1. Phân tích sơ bộ 2. Các yêu cầu và các chính sách an toàn 3. Thiết kế khái niệm 4. Thiết kế lôgíc 5. Thiết kế vật lý 11/23/2015 83
  84. Các phân tích sơ bộ (Preliminary analysis) Ngôn ngữ đặc tả yêu cầu an toàn (Security Các yêu cầu và các chính sách an toàn requirement (Security requirements and policies) specification language ) Thiết kế khái niệm Mô hình khái niệm an (Conceptual design) toàn (Security Conceptual model) Kỹ thuật DBMS (DBMS technology) Mô hình lôgíc Thiết kế lôgíc an toàn (Lôgícal design) Lược đồ lôgíc (Security Logical model) an toàn (Security Logical schema) Mô hình vật lý an toàn Thiết kế vật lý (Physical design) (Security Physical Các tham số chiếu (hiệu model) năng) Project parameters (performances) Các cơ chế an toàn (Security mechanisms) Thực thi 11/23/2015 (Implementation) 84
  85. 3. 2. 4 Thiết kế các cơ sở dữ liệu an toàn 1. Phân tích sơ bộ 2. Các yêu cầu và các chính sách an toàn 3. Thiết kế khái niệm 4. Thiết kế lôgíc 5. Thiết kế vật lý 11/23/2015 85
  86. 3.2.4.1. Giai đoạn phân tích sơ bộ  Mục đích: của giai đoạn này là tiến hành nghiên cứu tính khả thi của hệ thống an toàn  Nội dung:  Đánh giá các rủi ro  ước lượng các chi phí thiết kế  Phát triển các ứng dụng cụ thể nào và xác định quyền ưu tiên của chúng. 11/23/2015 86
  87. 3.2.4.1. Giai đoạn phân tích sơ bộ  Các rủi ro hệ thống: là các đe doạ đáng kể nhất có thể xảy ra đối với một cơ sở dữ liệu như: đọc và sửa đổi trái phép dữ liệu, từ chối dịch vụ => hình thức xâm phạm tương ứng.  Các đặc trưng của môi trường cơ sở dữ liệu: xem có bảo vệ đa mức hay không.  Khả năng ứng dụng của các sản phẩm an toàn hiện có (Ingres, Oracle, Sybase, SQL Base ) 11/23/2015 87
  88. 3.2.4.1. Giai đoạn phân tích sơ bộ  Khả năng tích hợp của các sản phẩm an toàn: khả năng tích hợp các cơ chế an toàn với các cơ chế phần cứng và phần mềm thực tế.  Hiệu năng đạt được của các hệ thống an toàn =>Kết quả của giai đoạn này là một tập hợp các đe doạ dễ xảy ra với một hệ thống, được sắp xếp theo quyền ưu tiên và đánh giá khả năng áp dụng và tích hợp của các sản phẩm thương mại an toàn với các cơ chế hiện tại. 11/23/2015 88
  89. 3. 2. 4 Thiết kế các cơ sở dữ liệu an toàn 1. Phân tích sơ bộ 2. Các yêu cầu và các chính sách an toàn 3. Thiết kế khái niệm 4. Thiết kế lôgíc 5. Thiết kế vật lý 11/23/2015 89
  90. 3.2.4.2 Phân tích yêu cầu và chọn lựa chính sách an toàn => Xuất phát từ tất cả các đe doạ có thể xảy ra với hệ thống.  Yêu cầu bảo vệ của mỗi cơ sở dữ liệu khác nhau, phụ thuộc vào:  Tính nhạy cảm của thông tin.  Tính tương quan dữ liệu  Chia sẻ dữ liệu  Khả năng truy nhập dữ liệu  Kỹ thuật được lựa chọn 11/23/2015 90
  91. 3.2.4.2 Phân tích yêu cầu và chọn lựa chính sách an toàn  Phân tích yêu cầu:  Phân tích giá trị : xác định mức nhạy cảm của dữ liệu.  Nhận dạng đe doạ/phân tích điểm yếu  Phân tích và đánh giá rủi ro: khả năng xảy ra của các biến cố không mong muốn và tác động của chúng.  Xác định yêu cầu 11/23/2015 91
  92. 3.2.4.2 Phân tích yêu cầu và chọn lựa chính sách an toàn  Lựa chọn chính sách: Chính sách là các quy tắc ở mức cao, bắt buộc phải tuân theo trong các quá trình thiết kế, thực thi và quản lý hệ thống an toàn.  Định nghĩa các chế độ truy nhập (đọc, ghi) của chủ thể vào các đối tượng của hệ thống  Tính bí mật, tính toàn vẹn, tính tin cậy  Chia sẻ tối đa và đặc quyền tối thiểu  Mức độ chi tiết của kiểm soát  Các thuộc tính được sử dụng cho kiểm soát truy nhập 11/23/2015 92
  93. 3.2.4.2 Phân tích yêu cầu và chọn lựa chính sách an toàn  Các quyền ưu tiên (priorities): quyền của cá nhân ưu tiên hơn quyền của nhóm, quyền từ chối truy nhập ưu tiên hơn các quyền khác.  Các đặc quyền (privileges): tồn tại một số đặc quyền ngầm định (đọc, ghi) cho chính sách DAC, nhưng MAC thì không.  Quyền (Authority): định nghĩa các role người dùng với các quyền và mức kiểm soát khác nhau.  Tính kế thừa (inheritance): cho phép việc sao chép quyền truy nhập hay không (chỉ cho DAC) 11/23/2015 93
  94. 3.2.4.3 Thiết kế khái niệm  Một mô hình an toàn khái niệm được định nghĩa thông qua  Nhận dạng các chủ thể và các đối tượng liên quan đến một quan điểm an toàn  Nhận dạng các chế độ truy nhập được trao cho các chủ thể khác nhau trên các đối tượng khác nhau, các ràng buộc truy nhập.  Phân tích việc thừa kế các quyền trên hệ thống, thông qua các đặc quyền trao/thu hồi. => Các yêu cầu được biểu diễn thành các bộ bốn, như sau: {subject, access right, objects, predicate}, trong đó tân từ 11/23/2015(predicate) miêu tả các điều kiện truy nhập có thể. 94
  95. 3. 2. 4 Thiết kế các cơ sở dữ liệu an toàn 1. Phân tích sơ bộ 2. Các yêu cầu và các chính sách an toàn 3. Thiết kế khái niệm 4. Thiết kế lôgíc 5. Thiết kế vật lý 11/23/2015 95
  96. 3.2.4.3 Thiết kế khái niệm  Các đặc trưng cơ bản của một mô hình an toàn khái niệm  Biểu diễn các ngữ nghĩa của an toàn cơ sở dữ liệu: tính bí mật và toàn vẹn của mục dữ liệu được thể hiện qua phạm vi của thông tin trong mục này.  Hỗ trợ việc phân tích các luồng quyền, có nghĩa là phân tích các kết quả khi trao/thu hồi quyền.  Hỗ trợ người quản trị cơ sở dữ liệu 11/23/2015 96
  97. 3.2.4.3 Thiết kế khái niệm  Yêu cầu đối với một mô hình an toàn khái niệm:  Đầy đủ (complete):Mô hình đáp ứng được tất cả các yêu cầu an toàn đã được xác định ban đầu.  Nhất quán (consistent): đảm bảo các yêu cầu không có sự xung đột hay dư thừa. =>Hiện có rất nhiều mô hình an toàn (như: Bell-La Padula, Biba, Graham-Denning, Harrison-Ruzzo- Ullman, Take-Grant việc chọn lựa các mô hình tuỳ thuộc vào kiểu của hệ thống, có nghĩa là kiểu của tài 11/23/2015nguyên được bảo vệ 97
  98. 3. 2. 4 Thiết kế các cơ sở dữ liệu an toàn 1. Phân tích sơ bộ 2. Các yêu cầu và các chính sách an toàn 3. Thiết kế khái niệm 4. Thiết kế lôgíc 5. Thiết kế vật lý 11/23/2015 98
  99. 3.2.4.4 Thiết kế lôgíc  Chuyển đổi từ mô hình khái niệm sang mô hình logic dựa trên một DBMS cụ thể.  Sử dụng một số kỹ thuật dựa vào câu truy vấn và khung nhìn để kiểm soát truy nhập.  Cần quan tâm các cơ chế mức OS và các chức năng mà các gói an toàn có thể đưa ra 11/23/2015 99
  100. 3. 2. 4 Thiết kế các cơ sở dữ liệu an toàn 1. Phân tích sơ bộ 2. Các yêu cầu và các chính sách an toàn 3. Thiết kế khái niệm 4. Thiết kế lôgíc 5. Thiết kế vật lý 11/23/2015 100
  101. 3.2.4.5 Thiết kế vật lý  Trong giai đoạn này người ta quan tâm đến các chi tiết liên quan đến việc tổ chức lưu trữ và các chế độ thực hiện/tích hợp các mô hình.  Từ mô hình logic, thiết kế chi tiết các cơ chế an toàn, bao gồm:  Thiết kế cấu trúc vật lý  Các quy tắc truy nhập 11/23/2015 101
  102. Các phân tích sơ bộ (Preliminary analysis) Ngôn ngữ đặc tả yêu cầu an toàn (Security Các yêu cầu và các chính sách an toàn requirement (Security requirements and policies) specification language ) Thiết kế khái niệm Mô hình khái niệm an (Conceptual design) toàn (Security Conceptual model) Kỹ thuật DBMS (DBMS technology) Mô hình lôgíc Thiết kế lôgíc an toàn (Lôgícal design) Lược đồ lôgíc (Security Logical model) an toàn (Security Logical schema) Mô hình vật lý an toàn Thiết kế vật lý (Physical design) (Security Physical Các tham số chiếu (hiệu model) năng) Project parameters (performances) Các cơ chế an toàn (Security mechanisms) Thực thi 11/23/2015 (Implementation) 102
  103. 3.2.4.6 Việc thực hiện của các cơ chế an toàn  Một số quy tắc trong quá trình thiết kế các hệ thống bảo vệ an toàn:  Tính kinh tế của các cơ chế: Một hệ thống bảo vệ cần nhỏ, đơn giản và minh bạch, giảm bớt các chi phí, độ tin cậy cao hơn, việc kiểm tra và kiểm toán các giai đoạn của hệ thống dễ dàng hơn. Các cơ chế cần đơn giản đến mức có thể.  Hiệu quả: Các cơ chế nên hiệu quả, vì chúng thường được gọi trong thời gian chạy. Cách hướng tiếp cận dựa vào nhân không thoả mãn hoàn toàn yêu cầu này 11/23/2015do quá tải hoặc các gánh nặng về hiệu năng 103
  104. 3.2.4.6 Việc thực hiện của các cơ chế an toàn  Độ tuyến tính của các chi phí : Sau giai đoạn cài đặt, các chi phí hoạt động nên cân xứng với việc sử dụng thực tế của cơ chế  Phân tách đặc quyền: ý tưởng là phân tầng các cơ chế kiểm soát và làm cho truy nhập phải phụ thuộc vào nhiều điều kiện hơn (ví dụ có nhiều mức mật khẩu).  Đặc quyền tối thiểu  Hạn chế lỗi  Bảo trì  Ngăn chặn con ngựa thành Tơroa 11/23/2015 104
  105. 3.2.4.6 Việc thực hiện của các cơ chế an toàn  Dàn xếp toàn bộ : Mỗi truy nhập vào một đối tượng đều phải được kiểm tra bằng các kiểm soát truy nhập.  Thiết kế mở: nên để công khai các kỹ thuật an toàn, đối với những thành phần bí mật, dùng khóa và mật khẩu để che dấu.  An toàn bằng mặc định: Nếu người sử dụng không quyết định các tuỳ chọn thì các tuỳ chọn bảo vệ thường được đặt ngầm định 11/23/2015 105
  106. 3.2.4.6 Việc thực hiện của các cơ chế an toàn  Các cơ chế chung tối thiểu: việc chia sẻ tạo nên những kênh thông tin tiềm tàng, các cơ chế nên độc lập với nhau.  Dễ sử dụng: Việc sử dụng các cơ chế phải dễ dàng, cho phép người dùng sử dụng chúng một cách phù hợp  Tính mềm dẻo: Một cơ chế an toàn nên tuân theo các chính sách khác nhau, hiệu quả trong nhiều trường hợp khác nhau ngay cả trong tình huống xấu nhất. 11/23/2015 106
  107. 3.2.4.6 Việc thực hiện của các cơ chế an toàn  Sự cách ly: Cơ chế an toàn nên cách ly (trong suốt) từ các thành phần khác nhau của hệ thống, và nó có thể chống lại được nhiều kiểu tấn công.  Tính đầy đủ và nhất quán: Cơ chế an toàn phải đầy đủ (có nghĩa là nó tuân theo toàn bộ các đặc tả thiết kế) và nhất quán (có nghĩa là không tồn tại các mâu thuẫn vốn có)  Khả năng quan sát: Cần có khả năng kiểm soát cơ chế an toàn và các tấn công chống lại cơ chế đó 11/23/2015 107
  108. 3.2.4.6 Việc thực hiện của các cơ chế an toàn  Vấn đề bỏ sót: Phần bị bỏ sót là các đoạn thông tin được lưu trữ trong bộ nhớ sau khi tiến trình kết thúc. Dữ liệu có thể bị lộ nếu các chủ thể trái phép có thể kiểm tra các phần bị bỏ sót  Khả năng không nhìn thấy được của dữ liệu: Nội dung của một đối tượng và sự tồn tại của đối tượng đó cần được che dấu để tránh những người dùng trái phép này suy diễn ra các đối tượng đó.  Hệ số làm việc: Việc phá vỡ một cơ chế an toàn phải là một công việc khó khăn, đòi hỏi nhiều nỗ lực 11/23/2015 108
  109. 3.2.4.6 Việc thực hiện của các cơ chế an toàn  Các bẫy chủ ý: Chúng ta có thể thiết kế một cơ chế với các lỗi chủ ý bên trong, sau đó kiểm soát chúng trong thời gian thực của hệ thống, để phát hiện ra các cố gắng xâm nhập có thể, nhằm giám sát các hành vi của kẻ xâm nhập.  Xác định tình trạng khẩn cấp: Chúng ta nên thiết kế cơ chế cùng với các phương thức “disable”- "mất khả năng làm việc“ trong trường hợp cần xây dựng lại hay cấu hình lại hệ thống, khi có sự cố xảy ra, hoặc khi có nhu cầu tổ chức lại hệ thống. 11/23/2015 109
  110. 3.2.4.6 Việc thực hiện của các cơ chế an toàn  Phần cứng an toàn: Yêu cầu này dành cho hệ thống được bảo vệ. Phần cứng phải tin cậy và được bảo vệ vật lý, bởi vì kẻ xâm nhập có thể dễ dàng sử dụng các lỗi phần cứng/phần mềm nhằm vượt qua kiểm soát an toàn.  Ngôn ngữ lập trình: cần lựa chọn một ngôn ngữ lập trình và dùng những nhà lập trình có kỹ năng để giảm tối thiểu lỗi xảy ra. Việc sửa đổi chương trình phải song hành với việc cập nhật các đặc tả.  Tính đúng đắn: Các cơ chế phải thông dịch một cách chính xác mô hình, nếu ngược lại thì các cơ chế này được xem là không đúng. 11/23/2015 110
  111. 3.2.4.7 Việc kiểm tra và thử nghiệm  Mục đích của giai đoạn này là kiểm tra các yêu cầu và các chính sách an toàn. Việc kiểm tra này được thực hiện thông qua sản phẩm phần mềm  Chứng minh tính đúng đắn của chương trình: có thể chứng minh mã lệnh trong một số ngôn ngữ lập trình là đúng đắn.  Thử nghiệm: phân tích hoạt động của hệ thống bằng cách kiểm tra, thuê chuyên gia để thử xâm nhập vào hệ thống 11/23/2015 111
  112. Câu hỏi và bài tập  Tìm hiểu một số mô hình an toàn: Take- Grant, Action-Entity, Seaview  Thiết kế cơ sở dữ liệu an toàn cho bài toán: Quản lý sinh viên trên hệ quản trị SQL Server. 11/23/2015 112
  113. 11/23/2015 113
  114.  Cơ chế an toàn là một tập hợp các chức năng phần cứng, phần sụn và phần mềm tuân theo các chính sách 11/23/2015 114