Verbindingen zonder wachtwoord voor Azure-services
Notitie
Verbindingen zonder wachtwoord is een taalagnostische functie die meerdere Azure-services beslaat. Hoewel de huidige documentatie zich richt op een aantal talen en services, zijn we momenteel bezig met het produceren van aanvullende documentatie voor andere talen en services.
In dit artikel worden de beveiligingsproblemen met wachtwoorden beschreven en worden verbindingen zonder wachtwoord geïntroduceerd voor Azure-services.
Beveiligingsproblemen met wachtwoorden en geheimen
Wachtwoorden en geheime sleutels moeten voorzichtig worden gebruikt en ontwikkelaars mogen ze nooit op een onbeveiligde locatie plaatsen. Veel apps maken verbinding met de back-enddatabase, cache, berichten en gebeurtenisservices met behulp van gebruikersnamen, wachtwoorden en toegangssleutels. Als deze worden weergegeven, kunnen deze referenties worden gebruikt om onbevoegde toegang te krijgen tot gevoelige informatie, zoals een verkoopcatalogus die u hebt gemaakt voor een aanstaande campagne of klantgegevens die privé moeten zijn.
Het insluiten van wachtwoorden in een toepassing zelf vormt om vele redenen een enorm beveiligingsrisico, waaronder detectie via een codeopslagplaats. Veel ontwikkelaars externaliseren dergelijke wachtwoorden met behulp van omgevingsvariabelen, zodat toepassingen ze uit verschillende omgevingen kunnen laden. Dit verschuift echter alleen het risico van de code zelf naar een uitvoeringsomgeving. Iedereen die toegang krijgt tot de omgeving, kan wachtwoorden stelen, waardoor uw risico op gegevensexfiltratie toeneemt.
In het volgende codevoorbeeld ziet u hoe u verbinding maakt met Azure Storage met behulp van een opslagaccountsleutel. Veel ontwikkelaars trekken zich aan bij deze oplossing, omdat het bekend is met opties waarmee ze in het verleden hebben gewerkt, ook al is het geen ideale oplossing. Als uw toepassing momenteel toegangssleutels gebruikt, kunt u overwegen om te migreren naar verbindingen zonder wachtwoord.
// Connection using secret access keys
BlobServiceClient blobServiceClient = new(
new Uri("https://<storage-account-name>.blob.core.windows.net"),
new StorageSharedKeyCredential("<storage-account-name>", "<your-access-key>"));
Ontwikkelaars moeten ijverig zijn om deze typen sleutels of geheimen nooit beschikbaar te maken op een onbeveiligde locatie. Veel bedrijven hebben strikte beveiligingsvereisten om verbinding te maken met Azure-services zonder wachtwoorden beschikbaar te stellen aan ontwikkelaars, operators of anderen. Ze gebruiken vaak een kluis om wachtwoorden in toepassingen op te slaan en te laden en het risico verder te verminderen door vereisten en procedures voor wachtwoordrotatie toe te voegen. Deze aanpak verhoogt op zijn beurt de operationele complexiteit en leidt soms tot storingen in de toepassingsverbinding.
Verbindingen zonder wachtwoord en Zero Trust
U kunt nu verbindingen zonder wachtwoorden in uw apps gebruiken om verbinding te maken met Azure-services zonder dat u wachtwoorden hoeft te roteren. In sommige gevallen hoeft u alleen maar te configureren. Er is geen nieuwe code vereist. Zero Trust maakt gebruik van het principe 'nooit vertrouwen, altijd verifiëren en referentiesvrij'. Dit betekent dat alle communicatie wordt beveiligd door computers of gebruikers alleen te vertrouwen nadat de identiteit is geverifieerd en voordat ze toegang krijgen tot back-endservices.
De aanbevolen verificatieoptie voor beveiligde, wachtwoordloze verbindingen is het gebruik van beheerde identiteiten en op rollen gebaseerd toegangsbeheer van Azure (RBAC) in combinatie. Met deze aanpak hoeft u niet handmatig veel verschillende geheimen voor beheerde identiteiten bij te houden en te beheren, omdat deze taken intern door Azure veilig worden afgehandeld.
U kunt wachtwoordloze verbindingen met Azure-services configureren met behulp van Service Verbinding maken or of u kunt ze handmatig configureren. Service Verbinding maken or maakt beheerde identiteiten mogelijk in app-hostingservices zoals Azure Spring Apps, Azure-app Service en Azure Container Apps. Service Verbinding maken or configureert ook back-endservices met verbindingen zonder wachtwoord met beheerde identiteiten en Azure RBAC en hydrateert toepassingen met de benodigde verbindingsgegevens.
Als u de actieve omgeving van een toepassing inspecteert die is geconfigureerd voor verbindingen zonder wachtwoord, ziet u de volledige verbindingsreeks. De verbindingsreeks bevat bijvoorbeeld een databaseserveradres, een databasenaam en een instructie voor het delegeren van verificatie aan een Azure-verificatie-invoegtoepassing, maar bevat geen wachtwoorden of geheimen.
In de volgende video ziet u verbindingen zonder wachtwoord van apps naar Azure-services, met behulp van Java-toepassingen als voorbeeld. Soortgelijke dekking voor andere talen wordt binnenkort geopend.
Inleiding tot DefaultAzureCredential
Verbindingen zonder wachtwoord met Azure-services via Microsoft Entra ID en op rollen gebaseerd toegangsbeheer (RBAC) kunnen worden geïmplementeerd met behulp DefaultAzureCredential van de Azure Identity-clientbibliotheken.
Belangrijk
Sommige talen moeten expliciet in hun code worden geïmplementeerd DefaultAzureCredential , terwijl andere intern worden gebruikt DefaultAzureCredential via onderliggende invoegtoepassingen of stuurprogramma's.
DefaultAzureCredential ondersteunt meerdere verificatiemethoden en bepaalt automatisch welke tijdens runtime moet worden gebruikt. Met deze aanpak kan uw app verschillende verificatiemethoden gebruiken in verschillende omgevingen (lokale ontwikkelomgeving versus productie) zonder omgevingsspecifieke code te implementeren.
De volgorde en locaties waarin DefaultAzureCredential wordt gezocht naar referenties verschillen per taal:
Wanneer u bijvoorbeeld lokaal werkt met .NET, DefaultAzureCredential wordt doorgaans geverifieerd met het account dat de ontwikkelaar heeft gebruikt om zich aan te melden bij Visual Studio, Azure CLI of Azure PowerShell. Wanneer de app wordt geïmplementeerd in Azure, DefaultAzureCredential detecteert en gebruikt u automatisch de beheerde identiteit van de gekoppelde hostingservice, zoals Azure-app Service. Er zijn geen codewijzigingen vereist voor deze overgang.
Notitie
Een beheerde identiteit biedt een beveiligingsidentiteit die een app of service vertegenwoordigt. De identiteit wordt beheerd door het Azure-platform en vereist niet dat u geheimen inricht of roteert. Meer informatie over beheerde identiteiten vindt u in de overzichtsdocumentatie .
In het volgende codevoorbeeld ziet u hoe u verbinding maakt met Service Bus met behulp van verbindingen zonder wachtwoord. In andere documentatie wordt beschreven hoe u naar deze installatie voor een specifieke service migreert. Een .NET-app kan een exemplaar doorgeven aan DefaultAzureCredential de constructor van een serviceclientklasse. DefaultAzureCredential detecteert automatisch de referenties die beschikbaar zijn in die omgeving.
ServiceBusClient serviceBusClient = new(
new Uri("https://<your-service-bus-namespace>.blob.core.windows.net"),
new DefaultAzureCredential());
Zie ook
Zie de ontwikkelaarshandleiding voor het configureren van verbindingen zonder wachtwoord tussen meerdere Azure-apps en -services voor een gedetailleerdere uitleg over verbindingen zonder wachtwoord.