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

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?

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.

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.