SNB Project — Cheatsheet

Infrastructuurontwerp, cloud, storage, webservices en automatisering — 2025–2026

Inhoudstafel

Ontwerp & keuzes

CAMPUS-parameters
Van behoefte naar infrastructuur
Services combineren en dimensioneren
DNS als ontwerpvoorbeeld

Cloud & endpointbeheer

Cloud- en Azure-basis
Microsoft 365 en Entra ID
Hybride identiteit
Intune en apparaatbeheer

Storage & virtualisatie

TrueNAS en ZFS
ESXi virtual storage
NFS-storage
iSCSI-storage

Webservices & automatisering

Shared hosting met IIS
NGINX en redundante webhosting
Docker
Ansible
Projectaanpak en controlelijst

CAMPUS-parameters

Een infrastructuurkeuze is pas sterk wanneer ze niet alleen technisch werkt, maar ook aantoonbaar bij de organisatie past. Toets elk scenario aan CAMPUS.

Letter	Parameter	Centrale vraag
C	Cost	Wat zijn aankoop-, licentie-, beheer-, energie- en migratiekosten?
A	Availability	Welke uitval is aanvaardbaar en welke redundantie is nodig?
M	Manageability	Hoe eenvoudig kan men beheren, monitoren, patchen en herstellen?
P	Performance	Volstaan capaciteit, latency, throughput en responstijd?
U	User-friendliness	Is de oplossing bruikbaar en begrijpelijk voor de doelgroep?
S	Security	Zijn data, identiteiten en diensten passend beschermd?

Parameters kunnen botsen. Redundantie verhoogt availability en mogelijk performance, maar ook cost en beheercomplexiteit. De beste keuze is daarom niet "het technisch maximum", maar de best onderbouwde balans volgens afgesproken prioriteiten.

Beslissingsmatrix

Criterium	Gewicht	Scenario A	Scenario B
Cost	20%	score × 0,20	score × 0,20
Availability	25%	score × 0,25	score × 0,25
Manageability	15%	score × 0,15	score × 0,15
Performance	15%	score × 0,15	score × 0,15
User-friendliness	10%	score × 0,10	score × 0,10
Security	15%	score × 0,15	score × 0,15

Motiveer concreet

"Dit is veiliger" is geen volledige motivering. Benoem dreiging, control, resterend risico, kost en impact op beheer en gebruikers.

Van behoefte naar infrastructuur

businessbehoefte
      ↓
functionele en niet-functionele vereisten
      ↓
afhankelijkheden en constraints
      ↓
scenario's + CAMPUS-afweging
      ↓
ontwerp en implementatie
      ↓
technische én functionele tests
      ↓
monitoring, documentatie en bijsturing

Een IT-infrastructuur bestaat uit hardware, software/services en gebruikers. Begin bij wat de dienst moet doen, niet bij een productnaam.

Vereisten verzamelen

aantal en locaties van gebruikers en apparaten;
verwachte gelijktijdige belasting en groei;
benodigde opslag, retentie en back-up;
netwerkbandbreedte en maximaal aanvaardbare latency;
beschikbaarheidsdoelstellingen, RPO en RTO;
wetgeving, classificatie en security-eisen;
integraties met bestaande identiteit, DNS, DHCP en cloud;
beschikbare kennis, tijd, budget en supportcontracten.

Het ideale netwerk is een utopie

Infrastructuur verandert voortdurend door nieuwe applicaties, migraties, groei en nieuwe risico's. Leg aannames vast en ontwerp zodat gecontroleerde verandering mogelijk blijft.

Services combineren en dimensioneren

Onderzoek per service functie, werking, afhankelijkheden, communicatiepatronen en resourceprofiel.

Service	Typische nadruk
DHCP	korte pieken op CPU en netwerkinterface
DNS	geheugen voor cache en snelle disk voor zones/logs
NAT	CPU, RAM en netwerkthroughput
VPN	CPU voor cryptografie en netwerkthroughput
Fileserver	diskcapaciteit, IOPS, netwerk en cache
Webserver	CPU/RAM, verbindingen en back-endafhankelijkheden

Complementaire workloads kunnen op dezelfde host passen, maar consolidatie vergroot ook blast radius en resource contention. Scheid diensten wanneer security boundaries, onderhoudsvensters, beschikbaarheid of onafhankelijke schaling dat vereisen.

Na implementatie volgt monitoring. Meet werkelijk gebruik om over- en onderdimensionering te herkennen; een leveranciersminimum is geen capaciteitsplan.

DNS als ontwerpvoorbeeld

Bij DNS moeten onder andere platform, namespace, zonetypes, updates, redundantie, plaatsing en relaties met AD/DHCP worden gekozen.

Zonetype	Eigenschap
Primary	schrijfbare bronzone
Secondary	read-only kopie via zone transfer
AD-integrated	multimasteropslag en replicatie via AD
Caching-only	geen eigen zones; cachet externe antwoorden

Belangrijke records: SOA, NS, A, AAAA, PTR, CNAME, MX en SRV.

Ontwerpregels

Gebruik een beheerste domeinnaam; een niet-bezette fictieve interne naam bemoeilijkt cloudintegratie.
AD kan niet zonder DNS; clients moeten de juiste interne resolver gebruiken.
Plaats redundante resolvers dicht bij gebruikers en belangrijke sites.
Publiceer extern alleen noodzakelijke records, bijvoorbeeld met split DNS.
Plaats een publieke secondary in de DMZ, niet de interne schrijfbare primary.
Beperk zone transfers en dynamic updates; gebruik secure updates waar mogelijk.
DNSSEC bewijst authenticiteit/integriteit van DNS-data, maar versleutelt queries niet.

DHCP levert DNS-server en suffix aan clients en kan namens clients dynamische updates uitvoeren. Controleer eigenaarschap en updatebeleid om stale records en poisoningrisico te beperken.

Cloud- en Azure-basis

Model	Beheergrens
IaaS	klant beheert OS, apps en data; provider fysieke laag
PaaS	klant beheert applicatie/data; provider platform en OS
SaaS	provider levert volledige toepassing; klant beheert gebruik/data/configuratie

Deployment	Betekenis
Public cloud	gedeelde providerinfrastructuur
Private cloud	cloudmodel voor één organisatie
Hybrid cloud	lokale en cloudresources geïntegreerd

Cloudvoordelen omvatten elasticiteit, schaalbaarheid, wereldwijde beschikbaarheid en consumption-based pricing. Daartegenover staan afhankelijkheid van connectiviteit/provider, governance, kostenbewaking en het shared responsibility model.

Azure-hiërarchie

Microsoft Entra tenant
└── Management groups
    └── Subscriptions
        └── Resource groups
            └── Resources

Regions bevatten datacenters; availability zones zijn fysiek gescheiden locaties binnen een region.
Resource groups zijn logische lifecycle-/beheercontainers; een resource zit in precies één resource group.
Azure RBAC bepaalt wie welke acties op welke scope mag uitvoeren.
Tags helpen met eigenaarschap, omgeving en kostenrapportering.
Azure Policy controleert of dwingt configuratieregels af.

AZ-900-labs

Begrijp waarom je een resource aanmaakt en hoe die wordt gefactureerd. Verwijder labresources na gebruik en vertrouw niet op tijdelijke save-retentie als documentatie.

Microsoft 365 en Entra ID

Microsoft Entra ID is de centrale cloud identity provider voor Microsoft 365. Het behandelt authenticatie en ondersteunt autorisatie, auditing en single sign-on.

Portaal/onderdeel	Gebruik
Microsoft 365 admin center	tenantoverzicht, users, groups, licenses en service health
Entra admin center	identity, authentication, roles en Conditional Access
Intune admin center	endpoints, apps en compliance
Security/Purview-portalen	security, compliance en information protection

Gebruikers en groepen

Statische groepen krijgen handmatig leden.
Dynamische groepen gebruiken membership rules op kenmerken.
Microsoft 365-groepen ondersteunen collaboration en liggen onder veel Teams-functionaliteit.
Gebruik consequente prefixen en namen die doel, doelgroep en eigenaar tonen.
Ken licenties bij voorkeur groepsgebaseerd toe.

Rollen

Gebruik least privilege: beperk Global Administrators en ken specifieke beheerrollen toe. Met Privileged Identity Management kan een rol tijdelijk, na voorwaarden en met logging geactiveerd worden.

Groepen zijn geen OU's

Dynamische groepen kunnen gebruikers/toestellen logisch verzamelen, maar vervangen niet alle functies van on-premises OUs, zoals hiërarchische GPO-verwerking.

Hybride identiteit

Synchronisatie koppelt lokale AD-objecten aan Entra-objecten. Een stabiele source anchor (mS-DS-ConsistencyGuid lokaal, ImmutableId in Entra) voorkomt dat hetzelfde individu als een nieuw cloudobject wordt gezien.

Authenticatiemethode	Werking
Password Hash Synchronization	afgeleide wachtwoordhash wordt naar Entra gesynchroniseerd; cloud authenticeert
Pass-through Authentication	agents valideren wachtwoord tegen lokaal AD
Federation	externe identity provider handelt authenticatie af

PHS is eenvoudig en blijft werken wanneer de on-premises verbinding uitvalt. PTA houdt validatie lokaal maar vereist beschikbare agents en infrastructuur.

Activeer de AD Recycle Bin en definieer herstelprocedures voordat synchronisatie breed wordt ingezet. Verwijderingen en foute wijzigingen kunnen anders naar de cloud doorstromen.

Intune en apparaatbeheer

Intune is cloudgebaseerd endpoint- en appbeheer. Het werkt samen met Entra ID, Conditional Access, Microsoft Defender en Autopilot.

Entra-device states

Status	Typisch scenario
Entra registered	persoonlijk/BYOD-apparaat
Entra joined	organisatieapparaat, cloud-first
Hybrid Entra joined	lokaal AD-joined én geregistreerd in Entra

Kernobjecten

Enrollment koppelt apparaat aan beheer.
Configuration profiles zetten instellingen.
Compliance policies beoordelen toestand, bijvoorbeeld encryptie, OS-versie en pincode.
Conditional Access gebruikt signalen zoals user, device compliance, locatie en risico.
App deployment installeert required/available apps.
Autopilot automatiseert de out-of-box provisioning.

apparaat enrolled → configuratie/applicaties → compliance-evaluatie
                                          ↓
                         Conditional Access laat toe of blokkeert

Compliance herstelt niet automatisch

Een compliance policy stelt vast of een apparaat voldoet. Gebruik configuration/remediation om de gewenste instelling daadwerkelijk af te dwingen of te herstellen.

Werk met testgroepen en gefaseerde uitrol. Controleer assignment, check-in, conflicts, per-setting status en lokale eventlogs voordat je een policy wijzigt.

TrueNAS en ZFS

TrueNAS is een storage-OS met OpenZFS en ondersteunt file storage zoals SMB/NFS en block storage via iSCSI.

disks → vdev(s) → ZFS pool → dataset of zvol → share/target

Object	Gebruik
Pool	storagecapaciteit opgebouwd uit vdevs
Dataset	filesystemachtig, eigen quota/snapshots/properties
zvol	block device, bijvoorbeeld voor iSCSI
Snapshot	point-in-time toestand via copy-on-write

ZFS biedt checksums, snapshots, compressie en zelfherstel bij redundante data. De redundantie van een pool hangt af van de vdev-layout; het verlies van één volledige vdev kan de hele pool verliezen.

RAID/ZFS is geen backup

Redundantie beschermt tegen bepaalde diskdefecten, niet tegen verwijdering, ransomware, brand of fouten die naar alle kopieën worden geschreven.

Voor een lab: geef TrueNAS een beheerinterface/IP, voeg afzonderlijke datadisks toe, maak een passende pool en dataset/zvol, configureer permissions en publiceer pas daarna de service.

ESXi virtual storage

Een ESXi-datastore is een logische opslagplaats voor VM-bestanden, templates, ISO's en snapshots.

Type	Eigenschap
Local storage	eenvoudig, maar niet gedeeld tussen hosts
NFS datastore	file-level NAS-protocol over IP
iSCSI/FC datastore	block storage; ESXi maakt typisch VMFS

Gedeelde storage ondersteunt scenario's zoals migratie, high availability en centraal beheer, maar introduceert afhankelijkheid van netwerk en storageplatform.

Scheid management- en storagetrafiek logisch of fysiek, voorzie redundante paden/switches waar availability dat vereist, gebruik geschikte MTU alleen end-to-end en meet latency/IOPS/throughput.

NFS-storage

Bij NFS exporteert TrueNAS een dataset; ESXi mount deze als NFS-datastore.

Stappen

Maak pool en dataset in TrueNAS.
Configureer datasetrechten en toegestane netwerken/hosts.
Maak de NFS-share en start de NFS-service.
Maak op ESXi een VMkernelinterface die de storage kan bereiken.
Voeg datastore toe met server-IP en exportpad.
Test create/read/write en herstel na reboot.

showmount -e <truenas-ip>

Root mapping

Te ruime maproot/root-toegang vergroot impact van een gecompromitteerde client. Beperk exports tot noodzakelijke ESXi-hosts of het storage-VLAN.

iSCSI-storage

iSCSI vervoert SCSI blockcommando's over TCP/IP. De storagezijde is de target; de client/ESXi-host gebruikt een initiator.

portal/IP + target/IQN + extent/zvol + association + access policy

Een IQN heeft typisch formaat:

iqn.jjjj-mm.omgekeerd-domein:unieke-naam

TrueNAS → ESXi

Maak een zvol of file extent.
Configureer portal en toegestane initiators/netwerken.
Maak target met unieke IQN.
Koppel target aan extent.
Start iSCSI-service.
Activeer ESXi software iSCSI adapter en voeg discovery portal toe.
Rescan storage en maak een VMFS-datastore op het gevonden LUN.

CHAP voegt authenticatie toe, maar is geen volledige encryptie. Isoleer iSCSI in een storage-VLAN en gebruik redundante paden/multipathing volgens ontwerp.

Eén LUN, één gecoördineerd clusterfilesystem

Laat niet meerdere onafhankelijke hosts hetzelfde blockvolume beschrijven zonder een gedeeld-clusterfilesystem of coördinatiemechanisme; gewone filesystems raken dan corrupt.

Shared hosting met IIS

IIS kan meerdere websites op één server onderscheiden via bindings.

binding = protocol + IP-adres + poort + hostname

Voor HTTPS horen certificaat en hostname/SNI bij de binding.

Basisworkflow

Installeer Web Server (IIS) en noodzakelijke role services.
Maak per site een afzonderlijke contentdirectory.
Maak een afzonderlijke application pool waar isolatie nodig is.
Configureer binding met unieke host header.
Maak DNS-record naar het server-IP.
Stel NTFS-rechten in voor beheerder en application-poolidentity.
Test lokaal en vanaf een client op hostname.

Install-WindowsFeature Web-Server -IncludeManagementTools
Get-Website
Get-WebBinding

Gebruik geen brede write-rechten op webroot. Geef de worker process identity alleen wat de applicatie nodig heeft. Scheid publieke website en intern intranet met DNS, netwerk/firewall, authenticatie en bindings — niet alleen met een "geheime" URL.

Diagnose

Fout	Controle
verkeerde site verschijnt	host header, DNS en bindingconflict
403	authenticatie/autorisatie, default document, NTFS
404	pad, bestand, URL rewrite
500/502/503	applicatie, handler, application pool en logs

NGINX en redundante webhosting

Op Debian/Ubuntu staan configuraties typisch in /etc/nginx, met sites in sites-available en symlinks in sites-enabled.

server {
    listen 80;
    server_name voornaam.whatsnap.be;
    root /var/www/whatsnap;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo apt update
sudo apt install nginx
sudo nginx -t
sudo systemctl reload nginx
sudo journalctl -u nginx

Gebruik reload na een geslaagde nginx -t zodat actieve verbindingen zo weinig mogelijk worden verstoord.

Redundantie

Twee webservers zijn pas een redundante dienst met:

een mechanisme dat verkeer verdeelt/failover uitvoert;
consistente content en configuratie;
health checks die de werkelijke site testen;
redundante DNS/netwerk/back-endafhankelijkheden;
monitoring en een geteste failoverprocedure.

Mogelijkheden zijn een load balancer/reverse proxy, floating virtual IP of DNS-gebaseerde verdeling. DNS round robin detecteert op zichzelf geen defecte server en clients kunnen records cachen.

Docker

image = immutable template/lagen
container = draaiende instantie van image
registry = opslag/distributie van images
volume = persistente data buiten containerlaag
network = communicatie tussen containers/extern

docker pull ubuntu
docker image ls
docker run --name ubuntu-container1 -it ubuntu bash
docker ps -a
docker container diff ubuntu-container1
docker exec -it ubuntu-container1 bash
docker logs ubuntu-container1
docker stop ubuntu-container1
docker rm ubuntu-container1

docker commit kan een aangepaste container als image bewaren, maar is moeilijk reproduceerbaar. Gebruik voor beheerste builds een Dockerfile.

FROM ubuntu:24.04
RUN apt-get update \
    && apt-get install -y --no-install-recommends curl \
    && rm -rf /var/lib/apt/lists/*
CMD ["bash"]

docker build -t mijn-ubuntu:1.0 .
docker tag mijn-ubuntu:1.0 registry.example/mijn-ubuntu:1.0

Goede praktijken

gebruik kleine, vertrouwde en vastgepinde base images;
draai als niet-root waar mogelijk;
zet secrets niet in image, Dockerfile of environmentdump;
schrijf persistente data naar volumes;
publiceer alleen noodzakelijke poorten;
scan images en rebuild regelmatig met patches.

Ansible

Ansible is agentless configuratiebeheer en provisioning. Linux/BSD wordt meestal via SSH en Python beheerd; Windows via WinRM; netwerktoestellen via SSH/API's.

Begrip	Betekenis
Control node	voert Ansible uit
Managed node	beheerd systeem
Inventory	hosts en groepen
Module	voert één soort taak uit
Play	hosts + vars + tasks/roles
Playbook	één of meer plays in YAML
Role	herbruikbare structuur van tasks, handlers, vars, files en templates

SSH en inventory

ssh-keygen -t ed25519 -f ~/.ssh/ansible -C ansible
ssh-copy-id -i ~/.ssh/ansible.pub beheer@server1
sudo apt update && sudo apt install ansible

[webservers]
server1 ansible_host=192.168.10.21
server2 ansible_host=192.168.10.22

[webservers:vars]
ansible_user=beheer
ansible_ssh_private_key_file=~/.ssh/ansible

ansible all -i inventory.ini -m ping
ansible webservers -i inventory.ini -m setup

Playbook

---
- name: Configureer webservers
  hosts: webservers
  become: true
  tasks:
    - name: Installeer NGINX
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Publiceer configuratie
      ansible.builtin.template:
        src: site.conf.j2
        dest: /etc/nginx/sites-available/site.conf
        mode: "0644"
      notify: Herlaad NGINX

  handlers:
    - name: Herlaad NGINX
      ansible.builtin.service:
        name: nginx
        state: reloaded

ansible-playbook -i inventory.ini site.yml --syntax-check
ansible-playbook -i inventory.ini site.yml --check --diff
ansible-playbook -i inventory.ini site.yml

Ansible is declaratief: beschrijf de gewenste toestand. Modules zijn zoveel mogelijk idempotent, zodat herhaald uitvoeren geen ongewenste bijwerkingen geeft. Een shell-task is vaak minder idempotent dan een passende module.

Secrets

Bewaar wachtwoorden en tokens met Ansible Vault of een secret manager. Commit geen leesbare secrets in inventory, playbooks of Git.

Projectaanpak en controlelijst

Ontwerpdocument

scope, stakeholders en aannames;
functionele en niet-functionele vereisten;
logisch/fysiek diagram, adresplan en naamgeving;
alternatieven en CAMPUS-motivering;
afhankelijkheden en failure domains;
security-, backup-, monitoring- en beheerplan;
testplan met acceptatiecriteria;
rollback- en herstelprocedure.

Implementatievolgorde

netwerk + tijd + naamgeving
        ↓
identity en DNS/DHCP
        ↓
storage en virtualisatie
        ↓
servers, webservices en endpoints
        ↓
automatisering
        ↓
security, monitoring, backup en tests

Minimale eindtests

Domein	Test
DNS	forward, reverse, interne/externe naam en redundantie
Identity	gewone login, MFA/CA, least privilege en herstel
Storage	read/write, rechten, performance en path/server failure
Web	juiste site per hostname, HTTPS, rechten en failover
Docker	herstart, volumepersistentie en beperkte poorten
Ansible	eerste run verandert, tweede run rapporteert idealiter `changed=0`
Operations	alert, backup én restore aantoonbaar getest

Bewijs boven screenshot

Leg per vereiste vast welke test is uitgevoerd, wat het verwachte resultaat was en wat werkelijk gebeurde. Een configuratiescherm alleen bewijst niet dat de volledige dienst werkt.