Je rencontre des problèmes pour permettre à mes utilisateurs d'exécuter des packages SSIS de manière raisonnable en raison des différents niveaux de privilèges requis.
Le scénario : nous avons créé un entrepôt de données, avec deux packages SSIS différents chargés de le charger avec des données, l'un doit être exécuté automatiquement (via un travail de l'Agent SQL et fonctionne correctement), et un autre doit être exécuté sur - demande des utilisateurs une fois les données en amont finalisées et nettoyées, etc.
Ce package effectue des opérations très privilégiées, notamment la sauvegarde de la base de données au début de l'exécution (pour être sûr, pour être sûr), la suppression et la recréation des tables calculées, etc.
J'ai écrit une procédure stockée pour exécuter ce travail via les procédures stockées [SSISDB]. [Catalogue]. [Create_execution] et [SSISDB]. [Catalogue]. [Start_execution] .... cela fonctionne très bien lorsqu'il est exécuté sous mon compte (Je suis un administrateur système).
La procédure stockée a échoué lorsqu'elle est exécutée par un utilisateur normal en raison du niveau plus élevé d'autorisations requises dans SSISDB et MSDB pour mettre en file d'attente l'exécution, et le package lui-même a échoué car il s'exécute dans son contexte de sécurité (modeste).
Ce que j'ai essayé :
J'ai essayé de résoudre le problème en utilisant `` Exécuter en tant que '' dans la procédure stockée, mais cela a échoué en raison de problèmes de chaînage entre bases de données, d'un indicateur de confiance, etc.
J'ai également tenté de résoudre le problème en ayant des travaux d'agent pour exécuter le package et en exécutant simplement le travail d'agent à partir de la procédure stockée, mais je suis rapidement entré dans un monde de douleur impliquant:
- L'incapacité à définir des autorisations d'exécution sur une base par tâche
- L'espoir de configurer cet accès via un rôle de serveur central pour répondre au changement de personnel au fil du temps, et les emplois ne peuvent avoir qu'un seul utilisateur en tant que propriétaire
- Le monde sombre des comptes proxy, des informations d'identification en combinaison avec les connexions sql-auth, etc.
Plans C et D
Les seules options auxquelles je peux penser me restent sont de créer une connexion SQL Server dédiée avec des autorisations élevées et de faire confiance aux utilisateurs pour ne pas transmettre les informations d'identification / perdre l'auditabilité de la personne qui a planifié l'importation (comment ce problème est résolu dans d'autres domaines de l'organisation), ou créez un frontal Web uniquement pour permettre aux utilisateurs de s'authentifier en tant que compte `` Rôle serveur '', puis laissez l'application Web exécuter la procédure stockée sous une seconde connexion (privilégiée).
Donc....
Y a-t-il des conseils sur la façon de:
- demander à un package SSIS d'effectuer des opérations privilégiées
- exécuté par un utilisateur peu privilégié (à l'aide d'un compte Windows AD)
- de préférence où l'accès pour exécuter le travail est géré via un rôle serveur central (je n'ai pas la possibilité facile de créer un nouveau groupe de fenêtres pour eux)
- et où tous les nouveaux comptes intermédiaires / proxy sont des comptes SQL Server Auth (encore une fois, la capacité très limitée de modifier l'AD)
Je comprends qu'il y a beaucoup de pièces mobiles ici (et certaines se sentent comme des lames qui tournent) alors faites-moi savoir s'il y a d'autres informations que vous pensez avoir manquées.
À la vôtre, Tim
Éditer....
Aujourd'hui, j'ai donc créé une connexion SQL Server dédiée avec les autorisations ssis_admin, créé trois tâches SQL Server Agent appartenant à cet utilisateur et mis à jour la procédure stockée que mes utilisateurs finaux appellent execute ascet utilisateur. Cela a échoué en raison de l'impossibilité d'appeler en create executiontant que connexion SQL Server, cela nécessite un compte Windows.
J'ai mis à jour la procédure stockée des utilisateurs sur execute asle compte Windows que SQL Server exécute en tant que (un compte de service AD), je l'ai accordé ssis_adminet il échoue avec l'erreur
Le contexte de sécurité actuel ne peut pas être inversé. Veuillez basculer vers la base de données d'origine où «Exécuter en tant que» a été appelé et réessayer.
Cela ne va nulle part rapidement :(
create_executionparce que j'ai besoin de passer un paramètre (l'une des trois valeurs) du sproc au travail. Je suis heureux d'avoir trois sprocs / jobs etc si cela le résout. 2) Si ssis_admin est le rôle de privilège le plus bas qui m'y amène, je suis ouvert à cela ... c'est mieux que sysadmin au moins et les résout en supprimant accidentellement / nuking les tables d'entrepôt en général.
ssis_adminrôle leur permettrait d'exécuter les packages SSIS (les procs vérifient l'appartenance aux rôles sysadmin ou ssis_admin) mais je pense que ça va fonctionner comme eux et donc pas capable de prendre des sauvegardes et autres. (Je devrais tester cela à coup sûr, je ne me souviens jamais s'il fonctionne comme eux ou le compte de service SQL Server). Cependant, être membre de ssis_admin leur permet de déployer des packages et de se débrouiller avec des configurations qui peuvent être ou non une bonne chose. Le 2016 nous donne des rôles plus granulaires mais évidemment pas très utiles ici
EXECUTE ASpour leur permettre d'exécuter les travaux spécifiques via sp_start_job. Dit le gars d'Internet au hasard qui est terrible à la sécurité
create_executionie ont -ils besoin de spécifier des paramètres lors de l'exécution pour leur "scénario prêt pour les données"? 2) Peut-on supposer que vous n'êtes pas intéressé à les placer dans le rôle ssis_admin?