Lightyear Security
The goal of Lightyear is to remove much of the pain of writing integration code. Since integration by its very nature requires Lightyear to access systems on your behalf, it is essential that Lightyear employ security best practices. This document outlines the measures we have in place so far. If you have any questions or concerns, we are eager to hear them. You can contact us at [email protected].
Architecture
Lightyear's architecture is designed to allow high performance execution of code supplied by users in a secure manner.
Code Execution
All code in the user's production environment are uploaded into and executed within an AWS Lambda. This Lambda is unique to the user's production environment and is never shared with other customer environments.
Network access
Production Lambdas are restricted from any network access except for Lightyear's internal load balancer and must proxy any https traffic through this load balancer and then through the Lightyear API. Lambdas are expressly prohibited from communicating with other Lambdas.
Memory and Computation Limitations
The production Lambda's are configured with strict memory limitations and run time limits and will be automatically be halted if they attempt to exceed either.
Redacted Logs
Lightyear allows user code to output data to the logs while running. The output is run through a filter that redacts any known secrets before the output is stored. The redaction retains the last 3 characters in plain-text to assist with debugging. Take care not to log very short secrets, such as 4-digit PIN numbers.
Encryption at Rest
The production Lambdas are stored with an API key to supply as a credential when making requests to the Lightyear API. This API key along with all other environment variables are encrypted at rest.
TLS Encryption
All traffic to Lightyear must be encrypted with TLS v1 or later. This is a choice to balance both security and compatibility since Lightyear needs support integration with legacy systems which may not implement the very latest security protocols.
Command Line Interface
The API key that the Command Line Interface (CLI) uses is currently stored on the filesystem in in cleartext. We are making plans to store the credential in the OS keychain.
Data Security and Durability
Lightyear stores data in an AWS Aurora cluster, which is a managed database service that provides excellent support for scalability, reliability and security.
Encrypted Storage at Rest
Lightyear's database has encryption enabled, so basic data is stored securely at rest.
In addition, secrets such as OAuth access tokens are stored in database columns that are encrypted/decrypted by the Lightyear web app using AES-GCM with 256 bit keys.
High availability
Lightyear's Aurora cluster has both a writer and a reader instance. In the event of a primary database failure, it is rapidly replaced with the standby reader instance.
Backups
Lightyear's Aurora cluster takes daily snapshots and stores database log records which allows for point-in-time restoration (PITR).
User Authentication
Lightyear uses a well-respected 3rd party authentication service called Clerk (opens in a new tab), which is configured to allow authentication with username/password or GitHub via OAuth. Users can enable multi-factor authentication (MFA) using authenticator apps that implement the TOTP protocol such as Google Authenticator. Users can also generate a list of backup codes in case they lose access to their MFA app. We plan to support hardware-based keys when that support is available in Clerk.
3rd-party Penetration Testing
Lightyear contracts 3rd party firms to perform at least one comprehensive penetration test per year. In addition, Lightyear may contract firms to perform tests on new functionality that could have security implications.
Bug Bounty Program
Lightyear plans to establish a bug bounty program later this year.