Oracle DBA에 루트 액세스 권한이 필요합니까?

내 Oracle DBA 동료가 프로덕션 서버 에서 루트 액세스를 요청하고 있습니다 .
그는 서버 재부팅 및 일부 다른 작업과 같은 일부 작업을 수행하는 데 필요하다고 주장 합니다.

Oracle 사용자 / 그룹과 Oracle 사용자가 속한 dba 그룹을 설정했기 때문에 동의하지 않습니다. DBA가 현재 루트 액세스 권한을 갖지 않고 모든 것이 원활하게 실행됩니다.
또한 인프라 상호 작용의 오해와 관련된 모든 종류의 문제를 피하려면 예약 된 서버 재부팅과 같은 모든 관리 작업을 적절한 관리자 (이 경우 시스템 관리자)가 수행해야한다고 생각합니다.

sysadmins와 Oracle DBA 모두의 의견을 원합니다.- 프로덕션 환경에서 Oracle DBA가 루트 액세스 권한을 갖는 충분한 이유가 있습니까?

동료가이 수준의 액세스 권한을 필요로한다면이를 제공 할 것이지만 보안 및 시스템 무결성 문제 때문에 그렇게하는 것이 두렵습니다.

나는 장단점을 찾는 것이 아니라이 상황을 처리하기 위해 취해야 할 방법에 대한 조언을 찾고 있습니다.

• 누가 서버에 Oracle을 설치합니까?
  DBA 인 경우 루트 액세스 권한이 필요합니다. sysadmin 인 경우 DBA는 그렇지 않습니다.

• 데이터베이스 서버가 다운 될 때 심야에 누가 전화합니까?
  sysadmins를 24 시간 연중 무휴로 사용할 수없는 경우 DBA에 루트 액세스 권한을 부여 할 수 있습니다.

DBA가 이미 일반 사용자로 쉘 액세스 권한을 가지고 있다면 (일부 명령을 사용하거나 실행하지 않고 chroot를 사용하거나 사용하지 않고) 서버를 망칠 수 있습니다. 스팸을 보내는 ulimit를 초과하고 데이터베이스를 삭제하십시오 ...).

이러한 모든 이유로 인해 이상적인 세계에서 DBA는 루트 액세스 권한을 가져서는 안된다고 생각 합니다 . 그러나 현실 세계에서는 최소한 비상시에는 항상 그것을 얻을 수 있어야합니다.

일반적으로 DBA에만 국한되지는 않지만 root유효한 이유없이 액세스 를 요구하는 사람 은 다음 중 하나입니다.

1. 자신이하는 일을 모르는 사람.
2. 오만한 & 비협조적인.
3. 위의 두 가지.

이제, 그들이 root업무를 처리하기 위해 접근 해야하는 실제 이유가있을 수 있지만, 다시 이유를 설명 할 수없고 서면으로 작성하지 않으면 처리하지 않을 것입니다. 서버를 다루는 전문가는 경계를 이해하고 존중합니다. 곤경에 처할만큼 충분히 잘 알고있는 사람들은 규칙이 규칙을 제외한 모든 사람에게 적용된다고 생각합니다.

이와 같은 사람들과 어울려야 할 경우, 미리 문제가 발생하여 서버에서 문제를 처리 할 수 ​​있도록 미리 예약해야한다고 주장했습니다. 그리고 이것은 실제로 잘 작동했습니다.

실용적이지 않은 또 다른 대안은 문제의 서버를 정확하게 복제하여 root액세스 할 수 있도록하는 것입니다. 물론 암호를 특정 암호로 변경하십시오. 격리 된 개발 박스를 폭파 시키십시오.

그러나 일반적으로, 당신이이 남자가 만들 수있는 혼란을 해결하기 위해 늦은 밤에 전화를받을 사람이라면, 당신은 담요 요청을 거부 할 권리가 root있습니다.

이론적으로 DBA는 루트 권한없이 작동 할 수 있지만 양쪽에 대한 PITA입니다. 를 통해 액세스 할 수있는 명령 목록을 정의하는 것은 사실상 불가능합니다 sudo.

다음과 같은 경우 DBA에 루트 권한을 부여하십시오.

• 한밤중에 깨어나지 않고 서버를 재부팅하기 만하면됩니다
• 빠르고 원활한 사고 관리를 원합니다
• 서버가 DB 서버 전용 인 경우

DBA는 커널 매개 변수 조정 (sysctl), 스토리지 조작, 문제점 조사를 위해 루트 권한이 필요합니다.

적절한 오디션은 엄격하게 정의 된 보안 규칙보다 더 나은 실행 조건을 보장합니다. 감사를 구현 한 경우 항상 왜 그들이 무엇을 변경 / 변경했는지 물어볼 수 있습니다. 감사가 없으면 보안이 유지되지 않습니다.

편집

독립형 (클러스터되지 않은 설치)에 대한 일반적인 Oracle 요구 사항 목록

• 커널 매개 변수

  • 메모리 관련 (대형 / 거대한 페이지 구성, 공유 RAM (ipcs), 교체 불가능 (잠금) RAM)
  • 네트워크 관련 (송수신 창 크기, TCP keepalive)
  • 스토리지 관련 (열린 파일 수, 비동기 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과 같은 것) 루트 권한이 필요합니다
  • 다양한 베리타스 레벨 조사
  • 그리고 많은 다른 사람들

문제가 해결 될 때까지 "폐기"할 시간을 결정하는 것은 귀하의 책임입니다. 강력한 역할 분리가 매우 비쌀 수 있음을 지적하고 싶었습니다. 따라서 "보안"을 높이는 대신 위험과 위험을 줄이는 데 중점을 둡니다. 동일하지 않습니다. ttysnoop 또는 shell spy와 같은 도구를 사용하면 전체 ssh 세션을 "기록"할 수 있으므로 거부 할 수 없습니다. 이것은 sudo보다 낫습니다.

나는 Oracle DBA이고 대답은 일반적으로 DBA는 루트 액세스가 필요하지 않습니다. 그러나 RAC DBA? 확실히 그는 CRS, 주택 관리 및 모든 것을 관리하기 위해 루트 액세스 권한이 필요합니다.

이 질문은 시스템이 훨씬 단순 해졌고 OS 대 데이터베이스 프로세스가 별도로 정의되고 식별 가능한 시대에서 비롯된 것입니다. 시스템 관리 및 데이터베이스 관리 업무와 책임은 매우 뚜렷했습니다. 오늘날의 IT 환경, 특히 오늘날의 데이터베이스 서버에서는 이러한 업무와 책임이 종종 겹치는 경향이 있습니다. 시스템 관리자는 "위험 관리"와 관련하여 "루트"액세스를 제한하기 위해주의를 기울입니다.

RAC 데이터베이스 시스템에서 발생하는 문제에 대한 "고 가용성"및 "즉시 개선"에 대한 오늘날의 요구에 따라 시스템 관리자와 데이터베이스 관리자는 기능적인 비즈니스 커뮤니티에 팀으로 협력합니다. RAC 데이터베이스 서버를 온라인으로 거의 100 % 가까이 유지하는 데 관심이 있으므로 "신뢰"에 대한 우려가 없어야합니다. DBA는 이미 데이터베이스 관리자로서 쉘 액세스 권한을 가지고 있음을 명심하십시오. 따라서 실제로 문제는 "Oracle DBA가 액세스 할 필요가없는 이유는 무엇입니까?"

오늘의 DBA는 데이터베이스 서버에 대한 추가 책임을 맡았으며, 여기서 데이터베이스 서버는 Oracle RAC (Real Application Cluster)의 구성원이며 Oracle ASM (Automatic Storage Management)을 사용하여 RAC 데이터베이스에서 공유 스토리지를 제공합니다. DBA가 RAC 및 ASM을 관리하면 이미 과도하게 작업 한 시스템 관리자가 줄어 듭니다. 이는 STS 그룹 / 팀에 기꺼이 기여해야합니다.

ibre5043에서 언급했듯이 "... 강력한 역할 분리는 비용이 많이들 수 있습니다. 따라서"보안 "을 높이는 대신 위험과 위험을 줄이는 데 중점을 둡니다. ttysnoop이나 shell spy와 같은 도구를 사용하면 전체 ssh 세션을 "기록"하여 부인할 수없는 권한을 부여합니다. 이는 sudo보다 더 잘 제공 될 수 있습니다. " 또한 누가 SSA를 모니터링하고 있는지 문의해야합니다.

서버가 CRS, RAC 또는 Oracle Restart와 같은 Oracle Grid Infrastructure 소프트웨어를 사용하는 경우 많은 중요한 데이터베이스 서비스가 루트로 실행되고 많은 중요한 데이터베이스 구성 파일이 루트에 의해 소유됩니다. 소프트웨어의 고유 한 디자인 기능입니다. 이것이 정책을 위반하는 경우 정책을 수정해야합니다.

DBA는 이러한 기능을 관리하기 위해 루트 액세스 권한이 필요합니다. 이론적으로 당신은 그가 Sudo에 입력 할 것으로 예상되는 명령 목록을 요청할 수 있지만 대답은 매우 긴 목록입니다. DBA가 정기적으로 사용할 수있는 모든 바이너리 목록을 보려면 $ GRID_HOME / bin을 살펴보십시오. 패치 작업을 수행하는 경우 (필수) 목록이 더 길어질 수 있습니다.

방금 비슷한 질문을 제출했습니다. 실제로 sysadmin이 루트 권한을 부여하지 않으려는 이유는 제가 생각하는 책임과 책임 중 하나입니다.

그러나 이것이 원인 인 경우 DBA도 유일한 sysadmin이어야합니다. 그리고 그 이유는 간단합니다. 책임과 책임을 분리해야하는 경우 sysadmin은 항상 DBA 일 수도 있습니다. 그는 oracle 계정을 가장 할 수 있으며 SYSDBA로 데이터베이스를 입력하고 SYS 또는 SYSTEM 암호 없이도 무엇이든 할 수 있습니다.

따라서 제 생각에는 책임과 책임으로 인해 sysadmin과 DBA를 분리해야 할 경우 유일한 논리적 원인은 sysadmin이 아닌 DBA가 서버를 관리해야한다는 것입니다. 서버와 데이터베이스는 전체 시스템 관리 지식을 가져야하는 DBA의 책임입니다.

서버가 데이터베이스를 호스팅하는 것 이상으로 사용되며 별도의 책임과 책임이 필요한 경우 이는 문제를 의미합니다. 그러나 서버가 데이터베이스를 호스팅하는 데에만 사용된다면 DBA가 루트 권한을 가져서는 안되는 이유가 없습니다.

개인적으로 나는 다른 방법으로 질문을 할 것입니다. sysadmin이 전용 데이터베이스 서버에 대한 루트 권한을 갖는 이유는 무엇입니까? 사실, 그의 전문 분야는 DBA의 전문 분야 (루트 권한이있는 것)보다 훨씬 적은 경우에 필요합니다.

Oracle 그리드 설치 및 패치에는 루트 액세스가 필요합니다. 그 주위에 방법이 없습니다. 그러한 요구에 대해 DBA에 임시 루트 액세스 권한을 부여 할 수있는 방법이 있다면 이상적입니다.