Aanbevelingen voor het beveiligen van toepassingsgeheimen

  • Artikel

Is van toepassing op deze aanbeveling voor de controlelijst voor beveiliging van Azure Well-Architected Framework:

SE:09 Beveilig toepassingsgeheimen door hun opslag te beveiligen, toegang en manipulatie te beperken en door deze acties te controleren. Voer een betrouwbaar en regelmatig rotatieproces uit waarmee rotaties in noodgevallen kunnen worden geïmproviseerd.

In deze handleiding worden de aanbevelingen beschreven voor het beveiligen van gevoelige informatie in toepassingen. Goed beheer van geheimen is van cruciaal belang voor het handhaven van de beveiliging en integriteit van uw toepassing, workload en bijbehorende gegevens. Onjuiste verwerking van geheimen kan leiden tot gegevensschendingen, serviceonderbrekingen, schendingen van regelgeving en andere problemen.

Referenties, zoals API-sleutels, OAuth-tokens (Open Authorization) en SSH-sleutels (Secure Shell) zijn geheimen. Sommige referenties, zoals OAuth-tokens aan de clientzijde, kunnen dynamisch worden gemaakt tijdens runtime. Dynamische geheimen moeten nog steeds worden beveiligd, ondanks hun tijdelijke aard. Niet-essentiële gegevens, zoals certificaten en digitale handtekeningsleutels, kunnen ook gevoelig zijn. Nalevingsvereisten kunnen ertoe leiden dat configuratie-instellingen die doorgaans niet als geheim worden beschouwd, worden behandeld als toepassingsgeheimen.

Definities 

Termijn Definitie
Certificaten Digitale bestanden met de openbare sleutels voor versleuteling of ontsleuteling.
Referentie Informatie die wordt gebruikt om de identiteit van de uitgever of consument in een communicatiekanaal te verifiëren.
Referenties scannen Het proces van het valideren van broncode om ervoor te zorgen dat geheimen niet worden opgenomen.
Versleuteling Het proces waarmee gegevens onleesbaar worden gemaakt en vergrendeld met een geheime code.
Sleutel Een geheime code die wordt gebruikt om versleutelde gegevens te vergrendelen of te ontgrendelen.
Toegang met minimale bevoegdheden Een Zero Trust principe dat gericht is op het minimaliseren van een set machtigingen voor het voltooien van een taakfunctie.
Beheerde identiteit Een identiteit die is toegewezen aan resources en wordt beheerd door Azure.
Niet-secret Informatie die de beveiligingspostuur van de workload niet in gevaar brengt als deze wordt gelekt.
Rotatie Het proces van het regelmatig bijwerken van geheimen, zodat ze, als ze zijn aangetast, slechts voor een beperkte tijd beschikbaar zijn.
Geheim Een vertrouwelijk onderdeel van het systeem dat communicatie tussen workloadonderdelen vergemakkelijkt. Als geheimen worden gelekt, kunnen deze een inbreuk veroorzaken.
X.509 Een standaard die de indeling van openbare-sleutelcertificaten definieert.

Belangrijk

Behandel nonsecrets niet als geheimen. Geheimen vereisen operationele striktheid die niet nodig is voor niet-beveiligingsleden en dat kan leiden tot extra kosten.

Toepassingsconfiguratie-instellingen, zoals URL's voor API's die door de toepassing worden gebruikt, zijn een voorbeeld van niet-secrets. Deze informatie mag niet worden opgeslagen met de toepassingscode of toepassingsgeheimen. Overweeg het gebruik van een toegewezen configuratiebeheersysteem zoals Azure App Configuration om deze instellingen te beheren. Zie Wat is Azure App Configuration? voor meer informatie.

Belangrijke ontwerpstrategieën

Uw strategie voor geheimbeheer moet geheimen zoveel mogelijk minimaliseren en deze integreren in de omgeving door gebruik te maken van platformfuncties. Als u bijvoorbeeld een beheerde identiteit voor uw toepassing gebruikt, worden toegangsgegevens niet ingesloten in verbindingsreeksen en is het veilig om de gegevens op te slaan in een configuratiebestand. Houd rekening met de volgende aandachtspunten voordat u geheimen opslaat en beheert:

  • Gemaakte geheimen moeten worden bewaard in beveiligde opslag met strikt toegangsbeheer.

  • Het rouleren van geheimen is een proactieve bewerking, terwijl intrekken reactief is.

  • Alleen vertrouwde identiteiten mogen toegang hebben tot geheimen.

  • U moet een audittrail bijhouden om de toegang tot geheimen te controleren en te valideren.

Bouw een strategie rond deze punten om identiteitsdiefstal te voorkomen, weerlegbaarheid te voorkomen en onnodige blootstelling aan informatie te minimaliseren.

Veilige procedures voor geheimbeheer

Vermijd, indien mogelijk, geheimen te maken. Manieren vinden om verantwoordelijkheid aan het platform te delegeren. Gebruik bijvoorbeeld de ingebouwde beheerde identiteiten van het platform om referenties te verwerken. Minder geheimen resulteren in een kleiner oppervlak en minder tijd besteed aan geheimbeheer.

We raden aan dat sleutels drie verschillende rollen hebben: gebruiker, beheerder en auditor. Rolscheiding helpt ervoor te zorgen dat alleen vertrouwde identiteiten toegang hebben tot geheimen met het juiste machtigingsniveau. Informeer ontwikkelaars, beheerders en ander relevant personeel over het belang van best practices voor geheimbeheer en beveiliging.

Vooraf gedeelde sleutels

U kunt de toegang beheren door afzonderlijke sleutels voor elke consument te maken. Een client communiceert bijvoorbeeld met een API van derden met behulp van een vooraf gedeelde sleutel. Als een andere client toegang moet hebben tot dezelfde API, moet deze een andere sleutel gebruiken. Deel geen sleutels, zelfs niet als twee gebruikers dezelfde toegangspatronen of rollen hebben. Consumentenbereiken kunnen na verloop van tijd veranderen en u kunt machtigingen niet onafhankelijk bijwerken of gebruikspatronen onderscheiden nadat een sleutel is gedeeld. Afzonderlijke toegang maakt het intrekken ook eenvoudiger. Als de sleutel van een consument is gecompromitteerd, is het eenvoudiger om die sleutel in te trekken of te roteren zonder dat dit van invloed is op andere consumenten.

Deze richtlijnen zijn van toepassing op verschillende omgevingen. Dezelfde sleutel mag niet worden gebruikt voor zowel preproductie- als productieomgevingen. Als u verantwoordelijk bent voor het maken van vooraf gedeelde sleutels, moet u meerdere sleutels maken om meerdere clients te ondersteunen.

Zie Aanbevelingen voor identiteits- en toegangsbeheer voor meer informatie.

Geheime opslag

Gebruik een geheimbeheersysteem, zoals Azure Key Vault, om geheimen op te slaan in een beveiligde omgeving, at-rest en in transit te versleutelen en toegang en wijzigingen in geheimen te controleren. Als u toepassingsgeheimen wilt opslaan, houdt u deze buiten de broncode voor eenvoudige rotatie.

Certificaten mogen alleen worden opgeslagen in Key Vault of in het certificaatarchief van het besturingssysteem. Het opslaan van een X.509-certificaat in een PFX-bestand of op een schijf wordt bijvoorbeeld niet aanbevolen. Als u een hoger beveiligingsniveau nodig hebt, kiest u systemen met HSM-mogelijkheden (Hardware Security Module) in plaats van op software gebaseerde geheimarchieven.

Afweging: HSM-oplossingen worden aangeboden tegen hogere kosten. Mogelijk ziet u ook een effect op de prestaties van toepassingen vanwege extra beveiligingslagen.

Met een toegewezen geheimbeheersysteem kunt u eenvoudig de toegang tot toepassingsgeheimen opslaan, distribueren en beheren. Alleen geautoriseerde identiteiten en services mogen toegang hebben tot geheimarchieven. Toegang tot het systeem kan worden beperkt via machtigingen. Gebruik altijd de methode met de minste bevoegdheden bij het toewijzen van machtigingen.

U moet ook de toegang beheren op geheimniveau. Elk geheim mag slechts toegang hebben tot één resourcebereik. Maak isolatiegrenzen zodat een onderdeel alleen geheimen kan gebruiken die nodig zijn. Als een geïsoleerd onderdeel wordt aangetast, kan het geen controle krijgen over andere geheimen en mogelijk de hele workload. Een manier om geheimen te isoleren, is door meerdere sleutelkluizen te gebruiken. Er zijn geen extra kosten verbonden aan het maken van extra sleutelkluizen.

Implementeer controle en bewaking voor toegang tot geheimen. Registreren wie toegang heeft tot geheimen en wanneer niet-geautoriseerde of verdachte activiteiten moeten worden geïdentificeerd. Zie Aanbevelingen voor beveiligingsbewaking en detectie van bedreigingen voor informatie over logboekregistratie vanuit een beveiligingsperspectief.

Geheime rotatie

Zorg voor een proces dat geheime hygiëne handhaaft. De levensduur van een geheim is van invloed op het beheer van dat geheim. Om aanvalsvectoren te verminderen, moeten geheimen zo vaak mogelijk buiten gebruik worden gesteld en vervangen door nieuwe geheimen.

Ga zorgvuldig met OAuth-toegangstokens om, rekening houdend met hun Time to Live. Overweeg of het blootstellingsvenster moet worden aangepast aan een kortere periode. Vernieuwingstokens moeten veilig worden opgeslagen met beperkte blootstelling aan de toepassing. Vernieuwde certificaten moeten ook een nieuwe sleutel gebruiken. Zie OAuth 2.0 On-Behalf-Of-vernieuwingstokens beveiligen voor informatie over vernieuwingstokens.

Vervang geheimen nadat ze het einde van de levensduur hebben bereikt, niet meer worden gebruikt door de workload of als ze zijn gecompromitteerd. Stel actieve geheimen daarentegen niet buiten gebruik, tenzij het een noodgeval is. U kunt de status van een geheim bepalen door toegangslogboeken te bekijken. Processen voor het rouleren van geheimen mogen geen invloed hebben op de betrouwbaarheid of prestaties van de workload. Gebruik strategieën die redundantie inbouwen in geheimen, consumenten en toegangsmethoden voor een soepele rotatie.

Zie Toegangssleutels voor accounts beheren voor meer informatie over hoe Azure Storage rotatie verwerkt.

Rotatieprocessen moeten worden geautomatiseerd en geïmplementeerd zonder tussenkomst van de mens. Het opslaan van geheimen in een geheimbeheerarchief dat systeemeigen ondersteuning biedt voor rotatieconcepten, kan deze operationele taak vereenvoudigen.

Veilige procedures voor het gebruik van geheimen

Als geheimgenerator of operator moet u geheimen op een veilige manier kunnen distribueren. Veel organisaties gebruiken hulpprogramma's om geheimen veilig te delen, zowel binnen de organisatie als extern met partners. Als er geen hulpprogramma is, moet u een proces hebben voor het correct overhandigen van referenties aan geautoriseerde ontvangers. Uw noodherstelplannen moeten procedures voor het herstellen van geheimen bevatten. Zorg voor een proces voor situaties waarin een sleutel is gecompromitteerd of gelekt en op aanvraag opnieuw moet worden gegenereerd. Houd rekening met de volgende aanbevolen procedures voor veiligheid bij het gebruik van geheimen:

Hardcoding voorkomen

Maak geen vaste codegeheimen als statische tekst in codeartefacten, zoals toepassingscode, configuratiebestanden en build-implementatiepijplijnen. Deze praktijk met een hoog risico maakt de code kwetsbaar omdat geheimen worden blootgesteld aan iedereen met leestoegang.

U kunt deze situatie voorkomen door beheerde identiteiten te gebruiken om de noodzaak om referenties op te slaan te elimineren. Uw toepassing gebruikt de toegewezen identiteit om te verifiëren bij andere resources via de id-provider (IdP). Test in niet-productieomgevingen met valse geheimen tijdens de ontwikkeling om onbedoelde blootstelling van echte geheimen te voorkomen.

Gebruik hulpprogramma's die periodiek zichtbaar gemaakte geheimen in uw toepassingscode detecteren en artefacten bouwen. U kunt deze hulpprogramma's toevoegen als git-precommit hooks die zoeken naar referenties voordat de broncodedoorvoeringen worden geïmplementeerd. Bekijk en opschoning van toepassingslogboeken regelmatig om ervoor te zorgen dat er geen geheimen per ongeluk worden vastgelegd. U kunt de detectie ook versterken via peer-beoordelingen.

Notitie

Als de scanprogramma's een geheim detecteren, moet dat geheim worden beschouwd als gecompromitteerd. Deze moet worden ingetrokken.

Reageren op geheimrotatie

Als eigenaar van een workload moet u het plan en beleid voor het rouleren van geheimen begrijpen, zodat u nieuwe geheimen kunt opnemen met minimale onderbreking voor gebruikers. Wanneer een geheim wordt geroteerd, is er mogelijk een venster wanneer het oude geheim ongeldig is, maar het nieuwe geheim niet is geplaatst. Tijdens dat venster worden aanvragen niet bevestigd door het onderdeel dat de toepassing probeert te bereiken. U kunt deze problemen minimaliseren door logica voor opnieuw proberen in de code in te bouwen. U kunt ook gelijktijdige toegangspatronen gebruiken waarmee u meerdere referenties hebt die veilig kunnen worden gewijzigd zonder dat dit van invloed is op elkaar.

Werk met het operations-team en maak deel uit van het wijzigingsbeheerproces. Laat referentie-eigenaren weten wanneer u een deel van de toepassing buiten gebruik stelt dat gebruikmaakt van referenties die niet meer nodig zijn.

Integreer het ophalen en configureren van geheimen in uw geautomatiseerde implementatiepijplijn. Het ophalen van geheimen helpt ervoor te zorgen dat geheimen automatisch worden opgehaald tijdens de implementatie. U kunt ook patronen voor geheiminjectie gebruiken om geheimen in te voegen in toepassingscode of configuratie tijdens runtime, waardoor geheimen niet per ongeluk worden blootgesteld aan logboeken of versiebeheer.

Azure-facilitering

Geheimen opslaan met behulp van Key Vault. Sla geheimen op in het Azure-geheimbeheersysteem, Key Vault, door Azure beheerde HSM en andere locaties. Zie How to choose the right key management solution (De juiste oplossing voor sleutelbeheer kiezen) voor meer informatie.

Op identiteit gebaseerd toegangsbeheer integreren. Microsoft Entra-id en beheerde identiteiten helpen de noodzaak van geheimen te minimaliseren. Microsoft Entra ID biedt een zeer veilige en bruikbare ervaring voor toegangsbeheer met ingebouwde mechanismen voor het afhandelen van sleutelrotatie, voor afwijkingen en meer.

Gebruik op rollen gebaseerd toegangsbeheer (RBAC) van Azure om machtigingen toe te wijzen aan gebruikers, groepen en toepassingen binnen een bepaald bereik.

Gebruik een toegangsmodel om sleutelkluizen, machtigingen en geheimen te beheren. Zie Overzicht van Access-model voor meer informatie.

Detectie van geheimblootstelling implementeren. Integreer processen in uw workload die verdachte activiteiten detecteren en periodiek controleren op beschikbaar gemaakte sleutels in uw toepassingscode. Enkele opties zijn:

Sla geen sleutels en geheimen op voor omgevingstypen in toepassingsconfiguratiebestanden of CI/CD-pijplijnen (Continue integratie en continue levering). Ontwikkelaars moeten Visual Studio Connected Services of lokale bestanden gebruiken om toegang te krijgen tot referenties.

Controlelijst voor beveiliging

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor beveiliging