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ą.
SYSDBA
dostępu.Odpowiedzi:
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.
źródło
sudo
i stosować poprawne reguły sudo zamiast dawać dostęp do roota.sudo
i 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 rzeczysudo
to „ezoteryczna technologia”, są idiotami.Zasadniczo - i nie dotyczy to DBA - każdy, kto żąda
root
dostępu bez podania ważnego powodu, to:Teraz mogą istnieć prawdziwe powody, dla których potrzebują
root
dostę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
root
dostę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
root
dostęp.źródło
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:
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
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.
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.
źródło
vxdisk resize
polecenie, a potem zagrać w ping-ponga przez e-mail w środku nocy. Chodzi bardziej o zaufanie i audyt, niż o „bezpieczeństwo”.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.
źródło
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.
źródło
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ć.
źródło
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).
źródło
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.
źródło