Delen via

Aanbevelingen voor het beveiligen van toepassingsgeheimen

  • Artikel

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

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

In deze handleiding worden de aanbevelingen voor het beveiligen van gevoelige informatie in toepassingen beschreven. Het juiste beheer van geheimen is van cruciaal belang voor het onderhouden van de beveiliging en integriteit van uw toepassing, workload en bijbehorende gegevens. Onjuiste verwerking van geheimen kan leiden tot gegevensschendingen, serviceonderbreking, 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 beschermd ondanks hun tijdelijke aard. Niet-credentiële informatie, zoals certificaten en digitale handtekeningsleutels, kan ook gevoelig zijn. Nalevingsvereisten kunnen ertoe leiden dat configuratie-instellingen die doorgaans niet als geheim worden beschouwd, worden behandeld als toepassingsgeheimen.

Definities 

Term Definitie
Certificaten Digitale bestanden die de openbare sleutels bevatten 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 voor het valideren van broncode om ervoor te zorgen dat geheimen niet zijn opgenomen.
Versleuteling Het proces waarmee gegevens onleesbaar worden gemaakt en vergrendeld met een geheime code.
Sleutel Een geheime code die wordt gebruikt voor het vergrendelen of ontgrendelen van versleutelde gegevens.
Toegang met minimale bevoegdheden Een Zero Trust-principe dat is gericht op het minimaliseren van een set machtigingen voor het voltooien van een functie.
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, als ze worden gecompromitteerd, ze slechts gedurende een beperkte tijd beschikbaar zijn.
Geheim Een vertrouwelijk onderdeel van het systeem dat de communicatie tussen workloadonderdelen vergemakkelijkt. Als ze worden gelekt, kunnen geheimen een inbreuk veroorzaken.
X.509 Een standaard waarmee de indeling van certificaten van openbare sleutels wordt gedefinieerd.

Belangrijk

Behandel niet nonsecrets zoals geheimen. Geheimen vereisen operationele rigor die niet nodig is voor niet-secrets 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 Configuratie om deze instellingen te beheren. Zie Wat is Azure-app Configuratie? voor meer informatie.

Belangrijke ontwerpstrategieën

Uw strategie voor geheimbeheer moet geheimen zoveel mogelijk minimaliseren en 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 verbindingsreeks s en kunt u de gegevens veilig opslaan in een configuratiebestand. Houd rekening met de volgende aandachtspunten voordat u geheimen opslaat en beheert:

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

  • Geheimrotatie is een proactieve bewerking, terwijl intrekking reactief is.

  • Alleen vertrouwde identiteiten moeten toegang hebben tot geheimen.

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

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

Workloadgeheimen beheren

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

We raden u 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 andere relevante medewerkers over het belang van aanbevolen procedures voor geheimbeheer en beveiliging.

Vooraf gedeelde sleutels

U kunt de toegang beheren door afzonderlijke sleutels te maken voor elke consument. Een client communiceert bijvoorbeeld met een API van derden met behulp van een vooraf gedeelde sleutel. Als een andere client toegang nodig heeft tot dezelfde API, moeten ze een andere sleutel gebruiken. Deel geen sleutels, zelfs niet als twee consumenten dezelfde toegangspatronen of rollen hebben. Consumentenbereiken kunnen na verloop van tijd veranderen en u kunt niet onafhankelijk machtigingen bijwerken of gebruikspatronen onderscheiden nadat een sleutel is gedeeld. Afzonderlijke toegang maakt het intrekken ook eenvoudiger. Als de sleutel van een consument is aangetast, is het eenvoudiger om die sleutel in te trekken of te draaien 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 beperkte omgeving, at-rest en in transit te versleutelen, en toegang en wijzigingen in geheimen te controleren. Als u toepassingsgeheimen wilt opslaan, moet u deze buiten de broncode bewaren 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 softwaregebaseerde geheime archieven.

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

Met een toegewezen geheimbeheersysteem kunt u eenvoudig toegang tot toepassingsgeheimen opslaan, distribueren en beheren. Alleen geautoriseerde identiteiten en services moeten toegang hebben tot geheime archieven. Toegang tot het systeem kan worden beperkt via machtigingen. Pas altijd de benadering met minimale bevoegdheden toe 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 is 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 voor het maken van extra sleutelkluizen.

Implementeer controle en bewaking voor geheime toegang. Meld u aan wie toegang heeft tot geheimen en wanneer u onbevoegde of verdachte activiteiten identificeert. Zie Aanbevelingen voor beveiligingsbewaking en detectie van bedreigingen voor informatie over logboekregistratie vanuit een beveiligingsperspectief.

Geheime draaiing

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

Afhandelen van OAuth-toegangstokens zorgvuldig, 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 Secure OAuth 2.0 Namens vernieuwingstokens voor informatie over vernieuwingstokens.

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

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

Rotatieprocessen moeten worden geautomatiseerd en geïmplementeerd zonder menselijke interactie. Het opslaan van geheimen in een archief voor geheimbeheer dat systeemeigen ondersteuning biedt voor rotatieconcepten, kan deze operationele taak vereenvoudigen.

Workloadgeheimen veilig gebruiken

Als geheime generator of operator moet u geheimen op een veilige manier kunnen distribueren. Veel organisaties gebruiken hulpprogramma's om geheimen veilig te delen binnen de organisatie en extern naar partners. Als u geen hulpprogramma hebt, moet u een proces hebben voor het correct overdragen van referenties aan geautoriseerde geadresseerden. Uw noodherstelplannen moeten geheime herstelprocedures bevatten. Een proces hebben voor situaties waarin een sleutel is aangetast of gelekt en opnieuw moet worden gegenereerd op aanvraag. Houd rekening met de volgende aanbevolen procedures voor veiligheid bij het gebruik van geheimen:

Hardcoding voorkomen

Codegeheimen als statische tekst in codeartefacten, zoals toepassingscode, configuratiebestanden en pijplijnen voor build-implementatie, worden niet vastgelegd. 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 regelmatig blootgestelde geheimen detecteren in uw toepassingscode en artefacten bouwen. U kunt deze hulpprogramma's toevoegen als vooraf toegewezen Git-hooks die scannen op referenties voordat de broncodedoorvoeringen worden geïmplementeerd. Controleer en saneer toepassingslogboeken regelmatig om ervoor te zorgen dat er per ongeluk geen geheimen worden vastgelegd. U kunt de detectie ook versterken via peerbeoordelingen.

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 inzicht hebben in het plan en het beleid voor het rouleren van geheimen, zodat u nieuwe geheimen kunt opnemen met minimale onderbreking van gebruikers. Wanneer een geheim wordt gedraaid, kan er een venster zijn wanneer het oude geheim niet geldig 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 te bouwen. U kunt ook gelijktijdige toegangspatronen gebruiken waarmee u meerdere referenties kunt hebben die veilig kunnen worden gewijzigd zonder dat dit van invloed is op elkaar.

Werk samen met het operations-team en maak deel uit van het wijzigingsbeheerproces. U moet referentie-eigenaren laten weten wanneer u een deel van de toepassing buiten gebruik wilt stellen waarvoor referenties worden gebruikt die niet meer nodig zijn.

Integreer geheim ophalen en configureren in uw geautomatiseerde implementatiepijplijn. Het ophalen van geheimen helpt ervoor te zorgen dat geheimen automatisch worden opgehaald tijdens de implementatie. U kunt ook geheime injectiepatronen 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 Key Vault. Sla geheimen op in het Azure Secret Management System, Key Vault, Azure Managed HSM en andere locaties. Zie De juiste oplossing voor sleutelbeheer kiezen voor meer informatie.

Integreer op identiteit gebaseerd toegangsbeheer. Microsoft Entra ID en beheerde identiteiten helpen de noodzaak van geheimen tot een minimum te beperken. 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 het overzicht van het Access-model voor meer informatie.

Detectie van geheime blootstelling implementeren. Integreer processen in uw workload die verdachte activiteiten detecteren en periodiek controleren op weergegeven sleutels in uw toepassingscode. Enkele opties zijn:

Sla sleutels en geheimen niet op voor elk omgevingstype 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