Information on the storage and security mechanisms for the day-to-day operation of the FMI Works application.
This article is for IT and security professionals
FMI stores customer data using two mechanisms, databases and file storage in support of the FMI Works application.
Data Storage
The FMI Works application stores most of its operational data in a cloud-based relational database, specifically the Azure SQL Server database based on Microsoft SQL Server. Additionally, FMI Works stores some data, in particular large file-based data, using a cloud-based blob storage, specifically the Azure Storage Account system. These storage solutions are then configured to provide robust storage, backup, auditing, and security.
Sovereignty and Ownership
All data is stored in specific countries and remains the property of customers. See Data Sovereignty and Ownership for full details.
Backups and Auditing
All data is backed up and audited. See Data Backup and Auditing for full details.
Security At-Rest and In-Transit
Whether data is store on physical media or being transferred between systems it is always encrypted. See Data Security At-Rest and In-Transit for full details.
Data Security
As an application best practice, FMI staff do not have access to customer data directly from the database.
Individual Accounts
All access to FMI Works data is done through the application to ensure that the appropriate application authorization checks are done. Internal to FMI, we have a policy of no anonymous or shared accounts. All accounts are linked to a single individual, a critical step in appropriate auditing.
When, in the process of supporting our customers, our staff require access to customer data, the application provides an authorized and audited mechanism for this access.
System Accounts
For access to databases and blob storage, our applications do require their own accounts. The details of these accounts require shared secrets that are known only to the application and the database or blob storage. To facilitate this mechanism, the FMI application contains a Key Vault, specifically the cryptographically strong Azure Key Vault.
The shared secret between the application and the database is generated as a cryptographically generated 32-character code. This secret is then stored in the Key Vault and the database for the application to have access. This shared secret is also used by our Continuous Deployment (CD) system for the routine maintenance of the database during releases. At no point in this process is the secret shown to administrators.
A mechanism also exists for the rotation of these secrets. The FMI DevOps team performs a routine rotation on all secrets once every six months, where the existing secrets are retired, and new secrets are created using an automated process.
System Maintenance
Most system maintenance is performed as part of our Continuous Deployment process during scheduled release windows. This includes database and blob account management functions, such as updating a schema. These changes are scripted and testing against multiple systems and are then performed automatically as part of the release process. This ensures that secrets do not need to be seen or used by adminstrators.
From time to time, the DevOps team might need to have access to databases or storage accounts for exceptional maintenance issues. In these rare instances, administrator access to these secrets might be required. In this event, the secret is considered compromised, and the rotation process is performed to restore the secret nature of the key.