The mechanisms and requirements used to generate, store, and re-issue internal keys and certificates that encrypt client data
This article is for IT and security professionals
FMI Works encrypts and secures customer data through a variety of mechanisms. Data is encrypted at rest and in transit and keys and certificates are securely stored.
HTTPS Access to Systems
All access to FMI Works is required to use HTTPS, where:
- All HTTP requests are serviced with a permanent redirect (HTTP 302)
- Connections require TLS 1.2
- HTTPS Certificates are recycled every six (6) months
- FMI routinely tests and maintains a grade of "A-" or better at SSL Labs
- FMI regularly retires older cipher suites, balanced against device compatibility
- Certificates are electronically issued with private keys not being accessed by FMI staff
- System to system access also uses HTTPS within the FMI network.
Secure Storage of Data
All FMI Works data is stored securely, using mechanisms provided by our cloud provider, Microsoft Azure:
- Blob storage is encrypted using at 256-bit AES Encryption (see also: Azure Storage Service Encryption)
- Database storage, both operational data and backups, is encrypted using SQL Server's Transparent Data Encryption (see also: Azure Encryption at Rest)
Secure Storage of Secrets
In addition to the encryption and secure storage of data, FMI also securely manages the certificates, keys and secrets that allow access to the data. In particular:
- Application passwords are never stored, they are cryptographically salted and hashed
- Keys and secrets (such as connection strings) are electronically generated and stored in Azure KeyVault
- Storage of HTTPS Certificates are managed and stored in Azure KeyVault
- Keys and secrets are not used by staff and are routinely re-cycled through automated processes
- Keys for securing data at rest use Azure's managed encryption keys service