Gegevens beveiligen in een gereguleerd AKS-cluster voor PCI-DSS 3.2.1 (deel 4 van 9)

In dit artikel worden de overwegingen beschreven voor een Azure Kubernetes Service-cluster (AKS) met een workload die voldoet aan de Payment Card Industry Data Security Standard (PCI-DSS 3.2.1).

Dit artikel maakt deel uit van een serie. Lees de inleiding.

Deze architectuur en de implementatie zijn gericht op infrastructuur en niet op de workload. Dit artikel bevat algemene overwegingen en best practices om u te helpen bij het nemen van ontwerpbeslissingen. Volg de vereisten in de officiële PCI-DSS 3.2.1-standaard en gebruik dit artikel als aanvullende informatie, indien van toepassing.

Kaartgegevens beveiligen

Vereiste 3 — Opgeslagen kaartaanduidingsgegevens beveiligen

Uw verantwoordelijkheden

Vereiste	Verantwoordelijkheid
Vereiste 3.1	Houd de gegevensopslag van kaartaanduidingen tot een minimum beperkt door beleid voor gegevensretentie en -verwijdering te implementeren, procedures en processen die ten minste het volgende bevatten voor alle CHD-opslag (cardholder data:
Vereiste 3.2	Sla na de autorisatie geen gevoelige verificatiegegevens op (zelfs niet als deze zijn versleuteld). Als gevoelige verificatiegegevens worden ontvangen, kunt u alle gegevens onherkenbaar maken wanneer het autorisatieproces is voltooid.
Vereiste 3.3	Masker PAN wanneer deze worden weergegeven (de eerste zes en laatste vier cijfers zijn het maximum aantal cijfers dat moet worden weergegeven), zodat alleen medewerkers met een legitieme zakelijke behoefte de volledige PAN kunnen zien.
Vereiste 3.4	Render PAN onleesbaar overal waar het is opgeslagen (inclusief op draagbare digitale media, back-upmedia en in logboeken) met behulp van een van de volgende methoden:
Vereiste 3.5	Documenteren en implementeren van procedures voor het beveiligen van sleutels die worden gebruikt om opgeslagen gegevens van kaartaanduidingen te beveiligen tegen openbaarmaking en misbruik:
Vereiste 3.6	Documenteren en implementeren van alle processen en procedures voor sleutelbeheer voor cryptografische sleutels die worden gebruikt voor het versleutelen van gegevens van kaartaanduidingen, inclusief de volgende:
Vereiste 3.7	Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het beveiligen van opgeslagen kaarthoudergegevens worden gedocumenteerd, in gebruik zijn en bekend zijn bij alle betrokken partijen.

Vereiste 4 — Versleutel de overdracht van kaartgegevens in open openbare netwerken.

Uw verantwoordelijkheden

Vereiste	Verantwoordelijkheid
Vereiste 4.1	Gebruik sterke cryptografie- en beveiligingsprotocollen (bijvoorbeeld TLS, IPSEC, SSH, enzovoort) om gevoelige gegevens van kaartaanduidingen te beveiligen tijdens de overdracht via open openbare netwerken, waaronder de volgende:
Vereiste 4.2	Verzend nooit onbeveiligde PAN's met berichtentechnologieën voor eindgebruikers (bijvoorbeeld e-mail, chatberichten, sms, chat, enzovoort).
Vereiste 4.3	Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het versleutelen van overdrachten van gegevens van kaartaanduidingen in gebruik zijn gedocumenteerd en bekend zijn bij alle betrokken partijen.

Vereiste 3.1

Houd de gegevensopslag van kaartaanduidingen tot een minimum beperkt door beleid voor gegevensretentie en -verwijdering te implementeren, procedures en processen die ten minste het volgende bevatten voor alle CHD-opslag (cardholder data:

• De hoeveelheid gegevensopslag en bewaartijd beperken tot de hoeveelheid die vereist is voor juridische, wettelijke en zakelijke vereisten
• Processen voor het veilig verwijderen van gegevens wanneer deze niet meer nodig zijn
• Specifieke retentievereisten voor kaartgegevens
• Een driemaandelijkse procedure voor het identificeren en veilig verwijderen van gegevens van opgeslagen kaartaanduidingen die de gedefinieerde retentie overschrijden.

Uw verantwoordelijkheden

Sla de status niet op in het AKS-cluster. Als u ervoor kiest om CHD op te slaan, verkent u de opties voor beveiligde opslag. Opties zijn Azure Storage voor bestandsopslag of databases zoals Azure SQL Database of Azure Cosmos DB.

Voldoe strikt aan de standaard richtlijnen over wat voor soort CHD kan worden opgeslagen. Definieer beleid voor gegevensretentie op basis van uw bedrijfsvereisten en het gebruikte type opslag. Enkele belangrijke overwegingen zijn:

• Hoe en waar worden de gegevens opgeslagen?
• Zijn de opgeslagen gegevens versleuteld?
• Wat is de bewaarperiode?
• Welke acties zijn toegestaan tijdens de retentieperiode?
• Hoe kunt u de opgeslagen gegevens verwijderen nadat de bewaarperiode is verlopen?

Governancebeleid rond een aantal van deze opties hebben. Ingebouwde Azure-beleidsregels dwingen deze keuzes af. U kunt bijvoorbeeld de volumetypen op de clusterpods beperken of schrijfbewerkingen op het hoofdbestandssysteem weigeren.

Bekijk deze lijst met beleidsdefinities en pas deze toe op het cluster, indien van toepassing.

Mogelijk moet u gegevens tijdelijk in de cache opslaan. U wordt aangeraden de gegevens in de cache te beveiligen terwijl deze naar een opslagoplossing worden verplaatst. Overweeg de hostgebaseerde versleutelingsfunctie in teschakelen in AKS. Hiermee worden de gegevens versleuteld die zijn opgeslagen op knooppunt-VM's. Zie Op host gebaseerde versleuteling op basis van Azure Kubernetes Service (AKS)voor meer informatie. Schakel ook een ingebouwd Azure-beleid in dat versleuteling van tijdelijke schijven en cache vereist voor knooppuntgroepen.

Wanneer u een opslagtechnologie kiest, kunt u de retentiefuncties verkennen. Azure Blob Storage bijvoorbeeld een retentiebeleid op basis van tijd. Een andere keuze is het implementeren van een aangepaste oplossing die gegevens verwijdert op basis van bewaarbeleid. Een voorbeeld is Data Lifecycle Management (DLM), waarmee activiteiten in de levenscyclus van gegevens worden beheert. De oplossing is ontworpen met services zoals Azure Data Factory, Azure Active Directory (Azure AD) en Azure Key Vault.

Zie Managing the data life cycle using Azure Data Factory (De levenscyclus van gegevens beheren met behulp van Azure Data Factory).

Vereiste 3.2

Sla na de autorisatie geen gevoelige verificatiegegevens op (zelfs niet als deze zijn versleuteld). Als gevoelige verificatiegegevens worden ontvangen, kunt u alle gegevens onherkenbaar maken wanneer het autorisatieproces is voltooid.

Uw verantwoordelijkheden

(VAN TOEPASSING OP: Vereiste 3.2.1, Vereiste 3.2.2, Vereiste 3.2.3)

Het verwerken en beveiligen van gegevens valt buiten het bereik van deze architectuur. Hier zijn enkele algemene overwegingen.

Volgens de standaardwaarde bestaan gevoelige verificatiegegevens uit volledige volggegevens, kaartvalidatiecode of -waarde en pincodegegevens. Als onderdeel van CHD-verwerking, moet u ervoor zorgen dat verificatiegegevens niet beschikbaar zijn in bronnen zoals:

• Logboeken die worden uitgezonden vanuit de pods.
• Routines voor afhandeling van uitzonderingen.
• Bestandsnamen.
• Cache.

Als algemene richtlijn moet deze informatie niet worden opgeslagen. Als er een document nodig is, moet de zakelijke reden worden beantwoord.

Vereiste 3.3

Masker PAN wanneer deze worden weergegeven (de eerste zes en laatste vier cijfers zijn het maximum aantal cijfers dat moet worden weergegeven), zodat alleen medewerkers met een legitieme zakelijke behoefte de volledige PAN kunnen zien.

Uw verantwoordelijkheden

Het primaire accountnummer (PAN) wordt beschouwd als gevoelige gegevens en blootstelling aan deze gegevens moet worden voorkomen. Eén manier is het verminderen van de weergegeven cijfers door middel van maskering.

Implementeer geen gegevensmaskering in de workload. Gebruik in plaats daarvan constructies op databaseniveau. De Azure SQL-servicelijn, inclusief Azure Synapse Analytics, ondersteunt dynamische gegevensmaskering, waardoor de blootstelling op de toepassingslaag wordt beperkt. Het is een beveiligingsfunctie op basis van beleid waarmee wordt bepaald wie de niet-gemaskeerde gegevens kan bekijken en hoeveel gegevens via maskering beschikbaar worden gemaakt. De ingebouwde methode voor het maskeren van creditcards toont de laatste vier cijfers van de aangewezen velden en voegt een constante tekenreeks toe als voorvoegsel in de vorm van een creditcard.

Zie Dynamische gegevensmaskering voor meer informatie.

Als u niet-gemaskeerde gegevens in uw cluster wilt gebruiken, maskeert u zo snel mogelijk.

Vereiste 3.4

Render PAN onleesbaar overal waar het is opgeslagen (inclusief op draagbare digitale media, back-upmedia en in logboeken) met behulp van een van de volgende methoden:

• Hashes in één manier op basis van sterke cryptografie (hash moet van de hele PAN zijn)
• Afkaping (hashing kan niet worden gebruikt om het afgekapte segment van PAN te vervangen)
• Indextokens en -pads (pads moeten veilig worden opgeslagen)
• Sterke cryptografie met gekoppelde processen en procedures voor sleutelbeheer.

Uw verantwoordelijkheden

Voor deze vereiste moet u mogelijk directe cryptografie gebruiken in de workload. PCI DSS wordt aanbevolen om door de branche geteste algoritmen te gebruiken, zodat ze kunnen worden gebruikt tegen echte aanvallen. Vermijd het gebruik van aangepaste versleutelingsalgoritmen.

De juiste technieken voor gegevensmaskering voldoen ook aan deze vereiste. U bent verantwoordelijk voor het maskeren van alle PAN-gegevens (primary account number). De Azure SQL serviceregel, inclusief Azure Synapse Analytics, ondersteunt dynamische gegevensmaskering. Zie Vereiste 3.3.

Zorg ervoor dat PAN niet wordt blootgesteld als onderdeel van uw werkstroomprocessen. Hier zijn enkele overwegingen:

• Houd PAN buiten logboeken, zowel werkstroomlogboeken als (verwacht of onverwacht) logboeken voor het afhandelen van uitzonderingen. Bovendien mogen diagnostische gegevensstromen, zoals HTTP-headers, deze gegevens niet beschikbaar maken.

• Gebruik PAN niet als een opzoeksleutel voor de cache of als onderdeel van een bestandsnaam die door dit proces wordt gegenereerd.

• Uw klanten bieden PAN mogelijk ongeprompt in vrije tekstvelden. Zorg ervoor dat er inhoudsvalidatie- en detectieprocessen zijn voor vrije tekstvelden, en schoon alle inhoud op die lijkt op PAN-gegevens.

Vereiste 3.4.1

Als schijfversleuteling wordt gebruikt (in plaats van databaseversleuteling op bestands- of kolomniveau), moet logische toegang afzonderlijk en onafhankelijk van systeemeigen besturingssysteemverificatie en toegangsbeheermechanismen worden beheerd (bijvoorbeeld door geen lokale gebruikersaccountdatabases of algemene aanmeldingsreferenties voor het netwerk te gebruiken). Ontsleutelingssleutels mogen niet worden gekoppeld aan gebruikersaccounts.

Uw verantwoordelijkheden

Als algemene regel moet u de status niet opslaan in het AKS-cluster. Gebruik een externe gegevensopslag die ondersteuning biedt voor versleuteling op opslag-engineniveau.

Alle opgeslagen gegevens in Azure Storage worden versleuteld en ontsleuteld met behulp van sterke cryptografie. Microsoft beheert de bijbehorende sleutels. Zelf beheerde versleutelingssleutels hebben de voorkeur. Versleutel altijd buiten de opslaglaag en schrijf alleen versleutelde gegevens naar het opslagmedium, zodat de sleutels nooit naast de opslaglaag liggen.

Met Azure Storage kunt u ook zelf beheerde sleutels gebruiken. Zie Door de klant beheerde sleutels voor Azure Storage versleuteling voor meer informatie.

Vergelijkbare mogelijkheden zijn beschikbaar voor databases. Zie Azure SQL Transparent Data Encryption met door de klant beheerde sleutel voor SQL azure-opties.

Zorg ervoor dat u uw sleutels opgeslagen in een beheerd sleutelopslag (Azure Key Vault, Azure Key Vault Managed Hardware Security Module (HSM) en andere).

Als u gegevens tijdelijk moet opslaan, moet u de hostversleutelingsfunctie van AKS inschakelen om ervoor te zorgen dat gegevens die zijn opgeslagen op VM-knooppunten, worden versleuteld.

Vereiste 3.5

Documenteren en implementeren van procedures voor het beveiligen van sleutels die worden gebruikt om opgeslagen gegevens van kaartaanduidingen te beveiligen tegen openbaarmaking en misbruik:

Uw verantwoordelijkheden

Deze punten worden beschreven in de subsecties:

• Behoud de praktijk van toegang met de minste bevoegdheden voor de cryptografische sleutels.
• Azure Key Vault en Azure Active Directory zijn ontworpen ter ondersteuning van de vereisten voor autorisatie en auditlogregistratie. Zie Verificatie aanvragen voor Azure Key Vault.
• Be bescherm alle gegevensversleutelingssleutels met een sleutelversleutelingssleutel die is opgeslagen op een cryptografisch apparaat.
• Als u zelfbeheerde sleutels gebruikt (in plaats van door Microsoft beheerde sleutels), hebt u een proces en documentatie nodig voor het onderhouden van taken met betrekking tot sleutelbeheer.

Vereiste 3.5.1

Aanvullende vereiste voor alleen serviceproviders: Behoud een gedocumenteerde beschrijving van de cryptografische architectuur met:

• Details van alle algoritmen, protocollen en sleutels die worden gebruikt voor de beveiliging van gegevens van kaartaanduidingen, inclusief sleutelsterkte en vervaldatum
• Beschrijving van het sleutelgebruik voor elke sleutel
• Inventarisatie van alle HMS's en andere SCD's die worden gebruikt voor sleutelbeheer

Uw verantwoordelijkheden

Eén manier om gevoelige informatie (sleutels, verbindingsreeksen en andere) op te slaan, is met de native Kubernetes-resource. Secret U moet versleuteling-at-rest expliciet inschakelen. U kunt ze ook opslaan in een beheerde opslag, zoals Azure Key Vault. Van de twee benaderingen raden we u aan een beheerde store-service te gebruiken. Een voordeel is verminderde overhead bij taken met betrekking tot sleutelbeheer, zoals sleutelrotatie.

Azure gebruikt standaard door Microsoft beheerde sleutels voor alle versleutelde gegevens, per klant. Sommige services ondersteunen echter ook zelf beheerde sleutels voor versleuteling. Als u zelfbeheerde sleutels gebruikt voor versleuteling in rust, moet u rekening houden met een proces en strategie voor het afhandelen van belangrijke beheertaken.

Als onderdeel van uw documentatie bevat informatie met betrekking tot sleutelbeheer, zoals verloop, locatie en onderhoudsplandetails.

Vereiste 3.5.2

Beperk de toegang tot cryptografische sleutels tot het minste aantal bewaarders dat nodig is.

Uw verantwoordelijkheden

Minimaliseer het aantal personen dat toegang heeft tot de sleutels. Als u op groepen gebaseerde roltoewijzingen gebruikt, stelt u een terugkerend controleproces in om rollen te controleren die toegang hebben. Wanneer leden van het projectteam wijzigen, moeten accounts die niet meer relevant zijn, worden verwijderd uit machtigingen. Alleen de juiste mensen moeten toegang hebben. Overweeg om permanente machtigingen te verwijderen in plaats van JIT-roltoewijzingen (Just-In-Time), activering van rollen op basis van tijd en activering op basis van goedkeuring.

Vereiste 3.5.3

Sla te allen tijde geheime en persoonlijke sleutels op die worden gebruikt voor het versleutelen/ontsleutelen van kaartgegevens in een (of meer) van de volgende formulieren:

• Versleuteld met een sleutelversleutelingssleutel die minstens even sterk is als de sleutel voor gegevensversleuteling en die afzonderlijk van de versleutelingssleutel voor gegevens wordt opgeslagen
• Binnen een beveiligd cryptografisch apparaat (zoals een HSM (Hardware Security Module) of een door PTS goedgekeurd punt-van-interactie-apparaat)
• Ten minste twee sleutelonderdelen of sleutel shares voor volledige lengte, in overeenstemming met een door de branche geaccepteerde methode

Uw verantwoordelijkheden

Een PCI-DSS 3.2.1-workload moet meer dan één versleutelingssleutel gebruiken als onderdeel van de strategie voor data-at-rest-beveiliging. Er wordt een DEK (Data Encryption Key) gebruikt voor het versleutelen en ontsleutelen van de CHD, maar u bent verantwoordelijk voor een extra sleutelversleutelingssleutel (KEK) om die DEK te beveiligen. U bent ook verantwoordelijk voor het opslaan van de KEK op een cryptografisch apparaat.

U kunt de Azure Key Vault gebruiken om de DEK op te slaan en Azure Dedicated HSM KEK op te slaan. Zie Wat is Azure Dedicated HSM? voor meer informatie over Azure Dedicated HSM HSM-sleutelbeheer.

Vereiste 3.6

Documenteren en implementeren van alle processen en procedures voor sleutelbeheer voor cryptografische sleutels die worden gebruikt voor het versleutelen van gegevens van kaartaanduidingen, inclusief de volgende:

Uw verantwoordelijkheden

(VAN TOEPASSING OP: Vereiste 3.6.1, Vereiste 3.6.2, Vereiste 3.6.3, Vereiste 3.2.4)

Als u een Azure Key Vault voor het opslaan van geheimen zoals sleutels, certificaten en verbindingsreeksen, moet u deze beveiligen tegen onbevoegde toegang. Azure Defender voor Key Vault detecteert verdachte toegangspogingen en genereert waarschuwingen. U kunt deze waarschuwingen weergeven in Azure Security Center. Zie voor meer informatie Azure Defender voor Key Vault.

Volg de richtlijnen van het NIST over sleutelbeheer. Zie deze artikelen voor meer informatie:

• Cryptografische sleutelbeheer.
• SP 800-133 Rev. 2, Recommendation for Cryptographic Key Generation
• SP 800-57 Deel 1 Rev. 5, Aanbeveling voor sleutelbeheer

Zie ook Azure Defender voor Key Vault.

Vereiste 3.6.7

Preventie van niet-geautoriseerde vervanging van cryptografische sleutels.

Uw verantwoordelijkheden

• Schakel diagnostische gegevens in voor alle sleutelopslag. Gebruik Azure Monitor voor Key Vault. Het verzamelt logboeken en metrische gegevens en verzendt deze naar Azure Monitor. Zie Uw sleutelkluisservice bewaken met Azure Monitor voor Key Vault.
• Geef alle consumenten alleen-lezenmachtigingen.
• U hebt geen permanente machtigingen voor alle beheerservice-principals. Gebruik in plaats daarvan JiT-roltoewijzingen (Just-In-Time), activering van op tijd gebaseerde rollen en activering op basis van goedkeuring.
• Maak een gecentraliseerde weergave door logboeken en waarschuwingen te integreren in SIEM-oplossingen (Security Information and Event Management), zoals Azure Sentinel.
• Onderneemt actie op waarschuwingen en meldingen, met name bij onverwachte wijzigingen.

Vereiste 3.6.8

Vereiste dat cryptografische sleutelbewaarders formeel bevestigen dat ze hun verantwoordelijkheden als sleutelbewaarder begrijpen en accepteren.

Uw verantwoordelijkheden

Onderhoud documentatie waarin de accountmogelijkheden worden beschreven van de partijen die verantwoordelijk zijn voor het beheer van sleutels.

Vereiste 3.7

Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het beveiligen van opgeslagen kaarthoudergegevens worden gedocumenteerd, in gebruik zijn en bekend zijn bij alle betrokken partijen.

Uw verantwoordelijkheden

Maak documentatie als algemene instructie plus een reeks bijgewerkte rolhandleidingen voor alle persona's. Voer een training voor nieuwe medewerkers en doorlopende training uit.

Het is essentieel dat u grondige documentatie bijhoudt over de processen en het beleid. Verschillende teams doen mee om ervoor te zorgen dat gegevens in rust en in transit worden beveiligd. Geef in uw documentatie richtlijnen voor rollen voor alle persona's. De rollen moeten SRE, klantondersteuning, verkoop, netwerkbewerkingen, beveiligingsbewerkingen, softwaretechnici, databasebeheerders en andere omvatten. Medewerkers moeten worden getraind in NIST-richtlijnen en data-at-rest-strategieën om de vaardighedenset up-to-date te houden. Trainingsvereisten worden verholpen in Vereiste 6.5 en Vereiste 12.6.

Vereiste 4.1

Gebruik sterke cryptografie- en beveiligingsprotocollen (bijvoorbeeld TLS, IPSEC, SSH, e.d.) om gevoelige gegevens van kaartaanduidingen te beveiligen tijdens de overdracht via open openbare netwerken, waaronder de volgende:

Uw verantwoordelijkheden

Gegevens van kaarthouder (CHD) die via het openbare internet worden verzonden, moeten worden versleuteld. Gegevens moeten worden versleuteld met TLS 1.2 (of hoger), met minder coderingsondersteuning voor alle verzendingen. Bieden geen ondersteuning voor omleidingen van niet-TLS naar TLS op gegevensoverdrachtservices.

Uw ontwerp moet een strategische keten van TLS-beëindigingspunten hebben. Als gegevens via netwerkhops worden verplaatst, moet u TLS bij hops onderhouden waarvoor pakketinspectie is vereist. U moet ten minste het laatste TLS-beëindigingspunt hebben op de resource voor ingress van het cluster. Overweeg om verder te gaan binnen de clusterbronnen.

Gebruik Azure Policy om het maken van resources te beheren:

• Het maken van een niet-HTTPS-toegangsbeheermiddel weigeren.
• Het maken van openbare IP-adressen of openbare load balancers in uw cluster weigeren om ervoor te zorgen dat webverkeer via uw gateway wordt getunneld.

Zie Overzicht van Azure-versleuteling voor meer informatie.

Vereiste 4.1.1

Zorg ervoor dat draadloze netwerken die gegevens van kaartaanduidingen verzenden of zijn verbonden met de gegevensomgeving van de kaarthouder, gebruik de best practices van de branche (bijvoorbeeld IEEE 802.11i) om sterke versleuteling voor verificatie en verzending te implementeren.

Uw verantwoordelijkheden

Deze architectuur en de implementatie zijn niet ontworpen voor on-premises of zakelijke netwerk-naar-cloud-transacties via draadloze verbindingen. Raadpleeg de richtlijnen in de officiële PCI-DSS 3.2.1-standaard voor overwegingen.

Vereiste 4.2

Verzend nooit onbeveiligde PAN's met berichtentechnologieën voor eindgebruikers (bijvoorbeeld e-mail, chatberichten, sms, chat, enzovoort).

Uw verantwoordelijkheden

Als voor uw workload e-mailberichten moeten worden verzonden, kunt u overwegen een quarantainepoort voor e-mail te bouwen. Deze validatie geeft u de mogelijkheid om alle uitgaande berichten te scannen op naleving en te controleren of gevoelige gegevens niet zijn opgenomen. Idealiter moet u deze methode ook overwegen voor klantondersteuningsberichten.

Validatie moet worden uitgevoerd op workloadniveau en het wijzigingsbeheerproces. De goedkeuringspoorten moeten de vereiste begrijpen.

Raadpleeg de richtlijnen in de officiële PCI-DSS 3.2.1-standaard voor overwegingen.

Vereiste 4.3

Zorg ervoor dat beveiligingsbeleid en operationele procedures voor het versleutelen van overdrachten van gegevens van kaartaanduidingen in gebruik zijn gedocumenteerd en bekend zijn bij alle betrokken partijen.

Uw verantwoordelijkheden

Het is essentieel dat u grondige documentatie bijhoudt over de processen en het beleid. Dit geldt met name wanneer u beleid voor Transport Layer Security (TLS) beheert. Hier zijn enkele gebieden:

• Openbare internettoegangspunten. Een voorbeeld hiervan is Azure Application Gateway ondersteuning voor TLS-coderingen.
• Netwerkhops tussen perimeternetwerk en workloadpods.
• Pod-to-pod-versleuteling (indien geïmplementeerd). Dit kan details bevatten over de configuratie van een service-mesh.
• Pod naar opslag (indien onderdeel van de architectuur).
• Pod naar externe services, Azure PaaS-services die gebruikmaken van TLS, een betalingsgateway of een fraudedetectiesysteem.

Personen die gereguleerde omgevingen gebruiken, moeten worden geleid, geïnformeerd en gecentraliseerd om de beveiligingsgaranties te ondersteunen. Dit is met name belangrijk voor mensen die vanuit beleidsperspectief deel uitmaken van het goedkeuringsproces.

Volgende

Bescherm alle systemen tegen malware en werk regelmatig antivirussoftware of -programma's bij. Veilige systemen en toepassingen ontwikkelen en onderhouden.