Auswirkungen der Applications auf Leistung und Sicherheit
In der guten alten Zeit konnten sich Unternehmen auf die Verwendung strategisch eingesetzter Proxys verlassen, um die Leistung von Applications zu verbessern. Der Grund hierfür liegt darin, dass herkömmliche Applications – Monolithen und Drei-Schichten-Architekturen – im Allgemeinen einen einzigen Datenpfad zwischen Client und Server verwendeten.
Vereinfacht ausgedrückt wurde für alle Inhalte – ob statisch oder dynamisch, textbasiert oder Bilder – nur ein einziger Weg eingeschlagen. Das bedeutet, dass ein Application Delivery Controller (Proxy) zwischen ihnen sitzen und mit dem richtigen die Leistung optimieren könnte. Dies wurde – und wird übrigens immer noch – oft durch die Anpassung verschiedener IP-, TCP- und sogar HTTP-Schaltflächen und -Regler erreicht. Wir können den Einsatz dieser Art von Techniken durch den Einsatz von Application wie Caching, Komprimierung und inhaltsspezifischen Beschleunigungstechniken sehen.
Doch moderne Applications sind nicht mehr autark. Laut Sonatype bestehen sie mittlerweile größtenteils (80–90 %) aus Komponenten von Drittanbietern (und zunehmend auch aus Open Source). Dies erkennen Sie an der Anzahl der Skripts und anderen injizierbaren Codes in Applications. Manchmal wird dieses Skript remote ausgeführt und gibt ein Bild, eine Anzeige oder andere Inhalte wie Webfonts und Sprites zurück. In anderen Fällen wird das Skript selbst zur Laufzeit geladen und innerhalb der Grenzen des Browsers ausgeführt, beispielsweise bei jQuery.
Dies wird als Komponentenbildung oder, wenn Sie so wollen, Atomisierung bezeichnet. Dabei handelt es sich um die Aufteilung von Applications in viele kleinere Teile. Wir nennen sie Komponenten auf der Clientseite, weil sie im Allgemeinen im selben Bereich ausgeführt werden. Auf der Serverseite bezeichnen wir sie zunehmend als Microservices und stellen sie in Containern bereit. In beiden Fällen sind die Auswirkungen ähnlich – wir erhalten am Ende eine unvorhersehbare Anzahl von Datenpfaden, die sich direkt auf die Leistung auswirken.
Grundsätzlich haben Sie die Kontrolle über einen Datenpfad , der vielleicht 20 % Ihrer Application ausmacht. Das bedeutet, dass Sie nur sehr wenig Kontrolle über das Benutzererlebnis haben, da Sie nur sehr wenig Kontrolle über die Leistung haben.
Das gilt auch für die Sicherheit – danke für den Hinweis. Der Punkt ist, dass wir schnell lernen, clientseitige Codetechniken zu nutzen, um die Sicherheit zu verbessern. Das wirkt sich nicht so positiv auf die Leistung aus, da die meisten Apps entweder mobil oder für das Web gedacht sind und keine dieser Apps wirklich die Möglichkeit oder Fähigkeit bietet, am Netzwerk-Stack herumzubasteln.
Eine Möglichkeit, dieses Problem zu bekämpfen, besteht darin, die Kontrolle zurückzugewinnen. Das Coole an der Rückerlangung der Kontrolle ist, dass Sie auch von den Sicherheitsnebeneffekten profitieren können.
Alle gewinnen: RISIKO REDUZIEREN und LEISTUNG VERBESSERN
Wenn Ihre Apps dazu neigen, Komponenten dynamisch von externen Sites zu laden, hören Sie damit auf. Hör jetzt damit auf. Dies ist sowohl ein Sicherheits- als auch ein Leistungsproblem. Sie erteilen einem Skript aus einer externen Quelle implizit freie Hand für die Ausführung im Kontext Ihrer Application. Vertrauen Sie mir, ein Benutzer wird im Falle einer Sicherheitsverletzung nicht in der Lage sein, zwischen Ihren Komponenten und den extern geladenen zu unterscheiden. Wie wir aus dem jüngsten Aufruhr im Zusammenhang mit der Runc-Container-Sicherheitslücke gelernt haben, birgt das Einschleusen von Schadcode in Ressourcen, die aus Registern oder Websites Dritter geladen werden, ein Sicherheitsrisiko.
Wenn es sich um ein Skript handelt, ist es besser, es zu klonen und von Ihrer eigenen Infrastruktur aus bereitzustellen. Sie profitieren von der Risikoreduzierung durch Beibehaltung der Kontrolle und von der Möglichkeit, Regler und Schalter so zu betätigen, dass die Leistung für Ihre Benutzer verbessert wird. Hierzu zählt DNS, das nachweislich den größten (und häufig negativen) Einfluss auf die Application hat. Wenn Sie Komponenten von externen Sites beziehen, verlassen Sie sich darauf, dass deren DNS-Infrastruktur die Erwartungen erfüllt. Durch das Abrufen von Komponenten von Ihren eigenen Sites können Sie die Auswirkungen erheblich reduzieren, da der lokale DNS-Cache des Benutzers für Sie arbeitet.
Durch das Hosten von Skripts von Ihrer eigenen Site aus können Sie außerdem TCP-Optimierungen oder SSL/TLS-Offload oder allgemeine App-Beschleunigungstechniken einsetzen, um die Leistung insgesamt zu verbessern. Darüber hinaus besteht die Möglichkeit, Sicherheitsscans für diese Skripte durchzuführen, um sicherzustellen, dass sich darin keine Überraschungen verbergen.
Die Komponentenbildung eignet sich hervorragend für die Entwicklung und trägt zweifellos dazu bei, die Wertschöpfungszeit zu verkürzen. Dies kann sich jedoch negativ auf die Leistung und Sicherheit auswirken. Seien Sie sich der Risiken für die Sicherheit und die Benutzerzufriedenheit bewusst und wissen Sie, wie Sie ihnen begegnen können.