Sensitive data in the cloud? You can’t do that!
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Grimstad, Rune Andreas
In my job I work with very sensitive medical information. The traditional view here is that this sensitivity excludes the cloud as a possible platform. I believe that this is not only wrong but also a very unfortunate limitation. In this talk I want to look at this situation to discuss the background and then to look at what you can do to fix it. In my opinion there is nothing stopping you from handling sensitive data in the cloud, but you have to know what you are doing. The same requirements for data security applies for the cloud as for on premise systems, the main difference is how we perceive the cloud. The focus of my talk will be on Microsoft Azure, but the principles are reusable across all platforms.
 Okay, hi everybody. My name is Runegrin Sir. I'm here today to talk about sensitive data in the cloud and the fact that you can't do that. Or at least that, the general opinion. I'll be talking today about writing custom software, not software as a service, Google Docs, Office 365, because that's boring. I'm a developer and writing code. That's what I like to do and that's what I like to talk about. So, much of what I'm going to say today applies to software as a service as well. That's not going to be my focus. But before I start, I want to say this is my opinion, not my employers. I've got some colleagues here. Because this is a kind of controversial topic actually. So, this is based on my experience, my opinions. And actually, the idea for my talk came around when I started working with sensitive data in our organization. We write software for the Norwegian hospitals. We're focused in the middle region of Norway, but we support all hospitals in Norway, even some foreign ones. And the software we write, it handles your medical information. So, it needs to be secure. At the same time, we see that the cloud offers a really nice feature. It's scalability, economy, availability. There's lots of good stuff here. So, while we really want to go there, the general opinion has been, you can't do that. So, that's what I'm going to talk about today. But before I start, I want to know who's here. How many of you are software developers? Write code? Yeah, almost all of you. Cool. Are many of you Norwegians? Yeah. Because at least one of the things, I'm more or less trying to skip it, the boring stuff, the law. But I only know Norwegian law after all. So, I won't spend too much time on it. How many of you handle sensitive data? Yeah. Anyone doing it in the cloud already? Almost nobody, exactly. Yeah, that's how it used to be. So, my topic today, sensitive data in the cloud. Can you do it? From the discussion we had at work, what I see on the internet, this is a really hot topic. I see lots of you here today. So, I suppose you agree. And at least, from what I'm in my organization, the consensus is, you can't do that. The cloud, it's not safe. But what I'm going to say today is that you can. So, for those of you who want to go into one of our other talks, that's a short version. You can do this. So, hurry up. There's lots of interesting stuff going on. So, that's my opinion. And I try to argue for that. But you have to know what you're doing. And this is my opinion. It's also, it's not just me. For instance, the Norwegian data protection authority, they're called data to see in Norway. They actually say that the cloud, it's not only safe, but it's probably safer than running on premises. And the Norwegian government, they're working on changing the law now because they want us to use the cloud. They see the benefits of cost flexibility and safety. So, this should be quite easy. But it's not that easy after all. So, if the authorities say you can do that, what is the problem? I think you all have an opinion on that. In essence, hosting an application in the cloud or on premises, you need to do the same thing. You need to secure it. And you have the same problem. There is a risk that somebody can access your data that you don't want them to do. They shouldn't be able to access your data because it's secret, it's private. And what's the problem with the cloud? It's got the same problem at home in your local data center. But the cloud, it's a shared platform. You're not hosting your data locally. And you don't control the environment. And it's very hard to have full control of what's going on. So, you have to trust somebody, an external part, your cloud provider. And also, data from the cloud is transferred over the internet. That may or may not be what you do today. But at least for my applications, handling medical data, we're running a more or less secure network, a closed network. So, if I want to move my application to the cloud, then I have to transfer it over the internet. And that's scary, very dangerous. Also, in the cloud, you don't know exactly where data is stored. Absolutely do not know which hard drive is stored on. You don't know which server, not which server room, maybe not even which country it's in. Most providers let you select the data center. But where is that data center? You've never been there. So, at least there is a perceived loss of control here. I'm not saying that you lose it, but the perception is that you don't control the world the same way as you do when you run locally. But the greatest problem, at least the way I say it, is that the cloud is new. It's been there for years, but this is new stuff. We're not comfortable with it yet. And that's what I see as a main problem, because there is a myth that the cloud isn't secure. I call it a myth because it's not true. But we all believe it. At least many do. So, when I say it's a myth, that's when I focus on the big cloud providers. I talk about Amazon, Google, Microsoft. So, the big ones. If you're looking at the hordes of small providers, calling them some cloud providers, honestly, I don't have any experience with them. If you're handling sensitivities, you should be careful. Go for the big ones. And from what I've seen, the security is really nice. So, I'm going to go back to that. But first, let's talk about what sensitive data is. I just need a drink. Did I know you go to the shrimp cruise last night, by the way? Yeah, it was a bit too much fun. My voice isn't exactly where it should be today. I hope you forget that. So, sensitive data. It's information you don't want to share. It's whatever you... It's your secrets. It's private. It could be economic information, health, of course. It can be a private discussion in your position, your company's economy. Anything that you don't want others to see. And it doesn't mean that we have something to hide. It's not that. But it's private. As long as it's private, then it's sensitive. But there are various levels of sensitivity. Not all sensitive data are equal. So, we need a background here. There are several levels of sensitivity. Usually, we talk about three or four. First, you have the directly identifiable data. This is the most sensitive data, the way I see it. It's when, for instance, in your database, you store up a personal ID, say, a social security number, to get away with it, a diagnosis. So, you say, this person has this medical condition. Combine them to not necessarily the same database, but if the data are available and easy to combine, then it's directly identifiable. You know who the person is. You know who the company is. You can point to someone directly. Then you have what is called, I call, indirectly identifiable data. This is information that it can look anonymous. But as soon as you start to combine it with other data sources, then you can get more information out of it than you intend to. For instance, if you have a diagnosis, and you don't store a social security number, you don't store a phone number, you don't store a name with that data. But maybe you have a person's age, a weight, gender, maybe even which part of the country that person lives. Without that information, and if it's, say, for medical, it's a rare diagnosis, then you may start to find out who that person is. And then you're exposing sensitive information without meaning to. There are several examples of people doing this. But you have anonymous data. That can be the same data source, but it's aggregated over a group of people. Usually you have a rule of thumb. If you have more than five people in an aggregated, then it's anonymous. You can't find out who the person is. It depends on what you're doing, depends on your data. But that's a simple rule that you can use. So even aggregated data can be sensitive if you have a small enough group. Finally, you've got information that isn't sensitive. Say, for instance, public information. Your name, your phone number, where you live, that's not sensitive information because it's probably in the public data sources. It's easy to find on the Internet. Also, test data and all kinds of that kind of stuff. It's not sensitive. So the more sensitive your data is, the more important it is to protect it properly. And you need to think of that. I'll give you an example. It's a fun story. In 2013, there was a released data source that contained all taxi rides in New York for a whole year. And it contained no personal information, they thought. So they had the taxi cab's ID. There was a date and time when the ride was done. It was where the ride was from, where it was to, how much was paid, did a passenger tip. But there was no information, there was no name, no number. It didn't say who the person was. So the smart people on the Internet, they took this data and started Googling pictures of celebrities on taxi drives in New York. And they found pictures. And they could see, they found pictures of celebrities working a ride at a certain moment. And they were able to find the data in the data source. The same place, same time. Then they knew who it was. So you can see that this celebrity went from there to that and didn't tip. But they could do more with that data. They started aggregating it. And so they found frequent trips between addresses. For instance, trip bars. To private addresses. And when they looked at those private addresses, some of them, there weren't that many people living there. And your address is public information. So they were able to find out who that person was. Several of them. And they were on Facebook. Only this anonymous data source identified very private information about people. So while your data may not look sensitive, it may well be, after all. So you have to think. Now how do we secure our data center? I love this picture. That's how it looks at home. We have this myth about insecure cloud. So how do we secure? First locally, how do we secure our local data center? There are many people talking about this. I won't get into the details. But normally you will build a secure data center. Probably underground, in a secure bunker. It's got limited access. Only this and that. You too have access. The rest of you can't even access the room. So it's physically protected. All of your servers are redundant. You probably have two data centers. So even if this data center stops, this one is still working. So you've got to redundant security. Then you set up your network. You use reverse proxies. You use heavy duty firewalls. So you make sure that only there is no inbound traffic. Everything goes out. You make sure that you have full control of what's going on. And then you set up your application. You follow all the best practices and guidelines doing proper authentication. Probably two-factor. It may be even better. You have full control of authorization. And you secure your data. You encrypt your storage. You use HTTPS, TLS, all the good stuff. You follow all the over spread commendations. So you secure your application. And you're happy. You're secure. How is the cloud different? Can't you do that in cloud as well? And you can. But there are some differences. So let's talk about the bad stuff first. The cloud, it's a shared environment. You don't own the servers. You don't own the environment. You share it with other tenants. So you don't control the data center. You don't control who can access your data center. You actually don't know who can go look at your servers. So you have to trust. And you don't control where your data is stored. As I said, you don't control the machine. You don't control the hard drives. You don't control anything. And your application, it is not running locally. And if you're offering a service on internet, that's business as usual. But if you're running in a closed network or a limited network, this can be a challenge. And you must, I can't repeat this enough, you must trust your cloud provider. You need to trust them. You need to be sure that they won't do anything wrong. You need to trust that they are good. You need to trust the certifications. You need to be sure that they know what they're doing. And on top of that, at least if you have an existing application, it probably doesn't fit in the cloud. That's a different talk. I won't get into it. But in some cases, it can be terribly expensive, actually writing your application to work well in the cloud. But there are lots of good stuff in the cloud. First of all, it's a shared environment. It's not just bad. It's great. Because you have proper separation between tenants. It's built so you can't access your neighbor's data. It's impossible. But this shared environment gives you flexibility. So it can be a problem, but it's also great. And this data center is run by huge corporations. Instead of your local data center, you're running 10, 100, maybe 1,000 servers. You're big. These guys, there are millions. I heard that in Azure, Microsoft, I believe there's one administrator per 15,000 servers. And they're running millions of servers. But they don't really spend too much money administrating it. But they spend lots of money, lots of resources on securing this. That's what I live from. In the cloud, you can usually control which region your data is stored. Like Azure, they have the data center in West Europe, Northern Europe, several places in the U.S., Asia, all around the world. And you can say, I want my data to be stored there and only there if that's what you need. Also, the challenge with network traffic, your data being on the Internet, there are ways to secure network traffic now, actually. Now, there have been lots of problems with traffic on the Internet, encrypted traffic being hacked. But as long as you're up to date on the latest standards, then you're good. And also, the cloud, it's a rapidly moving target. You get the new security features all the time. For instance, again, Microsoft, they just launched SQL Server 2016. It's been running in Azure for a long time. And the new features there, in Azure, you've had them. But you just got them locally. So they're updating the cloud much more often. So you get the new features much earlier. So there are lots of good stuff. And all the flexibility, it's really useful as well. There was another example. In 2010, Stone Ages, there was in Denmark, a company called Barnard-Donmark. You probably haven't heard of them unless you're Danish. They moved all the services from a local data center into the cloud. I've still read some articles about that. There was lots of discussion, is that smart? Is that the risk? They moved to the cloud. Then that winter, the day before Christmas, there was a huge snowfall. All the trains stopped. And people wanted to know what's going on. So they started hammering the websites of the train companies. It's really a DDoS attack. And all the websites went down. And that's this one. They were running in Azure. So when the traffic went from 50,000 visitors per day to 5 million, they pushed the button. They got enough capacity to keep it on. So all the services kept running. The customers were, I won't say happy. Nothing worked. But at least they got their information. And then after a few days, they could scale down again. And serving those 5 million visitors a day cost them, I think there was a 180 Danish Kroner. That's like $30. It's nothing. So they could scale up, have the capacity when they needed it, and then scale down again. So the flexibility here is incredible. So in most cases, I believe, actually, the cloud is most secure. The Norwegian government has written a strategy on cloud services. And they actually conclude that they want people to use the cloud because of security. That's interesting. That's new. So how do we protect our data in the cloud? In general, you follow the same rules. Exactly as you were locally. It sounds really easy, and it really is. But we need to consider our data and how to secure it. We have your data, it's a living thing. It's several places. We talk about data at rest. So when it's stored in your database. Then we talk about data in transit. That's when it's moving across the network, either between your servers or on the way to the user. And finally, we talk about data and use. That's when your user is actually viewing your data and using it. All those three places post risks. You need to think of security of all of them. Then we talk about confidentiality. That's how secure are we? What's the risk of someone who shouldn't be able to look at our data? Actually, I'm able to get access to it. And finally, we have data integrity. We're talking about what's the risk of your data not being complete? Have it been changed by someone in transit? So those are the factors we have to look at. Data at use. That's a cute cat, huh? Well, your data is at use. Your user is looking at it. So we're talking about the user interface. It's often the first thing we think of. We need to set up proper access control. You probably want sensitive data, at least two-factor authentication. Ideally, you don't want to do authentication yourself at all. You want to rely on a third party that has proper infrastructure. Here in Norway, we do what is called IDA-Porten. They are a national service that handles personal identities in a secure way. So not only can they give you an identity, they can tell you how sure they are about that identity. And we can trust them to have the proper infrastructure. And then we don't have to handle that complexity. Unless we have to do it better. So proper access control, that's important. You will, of course, set up your firewalls. If you need your application only to be available in a limited network, in the cloud, you can use firewall rules limited to a certain IP range. If that isn't enough, you can set up a virtual private network or even a dedicated line between the cloud and your local network. So there are ways to limit access to your cloud services, even though they are running in a shared environment. Of course, if you want to limit your limited access, then it means that you trust your home network. And here in Norway, all the hospitals, they are running in what is called the health network. It's a network combining all the hospitals and other companies handling medical data. It's actually quite large, a large mean of internet between the hospitals. But the challenge there is that the data is not, or the network, the computers that can access that network also can access the internet. And there is no real governance, who can access the health network? It depends on the various organizations. So is that really a secure network? So why do we trust so much this network and not the one run by professionals? I'm not saying that. Sorry, I'm sorry. I'm not saying that we're not professionals at home. We have best people available. But it's a big network. You can't really control it unless you have proper governance and you know exactly who has access to it. As long as the computers accessing your safe network also access to the internet, you have an open gateway. So what's the difference? So secure applications, set of firewalls, access rules, all that stuff, and follow all the best practices. OVOSP, you know them? They're an organization. The focus is security for applications on the internet, really. They have some really nice sheets, for example, on authentication and access control. I'll post links to them later. If you follow those guidelines, I'm not saying they're easy, but they're easy to read. So they're clear. They're quite good. And here, if you're running on premises or you're running in the cloud, it doesn't really matter too much. You need to secure application after all. In the cloud, you get some security feature that can be nice. In Azure, you have Azure AD. And it makes these things quite simple. But the biggest risk is the user. We are the risk, not the network, not the authentication mechanisms. All research shows that the easiest way to hack a system is to fool the users. If someone calls to a user of your system and says, hi, I'm from the IT department, what's your password? There is a real chance that they will say, oh, it's ABC123. Thanks. And you have access. It's much easier, much quicker than hacking into a system, brute-forcing password protection or whatever. So the challenge usually is the user, not the platform you're running on. So, data in transit. Here we have the fared man in the middle. It's scary. Potentially, someone can look at your data while in transit. So while your data is on the way from your local data center to your user, they can pick it up, maybe even modify it, read it, and post it on. In theory. And there have been some, actually, several attacks on the SSL and the TLS protocols, the encryption that we do over the network. So you need to stay up to date on the latest versions on the protocols and the software you're running. But as long as you encrypt your traffic, use the latest version, use HTTP strict transport. So you're always encrypting your traffic. Then in reality, it's very hard for someone to break into that traffic. Of course, if your user has a computer with a bad root certificate, then you have a problem. I got a Dell. And these computers, they were sold with a root certificate that the password was easily hacked. So it was quite easy to fake the traffic. So, again, the user can be a challenge. But you need to set up your network properly. And then you're quite secure, actually. So, man in the middle attacks, that can affect both confidentiality and integrity. Since not only can they look at the information being transmitted, but they can also change it. The difference here between running locally and in the cloud is that a cloud provider, they have lots and lots and lots of resources on securing the platform. Usually, at least where I work, the guys running a network, they're overloaded with work. They have way too much to do. They're brilliant people, really good. But they don't have enough time. So, securing our network, keeping everything up to date, that's going to be a challenge. Unless the network grows, the challenge is going to grow. In the cloud, when you have one administrator per 15,000 service, whatever, you can spend more money on securing the network. They do penetration testing. They look for problems all the time. And they have large teams doing that. So, again, most probably, the cloud is a more secure platform than your home network. Finally, data at rest. This is when your data is stored at your server. It can be in a database, it can be in a file, whatever. And this, I believe, this is the main challenge when running in the cloud. So, we need to ensure that whoever runs our servers can look at our data. Encryption is a friend here as well. You probably want to encrypt your storage, whatever you do. So in SQL server, you can encrypt the entire database, for instance. In Azure, the blob storage now supports encryption in preview. So, you want to encrypt it. Then you want to make sure that your sensitive data, they encrypt it again. So, not only do you encrypt your database, but you encrypt the data as well. So, layers of security. And, of course, you don't use the same encryption keys. Ideally, you don't even have access to those keys. Keep them away from your data. Further, you probably don't want to mix your sensitive data with your other data. Usually, a part of your data is more sensitive than the rest of it. For instance, in the systems I work on, we usually keep the personal ID, the social security number, in a separate database with separate encryption keys. And we keep it encrypted. But it's physically separated from the other data. So, even if someone gets access to my database, my data, it's in worst case. It's not directly identifiable. So, it's still sensitive data, but it's much less sensitive than if we throw it all in one big pile. So, you can get your data. You got in the cloud, you often get hardware encryption. So, you can get another layer of security. It costs money in Azure, for instance, but well worth it. And finally, you need to control who can access your environment. In the cloud, it's very easy to say, hey, you need to set up a server. I'll give you the pass, give your account access, and you can access everything. It's terribly easy. And you need to limit the access. So, keep a few persons that can administer your data. Because this is your server room in the traditional sense. So, lock it down and encrypt it. Keep your keys safe. There is one problem that I haven't discussed yet. And that's the government. Big brother. And especially the US government. There are cases that the US government, they want insight into data storage in the cloud. And this is a potential huge problem. All the big cloud providers, the American companies, they have to follow American law. And even though the data is, for instance, stored here in Europe, it's still an American company handling it. And this can be a huge problem. Of course, encryption, keep your keys safe somewhere else. And it's just garbage if they should access it. But it depends. Software as a service is a bigger problem here, I think. Also, Microsoft, they have a nice solution to this problem. They're setting up a new data center in Germany. It's Azure. It's got all the features, all that. But they don't own it. I believe it's Deutsche Telecom who owns the data center. So that means that even though it's Azure, Microsoft don't have access to your data. And so it's not following American law anymore. It's following European law. And this is a topic for discussion. But I believe European privacy laws are better, at least easier to have control of than American laws. We can discuss this for days. But let's just say that for now. European law, it's easier to follow. And it's better. So you're laughing. It's a big topic, so it's way outside the scope for today. So the cloud is safe for them running locally. You're almost guaranteed, say, for environment. You're almost guaranteed that the organization running the data center in the cloud has much more resources than your local company. And they probably spend much more resources on securing both the data center, the network, the servers, everything. And what you can do in your local data center. You got more security features, faster updates. And really anything you can do locally, you probably can do in the cloud. So it's the same bit more. Also you get better physical protection. Like my company, we have two data centers. They're physically separated. We've got several networks connecting to that. So it's not that it's going to stop. But should my hometown try to disaster happen there, then we have a problem. In the cloud, the data center is separated. So you can set up, for instance, services to be replicated between Western and Northern Europe. So even if something bad should happen in Ireland, it's still up and running. So the physical security is better. Also the protection of the data center themselves. That's insane. I recommend you look it up. Crazy guys. So, but still, there are reasons not to use the cloud. If you, for instance, have your existing infrastructure, moving to the cloud can be expensive. There are hybrid solutions. I'll get back to them. But also you have the problem that once you move to the cloud, going back, it's not easy. Azure isn't compatible with Amazon in any way other than the most superficial. They offer virtual machines. They offer storage, they offer databases. They're not the same. So it's not easy to move between the environments. So once you've chosen a provider, you're stuck. And this is a real concern. They're afraid of lock-in. And also the cloud is new. It's a new model. It's a new way of hosting your applications. And as I said, you need to trust your provider. And I see it as a natural next step. We started typically with a local data center where your local people were running your servers. Then you found that it's terribly expensive. You started hiring people to run it instead. Pay for what they do. So then you didn't control the people anymore. Then you probably saw that why should I be running these servers? Then you move your servers to a hosting provider. So then you don't control the environment. You have to trust your provider. But you still can probably know who they are. You still know where the data center is. And the cloud is the next step after that. You still have to have a provider that you must trust. But now you don't know where it is. You don't know where the servers are or anything. So what does the law say? This is probably only interesting for the Norwegians here. Because I didn't have time to look up the laws in all the countries in the world. But Norwegian law is quite strict. So I believe as long as the stuff is legal here, it's probably legal in your country as well. And I'm not a lawyer. I'm a programmer. So I'm no expert. But I've been reading and checking out. And you can't store classified military information in the cloud or outside Norway. But apart from that, there really aren't any... The law doesn't stop you. There are some old laws that say, for instance, that an archive can't be moved out of Norway. But as long as you keep a backup in Norway, you're probably good. And you can ask for dispensation for that law. The government, they're actively working on modernizing the law. Because they want us to use this. And for those of you who are interested in this, I got some resources on it. So I can help you to look it up. But we won't dig into it now. So the short summary here is that the law doesn't stop you. You can use the cloud for sensitive data. Really? Yeah, it's true. You can do it. But the same requirements apply as if you're hosting them in Norway or locally. Of course, in your country, there may be restrictions. There may be other laws. So make sure to look up this. Because if you don't check it out, then there's no guarantee. So talk to a lawyer before you move your data into the cloud. So if you're still uncertain, you can use hybrid solutions. And this is good... This is quite nice, actually. You don't have to move everything into the cloud at once. There are several ways to take one step at a time, move gradually. For instance, you can store your data in your local data center while you're running your servers in the cloud. You can set up a VPN so you can access your servers. And there are other technologies. So you can run your servers in the cloud and keep your sensitive data at home. Then you've got partially a cloud solution, partially the old way. And it can be a nice way to start your transition. Also, you have a hybrid cloud options. You can... Microsoft offers the Azure pack so you can actually set up your own cloud, your own Azure in your data center. And you can combine this with the public cloud, the real Azure. So you can set up some services locally, some in the cloud, depending on what you're comfortable with. And you can move them over time. And you can, of course, run your own private cloud if you want the cloud features, but you're not comfortable. But I don't see that as a really nice solution. But the hybrid options, they open up many new doors, I think. So anyone doing this now? We're working on an application. I won't get into the details. We're not done yet. But we're going to handle sensitive medical information and do analysis and reporting on those data in the cloud. We're actually going to use Microsoft Power BI to do analysis. It's going to be great. And I believe we're the first in Norway to do this. But we're not done yet. But I have to tell you guys because I think this is quite cool. We're probably going for both the hybrid and not hybrid solution, depending on we're supporting many customers. So we're probably going to recommend that they use the replicated data into the cloud, move a copy there. But we're also going to support connections to the local data center. And another example, this is from Microsoft. The Dothma of Hitchcock Medical Center in the US. They're gathering medical sensor data from patients. So this is real-time information. They're pushing it up into the cloud, into Azure, where they use machine learning to monitor the data. If there is a problem, they can actually notify the nurse, the doctor, and the patient can get help if they even notice that there is a problem. It's fantastic. And setting up a service like that in the cloud is doable. But setting up in your local data center, that would be a challenge in so many ways. So the cloud is opening many new possibilities here. How do you secure an application in Azure? I just want to go through a few details. I'll give you some references later. Encrypting your storage. SQL servers offer TDE. That's really, they encrypt the entire database. It's just a click of a button and it works. So do that. If you use blob storage in Azure, there is a preview now of encryption as well. So your blobs are encrypted. So they're going to roll it out this autumn sometime. I don't know exactly. But it's in preview now. And also you have the client-side encryption if you need that. So you can encrypt your data, even before it arrives in your service. Microsoft offers Key Vault as a nice way to handle all your secrets, your connection strings, your password, your encryption keys. Key Vault offers a nice API to access those data, only when allowed to do it. So it's quite easy to use. It's secure. And you can even use hardware encryption. So it's safe. And if someone somehow should be able to access your encryption keys, you know. Also, you have Azure Virtual Networks. If you need to connect to your on-premises services or you want to limit your only exposure to your cloud services to your local data center, and Azure AD offers some really nice security features as well. I got some, I'll give you some links and I'll publish my slides later. So watch the NDC Twitter feed. Because you need to read up on this if you want to do it. But there are some really nice features in Azure. If you're not on Azure, Amazon or Google, it's the same, but different. You can do more or less exactly the same things. I don't really, it's been a while since I used Amazon and Google. So I don't know so much about the details. But for instance, Amazon, they offer what is called Amazon Direct Connect. So it allows you to set up a channel to your local data center. So it's like a VPN. And they also offer exactly the same features for encryption of data as Azure does. And also Google, they got Google Cloud Interconnect. It's the same encrypted channel back to our home data center. And they also offer the same standard security features, encryption, all that. So I'm used to using Azure. And so that's what I talk the most about. But Amazon, Google, they offer the same thing, more or less. And I'm good on time as well. So let's summarize. If you know what you're doing, then I believe the cloud is quite safe for sensitive data. There are no technical reasons why you can't do it. You get the same security features. You get a safer data center. So as long as you trust your cloud provider. And they're certified in all levels. So I believe you can trust them. But make sure, talk to them. And as long as you trust them, then there are no technical reasons why you can't use the cloud for sensitive data. According to Norwegian law, you can use the cloud. And there are some old laws that can make things troublesome. You have to ask for dispensation or cheat. But the government is working on those laws as well. Depends on what you're doing. But you want to keep your data in Europe. I believe that's for all EU countries. You want to keep your data in Europe. Because of how the, then you're under European law, and it's much easier. You want to secure services exactly the same way as you do when you're running your local data center. But in the cloud, you can do more if you need to. And from what I know, the only exception here is classified military information. If you're working with that, then don't go for the cloud yet. Boring. So the challenge is the skeptics and convincing them. And I hope what I said today maybe can help. So let's end with some references. I will publish the slides. The first one, it's an analysis of the taxi data. It's a really interesting blog. It's a fantastic story. Also a story about the Danish railways. There are some Norwegian links here to what the government says. The Norwegian data protection authority. And the cheat sheets from OWASP. They have a tremendous amount of resources covering all aspects of security. So visit our site and read. It's a brilliant source. Fantastic. Also on the technical side, there are some references to Microsoft. There are some huge links. But I'm going to publish this. I don't worry about it. So Microsoft, they have some sample apps up on GitHub. There are no applications covering end-to-end all the security features. So you have to mix and match. I recommend them that they build a proper example that covers everything. So I hope they do that soon. And also there's some documentation on Kivo client side encryption and storage encryption. The storage encryption, as I said, is in preview. But it's going to be available quite soon. So I have time for a few questions if you want to. If you want to kick me down from here for what I said, then you're free to do so. And I can see a thing. The light is terribly bright. And if not, I'm here for the rest of the conference. So come on. Let's have a talk if you want to. Yeah. Thank you. Thank you.
 Okay, hi everybody. My name is Runegrin Sir. I'm here today to talk about sensitive data  in the cloud and the fact that you can't do that. Or at least that, the general opinion.  I'll be talking today about writing custom software, not software as a service, Google  Docs, Office 365, because that's boring. I'm a developer and writing code. That's what  I like to do and that's what I like to talk about. So, much of what I'm going to say today  applies to software as a service as well. That's not going to be my focus. But before  I start, I want to say this is my opinion, not my employers. I've got some colleagues  here. Because this is a kind of controversial topic actually. So, this is based on my experience,  my opinions. And actually, the idea for my talk came around when I started working with  sensitive data in our organization. We write software for the Norwegian hospitals. We're  focused in the middle region of Norway, but we support all hospitals in Norway, even some  foreign ones. And the software we write, it handles your medical information. So, it needs  to be secure. At the same time, we see that the cloud offers a really nice feature. It's  scalability, economy, availability. There's lots of good stuff here. So, while we really  want to go there, the general opinion has been, you can't do that. So, that's what I'm  going to talk about today. But before I start, I want to know who's here. How many of you  are software developers? Write code? Yeah, almost all of you. Cool. Are many of you Norwegians?  Yeah. Because at least one of the things, I'm more or less trying to skip it, the boring  stuff, the law. But I only know Norwegian law after all. So, I won't spend too much time  on it. How many of you handle sensitive data? Yeah. Anyone doing it in the cloud already?  Almost nobody, exactly. Yeah, that's how it used to be. So, my topic today, sensitive  data in the cloud. Can you do it? From the discussion we had at work, what I see on the  internet, this is a really hot topic. I see lots of you here today. So, I suppose you  agree. And at least, from what I'm in my organization, the consensus is, you can't do that. The  cloud, it's not safe. But what I'm going to say today is that you can. So, for those of  you who want to go into one of our other talks, that's a short version. You can do this. So,  hurry up. There's lots of interesting stuff going on. So, that's my opinion. And I try  to argue for that. But you have to know what you're doing. And this is my opinion. It's  also, it's not just me. For instance, the Norwegian data protection authority, they're  called data to see in Norway. They actually say that the cloud, it's not only safe, but  it's probably safer than running on premises. And the Norwegian government, they're working  on changing the law now because they want us to use the cloud. They see the benefits  of cost flexibility and safety. So, this should be quite easy. But it's not that easy after  all. So, if the authorities say you can do that, what is the problem? I think you all  have an opinion on that. In essence, hosting an application in the cloud or on premises,  you need to do the same thing. You need to secure it. And you have the same problem.  There is a risk that somebody can access your data that you don't want them to do. They  shouldn't be able to access your data because it's secret, it's private. And what's the  problem with the cloud? It's got the same problem at home in your local data center.  But the cloud, it's a shared platform. You're not hosting your data locally. And you don't  control the environment. And it's very hard to have full control of what's going on. So,  you have to trust somebody, an external part, your cloud provider. And also, data from the  cloud is transferred over the internet. That may or may not be what you do today. But at  least for my applications, handling medical data, we're running a more or less secure  network, a closed network. So, if I want to move my application to the cloud, then I have  to transfer it over the internet. And that's scary, very dangerous. Also, in the cloud,  you don't know exactly where data is stored. Absolutely do not know which hard drive is  stored on. You don't know which server, not which server room, maybe not even which country  it's in. Most providers let you select the data center. But where is that data center?  You've never been there. So, at least there is a perceived loss of control here. I'm not  saying that you lose it, but the perception is that you don't control the world the same  way as you do when you run locally. But the greatest problem, at least the way I say it,  is that the cloud is new. It's been there for years, but this is new stuff. We're not  comfortable with it yet. And that's what I see as a main problem, because there is a  myth that the cloud isn't secure. I call it a myth because it's not true. But we all  believe it. At least many do. So, when I say it's a myth, that's when I focus on the big  cloud providers. I talk about Amazon, Google, Microsoft. So, the big ones. If you're looking  at the hordes of small providers, calling them some cloud providers, honestly, I don't  have any experience with them. If you're handling sensitivities, you should be careful. Go for  the big ones. And from what I've seen, the security is really nice. So, I'm going to  go back to that. But first, let's talk about what sensitive data is. I just need a drink.  Did I know you go to the shrimp cruise last night, by the way? Yeah, it was a bit too  much fun. My voice isn't exactly where it should be today. I hope you forget that. So, sensitive  data. It's information you don't want to share. It's whatever you... It's your secrets. It's  private. It could be economic information, health, of course. It can be a private discussion  in your position, your company's economy. Anything that you don't want others to see.  And it doesn't mean that we have something to hide. It's not that. But it's private.  As long as it's private, then it's sensitive. But there are various levels of sensitivity.  Not all sensitive data are equal. So, we need a background here. There are several levels  of sensitivity. Usually, we talk about three or four. First, you have the directly identifiable  data. This is the most sensitive data, the way I see it. It's when, for instance, in  your database, you store up a personal ID, say, a social security number, to get away  with it, a diagnosis. So, you say, this person has this medical condition. Combine them to  not necessarily the same database, but if the data are available and easy to combine,  then it's directly identifiable. You know who the person is. You know who the company  is. You can point to someone directly. Then you have what is called, I call, indirectly  identifiable data. This is information that it can look anonymous. But as soon as you  start to combine it with other data sources, then you can get more information out of it  than you intend to. For instance, if you have a diagnosis, and you don't store a social  security number, you don't store a phone number, you don't store a name with that data. But  maybe you have a person's age, a weight, gender, maybe even which part of the country that  person lives. Without that information, and if it's, say, for medical, it's a rare diagnosis,  then you may start to find out who that person is. And then you're exposing sensitive information  without meaning to. There are several examples of people doing this. But you have anonymous  data. That can be the same data source, but it's aggregated over a group of people. Usually  you have a rule of thumb. If you have more than five people in an aggregated, then it's  anonymous. You can't find out who the person is. It depends on what you're doing, depends  on your data. But that's a simple rule that you can use. So even aggregated data can be  sensitive if you have a small enough group. Finally, you've got information that isn't  sensitive. Say, for instance, public information. Your name, your phone number, where you live,  that's not sensitive information because it's probably in the public data sources. It's  easy to find on the Internet. Also, test data and all kinds of that kind of stuff. It's  not sensitive. So the more sensitive your data is, the more important it is to protect  it properly. And you need to think of that. I'll give you an example. It's a fun story.  In 2013, there was a released data source that contained all taxi rides in New York  for a whole year. And it contained no personal information, they thought. So they had the  taxi cab's ID. There was a date and time when the ride was done. It was where the ride was  from, where it was to, how much was paid, did a passenger tip. But there was no information,  there was no name, no number. It didn't say who the person was. So the smart people on  the Internet, they took this data and started Googling pictures of celebrities on taxi drives  in New York. And they found pictures. And they could see, they found pictures of celebrities  working a ride at a certain moment. And they were able to find the data in the data source.  The same place, same time. Then they knew who it was. So you can see that this celebrity  went from there to that and didn't tip. But they could do more with that data. They started  aggregating it. And so they found frequent trips between addresses. For instance, trip  bars. To private addresses. And when they looked at those private addresses, some of them,  there weren't that many people living there. And your address is public information. So  they were able to find out who that person was. Several of them. And they were on Facebook.  Only this anonymous data source identified very private information about people. So  while your data may not look sensitive, it may well be, after all. So you have to think.  Now how do we secure our data center? I love this picture. That's how it looks at home.  We have this myth about insecure cloud. So how do we secure? First locally, how do we  secure our local data center? There are many people talking about this. I won't get into  the details. But normally you will build a secure data center. Probably underground,  in a secure bunker. It's got limited access. Only this and that. You too have access. The  rest of you can't even access the room. So it's physically protected. All of your servers  are redundant. You probably have two data centers. So even if this data center stops, this one  is still working. So you've got to redundant security. Then you set up your network. You  use reverse proxies. You use heavy duty firewalls. So you make sure that only there is no inbound  traffic. Everything goes out. You make sure that you have full control of what's going  on. And then you set up your application. You follow all the best practices and guidelines  doing proper authentication. Probably two-factor. It may be even better. You have full control  of authorization. And you secure your data. You encrypt your storage. You use HTTPS, TLS,  all the good stuff. You follow all the over spread commendations. So you secure your application.  And you're happy. You're secure. How is the cloud different? Can't you do that in cloud  as well? And you can. But there are some differences. So let's talk about the bad stuff first.  The cloud, it's a shared environment. You don't own the servers. You don't own the environment.  You share it with other tenants. So you don't control the data center. You don't control  who can access your data center. You actually don't know who can go look at your servers.  So you have to trust. And you don't control where your data is stored. As I said, you  don't control the machine. You don't control the hard drives. You don't control anything.  And your application, it is not running locally. And if you're offering a service on internet,  that's business as usual. But if you're running in a closed network or a limited network,  this can be a challenge. And you must, I can't repeat this enough, you must trust your cloud  provider. You need to trust them. You need to be sure that they won't do anything wrong.  You need to trust that they are good. You need to trust the certifications. You need to be  sure that they know what they're doing. And on top of that, at least if you have an existing  application, it probably doesn't fit in the cloud. That's a different talk. I won't get  into it. But in some cases, it can be terribly expensive, actually writing your application  to work well in the cloud. But there are lots of good stuff in the cloud. First of all,  it's a shared environment. It's not just bad. It's great. Because you have proper separation  between tenants. It's built so you can't access your neighbor's data. It's impossible. But  this shared environment gives you flexibility. So it can be a problem, but it's also great.  And this data center is run by huge corporations. Instead of your local data center, you're  running 10, 100, maybe 1,000 servers. You're big. These guys, there are millions. I heard  that in Azure, Microsoft, I believe there's one administrator per 15,000 servers. And  they're running millions of servers. But they don't really spend too much money administrating  it. But they spend lots of money, lots of resources on securing this. That's what I  live from. In the cloud, you can usually control which region your data is stored. Like Azure,  they have the data center in West Europe, Northern Europe, several places in the U.S.,  Asia, all around the world. And you can say, I want my data to be stored there and only  there if that's what you need. Also, the challenge with network traffic, your data being on the  Internet, there are ways to secure network traffic now, actually. Now, there have been  lots of problems with traffic on the Internet, encrypted traffic being hacked. But as long  as you're up to date on the latest standards, then you're good. And also, the cloud, it's  a rapidly moving target. You get the new security features all the time. For instance, again,  Microsoft, they just launched SQL Server 2016. It's been running in Azure for a long time.  And the new features there, in Azure, you've had them. But you just got them locally. So  they're updating the cloud much more often. So you get the new features much earlier.  So there are lots of good stuff. And all the flexibility, it's really useful as well.  There was another example. In 2010, Stone Ages, there was in Denmark, a company called  Barnard-Donmark. You probably haven't heard of them unless you're Danish. They moved all  the services from a local data center into the cloud. I've still read some articles about  that. There was lots of discussion, is that smart? Is that the risk? They moved to the  cloud. Then that winter, the day before Christmas, there was a huge snowfall. All the trains  stopped. And people wanted to know what's going on. So they started hammering the websites  of the train companies. It's really a DDoS attack. And all the websites went down. And  that's this one. They were running in Azure. So when the traffic went from 50,000 visitors  per day to 5 million, they pushed the button. They got enough capacity to keep it on. So  all the services kept running. The customers were, I won't say happy. Nothing worked. But  at least they got their information. And then after a few days, they could scale down again.  And serving those 5 million visitors a day cost them, I think there was a 180 Danish  Kroner. That's like $30. It's nothing. So they could scale up, have the capacity when  they needed it, and then scale down again. So the flexibility here is incredible.  So in most cases, I believe, actually, the cloud is most secure. The Norwegian government  has written a strategy on cloud services. And they actually conclude that they want people  to use the cloud because of security. That's interesting. That's new. So how do we protect  our data in the cloud? In general, you follow the same rules. Exactly as you were locally.  It sounds really easy, and it really is. But we need to consider our data and how to secure  it. We have your data, it's a living thing. It's several places. We talk about data at  rest. So when it's stored in your database. Then we talk about data in transit. That's  when it's moving across the network, either between your servers or on the way to the  user. And finally, we talk about data and use. That's when your user is actually viewing  your data and using it. All those three places post risks. You need to think of security  of all of them. Then we talk about confidentiality. That's how secure are we? What's the risk  of someone who shouldn't be able to look at our data? Actually, I'm able to get access  to it. And finally, we have data integrity. We're talking about what's the risk of your  data not being complete? Have it been changed by someone in transit? So those are the factors  we have to look at. Data at use. That's a cute cat, huh? Well, your data is at use. Your  user is looking at it. So we're talking about the user interface. It's often the first thing  we think of. We need to set up proper access control. You probably want sensitive data,  at least two-factor authentication. Ideally, you don't want to do authentication yourself  at all. You want to rely on a third party that has proper infrastructure. Here in Norway,  we do what is called IDA-Porten. They are a national service that handles personal identities  in a secure way. So not only can they give you an identity, they can tell you how sure  they are about that identity. And we can trust them to have the proper infrastructure. And  then we don't have to handle that complexity. Unless we have to do it better. So proper  access control, that's important. You will, of course, set up your firewalls. If you need  your application only to be available in a limited network, in the cloud, you can use  firewall rules limited to a certain IP range. If that isn't enough, you can set up a virtual  private network or even a dedicated line between the cloud and your local network. So there  are ways to limit access to your cloud services, even though they are running in a shared environment.  Of course, if you want to limit your limited access, then it means that you trust your  home network. And here in Norway, all the hospitals, they are running in what is called  the health network. It's a network combining all the hospitals and other companies handling  medical data. It's actually quite large, a large mean of internet between the hospitals.  But the challenge there is that the data is not, or the network, the computers that can  access that network also can access the internet. And there is no real governance, who can access  the health network? It depends on the various organizations. So is that really a secure network?  So why do we trust so much this network and not the one run by professionals? I'm not  saying that. Sorry, I'm sorry. I'm not saying that we're not professionals at home. We have  best people available. But it's a big network. You can't really control it unless you have  proper governance and you know exactly who has access to it. As long as the computers  accessing your safe network also access to the internet, you have an open gateway. So  what's the difference? So secure applications, set of firewalls, access rules, all that stuff,  and follow all the best practices. OVOSP, you know them? They're an organization. The focus  is security for applications on the internet, really. They have some really nice sheets,  for example, on authentication and access control. I'll post links to them later. If  you follow those guidelines, I'm not saying they're easy, but they're easy to read. So  they're clear. They're quite good. And here, if you're running on premises or you're running  in the cloud, it doesn't really matter too much. You need to secure application after  all. In the cloud, you get some security feature that can be nice. In Azure, you have Azure  AD. And it makes these things quite simple. But the biggest risk is the user. We are the  risk, not the network, not the authentication mechanisms. All research shows that the easiest  way to hack a system is to fool the users. If someone calls to a user of your system  and says, hi, I'm from the IT department, what's your password? There is a real chance  that they will say, oh, it's ABC123. Thanks. And you have access. It's much easier, much  quicker than hacking into a system, brute-forcing password protection or whatever. So the challenge  usually is the user, not the platform you're running on. So, data in transit. Here we have  the fared man in the middle. It's scary. Potentially, someone can look at your data while in transit.  So while your data is on the way from your local data center to your user, they can pick  it up, maybe even modify it, read it, and post it on. In theory. And there have been  some, actually, several attacks on the SSL and the TLS protocols, the encryption that  we do over the network. So you need to stay up to date on the latest versions on the protocols  and the software you're running. But as long as you encrypt your traffic, use the latest  version, use HTTP strict transport. So you're always encrypting your traffic. Then in reality,  it's very hard for someone to break into that traffic. Of course, if your user has a computer  with a bad root certificate, then you have a problem. I got a Dell. And these computers,  they were sold with a root certificate that the password was easily hacked. So it was  quite easy to fake the traffic. So, again, the user can be a challenge. But you need  to set up your network properly. And then you're quite secure, actually. So, man in the middle  attacks, that can affect both confidentiality and integrity. Since not only can they look  at the information being transmitted, but they can also change it. The difference here  between running locally and in the cloud is that a cloud provider, they have lots and  lots and lots of resources on securing the platform. Usually, at least where I work,  the guys running a network, they're overloaded with work. They have way too much to do. They're  brilliant people, really good. But they don't have enough time. So, securing our network,  keeping everything up to date, that's going to be a challenge. Unless the network grows,  the challenge is going to grow. In the cloud, when you have one administrator per 15,000  service, whatever, you can spend more money on securing the network. They do penetration  testing. They look for problems all the time. And they have large teams doing that. So,  again, most probably, the cloud is a more secure platform than your home network. Finally,  data at rest. This is when your data is stored at your server. It can be in a database, it  can be in a file, whatever. And this, I believe, this is the main challenge when running in  the cloud. So, we need to ensure that whoever runs our servers can look at our data. Encryption  is a friend here as well. You probably want to encrypt your storage, whatever you do.  So in SQL server, you can encrypt the entire database, for instance. In Azure, the blob  storage now supports encryption in preview. So, you want to encrypt it. Then you want  to make sure that your sensitive data, they encrypt it again. So, not only do you encrypt  your database, but you encrypt the data as well. So, layers of security. And, of course,  you don't use the same encryption keys. Ideally, you don't even have access to those keys.  Keep them away from your data. Further, you probably don't want to mix your sensitive  data with your other data. Usually, a part of your data is more sensitive than the rest  of it. For instance, in the systems I work on, we usually keep the personal ID, the social  security number, in a separate database with separate encryption keys. And we keep it encrypted.  But it's physically separated from the other data. So, even if someone gets access to my  database, my data, it's in worst case. It's not directly identifiable. So, it's still  sensitive data, but it's much less sensitive than if we throw it all in one big pile. So,  you can get your data. You got in the cloud, you often get hardware encryption. So, you  can get another layer of security. It costs money in Azure, for instance, but well worth  it. And finally, you need to control who can access your environment. In the cloud, it's  very easy to say, hey, you need to set up a server. I'll give you the pass, give your  account access, and you can access everything. It's terribly easy. And you need to limit  the access. So, keep a few persons that can administer your data. Because this is your  server room in the traditional sense. So, lock it down and encrypt it. Keep your keys  safe. There is one problem that I haven't discussed yet. And that's the government. Big brother.  And especially the US government. There are cases that the US government, they want insight  into data storage in the cloud. And this is a potential huge problem. All the big cloud  providers, the American companies, they have to follow American law. And even though the  data is, for instance, stored here in Europe, it's still an American company handling it.  And this can be a huge problem. Of course, encryption, keep your keys safe somewhere  else. And it's just garbage if they should access it. But it depends. Software as a service  is a bigger problem here, I think. Also, Microsoft, they have a nice solution to this problem.  They're setting up a new data center in Germany. It's Azure. It's got all the features, all  that. But they don't own it. I believe it's Deutsche Telecom who owns the data center.  So that means that even though it's Azure, Microsoft don't have access to your data.  And so it's not following American law anymore. It's following European law. And this is a  topic for discussion. But I believe European privacy laws are better, at least easier to  have control of than American laws. We can discuss this for days. But let's just say  that for now. European law, it's easier to follow. And it's better. So you're laughing.  It's a big topic, so it's way outside the scope for today. So the cloud is safe for them  running locally. You're almost guaranteed, say, for environment. You're almost guaranteed  that the organization running the data center in the cloud has much more resources than  your local company. And they probably spend much more resources on securing both the data  center, the network, the servers, everything. And what you can do in your local data center.  You got more security features, faster updates. And really anything you can do locally, you  probably can do in the cloud. So it's the same bit more. Also you get better physical protection.  Like my company, we have two data centers. They're physically separated. We've got several  networks connecting to that. So it's not that it's going to stop. But should my hometown  try to disaster happen there, then we have a problem. In the cloud, the data center is  separated. So you can set up, for instance, services to be replicated between Western and  Northern Europe. So even if something bad should happen in Ireland, it's still up and  running. So the physical security is better. Also the protection of the data center themselves.  That's insane. I recommend you look it up. Crazy guys. So, but still, there are reasons  not to use the cloud. If you, for instance, have your existing infrastructure, moving  to the cloud can be expensive. There are hybrid solutions. I'll get back to them. But also  you have the problem that once you move to the cloud, going back, it's not easy. Azure  isn't compatible with Amazon in any way other than the most superficial. They offer virtual  machines. They offer storage, they offer databases. They're not the same. So it's not easy to  move between the environments. So once you've chosen a provider, you're stuck. And this  is a real concern. They're afraid of lock-in. And also the cloud is new. It's a new model.  It's a new way of hosting your applications. And as I said, you need to trust your provider.  And I see it as a natural next step. We started typically with a local data center where your  local people were running your servers. Then you found that it's terribly expensive. You  started hiring people to run it instead. Pay for what they do. So then you didn't control  the people anymore. Then you probably saw that why should I be running these servers?  Then you move your servers to a hosting provider. So then you don't control the environment.  You have to trust your provider. But you still can probably know who they are. You still  know where the data center is. And the cloud is the next step after that. You still have  to have a provider that you must trust. But now you don't know where it is. You don't know  where the servers are or anything. So what does the law say? This is probably  only interesting for the Norwegians here. Because I didn't have time to look up the  laws in all the countries in the world. But Norwegian law is quite strict. So I believe  as long as the stuff is legal here, it's probably legal in your country as well. And I'm not  a lawyer. I'm a programmer. So I'm no expert. But I've been reading and checking out. And  you can't store classified military information in the cloud or outside Norway. But apart  from that, there really aren't any... The law doesn't stop you. There are some old  laws that say, for instance, that an archive can't be moved out of Norway. But as long  as you keep a backup in Norway, you're probably good. And you can ask for dispensation for  that law. The government, they're actively working on modernizing the law. Because they  want us to use this. And for those of you who are interested in this, I got some resources  on it. So I can help you to look it up. But we won't dig into it now. So the short summary  here is that the law doesn't stop you. You can use the cloud for sensitive data. Really?  Yeah, it's true. You can do it. But the same requirements apply as if you're hosting them  in Norway or locally. Of course, in your country, there may be restrictions. There may be other  laws. So make sure to look up this. Because if you don't check it out, then there's no  guarantee. So talk to a lawyer before you move your data into the cloud. So if you're  still uncertain, you can use hybrid solutions. And this is good... This is quite nice, actually.  You don't have to move everything into the cloud at once. There are several ways to take  one step at a time, move gradually. For instance, you can store your data in your local data  center while you're running your servers in the cloud. You can set up a VPN so you can  access your servers. And there are other technologies. So you can run your servers in the cloud and  keep your sensitive data at home. Then you've got partially a cloud solution, partially  the old way. And it can be a nice way to start your transition. Also, you have a hybrid cloud  options. You can... Microsoft offers the Azure pack so you can actually set up your own cloud,  your own Azure in your data center. And you can combine this with the public cloud, the  real Azure. So you can set up some services locally, some in the cloud, depending on what  you're comfortable with. And you can move them over time. And you can, of course, run  your own private cloud if you want the cloud features, but you're not comfortable. But  I don't see that as a really nice solution. But the hybrid options, they open up many  new doors, I think. So anyone doing this now? We're working on an application. I won't get  into the details. We're not done yet. But we're going to handle sensitive medical information  and do analysis and reporting on those data in the cloud. We're actually going to use  Microsoft Power BI to do analysis. It's going to be great. And I believe we're the first  in Norway to do this. But we're not done yet. But I have to tell you guys because I think  this is quite cool. We're probably going for both the hybrid and not hybrid solution,  depending on we're supporting many customers. So we're probably going to recommend that  they use the replicated data into the cloud, move a copy there. But we're also going to  support connections to the local data center. And another example, this is from Microsoft.  The Dothma of Hitchcock Medical Center in the US. They're gathering medical sensor data  from patients. So this is real-time information. They're pushing it up into the cloud, into  Azure, where they use machine learning to monitor the data. If there is a problem, they can  actually notify the nurse, the doctor, and the patient can get help if they even notice  that there is a problem. It's fantastic. And setting up a service like that in the cloud  is doable. But setting up in your local data center, that would be a challenge in so many  ways. So the cloud is opening many new possibilities here. How do you secure an application in Azure?  I just want to go through a few details. I'll give you some references later. Encrypting  your storage. SQL servers offer TDE. That's really, they encrypt the entire database.  It's just a click of a button and it works. So do that. If you use blob storage in Azure,  there is a preview now of encryption as well. So your blobs are encrypted. So they're going  to roll it out this autumn sometime. I don't know exactly. But it's in preview now. And  also you have the client-side encryption if you need that. So you can encrypt your data,  even before it arrives in your service. Microsoft offers Key Vault as a nice way to handle all  your secrets, your connection strings, your password, your encryption keys. Key Vault offers  a nice API to access those data, only when allowed to do it. So it's quite easy to use.  It's secure. And you can even use hardware encryption. So it's safe. And if someone somehow  should be able to access your encryption keys, you know. Also, you have Azure Virtual Networks.  If you need to connect to your on-premises services or you want to limit your only exposure  to your cloud services to your local data center, and Azure AD offers some really nice security  features as well. I got some, I'll give you some links and I'll publish my slides later.  So watch the NDC Twitter feed. Because you need to read up on this if you want to do  it. But there are some really nice features in Azure. If you're not on Azure, Amazon  or Google, it's the same, but different. You can do more or less exactly the same things.  I don't really, it's been a while since I used Amazon and Google. So I don't know so  much about the details. But for instance, Amazon, they offer what is called Amazon Direct  Connect. So it allows you to set up a channel to your local data center. So it's like a  VPN. And they also offer exactly the same features for encryption of data as Azure  does. And also Google, they got Google Cloud Interconnect. It's the same encrypted channel  back to our home data center. And they also offer the same standard security features,  encryption, all that. So I'm used to using Azure. And so that's what I talk the most  about. But Amazon, Google, they offer the same thing, more or less. And I'm good on  time as well.  So let's summarize. If you know what you're doing, then I believe the cloud is quite safe  for sensitive data. There are no technical reasons why you can't do it. You get the same  security features. You get a safer data center. So as long as you trust your cloud provider.  And they're certified in all levels. So I believe you can trust them. But make sure,  talk to them. And as long as you trust them, then there are no technical reasons why you  can't use the cloud for sensitive data. According to Norwegian law, you can use the cloud. And  there are some old laws that can make things troublesome. You have to ask for dispensation  or cheat. But the government is working on those laws as well. Depends on what you're  doing. But you want to keep your data in Europe. I believe that's for all EU countries. You  want to keep your data in Europe. Because of how the, then you're under European law,  and it's much easier. You want to secure services exactly the same way as you do when you're  running your local data center. But in the cloud, you can do more if you need to. And  from what I know, the only exception here is classified military information. If you're  working with that, then don't go for the cloud yet. Boring. So the challenge is the skeptics  and convincing them. And I hope what I said today maybe can help. So let's end with some  references. I will publish the slides. The first one, it's an analysis of the taxi data.  It's a really interesting blog. It's a fantastic story. Also a story about the Danish railways.  There are some Norwegian links here to what the government says. The Norwegian data protection  authority. And the cheat sheets from OWASP. They have a tremendous amount of resources  covering all aspects of security. So visit our site and read. It's a brilliant source.  Fantastic. Also on the technical side, there are some references to Microsoft. There are  some huge links. But I'm going to publish this. I don't worry about it. So Microsoft, they  have some sample apps up on GitHub. There are no applications covering end-to-end all  the security features. So you have to mix and match. I recommend them that they build a  proper example that covers everything. So I hope they do that soon. And also there's  some documentation on Kivo client side encryption and storage encryption. The storage encryption,  as I said, is in preview. But it's going to be available quite soon. So I have time for  a few questions if you want to. If you want to kick me down from here for what I said,  then you're free to do so. And I can see a thing. The light is terribly bright. And if  not, I'm here for the rest of the conference. So come on. Let's have a talk if you want to.  Yeah. Thank you.  Thank you.
Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_0_47.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_48_107.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_108_2003.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_2004_2219.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_2220_2267.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_2268_4967.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_4968_6599.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_6600_10091.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_10092_11447.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_11448_12887.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_12888_13019.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_13020_14111.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_14112_15683.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_15684_16499.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_16500_20327.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_20328_22751.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_22752_31547.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_31548_32231.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_32232_32351.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_32352_32543.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_32544_32807.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_32808_33107.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_33108_33623.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_33624_41243.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_41244_46175.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_46176_50699.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_50700_53327.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_53328_59051.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_59052_61931.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_61932_64283.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_64284_64355.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_64356_65507.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_65508_66863.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_66864_69995.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_69996_71543.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_71544_71591.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_71592_72059.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_72060_72191.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_72192_72419.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_72420_72491.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_72492_72539.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_72540_72767.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_72768_72815.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_72816_73043.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_73044_73439.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_73440_73667.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_73668_73763.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_73764_74027.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_74028_74963.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_74964_76115.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_76116_76751.png Sensitive_data_in_the_cloud_You_can_t_do_that_Rune_Andreas_Grimstad_76752_77157.png