How Google Protects Your Data at Rest and in Transit (Cloud Next '18)
Hello. Everyone thank, you very much for coming to our session we'll. Talk today about how Google protects your data arrests and transit, my, name is Ulsan Lee I'm a product, manager in the security, and privacy area, it's specifically, working on key management and I'm. Here with Maya, Katsuragi, who is working. On gke security. She. Used to be I guess. You, know what. I'm doing now is so so you still in the key management system I took. Over for her so in, case you can't tell us apart she said you know she's one more hair and so. That that's, the, main we can do it and, I'm also no same and, this is just basically, my OCD Gnaeus but people, like to send the edges, of the rows I'm not sure if that's for quick exit or whatever else but yeah. Probably right, so. Quick. Question how. Many people here are here. To learn more about data at rest as opposed to transit. All. Right and how, about didn't transit is that more important. Well. Too bad you're in there both right so. So. You're. Going to learn about the data rest on transit today and I promise, you that you'll learn something, new maybe. Not necessarily one or other but hopefully, in both and. So. When we talk about encryption, right we usually talk about three, broad areas so, you talked about data risk which is typically you know the data that's stored on disk or, when you're not using it data. In transit when you move it around right over you, know networks or you know from IPC. Inter-process communications. Or in use when the day is actually loaded, into active, memory and it's being used now, we're going to cover rest. And transit not so much in use right now and, it's not that I don't want to talk about in use but you know currently, right now there's not a lot of great, industry solutions around this and so. You know but. The rest, and trends are very very mature type, of technologies, now. When. We start talking like encryption, at rest you. Got to kind of think about how enterprises, approached encryption, so. This. Picture kind of depicts different. Types of customer, or, enterprise customers, so you may have small customers, who basically. Probably. Don't have a lot of need for maybe key management maybe, they are looking to actually use a default solution that the cloud provider provides them not, sort like service a they, basically take the encryption mechanism that's provided, with whatever, is provided, to them and, as, they get a little bit bigger they may decide that hey, I want, to do my own key management right, I have more complex scenarios I have more data I have different keys I need to use and so, I may actually have either my own key management system off-the-shelf, whatever is available and, we use that right and.
Then. You get to like maybe, a service C and this is where you're talking about the very large corporations. They've, got lots and lots of keys right and so when you have lots of keys then, you have to do a lot of key management and when, you do a lot of key management things get pretty complex and they may, have custom solutions, to handle this in, addition, to actually just using the keys to actually be stored in the kms they may also use something called an, HSM, or hardware security module. And. How. Many people here know what at HSN is, wow. That's. Amazing you guys are in the very right to the class so. They. Use HSN because it provides some you, know levels of assurance around, you know compliance, security things like that and that, makes it feel really really good. Know. When. We start talking about the Google cloud and one. Thing I want I always like to mention to everyone make sure everyone's aware is, that when. You put your data up into our cloud we always, always encrypted there's no such thing as unencrypted. Data arrests right and there's nothing that you can turn, off or do anything like that it's just something that we do and there's, no choice around it now. The data gets upload to Google and what we do is we go through this very elaborate process to, actually protect your data in several different ways the. First thing we do is that we take the data we break it up into small chunks no, you can think in the shards, or blocks or whatever you want to think of but, they're broken up into small chunks and for each of those chunks we generate a random unique. A s key okay. And so, you may ask why do you do that well it's obviously. It's one, of the obvious reasons is that it reduces a blast radius so, if one of these keys gets compromised, then you don't lose all your data, lose a small fragment of it and in, order to actually get access to the complete set of data you have to actually be able to break. All these different keys which, is actually not a trivial thing to do right. And. So each, data, each chunk of data gets us own encrypted, key and, the. And this encrypted. Piece chunks of data gets kind of distributed throughout the data center okay, they get replicated and, they get moved around and so you know again this, is also also helps from, a security perspective a loss, harddrive isn't likely, not going to lead to anything catastrophic. Right your data is not all collected in one place it's broken up and distributed across the day Center and, our day Center has, many. Many many many many many servers right lots, and lots and so, that's what happens there now. When, you start talking about you know encryption, then, it's, not the actual processors, in encryption that's hard it's the key management right, everybody knows this I mean, protecting. Keys is a very very hard thing to do and because. No matter how good your encryption is if someone takes a key then, they actually access your data as, simple as that in, our case what we do is that when, you actually have that piece of data we, create, this new new. Key, that's associated with it now. That, key actually stays with the data itself and you obviously don't want to do that in plaintext because, Noah Bennet's even even. Stupider than are encrypting but, we, then wrap it we encrypted, using a, higher-level key that we call the key encryption key so, it. Makes sense right data encryption key for the data and then key encryption key for encrypting the data I mean the key I'm sorry and the. Way that this works is that the the key encryption key resides, in our own internal key. Management system and this, key management system was designed to be very highly scaleable available, everything else it's basically. What we use internally to run Google as well right. So it had to be something back and you know performing, farm well enough to support the entire Google domain. When. The key actually gets protected, in there then the, clock is on, and the internal kms also has properties by which to actually make sure that the the proper Apple is involved, you, know like the services, have the proper you, know access to actually access key for this particular data and I'll a little bit more about that as well. But. Let's. Kind of walk through what happens when a service, access to encrypt a piece of data so. First thing that happens is that you have three parties here right you have a service the storage system and they came and the actual key management system they all all have to work together to make things work the. Service comes on and says hey, I want this piece of data please give it to me and so, what the storage system does is that first of all it checks does the person actually have access to this data right, and if that if they pass this out I am check then it says okay let me go and figure out how to do this it, will go and figure out which chunks, or.
Collectively, Form that data and then. Each. Of those chunks will actually have its data encryption keys sent over to the kms, to, actually go and decrypt right, so that it can actually decrypt the data so. It does that for each of the different chunks and then, once, it gets back the unwrapped key data, encryption key it, can then actually accurately, put the data back together and, then send it back to the application, well. I shouldn't mention too if you guys have any questions please prefer, to interrupt I'd. Rather pass right now yes please. Yeah. So. The. Question is is that you, know I said that every all data is encrypted rest but there's, documentation, of some things our exceptions, so, I should clarify when I say data I mean customer, data we make a distinction, between customer. Data and metadata and things. Like logs and and you know information around the data is considered, metadata, which we don't necessarily ensure, they're encrypted. That. That's true but. We try to make sure that there's nothing in terms of cents of data that's actually placed into these logs right, now if you actually do something where you actually you, know name name. Certain objects with with, the sensor information we advise you not to do that but. Again, you know we make that distinction and so you're, right but we. Cannot. Always encrypt, the metadata for various reasons okay. So. Now. We get down to a little bit more in terms of key hierarchy and so, this diagram here actually gives you a fairly, good picture of you know how we do the protect. The keys within the within, the storage. System and so, once we actually get to the top we've already discussed, that where they have the keys encrypted, and the. Cloud then kernel KMS actually is protecting, the green keys there, it, goes through a whole lab resistant, of different keys that actually, protected, you know through different layers to the point where at the the, second, for the bottom right there, you. End up with a root kms, master, key and this is a key that runs on very very special machines very you know highly secured machines in each of the data centers there's, not very many of them okay, they're designed to be very very reliable and performant, and everything else and there, are also meant to not store the keys on any permanent media okay, so the only existing memory and there's, an internal protocol that actually shares the keys around so as long as you have one of these machines running globally, then. It'll be able to recover in case any of these machines died now. In the case where we have a catastrophic, failure, like everything, goes you, know goes. Down like. You know a global reset then. We. Do actually keep a hard copy of that key. Put into a physically. Secure media and lock them into a physical safe that's, distributed, in, global. Aid spirits of set. Of locations. Around the world and there. Are very very few people in Google that actually have access or knowledge of this I'm.
Definitely Not one of them I'm not considered trustworthy enough but. There's, probably. Less than 20 if I remember correctly. Okay. Now. This does a kind general statement, that I'll make around this is that, you. Know this what the way we can describe in Christian arrest by default is a Google and Crips customer content stored. Arrest without any action report from the customer using one or more unchristian mechanisms, okay. So, what I described right there is one of the mechanisms that we use to actually encrypt your or your data there's sometimes more at the physical layer and everything else but, you can rest assured that there's at least you, know your DEA's been encrypted least once. Yes. So the question is how, do we instantiate the key that's bootstrapping to memory right. So. Again. As long as one of these nodes are up and so you have these specialized nodes that only actually. Serve. To actually provide this this. Hostess. Root kms, master key so. There's. Basically a sharing, protocol that's you know that's, inherent. With the system itself and so. They, know how to actually contact, one another to actually make sure that the key gets shared and propagated, throughout the system and so, if there's a new new. Machine. That comes up then automatically, gets shared, within the, brand new key. It's. A, little. More elaborate than that I can't get into too much more details, but, yes. Oh I. See, so you know when you start from from, zero and you actually want to actually I'm. Not sure about that to, be quite honest, Majan. That there's some process by which the few people who knew how to do this would set up and get, get, started but I'm not exactly sure yes. Question. I'm. Sorry cuz you repeat that. Yes. Oh I, see so the, question is basically around traceability, of where. The data resided. Yes. There's, there's, both internal, logs, that, actually keep track of all the activity that happens in terms of key management key, access and everything else and then, at a higher level there's, also the, you, know the cloud auto logging that would, actually, actually, that's not for this case but, there is actually logging that actually keeps track of the different accesses, and the different key requests, and everything else so that is all.
That's. All actually, recorded in our internal logs, okay. I'm. Sorry. Will, it appear in the metadata, like, do you mean if someone, access to the metadata. Yeah, there. Would be logs in case that any key. Axis right. Well. It's not necessarily something that's expose externally. Going, for here so now we actually get to the point where we're starting to talk about things, that you can manage yourself, so, this is options, for encryption at rest and so when you actually bring up you know like your data to the cloud we, discussed the first column there which is a default encryption where. You can actually go and do nothing and we'll just make sure all your days encrypted, and then. The middle we have the. Customer management christian keys with cloud KMS right. And that's the case where cloud, KMS is the cloud service that's sort of the extension. External. Extension, of the key management system and one. Of the great great benefits, of the kms, is that, you, can actually have, this integrated, to protect, with different services so currently, I'll talk a little bit more about this but if your data resides in other services then. You can actually associate with a key that you control under cloud kms and then. Finally on the right side we have customer supplied encryption keys and so. This is a feature that we shipped a couple, years ago and. This allows you to actually it's, only built for GCSE and GCE. I should mention as well but, this allows you to actually you. Know keep the keys resident. So you don't store them in the cloud but. Every time you actually make a call that nice access data you actually provide, a secret, that helps unlock that data now, that secret, is something that we actually only keep in memory we don't actually store to disk ever and so, as soon as you finish a request we actually purge it right. So, there. It's, only for GC s and GC GC, as I mentioned before it. Does have some drawbacks such, as no you can't do anything that's that's, offline. Or you. Know like, for example we can't do any kind of backups, or or things. Like compaction, and things like that so it kind of limits what we can do with the in terms of the different services. Ok. Now. I'll talk really quickly about cloud KMS as i mentioned it earlier so. Cloud KMS is actually the external. You, know external. Key management system and this is all taken from the website so i won't spend. Too much time on this right, but, it basically gives, you a path, by which you can actually go and create aes-256, keys, and you can manage them yourselves, right, you can explicitly say that I want to create this you know destroy, rotate. Disable. Whatever, you like with this and it's. Because. It's a cloud service it's completely, integrated with cloud IM and cloud otter logging so, that means that you can actually use IM roles to actually know dictate, who can access a key and what operations, they can do and addition.
All The operations, will be captured by a cloud cloud, auto logging so, whenever someone goes and accesses, the keys for whatever operation, then, that would be something that's captured by the log. You. Know this is just basically describing, some of the things that if, you're familiar with cloud KMS you already know but, you know it's designed to be a global, scalable. Performance system it's, extremely, fast very very low overhead just, because, the way that it works is that you know there's many many KMS. Nodes that do a lot of work and so it it, means that you know when you actually do encryption it actually doesn't really mealy, impact, the. Performance of the system. And. Then, this is something that that's. Probably interesting to a lot of people what's new. Asymmetric. Keys we are finally introducing a symmetric keys for cloud KMS okay. So, the. Other slide a couple slides ago i said it does symmetric, key. That. Was a case until this morning we just announced that we're, providing a cloudy, HSM in along with cloudy HSM we're, also providing, the ability for you to actually go into asymmetric, key operations, on both hardware and saw, we're and we're. Allowing you to do several different types of types, of keys okay, so you can actually use RSA, 2 K 3 K 4 K you, can use that both for signing and you can use that for decryption and then, we'll also provide you with elliptic, curve keys, with. A couple than this curves P 2 5 6 and 3/4 so, you can use those for for, signing purposes, we've. Also expanded, since since, last year to multiple regions so, very, very, recently we expand it to Finland London Frankfurt Netherlands, and then, Tokyo Mumbai Sydney Montreal, LA. And San. Paulo ok. Another. Thing that's really cool is that we are now supporting, multi regions so, if you're familiar we had a multi region before Bo's one multi-region, it was global right. So either you chose a specific region or you chose the whole entire world and, for. Some reason some people didn't like that so we're providing you with the ability to actually choose individual, regions so, you can either choose the Europe, Asia or u.s. multi regions ok, and it's just basically a very very simple thing when you create the keyring.
And. Finally, I just mentioned this a little while ago but where we're providing HSM. Backing for cloud KMS, ok. So, this, is a this. Is a very very fantastic news I've been working very hard on this for the last couple years so it's been my life for a little while so I feel very very happy and sad, at the same time but. It. It's. Basically a managed HSM, service that, allows you to actually go and do crypt operations, create, protect prediction of your keys and the FIPS 140, - to a level 3 device and if. You think that's gonna be hard to manage well you don't have to do anything except, know how to use cloud kms and it's, just a simple flag when you created you say I want to create this an HSN and, we just take care of the rest for you essentially ok. It's. An HSM which means that when you create the keys in there we can't extract the key material ok, we actually, really don't have the capabilities. Of actually doing it and, you. Know the keys are actually bound to a region itself when. You create the keys and say US central one then. The HSM. Hardware and us such from one is the thing that binds and creates and binds our keys to that regions so even if the key backup gets moved around it can't be you anywhere else okay, I have, a whole session on this tomorrow at 10:20. And so, if you're interested about this please drop by I'll, talk. A lot more about the hsm stuff and do a lot more demos, and stuff like that where you can see how it works, okay. All. Right I'm gonna I see, people taking pictures, so three two. One. And finally customer, magic encryption keys if. You guys haven't used this yet you, know you should really consider it's it's great it, essentially, allows you to use the corruption. That we provide into the different services, protected. Using a key that you control in cloud kms right. And because. Cloudy, HSM is integrated. Cloud kms you can also use an HSM key as well if you disappear if you feel like having some tighter controls around the, availability. Of the keys and so. Currently, right now we have this available for bigquery that's, fully, GA, the. Compute engine cloud storage data proc they're all in beta right now and so you're free to try this out for with, both software and hardware keys, there's. A talk at least for the GCS happening. Tomorrow Thursday, at 10:20. A.m. the same time I hear, the HSN, talk is a little bit better but. But. If you're interested in GCS then please feel free to actually go and attend, this session learn, a little bit more I don't think they're going to talk to exclusively about this but they'll mention it and. With, that I think I'm going to turn it over to, my. Predecessor. Maya. So. Here you go my. Can't. Have nice things. Did. I turn it off we're good great. Thanks, Alison unfortunately, I'm not as funny as Elsa I'm sorry in, advanced and also I talk very fast so, we'll see how this goes, so, the, other thing if in case you missed something ounce one set else like mentioned go check out the blog we, post all the security announcement a couple hours ago including cloudy HSM if, you're not familiar with that so. I'll be talking about encryption and transit at Google and how that works so, if you're if you're not familiar. And, to understand. How encryption, in transit works at Google we first need to understand how traffic moves, to Google and then inside Google so. There are five kinds of different writing requests here they're numbered on the slide from, the end-user to the Google to a Google, service from the end-user to a customer application hosted on Google from. A virtual machine to. A Google, service from, a virtual machine to another virtual machine and from, a service to another service so, the distinction here our service is a hosted service like a like. A bigquery or cloud ml etc, versus a VM is a VM endpoint has an IP address like GCE gke or Google, managed VM like. COD, sequel is so. Number one here from the end-user to Google to a Google cloud service for example if your users, can I think a big query to run a query Google. Cloud services accept. Requests from around the world using a globally distributed system, called the Google front end or GFE, and. The. GFC will terminate incoming HTTP, TCP. And TLS proxy, traffic provide. DDoS attack countermeasures, and route and load balance traffic to the to the right Google cloud service there. Are GP points of presence around the globe so. They proxy that traffic internally. By writing the users, request over our network backbone to the right spot. -. From the end-user to a customer application host on Google Cloud this, is actually the most complicated, case, so hopefully.
We. Don't have to. Talk. Through some of the examples that you have so this depends on how your traffic is routed through the Internet to your custom application, if, you're using a Google cloud load balancer, you can use it to terminate HTTP, TLS and TCP traffic and. It's actually, implemented, by the Geo fees so that's why you'd have the same the same parallel. Set, of options there for HTTP. Load balancers connections, between end users or Crypton authenticated, with TLS or quick using. Certificates that you provide, some. Other options if you're connecting using. Cod. VPN you connect from your host on your VM on-premises, to the on-prem VPN to, the cloud VPN to the cloud VPN, and the, the connection. Between the 2 VPNs is protected, using IPSec. We'll talk a little bit more about that if. You're connecting, to a v8 from the - directly to an external, IP for a VM that connection. Does not go through the GFE and it, is not encrypted, and protected the same way that a connection to the GFE is so if you're serving something with directly from an IP endpoint that's your responsibility, to protect and encrypt that traffic, similarly. If you're using cloud dedicated, interconnect, for, example to peer between your on-premises, and Google cloud that. Also does not go through the GFE and so it's also your responsibility to protect that for example by implementing. Some application, layer encryption. From. A virtual machine so, that those 2 for 3 from a virtual machine to Google Cloud Service it's. Actually just reduces to a to another case which is it. Will go it will connect to gf8 will route that request for, example from compute engine VM to Google Cloud Storage as if. It were an external. Request and gets into the GFE then GFE will then do their load balancing and routing internally, for, that from. A virtual machine to a virtual machine that connects over a network backbone uses, using private RFC 1918 IP. Addresses, and from, a Google cloud service to another Google cloud service also goes over our private network backbone we'll talk a little about what we do for, both of those in a second, so. -. Here. We go to. Get us started here. You. Know our, networking. Team is amazing and all the stuff that you saw there was kind of crazy, but I'm a security person so I care about how that traffic is protected, how does it all those five different things are protected so. First. From the user to the front end it travels over the open Internet and then, I'll talk more about how we protect that on the site in a second, then. Once the chat your traffic is inside Google's infrastructure, your, data travels, over our private, network backbone and might, go to multiple physical locations, in order to fulfill that request so. How is our network backbone protected, it's. Really. Important here to understand that Google applies, different, protections, to data in transit when it's transmitted, outside of a physical boundary controlled. By on behalf of Google compared to when and stays inside Google's physical boundaries so. What do I mean by this a physical. Boundary is the barrier to a physical space that is controlled by on behalf of Google where, we can ensure that there are rigorous security measures in place physical. Boundaries physical, access these locations is restricted, and have, we monitored only. A small percentage of Google employees can can have access to that hardware and because. We tightly control that space data. In transit within these physical boundaries is generally authenticated, but is not necessarily encrypted, now. Compare, that to the scale of the global Internet are everything, in, our wide area network we, just can't put the same physical security controls in place right we can't put like a Google, employee standing, every 10 feet of some fiber optic cable under the sea making sure that that's all it's all secured so. Anywhere. Outside our physical boundaries that we aware we can't control that that link we, assume that any network crossing a physical boundary can. Be compromised, by. An active adversary who, could snoop injector, ultra traffic on that wire in, order, to ensure data integrity and privacy we use encryption when data moves outside physical, boundaries, so.
Those Under C network cables encrypted. I want. To repeat this because it's really the key takeaway here before, I get into details based. On our threat model data Google. And Crips and authenticates, data in transit when that data moves outside physical, boundaries, but. Whereas data within a physical boundary is generally authenticated, but not always encrypted all. Right so now that we have the high-level picture let's talk through some of the different scenarios both. To the Google front end and then within Google's infrastructure add multiple, Network layers, so. As I, mentioned we flee earlier your data can travel from the user to the front end in a few different ways let's, take the most simple case where it talks to. Your, user and you connect to the to a Google cloud service so, in this case the Google front end like I mentioned will terminate your your connection and provide encryption using HTTP, protocol with a public certificate, the. GFE will negotiate a particular encryption protocol, with, the client depending on what the clients able to support the, GFE will negotiate a more modern. Infection protocol where possible. TLS. And the GFE is implemented using boring SSL which is a Google maintained open source implementation. Of the TLS protocol forked. From open SSL, and is mostly interface compatible, with OpenSSL, Google's, an industry leader in both the adoption, of TLS and the, strengthening of its illumination we've, enabled many, of the security features of TLS for example, since 2011, we have been using forward secrecy in our TLS implementation, forward. Secrecy makes sure that the key that. Protects a particular connection is not persisted, so that if that connection is compromised. If an, attacker can intercept, a particular message they can't read previous messages that you've sent over the same connection. As. Part of TLS a server must prove its identity identity to the user when, it receives a connection request by. Having the server present a certificate containing. Its claimed identity this, certificate is signed by an issuing certificate, authority, or CA, that's. Trusted, by the user requesting, the encryption, historically. Google operated, its own issuing, CA which, is what gives you the certificates, and we, use these two signed certificates for Google domains but, recently Google's also started operating our own route CA so the route CAS sign the other smaller CAS that operate, across the Internet today. Are CA server certificates, that are cross signed by multiple, routes which. Arabic, ously distributed, so. To summarize when you connect to Google the. Google front-end terminates your traffic encryption. Is implemented using boring SSL and certificates. Or cross signed including by Google owned route, CAS. Now. Let's get into our network now that your your request is inside Google's infrastructure, I might. Have to travel between Google locations there. We have protections in place place, both at the network layer and at the application, layer let's. Start the network layer this. Layer Google clouds virtual, network authenticates, all traffic between virtual, machines, this. Authentication, is a moment in using, a system that we call security, tokens which, protect a compromised host from spoofing packets on the network. Security. Tokens are each max negotiated. For a given sender and receiver pair so a sender VM and a receiver VM will each have their own set. Of tokens. During. Authentication, security tokens, are encapsulated in a tunnel header which contains authentication, information about, the sender and the receiver the. Control plan on the serving side sets the token and the receiving host validates, the token. Furthermore. Google, clouds virtual, network infrastructure enables encryption, when traffic goes outside physical boundary like I was saying before encryption. Applies to private IP traffic within the same virtual private cloud or between peered EPC networks. We. Used the advanced encryption standard in Galois counter mode a Galois counter mode with 128-bit. Key to, implement encryption of the network layer each, pair of communicating, hosts establishes. A session K via a control, channel protected by alt s which I'll talk about in a second and, for authenticated, encrypted communications, the session key is used to encrypt all, VM, to VM communication, between these hosts.
Going. Up to the application layer the, protection story is very, similar although the implementation is different at. The application, layer within Google's infrastructure we use applications, layer transport, security or alt, s for. The authentication integrity and, encryption of Google RPC calls this. Includes RPC calls from the GFE to a service and from, a service to another service. Alt. S uses service accounts for authentication, each. Service, that, runs in Google's, infrastructure has a service account identity, with, associated cryptographic credentials, which. It can use for authenticating, itself to other services when. Making or receiving our, pcs from other services it uses that service account to authenticate, itself to provide its its credentials, alts, will verify these credentials using an internal certificate, authority. Within. A physical boundary controlled, by Google, LT, s provides both authentication. And integrity, for. Our pcs for, traffic over the when outside, of physical boundaries LTS furthermore enforces, encryption for. Infrastructure RPC traffic automatically. Alt. S is also used to encapsulate other layer 7 protocols such as HTTP, this, protection ensures that our applicate this isolates. The application, layer removes any dependency, on the network path. Services. Can also be configured to only accept, and send, a eltis communication. When, encrypted, even within physical, boundaries notable. Examples within Google are, our internal team management system that Ellison was describing earlier in cloud kms both, of which only accept encrypted communications. Let's. Dig a little bit deeper into how a LTS works. Google's, application, layer transport security or alts is a, mutual, authentication and. And transport, encryption. System, developed by Google and, typically used for securing remote procedure communications. Our pcs within, our infrastructure. LTS, a similar in concept to mutual TLS if you're familiar with how that works or any handshake, protocol really but. Has been designed and optimized to meet the needs of Google's data. Center environments. The. LTS, trust model was purpose-built for cloud like containerized, opera applications, this is a key point identities. Are bound to entities, like a service account not, bound to a specific server name or host like an IP address this. Trust model makes it really easy for us to, replicate load, balance and reschedule, micro services across hosts. Sounds. A lot like it's 2u. Alts. Relies on two protocols the, handshake protocol to establish a session key which you see at the top there and a. Second protocol the record protocol to send their protected RPC these. Protocols govern, how sessions are established, authenticated. Encrypted, and resumed so. First the handshake protocol it's a defeat all men based authentication key, exchange that. Supports both perfect, chord secrecy and session resumption during. A handshake the client and the server will. Negotiate a shared transit encryption key and the specific protocol that they're going to use for encryption and then. The record protocol sends the data often. Encrypts enough indicates network traffic using the protocol secret that was established in the handshake we. Published a white paper explaining, exactly how a LTS works on our website so please do check that out if you're interested. So. Let's summarize, what we've seen so far and apologies. For these being on two different slides so. First what happens at layer 3 and the network layer we've covered what protections we have in place by default. You, know we mentioned that, we. Have a virtual. Network authentication. Between the GFE to the VM and between VMs and we, have encryption, when that data crosses physical boundaries um, I also want to point out it's not that we don't have any protection from the user to a front-end or from the user to VM but that's not at layer 3 that's a layer 7. So. I get asked often is there any point where my data isn't encrypted, in transit, what, are my options you know what can I do at.
This Network layer you, know in addition to this production that we already have if you need additional protection from, the user to, the VM or between the VMS you can use an IPSec tunnel. How. Do you set that up you. Can use cloud VPN to set up an IPSec tunnel to, securely connect your on-premises, network to your who cloud VPC you, have the option of setting up the you also quit you can also set up a VPN between two V pcs this. Means that your traffic would go from your on from host to your on from VM to. The cloud VPN sorry from your on from host to your on-prem VPN, to. Your cloud VPN. To, your cloud vm so there's three, hops there that it's making right from. Your on-prem host to, your on-prem VPN that's, on your network it's protected like you infect any other traffic in your environment from. The on-premises, VPN to the cloud VPN, that's protected using an IPSec tunnel and from. The cloud VPN, to the cloud VM that's, protected by our virtual, network as we, previously explained. So. To set up a VPN you first have to set up a VPN on-premises then. You can create a cloud VPN, gateway and tunnel on the hosted services VPC network and permit, traffic between the networks you. Can further customize your network by specifying, the internet key exchange version. For your VPN tunnel ika, v1 and ikev2 each. Of which supports different ciphers, if you specify ikv one google with the packets using AES. Advanced, encryption standard in cipher block, in. Cipher block chaining mode with 128-bit. Key and, provides. Integrity using a sha-1 h Mac if, you're using ikev2 you have a variety of ciphers that are available to you and supported and in all cases Google Cloud. VP animals negotiate the most secure option available between. The peer devices. An. Alternative, to an IPSec tunnel I mentioned briefly earlier would, be to use something like Google Cloud dedicated, in to interconnect to connect from your on-premises, to, Google Cloud in. That case it provides direct physical connections using RFC. 1918, addresses, between, your network and Google's network the. Data traveling over this connection is not encrypted, by default and it's your protection to secure this it's. Your it's your. Responsibility. To secure this and we'd recommend for example application layer encryption for. Example using TLS. So. That was at the network level let's look up at the at, the. Application, layer again as you. Recall we use TLS to. Encrypt data from the user to the Google front end and, also from a VM to the Google front end because that's how we write travel I wrote traffic back through the GFC and then. We use alt s within, infrastructure, between services, for authentication integrity. And, furthermore encryption, between physical locations, to. Avoid confusion I also want to point out here that VM to VM traffic, it's not that it's not protected again it's protected to layer a layer 3. If. You need additional network, layer protections, from the user to the GFE, we. Have a couple of AA different options including managed SSL Certificates for your user applications, and in, Gmail you can use s mime and within. Google's infrastructure if you need additional services service protections you can use Sto so let's quickly to dive into what these these provide. When. Building an application on Google cloud you can leverage the gfu support of TLS by configuring the SSL certificate that you want to use for. Example you could have the TLS session terminate, in your application. As. Well google provides free, and automated, ssl certificates, in both firebase hosting and Google, App Engine custom domains these, certificates are only available for Google hosted properties once. Your domain is pointed at Google's infrastructure, we request one and obtain. A certificate for that domain to assure to ensure -, sorry - allow secure communications, we, manage this TLS server private keys on your behalf which are either, 2048. Bit RSA or, SEC P 256. R1. ECC and we're. New certificates on your behalf as well. For. Gmail specifically. Gmail. Already uses TLS by default so. In fact Gmail actually records, and displays whether the last hop that an email made was over a TLS session when. A gmail user exchanges, an email with another gmail user the, emails are protected by TLS with. The exception of if they're sent directly within the application, they're protected with alt s as we described earlier for. Incoming messages from other email providers Gmail doesn't enforce the use of TLS if, this is a requirement for you as a, gmail, admin you can go configure Gmail to require secure, TLS connection for.
All Incoming and outgoing emails, if. You have stronger Enterprise requirements, for, secure multi-purpose, internet mail extensions, or s/mime which. Is an email security standard that provides authentication integrity, and, encryption for your emails then, you can implement. That in Gmail as well the. Implementation of s/mime standard mandates, that certificates, associated, with users sending, emails are hosted in a public CA, if. This if you have this requirement as a gmail admin you, can configure Gmail to enable, mine for outgoing emails setup policies for content and attachment compliance and create. Routing rules for incoming and outgoing emails. The. Last additional production will quickly cover is Sto. SCO. Is an open source service mesh that provides a uniform way to connect monitor. And secure services the. Trend towards micro services and containerization, in general is leading to more complicated applications. That are more difficult to monitor and. Why I'm excited about continuous security these days sorry ill son, sto. Supports managing traffic flows between micro services enforcing. Access policies, and IRA gating telemetry data and all of that without having to change our application so it's a complete godsend in that regard, given. Google's experience, with alts, sto, it's a logical extension of what we've already built and what we've done in developing, micro services for over 15 years, like, alts, sto, issues and identity which is a certificate for, every service running in the mesh is. To then transparently, adds mutual, TLS, to all service calls based. On these identities, providing, authentication, and integrand, encryption. Across your services there. Are lots of talks on this conference at this confrontation, so I won't dig into it there was one yesterday honesty of security so check out that recording online. So. To sum it all up for data encryption in transit Google. Encryption authenticates, data in transit at one or more network layers the, network layer and the application layer when, data moves outside physical, boundaries not controlled, by on behalf of Google. And. If you want to learn more I've, spent some, large amount, of my career writing niche-y papers, you. Can go check them out learn, more about encryption in transit encryption at rest what I'll sing and I talked about today. Thank. You so much for your time.
2018-08-24 11:10
