Azure - Verbindungszeichenfolge in Key Vault im Vergleich zu Anwendungseinstellungen


8

Gibt es für Azure-Funktionen und WebJobs einen Vorteil darin, Verbindungszeichenfolgen als Geheimnisse in Key Vault einzufügen, anstatt sie direkt in den Anwendungseinstellungen abzulegen (und sie mit ConfigurationManager.ConnectionStrings zu referenzieren)? Sind Azure Key Vault-Geheimnisse in erster Linie für VMs und dergleichen gedacht und nicht für Azure-Funktionen und WebJobs?

Es scheint, als würde nur ein zusätzlicher Schritt in der Entwicklung (Aktualisierung des Geheimnisses in Key Vault und der geheimen Kennung in den Anwendungseinstellungen) und ein zusätzlicher Schritt in der Laufzeit (zusätzlicher Abruf aus Key Vault) hinzugefügt, wobei der einzige Vorteil darin besteht, dass das Geheimnis In den Anwendungseinstellungen befindet sich eine Kennung anstelle des eigentlichen Geheimnisses. Ich sehe den Sicherheitsvorteil hier nicht, obwohl es Nachteile gibt.


Das ist super cool, um Ihre öffentliche Datenbank Verbindungszeichenfolge bei einem Fehler Push auf Github zu geben :) (Wenn Sie wirklich einen Grund brauchen)
Tensibai

Ich sehe nicht ein, wie das passieren würde. Ich spreche von der Verbindungszeichenfolge in den Anwendungseinstellungen, die in der Cloud gespeichert ist und niemals die Codebasis berührt.
Anonymous1

Solange dies in der Cloud erfolgt, da GUI-Interaktionen in Ordnung sind, wechseln Sie zu reinem IaC, wo Ihre gesamte Cloud-Konfiguration als Code erfolgt. Dies wird eines Tages geschehen. Dies ist der Hauptgrund für die Verwendung eines Tresors. Wenn Sie es nicht für notwendig halten, verwenden Sie es nicht ...
Tensibai

Ja, es ist nur so, dass der Secret Identfier genauso sicher / unsicher erscheint wie die DB-Verbindungszeichenfolge. Sie müssen entweder beide oder keine ändern.
Anonymous1

Hu .. nicht wirklich, etwas mit dem Namen 'DB_Cx_String', auf das in der App-Einstellung verwiesen wird, ist weniger problematisch als beispielsweise 'jdbc: // host: port / DBname'.
Tensibai

Antworten:


9

Die Vorteile, wie ich sie sehe, sind die allgemeinen Gründe für die Verwendung von Azure Key Vault

  • Geheimnisse werden zentral mit Optionen für Autorisierung, Prüfung usw. gespeichert.
  • Azure kann per Skript erstellt werden, um die Geheimnisse eines Timers zu aktualisieren. Wenn also eine Verbindungszeichenfolge in die falschen Hände gelangt, ist sie nur für einen Tag (oder eine Woche oder was auch immer) gültig.
  • Wenn das Geheimnis von mehreren Anwendungen gemeinsam genutzt wird, müssen Sie es nur an einer Stelle aktualisieren (nicht der größte Vorteil, aber dennoch hilfreich).

1
Es scheint mir, dass Sie sagen, dass der Schlüsseldepot nur dann nützlich ist, wenn mehrere App-Server die gleichen Geheimnisse teilen. Wenn die Verbindungszeichenfolge von einem einzelnen App-Server verwendet wird, hat der Schlüsseldepot keinen Vorteil.
John Henckel

3

Ich bin der gleichen Meinung wie Sie, ich sehe keinen Sinn darin, den Schlüsseltresor in solchen Szenarien zu verwenden.

Stattdessen verwende ich die Azure-App-Konfiguration https://docs.microsoft.com/en-us/azure/azure-app-configuration/overview , in der ich einfach alle Anwendungseinstellungen speichere. Die einzige Zeichenfolge, die ich zusammen im eigentlichen App-Dienst / Funk / Web-Job speichere, ist die Verbindungszeichenfolge für den Zugriff auf die Azure-App-Konfiguration.

In meinem Start, in dem die Konfigurationseinstellungen angewendet werden, lese ich entweder aus ..settings.json und suche, falls nicht vorhanden (was bei Azure nicht der Fall sein sollte), nach der Verbindungszeichenfolge zur Azure-App-Konfiguration.

Wenn ..settings.json gefunden wird, bedeutet dies, dass ich lokal ausgeführt werde.

..settings.json wird verschlüsselt, wenn es sich nicht in der Gitignore-Datei befindet.

Es sieht ungefähr so ​​aus:

var appConfigEndpoint = Environment.GetEnvironmentVariable("AppConfigEndpoint");
            var appConfigLabel = Environment.GetEnvironmentVariable("AppConfigLabel");

            if (!string.IsNullOrEmpty(appConfigEndpoint))
            {
                config.AddAzureAppConfiguration(options =>
                {
                    options.Connect(appConfigEndpoint);
                    options.Use(keyFilter: "*", labelFilter: appConfigLabel);
                });
            }
            else
            {
                config.AddJsonFile("appsettings.test.json", optional: false);
            }

Ich bin zu spät, aber wenn Sie immer noch die gleiche Meinung haben, müssen Sie sie ändern. Die Konfiguration (Ihre Referenz) dient nicht zum Speichern von Geheimnissen, sondern zum Speichern der Konfiguration. Die DB-Verbindungszeichenfolge ist ein Geheimnis, keine Konfiguration. KeyVault dient zum Speichern von Geheimnissen. Die Konfiguration dient zum Speichern der Konfiguration in einem zentralen Speicher. Ich hoffe das macht Sinn
RAM

0

Das Abrufen des Schlüsseldepots kann ein Leistungsproblem sein. Das Lesen aus dem Schlüsseldepot dauert einige Sekunden. Das Azure SLA gibt nur an, dass es in 99,9% der Fälle weniger als 5 Sekunden dauert . Es garantiert nicht die durchschnittliche Zeit, aber nach meiner Erfahrung und meinem Hörensagen beträgt der Durchschnitt ungefähr 2 Sekunden.

Sofern Ihre Web-App nicht "immer aktiviert" ist, wird sie im Leerlauf für 5 bis 20 Minuten entladen. Das bedeutet, dass die Antwortzeiten Ihrer Website häufig schlecht sind, es sei denn, Sie haben viel Verkehr.


1
Sie können die meisten Anwendungsgeheimnisse nur einmal während des Anwendungsstarts abrufen.
Miroslav Holec

0

Wir planen, unten zu verwenden

Geheimnisse - Azure Key-Vault

  • Hauptschlüsselrotation für immer verschlüsselte Spalten
  • Zertifikatspeicher (kann problemlos einen Anbieter in .NET schreiben)
  • Sensible Elemente wie Verbindungszeichenfolgen (Verstecken anderer Ressourceninformationen), Kennwörter usw.

Konfigurationen - Azure App-Konfigurationen (noch in der Vorschau)

  • Watch ist eine wunderbare Methode zur Serviceerkennung, insbesondere wenn Sie Flags oder Werte für betriebliche Zwecke aktualisieren müssen.
  • Sie müssen einen Container oder eine Instanz nicht erneut initiieren.
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.