Infrastructure is the backbone of any system or organization. It combines components and includes hardware, software, networking components, an operating system, and data storage.
In other words, it's like the root of a tree. Stronger the roots, the stronger the tree. Similarly, the stronger the infra, the stronger the product's core, stability, or security. When it comes to security, a system is considered secure if it can restrict access of both production data and resources to developers. It can protect customer data by isolating cloud services from other services. It does not allow access to any resources and data outside the Private network. It also should maintain multiple isolated environments and their accessibility.
Protecting data against any theft is of utmost priority. We at LambdaTest follow the standard norms and best engineering practices to ensure that Customer data is safe with us.
Action items we take to ensure data safety and integrity.
- Everything behind VPN: All the software tools, internal and external third-party applications, servers, and databases are only accessible behind VPN.
- Isolated Network and Cloud platform account: Every organization uses a couple of different environments in their deployment cycle like dev, stage, pre-prod, and prod. There are multiple ways to maintain all the environments on the cloud platforms (AWS, GCP, Azure), by using different namespaces within the same network and account or using completely different networks and accounts.
We use the different private networks in isolated cloud accounts to maintain production resources, services, databases etc. These are accessible only by a trusted entity. And, there is no connection between other environments' network interfaces. As all the resources, data is behind a private network, making it impossible to access the internet. It also helps us to maintain internal developers' access using the RBAC.
Maintaining different accounts/networks is also challenging to manage, but let me tell you how we do at LambdaTest.
When you reach a good scale, manually maintaining the Infrastructure becomes tough. It isn't easy to replicate the same resources or services across all the environments, so we went for Infrastructure as Code (IAC). IAC is a process by which you can provision and maintain your Infrastructure using the codebase. There are a couple of software applications to achieve this, but Terraform is one of the best tools. It supports cloud providers like AWS, Azure, GCP, etc. It could be easily integrated with other SaaS platforms like Cloudflare, Vault, etc.
We use Terraform across all the environments, and it helps us to manage it easily. Having said that, it's a part of security as well, but…how?
There's always a lingering doubt— what if you make a change manually in one of your products? Will it have any impact on the other products or not? It's a no if you are using Terraform MicroService architecture.
Terraform MicroService architecture is a way to design Terraform scripts differently for each product so that when you're making any changes and applying them on the cloud, you're sure they won't affect any other product.
With this, we've integrated this architecture on GitHub Actions so that every product team's lead can handle their infra accordingly.
The principle of least privilege: This states that any resource or service will have only limited access to function adequately, and we follow this. All the resources and services have limited required access to make it functional. This same policy is also applied to all the developers to access cloud resources across all the environments.
Multi-Factor authentication: Multiple factor authentication (MFA) means you add some extra security to access something, and it works the same as OTP. So, to access any server and database, OTP is required, and it's integrated with business email.
Encryption at Rest: It's designed to prevent the attacker from accessing the unencrypted data by ensuring the data is encrypted on a disk. All the data at rest in distributed file systems or disk storage volume during processing is encrypted using AES 256 encryption.
Encryption at transit: This is quite different from Encrypted at Rest as it's designed to prevent the attacker from accessing the unencrypted data while communicating from one service to another. In other words, it protects the data if communications are intercepted while data moves between your site and the cloud provider or between two services. This protection is achieved by encrypting the data before transmission, authenticating the endpoints, and decrypting and verifying the data on arrival.
Role-based access control: To enforce the Principle of Least Privilege Access (POLP) more effectively, resources and operations are managed by a role-based access control (RBAC) system. This helps us assign resource and server permissions to developers based on requests.
Automated Backups: AWS offers an SLA agreement with > 99.99% durability, but there will always be uncertainty in case of complete region collapse. This could happen due to human error, which can impact precious data. So, to ensure we don't lose customer data, we take automatic backups in different regions.
Centralized Secret Configuration: Secrets play an essential role in any software application as they are key elements in connecting with other resources, services, and databases. Having all the secrets centrally helps us to maintain and protect them easily. We use AWS Secret manager as a service to keep all the secrets so that it doesn't get exposed to anyone. We've added different types of policies to give access to developers across all the environments.
Auto rotated secrets: I explained in the above point that secrets are key elements of any software application; thus, rotating them from time to time is very important. AWS Secret manager provides this functionality to auto rotate database credentials. We've implemented this service in all the applications, so we don't have to hardcode any credentials. It helps us to protect databases.
AWS IAM Keyless Infra: There are two ways to access AWS resources— using an IAM role or AWS IAM keys. IAM Keys are very sensitive because everyone can access AWS resources using them if they are not IP protected. So to avoid this, we use only role mechanisms to access resources within the application. It leads to the following Principle of Least Privilege(POLP).
Security is as important as the speed and user experience of the application and should not be taken for granted. We have a security team that takes care of it across the products. This has been done by following widely acknowledged security standards and principles and getting necessary compliances.
To learn more about Security in LambdaTest, you can reach out to us at firstname.lastname@example.org.