Сле­ду­ющий уро­вень бе­зопас­ности — это раз­ре­шения на уров­не объек­тов БД. Су­щес­тву­ет нес­колько ви­дов раз­ре­шений на объек­ты БД.
Во-пер­вых, это раз­ре­шения на опе­рации SELECT, UDATE, INSERT и DELETE (опе­рации вы­бор­ки, из­ме­нения, встав­ки и уда­ления). Эти раз­ре­шения при­мени­мы только для таб­лиц и пред­став­ле­ний.
Для хра­нимых про­цедур и оп­ре­делен­ных пользо­вате­лями фун­кций су­щес­тву­ет раз­ре­шение на вы­пол­не­ние (EXECUTE). Ес­ли в от­но­шении не­кото­рой про­цеду­ры или фун­кции для пользо­вате­ля пре­дос­тавле­но та­кое раз­ре­шение, то он мо­жет ее вы­пол­нять, ина­че — нет.
На­конец, су­щес­тву­ет раз­ре­шение на дек­ла­ратив­ную це­лос­тность (Declarative Referential Integrity — DRI). Та­кие раз­ре­шения до­пус­ка­ют­ся для таб­лиц, пред­став­ле­ний и пользо­вательских фун­кций. Ес­ли пользо­ватель име­ет раз­ре­шение на DRI для не­кото­рой таб­ли­цы, это оз­на­ча­ет, что он мо­жет соз­да­вать в дру­гих таб­ли­цах свя­зи, ссы­ла­ющи­еся на ту таб­ли­цу, для ко­торой пользо­ватель име­ет это раз­ре­шение.
Кро­ме то­го, при соз­да­нии пред­став­ле­ния мож­но ука­зать, что это пред­став­ле­ние при­вяза­но к схе­ме дан­ных. Это поз­во­ля­ет от­сле­живать по­пыт­ки из­ме­нения объек­тов, на ос­но­ве ко­торых стро­ит­ся пред­став­ле­ние или фун­кция. Нап­ри­мер, ес­ли пред­став­ле­ние стро­ит­ся на ос­но­ве таб­ли­цы Students и ис­пользу­ет­ся при­вяз­ка это­го пред­став­ле­ния к схе­ме, то бу­дет не­воз­можно уда­лить таб­ли­цу Students, по­ка та­кая при­вяз­ка су­щес­тву­ет. Так­же бу­дет не­воз­можно из­ме­нить ту часть таб­ли­цы (стол­бцы), ко­торая при­сутс­тву­ет в опи­сании пред­став­ле­ния. Для то­го что­бы осу­щес­твить при­вяз­ку пред­став­ле­ния или фун­кции к схе­ме, не­об­хо­димо, что­бы на все ссы­ла­ющи­еся объек­ты для пользо­вате­ля, соз­да­юще­го или из­ме­ня­юще­го дан­ное пред­став­ле­ние или фун­кцию, име­лись раз­ре­шения ти­па DRI.

В MS SQL Server су­щес­тву­ет три сос­то­яния воз­можнос­ти дос­ту­па: раз­ре­шение (GRANT), не­яв­ное от­кло­нение дос­ту­па (REVOKE) и зап­рет (DENY).
Опе­ратор GRANT име­ет сле­ду­ющий син­таксис:

Спи­сок действий оп­ре­деля­ет на­бор действий из об­ще­допус­ти­мого пе­реч­ня действий над объек­том дан­но­го ти­па:

• оп­ция ALL PRIVILEGES ука­зыва­ет, что раз­ре­шены все действия из до­пус­ти­мых для объек­тов дан­но­го ти­па;
• <Имя_объек­та> за­да­ет имя кон­крет­но­го объек­та: таб­ли­цы, пред­став­ле­ния, хра­нимой про­цеду­ры, триг­ге­ра;
• <Имя_пользо­вате­ля> или PUBLIC оп­ре­деля­ет, ко­му пре­дос­тавля­ют­ся дан­ные при­виле­гии;
• оп­ция WITH GRANT OPTION яв­ля­ет­ся не­обя­зательной. Она оп­ре­деля­ет ре­жим, при ко­тором пе­реда­ют­ся не только пра­ва на ука­зан­ные действия, но и пра­во пе­реда­вать (де­леги­ровать) эти пра­ва дру­гим пользо­вате­лям. Пе­реда­вать пра­ва в этом слу­чае пользо­ватель мо­жет только в рам­ках раз­ре­шен­ных ему действий.

Для от­ме­ны ра­нее наз­на­чен­ных при­виле­гий в стан­дарте SQL оп­ре­делен опе­ратор REVOKE. Опе­ратор от­ме­ны при­виле­гий име­ет сле­ду­ющий син­таксис:

С раз­ре­шени­ем и зап­ре­том все ин­ту­итив­но по­нят­но: про­ис­хо­дит ли­бо пре­дос­тавле­ние не­кото­рых прав пользо­вате­лю, ли­бо выс­тавле­ние зап­ре­тов. Что ка­са­ет­ся не­яв­но­го от­кло­нения дос­ту­па, мож­но счи­тать, что это уда­ление ра­нее пре­дос­тавлен­но­го раз­ре­шения или зап­ре­та для дан­но­го пользо­вате­ля. Ес­ли бы не бы­ло воз­можнос­ти не­яв­но­го от­кло­нения дос­ту­па, то для не­кото­рого кон­крет­но­го пользо­вате­ля мож­но бы­ло бы ли­бо дать раз­ре­шение, ли­бо выс­та­вить зап­рет на не­кото­рый кон­крет­ный объект БД. С по­мощью же не­яв­но­го от­кло­нения дос­ту­па мож­но уб­рать как яв­ное раз­ре­шение, так и яв­ное от­кло­нение дос­ту­па, т. е. ус­та­новить не­оп­ре­делен­ность. Та­кое сос­то­яние на­зыва­ет­ся не­яв­ным от­кло­нени­ем дос­ту­па. Де­ло в том, что здесь при­меня­ет­ся по­лити­ка, в со­от­ветс­твии с ко­торой зап­ре­ща­ет­ся все, что яв­но не разрешено, т. е. ес­ли у пользо­вате­ля не бу­дет ни зап­ре­та, ни раз­ре­шения на не­кото­рую опе­рацию, то он не смо­жет ее вы­пол­нить.
Для од­но­го и то­го же объек­та на од­ну и ту же опе­рацию пользо­ватель мо­жет иметь сра­зу нес­колько раз­ре­шений (или зап­ре­тов), т. е. не­пос­редс­твен­но пользо­вате­лю, ко­неч­но, мо­жет быть вы­дано только од­но раз­ре­шение. Од­на­ко пользо­ватель мо­жет вхо­дить в мно­жес­тво раз­личных ро­лей БД. Нап­ри­мер, для БД ин­сти­тута мож­но рас­смот­реть ро­ли «Пре­пода­вате­ли», «Сту­ден­ты», «Сот­рудни­ки де­кана­та», «Сот­рудни­ки проф­со­юза», «Ла­боран­ты», «Сис­темные ад­ми­нис­тра­торы». Один пользо­ватель мо­жет вхо­дить сра­зу в не­сколько ро­лей. Для не­кото­рого объек­та на од­ну опе­рацию (нап­ри­мер, опе­рацию уда­ления) мо­гут быть выс­тавле­ны и зап­ре­ты, и раз­ре­шения. Кро­ме то­го, они мо­гут быть вы­став­ле­ны еще до­пол­ни­тельно не­пос­редс­твен­но для каж­до­го пользо­вате­ля.
Та­ким об­ра­зом, каж­дый пользо­ватель БД мо­жет иметь раз­ре­шения, пре­дос­тавлен­ные не­пос­редс­твен­но ему или пос­редс­твом вхож­де­ния в ро­ли. При­чем мо­жет по­лучиться, что эти раз­ре­шения и зап­ре­ты бу­дут про­тиво­речить друг дру­гу. Нап­ри­мер, опе­рация уда­ления бу­дет зап­ре­щена для ро­ли «Сту­ден­ты», но раз­ре­шена для ро­ли «Ла­боран­ты». Ес­ли учесть, что не­кото­рый пользо­ватель мо­жет вхо­дить в обе ро­ли, как бу­дет оп­ре­деляться воз­можность или не­воз­можность вы­пол­нить ту или иную опе­рацию в та­ких слу­ча­ях? Наи­бо­лее ве­сомым счи­та­ет­ся зап­рет из тех со­об­ра­жений, что глав­ное — не до­пус­тить (по ошиб­ке) не­сан­кци­они­рован­но­го дос­ту­па к дан­ным. Ес­ли же кто-ли­бо из пользо­вате­лей не­допо­лучит ка­ких-ли­бо прав, то он об­ра­тит­ся к ад­ми­нис­тра­тору и тот пре­дос­та­вит ему не­об­хо­димые пра­ва, т. е. счи­та­ет­ся, что луч­ше не­додать прав, чем дать их слиш­ком мно­го. В этом и сос­то­ит раз­ни­ца меж­ду REVOKE и DENY: ес­ли пользо­вате­лю од­новре­мен­но да­ны раз­ре­шение (GRANT) и зап­рет (DENY), то ре­зульта­том бу­дет зап­рет, а ес­ли же до­пол­ни­тельно к раз­ре­шению да­но не­яв­ное от­кло­нение дос­ту­па, то ре­зульта­том бу­дет раз­ре­шение.
Ин­тер­пре­тация двойных наз­на­чений раз­ре­шений при­веде­на в табл. 1.4. Из ана­лиза дан­ных, при­веден­ных в таб­ли­це, мож­но сде­лать вы­вод, что бу­дет про­ис­хо­дить при на­личии раз­ных раз­ре­шений.

Вла­дельцем объек­та БД яв­ля­ет­ся пользо­ватель, ко­торый его соз­дал. В прин­ци­пе, мож­но пе­реда­вать вла­дение объек­том БД дру­гому пользо­вате­лю, но это ис­пользу­ет­ся не­часто.
Наз­на­чение прав пользо­вате­лям БД, так же как и большинс­тво фун­кций ад­ми­нис­три­рова­ния, мо­жет быть вы­пол­не­но с ис­пользо­вани­ем гра­фичес­ко­го ин­терфейса Enterprise Manager. Для это­го не­об­хо­димо ус­та­новить кур­сор на кон­крет­но­го пользо­вате­ля или на пользо­вательскую роль в БД, ес­ли нуж­но пре­дос­та­вить оди­нако­вые пра­ва всем чле­нам дан­ной ро­ли, и на­жать кноп­ку Permissions.
В от­крыв­шемся ок­не нуж­но ус­та­новить «га­лоч­ки» в со­от­ветс­тву­ющие гра­фы раз­ре­шений. Каж­дая гра­фа от­ве­ча­ет за раз­ре­шение оп­ре­делен­ных действий над оп­ре­делен­ным объек­том (рис. 1.6).