A Developer's Guide for Building Zero Trust Ready Apps

afternoon everyone uh my name is kalyan krishna i'm a product manager with microsoft azure active directory or microsoft identity division i uh welcome to my talk i work very closely okay let me first fix this is because it's not really presenting the way i want to is it yep thank you thank you for coming to my talk i am going to talk to you about what zero trust means for developers and before i get started can i get like a quick uh idea of how many of you are like developers or work with developers can i see some hands okay so that's great and uh how many of you are into let's say application management like integration

monitoring okay fair enough so those are like the two uh primary audience personas that we basically want to address with this and uh so let's get started so uh zero trust has been around for a few years it got a lot of traction over the last one year or so and microsoft is doing all it can to basically make sure that our products our educational material our documents our tools essentially help you those who are who are looking into it or basically rolling it out one of the things that we heard back from our customers was essentially that the developers did not really figure out where their role was whatever they're supposed to do and and then we decided to basically

carve out a part of what microsoft's recommendation is for developers and i'm going to present some of it to here zero trust is a vast area we cannot do it in a single session but we will give you enough pointers so you can go and basically follow up and uh with the necessary uh idea of how to go about it so to start the session i'm basically gonna just start with a quick entry to zero trust i'm gonna assume that most of you are familiar uh it's again a topic in itself uh then we would cover touch the the important topic that basically started the conversations of the initiative in microsoft it's like how i does it

actually matters for developers and then i will share a few nuggets of recommendations for developers on what they need to do what is their responsibility what are the things that their application should follow in a year to make sure that their zero trust ready app and we'll give you some pointers that as a developer as an idea admin as an application administrator you should be able to follow up to basically get our up-to-date guidance on on what how developers should indicate zero trust in their application so yep uh before even i touch up on uh zero trust and what it is uh this is the first question that we all get at least from where i i said is like hey we have

been following the security development life cycle or a synonym of it in our organization for all these years so why why follow zero trust and the answer to that is that if you have been following those you have to understand first that zero trust is not a replacement for everything that you have been following today okay so if you have security fundamentals like threat modeling code reviews pen testing they stay there okay all we do have done under zero trust is that we have re-evaluated the security practices and basically aggregated them into a certain bucket and you will see that as i go through these and if you go through our entire documentation there isn't exactly a lot

of new stuff it's essentially a reorganization of a lot of things that as a developers as practitioners you have been following but you have to basically pay more attention to because the the perimeter has shifted you are now using a cloud and lateral movement is actually something that we see a lot happening okay so the primary motivator for zero trust in general and that also applies for developers and it actually hits developers very hard is that the culture of implicit trust has to give away to explicit verification what does what do we even mean by that there was a time when a developer you would develop an app you would put it into your apps a company's network

and maybe you integrated with windows integrated author maybe you had your own customized implementation and it was all good you really didn't worry about it that somebody would come in into your network you had firewalls you have all the security teams in place to make sure that things don't come from outside and things more or less worked and developers really didn't have to do a lot of these thinking themselves then cloud happened your applications now stay in azure and aws and gcps your app is what an attacker basically uses to start their compromise they'll move laterally so if your app is the weak point that's where the attackers will stop and that's where the developers are being now asked to

essentially look into the zero trust model the zero trust practices a little bit more carefully you cannot just assume that you have developed your app you have done what your business wanted you to do and you have some basic center sense of authentication and authorization and it's all fine your basic sense of authentication on authorization is what an attacker would actually use to see if they can get into the network get into the cloud and basically start their attacks okay and this is why developers now have to basically start looking into zero test principle a little bit so what are these principles i'm gonna cover it again for you for those who are new so essentially zero trust is made up

of three principles the very first principle is verify explicitly which essentially says that if something hap if something is accessing a resource a simpler way to explain if somebody is going to use an application before they can get to that application make sure that you authenticate authorized based on all data points user application device identity location device self-service and workload and classification and anomalies the good news is that it's not a developer's job but i'll explain later okay the second one is use least privilege access it has remained as a practice for a very long time it's essentially about hey if a user signs into their application do not just assume that every resource on the

hosting server or every resource on the network or every every every access to the data should be just assumed as something that that that gets to every user account you have to think about hey if a user signs in if your user logs into an application if an application is making access to some data they are just getting what they need and nothing more than that if you don't have those practices in place you would be your your your application your your authentication's education session would be used to get uh a lot more done uh than than what you had assumed for example if your application all it needed to do was to read a lot of

data but if you have those permissions that where they the application can unintentionally write data when your application is going to be breached or attacked that's the thing that you weren't prepared for but the attacker will make use of third is assume breach and this is something that comes as the biggest surprise as a developer what zero trust says actually it basically applies to every practitioner you can no longer work with an assumption that your application cannot be breached you have to prepare your application you have to deploy it you have to run it you have to monitor it in a way where you are able to recover your application get it back online after a breach has happened

it's kind of counterintuitive but the problem is because we don't want the breach to happen but unfortunately it does happen the worst part is not that what happens after the attackers do the the worst part could be hey you are a consumer site with millions of users and you are down for hours maybe days maybe you cannot even recover because your data is now in the hands of a ransomware so you have to as a developer make sure that you have the necessary uh mechanisms in place to recover from a breach when it happens as a developer most of most probably you would not be really you know be aware of when a breach happens is

more of a i.t security thing but when it happens if you have done some proactive steps it will really help them to recover your application make it online uh much quicker so that's your zero trust and as i said if you look at the verify explicitly part of the zero system most of the hard work is actually done by the identity providers if you're using azure active directory google or tapping they will do the most work of making sure that the anomalies the the device detection the device compliance and all these things are taken care of usually as a developer the first thing you should do is to make sure that you shift the authentication

parameter from your application to an identity provider do you have your own login screen you are going to be attacked you are actually a very very uh nice looking target for an attacker the moment you move it to an azure active directories of the world your application does not play that big of a part because the attacker now has to attack a very robust authentication system so most of the things that you look here that we talk about especially in the verify explicitly part of it will be taken care by the identity providers i i as long as you are integrated with them you have done the first and the best part you have taken care of the best part

already okay the next thing is uh it's essentially for my developers again we keep getting asking a little so why should you bother to get your zero type flap ready now that i've explained a lot but i'll give you some very unique examples uh sorry clear examples and the common examples of why we keep hearing about it and why you should bother about it so number one is the i.t is rolling out zero trust what do we mean by that because when the zero trust practices and guidelines started to get rolled out somewhere i say mid last year like in a big way it was for the it administrators even today like i would say 95 99 of the

guidance and steps and work is for the i.t administrators to do when they roll out they cannot always succeed a lot of things you know setting up firewalls you don't need like developers there for the most part but there will be certain steps where if if the it admins cannot succeed in rolling out if the developers have not prepared the app for it for example if you are enforcing mfa or if you are using ip addresses to blo or block traffic from if you are enforcing user compliance they do not always require participation from developers but there are some steps and i'll cover those right in the next slide which will not work out unless the developer has put an effort

in it the most common place where this happens is credential rotation you are using secrets you are using certificates breach happens something bad happens the iit administrators the security tools that your company has purchased and used they should be able to rotate those credentials mark them as inactive remove them without the app going down it actually is quite easily possible with a little bit of an effort from a developer a lot of developers don't even look at it you're like hey i have a secret in my config file i deployed and no you don't put a secret in a config file because that cannot be rotated it should be somewhere like an azure keyword or some

other security system where it can be rotated easily by the it admins without your application getting affected next mfa so if if an identity provider again azure activity octa ping is throwing out an ffa challenge and they will do it not just because the application is integrated or the policy says that every authenticated session should be in mfa there is a lot lot of risk based mfa between the session i take this laptop i go to another network the next time i'm gonna i try to access the app azure id aquatic depending upon the policy he said no you need to do an mfa again because i the policy dictates so in these cases applications break

because they get what what's called as a challenge from the idp they are they are coded to integrate for authentication which essentially means i'm going to send a user back to you you send me back some tokens when it happens the other way around when the azure id says nope i'm not going to send there is a special challenge that you need to do it's all uh rfcs and you know standardized but but this requires a little bit of coding effort from the developers as well the third one is a little bit of microsoft specific how how many of you are familiar with microsoft graph okay so microsoft graph essentially is the api behind which most of an organization data sets

think about all your users all your security groups all your policies all your data sharepoint site teams channels one drive everything sits behind it now microsoft graph has a permission model i cannot cover it in this session but sometimes if you have let's say an application that reads uh data from microsoft graph and all it needs to do is to let's say read a bunch of security groups but let's say there is a permission called directory.readwrite.all if an application has that permission that basically can destroy an entire azure id tenant if they wanted to they can make any easily so if your application is is coded to ask for permission like directly or rewrite or

all when all it needed was security groups dot read which is a much lower privilege permission then the application is going to be a good vector for attackers so in these cases there are tools now and there are iit administrators who are basically getting very careful about what permission and application request on the various apis behind which the organization's data sets and in those cases as a developer you should be looking at hey i'm not going to take the biggest permission out because developers have that mindset if i'm on a laptop i should be an admin and well you need to be an admin to develop i agree but in a production your application might not need to be an

admin it just needs the exact set of permissions and the privileges to actually get its job done and that mindset had to be developed because a lot of developers don't get it very easily unless they run into this consent problem that we call it okay this is something that came out as a surprise but we saw that we basically rolled out deprecating the basic authentication it's one of the protocols that's like super popular out there but it's turned out to be mostly quite insecure and we started asking developers to move to something like saml and open id and oauth if if you want to switch off basic authentication across your organization your app developers have to at least

stop using it first okay so these are good cases some cases on where as a developer you would start to look into why your app should be zero trust ready is because uh reasons like this and more would would affect you okay i'm just gonna stop here is does anybody have any any similar initiatives or as a developer you have run into some some of these things or anybody wants to talk about it it's all new

we've configured ews

is

so just to repeat what the question here uh he has third-party applications and please correct feel free to correct me if i'm wrong third-party app which basically are using aws which is the exchange web service which uses basic auth and it's super popular as well and ews has been trying to actually deprecate basic auth for a very long time they want everybody to move to the microsoft graph and open id that's question number one question number two is you have all these applications that you have in your azure id tenant to be specific and they have a bunch of permissions with microsoft graph and you're looking for a permission view of what it is okay so

i'll answer the first question is that it actually is time because about four days ago i actually did a session on twitch on how to move from ews basic auth to azure id sorry microsoft graph we i'll share the link if i can find but if you want to look into it we have a two part session one is how has an id admin you can find the applications and what you need to do and the second part is essentially how as a developer what do you exactly need to do to move from basic or ews to microsoft graph open id so both both are available the second one which is essentially hey can i have a view of permissions it is

something we previewed about three to four weeks ago unfortunately you might not find because azure active directory got renamed to microsoft entra so if you look at microsoft if you do a web search of microsoft entrap permission management it has started to roll out some of those visible you know visibility on what exactly is the permission set today that's being used what you have asked for is actually one of the two top ask for my with microsoft graph today number one is that we don't have a any request logs for microsoft graph usage which is something that a lot of the i.t admins and developers find frustrating and the second one is hey there is no visibility of how many

applications and which permissions they are and can we get so we have we are rolling out a few more things apart from permission management hopefully in future things will come to a point where we can tell you can generate a report which says that this application has these many permissions but never uses more than you know it has 10 permissions but only uses two so you can go and ask the developers that i can i get rid of this other eight is because you're unnecessarily over permission so but but it's coming it's not there half it's basically started to roll out just just

so that's exactly what we want to do is if a developer said hey i need these 10 permissions or the app breaks there is very little an id admin can basically have are you going to specifically look at every line of code and every api call it's not really possible so what we are working on is a report that essentially says that this application over the last seven days or a month has only used these permissions so this is the least amount that they actually need of the consent that has been provided for the entire set so but it's gonna take some time it's something that we are really very actively working on uh and and uh we hope to make it available

it's a very well known problem we know it we are working towards it but it basically requires going through a lot of data and that's where things get a little slowed down when we try to bring it to you thank you any other questions observations okay cool next [Music] so basically i had covered it like as an introduction so it goes beyond id policy you know it's earlier code security was mostly about hey i write my code i write it properly it's if you deploy it on cloud if now it's security your application can be the the attack vector that that attackers would use to basically make a lateral movement so it's not just about

your code anymore you have to as a developer rise up and basically embrace a few more practices and this is why it has become a practice that we want developers to start looking into so how to make zero trust apparently now i cannot go through all of it uh it's a huge it's not a huge but it's a substantial amount of information uh the but the most before we start talking about the various practices i want to call this out is that even with developer space the implementation is evolving uh so i'm gonna share the links where we microsoft publishes the latest bids uh please make it a habit or you know to go through

there every three months maybe and and to make sure that you are up to date with the latest guidance that we have out there so the very first is the zero trust guidance center so this is an overall guidance center for uh for all of the zero trust work that microsoft has out there there is a part that we have started to develop for uh sorry developer developers itself so that's that's the link to this uh it's a big long one but that's what it is uh we have an ebook that's available if you want like specific things things that i will cover in the next few minutes uh that you want to go through if you want to print it

out and give it to your developers to follow through that that's available on the second link so it's more of a developer guide it's written exactly it only has things that a developer needs to do and and and and basically it's completely different if there is nothing that in that the right items this is actually was an ask is because as to repeat myself uh 99 of the guidances for it admins and developers get confused so we made sure that it's taken out and just printed so that developers can basically just focus on those bits that matter to them and nothing more okay so again we will cover a few common and critical recommendation there

is a little bit of microsoft specific features here but usually you would find it useful for the uh for the on essentially to understand what direction i am or what what actually i am trying to convey through the messages here so we will start with a general guidance for applications i will discuss one specific feature called continuous access evaluation uh that we have brought up and it actually to address a very the verify explicitly zero trust scenario some guidance for mobile applications uh what exactly is that that we are talking about about least privileges microsoft graph i'll just cover that out how do you adopt credential hygiene and why should as a developer you should be looking at your logging

and telemetry it's a very common thing to do you know all applications have logging mechanisms but do you log enough for your it admins to essentially recover from a breach again the guide has more so let's talk about verify explicitly so verify explicitly again as i said most of the work would be done by an identity provider but as a developer make sure that you are using an identity provider do you have your own username password database do you have your own login screen you are an open candidate your application is an open candidate for attackers it's as simple as that we really have no other explanation here we don't have one of attackers today we

have state actors we have departments run by countries and if you i mean again let's be honest as a developer there is only so much you can do if you are handling credentials yourself today okay so use a modern protocol these have a very amazing thing that most developers miss when you hear about it when your application is using open ido author saml your application never sees a credential it never gets to see the actual password that the end user typed the primary mechanism of the modern protocols is send the user to the identity provider authentication happens here your application gets a bunch of tokens you never see that the moment it happens the security parameter moves to the

identity provider your application is no longer attractive for developers there is no variable in your code that is actually holding a credential it's not there and you start there the very first time so again uh look at this if you're not against the same problem as we were discussing basic or your application sees the credential and that's where the problem starts number two is if you are actually trying to build a policy to move applications to use a modern protocols so there is there is always a discussion about hey there is sometimes a discussion about whether to use open id connect oauth or saml we would recommend open id is because it actually continues to evolve even today there are additions

being made to handle some of the contemporary scenarios that we have seen come up so if you have a choice please choose open id os over saml but again xaml is quite popular it will remain so but uh we as a microsoft the official recommendation is that you should stick to open ideo auth for to if you are looking into uh basically integrating with an identity provider we have amsoil libraries for those of you who are actually don't want to deal with protocols but want to get all the benefits these are open source libraries you can use it you have three lines of code that you have to write you'd have to learn literally nothing about open id and

oauth it just works for you and you get you get into the secure space with like the least amount of or maybe like a couple of hours you know your application has completely moved from customers to the to the modern auth area okay this is a continuous access evaluation is a thing that we have started to develop we are working with the ietf and other groups to basically support it better a little better those of you who have worked with saml or open idea one of the problems with these protocols is that they rely on what we refer to as bearer tokens an identity provider will give your application a token which is valid for 1

hours to 24 hours depending upon how you have set up your policies in the meantime if a user account is rebooked maybe they got attacked you have a third party tool that basically tells you that this is a compromised account or you want to delete an account if some employee has left if a password has changed user's location has changed and you have a policy that says this application should or this resource should not be accessed if the user is not in the company network or the user respond to be risky so what happens is in these cases the validity of token does not go away so what we have developed is called it's called continuous access evaluation

again it cannot be covered in this this one session it essentially lets your applications if they have subscribed for it and event it tells your app it sends an application an even that hey you got a token for a b c d graph as your whatever and it was issued to a user who has found to be risky please throw that token out that's you it also sends the graph apis and assure that hey if this token shows up because this token is still valid but you would not respect it you will reject it so this is essentially it was pushed very hard on us especially from the banking sector who really want this to be done and we have

sort of managed to get this rolled out in a good capacity it's not really where we want it to be but it's getting there so again it will require some work from the developers to use it is because hey you need to be able to understand it we wish that you know once you had used a library like a third party library which works with open id and you were good for it unfortunately things changed to a point where we have to ask you to make those code changes again okay there is a lot here if you want to look into a deeper dive of how this is being developed as part of the open

id specification ca is microsoft implementation claims challenge is an open id specification that we are using if you want to read more there is another link there that you might uh find useful okay i'm going to skip this because i just explained it uh there is a demo that i have we have at this link if you want to look into it actually in action you can try this out uh yourself and there is a code sample that if you want to try it out there is another link that's available as well okay the next one is essentially a pure developer topic topic which is that hey if you get tokens you are actually supposed to use the

claims in the tokens just because you got a token is great is because a mountain of security policies and what not got applied before that token was issued but even in your application let's say your application is one of the twenty two thousand that your large organization has in its tenant do you really want everything do you want if you let's see if you're an api do you really want all 22 000 of them to be able to call you or do you want to have some control over it or maybe if a user signed in logged in do you want let's say if you have you know you are walmart with 1 million 1.5

million employees does every application gets to be used by all 1.5 million employees definitely not so the the idea is that while there will be some controls always available in the on the on the azure id tenant side of things for it as a developer you should also learn how to use some claims the claims that are provided it's actually for the developers they're literally sent for to developers so they would use it for making their authorization decisions and things like that so let's start with this if somebody sends a token especially if you're if you're using better tokens in an api you cannot just take any api azure id issues approximately 100 billion tokens a day

you have to make sure that it has a claim called audience which has an application id into it if it should be for your app now you should not just say i see a token it's signed by azure already know we sign a hundred billion tokens you have to make sure that it's for your app okay maybe you want to make sure that you only accept the tokens from that where you should in your tournament so that's your tenant id maybe you want to only get users a certain amount of features available in the app depending upon which security groups they are member of so that's there these are like names are especially uh this is actually a very good point

that i have to explain so when you work with uh name oid sorry i want to cover this so it doesn't have it a name is not unique it sounds like something people understand but the only unique ad especially if you are working with azure youtube you have to basically look for what is the immutable identifier what we mean by that is for example my name is kalyan krishna if i leave and the next kalyan creation joins microsoft will give my email id my alias to that same person what they will not have is my object id so if you have data basically that that you store if you want to work with permissions you should not be working

with names on user principle names learn about what an immutable id is and if you have scenarios where you have to keep you take care of those things you should look into those i use this uh immutable ids rather than the preferred usernames or things like that so yep uh this is this is one examples of how you can use various claims if your application needs to make those decisions uh if so that wasn't actually an id token for those of you on a computer this is essentially an application that has only authenticated a user it's not an access token or a bearer token this is an example of a let's talk about web apis web apis are

just end points out on the internet and the only way they basically authenticate or authorize is because somebody sends them a token this is called a bearer token and an access token alarmingly a lot of guidance that we see out there about processing access tokens is about just read the token a token is supposed to be signed there is cryptography involved so faking a token is no big deal it's just a jot string you know a base 64 string with claims and a lot of attackers what they do is they will basically see what a valid token for a certain api looks like they will frame their own and just just send it across to see if

that api actually validates tokens as a developer you would never write any code for it that's for sure that's like rolling your own crypto there are like hundreds of libraries out there which know how to do the token validation according to the established open id standards you should be validating tokens that's the number one thing that that basically tells you that it's actually a token signed by an identity provider that you trust before you use or even look into a claim into a token it should be validated that's number one look into it read about it and basically make sure it's happening in your app the next one is again a kind of a similar discussion that we had so this

is a an access token issued by azure id again make sure that it was a token that your app actually wanted to work with uh it has things like the application that's calling your api do you want to reach restrictions sorry restrict your api to just four or five applications that's what you will use okay it has permissions if you are providing access to data using permissions are you using a scope claim or not do you are you aware of it okay and the last one is the signature and that's what i was referring to that you should use a standard sdk for things like this so i'm going to just stop here and because

i know i threw out a lot of things does anybody have any questions you want to ask or i can move to the next topic yeah

the answer is yes and no for today what we do is as i said an application developer has to make some change and they have to tell the idp that hey i am cae enabled okay capable sorry in those cases instead of one hour tokens we send them 24 hour valid tokens but that's the static value that should be in future modifiable using a policy or two but the idea generally is the same is like hey can we expand the time because the application knows how to react to any serious events it's aware of those so maybe i don't have to basically ask them to come to my identity provider every five minutes to ask if things are okay

does that answer your question sir

so the question was is microsoft promoting security first mindset yes we are and this is exactly why i'm here to start with okay the the session and to be to be very frank here is because the session is essential as i said the problem uh that we wanted to solve by making doing all of this and me standing here and delivering this is because the it administrators got frustrated asking the developers to do a set of things that they were supposed to do because all of these zero trust rollouts were getting stuck at some place or the other so this is basically yes it's a guide for developers but it's also a guide for it admins to basically

help developers with why should you care you are the reasons what you need to do here is a guide and if you don't do it it's not gonna work out any more questions okay i'll move ahead is because we're kind of uh so the if you are if your your organization develops mobile applications uh we suggest we use brokers people who are aware of brokers have you used authenticator microsoft authenticator google authenticator and such yep your application should be using it it's actually quite good in the mobile space it's because your app developers if they're using the broker applications they really don't have to do a lot the brokers are really good they will take care of every policy

every security feature and everything that is in between automatically so that's number one that we basically say again if you're using msr liability there is some more uh those of you who work with mam or you know application policies things like you know if you want the policies you want to set policies like this application will not allow any any any end user to copy something from the app then you these these in these places you use sdks like in tune and others out there in those cases again using a broker is is required so i'm going to move to the next one is because we're kind of running out of time so i'm going to touch up that this

topic here which is around least privileged access i'm going to give you an example of microsoft graph and how it what really is a developer's responsibility if they are designing an application let's let's start with that okay so usually again uh the example that i've taken is a web api that publishes data so if you have a lot of data that a web api publishes for other client applications to use try to use a permission model for those of you are not familiar so this is an example from microsoft graph where you have permissions broken down which allows your application to just get the amount of permission or amount of access that it really needs and

nothing more so it basically reduces the impact so okay let me give you an example so this is uh the app registration screen in azure id for an app developer or a web api developer by default if you the the usual habit that we have seen is that people will publish one permission because they are using oauth and it requires at least one permission to work okay but you are literally saying that hey if i have one permission any client application having this one permission will access all of my api the entire set of data behind it that's the bad practice that we basically want to reduce so you basically you should look into breaking

down permissions publish permissions based on the data that you have okay at least try to have a read and a read write separate so that applications just need to read data basically remain in a much secure and uh way to place in the first place uh again then i'll move to the last thing which is about what as a developer you need to care about in uh in the assumed breach side of things so yes as we said the breach is something that uh that unfortunately does happen and it catches developers by surprise and you have a lot of problems recovering from it so as a developer the number one thing that you should look for is again supporting

credential hygiene make sure that you use one of the mechanisms that allow your applications credentials secrets etc etc to rotate without your application even going down uh then this this becomes really useful is because as the number of tools uh that basically watch data watch watch systems look for attacks and vulnerabilities and do risk assessments they're able to point out vulnerabilities and issues you should be able to quickly your application can keep running while i t admins are the tools rotate credentials uh use keyboard and manage identities if you have not seen that if you have ifr and azure if you are on azure and you use azure then these are two things that actually help

you keep credentials completely out of code you don't need any credential anywhere in your code at all so there is a demo for those who are interested uh it's recorded demo you can go and uh have a look at how managed identities actually help and what developers can do about it more here the this is the very important bit that we came in as a it actually came in as quite late is that if you remember you get tokens from identity providers it has some very useful claims object ids upn t ids if you have logging telemetry in your application please consider logging them according to your organizations pii guidance the reason it's not going to be very

useful to you what happens is a lot of these third party tools that look into logs are getting smart about these when they're looking for lateral movements if there are applications that provide this you know microsoft applications will provide this if you know how to configure them they will tell you how the attacker moved whether they managed to get to this particular app or not okay so look into those uh the third one is yeah as i've talked about your applications you can support cae if you want to uh the final set is that it's it's there for liking even before i got into the it business please test your backups don't just back up okay

when when a breach occurs you would want to restore a backup then if you have sensitive data basic information encrypted make sure that your encryption keys and other keys that you use in your application are different ones otherwise you don't want your application and your data to be hacked at the same time this is again very useful for those who have azure active directory tenants uh we give out free azure ad tenants for anybody who wants however you want you don't have to develop in your production tenant it will require you to do things like consents and registered applications and do all all kinds of things it it's very difficult for it administrators to accommodate that we

give you free fully loaded tenants with all the licenses literally free you can just search for an m365 developer subscription please get one or two of those or maybe 10 of those do your development there once you are ready then come to your production your business tenant to go and actually deploy that app don't test it here okay these are the links that i have and this is my final slide any other questions

uh if you go to the b site speedbox site and go to my session it actually is available as a download

okay thank you for coming to this session i hope you got oh sorry

i'm afraid i can't hear yourself

so the question is how is azure enabling now azure is an umbrella of a lot of services you have to understand there are two aspects of it are the services behind that run azure are zero sustainably as microsoft users first but while all the knobs and all the all the all the controls are there in azure the developers and i.t admins have to use it if you are integrating and deploying an app on azure today if your developer chooses not to use managed identity and as your key vault you it will not be zero trust ready so you have to understand that there are two aspects of it and that's why we have this it's like hey there are features

available but we cannot force you to use something developer by nature coding is a nature where people just write a lot of stuff and you have to always keep updating things so the one that we have is essentially azure active directory so that's literally our guide so it's the very first one for the developers yep thank you

okay okay thank you again uh it was really nice seeing this crowd i hope you had a good takeaway from this