Datenbankhandling über eine Cloud?

[Rollo62]

Da ist eine grundsätzliche Frage die mir bei Cloud (egal Google, AWS, Azure) unklar bleibt.
Vielleicht passt das ja hier auch ganz gut hin.

1. Ich habe z.B. eine Tabelle (oder was auch immer) in der Cloud.
2. Dazu gehört ja i.d.R. eine App
3. Für die App bekomme ich immer einen ApiKey
4. Die Nutzer könnten als weitere Tabelle angelegt werden.
5. Ich kann in meiner App mehrere Nutzer auf die gleiche Tabelle zugreifen lassen,
   und die App hat über den EINEN ApiKey den Zugriff auf die Tabelle.
6. Für die User habe ich aber i.d.R. KEINEN separaten UserKey, oder etwa doch ?

Was ich meine ist:
Bedeutet das nicht:
Das meine App die EIN User regulär nutzt von diesem gehackt werden kann ?

So das dieser User mit dem ApiKey (über den er ja regulär Zugriff hat),
dann einfach die ganze Tabelle ausliest (Vollzugriff), und nicht nur einen für ihn bestimmten Teil ?

Ok, man könnte sich da sicher die ein oder andere Sicherheitsmethode drumrum bauen,
aber in der Standardtabelle/anwendung, z.B. per SQL, sehe ich keine Beschränkung durch spezielle UserToken o.ä.

Ich bin bis jetzt eher theoretisch damit unterwegs gewesen, und habe nur ein paar kleinere Versuche gemacht.
Aber für ein MultiUser-Management müsste man dann extra zahlen, dan ist man auch womöglich in verschiedenen Tabellen unterwegs, und relativ schnell auf horrende Summen.

Wie würde denn in der Cloud eine sicher MultiUser-App aussehen, in der alle User voll gegeneinander gekapselt sind ?

Sehe ich das richtig, oder bin ich da vielleicht auf der falschen Fährte ?

Rollo

[TigerLilly]

Naja, ich finde, das passt nicht ganz daher, aber sei´s drum:

Das was du beschreibst ist die "Mandantenfähigkeit". In einer Datenbank liegen viele Daten, aber immer nur Teile davon sind einem User/einer App/einem Mandaten zuzuordnen bzw dürfen von ihm verarbeitet werden.

Ob die DB in der Cloud liegt oder nicht, ist da egal. Deine App muss dafür sorgen, dass deine User nur die Daten sehen, die sie sehen dürfen.

Der API-Key erlaubt den Zugriff auf das (nona) API bzw den entsprechenden Dienst (muss ja kein API sein). Im Fall von Azure hast du zB einen Datenbankserver + kein API.

[Rollo62]

Vielleihct ist "mandantenfähig" zu viel des Guten.

Was ich meine ist, du hast ein App,

1. wo sich sagen wir mal 1000-10000 einzelne Nutzer registrieren.
2. jeder User kann sich selbst registrieren und bekommt ein Unique-UserToken.
3. Jetzt möchte jeder vielleicht seinen kleinen Bereich nutzen,
   sei es seine Settings speichern, seine Messdaten speichern, nichts Besonderes halt.

Mit dem AccessToken hätte doch ein User die Möglichkeit des Vollzugriffs, wenn er etwas hacken könnte ?

Wenn ich dafür schon die "mandantenfähige" Cloud brauche bin ich schnell im 3-4 stelligen Bereich pro Monat, und deshalb halte ich noch ziemlichen Abstand zur Cloud.
Und der User müsste aufwändig an der Cloud registriert werden.
Das mit der "günstigen" Cloud ist IMHO nämlich eine Mogelpackung

Es müsste aber doch eine "kleine" Lösung geben für solche Anwendungen,
und ich denke das ist es was der TE genauso sucht wie ich.
(also deshalb hoffe ich der TE mir diese kleine Zwischenfrage erlaubt )

Über DropBox, OwnCloud, etc. habe ich natürlich entsprechend auch nachgedacht,
ich bin aber im Moment eher bei einer kleinen PHP-Lösung mit REST-Service stehengeblieben.

Rollo

[mjustin]

Zitat von Rollo62:

Wie würde denn in der Cloud eine sicher MultiUser-App aussehen, in der alle User voll gegeneinander gekapselt sind ?

Bei Firebase über Berechtigungen. Man kann Resourcen (Daten) Berechtigungen geben, damit sind diese dann

* öffentlich, ohne Anmeldung, zugänglich
* öffentlich, aber nur nach Anmeldung zugänglich
* nur dem Besitzer zugänglich
* nur einer Benutzergruppe zugänglich

Code:

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Anyone can view any image (no auth, publicly readable)
      match /{allImages=**} {
        allow read;
      }

      // Only authenticated users can write to "public" images
      match /public/{imageId} {
        allow write: if request.auth != null;
      }

      // Only an individual user can write to "their" images
      match /{userId}/{imageId} {
        allow write: if request.auth.uid == userId;
      }

      // Allow a "group" of users to read/write to shared images
      // An owner metadata property on the object contains the groupId for reads
      // A custom token has been minted with a groupId property for writes
      match /{groupId}/{imageId} {
        allow read: if resource.metadata.owner == request.auth.token.groupId;
        allow write: if request.auth.token.groupId == groupId;
      }
    }
  }
}

https://firebase.google.com/docs/sto.../user-security

Den API Key benötigt man nur, damit sich die App bei der Verbindunng zu Firebase legitimieren kann.

[Rollo62]

Hallo Michael,

Richtig, Firebase hatte ich in der Liste vergessen.
Könnte eine einfache Möglichkeit sein, ich tendiere sowieso eher zu Firebase statt anderen Clouds für mobile Anwendungen, weil da Alles drin ist was man braucht.

Etwas schwammig bleiben immer die Kosten, die muss man sich z.B. bei AWS von zig Stellen zusammensuchen und grob schätzen, und erlebt hinterher böse Überraschungen.
Z.B. hatte ich mal eine "tote" EC2 Instanz die nach 1 Jahr Test angefangen hat ca. 18 EUR pro Monat abzubuchen, ohne das darauf irgendwas gelaufen ist.
Zum Glück hatte ich nicht noch 50 andere Services getestet.
Wie ist das für eine simple Anwendung bei Firebase, kannst du das kostenmäßig empfehlen ?
Google ist ja mit den Free Tiers recht moderat.

Wichtig wäre ja das ein Nutzer sich selbst einen privaten Bereich auf dem Service anlegen kann (nach Addresscheck),
ist das damit auch möglich, ohne das ein Admin das extra freigeben muss ?

Bei AWS gibt es ja auch etwas wie IAM Manager oder so ähnlich, für die Nutzerverwaltung.
Das ist aber ein relativ komplexes Thema, und braucht glaube ich immer EC2 Instanzen, auf die ich gerne verzichten würde.

Ach ja, bei AWS gibt es AWS Lightsail relativ neu, das habe ich mir aber noch nicht tiefer angesehen.

Rollo

[Morphie]

Zitat von Rollo62:

Mit dem AccessToken hätte doch ein User die Möglichkeit des Vollzugriffs, wenn er etwas hacken könnte ?
...
Es müsste aber doch eine "kleine" Lösung geben für solche Anwendungen,
und ich denke das ist es was der TE genauso sucht wie ich.
(also deshalb hoffe ich der TE mir diese kleine Zwischenfrage erlaubt )

Ich habe deine Bedenken noch nicht so ganz verstanden.
Normalerweise läuft es doch so, dass man irgendeine REST-API (oder ähnliches) in der Cloud hostet, an die man sich dann technisch per Access-Token anmeldet. (OAuth2)
Zu keiner Zeit hat ein Nutzer von außerhalb direkten Zugriff auf die Datenbank. Jede Anfrage muss also durch die API gestellt werden, die natürlich nur die Daten bereitstellt, die für den angemeldeten Benutzer (über den Access-Token) ersichtlich sein sollen.

[Rollo62]

Was ich meine ist:

Wenn eine App und deren Cloud die Nutzerverwaltung selber macht,
dann gibt es EINEN AppToken, mit dem ich theoretisch auf alle Bereiche zugreifen kann.

Wenn die App also Nutzer anlegen, löschen, etc. kann, dann könnte sie auch auf ALLE Nutzerdatentabellen zugreifen.

Der Zugriff müsste in der Cloud verhindert werden, durch eine Art "UserToken" oder "Mandanten-Steuerung", wie auch immer.
So das ein angemeldeter User nur auf SEINE eigenen Daten zugriff hat.

Die App könnte z.B. sowas einbauen, aber ein Hacker könnte immer an den lokal gespeicherten AppToken kommen und sich generellen Zugriff verschaffen.
Es muss eine Art UserToken geben, den nur die Cloud verwaltet, und die Tabellen und Daten gegeneinander abschottet.


Rollo

[Morphie]

Im Grunde ist es dasselbe Problem wie bei Anmelde-Cookies auf einer Website.
Daher ist sicherzustellen dass die Tokens nicht extern ausgelesen werden können (Dafür gibt es in der Regel spezielle Mechanismen auf den Devices).
Außerdem benötigt man ein sicheres Übertragungsmedium. (HTTPS)

[Rollo62]

Ja, der Web-Server kümmert sich darum.

Aber die einfachen Cloud-Tabellen eben nicht automatisch.
So sehe ich das zumindest.
Entweder muss man das mit anderen Anmelde-Diensten verknüpfen, oder in der Cloud Mehrnutzer-Handling beantragen/zukaufen, etc.

Dehalb bin ich ja bei einem einfachen PHP Rest Service, der kann die Authentifizierung wieder selber übernehmen.

Es sei denn es gäbe einen Trick das auch bei AWS, Azure, etc. mit einfachen Mitteln hinzubekommen.
Der Tipp mit Firebase geht ja in die Richtung, muss ich checken.

[mjustin]

Zitat von Rollo62:

Dehalb bin ich ja bei einem einfachen PHP Rest Service, der kann die Authentifizierung wieder selber übernehmen.

Selbst verwalten bringt natürlich wieder den Aufwand der Benutzer- und Passwortverwaltung mit sich. Wenn es um eine App geht, sind Facebook oder Google Konten eine beliebte Methode, ohne weitere Passworteingabe authentifizieren zu können. Damit braucht man auf dem Server keine Benutzer/Passwortzuordnung mehr. Sobald ein Benutzer z.B. ein Google Konto auf dem Smartphone nutzt, kann Google ein kontobezogenes Zugriffstoken erzeugen - dieses kann die App an den Server senden, der Server (z.B. ein Webservice) kann dieses Token bei Google gegenchecken lassen. Falls Google das Token als gültig bestätigt, kann der Server dem Client vertrauen. "Wer" der Client ist, kann der Server aus der Google-Antwort auslesen (z.B. die registrierte E-Mailadresse des Kontos).

p.s. mit der Google App Engine hatte ich vor einigen Jahren eine cloudbasierte Datenbank für Delphi madExcept Bugreports im Betatest[1][2], diese unterstützte bereits OpenID Identitätsprovider und trennte die Benutzerdaten je registriertem Benutzerkonto (aus Zeitmangel habe ich die Entwicklung dann eingestellt).

[1] https://www.delphipraxis.net/159516-...tegration.html
[2] https://mikejustin.wordpress.com/201...-in-the-cloud/