EP81 Demystify Data Sovereignty and Sovereign Cloud Secrets at Google Cloud

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Timothy Peacock, the product manager for threat detection here at Google Cloud, and Anton Chuvakin, our reformed, tamed, and now much nicer analyst and esteemed member of our cloud security team here at Google. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you like our content and want it delivered to you piping hot every Monday afternoon Pacific time, please do hit that subscribe button. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, this is a fun episode for me because I was a political science major. Fun fact. Didn't actually major in computer science, and here I am. But we spent a lot of time talking about sovereignty and what it meant, where it comes from. What does it mean? How do you have it? How do you know if you have it? And I think those same questions are faced by our cloud customers.

Yes. And you would assume, or maybe somebody in the audience would assume that this is kind of about compliance, but it's really not so much about compliance.

No, I think it's much more useful than that.

It's way more useful than that. And it's almost like veers into geopolitical matters. And at the very end of the episode, it just takes a bit of an ominous turn. And like, how do you do cloud if there's like a maybe even warfare among countries? I don't know. It's some of the stuff is really scary. And it gets very like, I'm the type who gets excited over everything. But this time, I was kind of like, whoa, this is some serious stuff we're talking about.

Yeah, this ended up being quite serious, in fact. And, you know, one of the things I love about our guest is he's dealt with some quite serious things in his life. I mean, he used to be a fire captain. Among other things. So we have a really wonderful guest today, listeners. And with that preface, let's turn it over to CJ. I am delighted to introduce today's guest. Today we are joined by one of my absolute favorite coworkers, somebody who's been on the team with me since before I started at Google, CJ Johnson, the only PM at Google I know who's a retired fire chief, and today the global regulated cloud TJ, you have an interesting background. I have also an interesting background as a poli sci major. And in my world, we define sovereignty very narrowly as a local monopoly on the legitimate use of force. So what are you doing talking about sovereignty in IT? How did something as dry as IT end up becoming a matter of national interest? What's going on here?

Yeah, I mean, it's turned into a whole topic of interest for really everybody globally in cloud, right? And, you know, what we think about when we talk about sovereignty in cloud is a couple things. And at Google, we think about it really in 3 ways technically, right? We think about data residency, we think about personnel access, and we think about encryption. And really, those are the 3 things that we think about when we're talking about sovereignty. But we also describe it in really 3 different ways of describing what sovereignty is.

Wait a second. Residency, encryption, what's the third?

Data residency, encryption, and personnel access. So who has access to support or access the data? really the things that we think about. But we also define it, and Tim, I love that you asked the question of, like, what in the world do you mean by sovereignty? Because this is something we run into with customers and regulators and everybody globally. Like, what in the world are we talking about here? And we've tried to break it down really into 3 different layers, right? Data sovereignty, operational sovereignty, and what we call software sovereignty. And each of these has different meanings, right? Data sovereignty, when it comes down to it, The question of whether or not, let's say, a government shows up with the right piece of paper and asks for legal access to data is really what we think about here.

Hmm.

And this has turned into such a huge thing over the last 10 years. It's getting bigger and bigger, right? Especially as we've seen this evolve with new regulations globally, especially starting in Europe and some of the court cases there that we've seen. And with data sovereignty, what we're talking about there is Let's say a government shows up with the right piece of paper. Do we turn that data over to that government entity? And the answer to that is, when we've done data sovereignty, the answer is no. Like, we can't do that.

We're unable to comply, right?

We're unable to comply, right?

Right. And this is kind of important, right? We're unable to comply as opposed to we won't do it, right?

Exactly. Yeah. Very, very different, right? We won't do it means you're just going to get tangled up in court cases and the chances are you're going to lose.

And it would mean that Google was being a bad global citizen. have to follow the law where we operate.

That's right. Yeah, we're not going to break the law, and if you show up with the right pieces of paper, we're going to comply.

To the extent that we're able.

Yeah, and that's where this is important, right? When we've built these controls effectively to provide data sovereignty, we can't comply with that legal request, right? The entity that has the ability to provide that data is the end user, and that's what we're trying to provide with the data sovereignty controls. But that's really what data sovereignty means though, and also why it consists of these 3 components of where does that data live, who has access to the data, and how is that data encrypted and who has control of the keys.

So hang on, this is actually kind of amazing. What you're telling me is that with just 3 things—

Finally, Tim.

No, no, I'm having a moment, Anton. With just 3 things, data residency, personal access control, and encryption, we're able to say we can't do that.

Those 3 small things, so easy.

Just 3 easy things. Yeah.

Yeah. And I mean, of course, what it means to provide those is just unbelievably complicated at the end of the day when it comes to a hyperscale cloud provider. But our belief is that if we take care of those 3 things and we do those well, then in the context of sovereignty that we're talking about here, which would be a legal request for data, it would have to be only handled by the end user. And in our case, you know, a customer of Google Cloud Platform or something like that.

By the way, to kind of tie it to, well, to cloud a little bit, like you mentioned data sovereignty, you mentioned software sovereignty. So, when I think of modern, as you said, hyperscale cloud, I'm thinking of a combination of procedures, people, technology stack of some particular complexity. So, when you try to apply the label sovereign to the entire cloud, it sounds kind of complicated and it's sort of a little confusing. And I immediately start assuming, Ah, maybe it's all marketing. From your answer, it's very clear that it's not just marketing. It's very much grounded in reality. But how do you think of sovereign cloud in particular?

Yeah, it's a good question. And I don't believe it's just marketing. I do believe that there's a lot of technology that provides the outcomes that we're talking about here. And to your point there, what does it mean in the context of cloud? And that really starts to get into the operational sovereignty question, which would be, Like, when we really think about that next level of sovereignty, so that first level, which is data sovereignty, which would be a legal request for data, for example, we talked about that. But the next would be, what does it mean to have a really sovereign cloud? Let's say, for example, in a country, some, I don't know, an event occurs where the software's embargoed or fiber lines are cut or things like this happen. And we've seen it recently, right? And we've also seen the inverse of having too sovereign of a system, right, where you need to be able to flex internationally. You know, for example, the events in Ukraine have highlighted the importance of being able to, you know, have flexibility when it comes to how you implement your sovereignty controls. But the operational sovereignty means you'd probably be able to withstand some more of those kind of international pressures or government pressures or things like that and still have an operating cloud environment at the end of the day. And then software sovereignty goes to a next level, which honestly, just as me, a technologist and somebody with an opinion, I don't think is actually possible. So, with software sovereignty, it means that you have the entire supply chain and you can build new cloud and ship new software and do everything inside of the boundary of your country or your jurisdiction or your sovereign territory. And I don't think that's— it's just not possible.

Not going to happen.

Honestly, the supply chain's too complicated.

Even if we do things like pin our dependencies and try our best?

I mean, sure. You can probably increase the software sovereignty of an infrastructure by tightening down the supply chain or increasing, for example, I don't know, just working on your software supply chain and bringing that all in-country or something like that. You could increase the resilience of software sovereignty. and probably make for a stronger supply chain, but you can't create a sovereign environment that way. You can just— you can probably increase the amount of time that you could last in the event that you were embargoed from receiving software, let's say, or embargoed from receiving chips or something along those lines. But the truth is, it's only a matter of time before you run at the end of that.

So a lot of this actually is great cocktail conversation for policy wonks and technologists, but it also sounds like there's a customer need behind it. So in terms of who cares, or maybe also who should care about this, is this about specific countries? Is it about specific type of clients? I'm curious. Like, it's exciting to talk about, but like, who actually would pay money for it?

Yeah, this is actually one of the reasons that I love working on this is the problem isn't a Google problem, right? This is a customer problem. And the folks that I work with most in the sovereignty space are those in, of course, the regulated verticals, which aligns with the team that I work on. But really, the folks that care about this are my customers in those countries with the sovereignty concerns and something along those lines. And again, the sovereignty isn't just about the data. So for example, let's imagine that I'm a bank and let's say I'm a major bank. In, I don't know, let's pick a major market, right? And a bank in these major markets, the government is relying on them to run their economy in a lot of cases. And if you don't have good sovereign operations or sovereign capabilities, the ability for another government or another country or another company even to impact my entire economy really exists, right? This is an actual problem. These are material or financial workloads and things like that. Similarly, in healthcare, we also see this in public sector. So, what I love about my job in terms of working in this space is I get to work on these solutions. And again, it's not a Google problem. This is a problem that my customers face. And if they need to run these workloads in these verticals, which are giant verticals, these are really, really important industries, economy-changing, country-changing industries, you have to have these types of controls in place. You just simply can't do the work. The other thing that's really interesting about this to me as well is what we're seeing is more insight and regulation around the entire supply chain. So for example, what we see are contract terms from governments that get passed down through an entire supply chain. So in other words, a government in— I mean, shoot, we can just use the United States— has these the Federal Acquisition Regulations and the Defense Federal Acquisition Regulations have terms that flow through to the entire supply chain, which means as a pencil supplier, I have these regulations that apply to me because I'm selling to the seller that reaches the seller of the Defense Department, right? And what that means is that the entire supply chain gets affected by these. So, enterprises that sometimes, you know, you wouldn't imagine having to have sovereign controls in place actually need them, especially in the context of cloud. And that's why this is a really fun area for us to work, actually.

So that is really interesting. I wouldn't have guessed it comes from that kind of place. I want to sort of maybe poke at this a little bit. When it comes to sovereignty, are we more interested in the technical controls or the policy controls, or is it both together? Can you have one without the other?

I think I know the answer. Can I, can I please, please, please?

Oh my God, you must have been the most fun to have in classes. Yes, Anton, in the back, please tell the class what you think.

I think it must— from the previous answers, it almost certainly must be the technical controls, right? Because you're not going to hold the government with a paper. Yeah, like it absolutely necessarily must involve technical controls.

Oh, right, for sure. It's mostly about technical controls from our point of view at Google. We really believe it's about the technical controls, but I mean, we're, we're geeks at heart, so like that's how we think about it. And we also believe that that's been the case that we've seen from our regulators and from our customers as well, is that it really is about the technical controls. I mean, the rest of it can definitely be challenged. That being said, we do back this up with contractual terms, audit controls. We're ready to defend these things from a legal perspective as well. So it's definitely about both. And in fact, one of the things we do a lot of times is work with regulators So, like, I'll chat with, let's say, a European regulator, for example, and talk about the edges of data residency and when and where that makes sense. A good example of that was, you know, a recent conversation we're having around data sovereignty was, you know, requiring that all data be located in a specific country. But in Google, we enforce security throughout the entire network. And one of the things that this really brought up was, sure, like, core customer content, you want that in your jurisdiction, that makes sense. But what if you have a firewall rule? IP addresses are considered PII, so are email addresses. We use these to enforce security throughout our entire network. Wouldn't you rather we use that information to stop attacks where they are instead of bringing them to you, you know, in your customer content? Which means that if you think about it from that perspective, that means that acceptable use and, you know, appropriate use of that information is really good for the outcomes in a jurisdiction or in a sovereign context. And that's one of the areas that we push on in policy, because the policy itself a lot of times has these strict, like, you have to store all things here, when in fact that actually has negative outcomes, right? That creates a lot of times the opposite of what you're trying to achieve from a sovereignty perspective. So it's both, but from our perspective, like, at the end of the day, it has to be technical controls, and that's where we focus our energy.

And it sounds like in some cases, if there is a slider for sovereignty, you can crank it towards sovereignty so far that the resilience would suffer to an extent that it would not be solving the problems you have, right? So, I think I have a scenario in mind where you crank it to be so sovereign that it doesn't solve the problems you need the cloud for, right? That's also possible.

Oh, very much so. We see that. And in some cases, that makes sense. In some cases, you need to be able to do that. So, For example, maybe some public sector or some defense-related workloads, things like that, where you need for it to be super, super sovereign, and you turn that slider all the way to the end at risk of decreasing your resilience, decreasing your performance, decreasing your availability. But on that risk perspective, you need that turned all the way up, which means you're going to turn all those things way down. That's okay. Sometimes there's workloads for that. I would say that the vast majority of the customers and even governments that I work with, They're putting that slider in the middle, right? Where they're willing to decrease some of their performance or resilience, increase their sovereignty, but not turn it all the way to the end. Otherwise, it has negative consequences.

That makes sense. So to continue down this path, I mean, you mentioned 3 pillars, and of course, encryption was one of the pillars, right? I dealt with External Key Manager, our amazing technical innovation, kind of in this area a little bit. And so I'm kind of curious, when I think of encryption keys being in customer possession, you know, under the proverbial mountain in Switzerland or whatever else. So it sounds like EKM and similar technologies are a key pillar of sovereignty, right? So could you maybe explain it with more examples? Like, how does EKM play into this, and how else we use encryption to sort of assure sovereignty?

Yeah, yeah, I love it. And you're right, like, this, from our perspective, is the technical control that creates the sovereign outcome that we're looking Which means that, like I said, if a government shows up and says, hand me the data, which by the way, you know, we do publish in our transparency report, that just doesn't happen because that isn't the fastest way to get data for governments when they need it. But yeah, EKM, so external key management, coupled with another technology we call key access justification, when you put those 2 together, you end up with a very strong technical control. that prevents the cloud provider from either accessing or turning over the data. What happens with that, of course, is when the external— when the key is held and managed externally from Google, then, you know, we don't have access to that key material, and we can't use it for purposes of decrypting the data, combined with key access justification. So that happens, and that's really good. That creates good outcomes, but it's not enough. And here's why. Because you have to have the keys at some point to decrypt the data to process it. It has to be decrypted in memory at some point to do stuff. It has to be useful. And the reason key access justification is required is, with that control in place, the customer has the ability to tell Google when we're allowed to use that key.

Mm-hmm.

So, you know, 99 times out of 100, it will be because we need to process data. We need to do the thing that you asked us to do. So you're going to hand us the key. We're going to say, can we use it for that? You're going to say, yep, absolutely. That's great. And let's say on that 100th scenario, which, by the way, is Like I said, it still doesn't happen, but like the control's in place. The requester shows up, asks for access to the data, and the reason isn't to process it, it's some other reason, to support or whatever else. You can say no to that. And when you have that control, which prevents you from using that key to decrypt the data and process it, it means you have control over when and how that key is used. So you combine those 2 and you end up with a very strong sovereign control that's in place to protect the data for that outcome.

But this has to be married with the paper control, because as a pure technical control, that wouldn't cut it, because people may be compelled to lie about their justification, right? So in that sense, you probably need some paper controls, not just code.

Absolutely. Yeah. So the code, you know, the technical controls are in place, and we stand behind them, right? We stand behind them with audits and technical controls, as well as contract terms, which really To me is how you actually do this really for all of our security controls and even our performance controls, right? We could be compelled to lie about a lot of things, but what we do, as any real entity of our shape and size does, is we stand behind it with 2 other systems, right? Contract terms and then audits that stand behind those contract terms. So, have a third-party auditor come validate that we did what we say we're doing and put those into contract terms. And that way you've got the paper control, You've got a third-party view and audit of that, and you have the technical control that provides the outcome. And that's really how we take care of this for our customers.

Okay. So this is really interesting because this is reminding me a lot of the conversation we had with Sunil Yu a couple weeks ago about safety versus security. A lot of what you're describing feels more like the kind of safety approach that keeps, say, airplanes from falling out of the sky, which, our credit, they do a lot better at that than we do at preventing hacks. So this feels a lot like safety rather than security, but I have to ask, are sovereign cloud setups more secure, less secure, orthogonal to security? What's the relationship there?

I mean, I like the analogy you're using, which is this is much more of a safety than security control. And does it increase the operational security of the data? A little bit. I mean, it does have an outcome there, right? And it decreases insider risk is really what the control is taking care of. So there is a security outcome that's generated here. That being said, you know, we've got dozens upon dozens of insider risk controls, and this is yet another one. So it's hard to say that we've increased, you know, operational security significantly with a sovereign cloud, at least at Google. But it has happened, right? It does decrease that. It adds more and more controls in terms of— Access to customer content, but it is much more of a safety control. And there's a trade-off there. Like you said, Anton, like even using EKM and KHA, I love these technologies. They create amazing sovereign outcomes. They come with a cost, not only money, but also you have single failure points there, right? You've increased your latency because you're passing keys around. You have a control point where which you can automate, but can also be manual in terms of approving access to that key. So all of those things create super sovereign outcomes, but also increase the complexity, decrease potential resilience of those workloads. And that's kind of the trade-off that you make when you're doing those things.

So this is actually kind of fun because I see how it's not about an unambiguous answer. Yes, sovereign means more secure, or Eh, no, you're sacrificing security. It's really more about you're much closer to furthering somewhat different outcomes. It's not always about raw power to stop certain threats. It's kind of about your goals may not be just in increasing security, but in solving other problems that you have. So to me, this is kind of a useful— it's a bit of an it depends answer, but at least I understand fully what the logic is. The logic is not necessarily to boost security. It's to boost security down a particular axle.

Yeah, that's right.

So to kind of go down that path, I mean, I want to ask you a fun question. And I know that in our prep discussions, we discussed that maybe some things we can't really say, but like, what can you say about the threat models that are considered when this type of systems are built? Like, what sort of nightmarish scenarios are being discussed when we are deciding what to build in this area? Like, what are the threat models that we go through?

Yeah, I mean, this is one of the areas that I love working on. This makes it a lot more fun, right? And I've had lots of really interesting conversations with governments here, right? Because, again, these are, you know, some of the public sector or maybe even defense-related workloads, right? And when you're talking about that, so let's talk about like data residency, for example. One of the questions is like, why do we care about data residency? And where does that come from? Now, there's a lot of reasons that you require data residency, but one of the threat models, which is kind of interesting, is making sure that your data is, for example, in your air protection district, right? So, for example, being able to ensure that those data centers are safe from physical threats. And when you're a government and you're thinking about how you protect your systems and infrastructure, one of the things you think about is those air protection districts, making sure that the thing can't be attacked from the air, for example. So, there's dozens of other reasons you care about data residency, but that was kind of a fun one that I had a conversation with governments about. The others are, again, we talked about it with operational sovereignty, but attacked fiber lines and thinking about, again, these are more physical threats. But then there's the operational threats, which would be, let's say somebody shows up at your data center with not only the right piece of paper, but with some angry-looking people with the right type of tools in hands. We want to be able to ensure that we're protecting our customers' data and also, of course, our employees in that situation.

Yeah.

So those things come into mind and those are some of the models that we imagine and think about.

All right. Well, that's a really good answer. I wouldn't have thought about air defense in the context of cloud computing and perhaps that's—

Well, it seems logical, right, Tim? Cloud, air defense.

That seems like a miss on my part. So now I'm going to think about that. CJ, we're just about out of time here. Do you have one tip for improving your sovereign controls and Any recommended reading?

Yeah, I think the one tip is focus on encryption, right? That's the area to focus, no matter what cloud provider you're using, whether it be our peers or, you know, Google Cloud. Data residency is great, the personal access controls are great, but at the end of the day, it's always about encryption. That's the way that you achieve sovereign outcomes, and that's where you have to focus your energy. In terms of further reading, yeah, we've written, you know, a few white papers on the subject of sovereign cloud. And one of the ones that we published last December, which is relevant reading and also important for some of these sovereign contexts, is something we've coined software-defined community cloud, which isn't a super exciting name, but I called it that to align with some NIST 800-171 controls. But it kind of describes the concept of virtual sovereign or virtual community cloud concepts, which are really interesting to kind of learn about and can align with some of the regulations and compliance controls that our customers are thinking about and looking at.

I never thought I would be excited about a NIST control, but that actually is exciting. CJ, thank you so much for joining us today. Listeners, let us know what you think about Sovereign Cloud. We're looking forward to hearing from everybody about that. And with that, thank you for joining us.

You guys are awesome. Thanks.

And now we are at time. Thank you very much for listening and of course for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, Or wherever else you get your podcasts. Also, you can find us at our website cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter twitter.com/cloudsecpodcast. Your hosts are also on Twitter at Anton_Chuvaikin and Tim Pico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.