Architectuursamenvatting van een gereguleerd AKS-cluster (deel 9 van 9)

Kubernetes-service
Firewall
Application Gateway
Azure Active Directory
Azure Security Center
Monitor

Het Azure Well-Architected Framework is een set leidende grondbeginselen die kunnen worden gebruikt om een oplossing te beoordelen via de kwaliteitspijlers van hoogwaardige architectuur:

Dit artikel eindigt deze reeks. Lees de inleiding.

Deze richtlijnen in deze reeks bevatten Well-Architected principes in alle ontwerpkeuzen. In dit artikel worden deze keuzes samengevat. De GitHub: Azure Kubernetes Service (AKS) Basislijncluster voor de implementatie van gereguleerde workloads demonstreert deze principes, indien van toepassing.

PCI DSS 3.2.1-workloads moeten een goed ontworpen oplossing zijn. Hoewel het afstemmen van de infrastructuur met PCI-vereisten essentieel is, stopt 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 de benodigde belasting te bereiken voor het bereiken van compatibele resultaten.

Beveiliging

Volg de fundamentele richtlijnen in de beveiligingsontwerpprincipes. Best practices 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 besturingselementen voor het onderhouden van segmentatie, het openen van resources, het detecteren van beveiligingsproblemen en de belangrijkste bescherming van klantgegevens.

Strategie voor enterprisesegmentatie

Om volledige isolatie te behouden, raden we u aan 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 op uniforme wijze voor uw binnen bereik-abonnementen past. Pas binnen het abonnement gerelateerde Azure-beleidsregels toe op abonnementsniveau om de brede beleidsregels vast te leggen die van toepassing moeten zijn op alle clusters in de gegevensomgeving van de kaarthouder (CDE). Pas gerelateerde Azure-beleidsregels toe op het niveau van de resourcegroep om beleidsregels vast te leggen die van toepassing zijn op een specifiek cluster-exemplaar. Met deze beleidsregels worden de belangrijkste beveiligingslijnen van een landingszone gebouwd.

Isoleer de PCI-workload (binnen het bereik) van andere (buiten het bereik) workloads wat betreft bewerkingen en connectiviteit. U kunt isolatie maken door afzonderlijke clusters te implementeren. Of gebruik segmentatiestrategieën om de scheiding te behouden. De clusters maken bijvoorbeeld gebruik van afzonderlijke knooppuntgroepen, zodat workloads nooit een virtuele machine (VM) van een knooppunt delen.

Beleidsafdwinging

Beveiligingscontroles afdwingen door Azure-beleid in te stellen. In deze gereguleerde architectuur kunt u bijvoorbeeld onjuiste configuratie van de gegevensomgeving van de kaarthouder voorkomen. U kunt een Azure-beleid toepassen dat geen openbare IP-toewijzingen toestaat op de VM-knooppunten. Dergelijke toewijzingen worden gedetecteerd en gerapporteerd of geblokkeerd.

Zie ingebouwde definities voor AKS voor meer Azure Policy over beleidsregels die u voor AKS kunt Azure Kubernetes Service.

Azure biedt verschillende ingebouwde beleidsregels voor de meeste services. Bekijk deze Azure Policy ingebouwde beleidsdefinities en pas deze waar nodig toe.

Nalevingscontrole

Naleving moet systematisch worden bewaakt en onderhouden. Er worden regelmatig nalevingsverklaringen uitgevoerd. Als u weet of uw cloudbronnen in overeenstemming zijn, kunt u zich voorbereiden op attestations en controle.

Profiteer van het dashboard voor naleving van regelgeving in Azure Security Center. Door het dashboard continu te bewaken, kunt u de nalevingsstatus van uw workload bijhouden.

Voorbeeld van nalevingscontrole

Netwerkbeveiliging

In een hub-spoke-topologie biedt het hebben van afzonderlijke virtuele netwerken voor elke entiteit basissegmentatie in de netwerkvoetafdruk. Elk netwerk wordt verder gesegmenteerd in subnetten.

Het AKS-cluster vormt de kern van de CDE. Het mag niet toegankelijk zijn vanaf openbare IP-adressen en connectiviteit moet worden beveiligd. Typische stromen van en naar CDE kunnen worden gecategoriseerd als:

  • Inkomende verkeer naar het cluster.
  • Uitgaand verkeer van het cluster.
  • In-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 het verkeer van en naar het openbare internet beperkt. Zelfs communicatie met de door AKS beheerde Kubernetes API-server is privé. De beveiliging wordt verder verbeterd met strikte netwerkbesturingselementen en IP-firewallregels.

  • Netwerkbeveiligingsgroepen (NSG's) om de communicatie tussen resources binnen een netwerk te beveiligen.
  • Azure Firewall om uitgaand verkeer tussen cloudbronnen, internet en on-premises te filteren.
  • Azure Application Gateway geïntegreerd met Azure Web Application Framework om al het binnenkomende verkeer van internet te filteren dat Azure Application Gateway onderschept.
  • Kubernetes NetworkPolicy om alleen bepaalde paden toe te staan tussen de pods in het cluster.
  • Azure Private Link verbinding maken met andere Azure platform as a service(PaaS)-services, zoals Azure Key Vault en Azure Container Registry voor operationele taken.

Er zijn bewakingsprocessen om ervoor te zorgen dat de verkeersstromen naar verwachting verlopen en dat eventuele anomalie wordt gedetecteerd en gerapporteerd.

Zie Netwerksegmentatie voor meer informatie over netwerkbeveiliging.

Gegevensbeveiliging

PCI-DSS 3.2.1 vereist dat alle gegevens van kaartaanduidingen (CHD) nooit duidelijk zijn, ongeacht of deze in transit of in opslag zijn.

Omdat deze architectuur en de implementatie zijn gericht op infrastructuur en niet op de workload, wordt gegevensbeheer niet gedemonstreerd. Hier volgen enkele goed ontworpen aanbevelingen.

Inactieve gegevens

De gegevens moeten worden versleuteld met industriestandaard versleutelingsalgoritmen.

  • Sla geen gegevens op in de kaartaanduidingsomgeving.
  • 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. Zelf beheerde versleutelingssleutels hebben de voorkeur.

Als u gegevens tijdelijk wilt opslaan, moet u dezelfde overwegingen toepassen op die gegevens. We raden u ten zeerste aan om de hostversleutelingsfunctie van AKS in teschakelen. U kunt versleuteling van tijdelijke gegevens afdwingen met ingebouwd Azure-beleid.

Wanneer u een opslagtechnologie kiest, verkent u de retentiefuncties. 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 blootgesteld aan logboeken, bestandsnamen, cachegegevens en andere gegevens.

Actieve gegevens

Alle communicatie met entiteiten die met de CDE communiceren, moet via versleutelde kanalen worden verzonden.

  • Alleen HTTPS-verkeer mag naar de CDE stromen. In deze architectuur Azure Application Gateway al het verkeer via poort 80.
  • Versleutel en ontsleutel bij voorkeur geen gegevens buiten de CDE. Als u dit doet, kunt u die entiteit beschouwen als onderdeel van de CDE.
  • Binnen de CDE biedt veilige communicatie tussen pods met mTLS. U kunt ervoor kiezen om een service-mesh te implementeren voor dit doel.
  • Sta alleen beveiligde coderingen en TLS 1.2 of hoger toe.

Identiteit

Volg deze beveiligingsprincipes bij het ontwerpen van toegangsbeleid:

  • Begin met Zero-Trust beleidsregels. Maak zo nodig uitzonderingen.
  • Verleen de minste bevoegdheden, net genoeg om een taak te voltooien.
  • Permanente toegang minimaliseren.

Kubernetes RBAC (op rollen gebaseerd toegangsbeheer) beheert machtigingen voor de Kubernetes-API. AKS ondersteunt deze Kubernetes-rollen. AKS is volledig geïntegreerd met Azure Active Directory (Azure AD). U kunt Azure AD-identiteiten toewijzen aan de rollen en ook profiteren van andere mogelijkheden.

Zero-Trust toegang

Kubernetes RBAC-, Azure RBAC- en Azure-services implementeren alles standaard weigeren. Overschrijven deze instelling voorzichtig, zodat alleen de entiteiten die deze nodig hebben toegang hebben. Een ander gebied voor het implementeren Zero-Trust is het uitschakelen van SSH-toegang tot de clusterknooppunten.

Minste bevoegdheden

U kunt beheerde identiteiten gebruiken voor Azure-resources en -pods en deze scopen voor de verwachte taken. Zo moeten Azure Application Gateway 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 permanente toegang met behulp van Just-In-Time Azure AD-groepslidmaatschap. Besturingselementen verbeteren met beleid voor voorwaardelijke toegang in Azure AD. Deze optie ondersteunt veel gebruiksgevallen, zoals meervoudige verificatie, het beperken van verificatie tot apparaten die worden beheerd door uw Azure AD-tenant of het blokkeren van atypische aanmeldingspogingen.

Geheimenbeheer

Sla geheimen, certificaten, sleutels en wachtwoorden op buiten de CDE. U kunt de native Kubernetes-geheimen of een beheerd sleutelopslag gebruiken, zoals Azure Key Vault. Het gebruik van een beheerde opslag helpt bij geheime beheertaken, zoals sleutelrotatie en certificaatvernieuwing.

Zorg ervoor dat de toegang tot het sleutelopslag is verbonden met een balans tussen netwerk- en toegangsbesturingselementen. Wanneer u beheerde identiteiten inschakelen, moet het cluster zichzelf verifiëren aan de Key Vault om toegang te krijgen. Bovendien mag de verbinding met het sleutelopslag niet via het openbare internet zijn. Gebruik een particulier netwerk, zoals Private Link.

Operationele topprestaties

Volg de fundamentele richtlijnen in de principes voor operationele uitmuntendheid. Best practices voor een gereguleerde omgeving worden in deze secties samengevat.

Scheiding van rollen

Het afdwingen van duidelijke scheiding van taken voor gereguleerde omgevingen is essentieel. Definities van rollen en verantwoordelijkheden hebben op basis van de behoeften van de workload en interactie met de CDE. U hebt bijvoorbeeld mogelijk een infrastructuuroperator of SRE-rol (Site Reliability Engineer) 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 hebben bijvoorbeeld hoge bevoegdheden voor clustertoegang, maar moeten leestoegang hebben tot naamruimten van workloads.

Isolatie van workloads

PCI-DSS 3.2.1 vereist isolatie van de PCI-workload van andere werkbelastingen in termen van bewerkingen. In deze implementatie worden de werkbelastingen binnen en buiten het bereik gesegmenteerd in twee afzonderlijke gebruikers-knooppuntgroepen. Toepassingsontwikkelaars voor binnen het bereik en ontwikkelaars voor werkbelastingen buiten het bereik hebben mogelijk verschillende sets machtigingen. Er zijn ook afzonderlijke kwaliteitspoorten. De code binnen het bereik is bijvoorbeeld onderhevig aan het handhaven van 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 bijhoudt over de inventaris van workloads en documentatie over toegang tot personeel. We raden u ten zeerste aan Om Azure-tags te gebruiken, omdat u omgevingsgegevens kunt verzamelen met Azure-resources, resourcegroepen en abonnementen.

Informatie onderhouden over goedgekeurde oplossingen die deel uitmaken van de infrastructuur en workload. Dit omvat een lijst met VM-afbeeldingen, databases en oplossingen van derden 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 de lopende platformbewerkingen.

Waarneembaarheid

Om te voldoen aan vereiste 10 is waarneembaarheid in de CDE essentieel voor naleving. Activiteitenlogboeken bevatten informatie over bewerkingen met betrekking tot account- en geheimbeheer, beheer van diagnostische instellingen, serverbeheer en andere bewerkingen voor toegang tot resources. Alle logboeken worden vastgelegd met datum, tijd, identiteit en andere gedetailleerde informatie. Bewaar logboeken maximaal een jaar voor in opslagaccounts voor langetermijnarchivering en controle.

Zorg ervoor dat logboeken alleen toegankelijk zijn voor rollen die ze nodig hebben. Log Analytics en Azure Sentinel ondersteuning voor verschillende op rollen gebaseerd toegangsbesturingselementen voor het beheren van audittrailtoegang.

Antwoord en herstel

De Bewakingsservices van Azure, Azure Monitor en Azure Security Center, kunnen meldingen of waarschuwingen genereren wanneer afwijkende activiteiten worden gedetecteerd. Deze waarschuwingen bevatten contextinformatie zoals ernst, status en activiteitstijd. Wanneer waarschuwingen worden gegenereerd, moet u een herstelstrategie hebben en de voortgang controleren. Het is raadzaam om gegevens te centraliseren in een SIEM-oplossing (Security Information and Event Management), omdat het integreren van gegevens een uitgebreide waarschuwingscontext kan bieden.

Vanuit de weergave Beveiligingswaarschuwingen in Azure Security Center hebt u toegang tot alle waarschuwingen die Azure Security Center uw resources detecteert. Een triageproces hebben om het probleem op te lossen. Werk samen met uw beveiligingsteam om te begrijpen hoe relevante waarschuwingen beschikbaar worden gesteld aan de eigenaren van workloads.

Prestatie-efficiëntie

Volg de fundamentele richtlijnen in de principes voor prestatie-efficiëntie. Best practices 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 bij hoge belasting aangegeven. Door resources in de workload automatisch te schalen, wordt menselijke tussenkomst in de CDE geminimaliseerd. Een extra beveiligingsvoordeel is het te allen tijde verminderen van het aanvalsoppervlak. U kunt het voordeel maximaliseren door gebruik te maken van resources die ondersteuning bieden voor de benadering van schalen naar nul. AKS biedt bijvoorbeeld ondersteuning voor het omlaag schalen van de gebruikers-knooppuntgroepen naar 0. Zie Gebruikers-knooppuntgroepen schalen naar 0 voor meer informatie.

Partitionering

Partitionering is een belangrijke factor voor de efficiëntie van de prestaties in gereguleerde workloads. Het gebruik van discrete onderdelen maakt een duidelijke definitie van verantwoordelijkheid mogelijk en helpt bij nauwkeurige besturingselementen, zoals netwerkbeleid. Net als bij elke segmentatiestrategie is partitioneren onderdelen geïsoleerd en wordt de impact van een radius op onverwachte fouten of systeemcompromittie gecontroleerd.

Shared-nothing-architectuur

De shared-nothing-architectuur is ontworpen om de strijd tussen co-locatieworkloads 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 komt overeen met de shared-nothing-architectuur, wat resulteert in schaalbaarheidsvoordelen. Het biedt ook de mogelijkheid om relevante beveiligingscontroles en strengere controlemogelijkheden van de verschillende onderdelen te targeten.

Lightweight-frameworks

De complexiteit van workloads is moeilijk te documenteren en te controleren. Probeer het eenvoudig te houden vanwege de prestatievoordelen en het gemak van het controleren van wettelijke vereisten. Evalueer keuzes die moeilijker zijn dan nodig is, omdat hierdoor het aantal aanvallen toeneemt surface area de kans op misbruik of onjuiste configuratie.

Betrouwbaarheid

De betrouwbaarheid van gereguleerde omgevingen moet voorspelbaar zijn, zodat deze consistent kunnen worden uitgelegd voor controledoeleinden. Volg de fundamentele richtlijnen in de betrouwbaarheidsprincipes. Best practices voor een gereguleerde omgeving worden in deze secties samengevat.

Hersteldoelen en herstel na noodherstel

Vanwege de gevoelige aard van de gegevens die worden verwerkt in gereguleerde workloads, zijn hersteldoelen en herstelpuntdoelstellingen (RPO's) essentieel om te definiëren. Wat is acceptabel verlies van CHD? Herstelinspanningen binnen de CDE zijn nog steeds onderhevig aan de standaardvereisten. Verwacht fouten en heb een duidelijk herstelplan voor fouten die zijn afgestemd op rollen, verantwoordelijkheden en gerechtvaardigde gegevenstoegang. Problemen met live-site zijn geen reden om van regelgeving te afwijken. Dit is vooral belangrijk in een situatie met volledig herstel na noodherstel. Duidelijke documentatie voor herstel na noodherstel die voldoet aan de vereisten en onverwachte CDE- of CHD-toegang minimaliseert. Controleer na het herstel altijd de stappen van het herstelproces om ervoor te zorgen dat er geen onverwachte toegang is opgetreden. Documenteren van zakelijke redenen voor deze instanties.

Herstel

Het toevoegen van tolerantie- en herstelstrategieën aan uw architectuur kan de noodzaak van ad-hoctoegang tot de CDE verhinderen. Het systeem moet zichzelf kunnen herstellen op de gedefinieerde RPO zonder dat er direct menselijke tussenkomst nodig is. Op deze manier kunt u onnodige blootstelling van CHD voorkomen, zelfs voor personen die zijn gemachtigd voor toegang in noodgevallen. Het herstelproces moet controleerbaar zijn.

Bekijk beveiligingsrisico's omdat deze een bron kunnen zijn van downtime en gegevensverlies van workloads. De investeringen in beveiliging hebben ook invloed op de betrouwbaarheid van workloads.

Operationele processen

Betrouwbaarheid is een uitbreiding op alle operationele processen in en naast de CDE. Goed gedefinieerde, geautomatiseerde en geteste processen voor zaken zoals het bouwen van afbeeldingen en jump box-beheer in een goed ontworpen oplossing.

Kostenoptimalisatie

Volg de fundamentele richtlijnen in de principes van Kostenoptimalisatie.

Vanwege de nalevingsvereisten en strikte beveiligingscontroles zijn kosten een duidelijke afweging. We raden u aan om een eerste schatting te maken met behulp van de prijscalculator.

Hier is een weergave op hoog niveau van de kostenimpact van de belangrijkste resources die in deze architectuur worden gebruikt.

Diagram van kostenbeheer in de architectuur.

De belangrijkste stuurprogramma's zijn de virtuele-machineschaalsets waar de knooppuntgroepen en Azure Firewall. Een andere inzender is Log Analytics. Er zijn ook incrementele kosten verbonden aan Azure Defender, afhankelijk van uw gekozen plannen.

Een duidelijk inzicht hebben in wat de prijs van een service is. Azure houdt het gebruik naar gebruik naar gebruik bij. Hier is een overzicht van de Azure Firewall voor deze architectuur.

Diagram met een voorbeeld van kostenbeheer in Azure Firewall voorbeeld.

De kosten voor 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 met de diversiteit van workloads wordt gemaximalisatie. We raden deze benadering niet aan voor gereguleerde workloads. Geef altijd prioriteit aan naleving en segmentering boven kostenvoordelen.

Om binnen de budgetbeperkingen te blijven, kunt u de kosten onder andere beheren door de Azure Application Gateway-infrastructuur aan te passen, het aantal exemplaren voor automatisch schalen in te stellen en de logboekuitvoer te verminderen zolang ze voldoen aan de audittrail die is vereist voor PCI-DSS 3.2.1. Evalueer deze keuzes altijd op basis van de afwegingen ten opzichte van andere aspecten van het ontwerp waarmee u aan uw SLA kunt voldoen. Kunt u bijvoorbeeld nog steeds op de juiste manier schalen om te voldoen aan pieken in het verkeer.

Wanneer u groepen Azure-resources maakt, moet u tags toepassen zodat ze kunnen worden bijgespoord voor kosten. Gebruik hulpprogramma's voor kostenbeheer Azure Advisor en Azure Cost Management voor het bijhouden en analyseren van kosten.