Oracle DBAにはルートアクセスが必要ですか？

私のOracle DBA同僚は、本番サーバーでのルートアクセスを要求しています。
彼は、サーバーの再起動やその他のタスクなどの操作を実行するために必要であると主張しています。

彼にOracleユーザー/グループとOracleユーザーが属するdbaグループを設定したため、私は彼に同意しません。すべてが順調に実行されており、DBAが現在ルートアクセス権を持っていることはありません。
また、インフラストラクチャの相互作用の誤解に関連するあらゆる種類の問題を回避するために、スケジュールされたサーバーの再起動などのすべての管理タスクを適切な管理者（この場合はシステム管理者）が行う必要があると思います。

sysadminsとOracle DBAの両方からの入力を希望します-Oracle DBA が実稼働環境でrootアクセスできる理由はありますか？

同僚がこのレベルのアクセスを本当に必要とする場合は提供しますが、セキュリティとシステムの整合性の懸念から、そうすることを非常に恐れています。

私は賛否両論を探しているのではなく、この状況に対処するために私がとるべき方法に関するアドバイスを探しています。

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

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

DBAが既に通常のユーザーとしてシェルアクセスを持っている場合（sudoを介して実行できるコマンドの有無にかかわらず、chrootの有無にかかわらず）、サーバーを台無しにするのに十分である（アカウントを盗む悪人が爆弾をフォークする可能性がある） 、スパムを送信するulimitを超え、データベースを削除します、...）。

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

一般に（DBAに限定されない）root、正当な理由を与えずにアクセスを要求する人は次のいずれかです。

1. 彼らが何をしているかわからない人。
2. rog慢で非協力的。
3. 上記の両方。

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

私はこのような人々と取り組まなければならなかった場合、私は時間を前もってスケジュールすることを主張しました。そして、これは実際にうまく機能しています。

もう1つの選択肢は、実用的ではないかもしれませんが、問題のサーバーの正確なクローンを作成し、そのサーバーにrootアクセス権を付与することです。もちろん、パスワードをそれらに固有の何かに変更してください。孤立した開発ボックスを爆破させます。

しかし、一般的に、あなたが深夜にこの男が作成する混乱を一掃するために呼ばれる人なら、あなたは全面的なrootアクセス要求にノーと言う権利があります。

理論的には、DBAはルート権限なしで機能しますが、両側のPITAです。コマンドのリストを経由でアクセス可能に定義するのは事実上不可能sudoです。

次の場合は、DBAにルート権限を付与します。

• 真夜中に目覚めたくない、サーバーを再起動するだけ
• 迅速かつスムーズなインシデント管理が必要な場合
• サーバーがDBサーバー専用である場合

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

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

編集済み

これは、スタンドアロン（非クラスターインストール）での一般的なOracle要件のリストです。

• カーネルパラメーター

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

  約15〜20のsysctlパラメーターが存在する場合があります。それぞれについて、Oracleは推奨値または式を提供します。パラメータによっては、推奨される式が時間の経過とともに変化する場合があります（aync io）場合によっては、同じパラメータに対して複数の式が提供されます。

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

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

私はOracle DBAであり、私の答えは、通常DBAはルートアクセスを必要としません。しかし、RAC DBA？間違いなく、彼はCRS、ハウスキーピングなどを管理するためにルートアクセスが必要です。

この質問は、システムがはるかに単純で、OS対データベースプロセスが個別に定義され、識別可能であった時代に遡ります。システム管理とデータベース管理の義務と責任は非常に明確でした。今日のIT環境、特に今日のデータベースサーバーでは、これらの義務と責任は、しばしば重複する傾向があります。システム管理者は、「リスク管理」に関して「ルート」アクセスを制限するためにデューデリジェンスを行います。

RACデータベースシステムで発生する問題に対する「高可用性」と「即時修復」に対する今日の要求により、システム管理者とデータベース管理者はチームとして連携して機能的なビジネスコミュニティにサービスを提供しています。両当事者は、RACデータベースサーバーを常に100％近くの時間でオンラインに保つことに関心を持っているため、「信頼」に関する懸念はないはずです。DBAにはデータベース管理者としてのシェルアクセスが既にある（sudoを介して実行できるコマンドの有無にかかわらず、chrootの有無にかかわらず）ため、明らかにDBAは「信頼できる」エージェントです。したがって、実際には、「Oracle DBAがアクセスする必要がないのはなぜですか」という質問にすべきです。

今日のDBAは、データベースサーバーがOracle Real Application Cluster（RAC）のメンバーであり、Oracle自動ストレージ管理（ASMLIB）を使用してRACデータベース全体で共有ストレージを提供するデータベースサーバーの責任を追加しています。DBAによるRACとASMの管理により、すでに過労しているシステム管理者が解放されます。これは、STSグループ/チームへの歓迎すべき貢献です。

そして、ibre5043が述べたように、「...強力な役割の分離は非常に高価になる場合があります。そのため、リスクと危険を減らすことに「セキュリティ」重点を置く代わりに。同じではありません。 sshセッション全体を「記録」します。したがって、被付与者は否認できません。これは、sudoよりも役立つ場合があります。また、SSAを監視しているユーザーを尋ねる必要があります。

サーバーがCRS、RAC、Oracle RestartなどのOracle Grid Infrastructureソフトウェアを使用する場合、重要なデータベースサービスの多くはrootとして実行され、重要なデータベース構成ファイルの多くはrootが所有します。これは、ソフトウェア固有の設計機能です。これがポリシー違反である場合、ポリシーを修正する必要があります。

DBAは、これらの機能を管理するためにルートアクセスを必要とします。理論的には、Sudoに入力するために実行する予定のコマンドのリストを彼に尋ねることができますが、答えは非常に長いリストになります。DBAが定期的に使用する可能性のあるすべてのバイナリのリストについては、$ GRID_HOME / binをご覧ください。彼らがパッチ適用アクティビティを実行している場合（実行する必要があります）、リストはさらに長くなる可能性があります。

同様の質問を提出しました。実際、システム管理者がルート特権を与えたくない理由は、私が考える責任と説明責任の理由です。

ただし、これが原因である場合、DBAは唯一のsysadminでもある必要があります。そしてその理由は簡単です。説明責任と責任の分離が必要な場合、システム管理者は常にDBAでもあります。彼はoracleアカウントになりすますことができ、SYSまたはSYSTEMパスワードを必要とせずに、データベースにSYSDBAとして入力し、何でもできます。

したがって、私の意見では、説明責任と責任のためにシステム管理者とDBAを分離する必要がある場合、唯一の論理的な原因はサーバーがシステム管理者ではなくDBAによって管理されることです。サーバーとデータベースは全体としてDBAの責任である必要があり、DBAはシステム管理の知識も持っている必要があります。

サーバーがデータベースのホスティング以上に使用されており、責任と説明責任が別に必要である場合、これはトラブルを意味します。ただし、サーバーがデータベースのホストのみに使用される場合、DBAがルート特権を持たない理由はわかりません。

個人的に私は質問を他の方法で回避するでしょう。sysadminが専用のデータベースサーバーでroot権限を持っているのはなぜですか？実際、彼の専門分野はDBA（root特権を持つ）の場合よりもはるかに少ない場合に必要です。

Oracleグリッドのインストールおよびパッチ適用には、ルートアクセスが必要です。それを回避する方法はありません。そのようなニーズに対してDBAへの一時的なルートアクセスを許可する方法があれば、それは理想的です。