Mit <kes>+ lesen

API-Sicherheit im Web : Entwicklungen – Neue Top-10-Liste der OWASP – Maßnahmen

Die Verlagerung von HTML-basierten Webseiten hin zu REST-basierten Programmierschnittstellen schreitet rasch voran. OWASP hat daher eine neue und spezialisierte Top-10-Liste für API-Security publiziert [2]. Dieser Beitrag fasst die Ergebnisse zusammen und skizziert mögliche Maßnahmen zur Sicherung von Programmierschnittstellen (APIs) im Web.

Lesezeit 15 Min.

Von Michael Doujak, Zürich

Die Bedeutung von HTML-basierten Websites 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 bei, weil es effizienter erscheint, wenn Applikationen bereits im Gerät installiert sind und nur noch benötigte Daten nachgeladen werden müssen. Außerdem sind Geräte im Internet of Things (IoT) sowie Wearables meist zu klein, um Webseiten darstellen und bedienen zu können – der Datenaustausch über das Internet ist aber dennoch ein Schlüsselelement für ihren Einsatz. Und nicht zuletzt ermöglicht die kontinuierliche Weiterentwicklung von Webbrowsern den Entwicklern heute, ein Nutzungserlebnis (User-Experience, UX) umzusetzen, das sich optimal und automatisch den Rahmenbedingungen des verwendeten Devices anpassen kann.

Allen diesen Entwicklungen gemeinsam ist die Tatsache, dass hierzu Daten aus dem Internet bezogen werden und sich die dafür genutzten Representational-State-Transfer-(REST)-Schnittstellen deshalb immer mehr zu einem der wichtigsten Bausteine der Internet Architektur entwickeln.

APIs im Dienste der User-Experience

Das „Mobile First“-Paradigma führt heute dazu, dass moderne Applikationen entweder direkt nativ mobil entwickelt oder als sogenannte Single-Page-Applications (SPA) im Browser ausgeführt werden. Dabei können sie eine Vielzahl von Programmierschnittstellen (APIs) ganz unterschiedlicher Quellen nutzen und erst im Client zusammenfügen. Große und funktional sehr umfangreiche Ökosysteme unterstützen dabei die Softwareentwickler: Android Studio, Xcode, React oder Angular, um nur ein paar zu nennen. So entstehen Applikationen, deren UserExperience sehr nahe an derjenigen von Rich Clients ist – ohne aber deren Nachteile mitzubringen.

Aus Sicht der API-Anbieter geht es darum, eine Kombination von Businesslogik und Daten so zu exponieren, dass Applikationen sie effizient und gefahrlos nutzen können. Jeder API-Anbieter muss daher die Sicherheit seiner APIs selbst sicherstellen – ein Delegieren dieser Verantwortung an vorgelagerte Applikationen oder Portale ist nicht möglich, denn APIs müssen ja direkt im Internet exponiert werden.

REST-Schnittstellen basieren auf dem gleichen Hypertext-Transfer-Protocol (HTTP), das auch für HTMLbasierte Webseiten zum Einsatz kommt. Darum ist es nicht erstaunlich, dass viele potenzielle Angriffe sehr viel Ähnlichkeit zu Attacken auf traditionelle Websites oder Portale aufweisen. Gartner-Analysten erwarten, dass bis 2021 die größte Angriffsfläche bei 90 % der Web-Applikationen durch exponierte APIs entsteht [3] – bis 2022 werde der API-Missbrauch zum wichtigsten Angriffsvektor und weltweit zu Datenlecks (Data Breaches) führen.

Doch auch in den vergangenen Jahren gab es bereits mehr als genügend Berichte von Zwischenfällen, die auf schlecht gesicherte APIs zurückzuführen waren – eine Auswahl: Schon 2018 wurde eine Schwachstelle aufgedeckt, die jedem mit einem Account der US Postal Services den Zugriff auf Details der etwa 60 Millionen anderen User gewährt hat [4]. Ebenfalls noch 2018 gab es verschiedene Angriffsszenarien aufgrund der ElasticSearch API, die beispielsweise bei SKY Brasil aufgrund eines fehlenden Passworts 28.7 GB Logfiles und 492 GB API-Daten zu über 32 Millionen Benutzerkonten offenbarten [5] – ein knappes Jahr danach kompromittierte eine offene Elasticsearch-Datenbank 7,5 Millionen Kundendaten von Adobes Creative Cloud [6]. Im April 2019 wurde ein mutmaßlich schon vier Jahre lang ungeschütztes API gemeldet, das persönliche Daten von über 100 Millionen Nutzern der indischen Suchmaschine JustDial bereitwillig preisgab [7]. Andernorts wurden über unzureichend geschützte APIs Kryptowährungen aus Wallets gestohlen [8], Transaktionen mobiler Bezahldienste [9] und biometrische Datensätze [10] geleakt oder Smartwatches übernommen [11].

Ausblick: Noch lohnendere Ziele

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, eingescannte Dokumente per Fax oder als PDF via E-Mail zu übermitteln. In den letzten zwei Jahren kommt aber Bewegung ins Gesundheitswesen, weil die großen IT-Anbieter Apple [12], Google [13], Microsoft [14] und Amazon [15] aktiv ins Thema „Personal Health-Record“ investieren und alle auf den gleichen Standard setzen: Fast Healthcare Interoperability Resources (FHIR, [16,17]). FHIR beschreibt eine REST-Schnittstelle mit Funktionen und Daten und ermöglicht so den Austausch von strukturierten medizinischen Datensätzen. FHIR wird von den großen Anbietern als „Schlüsseltechnologie“ positioniert, um den Datenaustausch zwischen Behandelnden und Patienten zu realisieren – damit erfüllt sie alle Voraussetzungen, um im gesamten Gesundheitswesen zum Austauschstandard zu werden.

Einen Schritt weiter ist der Bereich der Finanzdienstleister: In der EU wurde mit der im Herbst 2019 in Kraft getretenen überarbeiteten Zahlungsdiensterichtlinie (Payment Services Directive – PSD2, [18,19]) ein Gesetz erlassen, das alle Banken zwingt, im Internet REST-Schnittstellen anzubieten, um die Abfrage von Kontoinformationen und die Erfassung von Zahlungsaufträgen durch Drittanbieter zu ermöglichen. 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 Schnittstellen im Detail spezifizieren. Die Ausstrahlung der Europäischen Gesetzgebung ist dabei enorm: Laut PwC [20] macht diese Entwicklung global Schule – so seien auch in den USA und in Asien entsprechende Empfehlungen oder Gesetze in Vorbereitung.

Damit setzen sich REST-Schnittstellen in zwei Bereichen durch, die einen deutlich erhöhten Schutzbedarf haben: Bei FHIR geht es um Gesundheitsdaten, für welche die EU-Datenschutzgrundverordnung (DSGVO) ganz unmissverständlich festlegt, dass es sich um besonders schützenswerte Daten handelt – bei PSD2 geht es 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 API Security Top 10

Wenn es darum geht, über die Risiken und Bedrohungen von Applikationen im Internet zu diskutieren, dann führt kein Weg an den Top 10 „Most Critical Web Application Security Risks“ des „Open Web Application Security Project“ (OWASP) vorbei. Seit 2003 veröffentlicht das wohl bekannteste OWASP-Projekt, basierend auf den Daten hunderter Organisationen weltweit, eine priorisierte Liste von Schwachstellen und möglichen Gegenmaßnahmen (www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).

Seit Dezember 2019 gibt auch das OWASP API Security-Projekt [1] eine eigene Top-10-Liste [2] heraus – nicht dass API-Security in der allgemeineren Liste gefehlt hätte, doch die zugenommene Bedeutung von APIs und speziell auch REST-Schnittstellen ließ einen eigenständigen Bedrohungs- und Maßnahmenkatalog gerechtfertigt erscheinen.

Die folgenden Abschnitte geben einen Überblick über die Top-Ten-API-Schwachstellen laut OWASP:

Broken Object Level Authorization (API1)

APIs neigen dazu, Endpunkte offenzulegen, die Objektidentifikatoren verarbeiten – das sorgt für eine große Angriffsfläche in der Zugriffskontrolle. Berechtigungsprüfungen auf Objektebene sollten bei jeder Funktion berücksichtigt werden, die mit von Benutzern erfassten Daten auf eine Datenquelle zugreift.

Broken Authentication (API2)

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

Excessive Data Exposure (API3)

Mit Rücksicht auf die 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.

Lack of Resources and Rate Limiting (API4)

Häufig implementieren 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 – bis hin zum „Denial of Service“ (DoS) – auswirken, sondern auch die Tür für Brute-Force-Angriffe öffnen.

Broken Function Level Authorization (API5)

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 können Angreifer Zugang zu den Ressourcen und/oder Verwaltungsfunktionen anderer Benutzer erhalten.

Mass Assignment (API6)

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 sogenannten 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 dann Angreifern, Objekteigenschaften zu ändern, die sie nicht ändern können sollten.

Security Misconfiguration (API7)

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

Injection (API8)

Injection-Fehler (z. B. SQL- oder Command-Injection etc.) treten auf, wenn nicht-vertrauenswürdige Daten als Teil eines Befehls oder einer Anfrage an einen Interpreter gesendet werden können. Bösartige Daten eines Angreifers können den Interpreter dann dazu bringen, unbeabsichtigte Befehle auszuführen oder ohne entsprechende Berechtigung auf Daten zuzugreifen.

Improper Assets Management (API9)

APIs neigen dazu, mehr Endpunkte zu veröffentlichen als klassische 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.

Insufficient Logging and Monitoring (API10)

Unzureichende Protokollierung und Überwachung, besonders gepaart mit fehlender oder ineffektiver Einbindung in die Gefahrenabwehr, ermöglichen es Angreifern, Attacken zu intensivieren, sich tiefer einzunisten und Angriffe auf 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, wobei Probleme in der Regel eher von externen Parteien als von internen Prozessen oder der Überwachung erkannt werden.

Vergleich zu OWASP Top Ten 2017

Vergleicht man die neue Top-10-Liste für APIs mit den aktuell gültigen Top-10-Risiken für Web-Applikationen aus dem Jahr 2017 (A1–A10), stellt man rasch fest, dass einige Schwachstellen in vergleichbarer Form und zum Teil auch mit ähnlicher Gewichtung in beiden Listen zu finden sind:

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

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

Viel spannender als die großen Gemeinsamkeiten sind die Unterschiede: Das Thema „Injection“ wird zwar inhaltlich auf beiden Listen gleichermaßen geführt, aber die Beurteilung der Priorität ist doch recht unterschiedlich. Eine mögliche Erklärung kann sein, dass die für REST genutzten Tools praktisch flächendeckend eingesetzt werden und 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 dort auch heute noch das Risiko höher einzuschätzen. Was gegen diesen Erklärungsansatz spricht, ist allerdings 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, die scheinbar für APIs nicht einschlägig ist, ist die Schwachstelle „XML External Entities (XXE)“. 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 kein JavaScript interpretieren, aber APIs könnten dennoch Skripte übermitteln und so in XSS involviert werden. Vermutlich gehen die Autoren davon aus, dass die Inputvalidierung der API8 auch JavaScript-Injection verhindert und darum XSS als eigenständiges Risiko unnötig ist.

Die API-Security-Top-10 identifizieren zudem auch Risiken, die sich ausschließlich auf REST-APIs beziehen. Speziell wird „Broken Access Control“ (A5 der Top 10) sehr viel detaillierter und auch viel höher gewichtet. Mit API1, API3 und API6 sind drei Risiken identifiziert worden, die alle einen starken Bezug zu A5 haben: API1 umfasst Risiken, welche die Zugriffsautorisierung auf Objektebene durch manipulierte Identifier fokussieren, API3 befasst sich mit dem Auslesen von Daten direkt am API selbst und API6 beschreibt die Risiken der Manipulation von Attributen von Objekten, wenn diese ungewollt exponiert werden. Mit API4 (Lack of Resource and Rate Limiting) und API9 (Improper Asset Management) wird überdies dem Umstand Rechnung getragen, dass es viel mehr APIs gibt und diese auch sehr viel direkter exponiert sind: Businesslogik und Daten sind nicht durch Webserver oder Portale abgeschottet, was zusätzliche Maßnahmen erfordert, um Risiken in diesem Bereich reduzieren zu können.

Maßnahmen zur Sicherung von APIs

Aufbau einer Security-Infrastruktur

Um exponierte Schnittstellen zu schützen, gilt die Verwendung spezialisierter Sicherheitskomponenten heute als Best Practice – diese Aussage gilt unabhängig davon, ob diese spezialisierten Komponenten an der Peripherie des Firmennetzwerks ihren Dienst tun oder 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 man aus einer Vielzahl von Produkten auswählen, aber grundsätzlich sind immer folgende Funktionen abzudecken (vgl. Abb. 1):

  • Web-Application-Firewall (WAF) für den Schutz von Webseiten und Portalen
  • API-Gateway für den Schutz von REST-Schnittstellen
  • Identity- und Access-Management (IAM) für die Access Control zu Webseiten, Portalen und Schnittstellen

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

Die Angriffsfläche lässt sich bereits substanziell einschränken, wenn man nur die APIs exponiert, die auch wirklich von extern erreichbar sein sollen (API9). So wird vermieden, dass man Interfaces, die ausschließlich für den internen Gebrauch vorgesehen sind, unnötigen Risiken aussetzt. Ist eine OpenAPI-Spezifikation verfügbar, dann kann ein API-Gateway die Zugriffe sogar auf explizit für die Veröffentlichung spezifizierte Funktionen beschränken (API9) und zudem eine formale Input-Validierung der übermittelten Parameter vornehmen (API8).

Bereits im API-Gateway können außerdem „Rate Limits“ durchgesetzt werden (API4), ohne die eigentliche Businesslogik oder die Daten-Persistenz mit überzähligen Requests zu belästigen. In vielen Produkten sind die Policies dabei so umgesetzt, dass auch komplexe Business-Modelle unterstützt werden, die abhängig vom Benutzer verschiedene Limits erfordern.

Identity- und Access-Management-Systeme (IAM) stellen sicher, dass Benutzer angemessen authentifiziert werden (API2). Moderne IAM-Systeme unterstützen dabei Standards mit OAuth, OpenID Connect oder SAML und propagieren so die verifizierte Identität der Benutzer zu den Applikationen und APIs (API5). IAM-Systeme sollten zudem die Umsetzung von Single Sign-on über mehrere Applikationen hinweg ermöglichen und stellen oft auch Self-Service-Funktionen für Benutzer zur Verfügung.

Sowohl API-Gateway als auch IAM erzeugen allerdings sowohl technischen als auch fachlichen Log-Output, der idealerweise in einem Security-Information- und -Event-Management-(SIEM)-System gesammelt und analysiert werden sollte (API10).

Pflichten für Entwickler

Generell lassen sich jedoch nicht alle API-Risiken mit vorgelagerten Sicherheitskomponenten adressieren. Weil Business-Regeln nur in der Business-Logik der Schnittstelle bekannt sind, können sie auch nur dort korrekt und angemessen durchgesetzt werden. Die Frage, ob ein bestimmter User wirklich auf ein spezifisches Business-Objekt zugreifen darf, lässt sich nur in der Business-Logik der Applikation beantworten (API1). Aber auch im Zusammenhang mit API3 und API6 sind Entwickler in der Pflicht, ihre Schnittstellen so zu entwerfen, dass nur die notwendigen Informationen exponiert werden und nur erlaubt wird, was erlaubt sein soll.

Als Softwareentwickler sollte man sich aber darüber im Klaren sein, dass sichere Software nur dann entsteht, wenn man während der Entwicklung stets anstrebt, dass die Software auch ohne vorgelagerte Sicherheitskomponenten bedenkenlos einzusetzen ist. „Security by Design“ ist ein Gebot, das speziell bei der Entwicklung von APIs befolgt werden sollte!

Abbildung 1

Abbildung 1: Sicherheitsarchitektur mit Web-Application-Firewall, API-Gateway sowie IAM

Fazit

Die Liste der OWASP API-Security-Risks ist das Resultat der zunehmenden Bedeutung von REST-Schnittstellen und die logisch konsequente Weiterführung der allgemeinen OWASP Top 10. Zunehmende Bedeutung führt aber auch zu zunehmender Bedrohung,
weil APIs bereits heute und in Zukunft noch vermehrt angegriffen werden.

Geeignete Sicherheitskomponenten (WAF, API-Gateway und IAM-Systeme) können helfen, Risiken zu reduzieren – aber auch Entwickler sind in der Pflicht, um den sicheren Umgang mit Businesslogik und Daten zu gewährleisten.

Michael Doujak ist Product Manager Airlock Secure Access Hub bei der Ergon Informatik AG.

Literatur

[1] OWASP, API Security Project, Übersichtsseite, www.owasp.org/index.php/OWASP_API_Security_Project
[2] OWASP, API Security Top 10 – 2019, Dezember 2019, https://github.com/OWASP/API-Security/tree/master/2019/en/dist
[3] Mark O‘Neill, Dionisio Zumerle, Jeremy D’Hoinne, API Security: What You Need to Do to Protect Your APIs, Gartner Analyst Note, August 2019, www.gartner.com/en/documents/3956746
[4] Brian Krebs, USPS Site Exposed Data on 60 Million Users, Krebs on Security, November 2018, https://krebsonsecurity.com/2018/11/usps-site-exposed-data-on60-million-users/
[5] Catalin Cimpanu, Sky Brasil exposes data of 32 million subscribers, ZDNet, November 2018, www.zdnet.com/article/sky-brasil-exposes-data-of-32-million-subscribers/
[6] Tilman Wittenhorst, Adobe: 7,5 Millionen Konten der Creative Cloud offen im Internet einsehbar, heise online, Oktober 2019, https://heise.de/-4569845
[7] Mohit Kumar, Over 100 Million JustDial Users’ Personal Data Found Exposed On the Internet, The Hacker News, April 2019, https://thehackernews.com/2019/04/justdial-hacked-data-breach.html
[8] Enej Pungercar, GateHub Preliminary Statement, Juni 2019, https://gatehub.net/blog/gatehub-preliminarystatement/
[9] Dan Salmon, I Scraped Millions of Venmo Payments – Your Data Is at Risk, WIRED, Juni 2019, www.wired.com/story/i-scraped-millions-of-venmo-payments-your-datais-at-risk/
[10] Stefan Krempl, Biometriedatenbank mit 27,8 Millionen Einträgen ungesichert im Netz, heise online, August 2019, https://heise.de/-4496575
[11] Catalin Cimpanu, Researcher prints ‚PWNED!‘ on hundreds of GPS watches’ maps due to unfixed API, ZDNet, April 2019, www.zdnet.com/article/researcherprints-pwned-on-hundreds-of-gps-watches-maps-due-tounfixed-api/
[12] Apple, The future of healthcare is in your hands, https://www.apple.com/healthcare/
[13] Google Cloud, Cloud Healthcare API – FHIR, https://cloud.google.com/healthcare/docs/concepts/fhir
[14] Microsoft Azure, Azure API for FHIR, https://azure.microsoft.com/en-us/services/azure-api-for-fhir/
[15] Amazon AWS, Achieve Healthcare Interoperability by integrating Amazon Comprehend Medical with FHIR,
https://aws.amazon.com/blogs/industries/achievehealthcare-interoperability-by-integrating-amazon-comprehend-medical-with-fhir/
[16] HL7 FHIR Foundation, Homepage, http://fhir.org/
[17] HL7 FHIR, FHIR Specification, https://hl7.org/fhir/
[18] European Commission, Payment services (PSD 2) – Directive (EU) 2015/2366, Portalseite, https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu2015-2366
[19] Richtlinie (EU) 2015/2366 des Europäischen Parlaments und des Rates vom 25. November 2015 über Zahlungsdienste im Binnenmarkt, zur Änderung der Richtlinien 2002/65/EG, 2009/110/EG und 2013/36/EU und der Verordnung (EU) Nr. 1093/2010 sowie zur Aufhebung der Richtlinie 2007/64/EG, https://eur-lex.europa.eu/legalcontent/DE/TXT/?uri=CELEX:02015L2366-20151223
[20] PwC Financial Crimes Unit, Open banking: US is next, Financial Crimes Observer, April 2018, www.pwc.com/us/en/financial-services/financial-crimes/publications/assets/pwc-open-banking.pdf

Diesen Beitrag teilen: