Microsoft AZ-500 Azure Security Engineer Certificering Notes

Azure AZ-500 is Microsoft’s antwoord op het security vraagstuk in de cloud. De cloud en daarmee ook de Azure cloud kent vele mogelijkheden en nieuwe attack vectoren in tegenstelling tot de traditionele ICT infrastructuur. Microsoft zou Microsoft niet zijn om daar een antwoord op te hebben en om de gebruiker de juiste tools te bieden. AZ-500 (Azure Security Engineer) gaat in om een scala van mogelijkheden om je Azure cloud veilig te houden. In deze post lees je mijn quick-notes van deze cursus. Dit zijn de zaken die ik interessant vond en dus niet zaken die ik al heb geleerd tijdens b.v. AZ103. Doe er je voordeel mee.

Zero Trust Model:

Het oude model is dat niets buiten het netwerk veilig is en alles in het netwerk wel. Zero trust gaat ervan uit dat niets veilig is en dat “ trust” altijd gevalideerd moet worden. Dit omdat toegang tot de cloud vaak gebeurt vanuit onbekende devices en v.a. het internet. Dit heeft diverse componenten:

• Identity Provider – Valideert gebruiker = Control Plane / Security Boundery (Credentials + privileges = digital identity)
• Device Directory – Valideert apparaat (en integriteit)
• Policy Evaluation Service – Voldoet gebruiker / device aan de gestelde policies
• Access Proxy – Bepaald welke bedrijfstoepassingen benaderd kunnen worden.

Privileged Identity Management – PIM

Sommige accounts hebben meer rechten dan andere, zogenaamde “privileged accounts”. Om deze te beschermen biedt Microsoft de “Azure AD Privileged Identity Management” service (PIM). Met PIM kun je toegang tot belangrijke assets van je netwerk managen, controleren en monitoren. Een aantal functies van PIM:

• ”Just-In-Time” toegang tot Azure resources (alleen het openen van specifieke poorten binnen een bepaalde tijd).
• Time-Bound access (alleen toegang van-tot)
• Extra controle door toegang te vragen aan een admin voor toegang
• Vereisen van MFA om een rol te activeren
• Vragen om verantwoording waarom gebruikers iets activeren
• Versturen van notificaties wanneer “ privileged roles” geactiveerd worden
• Access Reviews uitvoeren om te verifieren dat gebruikers nog steeds bepaalde rechten nodig hebben
• Audit controls

Voor PIM heb je minimaal nodig “Azure AD Premium P2” OF Enterprise Mobility + Security (EMS) E5.

PIM = Extra beveiliging van je rollen
RBAC = Definitie van je rollen – gebaseerd up user acties (controle van items) binnen verschillende scopes – Default deny and explicit allow
POLICY = Definitie van acties welke een gebruiker binnen een onderdeel kan uitvoeren – Default allow and explicit deny

Een nieuwe gebruiker aanmaken:

1. Maak een wachtwoord variabele

$PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile

2. Vul de variabele met een wachtwoord

$PasswordProfile.Password = "<Password>"

3. Maak de gebruiker aan

New-AzureADUser -AccountEnabled $True -DisplayName "Abby Brown" -PasswordProfile $PasswordProfile 
-MailNickName "AbbyB" -UserPrincipalName <a href="mailto:AbbyB@contoso.com" title="" target="_blank" data-generated='' rel="noopener noreferrer">AbbyB@contoso.com</a>

Gebruikers kunnen ook gemakkelijk toegevoegd worden met een CSV welke via Powershell te importeren is met het “Import-CSV” commando.

Multi Factor Authentication / Account Security

Azure MFA wordt uiteraard ook gebruikt om je accounts veilig te houden. Deze kan op 3 manieren gebruikt worden.

• Cloud Based – met Azure AD Premium licenties
• On Premise – met Azure AD Premium licenties
• Als onderdeel van Office365 – beperkt
• Voor de Azure AD Global Admin rol

Vervolgens worden accounts beschermd met o.a.:

• SSPR – Self Service Password Reset (incl. Link in Win10 login screen)
• AADIP – Azure AD Identity Protection = risk Based Policies
• Password protection – Block bekende wachtwoorden d.m.v. een password blacklist
• Smart Lockout – Anti Brute-Force
• Application Proxy – Security Enhanced Remote Access tot een on-prem applicatie
• SSO – Single Sign On
• Azure AD Connect – Beheer Azure AD vanuit On-Prem AD

Azure AD Roles

• Owner – Alle rechten op alle resources – kan controle delegeren naar andere users
• Contributer – Kan alle Azure resources aanmaken maar geen rechten delegeren
• Reader – Kan alle Azure resources zien maar niet aanmaken

Elke role definitie is gedefinieerd in een JSON bestand. Deze variabelen worden gebruikt om rechten aan te geven:

Actions:

• * = Alles
• */read = alleen lezen

NotActions:

• None = Geen NotActions
• Microsoft.Authorization//Delete, = Mag niet verwijderen
• Microsoft.Authorization//Write, = Mag niet aanmaken
• Microsoft.Authorization//elevateAccess/Action = Mag geen rechten aan anderen uitlenen

WebApps

AzureAD kan de toegang tot webapps regelen. Dit kan Azure in 5 scenario’s, namelijk:

• SPA – Single Page Application (een app die bestaat uit 1 pagina)
• Web Browser / Web application
• Native app (draaiend op computer / telefoon etc.) Web API
• Web application API
• Web API die toegang geeft tot een deamon of een server applicatie die geen web interface hebben

Om toegang te geven moet de applicatie geregistreerd zijn in Azura AD waar bekend is op welke URL de app werkt, waar authenticatietokens naar retour gestuurd moeten worden, welke protocollen er gebruikt mogen worden etc. Binnen AD is de app een abstract object. Wat de app werkelijk kan doen wordt bepaald met een “Service Principal”. De directory die het object heeft (in AD) kan service principals uitdelen aan andere directories.

Alvorens een web-app bereikbaar kan zijn middels een eigen custom DNS naam moet je uiteraard deze custom DNS naam laten hosten door Azure DNS en er moeten 3 DNS records aangemaakt worden. Te weten:

• Root A Record – verwijzend naar de root URL (custom domeinnaam zonder voorvoegsel)
• Root TXT Record – voor DNS verificatie
• CNAME Record – Record voor aanmaken van een alias (b.v. www.ALIAS.rootdomein)

Om een app te laten verwijzen naar een custom DNS naam moet ook het service plan ge-upgrade worden (scale up). Dit is alleen mogelijk in de non-free tiers zoals b.v. D1, B1, B2 of B3.

Role Based Access Control – RBAC

Role Based Accesss Control maakt het gemakkelijk om toegang tot objecten per group / user te beperken. Wanneer er toegang is tot een object wordt die toegang doorgegeven op onderliggende objecten. Je kunt je eigen RBAC rollen maken of gebruik maken van de default rollen.

Classic subscription admin roles waren alleen van toepassing v.a. een subscription en lager. RBAC rollen bestaan op een hoger niveau en overschrijden meerdere subscriptions.

1. List roles:

Get-AzRoleDefinition | FT Name, Description

2. Bekijk role definities:

Get-AzRoleDefinition <role_name> | ConvertTo-Json

3. Bekijk role acties:

Get-AzRoleDefinition <role_name> | FL Actions, NotActions

4. Bekijk role toegang op een groep:

Get-AzRoleAssignment -ResourceGroupName <resource_group_name>

5. Bekijk role toewijzingen aan een gebruiker:

Get-AzRoleAssignment -SignInName <email_or_userprincipalname>

6. Maak een rol toewijzing voor een gebruiker op een resource group:

New-AzRoleAssignment -SignInName <email_or_userprincipalname> -RoleDefinitionName <role_name_in_quotes> -ResourceGroupName <resource_group_name>

7. Remove role toewijzing:

Remove-AzRoleAssignment -ObjectId <object_id> -RoleDefinitionName <role_name> -Scope <scope_such_as_subscription>

8. Een custom rol aanmaken (Virtual Machine Commander):

Eerst moet je weten welke rechten je nodig hebt. In dit geval willen we een custom groep aanmaken die VM’s kan starten en stoppen. We moeten dus weten welke resource providers we moeten benoemen en welke acties deze ondersteunen. Om alle resource providers te bekijken gebruiken we:

Get-AzResourceProvider -ListAvailable

Om alle acties van een resource provider te bekijken gebruiken we:

Get-AzProviderOperation "Microsoft.Compute/virtualMachines/*" | FT OperationName, Operation, Description -AutoSize

Belangrijk voor ons zijn:
Microsoft.Compute/virtualMachines/start/action
Microsoft.Compute/virtualMachines/powerOff/action

$role = [Microsoft.Azure.Commands.Resources.Models.Authorization.PSRoleDefinition]::new()  
 
$role.Name = 'Virtual Machine Commander' 
 
$role.Description = 'Can start and stop virtual machines.' 
 
$role.IsCustom = $true 
 
$perms = 'Microsoft.Compute/virtualMachines/start/action', 'Microsoft.Compute/virtualMachines/powerOff/action' 
 
$role.Actions = $perms 
 
$role.NotActions = (Get-AzRoleDefinition -Name 'Virtual Machine Contributor').NotActions 
 
$subs = '/subscriptions/689b6a6b-c6e5-4409-be4e-01a6236daaa7' 
 
$role.AssignableScopes = $subs 
 
New-AzRoleDefinition -Role $role

Om de rol weer te verwijderen gebruik je:

Get-AzRoleDefinition 'Virtual Machine Commander' | Remove-AzRoleDefinition

Remove-AzRoleAssignment -ObjectId <object_id> -RoleDefinitionName <role_name> -Scope <scope_such_as_subscription>

Om alle custom roles te bekijken:

Get-AzRoleDefinition | ? {$_.IsCustom -eq $true} | FT Name, IsCustom

Wanneer je een subscription verhuisd naar een andere tennant zullen alle role-based toewijzingen verwijderd worden. Deze moeten dan opnieuw aangemaakt worden.

RBAC focust zich op user-actions binnen verschillende scopes. Je kunt ook Policies aanmaken. Deze Azure policies gaan in op resource properties. Een policy kan je b.v. beperken tot het aanmaken van een object in slechts een aantal regio’s terwijl RBAC je wel of geen object laat aanmaken. Policies zijn een expliciet deny mits allowed systeem.

Policies

Voor het aanmaken van policies is het goed om te weten dat policies aangemaakt kunnen worden met 6 soorten effecten (4 voordat de actie is uitgevoegd en 2 (IfNotExist) nadat de actie is uitgevoerd) kan worden uitgevoerd. Deze zijn als volgt, in de volgorde dat ze geëvalueerd worden. Tijdens evaluatie wordt de eerste match toegepast (first-match priciple):

• Disabled – Als policy disabled is wordt deze niet uitgevoerd
• Append – Toevoegen / Aanpassen. Als deze actie wordt uitgevoerd dan worden zaken aangepast tijdens het aanmaken of veranderen van een object. Er worden b.v. tags toegevoegd. Als een append policy wordt uitgevoerd op bestaande opjecten dan worden deze niet aangepast maar gemarkeerd als incompliant. Na de append actie kan een vervolgactie getriggerd (ifNotExist actie) worden
• Deny – De policy wordt genegeerd en er wordt geen audit uitgevoerd
• Audit – Indien een policy als “Audit” geëvalueerd wordt dan wordt er een warning event geplaats in de activity log als het om een non-compliant device gaat en er wordt een vervolgactie getriggerd (ifNotExist actie)
• AuditIfNotExist – Als de policy toegepast wordt maar de change nog niet aanwezig is dan wordt deze als “not-compliant”weggeschreven in de activity log
• DeployIfNotExist – Als de policy uitgevoerd wordt op een object waarbij de change nog niet in-place is dan wordt de change uitgevoerd (i.p.v. dat het apparaat als incompliant wordt aangemerkt). DeployifNotExist wordt dus gebruikt om devices weer compliant te krijgen. Let op, deze policy moet resources aanmaken of changes uitvoeren en gebruikt hiervoor een managed identity.

Managed Identity

Een Managed Identity (vroeger Managed Service Identity / MSI) is een identity welke automatisch beheerd wordt in Azure en die gebruikt kan worden door b.v. een applicatie om credentials op te vragen in de Azure KeyVault. Op deze manier worden identiteiten en secrets nooit in de programmacode verwerkt en blijft deze veilig.

Een system-assigned managed identity wordt direct geactiveerd op een Azure Service Instance. De identiteit wordt vervolgens opgeslagen in AAD (trusted AD). Credentials worden vervolgens doorgegeven aan de instance. Wanneer de instance verwijderd wordt, wordt ook het managed ID verwijderd.

Een user-assigned managed identity wordt als een stand-alone Azure resource aangemaakt in de Azure AD. Nadat de identiteit is aangemaakt kan deze toegekent worden aan 1 of meer Azure service instances. De user-assigned managed identity wordt niet automatisch verwijderd en moet handmatig beheerd worden.

Shared Responsibility Model

Het Shared Responsibility Model gaat in op het gegeven dat meerdere partijen een gedeelde verantwoordelijkheid hebben als het gaat over beveiliging. Wanneer je een VM in Azure afneemt heeft Microsoft een gedeelde verantwoordelijkheid maar ook de eindgebruiker.

De eindgebruiker (beheerder) is altijd verantwoordelijk voor:

• Data
• Endpoints
• Accounts
• Access Management

Azure Monitor

De Azure Monitor geeft inzicht in de performance van je Azure resources door gebruik te maken van verschillende input data. Denk aan performance, code functionaliteit, OS monitoring, Subscription health, Azure services etc. Zie de monitor als een algemene health monitor op basis van metrics. Azure monitored diverse data zelf maar deze kun je uitbreiden door meer sources toe te voegen zoals het toevoegen van een agent (Windows / Linux) of het aanzetten van diagnostics. De data die de monitor verzameld kunnen bestaan uit 2 type, namelijk logs en metrics. De montor geeft je ook toegang tot AutoScale en het aanmaken van AutoScale policies. Dus wanneer zijn er meer of minder resources nodig en op basis van wat (b.v. CPU).

Om data vanuit de monitor in een externe tool zoals een SIEM te krijgen wordt de data “ge-piped” naar de event hub. Data kan weer uit de event hub gepulled worden door andere tools zoals b.v. een SIEM zoals Microsoft Azure Sentinel.

De event hub is een streaming platform en event ingestion service welke data kan opslaan en transformeren.

Om Microsoft Azure Sentinel te gebruiken moet je een Log Analytics Workspace hebben. Er zijn 4 manieren waarop logs en metrics van Azure services verzameld in je Analytics Workspace:

• Vanuit Azure Diagnostics naar Log Analytics
• Vanuit Azure Diagnostics naar Azure Storage naar Log Analytics
• Via Azure Services Connectors
• Via scripts die data verzamelen en dan naar Log Analytics posten

Een Log Analitics Workspace kan alleen gebruikt worden door diensten die zich binnen dezelfde region en dezelfde resource group bevinden als de Log Analytics Workspace.

Azure Networking

Azure Load Balancer kent 3 manieren om te kijken of een service online en healthy is om er verkeer naartoe te sturen. Als de destination niet reageert zal de load balancer stoppen om verkeer naar die server te routeren.

• Guest Agent Probe (alleen PaaS VM’s)
• HTTP Custom Probe – HTML op basis van een TCP ACK respond – Elke 15 sec – overwrite Guest Agent Probe
• TCP Custom Probe – je eigen poort definieren

Elk outbound verkeer vanuit een load balancer gaat naar buiten via Source NAT (SNAT) op basis van het zelfde virtuele IP als het inkomende verkeer. Hier kunnen we gebruik maken van VIP’s (adresgroepen op basis van naam) waardoor we gemakkelijk kunnen upscalen en downscalen en waardoor we gemakkelijk disaster recovery kunnen uitvoeren door de VIP toe te wijzen aan een andere pool.

Uitgaand UDP verkeer (vanuit de VM’s) wordt terug naar binnen gerouteerd middels Full Cone NAT waarbij iedere request een eigen unieke poort krijgt waar terug naartoe gemapt wordt. Als je dienst veel uitvragen doet is het raadzaam om een public IP te koppelen om port exhaustion tegen te gaan.

Azure Traffic Manager helpt bij het load balancen van verkeer tussen verschillende regio’s en werkt op basis van priority rules. Traffic Manager werkt op basis van DNS en is geen proxy (dus ziet het verkeer niet welke op en neer gestuurd wordt). Azure Traffic Manager kent load balancing, high availability, low latency detection, maintenance without downtime, external non-azure endpoints.

Forced Tunneling is een methode die gebruikt kan worden voor b.v. traffic inspection. Al het uitgaande verkeer wordt met Forced Tunneling terug gerouteerd naar de on-premise infrastructuur (b.v. door de firewall).

Om een Azure netwerk te koppelen met een on-prem netwerk kun je gebruik maken van:

• Point-to-Site VPN
• Site-to-Site VPN
• ExpressRoute (gaat niet over het internet / is dedicated)

Laten we een load balancer aanmaken:

1. Laat Azure Powershell werken op een specifieke subscription:

Set-AzureRmContext -SubscriptionId 689b6a6b-c6e5-4409-be4e-a2i9p00456877r

2. Maak een resource group:

New-AzureRmResourceGroup -ResourceGroupName “myResourceGroupLB” -Location "WestEurope"

3. Maak een extern IP aan:

$publicIP = New-AzureRmPublicIpAddress -ResourceGroupName“myResourceGroupLB” -Location "WestEurope" -AllocationMethod “Static”-Name "myPublicIP"

4. Maak een front-end (internet facing) IP aan voor de load balancer:

$frontendIP = New-AzureRmLoadBalancerFrontendIpConfig -Name“myFrontEnd” -PublicIpAddress $publicIP

5. Maak een BackEnd adrespool aan waar de VM’s op connecten:

$backendPool = New-AzureRmLoadBalancerBackendAddressPoolConfig-Name “myBackEndPool”

6. Maak een healthprobe aan op poort 80 die om de 16 seconde controleerd en een verlies van 2 probes mag hebben.

$probe = New-AzureRmLoadBalancerProbeConfig -Name“myHealthProbe” -RequestPath healthcheck2.aspx -Protocol http -Port80 -IntervalInSeconds 16 -ProbeCount 2

7. Nu maken we een load balancing rule aan die balanced op poort 80.

$lbrule = New-AzureRmLoadBalancerRuleConfig -Name“myLoadBalancerRule” -FrontendIpConfiguration $frontendIP 
-BackendAddressPool $backendPool -Protocol Tcp -FrontendPort 80 -BackendPort 80 -Probe 
$probe

8. Nu maken we 2 NAT rules aan voor RDP verkeer over poorten 4221 en 4222:

New-AzureRmLoadBalancerInboundNatRuleConfig -Name myLoadbalancerRDP1 -FrontendIpConfiguration 
$frontendIP -Protocol tcp -FrontendPort 4221 -BackendPort 3389 
 
New-AzureRmLoadBalancerInboundNatRuleConfig -Name myLoadbalancerRDP2 -FrontendIpConfiguration 
$frontendIP -Protocol tcp -FrontendPort 4222 -BackendPort 3389

9. Tenslotte maken we een load balancer aan:

$lb = New-AzureRmLoadBalancer -ResourceGroupName ‘myResourceGroupLB’ -Name ‘MyLoadBalancer’ -Location ‘WestEurope’ 
-FrontendIpConfiguration $frontendIP -BackendAddressPool $backendPool -Probe 
 
$probe -LoadBalancingRule $lbrule -InboundNatRule $natrule1,$natrule2

DDoS Beveiliging

Er zijn bepaalde richtlijnen om DDoS aanvallen te mitigeren zoals:

• Hou de “5 pillars of Software Quality” in acht.
• Maak het mogelijk om horizontaal te schalen
• Maak gebruik van meerdere instances
• Maak gebruik van security-enhanced designs en built-in capabilities
• Maak de aanvalshoek kleiner / sluit onnodige poorten en services
• Gebruik Azure DDoS Protection

Er zijn 2 soorten DDoS tiers. Basic en Standard. De standard tier biedt meer beveiliging voor network resources (zoals public IP’s, load balancers en application gateways)op basis van traffic monitoring en machine learning en de Basic tier is ook van toepassing op de App Service omgeving (Standard niet). De standaard tier kan de volgende aanvallen het hoofd bieden:

• Volume Attacks (network flooding)
• Protocol Attacks (exploiting protocol weaknesses zoals de SYN flood)
• Resource Layer (application layer) attacks – verstoren van data transmissie tussen hosts

De Basic DDoS Protection Tier is standaard ingeschakeld en biedt bescherming voor de Azure Region (Standard op basis van toepassing). De Basic tier kent minder logging als de standard tier maar is wel gratis.

Host Security met Security Center

Je kunt Microsoft Anti Malware installeren op een host en de VM uitbreiden met de anti-malware extensie zodat de status van de anti malware software gemonitored kan worden in Azure Monitor.

De resource manager is de Azure API die resources aanmaakt, beheerd en monitored.

• Resource provider – Een service die Azure resources aanmaakt zoals Microsoft Compute en Microsoft Sotorage. De Resource Provider zet een Resource Manager JSON bestand om in een REST API.
• Resource Manager Template – Een JSON bestand welke via de Resource Provider API op een gestructureerde en herhaalbare manier resources uit kan rollen.
• Declarative Syntax – Syntax welke beschrijft hoe je iets wilt configureren zoals een Resource Manager JSON Template.

Azure Security Center helpt bij het voorkomen, detecteren en reageren op bedreigingen en de controle over de beveiliging van uw Azure-bronnen. Beveiligingscentrum helpt VM-gegevens in Azure te beschermen door inzicht te bieden in de beveiligingsinstellingen van uw VM’s. Wanneer Security Center uw VM’s beveiligt, zijn de volgende mogelijkheden beschikbaar:

• OS-beveiligingsinstellingen met de aanbevolen configuratieregels
Inzicht in systeembeveiligingsupdates en essentiële updates die ontbreken
• Aanbevelingen voor endpoint protection
• Validering van disk encryption
• Beoordeling en remediëring van kwetsbaarheden
• Threat Detection

Om aanbevelingen te krijgen moet je er eerst voor zorgen dat Security Center data kan analyseren. Om dit te doen moet je “Data Collection” inschakelen. Vervolgens kun je security policies definiëren. Security Center maakt deze aanbevelingen op verschillende geavanceerde manieren zoals:

• Integrated Threat Intelligence (op basis van global security threats zoals know hackers)
• Behavioral Analytics (op basis van patronen)
• Anomaly Detection (op basis van statistical profiling voor het bouwen van een baseline en detecteren van afwijkingen)

Security Center geeft de volgende meldingen over Endpoint Protection:

• Endpoint Protection niet geinstalleerd op Azure VM’s
• Endpoint Protection niet geinstalleerd op Non-Azure Computers
• Endpoint Protection – Signature out of date
• Endpoint Protection – Geen real-time protection
• Endpoint Protection – Rapporteerd niet
• Endpoint Protection – Onbekend

Het is belangrijk om te weten dat Security Center in 2 varianten aanwezig is. De gratis tier en de standard pricing tier. De gratis tier kent alleen het beveiligingsbeleid, evaluatie en aanbevelingen voor virtuele machines en app-services. Al je kiest voor de standaard pricing tier dan krijg je echter veel meer opties. De eerste 30 dagen is deze tier overigens gratis. Vervolgens kun je gebruik maken van geavanceerdere logging, JIT (Just-In-Time), advanced detectie, threat informatie, regelgeving naleving e.d. Dit kun je vervolgens doen op meer onderdelen zoals b.v. SQL, MySQL, Storage en IoT devices. Ook kun je security workloads uitbreiden naar niet-Azure omgevingen (hybride omgevingen).

Azure Update Management

Azure Update Management is speciaal ontwikkeld om machines up-to-date te houden en kost alleen maar de opslag van de log bestanden. Azure Update Management is een Azure Automation tool op basis van RunBooks. Computers die door Update Management worden beheerd maken gebruik van:

• Microsoft Monitoring Agent (MMA) for Windows or Linux
• PowerShell Desired State Configuration (DSC) for Linux
• Automation Hybrid Runbook Worker
• Microsoft Update or Windows Server Update Services (WSUS) for Windows computers

Met een update deployment kunnen meerdere machines tegelijkertijd worden geupdate onafhankelijk van hun region of resource group. Wel belangrijk is dat er een Windows update deployment is die alleen toepasselijk is op Windows machines (met de juiste .NET installatie) en dat er een Linux update deployment is die alleen toepasselijk is op Linux (CentOS, Red Hat, SuSe en Ubuntu) machines is (met een Linux agent). Windows client OS systemen zoals Windows 7 en Windows 10 worden niet ondersteund.

Windows Credential Guard

Windows 10, server 2016 en 2019 bieden additionele beveiligingsmechanismes zoals Windows Credential Guard, Windows Device Guard en Windows Defender Application Control.

Windows Credential Guard is op basis van virtualisatie. Middels virtualization-based security enhancement worden “secrets” zoals NTLM password hashes, Kerberos authentication en app credentials geisoleerd zodat alleen privileged system software deze kan benaderen.

Windows credential guard zorgt voor de volgende beveiliging:

• Hardware Security Enhancement. NTLM, Kerberos en Credential Manager maken gebruik van Secure Boot
• Virtualization-based Security – Derived Credentials worden uitgevoerd in een virtueel beveiligde, van het OS afgeschermde omgeving.
• Betere beveiliging tegen Advanced Persistent Threats. Denk aan tools en malware welke op het OS (onder Admin credntials draaien) krijgen geen toegang tot de credentials.

Windows Device Guard

De techniek die gebruikt wordt om alleen toegang te verlenen aan de hoognodige applicaties en code. Met Device Guard en Application Control kan een systeem in volledige lock-down mode geleverd worden.

Azure Playbooks

Een Azure Sentinal Playbooks (onderdeel van Sentinal en Security Center) is een automatische actie die je kunt koppelen aan een specifiek event. Deze playbooks zijn gemaakt middels Azure Logic Apps. Je kunt dus zelf een workflow maken en deze binnen Sentinal gebruiken.

Security Baseline

Microsoft werkt samen met CIS voor het veiliger maken van hun netwerk. Zo bestaat er diverse off-shelf hardend Azure VM’s en hebben ze samen een baseline uitgebracht welke bestaat uit benchmarks / aanbevelingen. Deze baseline bestaat uit een 2-tal niveaus:

• Level 1 / L1 – Dit zijn de minimale settings waar ieder systeem aan moet voldoen. Deze settings zorgen (vrijwel) niet voor verstoring of minder functionaliteit.
• Level 2 / L2 – Aanbevelingen voor omgevingen die zeer secuur moeten zijn. Deze maatregelen kunnen de functionaliteit beïnvloeden.

Leer de CIS baselins m.b.t. de verschillende onderwerpen zoals IAM – Networking – Security Center, Storage etc.

Dataclassificatie

Pas dataclassificatie toe om op de juiste momenten gebruik te maken van de meest toepasselijke security maatregelen. Je kunt onderscheid maken tussen 2 soorten data namelijk “structured” zoals in een database en “unstructured” zoals losse documenten. Verder kan data zich in 3 verschillende fases bevinden. “At-Rest” – “In transit” en “In Process”.

Data Discovery & Classification in onderdeel van de Advanced Data Security opties en is speciaal voor het vinden en classificeren van data in Azure SQL databases.

Data Classificatie

Het is belangrijk om retentie policies te maken en handhaven zodat data tijdig verwijderd of ontoegankelijk gemaakt wordt wanneer deze niet meer nodig is.

Ir bestaat ook zogenaamde Immutable Storage & Retention voor Azure Storage Blob’s. Er zijn 2 soorten immutable policies (WORM’s / Write Once Read Many) die toegepast kunnen worden, namelijk “time-based” en “legal holds”. Als deze policies worden toegepast op een container zal de data (en ook alle nieuwe data) getransformeerd worden naar een immutable state. Bij een Time-Based policy zal de data zo lang worden bewaard als de gebruiker gespecificeerd heeft en bij een Legal Hold policy zal data weer beschikbaar (schrijfbaar) worden wanneer de policy wordt opgegeven dus wanneer de “legal hold” periode voorbij is (b.v. tijdens een gerechtelijke procedure). Ook kunnen beide policies op een container van toepassing zijn. Wanneer een Legal Hold actief is zal data pas worden verwijderd vanuit de retentie periode als de Legal Hold is opgeheven.

SQL Database Security

De SQL databases kunnen voorzien worden van additionele firewall rules. Server Firewall rules zijn van toepassing op alle databases binnen een SQL server. En Database Firewall Rules zijn alleen van toepassing op een specifieke database. Een Database Firewall Rule kan alleen gemaakt worden nadat een SQL Server Firewall Rule in-place is. Bij een inkomende connectie wordt eerst gekeken of het adres aanwezig is in een database specific rule en zo ja dan wordt toegang alleen verleend tot die database. Zo niet dan wordt gekeken of het IP voorkomt in de allowed range van de SQL Server firewall rules. Zo ja dan wordt toegang verleend tot alle databases binnen de SQL server.

Alle SQL verbindingen gaan over poort 1433. Hou hiermee rekening op de firewall.

Maak een server firewall rule aan via Powershell:

New-AzSqlServerFirewallRule -ResourceGroupName "ResourceGroup01" -ServerName "Server01" 
-FirewallRuleName "Rule01" -StartIpAddress "192.168.0.198" -EndIpAddress "192.168.0.199"

En via CLI / Bash:

az sql server firewall-rule create -g ResourceGroup01 -s Server01 -n Rule01 --start-ip-address 192.168.0.198 --end-ip-address 192.168.0.199

De authenticatie van een SQL database kan op 2 manieren. Via SQL Authentication. Dit is via de gebruiksnaam en het wachtwoord welke je aangemaakt hebt tijdens het aanmaken van de SQL server. En via Azuree AD Authentication. Deze methode heeft de voorkeur. Hiervoor moet een nieuwe admin user met de juiste rechten worden aangemaakt.

CosmosDB authenticatie gaat via een HMAC hash die via 2 keys gemaakt kan worden. De master key en met resource tokens. Een hash gemaakt met de master key kan user en permission resources aanmaken en bewerken. Met een resource token kun je gericht toegang geven op een specifiek gedeelte.

Auditing, voor het bewaren van een legal audit trace kan ingeschakeld worden via een auditing policy op de database. Als er al een auditing policy op de database blob actief is dan wordt de database al geaudit en is het niet nodig om hem op database niveau in te schakelen. Het kan wel, maar dan bestaan we 2 audit databases met dezelfde info. Dit is alleen zinvol als je een andere storage wilt gebruiken voor opslag voor audits van een specifieke database of als je op die database een andere retentiepolicy wilt toepassen. Wanneer je auditing logs opslaat moet je deze opslaan op een storage account. Hiervoor gebruik je een storage access key. Wanneer je de key ververst moet de audit policy opnieuwe worden opgeslagen. De juiste methode om dit te doen is:

• Open auditiging tab en zet “Storage Access key” op “Secundary”
• Open de Storage Configuration Page. Regenerate de primary access key (via Access keys Blade)
• Open auditiging tab en zet “Storage Access key” op “Primary”
• Open de Storage Configuration Page. Regenerate de Secondary Access Key (ter voorbereiding op de volgende key-recycle actie).

Op databases kan ook threat Detection worden toegepast voor het herkennen en notificeren bij “vreemd SQL gedrag”. Denk aan vulnerabilities, SQL Injections, Anomalous Access en “vreemde” queries. Threat Protection is onderdeel van ADS (Advanced Data Security). ADS 3 database beveiligingstechnieken zoals:

• Data Discovery en Classification
• Vulnerability Assessment
• Threat Detection

Ook de data in een database kan door Azure beveiligd worden. Zo kent SQL de “Always Encrypted” methode om gevoelige data in een database nooit als plain-tekst op te slaan. Deze methode hashed de data welke vervolgens alleen door de applicaties gelezen kan worden die over de juiste sleutels beschikken. Om data uit de database te halen en te decrypten moet 2 zaken beschikbaar zijn. De “column encryption key” welke de sleutel is welke de data in een versleutelde kolom versleuteld en de “column master key” welke 1 of meerdere “column encryption keys” versleuteld. Always Encrypted kan geïmplementeerd worden via SSMS, Powershell en T-SQL. Om het proces met Powershell uit te voeren doen we het volgende:

1. Importeer de SQL Server module:

Import-Module "SqlServer"

2. Verbind met de database via SMO:

$serverName = "<Azure SQL server name>.database.windows.net" 
 
$databaseName = "<database name>" 
 
$connStr = "Server = " + $serverName + "; Database = " + $databaseName + "; Authentication = Active Directory Integrated" 
 
$connection = New-Object Microsoft.SqlServer.Management.Common.ServerConnection $connection.ConnectionString = $connStr 
 
$connection.Connect() 
 
$server = New-Object Microsoft.SqlServer.Management.Smo.Server($connection) 
 
$database = $server.Databases[$databaseName]

3. Laat de Column Master Keys zien

Get-SqlColumnMasterKey -InputObject $database

4. Maak een SqlColumnMasterKeySettings object welke informatie bevat over de Column master Key Location:

$CMKSettings = New-SqlAzureKeyVaultColumnMasterKeySettings -KeyUrl "https://myvault.vault.contoso.net:443/keys/CMK/4c05f1a41b12488f9cba2ea964b6a700"

5. Maak metadata van de Column Master Key in de database:

$CmkSettings = New-SqlAzureKeyVaultColumnMasterKeySettings -KeyUrl "https://myvault.vault.contoso.net:443/keys/CMK/4c05f1a41b12488f9cba2ea964b6a700" 
 
PS C:\> New-SqlColumnMasterKey "CMK1" -ColumnMasterKeySettings $CmkSettings

6. Als de Column Master Key opgeslagen is in de Azure Key Vault autenticeer dan op Azure:

Add-SqlAzureAuthenticationContext -ClientID ad34ca5a-a479-4cf4-b166-a2177b32d33e 
-Secret YU!KaoUa/JI8gvf6wT0p4m9AQE+sGB6oFY/iUdk2DHk= -Tenant "41fb6cc6-96f4-479d-bafd-a2e4810eb100

7. Genereer een nieuwe Column Encryption Key, versleutel deze met de Column Master Key en maak Column Encryption metadata aan in de database.

New-SqlColumnEncryptionKey -Name "CEK1" -ColumnMasterKeyName "CMK1"

Storage Security
Elke aanvraag op een storage onderdeel moet geautoriseerd worden. Dit kan middels:

• AzureAD
• Shared Keys
• SAS (Shared Access Signatures) – Alleen van toepassing op een onderdeel met specifieke rechten binnen een specifieke tijdsspanne.
• Anonymous Access – Alleen voor containers en blobs

Het is aan te raden om zoveel mogelijk AzureAD authenticatie te gebruiken. Als dat geen optie is dan is SAS the next best thing.

Storage Access keys zijn gebaseerd op het root password van het storage account en worden gebruikt door andere applicaties om toegang tot de storage te verkrijgen. Gebruik de Storage Keys niet voor andere doeleinden en deel deze nooit met anderen.

Er bestaan 2 soorten SAS tokens, Service en Account. Een Service SAS geeft toegang tot 1 storage onderdeel zoals b.v. Blob, Queue, Table of File service. Een Account SAS kan toegang geven tot meerdere onderdelen en kent meerdere soorten settings zoals het instellen van toegangsrechten en properties zoals GET/SET.

Naast versleuteling op storage niveau kunnen ook separate disks voorzien worden van Bitlocker versleuteling. Deze versleuteling zorgt ervoor dat VM’s en data disks at-rest versleuteld zijn en dat de VM’s booten met keys en policies die door de gebruiker beheerd worden. Om een bestaande VM te versleutelen gebruiken we het “Set-AzVMDiskEncryptionExtension” Powershell commando:

$KVRGname = 'AZ500'; 
 
$VMRGName = 'AZ500'; 
 
$vmName = 'Srv-Work'; 
 
$KeyVaultName = 'KeyVault1-az500'; 
 
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname; 
 
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri; 
 
$KeyVaultResourceId = $KeyVault.ResourceId; 
 
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGname -VMName $vmName 
-DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId;

Azure HDInsights Security

HDInsights maakt het mogelijk om analyses uit te voeren op populaire open-source frameworks zoals Apache, Hadoop en Spark. Om HDInsights beter te beveiligen kan de administrator een HDInsights cluster aanmaken waar alleen geautoriseerde personen toegang toe krijgen. Vervolgens kan RBAC toegepast worden om specifieke HDInsights onderdelen toegankelijk te maken alsmede auditing policies. Ook kan een VPN Gateway opgezet worden zodat toegang alleen maar mogelijk is via de VPN wat feitelijk de eerste mitigerende maatregel is. Azure HDInsights kan opgeslagen worden op Blob Storage en op Azure Data Lake Storage Gen1 en Gen2. Beide kunnen data versleutelen wat uiteraard aan te raden is.

Certificaten

Azure certificaten komen in de vorm van x.509 v3 en kunnen signed zijn door een ander vertrouwd certificaat. Certificaten worden gebruikt voor Azure Cloud Services (Service Certificates) en de management API (Management Certificates). Azure certificates kunnen zowel een public als een private key bevatten en worden opgeslagen in de Azure key Vault.

Maak een self-signed certificaat met Powershell:

$policy = New-AzureKeyVaultCertificatePolicy -SubjectName "CN=www.contoso.com" -IssuerName Self -ValidityInMonths 12
 
Add-AzureKeyVaultCertificate -VaultName $vaultName -Name $certificateName -CertificatePolicy $policy

App Frond Door (AFD)

App Front Door is speciaal ontwikkeld om web applicaties zo beschikbaar mogelijk te maken. AFD zorgt ervoor dat verbindingen naar de webapp gerouteerd worden met de mindste latency. AFD kijkt naar de meest optimale route en responsible node om de gebruiker a.s.a.p. van de app te voorzien. AFD werkt op layer 7 en gebruikt het anycast protocol met split TCP.

Azure KeyVault

We hebben het al een aantal keer over de Azure Key Vault gehad. Key Vault is bedoeld voor het opslaan van application keys, secrets en certificates maar is niet bedoeld als user password storage. Ook ondersteund KeyVault zogenaamde HSM (Hardware Security Modules) keys. Dit noemen we ook wel BYOK (Bring your Own key). HSM’s zijn FIPS 140-2 level 2 gevalideerd. Key Vault gebruikt de Thales nShield Family om deze keys te beschermen. Dit proces gaat als volgt:

• Genereer key op een offline werkstation
• Versleutel de key met een KEK (Key Exchange Key)
• Importeer de sleutel in de Azure Key Vault
• De KEK sleutel om je HSM sleutel te ontsleutelen is wederom versleuteld

Toegang tot de key vault wordt beheer op 2 planes, het management plane waar de keystore wordt aangemaakt en het data plane waar de keys / certificaten opgeslagen en gegenereerd worden. Iedereen die de keyvault benaderd moet geauthentiseerd zijn (AAD) en geautoriseerd zijn (RBAC). Op het data plane wordt ook nog de keyvault access policy toegepast om de data te beveiligen.

RSA keys van certificaten kunnen exporteerbaar gemaakt worden. RSA HSM Keys zijn nooit exporteerbaar.

Applicaties en services kunnen de key vault gebruiken om secrets uit op te vragen die ze noig hebben voor b.v. authenticatie of encryptie. Om dit te doen is het zaak dat er een managed identity aangemaakt wordt in AzureAD. Vervolgens zorg je er middels een RBAC role voor dat het service principal toegang heeft tot de key vault.

Nu gaan we een keyvault aanmaken in Powershell:

New-AzKeyVault -Name 'Contoso-Vault2' -ResourceGroupName 'ContosoResourceGroup' -Location 'East US'

Nu gaan we een secret toevoegen aan de keyvault. Eerst maken we een variabele met een secure string:

$secretvalue = ConvertTo-SecureString 'hVFkk965BuUv' -AsPlainText -Force

En nu voegen we hem toe aan de keyvault:

$secret = Set-AzKeyVaultSecret -VaultName 'ContosoKeyVault' -Name 'ExamplePassword' -SecretValue $secretvalue

Locks

Locks kunnen geplaatst worden op resources zoals b.v. resource groups. Er zijn 2 soorten locks namelijk “Delete” waarbij het niet meer mogelijk is om resources te verwijderen en “Read-Only” waarbij resources niet meer bewerkt of verwijderd kunnen worden. Als beide locks geactiveerd zijn dan telt de “Read-Only” lock. Locks worden doorgegeven naar onderliggende objecten. Een lock op een resource group zal alle objecten in die groep locken (ook resources die je later toevoegt). Om een lock te beheren moet je toegang hebben om de volgende acties uit te voeren: “Microsoft.Authorization/*” of “Microsoft.Authorization/locks/*”. Leden van de rommen “Owner” en “User Access Administrator” kunnen deze acties standaard uitvoeren.

AIP Labels

Labels ofwel AIP (Azure Information Protection Labels) kunnen handmatig worden toegevoegd aan een object (cloud en on-prem, voor on-prem is een client nodig). Deze labels kunnen voorzien zijn van condities en acties zoals het beveiligen van een document. Labels kunnen niet altijd worden toegevoegd. Niet alle documenten (zoals PDF Forms) en niet alle paden (zoals C:\Windows) worden ondersteund. Labels kunnen ook automatisch worden toegevoegd. Dit kan alleen op Office documenten, dus niet op b.v. *.txt documenten. Ook kunnen labels soms geadviseerd (dus niet enforced) worden. Deze recommended labels werken alleen in Office documenten na het opslaan van het document met uitzondering van Outlook (e-mails). Als (vooral bij automatic labeling) meerdere labels van toepassing zijn dan worden deze geëvalueerd volgens de volgorde waarop je deze in de policy hebt staan. Het label welke als laatste geëvalueerd wordt (last-matching label) wordt toegepast.

Azure Firewall

De Azure Firewall is een statefull firewall welke centraal aangemaakt wordt met een publiek IP adres. Dit zodat je on-prem firewall het verkeer van de Azure kan herkennen. Azure Firewall is volledig geïntegreerd met de Azure Monitor en kent nog meer voordelen zoals:

• Built-in High Availability (geen load balancer nodig)
• Cloud Scalability (peak traffic kost geen extra geld)
• Application Filtering Rules op basis van FQDN
• Network Traffic Filter Rules op basis van IP’s en poorten
• FQDN Tags – Sta bepaald verkeer toe op basis van een tag
• Outbound SNAT ondersteuning – Al het uitgaande verkeer krijgt het IP adres van de firewall
• Inbound DNAT (Destination NAT) ondersteuning. Als het inkomende verkeer krijgt het IP adres van de firewall.
• Azure Monitor Logging

Let op: de Azure Firewall heeft momenteel een issue met de Security Center (ASC) Just-in-Time (JIT) feature. Als er verbonden wordt met een machine via JIT en deze machine bevindt zich in een subnet met een user-defined route welke de firewall als gateway gebruikt dan werkt ASC JIT niet. Dit komt door asymetrische routering.

Network Security Groups (NSG) & Application Security Groups (ASG)

Een Network Security Group wordt gebruikt om network traffic rules af te dwingen op netwerk niveau. Hierin bepaal je dus op poort en directie niveau welk verkeer toegestaan en geweigerd wordt. NSG’s worden toegepast op een NIC of op een subnet. Het is altijd aan te raden om een NSG toe te passen op een subnet omdat je anders snel het overzicht verliest. Als een NSG wordt toegepast op een subnet is deze van toepassing op alle NIC’s of VM’s binnen dat subnet. Wanneer een subnet een security-zone an-sich is dan is het prima om hier NSG’s voor te gebruiken. Wanneer NIC’s of VM’s binnen een security zone toch een afwijkende netwerkconfig nodig hebben is het raadzaam om voor de afwijkingen ASG’s te gebruiken en geen NSG’s.

ASG (Application Security Groups) kunnen worden toegepast op een NIC’s van een virtuele machine. ASG’s kunnen worden toegepast op meerdere NIC’s en wordt dus gebruikt om machines binnen eenzelfde virtueel netwerk logisch te groeperen. ASG’s kunnen worden voorzien van een logische naam maar niet van poorten of directies. Binnen een NSG kun je een ASG gebruiken om verkeer wel of niet te roteren. Zo kun je een “Allow RDP” ASG maken en deze koppelen aan de NIC’s die dvia RDP bereikbaar moeten zijn. Je koppelt de ASG niet op de NIC’s die niet via RDP bereikbaar moeten zijn. Vervolgens zorg je er in de NSG van het subnet voor dat je RDP inbound toestaat op de “Allow RDP” ASG. Op deze manier kun je de veiligheid op basis van machine(s) instellen ongeacht hun subnet.

NSG’s en ASG vervangen niet de firewall functionaliteit of andersom. De Firewall biedt meer functies (zoals monitoring, SNAT en DNAT) en zal meestal gebruikt worden voor border-security.

Kubernetes en Docker

Ook wordt er aandacht besteed aan Kubernetes (K8s) en Docker. De basis voor dit is een container. Een container is een gevirtualiseerde functie zoals b.v. een app. In tegenstelling tot een virtuele machine draait een container niet zijn eigen OS en middleware maar is de container volledig geprogrammeerd om zijn functie uit te voeren. Een container kan als het ware opgepakt worden op locatie A en zonder problemen geplaatst worden op locatie B en weer verder draaien. Een container gebruikt niet de resources van een volledig virtueel systeem maar alleen de resources die het nodig heeft. De container tool die deze resources verdeelt en waar containers op draaien is Docker of soortgelijke tool zoals b.v. “rkt“. Docker maakt het mogelijk om containers te maken, draaien en managen. De Docker container draait echter op 1 host (of in Azure). Kubernetes kan als laag over deze Docker hosts gebruikt worden om vervolgens container provisioning, networking, load balancing, security en scaling te automatiseren over de verschillende docker hosts. Zo’n cluster heet een Kubernetes cluster. Docker kent overigens ook zijn eigen technologie onder de naam “Docker Swarm”

In Azure kunnen we een eigen Kubernetes cluster opzetten. Tijdens het opzetten van het cluster bepaal je het aantal nodes en de node size. De node size kun je na het aanmaken niet meer vergroten. Wel kun je het aantal nodes veranderen. Ook moet een service pricipal worden aangemaakt alsmede DNS records voor het cluster.

Het aanmaken van een AKS (Azure Kubernetes Service) Cluster via Bash:

az aks create --subscription 689b6a6b-c6e5-4409-be4e-01a6236daaa7 -g AZ500 -n alamo --node-count 3 --generate-ssh-keys --no-wait

Tijdens het aanmaken van een AKS cluster wordt er ook een service principal aangemaakt. Deze kun je gebruiken om b.v. te authentiseren op een Azure Container Registry (ACR). Om dat te doen moet je een AAD Role Assignment aanmaken welke de service principal toegang geeft tot het ACR register.

Een individuele container kun je aanmaken of importeren via de Azure Container Instances functie. Een container aanmaken via de CLI:

az container create -g AZ500 --name helloworld2 --image mcr.microsoft.com/azuredocs/aci-helloworld:latest --ports 80 443 --dns-name-label helloworld2az103

Je kunt uiteraard ook Docker containers op een VM plaatsen. Om deze docker containers toegang te geven tot Azure resources zoals storage, netwerk en databases moet de VM voorzien worden van een speciale plug-in. De zogenaamde CNI (Container Network Interface) plugin. Deze plugin ondersteund zowel Windows als Linux platforms.

De “Azure Container Registry” is een Azure onderdeel waarin je privé containers kunt plaatsen en managen om later te deployen of te gebruiken in Kubernetes.

Het aanmaken van een Azure Registry:

az acr create --resource-group AZ500 --name AzureContReg--sku Basic

Vervolgens kunnen we inloggen op het register om daarna een image erin te plaatsen:

az acr login --name AzureContReg

En nu taggen we een (nieuwe) image en halen we een image binnen op de local Docker environment:

docker tag hello-world AzureContReg /hello-world:v1 
 
docker pull hello-world

En tenslotte plaatsen we het image in ons register (ACR):

docker push AzureContReg/hello-world:v1

Nu het image in het register staat verwijderen we hem op de local Docker environment:

docker rmi AzureContReg/hello-world:v1

Alle repositories (images) in je register bekijken doe je als volgt:

az acr repository list --name AzureContReg --output table

Containers kunnen soms onveiliger zijn dan VM’s omdat ze dezelfde resources delen met andere containers en niet user-gebonden zijn. Dit wil zeggen dat een root user in container A ook root access heeft als deze uit de container kan breken. De volgende maatregelen zijn aan te raden om containers te beveiligen:

• Gebruik Vulnerability Management binnen de container lifecycle
• Scan voor kwetsbaarheden alvorens je een app naar eht register pushed en blijf vervolgens ook scannen
• Map image vulnerabilities naar draaiende containers
• Zorg ervoor dat alleen approved images gebruikt worden
• Laat alleen goedgekeurde registraties toe
• Blijf gedurende de lifecycle de integriteit monitoren
• Verklein de attack surface door onnodige privileges te verwijderen
• Whitelist alleen de files die in de container mogen draaien
• Pas netwerk segmentatie toe bij draaiende containers
• Monitor container activiteit en gebruikerstoegang
• Log alle admin activiteit binnen een container

Nu gaan we met Powershell een container aanmaken (let op dit is een gewone container met een IIS Nanoserver):

New-AzContainerGroup -ResourceGroupName myResourceGroup -Name mycontainer 
-Image mcr.microsoft.com/windows/servercore/iis:nanoserver -OsType Windows -DnsNameLabel aci-demo-win

Kubernetes is een onderdeel uit de Microsoft serverless computing model.

Serverless Computing

Microsoft Azure helpt in het “Serverless Computing” model door het wegnemen van servers, acties uitvoeren van events en micro-billing. Tools die Azure hiervoor biedt zijn o.a.:

• Azure Function – Business Logic – Geschreven in iedere taal zoals C#, F# en Javascript.
• Logic Apps – Azure Workflows op basis van Events
• Kubernetes

Conclusie

Het leren voor het AZ-500 Examen was nog prima te doen. De stof is beperkter dan de stof voor AZ-100 en AZ-101 en er zit ook nog een bepaalde overlap in. Zeker voor iedereen die al het e.e.a. met Azure doet is niet alles helemaal nieuw meer. Het grootste probleem was misschien nog wel het plannen van mijn examen. Tegenwoordig telt de regel dat het veld “Legal Name” op de Pearson Vue pagina overeen moet komen met de namen op je ID bewijs. Op zich helemaal niet zo erg maar… mijn Legal Name veld stond op “Jarno Baselier”. En Jarno is mijn roepnaam maar geen geboortenaam. En op mijn officiele ID documenten staan mijn geboortenamen en geen Jarno. Dit veld kun je zelf niet aanpassen en dat moet door Microsoft gebeuren. In eerste instantie vragen ze een kopie ID bewijs maar dat was in mijn geval niet voldoende. Dit was niet voldoende bewijs dat Jarno en de namen op het ID bewijs 1-en-dezelfde persoon waren. Vervolgens moest ik een notarieel stuk hebben (ondertekend door een notaris) om te bewijzen dat ik wel een-en-dezelfde persoon ben. Helaas brengt dit nogal wat kosten met zich mee. Het laat je ook wel nadenken. Mijn hele leven heet ik al Jarno… maar als het erop aankomt kan ik nooit bewijzen dat ik “Jarno” heet. Raar!? Daarnaast kennen ze in Amerika het systeem van een “roepnaam” helemaal niet. Een lastige situatie die er uiteindelijk voor zorgde dat ik een ander Microsoft account heb aangemaakt om mijn huidige en toekomstige examens te boeken. Dan maar 2 accounts waarin mijn certificeringen aanwezig zijn. Het was niet anders.

Het examen bestond uit slechts 39 vragen waarvan de meeste meerkeuze vragen en 1 case waar meerdere vragen over gesteld werden. Ook waren er ongeveer 10 drag-en-drop vragen. Ik kreeg 210 minuten de tijd voor het examen en ben gelukkig geslaagd. Het examen was moeilijker dan verwacht en heb diverse comments bij de vragen gezet. Je kun na je examen bij elke vraag een comment plaatsen. Al met al waren er vragen die voor mij het examen extra moeilijk maakte. Moeilijker dan aanvankelijk verwacht. Vragen die in de stof globaal aan bod kwamen en tijdens het examen toegepast moesten worden in een complexe infrastructuur. Vragen waar soms 2 antwoorden goed konden zijn afhankelijk van het achterliggende scenario welke er niet bij verteld stond en dubbele vragen met een ander antwoord. Zo kreeg ik 3 dezelfde vragen met 3 verschillende antwoorden. Natuurlijk was het antwoord op 2 vragen fout en op 1 vraag goed. Maar hier 1 fout in maken betekend wel 3x een vermindering in je punten. Dit soort vragen konden beter samengevat worden in een multiple choice vraag. Al met al geslaagd met een dikke 7… maar dus toch maar net met mijn voetjes over de sloot (want 700 punten is het minimum).

Met Azure en moderne SaaS, PaaS en IaaS toepassingen wordt de rol van de beheerder anders. Minder diepgaand op code maar zeker niet altijd makkelijker. Het AZ-500 examen bewijst dat er nog heel veel te leren is over optimalisatie (van security) en van de mogelijkheden en uitdagingen van het platform. De rol van de systeembeheerder veranderd… maar wordt zeker met de moderne toepassingen niet overbodig. De AZ-500 certificering en een mooi certificaat om te halen en te bewijzen dat je over een aantal moderne skills beschikt. Ik ben er i.i.g. erg blij mee.

Hopelijk helpen mijn aantekenen jou ook bij het halen van je certificering. Heel erg veel succes ermee. En als mijn aantekeningen geholpen hebben… laat het dan even weten. Altijd leuk. Geef een like of deel mijn post op je website of sociale kanalen. Dat zou erg tof zijn! Dankjewel!