Oracle DBA には root アクセスが必要ですか?

解決策 1:

• Oracle をサーバーにインストールするのは誰ですか?
  DBA の場合は、ルート アクセスが必要です。 sysadmin の場合、DBA はそうではありません。

• データベース サーバーがダウンしているときに深夜に呼び出されるのは誰ですか?
  システム管理者が 24 時間年中無休で利用できることを保証できない場合は、DBA にルート アクセス権を付与することをお勧めします。

DBA がすでに通常のユーザーとしてシェル アクセス権を持っている場合 (いくつかのコマンドの有無にかかわらず、sudo 経由で実行できます。chroot の有無にかかわらず)、サーバーを台無しにするのに十分であることに注意してください (自分のアカウントを盗んだ悪者は、爆弾をフォークすることができます)。 、送信スパムの ulimit を超える、データベースを削除する、...)。

これらすべての理由から、理想的な世界では、DBA はルート アクセス権を持つべきではないと思います。;しかし、現実の世界では、少なくとも緊急時にいつでも入手できる必要があります.

解決策 2:

一般的に (DBA に固有ではありません) root を要求する人なら誰でも 正当な理由のないアクセスは次のいずれかです:

<オール>

自分が何をしているのかわからない人

傲慢で非協力的

上記の両方

root が必要な本当の理由があるかもしれません 彼らの仕事を処理するためのアクセス権を持っていますが、彼らが理由を説明できず、それを書面にすることができない場合、私は彼らに対処しません.サーバーを扱う専門家は境界を理解し、尊重します。トラブルに巻き込まれることを十分に知っているホット ショットは、ルールが自分以外のすべての人に適用されると信じています。

このような人々と格闘しなければならなかった場合、問題が発生したときにサーバーで一緒に処理できるように、事前に時間をスケジュールするように主張しました.そして、これは実際にうまくいきました。

実用的ではないかもしれない別の代替手段は、問題のサーバーの正確なクローンを作成し、それらに root を与えることです。 その上でアクセスします。もちろん、パスワードを特定のものに変更してください。孤立した開発ボックスを爆破させてください。

しかし、一般的に、この男が作成する可能性のある混乱を片付けるために夜遅くに電話を受ける場合は、root の一括請求にノーと言う権利があります。 アクセス。

解決策 3:

理論的には、DBA は root 特権なしで作業できますが、それは双方にとって PITAbing です。コマンドのリストを sudo 経由でアクセスできるように定義することは事実上不可能です。 .

次の場合に DBA に root 権限を付与します:

• サーバーを再起動するためだけに、夜中に起こされたくない
• 迅速かつスムーズなインシデント管理が必要
• お使いのサーバーが DB前後サーバー専用の場合

DBA は通常、カーネル パラメータの調整 (sysctl)、ストレージの操作、問題の調査のために root 権限を必要とします。

適切なオーディションにより、厳密に定義されたセキュリティ ルールよりも優れた実行条件が保証されます。監査が実装されている場合は、なぜ彼らが何かを行った/変更したのかをいつでも尋ねることができます。監査がなければ、とにかくセキュリティがありません。

編集済み

これは、スタンドアロン（クラスタ化されていないインストール）での一般的なオラクルの要件のリストです

• カーネル パラメータ

  • メモリ関連 (ラージ/ヒュージ ページ構成、共有 RAM (ipcs)、スワップ不能 (ロック) RAM)
  • ネットワーク関連 (送受信ウィンドウ サイズ、TCPケプアライブ)
  • ストレージ関連 (開いているファイルの数、非同期 IO)

  約 15 ～ 20 個の sysctl パラメーターが存在する可能性があります。それぞれについて、オラクルは推奨値または方程式を提供します。パラメータによっては、推奨される方程式が時間の経過とともに変化する可能性があります (aync io)。場合によっては、Oracle が同じパラメータに対して複数の方程式を提供しています。

• ストレージ:Linux の udev ルールは、ブートの永続的なデバイス名を保証しません。そのため、Oracle はカーネル ドライバとツール (AsmLib) を提供しました。これらにより、ルートとして物理パーティションに「ラベルを付ける」ことができ、データベース ストレージを管理するときにこれらのラベルを確認できます
• 問題の調査:
  • これ以上ファイル ハンドルを開けないためにデータベースがクラッシュした場合、唯一の解決策は、カーネル制限を増やし、'sysctl -p' を実行してから DB を開始することです。
  • また、物理 RAM が断片化しすぎて、データベースが大きなページを割り当てられないことがわかった場合、唯一のオプションはサーバーを再起動することです。
  • (DCD) - 切断された接続の検出。たとえば、AIX では netstat は PID を出力しません。 TCP 接続と PID をペアにする唯一の方法は、カーネル デバッガーです。
  • glance (HP-UX の top のようなもの) にはルート権限が必要です
  • さまざまな Veritas レベルの調査
  • その他多数

問題が解決するまでどのくらいの時間を「無駄」にするかは、あなた次第です。場合によっては、強力な役割の分離が非常に高くつく可能性があることを指摘したかっただけです。そのため、「セキュリティ」を強化する代わりに、リスクと危険を軽減することに重点を置いています。これは同じではありません。 ttysnoop や shell spy などのツールを使用すると、ssh セッション全体を「記録」できるため、否定できないことが保証されます。これは sudo よりも優れています。