Hoe doe je een aanvraag¶
Alle aanvragen lopen via de intake van je platformteam (bijvoorbeeld een ticket of work item). Het platformteam is XMMS onder een managed-servicecontract, of het eigen platformteam van je organisatie: zie Beheermodellen en Support. Elke aanvraag is een standaardwijziging: een bekende procedure met vaste aanvraagvelden. Vul alle velden in; een complete aanvraag wordt het snelst afgehandeld.
Aanvraag of pull request?
Op sommige platformen kunnen workload teams een wijziging zelf voorbereiden, meestal een firewallregel, als pull request op de configuratierepository. Het platformteam beoordeelt en deployt die. Vraag je platformteam of dit voor jou mogelijk is. Zo ja, lees dan eerst de richtlijnen voor firewallregels en Pull request review. De stappen voor de bestanden staan in Firewallregels en IP-groepen.
Elke aanvraag¶
| Veld | Verplicht | Voorbeeld |
|---|---|---|
| Rationale | ja | "Nieuw factuurportaal voor Finance" |
| Omgeving | ja | dev, tst, acc, prd, shared |
| Opmerkingen | nee | Alles wat we verder moeten weten |
Een nieuwe spoke¶
| Veld | Verplicht | Voorbeeld / opmerkingen |
|---|---|---|
| Naam (korte naam van de workload) | ja | invprt. Maximaal 6 tekens, later niet te wijzigen. |
| Omgeving(en) | ja | dev en prd. Eén spoke per omgeving. |
| Bestaande subscription | ja | De subscription-ID, als je organisatie eerst subscriptions aanmaakt. Vraag je platformteam hoe subscriptions worden aangemaakt. |
| Productiedata ja/nee | ja | Bepaalt de management group en de policies |
| Persoonsgegevens (PII) ja/nee | ja | Bepaalt de pii-tag |
| Blootgesteld aan internet ja/nee | ja | Bepaalt corp of online, en of je de App Gateway nodig hebt |
| Grootte IP-range | ja | Bijvoorbeeld een /24. Het platformteam wijst de range toe. |
| Subnets | ja | Naam en grootte per subnet, delegations (bijv. Microsoft.Web/serverFarms), service endpoints (bijv. Microsoft.Storage) |
| Teamtoegang | ja | Weergavenaam van je bestaande Entra ID-groep, en per rol of je directe toegang, PIM self-approve of PIM met goedkeuring wilt. De groep moet bestaan voordat de spoke wordt aangemaakt. |
| Tags | ja | owner, department, workload, costcentre |
| Regio | nee | Standaard is de primaire regio van het platform |
| Azure DevOps-repository + service connection | nee | Projectnaam en repositorynaam |
| Optionele resources | nee | Laat Key Vault, storage of Log Analytics weg als je ze niet wilt. Geef aan als je de private endpoint van de Key Vault of het storage account niet gaat gebruiken. |
| Goedkeuringen | afhankelijk | De goedkeuringen die je organisatie vereist voordat een workload wordt aangemaakt, bijvoorbeeld product owner, architectuur en security. Zie Onboarding. |
Andere aanvragen¶
| Aanvraag | Velden |
|---|---|
| Firewallregel (nieuw of gewijzigd) | Bron (spoke/subnet), bestemming (FQDN, IP of service tag), poort en protocol, rationale. Geef voor uitgaand internetverkeer de voorkeur aan FQDN's. |
| Een app publiceren via de Application Gateway | Workloadnaam, backend-adres (IP/FQDN), listener-URL, poort (HTTP/HTTPS), SSL-certificaat (voor HTTPS), redirects ja/nee, health probe (pad, protocol, interval). Optioneel: URL's van aangepaste foutpagina's (bijvoorbeeld voor 502 en 403). |
| Een App Gateway-configuratie wijzigen | Dezelfde velden, alleen wat verandert |
| Een certificaat op de Application Gateway verlengen of vervangen | Listener-URL en certificaatnaam. Wie het certificaat bestelt hangt af van je platform: zie Certificaten voor gepubliceerde apps. |
| Uitzondering op de web application firewall | De geblokkeerde request (URI, argumentnaam, regel-ID uit het WAF-log), waarom het een false positive is, en de security-goedkeuring. Zie Application Gateway. |
| Inkomende SFTP van een externe partij naar een storage account | Zie Inbound SFTP naar een storage account |
| Managed VM (nieuw, wijziging, verwijderen) | Zie Managed virtual machines |
| Policy-uitzondering | Policy of initiative, scope (je subscription of resource group), categorie (waiver of mitigated), rationale, alternatieve maatregelen, einddatum, security-goedkeuring. Zie Policy en uitzonderingen. |
| Wijziging aan je spoke | Zie Hoe wijzig je |
| Een spoke verwijderen | Spokenaam en omgeving, bevestiging dat data verwijderd mag worden, bevestiging dat jij de workload owner bent. Verwijderen is permanent: de resource groups, Key Vault en storage van de spoke worden vernietigd. De subscription wordt niet automatisch opgezegd. Verwijder de firewallregels en Application Gateway-items van de workload in dezelfde aanvraag. Zie Een spoke verwijderen. |
| Groepstoegang (PIM-modus, teamgroep) | Zie Toegang, groepen en PIM |
| Budget, reservering | Zie Kosten en reserveringen |
| Shared service (registry, APIM, gateway) | Zie Shared services |
| Een nieuwe regio | Regio, rationale. Dit is een platformwijziging en duurt langer. |
Firewallregels¶
Uitgaand verkeer en spoke-naar-spoke-verkeer is geblokkeerd, tenzij een regel het toestaat. Vraag de regel aan voordat je hem nodig hebt.
| Veld | Beschrijving |
|---|---|
| Bron | De spoke of het subnet (CIDR) waar het verkeer vandaan komt |
| Bestemming | IP-adres, CIDR, FQDN of service tag. Geef voor internetbestemmingen de voorkeur aan FQDN's. |
| Poort(en) | De poortnummers van de service |
| Protocol | TCP, UDP of HTTP/HTTPS |
| Omgeving | Eén aanvraag per omgeving (dev, tst, acc, prd), omdat elke omgeving eigen regels heeft |
| Rationale | Waarom dit verkeer nodig is |
- Voor verkeer tussen twee workloads in Azure doet de owner van de ontvangende (bestemmings-)workload de aanvraag.
- Het platformteam (of je security officer, die goedkeurt) toetst de aanvraag aan het securitybeleid en implementeert hem daarna in de firewallconfiguratie van de hub.
- Voor operators: zie Firewallregels.
- Workload teams die de pull request zelf voorbereiden: Firewallregels en IP-groepen.
Wie vraagt welke regel aan¶
Een gebruikelijk eigenaarschapsmodel, dat per regel één duidelijke eigenaar oplevert:
| Verkeer | Wie vraagt aan |
|---|---|
| Je workload naar een internetbestemming | Jouw team (de bron) |
| Je workload naar een on-premises systeem | Jouw team (de bron) |
| Van de ene Azure-workload naar de andere | Het team van de bestemmingsworkload |
| Een extern of on-premises systeem naar een Azure-workload | Het team van de bestemmingsworkload |
De reden om interne regels bij de bestemming te leggen is dat de firewall gedeeld is. Als beide kanten regels konden toevoegen, kon een workload verkeer openen naar een andere workload die daar nooit mee heeft ingestemd. De eigenaar van de bestemming bepaalt wie met zijn workload mag verbinden.
Het regeltype en de bestemming kiezen¶
- Gebruik een application rule voor HTTP-, HTTPS- en SQL-verkeer naar een internet-FQDN. Die matcht op de FQDN en de firewall kan het verkeer inspecteren.
- Gebruik een network rule voor andere protocollen en voor intern verkeer. Application rules vertalen het bronadres (SNAT), waardoor de bestemming de firewall ziet in plaats van je workload, en logging en troubleshooting op basis van de bron moeilijker worden. Je platform kan anders kiezen, dus volg wat je platformteam zegt.
- Benoem de bestemming zo precies mogelijk: eerst een FQDN, dan één IP-adres, dan een IP-range. Vraag niet om
*, "any" of brede ranges. Noem de exacte poorten. - Meerdere regels hebben vaak dezelfde adressen nodig. Het platformteam zet ze dan in een IP group (IP groups).
Wat de review meestal controleert¶
Organisaties stellen vaak regels als deze. Vraag de jouwe welke gelden.
- Standaard alleen versleutelde protocollen. Onversleutelde protocollen vragen extra goedkeuring van security.
- Geen regels tussen productie- en niet-productieomgevingen, zodat productiedata niet naar niet-productie stroomt.
- Internetregels en interne regels worden gescheiden gehouden.
- Interne regels tussen workloads vragen de goedkeuring van de eigenaar van de bestemming. Regels naar internet of naar een workload met een ander gebruikstype vragen meestal ook een securityreview.
Het voorbeeld hieronder laat zien hoe goedkeuringen kunnen worden verdeeld. Het is een voorbeeld, geen vaste regel van het platform.
| Aanvraag | Eigenaar bestemming keurt goed | Security beoordeelt de rationale | Platformteam beoordeelt technisch |
|---|---|---|---|
| Verkeer tussen twee spokes van dezelfde workload | ja | nee | ja |
| Verkeer van een andere workload met hetzelfde gebruikstype (prod of niet-prod) | ja | ja | ja |
| Uitgaand verkeer naar internet | ja | ja | ja |
| Verkeer van of naar on-premises | ja | ja | ja |
| Een kleine wijziging aan een bestaande regel (alleen bron of bestemming binnen dezelfde spoke verandert) | ja | nee | ja |
| Al het andere | ja | ja | ja |
Certificaten voor gepubliceerde apps¶
Voor een HTTPS-listener op de Application Gateway staat het certificaat in de Key Vault van de gateway, die het platformteam beheert. Het bestellen en verlengen van het certificaat is meestal een verantwoordelijkheid aan de klantkant (een centraal team of het workload team), omdat de certificate authority en het account daarvan van je organisatie zijn. Spreek met je platformteam af wie wat doet als je de app publiceert, en zet de vervaldatum in je agenda of monitoring. De stappen voor verlenging staan in Een certificaat op de Application Gateway vervangen. Gebruikt de backend hetzelfde certificaat (bijvoorbeeld een reverse proxy die TLS afsluit), dan moeten beide kopieën tegelijk worden vervangen.
Wat er daarna gebeurt¶
- Het platformteam beoordeelt de aanvraag en stelt vragen als er velden ontbreken.
- Ze voeren de wijziging door in code, laten die reviewen, testen hem waar relevant op het canary-platform en passen hem toe.
- Je krijgt een bevestiging met wat is aangemaakt of gewijzigd. Voor een nieuwe spoke: de subscription-naam, het VNet-bereik, de groepsnamen en (als je PIM gebruikt) hoe je je rol activeert.