Verschlüsselte Offsite-Sicherung mit GPG mit privatem Schlüssel nie auf Sicherungsserver?

Ich habe einen Sicherungsserver, der xzkomprimierte tarArchive von Verzeichnisbäumen erstellt, die gesichert werden sollen. Diese Teerarchive können sehr groß werden (mehrere TBs), sind splitin Stücke (2,5 TB) unterteilt, und jedes Stück wird auf ein LTO-6-Band geschrieben, und die Bänder werden außerhalb des Standorts abgelegt.

Jetzt möchte ich die Verschlüsselung hinzufügen. Ich kann das Tar-Archiv vor dem Teilen mit GPG verschlüsseln, indem ich die Verschlüsselung mit öffentlich-privaten Schlüsseln verwende und mit einem oder mehreren Empfängern (öffentliche Administratorschlüssel).

Im Falle einer Wiederherstellung muss jedoch mindestens ein Administrator seinen privaten Schlüssel auf dem Sicherungsserver ablegen, da die Dateien zu groß sind, um irgendwo anders entpackt zu werden.

GPG verwendet ein hybrides Verschlüsselungsschema unter der Haube mit einer symmetrischen Verschlüsselung wie AES mit einem Sitzungsschlüssel, und nur dieser Sitzungsschlüssel wird für die Empfänger öffentlich-privat verschlüsselt.

Gibt es eine Möglichkeit, einen Administrator den Sitzungsschlüssel zum Entschlüsseln der wiederherzustellenden Datei bereitstellen zu lassen, ohne den privaten Schlüssel auf den Sicherungsserver zu legen ?

Ich könnte das Rad natürlich neu erfinden:

• Erstellen Sie für jede zu sichernde Datei einen zufälligen Sitzungsschlüssel auf dem Sicherungsserver
• Verwenden Sie die symmetrische GPG-Verschlüsselung, um die Datei zu verschlüsseln
• Verwenden Sie die asymmetrische GPG-Verschlüsselung, um den Sitzungsschlüssel für jeden Empfänger zu verschlüsseln

Aber gibt es einen "Standard" oder eine eingebaute oder bewährte Methode, um dies zu erreichen?

Dies ist mit den Optionen --show-session-keyund definitiv möglich --override-session-key.

Zuerst benötigen Sie den Anfang Ihrer verschlüsselten Datei. Hier wird der verschlüsselte Sitzungsschlüssel gespeichert.

root@qwerty:~/gpg# head -c 1024k bigfile.gpg > head.gpg

Kopieren Sie es dann auf Ihre Workstation und rufen Sie den Sitzungsschlüssel ab

PS C:\Users\redacted\Downloads> gpg --show-session-key .\head.gpg
gpg: encrypted with 2048-bit RSA key, ID DC21D645, created 2016-02-01
  "admin <admin@domain.tld>"
gpg: session key: '9:926EC16DF1248A1C4401F5AD5D86C63C1BD4BF351ECEFB121C57EC209DE3933D'

Jetzt können Sie die Datei mit Ihrem Sitzungsschlüssel entschlüsseln

root@qwerty:~/gpg# gpg -d -o bigfile --override-session-key 9:926EC16DF1248A1C4401F5AD5D86C63C1BD4BF351ECEFB121C57EC209DE3933D bigfile.gpg
gpg: encrypted with 2048-bit RSA key, ID DC21D645, created 2016-02-01
  "admin <admin@domain.tld>"

Es sieht so aus, als ob der größte Teil Ihrer Frage beantwortet wurde. Wenn Ihr Administratorteam jedoch Bedenken hat, dass private Schlüssel außerhalb der lokalen Kontrolle landen, sollten Sie in Betracht ziehen sshfs, die Remote-Backups über eine SSH-Sitzung bereitzustellen.

Installation über apt auf dem System jedes Remote-Administrators

sudo apt-get install sshfs

Angenommen, die SSH-Konfiguration der Administratoren sieht wie folgt aus

# configuration for ssh login to remote server
Host Remote
    Hostname Remote.web.domain
    User admin
    IdentityFile ~/.ssh/private.key

Dann können Ihre Administratoren etwas wie das Folgende für die Montage verwenden

# make a mount point
mkdir -p /mnt/remote
# mount remote directory to local file system
sshfs Remote:/path/to/encrypted/dir /mnt/remote

Um die Bereitstellung nach der Überprüfung aufzuheben, kann der Remote-Administrator Folgendes verwenden

fusermount -u /mnt/remote

Das Schöne an der Verwendung von sshfs ist, dass nur öffentliche Schlüssel für GnuPG und ssh auf dem Remote-Server benötigt werden. Die zugehörigen privaten Schlüssel verbleiben auf den Systemen, die sie besitzen. Das zweite nette bisschen ist, dass die meisten Dateiinformationen bis zum Lesen oder Zugreifen im zugehörigen Dateisystem verbleiben.

Wenn Sie immer noch nach Tools suchen, die die automatische Verschlüsselung von Protokollen oder Verzeichnissen erleichtern, sollten Sie das Prof-of-Concept-Tool überprüfen, das ich an GitHub gesendet habe (insbesondere Szenario 4, das für die sshsfVerwendung geschrieben wurde), das mit ein wenig Anpassung fast alle problemlos verschlüsselt Daten über GnuPG. Seien Sie jedoch gewarnt, dass es experimentell ist und einige seiner Funktionen bei Missbrauch zu einer Beschädigung der Daten führen können. Der Quellcode besteht aus weniger als ~ 1600 ~ Zeilen, sodass eine Prüfung in weniger als einem Wochenende möglich ist.

Zusätzliche Sicherheit erhalten Sie, indem Sie die SSH-Konfiguration des Remote-Servers so einrichten, dass Benutzer nur den Zugriff auf das verschlüsselte Verzeichnis zulassen und die interaktive Shell für Administratorschlüssel deaktivieren, die auf diese Weise verwendet werden.

Wenn Sie möchten, dass der geheime Schlüssel von den Festplatten ferngehalten wird, können Sie eine Ramdisk erstellen (erinnern Sie sich an diese?) Und die geheimen Schlüssel dort nach Bedarf von Ihrem sicheren Speicherort auf dem Server laden. Verwenden Sie es zum Entschlüsseln und überschreiben Sie es anschließend mit / dev / random. Das Geheimnis muss in den Arbeitsspeicher gehen, um von GPG verwendet zu werden. Warum also nicht zweimal?

Wenn Sie nicht zulassen können, dass sich jemals ein geheimer Schlüssel auf dem Server befindet, auch nicht im RAM, haben Sie eine technische Unmöglichkeit. GPG muss irgendwo den geheimen Schlüssel haben, um etwas entschlüsseln zu können.

Ramdisk-Informationen: /unix/66329/creating-a-ram-disk-on-linux