Azure-beveiliging voor cloudeigen apps

Tip

Deze inhoud is een fragment uit het eBook, Cloud Native .NET Applications for Azure ontwerpen, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

Cloudeigen toepassingen kunnen zowel eenvoudiger als moeilijker te beveiligen zijn dan traditionele toepassingen. Het nadeel is dat u meer kleinere toepassingen moet beveiligen en meer energie moet besteden aan het uitbouwen van de beveiligingsinfrastructuur. De heterogene aard van programmeertalen en -stijlen in de meeste service-implementaties betekent ook dat u meer aandacht moet besteden aan beveiligingsbulletins van veel verschillende providers.

Aan de andere kant beperken kleinere services, elk met hun eigen gegevensarchief, het bereik van een aanval. Als een aanvaller inbreuk maakt op één systeem, is het waarschijnlijk moeilijker voor de aanvaller om naar een ander systeem te gaan dan in een monolithische toepassing. Procesgrenzen zijn sterke grenzen. Als een databaseback-up beschikbaar wordt gemaakt, is de schade beperkter, omdat die database slechts een subset van gegevens bevat en waarschijnlijk geen persoonsgegevens bevat.

Bedreigingsmodellen

Ongeacht of de voordelen opwegen tegen de nadelen van cloudeigen toepassingen, moet dezelfde holistische beveiligingsmentaliteit worden gevolgd. Beveiliging en veilig denken moeten deel uitmaken van elke stap van het ontwikkelings- en operationele verhaal. Wanneer u een toepassing plant, stelt u vragen zoals:

• Wat is de impact van deze gegevens die verloren gaan?
• Hoe kunnen we de schade beperken van slechte gegevens die in deze service worden geïnjecteerd?
• Wie moet toegang hebben tot deze gegevens?
• Zijn er controlebeleidsregels voor het ontwikkeling- en releaseproces?

Al deze vragen maken deel uit van een proces dat threat modeling wordt genoemd. Dit proces probeert de vraag te beantwoorden van welke bedreigingen er zijn voor het systeem, hoe waarschijnlijk de bedreigingen zijn en de mogelijke schade van deze bedreigingen.

Zodra de lijst met bedreigingen is vastgesteld, moet u beslissen of ze de moeite waard zijn om ze te beperken. Soms is een bedreiging zo onwaarschijnlijk en duur om ervoor te plannen dat het niet de moeite waard is om er energie op uit te geven. Een actor op statusniveau kan bijvoorbeeld wijzigingen invoeren in het ontwerp van een proces dat door miljoenen apparaten wordt gebruikt. In plaats van een bepaald stukje code in Ring 3 uit te voeren, wordt die code nu uitgevoerd in Ring 0. Met dit proces kan een aanval worden uitgevoerd die de hypervisor kan omzeilen en de aanvalscode kan uitvoeren op de bare-metalcomputers, waardoor aanvallen worden uitgevoerd op alle virtuele machines die op die hardware worden uitgevoerd.

De gewijzigde processors zijn moeilijk te detecteren zonder microscoop en geavanceerde kennis van het siliciumontwerp van die processor. Dit scenario is onwaarschijnlijk en duur om te beperken, dus waarschijnlijk zou er geen bedreigingsmodel worden aanbevolen om misbruikbeveiliging voor het model te bouwen.

Meer waarschijnlijke bedreigingen, zoals verbroken toegangsbeheer dat incrementele aanvallen toestaat Id (vervangen door Id=2Id=3 in de URL) of SQL-injectie, zijn aantrekkelijker om bescherming tegen te bouwen. De oplossingen voor deze bedreigingen zijn redelijk om beveiligingsgaten te bouwen en te voorkomen die de reputatie van het bedrijf smeken.

Principe van de minste bevoegdheden

Een van de basisprincipes van computerbeveiliging is het principe van minimale bevoegdheden (POLP). Het is eigenlijk een fundamenteel idee in de meeste vormen van beveiliging, of het nu digitaal of fysiek is. Kortom, het principe is dat elke gebruiker of elk proces het kleinste aantal rechten moet hebben om zijn taak uit te voeren.

Denk bijvoorbeeld aan de tellers bij een bank: het openen van de kluis is een ongebruikelijke activiteit. De gemiddelde verteller kan de kluis dus niet zelf openen. Om toegang te krijgen, moeten ze hun verzoek escaleren via een bankmanager, die extra beveiligingscontroles uitvoert.

In een computersysteem is een fantastisch voorbeeld de rechten van een gebruiker die verbinding maakt met een database. In veel gevallen is er één gebruikersaccount dat wordt gebruikt om zowel de databasestructuur te bouwen als de toepassing uit te voeren. Behalve in extreme gevallen heeft het account waarop de toepassing wordt uitgevoerd, de mogelijkheid om schemagegevens bij te werken niet nodig. Er moeten verschillende accounts zijn die verschillende bevoegdheidsniveaus bieden. De toepassing mag alleen het machtigingsniveau gebruiken dat lees- en schrijftoegang verleent tot de gegevens in de tabellen. Dit soort beveiliging elimineert aanvallen die zijn gericht op het verwijderen van databasetabellen of het introduceren van schadelijke triggers.

Bijna elk onderdeel van het bouwen van een cloudeigen toepassing kan profiteren van het onthouden van het principe van minimale bevoegdheden. U kunt deze vinden bij het instellen van firewalls, netwerkbeveiligingsgroepen, rollen en bereiken in op rollen gebaseerd toegangsbeheer (RBAC).

Indringingstests

Naarmate toepassingen ingewikkelder worden, neemt het aantal aanvalsvectoren met een alarmerende snelheid toe. Bedreigingsmodellering is onjuist omdat het meestal wordt uitgevoerd door dezelfde personen die het systeem bouwen. Op dezelfde manier als veel ontwikkelaars problemen ondervinden bij het inrichten van gebruikersinteracties en vervolgens onbruikbare gebruikersinterfaces bouwen, hebben de meeste ontwikkelaars moeite om elke aanvalsvector te zien. Het is ook mogelijk dat de ontwikkelaars die het systeem bouwen niet goed in aanvalsmethodologieën zijn en iets cruciaals missen.

Penetratietests of 'pentests' omvat het binnenbrengen van externe actoren om het systeem aan te vallen. Deze aanvallers zijn mogelijk een extern adviesbedrijf of andere ontwikkelaars met goede beveiligingskennis van een ander deel van het bedrijf. Ze krijgen carte-option om te proberen het systeem te verdraaien. Vaak vinden ze uitgebreide beveiligingsgaten die moeten worden gepatcht. Soms zal de aanvalsvector iets totaal onverwachts zijn, zoals het misbruiken van een phishing-aanval tegen de CEO.

Azure zelf ondergaat voortdurend aanvallen van een team hackers binnen Microsoft. In de loop der jaren zijn ze de eersten geweest om tientallen potentieel catastrofale aanvalsvectoren te vinden en ze te sluiten voordat ze extern kunnen worden misbruikt. Hoe verleidelijker een doel, hoe waarschijnlijker het is dat eeuwige actoren proberen het te exploiteren en er zijn een paar doelen ter wereld die verleidelijker zijn dan Azure.

Controleren

Als een aanvaller probeert een toepassing te binnendringen, moet er een waarschuwing over zijn. Vaak kunnen aanvallen worden gezien door de logboeken van services te onderzoeken. Aanvallen laten telltale tekens achter die kunnen worden gezien voordat ze slagen. Een aanvaller die een wachtwoord probeert te raden, doet bijvoorbeeld veel aanvragen naar een aanmeldingssysteem. Bewaking rond het aanmeldingssysteem kan vreemde patronen detecteren die niet voldoen aan het typische toegangspatroon. Deze bewaking kan worden omgezet in een waarschuwing die op zijn beurt een operationele persoon kan waarschuwen om een soort tegenmaatregelen te activeren. Een zeer volwassen bewakingssysteem kan zelfs actie ondernemen op basis van deze afwijkingen om proactief regels toe te voegen om aanvragen te blokkeren of reacties te beperken.

De build beveiligen

Een plek waar de beveiliging vaak over het hoofd wordt gezien, is rond het buildproces. Niet alleen moet de build beveiligingscontroles uitvoeren, zoals scannen op onveilige code of ingecheckte referenties, maar de build zelf moet veilig zijn. Als de build-server is aangetast, biedt deze een fantastische vector voor het introduceren van willekeurige code in het product.

Stel dat een aanvaller de wachtwoorden wil stelen van personen die zich aanmelden bij een webtoepassing. Ze kunnen een buildstap introduceren waarmee de uitgecheckte code wordt gewijzigd om elke aanmeldingsaanvraag naar een andere server te spiegelen. De volgende keer dat de code door de build gaat, wordt deze op de achtergrond bijgewerkt. Bij het scannen van broncodeproblemen wordt dit beveiligingsprobleem niet onderscheppen, omdat deze vóór de build wordt uitgevoerd. Niemand zal het in een codebeoordeling ondervangen omdat de buildstappen live op de build-server worden uitgevoerd. De misbruikte code gaat naar productie waar wachtwoorden kunnen worden opgehaald. Waarschijnlijk is er geen auditlogboek van de wijzigingen in het buildproces, of ten minste niemand die de controle bewaakt.

Dit scenario is een perfect voorbeeld van een schijnbaar laagwaardedoel dat kan worden gebruikt om het systeem in te breken. Zodra een aanvaller de perimeter van het systeem heeft geschonden, kunnen ze aan de slag met het vinden van manieren om hun machtigingen te verhogen tot het punt dat ze echte schade kunnen toebrengen waar ze willen.

Beveiligde code bouwen

.NET Framework is al een heel veilig framework. Het voorkomt enkele valkuilen van onbeheerde code, zoals het aflopen van de uiteinden van matrices. Er wordt actief gewerkt om beveiligingsgaten op te lossen wanneer ze worden gedetecteerd. Er is zelfs een bug bounty-programma dat onderzoekers betaalt om problemen in het framework te vinden en ze te rapporteren in plaats van ze te misbruiken.

Er zijn veel manieren om .NET-code veiliger te maken. Het volgen van richtlijnen zoals de richtlijnen voor veilig coderen voor .NET is een redelijke stap om ervoor te zorgen dat de code vanaf de grond veilig is. De OWASP top 10 is een andere waardevolle handleiding voor het bouwen van beveiligde code.

Het buildproces is een goede plek om scanhulpprogramma's te plaatsen om problemen in broncode te detecteren voordat deze in productie worden genomen. De meeste projecten hebben afhankelijkheden van sommige andere pakketten. Een hulpprogramma dat kan scannen op verouderde pakketten, ondervindt problemen in een nachtbuild. Zelfs bij het bouwen van Docker-installatiekopieën is het handig om te controleren of de basisinstallatiekopieën geen bekende beveiligingsproblemen hebben. Een ander ding om te controleren is dat niemand per ongeluk referenties heeft ingecheckt.

Ingebouwde beveiliging

Azure is ontworpen om de bruikbaarheid en beveiliging voor de meeste gebruikers te verdelen. Verschillende gebruikers hebben verschillende beveiligingsvereisten, dus ze moeten hun benadering van cloudbeveiliging verfijnen. Microsoft publiceert veel beveiligingsgegevens in het Vertrouwenscentrum. Deze resource moet de eerste stop zijn voor die professionals die willen weten hoe de ingebouwde technologieën voor aanvalsbeperking werken.

In Azure Portal is Azure Advisor een systeem dat voortdurend een omgeving scant en aanbevelingen doet. Sommige van deze aanbevelingen zijn ontworpen om gebruikers geld te besparen, maar andere zijn ontworpen om mogelijk onveilige configuraties te identificeren, zoals het hebben van een opslagcontainer die open staat voor de wereld en niet wordt beveiligd door een virtueel netwerk.

Azure-netwerkinfrastructuur

In een on-premises implementatieomgeving is veel energie gewijd aan het instellen van netwerken. Het instellen van routers, switches en dergelijke is ingewikkeld. Netwerken stellen bepaalde resources in staat om met andere resources te communiceren en toegang in sommige gevallen te voorkomen. Een frequente netwerkregel is om de toegang tot de productieomgeving te beperken vanuit de ontwikkelomgeving, omdat een half ontwikkeld stukje code onhandig wordt uitgevoerd en een deel van de gegevens verwijdert.

Standaard hebben de meeste PaaS Azure-resources alleen de meest eenvoudige en permissieve netwerkinstallatie. Iedereen op internet heeft bijvoorbeeld toegang tot een app-service. Nieuwe SQL Server-exemplaren zijn doorgaans beperkt, zodat externe partijen er geen toegang toe hebben, maar de IP-adresbereiken die door Azure zelf worden gebruikt, zijn toegestaan via. Dus, terwijl de SQL-server is beveiligd tegen externe bedreigingen, hoeft een aanvaller alleen een Azure-brughoofd in te stellen waar ze aanvallen kunnen starten tegen alle SQL-exemplaren in Azure.

Gelukkig kunnen de meeste Azure-resources worden geplaatst in een virtueel Azure-netwerk waarmee gedetailleerd toegangsbeheer mogelijk is. Net zoals on-premises netwerken particuliere netwerken tot stand brengen die worden beschermd tegen de hele wereld, zijn virtuele netwerken eilanden van privé-IP-adressen die zich in het Azure-netwerk bevinden.

Afbeelding 9-1. Een virtueel netwerk in Azure.

Op dezelfde manier dat on-premises netwerken een firewall hebben voor toegang tot het netwerk, kunt u een vergelijkbare firewall tot stand brengen op de grens van het virtuele netwerk. Standaard kunnen alle resources in een virtueel netwerk nog steeds met internet communiceren. Het zijn alleen binnenkomende verbindingen waarvoor een vorm van expliciete firewall-uitzondering is vereist.

Wanneer het netwerk tot stand is gebracht, kunnen interne resources, zoals opslagaccounts, worden ingesteld om alleen toegang te verlenen door resources die zich ook in het virtuele netwerk bevinden. Deze firewall biedt een extra beveiligingsniveau, als de sleutels voor dat opslagaccount worden gelekt, kunnen aanvallers er geen verbinding mee maken om misbruik te maken van de gelekte sleutels. Dit scenario is een ander voorbeeld van het principe van minimale bevoegdheden.

De knooppunten in een Azure Kubernetes-cluster kunnen deelnemen aan een virtueel netwerk, net zoals andere resources die systeemeigen zijn voor Azure. Deze functionaliteit wordt Azure Container Networking Interface genoemd. In feite wijst het een subnet toe binnen het virtuele netwerk waarop virtuele machines en containerinstallatiekopieën worden toegewezen.

Door verder te gaan met het illustreren van het principe van minimale bevoegdheden, moet niet elke resource in een virtueel netwerk met elke andere resource communiceren. In een toepassing die een web-API biedt via een opslagaccount en een SQL-database, is het onwaarschijnlijk dat de database en het opslagaccount met elkaar moeten communiceren. Alle gegevens die ertussen worden gedeeld, lopen via de webtoepassing. Een netwerkbeveiligingsgroep (NSG) kan dus worden gebruikt om verkeer tussen de twee services te weigeren.

Een beleid voor het weigeren van communicatie tussen resources kan vervelend zijn om te implementeren, met name afkomstig van een achtergrond van het gebruik van Azure zonder verkeersbeperkingen. In sommige andere clouds is het concept van netwerkbeveiligingsgroepen veel gangbaarder. Het standaardbeleid voor AWS is bijvoorbeeld dat resources pas met elkaar kunnen communiceren als ze zijn ingeschakeld door regels in een NSG. Hoewel dit langzamer wordt ontwikkeld, biedt een meer beperkende omgeving een veiligere standaardwaarde. Door gebruik te maken van de juiste DevOps-procedures, met name het gebruik van Azure Resource Manager of Terraform om machtigingen te beheren, kan het beheren van de regels eenvoudiger worden.

Virtuele netwerken kunnen ook handig zijn bij het instellen van communicatie tussen on-premises en cloudresources. Een virtueel particulier netwerk kan worden gebruikt om de twee netwerken naadloos aan elkaar te koppelen. Met deze methode kunt u een virtueel netwerk uitvoeren zonder een gateway voor scenario's waarin alle gebruikers zich op locatie bevinden. Er zijn een aantal technologieën die kunnen worden gebruikt om dit netwerk tot stand te brengen. Het eenvoudigste is om een site-naar-site-VPN te gebruiken die tussen veel routers en Azure tot stand kan worden gebracht. Verkeer wordt versleuteld en via internet getunneld tegen dezelfde kosten per byte als elk ander verkeer. Voor scenario's waarbij meer bandbreedte of meer beveiliging wenselijk is, biedt Azure een service met de naam Express Route die gebruikmaakt van een privécircuit tussen een on-premises netwerk en Azure. Het is duurder en moeilijker om vast te stellen, maar ook veiliger.

Op rollen gebaseerd toegangsbeheer voor het beperken van de toegang tot Azure-resources

RBAC is een systeem dat een identiteit biedt aan toepassingen die worden uitgevoerd in Azure. Toepassingen hebben toegang tot resources met deze identiteit in plaats van of naast het gebruik van sleutels of wachtwoorden.

Beveiligingsprinciplen

Het eerste onderdeel in RBAC is een beveiligingsprincipaal. Een beveiligingsprincipaal kan een gebruiker, groep, service-principal of beheerde identiteit zijn.

Afbeelding 9-2. Verschillende typen beveiligingsprinciplen.

• Gebruiker: elke gebruiker met een account in Azure Active Directory is een gebruiker.
• Groep: een verzameling gebruikers uit Azure Active Directory. Als lid van een groep neemt een gebruiker naast hun eigen rollen de rollen van die groep over.
• Service-principal: een beveiligingsidentiteit waaronder services of toepassingen worden uitgevoerd.
• Beheerde identiteit: een Azure Active Directory-identiteit die wordt beheerd door Azure. Beheerde identiteiten worden doorgaans gebruikt bij het ontwikkelen van cloudtoepassingen die de referenties beheren voor verificatie bij Azure-services.

De beveiligingsprincipaal kan op de meeste resources worden toegepast. Dit aspect betekent dat het mogelijk is om een beveiligingsprincipaal toe te wijzen aan een container die wordt uitgevoerd in Azure Kubernetes, zodat deze toegang heeft tot geheimen die zijn opgeslagen in Key Vault. Een Azure-functie kan een machtiging aannemen, zodat deze kan communiceren met een Active Directory-exemplaar om een JWT te valideren voor een aanroepende gebruiker. Zodra services zijn ingeschakeld met een service-principal, kunnen hun machtigingen nauwkeurig worden beheerd met behulp van rollen en bereiken.

Rollen

Een beveiligingsprincipal kan veel rollen aannemen of, met behulp van een meer sartoriale analogie, veel hoeden dragen. Elke rol definieert een reeks machtigingen, zoals 'Berichten lezen van Azure Service Bus-eindpunt'. De effectieve machtigingenset van een beveiligingsprincipaal is de combinatie van alle machtigingen die zijn toegewezen aan alle rollen die een beveiligingsprincipaal heeft. Azure heeft een groot aantal ingebouwde rollen en gebruikers kunnen hun eigen rollen definiëren.

Afbeelding 9-3. RBAC-roldefinities.

Ingebouwd in Azure zijn ook een aantal rollen op hoog niveau, zoals Eigenaar, Inzender, Lezer en Gebruikersaccount Beheer istrator. Met de rol Eigenaar kan een beveiligingsprincipaal toegang krijgen tot alle resources en machtigingen toewijzen aan anderen. Een inzender heeft hetzelfde toegangsniveau voor alle resources, maar ze kunnen geen machtigingen toewijzen. Een lezer kan alleen bestaande Azure-resources en een gebruikersaccount bekijken Beheer istrator de toegang tot Azure-resources kan beheren.

Gedetailleerdere ingebouwde rollen, zoals Inzender voor DNS-zones, hebben rechten die zijn beperkt tot één service. Beveiligingsprinciplen kunnen een willekeurig aantal rollen overnemen.

Bereiken

Rollen kunnen worden toegepast op een beperkte set resources in Azure. Als u bijvoorbeeld het bereik toepast op het vorige voorbeeld van het lezen uit een Service Bus-wachtrij, kunt u de machtiging beperken tot één wachtrij: 'Berichten lezen van Azure Service Bus-eindpunt blah.servicebus.windows.net/queue1'

Het bereik kan zo smal zijn als één resource of kan worden toegepast op een hele resourcegroep, abonnement of zelfs beheergroep.

Bij het testen of een beveiligingsprincipaal bepaalde machtigingen heeft, wordt rekening gehouden met de combinatie van rol en bereik. Deze combinatie biedt een krachtig autorisatiemechanisme.

Weigeren

Voorheen waren alleen regels voor toestaan toegestaan voor RBAC. Dit gedrag maakte een aantal bereiken ingewikkeld om te bouwen. Zo kan een beveiligingsprincipaal toegang krijgen tot alle opslagaccounts, behalve één account dat expliciete machtigingen moet verlenen aan een mogelijk eindeloze lijst met opslagaccounts. Telkens wanneer een nieuw opslagaccount is gemaakt, moet dit worden toegevoegd aan deze lijst met accounts. Deze extra beheeroverhead die zeker niet wenselijk was.

Regels voor weigeren hebben voorrang op regels voor toestaan. Als u nu hetzelfde bereik 'alles toestaan maar één' vertegenwoordigt, kan dit worden weergegeven als twee regels 'alles toestaan' en 'dit één specifieke toestaan'. Regels voor weigeren vereenvoudigen niet alleen het beheer, maar zorgen ervoor dat resources die extra veilig zijn door toegang tot iedereen te weigeren.

Toegang controleren

Zoals u zich kunt voorstellen, kan het hebben van een groot aantal rollen en bereiken het bepalen van de effectieve machtiging van een service-principal vrij moeilijk maken. Het stapelen van regels voor weigeren daarboven dient alleen om de complexiteit te verhogen. Gelukkig is er een machtigingscalculator waarmee de effectieve machtigingen voor elke service-principal kunnen worden weergegeven. Deze wordt meestal gevonden op het tabblad IAM in de portal, zoals wordt weergegeven in afbeelding 9-3.

Afbeelding 9-4. Machtigingscalculator voor een app-service.

Geheimen beveiligen

Wachtwoorden en certificaten zijn een veelvoorkomende aanvalsvector voor aanvallers. Hardware die wachtwoord kraken kan een brute-force-aanval uitvoeren en miljarden wachtwoorden per seconde proberen te raden. Het is dus belangrijk dat de wachtwoorden die worden gebruikt voor toegang tot resources sterk zijn, met een grote verscheidenheid aan tekens. Deze wachtwoorden zijn precies het soort wachtwoorden dat bijna onmogelijk te onthouden is. Gelukkig hoeven de wachtwoorden in Azure niet echt bekend te zijn door een mens.

Veel beveiligingsexperts stellen voor dat het gebruik van een wachtwoordbeheerder om uw eigen wachtwoorden te behouden de beste aanpak is. Hoewel uw wachtwoorden op één locatie worden gecentraliseerd, is het ook mogelijk om zeer complexe wachtwoorden te gebruiken en ervoor te zorgen dat ze uniek zijn voor elk account. Hetzelfde systeem bestaat in Azure: een centraal archief voor geheimen.

Azure Key Vault

Azure Key Vault biedt een centrale locatie voor het opslaan van wachtwoorden voor zaken zoals databases, API-sleutels en certificaten. Zodra een geheim is ingevoerd in de kluis, wordt het nooit meer weergegeven en zijn de opdrachten om het te extraheren en weer te geven, doelbewust gecompliceerd. De informatie in de kluis wordt beveiligd met behulp van softwareversleuteling of MET FIPS 140-2 Level 2 gevalideerde hardwarebeveiligingsmodules.

Toegang tot de sleutelkluis wordt geboden via RBAC's, wat betekent dat niet alleen elke gebruiker toegang heeft tot de informatie in de kluis. Stel dat een webtoepassing toegang wil krijgen tot de database verbindingsreeks die zijn opgeslagen in Azure Key Vault. Voor toegang moeten toepassingen worden uitgevoerd met behulp van een service-principal. Onder deze veronderstelde rol kunnen ze de geheimen uit de kluis lezen. Er zijn verschillende beveiligingsinstellingen waarmee de toegang die een toepassing heeft tot de kluis verder kan worden beperkt, zodat geheimen niet kunnen worden bijgewerkt, maar alleen kunnen worden gelezen.

Toegang tot de sleutelkluis kan worden bewaakt om ervoor te zorgen dat alleen de verwachte toepassingen toegang hebben tot de kluis. De logboeken kunnen weer worden geïntegreerd in Azure Monitor, waardoor de mogelijkheid om waarschuwingen in te stellen wordt ontgrendeld wanneer er onverwachte omstandigheden worden aangetroffen.

Kubernetes

Binnen Kubernetes is er een vergelijkbare service voor het onderhouden van kleine stukjes geheime informatie. Kubernetes Secrets kan worden ingesteld via het gebruikelijke kubectl uitvoerbare bestand.

Het maken van een geheim is net zo eenvoudig als het vinden van de base64-versie van de waarden die moeten worden opgeslagen:

echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

Voeg het vervolgens toe aan een geheimenbestand met de naam secret.yml bijvoorbeeld dat lijkt op het volgende voorbeeld:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Ten slotte kan dit bestand worden geladen in Kubernetes door de volgende opdracht uit te voeren:

kubectl apply -f ./secret.yaml

Deze geheimen kunnen vervolgens worden gekoppeld aan volumes of worden blootgesteld aan containerprocessen via omgevingsvariabelen. De twaalf-factor-app-benadering voor het bouwen van toepassingen stelt voor het gebruik van de laagste gemeenschappelijke noemer voor het verzenden van instellingen naar een toepassing. Omgevingsvariabelen zijn de laagste algemene noemer, omdat ze worden ondersteund, ongeacht het besturingssysteem of de toepassing.

Een alternatief voor het gebruik van de ingebouwde Kubernetes-geheimen is toegang tot de geheimen in Azure Key Vault vanuit Kubernetes. De eenvoudigste manier om dit te doen, is door een RBAC-rol toe te wijzen aan de container die geheimen wil laden. De toepassing kan vervolgens de Azure Key Vault-API's gebruiken om toegang te krijgen tot de geheimen. Deze benadering vereist echter wijzigingen in de code en volgt niet het patroon van het gebruik van omgevingsvariabelen. In plaats daarvan is het mogelijk om waarden in een container te injecteren. Deze benadering is eigenlijk veiliger dan het rechtstreeks gebruiken van de Kubernetes-geheimen, omdat ze toegankelijk zijn voor gebruikers in het cluster.

Versleuteling in transit en at rest

Gegevens veilig houden is belangrijk, ongeacht of ze zich op schijf bevinden of worden overgedragen tussen verschillende services. De meest effectieve manier om te voorkomen dat gegevens worden gelekt, is door deze te versleutelen in een indeling die niet gemakkelijk door anderen kan worden gelezen. ondersteuning voor Azure een breed scala aan versleutelingsopties.

In transit

Er zijn verschillende manieren om verkeer op het netwerk in Azure te versleutelen. De toegang tot Azure-services wordt doorgaans uitgevoerd via verbindingen die gebruikmaken van Transport Layer Security (TLS). Voor alle verbindingen met de Azure-API's zijn bijvoorbeeld TLS-verbindingen vereist. Verbindingen met eindpunten in Azure Storage kunnen ook worden beperkt tot alleen werken via versleutelde TLS-verbindingen.

TLS is een ingewikkeld protocol en weet gewoon dat de verbinding gebruikmaakt van TLS niet voldoende is om de beveiliging te garanderen. TLS 1.0 is bijvoorbeeld chronische onveilig en TLS 1.1 is niet veel beter. Zelfs in de versies van TLS zijn er verschillende instellingen waarmee de verbindingen gemakkelijker kunnen worden ontsleuteld. De beste werkwijze is om te controleren of de serververbinding up-to-date en goed geconfigureerde protocollen gebruikt.

Deze controle kan worden uitgevoerd door een externe service, zoals SSL Labs SSL Server Test. Een testuitvoering op een typisch Azure-eindpunt, in dit geval een Service Bus-eindpunt, levert een bijna perfecte score van A op.

Zelfs services zoals Azure SQL-databases maken gebruik van TLS-versleuteling om gegevens verborgen te houden. Het interessante deel over het versleutelen van de gegevens tijdens overdracht met BEHULP van TLS is dat het niet mogelijk is, zelfs voor Microsoft, om te luisteren naar de verbinding tussen computers met TLS. Dit moet zorgen voor comfort voor bedrijven die zich zorgen maken over het risico dat hun gegevens risico lopen van De juiste of zelfs een staats actor met meer resources dan de standaard kwaadwillendheid.

Afbeelding 9-5. SSL-labsrapport met een score van A voor een Service Bus-eindpunt.

Hoewel dit versleutelingsniveau niet altijd voldoende is, moet het vertrouwen wekken dat Azure TLS-verbindingen behoorlijk veilig zijn. Azure blijft de beveiligingsstandaarden verder ontwikkelen naarmate versleuteling wordt verbeterd. Het is fijn om te weten dat er iemand is die de beveiligingsstandaarden bekijkt en Azure bijwerkt naarmate ze worden verbeterd.

Inactief

In elke toepassing zijn er een aantal plaatsen waar gegevens op de schijf rusten. De toepassingscode zelf wordt geladen vanuit een opslagmechanisme. De meeste toepassingen gebruiken ook een soort database, zoals SQL Server, Cosmos DB of zelfs de verbazingwekkend prijs-efficiënte Table Storage. Deze databases maken allemaal gebruik van sterk versleutelde opslag om ervoor te zorgen dat niemand anders dan de toepassingen met de juiste machtigingen uw gegevens kan lezen. Zelfs de systeembeheerders kunnen geen gegevens lezen die zijn versleuteld. Klanten kunnen er dus zeker van blijven dat hun geheime informatie geheim blijft.

Storage

De basis van veel van Azure is de Azure Storage-engine. Schijven van virtuele machines worden boven op Azure Storage gekoppeld. Azure Kubernetes Service wordt uitgevoerd op virtuele machines die zelf worden gehost in Azure Storage. Zelfs serverloze technologieën, zoals Azure Functions Apps en Azure Container Instances, zijn onvoldoende schijf die deel uitmaakt van Azure Storage.

Als Azure Storage goed is versleuteld, biedt het een basis voor de meeste andere dingen die ook moeten worden versleuteld. Azure Storage is versleuteld met FIPS 140-2-compatibele256-bits AES. Dit is een goed beschouwde versleutelingstechnologie die in de afgelopen 20 jaar uitvoerig is onderzocht. Op dit moment is er geen bekende praktische aanval waardoor iemand zonder kennis van de sleutel gegevens kan lezen die zijn versleuteld door AES.

Standaard worden de sleutels die worden gebruikt voor het versleutelen van Azure Storage beheerd door Microsoft. Er zijn uitgebreide beveiligingen aanwezig om schadelijke toegang tot deze sleutels te voorkomen. Gebruikers met bepaalde versleutelingsvereisten kunnen echter ook hun eigen opslagsleutels bieden die worden beheerd in Azure Key Vault. Deze sleutels kunnen op elk gewenst moment worden ingetrokken, waardoor de inhoud van het opslagaccount effectief wordt weergegeven met behulp van deze sleutels die niet toegankelijk zijn.

Virtuele machines gebruiken versleutelde opslag, maar het is mogelijk om een andere versleutelingslaag te bieden met behulp van technologieën zoals BitLocker in Windows of DM-Crypt op Linux. Deze technologieën betekenen dat zelfs als de schijfinstallatiekopieën uit de opslag zijn gelekt, het bijna onmogelijk zou blijven om deze te lezen.

Azure SQL

Databases die worden gehost in Azure SQL gebruiken een technologie met de naam Transparent Data Encryption (TDE) om ervoor te zorgen dat gegevens versleuteld blijven. Deze functie is standaard ingeschakeld voor alle nieuw gemaakte SQL-databases, maar moet handmatig worden ingeschakeld voor verouderde databases. TDE voert realtime-versleuteling en ontsleuteling uit van niet alleen de database, maar ook de back-ups en transactielogboeken.

De versleutelingsparameters worden opgeslagen in de master database en worden bij het opstarten in het geheugen gelezen voor de resterende bewerkingen. Dit betekent dat de master database niet-versleuteld moet blijven. De werkelijke sleutel wordt beheerd door Microsoft. Gebruikers met exacte beveiligingsvereisten kunnen echter op dezelfde manier hun eigen sleutel in Key Vault bieden als voor Azure Storage. Key Vault biedt services zoals sleutelrotatie en intrekking.

Het 'transparante' deel van TDS is afkomstig van het feit dat er geen clientwijzigingen nodig zijn om een versleutelde database te gebruiken. Hoewel deze aanpak een goede beveiliging biedt, is het lekken van het databasewachtwoord voldoende voor gebruikers om de gegevens te ontsleutelen. Er is een andere benadering waarmee afzonderlijke kolommen of tabellen in een database worden versleuteld. Always Encrypted zorgt ervoor dat de versleutelde gegevens op geen enkel moment worden weergegeven in tekst zonder opmaak in de database.

Voor het instellen van deze versleutelingslaag moet een wizard worden uitgevoerd in SQL Server Management Studio om het type versleuteling te selecteren en waar in Key Vault de bijbehorende sleutels moeten worden opgeslagen.

Afbeelding 9-6. Kolommen in een tabel selecteren die moeten worden versleuteld met Always Encrypted.

Clienttoepassingen die informatie uit deze versleutelde kolommen lezen, moeten speciale vergoedingen bieden voor het lezen van versleutelde gegevens. Verbinding maken ietekenreeksen moeten worden bijgewerkt met Column Encryption Setting=Enabled en clientreferenties moeten worden opgehaald uit key vault. De SQL Server-client moet vervolgens worden voorzien van de kolomversleutelingssleutels. Zodra dat is gebeurd, gebruiken de resterende acties de standaardinterfaces voor SQL Client. Hulpprogramma's zoals Dapper en Entity Framework, die op SQL Client zijn gebouwd, blijven werken zonder wijzigingen. Always Encrypted is mogelijk nog niet beschikbaar voor elk SQL Server-stuurprogramma in elke taal.

De combinatie van TDE en Always Encrypted, die beide kunnen worden gebruikt met clientspecifieke sleutels, zorgt ervoor dat zelfs de meest exacte versleutelingsvereisten worden ondersteund.

Cosmos DB

Cosmos DB is de nieuwste database van Microsoft in Azure. Het is helemaal zelf gebouwd met beveiliging en cryptografie in gedachten. AES-256-bits versleuteling is standaard voor alle Cosmos DB-databases en kan niet worden uitgeschakeld. In combinatie met de TLS 1.2-vereiste voor communicatie wordt de volledige opslagoplossing versleuteld.

Afbeelding 9-7. De stroom van gegevensversleuteling in Cosmos DB.

Hoewel Cosmos DB niet voorziet in het leveren van versleutelingssleutels van klanten, is er veel werk gedaan door het team om ervoor te zorgen dat het PCI-DSS-compatibel blijft zonder dat. Cosmos DB biedt ook geen ondersteuning voor versleuteling van één kolom die vergelijkbaar is met Always Encrypted van Azure SQL.

Veilig houden

Azure heeft alle hulpprogramma's die nodig zijn om een zeer veilig product vrij te geven. Een keten is echter slechts zo sterk als de zwakste link. Als de toepassingen die op Azure zijn geïmplementeerd, niet zijn ontwikkeld met een juiste beveiligingsmentaliteit en goede beveiligingscontroles, worden ze de zwakke koppeling in de keten. Er zijn veel geweldige hulpprogramma's voor statische analyse, versleutelingsbibliotheken en beveiligingsprocedures die kunnen worden gebruikt om ervoor te zorgen dat de software die in Azure is geïnstalleerd, net zo veilig is als Azure zelf. Voorbeelden hiervan zijn hulpprogramma's voor statische analyse, versleutelingsbibliotheken en beveiligingsprocedures.

VorigeVolgende