Déploiement du package SSIS et conservation d'un mot de passe de connexion

Question

J'ai un package SSIS qui interroge une vue pour certains enregistrements, puis envoie un courrier électronique à l'aide de la messagerie de base de données. Je veux déployer le package vers SQL Server dans lequel ces vues existent, puis nous planifier à l'aide de SQL Server Agent, mais j'ai rencontré un certain nombre de problèmes.

Le principal problème est que, dans le travail, un gestionnaire de connexions a stocké les informations d'identification d'un compte SQL Server qui a accès aux vues et au profil de messagerie. J'ai défini le package sur EncryptSensitiveWithPassword à la place de la clé utilisateur, mais je n'arrive pas à trouver un moyen de transmettre ce mot de passe à l'agent SQL Server lors de l'exécution du travail. Donc, quand il s'exécute, il échoue car il ne peut pas se connecter.

Un certain nombre de sites Web déclarent utiliser le fichier de configuration, mais lorsque j'emprunte cette route, le travail se brise complètement et se plaint que la connexion OLEDB ne peut pas être établie. Dans ce scénario, je ne peux même pas exécuter le travail sur ma machine localement. Quelques autres sites ont recommandé de copier le package dans le magasin de packages ssis local sur la machine, mais je n'ai accès qu'à la machine via les outils SQL Server, je ne peux pas y entrer ou installer quoi que ce soit sur le système de fichiers. avoir à installer via le fichier manifeste en utilisant le processus de déploiement SSIS.

J'ai lu quelque chose sur le stockage des paramètres dans une autre table DB, mais cela pose à nouveau des problèmes avec les autorisations sur le serveur.

Enfin, j'ai essayé de passer/mot de passe ou/décrypter dans le planificateur de travaux, mais quand je clique sur OK, le planificateur supprime ce paramètre.

Ceci est un serveur interne et la sécurité n'est pas vraiment une grande préoccupation, une idée de comment je peux passer le mot de passe de décryptage en clair ou simplement dire SSIS pour ne pas déranger la sécurisation des données sensibles?

Answer 1

Il semble que lorsque vous utilisez le fichier de configuration, vous ne configurez pas correctement le fichier de configuration.

Quelle est l'erreur exacte que vous recevez en l'exécutant localement? Je peux essayer de recréer le problème.

Answer 2

avez-vous le paquet mis en place dans les offres pour stocker les mots de passe, puis enregistrez le paquet à ssis et lui dire de crypter les mots de passe? Si vous ne les sauvegardez pas localement, il se peut que vous ayez perdu vos mots de passe, puis que vous ayez poussé le paquet sans eux.

Answer 3

L'astuce est:

• Lorsque vous enregistrez le package dans Business Intelligence SQL Server Management Studio, vérifiez que le Package Properties> ProtectionLevel est réglé sur EncryptSensitiveWithUserKey.
• Lorsque vous importez le package SSIS dans SQL Server (à partir de SQL Mgmt Studio> Explorateur d'objets> [serveur] Integration Services> Packages stockés> MSDB> cliquez avec le bouton droit> Importer package> Définir l'emplacement du package sur Système de fichiers, dans le chemin du package, et sélectionnez l'option "Fiez-vous sur le stockage du serveur et les rôles pour le contrôle d'accès" Je suppose que lors de l'importation du fichier .dtsx, vous devez être connecté en tant qu'utilisateur ayant enregistré le fichier .dtsx.

Cela signifie que le mot de passe est enregistré avec le package et peut donc être utilisé lorsque quelqu'un exécute le package. Si c'est quelque chose que vous ne voulez pas que quelqu'un vous exécute, puis verrouillez la sécurité de manière appropriée.Vous pouvez également modifier la connexion pour qu'elle utilise la sécurité intégrée (authentification Windows au lieu d'une connexion SQL) et modifier le travail afin qu'il exécute le package en tant qu'utilisateur ayant accès à la base de données interrogée par le package. Ceci est l'option préférée de l'avis que vous n'avez besoin d'aucun mot de passe et que vous le gérez à la place via l'identité de l'utilisateur et les permissions.