MS Certificering: AZ-204, deel 12

Ingediend door Dirk Hornstra op 15-dec-2021 11:18

Ik dacht dat ik alle blokken op de site van Azure zelf had gevolgd en dat ik dus klaar was met dat deel voor AZ-204. Maar toen ik wilde controleren welke eisen er in het PDF document staan en ik nog even naar het overzicht ging: link, zag ik dat ik nog 2 "learning paths" moet afronden, waarvan alle 6 modules van Deploy a website to Azure with Azure App Service: link en ook nog 4 van de 7 modules van Secure your cloud data: link moest uitvoeren (schijnbaar heb ik ooit al 3 gedaan).

Komt het dan nooit af? :D

Laat ik de chronologische volgorde aanhouden, eerst Deploy a website to Azure with Azure App Service: link.

Azure biedt je de mogelijkheid om snel op verschillende manieren je projecten online te brengen. Github, Azure DevOps, maar ook in een IDE als Eclipse en  IntelliJ IDE voor Linux. In dit blok ga je in je eigen IDE bezig. De site biedt je de keuze uit Eclipse, Intellij IDEA, Visual Studio Code of Visual Studio. Ik breng de meeste tijd door in Visual Studio en daarna voor projecten die ook een koppeling met VUE hebben in Visual Studio Code. Voor dit blok ga ik Visual Studio Code gebruiken, ook omdat je dan meer handigheid krijgt met de terminal en de commando's. Via de marketplace kun je allemaal plug-ins, ook voor Azure vinden: link.

Via plug-ins zoeken we op Azure App Service en installeren deze: link. Daarmee heb je het eerste blok afgerond, eitje!

Door met de volgende module, Host a web application with Azure App Service: link.

We gaan een Azure App opzetten in de Portal. Zo noemt de site ook de "slots", dus dat je een "staging slot" en een "production slot" hebt die je om kunt wisselen. Je kunt CI/CD (continuous integration/continuous development) inzetten omdat Azure ondersteuning biedt aan Azure DevOps, GitHub, Bitbucket, FTP maar ook een lokale GIT repo op jouw development machine. En natuurlijk wordt de eigen Azure DevOps nog even gepromoot: "with Azure DevOps, you can define your own build and release process that compiles your source code, runs the tests, builds a release, and finally deploys the release into your web app every time you commit the code. All that happens implicitly without any need to intervene".

Goede integratie met Visual Studio voor deployment. En je kunt gebruik maken van de mogelijkheid om te up-/downscalen (meer RAM beschikbaar) of te out-scalen (load over meer machines verdelen).

Vervolgens zie je de velden die je moet kiezen bij het aanmaken van een App Service. Zo komt ook het operating system voorbij, keuze tussen Windows en Linux. Goede tip hier is dat als je voor Windows kiest, Application Insights meteen werken zonder dat je ervoor code hoeft aan te passen. Het werkt ook op Linux, maar daarvoor moet je dus wel code aanpassen.

We krijgen een korte uitleg hoe je een nieuw project maakt en hoe je deze in GIT toevoegt:


dotnet new mvc --name <YourAppName>

git init
git add .
git commit -m "Initial commit"

In dit geval gaan we in de Azure Cloud Shell wat commando's uitvoeren om een project op te zetten;


// eerst de .NET SDK installeren:
wget -q -O - https://dot.net/v1/dotnet-install.sh | bash -s -- --version 3.1.102
export PATH="~/.dotnet:$PATH"
echo "export PATH=~/.dotnet:\$PATH" >> ~/.bashrc

// nieuwe MVC applicatie aanmaken
dotnet new mvc --name BestBikeApp

// met dotnet run voeren we de app uit, in een andere cloud shell doen we:
curl -kL http://127.0.0.1:5000/
 

Je kunt op meerdere manieren de code live zetten, automatisch via Azure DevOps, Github, Bitbucket, OneDrive, DropBox of handmatig, via Git, az webapp up, az webapp deployment source config-zip (een .ZIP deploy), http://<your-app-name>.scm.azurewebsites.net/api/wardeploy (java web-deploy met WAR, met behulp van Kudu), Visual Studio, FTP(S).

We gaan vervolgens onze code die we hierboven gemaakt hebben deployen:


// eerst publish, dat zippen
cd ~/BestBikeApp
dotnet publish -o pub
cd pub
zip -r site.zip *

// daarna deploy
az webapp deployment source config-zip \
    --src site.zip \
    --resource-group naam-resource-groep \
    --name <your-app-name>

// hierna moet je een status 202 terug krijgen: dan is het gelukt.

Dat was dit blok, door met het volgende blok, Publish a web app to Azure with Visual Studio: link.

De voorbeeld-case hier is dat je bij een ski-resort werkt en via de site routes laat zien en kaartjes verkoopt. En je gaat het bouwen met .NET Core in Visual Studio.

We beginnen met het configureren van Visual Studio 2019. Je hebt hiervoor versie 16.6 of hoger nodig. In Windows kies je eerst de Visual Studio Installer, klikt Modify en zorg dan dat ASP.NET en web development en Azure development aangevinkt zijn. Installeer deze (als ze nog niet op je pc staan) en ga dan door.

Hierna start je VS 2019 op en maak je een nieuw ASP.NET Core web app project. Deze draai je lokaal, die moet in een latere stap naar Azure overgezet worden. Eerst volgt uitleg over Azure App Service. Hier kun je web-appliaties, REST API's en backend services laten draaien. .NET Core, .NET Framework, maar ook Java, Ruby, Node.js, PHP en Python. Een App Service plan regelt wat voor resources je kunt gebruiken, waar je resource staan en de pricing tier. Elk plan definieert region (west europe, etc.), aantal VM's, grootte van VM (small, medium, large) en pricing tier (free, shared, basic, standard, premium, premium v2, isolated).

We publiceren deze naar Azure. Vervolgens volgt nog wat uitleg over bestanden in de oplossing en uitleg over Razor, dat is allemaal bekende materie. Bestanden aanpassen, nogmaals publiceren en we zien de aanpassingen live staan. Geen rocket-science.

Door met het volgende blok, Stage a web app deployment for testing and rollback by using App Service deployment slots: link.

In dit blok gaan we het hebben over een web-applicatie die eigenlijk niet "down" mag zijn, ook niet tijdens een update. En waarbij het mogelijk is om "snel naar de oude versie terug te gaan" als blijkt dat je nieuwe code toch te "buggy" is. Hier komen de deployment/swap-slots in beeld.

Je kunt meerdere slots aanmaken, één daarvan is het production-slot en dat is wat de "normale bezoekers" te zien krijgen. De andere kun je gebruiken voor integratietesten, acceptatietesten en je kunt testen op belasting van het systeem. Een slot swap is direct doorgevoerd, dus je hoeft niet als bij een deploy te wachten. Elke instantie heeft een eigen URL. Met een swap heb je ook geen "cold start", maar door de swap is er een warm-up omdat er een request naar de root van de site gestuurd wordt. Dat moet er namelijk voor zorgen dat compilatie en caching taken afgerond worden.

Het aantal beschikbare swap-slots is afhankelijk van je tier. Heb je Free, Shared of Basic dan heb je er 0. Heb je Standard: 5, Premium: 20 en Isolated ook 20.

Als je een slot toevoegt kun je kiezen voor het klonen van de instellingen van een ander slot. Je neemt dan alleen de instellingen over, geen content. Als je dat wilt, moet je dat inregelen met GIT of een ander deployment strategie.

Er volgt nu een voorbeeld hoe je swap-slots inricht en hoe je zaken aanpast. Zo kun je met preview eerst zien wat er gaat gebeuren (swap-slot wordt bijgewerkt met productie-data: werkt het nog?) en zo ja, dan kun je de swap definitief maken. Je hebt ook Auto Swap, zodra je code pusht, wordt de boel automatisch geswapt. Deze optie is niet beschikbaar in App Service op Linux.

Omdat je minimaal een Standard abonnement moet hebben kun je dit niet testen met de Sandbox van Azure. Dus mocht je dit willen uitvoeren, dan moet je het met een eigen App Service doorlopen.

Door met het volgende blok, Scale an App Service web app to efficiently meet demand with App Service scale up and scale out: link.

De voorbeeld-case is hier dat een hotel een website heeft waarop mensen een kamer kunnen boeken en ook de details/informatie daarover kunnen terug kijken. In bepaalde periodes is het "super druk" en heeft de site het zwaar.

  • Free tier: 1 GB diskruimte, maximaal 10 apps, geen SLA. En compute quota van 60 minuten per dag.
  • Shared tier: maximaal 100 apps, geen SLA. En compute quota van 240 minuten per dag.
  • Basic tier: 10 GB diskruimte, geen limiet qua apps, apps kunnen uitschalen naar 3 instanties. SLA 99.95%.
  • Standard tier: 50 GB diskruimte, geen limiet qua apps, opschalen naar 10 instanties. SLA 99.95%
  • Premium tier: 250 GB diskruimte, geen limiet qua apps, opschalen naar 30 instanties. SLA 99.95%
  • Isolated: 1 TG diskruimte, geen limiet qua apps, opschalen naar 100 instanties. SLA 99.95%

Hier staan de specs en prijzen: link.

Niet elke tier wordt door elk OS ondersteund. Zo is er geen Shared tier voor Linux.

Om zelf te testen wordt dit voorbeeld GIT-project gebruikt: link.

Hierbij wordt een scale-out gedaan (extra instanties van jouw app-service) en een scale-up (zwaardere machine). Dit is niet met het sandbox-account te testen, hiervoor zul je met een eigen abonnement aan de slag moeten.

Door met het volgende blok, Deploy and run a containerized web app with Azure App Service: link.

We gaan een Docker container maken en deze opslaan in de Azure Container Registry (in een Storage Account). Deze kunnen we vervolgens gebruiken om via App Service een web-app online te zetten.

Container Registry is een Azure service waar je jouw Docker images kunt beheren, vergelijkbaar met Docker Hub. Voordeel van Azure is dat je meer controle hebt over wie jouw images ziet en mag/kan gebruiken. Je kunt je containers "signen". En op het moment dat een container image opgeslagen is, is deze geëncrypt.

Omdat Container Registry in Azure draait kun je de zaken ook deployen in het datacenter wat het dichtst bij je klant(en) in de buurt is. Container Registry is hoog schaalbaar. De Premium SKU biedt 500 GiB aan opslag.


// container registry aanmaken
az acr create --name <name-container-registry> --resource-group <resource-group-name> --sku standard --admin-enabled true

// container builden
az acr build --file Dockerfile --registry <name-container-registry> --image <image-name>

We gaan de stappen doorlopen en ook hier geldt dat het (helaas) niet met een sandbox-account getest kan worden. Dit voorbeeldproject wordt gebruikt: link.

Bij het aanmaken van een Web App kun je bij "Publish" kiezen voor "Docker Container". Op een volgend tabblad kun je dan aangeven dat deze uit de Azure Container Registry moet komen, welk image met welke tag gebruikt moet worden.

Een Web App in een App Service kan zich abonneren op een webhook van Azure Container Registry. Met de tasks feature van Container Registry kun je bij een wijziging van code de image opnieuw laten builden. Je kunt met een andere taak de Github repo laten monitoren om te zien of er wat aangepast wordt. Bij een App Service resource kun je op het tabblad Container settings "Continuous Deployment" aanzetten.

Dit is een voorbeeld van het aanmaken van een taak, je hebt hiervoor wel een access token van Github nodig.


az acr task create --registry <container_registry_name> --name buildwebapp --image webimage --context https://github.com/MicrosoftDocs/mslearn-deploy-run-container-app-service.git --file Dockerfile --git-access-token <access_token>

Aan het eind van de module worden nog een aantal links vermeld:

  • Container Registry: link
  • Use a custom Docker image for Web App for Containers: link
  • Tutorial: Build and deploy container images in the cloud with Azure Container Registry Tasks: link
  • Tutorial: Automate container image builds in the cloud when you commit source code: link
  • List of Azure CLI commands to manage private Azure Container Registries: link

 

En door met het laatste blok, Secure your cloud data: link.

De eerste module, Protect against security threats on Azure: link, heb ik (in het verleden?) al afgerond. Ik doe daar nu niets meer mee, maar plaats toch even de link, mocht ik dit later nog een keer willen doorlezen. En misschien moet jij die module nog wel doen :)

Door met de volgende module, Top 5 security items to consider before pushing to production: link.

We beginnen met Microsoft Defender for Cloud. Dat is een monitoring service die de boel zowel in de cloud als "on-premise" in de gaten kan houden.

  • Aanbevelingen, op basis van je configuraties, resources en netwerken.
  • Monitoren van security instellingen en automatisch vereiste security zaken instellen als nieuwe diensten online gebracht worden.
  • Continu monitoren van je diensten en automatisch "security assesments" uitvoeren om potentiële zwaktes te identificeren voor ze gebruikt worden.
  • Gebruik van Machine Learning om malware te detecteren en blokkeren voor deze op je diensten en virtuele machines geïnstalleerd wordt. Je kunt met "allowlist" instellen dat alleen jouw applicaties uitgevoerd mogen worden zodat andere software automatisch geblokkeerd wordt.
  • Analyseren en identificeren van potentiële inbound aanvallen, onderzoeken van bedreigingen en activiteit die na een hack plaatsvindt.
  • Just in Time control voor poorten (open op het moment dat het nodig is, direct dicht indien niet meer nodig) om de mogelijkheden om jouw systeem binnen te komen minimaal te maken.


Defender for Cloud maakt deel uit van de aanbevelingen van het Center for Internet Security: link.

Je hebt 2 smaken, een Free en een Standard tier. Free biedt security policies, assessments en aanbevelingen, Standard heeft een aantal robuuste features, waaronder "threat intelligence". Ook hier geldt dat het niet in de sandbox uitgevoerd kan worden, dus wil je zaken testen/proberen, dan moet dit met een eigen account.

Als je Standard wil activeren, moet je een bepaalde rol hebben om dat te doen: Subscription Owner, Subscription Contributor of Security Admin. Standaard prijs is op dit moment (8 december 2021) 15 dollar per maand "per node".

We gaan door naar het volgende punt, "inputs en outputs". We zien een stukje SQL injection. Je moet altijd "alle input" controleren en valideren. Alles kan aangepast en gespoofed worden. En werkt met een allow-list. Dit mag wel, voldoet het niet: dan is het niet geldig. De site geeft een verwijzing naar validatie voor ASP.NET: link en naar deze post van OWASP over input: link.

En bij output, zorg dat het altijd "encoded en escaped" is, dit om Cross-Site Scripting (XSS) te voorkomen. Dit encoden wordt standaard al door ASP.NET gedaan, maar op sommige punten moet je daar toch nog even naar kijken. Better safe than sorry :) De site geeft nog even de link naar de OWASP XSS Prevention Sheet: link.

Secrets in Key Vault, als je credentials in config-bestanden (of erger: code) opslaat, is het niet echt een "secret". En zoals de site zegt, Key Vault is alleen voor credentials en dat type secrets, niet om bijvoorbeeld user-data in op te slaan. Daarvoor heb je andere zaken, een Azure SQL database met Transparent Data Encryption. Als je meer over Key Vault wil weten, dan wordt verwezen naar deze pagina: link.

Het volgende punt is Framework updates. Vaak maken we voor onze projecten gebruik van frameworks die door de community beschikbaar zijn gesteld. Maar hoe goed worden deze bijgehouden, bijvoorbeeld om bij te blijven qua security? De site verwijst hiervoor naar een complete module, "design for security", welke mij wel de moeite waard lijkt om een keer door te lopen: link.

Zo wordt het voorbeeld gegeven van Apache Struts, in de periode 2016-2017 werden hier 30 zwakke punten gevonden: link, waarbij klanten achter bleven met updaten en daar de prijs voor betaalden: link. De site geeft het voorbeeld van de release-notes pagina van .NET Core: link.

De site geeft nog een aantal links voor security features die .NET Core biedt:

  • Authentication -Identity Management: link
  • Authorization: link
  • Data Protection: link
  • Secure Configuration: link
  • Security Extensibility APIs: link


We gaan door met "dependencies", oftewel "afhankelijkheden". We gaan niet alles zelf maken, want dat is met de huidige grootte van applicaties, functionaliteit e.d. niet te doen. Hier gebruik je code-bibliotheken van 3e partijen voor. De OWASP heeft deze in de top 10 gezet: link. Als je zelf de boel wilt monitoren of wilt controleren of er problemen zijn met componenten die je gebruikt, Mitre heeft een CVE database online staan waar je dit kunt vinden: link.

En omdat elke tool welkom is nemen we ook even het overzicht mee wat de site ons geeft:


Tools voor statische analyse:


En zo komen we bij de samenvatting, die kort is, maar als je de punten gaat volgen wel tijd gaat kosten, namelijk Azure Cloud Defender gebruiken, inputs en output altijd controleren, geheimen sla je op in de Key Vault, je gebruikt altijd de meest up-to-date versie van je framework, inclusief security features en hetzelfde geldt voor de code-bibliotheken die je gebruikt.

Door met het volgende blok, Configure security policies to manage data: link.

In deze module krijgen we uitleg hoe we data in de cloud kunnen beschermen.

Digitale data heeft 3 soorten "state", at rest, in process of in transit. Als bepaalde data "vertrouwelijk" is en dus niet zomaar openbaar mag worden, moet het dus in al deze 3 mogelijke toestanden "vertrouwelijk" blijven.

"In rust"
Met behulp van Microsoft Azure Disk Encryption (link) kun je zowel Windows infrastructure as a service (IaaS) en Linux IaaS virtuele machines (VM) encrypten.
Bitlocker voor Windows, DM-Crypt voor Linux voor het OS en de data disks. Azure Storage en Azure SQL Database wordt standaard geëncrypt. Je kunt Azure Key Vault gebruiken om keys te bewaren die gebruikt worden voor toegang en het encrypten van je data. Op de Azure resource providers encryption model pagina kun je hier meer over lezen: link. En de tip: "encrypt je schijven voor je er vertrouwelijke data op wegschrijft".

"In beweging", dus gaat bijvoorbeeld via een netwerk van punt A naar B.
SSL, TLS, VPN, Azure VPN Gateway. Toegang vanaf werkstations on-premise met een Azure virtual netwerk: gebruik site-to-site VPN. Toegang van een enkel werkstation naar dat netwerk: gebruik point-to-site VPN. Als je grote hoeveelheden data over WAN wilt versturen, gebruik hiervoor Azure ExpressRoute. Hiermee kun je de data op applicatienniveau met SSL/TLS of andere protocollen encrypten voor extra bescherming. En als je via de portal van Azure acties uitvoert, dat gaat altijd via HTTPS. Ook de REST API's gaan via HTTPS.

Data Discovery wordt genoemd, dit een dienst in preview voor SQL Server, waarmee sensitieve data gevonden en gelabeld wordt. Het ondersteunt je om te voldoen aan privacy-eisen, kan afwijkende patronen detecteren, controleert toegang en versterkt het beveiligen van je data in een database. Azure heeft een speciaal pakket voor SQL Server: link. Het is niet bedoeld om je data "alleen maar" te beschermen maar voert ook dit uit:

  • Ontdek en geef aanbevelingen, dit systeem scant je database en identificeert kolommen met mogelijk vertrouwelijke data. Via de Azure Portal krijg je hier tips voor.
  • Labelen, op kolommen kun je een label "taggen", wat gebruikt kan worden voor geavanceerde auditing en beschermingsscenario's.
  • Query result set sensitivity, het resultaat wat je krijgt, hierop wordt automatisch berekend wat de gevoeligheid van die data is, bedoeld voor auditing (o.a. mag je dit wel zien?).
  • Zichtbaarheid, in een gedetailleerd dashboard in de portal kun je de status van je databases zien. Aanvullend kun je een Excel rapport downloaden voor compliance en auditing.


Classificaties hebben meerdere metadata attributen, labels voor de belangrijkste classificatie van de gevoeligheid van data welke in die kolom opgeslagen is en information types, aanvullende informatie, granulariteit van de data opgeslagen in de kolom. Zo kun je aangeven of een veld een geboortedatum is, IBAN nummer, BSN nummer, adres en zo de GDPR-zaken verwerken in het beheer van de structuur van je opslag.

Hierna volgt een voorbeeld. We maken in de sandbox een SQL Database aan.

SQL IP (SQL Information Protection) beschermt niet aleen je database, maar ook de data:

  • Tracken van database-events, wordt weggeschreven naar een audit-log in Azure Storage Account, Log Analytics of Event Hub.
  • Data discovery en classificatie, ingebouwd in Azure SQL Database, Azure SQL Managed Instance en Azure Synapse Analytics. Zorgt voor ontdekken, classificeren, labelen en rapporteren van gevoelige informatie in jouw databases.
  • Dynamic data masking, zorgen dat gevoelige informatie alleen getoond wordt aan de personen die het mogen zien. Ingebouwd in Azure SQL Database, Azure SQL Managed Instance en Azure Synapse Analytics.
  • Microsoft Defender for Cloud, scant je database en geeft je tips voor optimalisatie. Hiermee kun je ook Security Alerts instellen en monitoren.
  • Transparent data encryption, encryptie van je databases, backups en logs tijdens opslag zonder wijzigingen aan jouw applicatie(s) aan te hoeven brengen. Dit kun je per database instellen.


Vervolgens gaan we kijken naar data-retentie. Er zijn zaken die wettelijk verplicht zijn. Je moet dus eigenlijk wel een data retention policy hebben.

Blobs bieden de mogelijkheid tot Write Once Read Many (WORM) - Immutable Storage, waardoor de data voor een bepaalde tijdsinterval niet aan te passen en niet te verwijderen is.

Immutable storage biedt het volgende:

  • Tijd gebaseerde retentie policy ondersteuning, gebruikers stellen policies in om data voor een specifieke periode te bewaren
  • Legal hold policy support, als de tijdsduur niet bekend is, dan kan een legal hold ingesteld worden. Als deze actief is, dan kan een blob aangemaakt en gelezen worden, maar niet aangepast of verwijderd. Elke legal hold is gekoppeld aan een gebruikersgedefinieerde tag wat als ID gebruikt wordt (bijvoorbeeld een case ID).
  • WORM wordt door hot, cool en archive ondersteund. Hierdoor kun je de goedkoopste oplossing kiezen en daar je data opslaan.
  • Configuratie mogelijk op container-niveau, hier kun je tijd-gebaseerde policies, legal hold en meer onderhouden. Deze zijn dan actief voor alle blobs in de container, zowel bestaande als nieuwe.
  • Elke container heeft een audit log, welke tot 5 tijd gebaseerde retentie-commando's voor locked tijd-gebaseerde retentie policies toont. Het log heeft een maximum van 3 logs voor retention interval extensies of tijd-gebaseerde retentie. Het log bevat het gebruikers ID, commando type, timestamp en retentie-interval. In verband met wettelijke eisen bevat het log de gebruikers ID, commandtype, timestamp en wettelijke hold tags.


Zo lang de container bestaat, zolang wordt het log ook bewaard, dit voldoet aan de wet: SEC 17a-4(f). Azure Activity Log toont een soort beperkte weergave van alle acties. Het is de verantwoordelijkheid van de gebruiker om de logs goed op te slaan.

We zijn bijna bij het laatste deel, data souvereiniteit. Data moet voldoen aan de voorwaarden van het land waar de data opgeslagen is. Als je gebruik maakt van paired regions (omdat je bang bent dat alle datacenters in een regio uit kunnen vallen), dan vallen beide regions binnen hetzelfde land. Uitzondering is Zuid Brazilië, waarbij een ander land de tweede regio bevat.

Bij paired regions gelden een aantal zaken;

  • Azure Compute (IaaS), je moet van tevoren resources inrichten, zie ook de link.
  • Azure Storage, Geo redundante opslag wordt standaard geconfigureerd bij aanmaken. Met GRS wordt data 3x in de primaire regio gerepliceerd en 3x in een paired region. Zie ook de link.
  • Azure SQL Database, je kunt hiermee asynchrone replicatie van transacties over elke regio in de wereld instellen, advies om het in een paired region te doen. Zie ook de link.
  • Azure Resource Manager, de RM biedt logische isolatie van componenten verspreid over regio's.


Er wordt minimaal een afstand van 300 mijl tussen de regionale paren ingesteld. Sommige diensten, bijvoorbeeld geo-redundant storage, zorgen automatisch voor replicatie naar de "paired region". Als er een wereldwijde crash is, dan is 1 van de paren het "belangrijkste" deel om weer online te brengen. Systeem-updates worden in paired regions sequentieel uitgevoerd, niet gelijktijdig. Dit voorkomt downtime, bugs. En in verband met de wettelijke regels wordt een pair in hetzelfde gebied geplaatst.

En voor de Europese Unie is dit ook verder uitgewerkt: link.

Door met het volgende onderdeel, Secure your Azure resources with Azure role-based access control (Azure RBAC): link.

Voor "identiteit en toegang" gelden 2 belangrijke zaken: als mensen het bedrijf verlaten, moeten ze niet meer bij accounts/zaken in de portal/cloud kunnen komen en de balans tussen autonomie en toezicht houden/het in beheer hebben van de digitale infrastructuur. Zo zou een developer wel een virtual machine mogen aanmaken, maar zou de configuratie van het virtuele netwerk in beheer zijn bij de "main admin". Azure Active Directory (Azure AD) en Azure role-based access control (RBAC) werken samen om dit mogelijk te maken.

Elke subscription heeft een Azure Active Directory. Als je zelf Active Directory hebt kun je met Azure Active Directory Connect de verbinding maken naar de Azure AD: link.

Op veel plekken in de portal zie je Access control (IAM), daar kun je precies zien wie "iets" mag en wat dat "iets" is. De rolstructuur bestaat uit 3 onderdelen, de security principal (wie), de definitie van de rol (wat) en de scope (waar). Een security principal hoeft niet 1 persoon te zijn, het kan een groep zijn, maar ook een app die toegang tot een ander onderdeel nodig heeft.

Standaard zijn deze 4 rollen beschikbaar (maar als je meer nodig hebt, kun je die zelf aanmaken):

  • owner, eigenaar: volledig toegang, kan ook anderen toegang geven.
  • contributor, "schrijver", "uitvoerder", kan resources aanmaken en beheren maar geen rechten aan anderen geven.
  • reader, lees-account, kan bestaande resources bekijken.
  • user access administrator, kan gebruikerstoegang tot resources configureren.


De scope geeft aan waar je rechten op geeft, op de hele management groep, subscription, resource groep of op een resource. Met Azure RBAC geef je door een rol iemand mogelijkheden/bevoegdheden, het allow-model (anders mag je het niet). Onderdeel van zo'n rol is ook de NotAction permissions. Zoals je met Contributor de Actions * hebt gekregen om zaken aan te maken, met NotAction is aangegeven dat jij bijvoorbeeld geen gebruikers mag verwijderen. Kijk ook hier voor meer uitleg: link.

Na een paar controlevragen gaan we door met een LAB. Ik kan de machtigingen niet helemaal vinden, maar het blijkt dat als je rechtsboven op de profielfoto klikt, de pop-up die je daar krijgt, je klikt op 3 puntjes achter schakelen tussen mappen, dan zie je daar "Mijn machtigingen", daar kun je dus zien welke rechten je hebt.

Hierna gaan we naar een resource-groep en gaan we naar Access control (IAM). De site zegt dat Azure standaard 70 rollen zelf al levert. We voegen een gebruiker toe aan "inzender voor virtuele machines". En daarna verwijderen we deze persoon weer bij deze rol. Hierna de opdracht om een rapport van roltoewijzing en wijzigingen uit te draaien. Deze moet te vinden zijn in het activiteitenlogboek van Azure: link.

Tijd voor het laatste blok, Secure your Azure SQL Database: link.

De voorbeeld-case is dat je bij een bedrijf werkt waar klantdata (ook financiële gegevens) in een SQL Server database wordt opgeslagen. Hoe voorkom je dat mensen die niets met die data nodig hebben erbij kunnen komen?

We hebben weer een sandbox-account en gaan zaken aanmaken:


export ADMINLOGIN='[ServerAdmin]'
export PASSWORD='[password]'
export SERVERNAME=server$RANDOM
export RESOURCEGROUP=<naam-resource-groep>
export LOCATION=$(az group show --name $RESOURCEGROUP | jq -r '.location')

az sql server create \
    --name $SERVERNAME \
    --resource-group $RESOURCEGROUP \
    --location $LOCATION \
    --admin-user $ADMINLOGIN \
    --admin-password $PASSWORD

az sql db create --resource-group $RESOURCEGROUP \
    --server $SERVERNAME \
    --name marketplaceDb \
    --sample-name AdventureWorksLT \
    --service-objective Basic

// vraag de connectie-string op, die heb je straks nodig:
az sql db show-connection-string --client sqlcmd --name marketplaceDb --server $SERVERNAME | jq -r

// hierna maken we een Linux VM aan
az vm create \
  --resource-group $RESOURCEGROUP \
  --name appServer \
  --image UbuntuLTS \
  --size Standard_DS2_v2 \
  --generate-ssh-keys

// dit geeft ouptut, waaronder het IP-adres. hier met SSH connecten:
ssh nnn.nnn.nnn.nnn

// MSSQL tools installeren op Linux:
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bash_profile
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bashrc
source ~/.bashrc
curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
curl https://packages.microsoft.com/config/ubuntu/16.04/prod.list | sudo tee /etc/apt/sources.list.d/msprod.list
sudo apt-get update
sudo ACCEPT_EULA=Y apt-get install -y mssql-tools unixodbc-dev
 

Hiermee is de boel opgestart. Nu gaan we zaken dichttimmeren, zoals netwerktoegang.

Azure SQL Database heeft een ingebouwde firewall, die verkeer toegang geeft (of juist niet) en dat zowel op server-niveau als database-niveau uitvoert. Standaard staat alle publieke toegang uit (heel goed!). In de regels ga je aangeven welke ip-adressen wel toegang hebben en of Azure applicaties verbinding mogen maken.

SQL Data Warehouse ondersteunt alleen regels op database-server niveau, niet op database niveau.

Als je de Allow access to Azure services regel actief maakt, dan mogen services in Azure connectie maken met jouw Azure SQL database. Het staat communicatie toe met "alle publieke IP-adressen van Azure". Dus als je buurman met een eigen subscription op Azure zit: hij kan er ook bij.
Je zet het aan of uit in het firewall-paneel in het overzicht of als je echt "rules" hebt een rule met begin en eind IP van 0.0.0.0

Waarom zou je dit doen? Vaak heb je applicaties runnen als een PaaS service, zoals Azure Logic Apps of Azure Functions die bij je database moeten kunnen komen. Omdat veel van die diensten geen statisch IP-adres hebben is deze regel nodig om te zorgen dat ze erbij kunnen komen.

Met IP Address Rules stel je IP-ranges in, niet heel spannend.

Met Virtual Network Rules gebruik je het VNet van Azure, hou je zaken intern en kun je de boel helemaal "van buiten" afschermen, dit wordt vaak gebruikt als je vanuit een Virtual Machine toegang tot een database wilt/moet hebben.

De voorgaande regels waren op server-niveau. Als je op database niveau zaken wilt instellen, dan heb je alleen IP Address Rules beschikbaar.

Firewall regels voor databases kun je via TSQL inregelen. Voordeel is ook dat ze bij een migratie meegenomen worden.

De site geeft het ook aan als "best practise".

Als we nu proberen te verbinden vanuit onze SSH-sessie met de database, dan krijgen we ook de melding dat ons IP geen toegang heeft.


// TSQL voor firewall rule op DB toevoegen
EXECUTE sp_set_database_firewall_rule N'My Firewall Rule', '[From IP Address]', '[To IP Address]';
GO

// TSLQ voor verwijderen:
EXECUTE sp_delete_database_firewall_rule N'My Firewall Rule';
GO

En via het overzicht in de portal kunnen we op server-niveau deze regel toevoegen. In dat zelfde scherm kunnen we ook een Virtueel Netwerk toevoegen. Dat doen we, die regel op server-niveau halen we weer weg. En het werkt.

Bij het aanmaken van de VM zag je het ook wel, deze heeft een publiek IP van 138.91...., maar ook een intern IP van 10.0.0.4 - daar connecten we nu mee.

Vervolgens gaan we naar Authenticatie (bij voorkeur via Azure Active Directory) en Authorizatie: wat mag je, welke rol(len). En gebruik bij voorkeur contained databases: link.

We gaan een gebruiker toevoegen en  inrichten:


// user maken
CREATE USER ApplicationUser WITH PASSWORD = 'YourStrongPassword1';
GO

// rollen toewijzen
ALTER ROLE db_datareader ADD MEMBER ApplicationUser;
ALTER ROLE db_datawriter ADD MEMBER ApplicationUser;
GO

// toegang weigeren tot een bepaalde tabel:
DENY SELECT ON SalesLT.Address TO ApplicationUser;
GO

 

Hierna maken we connectie met deze user, kunnen we data opvragen uit tabel SalesLT.Customer, maar niet uit SalesLT.Address.

Bij de database, in de linkerkolom heb je onder "security" de optie "Transparent Data Encryption". Bij nieuwe databases staat dit altijd "aan", check altijd of dit bij jou ook aan staat. Daarmee is de data "in rust" namelijk geëncrypt.

Al eerder genoemd, sommige data kun je "maskeren". Je wilt niet dat iedereen IBAN nummers en e-mailadressen kan zien.

Je hebt verschillende standaard "masks" die je kunt gebruiken:

  • De standaard waarde, de standaard waarde voor dat datatype (bijvoorbeeld NL12TEST334556677 voor een IBAN).
  • Credit card waarde, waarbij je alleen de laatste 4 cijfers ziet, andere cijfers worden x-jes.
  • Email, je ziet het eerste karakter van het e-mailadres, domeinnaam wordt verborgen.
  • Nummer, een random nummer in een range van waardes. Voor creditkaart expiry maand en jaar kun je random maanden tussen 1 tot 12 en jaar van 2018 tot 3000 instellen.
  • Custom string, aantal karakters te tonen van start, aantal karakters te tonen vanaf het einde en de karakters die in de rest van de data getoond worden.


We stellen 2 velden in en zien inderdaad in de selectie dat data gemaskeerd wordt.

Hierna gaan we naar het monitoren van je database. Met auditing kun je zien wat er allemaal voor acties uitgevoerd zijn. Tip van de site is dat je gelijktijdig server blob auditing en database blob auditing actief hebt tenzij je goede redenen hebt, zoals een ander storage account of retentieperiode voor een specifieke database of je wilt voor een specifieke daabase andere event types of categorieën auditten.

In de portal, bij je databaseserver, staat onder Beveiliging - Controleren (Security - Auditing). Deze zet je aan. Bij Storage settings geef je aan in welk Storage Account de data gelogd moet worden.

Een ander item is Advanced Data Security for Azure SQL Database. In de applicatie heeft het Defender for Cloud. Die hebben we eerder al benoemd, die kun je hier ook aan zetten.

Hiermee zijn de blokken op de AZ-204 pagina afgerond.