Matt Hilbert

27 September 2023

Security in the cloud: Whose responsibility is it?

While the cloud is recognized as more secure than on-premises servers and infrastructures, it does come with the often talked about shared responsibility model. Cloud providers are responsible for security ‘of’ the cloud, while their clients are responsible for security ‘in’ the cloud. It’s ‘differently secure’, rather than the traditionally secure organizations have been used to when working with on-premises environments.

To find out what those differences are, what pitfalls await the unwary, and how security teams can help with cloud migrations, I sat down with Dustin Dorsey, Systems & Data Architect at Biobot Analytics, based in Cambridge, MA.

There, he manages the systems that analyze wastewater with molecular technologies and AI to provide early warning of population health threats like COVID-19 and norovirus across the globe. With over 15 years’ experience as a DBA, Data Architect and Director of Cloud Management and Analytics at a number of major healthcare organizations, he has a deep experience and knowledge of data and database management. He is also the co-author of Pro Database Migration to Azure and Unlocking dbt: Design and Deploy Transformations in Your Cloud Data Warehouse.

We had a fascinating Q&A session about the security issues organizations face when they migrate to the cloud, and how to overcome those issues. The result? This two-part blog series, in which Dustin talks about where the responsibilities for security lie when organizations migrate to the cloud, and then how to ensure security teams are on board with cloud migrations.

Do you think that organizations migrating to the cloud are aware of what their responsibilities are in terms of security in the cloud?

I think they’ve at least heard about the shared responsibility model, which is very prevalent in training materials and documentation, and is mentioned pretty much everywhere. Where I think there is a gap is that the understanding of responsibilities may get skewed, and some of these misunderstandings can lead to security gaps, or even over-engineering in cases. So it can go either way: you can have too little security, or you can have too much security.

One of the biggest misconceptions is that people assume the cloud provider handles everything, which obviously it doesn’t, or they think the default settings are the most secure, which they’re not always. Or they misinterpret default security settings, neglecting things like data encryption, which typically are not always on by default or, if they are on, it’s not encryption of data in transit.

There are also lots of new services coming out, and existing services are constantly changing because technology is always going to continue to evolve. So you’re going to need to stay up to date with what the settings are and how they’re configured. It’s not just ‘Oh, I learned this thing one time and I’m good’. It’s a constant evolution of learning. Things can change so fast that you might not even realize it if you’re not looking for it.

Who typically is included in a cloud migration project team?

It largely depends on what is being migrated, and then on the company itself. Different companies will have resources called different things and when you think about all of the people that are part of a project, you can have multiple folks, or the same person wearing multiple hats and filling many roles.

So someone who’s going to be the IT architect within your cloud migration project, for example, doesn’t necessarily have to have an architect title. It could be a data engineer or a systems engineer who has the relevant skills and it will vary from project to project, from company to company.

Core team members are likely to be IT architects or their equivalent, project managers, infrastructure and data engineers, network engineers and security experts, application owners, developers and QA testers. Outside of those, you may also end up with people from business teams, finance, other stakeholders who will be impacted by it, and leadership who want to be kept up to date.

Typically, when you’re doing a migration, especially if it’s one of your first migrations, it’s a pretty big deal. So there’s a lot of resources from your company, and a lot of folks who are very interested in it and who are going to be involved. It’s not just going to be a DBA, who’s sitting over here and wants to move this database to the cloud.

And like I mentioned, people can be wearing multiple hats because not every company will have someone dedicated to a particular role, especially if you’re a smaller company. It doesn’t mean you need to run out to a consulting company or post a new position to try to hire for it. That may be applicable if you don’t have the skills to be able to do it, but that’s something you should evaluate first.

Where does security come into the picture?

In my experience, regardless of where you are, security should be something that starts near the top and is continuously considered throughout the entire project. Security people should constantly be assessing potential risk and compliance requirements.

Even before you get to the migration, they should be evaluating your on-prem systems for vulnerabilities because it’s likely that some exist there. When you’re working within your private network, with private data centers, etc, it’s maybe okay – you have firewalls, and you have protections on the exterior that protect some of that. But if you pick an application up and move it to the cloud, there are vulnerabilities associated with it.

Security teams should be communicating those vulnerabilities from the very onset of the migration, so that you know what to design for once you move to the cloud. They should have policies and procedures, and components requirements should be defined and documented before you even start your design work. So you should know these are things you need to bake into the architecture before you start a migration.

Throughout the implementation phase, security is oftentimes implementing those policies and controls, and even in some cases part of the configuration and implementation of the services. So they’re working with those in DevOps or CloudOps roles, making sure that you’re standing up the services correctly.

There’s also the operationalizing and monitoring that they’re part of. So they need to be made aware of when there is an issue, and they need to be able to respond quickly. They require monitoring capabilities to know if there are people trying to get in and pinging your service, or if there are potential vulnerabilities that you should track for. They should be performing ongoing assessments of that. And beyond those smaller things, there are things like documentation and training and continuous improvement that should be going on.

So to wrap this up, security plays a role in every part of the migration, and they should be a part of the conversation from the very beginning.

In the second part of this series, I ask Dustin about how to get buy-in from the security team, as well as some healthcare and finance-specific cloud migration challenges.

To find out more about best practices for cloud migrations, and optimizing your cloud adoption efforts, read our previous posts:

• 7 Essential Factors for a Successful Cloud Migration: A Non-Technical Guide
• Managing the challenge of migrating to the cloud