Het Azure Well-Architected Framework is een reeks richtlijnen die kunnen worden gebruikt om een oplossing te beoordelen via de kwaliteitspijlers van architectuurpijlers:
Dit artikel beëindigt deze reeks. Lees de inleiding.
Deze richtlijnen in deze reeks bevatten goed ontworpen principes in alle ontwerpkeuzen. In dit artikel vindt u een overzicht van deze opties. GitHub : Azure Kubernetes Service (AKS) Baseline Cluster for Regulated Workloads implementation demonstreert deze principes, indien van toepassing.
PCI DSS 3.2.1-workloads vragen om een goed ontworpen oplossing. Hoewel het afstemmen van de infrastructuur met PCI-vereisten essentieel is, stopt de naleving niet bij de hostinginfrastructuur. Het niet aanpakken van de kwaliteitspijlers, met name beveiliging, kan de naleving in gevaar brengen. Goed ontworpen oplossingen combineren zowel de infrastructuur- als workloadperspectief om te komen tot de rigor die nodig is voor het bereiken van compatibele resultaten.
Beveiliging
Volg de fundamentele richtlijnen in de principes van het beveiligingsontwerp. Aanbevolen procedures voor een gereguleerde omgeving worden in deze secties samengevat.
Beheer
De governance-implementatie wordt aangestuurd door de nalevingsvereisten in PCI-DSS 3.2.1. Dit is van invloed op de technische controles voor het onderhouden van segmentatie, het openen van resources, het detecteren van beveiligingsproblemen en het belangrijkste beveiligen van klantgegevens.
Strategie voor segmentatie van ondernemingen
Om volledige isolatie te behouden, raden we u aan om de gereguleerde infrastructuur in een zelfstandig abonnement te implementeren. Als u meerdere abonnementen hebt die nodig zijn voor naleving, kunt u overwegen deze te groeperen onder een beheergroephiërarchie die het relevante Azure-beleid uniform toepast op uw binnen-scope-abonnementen. Pas binnen het abonnement gerelateerde Azure-beleidsregels toe op abonnementsniveau om de algemene beleidsregels vast te leggen die van toepassing moeten zijn op alle clusters in de gegevensomgeving voor kaartaanduidingen (CDE). Pas gerelateerd Azure-beleid toe op het niveau van de resourcegroep om beleidsregels vast te leggen die van toepassing zijn op een specifiek clusterexemplaren. Met deze beleidsregels worden de belangrijkste kaders van een landingszone gebouwd.
Isoleer de PCI-workload (binnen het bereik) van andere (buiten-scope) workloads in termen van bewerkingen en connectiviteit. U kunt isolatie maken door afzonderlijke clusters te implementeren. U kunt ook segmentatiestrategieën gebruiken om de scheiding te handhaven. De clusters maken bijvoorbeeld gebruik van afzonderlijke knooppuntgroepen, zodat workloads nooit een virtuele knooppuntmachine (VM) delen.
Beleidsafdwinging
Beveiligingscontroles afdwingen door Azure-beleid in te schakelen. In deze gereglementeerde architectuur kunt u bijvoorbeeld onjuiste configuratie van de gegevensomgeving van de kaarthouder voorkomen. U kunt een Azure-beleid toepassen dat openbare IP-toewijzingen niet toestaat op de VM-knooppunten. Dergelijke toewijzingen worden gedetecteerd en gerapporteerd of geblokkeerd.
Zie ingebouwde Azure Policy-definities voor Azure Kubernetes Service voor informatie over beleidsregels die u voor AKS kunt inschakelen.
Azure biedt verschillende ingebouwde beleidsregels voor de meeste services. Bekijk deze ingebouwde Azure Policy-beleidsdefinities en pas ze zo nodig toe.
Nalevingsbewaking
Naleving moet systematisch worden bewaakt en gehandhaafd. Regelmatige nalevingsverklaringen worden uitgevoerd. Als u weet of uw cloudresources in overeenstemming zijn, kunt u zich voorbereiden op attestations en controles.
Profiteer van het dashboard voor naleving van regelgeving in Microsoft Defender voor Cloud. Door het dashboard continu te bewaken, kunt u de nalevingsstatus van uw workload bijhouden.
Netwerkbeveiliging
In een hub-spoke-topologie biedt afzonderlijke virtuele netwerken voor elke entiteit basissegmentatie in de netwerkvoetafdruk. Elk netwerk wordt verder onderverdeeld in subnetten.
Het AKS-cluster vormt de kern van de CDE. Het mag niet toegankelijk zijn vanaf openbare IP-adressen en de connectiviteit moet worden beveiligd. Typische stromen in en uit CDE kunnen worden gecategoriseerd als:
- Binnenkomend verkeer naar het cluster.
- Uitgaand verkeer van het cluster.
- Clusterverkeer tussen pods.
Om te voldoen aan de vereisten van een gereguleerde omgeving, wordt het cluster geïmplementeerd als een privécluster. In deze modus wordt verkeer van en naar het openbare internet beperkt. Zelfs communicatie met de door AKS beheerde Kubernetes-API-server is privé. Beveiliging wordt verder verbeterd met strikte netwerkcontroles en IP-firewallregels.
- Netwerkbeveiligingsgroepen (NSG's) om communicatie tussen resources binnen een netwerk te beveiligen.
- Azure Firewall om uitgaand verkeer tussen cloudresources, internet en on-premises te filteren.
- Azure-toepassing Gateway geïntegreerd met Azure Web Application Framework om al het binnenkomende verkeer van internet te filteren dat Azure-toepassing Gateway onderschept.
- Kubernetes NetworkPolicy staat alleen bepaalde paden tussen de pods in het cluster toe.
- Azure Private Link om verbinding te maken met andere PaaS-services (Platform as a Service), zoals Azure Key Vault en Azure Container Registry voor operationele taken.
Er zijn bewakingsprocessen aanwezig om ervoor te zorgen dat verkeer stroomt zoals verwacht en dat eventuele afwijkingen worden gedetecteerd en gerapporteerd.
Zie Netwerksegmentatie voor meer informatie over netwerkbeveiliging.
Gegevensbeveiliging
PCI-DSS 3.2.1 vereist dat alle gegevens van de kaarthouder (CHD) nooit duidelijk zijn, ongeacht of ze onderweg of in opslag zijn.
Omdat deze architectuur en de implementatie gericht zijn op infrastructuur en niet op de workload, wordt gegevensbeheer niet gedemonstreerd. Hier volgen enkele goed ontworpen aanbevelingen.
Inactieve gegevens
De gegevens moeten worden versleuteld via industriestandaard versleutelingsalgoritmen.
- Sla geen gegevens op in de omgeving van de kaarthouder.
- Versleutelen buiten de opslaglaag.
- Schrijf alleen versleutelde gegevens naar het opslagmedium.
- Sla de sleutels niet op in de opslaglaag.
Alle gegevens in Azure Storage worden versleuteld en ontsleuteld met behulp van sterke cryptografie. Zelfbeheerde versleutelingssleutels hebben de voorkeur.
Als u gegevens tijdelijk wilt opslaan, past u dezelfde overwegingen toe op die gegevens. We raden u ten zeerste aan de hostversleutelingsfunctie van AKS in te schakelen. U kunt versleuteling van tijdelijke gegevens afdwingen met ingebouwd Azure-beleid.
Wanneer u een opslagtechnologie kiest, verkent u de bewaarfuncties. Zorg ervoor dat alle gegevens veilig worden verwijderd wanneer de geconfigureerde tijd verloopt.
De standaard vereist ook dat gevoelige verificatiegegevens (SAD) niet worden opgeslagen. Zorg ervoor dat de gegevens niet worden weergegeven in logboeken, bestandsnamen, cache en andere gegevens.
Actieve gegevens
Alle communicatie met entiteiten die met de CDE communiceren, moeten via versleutelde kanalen zijn.
- Alleen HTTPS-verkeer mag naar de CDE stromen. In deze architectuur weigert Azure-toepassing Gateway al het verkeer via poort 80.
- Versleutel en ontsleutel gegevens buiten de CDE bij voorkeur niet. Als u dat wel doet, moet u overwegen dat die entiteit deel uitmaakt van de CDE.
- Geef binnen de CDE beveiligde communicatie tussen pods met mTLS. U kunt ervoor kiezen om hiervoor een service-mesh te implementeren.
- Alleen veilige coderingen en TLS 1.2 of hoger toestaan.
Identiteit
Volg deze beveiligingsprincipes wanneer u toegangsbeleid ontwerpt:
- Begin met Zero-Trust-beleid. Maak waar nodig uitzonderingen.
- Verwijs de minste bevoegdheden, net genoeg om een taak te voltooien.
- Minimaliseer staande toegang.
Op rollen gebaseerd toegangsbeheer (RBAC) van Kubernetes beheert machtigingen voor de Kubernetes-API. AKS ondersteunt deze Kubernetes-rollen. AKS is volledig geïntegreerd met Microsoft Entra ID. U kunt Microsoft Entra-identiteiten toewijzen aan de rollen en ook profiteren van andere mogelijkheden.
Zero-Trust-toegang
Kubernetes RBAC, Azure RBAC en Azure-services implementeren standaard alles weigeren. Overschrijf deze instelling met voorzichtigheid, zodat alleen de entiteiten die deze nodig hebben, toegang hebben. Een ander gebied voor het implementeren van Zero-Trust is het uitschakelen van SSH-toegang tot de clusterknooppunten.
Minimale bevoegdheden
U kunt beheerde identiteiten gebruiken voor Azure-resources en -pods en deze beperken tot de verwachte taken. Azure-toepassing Gateway moet bijvoorbeeld machtigingen hebben om geheimen (TLS-certificaten) op te halen uit Azure Key Vault. Het mag geen machtigingen hebben om geheimen te wijzigen.
Permanente toegang minimaliseren
Minimaliseer staande toegang met just-in-time Microsoft Entra-groepslidmaatschap. Behard het besturingselement met beleid voor voorwaardelijke toegang in Microsoft Entra ID. Deze optie ondersteunt veel gebruiksvoorbeelden, zoals meervoudige verificatie, waardoor verificatie wordt beperkt tot apparaten die worden beheerd door uw Microsoft Entra-tenant of atypische aanmeldingspogingen blokkeren.
Geheimenbeheer
Bewaar geheimen, certificaten, sleutels en wachtwoorden buiten de CDE. U kunt de systeemeigen Kubernetes-geheimen of een beheerd sleutelarchief, zoals Azure Key Vault, gebruiken. Het gebruik van een beheerd archief helpt bij geheime beheertaken, zoals sleutelrotatie en certificaatvernieuwing.
Zorg ervoor dat de toegang tot het sleutelarchief een balans heeft tussen netwerk- en toegangsbeheer. Wanneer u beheerde identiteiten inschakelt, moet het cluster zich verifiëren bij Key Vault om toegang te krijgen. Bovendien mag de verbinding met het sleutelarchief niet via het openbare internet zijn. Gebruik een particulier netwerk, zoals Private Link.
Operationele topprestaties
Volg de fundamentele richtlijnen in de principes van Operational Excellence. Aanbevolen procedures voor een gereguleerde omgeving worden in deze secties samengevat.
Scheiding van rollen
Het afdwingen van duidelijke scheiding van taken voor gereguleerde omgevingen is essentieel. Beschikken over definities van rollen en verantwoordelijkheden op basis van de behoeften van de workload en interactie met de CDE. U hebt bijvoorbeeld een rol van infrastructuuroperator of sitebetrouwbaarheidstechnicus (SRE) nodig voor bewerkingen met betrekking tot het cluster en afhankelijke services. De rol is verantwoordelijk voor het onderhouden van beveiliging, isolatie, implementatie en waarneembaarheid. Formaliseer deze definities en bepaal de machtigingen die deze rollen nodig hebben. SRE's zijn bijvoorbeeld zeer bevoegd voor clustertoegang, maar hebben leestoegang nodig tot workloadnaamruimten.
Isolatie van workloads
PCI-DSS 3.2.1 vereist isolatie van de PCI-workload van andere workloads in termen van bewerkingen. In deze implementatie worden de workloads binnen het bereik en buiten het bereik gesegmenteerd in twee afzonderlijke gebruikersknooppuntgroepen. Toepassingsontwikkelaars voor binnen- en ontwikkelaars voor workloads buiten het bereik kunnen verschillende sets machtigingen hebben. Ook zijn er aparte kwaliteitspoorten. De code binnen het bereik is bijvoorbeeld onderworpen aan naleving en attestation, terwijl de code buiten het bereik niet is. Er is ook behoefte aan afzonderlijke build-pijplijnen en releasebeheerprocessen.
Operationele metagegevens
Vereiste 12 van de PCI DSS 3.2.1-standaard vereist dat u informatie over inventarisatie van werkbelastingen en documentatie voor personeelstoegang onderhoudt. We raden u ten zeerste aan Azure-tags te gebruiken, omdat u omgevingsgegevens kunt sorteren met Azure-resources, resourcegroepen en abonnementen.
Behoud informatie over goedgekeurde oplossingen die deel uitmaken van de infrastructuur en workload. Dit omvat een lijst met VM-installatiekopieën, databases en oplossingen van derden van uw keuze die u naar de CDE brengt. U kunt dat proces zelfs automatiseren door een servicecatalogus te bouwen. Het biedt selfservice-implementatie met behulp van deze goedgekeurde oplossingen in een specifieke configuratie, die voldoet aan doorlopende platformbewerkingen.
Waarneembaarheid
Om aan vereiste 10 te voldoen, is waarneembaarheid in de CDE essentieel voor naleving. Activiteitenlogboeken bieden informatie over bewerkingen met betrekking tot account- en geheimbeheer, beheer van diagnostische instellingen, serverbeheer en andere resourcetoegangsbewerkingen. Alle logboeken worden vastgelegd met datum, tijd, identiteit en andere gedetailleerde informatie. Bewaar logboeken tot een jaar door gegevensretentie en archiefbeleid te configureren in Azure Monitor-logboeken.
Zorg ervoor dat logboeken alleen worden geopend door rollen die ze nodig hebben. Log Analytics en Microsoft Sentinel ondersteunen verschillende op rollen gebaseerde toegangsbeheer om toegang tot audittrails te beheren.
Antwoord en herstel
De Azure-bewakingsservices, Azure Monitor en Microsoft Defender voor Cloud, kunnen meldingen of waarschuwingen genereren wanneer ze afwijkende activiteiten detecteren. Deze waarschuwingen bevatten contextinformatie, zoals ernst, status en activiteitstijd. Wanneer waarschuwingen worden gegenereerd, moet u een herstelstrategie hebben en de voortgang controleren. We raden u aan om gegevens te centraliseren in een SIEM-oplossing (Security Information and Event Management), omdat het integreren van gegevens uitgebreide waarschuwingscontext kan bieden.
Vanuit de weergave Beveiligingswaarschuwingen in Microsoft Defender voor Cloud hebt u toegang tot alle waarschuwingen die Microsoft Defender voor Cloud detecteert op uw resources. Zorg voor een sorteerproces om het probleem op te lossen. Werk samen met uw beveiligingsteam om te begrijpen hoe relevante waarschuwingen beschikbaar worden gesteld aan de eigenaren van de workload.
Prestatie-efficiëntie
Volg de fundamentele richtlijnen in de principes voor prestatie-efficiëntie. Aanbevolen procedures voor een gereguleerde omgeving worden in deze secties samengevat.
Schalen
Als u ziet hoe de omgeving zich aanpast aan veranderende eisen, wordt het verwachte runtimegedrag van de omgeving onder hoge belasting aangegeven. Door resources in de workload automatisch te schalen, wordt de menselijke interactie in de CDE geminimaliseerd. Een extra beveiligingsvoordeel is het verminderen van de kwetsbaarheid voor aanvallen. U kunt het voordeel maximaliseren door gebruik te maken van resources die ondersteuning bieden voor de benadering van schalen naar nul. AKS ondersteunt bijvoorbeeld het omlaag schalen van de gebruikersknooppuntgroepen naar 0. Zie Knooppuntgroepen van gebruikers schalen naar 0 voor meer informatie.
Partitionering
Partitionering is een belangrijke factor voor prestatie-efficiëntie in gereguleerde workloads. Het gebruik van discrete onderdelen zorgt voor een scherpe definitie van verantwoordelijkheid en helpt bij nauwkeurige controles, zoals netwerkbeleid. Net als bij elke segmentatiestrategie is partitioneren onderdelen geïsoleerd en wordt de impact van straalstraal op onverwachte fouten of systeemcompromittatie bepaald.
Architectuur met gedeelde niets
De architectuur met gedeelde inhoud is ontworpen om conflicten tussen werkbelastingen met een punt te verwijderen. Dit is ook een strategie voor het verwijderen van single points of failure. In een gereguleerde omgeving moeten onderdelen worden geïsoleerd door logische of fysieke grenzen. Dit is afgestemd op de architectuur met gedeelde niets, wat resulteert in schaalbaarheidsvoordelen. Daarnaast is het mogelijk om relevante beveiligingscontroles en strengere controlemogelijkheden van de verschillende onderdelen te gebruiken.
Lichtgewicht frameworks
Complexiteit van workloads is moeilijk te documenteren en te controleren. Streven naar eenvoud vanwege de prestatievoordelen en het gemak van het controleren van wettelijke vereisten. Evalueer keuzes die meer adem hebben dan nodig is, omdat dit het kwetsbaarheid voor aanvallen vergroot en het potentieel voor misbruik of onjuiste configuratie.
Betrouwbaarheid
De betrouwbaarheid van gereguleerde omgevingen moet voorspelbaar zijn, zodat ze consistent kunnen worden uitgelegd voor controledoeleinden. Volg de fundamentele richtlijnen in de principes voor betrouwbaarheid. Aanbevolen procedures voor een gereguleerde omgeving worden in deze secties samengevat.
Hersteldoelen en herstel na noodgevallen
Vanwege de gevoelige aard van de gegevens die worden verwerkt in gereguleerde workloads, zijn hersteldoelen en beoogde herstelpunten (RPO's) essentieel om te definiëren. Wat is acceptabel verlies van CHD? Herstelinspanningen binnen de CDE zijn nog steeds onderworpen aan de standaardvereisten. Verwacht fouten en heb een duidelijk herstelplan voor deze fouten die zijn afgestemd op rollen, verantwoordelijkheden en uitgevulde gegevenstoegang. Problemen met livesites zijn geen reden voor het afwijken van voorschriften. Dit is vooral belangrijk in een volledige noodherstelsituatie. Zorg voor duidelijke documentatie voor herstel na noodgevallen die aan de vereisten voldoet en onverwachte CDE- of CHD-toegang minimaliseert. Controleer na het herstel altijd de stappen voor het herstelproces om ervoor te zorgen dat er geen onverwachte toegang is opgetreden. Documenteer zakelijke redenen voor deze exemplaren.
Herstel
Het toevoegen van tolerantie- en herstelstrategieën aan uw architectuur kan voorkomen dat ad-hoctoegang tot de CDE nodig is. Het systeem moet zichzelf kunnen herstellen bij de gedefinieerde RPO zonder dat directe menselijke tussenkomst nodig is. Op deze manier kunt u onnodige blootstelling van CHD elimineren, zelfs voor personen die gemachtigd zijn om toegang tot noodgevallen te hebben. Het herstelproces moet controleerbaar zijn.
Beveiligingsrisico's aanpakken
Bekijk beveiligingsrisico's omdat ze een bron kunnen zijn van downtime van workloads en gegevensverlies. De investeringen in beveiliging hebben ook invloed op de betrouwbaarheid van workloads.
Operationele processen
Betrouwbaarheid is een uitbreiding op alle operationele processen in en grenzend aan de CDE. Goed gedefinieerde, geautomatiseerde en geteste processen voor problemen zoals het bouwen van afbeeldingen en jump box management factor in een goed ontworpen oplossing.
Kostenoptimalisatie
Volg de fundamentele richtlijnen in de principes van Kostenoptimalisatie.
Vanwege de nalevingsvereisten en strikte beveiligingscontroles is een duidelijke afweging kosten. We raden u aan om initiële schattingen te maken met behulp van de prijscalculator.
Hier volgt een algemene weergave van de kostenimpact van de belangrijkste resources die door deze architectuur worden gebruikt.
De belangrijkste stuurprogramma's zijn de virtuele-machineschaalsets waaruit de knooppuntgroepen en Azure Firewall bestaan. Een andere inzender is Log Analytics. Er zijn ook incrementele kosten gekoppeld aan Microsoft Defender voor Cloud, afhankelijk van uw keuze aan abonnementen.
Een duidelijk begrip hebben van wat de prijs van een service is. Azure houdt het gebruik van datalimiet bij. Hier volgt een analyse van Azure Firewall voor deze architectuur.
De kosten die zijn gekoppeld aan sommige resources, zoals Azure Firewall, kunnen worden verdeeld over meerdere bedrijfseenheden en/of toepassingen. Een andere manier om de kosten te optimaliseren, is het hosten van een multitenant-cluster binnen een organisatie, waardoor de dichtheid wordt gemaximaliseerd met de diversiteit van de werkbelasting. We raden deze benadering niet aan voor gereguleerde workloads. Geef altijd prioriteit aan naleving en segmentatie ten opzichte van kostenvoordelen.
Als u binnen de budgetbeperkingen wilt blijven, zijn sommige manieren om de kosten te beheren door de Azure-toepassing Gateway-infrastructuur aan te passen, het aantal exemplaren voor automatisch schalen in te stellen en de logboekuitvoer te verminderen zolang ze nog steeds voldoen aan het audittrail dat is vereist voor PCI-DSS 3.2.1. Evalueer deze keuzes altijd tegen de compromissen op andere aspecten van het ontwerp waarmee u aan uw SLA kunt voldoen. U kunt bijvoorbeeld nog steeds schalen om te voldoen aan pieken in het verkeer.
Wanneer u groepen Azure-resources maakt, past u tags toe zodat deze kunnen worden bijgehouden voor kosten. Gebruik hulpprogramma's voor kostenbeheer, zoals Azure Advisor en Azure Cost Management , voor het bijhouden en analyseren van kosten.
Overweeg om AKS-kostenanalyse in te schakelen voor gedetailleerde kostentoewijzing van clusterinfrastructuur door kubernetes-specifieke constructies.