Oracle DBA của tôi có cần quyền truy cập root không?

Đồng nghiệp Oracle DBA của tôi đang yêu cầu quyền truy cập root trên các máy chủ sản xuất của chúng tôi .
Anh ta đang lập luận rằng anh ta cần nó để thực hiện một số hoạt động như khởi động lại máy chủ và một số nhiệm vụ khác.

Tôi không đồng ý với anh ta vì tôi đã đặt cho anh ta một nhóm / người dùng Oracle và một nhóm dba nơi người dùng Oracle thuộc về. Mọi thứ đều hoạt động trơn tru và hiện tại không có DBA có quyền truy cập root.
Tôi cũng nghĩ rằng tất cả các tác vụ quản trị như khởi động lại máy chủ theo lịch trình cần phải được thực hiện bởi quản trị viên thích hợp (Quản trị viên hệ thống trong trường hợp của chúng tôi) để tránh mọi loại sự cố liên quan đến sự hiểu lầm về tương tác cơ sở hạ tầng.

Tôi muốn đầu vào từ cả hai hệ thống và các DBA của Oracle - Có lý do chính đáng nào để một DBA của Oracle có quyền truy cập root trong môi trường sản xuất không?

Nếu đồng nghiệp của tôi thực sự cần mức truy cập này, tôi sẽ cung cấp nó, nhưng tôi khá sợ làm điều đó vì những lo ngại về bảo mật và toàn vẹn hệ thống.

Tôi không tìm kiếm ưu / nhược điểm mà là lời khuyên về cách tôi nên làm để đối phó với tình huống này.

• Ai cài đặt Oracle trên các máy chủ?
  Nếu đó là DBA, họ cần quyền truy cập root. Nếu đó là sysadmin, DBA thì không.

• Ai được gọi là đêm khuya khi máy chủ cơ sở dữ liệu ngừng hoạt động?
  Nếu bạn không thể đảm bảo các sysadins có sẵn 24/7, bạn có thể muốn cấp quyền truy cập root cho DBA.

Hãy nhớ rằng nếu DBA của bạn đã có quyền truy cập shell như một người dùng thông thường (có hoặc không có một số lệnh thì anh ta có thể chạy qua sudo; có hoặc không bị chro) điều đó đủ để gây rối với máy chủ (một kẻ xấu đánh cắp tài khoản của anh ta có thể đánh bom , vượt quá ulimit gửi thư rác, bỏ cơ sở dữ liệu, ...).

Vì tất cả những lý do này, tôi nghĩ rằng trong một thế giới DBA lý tưởng không nên có quyền truy cập root ; nhưng trong thế giới thực, ít nhất họ phải luôn có thể có được nó trong trường hợp khẩn cấp.

Nói chung, và không dành riêng cho các DBA, bất cứ ai có nhu cầu roottruy cập mà không đưa ra lý do hợp lệ là:

1. Một người không biết họ đang làm gì.
2. Kiêu ngạo & bất hợp tác.
3. Cả hai ở trên.

Bây giờ, có thể có lý do thực sự họ cần rootquyền truy cập để xử lý công việc của họ, nhưng một lần nữa nếu họ không thể giải thích lý do & đưa nó vào văn bản, tôi sẽ không giải quyết chúng. Các chuyên gia đối phó với các máy chủ hiểu và tôn trọng ranh giới. Những bức ảnh nóng, những người biết đủ để gặp rắc rối tin rằng các quy tắc áp dụng cho tất cả mọi người trừ họ.

Trong trường hợp tôi phải đấu tranh với những người như thế này, tôi đã khẳng định rằng thời gian được sắp xếp trước thời hạn để tôi có thể ở trên máy chủ với họ để xử lý các vấn đề khi chúng phát sinh. Và điều này thực sự đã làm việc tốt.

Một thay thế khác có thể không thực tế, đó là tạo một bản sao chính xác của máy chủ đang được đề cập và cấp cho họ rootquyền truy cập vào đó. Tất nhiên hãy chắc chắn để thay đổi mật khẩu thành một cái gì đó cụ thể cho họ. Hãy để họ thổi lên một hộp phát triển bị cô lập.

Nhưng nói chung, nếu bạn là người sẽ được gọi vào đêm khuya để dọn dẹp một mớ hỗn độn mà anh chàng này có thể tạo ra, thì bạn có quyền nói không với yêu cầu chăn để roottruy cập.

Về mặt lý thuyết, các DBA có thể hoạt động mà không cần quyền riêng tư, nhưng đó là PITA cho cả hai bên. Thực tế không thể xác định danh sách các lệnh có thể truy cập thông qua sudo.

Cung cấp cho các DBA root root nếu:

• bạn không muốn thức dậy vào giữa đêm, chỉ để khởi động lại máy chủ
• bạn muốn quản lý sự cố nhanh chóng và suôn sẻ
• nếu sever của bạn chỉ dành riêng cho máy chủ DB

Các DBA thường cần các quyền riêng tư cho: điều chỉnh tham số kernel (sysctl), thao tác lưu trữ, điều tra vấn đề.

Thử giọng đúng cách đảm bảo điều kiện chạy tốt hơn so với các quy tắc bảo mật được xác định nghiêm ngặt. Nếu bạn đã thực hiện kiểm toán, bạn luôn có thể hỏi tại sao họ đã làm / thay đổi điều gì đó. Nếu bạn không có kiểm toán, dù sao bạn cũng không có bảo mật.

EDITED

Đây là danh sách các yêu cầu phổ biến của Oracle về độc lập (cài đặt không phân cụm)

• Thông số hạt nhân

  • Liên quan đến bộ nhớ (cấu hình trang lớn / lớn, RAM dùng chung (ipc), RAM không thể trao đổi (khóa)
  • các mạng liên quan (gửi / nhận kích thước cửa sổ, giữ nguyên TCP)
  • lưu trữ liên quan (số lượng tệp đang mở, async IO)

  Có thể có khoảng 15-20 thông số sysctl. Đối với mỗi người trong số họ, Oracle cung cấp một giá trị được đề xuất hoặc một phương trình. Đối với một số tham số, phương trình được đề xuất có thể thay đổi theo thời gian (aync io) hoặc trong một số trường hợp, Oracle đã cung cấp nhiều hơn một phương trình cho cùng một tham số.

• Lưu trữ: Các quy tắc udev của Linux không đảm bảo cho các tên thiết bị khởi động liên tục. Do đó, Oracle đã cung cấp trình điều khiển và công cụ kernel (AsmLib). Điều này cho phép bạn "gắn nhãn" các phân vùng vật lý dưới dạng root và sau đó bạn có thể thấy các nhãn này khi quản lý lưu trữ cơ sở dữ liệu
• Vấn đề điều tra:
  • Khi cơ sở dữ liệu gặp sự cố vì không thể mở thêm các tệp xử lý thì giải pháp duy nhất là tăng giới hạn kernel, thực thi 'sysctl -p' và sau đó khởi động DB.
  • Ngoài ra, khi bạn thấy rằng RAM vật lý quá phân mảnh và cơ sở dữ liệu không thể phân bổ các trang lớn, thì tùy chọn duy nhất là khởi động lại máy chủ.
  • (DCD) - phát hiện kết nối chết. Ví dụ trên AIX netstat không in PID. Cách duy nhất để ghép nối kết nối TCP với PID là trình gỡ lỗi kernel.
  • liếc (cái gì đó giống như trên HP-UX) yêu cầu quyền riêng tư gốc
  • điều tra cấp Veritas khác nhau
  • và nhiều người khác

Tùy thuộc vào bạn quyết định bạn sẽ "lãng phí" bao nhiêu thời gian cho đến khi vấn đề được giải quyết. Tôi chỉ muốn chỉ ra rằng sự phân tách vai trò mạnh mẽ có thể rất tốn kém là một số trường hợp. Vì vậy, thay vì tăng "an ninh" tập trung vào việc giảm thiểu rủi ro và nguy hiểm. Mà không giống nhau. Các công cụ như ttysnoop hoặc shell spy cho phép bạn "ghi lại" toàn bộ phiên ssh, do đó, chúng cho phép không suy giảm. Điều này có thể phục vụ tốt hơn sudo.

Tôi là một DBA của Oracle và câu trả lời của tôi là, thông thường DBA không cần quyền truy cập root. Nhưng một RBA DBA? chắc chắn anh ta cần quyền truy cập root để quản lý CRS, giữ nhà và tất cả.

Câu hỏi này xuất phát từ thời trước khi các hệ thống đơn giản hơn nhiều và các quy trình HĐH so với Cơ sở dữ liệu được xác định riêng biệt và có thể nhận dạng được. Nhiệm vụ và trách nhiệm quản trị hệ thống và quản trị cơ sở dữ liệu rất khác biệt. Với môi trường CNTT ngày nay và đặc biệt, với Máy chủ cơ sở dữ liệu ngày nay, các nhiệm vụ và trách nhiệm này, thường xuyên hơn không, có xu hướng chồng chéo. Quản trị viên hệ thống thực hiện thẩm định để hạn chế quyền truy cập vào root root đối với quản lý rủi ro trên mạng.

Với nhu cầu ngày nay về tính sẵn sàng cao, và khắc phục ngay lập tức, các vấn đề phát sinh ngay lập tức với các vấn đề phát sinh với Hệ thống cơ sở dữ liệu RAC của chúng tôi, các quản trị viên hệ thống và Quản trị viên cơ sở dữ liệu phục vụ các cộng đồng kinh doanh chức năng của họ, làm việc cùng nhau như một nhóm. Không nên có bất kỳ mối quan tâm nào với nhóm Trust Trust, vì cả hai bên đều có quyền lợi trong việc giữ Máy chủ Cơ sở dữ liệu RAC trực tuyến gần 100% thời gian. Xin lưu ý, DBA đã có quyền truy cập shell với tư cách là Quản trị viên cơ sở dữ liệu (có hoặc không có một số lệnh mà anh ta có thể chạy qua sudo; có hoặc không bị chroot), vì vậy rõ ràng DBA là một tác nhân tin cậy trên đường sắt. Vì vậy, trong thực tế, câu hỏi nên là, Tại sao DBA của Oracle không cần truy cập?

DBA ngày nay đã đảm nhận các trách nhiệm bổ sung cho máy chủ cơ sở dữ liệu, trong đó Máy chủ cơ sở dữ liệu là thành viên của Cụm ứng dụng thực Real (RAC) và sử dụng Quản lý lưu trữ tự động của Oracle (ASMLIB) để trình bày lưu trữ được chia sẻ trên (các) Cơ sở dữ liệu RAC. Việc quản lý RAC và ASM của DBA sẽ giải phóng Quản trị viên hệ thống đã làm việc quá sức. Đây là một đóng góp đáng hoan nghênh cho Nhóm / Nhóm STS.

Và, như ioust5043 đã nói, "... phân tách vai trò mạnh có thể rất tốn kém là một số trường hợp. Vì vậy, thay vì tăng" bảo mật "tập trung vào việc giảm rủi ro và nguy hiểm. Điều này không giống nhau. Các công cụ như ttysnoop hoặc gián điệp vỏ cho phép bạn để "ghi lại" toàn bộ phiên ssh, do đó họ cấp cho người không suy giảm. Điều này có thể phục vụ tốt hơn sudo. " Ngoài ra, bạn nên hỏi ai theo dõi SSAs.

Nếu các máy chủ sử dụng phần mềm Cơ sở hạ tầng lưới của Oracle như CRS, RAC hoặc Oracle Restart, thì nhiều dịch vụ cơ sở dữ liệu quan trọng chạy dưới quyền root và nhiều tệp cấu hình cơ sở dữ liệu quan trọng được sở hữu bởi root. Nó là một tính năng thiết kế vốn có của phần mềm. Nếu điều này vi phạm chính sách của bạn thì chính sách cần được sửa đổi.

DBA sẽ yêu cầu quyền truy cập root để quản lý các tính năng này. Về mặt lý thuyết bạn có thể yêu cầu anh ta cho một danh sách các lệnh mà anh ta sẽ chạy để được nhập vào Sudo, nhưng câu trả lời sẽ là một danh sách rất dài. Chỉ cần xem $ GRID_HOME / bin để biết danh sách tất cả các nhị phân mà DBA có thể sử dụng một cách thường xuyên. Nếu họ đang thực hiện các hoạt động vá lỗi (mà họ nên có) thì danh sách có thể còn dài hơn nữa.

Tôi vừa gửi một câu hỏi tương tự. Trên thực tế, lý do một sysadmin không muốn đưa ra đặc quyền gốc, là một trong những trách nhiệm và trách nhiệm mà tôi nghĩ.

Nhưng nếu đây là nguyên nhân, DBA cũng nên là một và duy nhất sysadmin. Và lý do rất đơn giản. Nếu có nhu cầu phân tách trách nhiệm và trách nhiệm, sysadmin cũng có thể LUÔN là DBA. Anh ta có thể mạo danh tài khoản orory, anh ta có thể nhập cơ sở dữ liệu dưới dạng SYSDBA và làm bất cứ điều gì, mà không cần mật khẩu SYS hoặc HỆ THỐNG.

Vì vậy, theo tôi, nếu có nhu cầu tách sysadmin và DBA, do trách nhiệm và trách nhiệm, nguyên nhân hợp lý duy nhất là máy chủ cũng phải được quản lý bởi DBA chứ không phải sysadmin. Máy chủ và cơ sở dữ liệu phải là toàn bộ trách nhiệm của DBA, người cũng có một số kiến ​​thức quản trị hệ thống.

Nếu máy chủ được sử dụng nhiều hơn là lưu trữ cơ sở dữ liệu và cần có trách nhiệm và trách nhiệm riêng biệt, điều này có nghĩa là rắc rối. Nhưng nếu máy chủ chỉ được sử dụng để lưu trữ cơ sở dữ liệu, thì tôi không hiểu lý do tại sao DBA không nên có đặc quyền gốc, đã tính đến vô số trường hợp mà anh ta cũng sẽ cần.

Cá nhân tôi sẽ đặt câu hỏi theo cách khác. Tại sao sysadmin có đặc quyền gốc trên máy chủ cơ sở dữ liệu chuyên dụng? Trên thực tế, chuyên môn của anh ta sẽ được yêu cầu trong các trường hợp ít hơn nhiều so với DBA (với đặc quyền gốc).

Truy cập root là cần thiết để cài đặt và vá lưới của Oracle. Không có cách nào xung quanh nó. Nếu có một cách để cấp quyền truy cập root tạm thời cho DBA cho các nhu cầu như vậy, đó sẽ là lý tưởng.