Sicherheitsrelevante Daten in .NET richtig schützen – Kein Platz für Hardcoding

Sensiblen Daten wie Passwörtern, API Keys, Tokens oder Verschlüsselungs-Keys kommen in modernen Anwendungen eine zentrale Rolle zu. Sie schützen Zugänge, sichern Nutzerdaten und verhindern unbefugte Zugriffe. In der Entwicklung ist ein sicherer Umgang mit diesen Daten essenziell und sollte von Anfang an in jedem Projekt berücksichtigt werden.

Hardcoding solcher Informationen im Source Code ist dabei ein häufiger Fehler, der schwerwiegende Sicherheitsrisiken birgt. Stattdessen sollten bewährte Methoden und Tools wie User Secrets, Azure Key Vault oder die Data Protection API genutzt werden, um sensible Daten sicher zu speichern und zu verwalten. Dieser Artikel zeigt dir, wie du diese Technologien effektiv einsetzt, um Sicherheitslücken zu vermeiden und deine Anwendungen zu schützen.

Das Problem mit den hart codierten Daten

Eine der größten Gefahren lauert im Hardcoding von Secrets direkt im Quellcode. Was auf den ersten Blick bequem erscheint, wird schnell zum Problem. Code wird in Versionskontrollsystemen wie Git gespeichert. Selbst private Repositories können versehentlich öffentlich werden oder von Unbefugten eingesehen werden.

// Hartcodierter API-Schlüssel
const string apiKey = "12345-abcde-67890-fghij";

using var client = new HttpClient();
client.DefaultRequestHeaders.Add("Authorization", $"Bearer {apiKey}");
var response = await client.GetAsync("https://api.example.com/data");

Sensible Informationen direkt im Code zu speichern birgt das Risiko, dass sie dauerhaft in der Historie der Versionsverwaltung erhalten bleiben. Selbst wenn die Historie nachträglich gelöscht oder angepasst wird, können diese Daten weiterhin in Backups, Forks oder auf den Rechnern anderer Entwickler:innen existieren – insbesondere bei verteilten Versionsverwaltungssystemen wie Git.

Außerdem können Angreifer durch einfaches Reverse Engineering kompilierten Code nach eingebetteten Secrets durchsuchen. Es zeigt sich immer wieder, dass hart codierte Daten gefunden werden, egal wie tief sie versteckt oder welche eigenen Versuche genutzt werden, um Secrets zu verstecken oder zu verschleiern. Bedenkt immer: Security by Obscurity ist verbreitet, aber nicht Best Practice.

// Eigenes Verschleierungsverfahren
string obfuscatedSecret = "U2VjcmV0MTIz";

string DecodeSecret(string encodedSecret)
{
  var base64EncodedBytes = Convert.FromBase64String(encodedSecret);
  return System.Text.Encoding.UTF8.GetString(base64EncodedBytes);
}

string secret = DecodeSecret(obfuscatedSecret);

Ein zentraler Vorteil der Auslagerung sensibler Daten besteht darin, dass sie bei Bedarf einfach aktualisiert und idealerweise automatisch rotiert werden können, beispielsweise durch den regelmäßigen Austausch von Passwörtern oder ähnlichen Sicherheitsinformationen.

Sicherheitsdaten richtig verwalten

Statt sensible Daten in Konfigurationsdateien oder Code abzulegen, sollten Entwickler:innen von Beginn an auf sichere Speicherlösungen setzen. Konfigurationsdateien wie appsettings.json sollten zwar genutzt werden, aber nur für unkritische Konfigurationen oder für Referenzen auf geschützte Speicherorte. Jede zusätzliche Datei oder Variable, die ungeschützt ist, vergrößert die Angriffsfläche und erhöht den Aufwand bei Audits und Sicherheitsprüfungen. Daher lohnt es sich, eine saubere Trennung frühzeitig umzusetzen. .NET bietet bereits ab Werk starke Mechanismen, um Secrets sicher zu verwalten.

Für die lokale Entwicklung eignet sich der User Secrets Configuration Provider hervorragend. Es speichert geheime Konfigurationsdaten außerhalb des Projektverzeichnisses, getrennt vom Quellcode. So bleibt der Code sauber und die Secrets bleiben lokal geschützt. Beim Deployment sollten Umgebungsvariablen genutzt werden. Sie ermöglichen es, sensible Daten bereitzustellen, ohne sie in Dateien oder Code zu hinterlegen. Besonders bei Cloud Deployments oder Container Szenarien ist diese Methode etabliert. Wer Projekte aufbaut, sollte die Anwendung so gestalten, dass Secrets bevorzugt aus Key Vault oder Umgebungsvariablen geladen werden. User Secrets sollten ausschließlich für lokale Entwicklungsumgebungen reserviert bleiben.

Für produktive Systeme empfiehlt sich die Nutzung von Azure Key Vault. Dieser Dienst ermöglicht eine zentrale Verwaltung von Secrets, Schlüsseln und Zertifikaten und bietet eine tiefe Integration in Azure basierte Workloads. Viele Azure Services wie z.B. der Azure App Service bieten die Möglichkeit, die Konfiguration über Umgebungsvariable direkt aus einem Key Vault Secret bereitzustellen.

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret)

Die Authentifizierung erfolgt dabei über die Managed Identity des Azure Services. Hierbei muss beachtet werden, dass die Managed Identity über die nötigen Berechtigungen im Key Vault verfügt.

Wer on-prem unter Windows und nicht in der Cloud unterwegs ist, für den eignet sich die Data Protection API von .NET. Diese abstrahiert die native Windows Funktionalität, um sensible Daten sicher zu verschlüsseln und zu speichern. Sie nutzt Betriebssysteminformationen wie Benutzer- oder Maschinenidentitäten zur Schlüsselgenerierung. Dadurch entfällt die komplexe Verwaltung eigener Schlüssel und die Daten bleiben trotzdem sicher. Besonders bei temporären Tokens oder internen Konfigurationsdaten bietet die Data Protection API eine zuverlässige und wartungsarme Lösung. Es zeigt sich immer wieder, dass eigene kryptografische Lösungen fehleranfällig sind. Daher sollte man sich auf etablierte Frameworks verlassen, die Security by Design mitbringen.

// Beispiel für die Verwendung der Data Protection API
using Microsoft.AspNetCore.DataProtection;

private static string Protect(string str)
{
    byte[] data = Encoding.UTF8.GetBytes(str.ToString());
    byte[] entropy = Encoding.UTF8.GetBytes(Assembly.GetExecutingAssembly().FullName);
    return Convert.ToBase64String(ProtectedData.Protect(data, entropy, DataProtectionScope.CurrentUser));
}

private static string Unprotect(string str)
{
    byte[] protectedData = Convert.FromBase64String(str);
    byte[] entropy = Encoding.UTF8.GetBytes(Assembly.GetExecutingAssembly().FullName);
    return Encoding.UTF8.GetString(ProtectedData.Unprotect(protectedData, entropy, DataProtectionScope.CurrentUser));
}

Zertifikate in .NET-Anwendungen richtig einsetzen

Zertifikate bieten zusätzliche Sicherheit auf mehreren Ebenen. Sie kommen zum Einsatz bei der Verschlüsselung von Daten während der Übertragung oder Speicherung und dienen der Authentifizierung von Clients und Servern. In .NET lassen sich Zertifikate einfach über den Windows Certificate Store verwalten, der für geschützte und zentrale Speicherung sorgt.

Der Windows Certificate Store bietet mehrere Vorteile gegenüber der lokalen Speicherung von Zertifikaten mit der Anwendung. Zum einen sorgt er für eine sichere und zentralisierte Verwaltung, die den Zugriff auf Zertifikate auf autorisierte Benutzer oder Prozesse beschränkt. Zum anderen schützt er private Schlüssel durch die Integration mit dem Betriebssystem, wodurch sie nicht im Klartext auf der Festplatte gespeichert werden. Dies reduziert das Risiko, dass Zertifikate durch versehentliche Offenlegung oder Angriffe kompromittiert werden.

Besonders in komplexen Systemen mit vielen Komponenten ist die saubere Verwaltung von Zertifikaten essenziell. Fehler in der Zertifikatskette oder in der Konfiguration können sonst ganze Anwendungen angreifbar machen. Es lohnt sich, die Zertifikatsverwaltung frühzeitig zu planen und auch die Gültigkeit der Zertifikate zu prüfen. Auch die Gültigkeit der Zertifikatskette sollte regelmäßig überprüft werden, falls eines Zertifikate in der Kette zurückgezogen wird oder für ungültig erklärt wird.

// Beispiel: Zugriff auf ein Zertifikat aus dem Windows-Zertifikatspeicher mit privatem Passwort
using System.Security.Cryptography.X509Certificates;

string certificateThumbprint = "YOUR_CERTIFICATE_THUMBPRINT";

// Zugriff auf den Zertifikatspeicher
using var store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);

// Zertifikat anhand des Thumbprints suchen
var certificate = store.Certificates.Find(X509FindType.FindByThumbprint, certificateThumbprint, validOnly: false)[0];
var privateKey = certificates[0].GetRSAPrivateKey();
var now = DateTime.Now;

if (now < certificate.NotBefore || certificate.NotAfter < now)
{
  throw new SecurityException("Das Zertifikat ist abgelaufen oder noch nicht gültig.");
}

Die Sicherheit von Anwendungen beginnt nicht erst nach dem Deployment, sondern schon in den ersten Zeilen Code. Hart codierte Secrets sind vermeidbare Risiken, die sich leicht durch den Einsatz von Secret Management, Umgebungsvariablen und verschlüsselten Speichern verhindern lassen. Tools wie User Secrets, Azure Key Vault und die Data Protection API bieten in .NET-Projekte starke Unterstützung, um Sicherheitsstandards einzuhalten und Risiken zu minimieren. Zertifikate ergänzen den Schutz bei Verschlüsselung und Authentifizierung. Entwickler:innen, die diese Werkzeuge konsequent nutzen und Sicherheit als festen Bestandteil ihres Prozesses betrachten, legen die Basis für robuste und vertrauenswürdige Anwendungen.

Wie man hart kodierte Daten im Code automatisiert findet, um direkt zu vermeiden, dass diese in die Codebase kommen, schauen wir uns im nächsten Artikel an.

Welche Best Practices wendest du beim Umgang mit Secrets in .NET an und welche Tools helfen dir dabei am meisten? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.