You. Hello. Hello everybody, and thank you for my session. My name is Radhu, Radhu von Foleya and for the next 40 minutes we'll talk about security. We'll talk about security best practices inside Microsoft Azure. There are a lot of things around us, and sometimes it's very easy to lose between different information or finding the right one. What I want to aim in this session is to share with you some things, some lesson learns and best practices that I identified that are relevant and can have a high impact on your own projects that are running on top of Azure. Some of them you might know, some of them you might know, but because of lack of time or team capabilities, you might not put so much effort on them. And I would like to highlight what are the top 13 security best practices that I consider relevant and fit very well in an application that we are building. We are running on top of Microsoft. On top of Microsoft Azure. Before going forward, I would like to share with you a code of Gibran that I think that is very relevant. If you reveal your secrets to the wind, you should not blame the wine for revealing them to the trees. In this context, we must be aware of that. The most important thing, the most relevant thing is that the wind, it is us and it is up to us what we are sharing, the level of security that we want in place in our Azure, inside our Microsoft Azure application. So it is up to us the level and the features of Azure and other technologies that we want to use to improve the security layer of our systems. Next, let's talk about some statistic information that make us aware of where we are now and what are the most important things that we need to take into account at this moment in time. Around 80% of security breaches involved privileged credentials, meaning that we have a lot of people inside our teams, inside our organizations that have more rights, more freedom that they should have inside the systems, inside the application that they are involved directly or interlocking. And the best example here is if a product manager needs to have access to an environment, to Azure services, to the code repo or to the pipelines, if he's not doing tasks or things that are related to that part of the system, does he need access to it, except maybe Azure DevOps dashboard or jira? I don't know. It is up to you. But we need to consider that going forward. We need to not forget that around 49% of the databases are not encrypted, even if we have a strong password. Who needs to be aware that a backup of a SQL database can be cracked. In 2016 I was joining Microsoft Techhead in Chicago, and in a 90 minutes session one of the security specialists from the market showed to us with tools that you can find on Google, how you can break the backup, how you can change the hash of the password and after that to access it. So it is important not only how we are setting different credentials, but also how we encrypt the data, the backups and where we are storing it. 25% of organization have cryptojacking activity with their environment. One four people, one four organization were involved directly or indirectly. We might not know it that one of our colleague machines were hacked, were cryptojacking, but we need to be aware of this because this is highly risky. And one of the stories that I really like to talk is about VIM, that a few years ago had the data breach not of their data, but of a backup with some customer data. So a backup of around 200gb data was stored in an AWS S free storage and was made public, available on the market in an unscrew way. It was available for a few hours, but was more than enough for a few of few of the guys from the Internet to download that backup. What happened with that backup? We don't know, but the backup was not encrypted and was available on the market so somebody could put their hands on the information. Officially it was just customer data that were not very important, but still that backup is very important. The same story could happen on an Azure storage, so it's not important. The cloud vendor or the company could have a pump, but it's more important to be aware that we need to take into considerations all the aspects, because in cloud everything can be paid publicly if you don't have the right policies and the right governance layer on top of your services. Now it's a good moment in time to present myself. My name is Radu Radhuvale. I'm group head of cloud delivery for Endava. My journey on cloud, more specifically my Azure started in 2010 with the first commercial project that went live I think in 2011, and from that on I was working, playing and enjoying the journey of cloud. I have a pretty good experience on Microsoft Azure and also AWS. I'm Microsoft Azure mvp and regional dive rector. There are two more things that I really enjoy. Coffee. I have around ten machines, ten coffee machine, I have around ten coffee machines and I really enjoy playing with the coffee, doing different types of coffee each day or during specific time of the day. I'm a big fan of home automation doing the harder part, but doing also the different automations to reduce the consumption of electricity or improve a little bit the way how you enjoy the working from home. What is agenda talking? A lot of things about different cloud, different azure services and ways of working. And let's start with the first thing on the agenda that we need to not forget. Most of the technical people are aware about shared responsibility model. Nevertheless, at management level, at project management level, sometimes the leadership has the expectation that once you go to a cloud vendor, once you start to use the services of a cloud vendor, most of the things will be the responsibility of the cloud vendor, not of the technical teams. So they forget to invest into programs, into efforts to secure and to harness that system. So talking about shared responsibility model from the cloud security point of view, we need to consider that is a general responsibility. The CSP will offer you the security foundation of the physical assets of the data center operation and of the fabric that is behind the infrastructure. Now it is up to us, it is up to the customer, to the technical team to ensure that we have the right network and VM security layer to be sure that we have the services and the functionality in place and configured aligned with our own needs to ensure that our apps and workloads are running in a secure way and the data is stored at a security layer that we expect. Security level that we expect. Now, what is the first thing that we need to take into account? Talking about security, there are four pillars, networking, operation, monitoring and cloud platform. On top of that we have storage, we have data, compute and identity and access management. And of course of that we have the application. Depending on the way and how we are consuming services, how we are building the application, this part b, these things might be in the scope of us. If you have an internal application that you are building from scratch, if you're using a software service or you are paying a subscription for different services, some of these items might not be in your own responsibility or might be less. And things like the API and the CI CD, the same story. Having all this landscape in mind, we need to consider how we are securing the storage, the data, the workloads and what kind of identity and access management we are using. Talking about the secret and access management, it's very important to have a policy and a way how we store the secrets where we are storing. It's not enough to say I'm storing them in the repo where you will store them in the database, what kind of encryption you will use on top of that, because in the end you can have the most secure application in the world. But if you don't manage the secrets in the right way, and if somebody puts their hands on the secrets on your access token, to your database, to your storage or to something else, they will be able to get the data, they will be able to stall the data and to sell it on the black market. So it's very important to know exactly how you lock the system, what are the services and what is the layer on top of it. We have access keys, we have connections, there are so many things that we need to be aware. And sometimes there's a break between infrastructure people and development people, because one of them are doing the full configuration of the infrastructure, the other ones are building the application. And if you are not having the right policy for secrets and configuration management, you can miss some things or to be stored somewhere else where they are more visible, more sensible to an attack. Everything is a configuration, but it's important to know exactly where this configuration is stored. So what is cloud vendor is offering for us? Azure key vault. The keyboard on AWS is AWS KMS. What is a key vault? In the end it is a storage, a secure storage where our connection strings our certificates, our keys and our secrets are stored, are stored in such a way that nobody can access, see them in clear text without having the right access to them. Once they get the access, well, it is what it is, but if you manage them correctly, you can ensure that that storage, that key vault as a storage for your secret, will not be accessible to anybody, depending on what kind of compliance you need to have. Azure dedicated HSM might be an option. It's like a key vault, an Azure key vault, but a hardware dedicated only for you and works pretty nice. Now one of the problem with Azure key vaults and with the key vaults in general is how you manage the access to them. And it's important to remember that at the moment in time when you are accessing the key vault, also the credentials or the way how you're accessing the key vault are very important. Usually when you access the key vault. Let's go back. You need a client id, a client secret to be able to access it. Be very careful how you are stored them, especially on dev environments, dev test environments, and to have a clear separation between the instances of the key vaults that are used for production or I wouldn't say not only for production, but for environments where you have real customer data and the one that are used for testing, for development and so on. Now, keyword give us the ability to store the client id, client secret and the tenant id inside the environment variables of a machine. It's a very smart way to build a development machine because even if your computer, your laptop installed, if that person doesn't have access to your windows user, he will not still be able to get access to the client id, client secret and will be very specific to each user that has that access. Of course, from the code you can retrieve them and you can use them without any kind of problem. Everything is built on top of role based access control. Azure role based access control give us the ability to access not only keywords but all Azure services and much more. Not using a username and password, but basically on service principle. Meaning that if a virtual machine, if an Azure functions, wants to access an Azure storage or a SQL database, Azure SQL database, you will not need to use the username and password for no, no, based on a role based access control, that Azure function will be able to do an automated authentication and authorization based on his service identity. No credential needs to be stored. Everything will happen behind the scene. Yes, the initial learning curve and the initial configuration from the effort point of view might take a little bit of longer, but once you have the system configured, you are much much safer than using a token, than using a username and password and similar things. There are four items that we need to know about role based assessment control. It's starting to be used more and more, but I would say that we are still not there yet to say that fully. Most of Azure customers or most of the systems are built on top of Azure are using role based control. So there's a lot of work behind it. There are four items that we need to consider. The service principle can be a user, can be a group, can be a service principle like a VM or an Azure function. We have the role basically what kind of operation you can do to a specific service and the scope like Azure skits, Azure SQL, like Azure storage, and so on. And you do a role assignment where you specify that that Azure functions will have only read operations on that Azure SQL. And more than that, you can specify exactly what are the tables that it can access. So even if somebody would hack your Azure functions, he will still be limited to do only some specific operations on specific tables. So there are a lot of things like this that you can use and one of them that is very very important is role based access control. It's doing duty segregation for the team and also for the services that you are using. You can limit it and to specify exactly what are the permissions and also you can avoid to specific exactly based on tokens and things like that, what are the operations and so on. Now the second thing that I would like to talk about today is repo and cloud secrets. Now repo and cloud secrets are something that we already used with it and are very important because nowadays when we are working from home, it's very easily for our dev or DevOps hero or our test hero to click on a link to have his machine compromised and a bad person from the Internet to get access to the application repo to the infrared repo and worst to have access to the Azure subscription. We need to ensure that we have the right tools not only to secure their machines, to limit their access, but also to ensure that we don't have any kind of secrets inside the repo, inside application, infrared repo and so on. One of the best way how we can do this is to use tools like git secrets. What does git secrets do? Basically it's allowing us to scan for everything that is pushed to the repo or through a pipeline to ensure that there are no secrets and to refuse secrets like for example an Azure storage account key or username or password of the database to be pushed inside the code. And the code can be the terraform script or an arm or for example a C sharp or Java code and so on. Now secret scanning can be done very easily. Git secret is one of the best example how you can configure very easily. You just install it, specify exactly what kind of plugin for different cloud vendors, and after that you just scan it without any kind of hassle on top of it without too much effort. One way how you can do this is each time when somebody do a commit you can scan it. If you identify a secret automatic, you can reject that commit and nothing more than that. There are a lot of tools on the market and I would say that there's not the best one that can fit everything as you can see here on the screen. I share with you some of them with what are the pros and what are the cons or the things that I consider them very relevant. And I would like to highlight two of them. The first one is git, all secret, GitHub secret. It's great. I really enjoy the tool, especially for learning internship and why it's so easy to configure. It's so easy to show and to learn how you can integrate a CK scanning tool inside the system or the value of it. The downside is that it's more like an MVP. The configuration is very basic and once you go deep and you want to have different rules, different fluffs like that, you'll not be able to do it. On the opposite part, we have spectral Ops that has a great UI. So the user interface I really enjoy not only for the technical people, but also from the reporting point of view for a project manager or a senior account manager has a very strong ML mechanism and the number of false positive number is reduced a lot. That's great. It's pretty complex for small projects, doesn't fit very well. But if you're working for a large project where let's say we have two or three or teams that are working day by day on the same repo, on the same project, or from the same program, spectral Ops is something that you need to consider and to take a look. Spectral Ops, it's not free, but it's a very good value for the money that you are paying for it. Okay, let's talk about configuration, application configuration, because this is important. Where we store this configuration, we talk about key vault. So we already have a repo for your secrets. We talk about Azure role basics control. So we already know how we can access the key vault or other Azure services from our workloads, but where we can store the rest of the configuration. The application configuration application configuration is very sensitive. Even if you don't store secrets, it can reveal a lot about how you are building the application, how you are communicating with different components, different configurations that once they are changed might affect how the system would work. A very good example here is the logging and audit level because somebody once is hacking your production environment, he might say okay, if I have access to the configuration, let's put it to the verbose mode. Even if I don't see any relevant or private data, I will still get the flocks from which I will understand exactly how the landscape looks like. To understand better, how can I attack more that system? So key and secrets different from application settings is very very important. And also the role management who get access to what? One of the things that we have available on the market is systems like application configuration and are very very useful because for example for an application we have the backend, we have the ETL, we have that main layer, some recurrent jobs and we have the API app. Everything goes well for each of them. We have different configuration, keeping them in different locations. Well yeah, you will say it's a lot of duplicated content and sharing across different teams and different roles. It's not easy and it's hard to maintain. Yeah. Nowadays in most of the cases we have a central repo like for example Azure app configuration or AWS app config that works very nice. And the main purpose of them is to push all the configuration from your application, from your configuration in only one place. And that's awesome. On top of it we have a very strong integration with Azure keyword. And what does this mean is that for example for Azure app configuration, and let me show here, because it will be more simple, we have the app, our own application, we have app configuration and we have key vault. If our application needs to access a configuration based on role based access control, he will be able to access app configuration. Now what we can have in the configuration, we can have a reference to a secret, meaning that if our application needs to access a keyboard value, for example a secret, he will go to application configuration. It will require it. But because we have here a reference for our system to be able to fetch this data from the keyboard, a role based access control needs to be configured and it needs to have access to that value. So if our system is hacked and somebody is getting access to application configuration, it will not be enough to get the secret because also the system needs to have access to the secrets themselves. And depending on the component that we have here, each component might have access only to specific secrets and keys and certifications from keyboard. So it's another layer of security that we add on top of that. Storage desk management I think is one of the primary, one of the most basic things that is part of all cloud services of all Microsoft Azure. And we are forgetting, and a lot of them are still seeing projects that are using account name and account key to get access to storage. That's bad, that's very bad. We have so many other options that we can use. Azure SAS based on signature goes very very well. If you need to provide temporary access to a third party to your system or to temporary access to another external system, and you can generate a shared access signature for a short period of time with only specific rights. For example, I get you access to that file for read operation for the next 2 hours based on the ip that you are using and nothing more than that. You can generate that access key on the fly. It's limited availability. What I highly recommend you to do to have these keys, sas keys with a very limited lifespan if it's possible. Five minutes, ten minutes, 15 minutes, don't forget. It's very cheap to get to provide another key. If you need to provide long access, for example to services, to system and so on. Don't use accounting key. You have Azure role based control that can be used all the time. And don't forget about the firewall rules that are part of Azure storage. I usually call them like Windows XP firewall like because basically you are just whitelisting the IPS. But it's very useful because you can limit very easily at least the public ips that can access your storage. It's one step forward. It's another layer that you are adding on top of your system. Sql let's talk about Azure Sql. Yes, except accessing them through username and password we already talked about. And we know that we also have other options we need to take into account that we need to encrypt the data, the backup we have the firewalls and the ip for the rules. And please try to have a clear policies how you're updating the IPs that can access the database. If you are just adding ips, adding ranges, it will doesn't work because in the end, especially if you are working remotely and you add the ips of each person that is working and not the range of IP that is used by the company or by the team from that city, you might be hacked very easily and also use as much as possible authentication using identity tax and management. We have the ad, we have the role based access control. Now on top of all object level permission, there are two main features that I would like to talk, but before going to that I would just want to highlight the treat detection system that is available on Azure SQL and can detect behaviors that are not normal or are not happening normally to your database and can give you a notification, can alert you or you can define a clear policy. What should happen in this ended case. Now column level encryption. It is another core service of Azure SQL. And what does this mean? We can specify that for a specific role we will have column with hidden value or for example with a default value or random value and very very useful. For example, if the support team needs to access environments, I don't say production environment but environments where you have customer data. So you can ensure that somebody, for example from support, even if needs to get access to the database, he will still not be able to see a specific column where you have sensitive data. You can have all the column except the id or even the id randomly depending on your own needs. At the same concept you have cell level encryption that is on the other dimension. You can decide exactly what are the cells that will be encrypted and will have some default values. It goes very well when for example, you have teams that needs to provide support and you can have some rows in your database, in your tables with maybe negative ids that are used only for, not even by real users, only for some smoke best or some tests that ensure you that the production system works as expected. Endpoints, web endpoints, best API and APIs are part of our life. I think that let's say 99.99 of the systems are providing APIs that are public available on the Internet or for private consumption on which they're exposing data, functionality, business and so on. Now we need to validate, we have a lot of parameterization and we encode it and we already know about oaps and all the best practices, but we need to build application with all the functionality that is provided also by each cloud vendor. And just give you an example, the OAS protection or to avoid SQL injection or for example lidos attacks and so on. We don't need to rely on the application that we are building. For example, Azure application gateway is offering us WAF. It's a level seven load balancer with a firewall built inside that that will protect us from oops, attacks and many more. So we are moving, we are externalized that security layer of building internally to Azure application gateway to an external service. What is the benefit? We can focus more on the business. We can reduce the workload on the processor and just focus on the things that we care, the things that are generating business and value to our customer. We have also Microsoft Defender for cloud and we need to, I have a typo here for cloud that is giving us the ability to do active scanning of our cloud infrastructure, on our Azure infrastructure and automatically can detect when we have misconfiguration, when for example, we are not complying with a specific compliance that is required. For example, Microsoft Defender can do active scanning of PCI, DSS 3.2, level one, basically adding infrastructure layer. And when we have a misconfiguration of something is not configured as it should be, it can alert us. It can even provide us recommendations or sometimes, and I will say most of the cases above them, that when we click it, it will automatically fix the problem for us. We have a security scoring, we can do inventory and many more. And additionally to this we have Azure advisor. This is not only on security, it's also on liability, performance, cost and operational excellence. So why I'm saying this? I wanted to highlight the cost because Azure advisor can provide us recommendations related to how we can optimize costs based on different patterns, based on specific tiers or number of instances that we have allocated, but we are not fully using them now. What are the conclusion? We should remember that we are the one that are responsible to build secure application inside Microsoft Azure. We have all the right tools to make and to grow secure application. We have a lot of security features, services we don't need to install on on prem, a lot of system it is at the distance of a button, but we need to be aware of them and we need to configure them and we need to consider all the features that each cloud vendor like Microsoft Azure is providing to us. I would highly recommend to take a look on sky high network. They have a great cloud security blog where they have a high level guide for Azure security. What are the most important thing? And they're covering seven categories like security policies, identity and asset management, storage account, SQL networking, vms and Michelle like for example subscription, something like that. Just take a look. It's a very good starting point. And don't forget about best practices and recommendations that Microsoft is providing to us through security, best practices for Azure through cloud adoption framework and WAF that also you'll find similar ones for other cloud vendors. Thank you. Thank you for listening me and if you have questions, feel free to reach me over LinkedIn and Twitter or Twitter. And why not? Let's have a virtual or physical coffee next time. Thank you and have a great day.