One of the primary uses of IRI FieldShield is to encrypt and decrypt sensitive data in database or flat-file columns. FieldShield relies on a passphrase to derive a symmetrical encryption key used at encryption and decryption time. The passphrase is stored in a job script file in one of three ways:

1. A text string directly in the the job script.
2. The path of a file containing the passphrase.
3. An environment variable whose value resolves to the passphrase at runtime. 

In this article, we improve upon the security of FieldShield passphrases for data sources either in the cloud or on premise by combining the third method with an Azure Key Vault. Future articles will show how to secure FieldShield passphrases or keys in other key management systems.

Benefits of the Approach

Because FieldShield passphrases can be expressed as environment variables, they can be managed through a command-line hook to an Azure Key Vault. The vault is a cloud service in Microsoft’s Azure platform for securely storing “secrets”, which in this case are the passphrases that FieldShield uses to encrypt and decrypt values.

Azure offers many security features for protecting access to the key vault, including Active Directory for user authentication, and key rotation to periodically change key values. Built-in firewall management functionality restricts certain applications/IP addresses from accessing the vault, too. 

It is also possible to log access to monitor how and when your key vaults are queried, and by whom. This helps discover abnormal events like unauthorized key extraction attempts, or access by privileged users at unusual times. 

Without the use of Azure Key Vault and batch files, the environment variable used in the FieldShield job would need to be a permanent environment variable. This permanent environment variable could be viewed by a user who may need to run the job but is not desired to have access to the passphrase. 

By using Azure key vault and an executable file that contains a batch script to run FieldShield, however, the environment variable is temporary and secure. It serves up the passphrase for only the FieldShield task defined in a particular batch job.

Solution Architecture

A FieldShield encryption or decryption target field function can be specified this way:

/FIELD=(ENC_FP_PAN=enc_fp_aes256_CreditCardNo, “$passvar), POSITION=6 …

where $passvar in this case is the environment variable that will resolve to the passphrase stored in Azure during batch execution of command-line FieldShield jobs.

Initially, the Azure Key vault will need to be set up, if one is not set up already. This example shows step-by-step how to set up a key vault with a secret — in this case a FieldShield passphrase — inside using the Azure Command Line Interface (CLI). The Azure CLI can be downloaded and run locally, which will be required for this example. 

A batch file has commands that run a FieldShield job to encrypt (or decrypt) fields using the passphrase stored in the Azure Key Vault. This batch file will be encased in an .exe file to prevent Azure login credentials from being read. 

Again, the environment variable tied to the passphrase exists only during the execution of the batch file, so all traces of the passphrase vanish after the batch file runs. And since a local environment variable is used, the passphrase cannot be accessed unless the batch file is edited, which is not possible as an executable set to read and run only.

Creating the Key Vault 

Following along with this example requires the following:

• Microsoft account
• Azure subscription
• Azure CLI
• IRI FieldShield

The Azure CLI can be downloaded from the Microsoft website. It is used to interact with Azure from a local command prompt. It is required for logging into Azure via batch file.

To integrate with Azure Key Vault, first make sure you have a Microsoft account and Microsoft Azure subscription. Sign into Azure, either online or from the CLI. If using the online console, start an Azure Cloud Shell. 

If signing in from a local CLI, use the command az login to sign in. This will open a window in the computer’s default browser for authentication to Azure. However, once authenticated, everything else can be performed from the CLI. 

There are also alternate authentication methods that allow for direct logins from the CLI, which include logging in with username or password included in the command, or logging in with a service principal. Logging in with a service principal gives the least amount of permission possible if properly configured (more about this later).

Once signed in, run the command:

az group create –name “SampleResourceGroup” –location eastus

This will create a resource group in the eastus region named “SampleResourceGroup”. Of course, you can change the name of the resource group to your liking. 

To create the key vault, run:

az keyvault create –name “SampleVault” –resource-group “SampleResourceGroup” –location eastus 

to create the “SampleVault” in the “SampleResourceGroup” where you can store “secrets” like passwords or FieldShield passphrases.

Storing the FieldShield Passphrase in the Vault

The command:

az keyvault secret set –vault-name “SampleVault” –name “ExamplePassphrase” –value “hVFkk965BuUv” 

sets a passphrase with the value hVFkk965BuUv and the name “ExamplePassphrase” in the “SampleVault”. Replace hVFkk965BuUv with the value you will store in the vault. 

To view the passphrase, run:

az keyvault secret show –name “ExamplePassphrase” –vault-name “SampleVault”.

If this command yields the passphrase, then that means the key vault has been successfully configured.

The passphrase could be set as a permanent environment variable based on the value from the key vault, but instead, this example demonstrates the use of a batch file within an .exe file that will use a local environment variable instead. This method will be more secure. 

Creating a Batch File to Store and Secure the Passphrase $EV

Even though the actual FieldShield encryption passphrase is kept secret in the Azure Key Vault, one could argue that even exposure of the environment variable name within the FieldShield job spec creates a security vulnerability. To address this, a batch file like this can be run to maintain the security of the passphrase:

In this batch file, a connection to Azure is established, the passphrase stored in the Azure Key Vault is written to a temporary text file, and a temporary environment variable is set to the value of the passphrase within that text file. FieldShield then runs the encryption or decryption job using that passphrase, and, finally, the text file is deleted for security. 

This allows a user to run the encrypt and decrypt jobs without being able to find out what the passphrase was; i.e., it eliminates the need to specify the name of the environment variable as the clear text of the passphrase in the FieldShield encrypt/decrypt /FIELD statement, persistent file, or exposed environment variable.

Remember, the environment variable must resolve to the same passphrase for both the encryption and the decryption script to get the original values back when decrypting. The batch file above logs in with the Azure username and password, but Azure service principals can be used to limit access when logging in, just to get the passphrase from the key vault. 

Using Azure Service Principals to Limit Login Access

Azure service principals can be used to login to prevent logging in with full access to Azure and to hide the username and password of your Microsoft Azure account. 

 “An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources.¹”

This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level”.

There are two types of authentication available for service principals: password-based authentication, and certificate-based authentication. In this example, password-based authentication is used.

The command

az ad sp create-for-rbac –name ServicePrincipalName

creates a service principal with a randomly generated password. Take note of the password, app id, and tenant id. Now, the administrator of the key vault should set up an access policy.

Log in to Azure via web browser and click on the key vault resource that you wish to grant access to. Click on “access policies” from the key vault menu, and select “Add access policy”. For key and secret permissions, under management operations, select get only. 

Select the name of the service principal previously created, click “add” and save the new setting after adding. Now, Azure be be accessed from the command line via a service principal. This service principal will only grant read-access to the secret (passphrase). ²

Use the following command to login to Azure via service principal:

az login –service-principal –username APP_ID –password PASSWORD –tenant TENANT_ID

If logging in through service principal, the aforementioned command can replace the first line of the batch file example, which used log-in via username and password.

Converting the Batch File to an .EXE to Secure the Azure Credentials 

Finally, the batch file shown above can be transformed into an executable file using the iexpress wizard from the windows/system32 directory. This will prevent unwanted users from viewing Azure login credentials within the batch file. 

To do this, 

1. Run the iexpress executable as an administrator. 
2. Create a new Self Extraction Directive file. 
3. Select “extract files and run an installation command”. 
4. Add the batch file to the list of packaged files. 
5. For the custom command in the “Install Program to Launch” menu, input “cmd /c yourscript.cmd”. 
6. Select a directory where the executable file will be created. 

Then, the executable file can be set to have permissions of read and execute only. Now, a lower-privileged user can safely run the file without the passphrase or any Azure passwords being exposed. 

Conclusion

FieldShield is a powerful tool for finding and masking PII. This example demonstrated how to increase the security of the passphrase used in FieldShield encryption and decryption jobs by:

• installing the Azure CLI from the Microsoft website  
• setting up an Azure key vault and storing the passphrase as a “secret” in the key vault 
• creating a batch file similar to the one depicted that logs into Azure, gets the passphrase from the key vault, and runs the FieldShield encryption/decryption job using that key 
• creating an Azure service principal, for an even more secure login from the batch file 
• converting the batch file to an .EXE file to prevent login credentials from being read. 

Utilizing an environment variable that is temporary, automatically deleted, and protected within an .EXE file as the passphrase for FieldShield encryption and decryption jobs can significantly improve encryption key security and key management options for those with FieldShield and an account in Azure. 

1. From https://docs.microsoft.com/en-us/powershell/azure/create-azure-service-principal-azureps?view=azps-2.7.0 
2. Logging in via service principal is useful to restrict access to one function: retrieving the secret FieldShield passphrase. If someone is able to read the batch script (or its more secure .exe version), they will only be able to access that one function, rather than get full control of the Azure account.