Da die Welt immer datengesteuerter wird, ist der sichere Umgang mit Benutzerdaten wichtiger denn je.
Als Entwickler sind unsere Jobs schon hart genug: Wir beschäftigen uns mit hochkomplexen und fragilen Systemen mit mehreren Fehlerpunkten, während wir menschliche Wünsche in UIs übersetzen und Backends. Die Aufgabe zu erweitern, ist eine aufkommende und wesentliche Überlegung: Datensicherheit. Und das aus gutem Grund: Wir als Kunden sind wütend, wenn unsere Daten missbraucht werden (also ist es nur fair, dass wir unseren Benutzern ein sicheres und angenehmes Erlebnis bieten), und Regierungen und Unternehmen fordern dies zur Einhaltung.
Datensicherheit als Glückssache
Was die Sicherheit erschwert, ist, dass sie mehrere Ebenen hat und zu einer Sache wird, bei der jeder die Verantwortung trägt. In einem modernen Cloud-Team steuern mehrere Teams direkt den Dateneingang/-ausgang: Entwickler, Datenbankadministratoren, Sysadmins (DevOps-Leute, wenn Sie so wollen), privilegierte Backoffice-Benutzer und so weiter. Diese Rollen/Teams können schnell die Augen schließen und die Datensicherheit als das Problem der anderen betrachten. Die Realität ist jedoch, dass sie sich um ihre eigenen Welten kümmern müssen, da ein Datenbankadministrator die App-Sicherheitsseite nicht kontrollieren kann, a DevOps Person kann absolut nichts über den Backoffice-Zugriff und so weiter tun.
Entwickler und Datensicherheit
Trotzdem haben Entwickler die größte Zugriffsfläche, wenn es um Daten geht: Sie erstellen jeden Teil der App; sie verbinden sich mit verschiedenen Backend-Diensten; die Fährzugangsmarken hin und her; sie haben den gesamten Datenbank-Cluster zum Lesen/Schreiben auf ihren Befehl; die Apps, die sie schreiben, haben uneingeschränkten Zugriff auf alle Teile des Systems (zum Beispiel hat eine Django-App in der Produktion alle Berechtigungen, um die gesamte S3-Sammlung der letzten zehn Jahre zu löschen oder zu löschen) und so weiter. Infolgedessen besteht die höchste Wahrscheinlichkeit von Nachlässigkeit oder Aufsicht in Bezug auf die Sicherheit auf Quellcodeebene und liegt in der direkten Verantwortung des Entwicklers.
Jetzt ist Datensicherheit ein bodenloses Kaninchenloch, und ich kann auf keinen Fall in einem einzigen Beitrag an der Oberfläche kratzen. Ich möchte jedoch die grundlegende Terminologie behandeln, die Entwickler kennen müssen, um ihre Apps sicher zu halten. Betrachten Sie es als App Data Security 101.
Lassen Sie uns loslegen!
Hashing
Wenn Sie eine sehr strenge Definition wünschen, gibt es immer Wikipedia , aber vereinfacht gesagt ist Hashing der Prozess der Konvertierung von Daten in eine andere Form, in der die Informationen unlesbar sind. Zum Beispiel mit dem bekannten (und sehr unsicheren) Verfahren von Base64-Kodierung, die Zeichenfolge „Ist mein Geheimnis bei dir sicher?“ kann in „SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/“ umgewandelt („gehasht“) werden. Wenn Sie beispielsweise anfangen, Ihr persönliches Tagebuch im Base64-Format zu schreiben, kann Ihre Familie Ihre Geheimnisse nicht lesen (es sei denn, sie wissen, wie man von Base64 entschlüsselt)!
Diese Idee des Verschlüsselns der Daten wird beim Speichern von Passwörtern, Kreditkartennummern usw. in Web-Apps verwendet (eigentlich sollte es in allen Arten von Apps verwendet werden). Die Idee ist natürlich, dass der Angreifer im Falle einer Datenpanne nicht in der Lage sein sollte, die Passwörter, Kreditkartennummern usw. zu verwenden, um tatsächlichen Schaden anzurichten. Für dieses Hashing werden sehr robuste und ausgeklügelte Algorithmen verwendet; so etwas wie Base64 wird ein Witz sein und wird sofort von jedem kaputt gemacht Angreifer.
Beim Passwort-Hashing wird eine kryptografische Technik verwendet, die als Einweg-Hashing bekannt ist. Dies bedeutet, dass die Daten zwar verschlüsselt, aber nicht entschlüsselt werden können. Woher weiß die App dann, dass es Ihr Passwort ist, wenn Sie sich anmelden? Nun, es verwendet den gleichen Prozess und vergleicht die verschlüsselte Form dessen, was Sie gerade als Passwort eingegeben haben, mit der verschlüsselten Form, die in der Datenbank gespeichert ist; wenn sie übereinstimmen, dürfen Sie sich einloggen!
Wo wir gerade beim Thema Hashes sind, hier ist etwas Interessantes. Wenn Sie jemals Software oder Dateien aus dem Internet herunterladen, wurden Sie möglicherweise aufgefordert, die Dateien vor der Verwendung zu überprüfen. Wenn Sie zum Beispiel die Ubuntu Linux ISO, die Download-Seite zeigt Ihnen eine Option zur Überprüfung Ihres Downloads; Wenn Sie darauf klicken, öffnet sich ein Popup:
Das Popup fordert Sie auf, einen Befehl auszuführen, der im Wesentlichen die gesamte gerade heruntergeladene Datei hackt und das Ergebnis mit der Hash-Zeichenfolge vergleicht, die Sie auf der Download-Seite sehen: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5. Diese Konvertierung erfolgt mit dem SHA256-Algorithmus, deren Erwähnung Sie in den letzten Teilen des Befehls sehen können: shasum -a 256 --check.
Die Idee ist, dass, wenn der durch Ihre Prüfung erzeugte Hash unterschiedlich ist, dies bedeutet, dass sich jemand in Ihren Download eingemischt und Ihnen stattdessen eine kompromittierte Datei bereitgestellt hat.
Einige bekannte Namen, die Sie im Bereich des Passwort-Hashings hören werden, sind MD5 (unsicher und jetzt veraltet), SHA-1 und SHA-2 (Familien von Algorithmen, zu denen SHA-256 ebenso wie SHA-512 gehört). SKRYPT, BCRYPT usw.
Salting
Alle Arten von Sicherheit sind ein Katz-und-Maus-Spiel: Der Dieb lernt das aktuelle System und entwickelt einen neuartigen Knack, der auffällt, und die Schlosser verbessern ihr Spiel und so weiter und so weiter. Kryptographie ist keine Ausnahme. Während die Umwandlung von Hashes in Passwörter unmöglich geworden ist, haben Angreifer im Laufe der Zeit ausgeklügelte Techniken entwickelt, die intelligente Vermutungen mit reiner Rechenleistung; Als Ergebnis, neun mal zehn, können sie das richtige Passwort vorhersagen, wenn nur der Hash gegeben ist.
Als Ergebnis hat sich die Technik des Salzens entwickelt. Dies bedeutet lediglich, dass die Hash-Berechnung eines Passworts (oder anderer Daten) auf der Grundlage einer Kombination von zwei Dingen erfolgt: den Daten selbst sowie einer neuen zufälligen Zeichenfolge, die der Angreifer nicht erraten kann. Also, mit Salting, wenn wir das Passwort hashen wollen superman009, wir würden zuerst eine zufällige Zeichenfolge als "Salz" auswählen, sagen wir: bCQC6Z2LlbAsqj77und führen Sie dann die Hash-Berechnung auf superman009-bCQC6Z2LlbAsqj77. Der resultierende Hash weicht von den üblichen Strukturen ab, die vom Algorithmus erzeugt werden, was den Spielraum für intelligente Daten erheblich einschränkt Reverse Engineering oder Vermutungen.
Sowohl Hashing als auch Salting sind unglaublich komplizierte Domänen und werden ständig weiterentwickelt. Als Anwendungsentwickler würden wir uns also nie direkt mit ihnen auseinandersetzen. Aber es würde uns sehr helfen, wenn wir diese kennen und bessere Entscheidungen treffen könnten. Wenn Sie beispielsweise ein altes PHP-Framework Wenn Sie zufällig feststellen, dass MD5-Hashes für Passwörter verwendet werden, wissen Sie, dass es an der Zeit ist, eine weitere Passwortbibliothek in den Erstellungsprozess des Benutzerkontos einzufügen.
Keys
Der Begriff „Schlüssel“ wird Ihnen oft im Zusammenhang mit Verschlüsselung begegnen. Bisher haben wir uns mit Passwort-Hashing oder Einwegverschlüsselung befasst, bei der wir die Daten irreversibel konvertieren und die ursprüngliche Form zerstören. Dies ist eine schlechte Idee für den praktischen Alltag – ein Dokument, das so sicher geschrieben und per E-Mail verschickt wird, dass es nie gelesen werden kann, nützt nichts! Daher möchten wir Daten so verschlüsseln, dass die Informationen beim Sender und beim Empfänger offen sein sollen, während sie jedoch übertragen oder gespeichert werden, sollten sie unlesbar sein.
Dafür existiert in der Kryptographie das Konzept eines „Schlüssels“. Es ist genau das, wonach es klingt: der Schlüssel zu einem Schloss. Die Person, der die Informationen gehören, verschlüsselt sie mithilfe eines Geheimnisses, das als Schlüssel bezeichnet wird. Wenn der Empfänger/Angreifer nicht über diesen Schlüssel verfügt, ist es unmöglich, die Daten zu entschlüsseln, egal wie ausgefeilt ihre Algorithmen sein mögen.
Rotating Keys
Während Schlüssel eine Verschlüsselung möglich und zuverlässig machen, bergen sie die Risiken, die Kennwörter bergen: Wenn jemand den Schlüssel kennt, ist das ganze Spiel aus. Stellen Sie sich ein Szenario vor, in dem jemand einen Teil eines Dienstes wie GitHub hackt (wenn auch nur für ein paar Sekunden) und an 20 Jahre alten Code gelangen kann. Im Code finden sie auch die kryptografischen Schlüssel, die zum Verschlüsseln der Unternehmensdaten verwendet werden (eine schreckliche Praxis, Schlüssel zusammen mit dem Quellcode zu speichern, aber Sie wären überrascht, wie oft dies passiert!). Wenn sich das Unternehmen nicht die Mühe gemacht hat, seine Schlüssel (genau wie Passwörter) zu ändern, kann derselbe Schlüssel verwendet werden, um Chaos anzurichten.
Als Ergebnis hat sich die Praxis des häufigen Wechselns von Tonarten weiterentwickelt. Dies wird als Schlüsselrotation bezeichnet, und wenn Sie eine seriöse Cloud verwenden PaaS sollte es als automatisierter Dienst verfügbar sein.
AWS hat dafür beispielsweise einen dedizierten Service namens AWS-Schlüsselverwaltungsservice (KMS). Ein automatisierter Service erspart Ihnen das mühsame Ändern und Verteilen von Schlüsseln auf alle Server und ist heutzutage bei großen Bereitstellungen ein Kinderspiel.
Public Key Cryptography
Wenn Sie das ganze bisherige Gerede über Verschlüsselung und Schlüssel für sehr umständlich halten, haben Sie Recht. Schlüssel sicher aufzubewahren und weiterzugeben, sodass nur der Empfänger die Daten sehen kann, führt zu logistischen Problemen, die die heutige sichere Kommunikation nicht ermöglicht hätten. Aber dank der Public-Key-Kryptografie können wir sicher online kommunizieren oder Einkäufe tätigen.
Diese Art der Kryptographie war ein großer mathematischer Durchbruch und der einzige Grund, warum das Internet nicht vor Angst und Misstrauen auseinanderfällt. Die Details des Algorithmus sind kompliziert und sehr mathematisch, daher kann ich sie hier nur konzeptionell erklären.
Die Kryptografie mit öffentlichen Schlüsseln basiert auf der Verwendung von zwei Schlüsseln, um Informationen zu verarbeiten. Einer der Schlüssel heißt Private Key und soll mit Ihnen privat bleiben und niemals mit jemandem geteilt werden; der andere heißt Public Key (woher der Name der Methode kommt) und soll öffentlich veröffentlicht werden. Wenn ich Ihnen Daten sende, muss ich zuerst Ihren öffentlichen Schlüssel abrufen und die Daten verschlüsseln und an Sie senden. an Ihrem Ende können Sie die Daten mit Ihrer Kombination aus privatem Schlüssel und öffentlichem Schlüssel entschlüsseln. Solange Sie Ihren privaten Schlüssel nicht versehentlich preisgeben, kann ich Ihnen verschlüsselte Daten senden, die nur Sie öffnen können.
Das Schöne an dem System ist, dass ich Ihren privaten Schlüssel nicht kennen muss und jeder, der die Nachricht abfängt, nichts tun kann, um sie zu lesen, obwohl er Ihren öffentlichen Schlüssel hat. Wenn Sie sich fragen, wie das überhaupt möglich ist, ergibt sich die kürzeste und untechnischste Antwort aus den Eigenschaften der Multiplikation von Primzahlen:
Es ist schwierig für Computer, große Primzahlen zu faktorisieren. Wenn der Originalschlüssel also sehr groß ist, können Sie sicher sein, dass die Nachricht auch in Tausenden von Jahren nicht entschlüsselt werden kann.
Transport Layer Security (TLS)
Sie wissen jetzt, wie die Kryptografie mit öffentlichen Schlüsseln funktioniert. Dieser Mechanismus (den öffentlichen Schlüssel des Empfängers zu kennen und ihm damit verschlüsselte Daten zu senden) ist der Grund für die Popularität von HTTPS und führt dazu, dass Chrome sagt: „Diese Website ist sicher“. Was passiert ist, dass der Server und der Browser den HTTP-Datenverkehr (denken Sie daran, Webseiten sind sehr lange Textstrings, die Browser interpretieren können) mit den öffentlichen Schlüsseln des anderen verschlüsseln, was zu Secure HTTP (HTTPS) führt.
Bildnachweis: MozillaEs ist interessant festzustellen, dass die Verschlüsselung nicht auf der Transportschicht selbst erfolgt; das OSI-Modell sagt nichts über das Verschlüsseln von Daten aus. Es ist nur so, dass die Daten von der Anwendung (in diesem Fall vom Browser) verschlüsselt werden, bevor sie an die Transportschicht übergeben werden, die sie später an ihrem Ziel ablegt, wo sie entschlüsselt werden. Der Prozess umfasst jedoch die Transportschicht, und am Ende des Tages führt alles zu einem sicheren Transport von Daten, sodass sich der lose Begriff „Transportschichtsicherheit“ herumgesprochen hat.
Vielleicht stoßen Sie sogar auf den Begriff Sicherer Socket Layer (SSL) in manchen Fällen. Es ist das gleiche Konzept wie TLS, außer dass SSL viel früher entstand und jetzt zugunsten von TLS eingestellt wird.
Full Disk Encryption
Manchmal sind die Sicherheitsbedürfnisse so groß, dass nichts dem Zufall überlassen werden kann. Beispielsweise können Regierungsserver, auf denen alle biometrischen Daten eines Landes gespeichert sind, nicht wie normale Anwendungsserver bereitgestellt und betrieben werden, da das Risiko zu hoch ist. Für diese Anforderungen reicht es nicht aus, dass Daten nur bei der Übertragung verschlüsselt werden; es muss auch im Ruhezustand verschlüsselt werden. Dafür, vollständige Festplattenverschlüsselung wird verwendet, um die gesamte Festplatte zu verschlüsseln, um sicherzustellen, dass die Daten auch bei einem physischen Angriff sicher sind.
Es ist wichtig zu beachten, dass die vollständige Festplattenverschlüsselung auf Hardwareebene durchgeführt werden muss. Denn wenn wir die gesamte Festplatte verschlüsseln, wird auch das Betriebssystem verschlüsselt und kann beim Starten des Computers nicht ausgeführt werden. Die Hardware muss also verstehen, dass der Festplatteninhalt verschlüsselt ist, und muss die Entschlüsselung im laufenden Betrieb durchführen, während sie angeforderte Festplattenblöcke an das Betriebssystem weitergibt. Aufgrund dieser zusätzlichen Arbeit führt Full Disk Encryption zu langsameren Lese-/Schreibvorgängen, die von den Entwicklern solcher Systeme berücksichtigt werden müssen.
End-to-End Encryption
Angesichts der anhaltenden Datenschutz- und Sicherheitsalpträume großer sozialer Netzwerke kennt heutzutage niemand den Begriff „End-to-End-Verschlüsselung“, auch wenn sie nichts mit der Erstellung oder Wartung von Apps zu tun haben.
Wir haben bereits gesehen, dass Full Disk Encryption die ultimative kugelsichere Strategie bietet, aber für den alltäglichen Benutzer ist es nicht bequem. Ich meine, stellen Sie sich vor, Facebook möchte, dass die Telefondaten, die es generiert und in Ihrem Telefon speichert, sicher sind, aber es kann nicht darauf zugreifen, Ihr gesamtes Telefon zu verschlüsseln und alles andere zu sperren.
Aus diesem Grund haben diese Unternehmen mit einer Ende-zu-Ende-Verschlüsselung begonnen, d. h. Daten werden verschlüsselt, wenn sie von der App erstellt, gespeichert oder übertragen werden. Mit anderen Worten, selbst wenn die Daten den Empfänger erreichen, sind sie vollständig verschlüsselt und nur über das Telefon des Empfängers zugänglich.
Beachten Sie, dass die Ende-zu-Ende-Verschlüsselung (E2E) keine mathematischen Garantien bietet, wie dies bei der Kryptografie mit öffentlichen Schlüsseln der Fall ist. Es ist nur eine Standardverschlüsselung, bei der der Schlüssel beim Unternehmen gespeichert wird, und Ihre Nachrichten sind so sicher, wie das Unternehmen entscheidet.
Fazit
Die meisten dieser Begriffe haben Sie wahrscheinlich schon gehört. Vielleicht sogar alle. Wenn ja, empfehle ich Ihnen, Ihr Verständnis dieser Konzepte zu überdenken und zu bewerten, wie ernst Sie sie nehmen. Denken Sie daran, dass die App-Datensicherheit ein Krieg ist, den Sie jedes Mal (und nicht nur einmal) gewinnen müssen, da bereits ein einziger Verstoß ausreicht, um ganze Branchen, Karrieren und sogar Leben zu zerstören!
