Jakie uprawnienia powinien mieć Deweloperzy w instancji bazy danych Dev

głosy
5

... i jak należy te uprawnienia zostać przyznana. Pracuję w dużym dziale IT z ponad 70 aplikacji, niektóre w serwerze SQL i najbardziej wyroczni. Każdy system ma prod, QA i Dev instancji. My (jestem programistą) mają dostęp tylko do odczytu do prod / QA, który jestem w porządku. W SQL przypadkach rozwoju serwera deweloperów podano db_owner, który działa całkowicie w porządku. Debata nad tym, co uprawnienia powinien mieć w bazach danych DEV Oracle.

Uznaję, że najlepszym wypadku byłoby mieć każdy dev uruchomić własną instancję na swoim stanowisku pracy na rzecz rozwoju, ale ze względu na wielkość bazy danych nie zostało to uznane za opcję.

Jestem również zainteresowany w jaki sposób te uprawnienia powinny być stosowane. W oracle uprawnień udzielonych za pośrednictwem roli nie są aktywne podczas wykonywania PL / SQL, tak ról (nawet „dba” Role), nie są użyteczne. To pozostawia za pomocą wbudowanego w rachunku (system) lub tworząc dziesiątki użytkowników accross kilkudziesięciu bazie danych i udzielanie bezpośrednio dziesiątki uprawnieniami do siebie. W moim umyśle tylko pozwalając login deweloperów jako system sprawia, że ​​wiele sensu, ale nasze DBA twierdzą, że to zły pomysł.

Utwórz 17/09/2009 o 23:03
źródło użytkownik
W innych językach...                            


7 odpowiedzi

głosy
0

Jednym z zadań DBA jest zarządzanie uprawnieniami użytkowników. Nie sądzę, że system jest dobry pomysł z kilku powodów, nie najmniej jest zdolność do spadku całego schematu, który jestem pewien, że nie chcesz. Mimo to, myślę, że to jest w porządku, aby przyznać wszystkim do użytkowników i pozwolić administratorom zarządzać tych uprawnień nie ma znaczenia ile dziesiątki kont może istnieć. Większość DBA będzie miał skrypty mogą wykorzystać do zarządzania tymi uprawnieniami tak.

Słuchaj swoich administratorów, na ogół wiedzą, co mówią.

Odpowiedział 17/09/2009 o 23:16
źródło użytkownik

głosy
0

Jeśli jest to tylko przykład dev; Chciałbym mieć wszyscy użytkownicy mają indywidualnych kont dodanych do roli administratora. W ten sposób można nadal aktywność logowania na poszczególnych użytkowników; ale dać deweloperów wystarczająco dużo miejsca do oddychania robić swoje rzeczy.

Odpowiedział 17/09/2009 o 23:17
źródło użytkownik

głosy
1

Zakładam, że istnieje stosunkowo niewielka liczba aplikacji, które są właścicielami kont rzeczywistych obiektów. Tak więc jeden lub więcej logicznych wniosków składają tablic posiadanych przez danego użytkownika Oracle. To nie przez system lub SYS, nie byłoby żadnego z kont, które Oracle Firma dostarcza. Byłoby konto, że DBA utworzony. Jeśli jesteś zaznajomiony z przykładowych schematów Oracle, użytkownik HR posiada wszystkie tabele w schemacie HR, które składają się na tylny koniec dla aplikacji HR.

Począwszy od zasady „najprostszą rzeczą, która mogłaby pracować”, moja pierwsza myśl byłoby sprawdzić, czy deweloperzy mogli zalogować się bezpośrednio do tych kont aplikacyjnych. To nie jest najbezpieczniejszym z możliwych konfiguracji, i otwierają się możliwości, że deweloper przypadkowo lub celowo robi pewne uszkodzenia, które mogą być trudne do śledzenia lub łatwo rozwiązać. Ale to może działać całkiem dobrze w zależności od organizacji. zarządzanie Privilege jest trivial-- konta właściciela aplikacja już posiada wszystkie przywileje potrzebuje najbardziej prawdopodobne.

Następnym krokiem będzie dając każdy deweloper oddzielny schemat rozwijać się, przypuszczalnie w związku z obciążeniem synonimy publicznych w bazie danych i braku kwalifikatorów schematu w kodzie aplikacji, tak, że każdy obiekt utworzony w schemacie dewelopera automatycznie nadpisuje wspólna wersja tego obiektu. To zapewnia znacznie lepszą izolację. Uprawnienia są zazwyczaj udzielane poprzez stworzenie skryptów które zawierają wszystkie dotacje deweloper potrzebuje lub tworząc skrypt, który kopiuje wszystkie przywileje od „znanego dobrego” konta do nowego konta. Nie jest szczególnie trudne do write-- po prostu trzeba się upewnić, że wszyscy deweloperzy skończyć z tym samym zestawem przywilejów, która jest na ogół po prostu inny skrypt, który pobiera uruchomić, gdy nowy przywilej jest przyznawana.

Odpowiedział 17/09/2009 o 23:28
źródło użytkownik

głosy
0

Moja grupa obsługuje około 100 aplikacji z około 20 z nich posiadania własnego schematu Oracle. Mamy już na dół droga każdego dewelopera ma hasło do schematu i jest to wygodne. Jednak z perspektywy czasu Polecam że każdy programista używać własnego konta Oracle rozwijać. Głównym powodem jest audyt.

Odpowiedział 18/09/2009 o 00:09
źródło użytkownik

głosy
0

Uznaję, że najlepszym wypadku byłoby mieć każdy dev uruchomić własną instancję na swoim stanowisku pracy na rzecz rozwoju, ale ze względu na wielkość bazy danych nie zostało to uznane za opcję.

Czy istnieje sposób, aby sobie z tym poradzić, może poprzez zmniejszenie ilości danych w osobistych kopii? Wydaje się to idealne rozwiązanie, ponieważ to pozwala wprowadzać żadnych zmian, których potrzebujesz. Następnie można przesłać je do DBA, kiedy jesteś gotowy, i mają go zaktualizować wspólny serwer deweloperski.

Odpowiedział 18/09/2009 o 00:17
źródło użytkownik

głosy
1

Jeśli tworzysz obiekty przechowywane PL / SQL, a następnie schemat posiadanie tych przedmiotów musi, jak wspomniano, jawne dotacje na obiekty wykorzystywane. Jeśli masz jednego schematu „dane”, ale rozwijają się kod do własnych indywidualnych schematów następnie należy uzyskać możliwość udzielenia dostępu na obiektach schematu dane do schematów rozwojowych. Normalnie bym oczekiwać login / hasło do schematu danych.

W odniesieniu do przywilejów systemowych (np utworzyć), będę oczekiwać CREATE TABLE, typ, widok, postępowanie spust, synonim. Inni mogą być odpowiednie (np kontekstu) w zależności od tego, co robisz. DBA może wykluczyć utworzyć katalogu jako że może być szkodliwe, jeśli wykorzystane mis. Ditto dla przywilejów z którymkolwiek z nich (na przykład SELECT dowolnej tabeli, usunąć wszelkie tabela)

Do monitorowania wydajności strojenie / systemu, na bazie dev SELECT_CATALOG_ROLE jest dobra. Jeśli DBA jest boi się ryzyka, być może trzeba będzie negocjować dotacje na poszczególnych widokach. Przejdź przez przewodnika odniesienia dla swojej wersji i poprosić o każdy może skorzystać.

Odpowiedział 18/09/2009 o 00:17
źródło użytkownik

głosy
3

Użyliśmy po prostu dać deweloperom dostęp do rachunku aplikacji. To działa dla małych sklepów, ale szybko wymknie się spod kontroli, ponieważ liczba programistów wzrośnie.

Oto co możemy teraz zrobić:

  1. Aplikacja posiada swój własny rachunek (schemat aka).
  2. Deweloperzy mają własne konta
  3. Dane znajdują się w schemacie aplikacji
  4. Mamy ant build skrypt do budowania kod w schema 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łasnym schemacie
  6. Kiedy szczęśliwy oni sprawdzić, do wywrotowej
  7. Schemat dev Aplikacja zbudowana jest z nowego subversion kompilacji.
  8. Programiści mogą sprawdzić i odbudować własne środowisko.
  9. DDL do zmiany struktury tabeli są wykonywane przez DBA
    • można je także skryptów

Ma to tę zaletę zapewnienia każda aplikacja Zaczepy nie jest uszkodzony przez programistów baz danych stale przebudowy wszystko.

Odpowiedział 18/09/2009 o 17:42
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more