Odpowiedź.

Serwer SQL wspiera wielopoziomowy system praw dostępu przez role, prawa użytkowników (GRANT/REVOKE) i schematy (schemas). Kluczowe zasady:

• Przypisuj rolę= zestaw uprawnień, które później otrzyma użytkownik.
• Daj minimalne prawa, tylko te niezbędne (zasada minimalnych uprawnień).
• Dziel uprawnienia na poziomie bazy, tabel, widoków i procedur osobno.
• Dla szczególnie ważnych operacji — używaj tylko przez procedury składowane lub widoki, a nie bezpośredni dostęp do tabel.

Przykład tworzenia ról i przypisywania praw:

-- Tworzymy rolę dla analityków
CREATE ROLE Analyst;
-- Dajemy tylko SELECT do potrzebnych tabel
GRANT SELECT ON Sales TO Analyst;
-- Zabranianie modyfikacji danych
REVOKE INSERT, UPDATE, DELETE ON Sales FROM Analyst;
-- Przypisujemy rolę użytkownikowi
GRANT Analyst TO user_ivan;

Często wyróżnia się role do odczytu (read-only), modyfikacji, administracji i poszczególnych operacji.

Pytanie z podstępem.

Podstęp: "Czy użytkownik, który ma dostęp tylko do widoku (VIEW), może zmienić bazową tabelę przez niego? Podaj przykład."

Odpowiedź: Tak, jeśli VIEW nie zawiera agregacji/grupowania i nie jest tylko do odczytu (WITH CHECK OPTION) – można wykonywać INSERT/UPDATE/DELETE na VIEW, a zmiany trafią do bazowej tabeli, jeśli zezwolenia na to pozwalają.

-- Widok, odrzucający zbędne kolumny
CREATE VIEW SalesAsView AS SELECT id, total, manager_id FROM Sales;
-- Jeśli jest to dozwolone, użytkownik wprowadzi zmiany w ten sposób:
UPDATE SalesAsView SET total=1000 WHERE id=42;
-- To wpłynie na Sales.total dla id=42

Rozwiązanie: używać tylko readonly VIEW lub zakazywać praw do zmian danych przez widoki.

Przykłady rzeczywistych błędów z powodu braku znajomości szczegółów tematu.

---

Historia

Projekt: Portal HR, dane osobowe pracowników.

Błąd: Operatorzy mieli dostęp do bazowej tabeli przez VIEW bez ograniczenia w zakresie UPDATE — przypadkowo modyfikowali wynagrodzenia nawzajem, chociaż początkowo VIEW był zaplanowany "tylko do raportów".

---

---

Historia

Projekt: Księgowość, integracje zewnętrzne.

Błąd: Przyznano zewnętrznemu systemowi prawa INSERT i SELECT na całą bazę danych zamiast tylko INSERT do potrzebnych tabel. Efekt: podatność na odczyt całej bazy danych i możliwe naruszenie przepisów dotyczących RODO.

---

---

Historia

Projekt: Platforma SaaS, wieloletnie raporty.

Błąd: Wszyscy klienci pracowali w jednym schemacie z wspólnymi prawami: przypadkowo widzieli i mogli edytować cudze dane. Rozwiązanie — podział na schematy, osobne role i własne ograniczenia na poziomie Row Level Security (RLS).

---