SECURITY Bảo mật trong cơ sở dữ liệu

SQL SECURITY C o u rs e I LT Chương 14 SECURITY Bảo mật trong cơ sở dữ liệu C o u rs e I LT Mục tiêu  Trong phần này, chúng ta sẽ học về – Các tính chất bảo mật của SQL Server – Tạo tài khoản đăng nh[.]

Bảo mật trong cơ sở dữ liệu

tài khoản người dùng (user ID)

– Các loại User Roles:

 Fixed Server Roles

 Database Roles

– Các loại quyền bảo mật( Security Permissions)

– Giải quyết xung đột giữa các quyền

 Mỗi database nên có 1 hệ thống bảo mật đáng tin cậy

động cũng như các thông tin cần được xem và chỉnh sửa

 Một hệ thống bảo mật đáng tin cậy phải

bảo đám được việc bảo vệ dữ liệu bất kể việc user đã dùng cách nào để truy xuất vào database SQL áp dụng các quyền bảo mật vào các mức: mức database, mức các đối tượng và mức các cột của bảng

 Cần phân biệt Login ID và user ID:

– Người dùng muốn truy xuất vào Microsoft SQL Server, thì phải

có login ID và password Nhưng login ID chính nó không cho phép nguời dùng quyền truy xuất đến các DB Muốn tạo login

ID, dùng lệnh sp_addlogin

– User ID nhận dạng người dùng trong 1 DB Tất cả các quyền và

chủ quyền của các đối tượng trong DB đều được điều khiển bởi user ID Ví dụ user ID là xyz trong DB sales khác với user ID cũng tên là xyz trong DB inventory

 Một login ID phải kết hợp với 1 user ID

trong mỗi DB để truy xuất dữ liệu trong

DB Nếu login ID không được kết hợp tường minh với 1 user ID thì nó sẽ kết hợp với user ID là guest Nều DB không

có user ID guest thì không thể truy xuất vào DB được

– sa là 1 tài khoản đăng nhập (login account)

được ánh xạ tự động với user ID dbo trong mọi

DB

– Guest là user ID đặc biệt

 Việc quản trị sẽ dễ dàng hơn nếu login

ID và user ID giống nhau nhưng điều này không bắt buộc.

 User có thể truy xuất vào DB thông qua 1

account đăng nhập (login ID) hợp lệ , nhờ

đó user có khả năng kết nối vào database server Quá trình này được gọi là

authentication(xác thực)

 Tài khoản đăng nhập (Login ID) sẽ được

ánh xạ với tài khoản user ( user ID) để cho phép user được quyền truy xuất trong 1 DB Quá trình này gọi là authorization (cấp phép) (hay permission validation) User

sẽ không thể truy xuất vào DB ngay cả khi

họ có tài khoản đăng nhập (login ID ) hợp

lệ

 Sử dụng tài khoản đăng nhập của chính Windows như tài

khoản đăng nhập vào SQL server

– Sử dụng thủ tục sp_grantlogin

 Tạo 1 tài khoản đăng nhập của riêng SQL server

– Sử dụng thủ tục sp_addlogin

sp_grantlogin [@loginame =] 'login‘

 Ví dụ: muốn có thể đăng nhập vào SQL server bằng account

của Windows là user1, ta dùng lệnh sau:

sp_grantlogin ‘user1’

Tạo User login của SQL server

 Chỉ có người quản tri (administrator)

mới có quyền tạo login ID mới.

sp_addlogin [ @loginame = ] 'login'

    [ , [ @passwd = ] 'password' ]     [ , [ @defdb = ] 'database' ]

 Ví dụ:

EXEC sp_addlogin ‘student1','Password','master'

Tạo user cho DB hiện hành

 Để thêm 1 tài khoản (ID) cho 1 user mới vào DB

hiện hành

 Cú pháp:

 sp_adduser [ @loginame = ] 'login'

    [ , [ @name_in_db = ] 'user' ]     [ , [ @grpname = ] 'group' ]

 Chú ý: chỉ có thể tạo user mới cho những user

nào đã có tài khoản đăng nhập (login ID)

 ‘login‘: xác định login id của user

 'user‘ là tên của user mới Nếu tuỳ chọn này

không được xác định, tên của user sẽ chính là tên login id của user đó Có thể tạo ra tài khoản user khác với tên login id của user đó.

 'group‘ là nhóm hay role mà user mới này sẽ tự

động trở thành thành viên của nhóm.

 Có thể tạo user mới từ Enterprise Manager

 Role là một công cụ cực mạnh cho phép ta

tập hợp các user vào cùng 1 unit nhờ đó ta

có thể gán quyền chung cho cả unit đó

 Tương tự như trong 1 công ty, ta có thể

tập hợp các công nhân làm cùng 1 công việc lại 1 nhóm, nhờ đó ta có thể giao việc, cấp quyền cho cả nhóm Mọi thành viên

trong nhóm sẽ có quyền như nhau Nếu chức năng của nhóm thay đổi, ta chỉ đơn giản thay đổi quyền của nhóm, khi đó

những thay đổi này sẽ được tự động áp dụng cho tất cả các thành viên trong

nhóm.

hợp các role dựa theo yêu cầu công việc

và gán mỗi role những quyền hạn (permission) khác nhau Sau đó, chỉ cần chuyển các user vào các role thích hợp hơn là phải cấp quyền cho mỗi user

riêng lẻ Nếu công việc thay đổi chỉ cần thay đổi quyền trong mỗi role thì những thay đổi này sẽ tự động được áp dụng cho toàn bộ các thành viên của role đó

 Các user có thể là thành viên của nhiều

role

 Giả sử có CSDL là courses, sau khi người

quản trị cho phép 5 tài khoản Windows bao gồm giáo sư John, Sarah, Diane và 2 sinh viên Betty và Ralph được đăng nhập vào SQL server Đặc biệt là Diane vừa là giáo

sư nhưng lại vừa theo học 1 lớp khác

Người quản trị cần cấp cho các giáo sư quyền được update điểm sinh viên, còn các sinh viên thì chỉ được xem điểm của

họ Người quản trị đã tạo ra 2 view có tên

là ProfessorGradeView dành cho giáo sư,

và StudentGradeView dành cho sinh viên.

 Script của người quản trị nên có nội dung

như thế nào??

GRANT SELECT, UPDATE ON

ProfessorGradeView TO Professor

GO

Các loại User Roles

 Trong SQL server không có group Tuy nhiên ta có thể quản lý

việc bảo mật của SQL server thông qua các group của Windows.

 Các nhóm của Windows có thể được dùng như là các role của

Fixed Server Roles

 Hạn chế khả năng truy xuất vào các

CSDL riêng lẻ sau khi user đăng nhập vào.

 Có 8 loại server roles Danh sách sau liệt

kê các loại này mà khả năng quản trị theo thứ tự giảm dần.

– sysadmin: quyền tối đa mà không bị bất kỳ 1 hạn chế nào Mặc định, tất cả các thành viên của nhóm quản trị Windows

(Administrators)và user sa thuộc vào server role này

– serveradmin: có quyền cấu hình mức server như xác lập lượng

bộ nhớ mà SQL server có thể dùng khi truyền thông tin qua mạng

Fixed Server Roles

– setupadmin: có quyền thực thi replication và quản trị các thủ tục (extended stored procedures)

– securityadmin: điều hành bảo mật như tạo login và gán quyền

– processadmin: có quyền kết thúc các tiến trình được gọi không hợp lệ

– dbcreator: tạo và chỉnh sửa database

Fixed Server Roles

– diskadmin: thực hiện các hoạt động sao lưu như sao chép đĩa và tạo các thiết bị sao lưu

– bulkadmin: thực hiện lệnh BULK INSERT

 Lưu ý: Một thành viên của bất kỳ server

role nào đều có thể thêm các user khác vào chính server role đó

 Để xem các fixed server roles:

sp_helpsrvrole

 Để xem quyền của mỗi role

sp_srvrolepermission

Fixed Server Roles

 Để gán 1 user vào 1 fixed server role, ta

có thể dùng lệnh sau

 Cú pháp:

sp_addsrvrolemember [ @loginame = ] 'login', [ @rolename = ] 'role‘

 Ví dụ 1: gán user1 vào nhóm sysadmin

EXEC sp_addsrvrolemember 'User1',

'sysadmin‘

 Ví dụ 2: thêm user của Windows NT

Corporate\HelenS vào role sysadmin

EXEC sp_addsrvrolemember 'Corporate\HelenS', 'sysadmin'

 Mỗi Database có một bộ các fixed database

roles Phạm vi của mỗi role này là chỉ trong từng database riêng rẽ.

 Ví dụ: nếu Database1 và Database2 cả hai đều

có 1 user ID là UserX Nhưng UserX trong Database1 thuộc fixed database role tên là db_owner Role này không ảnh hưởng gì đến UserX trong Database2 khi user này là thành viên của role có tên là db_owner

 Database roles cho phép bạn gán quyền cho 1

nhóm các user thay vì phải gán quyền cho từng user riêng lẻ.

 Có 3 loại database roles:

• Fixed

• Custom

• Application

db_owner Có tất cả các quyền trong DB

db_accessadmin Thêm hay xóa các user ID

db_securityadmin Quản lý tất cả các role và

permission trong DB,có thể thay đổi chủ quyềnower (ownership)

db_ddladmin Có thể thực hiện tất cả các lệnh

DDL nhưng không thể sử dụng các lệnh GRANT, REVOKE hay DENY

db_backupoperator Có thể thực hiện các lệnh DBCC,

CHECKPOINT và BACKUP

Fixed Database Roles

db_denydatareader Không thể chọn tất cả dữ liệu

từ bất kỳ bảng của user nào trong DB

db_denydatawriter Không thể chỉnh sửa bất kỳ

dữ liệu trong các bảng của user trong DB.

Fixed Server Roles

 Mỗi user trong 1 DB đều thuộc về role

public Nếu muốn mọi user trong 1 DB có quyền đặc biệt nào đó thì hãy gán quyền đó cho role public Nếu 1 user chưa được cấp quyền đặc biệt gì thì họ sẽ chỉ được dùng những quyền đã được gán cho public

 Bất kỳ thành viên nào của fixed database

role đều có thể thêm các user khác vào role của thành viên đó

Fixed Server Roles

Thêm thành viên vào DB role

 Tài khoản bảo mật (security account):

– có thể là bất kỳ user hợp lệ nào của SQL server – Có thể là 1 role nào đó của SQL Server

– có thể là bất kỳ user hay group nào của Windows

đã được gán quyền truy cập vào DB hiện hành

 Để thêm user hay group của Windows NT ,

dùng sp_grantdbaccess

 Dùng lệnh sp_addrolemember để thêm 1 tài

khoản vào 1 role, khi đó thành viên có thể

kế thừa bất kỳ quyền nào của role đó.

sp_addrolemember [ @rolename = ] 'role' ,

    [ @membername = ] 'security_account'

sp_grantdbaccess [@loginame =] 'login'

 [,[@name_in_db =] 'name_in_db' OUTPUT]]

 Ví dụ: thêm user của Windows vào CSDL

hiện hành với user ID là Georgie.

Custom Database Roles

 Người dùng có thể cần có thêm một số quyền mà các quyền

này chưa được xác định trong bất kỳ role database cố định nào SQL server cho phép tạo các database role tuỳ biến (custom)

 Khi tạo một role database tùy biến, trước tiên cần thêm các

quyền vào role, sau đó sẽ gán các user vào role.

 Chỉ có những thành viên của role sysadmin, db_securityadmin

và db_owner mới có quyền chạy lệnh này

 Ví dụ: tạo 1 role mới tên Managers cho CSDL hiện hành.

EXEC sp_addrole 'Managers'

Vai trò của Application Roles

 Hệ thống bảo mật trong SQL server được thực thi

ở mức thấp nhất:là database Đây là phương pháp tốt nhất để kiểm soát các hoạt động của user bất kể ứng dụng nào được dùng để kết nối với SQL server Tuy nhiên, đôi khi việc kiểm soát bảo mật phải được “customized” ( tuỳ biên) để phù hợp với 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 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 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

 Vì 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

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

 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ùng

 Ví dụ: EXEC sp_setapprole

'SalesApprole', 'AsDeFXX'

 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à Orders

Cá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ác

 User 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ệu

 Có 3 loại quyền

• Object Permissions

• Statement Permissions

• Implied Permissions

 Tấ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).

 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 :

view

trong bảng, tuy nhiên user không thể thêm hay xóa các hàng trong bảng được

trong bảng

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 foreign

được cấp quyền

 Cho 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

 Implied 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 Language

 Có 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

• DENY

Data Control Language

 Lệ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 SQL

    }

TO security_account [ , n ]

[ WITH GRANT OPTION ]

[ AS { group | role } ]