ГЛАВА 1
Технологии администрирования баз данных
1.6
Управление пользователями баз данных
Удоб­ным ме­ханиз­мом по­луче­ния ин­форма­ции о пользо­вате­лях те­кущей БД яв­ля­ет­ся сис­темная хра­нимая про­цеду­ра sp_helpuser (рис. 1.7):
Рис. 1.7. Результат выполнения системной процедуры sp_helpuser
Для пер­во­го пользо­вате­ля ука­зана только часть иден­ти­фика­тора бе­зопас­ности SID, так как раз­мер стра­ницы не поз­во­лил вмес­тить его весь.
CREATE USER до­бав­ля­ет но­вого пользо­вате­ля в те­кущую БД. Да­лее при­веде­ны нес­колько ти­пов пользо­вате­лей.
Ти­пы пользо­вате­лей:
1) пользо­вате­ли на ос­но­ве имен вхо­да в БД master — на­ибо­лее рас­простра­нен­ный тип пользо­вате­ля. Пользо­ватель с име­нем вхо­да для про­вер­ки под­линнос­ти SQL Server:
CREATE USER Mary;
2) пользо­вате­ли, ко­торые про­ходят про­вер­ку под­линнос­ти SQL Server. Про­вер­ка ре­комен­ду­ет­ся для то­го, что­бы по­высить пе­рено­симость БД. До­пус­ка­ет­ся только в ав­то­ном­ной БД в SQL Server.
CREATE USER Mary WITH PASSWORD='********';
DROP USER — уда­ля­ет пользо­вате­ля из БД.
DROP USER user_name;
Здесь user_name ука­зыва­ет имя, по ко­торо­му пользо­ватель иден­ти­фици­ру­ет­ся в этой БД.
Пользо­вате­ли, ко­торые вла­де­ют за­щища­емы­ми объек­та­ми, не мо­гут быть уда­лены из БД. Пе­ред уда­лени­ем пользо­вате­ля, ко­торый вла­де­ет за­щища­емым объек­том, не­об­хо­димо уда­лить или сме­нить вла­дельца за­щища­емо­го объек­та.
Пользо­ватель Guest не мо­жет быть уда­лен, од­на­ко его мож­но от­клю­чить, от­ме­нив раз­ре­шение CONNECT с по­мощью инс­трук­ции REVOKE CONNECT FROM GUEST в лю­бой БД, кро­ме master или tempdb.
Инс­трук­ция CREATE ROLE соз­да­ет но­вую роль БД в те­кущей БД:
CREATE ROLE имя_ро­ли [AUTHORIZATION имя_вла­дельца]
где имя_ ро­ли — имя соз­да­ва­емой ро­ли; AUTHORIZATION имя_вла­дельца — пользо­ватель (или роль) БД, ко­торый ста­нет вла­дельцем но­вой ро­ли.
Ес­ли пользо­ватель не ука­зан, вла­дельцем ро­ли ста­нет пользо­ватель, вы­пол­нивший инс­трук­цию CREATE ROLE.
Ро­ли — сущ­ности, за­щища­емые на уров­не БД.
Пос­ле соз­да­ния ро­ли не­об­хо­димо нас­тро­ить для нее раз­ре­шения уров­ня БД с по­мощью инс­трук­ций GRANT, DENY и REVOKE. Что­бы до­бавить чле­нов ро­ли БД, ис­пользу­ет­ся ко­ман­да ALTER ROLE (Transact-SQL).
Ро­ли БД вид­ны в пред­став­ле­ни­ях ка­тало­га sys.database_role_members и sys.database_principals.
Для пе­реда­чи ро­ли во вла­дение дру­гому пользо­вате­лю не­об­хо­димо свя­зан­ное с этим пользо­вате­лем раз­ре­шение IMPER­SONATE.
Для пе­реда­чи ро­ли во вла­дение дру­гой ро­ли не­об­хо­димо членс­тво в ро­ли-по­луча­теле или свя­зан­ное с этой ролью раз­ре­шение ALTER.
Для пе­реда­чи ро­ли во вла­дение ро­ли при­ложе­ния не­об­хо­димо свя­зан­ное с прик­ладной ролью раз­ре­шение ALTER.
В при­мере, при­веден­ном да­лее, по­каза­но соз­да­ние ро­ли БД buyers, при­над­ле­жащей пользо­вате­лю BenMiller.
USE AdventureWorks2014;
CREATE ROLE buyers AUTHORIZATION BenMiller;
GO
Сле­ду­ющий при­мер соз­да­ет роль БД auditors, при­над­ле­жащую пре­доп­ре­делен­ной ро­ли БД db_securityadmin.
USE AdventureWorks2014;
CREATE ROLE auditors AUTHORIZATION db_securityadmin;
GO
Сле­ду­ющий при­мер соз­да­ет роль БД buyers, при­над­ле­жащую пользо­вате­лю BenMiller.
USE AdventureWorks2014;
CREATE ROLE buyers AUTHORIZATION BenMiller;
GO
Еще один при­мер соз­да­ет роль БД auditors, при­над­ле­жащую пре­доп­ре­делен­ной ро­ли БД db_securityadmin.
USE AdventureWorks2014;
CREATE ROLE auditors AUTHORIZATION db_securityadmin;
GO
Пер­во­начально роль яв­ля­ет­ся пус­той, т. е. не име­ющей ни од­ной при­виле­гии. Вклю­чение при­виле­гий в роль про­из­во­дит­ся ко­ман­дой GRANT. Ро­ли мо­гут соз­да­вать ад­ми­нис­тра­тор и те пользо­вате­ли, ко­торым та­кое пра­во пре­дос­та­вил ад­ми­нис­тра­тор. Тот, кто соз­дал роль, или тот, кто яв­но ука­зан при оп­ре­деле­нии ро­ли (стан­дарт SQL), об­ла­да­ет пра­вами ее ад­ми­нис­три­рова­ния, т. е. мо­жет:
  • пре­дос­тавлять роль дру­гому пользо­вате­лю или ро­ли;
  • ан­ну­лиро­вать роль для дру­гого пользо­вате­ля или ро­ли;
  • из­ме­нять оп­ре­деле­ние ро­ли, нап­ри­мер, в це­лях из­ме­нения ав­то­риза­ции дос­ту­па к ней;
  • уда­лять роль.
Как и лю­бой дру­гой объект БД, оп­ре­деле­ние ро­ли мож­но из­ме­нять с по­мощью ко­ман­ды ALTER ROLE и уда­лять с по­мощью ко­ман­ды DROP ROLE:
DROP ROLE имя_ро­ли
Пре­дос­тавле­ние при­виле­гий про­из­во­дит­ся дву­мя пред­ло­жени­ями. Од­но пре­дос­тавля­ет при­виле­гии на объек­ты БД, а дру­гое — на ро­ли.
Пре­дос­тавле­ние при­виле­гий на объек­ты про­из­во­дит­ся сле­ду­ющим пред­ло­жени­ем:
GRANT {ALL PRIVILEGES | спи­сок_при­виле­гий} ON объект
ТО {PUBLIC | {пользо­ватель | роль}...}
[WITH HIERARCHY OPTION]
[WITH GRANT OPTION]
[GRANTED BY {CURRENT_USER | CURRENT_ROLE}]
К мно­жес­тву объек­тов, для ко­торых оп­ре­деля­ют­ся при­виле­гии, от­но­сят:
  • таб­ли­цы и пред­став­ле­ния БД;
  • до­мены, на ко­торых оп­ре­деля­ют­ся ти­пы стол­бцов;
  • оп­ре­деля­емые ти­пы дан­ных;
  • пос­ле­дова­тельнос­ти;
  • прог­раммы, вы­зыва­емые из SQL.
Спи­сок при­виле­гий, пре­дос­тавля­емых для ра­боты с объек­та­ми БД, вклю­ча­ет в се­бя:
  • ис­пользо­вание пред­ло­жения SELECT ко всей таб­ли­це или только к от­дельным ее стол­бцам;
  • ис­пользо­вание пред­ло­жения DELETE;
  • ис­пользо­вание пред­ло­жения INSERT ко всей таб­ли­це или только к от­дельным ее стол­бцам. В этом слу­чае од­ни пользо­вате­ли мо­гут вво­дить стро­ки таб­ли­цы только со зна­чени­ями от­дельных стол­бцов, а дру­гие — за­тем об­но­вить зна­чения дру­гих стол­бцов;
  • ис­пользо­вание пред­ло­жения UPDATE ко всей таб­ли­це или только к от­дельным ее стол­бцам;
  • ссыл­ки на таб­ли­цы или их стол­бцы лю­бым спо­собом — при­виле­гия REFERENCES, ко­торая поз­во­ля­ет ссы­латься на стол­бцы во внеш­нем клю­че или при за­дании ог­ра­ниче­ния це­лос­тнос­ти CHECK;
  • ис­пользо­вание не­кото­рых из объек­тов БД спо­собом, от­ли­ча­ющим­ся от опи­сан­ных ра­нее, — при­виле­гия USAGE. Ес­ли пользо­ватель по­лучит та­кую при­виле­гию по от­но­шению, нап­ри­мер, к до­мену, он мо­жет ис­пользо­вать его для ука­зания ти­па стол­бца оп­ре­деля­емой таб­ли­цы. В про­тив­ном слу­чае он это­го сде­лать не мо­жет;
  • ини­ци­иро­вание триг­ге­ров из ука­зан­ной таб­ли­цы — при­виле­гия TRIGGER;
  • вы­пол­не­ние прог­раммы, вы­зыва­емой из SQL, — при­виле­гия EXECUTE.
До­пол­ни­тельные фра­зы пред­ло­жения GRANT оз­на­ча­ют сле­ду­ющее:
  • WITH HIERARCHY OPTION — пе­реда­ет пра­ва ука­зан­но­го объек­та всем его по­добъек­там. Она име­ет смысл только для при­виле­гии SELECT, пре­дос­тавлен­ной объек­ту в и­ерар­хи­чес­кой струк­ту­ре объек­тов (и­ерар­хи­чес­кая струк­ту­ра нас­ле­дова­ния в объек­тно-ори­ен­ти­рован­ном SQL). В этом слу­чае спе­цифи­циру­емая при­виле­гия рас­простра­ня­ет­ся на все про­из­водные объек­ты то­го объек­та, от­но­сительно ко­торо­го спе­цифи­циро­вано это пол­но­мочие;
  • WITH GRANT OPTION — оз­на­ча­ет, что ука­зан­но­му пользо­вате­лю не только пре­дос­тавля­ют­ся спе­цифи­циро­ван­ные при­виле­гии, но и пра­ва пре­дос­тавлять эти при­виле­гии дру­гим пользо­вате­лям;
  • GRANTED BY — ука­зыва­ет, кто имен­но пе­реда­ет пол­но­мочия; мо­гут быть ука­заны ли­бо те­кущий пользо­ватель, ли­бо те­кущая роль.
Нес­колько при­меров:
GRANT SELECT, UPDATE (Salary. Rise) ON Teacher TO Kostya;
GRANT ALL PRIVILEGES ON Room TO Jones WITH GRANT OPTION;
GRANT SELECT ON Faculty TO Public;
DELETE UPDATE ON Subject TO Ivanov, Petrov;
GRANT REFERENCES (DepPK). UPDATE (Name. Head, Building) ON
Depatment TO Blake;
Пре­дос­тавле­ние при­виле­гий на ро­ли за­да­ет­ся сле­ду­ющим пред­ло­жени­ем:
GRANT спи­сок_ро­лей
ТО {PUBLIC | {пользо­ватель | роль}...}
[WITH ADMIN OPTION]
[GRANTED BY {CURRENT_USER | CURRENT_ROLE}]
Пре­дос­тавле­ние ро­ли име­ет три ва­ри­ан­та:
1) PUBLIC — все име­ющи­еся в ука­зан­ных ро­лях при­виле­гии ока­зыва­ют­ся дос­тупны­ми всем пользо­вате­лям;
2) пользо­ватель — по­луча­ет все при­виле­гии, ко­торые име­ют­ся в ука­зан­ных ро­лях;
3) роль — по­луча­ет до­пол­ни­тельно все при­виле­гии ука­зан­ных ро­лей.
Фра­за WITH ADMIN OPTION ука­зыва­ет, что вто­рая роль при­об­ре­та­ет все пра­ва по ад­ми­нис­три­рова­нию пер­вой ро­ли (т. е. пре­дос­тавлять или от­ме­нять ее дру­гим ро­лям или пользо­вате­лям, из­ме­нять спи­сок ее пол­но­мочий или да­же во­об­ще уда­лять эту роль). Фра­за GRANTED BY име­ет тот же смысл, что и в пре­дыду­щем пред­ло­жении.
Роль — единс­твен­ный сис­темный объект, на ко­торый мож­но пре­дос­тавлять пользо­вате­лям при­виле­гии по их ис­пользо­ванию:
GRANT SpecialRole TO Smith;
Здесь пользо­ватель Smith по­луча­ет все пол­но­мочия, име­ющи­еся в ро­ли Special Role;
GRANT Special Role TO AccountGroupRole;
Здесь вто­рая роль по­луча­ет все те при­виле­гии, ко­торые име­ют­ся в пер­вой ро­ли;
GRANT SpecialRole TO Public;
Все пользо­вате­ли по­луча­ют пол­но­мочия ро­ли Special Role.
Для по­луче­ния ин­форма­ции о ро­лях БД мож­но при­менять сис­темную хра­нимую про­цеду­ру sp_helprole:
USE AdventureWorks2014;
EXEC sp_helprole
Бу­дет воз­вра­щен ре­зультат, по­казан­ный на рис. 1.8.
Рис. 1.8. Результат выполнения процедуры sp_helprole
Как вид­но, про­цеду­ра вы­водит све­дения об име­ни ро­ли, ее иден­ти­фика­торе и флаг, го­воря­щий о том, яв­ля­ет­ся ли со­от­ветс­тву­ющая роль ролью при­ложе­ния.
По­луче­ние ин­форма­ции о членс­тве во всех ро­лях те­кущей БД осу­щест­вля­ет­ся сле­ду­ющим об­ра­зом:
USE AdventureWorks2014;
EXEC sp_helprolemember
Бу­дет по­лучен ре­зультат, по­казан­ный на рис. 1.9.
Рис. 1.9. Результат выполнения процедуры sp_helprolemember
По­лучив на­бор прав, пользо­ватель смо­жет вы­пол­нять раз­ре­шен­ные действия. Но в не­кото­рых слу­ча­ях бы­ва­ет не­об­хо­димо зап­ре­тить ему вы­пол­нять не­кото­рые опе­рации в БД.
В ка­чес­тве ил­люс­тра­ции ис­пользо­вания хра­нимой про­цеду­ры sp_helprotect по­лучим све­дения о пра­вах дос­ту­па пользо­вате­лей к таб­ли­це authors:
USE AdventureWorks2014;
EXEC sp_helprotect
Бу­дет по­лучен ре­зультат, по­казан­ный на рис. 1.10.
Рис. 1.10. Результат выполнения процедуры sp_ helprotect
Ин­форма­ция вы­водит­ся в нес­кольких стол­бцах:
  • Owner — в этом стол­бце ука­зыва­ет­ся имя те­куще­го вла­дельца объек­та;
  • Objects — имя объек­та, о ко­тором вы­водит­ся ин­форма­ция;
  • Grantee — имя пользо­вате­ля или ро­ли, ко­торым вы­дано раз­ре­шение на дос­туп к со­от­ветс­тву­юще­му объек­ту;
  • Grantor — имя пользо­вате­ля или ро­ли БД, ко­торый пре­дос­та­вил дру­гому пользо­вате­лю со­от­ветс­тву­ющее пра­во дос­ту­па;
  • Protect Type — тип раз­ре­шения, вы­дан­но­го пользо­вате­лю;
  • Action — тип действия, ко­торое раз­ре­шено вы­пол­нять пользо­вате­лю;
  • Column — ес­ли раз­ре­шение вы­дано для оп­ре­делен­но­го стол­бца таб­ли­цы, то бу­дет вы­веде­но имя это­го стол­бца. Ес­ли раз­ре­шение вы­дано для всех стол­бцов, то бу­дет ука­зано [All + New].
Пользо­ватель, соз­давший таб­ли­цу (а для это­го он дол­жен иметь та­кое пра­во), яв­ля­ет­ся вла­дельцем этой таб­ли­цы. Это оз­на­ча­ет, что он име­ет аб­со­лют­но все пра­ва на эту таб­ли­цу, на внеш­нюю па­мять, вплоть до пе­реда­чи прав на нее дру­гим пользо­вате­лям.
Пользо­ватель, соз­давший пред­став­ле­ние, ста­новит­ся его вла­дельцем. Но не все при­виле­гии по от­но­шению к не­му он по­луча­ет ав­то­мати­чес­ки. Для соз­да­ния пред­став­ле­ния не­об­хо­димо иметь при­виле­гию SELECT ко всем таб­ли­цам. Та­ким об­ра­зом, вла­делец пред­став­ле­ния по­луча­ет та­кую при­виле­гию ав­то­мати­чес­ки. Все дру­гие при­виле­гии он мо­жет по­лучить пос­редс­твом яв­но­го пре­дос­тавле­ния та­ковых по от­но­шению ко всем ба­зовым таб­ли­цам пред­став­ле­ния.
От­ме­на ра­нее пе­редан­ных при­виле­гий про­из­во­дит­ся ко­ман­дой REVOKE. В стан­дарте SQL име­ет­ся две раз­но­вид­ности этой ко­ман­ды: для от­ме­ны пол­но­мочий на объек­ты и от­ме­ны ро­ли. Пер­вая раз­но­вид­ность ко­ман­ды REVOKE име­ет сле­ду­ющий син­таксис:
REVOKE [{GRANT | HIERARCHY} OPTION FOR] {ALL PRIVILEGES | спи­сок_при­виле­гий} ON объект FROM {PUBLIC | {пользо­ватель | роль}...} [GRANTED BY {CURRENT_USER | CURRENT_ROLE}] {CASCADE | RESTRICT}
Это пред­ло­жение име­ет струк­ту­ру, ана­логич­ную струк­ту­ре пред­ло­жения GRANT: оно со­дер­жит на­бор от­ме­ня­емых при­виле­гий, объект, от­но­сительно ко­торо­го от­ме­ня­ют­ся при­виле­гии, и пользо­вате­лей, у ко­торых от­ме­ня­ют­ся при­виле­гии. С по­мощью этой ко­ман­ды мож­но от­ме­нить все ра­нее пре­дос­тавлен­ные при­виле­гии или только не­кото­рые. Фра­за HIERARCHY OPTION FOR от­ме­ня­ет ту раз­но­вид­ность при­виле­гии, ко­торая пре­дос­тавля­ет­ся пред­ло­жени­ем GRANT с ис­пользо­вани­ем фра­зы WITH HIERARCHY OPTION. Фра­за GRANTED BY име­ет тот же смысл, что и в пред­ло­жении GRANT.
Лю­бой пользо­ватель мо­жет от­ме­нять только те при­виле­гии, ко­торые он ра­нее пе­реда­вал, но не мо­жет от­ме­нить пол­но­мочия, ко­торы­ми об­ла­да­ет сам.
Мно­гие пользо­вате­ли мо­гут пре­дос­та­вить од­ну и ту же при­виле­гию на объект од­но­му и то­му же пользо­вате­лю (или ро­ли). Для ан­ну­лиро­вания у пользо­вате­ля та­кой при­виле­гии не­об­хо­димо, что­бы ее от­ме­нили все пользо­вате­ли, ко­торые ее ра­нее пе­реда­ли. Ес­ли хо­тя бы один из пользо­вате­лей не от­зо­вет та­кую при­виле­гию, то ее по­луча­тель бу­дет ею об­ла­дать.
Нап­ри­мер, пользо­ватель Dep_Head пре­дос­та­вил пользо­вате­лю Andrew пол­но­мочия вы­бирать дан­ные из таб­ли­цы Teacher, а так­же вы­бирать и об­новлять таб­ли­цу Sgroup:
GRANT SELECT, UPDATE ON Sgroup TO Andrew;
GRANT SELECT ON Teacher TO Andrew;
Пос­ле это­го еще один пользо­ватель, Dep_Deputy, пре­дос­та­вил Andrew воз­можность вы­бирать и уда­лять дан­ные из таб­ли­цы Subject и вы­бирать дан­ные из таб­ли­цы Subject:
GRANT SELECT, DELETE ON Sgroup TO Andrew;
GRANT SELECT ON Subject TO Andrew;
Andrew по­лучил при­виле­гии на таб­ли­цу Sgroup от двух лиц, при­чем при­виле­гия SELECT по­луче­на от обо­их пользо­вате­лей. Чуть поз­же пользо­ватель Dep_ Head ре­шил от­ме­нить все ра­нее пе­редан­ные им при­виле­гии пользо­вате­лю Andrew. В свя­зи с этим он ини­ци­иру­ет сле­ду­ющее пред­ло­жение:
REVOKE ALL PRIVILEGES ON Sgroup FROM Andrew;
В свя­зи с этим Andrew ли­шил­ся пра­ва об­новлять таб­ли­цу Sgroup, од­на­ко вы­бирать из нее дан­ные и уда­лять их он все же мо­жет, так как та­кое пра­во у не­го ос­та­лось от пользо­вате­ля Dep_Deputy.
Воз­можность пе­реда­вать при­виле­гии вмес­те с пра­вами на пе­реда­чу их дру­гим при­водит к воз­можнос­ти по­рож­де­ния це­лой це­поч­ки по­рож­денных при­виле­гий. Нап­ри­мер, пользо­ватель Chief пе­редал Andrew при­виле­гию UPDATE на таб­ли­цу Faculty с пра­вом пе­реда­вать ее (при­виле­гию) дру­гим пользо­вате­лям (WITH GRANT OPTION). Вос­пользо­вав­шись этим пра­вом, Andrew пе­редал пользо­вате­лю Valery ту же при­виле­гию на Faculty с тем же пра­вом пе­реда­вать ее дру­гим пользо­вате­лям.
В свя­зи с этим воз­ни­ка­ет сле­ду­ющий воп­рос: как пос­ту­пить в этом слу­чае, ес­ли у пользо­вате­ля Andrew за­бира­ет­ся пра­во об­новлять таб­ли­цу Faculty? Для от­ве­та на этот воп­рос в язык SQL вклю­чены два альтер­на­тив­ных клю­чевых сло­ва: CASCADE и RESTRICT. Пер­вое из них оз­на­ча­ет, что по­мимо от­ме­ны при­виле­гии у Andrew так­же сле­ду­ет от­ме­нить эту же при­виле­гию у Valery и т. д. Вто­рое клю­чевое сло­во оз­на­ча­ет, что нельзя бу­дет от­ме­нить при­виле­гию у Andrew, ес­ли он уже пе­редал ее дру­гому пользо­вате­лю. В этом слу­чае не­об­хо­димо, что­бы сна­чала Andrew от­ме­нил эту при­виле­гию у Valery, и только пос­ле это­го ее мож­но бу­дет от­ме­нить у Andrew.
Оче­вид­но, ес­ли пользо­ватель ли­ша­ет­ся тех или иных при­виле­гий, он так­же ли­ша­ет­ся прав пе­реда­чи их дру­гим, ес­ли они у не­го име­лись. Язык SQL поз­во­ля­ет от­ме­нять пра­ва пре­дос­тавле­ния при­виле­гий, сох­ра­няя при этом пра­во пользо­ваться са­мими при­виле­ги­ями. Пусть, нап­ри­мер, пользо­вате­лю Andrew бы­ли пре­дос­тавле­ны сле­ду­ющие при­виле­гии с пра­вом пе­реда­чи их дру­гим:
GRANT SELECT, UPDATE, DELETE ON Sgroup TO Andrew WITH GRANT OPTION;
он так­же ли­ша­ет­ся прав пе­реда­вать их дру­гим. Од­на­ко мож­но сле­ду­ющим об­ра­зом заб­рать у Andrew пра­ва пе­реда­чи этих при­виле­гий дру­гим, ос­тавляя воз­можность ими пользо­ваться:
REVOKE GRANT OPTION FOR SELECT, UPDATE, DELETE ON Sgroup FROM Andrew;
Пос­ле это­го у Andrew все же сох­ра­нились пра­ва по пе­реда­че при­виле­гии SELECT дру­гим пользо­вате­лям.
От­ме­на ро­лей про­из­во­дит­ся сле­ду­ющей ко­ман­дой:
REVOKE [ADMIN OPTION FOR] спи­сок_ро­лей FROM {PUBLIC | {пользо­ватель | роль}...} [GRANTED BY {CURRENT_USER | CURRENT_ROLE}] {CASCADE | RESTRICT}
Фра­за GRANTED BY име­ет тот же смысл, что и в пред­ло­жении GRANT. Роль мо­жет быть ан­ну­лиро­вана у пользо­вате­ля или дру­гой ро­ли. При от­ме­не ро­ли у пользо­вате­ля он те­ря­ет те при­виле­гии, ко­торые име­ют­ся у этой ро­ли. При от­ме­не ро­ли у дру­гой ро­ли вто­рая роль те­ря­ет те при­виле­гии, ко­торые име­ют­ся у пер­вой ро­ли.
При от­ме­не ро­ли у PUBLIC при­виле­гии за­бира­ют­ся у тех пользо­вате­лей, ко­торым они бы­ли пре­дос­тавле­ны с по­мощью PUBLIC.
Фра­за ADMIN OPTION FOR ука­зыва­ет, что у пользо­вате­ля за­бира­ют­ся пра­ва ад­ми­нис­три­рова­ния ука­зан­ной ролью, од­на­ко ее при­виле­гии за ним ос­та­ют­ся. Альтер­на­тив­ные клю­чевые сло­ва CASCADE и RESTRICT ука­зыва­ют, как пос­ту­пать со ссы­лоч­ным ог­ра­ниче­ни­ем це­лос­тнос­ти, ес­ли его су­щес­тво­вание бы­ло раз­ре­шено при­виле­ги­ей REFERENCES, ко­торая от­ме­ня­ет­ся пред­ло­жени­ем REVOKE. В этом слу­чае CASCADE оз­на­ча­ет, что все та­кие ссы­лоч­ные це­лос­тнос­ти дол­жны быть так­же уда­лены. В свою оче­редь, RESTRICT ука­зыва­ет, что при­виле­гию REFERENCES нельзя от­ме­нить до тех пор, по­ка сог­ласно ее су­щес­тво­ванию име­ет­ся ссы­лоч­ная це­лос­тность. Да­лее при­веде­ны при­меры от­ме­ны ро­лей.
REVOKE SpecialRole FROM Smith;
REVOKE SpecialRole FROM AccountGroupRole;
REVOKE SpecialRole FROM Public;
При­виле­гии мож­но оп­ре­делить и ис­пользуя пред­став­ле­ния. Каж­дый раз, ког­да пре­дос­тавля­ют­ся при­виле­гии от­но­сительно ба­зовой таб­ли­цы, они ав­то­мати­чес­ки рас­простра­ня­ют­ся на все стро­ки и стол­бцы. Ес­ли же соз­дать пред­став­ле­ние, а за­тем за­дать при­виле­гии от­но­сительно не­го, то об­ласть действия при­виле­гий ог­ра­ничи­ва­ет­ся только те­ми стол­бца­ми и стро­ками, ко­торые вид­ны че­рез пред­став­ле­ние. Это зна­чительно уси­лива­ет воз­можнос­ти ко­ман­ды GRANT.
Что­бы иметь воз­можность вы­бора дан­ных из пред­став­ле­ния, не­об­хо­димо иметь пра­во вы­бора дан­ных из всех тех ба­зовых таб­лиц и (или) пред­став­ле­ний, на ко­торых дан­ное пред­став­ле­ние оп­ре­деле­но. Ес­ли пред­став­ле­ние мо­дифи­циру­емо, лю­бая при­виле­гия INSERT, UPDATE и DELETE, ко­торую име­ет пользо­ватель в ба­зовых таб­ли­цах, бу­дет ав­то­мати­чес­ки пе­реда­ваться пред­став­ле­нию. Ес­ли пользо­ватель не об­ла­да­ет при­виле­ги­ями на мо­дифи­кацию в ба­зовых таб­ли­цах, то не смо­жет иметь их и в пред­став­ле­ни­ях, ко­торые соз­дал, да­же ес­ли они мо­дифи­циру­емые.
Так как внеш­ние клю­чи не оп­ре­деля­ют­ся от­но­сительно пред­став­ле­ний, пол­но­мочие REFERENCES ни­ког­да не ис­пользу­ет­ся при соз­да­нии пред­став­ле­ния. Пред­по­лага­ет­ся, что вла­дельцы при­води­мых пред­став­ле­ний име­ют со­от­ветс­тву­ющие при­виле­гии во всех ба­зовых таб­ли­цах.
Для то­го что­бы дать пользо­вате­лю John пра­во ви­деть только стол­бцы Name, Head, Building таб­ли­цы Department, мож­но соз­дать пред­став­ле­ние на этих стол­бцах:
CREATE VIEW DepForJohn AS
SELECT Name, Head, Building FROM Department;
и пре­дос­та­вить ему при­виле­гию SELECT от­но­сительно это­го пред­став­ле­ния:
GRANT SELECT ON DepForJohn TO John;
При­виле­гию SELECT мож­но ука­зывать в пред­ло­жении GRANT вмес­те со спис­ком столб­цов, ко­торые раз­ре­ша­ет­ся вы­бирать. При­веден­ное ра­нее ре­шение для ог­ра­ниче­ния до­сту­па по стол­бцам с ис­пользо­вани­ем пред­став­ле­ния мож­но пред­ста­вить и без не­го сле­ду­ющим об­ра­зом:
GRANT SELECT (Name, Head, Building) ON DepForJohn TO John;
Пред­став­ле­ния ока­зыва­ют­ся не­заме­нимы­ми для ог­ра­ниче­ния действий при­виле­гий на оп­ре­делен­ные стро­ки ба­зовой таб­ли­цы. Для это­го оп­ре­деля­ет­ся пред­став­ле­ние, со­дер­жа­щее не­об­хо­димые стро­ки, и от­но­сительно не­го спе­цифи­циру­ет­ся при­виле­гия. Нап­ри­мер, что­бы пре­дос­та­вить Andrew при­виле­гию об­новле­ния только тех строк таб­ли­цы Department, ко­торые от­но­сят­ся к фа­культе­ту ин­форма­тики, нуж­но соз­дать сле­ду­ющее пред­став­ле­ние:
CREATE VIEW DepFromCS AS

SELECT*FROM Department

WHERE FacFK IN (SELECT FacPK FROM Faculty

WHERE LOWER(Name)=‘информатика’) WITH CHECK OPTION;
За­тем пре­дос­та­вить пользо­вате­лю Andrew пол­но­мочие UPDATE от­но­сительно это­го пред­став­ле­ния:
GRANT UPDATE ON DepFromCS TO Andrew;
Фра­за WITH CHECK OPTION в оп­ре­деле­нии пред­став­ле­ния пре­дох­ра­ня­ет Andrew от из­ме­нения стол­бца FacFK на лю­бое дру­гое зна­чение, ко­торое не яв­ля­ет­ся но­мером фа­культе­та ин­форма­тики.
В не­кото­рых слу­ча­ях от­дельные зна­чения, хра­нимые в БД, мо­гут но­сить кон­фи­ден­ци­альный ха­рак­тер, и по­это­му сле­ду­ет ог­ра­ничи­вать к ним дос­туп. Од­на­ко обоб­ща­ющие дан­ные, ба­зиру­ющи­еся на этих зна­чени­ях, мо­гут быть дос­тупны. С по­мощью пред­став­ле­ний эта проб­ле­ма раз­ре­шима.
Нап­ри­мер, ес­ли све­дения о став­ке и над­бавке кон­крет­ных слу­жащих от­но­сят­ся имен­но к та­ким дан­ным, к ним не пре­дос­тавля­ют­ся ни­какие пра­ва дос­ту­па. Пос­кольку аг­ре­гиро­ван­ные све­дения о за­работ­ной пла­те яв­ля­ют­ся обез­ли­чен­ны­ми, их мож­но де­лать дос­тупны­ми и в свя­зи с этим оп­ре­делить та­кое пред­став­ле­ние:
CREATE VIEW AggregateSal SELECT Sum(Salary), SUM(Rise) FROM Teacher;
Те­перь по от­но­шению к это­му пред­став­ле­нию мож­но пре­дос­тавлять при­виле­гии по чте­нию, нап­ри­мер:
GRANT SELECT ON AggregateSal TO PUBLIC;
предыдущая страница
1.5 Права на доступ к объектам базы данных
следующая страница
1.7 Создание схемы базы данных
This site was made on Tilda — a website builder that helps to create a website without any code
Create a website
How to remove this block?About platformSubmit a complaint