Các nhà phát triển có quyền nào trong cá thể cơ sở dữ liệu Dev

Question

... và các quyền đó sẽ được cấp như thế nào. Tôi làm việc trong một phòng CNTT lớn với hơn 70 ứng dụng, một số trong máy chủ SQL và hầu hết trong oracle. Mỗi hệ thống có một sản phẩm prod, QA và Dev. Chúng tôi (tôi là một nhà phát triển) có quyền truy cập chỉ đọc vào prod/qa, điều mà tôi ổn. Trong SQL devs phát triển máy chủ SQL được cho db_owner, mà hoạt động hoàn toàn tốt. Cuộc tranh luận là về những quyền mà tôi nên có trong cơ sở dữ liệu oracle DEV.

Tôi nhận ra rằng trường hợp tốt nhất sẽ có mỗi dev chạy cá thể riêng của họ trên máy trạm của họ để phát triển, nhưng vì kích thước của cơ sở dữ liệu này chưa được coi là một tùy chọn.

Tôi cũng quan tâm đến CÁCH các quyền này nên được áp dụng. Trong các điều khoản oracle được cấp thông qua một vai trò không hoạt động trong quá trình thực thi PL/SQL nên các vai trò (ngay cả vai trò "dba") không hữu ích. Rằng lá sử dụng một tài khoản được xây dựng (hệ thống) hoặc tạo ra hàng chục người dùng trên hàng chục cơ sở dữ liệu và trực tiếp cấp hàng chục quyền cho mỗi. Trong tâm trí của tôi chỉ cho phép các nhà phát triển đăng nhập như hệ thống là làm cho rất nhiều ý nghĩa, nhưng yêu cầu bồi thường DBA của chúng tôi đó là một ý tưởng tồi.

Answer 1

Chúng tôi đã từng chỉ cấp cho nhà phát triển quyền truy cập vào tài khoản ứng dụng. Điều này làm việc cho các cửa hàng nhỏ nhưng nhanh chóng được ra khỏi tay như số lượng các nhà phát triển tăng lên.

Dưới đây là những gì chúng ta làm gì bây giờ:

1. các Ứng dụng đã nó là tài khoản riêng (hay còn gọi là sơ đồ).
2. Nhà phát triển có tài khoản riêng của họ
3. dữ liệu cư trú trong lược đồ ứng dụng
4. Chúng tôi có một xây dựng kịch bản kiến ​​để xây dựng mã vào bất cứ điều gì giản đồ mà bạn muốn.
   • đang có tầm nhìn ra, bao bì, các đối tượng vv ..
   • xây dựng kịch bản bao gồm một bước để chạy một thủ tục lưu trữ để cấp quyền rõ ràng để các nhà phát triển ứng dụng dữ liệu
5. phát triển thực hiện thay đổi trong họ lược đồ riêng
6. Khi vui, họ kiểm tra xem lật đổ
7. Lược đồ dev của ứng dụng được xây dựng từ bản dựng lật đổ mới.
8. Nhà phát triển có thể xem và xây dựng lại môi trường của riêng họ.
9. DDL thay đổi cấu trúc bảng được thực hiện thông qua các DBA
   • này có thể được kịch bản cũng

này có lợi ích của bảo đảm bất kỳ ứng dụng kết thúc trước không bị phá vỡ bởi các nhà phát triển cơ sở dữ liệu liên tục xây dựng lại mọi thứ.

Answer 2

Một trong những công việc của DBA là quản lý đặc quyền người dùng. Tôi không nghĩ rằng hệ thống là một ý tưởng tốt cho một vài lý do, không ít nhất là khả năng để thả một toàn bộ lược đồ mà tôi chắc chắn bạn không muốn. Điều đó đang được nói, tôi nghĩ rằng nó là hoàn toàn tốt đẹp để cấp tất cả cho người dùng của bạn và để cho các quản trị viên cơ sở quản lý các quyền này cho dù có bao nhiêu chục tài khoản có thể có. Hầu hết các DBA sẽ có các tập lệnh mà họ có thể sử dụng để quản lý các quyền này.

Nghe DBA của bạn, họ thường biết họ đang nói về điều gì.

Answer 3

Nếu đó chỉ là một phiên bản gốc; tôi muốn tất cả người dùng đều có tài khoản cá nhân được thêm vào vai trò quản trị viên. Bằng cách đó bạn vẫn có thể đăng nhập hoạt động trên cơ sở mỗi người dùng; nhưng cung cấp cho các nhà phát triển đủ phòng thở để làm việc của họ.

Answer 4

Tôi giả sử rằng có một số lượng tương đối nhỏ các tài khoản ứng dụng sở hữu các đối tượng thực tế. Vì vậy, một hoặc nhiều ứng dụng hợp lý bao gồm các bảng thuộc sở hữu của một người dùng Oracle cụ thể. Điều này sẽ không phải bởi SYSTEM hoặc SYS, nó sẽ không là bất kỳ tài khoản mà Oracle công ty cung cấp. Đó sẽ là tài khoản mà DBA của bạn đã tạo. Nếu bạn đã quen thuộc với các lược đồ mẫu của Oracle, người dùng HR sở hữu tất cả các bảng trong lược đồ HR bao gồm phần cuối của một ứng dụng nhân sự.

Bắt đầu từ nguyên tắc "điều đơn giản nhất có thể có thể hoạt động", suy nghĩ đầu tiên của tôi là xem các nhà phát triển có thể đăng nhập trực tiếp vào các tài khoản ứng dụng đó không. Đây không phải là cấu hình có thể bảo mật nhất và bạn đang mở ra khả năng nhà phát triển vô tình hoặc cố ý thực hiện một số thiệt hại có thể khó theo dõi hoặc dễ dàng giải quyết. Nhưng nó có thể hoạt động khá tốt tùy thuộc vào tổ chức. Quản lý đặc quyền là tầm thường-- tài khoản chủ sở hữu ứng dụng đã có tất cả các đặc quyền cần thiết nhất.

Bước tiếp theo sẽ cho mỗi nhà phát triển một lược đồ riêng biệt để phát triển, có lẽ kết hợp với tải từ đồng nghĩa công khai trong cơ sở dữ liệu và không có sơ đồ vị trí trong mã ứng dụng. lược đồ của nhà phát triển tự động ghi đè phiên bản được chia sẻ của đối tượng đó. Điều này giúp cô lập tốt hơn nhiều. Quyền thường được cấp bằng cách tạo tập lệnh chứa tất cả các khoản tài trợ mà nhà phát triển cần hoặc bằng cách tạo tập lệnh sao chép tất cả đặc quyền từ tài khoản "được biết đến" sang tài khoản mới. Không khó để viết - bạn chỉ cần đảm bảo rằng tất cả các nhà phát triển đều có cùng một bộ đặc quyền, thường chỉ là một tập lệnh khác được chạy khi một đặc quyền mới được cấp.

Answer 5

Nhóm của tôi hỗ trợ khoảng 100 ứng dụng với khoảng 20 ứng dụng có lược đồ Oracle riêng của họ. Chúng tôi đã đi xuống con đường của mỗi nhà phát triển có mật khẩu cho giản đồ và nó là thuận tiện. Tuy nhiên, trong tầm nhìn xa, tôi khuyên bạn nên mỗi nhà phát triển sử dụng tài khoản Oracle của riêng mình để phát triển. Lý do chính là kiểm toán.

Answer 6

tôi nhận ra rằng trường hợp tốt nhất là nên có mỗi dev chạy dụ của mình trên máy trạm của họ cho sự phát triển, nhưng vì kích thước của cơ sở dữ liệu này chưa được coi một lựa chọn.

Có cách nào để giải quyết vấn đề này, có thể bằng cách giảm lượng dữ liệu trong bản sao cá nhân của bạn? Điều này có vẻ như giải pháp lý tưởng, vì nó sẽ cho phép bạn thực hiện bất kỳ thay đổi nào bạn cần. Sau đó, bạn có thể gửi chúng cho DBA khi bạn đã sẵn sàng và yêu cầu anh ấy cập nhật máy chủ phát triển được chia sẻ.

Answer 7

Nếu bạn đang phát triển các đối tượng PL/SQL được lưu trữ, thì lược đồ sở hữu các đối tượng đó cần, như bạn đã đề cập, các khoản tài trợ rõ ràng trên các đối tượng được sử dụng. Nếu bạn có một lược đồ 'dữ liệu' duy nhất nhưng đang phát triển mã trong lược đồ riêng của bạn thì bạn sẽ có khả năng cấp quyền truy cập vào các đối tượng lược đồ dữ liệu cho các lược đồ phát triển của bạn. Thông thường tôi mong đợi tên người dùng/mật khẩu cho lược đồ dữ liệu.

Về các đặc quyền hệ thống (ví dụ CREATE), tôi mong đợi TẠO TẠO, LOẠI, XEM, THỦ TỤC TRIGGER, SYNONYM. Những người khác có thể thích hợp (ví dụ: CONTEXT) tùy thuộc vào những gì bạn làm. DBA có thể loại trừ CREATE DIRECTORY vì điều đó có thể gây hại nếu sử dụng sai. Ditto cho các đặc quyền với BẤT CỨ trong chúng (ví dụ: BẤT K SELECT BẤT CỨ BẤT CỨ, XÓA BẤT K T BẢNG)

Để điều chỉnh hiệu năng/giám sát hệ thống, trên cơ sở dữ liệu dev SELECT_CATALOG_ROLE là tốt. Nếu DBA là rủi ro, bạn có thể phải thương lượng tài trợ trên các quan điểm cá nhân. Xem qua hướng dẫn REFERENCE cho phiên bản của bạn và yêu cầu bất kỳ phiên bản nào bạn có thể sử dụng.