Bất kỳ gợi ý nào về việc giảm đặc quyền của tôi trong sản xuất nhưng không làm cho công việc của tôi quá khó khăn

Chạy SQL Server 2005 và 2008 trên Windows 2008 R2.

Chúng tôi sẽ giảm các đặc quyền trong sản xuất cho các nhà phát triển - và tôi muốn làm điều tương tự với bản thân mình như một DBA , hạn chế quyền sản xuất và nâng cao khi được yêu cầu .

Mục tiêu chính của tôi sẽ là loại bỏ những sai lầm ngu ngốc - được tạo ra bởi các DBA , những người sùng đạo sẽ có quyền truy cập đọc trong sản xuất nhiều nhất. Chúng tôi thích hành động như chúng ta là những siêu anh hùng không thể phạm sai lầm, nhưng không có quyền sản xuất mọi lúc có ý nghĩa và đó là một thực tiễn tốt nhất, được một số người khuyên dùng.

Cách tiếp cận tốt nhất là gì? Điều gì sẽ ít đau đớn nhất để sử dụng hàng ngày và trong khi cài đặt?

Chúng tôi hiện có một nhóm cửa sổ cho các DBA có quyền đối với tất cả các máy chủ và cơ sở dữ liệu của chúng tôi.

Tôi cũng quan tâm đến việc giảm quyền đăng nhập hệ điều hành / từ xa - nhưng tôi quan tâm nhất đến quyền DB.

Tôi đoán rằng chúng tôi sẽ cần các tư nhân nâng cao để chạy dấu vết như sa, và có thể để dọn dẹp quyền sở hữu trước khi chúng tôi lấy đi quyền SA đăng nhập cũ của chúng tôi. Những vấn đề khác chúng ta có thể mong đợi?

Cảm ơn lời khuyên của bạn và chia sẻ kinh nghiệm của bạn!

Lý tưởng nhất, đối với cơ sở dữ liệu sản xuất hoạt động, bạn không muốn các nhà phát triển có quyền truy cập vào máy chủ hoặc bất kỳ cơ sở dữ liệu nào trên đó. Điều đó là một trong những điều đầu tiên bạn sẽ phải làm để tuân thủ SOX .

Đối với các loại quyền mà userIds chạy theo, quyền duy nhất mà họ thực sự cần phải là db_datareader, db_datawritervà rõ ràng GRANT EXECUTE ON x TO y(đối với từng proc lưu trữ và chức năng người dùng định nghĩa xcho userID y).

Nếu bạn cần chạy dấu vết trong sản xuất, bạn có một số vấn đề và sẽ phải mất một Great Wall of Text ™ để giải thích tất cả. Đề nghị đầu tiên của tôi là có một môi trường QA bị khóa giống như sản xuất và nếu cần phải chạy dấu vết, hãy khôi phục bản sao lưu của prod db thành QA và chạy các dấu vết ở đó. Một lần nữa, nếu bạn có các yêu cầu SOX, HIPAA hoặc PCI-DSS , thì bạn nên vệ sinh tốt hơn dữ liệu prod trước khi khôi phục nó thành QA.

Chúng tôi hiện có một nhóm cửa sổ cho các DBA có quyền đối với tất cả các máy chủ và cơ sở dữ liệu của chúng tôi.

Cung cấp cho họ đăng nhập và xem quyền dữ liệu; tuy nhiên để thực hiện các nhiệm vụ DBAly, hãy sử dụng thông tin đăng nhập riêng với các đặc quyền nâng cao. Tôi biết một khách hàng tài chính thực hiện điều này - thông tin đăng nhập dựa trên xác thực của windows thường bị hạn chế về thiệt hại mà họ có thể vô tình gây ra. Khôi phục và chạy DML cần thiết khi chạy với đăng nhập xác thực SQL riêng.

Một cơ quan chính phủ tôi đã làm việc với 2 lần đăng nhập riêng cho mỗi máy chủ / quản trị viên db. Vì vậy, nếu Tangurenađăng nhập tên miền của tôi (đăng nhập này sẽ có Userđặc quyền thường xuyên ), thì đó TangurenaAdminsẽ là Administratorđăng nhập riêng của tôi . Bạn sẽ gặp rắc rối nếu bạn sử dụng tài khoản quản trị viên của mình mọi lúc, nhưng sau đó nó thiếu quyền đối với những thứ khác (như không có email. Ồ, bạn nói rằng đó là một điều xấu ... ).

Cơ quan chính phủ hiện tại tôi đang làm việc có mỗi quản trị viên máy chủ / db có các đặc quyền được nâng cao hơn người dùng chuẩn, nhưng không hoàn toàn là quản trị viên (hãy coi đó là PowerUsernhóm). Chức năng quản trị miền được thực hiện với tài khoản quản trị miền được chia sẻ.

Một lỗi phổ biến là khôi phục cơ sở dữ liệu sai (như QA được khôi phục trên máy chủ sản xuất) và điều này sẽ không được giải quyết thông qua quyền hạn chế hoặc nhiều lần đăng nhập. Làm những việc có khả năng phá hủy theo cặp là một cách để giảm thiểu rủi ro.

Tôi đoán chúng ta sẽ cần những người tư nhân cao để chạy dấu vết như sa

Không. Bạn chỉ cần quyền ALTER TRACE:
http://msdn.microsoft.com/en-us/l Library / ms187611.aspx

Đầu tiên, tôi khuyên bạn nên thực hiện tất cả các trò chơi đặc quyền trong môi trường phát triển hoặc QA, nơi không có vấn đề gì nếu quyền truy cập bị xóa trong một thời gian. Bạn sẽ cần phải xem các ứng dụng sẽ không có bất kỳ vấn đề nào với bảo mật.

Tôi sẽ cho bạn biết cách tiếp cận nội bộ của chúng tôi:

• tất cả các ứng dụng sử dụng một người dùng miền duy nhất được cấp quyền cần thiết trên cơ sở dữ liệu (thường là vai trò cơ sở dữ liệu db_owner).

• để đọc dữ liệu không thường xuyên, chúng tôi sử dụng thông tin đăng nhập SQL. Đối với người dùng đó, chúng tôi gán vai trò cơ sở dữ liệu - db_datareader. Đây là nơi nó kết thúc quyền truy cập cho các nhà phát triển trên cụm cơ sở dữ liệu chính. Đối với bất kỳ ý tưởng nào khác họ sẽ có, họ sẽ sử dụng cơ sở dữ liệu máy chủ báo cáo là bản sao (được thực hiện bằng Log Shipping) của cơ sở dữ liệu máy chủ chính được thực hiện vào nửa đêm. Để không giết máy chủ báo cáo với các truy vấn ad hoc kẻ giết người, chúng tôi sử dụng phân bổ nhóm tài nguyên cho bộ nhớ và cpu.

• đối với nhóm DBA, chúng tôi có một nhóm miền có tất cả các đặc quyền trên máy và máy chủ (quản trị viên trên máy windows và sysadmin trên máy chủ sql)

• để cài đặt, chúng tôi có người dùng SQL là db_owner trên cơ sở dữ liệu mà chúng tôi sử dụng khi chạy các bản cập nhật - chúng tôi sử dụng trình kích hoạt DDL để theo dõi các thay đổi của lược đồ và chúng tôi sẽ xem những thay đổi nào được thực hiện trong khi cài đặt hoặc là thay đổi riêng biệt

• thỉnh thoảng có một số trường hợp ngoại lệ cho các nhà phát triển có kinh nghiệm, nhưng sau khi nhu cầu của họ được đáp ứng, chúng tôi xóa quyền truy cập của họ - họ nhận được quyền dựa trên thông tin đăng nhập tên miền của họ, vì vậy chúng tôi có thể theo dõi các kết nối trong chế độ xem dấu vết / ddl và mọi thay đổi có thể xảy ra với trình kích hoạt ddl.

Đối với cách thực hiện tất cả những gì hoạt động với thông tin đăng nhập và người dùng - trong Management Studio trong thư mục bảo mật máy chủ, bạn tạo tất cả các thông tin đăng nhập cần thiết, sau đó, bạn liên kết chúng với cơ sở dữ liệu của bạn và cung cấp cho họ vai trò họ cần. Nếu bạn viết kịch bản hành động, bạn sẽ thấy rằng ban đầu nó sẽ được tạo đăng nhập máy chủ, sau đó người dùng cơ sở dữ liệu được kết nối với thông tin đăng nhập đó, sau đó gán vai trò cơ sở dữ liệu cho người dùng đó. Bạn có thể giữ tập lệnh trong tập lệnh của mình, vì vậy bạn có thể xác minh mỗi lần người dùng nào nên trực tiếp và đá và điều gì không nên.

Trong máy chủ SQL, bạn có thể tạo người dùng cơ sở dữ liệu và gán cho nó một quyền database roleđọc / ghi / quyền sở hữu. Khi người dùng được di chuyển đến sản xuất, bạn có thể chuyển đến người dùng cơ sở dữ liệu đã được di chuyển và bỏ kiểm tra các vai trò mà bạn không muốn nó có. Ví dụ: giả sử stan người dùng là thành viên của db_owner (quyền sở hữu cơ sở dữ liệu) trong thử nghiệm. Khi stan người dùng được di chuyển sang sản xuất, bạn có thể lấy nó ra khỏi db_owner và chỉ gán một vai trò của db_datareader (chỉ đọc) cho nó.

Trong SQL 2005+ điều khiển chi tiết hơn có thể được thực hiện với schema. Kiểm tra liên kết này trên lược đồ để biết thêm chi tiết.