Orchestrator Data Encryption
Updated: May 13, 2016
Applies To: System Center 2012 SP1 - Orchestrator, System Center 2012 - Orchestrator, System Center 2012 R2 Orchestrator
The following sections provide information about data encryption in Orchestrator:
What data is encrypted and decrypted in Orchestrator?
How is encrypted data managed in Orchestrator?
How can encrypted data be moved between Orchestrator instances?
Best practices for encrypted variables
Introduced in System Center 2012, encrypted variables in Orchestrator allow you to more securely use variables to provide sensitive data to runbook activities. Encrypted variables are used exactly like standard global variables; that is, by means of a subscription. If you subscribe to these variables in activity fields that get republished, the variable contents can be exposed on the data bus. Because of this, encrypted variables should be subscribed to only in fields that are not republished. This best practice is not enforced by Orchestrator, but it should be a part of your planning process.
However, if encrypted data must be published on the data bus in order to be sent to another system (for example, a product that runs on a different server), you should ensure that the channel to that product is secure. For example, BMC Remedy supports a secure mode for connection, and products with web interfaces typically allow using the Secure Sockets Layer connection (using the HTTPS protocol).
What data is encrypted and decrypted in Orchestrator?
Orchestrator provides a code set of encryption and decryption services that are used to generate Orchestrator platform-encrypted data. These services are used to secure data flagged for encryption in the Orchestrator database as well as decrypt the data to plain-text so it can be used as part of a runbook. These core encryption services are managed by the Orchestrator database and management server. Rights to these services are granted through membership in the Orchestrator Users group or the Orchestrator System group.
Note
Orchestrator runbooks could contain data encrypted by an external encryption service and used as runbook Published data. Orchestrator would not handle data from such an external system any differently than any other piece of data.
Orchestrator uses encryption in the following product feature areas:
| Feature area | Description |
|---|---|
| Runbook activities | Any property masked out when one types in the field is an encrypted property. This would include passwords on the Security Credentials tab but can include other properties as well. |
| Options menu | The Options menu is used to store credentials and other information used to configure integration packs. Properties of connection settings can contain encrypted properties. |
| Variables | Variables that have the Encrypted Variable checkbox selected will be encrypted. |
Note
Encrypted variables are intended to be used via subscription in properties that require an encrypted value such as a password used in a runbook activity. If an encrypted variable is subscribed to in a non-encrypted field the encrypted value will be provided. The plain-text value is only available when used in an encrypted property.
How is encrypted data managed in Orchestrator?
Orchestrator has a core cryptographic service whose design is based on AES using SQL Server cell-level encryption. As such, all encryption and decryption is performed centrally by SQL Server. Encryption keys are centrally managed by SQL Server. Both the SQL Server Service Master Key and the Orchestrator Database Master Key are required to encrypt and decrypt data.
Orchestrator uses cryptography in both the Run Time and Design Time experiences. Runbook authors interact with runbook activities in the Runbook Designer and often these activities will interact with external systems to "discover" property grids, list values, and other properties. Likewise, when a runbook is tested in the Runbook Tester the encrypted data provided in protected fields needs to be decrypted so it can be passed to the target system. Finally, the Runbook Servers need to be able to decrypt encrypted data to allow runbooks to interact with external systems. As such, the database cryptographic services need to be accessed from the Runbook Servers, Runbook Designer and Runbook Tester.
Since the core cryptographic services reside in the Orchestrator database, access to the database essentially defines access to the unencrypted data.
Runbook servers access the database directly. As such they directly access the crypto services provided by SQL Server. Run Time access to the crypto services provided by SQL Server are limited to members of the Orchestrator System Group.
Runbook Designers and the Runbook Tester access the database indirectly through the management server. The management server offers a new service that services requests for encryption/decryption from the Runbook Designer and Runbook Tester. The management server passes through the security context of the runbook author and these credentials are used to access the crypto services. Design Time access to the crypto services provided by SQL Server are limited to members of the Orchestrator Users group.
Access to encrypted data from Orchestrator is managed by the Orchestrator Users group and the Orchestrator Systems group. Members of these two security groups essentially have rich administrative access to Orchestrator including rights to access the core cryptographic services as well as decrypt data stored encrypted in the database.
How can encrypted data be moved between Orchestrator instances?
When the Orchestrator database is installed a database master encryption key is created. This database master key is used in conjunction with the SQL Server master key to encrypt and decrypt data stored in the Orchestrator database. This means encrypted data is essentially "keyed" to the instance of SQL Server 2008 R2 where the data was encrypted. For example, one can't "copy" an encrypted string from a column of one instance of SQL Server 2008 R2 and "paste" the value into another instance of an Orchestrator database and decrypt the data unless both the database master key and server master key matched that of the system where the data was encrypted.
Hence moving encrypted data between Orchestrator instances requires one of two scenarios:
Both the SQL Server service master key and the Orchestrator database master key are the same as the keys on the system where the data was originally encrypted.
Export the runbooks and related encrypted data and Import into the new system.
Essentially, the Export functionality creates an export file whose encrypted data has been encrypted a password provided by the user during export. This export file contains encrypted data that can be decrypted by providing the same password during import. The data will be encrypted and stored into the database by using the encryption keys for the new database.