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

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

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

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

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

私が試したもの：

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

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

• ジョブごとに実行許可を設定できない
• 中央のサーバーロールを介してこのアクセスを構成して、スタッフの経時的な変化に対応し、ジョブが所有者として1人のユーザーしか持つことができないようにしたい
• プロキシアカウントの暗い世界、sql-authログインなどと組み合わせた資格情報

プランCおよびD

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

そう....

以下の方法に関するアドバイスはありますか？

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

ここには多くの可動部品があることを理解しています（そして、一部は回転するブレードのように感じます）。

乾杯、ティム

編集...

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

ユーザーストアドプロシージャをexecute as、SQL Serverが（ADサービスアカウント）として実行されているWindowsアカウントに更新し、それssis_adminを許可するとエラーで失敗する

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

これはどこにも速く行きません:(

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

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

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

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