Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:ansible:playbook_example_07 [23.09.2022 08:16. ] – [Tests] django
+++ linux:ansible:playbook_example_07 [22.07.2023 08:08. ] (aktuell) – [Tests] django
@@ Zeile 410: / Zeile 410: @@
 Als erstes befassen wir uns mit dem Standard UNIX Passwort-Manager **[[https://www.passwordstore.org/|pass]]**. Der Passwort-Manager **''pass''** haben wir ein einfach zu bedienendes wie auch strukturiertes Tool. Bei **''pass''** wird jedes Passwort in einer PGP-verschlüsselten Datei abgelegt, deren Dateiname der Titel der Website oder Ressource ist, für die das Passwort benötigt wird. Diese verschlüsselten Dateien können in sinnvollen Ordnerhierarchien organisiert, bei Bedarf von Host zu Host kopiert und im Allgemeinen mit Standard-Kommandozeilen-Dienstprogrammen für die Dateiverwaltung bearbeitet werden. Ferner kann der Passwortmanager einfach über sein **CLI** angesprochen und bedient werden.
-Bei der Nutzung von **''pass''** gehen wir davon aus, dass man bereits über einen eigneen PGP-Key verfügt und mit dessen Verwendung vertraut ist. Falls nicht, wird in diesem **[[centos:openpgp_beim_mua#openpgp_in_der_praxis|Kapitel]]** die Erstellung und Verwendung ausführlich beschrieben. Besonders sicherheitsbewussten Administratoren ist auch die Verwendung einer Kryptographie-Hardware z.B. eines **[[https://shop.nitrokey.com/de_DE/shop/product/nksa-nitrokey-start-6|Nitrokey Start]]** empfohlen. Die Erstellung von passenden Schlüsselmaterial wie ECDSA-basierten SSH-Schlüssel und PGP-Schlüssel ist z.B. in diesem **[[suse:nitrokey:start#nitrokey_start_und_gnupg|Kapitel in Djangos WIKI]]** ausführlich beschrieben und erklärt.
+Bei der Nutzung von **''pass''** gehen wir davon aus, dass man bereits über einen eigenen PGP-Key verfügt und mit dessen Verwendung vertraut ist. Falls nicht, wird in diesem **[[centos:openpgp_beim_mua#openpgp_in_der_praxis|Kapitel]]** die Erstellung und Verwendung ausführlich beschrieben. Besonders sicherheitsbewussten Administratoren ist auch die Verwendung einer Kryptographie-Hardware z.B. eines **[[https://shop.nitrokey.com/de_DE/shop/product/nksa-nitrokey-start-6|Nitrokey Start]]** empfohlen. Die Erstellung von passenden Schlüsselmaterial wie ECDSA-basierten SSH-Schlüssel und PGP-Schlüssel ist z.B. in diesem **[[suse:nitrokey:start#nitrokey_start_und_gnupg|Kapitel in Djangos WIKI]]** ausführlich beschrieben und erklärt.
 Bevor wir uns nun eingehender mit **''pass''** beschäftigen installieren wir das Programm-Paket mit Hilfe des Paketverwaltungs-Tools unserer Distribution.
@@ Zeile 419: / Zeile 419: @@
   * **Ubuntu / Debian** : <code> $ sudo apt-get install pass</code>
-Was das Programm **''pass''** alles an Befehlsoptionen mitbringt, offenbart uns die der Programmaufruf mit der Option ***''help''**.
+Was das Programm **''pass''** alles an Befehlsoptionen mitbringt, offenbart uns die der Programmaufruf mit der Option **''help''**.
    $ pass --help
 <code>============================================
@@ Zeile 482: / Zeile 482: @@
 Im Homeverzeichnis unseres Admins findet sich nun das zugehörige verschlüsselte Dokument.
-<code>/home/chrsitoph/.password-store/
+<code>/home/christoph/.password-store/
 └── ansible-vault-password.gpg</code>
@@ Zeile 641: / Zeile 641: @@
 Aus dem Blickwinkel **Sicherheit** haben wir nun zum einen erreicht, dass schützenswerte Informationen nicht mehr als plain-text in unserer  Ansible-Entwicklungsumgebnung ungeschützt herumliegen. Darüber hinaus haben wir nun quasi einen **//zweiten Faktor//** bei der Abarbeitung unserer Ansible-Playbooks eingeführt - genauer gesagt sind es ja eher drei Dinge, über die der Admin verfügen muss:
   - Der Admin muss den SSH-Privat-Key besitzen und von dessen Passphrase Kenntnis haben. Wird ein **Nitrokey Start** USB-Schlüssel verwendet, kann bei Bedarf auch der **[[suse:nitrokey:start#nitrokey_start_und_secure_shell|SSH-Key bei Verwendung der SSH]]** benutzt werden. Die Zusätzliche Eingabe einer Passphrase erübrigt sich dadurch auch hier, wenn der SSH-Key auf dem Kryptostick verwendet wird!
-  - Der Administrator muss beim Aufruf der Playbooks nunmehr **__nur noch__** den PGP-Schlüssel durch Eingabe der zugehörigen Passphrase entsperren. Das Passwort für die Rechteerweiterung wird von Ansible aus dem Vault gelesen, genau so wie das **''become_password''** zur Rechteerweiterung.
+  - Der Administrator muss beim Aufruf der Playbooks nunmehr **__nur noch__** den PGP-Schlüssel durch Eingabe der zugehörigen Passphrase entsperren. Das **''become_password''** Passwort für die Rechteerweiterung wird nun auch von Ansible aus dem Vault gelesen.
 Aus Sicht von **IT-Security** haben wir auch hier einen erheblicher Zugewinn an Sicherheit. Die Akzeptanzschwelle ist durch Minimierung von mehrfachen Eingaben diverser Passworte durchaus niedrig, so dass für den Admin durchaus ein Mehrwert bei der täglichen administrativen Tätigkeit ausgemacht werden kann.