Thực thi Gói SSIS từ một quy trình được lưu trữ với các đặc quyền người dùng khác nhau


14

Tôi gặp vấn đề với việc cho phép người dùng của mình thực thi Gói SSIS một cách hợp lý do các mức đặc quyền khác nhau được yêu cầu.

Kịch bản : chúng tôi đã tạo một kho dữ liệu, với hai gói SSIS khác nhau chịu trách nhiệm tải dữ liệu, một gói sẽ được chạy tự động (thông qua công việc Tác nhân SQL và đang hoạt động tốt) và một gói khác phải được chạy trên- nhu cầu của người dùng một khi dữ liệu ngược dòng được hoàn thiện và làm sạch, v.v.

Gói này thực hiện các hoạt động rất đặc quyền bao gồm sao lưu cơ sở dữ liệu khi bắt đầu chạy (để chắc chắn, chắc chắn), bỏ và tạo lại các bảng được tính toán, v.v.

Tôi đã viết một thủ tục được lưu trữ để thực thi công việc này thông qua [SSISDB]. [Danh mục]. [Tạo_execut] và [SSISDB]. [Danh mục]. [Start_execut] các thủ tục được lưu trữ .... điều này hoạt động tốt khi chạy trong tài khoản của tôi (Tôi là một sysadmin).

Quy trình được lưu trữ không thành công khi được chạy bởi người dùng bình thường do mức độ yêu cầu cao hơn trong SSISDB và MSDB để thực hiện việc thực thi và bản thân gói không thành công vì nó chạy trong bối cảnh bảo mật (thấp) của chúng.

Những gì tôi đã thử :

Tôi đã cố gắng giải quyết vấn đề bằng cách sử dụng 'Thực thi As' trong quy trình được lưu trữ, tuy nhiên điều này không thành công do các vấn đề xâu chuỗi cơ sở dữ liệu chéo, cờ đáng tin cậy, v.v.

Tôi cũng đã cố gắng giải quyết vấn đề bằng cách có các công việc Đại lý để chạy gói và chỉ chạy công việc đại lý từ thủ tục được lưu trữ, tuy nhiên tôi nhanh chóng bước vào một thế giới đau đớn liên quan đến:

  • Không thể đặt quyền thực thi trên cơ sở mỗi công việc
  • Hy vọng sẽ định cấu hình quyền truy cập này thông qua Vai trò Máy chủ trung tâm để phục vụ thay đổi nhân viên theo thời gian và công việc chỉ có thể có một người dùng là chủ sở hữu
  • Thế giới đen tối của tài khoản Proxy, Thông tin kết hợp với thông tin đăng nhập sql-auth, v.v.

Kế hoạch C và D

Các tùy chọn duy nhất tôi có thể nghĩ đến còn lại với tôi là tạo Đăng nhập máy chủ SQL chuyên dụng với quyền nâng cao và tin tưởng người dùng không vượt qua thông tin đăng nhập xung quanh / mất khả năng kiểm toán của người đã lên lịch nhập (cách giải quyết vấn đề này trong các lĩnh vực khác tổ chức) hoặc tùy chỉnh xây dựng giao diện người dùng web hoàn toàn để cho phép người dùng xác thực là tài khoản 'Vai trò máy chủ' của họ và sau đó để ứng dụng web chạy quy trình được lưu trữ trong kết nối thứ hai (đặc quyền).

Vì thế....

Có lời khuyên nào về cách làm:

  • có gói SSIS thực hiện các hoạt động đặc quyền
  • được thực thi bởi người dùng có đặc quyền thấp (sử dụng tài khoản cửa sổ AD)
  • tốt nhất là nơi quyền truy cập để chạy công việc được quản lý thông qua Vai trò máy chủ trung tâm (Tôi không có khả năng dễ dàng tạo nhóm cửa sổ mới cho họ)
  • và trong đó bất kỳ tài khoản mới, trung gian / proxy nào đều là tài khoản SQL Server Auth (một lần nữa, khả năng rất hạn chế để thực hiện các thay đổi đối với AD)

Tôi hiểu rằng có rất nhiều bộ phận chuyển động ở đây (và một số cảm giác như lưỡi dao quay) vì vậy hãy cho tôi biết nếu có bất kỳ thông tin nào khác mà bạn cảm thấy đã bỏ lỡ.

Chúc mừng, Tim

Biên tập....

Vì vậy, hôm nay tôi đã tạo một đăng nhập SQL Server chuyên dụng với quyền ssis_admin, tạo ba công việc Đại lý SQL Server do người dùng đó sở hữu và cập nhật quy trình được lưu trữ mà người dùng cuối của tôi gọi cho execute asngười dùng đó. Điều này không thành công do không thể gọi create executionlà đăng nhập SQL Server, nó yêu cầu tài khoản windows.

Tôi đã cập nhật quy trình lưu trữ của người dùng vào execute astài khoản Windows SQL Server đang chạy dưới dạng (tài khoản dịch vụ quảng cáo), được cấp ssis_adminvà không thành công với lỗi

Bối cảnh bảo mật hiện tại không thể được hoàn nguyên. Vui lòng chuyển sang cơ sở dữ liệu gốc nơi 'Thực thi As' đã được gọi và thử lại.

Điều này không đi đâu nhanh cả :(


1) Họ có phải khởi chạy các gói thông qua create_execution tức là họ có cần chỉ định tham số khi thực hiện cho "kịch bản sẵn sàng của dữ liệu không?" 2) An toàn khi cho rằng bạn không quan tâm đến việc đặt chúng vào vai trò ssis_admin?
billinkc

1) Tôi đang sử dụng create_executionvì tôi cần truyền một tham số (một trong ba giá trị) từ sproc vào công việc. Tôi rất vui khi có ba sprocs / công việc, vv nếu điều đó giải quyết nó. 2) Nếu ssis_admin là vai trò đặc quyền thấp nhất đưa tôi đến đó, thì tôi sẽ mở nó ra ... tốt hơn là sysadmin ít nhất và giải quyết chúng vô tình làm rơi / vứt bỏ các bảng kho trong sử dụng chung.
Wokket

Các ssis_adminvai trò sẽ cho phép họ để chạy các gói SSIS (procs kiểm tra các thành viên trong sysadmin hoặc ssis_admin vai trò) nhưng tôi nghĩ rằng nó sẽ chạy như họ và do đó không thể sao chép lại và như vậy. (Tôi phải kiểm tra chắc chắn rằng, không bao giờ có thể nhớ nếu nó chạy như họ hoặc tài khoản dịch vụ SQL Server). Tuy nhiên, việc trở thành thành viên của ssis_admin cho phép họ triển khai các gói và kết hợp với các cấu hình có thể hoặc không phải là một điều tốt. Năm 2016 cho chúng ta nhiều vai trò chi tiết hơn nhưng rõ ràng không được sử dụng nhiều ở đây
billinkc

Tôi nghĩ rằng ít rủi ro nhất sẽ có 3 công việc được mã hóa cứng sử dụng kết hợp chính xác người dùng / tài khoản được ủy quyền để đạt được trạng thái ít đặc quyền nhất. Sau đó, tôi sẽ xem xét cấp cho những người dùng đó khả năng chạy công việc hoặc chặn điều đó, tạo ba procs sử dụng EXECUTE ASđể cho phép họ chạy các công việc cụ thể thông qua sp_start_job. Gã nói internet ngẫu nhiên người là khủng khiếp tại an ninh
billinkc

@billinkc Tôi nghĩ ssis_operator sẽ làm
Tom V - Đội Monica

Câu trả lời:


2

Đối với hậu thế tôi đã làm việc này thông qua như sau:

  • Thay đổi thủ tục được lưu trữ được gọi bởi người dùng ( Admin.RunImport) thành 'Thực thi dưới dạng' tài khoản được sử dụng bởi Dịch vụ SQL
  • Tài khoản dịch vụ SQL Server (tài khoản Dịch vụ được quản lý AD) được sửa đổi để có quyền thực thi lệnh Quản trị viên cho phép sử dụng execute asở trên
  • Tài khoản dịch vụ SQL Server được sửa đổi để có các vai trò ssisdb.ssis_admin và msdb.SQlAgentOperator.
  • Quy Admin.RunImporttrình được lưu trữ này xếp hàng một trong 3 Công việc Tác nhân bằng cách sử dụng sp_start_jobphụ thuộc vào tham số đã truyền
    • Chuyển hướng này thông qua Đại lý SQL là bắt buộc để bỏ qua lỗi bối cảnh bảo mật ssis ở trên
    • Các công việc tác nhân được sở hữu bởi 'sa' và chỉ cần thực hiện một thủ tục được lưu trữ bên dưới ( Raw.hp_Execute_Import_Impl) truyền vào một tham số khác nhau cho mỗi công việc.
    • Điều này có nghĩa là công việc Đại lý chạy sado đặc quyền ssis_admin ở trên, giống như các công việc được lên lịch
  • Quy Raw.hp_Execute_Import_Impltrình được lưu trữ xếp hàng Gói SSIS sagiống như bình thường.

Thay vì có thể tạo các tài khoản windows chuyên dụng cho mục đích này, tôi nghĩ rằng điều này tốt như tôi sẽ nhận được vào lúc này.

Cảm ơn anh em về sự giúp đỡ!


2
Cảm ơn đã trở lại và đăng giải pháp. Bây giờ khi bạn gặp vấn đề này một lần nữa và quên đi những gì bạn đã làm, bạn có thể tìm kiếm trên web và bạn sẽ tìm thấy giải pháp của riêng mình!
Nick.McD Nàng tiên cá
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.