Zapewnianie użytkownikom MySQL tylko minimalnych uprawnień

Question

Dla aplikacji internetowej, podczas tworzenia użytkownika, który połączy się z bazą danych MySQL, masz wybór uprawnień. Zakładając, że jedynymi czynnościami, które mają być wykonane przez tego użytkownika są SELECT/INSERT/UPDATE/DELETE, wydaje się, że sensowne jest jedynie zapewnienie tych przywilejów, jednak nigdy nie widziałem tego polecanego w dowolnym miejscu - jakie są powody tego i przeciw temu metoda?

Answer 1

Istnieją inne przywileje, które użytkownik może potrzebować podczas zwykłej aplikacji, na przykład:

• utworzenia tymczasowej tabeli
• EXECUTE (procedury składowane)
• pliku (na SELECT INTO i dane obciążenia)
• LOCK TABELE

Istnieje również możliwość, że minimalne przywileje mogą oznaczać tylko WYBIERZ na niektórych tabelach i tylko WYBIERZ i AKTUALIZUJ na innych stołach itp. Może to ulec zmianie w dowolnym momencie, gdy funkcjonalność aplikacji jest udoskonalona. I są dziwne przypadki, takie jak potrzeba posiadania uprawnienia SELECT na tabeli, której nigdy nie kwerendy, ponieważ odwołuje się przez klucze obce w tabela, którą UPDATE. Śledzenie minimalnych uprawnień jest królewskim bólem.

Co próbujesz ograniczyć za pomocą uprawnień SQL? To Ty napisałeś cały kod, więc zarządzanie uprawnieniami SQL z drobną ziarnistością nie powinno być konieczne. Szczerze mówiąc, jeśli użytkownicy są w stanie załadować i uruchomić SQL, które nie zostały sprawdzone, masz większe problemy:

SELECT * FROM mytable, mytable, mytable, mytable, mytable ORDER BY 1; 

Rzeczywiste zadań, które mają rządzić nie są na poziomie bazy danych, są one na poziomie biznesowym aplikacji. Na przykład CMS ma operacje takie jak: tworzenie strony, edycja strony, administrowanie komentarzami itp. Zadania te są na wyższym poziomie niż uprawnienia SQL. Można naśladować je za pomocą ról SQL (które są grupami uprawnień), ale role SQL nie są szeroko obsługiwane.

Nie znam nikogo, kto mapuje użytkowników aplikacji na różnych użytkowników MySQL. Są to użytkownicy uwierzytelnieni w swojej aplikacji, po aplikacja połączyła się z bazą danych (użytkownicy są po prostu rzędami danych w bazie danych).

Prawdopodobnie lepiej, aby Twoja aplikacja internetowa korzystała z jednego użytkownika MySQL z pełnymi uprawnieniami.

Answer 2

Aplikacja internetowa zazwyczaj używa tylko jednego użytkownika, aby uzyskać dostęp do bazy danych zamiast użytkownika na rzeczywiste konto użytkownika. Stosowanie minimalnych przywilejów jest dobrą praktyką. Nazwa użytkownika i hasło zostaną zakodowane w twoim skrypcie (czy ktoś to zaciemni?), Więc jest miejsce na kompromis, jeśli twoje skrypty nie są właściwie zarządzane.

Z mojego doświadczenia wynika, że ​​bardzo rzadko zdarza się, że aplikacja usuwa wiersze - o wiele lepiej, aby oznaczyć wiersz jako usunięty, a następnie przeprowadzić kontrolę tego, co się tam dzieje, a nie wiedzieć, co tam było! Takie podejście pomaga również zoptymalizować tabele i indeksy.

Dlatego sugerowałbym, aby pozwolić tylko WSTAW, AKTUALIZUJ i WYBIERZ - szybko stanie się oczywiste, jeśli części aplikacji muszą być nieco odprężone!

Pozwolenie na więcej przywilejów może jedynie zwiększyć możliwość ataków typu DoS, wydając polecenia o dużym natężeniu zasobów lub umożliwiając złośliwe ataki danych.

Answer 3

Nie zgadzam się z Billem, a linia myślenia Atomix jest bardziej odpowiednia. O ile nie można wykazać inaczej, odpowiedź Billa znacznie zwiększa ryzyko naruszenia bazy danych.

Być może dla bardzo doświadczonych programistów istnieją inne zabezpieczenia, ale dla innych programistów, które dają pełny skrypt, nieskrępowany dostęp do ~ czegokolwiek ~ do bazy danych wymaga kłopotów, kiedy nie ma takiej potrzeby.

Zasada najmniejszych uprawnień powinna być tutaj stosowana. W przypadku MySQL, masz superużytkownika z wszystkimi uprawnieniami, które są używane do tworzenia tabel, upuszczania bazy danych i tak dalej. Idealnie ta nazwa użytkownika i hasło nigdy nie są widoczne w żadnym pliku PHP ani żadnym pliku na serwerze WWW. (Używam PHP jako przykładu, ale dotyczy to innych aplikacji internetowych). Używałbyś tylko tej nazwy użytkownika i hasła z czymś takim jak PHPMyAdmin lub MySQL Workbench.

Następnie, w przypadku skryptów PHP, należy wybrać jeden z minimalnym wymaganiem, na przykład po prostu INSERT, SELECT, UPDATE, a może nawet DELETE, w zależności od skryptu PHP. Byłoby to w plikach PHP, to znaczy w rzeczywistości tylko JEDEN plik poza katalogiem głównym dokumentu, jak zaleca większość.

Powód brzmi: tak, nie potrzebujesz użytkownika MySQL dla każdego użytkownika aplikacji internetowej. Należy jednak stosować zasadę najmniejszego przywileju (http://en.wikipedia.org/wiki/Principle_of_least_privilege). Jeśli w jakiś sposób twój superużytkownik MySQL zostanie przejęty, ponieważ przypadkowo nazwałaś skrypt połączenia MySQL jako .txt zamiast .php, lub ktoś uzyskał dostęp do plików serwera WWW, przynajmniej "najgorsze", co mogą zrobić, to WYBIERZ, AKTUALIZUJ i WSTAW. .. Które, chociaż może powodować duże problemy, nie jest tak źle, jak daje im DROP DATABASE, DROP TABLES i wiele gorszych rzeczy. Dodatkowo, w moim obecnym projekcie ze względu na zwinne praktyki programistyczne (nie pracuję, ale polecam http://www.agilealliance.org/), jeden lub dwóch członków zespołu "nie-tech" bezpośrednio używa PHPMyAdmin, aby dokonać bezpośrednich zmian w bazie danych MySQL. Wynika to z faktu, że tworzenie CMS do prostego bezpośredniego wprowadzania danych nie jest wymagane. W tym przypadku odpowiedni dla nich jest trzeci użytkownik MySQL z uzasadnionymi, ale znowu "wystarczającymi" uprawnieniami. Nie chcemy sparaliżować członka zespołu zbyt małymi przywilejami, ale oczywiście nie powinni oni być w stanie przypadkowo usunąć lub zmienić rzeczy.

Ponieważ MySQL nie ma ROLE (od czasu pierwotnego pytania i zgodnie z Ustawą), wówczas zezwolenie każdemu skryptowi sieciowemu na dostęp do MySQL tylko z jednym Superużytkownikiem jest bardzo ryzykowne.