it-swarm.com.de

Sicheres Speichern von Anwendungsgeheimnissen unter Linux

Ich habe eine Linux-Anwendung, die ein Geheimnis lesen muss, um einige Daten zu entschlüsseln. Die Anwendung ermöglicht es den Benutzern auch, das Verschlüsselungskennwort zur Laufzeit zu ändern. Die Anwendung wird unter einem separaten Benutzerkonto ausgeführt und das Geheimnis befindet sich derzeit in einer Datei, die diesem Benutzer gehört. Ich versuche Möglichkeiten zu finden, um diese Situation zu verbessern, da das Passwort in einer Datei im Klartext vorliegt.

Die Anwendung kann als root gestartet werden und dann dem Anwendungsbenutzer Berechtigungen übertragen. Auf diese Weise kann die geheime Datei root gehören, aber dann bricht das Szenario zur Kennwortänderung ab, es sei denn, ich führe einen anderen Daemon als root aus.

Ich versuche im Grunde zu verhindern, dass das Geheimnis im Klartext auf der Festplatte und ohne einen Menschen in der Schleife zu bootstrap der Verschlüsselung) ist. Das Beste, was getan werden kann, ist, es schwieriger zu machen Holen Sie sich das Geheimnis, auch wenn jemand Code-Ausführung bekommt.

Kann jemand Vorschläge machen, wie ich die aktuelle Situation verbessern kann? Ist keyctl hier anwendbar oder wird es normalerweise nur zum Speichern von Kernel-Geheimnissen verwendet?

Anregungen werden geschätzt!

10
johne

Ihr Dienst sollte im Allgemeinen nicht als root ausgeführt werden. Die Verwendung eines separaten Benutzers zum Speichern des Geheimnisses ist eine kluge Vorsichtsmaßnahme, aber das Speichern von Dateien mit root Besitz ist aus Gründen der Geheimhaltung nicht besser als die Verwendung eines anderen dedizierten Benutzers. Solange Ihre geheime Datei Berechtigungen hat 600 oder weniger ist sicher vor anderen Nicht-root Benutzern. Alles, was root ausführt, hat sowieso vollen Zugriff. (es sei denn, Sie führen ein komplexes SELinux-Setup aus)

Es kann hilfreich sein, zwei Benutzer verwenden für diese einzelne Anwendung, um die geheime Verwaltung vom normalen Betrieb zu isolieren. Entweder haben zwei Daemons, die mit Echtzeitkommunikation ausgeführt werden, oder Sie haben Dienstprogrammbefehle, um das Geheimnis zu verarbeiten und über Sudo die erforderlichen Berechtigungen (benutzer- oder gruppenbasiert) zu erhalten.

Sie sollten mögliche Angriffsvektoren berücksichtigen.

  • Wenn SQLi ordnungsgemäß konfiguriert ist, wird kein Dateisystemzugriff gewährt, Path Traversal-Angriffe jedoch. Es gibt andere Arten von Angriffen auf Ihre Anwendung, gegen die Sie sich schützen sollten.

  • Exploits in C-Bibliotheken (d. H. OpenSSL, auf dem Ihre HTTPS-Verschlüsselung, Bildverarbeitung usw. ausgeführt wird) ist möglicherweise möglich. Die Verwendung eines getrennten Benutzers für netzwerkfähige Prozesse kann dazu beitragen, den Umfang einzuschränken oder einem Angriff Schwierigkeiten zu bereiten.

  • Einbrüche von anderen Angriffsmethoden könnten ein Problem sein. (SSH, andere Dienste auf dem Computer) Stellen Sie sicher, dass alles, was den Zugriff auf root ermöglicht, gut gesichert ist.

All diese Überlegungen sollen Ihnen helfen, das Geheimnis selbst zu sichern. Nun ist die Frage, muss das Geheimnis wirklich in der Ebene gespeichert werden ?

Auf der einfachsten Ebene muss das Geheimnis irgendwo gespeichert werden, damit es verwendet werden kann. Es muss zumindest im Speicher gespeichert werden, aber es ist auch eine dauerhafte Speicherung erforderlich.

Abgesehen von der von uns diskutierten Benutzertrennung kann es hilfreich sein, Geheimnisse auf einen separaten Hardware-Sicherheitsmodul oder sogar einen separaten Mini-Computer zu laden. (d. h. Raspberry Pi) Es gibt einige Diskussionen über physikalische Trennung hier .

Es gibt nur sehr wenige Fälle, in denen das Geheimnis selbst dauerhaft verschlüsselt werden kann.

Wenn Ihr Problem der Festplattendiebstahl ist (der Rest des Computers bleibt zurück), können Sie ein Startskript haben, das einige der anderen Hardware nach eindeutigen Kennungen abfragt und eine Verschlüsselung ableitet Schlüssel mit einer guten kennwortbasierten Schlüsselableitungsfunktion; das Geheimnis entschlüsseln.

Wenn der Kunde einen Teil des Geheimnisses bereitstellen kann, wäre dies hilfreich. Ich habe einen Weg skizziert, um Entschlüsselungsschlüssel von Benutzerkennwörtern und Sitzungstoken hier abzuleiten . Dies ist ein ausgeklügeltes und dennoch effektives System, das sich darauf konzentriert, die Zeitspanne zu begrenzen, in der ein Geheimnis gespeichert wird, selbst im Speicher. (vorausgesetzt, Sie benötigen kein automatisches Zurücksetzen des Passworts)

4
Bryan Field

Was Sie haben, ist die traditionelle Art, Dinge zu tun. So empfiehlt Tomcat dies beispielsweise mit OWASP übereinstimmend . Also, was du hast, ist nicht schlecht.

Es gibt jedoch auch andere Möglichkeiten: Hardware-Sicherheitsmodule sind Speicher mit beschränktem Zugriff, die für die Schlüsselspeicherung ausgelegt sind. Hashicorps Vault, KeyWhiz und ähnliche Technologien sind geheime Managementsysteme, die im Grunde genommen versuchen, Software-HSMs zu sein. Natürlich müssen alle diese Technologien in der Lage sein, den Prozess zu authentifizieren - ihr Vorteil ist, dass sie eine Vielzahl von Mechanismen dafür haben. Sie können root verwenden, um Zugriff auf einen Schlüssel zu erhalten, der dann nur dem Webbenutzer im Speicher bereitgestellt wird. Mit diesem Schlüssel können Sie auf HSM/Vault/KeyWhiz zugreifen, um auf den eigentlichen Schlüssel zugreifen und ihn ändern zu können. Es gibt auch andere Mechanismen - AWS-spezifische, die EC2-Schlüssel verwenden, eine Reihe anderer. Möglicherweise finden Sie etwas, das gut ineinander greift.

Meine persönliche Meinung ist, dass der bewährte eingeschränkte Benutzer (der NUR für diesen Zweck verwendet wird) und Dateien, die nur auf diesen Benutzer beschränkt sind, kein schlechter Weg ist. Es lässt sich jedoch nicht so gut skalieren, wo andere Optionen möglich sind.

1
crovers

Wenn das Geheimnis auf eine Weise auf dem Server gespeichert ist, die von der Anwendung ohne menschliches Eingreifen gelesen werden kann, kann es zumindest von root auf dem Computer gelesen werden.

Es spielt keine Rolle, dass die Datei im Klartext vorliegt. Es kann nur durch Berechtigungen geschützt werden und root kann diese Berechtigungen umgehen. Das Verschlüsseln der Datei (oder des Dateisystems, in dem sie sich befindet) hilft nur, wenn der Verschlüsselungsschlüssel nur dem Prozess zum Lesen der Datei zur Verfügung gestellt wird und dies einen externen Eingriff (und eine Überprüfung) erfordert. Sie verschieben nur das Problem des Zugriffs auf das Geheimnis woanders hin.

Selbst wenn Sie die Kontrolle über alle Konten auf dem System behalten - als Appliance erstellen - bleibt das Problem des physischen Zugriffs auf das System bestehen. Wenn Sie zufrieden sind, dass die physische Integrität gewährleistet werden kann, haben Sie das Problem, das System als Appliance zu warten. Wie werden Patches installiert?

Ich bin weit davon entfernt, davon überzeugt zu sein, dass ein hsm selbst in Hardware eine völlig sichere Lösung bietet, anstatt den normalen Zugriff übermäßig aufwändig zu gestalten (während er gleichzeitig den unbefugten Zugriff kompliziert, aber nicht verhindert).

Angesichts der Tatsache, dass jede Lösung einen Kompromiss in Bezug auf Ihre Erwartungen darstellen würde, müssten Sie die Einschränkungen (Entwicklungskosten, Stückkosten, erwartetes Volumen) genauer kennen und das Thret-Modell detaillierter beschreiben.

1
symcbean