Blog
Updated 15 Apr 2022
As mentioned previously in How to Stay Compliant When Deploying Fintech in a Public Cloud, there are strong incentives to deploy fintech in a public cloud. These incentives include a shorter time to market, less up-front capital requirements and greater scalability. Similar to the compliance challenges, it’s easy to overlook security ahead of time in an effort to “move quickly”.
In this article, we’ll discuss cloud security: tactics for staying secure when deploying your fintech SaaS in a public cloud and tactics you should think about before you launch.
Even though you’re using a public cloud service, that doesn’t mean you have to use a public cloud. Most public cloud service providers (CSP) offer a virtual private cloud service. A virtual private cloud (VPC) is a secure, isolated private cloud hosted within a public cloud.
If you choose to use a VPC, it’s important you understand how to use it to maximize security. In general, network-level security is stronger than application-level security. The good news is that VPCs offer a lot of ways to strengthen network security.
For example, AWS provides you with “complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.” Other available networking mechanisms to enhance security include VLANs, DMZs, VPNs, NAT, ACLs, load balancing, and ingress routing.
VPCs combine all the benefits of a public cloud (i.e., scalability, convenience) with the data isolation of a private cloud. In many ways, it’s the best of both worlds
Cloud data security best practices dictate that you must encrypt data in transit and data at rest. And that continues to hold true when deploying a fintech SaaS in a public cloud. And just as with VPCs, CSPs are prepared to support the most stringent encryption requirements by making the most advanced encryption algorithms (i.e., TLS and AES256) available.
With respect to Google Cloud Platform (GCP), “GCP uses AES-256 encryption by default when data is at-rest in Google Cloud Storage, and data-in-transit is encrypted with TLS by default.”
Of course just because you have access to the latest encryption, doesn’t mean you’ll use it properly. On the one hand, encryption should always be configured on the lowest level possible. On the other hand, you don’t want to apply encryption where it negatively impacts performance. One common mistake to avoid is to unknowingly encrypt/decrypt data multiple times throughout the data lifecycle.
Another cloud data security best practice is to always use service accounts, and not user accounts, for significant security actions (like encryption). From Google Cloud, “A service account is a special type of Google account intended to represent a non-human user that needs to authenticate and be authorized to access data in Google APIs.” This gives greater control over security while eliminating human variability.
Hybrid cloud combines and unifies public cloud, private cloud, and on-premises infrastructure to create a single, flexible, cost-optimal IT infrastructure. There are circumstances, especially with a fintech SaaS, in which a hybrid architecture makes the most sense. In this case, it is usually combining a public cloud deployment with on-premises infrastructure.
Hybrid setups are more secure by nature as they provide the freedom to have key data or services under full control in a DMZ zone. Hybrid setups can also help your SaaS with a regional presence by ensuring data is geographically located where it’s supposed to be for compliance purposes.
Another benefit of the hybrid setup is that it allows your SaaS to have on-premises processing/persistence of the sensitive data while simultaneously avoiding “vendor lock-in”.
The bottom line is that a hybrid cloud setup for a fintech SaaS affords the maximum possible control over data and data processing when it comes to security (and compliance).
Once you commit to deploying all or part of your fintech SaaS in a public cloud, there are some specific steps you must take to keep your SaaS secure. For starters, whatever part of the application you deploy in a public cloud should be deployed in a VPC within that public cloud.
You must ensure that no matter where your data reside, they are encrypted in transit and at rest with the most advanced encryption algorithms. And, you should make sure to optimize your encryption-performance tradeoff.
Finally, there are compelling scenarios where it makes sense to deploy part of your SaaS in a public cloud and part of it on-premises. Your security, regional presence and compliance requirements will dictate when it makes sense.
Our newsletter (you’ll love it):
