 So the first speaker for today is going to be taking of the topic designing secure applications in the cloud. And that is by Adora Wadu. I hope I pronounced that right. Yeah, so Adora is fun to call. She's called Adora. I'm just calling her Adora because yes, that's what I know her by. She is a software engineer based in Lagos, Nigeria and currently works at Microsoft where she builds cloud services related to artificial intelligence and mixed reality. She's also an author of the book, Cloud Engineering for Beginners. If you haven't seen that, you can check her Twitter. It's been there. It's an interesting book to look out for. And Adora has created a blog called Adora Hack, where she publishes articles on software engineering, productivity and career groups. You might also want to check out her YouTube channel where she posts content on useful software development tips. Over to you, Adora. Thank you. Can everybody hear me first of all? Yes. All right. Okay. Hi everyone. I'm excited to be here this morning or good morning, good afternoon, good evening depending on where you are joining us from. Excited to be giving this talk today about designing secure cloud applications. So yeah, let's get right into it. I heard Didis's story and it's interesting. I mean, I've heard it before on its Twitter space, but it's just interesting to hear again and to reinforce that. And to be honest, there are so many people like her that have transitioned into that space and there are so many more people that would do that. And one of the reasons why is because it's interesting and the cloud is also becoming really big if we think about it. Apart from the fact that the cloud is like the bedrock for a lot of innovation nowadays, there are so many benefits to why a business would want to move their computing to the cloud. And there's some of these benefits that are listed here. You can use applications as utilities over the internet. You can manipulate and configure your apps online. You don't need to install any software to your local computer. You can use online dev and deployment tools you have on demand self-service, depending on how you are using the cloud. It can also be cost effective for you in the sense that you pay for only things that you need. It's highly efficient, reliable and flexible. And there's so many more reasons why you would actually want to do your, move your business to the cloud. But the truth is with all of these benefits and things that come with the cloud, comes with some kind of responsibility as well. Yes, if you are using Docker or Kubernetes as well, you will be able to do zero downtime deployment. So it's not because you are trying to deploy code that your customers would not be able to use your service, even if it is for a split second. You'll be able to do a bunch of amazing things. But again, with all of these things, because now everything is on the internet and it is publicly accessible over some network, there has to be some form of responsibility. And I want to play this short video. I really hope that my laptop can't transmit sound as I'm screen sharing, but let's see how it goes. Hey there, I'm going to tell you a story about what happens when you do not protect public resources. This house has water supply in form of a bucket at the compound. This is a housemate who actually needs water. He gets on into his bowl and goes back inside. This second person who happens not to be a housemate comes to the public area where the water is and makes it unfit for everyone to use by washing her hands inside. This housemate happened to be walking in the direction of the water and accidentally kicked it. Now all the water is gone. Why did this happen? Because access to the water wasn't properly regulated. How do we fix this? Take the bucket away and keep it in a safe place. Secure the house to prevent outsiders walking by from tampering with resources only meant for housemates. Connect a tap so that housemates get water in a structured way. The end. The water was a cloud resource on the internet. Somebody has come and put what they are not supposed to put inside. Somebody has come and used it in the way that it's supposed to be used. Somebody came from nowhere and was just walking by and accidentally kicked the water and disappeared. And now let me use data as let's swap this bucket of water with actual customer data. Somebody comes and washes their hands inside. Basically an attacker comes and is able to corrupt your data in some way just because you've not protected it properly and because they can. Somebody comes and uses the data how they're supposed to use it which is a normal regular user that needs that data. A normal developer that wants to fetch that data through API calls and has the right permissions or doesn't but just because they are the normal person they are using it the right way and that's fine. Then a third person who is coming and mistakenly kicks the bucket and throws the water which is basically somebody else who is supposed to be using or rather who is not supposed to be in that environment but has access to that data for whatever reason because it's not properly secure or regulated. And then they can just like delete the entire thing or even if it's someone that has permissions to do it it could be someone that doesn't have permissions to do it just coming to copy all your resources and then deleting it or it could be someone that has that is supposed to have permissions to do it but shouldn't have permissions to that level and they make a mistake and they go and delete the whole product and then somehow all your data is gone. Things like that. There's some security risks in building cloud applications. The first one is human errors, human mistakes which I just talked about. Somebody accidentally deleting all of the data because they didn't realize they had those permissions or because they wanted to delete something else and then somehow they went to go and delete the entire production infrastructure and now suddenly you don't have data anymore. Malicious Attacks which is similar to things like, sorry, Malicious Attacks which is similar to people going to wash their hands inside the tap, for example, right? So people coming to your data and corrupting it because you're not properly secured it. And the last one, which is legal and compliance issues I mean to be honest, there's no way you would tamper with a lot of customer data or use PII the way you're not supposed to that you don't expect lawsuits from coming to you or you don't expect security agencies when they do an audit on your business to say that you are not security compliance and this can bring issues for you and could also possibly damage your reputation. So in this talk, I would be highlighting the different architectural patterns for building secure cloud application and also some things that you can do outside software architecture still within your code as a programmer. Or a cloud engineer to also help you in thinking about securing these cloud applications. But before we go deeply into all of this I would want to quickly introduce myself. So hi again, my name is Adora and I'm a software engineer contributing mixed reality on the cloud at Microsoft. I'm also the creator of Adora Hack which started as a blog where I post content for software developers grew into a YouTube channel or rather extended into a platform extended into also having a YouTube channel where I post lifestyle content about my life as a software developer as well as content for software developers in terms of how to grow their careers, productivity tips and all of that. And recently also included a study group for people to ask questions and do peer programming together and learn sort of like having people come every week or every other week to answer all the questions that people have and facilitating sessions that force people to actually own their learning because now they have a safe space that they can get their questions answered. I'm also the author of this book Cloud Engineering for Beginners. It's a book that introduces the concept of the cloud, cloud engineering, different roles and job types in cloud engineering and different parts of the cloud to beginners in a beginner friendly way. Also on the advisory board for VRAR, Nigeria currently trying to do some form of VRAR education in this space advocate for the technology and promote usage of this technology in different industries as we move towards building the metaverse. And I basically live on Twitter. If you are on Twitter, you know that I'm mostly always there and you can find me on Twitter at Adiron Woodrow. So now let's get to it. When you want to start building your application, one of the first things you would do is to have a security checklist. And this checklist actually helps you analyze and understand how your applications need to be secure. So it's some form of defense before you are actually even attacked, which in my opinion is important. And there are some of these questions that you ask yourself, which is will my application contain sensitive data? Where and how are my applications data stored? Will this application be available over the internet publicly or will it just be available internally? How do I plan to verify my user's identity? What sensitive tasks are performed in my application and does my application perform any risky software activities? Asking this question will allow you to be able to think about your application security holistically. And when you ask yourself these questions, you can come up with answers. So if you're asking yourself, will my application contain sensitive customer data? If your application does contain sensitive customer data or what is called PII, you would now go towards thinking about identifying a data protection method for your application so that you can secure that data in transit and at rest. Where and how is my application data stored? You might start thinking about, you know, instrumentation to your storage services client so that you know at what points you are connecting to the client, storing the application. You entirely know the entire, you basically have a holistic view in your application about the entire life cycle in the storage bits. And you can also think about data protection so when you're thinking about where and how your application is stored and you can now properly think about data protection in an effective way. Will this application be available over the internet's publicly or just internally? So for public apps, you can be thinking about data protection methods. You want to make sure that people's data are protected. For internal apps, you might be thinking about, oh, okay, if this app is just available internally to maybe the developers in this company or on this team, you think about granting permissions to internal users. You don't want to give everyone super mean access. You want to make sure that the right people have the right access and no one is over privileged, basically. You can be thinking about how do you plan to verify your user's identity? And that's where you'd have to think of a good authentication and authorization strategy for the application that you are building so that it's secure. What sensitive tasks are performed in your application? You might also be thinking about an authorization strategy that is very key because you don't want people that should not be able to perform sensitive tasks to be performing this task because you haven't properly set the right permissions. And then the final question, does my application perform any risky software activities? And if it does, like maybe downloading, if you are going to be doing risky software activities like allowing people upload things up into your infrastructure, into your storage, you might be thinking about protection against malicious data. You might be thinking about the way to sign the data that comes into your storage before you make that data publicly accessible to many people because imagine people uploading data to your storage and that data is also supposed to be publicly accessible to anyone that is using the application. So it's like, oh, okay, I'm a creator. I can put things here and I can also, you know, I can read and I can write basically to your application or to your infrastructure. If you don't think about protection against malicious data, what's going to happen is that people can upload random things and they're not supposed to upload. If you've not thought of a way to sign that data, if not a way to protect or rather to verify that data that is being uploaded, somebody can upload in my way and something happens to everyone's data and next thing, people are calling you, you're answering lawsuits and different things that you do not want. And based on these questions that have been asked, you can put them into two buckets, the data protection buckets and the identity management buckets. And in this talk today, I'll be talking about three architectural patterns in these two buckets. The first pattern is the gatekeeper pattern which is under the data protection bucket. And the second pattern is the identity management pattern. Sorry, is the federated identity and valet key patterns which are under the identity management buckets. Now let's talk about the gatekeeper data protection scenario. So applications functionality are usually exposed when they accept and process a client request. So if the system is compromised and the malicious user gains access, all sensitive data will be exposed. So enter the gatekeeper pattern which is a way for the system to have a gatekeeper that validates and sanitizes the request before the request is actually forwarded to the service so that you can sanitize this request if somebody is, imagine someone sending a query, right? Somebody trying to just, you know how they pick at your data, still your data and in whatever request they're making to your service, it is a raw query and you don't check and validate or sanitize these things but you just let it go. They're going to be able to even write queries that delete things off of your storage or your database if you've not set these right data protection policies in place and you don't implement this gatekeeper pattern that helps validate and sanitizes these requests. So what happens with the gatekeeper pattern is that a gatekeeper exposes an endpoint to the client that is like a public endpoint. And then the public endpoint is the endpoint to a gatekeeper not the endpoint to a service. And after the sanitization and the validation is done, then a private endpoint that is the call to the service is made and with that, you can call all the different parts of the service, call your storage and stuff like that. So the benefit of using the gatekeeper is, you know requires validation, limited risk and security. And this is like a real life application of a gatekeeper pattern where there is a public endpoint which when you call it, you have like a gate, it gives you a gatekeeper role which is, you know, a limited privileged mode. And then once you are done validating and sanitizing then the gatekeeper can call the internal endpoint. And in that internal endpoint, you have full privilege because now you have a trusted role and you can use the service or the application however you want to. And the next thing I want to talk about is the valet key pattern which, you know, allows you securely control access to data by using a token that expires after a period of time. So this token can be used either for authentication and authorization. So let's say you want to access as a user, me, right? As a user or a client or a customer. I want to access your organization's storage because maybe I need like a read and write role to that storage because I'm supposed to be able to, you know, upload data onto the storage and then, you know, you would now help me process that data and then, you know, people can use it or I can get it back or whatever. I would have to implement something similar to a valet key pattern which is where me as a user, I request a resource from an application and then the application validates the request and generates a token for me, returns that token back to me. Now that I have that token, I can now present that token to the resource and be like, okay, this is the token and this is the action I want to perform on this resource. And then the resource can validate that token and perform the action or tell me that the token is invalid. So I will need to, you know, request another token or just know that I don't have permission to access that resource. And as an application, I can decide to set policies where I can, you know, revoke tokens after 30 minutes, you know, add some specific permissions to tokens so that it's not just anyone that has a token that can perform any kind of action on the resource. If I'm giving you a token that, you know, the claims on that token are only for read access, I don't expect you to be able to write any form of information to that resource and things like that. So this is a code that I got from the internet that explains this in like actual source code. So I hope it helps you. So doing this in like an Azure storage account, for example, I have a blob service client and I have a blob container. And then I'm like, okay, hey, I want to get shared access reference because I want to be able to upload data to the storage account. And then I get the client for the blob, which is like the storage account clients basically. And then I create a storage shared key credential. So I say, okay, this is the storage account name and I pass in the app setting as well for the Azure storage and Milito account key. And then I create like a blob source builder where I pass in my storage container, I pass in the name of the blob that I want access to. I pass the resource and also the time. So if I want to create an access key that allows someone upload a file and I want that access key to be revoked after 10 minutes, I can now add that, okay, my time offset should be 10 minutes. So after 10 minutes, if you're not done doing what you're doing, sorry, you have to request another token. And then I set permissions because you want to be able to upload a file onto my Azure storage, I give you right permissions. And then I create the URI and I send them back to you and then now you can do what you want to do with that. So this is like a code snippet for that sort of thing. The third identity pattern that I want to talk about is the federated identity pattern. So this allows you separate user authentication from application source code and delegates authentication to an external provider. A lot of people don't know that they do this, but they do this today. So if you are using, if in your application, you are not doing username and password, but you are actually using an external, maybe social media sign-on or if you are using maybe Microsoft, for example, you are using Azure access directory or MSI logging or MSI logging rather, you are already doing this sort of thing. And this pattern works like, okay, I am using this identity provider or security token service as a service or as an application, which is like, oh, signing with this thing. And what happens is that I write code in a way that users authenticate and request tokens. And then once they authenticate and they get those tokens, once they authenticate rather, I send a token from a security token service back to the user. And then now the user can use that token or that, yeah, that token. It could be a JOT token or any other kind of token, a JWT, because people have these arguments that is either pronounced as JWT or JOT, I call it JOT anyway. So it could either be a JOT token or any other kind of token sent back to the user. And the user can present this token to the service and that can give them access to certain things in that application. So there are different use cases for this federated identity pattern, single enterprise sign-on, if you have multiple partners and if you're building software as a service application. So this is an example for using the federated identity pattern in a claims-based access control scenario. And imagine a SaaS application that is also as a service application by a tenant company that is using this federated identity pattern. So I trust this provider and basically I can get a token from this provider and then use the claims to access whatever resources and this helps me protect myself from certain scenarios. So even within a company or even within different providers and stuff like that, it's like, okay, this tenant is different from this other tenant and things are groups like different tenants and stuff. And basically if you present a token that is not for my tenants, I can basically kick you out of accessing my resource and stuff like that. So I have talked about three patterns. So now I want to talk about other ways that you can enforce security. The first one is using multi-facto authentication. Recently, I've been getting a lot of emails from different things that I'm signed onto that ask from this dates, we are going to be moving to two-facto authentication or multi-facto authentication. If you've already enabled multi-facto authentication on your account, you don't have anything, you don't have to do anything or perform any action. But if you've not, before this date, please go and enable it, blah, blah, blah, blah, because passwords are not enough these days, right? People have been hacked, they've been in a lot of security breaches in lots more recently than before. Also with this whole remote work and everybody being at home, we have to find a way to secure ourselves a lot more than we did before because now we're no longer in physical buildings in our offices where there's like, oh, intranet and it's like secure and it's shared and all of that. We need to find new ways to make sure that we secure ourselves and we secure all the things that we're doing in the context of the work that we are doing. Implement just-in-time access for resources as well. So JIT access is like, on a normal day as a cloud engineer, you don't have access to cloud resources, production cloud resources in your team. But let's say you are an on-call engineer or you want to make a particular update to your application, you can request just-in-time access and then an admin grants you that access with certain privileges. So if you request just-in-time access for write operations, an admin grants you that access so now you can perform write operations in production and then maybe after like a certain amount of time your access is removed. So that someone else, you know, or at least another entity is aware that you are requesting for access for a particular thing. Not that everyone just has access and then people can mistakenly do things they're not supposed to do. You know, use stable authorization and authentication platforms as well. Require re-authentication for some actions that you know, if you are performing financial transactions, for example, if you go to an AT&T today or if you're even using your bank app or something and you want to transfer money, even if you've logged in with your password, right before you do, you're required to, right before you make that action, you're required to pass a token or a PIN or a password or something like these things actually help to be sure that, okay, this person is actually the person using this thing and I'm authenticating them twice to be sure that they are the ones and they know what they are about to do before they do it. Cause once you do things like this, nowadays things can be reversed but they take a very long process and sometimes even to an extent, some of these things cannot be reversed, right? Reduce your attack surface. Your attack surface is basically the different areas in your architecture, the different areas in your infrastructure that you can possibly be attacked. So if there's, or rather, the different areas in your infrastructure that can serve as entry points for attacks, yes. So basically, if there is a VM that you are not using, go and delete it. There's no reason why it should be there. If there is like, you know, storage or anything that you're supposed to be using that you haven't used in a long time that you don't need anymore or anything like that, go and delete it. Like make that attack surface because what happens to us as human beings most times is we're not using some certain resources. We don't pay as much attention to them and over time they get outdated and they become more vulnerable and then this can become problematic. Properly handle errors and exceptions for, you know, instrumentation and proper telemetry so that you can track what's going on, monitor your services as well and trigger alerts about issues. For example, apart from issues like, oh, this service is not working, there are things that you can trigger alerts for. For example, people have been deploying code over the past like three weeks but somehow people tend to stop at the staging infrastructure. There's been so many changes made and so many code has been checked in over the last two weeks but nobody has gone all the way to a production deployment. You might want to trigger that as an issue because the day you finally do that you might be deploying changes of like five weeks into production and that might break something and there might be an outage. So you might want to trigger these alerts as well to make people not just know about, you know, the health of your service but also not just know about the latency and speed and all of that but also know about the health of your service and things like that. Encrypt sensitive data in transits and at risk and at rest rather. Implement failsafe measures so that if your application is actually failing it's failing gracefully and consider threat modeling. Threat modeling again is like a thing where you can defend yourself before you actually get to the point where you have issues. And it's just like, you know thinking about your application and thinking about the specific kinds of threats that your application can have and, you know, thinking of a way to combat those threats before they become actual threats. And there's this framework called, you know the stride framework where in stride there are six different kinds of threats. So if spoofing attacks can be a possible threat in the application that you're building that is an attack on like, you know, your authentication and you might want to enforce things like HTTPS connections to make sure that doesn't happen. If, you know, tampering is the threat it is a threat on, you know the integrity of the software. And you might want to use user valid SSL or TLS certificate. If repudiation is the threat you might want to think about enabling monitoring and proper instrumentation. If information disclosure is the threat that's a problem with your confidentiality and you might want to encrypt all of your data in transit and at rest again you don't only encrypt data at rest. It's also important to encrypt data when that data is moving from point A to point B. If denial of service is the threat that is an availability problem. And you might want to enable monitoring and proper instrumentation. I use the example of, you know deploying to staging for like five weeks and then you finally go to broad, it breaks. So you might want to make sure that you don't have an availability problem. So enable proper monitoring so that you know when these things are happening and you can combat them quickly. Also things like, oh, this particular storage token is about to expire. This password is about to expire. These are things that you should also do monitoring and instrumentation for so that you know that they are about to expire a month before they expire and you can, you know, request to get a new one as opposed to it being expiring or rather as opposed to it expiring your application being like, you know out of service for some minutes or hours before you fix that problem. If the deviation of privilege is the issue authorization is the problem. And then, you know using security identity management is a way to combat that issue. Other things that you can do use secure libraries obeyed service dependencies to prevent vulnerabilities and avoid had coding secrets in your code. If you want to learn more about how to build secure on how to design and build secure cloud applications you can take a screenshot of this because these are useful links that you can check out. I would also tweet these links so you can check my account in a few hours on Twitter. I should have tweeted them by then. I feel like I am past time but I apologize for that and also thank you for listening to my talk. I hope you learned something. If you have any questions you can ask you can tweet at me and I will respond to your questions. Thank you. Oh yeah, you can also ask me questions in the chat. I didn't realize I'm just seeing that. So yeah, if you have any questions put them in the chat and I will be happy to respond. Thank you. Awesome, that was an interesting session Adora. I think everyone was actually into it. Most of us didn't actually know when it was passed away for AD. We don't have any questions yet but if you have any questions like Kershi mentioned you can tweet at her, Twitter handle is at Adora and Waldo. She's very, very active on Twitter so you can, I'm very sure you get a response when you ask your questions.