Nadawanie uprawnień

Nadawanie uprawnień to przyznawanie prawa do określonych operacji poleceniem GRANT.

Trzy polecenia sterujące dostępem

W SQL Server dostępem rządzi trójka instrukcji. GRANT przyznaje prawo, REVOKE cofa wcześniej przyznane, a DENY jawnie zakazuje operacji. Kluczowa zasada mówi, że DENY wygrywa ze wszystkim: użytkownik należący do roli z uprawnieniem odczytu, ale objęty jawnym zakazem na konkretnej tabeli, nie zobaczy jej mimo członkostwa w roli. Typowa składnia to GRANT SELECT ON dbo.Kontrahenci TO rola_sprzedaz, a przyznanie prawa do dalszego rozdawania go innym wymaga dopisania klauzuli WITH GRANT OPTION.

Uprawnienia można nadawać na różnych poziomach hierarchii: całego schematu, pojedynczej tabeli, a nawet wybranych kolumn. Nadanie na schemat obejmuje automatycznie obiekty utworzone w nim później, co zwykle jest wygodniejsze niż wyliczanie tabel po nazwie.

Login, użytkownik i rola — trzy różne byty

Na poziomie instancji istnieje login, czyli tożsamość pozwalająca w ogóle nawiązać połączenie. Wewnątrz każdej bazy istnieje osobny obiekt użytkownika powiązany z tym loginem i to jemu przypisuje się uprawnienia do tabel. Rola jest workiem, do którego wrzuca się użytkowników poleceniem ALTER ROLE nazwa ADD MEMBER uzytkownik.

Gotowe role bazodanowe skracają pracę: db_datareader daje odczyt wszystkich tabel, db_datawriter zapis, db_owner pełnię władzy nad bazą. Kuszące, ale zbyt szerokie — nadanie roli właściciela bazy szeregowemu pracownikowi oznacza, że może on skasować dowolną tabelę. Do wywoływania procedur służy uprawnienie EXECUTE i w dobrze zaprojektowanej aplikacji to ono, a nie bezpośredni dostęp do tabel, powinno być podstawą uprawnień użytkownika.

Osieroceni użytkownicy i inne niespodzianki po przeniesieniu bazy

Najczęstsza awaria pojawia się po odtworzeniu kopii bazy na innym serwerze. Użytkownik w bazie wskazuje wtedy na identyfikator loginu, którego na nowej instancji nie ma, więc mimo poprawnie wyglądających uprawnień logowanie kończy się błędem o braku dostępu. Naprawia się to przez powiązanie użytkownika z istniejącym loginem instrukcją ALTER USER z klauzulą WITH LOGIN.

Druga pułapka to nadawanie uprawnień pojedynczym osobom zamiast rolom. Przy dwóch pracownikach działa, przy piętnastu nikt już nie wie, kto co może, a odejście jednej osoby zostawia w bazie wpisy, których nikt nie sprząta. Trzecia to logowanie aplikacji na koncie sa — wygodne, dopóki nie okaże się, że każdy użytkownik programu handlowego ma techniczną możliwość skasowania całej instancji.

Uprawnienia w bazach programów handlowych

Systemy pokroju Subiekta, WAPRO czy Comarcha mają własną warstwę uprawnień w interfejsie, ale pod spodem i tak siedzi baza SQL Server z własnym zestawem praw. Przy wdrożeniach ustawiamy oba poziomy tak, żeby się nie wykluczały: konto aplikacji z uprawnieniami wystarczającymi do pracy, osobne konto do wykonywania kopii zapasowych i pełne prawa zarezerwowane dla administratora. Porządkujemy również instalacje odziedziczone po innych firmach, gdzie zwykle wszystko chodzi na jednym koncie z hasłem znanym połowie biura. Pracujemy siedem dni w tygodniu, więc przebudowę uprawnień da się zrobić w weekend, bez przestoju w pracy firmy.