Skalierung im Zeitalter von „Secure Everything“
Auf der WWDC (World Wide Developer Conference) von Apple im Juni kündigte der Mobilriese an , dass ab dem 1. Januar 2017 alle Apps im App Store App Transport Security (ATS) verwenden MÜSSEN (das ist ein MUSS im RFC-Stil für Netzwerker, die mitlesen).
Im Grunde zwingt es Apps, HTTPS statt HTTP zu verwenden.
Für die Menschen bedeutet das, dass ihnen nur wenige Monate bleiben, um:
- Aktualisieren Sie ihre mobilen Apps
Das scheint offensichtlich. Schließlich besteht für mobile Apps unter iOS die Voraussetzung, dass sie HTTPS verwenden. Also, ja, das gibt es. - Unterstützt HTTPS im Backend
Dies ist vielleicht nicht so offensichtlich, aber der Sinn von HTTPS besteht darin, die Kommunikation abzusichern, was die Beteiligung von mindestens zwei Parteien voraussetzt. Bei mobilen Apps ist das eine Art Endpunkt (App, Dienst, API-Gateway), entweder vor Ort oder in der Cloud. Auch dies muss HTTPS unterstützen.
Diese zweite Anforderung ist technisch und betrieblich komplexer als die erste, da es sich hier nicht einfach um das Umlegen eines Schalters handelt. Es gibt Zertifikats- und Schlüsselverwaltung, Verteilung, Upgrades, Änderungen an Konfigurationen auf Webservern und API-Gateways, die zuvor HTTPS nicht unterstützten. Möglicherweise müssen umfangreiche Änderungen an der Infrastruktur (und Architektur) unterstützt werden. Und dann müssen auch noch betriebliche Änderungen vorgenommen werden, wie etwa die Überwachung ablaufender Zertifikate und deren Ersetzung.
Im Zeitalter der „Secure Everything“-Strategie ist Skalierung nicht nur eine Frage der Kapazität, sondern auch der betrieblichen Leistungsfähigkeit. Die betrieblichen Auswirkungen auf die Unterstützung einer sicheren App-Infrastruktur sind nicht unerheblich. Es handelt sich nicht nur um Kontrollkästchen oder eine neue Konfigurationsdatei.
1. Prozessänderungen
Wenn Sie „DevOps betreiben“ (oder auch wenn nicht), müssen Sie Ihren Bereitstellungspipelineprozess prüfen und sicherstellen, dass er die erforderlichen Komponenten zur Unterstützung von HTTPS enthält. Das bedeutet, dass Schlüssel, Zertifikate und Konfigurationen in den Prozess einbezogen werden müssen.
2. Veränderungen im Management
Zertifikate laufen ab. Und wenn sie es tun, ist es eine schlechte Sache™. Die Betriebsabteilung muss wissen, wann Zertifikate ablaufen, und sicherstellen, dass ein Prozess zum Erneuern und Bereitstellen dieser Zertifikate vorhanden ist (das ist im Wesentlichen GOTO #1 – Prozessänderung).
3. Kapazitätsänderungen
Die Verschlüsselung und Entschlüsselung sind rechnerisch nicht billig. Auch wenn sie nicht mehr so ressourcenhungrig sind wie früher, verbrauchen sichere Verbindungen immer noch mehr Ressourcen als unsichere. Bei Apps mit sehr wenigen Benutzern sehen Sie möglicherweise keinen erkennbaren Unterschied. Bei stark (gleichzeitig) genutzten Rechnern müssen Sie jedoch prüfen, welche Kapazität für eine Skalierung verfügbar ist. Und zwar nicht nur Server (virtuell oder physisch), sondern auch die Infrastruktur. Hierzu gehören API-Gateways (oder Geräte/Systeme, die sich wie API-Gateways verhalten) und möglicherweise Service-Registries (wenn Sie bereits Container und Microservices verwenden).
4. Architektonische Änderungen
Eine durchgängig sichere Verbindung kann alle Sicherheitsdienste zwischen dem Benutzer und der App lähmen und sie praktisch nutzlos machen, wenn es darum geht, zu verhindern, dass Malware oder Schadcode in Apps und Dienste gelangt, die Zugriff auf vertrauliche Daten haben. Die Fähigkeit, sichere Verbindungen abzufangen und zu überprüfen – sowohl beim Eingehen (Anfrage) als auch beim Verlassen (Antwort) – ist ein wichtiger Bestandteil einer erfolgreichen Sicherheitsstrategie. Um sicherzustellen, dass die kritische Sicherheitsinfrastruktur weiterhin über die erforderliche Sichtbarkeit verfügt, um ihre Aufgabe bei der Verhinderung von Sicherheitsverletzungen und Infektionen erfüllen zu können, sind möglicherweise architektonische Änderungen erforderlich.
Eine zweistufige Architektur, in der sichere Verbindungen vom Kernnetzwerk verwaltet werden, kann viele der betrieblichen Probleme lindern, die durch die Verteilung von Zertifikaten und Schlüsseln auf die gesamte App-Infrastruktur entstehen. Denn die sichere Verbindung kann im Kernnetz durch einen sicheren Proxy beendet werden. Die Kommunikation mit Back-End-Apps kann bei Bedarf weiterhin im Klartext erfolgen oder erneut verschlüsselt werden, um eine durchgängig sichere Kommunikation aufrechtzuerhalten. Unverschlüsselte Daten können zur weiteren Überprüfung auf Sicherheitslösungen (wie IDS/IPS) gespiegelt werden, wodurch die Investition in die vorhandene Infrastruktur erhalten bleibt. Das bedeutet einen zentralen Ort, an dem Zertifikate und Schlüssel bereitgestellt, verwaltet und überwacht werden müssen. Darüber hinaus bietet es einen strategischen Punkt im NS-Datenpfad, an dem Abfangen und Überprüfen erfolgen kann, ohne die Kommunikation zwischen Mobilgerät und App zu beeinträchtigen.
Unabhängig davon sind die Auswirkungen eines Secure Everything-Ansatzes auf die Skalierung von Apps (mobile und andere) nicht nur eine Frage der Rechenressourcen, sondern auch eine betriebliche. Und obwohl Apple zweifellos zu den Treibern dieser Veränderungen zählt, ist das Unternehmen nicht der einzige. Bedenken Sie, dass die Webbrowser-Community trotz der Eliminierung der SSL/TLS-Anforderung für HTTP/2 aus dem offiziellen Standard nur HTTP/2 über SSL/TLS unterstützt. Das bedeutet, dass Secure Everything seine Reichweite einfach weiter ausbauen wird, je mehr das Web von HTTP/1x auf HTTP/2 umsteigt.
Dieser anhaltende Vormarsch in Richtung der Beseitigung jeglicher Art unverschlüsselter Kommunikation zwischen Apps und Benutzern (per Dekret oder Funktion) wird für einige Organisationen erhebliche Prozess- und Produktänderungen erforderlich machen.