Bảo mật cho các nhà phát triển ứng dụng thực hiện công việc PL / SQL trong Oracle

Làm thế nào để bạn xử lý việc thiếu các đặc quyền cấp Schema trong Oracle? Kiến trúc bảo mật của Oracle hoạt động tốt cho các ứng dụng chỉ cần đặc quyền cấp đối tượng và nó hoạt động tốt cho các DBA cần ít hạn chế. Tuy nhiên, dường như có một lỗ hổng lớn trong kiến ​​trúc dành cho các lập trình viên đang phát triển với ứng dụng giao diện người dùng và PL / SQL trong nhiều lược đồ. Dưới đây là một số lựa chọn của tôi với nhược điểm của họ:

1. Làm cho mỗi lập trình viên phát triển trong lược đồ riêng của họ. DBA sẽ cấp các đặc quyền cấp đối tượng cho các lập trình viên cần chúng. Bất kỳ sự phát triển gói phải được thực hiện bởi một DBA. Nhược điểm chính là các lập trình viên sẽ sử dụng cơ sở dữ liệu như một thùng bit để làm giảm hiệu suất của cơ sở dữ liệu. Tôi muốn các lập trình viên phát triển trong cơ sở dữ liệu, nhưng phương pháp này sẽ làm nản lòng nó rất nhiều.

2. Cung cấp cho mỗi lập trình viên tên người dùng / mật khẩu cho hàng tá lược đồ họ cần để phát triển. Cấp quyền cho lược đồ ứng dụng này để tạo quy trình, bảng, v.v. Một số nhược điểm của phương pháp này là lập trình viên phải duy trì nhiều lần đăng nhập và hiếm khi đăng nhập như chính họ. Phát triển lược đồ chéo cũng khó khăn.

3. Cấp cho các lập trình viên đặc quyền xác thực proxy trên mỗi lược đồ mà họ cần để phát triển. Điều này giữ cho họ đăng nhập như chính họ mà không phải cấp cho họ các đặc quyền khác ngoài đặc quyền proxy. Nhược điểm bao gồm các lập trình viên phải duy trì các kết nối riêng cho từng lược đồ mà họ ủy quyền, việc phát triển lược đồ chéo trở nên cồng kềnh hơn vì các kết nối phải liên tục thay đổi và các gói sử dụng liên kết cơ sở dữ liệu công cộng với xác thực được thông qua sẽ không được biên dịch trong các kết nối proxy.

4. Cung cấp cho mỗi đặc quyền DBA lập trình viên. - Nhược điểm ở đây là bảo mật. Không có lập trình viên lược đồ nào có thể được giữ ngoài bất kỳ lược đồ nào và bất kỳ lập trình viên nào cũng có thể mạo danh bất kỳ lập trình viên nào khác (DBA).

Dường như có một tùy chọn còn thiếu để cấp cho mỗi lập trình viên CHỌN / CHERTN / TẠO / v.v. đặc quyền trên lược đồ mà họ cần để phát triển. Họ đăng nhập như chính họ để thực hiện công việc của họ bằng một kết nối. Các đối tượng mới trong lược đồ mà chúng có quyền truy cập ngay lập tức có sẵn.

Tui bỏ lỡ điều gì vậy? Làm thế nào để bạn xử lý các lập trình viên ứng dụng phát triển PL / SQL?

Quay trở lại những ngày khi tôi làm việc trong một cửa hàng của Oracle, chúng tôi đã có một máy chủ 'dev' (phát triển) cụ thể, có các hạn chế bảo mật khác với máy chủ 'prod' (sản xuất). Các nhà phát triển có thể làm bất cứ điều gì họ cần, và sau đó chúng tôi sẽ chuyển các tập lệnh cần thiết cho DBA để áp dụng cho máy chủ sản xuất.

Trong trường hợp các hệ thống quan trọng của chúng tôi (Biểu ngữ SCT, để theo dõi các lớp học & sinh viên và Tài chính Oracle), cũng có các máy chủ 'thử nghiệm' và 'hạt giống'. Kiểm tra là để kiểm tra chấp nhận của người dùng trước khi công cụ chuyển từ dev sang prod; 'Seed' là cài đặt phần mềm của phần mềm, vì vậy chúng tôi sẽ tìm thấy một lỗi, chúng tôi có thể xác minh xem đó có phải là thứ chúng tôi đã giới thiệu hoặc đến từ phần mềm của SCT hoặc Oracle không.

Sử dụng vai trò để liên kết các bộ sưu tập các đối tượng, sau đó cấp quyền truy cập vào các vai trò

Câu lệnh GRANT cho phép DBA:

Đặc quyền đối tượng cho một đối tượng cụ thể cho người dùng, vai trò và CÔNG. Bảng 18-2 liệt kê các đặc quyền đối tượng và các hoạt động mà chúng ủy quyền.

Vì các đặc quyền đối tượng có thể được cấp cho một vai trò, nên việc cấp quyền truy cập vai trò cho tất cả các bảng trong một lược đồ là tương đối dễ dàng:

sql> spool privates.sql
sql> chọn 'cấp chọn trên scott.' | | tên_bảng | | ' vào vai trò_select; ' từ dba_tables nơi chủ sở hữu = 'SCOTT';
sql> @ privates.sql
sql> cấp vai trò_select cho john, sam, peter;

Điều này, kết hợp với GRANT CREATE TABLEvấn đề của người dùng lược đồ thích hợp với vai trò có nghĩa là các nhà phát triển có thể chọn và tạo các bảng. Nó không hoàn hảo vì một bảng được tạo yêu cầu chạy lại tập lệnh, nhưng WITH GRANT OPTIONgợi ý rằng mỗi nhà phát triển sau đó có thể cấp quyền truy cập vào bảng mà họ đã tạo cho vai trò phù hợp.

Điều này cho thấy rằng bạn có thể tạo các trình kích hoạt mức DDL có thể thực hiện quy trình cấp phù hợp, mặc dù số lượng thử nghiệm đáng kể rõ ràng là cần thiết, có thể làm cho câu lệnh tạo bảng tự động cấp quyền phù hợp cho các vai trò phù hợp.

Biên tập --

Theo GRANT , CREATE TABLEđặc quyền:

Tạo một bảng trong lược đồ của người được cấp.

Do đó, bằng cách cho họ tạo bảng, thay đổi bảng, v.v. từ người dùng chính xác, họ sẽ có thể truy cập vào lược đồ của người dùng đó như thể họ là người dùng phù hợp.