Die Verlagerung von HTML-basierenden Webseiten hin zu REST basierenden Programmierschnittstellen schreitet rasch voran. OWASP publiziert darum eine neue und spezialisierte Top 10 Liste für API Security. Dedizierte Sicherheitsprodukte, wie Web Application Firewalls, API Gateways mit entsprechenden Erweiterungen und Identity und Access Management Systeme, wie von Airlock, können einen wesentlichen Beitrag zur Sicherung von APIs beitragen, aber auch Entwickler müssen in die Pflicht genommen werden und ihren Teil leisten, um einen optimalen Schutz der Ressourcen des Unternehmens zu gewährleisten.

Die Bedeutung von HTML basierenden Webseiten und Portalen nimmt seit einigen Jahren ab. Die Gründe dafür sind vielfältig. Einen wichtigen Teil trägt die zunehmende Verwendung von Smartphones und Tablets dazu bei, weil es effizienter und kostengünstiger ist, wenn Applikationen bereits im Gerät installiert sind und nur noch die Daten über das Internet geladen werden müssen. IoT Geräte und Wearables sind meist zu klein um Webseiten darstellen und bedienen zu können aber der Datenaustausch über das Internet ist ein Schlüsselelement für deren Einsatz. Die kontinuierliche Weiterentwicklung von Web Browsern erlaubt es den Entwicklern heute eine optimale User Experience umzusetzen, die sich automatisch den Rahmenbedingungen des verwendeten Devices anpassen kann.  Diesen Entwicklungen gemeinsam ist die Tatsache, dass die Daten aus dem Internet bezogen werden und für die dafür nötigen REST Schnittstellen sich deshalb immer mehr zu einem der wichtigsten Bausteine der Internet Architektur entwickeln.

APIs im Dienste der User Experience

Die zunehmende Bedeutung von REST Schnittstellen ist dem Umstand geschuldet, dass sich die Architekturparadigmen der Applikationsentwicklung an die Anforderungen der User anpassen mussten. Mobile First führt dazu, dass moderne Applikationen entweder direkt als native mobile Applikationen entwickelt oder als Single Page Applications (SPA) direkt im Browser ausgeführt werden. Dabei können diese Applikationen ein Vielzahl von APIs von ganz unterschiedlichen Quellen nutzen und erst im Client zusammenfügen. Unterstützt werden die Software Entwickler durch grosse und funktional sehr umfangreiche Ökosysteme: Android Studio, Xcode, React oder Angular um nur ein paar zu nennen. Als Resultat entstehen so Applikationen, die eine User Experience ermöglichen, die sehr nahe an derjenigen von Rich Clients ist ohne aber deren Nachteile akzeptieren zu müssen.

Aus Sicht der API Anbieter geht es darum eine Kombination von Business Logik und Daten so zu exponieren, dass die Applikationen diese effizient und gefahrlos nutzen können. Dies bedeutet, dass jeder API Anbieter selbst die Sicherheit der angebotenen API sicher stellen muss. Ein delegieren dieser Verantwortung an vorgelagerte Applikationen oder Portale ist nicht möglich, denn APIs müssen direkt im Internet exponiert werden.

Die Evolution der REST Schnittstellen basiert auf dem gleichen HTTP Protokoll welches bereits für HTML basierende Webseiten so erfolgreich war. Darum ist es nicht erstaunlich, dass viele potentielle Angriffe sehr viel Ähnlichkeiten zu den Angriffen auf traditionelle Webseiten oder Portale aufweisen. Gemäss einer Studie von Gartner zur API Security [1] ensteht bis 2021 die grösste Angriffsfläche bei 90% der Web-Applikationen durch exponierte APIs. Bis 2022 wird der API Missbrauch zum wichtigsten Angriffsvektor und global zu Data Breaches führen. Aber bereits heute gibt es genügend Berichte von Zwischenfällen die auf schlecht gesicherte APIs zurück zu führen sind.

 

System Owner

Date

Effect of Data Leaks

Citation

US Postal Services Hack

21.11.2018

Alle Benutzerkonten, inckl. Adresse, Telefonnummer und E-Mail

https://krebsonsecurity.com/2018/11/usps-site-exposed-data-on-60-million-users/

Brazil Fed of Indus - ElasticSearch API exposed

23.11.2018

34.8 Mio. Benutzerkonten

https://www.zdnet.com/article/brazils-largest-professional-association-suffers-massive-data-leak/

Urban Massage - ElasticSearch API exposed

27.11.2018

309'000 Benutzerkonten, inkl. Transaktionsdaten

https://techcrunch.com/2018/11/27/urban-massage-data-exposed-customers-creepy-clients/

SKY Brasil - ElasticSearch API exposed

29.11.2018

32 Mio. Benutzerkonten, 492 GB API Daten

https://www.zdnet.com/article/sky-brasil-exposes-data-of-32-million-subscribers/

Atrium Health - ElasticSearch API exposed

29.11.2018

2 Mio Patienten, inkl. Sozialversicherungsnummer, Geburtsdatum. Keine medizinischen Daten

https://www.securityinfowatch.com/healthcare/news/ 12438109/personal-data-of-more-than-2m-patients -compromised-in-atrium-health-data-breach

Data&Leads

29.11.2018

44.3 Mio. Benutzerkonten

https://www.bankinfosecurity.com/blogs/data-leads-site-disappears-after-data-exposure-alert-p-2687

Smart Watches PWNED

2.4.2019

Kontrolle über hunderte von Smart Watches

https://www.zdnet.com/article/researcher-prints-pwned-on-hundreds-of-gps-watches-maps-due-to-unfixed-api/

JustDial Leak

17.4.2019

100 Mio Benutzerkonten inkl. Mobiltelefonnummern

https://thehackernews.com/2019/04/justdial-hacked-data-breach.html

GateHub Cryptocurrency Wallet Hack

6.6.2019

Cryptogeld aus XRP Ledger Wallets gestoheln

https://gatehub.net/blog/gatehub-preliminary-statement/

Venmo transactions Leaked

16.6.2019

7 Mio. Transaktionen

https://techcrunch.com/2019/06/16/millions-venmo-transactions-scraped/

Suprema: "Biostar 2" (Biometrie DB)

 

27.8 Mio Benutzerprofile Profildaten, Usernamen, Passwörter, Gesichtsbilder, Fingerabdrücke, 

https://www.heise.de/security/meldung/Biometriedatenbank-mit-27-8-Millionen-Eintraegen-ungesichert-im-Netz-4496575.html

Adobe Creative Cloud - ElasticSearch API exposed

26.10.2019

7.5 Mio Benutzerkonten

https://www.heise.de/newsticker/meldung/Adobe-7-5-Millionen-Konten-der-Creative-Cloud-offen-im-Internet-einsehbar-4569845.html

OnePlus räumt Datenleck ein

23.11.2019

Benutzerkonten mit Adresse, Telefonnummern und E-Mail.

https://www.heise.de/newsticker/meldung/Zugriff-auf-sensible-Daten-OnePlus-raeumt-Datenleck-ein-4595176.html

[1] “API Security: What You Need to Do to Protect Your APIs”, Mark O'Neill, Dionisio Zumerle, Jeremy D'Hoinne, Gartner, 28.8.2019

Datensicherheit und Datenschutz

Im Gesundheitswesen ist der rasche und zuverlässige Austausch von strukturierten medizinischen Daten eine Anforderung die Ärzte und vermehrt auch Patienten immer lauter stellen. Die Realität zeigt aber, dass der Austausch häufig noch darin besteht, dass eingescannte Dokumente oder PDF über Fax und E-Mail übermittelt werden. In den letzten zwei Jahren kommt aber Bewegung ins Gesundheitswesen, weil die grossen IT Anbieter: Apple, Google, Microsoft und Amazon aktiv ins Thema "Personal Health Record" investieren und alle auf den gleichen Standard setzen: FHIR. FHIR beschreibt eine REST Schnittstelle mit Funktionen und Daten und ermöglicht so den Datenaustausch von strukturierten, medizinischen Daten. FHIR wird von den grossen Anbietern als Schlüsseltechnologie positioniert um den Datenaustausch zwischen Behandelnden und Patienten zu realisieren. Damit erfüllt FHIR aber auch alle Voraussetzungen um im gesamten Gesundheitswesen zum Austauschstandard zu werden.

Einen Schritt weiter ist der Bereich der Finanzdienstleister. In der EU wurde mit PSD2 ein Gesetz erlassen, dass alle Banken zwingt im Internet REST Schnittstellen anzubieten, welche für die Abfrage von Kontoinformationen und die Erfassung von Zahlungsaufträgen genutzt werden können. Dies hat dazu geführt, dass auf der Basis der gesetzlichen Vorlage bereits mehrere Standards entstanden sind, welche die für die Umsetzung nötigen REST Schnittstellen im Detail spezifizieren. Die Ausstrahlung der Europäischen Gesetzgebung ist aber enorm. Im Dokument von PwC kann man nachlesen, dass diese Entwicklung global Schule macht und auch in den USA und in Asien Empfehlungen oder Gesetze in Vorbereitung sind.

Damit setzen sich REST Schnittstellen in zwei Bereichen durch, die ein erhöhtes Maß an IT-Security aufweisen. Bei FHIR geht es  um Gesundheitsdaten, für die die GDPR ganz unmissverständliche festlegt, dass es sich hier um besonders schützenswerte, sensible Daten handelt und andererseits geht es bei PSD2 um Anwendungen der Finanzbranche wo die Kunden klare Erwartungen bezüglich der Sicherheit ihres Vermögens haben und wo jedes mögliche Reputationsrisiko sehr ernst genommen wird.

OWASP Top Ten und OWASP API Security 

Wenn es darum geht über die Risiken und Bedrohungen von Applikationen im Internet zu diskutieren, dann führt kein Weg an den OWASP Top 10 vorbei. Die OWASP ist eine non-Profit Organisation und die Top 10 sind das vermutlich bekannteste Projekt der OWASP. Seit 2003 veröffentlicht das Top 10 Projekt, basierend auf den Daten von hunderten Organisationen weltweit, eine priorisierte Liste von Schwachstellen/Risiken und möglichen Gegenmassnahmen. 

Seit Dezember 2019 veröffentlich das API Security Projekt der OWASP auch eine Top 10 Liste. Nicht dass API Security in der bekannten Top 10 Liste gefehlt hätte, aber OWASP trägt dem Umstand Rechnung, dass die Bedeutung von Schnittstellen und speziell auch REST Schnittstellen im mehr zugenommen hat und darum ein eigenständiger Bedrohungs- und Massnahmenkatalog gerechtfertigt ist.

 

Überblick über die Top Ten API Schwachstellen

Die folgende Tabelle zeigt die vollständige Liste der API Schwachstellen gemäss OWASP:
 

Nummer

Titel

Beschreibung

API1 

Broken Object Level Authorization 

APIs neigen dazu, Endpunkte freizulegen, die Objektidentifikatoren verarbeiten, was zu einer großen Angriffsfläche für die Zugriffskontrolle führt. Berechtigungsprüfungen auf Objektebene sollten bei jeder Funktion berücksichtigt werden, die über die Eingabe des Benutzers auf eine Datenquelle zugreift.

API2 

Broken Authentication 

Authentifizierungsmechanismen sind oft falsch implementiert, so dass Angreifer Authentifizierungstoken kompromittieren oder Implementierungsfehler ausnutzen können, um vorübergehend oder dauerhaft die Identitäten anderer Benutzer zu übernehmen. Wenn die Fähigkeit des Systems, den Client/Benutzer zu identifizieren, beeinträchtigt wird, wird die API-Sicherheit insgesamt beeinträchtigt. 

API3 

Excessive Data Exposure 

Mit Rücksicht auf sehr allgemeine Nutzung von APIs, neigen Entwickler dazu, alle Attribute von Objekten offenzulegen, ohne Rücksicht auf deren individuellen Schutzbedarf. Sie verlassen sich darauf, dass Clients die Daten filtern, bevor sie dem Benutzer angezeigt werden.

API4 

Lack of Resources & Rate Limiting 

Häufig beinhalten APIs keine Einschränkungen in Bezug auf die Größe oder Anzahl der Ressourcen, die vom Client oder Benutzer angefordert werden können. Dies kann sich nicht nur auf die Leistung des API-Servers auswirken, was zu Denial of Service (DoS) führt, sondern auch die Tür für Authentifizierungsfehler wie Brute Force offen halten.

API5 

Broken Function Level Authorization 

Komplexe Zugriffskontrollrichtlinien mit unterschiedlichen Hierarchien, Gruppen und Rollen sowie eine unklare Trennung zwischen administrativen und regulären Funktionen führen tendenziell zu Berechtigungsfehlern. Durch die Ausnutzung dieser Probleme erhalten Angreifer Zugang zu den Ressourcen und/oder Verwaltungsfunktionen anderer Benutzer.

API6 

Mass Assignment 

Die Bindung von vom Kunden bereitgestellten Daten (z.B. JSON) an Datenmodelle, ohne eine geeignete Filterung der Eigenschaften auf der Grundlage einer Whitelist, führt in der Regel zu einer Massenzuordnung. Das Erraten von Objekteigenschaften, das Erkunden anderer API-Endpunkte, das Lesen der Dokumentation oder das Bereitstellen zusätzlicher Objekteigenschaften in Anforderungs-Payloads ermöglicht es Angreifern, Objekteigenschaften zu ändern, die sie nicht ändern sollen.

API7 

Security Misconfiguration 

Fehler in der Konfiguration der Sicherheit ist in der Regel das Ergebnis unsicherer Standardkonfigurationen, unvollständiger oder ad-hoc-Konfigurationen, offener Cloud-Speicher, falsch konfigurierter HTTP-Header, unnötiger HTTP-Methoden, permissiver Cross-Origin Resource Sharing (CORS) und ausführlicher Fehlermeldungen mit sensiblen Informationen

API8 

Injection 

Injection Fehler, wie SQL, NoSQL, Command Injection, etc. treten auf, wenn nicht vertrauenswürdige Daten als Teil eines Befehls oder einer Anfrage an einen Interpreter gesendet werden. Die bösartigen Daten des Angreifers können den Interpreter dazu bringen, unbeabsichtigte Befehle auszuführen oder ohne entsprechende Berechtigung auf Daten zuzugreifen.

API9 

Improper Assets Management 

APIs neigen dazu, mehr Endpunkte zu veröffentlichen als herkömmliche Webanwendungen, was eine korrekte und aktualisierte Dokumentation sehr wichtig macht. Ein ordnungsgemäßer Bestand an Hosts und bereitgestellten API-Versionen spielt ebenfalls eine wichtige Rolle, um Probleme wie veraltete API-Versionen und exponierte Debug-Endpunkte zu reduzieren.

API10

Insufficient Logging & Monitoring 

Unzureichende Protokollierung und Überwachung, gepaart mit fehlender oder ineffektiver Einbindung in die Gefahrenabwehr, ermöglichen es Angreifern, ihre Angriffe zu intensivieren, sich tiefer einzunisten und ihre Angriffe aus andere Systeme auszudehnen. Alles mit dem Ziel Daten zu manipulieren, zu extrahieren oder zu zerstören. Die meisten Studien zeigen, dass die Zeit bis zur Feststellung einer Verletzung mehr als 200 Tage beträgt, was in der Regel eher von externen Parteien als von internen Prozessen oder der Überwachung erkannt wird.

OWASP API Security 2019 vs. Top Ten 2017

Vergleicht man die neue Top Ten Liste für API Security mit der aktuellen für Web-Applikationen aus dem Jahr 2017 (A1-A10), stellt man sehr rasch fest, dass einige Schwachstellen in vergleichbarer Form und zum Teil auch mit ähnlicher Gewichtung auf beiden Listen aufzufinden sind:

 

  • Broken Authentication: API2 ist identisch zu A2
     
  • Excessive Data Exposure: API3 ist ähnlich zu A3
     
  • Security Misconfiguration: API7 ist vergleichbar zu A6
     
  • Injection: API8 ist identisch, aber unterschiedliche priorisiert zu A1
     
  • Insufficient Logging & Monitoring: API10 ist identisch zu A10

Dies ist nicht weiter erstaunlich, denn die Gemeinsamkeiten von traditionellen Webseiten oder Portalen mit Applikationen die REST Schnittstellen nutzen sind sehr gross. Die Applikationen verfolgen den gleichen Zweck und auch die verwendeten Technologien sind sehr eng miteinander verwandt. Die Applikationen müssen auch die gleichen Probleme lösen, zum Beispiel die Authentisierung von Benutzern, die Autorisierung der Datenzugriffe, die Persistenz von Daten, das Deployment in der Cloud oder im Rechenzentrum, das Schreiben von Logs oder die Einbettung in Monitoring Systeme. 

Viel spannender als die grossen Gemeinsamkeiten sind die Unterschiede. Das Thema Injection wird zwar bezüglich Inhalt auf beiden Listen geführt, aber die Beurteilung der Priorität ist doch recht unterschiedliche. Eine mögliche Erklärung kann sein, dass die für REST genutzten Tools praktisch flächendeckend eingesetzt werden und diese bereits sehr viele Probleme im Bereich der Validierung von Inputdaten, ohne weiteres Zutun des Entwicklers, lösen. Solche Tools waren in den Anfängen der traditionellen Webapplikationen viel weniger ausgereift und darum ist auch heute noch das Risiko für traditionelle Web-Applikationen höher einzuschätzen. Was gegen diesen Erklärungsansatz spricht ist der Umstand, dass injection grundsätzlich im API selbst verhindert werden muss, denn ein API kann sich ja nicht auf den Schutz durch "wohlgesonnene" Clients verlassen.

Eine Bedrohung, welche scheinbar für APIs nicht gilt, ist die XML External Entities (XXE) Schwachstelle. Es liegt nahe, dass die Autoren der API Security Risks vor allem REST Schnittstellen im Fokus haben, denn SOAP Webservices werden im Bereich mobiler Applikationen oder bei SPAs im Browser praktisch nicht eingesetzt. Auch Cross Site Scripting (XSS) fehlt in der API Security Risks Liste. Es ist zwar korrekt, dass XSS in erster Linie ein Browser Problem ist und APIs selbst keine JavaScript interpretieren, aber APIs könnten JavaScript übermitteln und so in XSS involviert werden. Vermutlich sind die Autoren davon ausgegangen, dass die Inputvalidierung der API8 auch JSP Injection verhindert und darum XSS als eigenständiges Risiko unnötig ist. 
 

API Security spezifische Risiken

Die API Security Top 10 identifiziert auch Risikien die sich ausschliesslich auf REST APIs beziehen. Im speziellen wird "Broken Access Control" (A5 der Top 10) sehr viel detaillierter und auch viel höher gewichtet. Mit API1, API3 und API6 sind 3 Risiken identifiziert worden, die alle einen starken Bezug zu A5 haben. API1 umfasst Risiken welche die Zugriffsautorisierung auf Objekt-Ebene durch manipulierte Identifier fokussieren, API3 befasst sich mit dem Auslesen von Daten direkt an der API selbst und API6 beschreibt die Risiken der Manipulation von Attributen von Objekten wenn diese ungewollt exponiert werden.

Mit API4 (Lack of Resource & Rate Limiting) und API9 (Improper Asset Management) wird dem Umstand Rechnung getragen, dass es viel mehr APIs gibt und diese auch sehr viel direkter exponiert sind. Business Logik und Daten werden nicht durch Webserver oder Portale abgeschottet und das erfordert zusätzliche Massnahmen, damit die Risiken in diesem Bereich reduziert werden können.

 

Massnahmen zum Schutz von APIs

Aufbau einer Security Infrastruktur

Die Verwendung spezialisierter Sicherheitskomponenten um exponierte Schnittstellen zu schützen gilt heute als Best Practice. Diese Aussage gilt unabhängig davon, ob die spezialisierten Sicherheitskomponenten an der Peripherie des Firmennetzwerks ihren Dienst tun, ob im Sinne einer Zero Trust Architektur, jede einzelne Schnittstelle durch eigene Sicherheitskomponenten geschützt wird oder ob ein Hybrider Ansatz zum Zug kommt.

Für die Umsetzung kann aus einer Vielzahl von Produkten ausgewählt werden, aber im Grundsatz müssen immer folgende Funktionen abgedeckt werden: 

 

Airlock vereint diese 3 Komponenten in einem zentralisierten Secure Access Hub.
 

Je nach Hersteller kann es Abweichungen geben, wie die Architektur im Detail umgesetzt wird, weil die Anzahl Komponenten und auch die Verteilung von Funktionen auf die Komponenten im Detail unterschiedlich realisiert sein kann. Für die Zielsetzung, die Risiken der OWASP API Security zu reduzieren, ist das aber nicht entscheidend. Entscheidend ist, dass die verschiedenen Funktionen im ausgewählten Produkt umgesetzt und korrekt konfiguriert sind (API7).

Die Angriffsoberfläche kann bereits substantiell eingeschränkt werden, weil nur die API auch wirklich exponiert werden, die von extern auch erreichbar sein sollen (API9). So wird vermieden, dass Interfaces die für den ausschliesslich internen Gebrauch vorgesehen sind, unnötig exponiert werden.

Ist eine OpenAPI Spezifikation verfügbar, dann kann der API Gateway die Zugriffe auf explizit für die Veröffentlichung spezifizierte Funktionen einschränken (API9) und auch eine formale Input-Validierung der übermittelten Parameter vornehmen (API8).

Bereits im API Gateway können Rate Limits durchgesetzt werden (API4) ohne dass die eigentliche Business Logik oder die Daten Persistenz überhaupt mit überzähligen Requests belästigt wird. In vielen Produkten sind die Policies dabei so umgesetzt, dass auch komplexe Business Modelle unterstützt werden können, die abhängig vom Benutzer andere Limiten durchsetzen.

Identity und Access Management Systeme stellen sicher, dass Benutzer angemessen authentisiert sind (API2). Moderne IAM Systeme, wie von Airlock, unterstützen Standards with OAuth, OpenID Connect oder SAML und propagieren so die verifizierte Identität der Benutzer zu den Applikationen und APIs (API5). Airlock IAM erlaubt zusätzlich die Umsetzung von Single-Sign-On über mehrere Applikationen und stellt User Self-Services Funktionen zur Verfügung. 

Beide Systeme, API Gateway und IAM, erzeugen sowohl technische als auch fachlichen Log Output, der idealerweise in einem SIEM System gesammelt und analysiert wird (API10). 

Pflichten für Entwickler

Der aufmerksame Leser hat bereits gemerkt, dass nicht alle API Risiken mit vorgelagerten Sicherheitskomponenten adressiert werden können, weil Business Regeln nur in der Business Logik der Schnittstelle bekannt sind und darum auch nur dort durchgesetzt werden können. Die Frage, ob ein gewisser User wirklich zugreifen darf auf ein spezifisches Business Objekt, kann nur in der Business Logik der Applikation beantwortet werden (API1) aber auch im Zusammenhang mit API3 und API6 sind Entwickler in der Pflicht ihre APIs so zu entwerfen, dass nur die notwendigen Informationen exponiert werden und nur das erlaubt wird, was erlaubt sein soll. 

Als Software Entwickler sollte man sich aber darüber im klaren sein, dass sichere Software nur dann entsteht, wenn während der Entwicklung berücksichtigt wird, dass die Software auch ohne vorgelagerte Sicherheitskomponenten bedenkenlos eingesetzt werden kann. "Security by Design" ist ein Gebot, dass speziell bei der Entwicklung von APIs befolgt werden sollte.

Zusammenfassung

Die Liste der OWASP API Security Risks ist das Resultat der zunehmenden Bedeutung von REST Schnittstellen und es ist die logisch konsequente Weiterführung der OWASP Top 10 Liste. Zunehmende Bedeutung führt aber auch zu zunehmender Bedrohung, weil APIs bereits heute aber auch in Zukunft vermehrt angegriffen werden. Geeignete Sicherheitskomponenten (Secure Access Hub: Web Application Firewall, API Gateway, Identity und Access Management Systeme) können helfen um die Risiken zu reduzieren, aber auch die Entwickler sind in der Pflicht um den sicheren Umgang mit der Business Logik und den Daten sicher zu stellen.

Der Secure Access Hub von Airlock bietet sicheren Schutz vor den OWASP API Security Risks und vor den OWASP Top 10. Entdecken Sie die Vorteile und weitere Funktionen vom Airlock Secure Access Hub und lesen Sie den im Heise Magazin veröffentlichten Fachartikel, um mehr über die neue OWASP Top 10 Liste, die Hintergründe und Verantwortlichkeiten zu erfahren.

Blognews direkt in Ihr Postfach

Der Airlock Newsletter informiert Sie laufend über neue Blogartikel.

Blognews abonnieren

Keine Blogbeiträge

Die Liste enthält keine Blogbeiträge.

Wir informieren Sie

-Unsere Whitepaper-

Executive View: KuppingerCole - Airlock Secure Acces Hub für Applications und APIs

Dieser KuppingerCole Executive View Bericht gibt einen architektonischen und funktionalen Überblick über den Airlock Secure Access Hub, eine integrierte Plattform für sicheres Access Management - ein multicloud-natives Sicherheitstool für Webanwendungen, APIs und darüber hinaus.

Jetzt Formular ausfüllen und Executive View erhalten!

Whitepaper: Sicherheit für cloudnative Anwendungen

Wie es Unternehmen gelingt, die Sicherheit von Web-Applikationen und APIs in Kubernetes zu gewährleisten lesen Sie hier im Whitepaper "Sicherheit für cloudnative Anwendungen“, das in Zusammenarbeit zwischen heise und Airlock entstanden ist.

Whitepaper anfordern

Whitepaper: Zero Trust ist eine Reise

Die kontinuierliche digitale Transformation der Welt schreitet voran und wirkt sich tiefgreifend auf das Privat- und Berufsleben in einer Weise aus, die vor wenigen Jahren noch schwer vorstellbar war.

Dieses Whitepaper behandelt die Effekte der kontinuierlichen Digitalisierung und ihre Auswirkungen.

Kostenlos anfordern

Auf zu DevSecOps

Erfahren Sie in diesem Whitepaper die wichtigsten Erkenntnisse, wie Sie DevSecOps erfolgreich und effizient umsetzen können, welche Sicherheitskomponenten es dafür braucht und welche Vorteile eine Microgateway Architektur bringt.

Kostenlos anfordern

Airlock 2FA - Starke Authentifizierung. Einfach.

Doppelte Sicherheit – das bietet die Zwei-Faktor-Authentifizierung im Bereich IT-Security.

Erfahren Sie in unserem Whitepaper mehr über starke Authentifizierung und die Möglichkeiten, die Airlock bietet.

Kostenlos herunterladen

Weitere Whitepaper

Zu diesen und weiteren Themen stellen wir Ihnen kostenlos Whitepaper zur Verfügung:

  • erfolgreiche IAM Projekte
  • Compliance
  • Datenschutz (DSGVO)
  • Einführung von PSD2
  • PCI DSS Anforderungen
Kostenlos anfordern