Delen via


Beveiligingsoverwegingen voor bedrijfskritieke workloads in Azure

Beveiliging is een van de fundamentele ontwerpprincipes en ook een belangrijk ontwerpgebied dat moet worden behandeld als een eersteklas zorg binnen het essentiële architectuurproces.

Aangezien de primaire focus van een bedrijfskritisch ontwerp is om de betrouwbaarheid te maximaliseren, zodat de toepassing goed presteert en beschikbaar blijft, richten de beveiligingsoverwegingen en aanbevelingen die binnen dit ontwerpgebied worden toegepast zich op het beperken van bedreigingen met de capaciteit om de beschikbaarheid te beïnvloeden en de algehele betrouwbaarheid te belemmeren. Succesvolle Denial-Of-Service-aanvallen (DDoS) hebben bijvoorbeeld een catastrofale invloed op beschikbaarheid en prestaties. Hoe een toepassing deze aanvalsvectoren beperkt, zoals SlowLoris, heeft invloed op de algehele betrouwbaarheid. De toepassing moet dus volledig worden beschermd tegen bedreigingen die zijn bedoeld om de betrouwbaarheid van toepassingen direct of indirect te compromitteren om echt bedrijfskritiek van aard te zijn.

Het is ook belangrijk te weten dat er vaak aanzienlijke afwegingen zijn met betrekking tot een beperkte beveiligingspostuur, met name met betrekking tot prestaties, operationele flexibiliteit en in sommige gevallen betrouwbaarheid. De opname van inline network Virtual Appliances (NVA) voor NGFW-mogelijkheden (Next Generation Firewall), zoals grondige pakketinspectie, leidt bijvoorbeeld tot een aanzienlijke prestatiestraf, extra operationele complexiteit en een betrouwbaarheidsrisico als schaalbaarheids- en herstelbewerkingen niet nauw zijn afgestemd op die van de toepassing. Het is daarom essentieel dat extra beveiligingsonderdelen en -procedures die zijn bedoeld om belangrijke bedreigingsvectoren te beperken, ook zijn ontworpen ter ondersteuning van het betrouwbaarheidsdoel van een toepassing, wat een belangrijk aspect vormt van de aanbevelingen en overwegingen die in deze sectie worden gepresenteerd.

Belangrijk

Dit artikel maakt deel uit van de azure Well-Architected mission-critical workload series. Als u niet bekend bent met deze reeks, raden we u aan te beginnen met wat een bedrijfskritieke workload is?

GitHub-logoBedrijfskritiek opensource-project

De referentie-implementaties maken deel uit van een opensource-project dat beschikbaar is op GitHub. De codeassets gebruiken een Zero Trust-model om het beveiligingsontwerp en de implementatiebenadering te structureren en te begeleiden.

Uitlijning met het Zero Trust-model

Het Microsoft Zero Trust-model biedt een proactieve en geïntegreerde benadering voor het toepassen van beveiliging op alle lagen van een toepassing. De leidende principes van Zero Trust streven ernaar om elke transactie expliciet en continu te verifiëren, minimale bevoegdheden te bevestigen, intelligentie te gebruiken en geavanceerde detectie te gebruiken om in bijna realtime te reageren op bedreigingen. Het is uiteindelijk gericht op het elimineren van vertrouwen binnen en buiten toepassingsperimeters, waardoor verificatie wordt afgedwongen voor alles wat probeert verbinding te maken met het systeem.

Ontwerpoverwegingen

Wanneer u de beveiligingspostuur van de toepassing beoordeelt, begint u met deze vragen als basis voor elke overweging.

  • Doorlopende beveiligingstests om risicobeperking te valideren voor belangrijke beveiligingsproblemen.

    • Wordt beveiligingstests uitgevoerd als onderdeel van geautomatiseerde CI/CD-processen?
    • Zo niet, hoe vaak worden specifieke beveiligingstests uitgevoerd?
    • Worden testresultaten gemeten op basis van een gewenste beveiligingspostuur en bedreigingsmodel?
  • Beveiligingsniveau in alle lagere omgevingen.

    • Hebben alle omgevingen binnen de ontwikkelingslevenscyclus hetzelfde beveiligingspostuur als de productieomgeving?
  • Verificatie- en autorisatiecontinuïteit in het geval van een fout.

    • Als verificatie- of autorisatieservices tijdelijk niet beschikbaar zijn, kan de toepassing blijven werken?
  • Geautomatiseerde naleving en herstel van beveiliging.

    • Kunnen er wijzigingen in belangrijke beveiligingsinstellingen worden gedetecteerd?
    • Worden reacties om niet-compatibele wijzigingen te herstellen geautomatiseerd?
  • Scannen van geheimen om geheimen te detecteren voordat code wordt doorgevoerd om eventuele geheime lekken via broncodeopslagplaatsen te voorkomen.

    • Is verificatie voor services mogelijk zonder referenties als onderdeel van code?
  • Beveilig de softwareleveringsketen.

    • Is het mogelijk om COMMON Vulnerabilities and Exposures (CVE's) bij te houden binnen gebruikte pakketafhankelijkheden?
    • Is er een geautomatiseerd proces voor het bijwerken van pakketafhankelijkheden?
  • Levenscyclus van gegevensbeschermingssleutels.

    • Kunnen door de service beheerde sleutels worden gebruikt voor gegevensintegriteitsbeveiliging?
    • Als door de klant beheerde sleutels vereist zijn, hoe is de veilige en betrouwbare sleutellevenscyclus?
  • CI/CD-hulpprogramma's moeten Microsoft Entra-service-principals met voldoende toegang op abonnementsniveau vereisen om de toegang tot azure-resourceimplementaties tot alle overwogen omgevingsabonnementen te vergemakkelijken.

    • Wanneer toepassingsbronnen zijn vergrendeld binnen particuliere netwerken, is er een connectiviteitspad voor privégegevensvlak, zodat CI/CD-hulpprogramma's implementaties en onderhoud op toepassingsniveau kunnen uitvoeren.
      • Dit introduceert extra complexiteit en vereist een reeks binnen het implementatieproces via vereiste privé-buildagents.

Ontwerpaanaanvelingen

  • Gebruik Azure Policy om beveiligings- en betrouwbaarheidsconfiguraties af te dwingen voor alle services, zodat elke afwijking wordt hersteld of verboden door het besturingsvlak tijdens de configuratie, waardoor bedreigingen die zijn gekoppeld aan 'schadelijke beheerders'-scenario's, worden beperkt.

  • Gebruik Microsoft Entra Privileged Identity Management (PIM) in productieabonnementen om permanente toegang tot productieomgevingen in te trekken. Dit vermindert het risico dat wordt gesteld door 'kwaadwillende beheerders'-scenario's aanzienlijk via extra 'controles en saldo's'.

  • Gebruik Azure Managed Identities voor alle services die de mogelijkheid ondersteunen, omdat het het verwijderen van referenties uit toepassingscode vergemakkelijkt en de operationele last van identiteitsbeheer voor service-naar-servicecommunicatie verwijdert.

  • Gebruik op rollen gebaseerd toegangsbeheer (RBAC) van Microsoft Entra voor autorisatie van gegevensvlakken met alle services die ondersteuning bieden voor de mogelijkheid.

  • Gebruik eigen Microsoft Identity Platform-verificatiebibliotheken in toepassingscode om te integreren met Microsoft Entra ID.

  • Overweeg beveiligde tokencaching om een gedegradeerde maar beschikbare ervaring mogelijk te maken als het gekozen identiteitsplatform niet beschikbaar is of slechts gedeeltelijk beschikbaar is voor toepassingsautorisatie.

    • Als de provider geen nieuwe toegangstokens kan uitgeven, maar nog steeds bestaande toegangstokens kan valideren, kunnen de toepassing en afhankelijke services zonder problemen werken totdat hun tokens verlopen.
    • Tokencaching wordt doorgaans automatisch verwerkt door verificatiebibliotheken (zoals MSAL).
  • Gebruik Infrastructure-as-Code (IaC) en geautomatiseerde CI/CD-pijplijnen om updates te sturen naar alle toepassingsonderdelen, inclusief onder storingssituaties.

    • Zorg ervoor dat verbindingen met ci/CD-hulpprogramma's worden beveiligd als kritieke gevoelige informatie en niet rechtstreeks beschikbaar moeten zijn voor een serviceteam.
    • Pas gedetailleerde RBAC toe op productie-CD-pijplijnen om schadelijke beheerdersrisico's te beperken.
    • Overweeg het gebruik van handmatige goedkeuringspoorten binnen productie-implementatiepijplijnen om de risico's van kwaadwillende beheerders verder te beperken en aanvullende technische zekerheid te bieden voor alle productiewijzigingen.
      • Aanvullende beveiligingspoorten kunnen een afweging maken in termen van flexibiliteit en moeten zorgvuldig worden geëvalueerd, met inachtneming van de flexibiliteit, zelfs met handmatige poorten.
  • Definieer een geschikte beveiligingspostuur voor alle lagere omgevingen om ervoor te zorgen dat belangrijke beveiligingsproblemen worden beperkt.

    • Pas niet hetzelfde beveiligingspostuur toe als productie, met name met betrekking tot gegevensexfiltratie, tenzij wettelijke vereisten hiervoor bepalen, omdat dit de flexibiliteit van ontwikkelaars aanzienlijk zal in gevaar brengen.
  • Schakel Microsoft Defender voor Cloud (voorheen Bekend als Azure Security Center) in voor alle abonnementen die de resources voor een bedrijfskritieke workload bevatten.

    • Gebruik Azure Policy om naleving af te dwingen.
    • Schakel Azure Defender in voor alle services die ondersteuning bieden voor de mogelijkheid.
  • Gebruik DevSecOps en implementeer beveiligingstests binnen CI/CD-pijplijnen.

    • Testresultaten moeten worden gemeten op basis van een nalevingsbeveiligingspostuur om goedkeuringen voor de release te informeren, of ze geautomatiseerd of handmatig zijn.
    • Beveiligingstests toepassen als onderdeel van het CD-productieproces voor elke release.
      • Als beveiligingstests voor elke release de operationele flexibiliteit in gevaar brengen, moet u ervoor zorgen dat er een geschikte frequentie voor beveiligingstests wordt toegepast.
  • Schakel geheim scannen en afhankelijkheid scannen in de broncodeopslagplaats in.

Bedreigingsmodellen

Bedreigingsmodellering biedt een op risico's gebaseerde benadering van beveiligingsontwerp, waarbij gebruik wordt gemaakt van geïdentificeerde mogelijke bedreigingen om passende beveiligingsbeperkende oplossingen te ontwikkelen. Er zijn veel mogelijke bedreigingen met verschillende waarschijnlijkheden van het optreden, en in veel gevallen kunnen bedreigingen op onverwachte, onvoorspelbare en zelfs chaostische manieren worden gekoppeld. Deze complexiteit en onzekerheid is waarom traditionele beveiligingsmethoden op basis van technologievereisten grotendeels ongeschikt zijn voor bedrijfskritieke cloudtoepassingen. Verwacht dat het proces van threat modeling voor een bedrijfskritieke toepassing complex en onvrijbaar is.

Om door deze uitdagingen te navigeren, moet een gelaagde diepgaande verdedigingsbenadering worden toegepast om compenserende oplossingen voor gemodelleerde bedreigingen te definiëren en te implementeren, rekening houdend met de volgende defensieve lagen.

  1. Het Azure-platform met fundamentele beveiligingsmogelijkheden en besturingselementen.
  2. De toepassingsarchitectuur en het beveiligingsontwerp.
  3. Ingebouwde, ingeschakelde en implementeerbare beveiligingsfuncties die worden toegepast op beveiligde Azure-resources.
  4. Toepassingscode en beveiligingslogica.
  5. Operationele processen en DevSecOps.

Notitie

Wanneer u implementeert binnen een Azure-landingszone, moet u er rekening mee houden dat er een extra bedreigingsbeperkingslaag wordt geboden door het inrichten van gecentraliseerde beveiligingsmogelijkheden door de implementatie van de landingszone.

Ontwerpoverwegingen

STRIDE biedt een lichtgewicht risicoframework voor het evalueren van beveiligingsrisico's voor belangrijke bedreigingsvectoren.

  • Vervalste identiteit: imitatie van personen met autoriteit. Een aanvaller die bijvoorbeeld een andere gebruiker imiteert met behulp van de -
    • Identiteit
    • Verificatie
  • Invoer voor manipulatie: wijziging van invoer die naar de toepassing wordt verzonden of de schending van vertrouwensgrenzen om toepassingscode te wijzigen. Bijvoorbeeld een aanvaller die SQL-injectie gebruikt om gegevens in een databasetabel te verwijderen.
    • Gegevensintegriteit
    • Validatie
    • Blokkering/acceptatielijst
  • Repudiation of Action: Mogelijkheid om reeds ondernomen acties te weerleggen en de mogelijkheid van de toepassing om bewijs te verzamelen en verantwoording te stimuleren. Bijvoorbeeld het verwijderen van kritieke gegevens zonder de mogelijkheid om te traceren naar een kwaadwillende beheerder.
    • Controle/logboekregistratie
    • Ondertekenen
  • Openbaarmaking van informatie: toegang krijgen tot beperkte informatie. Een voorbeeld hiervan is een aanvaller die toegang krijgt tot een beperkt bestand.
    • Versleuteling
    • Gegevensoverdracht
    • Man-in-the-middle-aanvallen
  • Denial of Service: schadelijke toepassingsonderbreking om de gebruikerservaring te verminderen. Bijvoorbeeld een DDoS-botnetaanval zoals Slowloris.
    • DDoS
    • Botnets
    • CDN- en WAF-mogelijkheden
  • Uitbreiding van bevoegdheden: toegang krijgen tot bevoegde toepassingen via autorisatie-aanvallen. Een aanvaller die bijvoorbeeld een URL-tekenreeks bewerkt om toegang te krijgen tot gevoelige informatie.
    • Uitvoering van externe code
    • Autorisatie
    • Isolatie

Ontwerpaanaanvelingen

  • Wijs het technische budget binnen elke sprint toe om potentiële nieuwe bedreigingen te evalueren en oplossingen te implementeren.

  • Bewuste inspanningen moeten worden toegepast om ervoor te zorgen dat beveiligingsbeperkende maatregelen worden vastgelegd binnen een gemeenschappelijk technisch criterium om consistentie in alle toepassingsserviceteams te stimuleren.

  • Begin met een service op bedreigingsmodellering op serviceniveau en koppel het model door het threadmodel op toepassingsniveau te consolideren.

Beveiliging tegen inbraak in het netwerk

Het voorkomen van onbevoegde toegang tot een bedrijfskritieke toepassing en omvattende gegevens is essentieel voor het behouden van beschikbaarheid en het beschermen van gegevensintegriteit.

Ontwerpoverwegingen

  • Zero Trust veronderstelt een geschonden status en verifieert elke aanvraag alsof deze afkomstig is van een niet-gecontroleerd netwerk.

    • Een geavanceerde zero-trust-netwerk-implementatie maakt gebruik van microsegmentatie en gedistribueerde micro-perimeters voor inkomend/uitgaand verkeer.
  • Azure PaaS-services worden doorgaans geopend via openbare eindpunten. Azure biedt mogelijkheden om openbare eindpunten te beveiligen of ze zelfs volledig privé te maken.

    • Azure Private Link/Privé-eindpunten bieden toegewezen toegang tot een Azure PaaS-resource met behulp van privé-IP-adressen en connectiviteit met een privénetwerk.
    • Service-eindpunten voor virtuele netwerken bieden toegang op serviceniveau van geselecteerde subnetten naar geselecteerde PaaS-services.
    • Virtual Network-injectie biedt toegewezen privé-implementaties voor ondersteunde services, zoals App Service via een App Service-omgeving.
      • Het beheervlakverkeer loopt nog steeds via openbare IP-adressen.
  • Voor ondersteunde services behandelt Azure Private Link met behulp van Azure Private Endpoints gegevensexfiltratierisico's die zijn gekoppeld aan service-eindpunten, zoals een kwaadwillende beheerder die gegevens naar een externe resource schrijft.

  • Wanneer u netwerktoegang tot Azure PaaS-services beperkt met behulp van privé-eindpunten of service-eindpunten, is een beveiligd netwerkkanaal vereist voor implementatiepijplijnen voor toegang tot zowel het Azure-besturingsvlak als het gegevensvlak van Azure-resources om de toepassing te implementeren en te beheren.

    • Privé zelf-hostende buildagents die zijn geïmplementeerd in een privénetwerk, omdat de Azure-resource kan worden gebruikt als proxy voor het uitvoeren van CI/CD-functies via een privéverbinding. Er moet een afzonderlijk virtueel netwerk worden gebruikt voor buildagents.
      • Connectiviteit met de privé-buildagents vanuit CI/CD-hulpprogramma's is vereist.
    • Een alternatieve methode is om de firewallregels voor de resource on-the-fly in de pijplijn te wijzigen om een verbinding vanaf een openbaar IP-adres van een Azure DevOps-agent toe te staan, waarbij de firewall vervolgens wordt verwijderd nadat de taak is voltooid.
      • Deze benadering is echter alleen van toepassing op een subset van Azure-services. Dit is bijvoorbeeld niet haalbaar voor privé-AKS-clusters.
    • Voor het uitvoeren van ontwikkelaars- en beheertaken in de sprongvakken van de toepassingsservice kunnen worden gebruikt.
  • Het voltooien van beheer- en onderhoudstaken is een ander scenario dat connectiviteit met het gegevensvlak van Azure-resources vereist.

  • Serviceverbindingen met een bijbehorende Microsoft Entra-service-principal kunnen worden gebruikt in Azure DevOps om RBAC toe te passen via Microsoft Entra-id.

  • Servicetags kunnen worden toegepast op netwerkbeveiligingsgroepen om connectiviteit met Azure PaaS-services te vergemakkelijken.

  • Toepassingsbeveiligingsgroepen omvatten niet meerdere virtuele netwerken.

  • Pakketopname in Azure Network Watcher is beperkt tot maximaal vijf uur.

Ontwerpaanaanvelingen

  • Beperk de toegang tot het openbare netwerk tot het absolute minimum dat de toepassing nodig heeft om te voldoen aan het bedrijfsdoel om het externe aanvalsoppervlak te verminderen.

  • Wanneer u te maken hebt met privé-buildagents, opent u nooit rechtstreeks een RDP- of SSH-poort naar internet.

    • Gebruik Azure Bastion om beveiligde toegang te bieden tot virtuele Azure-machines en om beheertaken uit te voeren op Azure PaaS via internet.
  • Gebruik een DDoS-standaardbeveiligingsplan om alle openbare IP-adressen in de toepassing te beveiligen.

  • Gebruik Azure Front Door met firewallbeleid voor webtoepassingen om wereldwijde HTTP/S-toepassingen te leveren en te beveiligen die meerdere Azure-regio's omvatten.

    • Gebruik header-id-validatie om openbare toepassingseindpunten te vergrendelen, zodat ze alleen verkeer accepteren dat afkomstig is van het Azure Front Door-exemplaar.
  • Als er aanvullende inline netwerkbeveiligingsvereisten, zoals grondige pakketinspectie of TLS-inspectie, het gebruik van Azure Firewall Premium of Network Virtual Appliance (NVA) vereisen, moet u ervoor zorgen dat deze is geconfigureerd voor maximale hoge beschikbaarheid en redundantie.

  • Als er vereisten voor pakketopname bestaan, gebruikt u Network Watcher-pakketten om vast te leggen ondanks het beperkte opnamevenster.

  • Gebruik netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen om toepassingsverkeer te segmenteren.

    • Vermijd het gebruik van een beveiligingsapparaat om verkeerstromen binnen toepassingen te filteren.
    • Overweeg het gebruik van Azure Policy om specifieke NSG-regels af te dwingen, altijd gekoppeld aan toepassingssubnetten.
  • Schakel NSG-stroomlogboeken in en voer ze in Traffic Analytics in om inzicht te krijgen in interne en externe verkeersstromen.

  • Gebruik Azure Private Link/Privé-eindpunten, indien beschikbaar, om de toegang tot Azure PaaS-services binnen het toepassingsontwerp te beveiligen. Zie de beschikbaarheid van Azure Private Link voor informatie over Azure-services die ondersteuning bieden voor Private Link.

  • Als privé-eindpunten niet beschikbaar zijn en risico's voor gegevensexfiltratie acceptabel zijn, gebruikt u Service-eindpunten voor virtuele netwerken om de toegang tot Azure PaaS-services vanuit een virtueel netwerk te beveiligen.

    • Schakel service-eindpunten voor virtuele netwerken niet standaard in op alle subnetten, omdat dit aanzienlijke exfiltratiekanalen voor gegevens introduceert.
  • Voor hybride toepassingsscenario's hebt u toegang tot Azure PaaS-services vanaf on-premises via ExpressRoute met persoonlijke peering.

Notitie

Wanneer u implementeert binnen een Azure-landingszone, moet u er rekening mee houden dat de netwerkverbinding met on-premises datacenters wordt geboden door de implementatie van de landingszone. Een benadering is het gebruik van ExpressRoute die is geconfigureerd met persoonlijke peering.

Beveiliging van gegevensintegriteit

Versleuteling is een essentiële stap voor het waarborgen van gegevensintegriteit en is uiteindelijk een van de belangrijkste beveiligingsmogelijkheden die kunnen worden toegepast om een breed scala aan bedreigingen te beperken. Deze sectie biedt daarom belangrijke overwegingen en aanbevelingen met betrekking tot versleuteling en sleutelbeheer om gegevens te beschermen zonder de betrouwbaarheid van toepassingen in gevaar te brengen.

Ontwerpoverwegingen

  • Azure Key Vault heeft transactielimieten voor sleutels en geheimen, waarbij beperking per kluis binnen een bepaalde periode wordt toegepast.

  • Azure Key Vault biedt een beveiligingsgrens omdat toegangsmachtigingen voor sleutels, geheimen en certificaten worden toegepast op kluisniveau.

    • Key Vault-toegangsbeleidstoewijzingen verlenen afzonderlijke machtigingen aan sleutels, geheimen of certificaten.
  • Nadat een roltoewijzing is gewijzigd, is er een latentie van maximaal 10 minuten (600 seconden) voordat de rol wordt toegepast.

    • Er geldt een limiet van 2000 Azure-roltoewijzingen per abonnement.
  • Onderliggende HSM's (Hardware Security Modules) van Azure Key Vault hebben FIPS 140-validatie.

  • Azure Key Vault biedt hoge beschikbaarheid en redundantie om de beschikbaarheid te behouden en gegevensverlies te voorkomen.

  • Tijdens een regiofailover kan het enkele minuten duren voordat de Key Vault-service een failover heeft uitgevoerd.

    • Tijdens een failover-sleutelkluis bevindt zich in een modus met het kenmerk Alleen-lezen, zodat het niet mogelijk is om eigenschappen van de sleutelkluis te wijzigen, zoals firewallconfiguraties en -instellingen.
  • Als private link wordt gebruikt om verbinding te maken met Azure Key Vault, kan het tot 20 minuten duren voordat de verbinding opnieuw tot stand is gebracht tijdens een regionale failover.

  • Een back-up maakt een momentopname van een geheim, sleutel of certificaat naar een bepaald tijdstip als een versleutelde blob die niet buiten Azure kan worden ontsleuteld. Als u bruikbare gegevens uit de blob wilt ophalen, moet deze worden hersteld in een Key Vault binnen hetzelfde Azure-abonnement en azure-geografie.

    • Geheimen kunnen tijdens een back-up worden vernieuwd, waardoor deze niet overeenkomen.
  • Met door de service beheerde sleutels voert Azure sleutelbeheerfuncties uit, zoals rotatie, waardoor het bereik van toepassingsbewerkingen wordt verminderd.

  • Voor regelgevingscontroles kan het gebruik van door de klant beheerde sleutels worden bepaald voor de functionaliteit voor serviceversleuteling.

  • Wanneer verkeer tussen Azure-datacenters wordt verplaatst, wordt MACsec-gegevenskoppelingslaagversleuteling gebruikt op de onderliggende netwerkhardware om gegevens die worden overgedragen buiten de fysieke grenzen te beveiligen die niet worden beheerd door Microsoft of namens Microsoft.

Ontwerpaanaanvelingen

  • Gebruik waar mogelijk door de service beheerde sleutels voor gegevensbeveiliging, waardoor u geen versleutelingssleutels hoeft te beheren en operationele taken, zoals sleutelrotatie, moet afhandelen.

    • Gebruik door de klant beheerde sleutels alleen als er een duidelijke wettelijke vereiste is om dit te doen.
  • Gebruik Azure Key Vault als een beveiligde opslagplaats voor alle geheimen, certificaten en sleutels als er aanvullende versleutelingsmechanismen of door de klant beheerde sleutels nodig zijn.

    • Richt Azure Key Vault in met het beleid voor voorlopig verwijderen en opschonen ingeschakeld om bewaarbeveiliging voor verwijderde objecten mogelijk te maken.
    • Gebruik HSM-ondersteunde Azure Key Vault-SKU voor toepassingsproductieomgevingen.
  • Implementeer een afzonderlijk Azure Key Vault-exemplaar binnen elke regionale implementatiestempel, met foutisolatie en prestatievoordelen door middel van lokalisatie, en door de schaallimieten te navigeren die door één Key Vault-exemplaar worden opgelegd.

    • Gebruik een toegewezen Azure Key Vault-exemplaar voor globale toepassingsbronnen.
  • Volg een model met minimale bevoegdheden door autorisatie te beperken om geheimen, sleutels en certificaten permanent te verwijderen naar gespecialiseerde aangepaste Microsoft Entra-rollen.

  • Zorg ervoor dat er een back-up wordt gemaakt van versleutelingssleutels en certificaten die zijn opgeslagen in Key Vault, waardoor een offlinekopie wordt geboden in de onwaarschijnlijke gebeurtenis dat Key Vault niet meer beschikbaar is.

  • Key Vault-certificaten gebruiken om de aanschaf en ondertekening van certificaten te beheren.

  • Stel een geautomatiseerd proces in voor sleutel- en certificaatrotatie.

    • Automatiseer het proces voor certificaatbeheer en verlenging met openbare certificeringsinstanties om het beheer te vereenvoudigen.
      • Stel waarschuwingen en meldingen in om automatische certificaatvernieuwingen aan te vullen.
  • Controleer het gebruik van sleutels, certificaten en geheimen.

Governance op basis van beleid

Beveiligingsconventies zijn uiteindelijk alleen effectief als consistent en holistisch wordt afgedwongen voor alle toepassingsservices en teams. Azure Policy biedt een framework voor het afdwingen van beveiligings- en betrouwbaarheidsbasislijnen, waardoor de naleving van algemene technische criteria voor een bedrijfskritieke toepassing wordt gewaarborgd. Meer specifiek vormt Azure Policy een belangrijk onderdeel van het Azure Resource Manager-besturingsvlak (ARM), aangevuld met RBAC door te beperken welke acties geautoriseerde gebruikers kunnen uitvoeren en kunnen worden gebruikt om essentiële beveiligings- en betrouwbaarheidsconventies af te dwingen voor alle gebruikte platformservices.

In deze sectie worden daarom belangrijke overwegingen en aanbevelingen besproken rond het gebruik van Azure Policy-governance voor een bedrijfskritieke toepassing, waardoor beveiligings- en betrouwbaarheidsconventies continu worden afgedwongen.

Ontwerpoverwegingen

  • Azure Policy biedt een mechanisme om naleving te stimuleren door beveiligings- en betrouwbaarheidsconventies af te dwingen, zoals het gebruik van privé-eindpunten of het gebruik van Beschikbaarheidszones.

Notitie

Wanneer u implementeert in een Azure-landingszone, moet u er rekening mee houden dat het afdwingen van gecentraliseerde basislijnbeleidstoewijzingen waarschijnlijk wordt toegepast in de implementatie voor beheergroepen en abonnementen voor landingszones.

  • Azure Policy kan worden gebruikt om geautomatiseerde beheeractiviteiten te stimuleren, zoals inrichten en configureren.

    • Registratie van de resourceprovider.
    • Validatie en goedkeuring van afzonderlijke Azure-resourceconfiguraties.
  • Het toewijzingsbereik van Azure Policy bepaalt de dekking en de locatie van Azure Policy-definities informeert de herbruikbaarheid van aangepaste beleidsregels.

  • Azure Policy heeft verschillende limieten, zoals het aantal definities in een bepaald bereik.

  • Het kan enkele minuten duren voordat het DINE-beleid (Deploy If Not Exist) wordt uitgevoerd.

  • Azure Policy biedt een essentiële invoer voor nalevingsrapportage en beveiligingscontrole.

Ontwerpaanaanvelingen

  • Wijs wettelijke en nalevingsvereisten toe aan Azure Policy-definities.

    • Als er bijvoorbeeld vereisten voor gegevenslocatie zijn, moet een beleid worden toegepast om de beschikbare implementatieregio's te beperken.
  • Definieer algemene technische criteria voor het vastleggen van veilige en betrouwbare configuratiedefinities voor alle gebruikte Azure-services, zodat deze criteria worden toegewezen aan Azure Policy-toewijzingen om naleving af te dwingen.

    • Pas bijvoorbeeld een Azure Policy toe om het gebruik van Beschikbaarheidszones af te dwingen voor alle relevante services, waardoor betrouwbare implementatieconfiguraties binnen regio's worden gegarandeerd.

De missiekritieke referentie-implementatie bevat een breed scala aan beveiligings- en betrouwbaarheidsgerichte beleidsregels om een voorbeeld van algemene technische criteria te definiëren en af te dwingen.

  • Bewaak serviceconfiguratiedrift, ten opzichte van de algemene technische criteria, met behulp van Azure Policy.

Voor bedrijfskritieke scenario's met meerdere productieabonnementen onder een toegewezen beheergroep geeft u prioriteit aan toewijzingen binnen het bereik van de beheergroep.

  • Gebruik waar mogelijk ingebouwde beleidsregels om de operationele overhead van het onderhouden van aangepaste beleidsdefinities te minimaliseren.

  • Wanneer aangepaste beleidsdefinities vereist zijn, moet u ervoor zorgen dat definities worden geïmplementeerd op het geschikte bereik van de beheergroep om hergebruik toe te staan voor hergebruik in alle beheerde omgevingen, zodat beleid opnieuw kan worden gebruikt in productieomgevingen en lagere omgevingen.

    • Wanneer u de roadmap van de toepassing uitlijnt met Azure-roadmaps, gebruikt u beschikbare Microsoft-resources om te onderzoeken of kritieke aangepaste definities als ingebouwde definities kunnen worden opgenomen.

Notitie

Bij het implementeren binnen een Azure-landingszone kunt u overwegen aangepaste Azure Policy-definities binnen het bereik van de tussenliggende bedrijfshoofdbeheergroep te implementeren om hergebruik in alle toepassingen binnen de bredere Azure-omgeving mogelijk te maken. In een omgeving met landingszones worden bepaalde gecentraliseerde beveiligingsbeleidsregels standaard toegepast binnen hogere beheergroepbereiken om beveiligingsnaleving af te dwingen in de hele Azure-omgeving. Azure-beleid moet bijvoorbeeld worden toegepast om softwareconfiguraties automatisch te implementeren via VM-extensies en een compatibele basislijn-VM-configuratie af te dwingen.

  • Gebruik Azure Policy om een consistent tagschema af te dwingen in de toepassing.
    • Identificeer vereiste Azure-tags en gebruik de modus voor het toevoegen van beleid om gebruik af te dwingen.

Als de toepassing is geabonneerd op Microsoft Mission-Critical Support, moet u ervoor zorgen dat het toegepaste tagschema zinvolle context biedt om de ondersteuningservaring te verrijken met diepgaande toepassingskennis.

  • Exporteer microsoft Entra-activiteitenlogboeken naar de globale Log Analytics-werkruimte die door de toepassing wordt gebruikt.
    • Zorg ervoor dat Azure-activiteitenlogboeken worden gearchiveerd in het globale opslagaccount, samen met operationele gegevens voor langetermijnretentie.

In een Azure-landingszone worden activiteitenlogboeken van Microsoft Entra ook opgenomen in de gecentraliseerde Log Analytics-werkruimte van het platform. Deze moet in dit geval worden geëvalueerd als Microsoft Entra-id nog steeds vereist is in de globale Log Analytics-werkruimte.

  • Integreer beveiligingsinformatie en gebeurtenisbeheer met Microsoft Defender voor Cloud (voorheen Bekend als Azure Security Center).

Specifieke overwegingen voor IaaS bij het gebruik van virtuele machines

In scenario's waarin het gebruik van virtuele IaaS-machines vereist is, moet rekening worden gehouden met enkele specifieke kenmerken.

Ontwerpoverwegingen

  • Installatiekopieën worden niet automatisch bijgewerkt zodra ze zijn geïmplementeerd.
  • Updates worden niet automatisch geïnstalleerd voor het uitvoeren van VM's.
  • Installatiekopieën en afzonderlijke VM's worden doorgaans niet standaard beperkt.

Ontwerpaanaanvelingen

  • Directe toegang via het openbare internet naar virtuele machines niet toestaan door toegang te verlenen tot SSH, RDP of andere protocollen. Gebruik Altijd Azure Bastion en jumpboxes met beperkte toegang tot een kleine groep gebruikers.
  • Beperk directe internetverbinding met behulp van Netwerkbeveiligingsgroepen, (Azure) Firewall of Application Gateways (niveau 7) om uitgaand verkeer te filteren en te beperken.
  • Voor toepassingen met meerdere lagen kunt u overwegen om verschillende subnetten te gebruiken en netwerkbeveiligingsgroepen te gebruiken om de toegang tussen beide te beperken.
  • Geef waar mogelijk prioriteit aan het gebruik van openbare-sleutelverificatie. Bewaar geheimen op een veilige locatie, zoals Azure Key Vault.
  • Beveilig VM's met behulp van verificatie en toegangsbeheer.
  • Pas dezelfde beveiligingsprocedures toe zoals beschreven voor bedrijfskritieke toepassingsscenario's.

Volg en pas beveiligingsprocedures toe voor bedrijfskritieke toepassingsscenario's zoals hierboven beschreven, indien van toepassing, evenals de aanbevolen beveiligingsprocedures voor IaaS-workloads in Azure.

Volgende stap

Bekijk de aanbevolen procedures voor operationele procedures voor bedrijfskritieke toepassingsscenario's.