Oracle DBAにはrootアクセスが必要ですか？
私のOracle DBA同僚が本番サーバーへのrootアクセスをリクエストしています。
rebootingサーバーや他のいくつかのタスクのようないくつかの操作を実行するためにそれが必要であると彼は主張しています。
私は彼にOracleユーザー/グループとOracleユーザーが所属するdbaグループを設定したので、彼に同意しません。すべてがスムーズに実行されており、DBAは現在rootアクセス権を持っていません。
また、インフラストラクチャの相互作用に関する誤解に関連するあらゆる種類の問題を回避するために、スケジュールされたサーバーの再起動などのすべての管理タスクは適切な管理者（この場合はシステム管理者）が行う必要があると思います。
SysadminsとOracle DBAの両方からの入力を希望します-Oracle DBAが実稼働環境でrootアクセス権を持つに正当な理由はありますか？
同僚が本当にこのレベルのアクセスを必要とする場合は、それを提供しますが、セキュリティとシステムの整合性の問題のため、そうすることは非常に恐れています。
私は長所/短所を探しているのではなく、この状況に対処するためにどうすればよいかについてのアドバイスをしています。
サーバーにOracleをインストールするのは誰ですか？
DBAの場合、rootアクセスが必要です。 sysadminの場合、DBAはしません。データベースサーバーがダウンしている夜遅くに呼び出されるのは誰ですか？
システム管理者が24時間年中無休で対応できない場合は、DBAにrootアクセスを付与することをお勧めします。
DBAが通常のユーザーとしてシェルアクセスを既に持っている場合（いくつかのコマンドの有無にかかわらず、Sudoを介して実行できます; chrootされているかどうかにかかわらず）、サーバーを混乱させるのに十分です（悪意のあるユーザーがアカウントを盗むと爆弾をフォークできます） 、スパムを送信するulimitを超え、データベースを削除します...）。
これらすべての理由から、理想的な世界ではDBAにrootアクセス権;を与えるべきではないと思います。しかし、現実の世界では、緊急時に少なくともいつでもそれを入手できるはずです。
一般に、DBAに固有ではありませんが、正当な理由なしにrootアクセスを要求する人は、次のいずれかです。
- 彼らが何をしているか知らない人。
- 傲慢で非協力的。
- 上記の両方。
さて、彼らがタスクを処理するためにrootアクセスを必要とする本当の理由があるかもしれませんが、繰り返しますが、彼らが理由を説明できず、それを書面で説明できない場合、私はそれらを扱いません。サーバーを扱う専門家は境界を理解し、尊重します。トラブルに巻き込まれるのに十分な知識があるホットショットは、ルールが彼ら以外の全員に適用されると信じています。
私がこのような人々と乱闘しなければならなかった場合、私は問題が発生したときに彼らと一緒にサーバーにいることができるように時間を事前にスケジュールするように主張しました。そして、これは実際にうまくいきました。
別の代替手段（実用的ではないかもしれません）は、問題のサーバーの正確なクローンを作成し、そのサーバーにrootアクセスを与えることです。もちろん、パスワードを彼らに固有のものに変更してください。孤立した開発ボックスを爆破させます。
しかし、一般的に、あなたがこの人が作成するかもしれない混乱を片付けるために夜遅くに呼ばれる人であるなら、あなたにはrootアクセスの全面的な要求にノーと言うあらゆる権利があります。
理論的には、DBAはroot特権なしで作業できますが、どちらもPITA Pです。 Sudoを介してアクセスできるようにコマンドのリストを定義することは事実上不可能です。
次の場合は、DBAにroot権限を付与します。
- あなたは真夜中に目が覚めたくない、ただサーバーを再起動したい
- 迅速かつ円滑なインシデント管理が必要
- サーバーがDBサーバー専用である場合
DBAは通常、カーネルパラメータの調整（sysctl）、ストレージの操作、問題の調査のためにルート権限を必要とします。
適切な試聴により、厳密に定義されたセキュリティルールよりも優れた実行条件が保証されます。監査を実装している場合は、なぜ彼らが何かをした/変更したのかをいつでも尋ねることができます。監査がなければ、セキュリティはありません。
[〜＃〜]編集済み[〜＃〜]
これは、スタンドアロン（クラスタ化されていないインストール）での一般的なOracle要件のリストです。
カーネルパラメーター
- メモリ関連（ラージ/ヒュージページ構成、共有RAM（ipcs）、非スワップ可能（ロック）RAM）
- ネットワーク関連（送信/受信ウィンドウサイズ、TCPキープアライブ）
- ストレージ関連（開いているファイルの数、非同期IO）
約15から20のsysctlパラメーターがある場合があります。それらのそれぞれについて、Oracleは推奨値または方程式を提供します。一部のパラメーターでは、推奨される方程式が時間の経過とともに変化する可能性があります（aync io）。場合によっては、同じパラメーターに対して複数の方程式がOracleから提供されています。
- ストレージ：Linux udevルールは、ブート永続デバイス名を保証しません。したがって、Oracleはカーネルドライバーとツール（AsmLib）を提供しました。これらにより、物理パーティションをルートとして「ラベル付け」でき、データベースストレージを管理するときにこれらのラベルを表示できます。
- 問題調査：
- それ以上のファイルハンドルを開けないためにデータベースがクラッシュした場合の唯一の解決策は、カーネル制限を増やし、「sysctl -p」を実行してからDBを起動することです。
- また、物理RAMが断片化されすぎており、データベースが大きなページを割り当てられない場合は、サーバーを再起動するしか選択肢がありません。
- （DCD）-デッド接続検出。たとえば、AIX netstatではPIDは出力されません。 TCP接続をPIDとペアリングする唯一の方法は、カーネルデバッガーです。
- 一目（HP-UXのtopなど）にはroot権限が必要です
- さまざまなVeritasレベルの調査
- その他多数
問題が解決するまで「無駄」にする時間を決めるのはあなた次第です。強力な役割分担は非常にコストがかかる場合があることを指摘したかっただけです。したがって、「セキュリティ」を高める代わりに、リスクと危険の低減に重点を置きます。同じではありません。 ttysnoopやShell spyなどのツールを使用すると、sshセッション全体を「記録」できるため、否認できないことになります。これは、Sudoよりも優れたサービスを提供できます。
私はOracle DBAです。私の答えは、通常、DBAはrootアクセスを必要としないことです。しかし、RAC DBA？間違いなく、CRS、ハウスキーピングなどを管理するには、rootアクセスが必要です。
Oracleグリッドのインストールとパッチ適用には、ルートアクセスが必要です。それを回避する方法はありません。このようなニーズのためにDBAに一時的なrootアクセスを許可する方法があった場合、それは理想的です。
サーバーがCRS、RAC、Oracle RestartなどのOracle Grid Infrastructureソフトウェアを使用している場合、重要なデータベースサービスの多くはrootとして実行され、重要なデータベース構成ファイルの多くはrootが所有しています。これは、ソフトウェア固有の設計機能です。これがポリシーの違反である場合、ポリシーを修正する必要があります。
これらの機能を管理するには、DBAにrootアクセスが必要です。理論的には、彼がSudoに入力するために実行する予定のコマンドのリストを要求することができますが、答えは非常に長いリストになります。 DBAが定期的に使用するすべてのバイナリのリストについては、$ GRID_HOME/binを参照してください。彼らがパッチングアクティビティを実行している場合は（そうでなければなりません）、リストはさらに長くなる可能性があります。
同様の質問を送信しました。実際、システム管理者がroot権限を与えたくない理由は、責任と説明責任の1つだと思います。
しかし、これが原因である場合、DBAも唯一のsysadminである必要があります。そしてその理由は簡単です。説明責任と責任を分離する必要がある場合、システム管理者は常にDBAになることもできます。彼はOracleアカウントになりすますことができ、SYSDBAとしてデータベースに入力して、SYSまたはSYSTEMパスワードを必要とせずに何でもできます。
したがって、私の意見では、説明責任と責任のためにsysadminとDBAを分離する必要がある場合、論理的な原因は、サーバーもsysadminではなくDBAが管理する必要があることです。サーバーとデータベースは、全体としてDBAの責任である必要があります。DBAは、システム管理に関する知識も必要です。
サーバーがデータベースをホストする以上の目的で使用されており、責任と説明責任を別にする必要がある場合、これはトラブルを意味します。しかし、サーバーがデータベースをホストするためだけに使用されている場合、DBAが必要とする無数のケースを考慮に入れて、DBAがroot特権を持たない理由はわかりません。
個人的には私はその逆の質問をします。 sysadminが専用データベースサーバーでroot権限を持つ必要があるのはなぜですか？実際、彼の専門性は、DBAの（root特権を持つ）専門家よりもはるかに少ないケースで必要とされます。
この質問は、システムがはるかにシンプルで、OSとデータベースのプロセスが別々に定義され、識別可能だった時代に遡ります。システム管理とデータベース管理の義務と責任は非常に異なっていました。今日のIT環境、特に今日のデータベースサーバーでは、これらの義務と責任が、しばしば重複する傾向があります。システム管理者は、「リスク管理」に関して「ルート」アクセスを制限するために十分な注意を払います。
RACデータベースシステムで発生する問題に対する「高可用性」と「即時修復」に対する今日の要求により、システム管理者とデータベース管理者は、チームとして共同で機能するビジネスコミュニティにサービスを提供します。両方の当事者がRACデータベースサーバーをオンラインのほぼ100％の時間でオンラインに保つことに既得権を持っているので、「信頼」についての懸念はありません。 DBAは既にデータベース管理者としてShellアクセス権を持っているため（Sudoを介して実行できるコマンドの有無にかかわらず、chrootされているかどうかに関係なく）、DBAは明らかに「信頼できる」エージェントです。したがって、実際の問題は、「なぜOracle DBAはアクセスを必要としないのか」ということです。
今日のDBAは、データベースサーバーがOracle Real Application Cluster（RAC）のメンバーであり、Oracle自動ストレージ管理（ASMLIB）を利用してRACデータベース全体の共有ストレージを提示するという、データベースサーバーの追加の責任を引き受けました。 DBAによるRACとASMの管理は、すでに過労しているシステム管理者を解放します。これは、STSグループ/チームへの歓迎すべき貢献です。
そして、ibre5043が述べたように、「...強力な役割の分離は非常に高価になる場合があります。そのため、リスクと危険を減らすことに「セキュリティ」の焦点を増やす代わりに、それは同じではありません。ttysnoopやShell spyなどのツールを使用すると、 sshセッション全体を "記録"するため、彼らは否定できないことを認めます。これはSudoよりも優れたサービスを提供できます。」また、SSAを監視しているユーザーを確認する必要があります。