Dieses Dokument erklärt die grundlegenden Konzepte von Open as App, stellt die Architektur des Gesamtsystems vor und greift insbesondere die sicherheitsrelevanten Themen auf.
Es ist wie folgt organisiert.
- App-Rendering
- App-Erstellungsprozess
- App-Erstellungsprozess mit externen Cloudanbietern
- App-Erstellungsprozess mit on-premise Dateien
- Authentifizierungskonzepte
Bei diesem Artikel handelt es sich um eine Übersetzung. Die Originalfassung finden Sie unter diesem Link: https://support.openasapp.net/hc/en-us/articles/209775469.
Bevor die die Architektur des Gesamtsystems und die damit verbundenen sicherheitsrelevanten Fragen diskutiert werden können, muss zunächst das grundlegende Konzept von Open as App betrachtet werden: das dynamische Rendern von spreadsheet-basierten Apps auf Client-Geräten.
Open as App rendert spreadsheet-basierte Apps on-demand auf Client-Geräten, sobald der Benutzer eine App startet. Für diesen Prozess werden zwei Ressourcen benötigt: 1) eine lokale Kopie des ursprünglichen Spreadsheets, und 2) eine App-spezifische sogenannte app definition (siehe Abbildung 1). Die app definition enthält deskriptive Daten der App (Name, Beschreibung, Icon, etc.) und liefert dem Client-Gerät Anweisungen, wie mit den Daten aus dem Spreadsheet interagiert werden muss und wie diese visualisiert werden. Die app definition enthält keine sensiblen Daten, sondern beschreibt lediglich die Benutzeroberfläche und enthält Verweise auf einzelne Segmente des Spreadsheets. Siehe Tabelle 1 für eine beispielhafte app definition. Daten und Logik werden direkt von dem Spreadsheet selbst zur Verfügung gestellt. Dies ermöglicht eine klare Trennung von Layout, Daten und Logik. Beide Bestandteile - das Spreadsheet und die app definition - werden auf dem Client-Gerät synchronisiert und on-demand miteinander kombiniert, sobald der Benutzer eine App startet. Dies ermöglicht nicht nur offline-Zugriff, sondern auch eine voneinander unabhängige Aktualisierung der einzelnen Ressourcen.
Abbildung 1: Die App wird aus dem Spreadsheet gerendert, die app definition lokal auf dem Client-Gerät.
Alle synchronisierten Daten sind sicher in einem verschlüsselten Speicher auf dem Client-Gerät gelagert, und durch die Anmeldeinformationen des Benutzers und die Microsoft Data Protection API (DPAPI) geschützt[1]. Die Möglichkeit MobileIron[2] für zusätzlichen Schutz der Daten zu verwenden ist bereits in der Pipeline.
Tabelle 1: Beispielhafte app definition für die Darstellung einer spreadsheet-basierten App.
| Id | fb864b33-c138-4b16-b582-e6bf25a65895 |
| Name | BMI Calculator |
| Description | Body Mass Index Calculator |
| SpreadsheetUrl | https://data.openasapp.net/fb864b33-c138-4b16-b582-e6bf25a65895.xlsx |
| Layout | …<item caption="Body Height" inputtype="input" contenttype="integer" address="B1">... |
| Owner | apphub@openasapp.net |
| PublishMode (internal, not synced) | private |
| AccessControlList (internal, not synced) | [j.doe@openasapp.net, …] |
Das gesamte Open as App System besteht aus drei Hauptkomponenten: 1) dem web-basierten Management-Portal für die Erstellung, Pflege und Verteilung von Apps, 2) dem Open as App Player für die Nutzung der Apps auf Client-Geräten, und 3) dem Open as App Cloud Service der beide Plattformen miteinander verbindet. Der Open as App Cloud Service kann in drei Sub-Bereiche unterteilt werden: 3a) App-Erstellungssdienst, 3b) App-Verteilungsdienst, und 3c) Open as App Cloud-Speicher.
Abbildung 2 veranschaulicht die Zuständigkeit der Hauptkomponenten des Systems anhand von drei beispielhaften, grundlegenden Anwendungsfällen die der Nutzer spielt. App distributor - App Ersteller, app consumer - App Benutzer. Apps werden über das Management-Portal erstellt und veröffentlicht, mit dem App-Player werden diese dann benutzt. In allen drei use cases (App-Erstellung, App-Speicherung, App-Verteilung) ist der Open as App Cloud Service involviert.
Abbildung 2: Aufgaben des Management-Portals, des App-Players und des Cloud-Services.
Abbildung 3 bietet eine umfassende Abbildung des Workflows von der Erstellung bis hin zum Konsum einer spreadsheet-basierten App.
Abbildung 3: Workflow für das Erstellen und Konsumieren einer App, die auf einem, beim Benutzer lokal gespeichertem, Spreadsheet basiert.
Für die Erstellung einer App sendet der Benutzer sein Spreadsheet an den App-Erstellungsdienst, wo es mit der (zum Patent angemeldeten) 'Open as App'-App-Erstellungstechnologie verarbeitet wird. Der Benutzer verhandelt das gewünschte App-Layout mit dem App-Erstellungsdienst über das Management Portal in einem semi-automatischen Prozess. Es ist wichtig anzumerken, dass der App-Erstellungsdienst ein in der Open as App Cloud isoliertet Service ist, der die Daten sicher im Speicher verarbeitet. Zwischenergebnisse von diesem Service werden nur temporär und anonym, in einem sicheren, nicht-anhaltenden (non-persisting) hinter-VPN (behind-VPN), in-memory Redis[3] Cache gespeichert. Diese laufen nach einer kurzen Inaktivität des Nutzers automatisch ab und sind nur für dem aktiven Benutzer sichtbar. (Gesichert durch einen zufälligen id-token der nur der aktiven Browser-Session des Nutzers bekannt ist.) Kein 'Open as App'-Service und vor allem keine Dritte Partei haben Zugriff auf die für den App-Erstellungsdienst zur Verfügung gestellte Dateien, ohne eine explizite Aufforderung vom Benutzer selbst zu haben. Darüberhinaus werden diese Dateien nur für den App-Erstellungsprozess verwendet. Zu keinem Zeitpunkt werden Daten aus dieser Datei an einem persistenten Standort gespeichert, weder direkt noch indirekt. Insbesondere werden weder personalisierte, noch anonyme Analysen der Dateien unternommen und gespeichert. Die Verarbeitung findet ausschließlich im Speicher statt. Weder die Datei selbst, noch jegliche davon abgeleitete Daten werden in der Cloud gespeichert. Außer man entscheidet sich das Spreadsheet in der Open as App Cloud zu hosten, anstatt bei externen Cloud-Speicher-Diensten oder on-premise. Dennoch bietet Open as App die Möglichkeit, Apps von Hand zu erstellen und damit die gesamte Interaktion mit dem App-Erstellungsdienst für eine App, aus einer Umgebung mit höchster Sicherheitsstufe, zu überspringen[4]. Dies bedeutet jedoch den Verzicht auf das, zum Patent angemeldete, semi-automatische, App-Erstellungsystem von Open as App.
Nachdem der Benutzer sich für ein App-Layout entschieden hat, kann er die App hochladen und veröffentlichen. Das Spreadsheet wird in die Open as App Cloud hochgeladen. Technisch gesehen wird das Spreadsheet mit dem (nur dem aktiven Browser-Session des Nutzers bekannten und zufälligen) Identifizierungstoken, aus dem in-memory Cache des App-Erstellungsdienst abgerufen und nicht ein erneutes mal hochgeladen. Die app definition, einschließlich der URL des Spreadsheets werden an den App-Verteilungsdienst von Open as App weitergereicht. Bei der Erstellung einer App aus einem lokal verfügbaren Spreadsheet des Nutzers, wird die Datei in der Open as App Cloud gespeichert. Dieser Schritt ist jedoch optional, da das Spreadsheet auch bei externen Cloud-Speicher-Diensten (wie Dropbox, Microsoft Onedrive oder Google Drive) oder auch auf lokalen Servern (on-premise) gehostet werden kann. Siehe folgende Abschnitte: App-Erstellungsprozess mit externen Cloudanbietern und App-Erstellungsprozess mit on-premise Dateien für mehr Informationen zu diesem Thema.
Nachdem die App veröffentlicht wurde, kann sie von berechtigten Nutzern konsumiert werden. (Siehe Artikel Team, User, Gruppen und Gäste | Verwaltung, um mehr über die Möglichkeiten der App-Distribution bei Open as App zu erfahren.) Für diesen Zweck ruft der app player die app definition aus dem App-Verteilungsdienst, sowie eine Kopie des Spreadsheets aus dem Cloudspeicher auf. Sowohl die app definition, als auch das Spreadsheet selbst werden durch das Open as App Authentifizierungs- und Ressourcen-Sharing-System unzugänglich für Benutzer ohne ausdrückliche Genehmigung durch den App-Administrator gemacht. (Siehe folgenden Abschnitt Authentifizierungskonzepte für mehr Informationen.) App definition und das Spreadsheet werden dann on-demand auf dem Client Gerät miteinander kombiniert, um die App, wie bereits im Abschnitt App-Rendering beschrieben, zu rendern. Dieses Verfahren trennt das Layout, Daten und Logik und ermöglicht so das Abrufen des Spreadsheets aus verschiedenen Datenquellen wie zum Beispiel von externen Cloud-Speicher-Diensten (wie Dropbox, OneDrive oder Google Drive) oder sogar von on-premise Servern. So kann Open as App benutzt werden, ohne dabei sensible Daten in der Cloud speichern zu müssen. Dieses Thema wird in den folgenden Abschnitten: App-Erstellungsprozess mit externen Cloudanbietern und App-Erstellungsprozess mit on-premise Dateien beleuchtet.
App-Erstellungsprozess mit externen Cloudanbietern
Wie im vorherigen Abschnitt erläutert, wird Nutzern die Möglichkeit geboten, Spreadsheets für die Apps in der Open as App Cloud zu hosten. Allerdings bietet Open as App auch die Integration mit einer Vielzahl von externen Cloud-Speicher-Diensten (Dropbox, OneDrive und Google Drive) und ermöglicht dem User so die Erstellung von Apps die aus Spreadsheets aus der eigenen Cloud stammen.
Abbildung 4 zeigt den Workflow bei der Erstellung und Nutzung von Apps die auf bei externen Cloud-Speicher-Anbietern gespeicherten Spreadsheets basieren. Durch den modularen Aufbau des Open as App-Systems ist dieser Workflow sehr ähnlich wie der Workflow im vorhergehenden Abschnitt. Im Grunde unterscheiden sie sich nur in der Art und Weise wie das Management-Portal und der App-Player auf das Spreadsheet zugreifen.
Abbildung 4: Workflow bei der Erstellung und Nutzung von Apps die auf bei externen Cloud-Speicher-Anbietern gespeicherten Spreadsheets basieren.
Der App-Erstellungsprozess beginnt mit dem Abrufen des für die App-Erstellung relevanten Spreadsheets durch das Management-Portal. Der Benutzer wählt den gewünschten Cloud-Speicher-Dienst, authentifiziert sich auf der Plattform (in der Regel unter Verwendung von OAuth[5]) und wählt die Datei die für die App-Erstellung verwendet werden soll. Anschließend lädt das Management-Portal die Datei in den lokalen Speicher und fährt mit dem App-Erstellungsprozess so fort, als ob die Datei vom lokalen Gerät des Benutzers stammen würde, bis zu dem Zeitpunkt an dem der Benutzer im Begriff ist, die App zu veröffentlichen. Speziell die Interaktion mit dem App-Erstellungsdienst bleibt gleich. Bei der Veröffentlichung der App, wird das Spreadsheet nicht in den Open as App Cloud Speicher hochgeladen. Stattdessen wird die app definition direkt mit de, ursprünglichen Speicherort des Spreadsheets verknüpft, da die Datei bereits online zur Verfügung steht.
Der Prozess der Verwendung einer App bleibt im wesentlichen identisch mit dem einer in der Open as App Cloud gehosteten Datei. Der einzige Unterschied liegt in der Art und Weise wir der app player das Spreadsheet aufruft. Zunächst ruft der app player die app definition aus dem App-Verteilungsdienst und lädt das Spreadsheet runter. Anstatt das Spreadsheet aus der Open as App Cloud abzurufen, ruft der app player das Spreadsheet direkt vom externen Cloud-Speicher-Anbieter. Die Datei wird lokalisiert. Wenn nötig, wird der User mit der externen Plattform authentifiziert (in der Regel mit OAuth5). Die Datei wird dann in den verschlüsselten lokalen Speicher abgelegt. Danach werden beide Ressourcen, die für die App entscheidend sind, wie üblich on-demand miteinander kombiniert.
App-Erstellungsprozess mit on-premise Dateien
So wie Open as App mit externen Cloud-Speicher-Diensten verwendet werden kann (wie im Abschnitt App-Erstellungsprozess mit externen Cloudanbietern erläutert), ist auch die Verwendung mit on-premise Servern (wie SharePoint on-premise Installationen) möglich. Abgesehen vom Serverstandort unterscheidet sich dieser Ansatz nicht von dem im Abschnitt zuvor beschriebenem. Bitte lesen Sie den Vorherigen Abschnitt App-Erstellungsprozess mit externen Cloudanbietern für weitere Details zu diesem Ansatz.
Spreadsheets können on-premise gehostet werden. Einzig und allein die app definition - die keine sensiblen Daten enthält - wird in der Cloud mit dem App-Verteilungsdienst gehostet. Sowhl das Management Portal, als auch der App Player rufen das Spreadsheet direkt von ihrem ursprünglichen Speicherort auf und benötigen dafür keine Interaktion mit einem Cloud-Speicher-Dienst. Deshalb können Spreadsheets ebenso on-premise gehostet werden, wie sie bei externen Cloud-Speicher-Diensten gehostet werden können. Da beide Systeme lokal auf dem Client-Gerät des Nutzers laufen, ist es sogar möglich Apps zu benutzen deren Spreadsheets sicher auf lokalen Servern, hinter privaten VPN gespeichert sind. Es ist dabei nicht erforderlich, dass der Server über eine öffentliche IP-Adresse erreichbar ist. (Der app player ist eine native mobile App. Das management portal ist eine reine JavaScript-Anwendung, die über den Browser des Users läuft.) Mit diesem Ansatz bietet Open as App die maximale Datensicherheit. App-Distributoren haben größte Kontrolle über ihre Apps, da sie auch volle Kontrolle über ihre Daten haben. Es ist technisch unmöglich eine App zu benutzen, wenn kein Zugriff auf das dazugehörige Spreadsheet besteht. Deshalb bedeutet die Rücknahme der Zugangsberechtigung zum Spreadsheets automatisch auch die Zugangsverweigerung zu dieser App.
Open as App kann mit allen on-premise Servern, die Dateien über das HTTP-Protokoll anbieten, integriert werden. On-premise-Dateien können mit der Standardauthentifizierung NTLM oder OAuth gesichert werden. Erweiterte Authentifizierungstechniken wie Kerberos befinden sich in der Entwicklungspipeline.
User registrieren sich bei Open as App über Ihre E-Mail-Adresse und ein Passwort ihrer Wahl. Passwörter werden mit einem 64-bit salt kombiniert und als hashes mit PBKDF2[6] abgeleitet. Dabei werden, wie von NIST[7] empfohlen, mindestens 10.000 Iterationen verwendet.
Die Benutzer werden aufgefordert ihre E-Mail-Adresse zu bestätigen, um alle Funktionen von Open as App nutzen zu können. Nutzer können ohne Bestätigung Apps erstellen und ausprobieren, für das Annehmen einer Einladung müssen sie jedoch einen bestätigten Open as App Account haben. Dies verhindert unberechtigten Zugriff auf freigegebene Apps.
Erweiterte Authentifizierungskonzepte wie z.B. die Integration in die Active Directory eines Unternehmens oder erweiterte Sicherheitsrichtlinien für Teams sind in der Entwicklungspipeline.
Die Authentifizierung basiert auf kurzlebigen, HMAC-SHA256 unterzeichneten, JWT[8] Tokens. Client Geräte verwenden widerrufbare Refresh-Tokens, um permanenten Zugriff zu erhalten.
E-Mail-Bestätigungs-Links sind mit nicht ablaufenden, HMAC-SHA256 unterzeichneten, JWT 7 Tokens gesichert.
Einladungs-Links sind mit nicht ablaufenden, HMAC-SHA256 unterzeichneten, JWT 7 Tokens gesichert.
Passwort-zurücksetzen-Links werden mit kurzlebigen (Ablauf nach 24 Stunden), HMAC-SHA256 unterzeichneten, JWT 7 Tokens gesichert.
[1] Microsoft Data Protection API: https://msdn.microsoft.com/en-us/library/ms995355.aspx
[2] MobileIron: https://www.mobileiron.com
[3] Redis: http://redis.io
[4] Kommt bald
[5] OAuth: http://oauth.net
[6] PBKDF2: http://www.ietf.org/rfc/rfc2898.txt
[7] NIST Recommendation for Password-Based Key Derivation: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf
[8] JWT: https://jwt.io
Kommentare
0 Kommentare
Zu diesem Beitrag können keine Kommentare hinterlassen werden.