In the cloud, you need an architecture that meets your information security needs. After all, who wants one that doesn’t? Anyway, I’m going to cover a few key concerns to think about when you’re designing for cloud security.
Since you’re reading our blog, I’m assuming you work for a SaaS business. This means that cloud computing is an obvious choice - in fact, the chances are that you’re already running in the cloud.
Showing that you’re doing this securely depends on exactly what kind of software you sell and how you keep different customers apart (“tenant isolation”). Landing zones are a great way to set up the foundations to make that possible.
As a SaaS business, you’re responsible to those tenants - your paying customers - for part of their information security. Each firm you sign up wants control of how those data are shared, and they expect you to take care of confidentiality.
You might need an automated way to provision new tenants, and as you scale your business, the overhead of winning new business matters more. A good security architecture provides the level of tenant isolation that’s right for you, and a way to automate customer onboarding without compromising security in the process.
We’ve helped quite a few firms that work with sensitive data. A common example is details for payment cards, where the accepted practice is to define a boundary around any system that either processes card data, or directly communicates with something that does. The less you have inside that boundary, the less effort you have to show that it’s secure. Developers working outside that boundary encounter smaller obstacles to delivering value.
There’s often another drive for isolating and securing sensitive information: the cost of noncompliance. Security incidents that actually expose these data can lead to prosecution and fines, or other financial consequences such as liquidated damages.
In the cloud, responsibility for security and compliance is shared between you and the cloud vendor. On AWS, they’re responsible for securing the cloud infrastructure: things like physical data centre security, network and the virtualisation layer. You are responsible for securing the services running on their infrastructure, like patching up the operating system on EC2 instances and ensuring security groups are configured correctly. The good news for compliance is that the AWS slice of that pie is already certified and compliant with many standards - including ISO 27001. So that’s a load of stuff you don’t need to worry about.
Do your customers want evidence that you’re using two factor authentication? Maybe your own risk assessment identifies this as a critical control. At the same time, the team need to be able to troubleshoot issues and work on improvements.
We’ve got plenty of experience working with different single-sign on systems. Whether you’ve already got your own working login system, or you’re starting from scratch, you can give your customers solid evidence that you’re taking internal security seriously. Integrations such as SCIM let you automate adding and removing access as colleagues join and leave, or when they switch roles.
Using a packaged approach makes sense because it lets you and your colleagues focus on details that matter to your end users and their experience. I mean, those users probably do expect you to keep their information secure, but they usually don’t want to know how that happens. They just want you do do it.
If you’re using AWS and need to produce audit evidence, you should definitely consider using Control Tower.
Control Tower helps you to comply with standards such as ISO 27001, and gives you a great starting place to capture that evidence. There’s even an AWS account dedicated to audit work, included as standard.
The ISO 27000 series of standards are high level: the standards describe the approach to take and the control outcomes you need to achieve. It’s done this way so that any business can comply, whether you’re in manufacturing, retail, finance, software, whatever.
Sometimes you have customers - or sales leads - who want proof you’re doing these things. That’s where an ISO 27001 audit certificate comes in.
If you’re looking for an ISAE 3402 attestation, the controls for that come from ISO 27002 (equivalent to Annex A from ISO 27001), so the same approach applies.
In terms of ISO 27002, our Saas Foundations package for AWS provides implementations of several controls, including:
- Access control
- Configuration management
- Identity management
- Information access restriction
- Information deletion
- Monitoring activities
- Privileged access rights
- Protection of information systems during audit testing
- Secure authentication
- Secure system architecture and engineering principles
- Segregation of networks
I want to talk about what a landing zone doesn’t come with: servers. There aren’t any, at least not as part of the landing zone itself.
Once your landing zone is running, there are some new operational costs; these are often less than $10 per month. Any compute that the landing zone uses is serverless and fully managed by AWS. Because you’re not responsible for any new servers or similar infrastructure, your own staff costs for managing this are super low. In my experience, those costs are mostly for around changes to the rules about who gets access to what.
The right architecture
It’s important to make sure that the landing zone - or other architecture - you set up is right for you. Although there are a few fixed details, such as the security controls for the CloudTrail log archive, there’s a lot of flexibility in AWS Control Tower. That’s because different businesses have different needs.
When we start any project to set up Control Tower as a basis for an AWS landing zone, we run a workshop session to understand your context. That lets us spot potential snags such as extra costs, and explain how to account for that in the design.
If you were building your own - and we’d like to think that our fixed price package is going to be better overall value - it’s important to set an overall direction and draw up an architecture before you start. Once you’ve got a diagram and an architecture overview, that gives you a baseline for developer documentation - as well as shared context in case you want to discuss details.
Setting up a landing zone covers a set of controls from ISO 27002 that you’ll need to cover to keep the auditors happy - and for your own peace of mind.
Your onward journey
The benefit you get from a landing zone is that different teams can spend more time on delivering value, and less effort on work that doesn’t improve end user experience.
Charity Majors explains it like this:
Developer cycles are the scarcest resource in your company, and you want to spend as many of those as possible on your core product: the crown jewel, the code that makes you a business.
You might be doing a compliance project to help secure sales, or to protect revenue coming from existing customers. You quite possibly have customers who do want to see the audit certificate at the end of the process. However, their end users don’t and won’t see any improved user experience from this—and that’s fine.
A project that protects revenue can be just as valuable overall as work to add features. The difference is that only your developer team are experts in the second kind of work. That’s a key reason why using cloud services for a landing zone trumps building a bespoke security architecture.
What it boils down to is: repeating all of these security measures for each component, or for each service team, or even for each customer, isn’t cost effective. You want an architecture that lets you solve common concerns once, and that gives you a single place to manage specifics. That’s called a landing zone, and we can help you get one.
Designing effective systems security for your SaaS business can feel like a distraction from delivering customer value. Book a security review today.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.