Benötigt mein Oracle-DBA Root-Zugriff?

Lösung 1:

• Wer installiert Oracle auf den Servern?
  Wenn es der DBA ist, benötigen sie Root-Zugriff. Wenn es der Systemadministrator ist, tut es der DBA nicht.

• Wer wird nachts angerufen, wenn der Datenbankserver ausgefallen ist?
  Wenn Sie nicht sicherstellen können, dass Systemadministratoren rund um die Uhr verfügbar sind, sollten Sie dem DBA Root-Zugriff gewähren.

Denken Sie daran, dass, wenn Ihr DBA bereits als normaler Benutzer Shell-Zugriff hat (mit oder ohne einige Befehle, die er über sudo ausführen kann; mit oder ohne Chrooting), das ausreicht, um sich mit dem Server herumzuschlagen (ein Bösewicht, der sein Konto stiehlt, kann eine Gabelbombe , Ulimit überschreiten, Spam senden, Datenbank löschen, ...).

Aus all diesen Gründen denke ich, in einer idealen Welt sollten DBAs keinen Root-Zugriff haben; aber in der realen Welt sollten sie es im Notfall zumindest immer bekommen können.

Lösung 2:

Im Allgemeinen – und nicht spezifisch für DBAs – jeder, der root fordert Zugriff ohne triftigen Grund ist entweder:

1. Jemand, der nicht weiß, was er tut.
2. Arrogant und unkooperativ.
3. Beides.

Nun, es könnte echte Gründe geben, warum sie root benötigen Zugang haben, um ihre Aufgabe zu erledigen, aber wenn sie nicht erklären können, warum und es schriftlich niederlegen können, würde ich mich nicht mit ihnen befassen. Profis, die mit Servern zu tun haben, verstehen und respektieren Grenzen. Hot Shots, die genug wissen, um in Schwierigkeiten zu geraten, glauben, dass die Regeln für alle außer ihnen gelten.

In Fällen, in denen ich mich mit solchen Leuten herumschlagen musste, habe ich darauf bestanden, dass die Zeit im Voraus geplant wird, damit ich mit ihnen auf dem Server sein kann, um Probleme zu lösen, sobald sie auftreten. Und das hat tatsächlich gut funktioniert.

Eine andere Alternative – die möglicherweise nicht praktikabel ist – besteht darin, einen exakten Klon des betreffenden Servers zu erstellen und ihnen root zu geben darauf zugreifen. Stellen Sie sicher, dass Sie das Passwort natürlich in ein spezifisches Passwort ändern. Lassen Sie sie eine isolierte Entwicklungsbox in die Luft jagen.

Aber im Allgemeinen, wenn Sie derjenige sind, der spät in der Nacht angerufen wird, um ein Chaos zu beseitigen, das dieser Typ anrichten könnte, dann haben Sie jedes Recht, eine pauschale Anfrage für root abzulehnen Zugriff.

Lösung 3:

Theoretisch können DBAs ohne Root-Privilegien arbeiten, aber es ist PITA für beide Seiten. Es ist praktisch unmöglich, eine Befehlsliste so zu definieren, dass sie über sudo zugänglich ist .

Geben Sie DBAs Root-Privilegien, wenn:

• Sie möchten nicht mitten in der Nacht geweckt werden, nur um den Server neu zu starten
• Sie möchten ein schnelles und reibungsloses Vorfallmanagement
• wenn Ihr Server nur für DB Server dediziert ist

DBAs benötigen normalerweise Root-Privilegien für:Kernel-Parameteranpassungen (sysctl), Speichermanipulation, Problemuntersuchung.

Korrektes Auditing sorgt für bessere Laufbedingungen als streng definierte Sicherheitsregeln. Wenn Sie Auditing implementiert haben, können Sie immer fragen, warum sie etwas getan/geändert haben. Wenn Sie kein Auditing haben, haben Sie sowieso keine Sicherheit.

BEARBEITET

Dies ist eine Liste allgemeiner Oracle-Anforderungen für Standalone-Installationen (nicht geclusterte Installationen)

• Kernel-Parameter

  • Speicherbezogen (Konfiguration großer/riesiger Seiten, gemeinsam genutzter RAM (ipcs), nicht austauschbarer (gesperrter) RAM)
  • netzwerkbezogen (Sende-/Empfangsfenstergröße, TCP keepalive)
  • speicherbezogen (Anzahl geöffneter Dateien, asynchrone E/A)

  Es könnte etwa 15-20 sysctl-Parameter geben. Für jeden von ihnen stellt Oracle einen empfohlenen Wert oder eine Gleichung bereit. Für einige Parameter kann sich die empfohlene Gleichung im Laufe der Zeit ändern (aync io) oder in einigen Fällen hat Oracle mehr als eine Gleichung für denselben Parameter bereitgestellt.

• Storage:Linux udev-Regeln garantieren keine persistenten Boot-Gerätenamen. Daher hat Oracle Kerneltreiber und Tools (AsmLib) bereitgestellt. Diese ermöglichen es Ihnen, physische Partitionen als root zu „kennzeichnen“, und dann können Sie diese Kennzeichnungen sehen, wenn Sie den Datenbankspeicher verwalten
• Problemuntersuchung:
  • Wenn die Datenbank abstürzt, weil sie keine weiteren Dateihandles öffnen kann, besteht die einzige Lösung darin, das Kernel-Limit zu erhöhen, 'sysctl -p' auszuführen und dann die DB zu starten.
  • Auch wenn Sie feststellen, dass der physische Arbeitsspeicher zu fragmentiert ist und die Datenbank keine großen Seiten zuweisen kann, besteht die einzige Möglichkeit darin, den Server neu zu starten.
  • (DCD) - Erkennung toter Verbindungen. Zum Beispiel gibt netstat unter AIX keine PID aus. Die einzige Möglichkeit, eine TCP-Verbindung mit PID zu koppeln, ist der Kernel-Debugger.
  • glance (etwas wie top auf HP-UX) erfordert Root-Privilegien
  • verschiedene Untersuchungen auf Veritas-Ebene
  • und viele viele andere

Es liegt an Ihnen, zu entscheiden, wie viel Zeit Sie „vergeuden“, bis das Problem gelöst ist. Ich wollte nur darauf hinweisen, dass die starke Rollentrennung in manchen Fällen sehr teuer werden kann. Anstatt also die "Sicherheit" zu erhöhen, konzentrieren Sie sich auf die Reduzierung von Risiken und Gefahren. Was nicht dasselbe ist. Tools wie ttysnoop oder Shell Spy ermöglichen es Ihnen, die gesamte SSH-Sitzung "aufzuzeichnen", wodurch sie Unleugbarkeit gewähren. Dies kann besser als sudo dienen.