1. 1 SQL Server 2005 Security An Approach For Group Level Management of Jobs and Packages In a SQL Server 2005 Shared Environment for Application Developers © Eastman Kodak Company, 2009

2. 2 In order to provide the proper access to SQL Server 2005 SSIS packages and SQLAgent jobs, the instance must be properly configured, and development teams will need to perform specific actions and adhere to standards. The methodology for managing jobs and packages identified in this document allows access to be restricted by application as well as by role or by application support sub-team. In order for this to work, all teams in the shared environment must be configured using this methodology and adhere to these standards. Any project that is given elevated authority, such as “sysadmin” privilege, has access to all jobs and packages for all applications on the instance. SQL Server 2005 Application Team Job & Package Management

3. 3  Casual, one-time, or ad-hoc SSIS packages should be executed from SQL Server 2005 Business Intelligence Development Studio (BIDS). If the ad-hoc package needs to be saved, it should be stored in an application folder, or in a source code version control application such as Microsoft Visual Source Safe (VSS). These types of packages should not be deployed to the msdb database for the SQL Server 2005 instance, or setup to run via a SQL Agent job.  SSIS packages that need to be run on a recurring basis may be deployed to the application team folder in the msdb database for the SQL Server 2005 instance. A SQL Agent job may be created to schedule the SSIS package to run at specific times. All of the conventions identified further below should be observed when deploying the SSIS package and creating the SQLAgent job.  SSIS packages that are deployed, and any SQLAgent jobs that run them, must be created first in a non- production SQLServer 2005 instance and fully tested there before deploying them in a production SQLServer 2005 instance. Where separate development and QA environments exist, the SSIS package and its related SQLAgent job should be created and unit tested first in the development environment, then deployed to the QA environment and tested (for integration with other parts of the application and for volume testing), then deployed to the Production environment. If a source code version control application is being used by the application support team, deployment to QA and Production should be done from the correct version of the package in the code library, rather than from the copy of the package in development, which assumes the package has been checked into the code library by the end of the development testing.  Application support teams need to be diligent in removing old SSIS packages and jobs from their SQL Server instances, and generally in helping to keep the environment clean. Package and Job Usage Guidelines For applications that are hosted in a shared instance of SQL Server 2005, the following recommendations are made:

4. 4 There are a number of objects that need to be created in the SQL Server environment in order to manage jobs and packages. In order to better manage these objects, the names of the objects must all include a text string that identifies the application (or project), such as A_APP (or B_PROJ). If the application has multiple databases, it is preferable to have each of the database names begin with this text string as well, so that they will group together in the database list, and so that it is clear to support teams which application the databases are related to.

5. 5 The dba will create two special database roles for the application in the msdb database on the SQL Server instance. These roles will control access to the packages, jobs, credential, and proxy for the application. Application development and support users will be assigned these roles, depending on their responsibilities. The SSIS_ADMIN role for the application will allow the user full access to the jobs, packages, credential, and proxy for the application. The SSIS_USER role for the application will allow the user limited access to the packages for the application. The specific access granted to each of these roles is identified in the detailed information below.

6. 6 SSIS packages can be stored in the msdb database for the SQL Server instance. This may be done by using the “Import Package” option within the Integration Services component of the SQL Server Management Studio. The DBA team will create a folder for the application in Integration Services. All SSIS packages for the application must be located under the application’s folder. The application team can create sub-folders to further organize their packages, and deploy packages under these sub-folders. NOTE: Packages that are not stored in an application folder may be eliminated during DBA cleanup activities.

7. 7 Since packages are nested under a folder that is named with the application text string, it is not required to begin each package name with the application string. However, it is recommended so that the owner of packages that are accidentally deployed in the wrong location can be more easily identified. It is also recommended that no embedded blank spaces be used in package names.

8. 8 After the package is imported (deployed), the package permissions must be set. Right-click on the package and choose the Package Roles… option from the pop-up menu. For the Reader Role, select the SSIS_USER role for the application from the dropdown list. For the Writer Role, select the SSIS_ADMIN role for the application from the dropdown list.

9. 9 Users assigned the SSIS_USER role will be able to view the package, use it in jobs, and execute it manually. Users assigned the SSIS_ADMIN role will be able to re-import the package to update it. If a user needs to use the package and to update the package, they will need to be assigned both roles in the msdb database. Since each application will have its own SSIS_USER and SSIS_ADMIN role, assigning your own team’s SSIS_USER and SSIS_ADMIN roles to each package, and granting your team members these roles, will ensure that only your team can use and edit your team’s packages. If you forget to set these roles immediately after importing the package, only the person who imported the package or a dba can set the roles. Until the roles are set, the rest of your team will not be able to access the package.

10. 10 The dba will create a credential for your application. The credential name will begin with the application text string.

11. 11 The Identity for the credential should be the windows robot account that will be used to run scheduled jobs for the application. It should not be an individual user account, since multiple team members should have the ability to update the password stored in the credential, and users should not be sharing their personal account password with others. When the dba creates the credential, they will enter a value in the “password” fields that is not the actual password, since a value is required to create the credential. Before the credential can be used, the application team must modify the password stored in the credential to be the correct password for the robot account. This is done by running the following command from a query session on the SQL Server instance. EXEC msdb.dbo.reset_credential_password @requested_credential=' CredentialName ', @new_password=' Robot-acct-pwd ' Only users who have been granted the SSIS_ADMIN msdb role for the project and the msdb role Update_Credential_Password will be able to run this command.

12. 12 The dba will also create a proxy for the application. The proxy name will begin with the application text string. The application credential will be identified in the proxy, so that job steps that use the proxy will run under the robot account. An owner and backup owner may be identified for the proxy.

13. 13 The dba will activate specific subsystems for the proxy, depending on the application needs. The robot account associated with the proxy (via the credential) will need to be granted permission for the databases these commands will operate against. The dba will set the proxy principal to the SSIS_ADMIN role for the application. This will limit the users who can use this proxy (and therefore who can use the robot account) to the members of the application support team who have been granted this msdb role.

14. 14 Unfortunately there is no way to create an application folder for jobs in SQL Server 2005. To make navigation and management for jobs easier, all job names must begin with the application text string. This will cause jobs for the same application to be grouped together in the job list. It will also allow an application support team member to filter the job list to show only their application’s jobs. Unfortunately, the filter must be reset each time the user starts their SQL Server Management Studio session. It is also recommended that job names not contain any embedded blanks.

15. 15 The dba will create a job category using the application text string. When the application team creates a new job, they must select their application job category. This will limit update, execution, and termination access to members of the application support team. If the job category is not properly assigned before the new job is saved, only the Owner of the job or a dba will be able to set the job category. Other members of the team will not be able to edit the job (or run/terminate the job in Production) until the category is corrected.

16. 16 Each step in the job should use the application proxy for the “Run as” value. The default “Run as” value is the SQL Agent Service Account. Do not use this account, since it will not have access to the application resources (databases, file shares, etc.) that your job needs to access.

17. 17 Once a job is created, it can be edited, run, or terminated only by the current owner of the job or by a dba. To edit, run, or terminate** a job created by someone else, the user will need to assume ownership of the job. This is done by running the following command from a query session in SQL Server Management Studio. EXEC msdb.dbo.update_job_owner @requested_jobname='job name', @new_owner_name='new owner account id' Only users who have been granted the SSIS_ADMIN msdb role for the application and the msdb role Update_SQLAgent_Jobs will be able to run this command. A user will only be able to take over ownership for jobs that are in the application’s job category. ** Note that in non-production environments, users will normally be granted the ability to run/terminate any job, but will only be able to edit jobs in their application’s job category. In the production environment users will not be able to run/terminate or edit a job unless they it is in their application’s job category. It is recommended that the job owner be set to the robot account in production.

18. 18 Many jobs will require run-time parameters that contain values specific to the environment. Run-time parameter values should not be hard-coded into a package or job step. This includes the connection to the SQL Server instance and database against which the job will run. The name of a parameter that holds a run-time value should be the same in development, QA, and production. This allows the package and job to be migrated without having to edit it after it is pushed to each new environment. All of these parameters should be stored in an encrypted table in the application database, with one exception as described on the next page.

19. 19 The connection information for the database that hosts the encrypted table of run-time parameters must be stored in an xml configuration file on a share where the application development/support team has update access. The application robot account that will be used to run SSIS packages, referenced in the application credential, must also have access to the share. The file should reference the SQL Server instance name and database name where the run-time parameter table resides. It may also contain the name of the table where the run-time parameters reside, if the SQL Server default name [SSIS Configurations] is not used. The file should specify windows authentication. No account or password should be stored in the file. These will be retrieved at runtime from the credential, or from the windows login of a user manually running a package.

20. 20 <DTSConfigurationFileInfo GeneratedBy=“ABCDEFGH\abcdefg" GeneratedFromPackageName=“A_APP_Load_1" GeneratedFromPackageID="{12345678-ABCD-DEFG-HIJK-00023456789}" GeneratedDate="6/18/2007 8:12:57 AM"/> <Configuration ConfiguredType="Property" Path="\Package.Connections[conA_APP_DB1].Properties[ConnectionString]" ValueType="String"> Data Source=SQL2005_SVR01; Initial Catalog=A_APP_DB1; Provider=SQLNCLI.1; Integrated Security=SSPI; autotranslate=False; AutoTranslate=False; Example xml Configuration File Note: Line feeds were inserted in the sample below to make it more readable. Normally this is all on one line in the configuration file. The first package to reference the file can auto-generate it. It will not hurt anything if the values in the “Generated by” fields do not match the packages that use this file. SQL Server Instance Name DataBase Name Indicates windows authentication

21. 21 There must be one file for each environment (Development, QA, Production), where each file references the appropriate SQL Server instance and application database name where the run-time parameter table resides. The application team must supply the UNC pathname for these files to the dba team. The file names can be different, but they should have the file extension “.dtsconfig”. The dba team will create a single environment variable for the application on the database servers for each environment and set the value of the environment variable to the UNC pathname for the configuration file for that environment. The environment variable name will be the same on all servers. Users who will run SSIS packages from the Integration Services component of a SQL Server Management Studio session or a Business Intelligence Development Studio session initiated from their desktop must create the same environment variable on their workstation. They will need to be careful that the single variable on their workstation is pointing to the correct environment. Note that this limits the number of database environments (dev, QA, Prod) that can be hosted on a single server or a server cluster to one. If multiple database environments are hosted on a single server/cluster, one environment variable will be needed for each environment, and the variable name will need to be modified in the package as it is moved between environments.

22. 22 When an SSIS package is created, the first variable in the package must reference the application environment variable that contains the location of the xml file containing the connection information for the application database that hosts the run-time parameters table.

23. 23 The dba will create the run-time parameters table in the database. Since the run-time parameter values may include connection information, including accounts and passwords for pulling data from other databases, the run-time parameters table must be encrypted, if corporate security requires this. The dba will provide a set of scripts to the application team for creating a password-protected view and set of triggers on the view. All updates to the encrypted table must be done via the view. The triggers handle the encryption and decryption as they update the data in the encrypted table.

24. 24 The application team will need to insert an appropriate password into the scripts and run them to create the view and triggers. It is extremely important that the application team store these scripts in a secure place. If the view or triggers are accidentally eliminated and need to be replaced, the same password must be used or access to the decrypted parameter values will be lost. The trigger and view code is also encrypted so that users cannot simply look at the code to determine the password, and then run a query directly against the encrypted configurations table using the password. Once the view is in place, the dba will create a role in the database that denies access to the unencrypted view. All users who should not have access to the decrypted parameter values must be assigned the DENY_ACCESS_SSIS_CONFIGURATIONS_VIEW role in the database. Users who have been assigned this role will not see the view in the list of views for the database.

25. 25 Once the table and view are created, the application team will need to add rows to the table. This can be done via the package or directly into the table. Each row will hold one parameter. The name of the parameter will be stored in the ConfigurationFilter column of the table. This name will be referenced in the SSIS package. The same parameter name should be used in Development, QA, and Production, so that the package parameters do not need to be changed as it is migrated through the environments. The value for the parameter will be stored in the ConfiguredValue column of the table.

26. 26 In the SSIS package, the values for all of the remaining run-time variables must be retrieved from the SSIS Configuration parameters table. This includes the connection information for the database the job will update, as well as any other databases from which the job will extract data. It may also include email distribution lists, and other types of parameters that have different values in Development, QA, and Production. The value in the “Configuration Filter” field references a specific row in the SSIS Configuration table.

27. 27 When a job runs under a robot windows account and executes a jobstep that contains an SSIS package, the following happens  The proxy in the jobstep is used to retrieve the associated credential, which is used to retrieve the windows robot account and password in the credential.  The SSIS package initiates under the authority of the windows robot account.  The first variable in the SSIS package variable list is read, retrieving the name of the server environment variable.  The value stored in the server environment variable is retrieved, which is the UNC pathname to the xml configuration file on the application share.  The xml configuration file is read, which contains the SQL Server instance and database connection information for a windows authenticated connection.  The connection is made to the SQL Server instance and database using windows authentication for the robot account and using the password stored in the credential.  The values for the remaining variables in the SSIS package are retrieved from the dbo.[SSIS Configurations] view in the database (assuming the default configuration table name is used).  The SSIS package executes using the retrieved parameter values.

28. 28 Packages that are used to load data into a table in the database may also need to eliminate existing data before loading the new data. A check-box option is available in the SSIS package to “Delete rows in destination table.” This option performs a table truncate command behind the scenes. This is a fast way to clear data from a table, since it does not log every row that is deleted. Instead it only logs the fact that all rows were deleted from the table. User accounts and robot accounts that run packages with this option selected must have the authority to truncate data from database tables. Unfortunately this authority is part of the “create table” privilege in a database. Applications that have chosen to restrict the ability to create a table in the production environment to the dba team (or at least to not allow users that run jobs to create tables) will not be able to use this SSIS option.

29. 29 An alternate option exists for performing a table truncate. The dba can add a special procedure to the database that can be run to perform a table truncation. The command syntax is EXEC dbo.truncate_user_table @requested_schema=’schema name', @requested_table='table name' A pre-load step can then be added to an SSIS package to truncate the table by calling this procedure. If desired, the dba can also add a table to the database, which will allow the application team to restrict truncation to a subset of the tables in the database. The application team can then populate this table with the application table names for which truncation is allowed. If this table does not exist, the procedure will allow truncation on any table in the database. If this table exists, the procedure will allow truncation only on tables included in this table. Two new roles will be added to the database to provide the privilege to update this table and run the procedure. This role must be granted to the appropriate application support team members. The roles are Note that no table can be truncated if foreign keys reference it, even if they are listed in this table.

30. 30 Miscellaneous Points  Privileges within a database will be granted to Domain Local groups or Global groups, rather than to individual user accounts.  It is recommended that a global group be created and granted all the privileges required by the jobs in the databases, and that the robot account and the application support team members handling the batch administrator role (job and package management) be members of this global group.  It is recommended that SSIS packages be deployed in the environment where the jobs exist that call them. Other teams have experienced difficulties creating jobs in one SQL Server instance that call SSIS packages in another SQL Server instance. If a package is used in multiple SQL Server instances it should be deployed to each instance. Certainly a Production SQL Agent job should never call an SSIS package in a non-production environment.  The privileges that Microsoft provides with SQL Server 2005 allow for greater granularity in assigning permissions. Unfortunately, they do not provide a way to give a group of users access to a group of jobs and packages. The processes described in this document rely on custom configuration tables and stored procedures developed by the dba team. Even with these additions, there are some privileges that cannot be separated. For example, there is no way to separate the privilege to view a package from the privilege to run a package.

31. 31 Miscellaneous Points  If a package that executes a stored procedure in the database is running via BIDS (Business Intelligence Development Studio) and needs to be cancelled: First contact the dba team and have them cancel the related processes in the database. Then cancel the BIDS execution. If the BIDS portion is cancelled first, it can leave an orphaned process that can rapidly become a runaway process, consuming all the processing resources (cpu, memory) on the SQL Server instance. This can cause other processes to appear to hang, since they are waiting for server resources to free up.  In order for a user to manually execute an SSIS package from the Integration Services component of a SQL Server Management Studio session initiated on their workstation, they will need to have the SQL Server 2005 Developer client installed on their workstation. This requires a license, which must be purchased.  Application development/support users who log on to their workstation via a non- trusted domain outside the corporate domain structure will not be able to connect directly from their workstation session to a SQL Server instance residing in the corporate domain structure using windows authentication. If necessary, a Citrix server within the corporate domain with the appropriate developer tools on it can be used to allow access to these users.

32. 32 Miscellaneous Points  No data files or application error logs should be written to the database server. These must be stored in application shares.  The use of the run-time parameters table, SSIS Configurations, puts the addition of new parameters totally in the hands of the application development/support team. It also eliminates the need for the application support team to have logon access to the database server. And it eliminates the need for the dba or sa to create new environment variables each time a new parameter is added.