Bài giảng Cơ sở dũ liệu - Chương 14: Security

các yêu cầu đặc biệt của mỗi ứng dụng. Hơn nữa, để có thể hạn chế việc truy xuất dữ liệu của người dùng thông qua 1 ứng dụng nào đó hay để tránh khỏi truy xuất dữ liệu trực tiếp, cần ngăn chặn người dùng không được kết nối vào SQL server thông qua ứng dụng. Vì khi truy xuất vào SQL server được, họ có thể tạo ra các truy vấn sai trong cửa sồ analyzer , ảnh hưởng đến việc thực thi của cả server. gây hậu quả xấu Để đáp ứng các yêu cầu trên, SQL server đã cung cấp 1 role đặc biệt khác với role tiêu chuẩn, đó là application role Application RolesApplication role không có member (thành viên) như các role khác. Quyền của apllication role có được khi application role hoạt động do 1 ứng dụng nào đó đang chạy. Người dùng có liên quan đến application role là do người dùng đó có khả năng chạy được ứng dụng hơn là do nguời dùng đó là thành viên của application role. Mặc định application role không hoạt động ( inactive) và đòi hỏi password khi được kích hoạt. Application RoleApplication role sẽ bỏ qua các quyền tiêu chuẩn. Application role sẽ hoạt động khi có 1 ứng dụng đang kết nối vào SQL server. Việc kết nối này sẽ làm mất tất cả các quyền của login ID, user ID, các group hay các database role khác trong tất cả các DB trong suốt thời gian kết nối. Việc kết nối này sẽ đạt được các quyền có liên quan đến application role của DB nào mà ứng dụng đang chạy. Application RoleVì application role chỉ có thể áp dụng vào DB mà ứng dụng đang chạy, kết nối có thể truy xuất được đến các DB khác chỉ thông qua các quyền được cấp cho user guest trong các DB khác mà thôi. Vì vậy nếu user guest không tồn tại trong 1 DB nào đó, thì kết nối không thể truy xuất vào DB đó được. Thậm chí ngay cà khi có user guest nhưng quyền truy xuất vào 1 đối tượng nào đó không được gán 1 cách tường minh thì user guest dù có kết nối được cũng không thể truy xuất đối tượng đó được bất kể ai đã tạo ra đối tựong đó. Quyền của user có được từ application role vần còn có hiệu quả cho đến khi kết nối thoát khỏi SQL server. Application RoleĐể bảo đảm là tất cả chức năng của ứng dụng có thể được thực thi, một kết nối phải làm mất đi các quyên được áp dụng cho các tài khoản login và user hay các group, database role trong tất cả các DB trong suốt thời gian kết nối và chỉ có quyền liên quan đến ứng dụng mà thôi. Ví dụ nếu 1 user thường bị từ chối truy xuất vào bảng mà 1 ứng dụng có thể truy xuất vào được,khi đó việc bị từ chối truy xuất này sẽ hủy bỏ khi user sử dụng ứng dụng này Application role cho phép ứng dụng được quyền xác nhận người dùng ( user authentication). Tuy nhiên SQL server vần phải xác nhận ứng dụng khi nó truy xuất vào DB, ứng dụng phải cung cấp password vì không có cách nào khác đề xác nhận một ứng dụng có hợp lệ hay không.sp_addapproleTạo 1 application role cho DB hiện hànhCú phápsp_addapprole [ @rolename = ] 'role‘ , [ @password = ] 'password' Giá trị trả về của thủ tục :0 (thành công) hoặc 1(bị lỗi)Có thể tạo application role từ enterprise managersp_setapproleĐể kích hoạt 1 application role trong DB hiện hànhCú phápsp_setapprole [@rolename =] 'role' , [@password =] 'password‘Sau khi application role được kích hoạt bằng sp_setapprole, role sẽ không bị mất tác dụng trong DB hiện hành cho đến khi user ngắt kết nối khỏi SQL Server Thủ tục sp_setapprole chỉ có thể được gọi trực tiếp bằng lệnh exec. Nó không thể được thực thi bên trong 1 thủ tục khác hay từ 1 transaction của người dùngVí dụ: EXEC sp_setapprole 'SalesApprole', 'AsDeFXX' Ví dụSue đang chạy ứng dụng Sales ma ứng dụng này yêu cầu các quyền SELECT, UPDATE và INSERT vào các bảng Products và Orders trong CSDL Sales, nhưng cô ta lại không có các quyền này khi truy xuất trực tiếp vào hai bảng trên khi dùng cửa sổ Analyzer hay các công cụ khác của SQL. Tạo 1 Database role cấm các quyền SELECT, INSERT và UPDATE trên bảng Products và Orders, và thêm Sue vào như là thành viên của role đó. Sau đó tạo 1 application role trong database Sales với các quyền SELECT, INSERT và UPDATE trên các bảng Products và Orders. Khi application chạy, cần đưa password vào để kích hoạt application role. Nếu Sue cố đăng nhập vào SQL server không thông qua ứng dụng thì cô ta không thể nào truy xuất vào được hai bảng Products và OrdersCác loại quyền (Permissions) Khi 1 đối tượng được tạo ra, chỉ có owner ( người tạo đối tượng) mới có quyền truy xuất đối tựong. Owner phải cấp quyền cho các user khácUser phải có quyền thích hợp để thực thi bất kỳ hoạt động nào liên quan đến việc thay đổi định nghĩa DB hay truy xuất dữ liệuCó 3 loại quyền • Object Permissions• Statement Permissions	• Implied PermissionsTất cả các quyền trong SQL server có thể tồn tại dưới 1 trong 3 trạng thái sau: granted ( cấp quyền), revoked (thu hồi) và denied (từ chối).Object Permissions (Quyền về đối tượng)Ngay khi 1 DB được tạo, các user cần được cho quyền để làm việc với dữ liệu được lưu trữ trong DB. Có 6 lọai quyền object :SELECT: cho phép user đọc dữ liệu từ 1 bảng hay view INSERT: cho phép user thêm các hàng mới vào bảngUPDATE: cho phép user sửa đổi dữ liệu hiện có trong bảng, tuy nhiên user không thể thêm hay xóa các hàng trong bảng đượcDELETE: cho phép user được quyền xóa các hàng trong bảngREFERENCES khi 2 bảng kết với nhau thông qua khóa ngọai (foreign key) quyền REFERENCES cho phép user chọn dữ liệu từ bảng primary mà không cần có quyền SELECT trên bảng foreignEXECUTE: cho phép user thực thi thủ tục mà user được cấp quyềnStatement PermissionsQuyền về lệnhCho phép các họat động liên quan đến việc tạo DB hay 1 đối tượng nào đó trong DB như bảng, thủ tục. Các quyền về lệnh đươc áp dụng chỉ cho lệnh hơn là cho bản thân các đối tượng. Các Statement permissions làBACKUP DATABASEBACKUP LOGCREATE DATABASECREATE DEFAULTCREATE FUNCTIONCREATE PROCEDURECREATE RULECREATE TABLECREATE VIEWImplied PermissionsQuyền ngầm địnhImplied permissions kiểm sóat các họat động mà chỉ có thể được thực hiện bởi các thành viên của các role hệ thống (như sysadmin,..) hoặc các owner của các đối tượng CSDL.Các owner của các đối tượng DB cũng có thể có các quyền ngầm định cho phép họ thực thi tất cả các hoạt động với đối tượng mà họ là chủData Control LanguageCó thể dùng các lệnh DCL(Data Control Language) để thay đổi các quyền có liên quan đến user hay role của DB. Có 3 lệnh DCL :• GRANT• REVOKE• DENYData Control LanguageLệnh GRANT cho phép user, group hay role làm việc với lệnh về dữ liệu hay thực thi các lệnh T-SQLCú pháp:Statement permissions:	GRANT { ALL | statement [ ,...n ] } TO security_account [ ,...n ] Object permissions:GRANT     { ALL | permission [ ,...n ] }     {         [ ( column [ ,...n ] ) ] ON { table | view }         | ON { table | view } [ ( column [ ,...n ] ) ]         | ON { stored_procedure | extended_procedure }         | ON { user_defined_function }    } TO security_account [ ,...n ] [ WITH GRANT OPTION ] [ AS { group | role } ] Data Control LanguageALL: đối với quyền về lệnh (statement permission), thì ALL chỉ có thể được dùng bởi các thành viên của sysadmin. Đối với quyền về đối tượng (object permissions), ALL chỉ được dùng bởi các thành viên của sysadmin, db_owner và owner của đối tượng CSDL.WITH GRANT OPTION (chỉ dùng cho quyền về đối tượng) cho khả năng các tài khoản sau khi được gán quyền được phép cấp quyền này cho các tài khoản khácVí dụ:Use pubsGRANT select, insert, update ON titles TO facultyData Control Language (Contd.)Lệnh Deny để loại bỏ quyền khỏi 1 tài khoản trong CSDL hiện hành và để tránh tài khoản này được thừa hưởng quyền của nhóm hay role của tài khoản đó.Cú pháp:DENY [ON ]TO Ví dụ:Use pubsDENY select, insert, update ON titles TO facultyLệnh REVOKE dùng để thu hồi lại quyền đã đuợc cấp hay từ chối từ 1 user của CSDL hiện hành Cú phápREVOKE [GRANT OPTION FOR] [ON ]TO Ví dụ: 	REVOKE select, insert, update ON titles TO facultyGiải quyết xung đột các quyềnCác quyền được cấp cho 1 nhóm hay 1 role sẽ được kế thừa bởi các thành viên của nhóm hay role đó. Mặc dù user có thể có quyền grant hay revoke 1 mức nào đó nhưng có thể bị xung đột ở mức cao hơn làm cho user có thể bị ngăn hay cho phép truy xuất đến 1 đối tượng.Deny: quyền deny luôn ưu tiên hơn. Quyền deny ở bất kỷ mức nào cũng sẽ cấm các quyền trên các đối tượng bất kể có tồn tại quyền grant hay revoke dành cho user đó hay không. Ví dụ nếu John là thành viên của role sales, role này đã được cấp quyền SELECT trên bảng Customer, nếu John bị cấm (deny) 1 cách tường minh quyền SELECT trên bảng Customer thì John sẽ không còn được truy xuất vào bảng đó nữa. Tương tự, nều role sales bị cấm truy xuất bảng customer thì dù cho John được cấp quyền truy xuất cũng sẽ bị cấm theo. Lưu ý: SQL Server luôn xử lý các quyền bị cấm trước. Nếu bạn deny các quyền vào role public thì có nghĩa là bạn cấm mọi người truy xuất đến đối tượng đó kể cả người đã tạo ra lệnh DENY nàyGiải quyết xung đột các quyềnRevoke: chỉ thu hồi các quyền được cấp hoặc bị từ chối ở mức được thu hồi ( user, group hay role). Cùng 1 quyền đó mà được cấp hay cấm ở mức khác chẳng hạn của 1 group hay 1 role chứa user đó thì quyền của group hay role vẫn đựoc áp dụng. Ví dụ: nếu role sale được cấp quyền SELECT trong bảng Customer và John (thành viên của sales) đã bị thu hồi một cách tường minh quyền SELECT trên bảng customer, anh ta vẫn có thể truy xuất bảng đó do anh ta vẫn là thành viên của role sales. Để tránh cho John không truy xuất được vào bảng customer phải thực hiện 1 trong 3 cách sau: Thu hồi quyền (giả thiết là John không có quyền nào khác ở cấp khác)Cấm quyền vào role sales ( cấm tất cả các thành viên của sales không được truy xuất vào bảng)Cấm 1 cách tường mình John quyền SELECT trên bảng customer. Giải quyết xung đột các quyềnGrant: xóa các quyền bị cấm hoặc bị thu hồi ở mức được cấp. Cùng quyền này mà bị cấm ở mức khác chẳng hạn mức group hay role thì các quyền này vẫn còn được áp dụng. Ví dụ quyền thu hồi dành cho role sales kết hợp với quyền được cấp cho John sẽ cho John quyền được cấp.Vì vậy, 1 user nhận 1 tổ hợp của tất cả quyền được cấp, cấm hay thu hồi trên 1 đối tượng thì quyền bị cấm sẽ ưu tiên hơn.