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

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ą.

• 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.

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.

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.

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.

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.

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ć.

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).

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.