Overwegingen voor sleutel- en geheimbeheer in Azure

Versleuteling is een essentieel hulpmiddel voor beveiliging, omdat hiermee de toegang wordt beperkt. Het is echter net zo belangrijk om de geheimen (sleutels, certificaten) te beveiligen die toegang tot de gegevens bieden.

Belangrijkste punten

• Gebruik op identiteit gebaseerd toegangsbeheer in plaats van cryptografische sleutels.
• Gebruik standaard- en aanbevolen versleutelingsalgoritmen.
• Sla sleutels en geheimen op in de beheerde sleutelkluisservice. Machtigingen met een toegangsmodel bepalen.
• Sleutels en andere geheimen regelmatig roteren. Vervang verlopen of aangetaste geheimen.

Op identiteit gebaseerd toegangsbeheer

Organisaties mogen geen eigen versleutelingsalgoritmen ontwikkelen en onderhouden. Er zijn veel manieren om toegangsbeheer te bieden voor opslagbronnen, zoals:

• Gedeelde sleutels
• Gedeelde handtekeningen
• Anonieme toegang
• Methoden op basis van identiteitsproviders

Er bestaan al beveiligde standaarden op de markt en moeten de voorkeur hebben. AES moet worden gebruikt als symmetrische blokcodeer, AES-128 AES-192 , en is AES-256 acceptabel. Waar mogelijk moeten ingebouwde crypto-API's in besturingssystemen worden gebruikt in plaats van niet-platform cryptobibliotheken. Voor .NET moet u het .NET-cryptografiemodel volgen.

Geeft u prioriteit aan verificatie via identiteitsservices voor een workload boven cryptografische sleutels?

Beveiliging van cryptografische sleutels kan vaak over het hoofd worden gezien of slecht worden geïmplementeerd. Het veilig beheren van sleutels met toepassingscode is bijzonder moeilijk en kan leiden tot fouten, zoals het per ongeluk publiceren van gevoelige toegangssleutels naar openbare code-opslagplaatsen.

Het gebruik van op identiteit gebaseerde opties voor toegangsbeheer voor opslag wordt aanbevolen. Deze optie maakt gebruik van op rollen gebaseerd toegangsbesturingselement (RBAC) via opslagbronnen. Gebruik RBAC om machtigingen toe te wijzen aan gebruikers, groepen en toepassingen met een bepaald bereik. Identiteitssystemen zoals Azure Active Directory (Azure AD) bieden een veilige en gebruiksbare ervaring voor toegangsbeheer met ingebouwde mechanismen voor het verwerken van sleutelrotatie, het controleren op afwijkingen en andere.

Stel dat u gevoelige gegevens moet opslaan in Azure Blob Storage. U kunt Azure AD en RBAC gebruiken om een service-principal te verifiëren die de vereiste machtigingen heeft voor toegang tot de opslag. Voor meer informatie over de functie, verwijzen wij u naar Toegang tot blobsen wachtrijen machtigen met behulp van Azure Active Directory .

Sleutelopslag

Sla de volgende sleutels en geheimen op in een beveiligde opslag om beveiligingslekken te voorkomen:

• API-sleutels
• Databaseverbindingsreeksen
• Gegevensversleutelingssleutels
• Wachtwoorden

Gevoelige informatie mag niet worden opgeslagen in de toepassingscode of configuratie. Een aanvaller die leestoegang tot broncode krijgt, mag geen kennis krijgen van toepassings- en omgevingsspecifieke geheimen.

Sla alle toepassingssleutels en geheimen op in een beheerde sleutelkluisservice, zoals Azure Key Vault of HashiCorp Vault. Het opslaan van versleutelingssleutels in een beheerde opslag beperkt de toegang verder. De workload heeft toegang tot de geheimen door te Key Vault met behulp van beheerde identiteiten. Deze toegang kan worden beperkt met Azure RBAC.

Zorg ervoor dat er geen sleutels en geheimen voor omgevingstypen (Dev, Test of Production) zijn opgeslagen in toepassingsconfiguratiebestanden of CI/CD-pijplijnen. Ontwikkelaars kunnen Visual Studio connected services of lokale bestanden gebruiken om toegang te krijgen tot referenties.

Processen hebben die periodiek blootgestelde sleutels in uw toepassingscode detecteren. Een optie is Referentiescanner. Voor informatie over de configuratietaak verwijst u naar de taak Referentiescanner.

Hebt u een toegangsmodel voor sleutelkluizen om toegang te verlenen tot sleutels en geheimen?

Beheer machtigingen voor sleutels en geheimen via een toegangsmodel om de toegang tot uw sleutelkluizen te beveiligen. Voor meer informatie verwijzen we naar Overzicht van het toegangsmodel.

Voorgestelde acties

Overweeg het gebruik Azure Key Vault voor geheimen en sleutels.

Operationele overwegingen

Wie is verantwoordelijk voor het beheren van sleutels en geheimen in de toepassingscontext?

Sleutel- en certificaatrotatie is vaak de oorzaak van uitval van toepassingen. Zelfs Azure heeft te maken met verlopen certificaten. Het is essentieel dat de rotatie van sleutels en certificaten wordt gepland en volledig operationeel is. Het rotatieproces moet worden geautomatiseerd en getest om de effectiviteit te garanderen. Azure Key Vault ondersteunt sleutelrotatie en -controle.

Het centrale SecOps-team biedt richtlijnen voor het beheer van sleutels en geheimen (governance). Het Application DevOps-team is verantwoordelijk voor het beheren van de toepassingsgerelateerde sleutels en geheimen.

Welke typen sleutels en geheimen worden gebruikt en hoe worden deze gegenereerd?

De volgende benaderingen zijn:

• Door Microsoft beheerde sleutels
• Door de klant beheerde sleutels
• Bring Your Own Key

De beslissing wordt vaak aangestuurd door beveiligings-, nalevings- en specifieke vereisten voor gegevensclassificatie. Ontwikkel een duidelijk begrip van deze vereisten om het meest geschikte type sleutels te bepalen.

Worden sleutels en geheimen regelmatig geroteerd?

Om de aanvalsvectoren te verminderen, moeten geheimen worden geroulatied en zijn ze gevoelig voor verloop. Het proces moet worden geautomatiseerd en uitgevoerd zonder menselijke tussenkomst. Het opslaan ervan in een beheerde opslag vereenvoudigt deze operationele taken door sleutelrotatie te verwerken.

Vervang geheimen nadat ze het einde van hun actieve levensduur hebben bereikt of als ze zijn aangetast. Voor vernieuwde certificaten moet ook een nieuwe sleutel worden gebruikt. Een proces hebben voor situaties waarin sleutels worden gecompromitteerd (gelekt) en op aanvraag opnieuw moeten worden gecompromitteerd. Bijvoorbeeld: roulatie van geheimen in SQL Database.

Voor meer informatie, verwijzen Key Vault sleutelrotatie.

Door beheerde identiteiten te gebruiken, verwijdert u de operationele overhead voor het opslaan van de geheimen of certificaten van service-principals.

Worden de vervaldatums van SSL/TLS-certificaten bewaakt en worden er processen gebruikt om ze te vernieuwen?

Een veelvoorkomende oorzaak van een toepassingsstoring zijn verlopen SSL/TLS-certificaten.

Voorkom uitval door de vervaldatums van SSL/TLS-certificaten bij te houden en deze op tijd te vernieuwen. In het ideale moment moet het proces worden geautomatiseerd, hoewel dit vaak afhankelijk is van de gebruikte certificeringsinstantie (CA). Als dit niet geautomatiseerd is, gebruikt u waarschuwingen om ervoor te zorgen dat vervaldatums niet ongemerkt blijven.

Voorgestelde acties

Implementeert u een proces voor SSL-certificaatbeheer en het automatische verlengingsproces met Azure Key Vault.

Lees meer

Zelfstudie: Automatische rotatie van certificaten in Key Vault configureren

Gerelateerde inhoud

Identiteits- en toegangsbeheerservices verifiëren en verlenen machtigingen aan de volgende groepen:

• Gebruikers
• Partners
• Customers
• Toepassingen
• Services
• Andere entiteiten

Voor beveiligingsoverwegingen kunt u verwijzen naar overwegingen voor Identiteits- en toegangsbeheer van Azure.

Terug naar het hoofdartikel: Gegevensbeveiliging

Volgende stappen

Bescherm data-at-rest en in transit via versleuteling. Zorg ervoor dat u standaardversleutelingsalgoritmen gebruikt.