web-dev-qa-db-ja.com

異なるユーザー権限でストアドプロシージャからSSISパッケージを実行する

さまざまなレベルの特権が必要なため、ユーザーがSSISパッケージを合理的な方法で実行できるようにするには問題があります。

シナリオ：データウェアハウスを作成しました。データをロードする2つの異なるSSISパッケージがあり、1つは自動的に実行されます（SQLエージェントジョブを介して正常に動作します）。もう1つは、アップストリームデータが完成してクレンジングされたら、ユーザーがオンデマンドで実行する必要があります。

このパッケージは、実行開始時のデータベースのバックアップ（確実に、確実に）、計算されたテーブルの削除と再作成など、非常に特権的な操作を実行します。

[SSISDB]。[catalog]。[create_execution]および[SSISDB]。[catalog]。[start_execution]ストアドプロシージャを使用してこのジョブを実行するストアドプロシージャを記述しました。これは私のアカウントで実行すると正常に動作します（私はシステム管理者です）。

ストアドプロシージャは、SSISDBおよびMSDBで実行をエンキューするために必要なより高いレベルのアクセス許可のため、通常のユーザーが実行すると失敗し、パッケージ自体は（低）セキュリティコンテキストで実行されているため失敗しました。

私が試したこと：

ストアドプロシージャで「実行」を使用して問題を解決しようとしましたが、クロスデータベースチェーンの問題、信頼できるフラグなどが原因で失敗しました。

また、パッケージを実行するエージェントジョブを用意し、ストアドプロシージャからエージェントジョブを実行するだけで問題を解決しようとしましたが、次のような苦痛の世界に急速に突入しました。

  • ジョブごとに実行権限を設定できない
  • 中央のサーバーの役割を介してこのアクセスを構成して、時間の経過に伴うスタッフの変更に対応し、ジョブは所有者として1人のユーザーしか持つことができない
  • プロキシアカウントの暗い世界、クレデンシャルとsql-authログインの組み合わせなど

プランCおよびD

私に残っていると思う唯一のオプションは、昇格されたアクセス許可で専用のSQL Serverログインを作成し、ユーザーが信頼を渡さないようにする/インポートをスケジュールした人の監査能力を失うことです（この問題が他の領域でどのように解決されるか）組織）、またはユーザーが純粋に「サーバーロール」アカウントとして認証できるようにWebフロントエンドをカスタムビルドし、2番目の（特権）接続の下でWebアプリにストアドプロシージャを実行させます。

そう....

次の方法についてアドバイスはありますか？

  • sSISパッケージに特権操作を実行させる
  • 権限の低いユーザーが実行（AD Windowsアカウントを使用）
  • できれば、ジョブを実行するためのアクセスが中央のサーバーの役割を介して管理される場合（私はそれらの新しいWindowsグループを作成する簡単な機能を持っていません）
  • また、新しい中間/プロキシアカウントがSQL Server Authアカウントである場合（ADに変更を加えるための非常に限られた機能）

ここには多くの可動部品があることを理解しています（そして、ブレードが回転しているように感じる場合もあります）。他にも見逃した情報がある場合はお知らせください。

乾杯、ティム

編集...

そこで、今日、ssis_admin権限を持つ専用のSQL Serverログインを作成し、そのユーザーが所有する3つのSQL Serverエージェントジョブを作成し、エンドユーザーがexecute asに呼び出すストアドプロシージャをそのユーザーに更新しました。これは、SQL Serverログインとしてcreate executionを呼び出せないために失敗しました。Windowsアカウントが必要です。

ユーザーストアドプロシージャをexecute asに更新しました。SQLServerが（ADサービスアカウント）として実行されているWindowsアカウントにssis_adminを付与し、エラーで失敗しました

現在のセキュリティコンテキストを元に戻すことはできません。 「実行」が呼び出された元のデータベースに切り替えて、再試行してください。

これはどこにも速くはありません:(

sql-serversql-server-2014ssisssis-2014
14
Wokket

後世のために、私はこれを次の方法で機能させました：

  • ユーザー（Admin.RunImport）によって呼び出されたストアドプロシージャを変更して、SQLサービスが使用するアカウントを「実行」する
  • SQL Serverサービスアカウント（AD管理サービスアカウント）は、上記のexecute asの使用を許可する管理sprocを実行する権限を持つように変更されています
  • SQL Serverサービスアカウントは、ssisdb.ssis_adminおよびmsdb.SQlAgentOperatorロールを持つように変更されます。
  • このAdmin.RunImportストアドプロシージャは、渡されたパラメーターに依存するsp_start_jobを使用して、3つのエージェントジョブの1つをキューに入れます
    • 上記のssisセキュリティコンテキストエラーを回避するには、SQLエージェントを介したこのリダイレクトが必要です
    • エージェントジョブは「sa」が所有し、ジョブごとに異なるパラメーターを渡して、基になるストアドプロシージャ（Raw.hp_Execute_Import_Impl）を実行するだけです。
    • これは、上記のssis_admin特権により、スケジュールされたジョブと同じように、エージェントジョブがsaとして実行されることを意味します
  • Raw.hp_Execute_Import_Implストアドプロシージャは、SSISパッケージをsaとして通常と同じようにキューに入れます。

この目的のために専用のWindowsアカウントを作成できる代わりに、現時点で取得するのと同じくらい良いと思います。

助けてくれてありがとう！

2
Wokket