ความปลอดภัยสำหรับ Application Developers ที่ทำงานกับ PL / SQL ใน Oracle

คุณจะจัดการกับการขาดสิทธิ์ระดับ Schema ใน Oracle ได้อย่างไร สถาปัตยกรรมความปลอดภัยของออราเคิลทำงานได้ดีสำหรับแอปพลิเคชันที่ต้องการเฉพาะสิทธิ์ระดับวัตถุและทำงานได้ดีสำหรับ DBA ที่ต้องการข้อ จำกัด เล็กน้อย อย่างไรก็ตามดูเหมือนว่าจะมีช่องโหว่ขนาดใหญ่ในสถาปัตยกรรมสำหรับโปรแกรมเมอร์ที่ทำการพัฒนาด้วยแอพพลิเคชั่นส่วนหน้าและ PL / SQL ในหลายสคีมา นี่คือตัวเลือกของฉันบางส่วนที่มีข้อเสีย:

1. ทำให้แต่ละโปรแกรมเมอร์ทำการพัฒนาในสคีมาของตนเอง DBA จะให้สิทธิพิเศษระดับวัตถุแก่โปรแกรมเมอร์ที่ต้องการ การพัฒนาบรรจุภัณฑ์ใด ๆ จะต้องทำโดย DBA ข้อเสียที่สำคัญคือโปรแกรมเมอร์จะใช้ฐานข้อมูลเช่น bit bucket เพื่อลดความเสียหายของประสิทธิภาพของฐานข้อมูล ฉันต้องการโปรแกรมเมอร์ที่จะพัฒนาในฐานข้อมูล แต่วิธีนี้จะทำให้หมดกำลังใจอย่างมาก

2. ให้ชื่อผู้ใช้ / รหัสผ่านของโปรแกรมเมอร์แก่ schema ที่ต้องการพัฒนามากกว่าสิบตัวอนุญาตให้สคีมาของแอปพลิเคชันเหล่านี้เพื่อสร้างโพรซีเดอร์ตารางและอื่น ๆ ข้อเสียของวิธีการนี้คือโปรแกรมเมอร์ต้องดูแลการเข้าสู่ระบบหลายครั้ง ไม่ค่อยเข้าสู่ระบบในฐานะตัวเอง การพัฒนาข้ามสคีก็ยากเช่นกัน

3. ให้สิทธิการพิสูจน์ตัวตนพร็อกซีโปรแกรมเมอร์แก่แต่ละสคีมาที่ต้องพัฒนา สิ่งนี้ทำให้พวกเขาล็อกอินด้วยตนเองโดยไม่ต้องให้สิทธิพิเศษนอกเหนือจากสิทธิ์พร็อกซี ข้อเสียรวมถึงโปรแกรมเมอร์ที่ต้องรักษาการเชื่อมต่อแยกกันสำหรับแต่ละสคีมาที่พร็อกซีสำหรับการพัฒนาข้ามสคีมานั้นยุ่งยากกว่าเนื่องจากการเชื่อมต่อจะต้องมีการเปลี่ยนแปลงอยู่ตลอดเวลาและแพ็คเกจที่ใช้การเชื่อมโยงฐานข้อมูลสาธารณะ

4. ให้สิทธิ์ DBA สำหรับโปรแกรมเมอร์แต่ละคน - ข้อเสียนี่คือความปลอดภัย ไม่มีโปรแกรมเมอร์สคีมาสามารถถูกเก็บออกจากสคีมาใด ๆ และโปรแกรมเมอร์ใด ๆ สามารถเลียนแบบโปรแกรมเมอร์อื่น ๆ (DBA)

ดูเหมือนว่าจะมีตัวเลือกที่ขาดหายไปเพื่อให้โปรแกรมเมอร์แต่ละตัว SELECT / INSERT / CREATE / etc สิทธิพิเศษในสคีมาที่พวกเขาต้องการในการพัฒนาพวกเขาลงชื่อเข้าใช้ด้วยตนเองเพื่อทำงานโดยใช้การเชื่อมต่อเดียว วัตถุใหม่ในสคีมาที่พวกเขาสามารถเข้าถึงได้จะพร้อมใช้งานทันที

ฉันพลาดอะไรไปรึเปล่า? คุณจัดการโปรแกรมเมอร์แอปพลิเคชันที่พัฒนา PL / SQL อย่างไร

ย้อนกลับไปในสมัยที่ฉันทำงานในร้านค้า Oracle เรามีเซิร์ฟเวอร์ 'dev' (การพัฒนา) เฉพาะซึ่งมีข้อ จำกัด ด้านความปลอดภัยที่แตกต่างจากเซิร์ฟเวอร์ 'prod' (การผลิต) นักพัฒนาสามารถทำอะไรก็ได้ที่พวกเขาต้องการจากนั้นเราก็มอบสคริปต์ที่จำเป็นให้กับ DBA เพื่อนำไปใช้กับเซิร์ฟเวอร์ที่ใช้งานจริง

ในกรณีของระบบที่สำคัญของเรา (แบนเนอร์ SCT สำหรับการติดตามชั้นเรียนและนักเรียนและ Oracle Financials) ก็มีเซิร์ฟเวอร์ 'ทดสอบ' และ 'เมล็ด' การทดสอบสำหรับการทดสอบการยอมรับของผู้ใช้ก่อนที่สิ่งต่างๆจะถูกโอนย้ายจาก dev เป็น prod; 'seed' คือการติดตั้งสต็อกซอฟต์แวร์ดังนั้นหากเราพบข้อผิดพลาดเราสามารถตรวจสอบว่าเป็นสิ่งที่เราแนะนำหรือมาจาก SCT หรือซอฟต์แวร์ของ Oracle

ใช้บทบาทเพื่อเชื่อมโยงคอลเลกชันของวัตถุจากนั้นให้สิทธิ์การเข้าถึงบทบาท

GRANTคำสั่งอนุญาตให้ DBA เพื่อ:

สิทธิ์ของออบเจกต์สำหรับออบเจกต์เฉพาะกับผู้ใช้บทบาทและสาธารณะ ตารางที่ 18-2 แสดงสิทธิ์พิเศษของวัตถุและการดำเนินการที่ได้รับอนุญาต

เนื่องจากสิทธิ์ของออบเจ็กต์สามารถมอบให้กับบทบาทจึงค่อนข้างง่ายที่จะให้สิทธิ์การเข้าถึงบทบาทกับตารางทั้งหมดในสคีมา:

sql> spool privs.sql
sql> select 'Grant select on scott' || table_name || ' ถึง role_select; ' จาก dba_tables โดยที่ owner = 'SCOTT';
SQL> @ privs.sql
sql> ให้ role_select กับ john, sam, peter;

สิ่งนี้รวมกับการGRANT CREATE TABLEออกโดยผู้ใช้ schema ที่เหมาะสมกับบทบาทหมายความว่านักพัฒนาสามารถเลือกและสร้างตารางได้ มันไม่สมบูรณ์แบบในขณะที่ตารางที่สร้างขึ้นต้องการให้สคริปต์ทำงานอีกครั้ง แต่WITH GRANT OPTIONแนะนำว่านักพัฒนาซอฟต์แวร์แต่ละคนสามารถให้สิทธิ์การเข้าถึงตารางที่สร้างขึ้นเพื่อบทบาทที่เหมาะสม

สิ่งนี้ชี้ให้เห็นว่าคุณสามารถสร้างทริกเกอร์ระดับ DDL ที่สามารถดำเนินการตามกระบวนการอนุญาตที่เหมาะสมแม้ว่าจะต้องมีการทดสอบจำนวนมากอย่างเห็นได้ชัด แต่ก็เป็นไปได้ที่จะทำให้คำสั่งสร้างตารางให้สิทธิ์ที่เหมาะสมกับบทบาทที่เหมาะสมโดยอัตโนมัติ

แก้ไข -

ตามGRANTที่CREATE TABLEสิทธิพิเศษ:

สร้างตารางในสคีมาของผู้รับสิทธิ์

ดังนั้นโดยให้พวกเขาสร้างตารางปรับเปลี่ยนตาราง ฯลฯจากผู้ใช้ที่ถูกต้องพวกเขาควรจะสามารถเข้าถึงคีมาของผู้ใช้ราวกับว่าพวกเขาเป็นผู้ใช้ที่เหมาะสม