Oracle DBA ของฉันต้องการการเข้าถึงรูทหรือไม่?

Oracle DBA Colleague ของฉันกำลังร้องขอการเข้าถึงรูทบนเซิร์ฟเวอร์ที่ใช้งานจริงของเรา
เขาโต้เถียงว่าเขาต้องการให้มันทำงานบางอย่างเช่นการรีบูทเซิร์ฟเวอร์และงานอื่น ๆ

ฉันไม่เห็นด้วยกับเขาเพราะฉันได้ตั้งเขาเป็นผู้ใช้ / กลุ่ม Oracle และกลุ่ม dba ที่ผู้ใช้ Oracle อยู่ ทุกอย่างทำงานได้อย่างราบรื่นโดยที่ DBA ไม่สามารถเข้าถึงรูทได้ในขณะนี้
ฉันยังคิดว่างานด้านการดูแลระบบทั้งหมดเช่นการรีบูทเซิร์ฟเวอร์ตามกำหนดเวลานั้นจะต้องทำโดยผู้ดูแลระบบที่เหมาะสม (ผู้ดูแลระบบในกรณีของเรา) เพื่อหลีกเลี่ยงปัญหาใด ๆ ที่เกี่ยวข้องกับการเข้าใจโครงสร้างพื้นฐาน

ฉันต้องการอินพุตจาก sysadmins และ Oracle DBAs - มีเหตุผลใดที่ดีที่Oracle DBA จะสามารถเข้าถึงรูทในสภาพแวดล้อมการใช้งานจริงได้หรือไม่?

หากเพื่อนร่วมงานของฉันต้องการการเข้าถึงระดับนี้ฉันจะให้ แต่ฉันกลัวที่จะทำเช่นนั้นเนื่องจากความปลอดภัยและความสมบูรณ์ของระบบ

ฉันไม่ได้มองหาข้อดี / ข้อเสีย แต่ควรจะให้คำแนะนำว่าฉันควรทำอย่างไรเพื่อรับมือกับสถานการณ์นี้

• ใครติดตั้ง Oracle บนเซิร์ฟเวอร์
  ถ้าเป็น DBA พวกเขาต้องการการเข้าถึงรูท หากเป็นระบบการดูแลระบบ DBA จะไม่ทำงาน

• ใครจะเรียกว่าตอนดึกเมื่อเซิร์ฟเวอร์ฐานข้อมูลหยุดทำงาน
  หากคุณไม่สามารถมั่นใจได้ว่า sysadmins พร้อมให้บริการทุกวันตลอด 24 ชั่วโมงคุณอาจต้องการให้รูทเครื่องเข้าถึง DBA

โปรดจำไว้ว่าถ้า DBA ของคุณมีการเข้าถึงเชลล์ในฐานะผู้ใช้ทั่วไป (โดยมีหรือไม่มีคำสั่งบางอย่างเขาสามารถเรียกใช้ผ่าน sudo โดยมีหรือไม่มีการ chrooted) ซึ่งเพียงพอที่จะยุ่งกับเซิร์ฟเวอร์ (คนเลวขโมยบัญชีของเขาสามารถแยกระเบิดได้ เกินกว่าที่ ulimit ส่งสแปมปล่อยฐานข้อมูล ... )

ด้วยเหตุผลเหล่านี้ผมคิดว่าใน DBAs โลกที่เหมาะไม่ควรมีการเข้าถึงราก ; แต่ในโลกแห่งความเป็นจริงอย่างน้อยพวกเขาควรจะสามารถรับมันได้ในกรณีฉุกเฉิน

โดยทั่วไป - และไม่เฉพาะเจาะจงกับ DBA - ใครก็ตามที่ต้องการrootเข้าถึงโดยไม่ให้เหตุผลที่ถูกต้องก็คือ:

1. คนที่ไม่รู้ว่ากำลังทำอะไรอยู่
2. อวดดีและไม่ร่วมมือ
3. ทั้งสองข้างต้น

ตอนนี้อาจมีเหตุผลที่แท้จริงที่พวกเขาต้องการrootเข้าถึงเพื่อจัดการงานของพวกเขา แต่อีกครั้งหากพวกเขาไม่สามารถอธิบายได้ว่าทำไม & วางไว้เป็นลายลักษณ์อักษรฉันจะไม่จัดการกับพวกเขา ผู้เชี่ยวชาญที่จัดการกับเซิร์ฟเวอร์เข้าใจและเคารพขอบเขต ช็อตเด็ดที่รู้ปัญหามากพอที่จะเชื่อได้ว่ากฎนั้นบังคับใช้กับทุกคนยกเว้นพวกเขา

ในกรณีที่ฉันต้องดิ้นรนกับคนแบบนี้ฉันได้ยืนยันเวลาที่กำหนดไว้ล่วงหน้าเพื่อให้ฉันสามารถอยู่บนเซิร์ฟเวอร์กับพวกเขาเพื่อจัดการกับปัญหาที่เกิดขึ้น และนี่ใช้งานได้ดีจริง ๆ

ทางเลือกอื่น - ที่อาจไม่สามารถใช้งานได้ - คือการสร้างโคลนที่แน่นอนของเซิร์ฟเวอร์ที่มีปัญหาและให้พวกเขาrootเข้าถึงได้ อย่าลืมเปลี่ยนรหัสผ่านเป็นสิ่งที่เฉพาะเจาะจงสำหรับพวกเขาแน่นอน ปล่อยให้พวกเขาระเบิดกล่องพัฒนาแยกออกมา

แต่โดยทั่วไปแล้วถ้าคุณเป็นคนหนึ่งที่จะได้รับการเรียกว่าตอนดึกเพื่อทำความสะอาดเป็นระเบียบว่าผู้ชายคนนี้อาจสร้างแล้วคุณมีสิทธิที่จะบอกว่าไม่มีการร้องขอผ้าห่มสำหรับทุกrootการเข้าถึง

ในทางทฤษฎี DBAs สามารถทำงานได้โดยไม่ต้องรูทรูท แต่มันเป็น PITA สำหรับทั้งสองฝ่าย เป็นไปไม่ได้ที่จะกำหนดรายการคำสั่งที่สามารถเข้าถึงได้ผ่านทางsudoจริง

ให้ DBAs รูตส่วนตัวถ้า:

• คุณไม่ต้องการตื่นขึ้นกลางดึกเพียงรีบูตเซิร์ฟเวอร์
• คุณต้องการการจัดการเหตุการณ์ที่รวดเร็วและราบรื่น
• หากเซิร์ฟเวอร์ของคุณเฉพาะเซิร์ฟเวอร์ DB เท่านั้น

DBA จำเป็นต้องใช้รูทเซิร์ฟเวอร์สำหรับ: การปรับพารามิเตอร์เคอร์เนล (sysctl), การจัดการหน่วยเก็บข้อมูล, การตรวจสอบปัญหา

การคัดเลือกที่เหมาะสมจะช่วยให้มั่นใจว่าเงื่อนไขการทำงานดีกว่ากฎความปลอดภัยที่กำหนดไว้อย่างเคร่งครัด หากคุณทำการตรวจสอบแล้วคุณสามารถถามได้ว่าทำไมพวกเขาถึงทำ / เปลี่ยนแปลงบางสิ่ง หากคุณไม่ได้ทำการตรวจสอบคุณจะไม่มีความปลอดภัยอยู่ดี

แก้ไข

นี่คือรายการข้อกำหนดทั่วไปของ Oracle ในรูปแบบสแตนด์อโลน (การติดตั้งที่ไม่ทำคลัสเตอร์)

• พารามิเตอร์เคอร์เนล

  • หน่วยความจำที่เกี่ยวข้อง (การกำหนดค่าหน้าขนาดใหญ่ / ใหญ่, RAM ที่ใช้ร่วมกัน (ipcs), RAM ที่ไม่สามารถสลับได้ (ล็อค)
  • เครือข่ายที่เกี่ยวข้อง (ขนาดของหน้าต่างการส่ง / รับ, TCP keepalive)
  • เกี่ยวข้องกับที่เก็บข้อมูล (จำนวนไฟล์ที่เปิด, async IO)

  อาจมีพารามิเตอร์ประมาณ 15-20 sysctl สำหรับแต่ละข้อ Oracle มีค่าที่แนะนำหรือสมการ สำหรับพารามิเตอร์บางตัวสมการที่แนะนำสามารถเปลี่ยนแปลงได้ตลอดเวลา (aync io) หรือในบางกรณี Oracle มีสมการมากกว่าหนึ่งสมการสำหรับพารามิเตอร์เดียวกัน

• พื้นที่เก็บข้อมูล: กฎ Linux udev ไม่รับประกันการใช้งานชื่ออุปกรณ์ถาวรของการบู๊ต ดังนั้นออราเคิลจึงจัดหาเคอร์เนลและเครื่องมือ (AsmLib) สิ่งเหล่านี้ช่วยให้คุณ "พาร์ติชัน" ฟิสิคัลพาร์ติชันเป็นรูทและจากนั้นคุณสามารถเห็นเลเบลเหล่านี้เมื่อจัดการกับที่เก็บฐานข้อมูล
• การตรวจสอบปัญหา:
  • เมื่อฐานข้อมูลขัดข้องเนื่องจากไม่สามารถเปิดตัวจัดการไฟล์ได้มากขึ้นวิธีแก้ปัญหาเดียวคือเพิ่มขีด จำกัด เคอร์เนลให้เรียกใช้งาน 'sysctl -p' แล้วเริ่มฐานข้อมูล
  • นอกจากนี้เมื่อคุณพบว่าฟิสิคัลแรมมีการแยกส่วนเกินไปและฐานข้อมูลไม่สามารถจัดสรรเพจขนาดใหญ่ได้ตัวเลือกเดียวคือรีบู๊ตเซิร์ฟเวอร์
  • (DCD) - การตรวจจับการเชื่อมต่อที่ไม่ทำงาน ตัวอย่างเช่นบน AIX netstat ไม่ได้พิมพ์ PID วิธีเดียวที่จะจับคู่การเชื่อมต่อ TCP กับ PID คือเคอร์เนลดีบักเกอร์
  • เหลือบ (บางอย่างเช่นด้านบนของ HP-UX) ต้องใช้สิทธิ์ส่วนบุคคล
  • การตรวจสอบระดับต่างๆของ Veritas
  • และอื่น ๆ อีกมากมาย

ขึ้นอยู่กับคุณที่จะตัดสินใจว่าคุณจะ "เสีย" เวลาเท่าไรจนกว่าปัญหาจะได้รับการแก้ไข ฉันแค่อยากจะชี้ให้เห็นว่าการแยกบทบาทที่แข็งแกร่งอาจมีราคาแพงมากคือบางกรณี ดังนั้นแทนที่จะเพิ่ม "ความปลอดภัย" มุ่งเน้นไปที่การลดความเสี่ยงและอันตราย ซึ่งไม่เหมือนกัน เครื่องมือเช่น ttysnoop หรือ shell spy ช่วยให้คุณ "บันทึก" เซสชันทั้งหมดของ ssh ได้ดังนั้นพวกเขาจึงไม่อนุญาตให้ปฏิเสธ สิ่งนี้สามารถให้บริการได้ดีกว่า sudo

ฉันเป็น Oracle DBA และคำตอบของฉันคือปกติ DBA ไม่ต้องการการเข้าถึงรูท แต่ RAC DBA? แน่นอนว่าเขาต้องการการเข้าถึงรูทเพื่อจัดการซีอาร์เอสการดูแลบ้านและทั้งหมด

คำถามนี้เกิดขึ้นในช่วงเวลาที่ระบบง่ายขึ้นมากและระบบปฏิบัติการเมื่อเทียบกับกระบวนการฐานข้อมูลถูกกำหนดแยกต่างหากและสามารถระบุตัวได้ การบริหารระบบและฐานข้อมูลหน้าที่และความรับผิดชอบแตกต่างกันมาก ด้วยสภาพแวดล้อมไอทีในปัจจุบันและโดยเฉพาะอย่างยิ่งกับเซิร์ฟเวอร์ฐานข้อมูลในปัจจุบันหน้าที่และความรับผิดชอบเหล่านี้มักจะทับซ้อนกันบ่อยกว่าไม่ ผู้ดูแลระบบทำการตรวจสอบสถานะอย่างเข้มงวดเพื่อ จำกัด การเข้าถึง“ รูท” ที่เกี่ยวข้องกับ“ การจัดการความเสี่ยง”

ด้วยความต้องการในปัจจุบันสำหรับ“ ความพร้อมใช้งานสูง” และ“ การแก้ไขทันที” สำหรับปัญหาที่เกิดขึ้นกับระบบฐานข้อมูล RAC ของเราผู้ดูแลระบบและผู้ดูแลระบบฐานข้อมูลให้บริการชุมชนธุรกิจที่ใช้งานได้ทำงานร่วมกันเป็นทีม ไม่ควรมีข้อกังวลใด ๆ กับ“ ความน่าเชื่อถือ” เนื่องจากทั้งสองฝ่ายมีส่วนได้เสียในการทำให้เซิร์ฟเวอร์ฐานข้อมูล RAC ออนไลน์ใกล้ 100% ของเวลา จำไว้ว่า DBA มีสิทธิ์เข้าถึงเชลล์ในฐานะผู้ดูแลฐานข้อมูล (มีหรือไม่มีคำสั่งบางคำสั่งที่เขาสามารถเรียกใช้ผ่าน sudo โดยมีหรือไม่มี chrooted) ดังนั้น DBA จึงเป็นตัวแทน "ที่เชื่อถือได้" ดังนั้นในความเป็นจริงคำถามที่ควรจะเป็น "ทำไม Oracle DBA ไม่ต้องการการเข้าถึง"

วันนี้ DBA มีหน้าที่รับผิดชอบเพิ่มเติมสำหรับเซิร์ฟเวอร์ฐานข้อมูลโดยที่ Database Server เป็นสมาชิกของ Oracle Real Application Cluster (RAC) และใช้ Oracle Automatic Storage Management (ASMLIB) เพื่อนำเสนอพื้นที่เก็บข้อมูลที่ใช้ร่วมกันทั่วฐานข้อมูล RAC การจัดการของ RAC และ ASM โดย DBA จะช่วยบรรเทาผู้ดูแลระบบที่ทำงานหนักเกินไปแล้วซึ่งน่าจะเป็นประโยชน์ต่อกลุ่ม / ทีมของ STS

และตามที่ ibre5043 ระบุว่า "... การแยกบทบาทที่แข็งแกร่งอาจมีราคาแพงมากคือบางกรณีดังนั้นแทนที่จะเพิ่ม" ความปลอดภัย "ให้มุ่งเน้นไปที่การลดความเสี่ยงและอันตรายซึ่งไม่เหมือนกันเครื่องมือเช่น ttysnoop หรือ shell spy ช่วยให้คุณ เพื่อ "บันทึก" เซสชันทั้งหมดของ ssh ดังนั้นพวกเขาจึงให้สิทธิ์ในการปฏิเสธสิ่งนี้สามารถให้บริการได้ดีกว่า sudo " นอกจากนี้คุณควรถามผู้ที่ติดตาม SSAs ด้วย

หากเซิร์ฟเวอร์ใช้ซอฟต์แวร์โครงสร้างพื้นฐาน Oracle Grid เช่น CRS, RAC หรือ Oracle Restart บริการบริการฐานข้อมูลที่สำคัญจำนวนมากจะทำงานเป็นรูทและไฟล์กำหนดค่าฐานข้อมูลที่สำคัญจำนวนมากนั้นเป็นของรูท มันเป็นคุณสมบัติการออกแบบโดยเนื้อแท้ของซอฟต์แวร์ หากนี่เป็นการละเมิดนโยบายของคุณคุณจำเป็นต้องแก้ไขนโยบาย

DBA จะต้องการการเข้าถึงรูทเพื่อจัดการคุณสมบัติเหล่านี้ ในทางทฤษฎีคุณอาจถามเขาถึงรายการคำสั่งที่เขาคาดว่าจะเรียกใช้เพื่อเข้าสู่ Sudo แต่คำตอบจะเป็นรายการที่ยาวมาก เพียงแค่ดูใน $ GRID_HOME / bin เพื่อดูรายการไบนารีทั้งหมดที่ DBA อาจใช้เป็นประจำ หากพวกเขากำลังทำกิจกรรมการปะแก้ (ซึ่งควรจะเป็น) รายการนั้นอาจยาวขึ้นกว่าเดิม

ฉันเพิ่งส่งคำถามที่คล้ายกัน ที่จริงแล้วเหตุผลที่ผู้ดูแลระบบไม่ต้องการให้สิทธิ์รูทเป็นหนึ่งในความรับผิดชอบและความรับผิดชอบที่ฉันคิด

แต่ถ้านี่คือสาเหตุ DBA ก็ควรเป็นระบบเดียวเท่านั้น และเหตุผลนั้นง่าย หากมีความต้องการแยกความรับผิดชอบและความรับผิดชอบระบบดูแลระบบสามารถเป็น DBA ได้เช่นกัน เขาสามารถเลียนแบบบัญชี oracle เขาสามารถป้อนฐานข้อมูลเป็น SYSDBA และทำสิ่งใดก็ได้โดยไม่ต้องใช้รหัสผ่าน SYS หรือ SYSTEM

ดังนั้นในความคิดของฉันหากมีความจำเป็นในการแยก sysadmins และ DBAs เนื่องจากความรับผิดชอบและความรับผิดชอบเหตุผลเชิงตรรกะเพียงอย่างเดียวคือเซิร์ฟเวอร์ควรได้รับการจัดการโดย DBA และไม่ใช่ sysadmin เซิร์ฟเวอร์และฐานข้อมูลควรเป็นความรับผิดชอบโดยรวมของ DBA ซึ่งควรมีความรู้ด้านการบริหารระบบเช่นกัน

หากเซิร์ฟเวอร์ถูกใช้งานมากกว่าโฮสต์ฐานข้อมูลและมีความต้องการความรับผิดชอบและความรับผิดชอบแยกต่างหากนี่หมายถึงปัญหา แต่ถ้าเซิร์ฟเวอร์ใช้สำหรับโฮสต์ฐานข้อมูลเท่านั้นฉันก็ไม่เห็นเหตุผลว่าทำไม DBA ไม่ควรมีสิทธิ์ใช้งานรูท

โดยส่วนตัวแล้วฉันจะตั้งคำถามด้วยวิธีอื่น ทำไม sysadmin ถึงมีสิทธิ์รูทบนเซิร์ฟเวอร์ฐานข้อมูลเฉพาะ ในความเป็นจริงแล้วความต้องการพิเศษของเขาในกรณีที่น้อยกว่าของ DBA (โดยมีสิทธิ์รูท)

จำเป็นต้องมีการเข้าถึงรูทสำหรับการติดตั้งและการแก้ไขตารางของ Oracle ไม่มีทางรอบมัน หากมีวิธีที่จะให้สิทธิ์การเข้าถึงรูทชั่วคราวไปยัง DBA สำหรับความต้องการดังกล่าวนั่นจะเป็นอุดมคติ