Letzten Donnerstag fand in Bozen die 6. Ausgabe der Open Source System Management Conference statt. John “maddog” Hall eröffnete den Reigen mit einem seiner berühmten Vorträge über freie Software und machte uns klar, dass wir alle froh sein können keine Duschen von Apple zu besitzen. Es ist umständlich und nicht gerade preiswert, sich für die neue Dusche gleich neue Apple-Leitungen verlegen zu lassen um sich an die Apple-Kanalisation und die Apple Wasserwerke anschließen zu können.

ossmc logo Die OSSM Conference 2014 in Bozen
Die Agenda der von unseren Freunden bei Würth Phoenix organisierten Konferenz richtete sich sowohl an Systemadministratoren als auch an IT Entscheider. 2014 Open Source System Management Conference Thomas Gelf 150x150 Die OSSM Conference 2014 in BozenDiese durchaus schwierige Grätsche ist dem Veranstalter dabei sehr gut gelungen. Die Vorträge waren kurzweilig und spannend und es machte Freude, einmal mehr mit Michael Medin und Andreas Ericsson bis spät in die Nacht fachsimpeln zu können. Für mich war es zudem eine gute Gelegenheit meine alte Heimat besuchen zu können. Ich war nämlich mit einem kleinen Vortrag der Lust auf Puppet machen sollte mit am Start. Blauer Himmel, Sonnenschein – in Südtirol war alles wie gewohnt.

Ein Dankeschön nochmal an Würth Phoenix und ein großes Kompliment für die professionelle Abwicklung. Slides und Videos sind bereits online, auch das ist vorbildlich! Für mich als italienischen Staatsbürger deutscher Muttersprache war es zudem ein persönliches Highlight, einen englischen Vortrag zu halten und dabei simultan ins Deutsche und Italienische übersetzt zu werden!

33.thumbnail Die OSSM Conference 2014 in Bozen

Autor: Thomas Gelf

Der gebürtige Südtiroler Tom arbeitet als Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

PUPPET FUNDAMENTALS TRAINING IN PRAGUE

 New town, new look, new audience

Good news for all Puppet fans: We are offering our PUPPET FUNDAMENTALS
training now as well in Prague!

As we are always in search of new locations which are most convenient to reach and will save travel time for the participants, we selected Prague as our new training location starting this autumn. The trainings are scheduled for September and November this year. So, still there is plenty of time, but the registration is already open to save your seat for the PUPPET FUNDAMENTALS training.

 New town, new look, new audienceIf you are new to the field of Puppet and your company is working already with Puppet or you are an already experienced system administrator who would like to integrate Puppet as a new solution, then our PUPPET FUNDAMENTALS training fits you perfectly. This training is also recommended for the Puppet Certification Exam. In this training you will learn everything you need to successfully work with Puppet. This training course will be held in English language.

More information on the training schedule and the registration you will find here.

We are looking forward to your registration -Zatím!

Silke Panayiotou
Event Manager

92.thumbnail New town, new look, new audience

Autor: Silke Panayiotou

Silke verstärkt uns seit September 2013 in unserem Event Team und hat dort vor allem den Bereich Schulungen übernommen. Gemeinsam mit Eva und Markus ist sie für die Planung, Umsetzung und den reibungslosen Ablauf unserer Workshops und Schulungen zuständig. In Ihrer Freizeit beschäftigt sie sich gerne mit verschiedenen Wellnessanwendungen und Reiki als perfekten Ausgleich, um für die nächsten Schulungen die nötige Ruhe mitzubringen.

camera Weekly Snap: OSDC 2014, Puppet Camp & GnuPG/GPG Best Practices7 – 11 April was OSDC 2014 and PuppetCamp week, with a few GPG best practices and Python musings slipped in.

Eva ended her countdown to the OSDC with Daniel Kirstenpfad’s talk on ‘Why Virtual Development and Testing isn’t Rocket Science’ and thanked all attendees and sponsors in advance. Dirk and Michael then followed with their highlights from the first and second days at the OSDC 2014.

Continuing with events, Christian announced the next round of webinars featuring Request Tracker, Puppet, Bareos and inGraph and Dirk returned with his review of Puppet Camp 2014.

Thomas then gave a comprehensive rundown of GnuPG / GPG best practices as Alexander shared his thoughts on Python 2.4 and RHEL.

Finally, Georg ended the week by introducing the newest addition to our hardware store: HW Group Poseidon2 3266.

20.thumbnail Weekly Snap: OSDC 2014, Puppet Camp & GnuPG/GPG Best Practices

Autor: Amanda Mailer

Amanda unterstützt das NETWAYS Team im Bereich Marketing und da vor allem bei allen englischen Aktivitäten. Als Australierin mit einem deutschen Mann verheiratet, fällt ihr das auch besonders leicht. Neben NETWAYS arbeitet sie auch im Icinga Team mit.

Puppet Camp started for Lennart, me and an audience of 66 persons yesterday with an introduction to puppet. I tried to cover different topics starting with the different components to hopefully helpful tips in designing infrastructure, workflow and modules while Lennart added a practical demo.

For the rest of the attendees puppet camp started with a warm welcome from Bernd and our partner puppetlabs who also provided the keynote. Andy Parker started with a quick poll and some nice giveaways before giving an insight look in puppetlabs philosophy and ecosystem around puppet.

Ger Apeldoorn talked about creating a puppet infrastructure instead of implementing a specific component. Like always I found some homework for me to do, this time having a deeper look on the hiera backend eyaml which adds encryption, the git extension gitflow and r10k, a deployment tool for puppet modules.

In his talk “Module (Re)writing the smart way” Martin Alfke encouraged people to write and publish modules as a community also mentioned some important things to consider. He also gave good advise on how to find good modules provided by the community.

 

After Lunch Jos Boumans gave his talk about metrics and how these help to improve your it infrastructure. And he knows what he is talking about because his company is making a good revenue with providing metrics. These metrics are created using collectd, statsd and graphite with many many modules pushing their data to this solution. One of those is puppet which is also used to configure everything.

The pitfalls and antipattern shown by Felix Frank were quit nice and it is always helpful to learn from others mistakes instead of doing it wrong by your own.

Never had a deeper look into OpenBSD but it was quite interesting what challenges the OpenBSD community represented by Jasper Lievisse Adriaanse had to master to get puppet running on all the supported platforms.

Craig Dunn provided advise to mitigate the pitfalls we heard about earlier and additional patterns helping to improve your puppet code. I also encourage everybody to use the roles and profiles pattern perhaps many advanced users will notice that they are doing it this way anyway.

After many high level talks for the experienced users Steven Thwaites did a demo covering puppet and puppet enterprise which was quite nice especially for beginners.

Jordan Sissel gave a great talk on fpm and pleaserun, some nice tools to simplify and abstract packaging and running services. I like it, but I also have to disagree in some points. Mainly seeing myself as an administrator I prefer guidelines like those provided by fedora, file system hierarchy standard and manual work to get better supportable packages. But I fully agree on the usefulness also of the ELK stack (elastic search – logstash – kibana) he additionally talked about.

It was an awesome conference especially for networking with other puppet users. So I am looking forward to October 16th when the next puppet camp will take place in Dusseldorf. So save the day!

P.S.: I want to congratulate those passed the puppet certified professional exam that took place next to the conference.

64.thumbnail Welcome to Berlin   Puppet Camp 2014

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

Dieser Artikel richtet sich an User, die bereits etwas Erfahrung mit GnuPG / GPG / OpenPGP haben. GnuPG liefert bereits sehr brauchbare Standardeinstellungen mit und es kann ohne Probleme ohne grossen Zusatzaufwand verwendet werden. Wer aber etwas tiefer eintauchen, höhere Sicherheit und mehr Komfort möchte, findet im Folgenden einige Vorschläge.

Die Konfiguration

Normalerweise konfiguriert man GnuPG durch ein Konfigfile, meist ~/.gnupg/gpg.conf. Einige graphische Frontends sollten einige dieser Optionen auch anbieten und sie gegebenenfalls in eine Konfigurationsdatei schreiben.

Bei mir sieht das so aus:

default-key 91B8ECDC6265BAE6
default-recipient-self
keyserver hkp://keys.gnupg.net
keyserver-options auto-key-retrieve
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
personal-cipher-preferences AES256 AES192 AES
personal-compress-preferences SHA512 SHA384 SHA256 SHA224
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
use-agent
verify-options show-uid-validity

Nicht alle Optionen sind für die Verwendung des Schlüssels für sichere E-Mail wichtig, sondern werden mehr beim Verschlüsseln und Signieren von Dateien auf der Kommandozeile verwendet. Die Optionen können auch beim Aufruf von gpg auf der Kommandozeile angegeben werde. Eine Liste findet sich auf der GnuPG Homepage.

Der default-key gibt einfach an, welcher Schlüssel als eigener Schlüssel für Signaturen oder Verschlüsselung an sich selbst verwendet wird. Dabei wird eine längere Fassung der ID verwendet, da es bei der 8 stelligen Kurzfassung, die man oft sieht, zu leicht zu Kollisionen kommen kann. Wer meinen Schlüssel betrachtet, wird sehen, dass ich auch noch nicht alle dieser Ratschläge mit diesem Key umgesetzt habe. Ein neuer Schlüssel ist generiert, hat aber noch zu wenig Signaturen, um ihn sinnvoll zu verwenden. Es ist also nur mehr eine Frage der Zeit, bis ich mich an meine eigenen Empfehlungen halte. icon smile GnuPG / GPG Best Practices

Die Option default-recipient-self gibt an, dass man beim Verschlüsseln auf der Kommandozeile keinen Empfänger angeben muss, sondern immer mit dem eigenen Key verschlüsselt wird, wenn keine ID angegeben wird.

Mit keyserver wird der Standardkeyserver angegeben, der genutzt wird, wenn kein anderer Schlüsselserver auf der Kommandozeile genannt wird. Dabei wird immer wieder davor gewarnt, pgp.mit.edu als Keyserver zu verwenden, da dieser berüchtigt dafür ist, Daten nicht sauber mit anderen Servern zu synchronisieren. Welcher andere Keyserver genannt wird, ist meist nebensächlich, da sich eigentlich alle Keyserver miteinander abgleichen sollen.

Durch keyserver-options auto-key-retrieve werden Schlüssel, die im Keyring fehlen, aber zum Verifizieren von Signaturen benötigt werden, automatisch geholt.

Die personal-digest-preferences, personal-cipher-preferences und personal-compress-preferences Listen geben an, welche dieser Algorithmen man bevorzugt, in absteigender Reihenfolge. Beim Versand einer Nachricht wird damit jeweils von links an nach dem ersten Algorithmus gesucht, den alle Empfänger unterstützen. So ist sichergestellt, dass möglichst starke Standards verwendet werden, aber auch an ältere oder suboptimal konfigurierte Clients versandt werden kann. Gibt man z.B. keinen Digest (Hashing) Algorithmus aus der SHA-2 Familie an, nutzt GnuPG Standardmässig SHA-1 für Hashing, was nicht mehr empfohlen werden kann. Es sollte unbedingt ein Algorithmus aus der SHA-2 Familie vor SHA-1 und MD5 in der Liste stehen. Welche Algorithmen in der eigenen Installation zur Verfügung stehen, sieht man übrigens bei einem Aufruf von gpg --version. Bei diesen Optionen eine Liste anzugeben, verhindert den Versand nicht, da immer ein Algorithmus gewählt wird, den alle Empfänger verstehen. Das bedeutet aber auch, dass unter Umständen dennoch unsichere Algorithmen verwendet werden.

Die Option cert-digest-algo ist etwas tückisch. Sie gibt an, welcher Hash Algorithmus beim Signieren von fremden Schlüsseln verwendet wird. Wird der nicht von anderen Usern unterstützt, können Signaturen nicht überprüft werden. Gilt das auch für die Selbstsignatur eines Schlüssels, kann er gar nicht vom Kommunikationspartner verwendet werden. Standard ist eigentlich MD5 für PGP2 Schlüssel und SHA-1 für alle anderen Schlüssel. Da diese aber nicht mehr verwendet werden sollten, steht man vor der Wahl: Unsicherer Algorithmus oder unter Umständen Inkompatibilität zu anderen Usern. Ich habe mich bei neuen Schlüsseln für die mögliche Inkompatibilität entschieden. Vielleicht kann ich damit ja auch den einen oder anderen User zum Upgrade auf eine sichere Version bewegen. Da Signaturen normalerweise nur einmal erstellt werden, sollte man diese Option unbedingt setzen, bevor man einen neuen Schlüssel erstellt. Aus den genannten Gründen führen auch manche Seiten diese Option als “esoteric option” auf. icon smile GnuPG / GPG Best Practices

Mit default-preference-list gibt man an, welche Algorithmen man selbst unterstützen möchte. Diese Liste wird beim Erstellen eines neuen Schlüssels verwendet, sie sollte also unbedingt gesetzt werden, bevor man einen Schlüssel erstellt. Diese Liste wird auch im Schlüssel verankert und daraus und aus den oben genannten personal-...-preferences wird dann die beste bevorzugte Version ausgesucht, die von allen Beteiligten unterstützt wird. Diese Einstellung kann auch nachträglich am Schlüssel geändert werden. Allerdings muss dann der Absender wieder den aktuellen Schlüssel haben, um die aktuelle Liste zu verwenden. Also auch gleich lieber vor Erstellung eines neuen Schlüssels richtig setzen.

use-agent gibt lediglich an, dass der GnuPG Agent verwendet wird, sofern verfügbar. Damit wird eine eingegebene Passphrase für einige Zeit gespeichert und man muss sie nicht gleich erneut eingeben.

Zu guter letzt sorgt verify-options show-uid-validity dafür, dass beim Anzeigen von UIDs auch gleich deren Gültigkeit angezeigt wird.

Beim Erstellen neuer Schlüssel zu beachten

Wie erwähnt, macht es Sinn, die Optionen in der Konfigurationsdatei zu setzen, bevor man einen Schlüssel erstellt.

Mit gpg --gen-key wird die Erstellung eines neuen Schlüssels gestartet. Ausnahmsweise sei es auch erlaubt, eine GUI dafür zu verwenden. icon wink GnuPG / GPG Best Practices Dieser Artikel richtet sich an Fortgeschrittene, weshalb auf die Erstellung an sich nicht weiter eingegangen wird.

Als Schlüsselpaar wird bei aktuelleren GnuPG Installationen bereits RSA/RSA vorgeschlagen, was auch übernommen werden sollte.

Dann kommt das leidige Thema der Schlüssellänge. Hier gilt fast noch mehr, als bei den Algorithmen, dass davon die Kompatibilität zu Kommunikationspartnern abhängt. Die meisten sollten inzwischen 4096bit unterstützen. Weniger sollte man alleine schon deshalb nicht mehr wählen, weil man den Schlüssel ja einige Zeit behalten möchte und 4096bit noch länger aktuell bleiben wird, als kürzere Schlüssel. Längere Schlüssel werden noch immer von zu wenig Clients unterstützt. Wobei man bedenken sollte, dass viele Clients zwar keine Erstellung von Schlüsseln über einer bestimmten Länge anbieten, aber sehr wohl mit solchen umgehen können. Es gibt noch weitere Gründe, warum es nicht unbedingt sinnvoll ist, längere Schlüssel als 4096bit zu erstellen, aber dazu vielleicht später mehr.

Es gibt einige Artikel, die darauf eingehen, ob es Sinn macht, ein Kommentar zum Schlüssel hinzuzufügen. Wobei die meisten entweder sehr dafür oder sehr dagegen sind. Ich selbst füge nur mehr Kommentare hinzu, wenn es für mich Sinn macht. Ein Beispiel wäre “package signing key” für Schlüssel, über die ich eigentlich nicht kommunizieren möchte. Kommentare, die nur Informationen enthalten, die man auch aus der zu der uid gehörigen E-Mail Adresse entnehmen kann, kann man getrost weglassen.

Wichtig ist, ein Ablaufdatum festzulegen. Einige Seiten empfehlen, es nicht weiter als 5 Jahre in die Zukunft zu setzen. Es kann jederzeit, auch nach Ablauf des Schlüssels, verändert werden. Nach einer Änderung sollte der Schlüssel wieder auf einen Keyserver hochgeladen werden. Auch wenn man noch so darauf achtet, kann es passieren, dass man den privaten Teil des Schlüssels verliert oder die Passphrase vergisst. Dann sollte der Schlüssel nicht ewig über die Keyserver geistern, sondern irgendwann entfernt werden. Dabei geht es weniger darum, dass Ressourcen gespart werden, sondern mehr darum, dass ein Kommunikationspartner auch wirklich nur Schlüssel von den Keyservern holt, die auch noch zum Entschlüsseln genutzt werden können. Ähnliches gilt, wenn der Besitzer des Schlüssels ihn aus anderen Gründen nicht mehr nutzen kann (z.B. weil er verstorben ist)

Nach dem Erstellen des Schlüssels

Als erstes sollte ein Revocation Certificate erstellt werden. gpg --output revoke.asc --gen-revoke [keyid] Dieses sollte an einem sicheren Platz (USB Stick in einem Tresor, Truecrypt Container, oder vergleichbares) abgespeichert und evtl. sogar ausgedruckt (dazu beim Erstellen die Option --armor verwenden, um das Zertifikat als ASCII zu erhalten) werden, um sie im schlimmsten Fall abzutippen. Mit diesem Zertifikat kann der Schlüssel ungültig gemacht werden, ohne, dass man den privaten Teil oder die Passphrase braucht. Das ist einerseits gut, wenn man einen oder beide dieser Teile verloren hat, aber andererseits sehr gefährlich, weil jeder damit den Schlüssel ungültig machen kann. Um es zu verwenden, importiert man es einfach in seinen Schlüsselbund und lädt den Schlüssel auf einen Keyserver hoch. Ab da scheint er bei jedem als ungültig auf, der die aktuelle Version des Schlüssels hat.

Dann können weitere IDs zu dem Schlüssel hinzugefügt werden. Eine für jede E-Mail Adresse, mit der man den Schlüssel verwenden will. Einige Anleitungen empfehlen auch, eine ID ohne E-Mail Adresse hinzuzufügen, da sich der Name seltener ändert als E-Mail Adressen. Ich bin ein Freund davon, sich zumindest eine Adresse mit einer eigenen Domain zuzulegen, die sich möglichst nie ändert, was diesen Grund wieder relativiert. Ausserdem signieren manche automatisierte Tools nur “aktive” IDs, also solche, von deren E-Mail Adressen man auch Nachrichten empfangen kann, was hier ebenfalls nicht funktionieren würde. Es spricht aber auch nicht wirklich etwas gegen das Erstellen einer solchen ID.

Eine Photo ID finde ich persönlich sinnvoll, vor allem wenn man Schlüssel nur bei persönlichem Kontakt signiert. Legt man sich selbst eine Signatur Policy zurecht, die auch Signaturen ohne persönliches Treffen erlauben, kann es sinnvoll sein, auf die Signatur einer Photo ID zu verzichten. Man kann ja auch einzelne IDs signieren.

Mit gpg --send-key [keyid] schickt man den Schlüssel dann an den konfigurierten Keyserver. An sich reicht es, ihn an einen Server zu senden, da sich die Keyserver untereinander synchronisieren. In der Praxis funktioniert das nicht immer reibungslos, aber im Allgemeinen findet jeder Schlüssel früher oder später den Weg zu den einzelnen Servern.

Regelmässige Wartung

Da, anders als bei S/MIME, aktualisierte Schlüssel nicht beim Versand von E-Mails übertragen werden, sondern immer wieder vom Keyserver geladen werden müssen, ist es sehr wichtig, die Schlüssel regelmässig von einem Keyserver zu aktualisieren. Dazu habe ich folgenden Eintrag in meiner crontab: 40 5 * * 4 /usr/bin/gpg --refresh-keys --keyserver-options no-honor-keyserver-url ; /usr/bin/gpg --refresh-keys --keyserver-options honor-keyserver-url . Das funktioniert, weil ich das Gerät regelmässig für Wartungsaufgaben über Nacht laufen lasse. Wer das anders hält, muss eben die Zeit des cronjobs anpassen. Dabei führe ich --refresh-keys zwei mal aus. Einmal hole ich die Schlüssel von dem Keyserver, den ich mir als Standard konfiguriert habe und einmal von dem Keyserver, den die Schlüsselbesitzer evtl. in ihren Schlüsseln hinterlegt haben. Damit respektiere ich einerseits, falls jemand seinen Schlüssel an einem bestimmten Server pflegt, der sich unter Umständen gar nicht mit anderen Schlüsselservern synchronisiert und bin andererseits dafür gewappnet, dass jemand evtl. einen Server angegeben hat, der gar nicht mehr existiert. Wer keinen hkps fähigen Keyserver verwendet, überträgt damit regelmässig eine Liste der Schlüssel im eigenen Keyring und damit wahrscheinlich eine Liste der regelmässigen Kommunikationspartner. Es gibt Tools, die helfen, das zu Verschleiern, ohne auf hkps umsteigen zu müssen, da aber keine weitere Information enthalten ist, hebe ich Anleitungen dafür für etwaige spätere Artikel auf.

Mit dem Befehl gpg --update-trustdb kann man die Trust-DB ausfüllen. Damit gibt man für alle Schlüssel, für die man das noch nicht getan hat, an, wie sehr man dem Besitzer zutraut, Schlüssel anderer Personen nur nach ordentlicher Überprüfung der Identität zu vertrauen. Diese Information hat durchaus mit der persönlichen Meinung über die Besitzer zu tun und sollte deshalb sehr vertraulich behandelt werden. Sie wird auch nicht mit einem Schlüssel exportiert. Zu beachten ist, dass dies nichts damit zu tun hat, wie sehr man dem Besitzer eines Schlüssels glaubt, tatsächlich der zu sein, der er zu sein vorgibt. Diesen Befehl sollte man regelmässig ausführen, da diese Einstufung bei jedem neu importierten Schlüssel nötig ist. Das muss interaktiv passieren, deshalb macht es keinen Sinn, einen Cronjob dafür zu planen.

Zum Backup der geheimen Schlüssel sollte man ab und zu gpg --export-secret-keys --armor ausführen und den Output an einem sicheren Ort speichern. Zwar ist der Schlüssel mit der Passphrase geschützt, aber nur darauf sollte man sich auf keinen Fall verlassen. Die öffentlichen Schlüssel kann man zwar von Schlüsselservern neu holen, aber wenn man schon mal dabei ist: gpg --export --armor.

Es ist auch sinnvoll, immer wieder zu kontrollieren, ob das Ablaufdatum des Schlüssels nicht kurz bevor steht. Da es einige Zeit braucht, bis alle Kommunikationspartner einen aktualisierten Schlüssel holen, sollte man früh genug damit beginnen, das Ablaufdatum wieder nach hinten zu verschieben und den öffentlichen Schlüssel über die Keyserver zu verteilen.

Als stolzer Schlüsselbesitzer sollte man regelmässig versandte Mails signieren. Das ist wahrscheinlich der effektivste Weg, herauszufinden, ob man nicht unter seinen regelmässigen Kommunikationspartnern auch GnuPG Anwender hat. Ausserdem wird so oft die Rückfrage kommen, was denn “diese komischen Zeichen” sein sollen. Ein sehr praktischer Weg, um ein Gespräch über sichere E-Mailkommunikation zu beginnen. icon smile GnuPG / GPG Best Practices

Was man sonst noch tun kann

Natürlich sollte man über diesen Vorschlägen nicht vergessen, den Schlüssel einfach auch mal zu verwenden. Zum Signieren und Verschlüsseln von E-Mails, Signieren von Softwarepaketen, Verschlüsseln von Dateien, die man sicher aufbewahren will und einiges mehr.

Die wichtigste Regel im Umgang mit E-Mail Sicherheit ist meiner Meinung die gleiche, die ich für Wiederbelebung in der Ersten Hilfe gelernt habe: Hauptsache, man tut’s. Auch wenn man sich nicht ans Handbuch hält und vielleicht nicht alles perfekt ausführt, ist es immer noch viel, viel besser, als nichts zu tun. Bei beidem gilt jedoch auch, dass man immer nur Chancen verschieben kann. 100% Erfolgschance gibt es bei beidem leider nicht, auch wenn man noch so gut vorbereitet ist. Je besser man sich vorbereitet, umso höher sind aber die Chancen des Erfolges. Sicher ist nur eines: Macht man nichts, sieht’s düster aus.

Für alle, die sich dennoch gerne vorbereiten wollen, soll dieser Artikel einen Anhaltspunkt für den E-Mail Teil des Vergleichs geben, für den Rest gibt’s hier, hier und bei vielen anderen Stellen, die ich leider hier aus Platzgründen nicht mehr nennen kann, Angebote.

Für die Nerds und Geeks unter den Lesern findet sich viel Spass mit Graphen und Statistiken zu Schlüsseln auf http://pgp.cs.uu.nl/

Natürlich gibt es noch viel mehr, was man mit GnuPG und GPG Schlüsseln machen kann, was sich im täglichen Leben als praktisch und/oder sicher erweist, aber als Start sollte dieser Artikel einige Anhaltspunkte geben. Sollte Bedarf bestehen, können gerne Einführungsanleitungen folgen. Eine wunderbare Anwendung des Kommentarfeldes, solchen Bedarf anzumelden. icon smile GnuPG / GPG Best Practices

Noch eine Anmerkung: Sicherheitstechnologien sind einem ständigen Wandel unterworfen. Es lohnt sich also immer, mal kurz nach dem aktuellen Stand der Technik zu suchen, um zu vergleichen, ob die Informationen nicht schon wieder überholt sind. Bei Kommunikationstechnologien ist das doppelt wichtig, da sich Sender und Empfänger auf einen Satz an Technologien einigen müssen. Dafür wird  oft eine gewichtete Liste konfiguriert, welche Technologien unterstützt werden und welche bevorzugt werden. Das sollte nicht zu restriktiv gehalten werden, sonst kann es schon zu Problemen beim Versand von E-Mails von sehr konservativen Betriebssystemen an Bleeding-Edge OS und umgekehrt kommen. Beispiele solcher Listen finden sich oben in dem Beispiel der Konfigurationsdatei.

Für weitere Vorschläge anderer Best Practices bietet sich ebenfalls die Kommentarfunktion an.

Ein paar weiterführende Links zum Thema:

76.thumbnail GnuPG / GPG Best Practices

Autor: Thomas Widhalm

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool.

Page 1 of 4641234...10...>>