At SourceFlow we take our technology and its security extremely seriously.

We have created this guide so our customers’ tech and ops teams can easily find any info they require should they need it.

If you need support for your SourceFlow tech, raise a ticket with our support team or call +44 333 006 7705.

The websites provided by Sourceflow consist of two parts: The static internet facing website, and the digital experience platform which contains dynamic admin control panel and API. There are dynamic on-page javascript elements that interact with the API to provide a dynamic experience to users.

The static websites are pre-compiled and served directly from filestorage to the user via a CDN, resulting in unparalleled speed and reliability.

The dynamic content is provided by a pool of containerised Ruby on Rails servers.

Data Centre

All Sourceflow customer hosting is provided by Amazon Web Services using their London data centre (eu-west-2).

All data storage is in this region.

There are CDNs and other networking infrastructure provided by AWS that may be in other regions to enable Sourceflow to be accessible globally, but no sensitive data is stored by these services.

Servers

The web servers providing dynamic content are Ruby on Rails running in Docker containers on AWS Fargate. Autoscaling is enabled to scale to meet the load demands.

All security patches for both operating system and our code are applied as soon as they are available.

Data storage

Persistent data storage is provided by two AWS services.

The database is Postgresql running on AWS Serverless Aurora. It is autoscaling to meet capacity demands. Encryption at rest is enabled, using AES-256.

Static file storage is provided by AWS S3. There are 3 categories of content that are stored on S3, using different buckets for each. These are:

Static files representing the static HTML website. These are each in a separate bucket per customer. This content is all considered to be public, and is fronted by a CDN.

Files uploaded to the platform for use on the website. This includes items such as images for blogs, or PDF files that can be downloaded. All of this content is considered to be public, and is fronted by a CDN. All customers share the same bucket here for ease of management via the platform, but the file names are difficult to guess.

Candidate files, such as CVs, certificates, copies of identity cards etc. that have been provided by a candidate during a job application. This data is all confidential. This is stored in its own bucket separate to any public data, and is encrypted with AES-256. Access to this data is only by authenticated requests from the platform. As it is intended that this data only be used when fresh (and likely to have been transferred to a customer’s systems via an integration) this data is automatically deleted after 90 days. The metadata representing that the file once existed is persisted to allow for audit purposes.

CDN

AWS Cloudfront is used as a CDN as part of the service. Only public data will ever be cached by this CDN, for all other data it merely acts as an entrance point into the AWS network.

Encryption

All network traffic is encrypted using a version of TLSv1.2 with the weakest cipher suites disabled.

The supported ciphers are detailed here:
https://aws.amazon.com/about-aws/whats-new/2021/06/amazon-cloudfront-announces-new-tlsv12_2021-security-policy-for-viewer-connections/

TLS certificates are provided for customer websites as part of the service, and all insecure web requests are redirected to https to ensure minimal data transfer over an insecure connection.

Internal data transfer within the Sourceflow AWS environment is also encrypted where supported. This includes CDN to server, server to database, and server to filestore.

All encryption at rest is using AES-256.

Types of user account

Admin - any user authorised by the customer to access their sourceflow environment and make changes to their sites

Superadmins - Sourceflow employees who have access to customer Sourceflow environments to enable them to assist Admins with configuration, data entry, or any other tasks a customer may need assistance with.

The environment here is the entirety of the account belonging to a customer. This may include multiple websites.

The primary difference between these two user types is that Admins are restricted to within their customer environment, whereas Superadmins can switch between customer environments.

Permissions

Sourceflow users have a default of no access. Roles must be granted to users to allow access to the different features of the platform.

Roles are limited in scope, and are not dependent on each other. A user can be granted any combination of roles to tailor their permissions to the bare minimum they need to perform their tasks.

For ease of management, User Groups can be created to assign the same roles to multiple users.

There is a role that grants full access to all functionality. It is recommended that at least one Admin user has this role to ensure at least one person can make any necessary changes.

Data access

Access to features and the data contained within is handled by roles. Roles usually come in pairs, one granting read only access, and one granting write access to modify the data.

Users without a role cannot view, download, modify, or otherwise interact with the data it controls.

Read only access allows users to read, search, or download the data.

Write access allows users to modify existing data, or create new data, either via the web interface or the API.

For certain sensitive data, the read and write roles are broken into much more specific roles to allow fine tuning of access.

The platform provides a rich API for interacting with the data. This is used to provide both dynamic content on the websites, and to enable integrations between Sourceflow and 3rd parties to meet customer business needs.

The API consists of two types of endpoints; those requiring authentication, and those that are public.

Public API endpoints are for content that is already presented on the website, such as lists of job adverts or other content pages.

Authenticated APIs are for creating new data, or retrieving sensitive data such as candidate data. Authentication is either via session cookies (for APIs being used by the page the user is looking at) or via the Client Credentials OAuth2 flow for any external connection.

API credentials are also assigned roles to control which endpoints they can interact with.