Cấp đặc quyền SA cho Nhà phát triển trên hộp phát triển


8

Bất chấp các cuộc biểu tình kịch liệt của chúng tôi, ban quản lý của chúng tôi đã quyết định rằng nhóm phát triển phải được cấp quyền 'sa' trên máy chủ phát triển. Điều hấp dẫn là chúng tôi, nhóm hỗ trợ DB vẫn chịu trách nhiệm duy trì hộp này.

Bây giờ chúng tôi đã được giao nhiệm vụ đưa ra một danh sách Dos và Don'ts cho các nhóm phát triển với các đặc quyền nâng cao này.

Vui lòng thêm vào danh sách này:

DO - giới hạn các hoạt động cho DB đang được phát triển

ĐỪNG --

  • thay đổi bất kỳ cài đặt SQL nào
  • sp_cool (bao gồm cả cmdshell)
  • thêm / thay đổi / xóa bất kỳ cài đặt bảo mật
  • thêm / thay đổi / xóa các đối tượng cơ sở dữ liệu
  • thêm / thay đổi / xóa các đối tượng máy chủ như thiết bị sao lưu và máy chủ được liên kết
  • thêm / thay đổi / xóa bản sao
  • thêm / thay đổi / xóa kế hoạch bảo trì
  • chạm vào bất kỳ cơ sở dữ liệu nào không thuộc về nhóm của bạn

Bất kỳ con trỏ đến các công cụ có sẵn để theo dõi các hoạt động của người dùng này sẽ được đánh giá rất cao.


1
Những nhiệm vụ nào họ cần thực hiện đòi hỏi phải có quyền riêng tư cao hơn của SA?

Tôi nghĩ rằng db_owner sẽ là tất cả những gì họ cần ...

5
OK, nếu họ được khuyên KHÔNG "thêm / thay đổi / xóa các đối tượng cơ sở dữ liệu", họ phải làm gì? Không phải toàn bộ vấn đề có một hộp phát triển là họ có thể phá vỡ nó không?
Stuart Ainsworth

Đây là những nhà phát triển ứng dụng. Họ cần đặc quyền 'sa' để có thể gỡ lỗi các thủ tục được lưu trữ trong Dev Studio. Quyết định đã được ban quản lý đưa ra và họ không sẵn sàng nhúc nhích. Chúng tôi đang cố gắng giảm thiểu cơn đau đầu tiềm năng

2
+1 cho câu hỏi, vì tôi đã gặp vấn đề đó một vài lần. Một giải pháp khác: Cung cấp cho các nhà phát triển một VM có hộp cát với SQL mà họ là ông chủ 100%. Họ cũng chịu trách nhiệm 100% cho việc duy trì sự sống :) -> thật đáng kinh ngạc khi các DEV học cách nhanh chóng không phá vỡ hệ thống của họ :)
Martin S. Stoller

Câu trả lời:


8

Nếu chưa quá muộn, một tùy chọn thỏa hiệp mà tôi đã thấy hoạt động tốt hơn là nâng cấp các quyền hoặc thay thế các tài khoản hiện có của nhà phát triển, tạo một tài khoản riêng chỉ được sử dụng khi họ cần các quyền nâng cao.

Vì vậy, thông thường chúng hoạt động trong các tài khoản "bị hạn chế" riêng lẻ (mà tôi sử dụng một cách lỏng lẻo vì các tài khoản bị hạn chế này vẫn cần một số quyền lớn - tức là tạo, thả, thay đổi cho các bảng). Nhưng trong dịp hiếm hoi đó khi họ nghĩ rằng họ cần sa, họ có thể đăng nhập bằng tài khoản này. Sau đó, bạn có thể gắn cờ tài khoản trong nhật ký của mình và theo dõi thêm về nó. Bạn đã cấp cho các nhà phát triển quyền truy cập mà họ yêu cầu, nhưng theo cách dễ kiểm soát hơn một chút.

Cuối cùng, nếu có lạm dụng, nhật ký trên tài khoản này có thể được sử dụng làm bằng chứng để lấy đi.


6

Nó nói rằng ở đây (MSDN) bạn cần sysadmin (sa) để gỡ lỗi trên SQL Server 2005.

Tuy nhiên, câu hỏi SO này cho thấy một cách khác mà không có sa, đó là những gì tôi nghĩ ban đầu. Đơn giản chỉ cần cho phép họ chạysp_sidedebug

Tôi cũng đề nghị cung cấp cho họ SQL Express cục bộ để giải quyết các vấn đề khác ...

(chỉnh sửa với nhiều thông tin hơn)

Chỉnh sửa, sau câu trả lời của W. Craig Trader

Các vấn đề khác với quyền "sa", trong trường hợp xấu nhất:

  • nhà phát triển sẽ tạo ra các hội đồng CLR không đáng tin cậy
  • họ sẽ sử dụng xp_cmdshell
  • tất cả các hành động trong bối cảnh của tài khoản dịch vụ máy chủ sql
  • họ sẽ đảm nhận quyền cho kết nối máy khách
  • Vân vân

ví dụ xp_cmdshell 'scm -Action 6 -Server PRODSERVER'


1
Câu trả lời cho các nhà phát triển mã bên ngoài các dòng là tích hợp liên tục với khóa bị khóa 'như sẽ được điều hành bởi quyền của người dùng và không xây dựng được. Yêu cầu máy chủ xây dựng tạo lại cơ sở dữ liệu từ đầu và điền dữ liệu thử nghiệm (tất nhiên là từ SCM). (Trong trường hợp của tôi, tôi đã sử dụng chính xác mã giống như trình cài đặt ứng dụng sẽ sử dụng để tạo cơ sở dữ liệu mới, do đó kiểm tra trình cài đặt cũng như ứng dụng.)

1
@Craig Trader: sẽ không làm việc. Để viết lại câu trả lời cũ của tôi, các nhà phát triển không thể tin tưởng được và integratiointegationsn sẽ không phát hiện ra tất cả các trường hợp. Tôi là một nhà phát triển dba: một con khỉ mã khách hàng là kẻ thù của tôi. Trong công ty của tôi, tôi giành chiến thắng .... đó là tập luyện của tôi và tôi đối phó với mẫu số chung thấp nhất ...
gbn

Rõ ràng, Mileage của bạn có thể khác nhau. Theo kinh nghiệm của tôi, tôi thường phải thực hiện một khóa đào tạo / định hướng nhỏ để giải thích cách thức và lý do tại sao mọi việc được thực hiện, nhưng sau đó mọi thứ thường chạy khá tốt. Tất nhiên, tôi luôn khẳng định rằng các bản dựng duy nhất vượt ra ngoài sự phát triển là những bản dựng đến từ máy chủ bản dựng được kiểm soát chặt chẽ - nếu mã không được xây dựng ở đó, thì đó là vấn đề với mã của bạn (hoặc các bài kiểm tra của bạn) không phải là cấu hình. Tôi đã thực hiện điều này với các nhóm nhỏ và các dự án lớn, trên nhiều công ty và luôn thành công.

4

Theo gợi ý tôi có là thiết lập Quản lý dựa trên chính sách và thực thi tất cả 'làm' và 'không' của bạn làm quy tắc chính sách. Điều này sẽ đi một chặng đường dài để bảo vệ ví dụ.

Tôi cũng sẽ triển khai DDL thay đổi kiểm toán, xem Kiểm toán trong SQL Server 2008 , không quá nhiều như một răn đe, nhưng chủ yếu như một hệ thống thay đổi theo dõi nên khi một cái gì đó đang hơi say, ít nhất bạn sẽ biết những gì thay đổi.


3

Nếu đó là máy chủ PHÁT TRIỂN, thì vấn đề gì với các NHÀ PHÁT TRIỂN có thể có quyền truy cập đầy đủ? Nói với các nhà phát triển rằng bạn không thể thêm / xóa / thay đổi các đối tượng cơ sở dữ liệu (ví dụ: bảng, cột, chỉ mục) giống như nói với họ "Bạn có thể có trình biên dịch, nhưng bạn không được phép chạy nó". Đối với tôi, dường như các nhà phát triển muốn / cần truy cập vào cá thể cơ sở dữ liệu của riêng họ để cho phép họ thử nghiệm các phương pháp giải quyết vấn đề khác nhau mà KHÔNG cần phải xử lý với cơ sở dữ liệu SẢN XUẤT hoặc TEST. Bạn nên khuyến khích loại hành vi đó, không làm nản lòng nó.

Một số người có thể đề xuất rằng các nhà phát triển làm việc với các phiên bản SQL Express cục bộ, nhưng trong khi SQL Express cho mỗi nhà phát triển có thể giải quyết một số vấn đề nhất định, thì nó có các hạn chế và đặc tính hiệu suất khác với SQL Server đầy đủ trên một máy chủ riêng biệt.

Những gì bạn NÊN làm là lập một lịch trình sao lưu thường xuyên (ít nhất là hàng đêm) và làm việc với các nhà phát triển để đảm bảo rằng họ biết cách bắt đầu sao lưu dự phòng và khôi phục từ các bản sao lưu, để giảm thời gian ngừng hoạt động trong trường hợp xảy ra sự cố.


Sự tương tự của bạn là hoàn toàn sai. Điều gì xảy ra là chúng lẩn quẩn xung quanh và sau đó rên rỉ khi chúng không thể di chuyển mucking xung quanh đến các máy chủ bị khóa. Tôi là một nhà phát triển DBA tất nhiên :-)
gbn

Sau đó, một chút giáo dục là theo thứ tự. Tôi là một nhà phát triển đã từng là một DBA quá thường xuyên. Với một chân ở cả hai thế giới, công việc của tôi là dạy cả hai bên cùng tồn tại. Rốt cuộc, đó là những NGƯỜI DÙNG là kẻ thù, không phải là DBA hay Nhà phát triển ...

Ngoài ra còn có những thứ như kế hoạch bảo trì mà họ không nên truy cập.
Joel Coehoorn

1
Vấn đề là, chúng tôi có nhiều nhóm Dev và máy chủ này lưu trữ tất cả các DB của họ. Nhóm này yêu cầu quyền 'sa' chỉ sở hữu 33% số Dbs. Mối quan tâm là họ có thể làm hỏng và đưa máy chủ xuống, ảnh hưởng đến các nhóm khác. Công ty không muốn có phần cứng riêng cho họ, trừ khi chúng tôi có thể chứng minh rằng họ đã làm hỏng việc.

2
Điều đó thật nực cười. Mỗi nhóm phát triển nên có máy chủ của riêng mình, để không ai bước lên bất kỳ ai. Phần cứng ngày nay là thực tế miễn phí, và phần mềm gần như rẻ như phần cứng. Và nếu tổ chức của bạn đủ lớn để có nhiều nhóm phát triển, thì nên sử dụng ảo hóa máy chủ, điều này sẽ làm cho tất cả điều này trở nên dễ dàng hơn.

3

Đó là máy chủ dev , không phải máy chủ nhóm hỗ trợ DB hoặc máy chủ sản xuất. Giữ một bản sao lưu / hình ảnh tốt và để các nhà phát triển hack đi. Để DBA kiểm soát devbox giống như để đuôi vẫy chó. Nó có cho các nhà phát triển để làm công việc phát triển. Điều này liên quan đến việc phá vỡ mọi thứ đôi khi và làm rơi các bảng, sau đó đặt chúng trở lại với các cài đặt khác nhau. Các hộp dev luôn trong tình trạng hư hỏng sau một lúc, đó là những gì chúng ta làm. Nếu chúng ta không biết vấn đề đang xảy ra ở đâu, chúng ta sẽ thử những thứ khác nhau. Một số trong số chúng dễ dàng hoàn tác, một số không quá nhiều.


Vấn đề ở đây là các nhà phát triển dễ dàng quên rằng các ứng dụng họ xây dựng sẽ không có quyền giống nhau mọi lúc. Có, đưa cho họ sa, nhưng làm cho họ không mặc định, để họ nhận thức được khi họ đang làm gì đó sẽ cần thêm một chút công việc để triển khai đúng cách.
Joel Coehoorn

1

Tôi không nghĩ rằng họ cần đặc quyền SA trên hộp Phát triển. Trong hầu hết các trường hợp, họ có thể làm mà không cần.

Tôi nghĩ rằng một lựa chọn tốt là cài đặt phiên bản dev cục bộ.

câu hỏi:

Bạn không muốn các nhà phát triển thêm / thay đổi / xóa các đối tượng cơ sở dữ liệu? !! Họ sẽ phát triển như thế nào?


Xin lỗi về sự nhầm lẫn. Điều tôi muốn nói là điểm đạn đó là các nhà phát triển không được thay đổi cài đặt cơ sở dữ liệu hoặc bỏ cơ sở dữ liệu.

1

Chúng tôi yêu cầu tất cả các thay đổi cấu trúc cơ sở dữ liệu phải được thực hiện với các tập lệnh (ngay cả trên dev) và được lưu trong lật đổ. Sau đó, trên một lịch trình được thiết lập, chúng tôi làm mới dev từ prod và họ phải chạy lại các tập lệnh của họ để quay lại vị trí của chúng trong chu kỳ phát triển. Điều này giúp đảm bảo rằng mọi thứ được thực hiện thông qua các tập lệnh và chúng có sẵn các tập lệnh khi đến lúc triển khai.

Tôi biết năm 2008 bạn có thể thiết lập DDL Triggers để theo dõi các thay đổi cấu trúc cơ sở dữ liệu, bạn có thể làm điều này vào năm 2005 không? Bằng cách này, ít nhất bạn có thể tìm ra khi ai đó thay đổi cài đặt đã thực hiện và tìm hiểu lý do tại sao.


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.