Stand der Anwendungsbereitstellung 2016: Der Aufstieg von Identitäts- und Anwendungszugriff

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Früher bestand zwischen Netzwerkports und Anwendungen nahezu eine 1:1-Beziehung. Port 53? Das ist DNS. Port 22? SSH. Port 23? Telnet. Port 80? Das ist die Website.

Beachten Sie hier den Singular: „die“ Website. Nicht „eine von etwa zweihundert über HTTP bereitgestellten Webanwendungen“.

Das ist eine wichtige Unterscheidung, denn sie hilft dabei, die Verlagerung des Anwendungsschutzbereichs vom Rand (der Netzwerk-Firewall) näher an die Anwendung, also ins Innere des Rechenzentrums, zu verstehen (für diejenigen unter Ihnen, die bei der Sicherheit noch mit der „Burg“-Analogie arbeiten: Das ist die innere Burgmauer).

Unsere neuesten Daten zeigen, dass 65 % der bereitgestellten Anwendungen HTTP-basiert sind. Beim Rest handelt es sich unter anderem um die üblichen Verdächtigen wie SSH, FTP, SMTP und DNS sowie um einige weniger bekannte Protokolle. Und wie viele Anwendungen gibt es in einem typischen Unternehmen? Unser Bericht „State of Application Delivery 2016“ ist hier sehr aufschlussreich. Fast die Hälfte der Unternehmen hat zwischen 1 und 200 Apps im Einsatz. Die andere Hälfte? Nun, mehr als 200. Erstaunliche 10 % betreiben derzeit sogar mehr als 3.000 Anwendungen.

Mehr als die Hälfte dieser Anwendungen basiert auf HTTP. Sie alle passieren denselben Port des unerschütterlichen Verteidigers des Rechenzentrums: der Netzwerk-Firewall. Einer Netzwerk-Firewall, die höchstwahrscheinlich nicht zwischen diesen Anwendungen unterscheiden kann. Der es völlig gleichgültig ist, ob sie JSON oder HTML überträgt, ob die Anwendung für Unternehmen oder Verbraucher bestimmt ist und ob von einem Mobilgerät aus darauf zugegriffen werden darf, während Sie zu Hause sind.

Diese Aspekte werden für die Absicherung von Anwendungen immer wichtiger. Dazu gehört sowohl das Wissen, wie sich feststellen lässt, ob die Nutzdaten einer Anwendung kompromittiert sind oder nicht (JSON ist nicht HTML und HTML ist nicht XML), als auch die Entscheidung, ob der Zugriff von einem bestimmten Standort oder Gerät aus erlaubt werden sollte.

Genau solche Fragen sind für Dienste zur Anwendungszugriffskontrolle von großer Bedeutung. Wie andere anwendungsbezogene Dienste spielen auch Dienste zur Anwendungszugriffskontrolle eine immer wichtigere Rolle in der übergreifenden Sicherheitsstrategie, gerade weil sie in der Lage sind, zwischen Anwendungen zu unterscheiden und die entsprechenden Richtlinien anzuwenden. Sie betrachten nicht nur Protokolle und Ports, sondern analysieren die gesamte Kommunikation eingehend und werten eine Vielzahl von Variablen aus (wir nennen das Kontext), um zu entscheiden, ob Bob tatsächlich von seinem Wohnzimmer aus auf diese hochsensible Anwendung zugreifen darf.

Unseren Untersuchungen zufolge sind sich Unternehmen dessen bewusst. 87 % haben heute mindestens vier Identitäts- und Zugriffsdienste im Einsatz. Und wenig überraschend (zumindest für mich) ist dies 2016 die am schnellsten wachsende Kategorie von Anwendungsdiensten: 50 % planen, in den nächsten zwölf Monaten einen solchen Dienst einzuführen. Ich sage „wenig überraschend“, weil der Zugriff auf Anwendungen heute zwangsläufig auch die Cloud umfasst, wo Netzwerk-Firewalls die Zugriffskontrolle nicht auf Anwendungen ausweiten können. Identitäts- und Zugriffsdienste hingegen schon.

Natürlich stimmt es, dass Netzwerk-Firewalls nach wie vor der von Unternehmen am häufigsten eingesetzte Dienst sind, und ich erwarte nicht, dass sich daran in absehbarer Zeit etwas ändern wird. Sie spielen und werden auch weiterhin eine bedeutende Rolle in der Sicherheitsstrategie jedes Unternehmens spielen. Doch da Cloud, Mobilgeräte und das Internet der Dinge die zu schützende Anwendungslandschaft immer weiter vergrößern, werden Rolle und Bedeutung der Zugriffskontrolle für Anwendungen weiter zunehmen. Das liegt nicht nur daran, dass Netzwerk-Firewalls nicht mehr über die nötige Transparenz verfügen, um zwischen Apps zu unterscheiden, die über dasselbe Protokoll (HTTP) bereitgestellt werden, sondern auch daran, dass sie nicht mehr den einzigen Zugangspunkt zu diesen Anwendungen darstellen, wenn eine erhebliche Anzahl davon extern in der Cloud bereitgestellt wird.

Weitere Einzelheiten finden Sie im vollständigen Bericht „State of Application Delivery 2016“, den Sie sich nicht entgehen lassen sollten.

Ü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