Data Security At-Rest and In-Transit

Describes how FMI Works secures application data, to prevent data leakage from intentional and accidental sources

This article is for IT and security professionals

FMI Works is designed as a cloud delivered application which requires additional care to be taken to ensure that data is protected. This is important whether the data is in the data centre or is being routed through the Internet.

FMI leverages modern cloud storage and application delivery through the web, including:

FMI uses the Microsoft Azure Cloud. This provides many core security features, such as physically secured data centres.
Within the cloud, FMI stores information in three data locations. All of these locations are encrypted at rest using the built-in mechanisms that are provide by Azure.
1. Some data is associated with assets and tags that are not relational or transactional in nature. This data is stored using a document store in Azure called CosmosDB.
2. Some data is more traditional and transactional in nature and is stored in a relational database, Azure SQL Database, which is based on Microsoft SQL Server.
3. Other data has very little indexing requirements and is just directly referenced. This data is stored in Microsoft Azure Storage as Blobs
Both web applications and the FMI RESTful APIs access data from these sources. These applications are hosted in the same region as the associated data storage and there is no external access to these networks. Regardless, all internal data access is performed via HTTPS using TLS 1.2.
Traffic to both the RESTful APIs and the Web Application over the Internet is also via HTTPS.
1. We no longer support TLS 1.0 or 1.1 and require all clients to use TLS 1.2
2. We check and maintain a SSL Labs score of A- or better on our application domains (e.g. demo.fmiworks.com)
3. Applications are secured using cookies and JWT tokens as described in Authentication, Authorization, and Single-Sign-On.

Firewalls

When in transit, operational data must pass through either our web application or our APIs, there are no other alternatives. For example, we do not all access to our databases from the Internet. To enforce this architecture, we use a multiple firewalls. Firstly, our web application servers:

Have physical firewall rules for inbound ports 80 and 443 only
All requests on port 80 are redirected to port 443
Serve web page traffic through port 443 only
Serve APIs traffic through port 443 only
Have software firewalls that restrict access to only applications within our own private network on specific ports

Our database servers (and anything other than web servers):

Have physical firewall rules that disallow all inbound traffic
Have software firewalls that restrict access to only applications within our own private network on specific ports

For DevOps and debugging purposes, access to systems is limited. It requires the use of a separate web portal as a "jump-box", for developers to debug, access logs, etc. No firewall allowances are made for this scenario.