Kontext ist König

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Dinge für Verbraucher. Dinge für Unternehmen. Dinge für die Fertigung.

Smartphones. Tablets. Phablets. Laptops. Desktop-PCs.

Rechenintensiv. Netzwerkintensiv. Speicherintensiv.

Zuhause. Arbeit. Restaurant. Auto. Park. Hotel.

Die Rahmenbedingungen verändern sich auf beiden Seiten des Geschäftsbetriebs – bei Anwendungen und Clients. Der Begriff „Benutzer“ bezeichnet nicht mehr nur einen Menschen. Er umfasst auch Systeme und Geräte, die automatisch Verbindungen herstellen, Daten austauschen und mit Anwendungen im gesamten Rechenzentrum interagieren.

Betrachten wir beispielsweise den aufkommenden Architekturtrend der Microservices, bei dem monolithische Anwendungen in ihre einzelnen Bestandteile zerlegt werden. Jeder Bestandteil ist ein eigenständiger Dienst und stellt eine API (Schnittstelle) bereit, über die andere Bestandteile (Dienste) und „Benutzer“ kommunizieren können.

Gehören Sie nicht zu den 36 %, die mit Microservices experimentieren? (Typesafe, 2015) Auch wenn Sie an bewährten Anwendungsarchitekturen festhalten, schützt Sie das nicht vor den Auswirkungen der zunehmenden Vielfalt der „Nutzer“ – insbesondere, wenn Sie in das Internet der Dinge einsteigen. Unseren Daten zufolge tun dies einige von Ihnen: 22 % aller Befragten sind der Ansicht, dass es in den nächsten zwei bis fünf Jahren von strategischer Bedeutung sein wird, und 15 % verschaffen sich einen Vorsprung, indem sie planen, in den nächsten zwölf Monaten Technologien zur Unterstützung des IoT anzuschaffen.

Das bedeutet, dass „Dinge“ wie „Benutzer“ betrachtet werden müssen, da sie ihre eigenen spezifischen Bedürfnisse und Anforderungen in Bezug auf Sicherheit und Leistung haben – ganz zu schweigen von der Verfügbarkeit.

Das bedeutet, dass Netzwerk- und Anwendungsdienste, die eine immer vielfältigere Palette von Anwendungen für eine wachsende Zahl von Clients an immer mehr Standorten bereitstellen, zwischen einem menschlichen Benutzer und einem vernetzten Gerät unterscheiden können müssen. Um die Leistung zu optimieren und die Sicherheit zu gewährleisten, müssen die für Leistung und Sicherheit zuständigen Dienste unbedingt in der Lage sein, unter Berücksichtigung der jeweils aktuellen Variablen zum richtigen Zeitpunkt die richtige Richtlinie anzuwenden.

Das bedeutet, dass sie den Datenverkehr (also Daten und Kommunikation im Anwendungskontext) im Gesamtzusammenhang der Transaktion verwalten müssen: unter Berücksichtigung des Benutzers, der Anwendung und des Zwecks, zu dem die Kommunikation hergestellt werden soll.

Kontext lässt sich ähnlich verstehen wie die fünf W-Fragen, die Sie vielleicht einmal gelernt haben (wenn Sie alt genug sind – und nein, Sie müssen es nicht zugeben, wenn Sie nicht möchten) und die bei der grundlegenden Informationsbeschaffung gestellt werden: Wer, was, wo, wann und warum? Indem Sie den Datenverkehr untersuchen und Antworten auf all diese Fragen ermitteln, können Sie genügend Kontext zusammentragen, um angemessen darüber zu entscheiden, wie mit dem Datenaustausch verfahren werden soll. Blockieren. Zulassen. Scannen. Bereinigen. Optimieren. Weiterleiten. Genau solche Aufgaben übernehmen Anwendungsdienste „im Netzwerk“ – und sie erledigen sie besser und effektiver, wenn sie dabei den Kontext des Datenaustauschs berücksichtigen.

• Wer
  Identifiziert den Benutzer. Handelt es sich um einen Menschen? Wenn ja, um einen Unternehmens- oder Privatkunden? Ist es ein Gerät oder eine andere App? Wenn ja, um welches Gerät und welche App? Meine intelligente Glühbirne hat zwar möglicherweise Zugriff auf eine App zur Datenberichterstattung, aber nicht auf die Buchhaltungssysteme.
• Was
  Was tun sie? Senden sie Daten? Fordern sie Daten an? Führen sie eine Suche durch? HTTP enthält eine Fülle von Informationen, anhand derer sich dies ohne tiefgreifende Analyse feststellen lässt. Handelt es sich um einen HTTP-POST- oder GET-Request? Um UPDATE oder DELETE? Schon allein der Status kann uns Hinweise auf den Zweck dieses Austauschs geben.
• Wo
  Von wo aus tun sie es? Sind sie zu Hause? In der Unternehmenszentrale? Im Starbucks auf der anderen Straßenseite oder am anderen Ende der Welt? In einem lokalen Netzwerk oder über das Internet? Geolokalisierung ist ein beliebtes Mittel, um den Zugriff auf Apps, Ressourcen und Daten einzuschränken. Bei der Bereitstellung von Apps für Benutzer spielt der Standort unabhängig vom App-Typ eine wichtige Rolle, insbesondere wenn Unternehmensrichtlinien den Zugriff auf bestimmte Arten von Daten oder Apps von öffentlichen Orten wie dem Flughafen oder dem örtlichen Starbucks aus untersagen.
• Wann
  Wie spät ist es? Und noch wichtiger: Wie spät ist es sowohl hier als auch am Standort des Benutzers? Versucht die Person um 3 Uhr morgens von einem Ort aus auf ein System zuzugreifen, an dem es 8 Uhr morgens ist? Beispielsweise wissen wir aus Untersuchungen dass der Bot-Traffic außerhalb der Geschäftszeiten zwischen 18 und 21 Uhr deutlich zunimmt. Wir könnten diese Daten mit der Information darüber, „wer“ zugreift, verknüpfen und sofort feststellen, dass Alice um 3 Uhr morgens arbeiten sollte, wenn sie in der Unternehmenszentrale tätig ist.
• Warum
  Das Warum ist wie die nicht existente Schicht 8. Es lässt sich nur aus dem Was ableiten und setzt voraus, dass man Hinweise aus ansonsten recht einfachen Daten wie dem URI zusammensetzen kann (vorausgesetzt, es handelt sich um HTTP, was heutzutage durchaus plausibel ist). Sobald wir wissen, was sie tun, beispielsweise Daten senden, möchten wir möglicherweise auch wissen, warum sie diese senden. Handelt es sich um eine Profilaktualisierung oder senden sie Sensordaten? Führen sie eine Suche durch oder geben sie eine Bestellung auf?

Diese fünf Aspekte bilden den Kontext. Sie müssen nicht unbedingt alle fünf erfassen (schließlich geht es hier nicht um Pokémon), um über die richtige Vorgehensweise entscheiden zu können. Sie benötigen jedoch Einblick in alle fünf Aspekte (und Zugriff darauf), falls dies doch einmal erforderlich sein sollte. Deshalb ist der Einblick in den gesamten Netzwerk-Stack – von Schicht 2 bis 7 – für Anwendungsdienste so wichtig. Denn jeder von ihnen muss möglicherweise eine Anfrage oder Antwort in dem Kontext bewerten, in dem sie erfolgt ist. Nur der Einblick in den gesamten Stack stellt sicher, dass Sie bei Bedarf auf diese Informationen zugreifen können.

Das ist einer der Vorteile, die ein intelligenter Proxy bietet: die nötige Transparenz, damit Netzwerk-, Sicherheits- und Infrastrukturarchitekten (und -ingenieure) kontextabhängige Richtlinien implementieren können, die letztlich die Sicherheit, Geschwindigkeit und Zuverlässigkeit gewährleisten, die jeder Nutzer benötigt – ganz gleich, ob Mensch, Sensor oder Software.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie