Indeling van firewallregels¶
Hoe je de firewallregelbestanden indeelt, zodat elke regel naar een workload te herleiden is, conflicten zeldzaam zijn en een uitgefaseerde workload zijn regels meeneemt. Deze pagina geeft de ontwerpredenering en de bestandsstructuur. De details over naamgeving, prioriteiten, IP groups, limieten en veilige wijzigingen staan in Richtlijnen voor firewallregels en IP groups. Het bestandsformaat en de procedure staan in Firewallregels.
Het probleem¶
Regels die per technologie zijn ingedeeld (bijvoorbeeld één collection AllowDatabase per regio) worden moeilijk te beheren naarmate
er workloads bijkomen:
- je kunt niet zien welke regels bij welke workload horen,
- regels overlappen of conflicteren tussen workloads,
- als een workload wordt uitgefaseerd, weet niemand welke regels weg moeten,
- de extra dimensie van regio's maakt het erger.
Richtlijn: deel in per workload¶
Groepeer regels rond de workload en zijn doel, niet rond een technologie. Deze soorten bestanden dekken alles:
| Soort bestand | Inhoud | Waar |
|---|---|---|
| Regels voor platforminfrastructuur | Alleen de kernregels die het platformteam beheert: updates van het besturingssysteem, basismonitoring, platformdiagnostics, DNS, build agents. Zie Basisregels van het platform. | Globale map, één bestand |
| Bestanden per functionele eis | Eén bestand per functionele eis die voor veel workloads geldt. Elk hoort bij één ontwerpbeslissing, bijvoorbeeld standaardpoorten voor private endpoints in dev en test, of toegang voor build agents. | Globale map, vernoemd naar de eis |
| Regionale gemeenschappelijke regels | Regels die specifiek zijn voor één regio en voor meerdere workloads gelden. Beperk dit tot gevallen met een echt regionaal verschil. | Regiomap, met de regio in de bestandsnaam |
| Workloadbestanden | Alle regels van één workload. Alle omgevingen (dev, tst, acc, prd) zijn aparte rule collections in hetzelfde bestand, met een standaard collectienaam die de omgeving bevat. | Globale map, of de regiomap als een regionaal verschil echt is (failover, data residency) |
Geef regels namen die de verkeersstroom en de reden tonen, bijvoorbeeld <action><workload>_<reason>_<environment>
(AllowApp1_FromJumpHost_ToDb_tst), en zet de omgeving in de naam van de collection.
Globale en regionale bestanden¶
In MCP worden de globale en de regionale bestanden samengevoegd, en een regionaal bestand met dezelfde bestandsnaam als een globaal bestand vervangt dat in die regio (Firewallregels). Zet de regio in de naam van regiospecifieke bestanden, zodat ze niet per ongeluk een globaal bestand overschaduwen, en gebruik de vervanging alleen bewust.
Consistentie tussen regio's¶
Als regio's elkaar back-uppen (bijvoorbeeld met een active/standby-verbinding naar on-premises), moeten dezelfde regels in beide bestaan. Een failover faalt dan niet op een regel die maar in één regio bestaat. Verschillen tussen regio's hebben een reden nodig. Dit kost een reviewstap bij het toevoegen van regels, maar het haalt een hele klasse failoverproblemen weg.
Prioriteiten¶
Reserveer per soort bestand een bereik van prioriteiten voor rule collection groups, zodat twee teams nooit hetzelfde nummer nodig hebben. Een voorbeeld, volgens de bestandssoorten hierboven:
| Bereik | Gebruik |
|---|---|
| 100 - 199 | Regels voor platforminfrastructuur |
| 200 - 299 | Globale bestanden per functionele eis |
| 300 - 499 | Regionale gemeenschappelijke regels |
| 500 - 5000 | Workloadbestanden, met een blok per workload |
Een tweede schema in gebruik verdeelt workloads in productie- en non-productiebereiken, met een blok per workload
(voorbeeldschema). Kies er één, leg het vast en laat gaten open. Gebruik prioriteit
8999 niet, die het platform reserveert.
Regels bij de bestemming¶
Zet een regel in het bestand van de bestemmingsworkload en beschrijf inkomend verkeer (on-premises en internet zijn de uitzonderingen: die hebben geen workloadbestand). De firewall is gedeeld. Als workload B een regel kon toevoegen waarmee B bij workload A kan, dan zou A bereikbaar zijn zonder goedkeuring van A, en zou de evaluatievolgorde bepalen wie wint. Met regels bij de bestemming beslist A wie binnen mag. Hoe aanvragen worden verdeeld staat in Hoe vraag je aan.
Basisregels van het platform¶
Het platformteam beheert een globale regelset waar alle workloads van afhangen. Die bevat meestal:
| Categorie | Voorbeelden |
|---|---|
| Naamresolutie en directory | DNS naar on-premises servers, poorten van de directoryservice |
| Updates | Updateservices van het besturingssysteem, FQDN tags voor updates, automation endpoints |
| Monitoring | Endpoints van Azure Monitor en Application Insights, diagnostics |
| Tijd | Tijdsynchronisatie |
| Pipelines | Endpoints die hosted en self-hosted agents nodig hebben (hosts voor broncode, package registries, downloads van tools) |
| Beheer | Bastion naar SSH en RDP in de bereiken van de workloads |
Houd deze gescheiden van workloadbestanden, zodat het verwijderen van een workload er nooit aan raakt.
Workload teams wijzigingen laten voorstellen¶
Teams kunnen leestoegang krijgen tot de firewallregelrepository, zodat ze kunnen zien welke regels voor hen gelden en of de firewall de oorzaak van een probleem is. Ze kunnen ook pull requests mogen openen voor het bestand van hun eigen workload. Dat verkort de doorlooptijd: een pull request is makkelijker te valideren dan de tekst van een ticket die iemand moet interpreteren.
Houd deze voorwaarden aan:
- het platformteam (en, waar je proces dat vereist, de security officer) keurt nog steeds goed en deployt,
- het ticket of wijzigingsrecord blijft verplicht,
- pull requests zijn toegestaan per team, nadat het team heeft laten zien dat het de regels, Git en de firewall kent.
Zie Review van pull requests voor wat de reviewer controleert.
Gevolgen¶
Positief:
- een duidelijke koppeling tussen regels en workloads,
- makkelijker troubleshooten als connectiviteit faalt,
- een eenvoudig uitfaseringsproces: verwijder het bestand van de workload,
- minder verweesde regels,
- consistente naamgeving en minder prioriteitsconflicten.
Negatief of aandachtspunt:
- elke regionale regel heeft een motivatie nodig,
- regiospecifieke adressen en resources zijn lastiger te hanteren,
- de regio's consistent houden vraagt een extra review,
- de structuur houdt alleen stand als het team zich eraan houdt terwijl het platform groeit.