Ich lerne etwas über Umgebungsvariablen. Ich weiß zum Beispiel, dass ich ein geheimes Passwort nicht in meinen Code codieren sollte.
So wie ich es verstanden habe, ist ein.envDatei sollte zum Laden der Geheimnisse und Umgebungsvariablen verwendet werden.
Eine noch sicherere Möglichkeit zum Speichern der Variablen besteht darin, dies als CLI-Variablen zu tun, unter Verwendung desSatzBefehl.
Der Grund hierfür besteht darin, zu verhindern, dass Ihr Passwort und Ihre vertraulichen Daten unbefugten Personen zugänglich gemacht werden.
Nehmen wir nun an, ich erstelle eine Website, auf der einige API-Geheimnisse als CLI-Variablen gespeichert sind, und ein Hacker kann auf meinen Server zugreifen. Er könnte die API-Geheimnisse und Passwörter ganz einfach herausfinden, indem er einfach den Befehl eingibtdruckenvauf der CLI.
Welchen Vorteil bietet die Verwendung von CLI-Variablen gegenüber der Speicherung in einer .env-Datei? Wie kann ich sicherstellen, dass diese Variablen auch für fremde Benutzer verborgen bleiben?
Antwort1
Eine noch sicherere Möglichkeit zum Speichern der Variablen besteht darin, dies als CLI-Variablen mit dem Befehl „Set“ zu tun.
Nein, das ist es nicht. Erstens funktioniert der Befehl nicht wirklichspeichernsie überall persistent zu machen; und das andere, wichtigere an tatsächlichen Umgebungsvariablen ist, dass sie das genaue Gegenteil von sicherem Speicher sind. Ihre gesamte Funktionalität basiert aufjeder ProzessErhalten einer kostenlosen Kopie aller Umgebungsvariablen – wenn Sie beispielsweise setxunter Windows verwenden, um die Variablen dauerhaft zu speichern, erhält buchstäblich jede App oder jedes Tool, das Sie ausführen, danach automatisch eine Kopie, unabhängig davon, ob sie danach gefragt wurde oder nicht.
Wenn Sie Dateien verwenden sehen .env, werden sie normalerweise entweder nur in die Umgebung der Webanwendung geladen oder überhaupt nicht als Umgebungsvariablen verwendet (sie ahmen nur die bekannte API nach, laden die Variablen aber tatsächlich in ein einfaches altes Dict/Array). Im ersten Fall wären die Variablen immer noch für Programme verfügbar, die direkt von der Webanwendung erstellt werden, aberniemalsfür Ihre reguläre SSH-CLI verfügbar gemacht – obwohl sie immer noch „Umgebungsvariablen“ genannt werden, ist das nicht die beabsichtigte Verwendung.
(Die App selbst hat natürlich weiterhin Zugriff darauf – schließlich muss sie den API-Schlüssel kennen, um die API verwenden zu können, also ist das unvermeidlich. Befolgen Sie die empfohlenen Programmierpraktiken, um es weniger wahrscheinlich zu machen, dass ein Angreifer einen Weg findet, dies auszuführen printenv; geben Sie beispielsweise keine externen Eingaben wie Dateinamen direkt in Befehle ein.
Je nachdem, welche APIs Sie verwenden, ist es möglicherweise möglich, Ihre App in zwei Hälften aufzuteilen (ähnlich wie Microservices), sodass das Frontend nicht direkt auf die API zugreift, sondern immer über einen anderen Dienst läuft, der den API-Schlüssel kennt und dem Frontend nur die Ausführung ganz bestimmter Aufgaben erlaubt.)
Antwort2
Die Verwaltung von Geheimnissen/Passwörtern/Schlüsseln ist ein kompliziertes Spiel, bei dem man den Aufwand, den man betreiben möchte, mit dem Risiko, das es mit sich bringt, in Einklang bringen muss. Hier einige Beispiele:
- Über Befehlszeilenargumente übergebene Geheimnisse: Jeder Benutzer im System kann sie sehen
- Geheimnisse, die aus einer Text-/.env-Datei übergeben werden: Jeder Benutzer mit Lesezugriff auf die Datei kann sie stehlen. Wenn Sie CLI verwendenSatzBefehle, diese werden standardmäßig auch in Ihrem Befehlsverlauf angezeigt
- Von einem anderen Server geladene Geheimnisse: Die Anmeldeinformationen für den Zugriff auf diesen Server werden weiterhin lokal gespeichert
- Geheimnisse werden nur im Speicher gespeichert: Benutzer mit Root-Zugriff können auf Daten aus dem Rohspeicher zugreifen und diese sichern.
Wenn jemand Kontrolle über Ihren Server hat, kann er einfach Ihren Code ändern, um ihm die Passwörter trotzdem zu senden (eine gängige Methode, beispielsweise zum Stehlen von Kreditkarteninformationen).
Ich empfehle, primäre Geheimnisse nicht lokal im Klartext zu speichern, da es sehr einfach ist, Dateien einfach nach Passwörtern zu durchsuchen. Darüber hinaus liegt es an Ihnen. Einige gute Möglichkeiten zur Verbesserung der Sicherheit sind:
- Verwenden Sie einen verschlüsselten Schlüsselspeicher für lokale Geheimnisse: Durch das Hinzufügen eines weiteren Schritts zum Zugriff auf echte Passwörter können viele einfache Angriffe gestoppt werden.
- Verwenden Sie einen externen Server/Dienst zum Speichern von Geheimnissen, damit jemand, der nur lokalen Zugriff hat, nicht so leicht an alles kommt