Frage: Was ist der Unterschied zwischen Zombie-APIs und Schatten-APIs?
Nick Rago, Field CTO, Salt Security: Zombie-APIs und Schatten-APIs stellen Nebenprodukte einer größeren Herausforderung dar, mit der Unternehmen heute zu kämpfen haben: der API-Wildwuchs.
Da Unternehmen versuchen, den mit APIs verbundenen Geschäftswert zu maximieren, haben APIs stark zugenommen. Digitale Transformation, App-Modernisierung hin zu Microservices, API-First-App-Architekturen und Fortschritte bei schnellen, kontinuierlichen Softwarebereitstellungsmethoden haben das rasante Wachstum der Anzahl der von Unternehmen erstellten und genutzten APIs vorangetrieben. Als Folge dieser schnellen API-Produktion hat sich die API-Ausuferung bei mehreren Teams manifestiert, die mehrere Technologieplattformen (Legacy, Kubernetes, VMs usw.) über mehrere verteilte Infrastrukturen (lokale Rechenzentren, mehrere öffentliche Clouds usw.) nutzen. . Unerwünschte Einheiten wie Zombie-APIs und Schatten-APIs entstehen, wenn Unternehmen nicht über die richtigen Strategien zur Bewältigung der API-Ausuferung verfügen.
Einfach ausgedrückt ist eine Zombie-API eine offengelegte API oder ein API-Endpunkt, der aufgegeben, veraltet oder vergessen wurde. An einem Punkt erfüllte die API eine Funktion. Möglicherweise wird diese Funktion jedoch nicht mehr benötigt oder die API wurde durch eine neuere Version ersetzt/aktualisiert. Wenn eine Organisation nicht über angemessene Kontrollen zur Versionierung, Abwertung und Einstellung alter APIs verfügt, können diese APIs auf unbestimmte Zeit bestehen bleiben – daher der Begriff „Zombie“.
Da sie im Wesentlichen vergessen werden, erhalten Zombie-APIs keine laufenden Patches, Wartungsarbeiten oder Aktualisierungen in irgendeiner funktionalen oder sicherheitstechnischen Hinsicht. Daher werden die Zombie-APIs zu einem Sicherheitsrisiko. Tatsächlich ist Salt Security “Stand der API-SicherheitIn dem Bericht werden Zombie-APIs in den letzten vier Umfragen als größtes API-Sicherheitsrisiko für Unternehmen genannt.
Im Gegensatz dazu ist eine Schatten-API eine offengelegte API oder ein API-Endpunkt, dessen Erstellung und Bereitstellung „unter dem Radar“ erfolgte. Schatten-APIs wurden außerhalb der offiziellen API-Governance, Sichtbarkeit und Sicherheitskontrollen einer Organisation erstellt und bereitgestellt. Folglich können sie eine Vielzahl von Sicherheitsrisiken bergen, darunter:
- Die API verfügt möglicherweise nicht über die richtigen Authentifizierungs- und Zugriffstore.
- Möglicherweise stellt die API vertrauliche Daten unsachgemäß offen.
- Unter Sicherheitsgesichtspunkten entspricht die API möglicherweise nicht den Best Practices, was sie für viele davon anfällig macht OWASP API-Sicherheit Top 10 Angriffsdrohungen.
Es gibt eine Reihe von Motivationsfaktoren dafür, warum ein Entwickler oder ein App-Team schnell eine API oder einen Endpunkt bereitstellen möchte. Allerdings muss eine strikte API-Governance-Strategie befolgt werden, um Kontrollen und Prozesse darüber durchzusetzen, wie und wann eine API bereitgestellt wird, unabhängig von der Motivation.
Zusätzlich zu den Risiken gehen die API-Ausuferung und die Entstehung von Zombie- und Schatten-APIs über die intern entwickelten APIs hinaus. APIs von Drittanbietern, die als Teil von Paketanwendungen, SaaS-basierten Diensten und Infrastrukturkomponenten bereitgestellt und genutzt werden, können ebenfalls Probleme verursachen, wenn sie nicht ordnungsgemäß inventarisiert, verwaltet und gewartet werden.
Die Funktionsweise von Zombie- und Shadow-APIs ist ähnlich Sicherheitsrisiken. Abhängig von den vorhandenen API-Kontrollen einer Organisation (oder deren Fehlen) kann eine davon weniger oder problematischer sein als die andere. Als ersten Schritt zur Bewältigung der Herausforderungen von Zombie- und Schatten-APIs müssen Unternehmen eine geeignete API-Erkennungstechnologie verwenden, um alle in ihren Infrastrukturen eingesetzten APIs zu inventarisieren und zu verstehen. Darüber hinaus müssen Unternehmen eine API-Governance-Strategie einführen, die standardisiert, wie APIs erstellt, dokumentiert, bereitgestellt und gewartet werden – unabhängig von Team, Technologie und Infrastruktur.
