Jakie są rozsądne uprawnienia do przyznania typowym użytkownikom? [Zamknięte]

Uważam, że lista uprawnień zapewnianych przez MySQL jest nieco przytłaczająca. Nie jestem pewien, kto powinien mieć jakie przywileje. Moim zdaniem w mojej sytuacji jest trzech typowych użytkowników:

1. root
2. developer
3. application

rootjest oczywiste. Aby developerten użytkownik mógł mieć łatwy dostęp do dowolnej bazy danych, wprowadzić w niej zmiany itp. Na początek ustawiam tego użytkownika na ten zestaw uprawnień:

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationma jeszcze bardziej ograniczony zestaw. Powinno to być ograniczone do manipulowania określoną bazą danych.

Nie jestem pewien, jaki rozsądny zestaw uprawnień należy przyznać. Jakie są uzasadnione uprawnienia do przyznania programistom i aplikacji i dlaczego?

Typowy użytkownik powinien mieć:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

Pierwsze cztery są dość oczywiste - chociaż możesz również skonfigurować użytkowników „tylko do odczytu” z tylko SELECT.

CREATE TEMPORARYjest również przydatny i zwykle nieszkodliwy: tabele tymczasowe mogą pomóc w optymalizacji zapytań, dzieląc je na mniejsze i szybsze części. Są ograniczone do wykonującego połączenia i są automatycznie usuwane po jego zamknięciu.

EXECUTEzależy od typu systemu. Czy masz zapisane procedury? Czy chcesz, aby użytkownicy mieli do nich dostęp? Upewnij się, że znasz również SECURITY=DEFINER/INVOKERdefinicję przechowywanych procedur.

W każdym przypadku pamiętaj, aby zastosować wszystkie powyższe w określonych schematach . Unikaj używania:

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

ponieważ powyższe przyznaje również uprawnienia do mysqltabel systemowych, skutecznie umożliwiając każdemu użytkownikowi tworzenie nowych kont lub aktualizację własnego zestawu uprawnień. Zamiast tego wykonaj:

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

W każdym systemie w skali rzeczywistej (tj. Nie jest to projekt osobisty), typy użytkowników będą się różnić w zależności od środowiska, więc nie jest to takie proste.

We wszystkich środowiskach aplikacja powinna mieć to, czego potrzebuje i nie więcej (ogólnie jest to „wybierz / wstaw / aktualizuj na wszystkich tabelach” i „wykonaj na wszystkich procedurach”. W większych systemach, w których możesz mieć oddzielnych użytkowników aplikacji do różnych zadań (dla instancja jedna aplikacja jest odpowiedzialna za wprowadzanie danych cenzora, a inna za generowanie raportów), powinieneś oddzielić ich uprawnienia, aby mieli najmniej potrzebnych im danych (użytkownik raportujący prawdopodobnie nie potrzebuje i nie pisze praw). Upewnij się, że replikujesz to w teście środowisk, jeśli je masz: widziałem, jak kod się przewraca, gdy awansował do Live, który działał w teście, ponieważ wszystko w środowisku testowym uzyskiwało dostęp do DB as sa(odpowiednik MSSQL root).Najlepiej byłoby, gdyby użytkownik aplikacji nie miał żadnych uprawnień, które pozwalałyby mu zmieniać schemat (CREATE,, DROP...) - są wyjątki, ale jest ich niewiele.

rootjest dobrze root. W produkcji jest to tylko Twój DBA i powinien być rzadko używany - tylko do konserwacji systemu (aktualizacje do projektu DB itp.) I monitorowania. W przypadku dużego systemu, szczególnie w środowiskach regulowanych, w których musisz zachować ścisłą kontrolę nad osobami do celów rozliczeniowych, możesz w ogóle nie pozwolić jednemu rootużytkownikowi i spróbować rozdzielić uprawnienia na mniejsze rolki (nie jestem pewien, jak daleko możesz się posunąć z tym w mysql, ale możesz być dość drobnoziarnisty w MSSQL, Oracle i tak dalej).

Użytkownicy programiści: nie powinni mieć żadnego dostępu do środowiska na żywo. Jest to jeden z powodów, dla których użytkownicy aplikacji nie powinni mieć schematu wpływającego na prawa: ktoś mający dostęp do konta programisty może potencjalnie obejść blokadę w ten sposób. Również w środowiskach testowych zwykle nie mają dostępu: przesyłają łaty do QA, a DBA (prawdopodobnie używa rootużytkownika) do QA zastosuje aktualizacje do środowiska testowego (w rzeczywistości jest to często zautomatyzowane w dużych organizacjach, więc QA DBA jest w rzeczywistości zestawem skryptów, które kontrolują przebudowę środowiska testowego dla każdego cyklu). W środowiskach programistycznych, zwłaszcza jeśli deweloperzy mają własne lokalne kopie uruchomionej usługi, użytkownicy ci powinni oczywiście mieć pełny dostęp do wszystkiego, aby móc eksperymentować.

Powyższe zawiera jednak ogólne uwagi: aby sformułować jakieś konkretne zalecenia, musielibyśmy dowiedzieć się znacznie więcej o twoich aplikacjach i środowiskach, w których działają. Środowisko docelowe jest czasem ważniejsze niż mogłoby się wydawać: w zależności od środowiska biznesowego prawa użytkowników mogą być nawet podyktowane dość bezpośrednio przepisami prawa, nawet w fazie rozwoju, jeśli klienci kiedykolwiek dadzą ci dostęp do prawdziwych danych w celach diagnostycznych.