Czy programiści powinni mieć uprawnienia do przeszukiwania ( SELECT/ tylko do odczytu) baz danych produkcji? W poprzednim miejscu, w którym pracowałem, zespół programistów miał db_datareaderrolę; gdzie teraz pracuję, zespół programistów nie może nawet połączyć się z instancją produkcyjną.

Jedną z instancji testowych jest kopia produkcyjna przywracana z produkcyjnej kopii zapasowej raz w tygodniu, więc nie ma żadnych problemów z faktycznym wyświetlaniem danych przez programistów.

Jakie są dobre powody, dla których programiści nie mogą wysyłać zapytań dotyczących produkcji (z wyjątkiem po prostu braku dostępu do odczytu poufnych danych)?

To naprawdę zależy od tego, czy programista ma jakieś obowiązki wsparcia. Jeśli czekają na wsparcie trzeciej linii, prawdopodobnie będą musieli spojrzeć na produkcyjną bazę danych, aby to zrobić.

Zasadniczo nie jest dobrym pomysłem robienie czegokolwiek na serwerze produkcyjnym, chyba że jest to naprawdę konieczne.

Do większości celów programistycznych lustra lub migawki produkcyjnej bazy danych będą odpowiednie i prawdopodobnie lepsze niż produkcyjna baza danych na żywo. Jeśli zajmujesz się integracją, potrzebujesz stabilnych środowisk baz danych, w których możesz kontrolować, co w nich jest. Wszystko, co wymaga pojednania, będzie również wymagało umiejętności spojrzenia na kontrolowany punkt w czasie.

Jeśli problem polega na tym, że nie masz produkcyjnego środowiska kopii lustrzanych ani żadnego sposobu na umieszczenie kopii danych produkcyjnych gdzieś dla programistów, to jest to nieco inne pytanie. W takim przypadku programiści naprawdę potrzebują co najmniej jednego środowiska kopii lustrzanej. Jeśli nie widzisz, jaki jest problem w danych, trudno jest go rozwiązać.

Nie.

Programiści nie powinni mieć dostępu do systemów produkcyjnych baz danych z następujących powodów:

1. Dostępność i wydajność : Posiadanie praw do bazy danych tylko do odczytu nie jest nieszkodliwe. Źle napisane zapytanie może:

   1. Blokuj tabele, blokując inne krytyczne procesy.
   2. Kosz pamięci podręcznej danych, zmuszając inne procesy do ponownego odczytu danych z dysku.
   3. Opodatkuj warstwę pamięci, wpływając na inne usługi, które współużytkują tę pamięć.

2. Bezpieczeństwo : Twoja produkcyjna baza danych może zawierać poufne informacje, takie jak:

   • hash hasła
   • informacje rozliczeniowe
   • inne dane osobowe

   Tylko ci, którzy absolutnie potrzebują dostępu do tych informacji, powinni je mieć. W dobrze zorganizowanej firmie programiści nie należą do tych osób. Co więcej, Twoja firma nie spełni wymagań PCI i SOX, jeśli jej programiści będą mogli uzyskać dostęp do systemów produkcyjnych za pomocą tych danych.

   Przyczyny tego są oczywiste. Prace programistyczne dewelopera przechodzą wiele rąk, zanim zostaną uruchomione. Co powstrzyma złośliwego programistę z bezpośrednim dostępem do produkcji przed kradzieżą danych produkcyjnych lub rzuceniem bazy danych na żywo na kolana?

   „Ale to dotyczy również DBA! Mogą to zrobić!” Dokładnie. Chcesz mieć tak mało superużytkowników, jak to możliwe.

Tak.

Deweloperzy powinni mieć dostęp do systemów produkcyjnych.

W mojej firmie mamy cztery zespoły zajmujące się produkcyjnymi bazami danych. Oni są:

1. Programiści , którzy projektują i piszą schemat i kod dla baz danych. Nie mają dostępu do baz danych w produkcji. Czasami jednak siedzą z administratorami lub osobami z Wsparcia i pomagają im spojrzeć na coś na żywo.
2. Administratorzy , którzy wdrażają, monitorują i zarządzają bazami danych w produkcji.
3. Wspieraj ludzi , którzy badają problemy produkcyjne wrażliwe na czas i przekazują informacje zwrotne programistom, aby mogli opracować poprawki.
4. Ludzie Business Intelligence , którzy wydobywają dane z baz danych produkcji przy użyciu regularnie odświeżanych kopii tych baz danych lub starannie napisanych i wyodrębnionych przez QA fragmentów (zazwyczaj opracowanych przez Administratorów).

Właściwe jest przyznanie programistom dostępu do produkcji, jeśli występują pewne braki w tych innych grupach.

Na przykład:

• Nie masz zespołu wsparcia. Kto będzie wiedział, gdzie szukać rozwiązania tego wrażliwego na czas problemu z produkcją? Twoi programiści. Zapewnij im dostęp do „ zbicia szyby ”.
• Nie masz zespołu BI. Twoi administratorzy nie mają ani nie chcą mieć nic wspólnego z raportami lub wyciągami. Kto rozwiąże problem, który twoi szefowie widzą każdego ranka? Twoi programiści. Przyznaj im ograniczony dostęp do debugowania tych raportów i wyciągów.
• Nie masz zespołu administracyjnego. Jesteś w bardzo małej lub startupowej firmie, więc przywitaj się z „przypadkowym DBA”. Twoi programiści pełnią podwójną rolę administratorów, dlatego potrzebują pełnego dostępu do produkcji.

Wydajność byłaby WIELKIM powodem.

To, że nie mogą zmienić danych, nie oznacza, że ​​nie mogą wpłynąć na serwer. Źle napisane zapytanie może sprowadzić środowisko produkcyjne na kolana i potencjalnie spowodować inne problemy (np. Przepełnienia tempdb):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

To przepis na katastrofę. Zauważ, że jest to produkt kartezjański z zamówieniem, co oznacza, że ​​zostanie posortowany w tempDB.

Zasadą jest „najmniejszy przywilej” i „trzeba wiedzieć”: czy programiści zdają ten test?
Zwłaszcza, gdy pukają Audytorzy lub Sarbannes-Oxley.

Następnie moje następne założenie: programiści są głupi. Więc jeśli potrzebują powiedzieć o wsparciu trzeciej linii, to kto tego potrzebuje? Małpy internetowe zwykle nie, ale typy baz danych tak, jeśli oczekuje się, że będą je obsługiwać.

Czy dostęp jest potrzebny na stałe? Mogą mieć dostęp do „zbicia szkła” przy użyciu loginu SQL lub alternatywnego konta Windows, które wymaga wylogowania. W naszym przypadku to właściciel danych (mam nadzieję, że jakiś przedsiębiorca znający się na technologii) i kierownik działu IT zatwierdzili to.

I nie widać programiści przetestować przed lub uruchamiania kwerend na produkcję i zabrać go w dół z powodu niewiedzy. Mówiąc to, programiści powinni wziąć odpowiedzialność za swoje działania: jeśli zdejmą serwer, powinni odpowiednio cierpieć. Mam kogoś zdegradowanego po jednym incydencie ...

Zakładają one oczywiście sklep o rozsądnych rozmiarach. Im więcej kapeluszy nosi się, tym mniej obowiązków możesz mieć

Czy istnieje również środowisko, w którym programiści mogą uruchamiać zapytania dotyczące najnowszych danych? W moim ostatnim sklepie prod co noc był przywracany na serwerze testowym, aby to zapewnić.

Myślę, że odpowiedź brzmi, podobnie jak w wielu sprawach IT, „to zależy”.

Ogromna baza danych ERP z dużą ilością poufnych informacji o firmie i kliencie? Prawdopodobnie nie (zarówno ze względów bezpieczeństwa, jak i wydajności).

Departamentowa baza danych 5 MB z interfejsem Access, która śledzi składki na fundusze pączków i pizzy? Nie zrobi dużej różnicy, przynajmniej dla dostępu tylko do odczytu.

To prawda, że ​​pierwszy przykład jest znacznie częstszy niż drugi, ale są to różnice, o których powinieneś wiedzieć, jeśli jesteś odpowiedzialny za podejmowanie tego rodzaju decyzji politycznych. Ale z drugiej strony, niesamowite jest to, jak szybko baza danych o funduszach na pączki i pizze o pojemności 5 MB może dotrzeć do 50-częściowych numerów / numerów kart kredytowych klientów / kto-co-co- inna baza danych, jeśli na to pozwolisz.

W zwykłym środowisku OLTP 24/7 normalny programista nie powinien być dopuszczony do produkcji. Kropka! Jeśli od czasu do czasu pojawia się konkretny powód, na żądanie można udzielić zezwolenia. Ale zwykle nie.

Widziałem wiele powodów:

• Wybierz * z dużego stołu prowadzącego do:

  • problemy z wydajnością (produkty kartezjańskie);
  • blokowanie problemów, które ostatecznie doprowadziły stronę do upadku;
  • blokowanie łańcucha zawieszającego replikację;
  • zamawianie dużego zestawu danych, które wypełniły dysk TempDB, które ... zgadnij co? Spowodowało całkowite szaleństwo :-)!
  • wysokie ciśnienie krwi dla DBA odpowiedzialnego za produkcję tej nocy;

• odczyt poufnych danych (deweloper nie powinien mieć dostępu do danych karty kredytowej ani żadnych danych osobowych użytkownika);

Jestem pewien, że jest jeszcze więcej powodów.

• Bezpieczeństwo: poufne informacje mogą zostać zdezynfekowane, gdy udostępnią je programistom.
• Paranoja: Niektórzy mogą myśleć, że nadal możesz zepsuć dane, wybierając tylko dostęp.
• Wydajność: zapytanie wymaga wykonania pewnych zasobów i nie możesz mi powiedzieć, że Twoi programiści są idealni, gdy piszą kod.

Kilka rzeczy do rozważenia

• Czy dane są wrażliwe?
• Czy programiści należą do głównego zaufanego zespołu, czy do jakiegoś zespołu offshore?
• Jaka jest skala danych, których dotyczy zapytanie, pod kątem wpływu na wydajność?
• Jaka jest skala projektu lub dolary?
• Jak krytyczny jest czas sprawności?

Mniejsze dolary wymagają mniejszego procesu, szybszego rozwoju.

Większe dolary potrzebują więcej procesów, wymagają surowszych standardów praktyk rozwojowych.

Dostosuj swoje praktyki do tego, co robisz.

Pracuję jako programista w bardzo dużej firmie. Wszyscy nasi programiści, którzy będą udzielać wsparcia (w zasadzie wszyscy), mają dostęp do odpowiednich produkcyjnych baz danych. Mogę mówić tylko w imieniu mojego konkretnego zespołu, ale powiem ci, dlaczego mamy dostęp.

1. Potrzebujemy dostępu w czasie rzeczywistym, aby mieć oko na nasze codzienne przetwarzanie. (Chociaż dysponujemy pulpitem nawigacyjnym, musimy mieć dogłębne oko na rzeczy. Chociaż byłoby miło mieć tę funkcję na naszym pulpicie nawigacyjnym, okazało się, że jest to niepraktyczne.)
2. Potrzebujemy dostępu w czasie rzeczywistym, aby zbadać wszelkie awarie produkcji, ponieważ opóźnienia mogą mieć ogromny wpływ. (Nie zamierzam tutaj omawiać naszych porażek. Przychodzą one wszelkiego rodzaju)
3. Często musimy tworzyć niestandardowe raporty dla użytkowników biznesowych, a informacje te muszą być aktualne. (dba nie ma na to czasu i nie mamy czasu na nie czekać. na pewno nie idealne).
4. Musimy przeprowadzić weryfikację produkcyjnych wdrożeń / poprawek DDL / DML. (DBA wdrażają je, ale tylko my wiemy, jak powinno się to ustrukturyzować. Wiemy więcej o naszej strukturze bazy danych niż DBA. Możemy być tutaj dziwni, ale nasza baza danych jest bardzo skomplikowana, ponieważ nasza działalność jest bardzo skomplikowana.)

Wydajność jest problemem. Mamy przypadki deweloperów powodujących spowolnienia. Są to jednak pojedyncze przypadki, a nasz SQL jest tak napędzany wydajnością, że rzadko programiści nie rozumieją wpływu swoich zapytań.

Aby zadać to pytanie, należy założyć, że obecnie nie mają one dostępu. Jeśli organizacja opracowuje oprogramowanie w celu rozwiązania problemu z klientem, a klient dostarcza kopię swojej bazy danych, wówczas „tak”. W przeciwnym razie zalecałbym trzymanie programistów poza produkcją i tworzenie alternatywnych środowisk dla ich potrzeb badawczych. Gdy pasta do zębów wyjdzie z tubki, trudno ją z powrotem włożyć.

Zgadzam się, że ciężar uzasadnienia powinien spoczywać na tych, którzy wymagają dostępu. Zazwyczaj w środowiskach, w których się konsultowałem, miałem dostęp do systemów produkcyjnych, w których było to małe środowisko i byłem osobą wspierającą. Miałem dostęp do kopii zapasowych itp., W których wspierałem wsparcie, oraz pośredni dostęp (za pośrednictwem dedykowanego programisty wsparcia) do danych produkcyjnych.

Najważniejsze jest to, że potrzebujesz tego dostępu, gdy jesteś na haku, aby wszystko działało płynnie i musisz odpowiedzieć na pytanie faceta ds. Finansów o coś, co nie działa. W takim przypadku nie zawsze można pracować z danych nawet z jednodniowych danych. Z drugiej strony, im większy dostęp, tym gorzej. Zazwyczaj jako konsultant staram się unikać takiego dostępu, chyba że jest to konieczne. Ponieważ pracuję nad bazami danych finansowych, ostatnią rzeczą, jakiej chcę, jest oskarżenie mnie o wprowadzanie własnych faktur :-D.

Z drugiej strony, jeśli nie potrzebujesz dostępu, nie powinieneś go mieć. Tak naprawdę nie kupuję argumentu o poufnych danych, ponieważ programista prawdopodobnie nie może się doczekać, aby upewnić się, że jest on obsługiwany poprawnie (i bardzo trudno jest zweryfikować bez patrzenia na to, co faktycznie zostało zapisane, gdy pojawia się raport o błędzie). Jeśli nie możesz ufać programistom, że przejrzy dane przechowywane przez aplikację programisty, nie powinieneś zatrudniać programisty do napisania aplikacji. Istnieje zbyt wiele sposobów, by programista mógł zaciemnić dane i wysłać je pocztą e-mail. Nigdy nie możesz być tego pewien. Kontrolki MAC pomagają tutaj, ale ich wdrożenie jest nadal dość skomplikowane.

Duży problem z mojej strony dotyczy dostępu do zapisu. Jeśli programista nie ma wtedy dostępu, a fortiori, programista nie ma dostępu do zapisu. Jeśli chcesz zweryfikować integralność książek, chcesz zachować dostęp do zapisu dla jak najmniejszej liczby osób. Ścieżki audytu są znacznie łatwiejsze do sprawdzenia, jeśli programiści nie mają dostępu. Jeśli programista ma dostęp do odczytu, zawsze masz pytanie, czy istniało jakieś dołączenie do eskalacji uprawnień, które może dać dostęp do zapisu (może zastrzyk SQL w procedurze składowanej?). Często miałem pełny dostęp do informacji rozliczeniowych klienta, gdy miałem dostęp do środowisk pomostowych. Jeśli jednak działa środowisko przejściowe, zwykle aktywnie poprosię o brak dostępu do produkcji, chyba że jest to konieczne.

Oczywiście to nie jest idealne. Deweloper może nadal wbudować w aplikację tylne drzwi, które mogą nie być łatwo wykrywalne, ale takie podejście jest rozsądne, biorąc pod uwagę fakt, że dane kopii zapasowej są dostępne od poprzedniego dnia, wydaje mi się, że jest to ich troska.

Mam nadzieję że to pomoże.

Edycja: Dodając, że w większych środowiskach, w których pracowałem, miałem dostęp do pełnej kopii zapasowej danych, często od kilku dni do kilku miesięcy dla systemu finansowego. To zawsze było wystarczająco dobre dla mojej pracy i jedyne czasy, kiedy się zepsuły, były wtedy, gdy faceci finansowi potrzebowali umiejętności testowania z nowszymi danymi, aby mogli porównać z produkcją.

Brak dostępu to dobra rzecz i sposób na ochronę programistów i innych osób przed przypadkowym uszkodzeniem lub przeglądaniem danych. Chroni to również firmy przed łamaniem prawa (tj. Naruszenia Hipaa i obawy dotyczące prywatności)

Deweloper nigdy tak naprawdę nie potrzebuje dostępu do środowiska produkcyjnego, z punktu widzenia deweloperów jest po prostu łatwiej, jeśli trudny błąd nie może zostać odtworzony.

Deweloper może jednak wstawić mini-zrzuty lub pliki dziennika i użyć plików symboli PDB do odtworzenia błędu.

Jeśli dane muszą zostać sprowadzone do środowiska testowego, typowym procesem jest szorowanie danych, które może spowodować dodatkową pracę.

W zależności od oprogramowania bazy danych używanego do tego, co nazywamy produkcją, deweloper może wymagać nowej licencji, aby uzyskać dostęp do bazy danych, co jest dużym wydatkiem, aby mieć tylko dostęp do odczytu.

Jeśli Twoja firma nie udostępnia narzędzi do debugowania lub badania problemów związanych z produkcją, nie dzieje się tak dlatego, że nie masz dostępu do danych produkcyjnych.

Dane są najcenniejszą częścią większości aplikacji!

Wydajność może być jednym z powodów.

Zapytania programistów często mogą być nieefektywne, powodując nadmierne blokowanie lub zużycie zasobów, dopóki nie zostaną odpowiednio dostrojone.

System produkcyjny nie jest odpowiednim miejscem dla programistów do eksperymentowania.

To zależy od DBA i tego, czy on lub ona jest pewna dewelopera. Zwykle programiści mają uprawnienia do wysyłania zapytań (odczytu) do produkcyjnych baz danych. Zasadniczo programiści powinni pracować tylko z bazami test / dev.

Wyzwanie polega na tym, że większość aplikacji jest sterowana danymi. Kiedy więc próbujesz naprawić problem w aplikacji, naprawdę potrzebujesz zobaczyć dane, które go napędzają. Dlatego programiści naprawdę potrzebują jakiejś formy dostępu.

Używanie loginów SQL, aby dać im dostęp tylko do odczytu do tabel, jest świetne. ALE, co uniemożliwia im utworzenie zapytania z 20 połączeniami lub wykonanie SELECT * z tabeli z milionami rekordów? Te zapytania mogą przypadkowo zabić wydajność bazy danych i pamięci.

Moja firma Stackify wpadła na sprytny sposób na rozwiązanie tego problemu. Programiści mogą uruchamiać zapytanie za pomocą naszego oprogramowania, a my używamy planu zapytań, aby upewnić się, że jest to tylko instrukcja SELECT oraz że szacowany koszt zapytania jest niski i zwróci tylko kilka rekordów. W ten sposób nie mogą wyrządzić wiele szkody. Kontrolujemy również wszystkie zapytania, które uruchamiają.

To tylko jedna z rzeczy, które zapewniamy. Sprawdź nas na http://www.Stackify.com, aby dowiedzieć się więcej o naszych rozwiązaniach pomocniczych DevOps .

Tak. W niektórych przypadkach sensowne jest zezwolenie niektórym podzbiorom użytkowników, w tym programistom, na pewien poziom dostępu do danych produkcyjnych zapytań. Należy jednak wprowadzić odpowiednie ograniczenia z dwóch powodów. Po pierwsze, jako DBA musisz dołożyć wszelkich starań, aby zapewnić poziom usług wymagany przez wszystkich użytkowników. Ponadto chcesz zapobiegać niezamierzonym błędnym zapytaniom, takim jak masowe usuwanie lub niszczenie reguł biznesowych. Oczywiste jest, że należy wprowadzić odpowiednie środki kontroli bezpieczeństwa.

Bez względu na powody, dla których możesz nie zezwalać na zapytania ad hoc bezpośrednio na tabele bazy danych, możesz uzasadnić zgodę na wyświetlanie zapytań i procedur przechowywanych. Korzystając z uprawnień do bazy danych, możesz zapobiec zapytaniom SELECT bezpośrednio w tabelach, a nawet ograniczyć, do których widoków i procedur przechowywanych ma dostęp dany użytkownik. Ta metoda nie tylko zapewnia elastyczność twojej bazie użytkowników, ale także chroni twoją integralność danych i niezawodność, jeśli jest poprawnie wdrożona.

W naszej firmie utrzymujemy slave'y tylko do odczytu baz produkcyjnych, na których nie polegają usługi produkcyjne. Zapewniamy programistom dostęp do danych w celu uzyskania dostępu do danych produkcyjnych. Jeśli są dane wrażliwe (informacje o kliencie, informacje o płatnościach itp.), Ograniczamy replikację tych tabel i utrzymujemy przykładową tabelę danych na serwerze podrzędnym.

Nie ... nigdy !!

Właśnie dlatego mamy serwery programistyczne / testowe / UAT. Dane z produkcji można skopiować do środowiska testowego, a programiści mogą rozpocząć testy. Wybrane zapytania mogą być również bardzo szkodliwe w przypadku środowiska produkcyjnego. Zwiększa obciążenie, a w godzinach szczytu może obniżyć całą wydajność.

Wszelkie potrzebne informacje powinny przechodzić przez DBA, który może uruchomić to, co chce (Wybierz) i wysłać im wyniki. Tak właśnie robimy w naszym środowisku.

Nie jestem pewien, dlaczego wszyscy zakładają, że programiści są głupi i nic nie wiedzą. Dostaję próbkę mnóstwa różnych ról, które pomieszały i nie powinny być „w produkcji”. Mam administratorów danych, administratorów systemów, administratorów sieci, programistów itp.

Nikt (dev, dba, sa) nie ma dostępu do żadnego serwera ani bazy danych w żadnym środowisku z normalnym logowaniem do sieci. Wszystkie mają określone konta „admin”, z których należy korzystać. Tak, zazwyczaj dba i sa używają ich częściej, ale nawet one powinny lekko kroczyć. Wszyscy spalili mnie.

Tak więc w dobry dzień żadna rola IT nie potrzebuje dostępu. Jednak sh! T uderza w wentylator, wszystkie ręce na pokładzie i potrzebujemy odpowiednich ludzi rozwiązujących problem. Zwykle prowadzi to programista, który zna aplikację i prowadzi dba i sa do określonych punktów. To tylko niepotrzebne opóźnienie lub prośba i zatwierdzenie.

Ponadto, po zatwierdzeniu nigdy nie następuje audyt typu, więc zatwierdzenie nic nie znaczy.