Anwendungssicherheit

Die Wahrheit über Anwendungssicherheit ist, dass es eigentlich gar nicht um Anwendungssicherheit geht. Sichere Programmierpraktiken sind eine gute Sache – bitte bereinigt eure Eingaben, Leute. Aber eigentlich ist das vielleicht nur der kleinste Teil eines viel größeren Cybersicherheitspuzzles.

Das grundlegende Ziel der Anwendungssicherheit ist, dass du nicht gehackt werden willst und dass deine Anwendung(en) nicht ausfallen.

Leider gibt es unglaublich viele Leute, die dich aus dem einen oder anderen Grund hacken und deine Systeme lahmlegen wollen. Und das ist nicht mal persönlich gemeint. Es ist ihr Job. Sie werden dafür bezahlt. Und ihre Chefs wollen ihre Zeit nicht unnötig verschwenden. 

Wie jeder gute Profi automatisieren diese Hacker ihre Arbeit. 

Du musst nichts Besonderes sein, um ein Ziel zu sein. Du musst keine Milliarde auf dem Konto haben. Und du kannst dich nicht in der Menge verstecken. Computer sind schnell. Oft schneller, als wir uns intuitiv vorstellen. Selbst wenn du etwas hinter einer Milliarde Permutationen versteckt hast, braucht ein Computer weniger als eine Sekunde, um jede einzelne auszuprobieren.

Ich liebe diesen Witz: Ein paar Touristen spazieren durch den Dschungel, als sie einen wunderschönen, hungrig aussehenden Tiger entdecken. „Rettet euch!“, ruft jemand. Und alle, bis auf einen, rennen los. Er bleibt stehen, holt Laufschuhe aus seinem Rucksack und zieht sie an. Ein anderer seiner Kameraden, der noch rennt, ruft ihm zu: „Bist du verrückt?! Glaubst du etwa, du kannst einen Tiger überholen?“ – Er antwortet: „Ich muss den Tiger nicht überholen, ich muss nur dich überholen.“

Dieser Witz wurde verwendet, um den Leuten zu erklären, dass sie keine „leichte Beute“ sein sollten – man sollte sich stark genug geben, damit der hungrige Tiger zum nächsten leckeren Ziel weiterzieht. 

Aber wie du vielleicht weißt, ist der große Killer der Wälder nicht der beeindruckende Tiger. Es sind die Mücken, die dich erwischen. Es gibt genug Ziele für alle durstigen Mücken und genug Mücken, um jeden zu stechen, der nicht bedeckt ist.

Und obwohl einige Systeme offensichtlich wichtiger sind als andere und mehr Schutz verdienen – nicht jedes Computersystem auf der Welt enthält nukleare Startcodes –, brauchen alle einen gewissen Schutz. Die Frage ist nicht, ob du angegriffen wirst, sondern wann. Und „wann“ ist meistens „die ganze Zeit“ und ein paar Minuten, nachdem dein System live gegangen ist (und möglicherweise sogar schon vorher, darauf kommen wir noch zu sprechen).

Nehmen wir mal als gegeben hin, dass du ein seriöser Softwareentwickler bist und sichere Programmierpraktiken anwendest. Du bereinigst deine Eingaben, wie es dir deine Eltern beigebracht haben. Du minimierst die Angriffsfläche. Du schaffst mehrschichtige Verteidigung. Du baust dein System so auf, dass es kurzlebige Geheimnisse nutzt (damit sie natürlich sowieso nicht auf Festplatten herumliegen). 

Das Problem ist, dass Software an sich nicht viel bewirkt. Oder gar nichts. Um nützliche Dinge zu tun, braucht sie tatsächlich eine ganze Menge mehr. Eine Möglichkeit, sie zu erstellen – einschließlich ihrer Abhängigkeiten. Einen Ort, an dem sie erstellt werden kann. Konfiguration. Manchmal mit Geheimnissen (denn auch wenn du nur kurzlebige verwendest – die API, die du nutzt, verlangt vielleicht einen statischen API-Schlüssel). Zugrundeliegende Betriebssysteme mit einem Netzwerkstack – der sie hoffentlich nur so offenlegt, wie sie offenlegt werden sollen. Datenbanken. Nachrichtenqueues. Caches. Und dann sind da noch die Daten. Daten, die ein Vektor sein können (Benutzernamen und Passwörter sind auch Daten).

Wenn man es sich genau ansieht, könnte in jedem trivialen System und in jeder Zeile Code, die ausgeführt wird, ein Sicherheitsproblem verborgen sein. Stellen wir uns eine typische Ruby-on-Rails-Anwendung vor:

• Typische Rails-Anwendung: 15.443 Zeilen zum Programmieren. 
• Ruby on Rails: 338.728 Codezeilen. 
• Standardabhängigkeiten von Ruby on Rails: 1.161.724 Codezeilen. 
• Postgres: 1.491.985 Codezeilen. 
• Linux: 34.279.868 Zeilen Code. 

Das winzige grüne Quadrat ist dein Programm. Auf einem echten Bild würdest du es gar nicht sehen können. Das ist ohne SystemD: dafür kommen allein schon 1,3 Millionen Zeilen hinzu. Und das ist ohne Distribution. Ohne OpenSSL usw. – und bevor wir all den anderen Code berücksichtigen, der beim Deployen und Ausführen deiner Anwendung ins Spiel kommt. Dein Observability-Stack. Deine Orchestrierungstools.

Quelle: https://xkcd.com/2347/ 

Du kennst XKCD 2347 … das ist eine ähnliche Situation – nur umgekehrt. Und wenn wir beide Bilder miteinander verknüpfen, ist die Wahrheit, dass der Großteil der Anwendung nicht von dir geschrieben wurde – sie wird irgendwo eine Schwachstelle haben. Und selbst das ist eine eher statische Sichtweise. Die tatsächliche Oberfläche sieht anders aus.

Menschen sind das schwächste Glied

Selbst die sicherste Software kann durch einen einzigen Fehler einer Person oder durch erfolgreiches Social Engineering untergraben werden. Die Aufklärung der Nutzer über bewährte Sicherheitspraktiken ist genauso wichtig, wenn nicht sogar wichtiger als die integrierten Sicherheitsfeatures der Software.

Die Infrastruktur ist entscheidend

Selbst wenn eine Anwendung sicher ist, muss auch die Infrastruktur, auf der sie läuft, sicher sein. Dazu gehören die Server, das Netzwerk und sogar die physischen Einrichtungen, in denen die Hardware untergebracht ist. Eine Sicherheitslücke in einem dieser Bereiche kann die Anwendungssicherheit untergraben.

Ganzheitlicher Sicherheitsansatz

Eine wirklich sichere Umgebung berücksichtigt nicht nur die Anwendungssicherheit, sondern auch die Netzwerksicherheit, die Endpunktsicherheit, das Identitäts- und Zugriffsmanagement, die Datensicherheit und vieles mehr. All diese Komponenten arbeiten zusammen.

Es geht um Risikomanagement

Absolute Sicherheit ist unmöglich. Es geht darum, Risiken zu verstehen, sie zu priorisieren und effektiv zu managen. Dazu gehören regelmäßige Sicherheitsbewertungen, Überwachung und ein proaktiver Umgang mit potenziellen Schwachstellen.

Ein kontinuierlicher Prozess

Sicherheit ist keine einmalige Angelegenheit. Jeden Tag werden neue Schwachstellen entdeckt, und Angreifer entwickeln ihre Techniken ständig weiter. Regelmäßige Updates, Patches und Überwachung sind unerlässlich, um sicherzustellen, dass die Sicherheitsmaßnahmen immer auf dem neuesten Stand sind.

Datenschutzaspekte

Eine sichere Anwendung respektiert auch die Privatsphäre der Nutzer. Manchmal können die Grenzen zwischen Sicherheit und Datenschutz verschwimmen. So kann beispielsweise die Erfassung von Nutzerdaten zwar die Sicherheitsmaßnahmen verbessern, aber auch die Datenschutzrechte der Nutzer verletzen.

Compliance und Vorschriften

Anwendungssicherheit umfasst auch die Einhaltung verschiedener Vorschriften und Standards, die je nach Branche und Region variieren können. Dazu gehören beispielsweise die DSGVO für den Datenschutz, PCI DSS für die Sicherheit von Zahlungskarten, HIPAA für Gesundheitsdaten und vieles mehr.

Risiken durch Anbieter und Dritte

Eine Anwendung mag sicher sein, aber wenn sie mit Diensten oder Anbietern von Drittanbietern integriert ist, die es nicht sind, wird das gesamte System anfällig. Das bedeutet, dass zur Sicherung einer Anwendung auch die Gewährleistung der Sicherheit aller ihrer Verbindungen und Integrationen gehört.

Die harte Realität ist, dass dieses Gewirr aus Risiken und Bedenken bei der modernen Anwendungsbereitstellung weitgehend unvermeidbar ist. Wir können nicht in allem Experten sein oder all diese sich ständig verändernden Faktoren um uns herum überwachen.

Letztendlich sind wir besser dran, je eher wir das akzeptieren, und die Wahl einer sicherheitsorientierten cloud-basierten Anwendungsplattform wie Upsun macht das um einiges einfacher. Upsun bietet Fachwissen zur Sicherung der Infrastruktur, stützt sich auf klare Definitionen zur Festlegung der Zugriffskontrolle und verwaltet Dienste kontinuierlich im Hintergrund, um Risiken zu minimieren und stets die Compliance zu gewährleisten – selbst bei den sensibelsten Daten. 

Das Programmieren zu schützen, das du nicht selbst ausführst, ist schwierig – aus vielen verschiedenen Gründen. Lerne, was du kannst, und halte dich und dein Team so gut wie möglich über Best Practices auf dem Laufenden. Ansonsten akzeptiere, dass wir nicht alle Experten sein können, kontrolliere, was du kannst, so streng wie möglich, und bedenke, dass in Sachen Infrastruktur und DevOps ein Experte wie Upsun deine Geheimwaffe sein könnte.