Bezpieczeństwo dla programistów aplikacji wykonujących PL / SQL w Oracle

13

Jak poradzić sobie z brakiem uprawnień na poziomie schematu w Oracle? Architektura bezpieczeństwa Oracle działa dobrze w przypadku aplikacji, które potrzebują tylko uprawnień na poziomie obiektu, i działa dobrze w przypadku DBA, które wymagają kilku ograniczeń. Wydaje się jednak, że istnieje duża luka w architekturze dla programistów wykonujących programowanie z aplikacją front-end i PL / SQL w wielu schematach. Oto niektóre z moich opcji z ich wadami:

  1. Niech każdy programista wykona programowanie we własnym schemacie. DBA przyznaje uprawnienia na poziomie obiektowym potrzebującym ich programistom. Opracowanie każdego pakietu musi być wykonane przez DBA. Główną wadą jest to, że programiści będą korzystać z bazy danych jak trochę wiadra ze szkodą dla wydajności bazy danych. Chcę, aby programiści rozwijali się w bazie danych, ale ta metoda bardzo by go zniechęciła.

  2. Daj każdemu programiście nazwę użytkownika / hasło do kilkunastu schematów, w których trzeba wykonać programowanie. Przyznaj uprawnienie schematu aplikacji do tworzenia procedur, tabel itp. Niektóre z wad tego podejścia polegają na tym, że programiści muszą utrzymywać wiele loginów i są rzadko zalogowani jako sami. Trudne jest także tworzenie schematów krzyżowych.

  3. Przyznaj programistom uprawnienia do uwierzytelniania proxy na każdym schemacie, dla którego muszą oni opracowywać. Dzięki temu są zalogowani jako sami, bez konieczności nadawania im uprawnień innych niż uprawnienia proxy. Wady polegają na tym, że programiści muszą utrzymywać osobne połączenia dla każdego schematu, dla którego są proxy, tworzenie schematów krzyżowych jest bardziej kłopotliwe, ponieważ połączenia muszą być ciągle zmieniane, a pakiety korzystające z łączy publicznych baz danych z przekazanym uwierzytelnieniem nie kompilują się w połączeniach proxy.

  4. Nadaj każdemu programistowi uprawnienia DBA. - Minusem tutaj jest bezpieczeństwo. Żaden programista schematu nie może być trzymany poza jakimkolwiek schematem, a każdy programista może podszyć się pod dowolnego innego programistę (DBA).

Wydaje się, że brakuje opcji przyznania każdemu programatorowi SELECT / INSERT / CREATE / etc. uprawnienia do schematu, w którym muszą się rozwijać. Logują się, aby wykonywać swoją pracę przy użyciu jednego połączenia. Nowe obiekty w schemacie, do których mają dostęp, są natychmiast dostępne.

Czy coś brakuje? Jak radzisz sobie z programistami aplikacji, które zajmują się tworzeniem PL / SQL?

Leigh Riffel
źródło
3
+1 świetne pytanie - w połączeniu z brakiem zintegrowanej kontroli źródła, jest to poważny problem z Oracle w środowisku wielu programistów.
ScottCher,

Odpowiedzi:

11

W czasach, gdy pracowałem w sklepie Oracle, mieliśmy konkretny serwer „deweloperski” (programistyczny), który podlegał innym ograniczeniom bezpieczeństwa niż serwer „produkcyjny”. Programiści mogli zrobić wszystko, czego potrzebowali, a następnie przekazaliśmy niezbędne skrypty do DBA, aby zastosować się do serwera produkcyjnego.

W przypadku naszych krytycznych systemów (SCT Banner, do śledzenia zajęć i studentów oraz Oracle Financials) istniały również serwery „testowe” i „seedowe”. Test polegał na testowaniu akceptacji użytkownika przed przeniesieniem rzeczy z dewelopera do prod; „seed” to standardowa instalacja oprogramowania, więc jeśli znajdziemy błąd, możemy zweryfikować, czy jest to coś, co wprowadziliśmy, czy też pochodziło z oprogramowania SCT lub Oracle.

Joe
źródło
+1 Dzięki naszej bazie danych ogólnego użytku programiści pracują nad bardzo różnorodnymi projektami, więc zasada najmniejszych uprawnień nie dawałaby im pełnego dostępu nawet do serwera programistycznego. ( en.wikipedia.org/wiki/Principle_of_least_privilege )
Leigh Riffel
@Leigh - prawdopodobnie powinienem był wyjaśnić ... serwer deweloperów w większości wypadł poniżej tego, co miałeś jako nr 1, a nie # 4
Joe
1
Pamiętam, że bazy danych DEV zostały sklonowane z Production, a następnie skomplikowane granty, aby umożliwić programistom pracę bez ograniczeń. Ostatecznie łatwiej było dać każdemu deweloperowi własną bazę danych i dostęp do DBA. Następnie wprowadzałby zmiany do Dev w cyklu wydawniczym. Teraz powinno być łatwiejsze dzięki wirtualizacji.
Sumnibot,
@ Sumumbot - Łatwiejsze instalowanie utrzymywania, tworzenia kopii zapasowych itp. Oddzielnej bazy danych dla każdego programisty niż udzielanie im uprawnień!?! Oprócz czasu potrzebnego na aktualizację każdego z nich wydaje się, że koszty licencji byłyby znaczne, czy też nie dostałeś wersji Enterprise?
Leigh Riffel
1
Nie zawiera dla mnie konkretnej odpowiedzi.
Michael-O,
3

Użyj ról, aby powiązać kolekcje obiektów, a następnie przyznaj dostęp do ról

Instrukcja GRANT pozwala DBA na:

Uprawnienia do obiektu dla określonego obiektu dla użytkowników, ról i PUBLIC. Tabela 18-2 zawiera listę uprawnień do obiektów i operacji, które autoryzują.

Ponieważ do roli można nadać uprawnienia do obiektu, stosunkowo łatwo jest przyznać dostęp do roli do wszystkich tabel w schemacie:

sql> spool privs.sql
sql> wybierz „grant select on scott.” || table_name || ” to role_select; ' z dba_tables gdzie właściciel = 'SCOTT';
sql> @ privs.sql
sql> grant role_select John, Sam, Peter;

W połączeniu z GRANT CREATE TABLEwydanym przez odpowiedniego użytkownika schematu rolą oznacza to, że programiści mogą wybierać i tworzyć tabele. Nie jest idealny, ponieważ utworzona tabela wymaga ponownego uruchomienia skryptu, ale WITH GRANT OPTIONsugeruje, że każdy programista może następnie udzielić dostępu do utworzonej tabeli do odpowiedniej roli.

Sugeruje to , że można utworzyć wyzwalacze poziomu DDL, które mogą wykonać odpowiedni proces przyznawania uprawnień, chociaż oczywiście konieczne będą znaczne ilości testów, powinna istnieć możliwość automatycznego tworzenia instrukcji tworzenia tabeli odpowiednich uprawnień do odpowiednich ról.

Edytować --

Według DOTACJI Z CREATE TABLEprzywileju:

Utwórz tabelę w schemacie beneficjenta.

Tak więc, dając im możliwość utworzenia tabeli, zmiany tabeli itp. Od właściwego użytkownika, powinni oni mieć dostęp do schematu tego użytkownika, tak jakby był on odpowiednim użytkownikiem.

Brian Ballsun-Stanton
źródło
Widziałem metodologię, do której się odwołujesz, bez większego powodzenia; jednak uważam, że masz rację, że można tego dokonać za pomocą obszernych testów. Problem polega na tym, że pozwala to programistom tylko na dostęp do tabel. Przyznanie tworzenia tabeli bezpośrednio lub poprzez rolę daje im jedynie uprawnienia do tworzenia tabeli na ich własnym schemacie. Nadal nie mogą tworzyć tabel, procedur, pakietów, wyzwalaczy ani żadnych innych obiektów w żadnym schemacie oprócz własnego, czy masz na myśli, że powinni tworzyć obiekty we własnym schemacie nawet podczas programowania?
Leigh Riffel,
@Leigh Zaktualizowano ze szczegółami.
Brian Ballsun-Stanton
To nie tak działa Oracle. Spróbuj tego: utwórz użytkownika u1 identyfikowanego przez „ThisIsMy1Password”; utwórz użytkownika u2 identyfikowanego przez „ThisIsMy1Password”; przyznać dba do u1; przyznaj połączenie z u2; podłącz u1 / „ThisIsMy1Password” @db; utwórz tabelę u2; podłącz u2 / „ThisIsMy1Password” @db; utwórz tabelę u1.t1 (c1 varchar2 (10)); Ostatni krok kończy się niepowodzeniem z powodu niewystarczających uprawnień.
Leigh Riffel