Wszelkie wskazówki dotyczące zmniejszenia moich przywilejów produkcyjnych, ale nie nadmiernego utrudniania mojej pracy

Uruchamianie programu SQL Server 2005 i 2008 w systemie Windows 2008 R2.

Będziemy redukować przywileje w produkcji dla programistów - i chciałbym zrobić to samo dla siebie jako DBA , ograniczając prawa do produkcji i podnosząc w razie potrzeby .

Moim głównym celem byłoby wyeliminowanie głupich błędów - popełnianych przez DBA , devopers będą mieli co najwyżej dostęp do odczytu w produkcji. Lubimy zachowywać się, jakbyśmy byli superbohaterami, którzy nie mogą popełnić błędu, ale brak ciągłych praw do produkcji ma sens i jest to najlepsza praktyka, zalecana przez niektórych.

Jakie jest najlepsze podejście? Co będzie najmniej bolesne w codziennym użytkowaniu i podczas instalacji?

Obecnie mamy grupę okien dla DBA, która ma prawa do wszystkich naszych serwerów i baz danych.

Byłbym także zainteresowany obniżeniem uprawnień do logowania do systemu operacyjnego / zdalnego - ale najbardziej interesują mnie prawa DB.

Domyślam się, że potrzebowalibyśmy podwyższonych szeregów prywatnych, aby uruchomić ślady jako sa i ewentualnie do pewnego oczyszczenia własności, zanim zabierzemy prawa SA starego loginu. Jakich innych problemów możemy się spodziewać?

Dzięki za porady i dzielenie się doświadczeniami!

Idealnie, jeśli chodzi o działającą produkcyjną bazę danych, nie chcesz, aby programiści mieli jakikolwiek dostęp do serwera lub jakiejkolwiek bazy danych na nim. Jest to jedna z pierwszych rzeczy, które musisz zrobić, aby zachować zgodność z SOX .

Dla tego rodzaju praw, które użytkownicy o identyfikatorach prowadzonym pod jedynymi prawa tak naprawdę powinien mieć to db_datareader, db_datawriteri wyraźny GRANT EXECUTE ON x TO y(dla każdej przechowywanej obrady i funkcji zdefiniowanych przez użytkownika xdla identyfikatora użytkownika y).

Jeśli potrzebujesz uruchamiać śledzenie w produkcji, masz pewne problemy i zajmie to Great Wall of Text ™, aby wszystko wyjaśnić. Moje pierwsze zalecenie to mieć środowisko QA, które jest zablokowane tak jak produkcja, a jeśli ślady muszą być uruchomione, przywróć kopię zapasową prod db do QA i uruchom tam ślady. Ponownie, jeśli masz wymagania SOX, HIPAA lub PCI-DSS , lepiej oczyść dane prod przed przywróceniem ich do kontroli jakości.

Obecnie mamy grupę okien dla DBA, która ma prawa do wszystkich naszych serwerów i baz danych.

Daj im się zalogować i przeglądaj prawa do danych; jednak aby wykonywać obowiązki DBAly, użyj osobnego loginu z podwyższonymi uprawnieniami. Znam jednego klienta finansowego, który to robi - zwykłe logowania oparte na uwierzytelnianiu systemu Windows miały ograniczone szkody, które mogliby przypadkowo wyrządzić. Przywracanie i uruchamianie DML wymaga uruchomienia z oddzielnym loginem do uwierzytelnienia SQL.

Jedna agencja rządowa, z którą współpracowałem, użyła 2 oddzielnych loginów dla każdego administratora serwera / db. Więc jeśli Tangurenabyłby login mojej domeny (to logowanie miałoby regularne Useruprawnienia), to TangurenaAdminbyłby mój osobny Administratorlogin. Wpadniesz w kłopoty, jeśli cały czas korzystasz z konta administratora, ale potem nie ma on uprawnień do innych rzeczy (jak brak wiadomości e-mail. Och, mówisz, że to coś złego ... ).

Obecna agencja rządowa, z którą współpracuję, ma każdego administratora serwera / db mającego uprawnienia podwyższone powyżej standardowego użytkownika, ale nie do końca administracyjnego (traktuj to jako PowerUsergrupę). Funkcje administratora domeny są wykonywane przy użyciu współdzielonego konta administratora domeny.

Częstym błędem jest przywracanie niewłaściwej bazy danych (np. QA przywracanej przez serwer produkcyjny) i nie zostanie to rozwiązane przez ograniczone prawa lub wielokrotne logowanie. Robienie rzeczy potencjalnie destrukcyjnych parami jest jednym ze sposobów zminimalizowania ryzyka.

Zgaduję, że potrzebowalibyśmy podwyższonych szeregowców, aby prowadzić ślady jako sa

Nie. Potrzebujesz tylko uprawnień ALTER TRACE:
http://msdn.microsoft.com/en-us/library/ms187611.aspx

Na początku sugeruję, abyś wykonał wszystkie przywileje w środowisku programistycznym lub kontroli jakości, gdzie nie ma problemu, jeśli dostęp zostanie usunięty na jakiś czas. Musisz sprawdzić, czy aplikacje nie będą miały problemów z bezpieczeństwem.

Opowiem ci nasze wewnętrzne podejście:

• wszystkie aplikacje używają jednego użytkownika domeny, któremu przyznano niezbędne uprawnienia do bazy danych (zwykle rola bazy danych db_owner).

• do sporadycznego odczytu danych używamy loginu SQL. Dla tego użytkownika przypisujemy rolę bazy danych - db_datareader. Tutaj kończy się dostęp programistów do głównego klastra bazy danych. W przypadku każdego innego pomysłu użyliby baz danych serwera raportowania, które są kopiami (wykonanymi za pomocą Log Log) głównych baz danych serwera wykonanymi o północy. Aby nie zabić serwera raportującego zabójczymi zapytaniami ad hoc, korzystamy z przydziałów grup zasobów dla pamięci i procesora.

• dla zespołu DBA mamy grupę domen, która ma wszystkie uprawnienia na komputerze i serwerze (administrator na komputerze z systemem Windows i sysadmin na serwerze sql)

• w przypadku instalacji mamy użytkownika SQL, który jest db_owner w bazach danych, których używamy podczas uruchamiania aktualizacji - używamy wyzwalaczy DDL do monitorowania zmian schematu i powinniśmy zobaczyć, które zmiany zostały wykonane podczas instalacji lub jako osobna zmiana

• istnieją pewne wyjątki od doświadczonych programistów, ale po ich zaspokojeniu usuwamy ich dostęp - otrzymują uprawnienia na podstawie loginu domeny, dzięki czemu możemy monitorować połączenia w widokach śledzenia / ddl i wszelkich możliwych zmianach za pomocą wyzwalaczy ddl.

Jeśli chodzi o sposób wykonywania wszystkich prac związanych z logowaniami i użytkownikami - w Management Studio w folderze bezpieczeństwa serwera tworzysz wszystkie potrzebne loginy, a następnie kojarzysz je ze swoimi bazami danych i nadajesz im role, których potrzebują. Jeśli wykonasz skrypt, zobaczysz, że początkowo zostanie utworzony login serwera, następnie użytkownik bazy danych podłączony do tego loginu, a następnie przypisana rola bazy danych dla tego użytkownika. Możesz zachować skrypt w zestawie skryptów, aby za każdym razem można było zweryfikować, którzy użytkownicy powinni być aktywni, a którzy nie.

Na serwerze SQL możesz utworzyć użytkownika bazy danych i przypisać mu database roleuprawnienia do odczytu / zapisu / posiadania. Po migracji użytkownika do wersji produkcyjnej możesz przejść do użytkownika bazy danych, który został poddany migracji, i odznaczyć role, których nie chcesz mieć. Załóżmy na przykład, że użytkownik stan jest członkiem testowanego właściciela_bazy_danych (własność bazy danych). Po migracji stanu użytkownika do wersji produkcyjnej można go usunąć z db_owner i przypisać mu tylko rolę db_datareader (tylko do odczytu).

W SQL 2005+ można uzyskać bardziej szczegółową kontrolę za pomocą schema. Sprawdź ten link na schemacie, aby uzyskać więcej informacji.