Hej, Nicolaj, velkommen. Hej, Michael. Nu er det 25, og det er været jul, og du havde julefedja, der var vi akket med. Ja, jeg gad ikke. Jeg druknede i julestress. Men nu er vi tilbage, og i nye rammer. Nyt studie. Det hele bliver super godt. Det er produceret Brian, der sidder her ved siden af os. Han har styr på det. Vi er klar. 25. Vi har stadig Mogens med. Det bliver rigtig godt. Måske er studiet lidt anlæst næste gang, når man skal sende, men præmere af ny studie. Det bliver bedre og bedre hele tiden. Men det skal ikke handle om, at vi er ved at flytte. Det skal handle om firewalls. Ja. Og firewalls, det må være nogen i Azure, vi snakker om. Det må det være. Det er firewalls i Azure. Og det bliver superspændende. Jeg skal nok love, at vi har nogle spændende ting med. Vi skal snakke lidt om forskellige typer af firewalls. Vi skal demo lidt nogle nye preview-funktionaliteter i Azure. Jeg tror, vi har mange forskellige ting i Azure, der smager firewallen. Og det er lidt det, vi skal komme lidt ind på i dag. Det er alt det her. Der er firewall i mange forskellige services. Der er nogle services, som har firewall i navnet. Det indgår nok også i den del, der er vores firewalls. Så lad os prøve at snakke lidt om i dag. Ja. Men du stiller lidt spørgsmålet, inden vi går i gang. Hvorfor skal jeg overhovedet have en firewall? Ja. Der er nogen derude, inklusiv også os selv, som mener, at det er en god idé at beskytte sine data og sine ressourcer, sine entiteter og alt sådan noget. En af de metoder, vi kan gøre det på, er jo i firewalls, som er det, vi kan beskytte noget igennem trafikken, der flyder frem og tilbage. Ja. Ja. Der er mange lærer sikkerhed, som vi ikke kommer ind på, fordi det er en anden broadcast, som vi ikke laver. Ja, og det er heller ikke Sierotor, vi snakker om det. Nej. Det er der selvfølgelig også. Det er også en helt anden snak. Det snakker vi også om, men det er også noget intra-Sveden. Ja, lige præcis. Så hvorfor skal vi have en firewall? Det skal vi, fordi vi skal sikre vores data. Ja. Det er det, vi gerne vil beskytte. Inbound, outbound. Inbound, outbound. Så lad os prøve at tage et kig på, hvad der findes af forskellige firewall-løsninger i Azure. Og vi har taget en lille håndfuld med. Den kvikke serier vil se, at det eneste, vi har med her, er Azure Native Services. Ja. Så jeg kan hurtigt lige parkere, at vi kommer ikke til at snakke om third-party firewalls i Azure. Hvis du er vanvittig forældskig i Palo Alto eller FortiGate eller et eller andet Cisco, whatever. Så tag det med op. De ligger der på marketplace, og de ligger i forskellige konstellationer. Om du bruger det ene eller andet produkt, noget software-defined, noget firewall, altså service-produkter og sådan noget. Så kan man gå ind og undersøge, findes det produkt i Azure. Der kan godt være use cases. Hvis du har 700 lokationer og en lille bit af Azure-ting, så kan det godt give mening måske at have den samme firewall. Det kan det sagtens. Der kan være masser af use cases, som vi overhovedet ikke har tænkt os at komme på i dag. Præcis. Så vi tager Azure Native, for det er det, vi kan finde ud af at snakke om. Og det vi så skal snakke om i dag i forskellige firewalls, det er, at vi har det, vi vil kalde for en fattigmand firewall network security group. Ja. Den kan åbne og den kan lukke, og det læger fire trafik. Ja. Øhm. Det er sindssygt det. Det er enten at adgang, jeg tror, der ikke er. Og det er til at blive. Det er egentlig sådan noget gammel deres netværksikkerhed. Ja. Ja. Lige præcis. Ja. Så har vi den store Azure Firewall, som er vores next generation firewall. Læger 3-7 trafik. Jep. Dermed kan vi jo så se, at den her firewall også kan lave noget natting. destination og source natting. Ja. Men også er ude og kunne lave noget web content filtering og nogle smarte IDS og IP. Ja, ja, ja. Og disklemmer vil jeg lige så godt sige, at det er jo ikke bare en software, der kan lave lukning på. Det er en rigtig firewall. Det er en rigtig firewall. Det er en rigtig firewall. Det er en rigtig firewall. Det er en rigtig best generation firewall. Så skal vi snakke om web application firewalls. Det er jo også en firewall til al vores web trafik. Og der er nogle forskellige services, hvor man kan tilknytte en web application firewalls. Du har noget net scale eller noget F5 eller sådan noget. Det vil være lidt de samme services, som vi har her i vores web application firewall. Og det er her, vi har sådan noget. Det her OVASP-regelsætning. Det er den lille cross-site injection og scripting og sådan noget. Det er det, vi kigger efter her. Så har rigtig mange platformers og service ressourcer i Azure deres egen indbygget firewall. Ja. Så en Key Vault, en storage account og alt det her, det er deres egen firewall. IP-baseret firewall. Igen. Åben eller lukket. Så det skal vi også snakke lidt om. Og så skal vi snakke om den helt nye pige i klassen, som er Network Security Perimeter. som er en måde, vi så kan gruppere og styre alle de her native pass firewalls. Så en centralisering af firewalls til vores pass services. Jeg har jo en nemt få, jeg kan huske navn på. Det er jo natgatewayen. Det vil du så ikke tage med. Fordi det er muligt, at mange burde deres firewall til natte med. Men det er jo ikke noget af det firewall. Og det gør vi stadig i Azure Firewall. Ja. Men natgateway er en rutningsenhed. Det er rent natting af outbound trafik. Ja. Så det er source natting. Det er ikke en firewall. Så er det ikke med. Og nu gider jeg ikke sige det igen. Fordi nu har vi sagt det så mange gange. Jeg har heller ikke routesurber med. Fordi det er også en router. Ja. Uden firewall. Og i dag handler den om firewalls. Yes. Lige præcis. Lad os kigge på den her fattigmandns NSG. Ja. Og den er der nok rigtig mange, der kender det ude, fordi den har eksisteret i ciliater af år i Azure. Ja. Så igen. Vi kan lave sådan en Network Security Group. Og i de her Network Security Group kan vi lave nogle rules. Inbound og outbound rules. Og dem kan vi så tilknytte netværksinterfacet på VM eller på subnet. Og rules det er port og IP adresser. Det er port og IP adresser. snakker IP adresser i Azure. Så kan man inden gå ind og sætte IP adresser. Ja. Men man kan også gå ind og sætte nogle forskellige andre service tags. Hvor Microsoft har så grupperet nogle IP adresser for os i nogle service tags. Det kunne være alle keywords i West Europe. Det kunne være et service tag. Så behøver jeg jo ikke at definere det. at hvis du har noget public trafik som flyder i Microsoft. Så kan jeg begynde at åbne og lukke for tingene der. Og du kan også bruge navnet på VNet ikke også? Jo. Ja. Vi har en masse måder vi kan definere de her ting på. Vi kan også gå ind og ud over IP adresser også lave nogle IP groups. Og lave nogle forskellige grupperinger af de her IP adresser. Det er så over i nogle af de andre services. Så igen en helt simpel firewall her. Så når vi går fra VM og vi skal ud. Så går den igennem Nikke. Og hvis der er en NSG der. Så tjekker den den. Er der en på subnet, så tjekker den den. Uanset hvad er vi så interesseret i at vi altid har det uanset hvad? Altså vi kan godt lægge farmorgens på at vi lever god praksis. Lægge på det på din netværk uanset hvad? Ja det er vi her. Altså jeg ville lægge den på uanset hvad. Vi har lidt tekniske udfordringer ser du ud til med den ene dog her. Det er godt du er her Mikke. Ja som man kan sige. Uanset hvad. Så er det god praksis at bruge de her network security groups. Altså vi har først snakket om de her Azure landing zone. Concept design og enterprise scale. og hvad hedder det hele. Fellow mind manage platform. Øhm. Der har vi jo en central firewall. Men det er stadig god praksis hvis vi så kan lave den her. Som måske er imellem vores services. Imellem vores VM'er ikke. Men der er jo hele tiden når vi snakker firewalling. Og jo mere sikkerhed vi lægger ned på. Jo mere management overhead får vi også ikke. Så det er jo også sådan en. Det er den der balancegang. Og hvad er den rigtige det ved jeg ikke. Det kommer an på hvor følsom den data måske er. Ja fordi det kunne godt blive sådan kodet. Vi skal jo stadigvæk vedligeholde det. Det er jo sådan der udfordring med det. Ja ja. Okay men der kan man starte. Og det koster ikke noget. Nej der kan man starte det koster ikke noget. Gratis. Der har jeg lært af en klog mand at sige uden mere omkostning. Inkluderet. Inkluderet. Nå. Den næste. UB. UB. Firewall. Ja. Så hvis vi lige kigger på det. Azure Firewall er ikke den nye drengklassen længere. Det end har været der i en del år efterhånden nu. Azure Firewall kan vi integrere med enten et virtuelt netværk. Eller virtual hub. vi kan lave det der hedder en secure hub. Og på den her måde når vi så har et up spoke arkitektur. Nå men så kan vi sørge for alle vores spoke som next hub rammer vores Firewall. Det gør at vi kan lave en eller anden zone opdeling af vores ressourcer. Og de rammer Firewall. Altså man kan også lave det helt nede på slags 32. At den så skal råbe det hen til. Det er faktisk godt. Men igen det giver også noget. Og nu har du jo fint tegnet noget dubleret her. Ja jeg har faktisk ikke tegnet noget som helst. Jeg har 20.8 det fra Microsoft hjemmesiden. Men det har jeg gjort godt. Ja. Og derfor kan man se at. Og det vi prøver at visualisere her. Det er jo et flow imellem. Så vi har noget on prem. Vi har noget hybrid netværk. For nogle datacenter. Eller vores kontorer. Som så rammer vores VPN terminerer jo så heroppe i den her hop hvor vores Firewall ligger. Så det er jo knudepunktet i alt trafik ind og ud af Asien. Ja. Så det er lidt en. Det er ikke kun en Edge Firewall. Også have den så imellem vores forskellige spokes som kunne være vores landing zones. Vores opdeling. Vores line of business applikationer. Ja det tror jeg faktisk er en ret vigtig ting jo. Fordi der er jo ingen tvivl om at der er mange der har sagt det. Men når du laver datacenter. Netværkssikkerhed. Så er det en helt anden størrelse Firewall. Så det er jo en helt anden Firewall. Så det kræver meget mere kapacitet. Ja. Men det her det skalere faktisk. Så man kan bygge det imellem landing zones. Den er fuld skalerbar. Og det kan vi jo komme lidt ind ved fordele. Der er ved at have det. Ja. Så Azure Firewall er den her Next Generation Firewall i Azure. Og den kommer i tre forskellige skuer. Ja. Basic, standard eller premium. Ja. Og der er noget forskel i bridssætning. Der er noget forskel på en masse forskellige ting her. Det man skal tage højde for det er selvfølgelig. Hvad for nogle services er det jeg skal have i brug. Hvad er vigtigt for mig. Og så noget med den her skalerbarhed i kapaciteten. Altså den performance jeg vil have. Så hvis man vælger en premium. Så er det op til 100 GB pr. sekund. Og ned i en basic er det 250. Så måske er basic fint. Og jeg skriver også at har du en lille forretning. Noget small medium business. Så er det en basic måske er fint nok. Ja. Men selvfølgelig skal du op i at have nogle flere sådan. Martin Next Generation Firewall services. Nå men så skal du op i stacken ikke. Vi snakker altså med at køre 30-100 GB. Hvor du bare skal plukke en service. Og så sørger Microsoft her. For der er jern bagved. Yes. I strømme. Yes. Du skal ikke sørge for at styre noget cluster. Eller have nogle VM. Eller et high-valuable setup. Og det er jo det der er med. Ja for der kunne godt være en del kompetitive. Og helt lige netværksadresser og sådan nogle ting. Og alt muligt palaver. Ja ja ja. Ja helt klart ikke. Og det vil jeg se tit med. Der er også noget. Når du har et high-valuable setup på VM. Og med noget. Med en VA. Så har du noget indbar og anbar trafik. Hvor er det aktiv og passiv. Og der er noget infrastruktur du skal styre. Data og statlæser er det sådan noget. Det kan du ikke tænke på. Det styrer mig. Så det der er vigtigt at tage med her. I forhold til den her. Azure Firewall. Det er jo de her. Gå ind og kig på de her premium features. I forhold til det her. IDPS. Ult filtering. Altså web content. Firewallen. Er også. Kan også være DNS proxy. Okay. Så det vil sige at. Hvis vi har den som DNS proxy. Når vi så laver vores FQDN regler. Hvor slår den dem op hen. Så vi kan bruge den til en masse intern DNS. Og private DNS også. Så hvis vi har noget private routed netværk. Og noget intern DNS. Opslag. Så kan vi begynde at sætte det op. Vi gør det jo sådan i vores. Fellow Mind Managed platform. Hvor vi har Azure Firewallen. Så er den DNS proxy. Ja. Og det betyder jo så også. Hvis vi skal begynde at rette. Noget senere hen. Nå men så alle de her spokes vi har. Dem kan vi have 100 vis af. De peger et sted hen. Og det er vores firewall. Så vi har et sted vi skal rette tingene. Så hvis vi laver nogle andre. DNS konfigurationer. Når vi så skal det ske centralt. Så skal vi gå ud og rette 100. Boks. Det er også en fordel. I den også. Og selvfølgelig at firewall kan lave DNS opslag. Ja ja. Ja ja. Men du får sikkerhed end et sted. Det er jo. Det er fedt. Yes. Så det var lige en teaser. Gå ind og så læs lidt mere om det. Igen. Der er virkelig forskel på de her produkter. Hvad de kan og hvad de ikke kan. Nu tænker jeg på Azure Firewall. Og de konkurrerende produkter. Så man går ind og ser. Hvad er right fit for mig. Ja. Det er ret full features. Det synes jeg. Ja det synes jeg også. Web application for. Ja. Microsoft har. To typer af. Det vi vil kalde for sådan noget. Layer 7 load balancer. Mhm. Application gateway. Og front door. Ja. Application gateway er en. Regional. Ja. Load balancer. Den ligger i datacenteret. Yes. Den ligger i West Europe. Sweden central. North Europe. Whatever. Whatever you got. Tilsøger bagved. Så prøver du den foran. Så prøver du den foran. Og så kan den. Lave load balancing. På. Hotsp. Mhm. Og alt det der smarte med. Tils terminer. Og der er en mulig andre servicering. Igen. Det har ikke noget med firewall gør. Ja. Det kan også hjælpe dig når du skal. Holde det ved det servicering og sådan noget. Ja. Den kan alt muligt fedt. Ja. Så gå ind og tjekke det ud. Ja. Men her der er det så web application firewall den. Den anden det er så front door. Ja. Igen. Også en. En load balancing. Den er så global og ikke regional. Det vil sige. Den ligger ikke i. West Europe. Den ligger ikke i Sweden central. Men den ligger ude i de her pop locations. Copenhagen. Den ligger ude på edge. Så noget edge compute. Mhm. Og det er fordi det er CDN. Ja. Har du noget med at lige hurtigt sige. DDoS. For det er der også nogen der tror en firewall gør. Det er der ikke vel. Og det kan de jo begge to hjælpe med. Det kan de begge to hjælpe med. Ja. Fordi der er DDoS som en del af de services. Og så kan man også købe DDoS protection som en service på en public IP adresse. Det er noget her. Så. Men de her to services. Application gateway og front door. Dem kan vi lægge en web application firewall policy på. Mhm. Hvis de vælger at mærke har den rigtige sku. Uh. Men det kan man også gøre nu. Og slå lidt op. Så en web application firewall gør at vi kan gå ind og have en. Den her firewall politik. Så vi kan begynde at åbne og lukke. I forhold til hvem må få adgang. Hvornår og hvordan. Mhm. Øhm. Og det er de her ovars regler. Det kan også være nogle custom regler. Microsoft har også et regelsæt. Der er faktisk også et bot regelsæt. Ja. Øhm. Og det kan vi gå ind og lægge ned over det her. Øhm. Over den front door eller application gateway vi har. Og så har vi nu en web application firewall vi begynder at styre der. Vi bruger det. Mange use cases hvor vi tit bruger det. For eksempel hvis vi har et dev environment. Det er public. Available for alle. Så okay. Så alle mine services er public. Men hvis jeg har et dev environment. Kan det godt være ikke vil have mine kunder til at gå ind og kigge i et dev environment. Bare fordi de lige finder ud af hvad urlen er. Men så kan jeg begynde at whiteliste IP adresser og sådan nogle forskellige andre ting. for de udviklere som måtte sidde i det her dev environment. Så sådan en simpel use case til sådan nogle web application firewall. Ja. Og den hjælper dig når du har de ekstra websites hvor du også har nogen til at forsøge at hacke dem. Altså lave dine pensions-tests. Så er den der sørger for at. Det er der det bliver fanget ikke. Og så begynder vi at lave en masse exceptions fordi vi får nogle false positive resultater og sådan nogle forskellige ting. Og så kan vi begynde at lave nogle regler for det også i vores web application firewall. Jeg tror dem der har nedskilleren eller femkast de ved godt der skal laves en del arbejde. Og det skal selvfølgelig også have hvis du går ned og. Det ser vi også. Og det er også derfor man når man bygger den her kan vi gå ind og bygge den i sådan en detection mode. Så vi starter med at gå ind og få en masse log indsamling. Hvad er det for noget trafik vi ville se ville blive blokeret. Og så kan vi gå ind og rette det og så sætter vi ned prevention mode og så går vi ind og fikser de sidste ting vi mangler. Det ser vi jo også ikke. Det var aldrig 100% det her. Nej. Så vi må tage nogle ordentlængere. Ja hov for søv. Er det ikke sige det. Ja. Så det er web application firewall vi kan tilsynde vores application game og vores front door. Custom regler skriver en premium. Så hvis du skal lave IP filter. Det er i ordentligt. Det må man så gå ind og tjekke lidt ud. Geoblocking ligger også derinde. Hvis du ikke vil have at forskellige regioner skal kunne tilgå din service. Hvis du nu laver en service der kun er et europæisk markedskab. Så kan du jo skrue ned på det. Fedt. Den sidste er så den nyeste. Det er vores network security parameter. Og nu sprang jeg lidt over native pass. Er der ikke et slide på. Fordi jeg tænkte den tager vi med i det her. Ja. Okay. Så forestil dig at vi har en løsning med flere forskellige pass ressourcer i sig. Key Vault. Sequel. Storage account. Nu læser jeg bare hvad der står i slide. Det er ikke det nemmeste for mig. Cosmos DB. Dem skal jeg gå ind og definere firewall regler på enkeltvis. Og her er det selvfølgelig. Vi snakker om noget der vil være publicly available. Vi kan godt lave private link og privat routet netværk og alt det her. Så er det selvfølgelig ikke publically available. Men der er et scenarie hvor det ikke er nødvendigt. At bygge det her store privat routede netværk. Som også skal håndteres. Fordi der er ikke noget data i det som nødvendigvis er noget vi behøver håndtere det her. Så det må gerne være public livet. Ja. Så de har de her firewall regler og det skal jeg så håndtere per ressource. Ja fordi de kan det jo alle sammen være for dig. Så når mit udviklingsteam A, B og C skal have fat i min developer sequel. Og den vil jeg jo gerne låse lidt ned så alle i hele verden ikke kan tilgå den. Så skal jeg gå ind og lave firewall regler. For de hjemmearbejdspladser. For de kontorer de nu flyger på. Og måske der ikke. Og det skal jeg jo så håndtere. Og de vil jo også gerne have adgang til en storage account. Så skal jeg lave det her også. Og når der kommer ind så skal huske at opdatere alle ressourcerne. Ja. Det kan selvfølgelig gøre jeres code. Og jeg kan gøre det på en meget smarte måde. Men det er stadig sådan lidt et sprawl af ressourcer jeg skal opdatere. Det prøver Microsoft at løse med det her network security parameter. Så jeg skal definere det i den her network security parameter. Definere jeg regelsættet inbound outbound et sted. Og så attache jeg den profil til mine ressourcer. Så jeg definerer FIW. Så jeg siger udviklingsteam A, B og C. Og når Brian og vores producer skal have sin hjemmearbejdsplads på. Så tilføjer jeg også den til perimeteren. Og så har jeg nedgang til alle de ressourcer. Og hvorhener du tilfører den på en database eller noget. Den her parameter. Så lugter lidt af demotid snart. Og det er den her tegning vi så viser lidt. Ej gå lige til spændstegning. Den er der. Den viser også noget med et privatruttet netværk. Det virker også med private links. Det virker ikke med private endpoints. For det er private endpoints som udgangspunkt er noget outbound trafik. Så det virker med de her private links. Men det virker også med public. Okay. Så. That's the queue. Okay. Så vi skal lidt ind og prøve at kigge på det her. Hvordan virker det? Ja. Det virker også. En pisse god idé. Okay. Ja. Så god var den. Ja. Så vi skal prøve lidt at kigge på det her. Så hvis jeg kigger. Nu har jeg min Always Asher her. Og så har vi Super App. Ja. Super App. Den kan jeg. Hvad kan den ikke. Den kan jeg det hele ikke. i min SQL Server. Herinde i min SQL Server. Vil jeg have noget networking. Mhm. Og herinde i networking. Vil jeg have nogle. Øh. Regler her. Der har jeg en regel. Med en public adresse. Mhm. Men ikke altså tilføjt to gange. Det var så ikke lidt meningen. Men. Og det er også her jeg kan gå ind og sige. Nå men. Der har jeg ikke public adgang. Selected networks. Mhm. Og hvor jeg kan give virtuel netværk adgang. Som der så også kan få adgang til. Ja. Og så er det faktisk. Så når jeg skal ind og lave det her. Selvfølgelig vil jeg lave det. I noget bicep. Eller noget infrastructures code. Og så definerer jeg det her. Så det virker det her. Jeg har adgang. Og jeg kan åbne min Azure Data Studio. Og hurra. Jeg har adgang til min SQL Server. Hvad? Nej. Hvor det spiller ikke? Ja. Og man kan sige. Det her lille networking blad og firewall. Det er jo blevet sådan lidt strømlignende nu. Så nu ser alle ressourcerne mere eller mindre sådan her ud. Ja. De har lige set lidt forskelligt ud. Men nu ser de alle sammen mere eller mindre sådan her ud. Og vi kan da godt tage et lille eksempel mere med den her Key Vault. Ja. Den har også noget networking. Og den har også noget firewall. Sådan. Den er så bare sat public public. Det er fint. Alle må gå ind i den her. Der er selvfølgelig noget adgangsstyring med noget AirBug og nogle forskellige ting for at få adgang til de her sikkerhedser. Men det er jo det, vi vil gerne have mere lag af sikkerhed i det her. Så her vil jeg også kunne gå ind sammen med interface. Men nu laver vi den public for alle. Det der så er interessant her. Det er så at lave sådan en network security perimeter. Ja. Det her er en service, der er i public preview. Uh. Så. Nej med det. Men lad være med at bruge det i produktion. Ja. Hvad kommer man til at koste? Der er ikke noget slag på. Alt sådan nogle ting. Det er jo det der. Men det kræver jo så, at man lige går ind i preview features. Network security perimeter. Og så enabler man det her feature flag, der er inden at man kan køne på. Ja. Tjek. Så er det gjort. Så ved man også, at det er der man er. Ja. Og så kan vi sætte den på. Og man kan få lov til at gå ind og så klikke den igennem og så tilføje tingene. Men her har jeg den. Vi kan også bruge infrastruktures code til at bygge den. Det vil vi jo rigtig gerne. Det giver god mening. Uh. Så det jeg kigger på her er min super appen. Uh. Uh. Profiles. Det vil sige, at jeg kan gå ind og opdele i forhold til nogle forskellige profiler, hvis jeg har en gruppe af udviklere. Uh. Eksterne konsulenter. Et eller andet andet, hvor jeg gerne vil gå ind og lave sådan noget profilstyrning. Hvem har adgang til hvilke ressourcer. Der er jo sådan nogle grupperinger i de her profiler. Fedt. Og så har jeg alle mine associated resources. Uh. Uh. Hvordan afgrænter du så dem? Det er jo så det. Det er, at jeg laver sådan en profil. Og i den her profil, der er associated nogle resources. Uh. Og så sætter jeg nogle inbound og outbound. Uh. Uh. Uh. Så her kan jeg lave en inbound access room. Uh. Uh. Og det kunne jo så være en eller anden IP-adresse, jeg gerne vil smide på her. Giv navn. Giv et eller andet CIDR scope her. Uh. Men det kan også være en subscription. Og så kan jeg gå ind og give en hel subscription adgang til de her ressourcer. Nej, det er jo smart. Så kan den på resource ID finde ud af, hvad IP-adresse er. Det er smart. Det er ret smart. Øhm. Det er lidt i stedet for, at man bruger de her service tags. Uh. Så kan vi gøre det på den her måde. Du må stærlig ikke lave tags, men du kan også bare bruge en subscription. Det er smart. Og sammen med outbound, og så har jeg mine associated resources her. Og den går ind, og den siger, at den er associated. Den siger noget om access mode. Det kommer vi lige ind på. Og så går den ind og siger, at den er enabled. Og der er en farlig, farlig trekant. Og det er sikkert, fordi den er public. Ja. Alt, der er public, er farligt. Vi anbefaler også, Microsoft anbefaler i alle deres defenderting og alt muligt andet. Private. Men igen, der kan jeg måske godt lide, at man tager stilling til, hvad det er for noget data, der er i den her provision. I stedet for at bygge den store forkromede infrastruktur. Der er også godt for lige. Der er også godt for lige. Ja. Og så kan vi se, at der er noget, den er succeeded her. Det er succeeded med issues. Det issues handler lidt om noget managed identity, der skal være signet her for at få outbound access til andre ressourcer. Ja, ja. Så den hjælper os også lidt at sige, at den her kan nok ikke få adgang til andre, fordi du mangler den her managed identity. Nå. Tæk. Så nu har vi styr på det. Vi kan gå ind og øge flere ressourcer. Vi kan se effekten. Vi kan konfigurere, om den her public er enabled, eller om vi vil lukke ned fra public adgang til alle de her ressourcer, der ligger i den her profil. Eller om den er secured af den her perimeter. Ja. Lige nu er det bare, at enable public access from all networks to this resource. Og så laver jeg skobet mindre. Mhm. Og så change access mode. Og access mode, det kan stå i learning eller enforced. Good. Learning. Men så gør den jo faktisk ingenting. Nej. Så kan du godt lave en masse regler herinde stadigvæk. Mhm. Men så, hvis den ikke bliver ramt af en regel i den her perimeter, så vil den default tilbage til reglen, der er på passressourcen. Mhm. Og det gør jo så, at når du er i en transition, hvor du allerede har nogle eksisterende ressourcer, men skal implementere det her. Ja. Hvilke regler skal jeg flytte? Har jeg fået flyttet dem alle sammen? Ja. Og så kan man gå ind og query i loggen, hvor terminerer de forskellige bruger, der er min inbound-trafik her. Ja, ja, ja. Og en forrest mode, det er selvfølgelig bare bom. Og så risikerer jeg jo, at jeg gør nogen, der ikke kan prøve gang. Nogle, der ikke kan arbejde lige pludselig. Ja. Men det er jo også meningen. Ja, det kan jeg måske. For at høre, hvem nogen er. Måske ikke. Det kan jeg ikke arbejde længere. Og nu står den i learning mode, og så kan vi se access logs. Her trykker jeg på access logs. Øhm. Så tænker den. Og så dukker den op lige pludselig, efter den har tænkt. Men her kan jeg faktisk gå ind og se nogle access logs for den her Cicro. Og her kan jeg se, at der er min profil, der er min service, men her kan jeg se match rule. Her bliver jeg faktisk ramt af en regel, der hed FellowMind. Og det er fordi, jeg lavede en indbound-regel. Den kaldte FellowMind. Gav FellowMind IP'en, og så kører jeg for adgang. Og jeg kan også se her, at her er materialet faktisk vores resource, Firewall rule. Så her der defolter den tilbage. Og det vil den jo ramme nu, fordi jeg ikke har defineret nogen indbound-regel. Så kan jeg se, hvor terminerer min trafik. Og så kan jeg få flyttet de folk, der ikke længere terminerer de rigtige steder ind her. Eller som du også siger, fjerner dem helt. Så ja, gå hjem. Gå hjem, ikke? Så på den måde kan jeg have den her learning mode, og så få flyttet over. Men det her gør altså, at jeg kun skal definere mine Firewall -regler for PAS-ressourcen et sted. Og det synes jeg er supersmart, og det gør det lidt nemmere for os. Ja, så kan du faktisk lave lige så mange, det skal være. Men hvis nu er de nogen af ens, kan de lave hierarkisk også? Får I lige lyst til at gøre også? Altså lave et basis-set, jeg bruger på alle mine subscriptions, og så have nogen, der er lidt mere fræk, end jeg bruger på nogle enkelte? Jamen det er jo det, du kan inddele dine profiler i. Ja. Så du kan lave forskellige profiler i forhold til forskellige brugere, der skal ind og have adgang. Hvilken person er der, der skal ind, og hvad skal det have adgang til? Ja. Men det er jo ikke sådan sådan en stor flad struktur, ikke? Så der er ikke sådan noget hierarki i det. Nej. Men forskellige profiler. Men forskellige profiler. Det er den måde, du vil styre det her på. Galera. Så jeg synes, det er en superspændende ny feature, der er kommet. Ja. Og igen, noget af det, vi også gerne vil snakke lidt om, og noget af det, der var... Altså, den her snak om, hvorfor bruger cloud-native services frem for en mon egen ting, det er jo også, vi snakkede lidt om det, inden vi gik ind i studio også, det her med central og decentral organisationer. Hvor ligger din udvikling henne? Har du mange udviklingsteams, der er selvstyrende, og kan bygge en masse ting selv i Azure? Eller har du en central IT-enhed, der styrer alt, der hedder firewall og DNS? Og dem skal du ringe til hver gang, at du skal have løst noget. Men når du har de her cloud-native ressourcer, så kan du begynde at dele det ansvar op. Ja. Tænk hvis du havde en centralstyret firewall, eller front door med en web application, eller network security perimeter, hvor du giver andre adgang til at skrive de firewall-regler ind. Ja. Så du har både de centralstyret og de får lov til at lave deres andet decentral. Fordi så kan vores team selv få lov til at få mere kontrol over den samlede application. Det vil vi jo rigtig gerne. Vi vil jo rigtig gerne have den decentral kontrol. Men vi skal også sikre, at det vores udviklere smider ind i den firewall, også er det rigtige. Så har vi alle mulige processer for at sørge for, at de kan smide det rigtigt ind. Azure policies, pipelines, der er sikre, at nogen læser de der ting, der er kommettet igennem, og det er noget rigtigt. Så det vi kan med de her cloud-næse-ressurser, det er, at vi kan begynde at splitte ansvaret også ud. Ja. Det er smart. Det er supersmart. Det virker også simpeltere end at skulle til at lave Start Service Up. Det er det bare. Det er jo nogle regler. Ja. Og det er ikke det for i dag. Det er det for i dag. Tak for i dag. Tak for i dag. Hej.