Signiant Flight quickly moves high-value, large digital assets to and from cloud object storage such as Amazon S3 and Microsoft Azure. For every cloud vendor integration, Flight was built from the ground up with security in mind.
Building on the core Transport Layer Security (TLS) incorporated into the Signiant transfer protocol, Flight contains a variety of security features that adhere to the information assurance principle of ‘defense in depth’. A defense-in-depth design strategy incorporates several security controls for a system so that multiple security failures must occur before an attacker can gain access to critical resources.
Two key components of this strategy are the principles of ‘least privilege’ and ‘secure by default’. Least privilege works on the basis that every task in the system should be performed with the most limited privileges possible in terms of both scope of resources and duration of time that resources can be accessed.
A corollary of least privilege is that mechanisms used to control access to resources should never be shared. A system is secure by default when the default settings put the system in a secure state, ensuring that overt action must be taken to disable security features.
When the customer account is created, each transfer client securely binds with the Signiant SaaS and the customer account using a one-time setup key generated by Signiant for this purpose.
This one-time key is used to securely establish and exchange security credentials, which are then used to validate and encrypt all future communication between the SaaS and the transfer client.
Flight automatically provides ‘encryption in flight’, via AES256 data encryption of all files in transit between the customer’s facility and cloud object storage, for both uploads and downloads.
Another layer of security is provided by Flight’s support for end-to-end encryption. This enables content to be encrypted in the client application, using customer-supplied keys, prior to sending it to the cloud. There the content remains encrypted at rest until decrypted again within a client application, using the same customer-provided keys.
For customers using AWS, it is also possible to enable the built-in encryption at rest capability of S3 from the Flight management console or the CLI.
Flight further increases security by maintaining the secrecy of keys and providing a range of options for controlling access to cloud storage. By using abstracted tokens based on customer-defined roles to determine storage access, the primary customer key to a cloud storage account need never be shared within a customer’s ecosystem.
This protection of account credentials is especially important in situations where a Flight customer provides access to their storage tenancy and Flight account to third parties, such as content producers contributing to a video aggregator.
Flight system administrators can configure access to their cloud storage by logging into the management console with their key and account name. From there is it possible to configure IDs for different partners, restrict access to certain containers, assign permissions for upload or download only, and more. Additionally customers can choose to give one ID to hundreds of partners, or give them each a unique ID.
With Flight’s SaaS control layer, all transfers are tracked and time-stamped. Through the management console, system administrators can see which client location sent or received the data and when the transfer occurred.
Traceability in and of itself is a deterrent to sloppy data handling, and the ability to perform fast forensics when a breach occurs is becoming increasingly important in corporate security best practices.
Flight serves both of these purposes by making it easy to monitor the flow of data to and from the cloud.