Czy moja baza danych Oracle DBA wymaga dostępu do konta root?

14

Mój kolega z bazy danych Oracle DBA prosi o dostęp do konta root na naszych serwerach produkcyjnych .
Twierdzi, że potrzebuje go do wykonania niektórych operacji, takich jak ponowne uruchomienie serwera i kilka innych zadań.

Nie zgadzam się z nim, ponieważ ustawiłem mu użytkownika / grupę Oracle i grupę dba, do której należy użytkownik Oracle. Wszystko działa płynnie i bez dostępu administratora do bazy danych DBA.
Myślę również, że wszystkie zadania administracyjne, takie jak zaplanowane ponowne uruchomienie serwera, muszą być wykonane przez właściwego administratora (w naszym przypadku administratora Systemu), aby uniknąć jakichkolwiek problemów związanych z niezrozumieniem interakcji infrastruktury.

Chciałbym uzyskać dane wejściowe od sysadminów i Oracle DBA - czy istnieje jakiś dobry powód, aby Oracle DBA miał dostęp do roota w środowisku produkcyjnym ?

Jeśli mój kolega naprawdę potrzebuje tego poziomu dostępu, zapewnię go, ale boję się tego ze względu na bezpieczeństwo i integralność systemu.

Nie szukam zalet / wad, ale raczej porady dotyczące tego, jak powinienem poradzić sobie z tą sytuacją.

Dr I.
źródło
12
Poproś o listę poleceń, których potrzebuje, a następnie dostosuj plik sudoers, aby zezwalał tylko na te polecenia.
dmourati,
Powiedziałbym, że przejście sudoers, jak sugerowano powyżej, jest wyraźnie właściwą drogą.
Sami Laine,
Nie będę używać sudo, jest to serwer z ograniczonym dostępem i kontrolowanym wrażliwym serwerem, zrobię to na poważnie, używając POSIX Rights i Chrooted / limited shell.
Dr I
Jako sysadmin IMHO zawsze wybieram sudoers i ograniczam dostęp w miarę możliwości. Lepiej zacząć od absolutnego minimum, a następnie dodawać stopniowo dostęp do poleceń w razie potrzeby. +1 @dmourati
sgtbeano
7
Twoje DBA potrzebuje hasła roota tak bardzo, jak potrzebujesz SYSDBAdostępu.
Michael Hampton

Odpowiedzi:

14
  • Kto instaluje Oracle na serwerach?
    Jeśli jest to DBA, potrzebują dostępu do konta root. Jeśli jest to sysadmin, DBA nie.

  • Kto dzwoni późno w nocy, gdy serwer bazy danych jest wyłączony?
    Jeśli nie możesz zapewnić, że sysadmins są dostępni 24 godziny na dobę, 7 dni w tygodniu, możesz chcieć dać rootowi dostęp do DBA.

Pamiętaj, że jeśli Twój DBA ma już dostęp do powłoki jako zwykły użytkownik (z niektórymi komendami lub bez nich, może uruchamiać się przez sudo; z chrooterem lub bez niego) wystarczy, aby zadzierać z serwerem (zły facet kradnący jego konto może rozwalić bombę , przekraczaj ulimit wysyłając spam, upuść bazę danych, ...).

Z tych wszystkich powodów uważam, że w idealnym świecie DBA nie powinny mieć dostępu do roota ; ale w prawdziwym świecie powinni przynajmniej móc je uzyskać w nagłych przypadkach.

voretaq7
źródło
3
możesz używać sudoi stosować poprawne reguły sudo zamiast dawać dostęp do roota.
jirib
3
@Jiri: Posiadanie czegoś takiego jak% dba ALL = (ALL) ALL w / etc / sudoers daje dostęp do roota. Listę ograniczonego zestawu poleceń dla dba nazywam „regularnym dostępem do powłoki”.
2
Doker Oracle + brzmi jak przepis na katastrofę. Sudo nie jest dozwolone? Wygląda na to, że ktokolwiek ogranicza środowisko, nie ma pojęcia, co robią.
dmourati
4
@DrI Usuwanie sudoi zapewnianie ludziom nieograniczonego dostępu do roota jest dość znaczącym krokiem WSTECZ w zakresie bezpieczeństwa systemu. Będę szczery, jeśli twoje szefowe rzeczy sudoto „ezoteryczna technologia”, są idiotami.
voretaq7
1
@ voretaq7 Wiem o tym, ale jak już powiedziałem, pracuję dla dużej korporacji, a nie dla siebie, więc nie zajmuję się każdym aspektem naszego IT i muszę radzić sobie z moimi narzędziami ;-) Moje główne pytanie było powiązane do POTRZEB, aby DBA miał dostęp do roota, a większość ludzi uważa, że ​​jest odwrotnie, więc zbadam jeszcze jego potrzeby ;-), a następnie zajmę się nim w przypadku kompromisowej sytuacji.
Dr I
6

Zasadniczo - i nie dotyczy to DBA - każdy, kto żąda rootdostępu bez podania ważnego powodu, to:

  1. Ktoś, kto nie wie, co robią.
  2. Arogancki i niechętny do współpracy.
  3. Oba powyższe.

Teraz mogą istnieć prawdziwe powody, dla których potrzebują rootdostępu do wykonania zadania, ale znowu, jeśli nie potrafią wyjaśnić, dlaczego i napisać to na piśmie, nie poradziłbym sobie z nimi. Specjaliści zajmujący się serwerami rozumieją i szanują granice. Gorące ujęcia, które wiedzą wystarczająco dużo, aby wpaść w kłopoty, uważają, że zasady dotyczą wszystkich oprócz nich.

W przypadkach, w których musiałem zmagać się z takimi ludźmi, nalegałem, aby zaplanować czas z wyprzedzeniem, abym mógł być z nimi na serwerze, aby zająć się problemami, gdy tylko się pojawią. I to naprawdę działało dobrze.

Inną alternatywą - która może nie być praktyczna - jest stworzenie dokładnego klonu danego serwera i udzielenie mu rootdostępu do tego. Oczywiście pamiętaj, aby zmienić hasło na coś konkretnego. Pozwól im wysadzić pojedyncze pudełko rozwoju.

Ale ogólnie rzecz biorąc, jeśli to ty zostaniesz wezwany późno w nocy, aby posprzątać bałagan, który ten facet może stworzyć, masz pełne prawo odmówić przyjęcia prośby o rootdostęp.

JakeGould
źródło
4

Teoretycznie DBA mogą działać bez uprawnień roota, ale jest to PITA dla obu stron. Praktycznie niemożliwe jest zdefiniowanie listy poleceń dostępnych za pośrednictwem sudo.

Podaj uprawnienia administratora root DBA, jeśli:

  • nie chcesz budzić się w środku nocy, wystarczy zrestartować serwer
  • chcesz szybkiego i sprawnego zarządzania incydentami
  • jeśli twój serwer dedykowany jest tylko dla serwera DB

DBA zwykle potrzebują uprawnień roota do: regulacji parametrów jądra (sysctl), manipulacji pamięcią, badania problemów.

Odpowiednie przesłuchanie zapewnia lepsze warunki pracy niż ściśle określone reguły bezpieczeństwa. Jeśli masz wdrożony audyt, zawsze możesz zapytać, dlaczego coś zmienił / zmienił. Jeśli nie masz audytu, i tak nie masz zabezpieczeń.

EDYTOWANE

To jest lista typowych wymagań Oracle dla autonomicznych (instalacji nieklastrowanych)

  • Parametry jądra

    • Związane z pamięcią (konfiguracja dużych / dużych stron, współużytkowana pamięć RAM (ipcs), niewymienna (zablokowana) pamięć RAM)
    • związane z sieciami (rozmiar okna wysyłania / odbierania, zachowanie TCP)
    • związane z pamięcią masową (liczba otwartych plików, asynchroniczne operacje we / wy)

    Może być około 15-20 parametrów sysctl. Dla każdego z nich Oracle podaje zalecaną wartość lub równanie. W przypadku niektórych parametrów zalecane równanie może się zmieniać w czasie (aync io) lub w niektórych przypadkach Oracle dostarczyło więcej niż jedno równanie dla tego samego parametru.

  • Pamięć: reguły udev w systemie Linux nie gwarantują trwałych nazw urządzeń podczas rozruchu. Dlatego Oracle dostarczył sterownik jądra i narzędzia (AsmLib). Umożliwiają one „etykietowanie” partycji fizycznych jako root, a następnie wyświetlanie tych etykiet podczas administrowania pamięcią bazy danych
  • Badanie problemu:
    • Gdy baza danych ulega awarii, ponieważ nie można otworzyć więcej uchwytów plików, jedynym rozwiązaniem jest zwiększenie limitu jądra, wykonanie polecenia „sysctl -p”, a następnie uruchomienie bazy danych.
    • Również, gdy okaże się, że fizyczna pamięć RAM jest zbyt podzielona i baza danych nie może przydzielić dużych stron, jedyną opcją jest ponowne uruchomienie serwera.
    • (DCD) - wykrywanie martwego połączenia. Na przykład w systemie AIX netstat nie drukuje PID. Jedynym sposobem sparowania połączenia TCP z PID jest debuger jądra.
    • rzut oka (coś takiego jak top w HP-UX) wymaga uprawnień roota
    • różne dochodzenia na poziomie Veritas
    • i wiele innych

Od Ciebie zależy, ile czasu „zmarnujesz”, aż problem zostanie rozwiązany. Chciałem tylko zauważyć, że silna separacja ról może być bardzo kosztowna w niektórych przypadkach. Zamiast zwiększać „bezpieczeństwo”, skup się na zmniejszeniu ryzyka i niebezpieczeństw. Co nie jest takie samo. Narzędzia takie jak ttysnoop lub spy spy pozwalają „nagrywać” całą sesję ssh, dzięki czemu zapewniają niezaprzeczalność. Może to służyć lepiej niż sudo.

ibre5041
źródło
4
Nie jest rolą DBA ponowne uruchamianie serwerów produkcyjnych, poprawianie parametrów jądra serwera produkcyjnego, manipulowanie pamięcią serwera produkcyjnego itp. Jego rolą jest określenie, w jaki sposób serwer konfiguracyjny powinien zostać skonfigurowany, i pozwolenie sysadmins na wdrożenie. Zarządzanie incydentami, które ma wpływ na serwer produkcyjny, zawsze należy kierować do sysadmin, a nie do dba.
Stephane
6
@Stephane W idealnym świecie tak, role wszystkich są jasno określone. Ale w wielu przypadkach tak nie jest. W przypadku pracy DBA zgodnie z opisem może być tak, że ten DBA jest wynajmowany w celu ulepszenia wydajności na poziomie serwera. Spójrzmy prawdzie w oczy: nie wszyscy administratorzy rozumieją optymalizacje konfiguracji dla wszystkich kontrolowanych aplikacji. Ale nadal to, co źle mnie ociera, to pragnienie DBA dostępu bez szczegółów. Ogromna czerwona flaga w mojej książce.
JakeGould
2
@Stephane Oracle jest w tym przypadku bardzo specyficzny. Jego wymagania dotyczące strojenia plików jądra mogą być nietrywialne, ma swój własny LVM (zwany ASM), a ponadto w przypadku Oracle RAC niektóre z jego procesów CLusterwares działają z uprawnieniami roota, a także manipuluje pamięcią masową i kartami sieciowymi. Czasami łatwiej jest pozwolić DBA wykonać vxdisk resizepolecenie, a potem zagrać w ping-ponga przez e-mail w środku nocy. Chodzi bardziej o zaufanie i audyt, niż o „bezpieczeństwo”.
ibre5041
Oracle jest parującym stosem. Najlepsze dostępne dokumenty to: puschitz.com
dmourati
1
Jeśli poprawiają określone rzeczy w celu naprawienia lub poprawy określonych problemów, powinni przetestować / zweryfikować je w środowisku deweloperskim (i dobrze, dajcie im zrootować), a następnie przekazać instrukcje zespołowi sysadmin / ops na temat tego, co dokładnie należy zrobić do środowiska na żywo, aby wprowadzić te zmiany po ich przetestowaniu. A jeśli oni nie robią to, a zamiast tego po prostu zabawy z ustawieniami, dopóki nie działa wtedy nikt nie powinien tego robić na środowisku żywych anyway .
Rob Moir
1

Jestem Oracle DBA i moja odpowiedź brzmi: zwykle DBA nie potrzebuje dostępu do roota. Ale RAC DBA? zdecydowanie potrzebuje dostępu do katalogu głównego, aby zarządzać CRS, utrzymywaniem domu i wszystkim.

Mohamed Amjad
źródło
0

Pytanie to wywodzi się z czasów, gdy systemy były znacznie prostsze, a procesy OS w porównaniu z bazami danych były oddzielnie definiowane i identyfikowalne. Administracja systemem i administracja bazami danych Obowiązki i obowiązki były bardzo różne. W dzisiejszych środowiskach informatycznych, aw szczególności w dzisiejszych serwerach baz danych, te obowiązki i obowiązki najczęściej się pokrywają. Administrator systemu dokłada należytej staranności, aby ograniczyć dostęp „root” w odniesieniu do „zarządzania ryzykiem”.

Przy dzisiejszych wymaganiach dotyczących „wysokiej dostępności” i „natychmiastowej naprawy” problemów z naszymi systemami baz danych RAC, administratorzy systemów i administratorzy baz danych obsługują funkcjonalne społeczności biznesowe, współpracując ze sobą jako zespół. „Zaufanie” nie powinno budzić żadnych obaw, ponieważ obie strony są żywotnie zainteresowane utrzymywaniem serwerów baz danych RAC online przez prawie 100% czasu. Należy pamiętać, że DBA ma już dostęp do powłoki jako Administrator bazy danych (z niektórymi poleceniami lub bez nich może uruchamiać się przez sudo; z chrootowaniem lub bez), więc DBA jest „zaufanym” agentem. Tak więc w rzeczywistości pytanie powinno brzmieć: „Dlaczego baza danych Oracle DBA nie potrzebuje dostępu?”

Dzisiejsze DBA przejęło dodatkową odpowiedzialność za serwer bazy danych, gdzie serwer bazy danych jest członkiem Oracle Real Application Cluster (RAC) i wykorzystuje Oracle Automatic Storage Management (ASMLIB) do prezentacji współdzielonej pamięci w bazach danych RAC. Zarządzanie RAC i ASM przez DBA odciąża już przepracowanego Administratora Systemu, co powinno być mile widzianym wkładem w Grupę / Zespół STS.

I, jak stwierdził ibre5043, „... silna separacja ról może być bardzo kosztowna w niektórych przypadkach. Więc zamiast zwiększania„ bezpieczeństwa ”skup się na zmniejszeniu ryzyka i niebezpieczeństw. To nie to samo. Narzędzia takie jak ttysnoop lub spy spy pozwalają ci „nagrywać” całą sesję ssh, dzięki czemu zapewniają niezaprzeczalność. Może to służyć lepiej niż sudo. ” Powinieneś również zapytać, kto monitoruje SSA.

Gary Cates
źródło
0

Jeśli serwery używają oprogramowania Oracle Grid Infrastructure, takiego jak CRS, RAC lub Oracle Restart, wówczas wiele krytycznych usług baz danych działa jako root, a wiele krytycznych plików konfiguracyjnych bazy danych jest własnością root. Jest to nieodłączna cecha projektowa oprogramowania. Jeśli jest to naruszenie twoich zasad, należy je zmienić.

DBA będzie wymagał dostępu do konta root w celu administrowania tymi funkcjami. Teoretycznie możesz poprosić go o listę poleceń, których wykonania będzie oczekiwał w Sudo, ale odpowiedź będzie bardzo długa. Wystarczy zajrzeć do $ GRID_HOME / bin, aby zobaczyć listę wszystkich plików binarnych, których DBA może używać regularnie. Jeśli wykonują czynności związane z łataniem (które powinny być), lista może się wydłużyć.

Andrew Brennan
źródło
0

Właśnie zadałem podobne pytanie. W rzeczywistości powodem, dla którego sysadmin nie chce nadawać uprawnień roota, jest odpowiedzialność i odpowiedzialność.

Ale jeśli jest to przyczyną, DBA powinien być również jedynym sysadminem. Powód jest prosty. Jeśli zachodzi potrzeba oddzielenia odpowiedzialności i odpowiedzialności, sysadmin ZAWSZE może być DBA. Może podszyć się pod konto Oracle, może wejść do bazy danych jako SYSDBA i robić cokolwiek, bez potrzeby podawania hasła SYS lub SYSTEM.

Więc moim zdaniem, jeśli istnieje potrzeba oddzielenia sysadminów i DBA, ze względu na odpowiedzialność i odpowiedzialność, jedyną logiczną przyczyną jest to, że serwer powinien być również zarządzany przez DBA, a nie sysadmin. Serwer i baza danych powinny być w całości odpowiedzialne za DBA, który również powinien mieć trochę wiedzy na temat administrowania systemem.

Jeśli serwer jest używany nie tylko do przechowywania bazy danych, a istnieje potrzeba oddzielnej odpowiedzialności i odpowiedzialności, oznacza to kłopoty. Ale jeśli serwer jest używany tylko do hostowania bazy danych, nie widzę powodu, dla którego DBA nie miałaby uprawnień administratora, biorąc pod uwagę niezliczone przypadki, których również potrzebowałby.

Osobiście postawiłbym pytanie na odwrót. Dlaczego sysadmin ma uprawnienia roota na dedykowanym serwerze bazy danych? W rzeczywistości jego specjalność byłaby wymagana w znacznie mniejszej liczbie przypadków niż specjalizacja DBA (z uprawnieniami roota).

Savvas
źródło
0

Dostęp root jest wymagany do instalacji i łatania Oracle grid. Nie można tego obejść. Gdyby istniał sposób na udzielenie tymczasowego dostępu roota do DBA dla takich potrzeb, byłoby to idealne.

David M. Skibinski
źródło