Jakie uprawnienia powinni mieć deweloperzy w instancji bazy danych Dev

Question

... i w jaki sposób powinny być przyznane te uprawnienia. Pracuję w dużym dziale IT z ponad 70 aplikacjami, niektóre w serwerze SQL i większość w Oracle. Każdy system ma instancję prod, QA i Dev. My (jestem programistą) mam tylko dostęp do prod/qa, z którym nie mam nic przeciwko. W programach SQL Server instancje deweloperów otrzymują db_owner, który działa całkiem dobrze. Debata dotyczy jakich uprawnień powinienem mieć w bazach danych Oracle DEV.

Rozumiem, że najlepszym rozwiązaniem byłoby, gdyby każdy programista uruchamiał na swoim stanowisku roboczym własną instancję do programowania, ale ze względu na wielkość baz danych nie było to uważane za opcję.

Jestem również zainteresowany tym, JAK te uprawnienia powinny być stosowane. W prawach oracle udzielanych przez rolę nie są aktywne podczas wykonywania PL/SQL, więc role (nawet rola "dba") nie są użyteczne. Pozostawia to wbudowane konto (system) lub tworzenie dziesiątek użytkowników w dziesiątkach baz danych i bezpośrednio przyznaje każdemu dziesiątki uprawnień. Moim zdaniem pozwolenie programistom na zalogowanie się jako system ma wiele sensu, ale nasze administracje DBA twierdzą, że to zły pomysł.

Answer 1

Zwykliśmy dawać deweloperom dostęp do konta aplikacji. Działa to w przypadku małych sklepów, ale szybko wymyka się spod kontroli wraz ze wzrostem liczby deweloperów.

Oto co możemy teraz zrobić:

1. aplikacja ma swój własny rachunek (aka schemat).
2. Deweloperzy mają własne konta rezyduje
3. danych w schemacie aplikacji
4. Mamy ant build skrypt do budowania kod w schemacie chcesz.
   • Kod zawiera widoki, opakowań, przedmiotów itp ..
   • skrypt kompilacji obejmuje etap, aby uruchomić procedurę przechowywaną, aby udzielić jednoznacznych praw twórców do danych aplikacji
5. Deweloperzy dokonać zmian w ich własny schemat
6. Gdy są szczęśliwe, sprawdzają to w subversion
7. Schemat deweloperski aplikacji zbudowany jest z nowej wersji subversion.
8. Deweloperzy mogą sprawdzać i odtwarzać własne środowiska.
9. DDL zmiany struktury tabeli są wykonywane przez DBA
   • można je skryptów oraz

Ma to tę zaletę zapewnienia dowolną aplikację Zaczepy nie jest łamany przez programistów baz danych stale przebudowując wszystko.

Answer 2

Jednym z zadań DBA jest zarządzanie uprawnieniami użytkownika. Nie sądzę, aby system był dobrym pomysłem z kilku powodów, nie tylko z powodu upuszczenia całego schematu, na który jestem pewien, że nie chcesz. Biorąc to pod uwagę, uważam, że jest całkowicie w porządku, aby przyznać wszystkim użytkownikom i pozwolić administratorom administracyjnym na zarządzanie tymi uprawnieniami, bez względu na to, ile dziesiątek kont może być. Większość administratorów danych ma skrypty, z których mogą korzystać, aby i tak zarządzać tymi uprawnieniami.

Słuchaj swoich administratorów, oni na ogół wiedzą, o czym mówią.

Answer 3

Jeśli jest to tylko instancja programisty; chciałbym, aby wszyscy użytkownicy mieli indywidualne konta dodane do roli administratora. W ten sposób nadal możesz rejestrować aktywność dla poszczególnych użytkowników; ale daj fanom wystarczająco dużo miejsca do oddychania, żeby zrobić swoje.

Answer 4

Zakładam, że istnieje stosunkowo niewielka liczba kont aplikacji, które są właścicielami rzeczywistych obiektów. Tak więc jedna lub więcej aplikacji logicznych składa się z tabel posiadanych przez określonego użytkownika Oracle. Nie byłoby to przez SYSTEM ani SYS, nie byłoby to żadne z kont, które firma Oracle dostarcza. Byłoby to konto utworzone przez twoje DBA. Jeśli znasz schematy przykładowe Oracle, użytkownik HR posiada wszystkie tabele w schemacie HR, które stanowią zaplecze dla aplikacji HR.

Począwszy od zasady "najprostszej rzeczy, która może działać", moją pierwszą myślą byłoby sprawdzić, czy programiści mogą zalogować się bezpośrednio do tych kont aplikacji. Nie jest to najbezpieczniejsza z możliwych konfiguracji, a Ty otwierasz możliwość, że programista przypadkowo lub celowo wyrządza szkody, które mogą być trudne do śledzenia lub łatwe do rozwiązania. Ale może działać całkiem dobrze w zależności od organizacji. Zarządzanie przywilejami jest banalne - konto właściciela aplikacji ma już wszystkie wymagane uprawnienia.

Następnym krokiem byłoby stworzenie dla każdego programisty oddzielnego schematu do opracowania, prawdopodobnie w połączeniu z obciążeniem publicznych synonimów w bazie danych i brakiem kwalifikatorów schematu w kodzie aplikacji, tak aby każdy obiekt utworzony w Schemat programisty automatycznie zastępuje udostępnioną wersję tego obiektu. Zapewnia to znacznie lepszą izolację. Uprawnienia są generalnie przyznawane przez tworzenie skryptów, które zawierają wszystkie granty wymagane przez programistę lub przez utworzenie skryptu, który kopiuje wszystkie przywileje z "dobrze znanego" konta na nowe konto. Nie jest to szczególnie trudne do napisania - wystarczy upewnić się, że wszyscy programiści otrzymają ten sam zestaw uprawnień, co jest generalnie kolejnym skryptem uruchamianym po przyznaniu nowego przywileju.

Answer 5

Moja grupa obsługuje około 100 aplikacji, a około 20 z nich ma własny schemat Oracle. Poszliśmy na dół, każdy programista ma hasło do schematu i jest to wygodne. Jednak z perspektywy czasu polecam każdemu deweloperowi wykorzystanie własnego konta Oracle do opracowania. Głównym powodem jest audyt.

Answer 6

uznaję, że najlepszym wypadku byłoby mieć każdy dev uruchomić własną instancję na swojej stacji roboczej rozwoju, ale ze względu na wielkość baz ten nie został uznany opcja.

Czy można temu zaradzić, może zmniejszając ilość danych w swoich osobistych kopiach? Wydaje się to idealnym rozwiązaniem, ponieważ umożliwiłoby to wprowadzenie wszelkich niezbędnych zmian. Następnie możesz przesłać je do DBA, kiedy będziesz gotowy, i poprosić go o aktualizację udostępnionego serwera programistycznego.

Answer 7

Jeśli tworzysz przechowywane obiekty PL/SQL, to schemat będący właścicielem tych obiektów wymaga, jak wspomniałeś, wyraźnych przydziałów dla używanych obiektów. Jeśli masz jeden schemat "danych", ale rozwijasz kod w swoich własnych schematach, powinieneś mieć możliwość nadawania dostępu do obiektów schematów danych do schematów rozwoju. Normalnie oczekiwałbym nazwy użytkownika/hasła dla schematu danych.

Jeśli chodzi o uprawnienia systemowe (np. CREATE), oczekiwałbym STWORZENIA TABELI, TYPU, WIDZENIA, PROCEDURY WYZWALANIA, SYNONYM. Inne mogą być odpowiednie (np. CONTEXT) w zależności od tego, co robisz. Administrator bazy danych może wykluczyć utworzenie folderu, ponieważ może to być szkodliwe, jeśli zostanie niewłaściwie użyte. Ditto dla uprawnień z DOWOLNYM w nich (np. WYBIERZ KAŻDĄ TABELĘ, USUŃ DOWOLNĄ TABELĘ)

Do dostrajania wydajności/monitorowania systemu w bazie danych dev SELECT_CATALOG_ROLE jest dobra. Jeśli DBA jest niechętny do podejmowania ryzyka, być może będziesz musiał negocjować dotacje na indywidualne poglądy. Przejdź do podręcznika REFERENCE dla swojej wersji i poproś o dowolne użycie.