Flomatika will extract performance metrics from your Work Management system via their API. Access to this data will be strictly limited to client’s employees and Flomatika team members for the purposes of supporting the platform.
Data extracted does not include any confidential data (such as description, acceptance criteria, etc) with the fields extracted being explicitly described in Section 2. The list of fields can increase dependent on the level of additional analysis as requested by the client, such as:
Core fields:
The Flomatika ETL (Extract Transform Load) Engine will be running according to the configuration described below to extract, transform, and load client’s data as described below:
The Flomatika user interface has been developed as a single-page application based on the React framework. As such it is served as a static set of files from an AWS S3 bucket in the ap-southeast-2 region (Sydney), through AWS' globally deployed Content Delivery Network Cloudfront.
The Flomatika user interface itself has no user data and relies on Auth0 for user authentication, and the Flomatika API for interacting with the user's data.
For the purpose of configuring Flomatika for the organisation, the user would also have to be authenticated to the appropriate issue tracking data source (eg Jira, Azure Boards) and will have to have the appropriate access to pull data that would be used to link the Flomatika configuration to the equivalent data source entities. The user's authentication tokens for the data source are only kept in the user's browser and are not passed on to the Flomatika API, nor stored by Flomatika.
The Flomatika user interface itself is available to everyone. Login security is provided via Auth0's API, which provides the appropriate tokens that must be passed on to the Flomatika API for authorisation.
Access to the Flomatika app source can only be done via SSL calls. Any plain http call will be redirected to https. Only http and https ports are made available in Cloudfront.
The underlying S3 bucket has no direct public access, it serves its contents only via Cloudfront.
SSL certificates are provided to Cloudfront using its integration to AWS' Certificate Manager service.
Access to webapp assets is logged by Cloudfront.
MFA can be enabled via Auth0 if required.
Auth0 provides integration with Social and Enterprise security backends like Azure AD, Google Enterprise, as well as platforms that support LDAP and OpenID (eg Okta).
Roles and privileges for clients using an enterprise platform like Azure AD can be managed through Groups in the platform that can be mapped to Flomatika's Admin, Power, and Standard user roles.
Auth0 provides access logging for reporting.
The Flomatika implementation for its User Interface leverages AWS' approach to high availability.
Although the UI assets are stored in a single region (Sydney), AWS replicates those assets through a number of availability zones within the region.
Cloudfront is a global service and, as such, can be made available from any region and zone, should one of those become inaccessible.
The Flomatika API is executed through AWS' Lambda service. The API endpoints are accessed via AWS' Gateway V2 service.
Whilst the Gateway allows global access to the Flomatika API, the Lambda functions servicing the endpoints are deployed in AWS' Sydney region.
The Lambda code is written in Javascript and executes under Node.js 12.x.
Flomatika leverages the Gateway's integration with JWT providers (in our case Auth0) that verify the signature of the token passed from the calling client. This is the first pass at working out whether the user is a valid Flomatika user. Per JWT specification, the data passed in the token must match the signature. The token also has a limited lifetime and must be replaced by Auth0 regularly.
The context passed in the signed token includes the user's organisation, as well as the user's role and permissions within that organisation. These details are used by the Flomatika functions to ensure the correct data partition and rows are accessed.
Access to endpoints is only allowed via https, which is the only port available in this service. The SSL certificate is provided through the Gateway's integration to AWS' Certificate manager.
Communication between the Gateway and the Lambda functions leverages AWS' security model, which includes a secure transport.
Flomatika leverages AWS' HA for the API Gateway which is a globally deployed service.
Lambda functions are deployed in the Sydney region but leverage AWS' multi-zone approach to availability.
Loading data from issue and project work tracking sources, aka Flomatika ETL
Data from the data sources is extracted, transformed, and loaded in an incremental fashion, based on the items' change date.
The whole process is executed via Lambda functions that respond to requests in AWS SNS queues.
The Lambda code is written in Javascript and executes under Node.js 12.x.
The ETL Lambdas are not deployed as part of the API set.
The security credentials used to access the data sources can only be accessed by those Lambdas that require them (those providing the Extract functionality). Those credentials are stored using AWS Secrets Manager service.
Flomatika data is stored in a relational database service provided by Amazon called Aurora.
Security tokens to access the data sources are kept separately using AWS' Secrets Manager.
AWS Simple Notification Service is used to temporarily hold data between the ETL services.
Access to Aurora database is only allowed via its own SSL-encrypted API. Aurora database encrypts its data at rest by default. AWS provides hardening and patching as part of its own operating model.
SNS server side encryption is turned on for all topics.
Flomatika currently uses GitLab to host its code base and execute CI/CD.
Only those members of the Flomatika team that have development or operational duties have write access to the Flomatika code base.
As part of our normal development processes we ensure all 3rd-party packages are upgraded regularly.
The use of AWS Platform services like Cloudfront, Lambda, and the API Gateway allows the Flomatika team to leverage AWS' approach to security, patching, and availability which are best-of-breed.
Wherever possible we have used an Infrastructure-As-Code approach to deployment either through Terraform scripts, or through Serverless scripts when appropriate.
Only those members of the Flomatika team that have operational duties have access to the Flomatika AWS account.
CI/CD use a separate login not related to any Flomatika member. This login does not have access to the AWS console, and only has permissions that allow it to deploy Flomatika code.
