Vermeiden. Erkennen. Beheben.

Bereits seit einiger Zeit orientiere ich mich bei der Auswahl von Sicherheitsmaßnahmen an einer Einteilung, die ich bereits im Artikel über die aktive Verteidigung gegen Kryptotrojaner einmal verwendet hatte: Vermeiden. Erkennen. Beheben.

Bisher war ich davon ausgegangen, dass es sich dabei um ein gängiges Modell handelt - schließlich wird es in vielen Bereichen eingesetzt, in denen es um Fehlervermeidung geht. Bezogen auf das Management der Informationssicherheit habe ich jedoch keine relevanten Quellen ausfindig machen können, die sich mit dieser Klassifizierung von Sicherheitsmaßnahmen beschäftigt.

Aus diesem Grund habe ich mir überlegt, einfach einmal aufzuschreiben, was ich mit den drei Punkten meine und wie deren Anwendung einem helfen kann, die Absicherung der eigenen Informationssicherheit ganzheitlicher zu gestalten.

tl;dr

Anstatt sich im risikoorientierten Sicherheitsmanagement nur mit der Frage zu beschäftigen, wie man Schäden vermeidet, sollte man in seinen Prozessen auch die Frage berücksichtigen, wie man denn entstandene Schäden erkennt und wie man diese entstandenen Schäden behebt.

Grundsätzliches

Sicherheitsmanagement, wie es heutzutage praktiziert wird, ist primär risikoorientiert. Man baut sich einen Pool an potentiellen Bedrohungen auf; prüft, ob ein spezifisches Asset Schwachstellen hat, die durch eine Bedrohung zu tatsächlichen Gefährdungen werden; bewertet das daraus entstehende Risiko und überlegt sich, wie man mit diesem Risiko umgehen möchte. Möglichkeiten sind die Übernahme des Risikos - man lebt also damit, dass das Risiko existiert; man transferiert das Risiko auf jemand anderen - z.B. indem man eine Versicherung abschließt; man vermeidet das Risiko - z.B. indem man eine andere technische Lösung wählt - oder man reduziert das Risiko, indem man Maßnahmen ergreift, die dabei helfen, die Eintrittswahrscheinlichkeit oder die Auswirkung zu verringern.

Wie man erkennt, beschränkt sich diese Form der Betrachtungsweise primär auf die Vermeidung von Schäden. Was fehlt, ist die Betrachtung von Maßnahmen, die dabei helfen, eingetretene Schäden zu erkennen und diese zu beheben. Meiner Erfahrung nach führt diese einseitige Herangehensweise dazu, dass sich Unternehmen darauf versteifen, Gefahren abzuwehren und sich zu wenig damit auseinander setzen, was passiert, wenn ein Schaden trotzdem eintreten sollte.

Erst in jüngerer Zeit scheint es hier ein Umdenken zu geben. Nachdem sogar Sicherheitsunternehmen wie z.B. Antivirenhersteller und Sicherheitsbehörden gehackt werden, entsteht langsam das Mantra "es stellt sich nicht die Frage, ob man gehackt wird, sondern wann".

Die Klassifizierung von Sicherheitsmaßnahmen in die Kategorien Vermeidung, Erkennung und Behebung - wobei Mehrfachklassifizierungen je nach Nutzungsart durchaus möglich sind - kann dabei helfen, einen ganzheitlichen Ansatz des Sicherheitsmanagements zu etablieren.

Vermeiden

Meiner Erfahrung nach handelt es sich bei der Vermeidung von Schäden um den Maßnahmenkomplex, den Unternehmen als erstes betrachten, wenn sie sich mit dem Thema Sicherheits- oder Risikomanagement beschäftigen.

Als ich begonnen habe, mich mit der IT-Security zu beschäftigen, ist man häufig noch davon ausgegangen, dass es ausreichend ist, genügend technische Maßnahmen zu ergreifen, um sich vollständig abzusichern. Das Nutzen von Verschlüsselung, der Einsatz von Antivirenscannern und Firewalls, das Nutzen von RAIDs, das Erstellen von Backups, sowie das regelmäßige Patchen von Anwendungen waren die klassischen zu ergreifenden Maßnahmen.

Wie bereits weiter oben beschrieben, führen auch die klassischen Risikomanagementmethoden dazu, sich primär mit Maßnahmen zur Vermeidung von Schäden zu beschäftigen.

Erkennen

Die Erkennung von Schäden ist - so zumindest meine Erfahrung - selten vom Gedanken des Risikomanagements getrieben, dafür aber umso häufiger vom Gedanken der operativen Funktionstüchtigkeit. Die klassische Erkennungsmethode ist der Einsatz einer Monitoringlösung im IT-Umfeld. Diese beschränkt sich jedoch sehr häufig auf Themen wie die Verfügbarkeit von Services und der Ressourcenauslastung von Hardware.

Nur selten wird sie genutzt, um regelmäßig nach veränderten Dateien, unzulässigen Netzwerkverbindungen, unbekannten Prozessen oder bekannten Prozessen mit unbekannten Parameterlisten zu scannen. Hintergrund dürfte auch sein, dass sich das Erkennen von Verfügbarkeitsproblemen recht einfach standardisieren lässt, während Verhaltensmuster von Systemen und Anwendungen sehr unterschiedlich sein können und jeweils ein individuelles Profiling bedürfen. Das führt dazu, dass solche komplexeren Erkennungen in Form von IDS- und IPS-Lösungen erst dann zum Einsatz kommen, wenn das gesamte Sicherheitsmanagement des Unternehmens einen gewissen Reifegrad erreicht hat.

Eine andere klassische Maßnahme ist die Einführung einer zentralen Logging-Infrastruktur, die es einem prinzipiell ermöglicht, durch das Analysieren einer Vielzahl von Systemevents einen möglichen Schaden zu erkennen. Aber auch hier müssen erst im Zuge einer SIEM-Lösung entsprechende Trigger definiert werden, bevor man einen tatsächlichen Nutzen aus der Maßnahme ziehen kann.

Doch auch abseits der Technik sollte man sich im Zuge seines Risikomanagements immer die Frage stellen, welche Maßnahmen ergriffen werden, um das Eintreten eines Schadens überhaupt erkennen zu können.

Beheben

Nachdem man sich Gedanken gemacht hat, wie man eingetretene Schäden erkennt, besteht die schlussendliche Arbeit darin, sich zu überlegen, wie man den Schaden auch wieder beheben kann. Eine klassische Maßnahme zur Behebung von Schäden ist das Wiedereinspielen von Backups oder das Neuaufsetzen von kompromittierten Systemen. Doch evtl. muss man je nach Anwendung granularer vorgehen oder es ergibt sich die Möglichkeit, die Behebung einzelner Schäden automatisiert durchführen zu lassen.

Meiner Erfahrung nach bestehen viele Maßnahmen zur Behebung von Schäden im ersten Schritt aus spontanen Ideen, die im tatsächlichen Ernstfall umgesetzt werden. Diese verfestigen sich anschließend durch die Formulierung von Wiederherstellungsplänen oder - gröber gefasst - durch Notfallpläne im Zuge der Etablierung eines Notfallmanagements. Die erstellten Pläne stützen sich anfangs oft vor allem auf händische Prozesse. Erst bei zunehmender Reife werden manuelle Arbeiten durch automatisierte Tasks abgelöst. Denn auch hier müssen viele individuelle Aspekte berücksichtigt werden.

Auch abseits der Technik sollte man sich Gedanken zur Behebung von Schäden machen. Wie reagiert man als Unternehmen, wenn essentielle Ressourcen nicht zur Verfügung stehen oder wie würde man beim Abhandenkommen sensibler Daten vorgehen?

Praxisbeispiel

Um diese Dreiteilung an Maßnahmen einmal im Zusammenspiel zu zeigen, möchte ich einmal Antivirensoftware als plakatives Beispiel wählen - unabhängig von der Diskussion über deren tatsächlichen Nutzen:

Wir beginnen mit der Hauptaufgabe von Antivirensoftware - dem Erkennen von Viren. Im ersten Schritt wird man nur einzelne Dateien geprüft haben und diese Maßnahme Stück für Stück erweitert haben - um das Scannen ganzer Ordner, um das Scannen des ganzen Systems und schlussendlich auch um das Scannen des Bootsektors. Die Erkennung erfolgte früher allein auf Basis einer Virensignatur - sprich, der Information darüber, wie der kompilierte Quelltext des Virus aussieht.

Als man Viren erkennen konnte, stellte sich die Frage, wie man mit ihnen umgeht - sprich, wie das Beheben eines Virenbefalls aussehen könnte. Man könnte sie z.B. in Quarantäne schieben, sie direkt löschen oder - mit entsprechend viel Wissen über den Virus - diesen evtl. sogar aus einer infizierten Datei entfernen.

Als man nun weiter fortschritt, Festplatten größer und die Scans damit zeitaufwändiger wurden, kam man evtl. nicht mehr dazu, regelmäßig alle Dateien händisch zu prüfen. Trotzdem war es wichtig, zu verhindern, dass eine virenverseuchte Datei geöffnet oder verteilt wurde. Also begann man damit, Dateien noch vor einem tatsächlichen Zugriff zu prüfen. Das Live-Scannen von Dateien half, das Ausführen von Viren zu vermeiden, optimierte gleichzeitig aber auch das Erkennen von Viren.

Viren wurde intelligenter und polymorph - ihr Quelltext änderte sich regelmäßig, sodass einfache Virensignaturen nicht mehr in der Lage waren, diese zu erkennen. Erst durch die Einführung von Heuristiken kam Antivirensoftware dazu, auch diese neuen, komplexeren Viren überhaupt erkennen zu können.

Das Internet hielt Einzug und verdrängte Wechseldatenträger als primäres Einfallstor für Viren. Die Hersteller von Antivirensoftware gingen mit und begannen, sich in den Datenkanal einzuklinken. Man wollte Viren bereits erkennen können, noch bevor sie auf der Festplatte des Nutzers gespeichert werden. Das sollte auch vermeiden, dass Nutzer überhaupt die Möglichkeit haben, irgendetwas mit der virenverseuchten Datei anstellen zu können.

Im Businessumfeld sind die Risiken, die von einem Virenbefall ausgehen, sogar noch größer, als in anderen Bereichen. Virenschreiber haben es vor allem auch auf diesen Bereich abgesehen - mitunter sogar mit speziell entwickelten Viren. Aber auch Antivirenhersteller haben dies erkannt und bieten spezifische Lösungen für solche Unternehmen an. Eine Lösung ist, Anwendungen vor ihrem Download auf einen Nutzerrechner in einer VM einer Scanning-Appliance gezielt zur Ausführung zu bringen, um ein verdächtiges Verhalten dieser Anwendung bereits im Vorfeld erkennen zu können. Hiermit will man die Ausführung eines Virus auf einem Nutzerrechner vermeiden.

Fazit

Wie man am Beispiel der Antivirensoftware gut erkennen kann, kann die Klassifizierung von Maßnahmen in die Themenfelder Vermeidung, Erkennung und Behebung dabei helfen, diese besser in einem gesamtheitlichen Sicherheitsansatz zu begreifen.

Je nach Reifegrad des Sicherheitsmanagements im eigenen Unternehmen sollte man sich einmal ansehen, in welchem der drei Themenkomplexe noch Nachholbedarf bzgl. der geplanten und umgesetzten Maßnahmen besteht.

Vermeidende, erkennende & behebende Grüße, Kenny

Das Scrollrad unter Linux beschleunigen

Wie ich bereits im letzten Artikel beschrieben habe, wechsele ich derzeit zu Linux als mein Hauptbetriebssystem. Leider gibt es dabei immer wieder kleinere Stolpersteine, die die Arbeit mit dem System nervig machen. Eines davon war die absolut träge Scrollgeschwindigkeit innerhalb des Systems. Nicht nur, dass man sich dadurch durch längere Webseiten und Terminalsessions krampfen muss - das System fühlt sich oft einfach lahm und überfordert an.

Auf der Suche danach, diesen Missstand zu beseitigen, wanderte ich natürlich erst einmal in die Systemeinstellungen, die bzgl. der Einstellungsmöglichkeiten der Maus, nennen wir es, "spartanisch" ist. Von Themen wir Beschleunigung ist man hier offenbar meilenweit entfernt.

Gnome Mauseinstellungen

Also begann ich damit, mich durch Google zu graben. Als erstes stolperte ich über Beschreibungen zur Nutzung von "xinput". Also fix installiert und per "xinput list" erst nach der ID des Devices gesucht und anschließend per "xinput list-props " die möglichen Optionen durchforstet. Leider fand ich in der Auflistung nichts, was nach der Scrollgeschwindigkeit aussah oder wenigstens wie etwas, was dem nahe kam, was laut den Foreneinträgen der korrekte Konfigurationswert hätte sein sollen.

Noch gab ich aber nicht auf und suchte weiter. Dabei stieß ich auf das Tool "imwheel", das genau das tun sollte, was ich erreichen wollte. Es funktioniert allerdings nicht out-of-the-Box und die meisten Artikel, die ich zuerst fand, bezogen sich darauf, wie man mit imwheel zusätzliche Maustasten unter Linux zum Laufen kriegt. Erst ein halbwegs neuer Artikel half mir dann tatsächlich weiter.

Zuerst einmal muss man imwheel installieren:

1
sudo apt-get install imwheel

Anschließend muss man eine Konfigurationsdatei unter "~/.imwheelrc" erstellen:

1
2
3
4
5
6
7
".*"
None,      Up,   Button4, 3
None,      Down, Button5, 3
Control_L, Up,   Control_L|Button4
Control_L, Down, Control_L|Button5
Shift_L,   Up,   Shift_L|Button4
Shift_L,   Down, Shift_L|Button5

Der Wert ".*" sorgt dafür, dass imwheel in allen Anwendungsfenstern aktiv ist. Man kann hier auch alternativ Fensternamen eintragen, um die Funktion von imwheel auf einzelne Anwendungen zu beschränken. Die einzelnen Zeilen sind nun Ersetzungen, die von imwheel durchgeführt werden. "Button4" ist das nach-oben-scrollen der Maus, "Button5" das nach-unten-scrollen. Diese werden hier durch 3-faches Drücken der Up- bzw. Down-Taste ersetzt. Das gleiche geschieht für Situationen, in denen die Ctrl- bzw. Shift-Taste gedrückt wird.

Nun muss man diese Ersetzung nur noch aktivieren:

1
imwheel --kill --buttons "4 5"

Mit --kill werden alle bereits laufenden Instanzen von imwheel beendet, damit sich unterschiedlich konfigurierte Instanzen nicht in die Quere kommen können. Die Angabe --buttons "4 5" sorgt dafür, dass imwheel sich nur um die Behandlung des Scrollrads kümmert. Man kann über imwheel auch die Scrollrichtung umkehren - entweder, indem man die oben stehende Konfigurationsdatei umschreibt oder aber, indem man einfach den zusätzlichen Parameter --flip-buttons verwendet:

1
imwheel --kill --buttons "4 5" --flip-buttons

Das ganze funktioniert unter Debian mit Gnome schon ganz gut - aber nur bis zum nächsten Neustart. Um die Änderung dauerhaft einzurichten, muss man noch dafür sorgen, dass imwheel beim Hochfahren aktiviert wird. Hierfür bietet sich an, die Autostart-Funktion von Gnome zu verwenden. Um das zu erreichen, legt man die Datei "~/.config/autostart/imwheel.desktop" an und befüllt diese wie folgt:

1
2
3
4
5
6
7
8
[Desktop Entry]
Name=imwheel
Comment=Use imwheel to increase scroll speed
Exec=/usr/bin/imwheel --kill --buttons "4 5"
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true
X-GNOME-Autostart-Delay=10

Auch hier kann man optional den Parameter --flip-buttons verwenden, um die Scrollrichtung umzukehren:

1
2
3
4
5
6
7
8
[Desktop Entry]
Name=imwheel
Comment=Use imwheel to increase scroll speed
Exec=/usr/bin/imwheel --kill --buttons "4 5" --flip-buttons
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true
X-GNOME-Autostart-Delay=10

Ich muss gestehen, dass ich ziemlich genervt bin, dass man halbe Handstände vollführen muss, nur um das Scrollrad zu beschleunigen. 🙄

Scrollende Grüße, Kenny

Emojis unter Linux nutzen

Da Apple sich aus meiner Sicht mit den MacBooks in die falsche Richtung entwickelt, arbeite ich derzeit an einem Soft-Exit aus der macOS-Welt. Da ich sowieso noch einen Tower-PC umher stehen hatte, habe ich mir deshalb gedacht "Warum nicht den ersten Schritt gehen und einen alltagstauglichen Rechner mit Linux bestücken und anfangen, diesen häufiger zu nutzen?".

Genau dabei bin ich gerade. Ich habe mir ein hübsches neues Debian 9 eingerichtet, zwei ordentliche Monitore besorgt und nutze den Desktoprechner nun als Linux-only Haupt-PC. Das klappt soweit auch ganz gut.

Eine Sache hat mir als jahrelanger MacBook- und iPhone-Nutzer jedoch gefehlt: Emojis! 😭

Also machte ich mich auf die Suche nach einer Möglichkeit, Emojis zu verwenden. Die meisten Lösungen, die ich gefunden habe, waren jedoch eher suboptimal - vor allem unterstützte keine davon farbige Emojis in der Auswahlansicht. Und Schwarz-/Weiß-Emojis unterscheiden zu wollen, ist nahezu ein Ding der Unmöglichkeit.

Glücklicherweise bin ich über diesen Artikel gestolpert, der von einem Emoji-Picker handelt, der zu Ubuntu-14.04-Zeiten für Unity 7 entwickelt worden ist. Glücklicherweise ist der EmojiOne Picker for Ubuntu auch unter Debian 9 mit Gnome lauffähig.

Um das zu bewerkstelligen, muss zuerst einmal das aktuelle Release in der Version 0.1 heruntergeladen und entpackt werden. Dieses enthält die Datei "install.sh". Dieser Installer kann als Root aufgerufen werden, um den Emoji-Picker für alle Nutzer zu installieren. Oder aber man startet ihn als normaler Nutzer, damit der Emoji-Picker nur für diesen spezifischen Nutzer installiert wird.

Leider war es bei mir an der Stelle noch nicht getan. Um die Integration in die Oberfläche zu erhalten, nutzt das Tool die Library "AppIndicator 3.0". Um diese zu installieren, muss man erst einmal den korrekten Paketnamen ausfindig machen. Die Installation kann folgendermaßen angestoßen werden:

1
sudo apt-get install gir1.2-appindicator3-0.1

Nach einem Reboot erhält man nun in der unteren linken Bildschirmecke einen Eintrag für den Emoji-Picker, der sich wunderbar aufklappen lässt, um das passende Emoji rauszusuchen - in Farbe und bunt.

EmojiOne Picker Ubuntu

Leider ist das Tool nicht ganz so komfortabel wie die Emoji-Eingabe bei macOS. Anstatt das Menü über eine Tastenkombination aufzurufen, muss man händisch mit der Maus in den Bildschirmbereich fahren. Und im Gegensatz zu macOS wird das gewählte Emoji lediglich in die Zwischenablage kopiert, anstatt direkt ins aktive Textfeld geschrieben zu werden. Aber zumindest scheint es erst einmal besser zu sein, als alles, was ich bisher sonst so unter Linux gesehen habe. Leider.

Emoji-Grüße, Kenny ✌😁

Das Leben geht weiter…

Die letzten Wochen und Monate waren reichlich mit Arbeit gefüllt, sodass der Blog leider ziemlich kurz gekommen ist. Deshalb wollte ich an dieser Stelle einmal ein Lebenszeichen von mir geben... 😀

Nachdem ich im April 2016 einen neuen Job als Security Engineer angenommen hatte, bin ich in dem Unternehmen inzwischen zum Leiter der Informationssicherheit (neudeutsch: Chief Information Security Officer) aufgestiegen. Meine Arbeit hat sich vom Technischen mehr ins Theoretische verlagert. Allerdings sehe ich dadurch auch einige neue Aspekte im Bereich der Unternehmensleitung und -gestaltung, was ja auch mal ganz spannend ist.

Im Zuge dessen habe ich für mich eine neue Form der Selbstorganisation entdeckt, die mir dabei hilft, den Haufen an Aufgaben zu organisieren und zu planen. Das Vorgehen würde ich euch bei Gelegenheit einmal vorstellen wollen, da es für den einen oder anderen sicherlich spannend sein könnte. 🙂

Darüber wurde ich nun in die Lage versetzt, einmal selbst Personalentscheidungen zu treffen. So suche ich für mein Securityteam derzeit Verstärkung in Form eines Security Engineers (m/w). Bei dieser Suche sind mir einige Dinge aufgefallen, die mir bei Bewerbungsunterlagen und -gesprächen zusagen bzw. nicht zusagen. Ein paar davon werde ich demnächst mal zusammenfassend verbloggen.

Zudem habe ich dieses Jahr einen Traum wahr werden lassen, habe Berlin den Rücken gekehrt und wohne nun seit ein paar kurzen Monaten im beschaulichen Potsdam. Die tägliche Anfahrt zum Job in Berlin ist zwar recht lang, aber es lohnt sich einfach, seine Freizeit in einer wesentlich schöneren Gegend verbringen zu können. Der Umzug ging mit einer vollständigen Neumöblierung einher, die - dank IKEA - jedoch recht schlicht und funktional ausgefallen ist.

Hier und da bastele ich an kleineren, privaten IT-Projekten. Wirklich vorzeigbar ist davon jedoch noch nichts. Wenn es in dem Bereich mehr Fortschritt gibt, werde ich es natürlich wieder verbloggen. 😉

Lebendige Grüße, Kenny

Shared-Secrets: Geheimnisse über verschlüsselte Links austauschen

Im Internet gibt es inzwischen eine größere Anzahl an Diensten, über die es möglich ist, Texte auszutauschen - der bekannteste davon dürfte wohl Pastebin.com sein. Einige davon haben zudem begonnen, damit zu werben, dass man über sie Geheimnisse austauschen kann, die wahlweise verschlüsselt auf dem Server abgelegt werden oder nur einen einzigen Abruf des Geheimnisses ermöglichen - beispielsweise OneTimeSecret.com.

Auf Arbeit haben wir vor kurzem nach einer Möglichkeit gesucht, Informationen möglichst sicher an einen Empfänger zu übertragen, ohne, dass auf dessen Seite Software installiert oder eine spezifische Konfiguration vorgenommen werden muss. Dabei bot sich solch ein einfacher Webdienst regelrecht an.

Allerdings sahen wir die vorhandenen Lösungen als eher kritisch an - denn obwohl ein Passwortschutz besteht, werden die Informationen (meistens unverschlüsselt) auf dem Server abgelegt. Dadurch hat der entsprechende Betreiber die Möglichkeit, auf sie zuzugreifen - natürlich auch jeder Hacker, dem es gelingt, in den jeweiligen Dienst einzudringen. Eine zusätzliche Verschlüsselung wiederum würde die Hürde auf der Seite des Empfängers wieder erhöhen - eine Alternative musste her.

Also begann ich damit, eine neue Lösung zu implementieren - das Ergebnis der Entwicklung wurde als Shared-Secrets auf Github veröffentlicht. Zudem ist in unserem Firmenblog ein begleitender Artikel veröffentlicht worden.

Im Gegensatz zu den üblichen Lösungen im Netz haben wir dabei auf mehrere Faktoren Wert gelegt:

  • Die Geheimnisse sollen nicht auf dem Server gespeichert werden.
  • Die Geheimnisse sollen nur ein Mal abrufbar sein, um einen Vertraulichkeitsverlust erkennen zu können.
  • Es muss möglich sein, ein Geheimnis zu teilen, ohne, dass der Server es lesen kann.
  • Es muss möglich sein, ein Geheimnis zu teilen, ohne, dass der Server bei der Verteilung involviert ist.

Dabei herausgekommen ist folgende Lösung: Das zu teilende Geheimnis wird via GPG verschlüsselt und Base64-encodiert. Der Base64-encodierte String wird in eine URL überführt. Bei Aufruf der URL wird der Base64-encodierte String an einen Server übertragen, der ihn decodieren und entschlüsseln kann. Das entschlüsselte Ergebnis wird anschließend angezeigt. Die Prüfsumme des Base64-encodierten Strings wird in einer Datenbank abgelegt. Zudem besteht die Möglichkeit, das Geheimnis vor dem Versand an den Server symmetrisch zu verschlüsseln und nach dem Abruf vom Server wieder zu entschlüsseln.

Auf diese recht einfache Weise konnten alle Designziele erfüllt werden:

  • Dadurch, dass das verschlüsselte Geheimnis direkt in der URL enthalten ist, muss es nicht auf dem Server gespeichert werden. Auch nach einem Abruf wird lediglich die Checksumme der URL und nicht das eigentliche Geheimnis gespeichert.
  • Durch das Speichern der Checksummen von bereits abgerufenen URLs ist es möglich, zu erkennen, wenn ein Geheimnis mehrfach abgerufen werden soll. Dieser Abruf kann dann unterbunden werden.
  • Mit der Möglichkeit, ein Geheimnis zusätzlich lokal zu ver- und entschlüsseln, besteht die Möglichkeit, ein Geheimnis auszutauschen, ohne, dass der Server dieses im Klartext lesen kann. Das verwendete Passwort kann bspw. über einen zweiten Kanal übertragen werden.
  • Dadurch, dass für die Erstellung der URL Standardverfahren eingesetzt werden, können diese lokal mit Hilfe einer einzelnen Shell-Befehlszeile erzeugt werden. Das erspart zudem die Bereitstellung einer API.

Ein weiterer Vorteil der gewählten Lösung ist, dass der Speicherbedarf recht gering ausfällt. Es muss großteilig nur die Checksumme eines tatsächlich abgerufenen Geheimnisses gespeichert werden. Geheimnisse, für die URLs erzeugt wurden, die aber nicht abgerufen werden, verbrauchen daher im Umkehrschluss auch keinen Speicherplatz.

Getestet werden kann die Anwendung unter secrets.syseleven.de - der Referenzinstallation der Anwendung. Über sie wird auch sichergestellt, dass es möglich ist, mit einem korrekten Setup ein A+ Rating im Mozilla Observatory zu erhalten.

Wenn ihr Feedback oder Verbesserungsvorschläge habt, hinterlasst einfach einen Kommentar. 🙂

Ausgetauschte Grüße, Kenny

Seite 1 von 88123...Letzte »