Sicheres Speichern sensibler Daten in Datenbanken

[IchBins237]

Hallo zusammen,

Ich hol mal ein kleines Bisschen aus bevor ich zu meiner eigentlichen Fragestellung komme, damit ihr mein Anliegen besser einordnen könnt. Für die schnelle Variante hab ich euch meine Fragen fett hervorgehoben.

Ganz wichtig: Ich bin kein Softwareentwickler und habe glaub ich auch nicht vor das zu werden. Ich kann ein klein wenig programmieren, das war es aber auch schon. Dieses "ein klein wenig programmieren" möchte ich zur persönlichen Horizonterweiterung auf "ein wenig programmieren" erweitern.

Spoiler

Dazu erarbeite ich mir momentan als Freizeitprojekt eine Web App zur Arbeitszeiterfassung. Ich sehe es komplett als Hobbyprojekt und plane damit nicht, kommerziell erfolgreich zu werden. Gibt mehr als genug kommerzielle digitale Zeiterfassungen, da braucht's kein Produkt von einem Laienentwickler. Es ist auch nicht für den Einsatz bei meinem Arbeitgeber geplant und ich plane nicht den Service an mir Unbekannte oder Unternehmen selbst auszurollen.
Was ich aber plane ist, mein Projekt unter GNU AGPL der Öffentlichkeit zur Verfügung zu stellen. Vielleicht kann ja jemand später mal etwas damit anfangen.

Ich habe momentan einen konkreten Anwendungsfall für die Privatnutzung in meinem engeren Umfeld. Kann natürlich zügig obsolet werden, wenn das BAG Urteil zur Zeiterfassung einschlägt und auch jedes noch so kleine Unternehmen sich irgend eine bereits erhältliche Lösung kauft. Da es mir aber in erster Linie ums Lernen geht, mag das Projekt obsolet werden und "scheitern", das Gelernte bleibt mir ja aber erhalten.

Ich möchte das Thema einigermaßen vernünftig angehen, d.h. ich nutze bereits Gitlab mit unterschiedlichen Branches/Tags und hab mir für's Frontend bereits eine Pipeline gebaut, die mir mein Frontend beim Commit/Merge baut und auf unterschiedlichen Environments hostet um mal so meinen aktuellen Stand grob zu umreißen. Hab mich mit Lizenzen beschäftig und auch wenn ich keinen Service für Fremde anbieten möchte wird die Webseite am Ende im Internet für jeden erreichbar sein, daher muss ich mich zwangsläufig auch mit den nicht technischen Themen in dem Zusammenhang beschäftigen. Unit und Integration Test ist momentan auch noch out of Scope für mich, das folgt, wenn ich mal einen ersten Prototypen mit Frontend und Backend bereit hab, der mit erfasste Arbeitszeiten in eine Datenbank geschrieben hat. Ich brauche jetzt erstmal das "schnelle" Erfolgserlebnis und kann nicht alles auf einmal lernen

Für den Moment hab ich mein Flutter Frontend zumindest schonmal soweit, dass ich bestimmte Routen nur für via Firebase authentifizierte Nutzer freigebe, unauthorisiert sind erstmal nur die Login-Seite und Nutzungsbedingungen, Datenschutzerklärung, Impressum erreichbar. Eingeloggt gibts eine Zeiterfassungsseite, ganz simpel ein Button mit dem ich einstechen und ausstechen kann. Momentan ist das noch ein Klickdummy, hab also im Frontend umgesetzt, dass der die Startzeit beim ersten Klick aufnimmt, in den State working geht, den Button ändert, dass das erkenntlich ist und beim nächsten Klick die Endzeit aufnimmt und die Zeitdifferenz berechnet.
Hab auch schonmal zwei go-Microservices programmiert. Ein Service bekommt HTTP-Befehle und spricht über gRPC mit dem zweiten µ-Service um etwas in einer Postgres db zu speichern. Ganz primitiv erstmal und hat schonmal geklappt. Bin zuversichtlich, dass ich damit zurechtkomme.

Nun wisst ihr schonmal etwas über meinen Background und könnt hoffentlich auch ganz grob einschätzen, was in scope und out of scope für mein Projekt ist.
Nähern wir uns meiner Fragestellung etwas weiter.

Spoiler

Ich hab jetzt also meinen Ein- Ausstechen Button und die Authentifizierung. Die Arbeit und das Speichern soll nun also im Backend passieren, womit ich jetzt loslegen möchte.
Grobe Struktur: Ich hab ein API-Gateway. Im ersten Schritt möchte ich den Login des Users im Backend verifizieren mit übermittelten Firebase Token. Damit werden weitere geschützte Backend-Services freigeschaltet. Als erstes mal die Zeiterfassung selber, die mir eine Startzeit und Endzeit des Users in einer Datenbank speichert. Nächster Service ist für die Ermittlung der täglichen Arbeitszeit und des laufenden Saldos (=Flextime Konto) zuständig. Weitere Funktionen spare ich mir mal an dieser Stelle.
Später werde ich verschiedene Nutzergruppen benötigen. Grobe Idee:

• Mitarbeiter: Können ihre Zeit per "Stechuhr" erfassen und ihre eigenen Stundensalden sehen,
• Abteilungsverantwortliche: Können Arbeits-/Pausenzeitmodelle der MA ihrer Abteilungen festlegen, die AZ Daten der MA ihrer Abteilungen einsehen, fehlende Stechdaten und Abwesenheiten für die MA eintragen etc. und
• Admin: Mitarbeiter für's Unternehmen anlegen, Rollenzuordnung der Nutzer, KEIN Zugriff auf die Arbeitszeitdaten.

Nun meine Fragen:
Wie gestalte ich denn die Datenbanken, dass die Daten möglichst sicher verstaut sind?
Meine Ideen bisher:
1. Jedes registrierte Unternehmen bekommt eigene Datenbanken, nicht alles von jedem Unternehmen in eine Datenbank. Die Datentrennung kommt mir irgendwie richtig vor, ich weiß aber noch nicht wofür. Sinnvoll, zwingend erforderlich oder überflüssig?
2. Ich dachte im ersten Schritt, dass ich die Arbeitszeitdaten anonymisiert speichere mit Hilfe der uid von Firebase Auth. Für den einzelnen Nutzer der Gruppe Mitarbeiter wäre das ja ok. Der Mitarbeiter loggt sich ein und sieht und speichert seine Daten, dafür braucht es keine weiteren personenbezogenen Daten im App-Backend. Kommen die Datenbanken im Hintergrund in die falschen Hände, dann sehen die Bösewichte nur eine uid mit irgendwelchen Zeitdaten und werden es (hoffentlich) schwer haben das Personen zuzuordnen - Credentials mit Email Adresse liegen ja bei Firebase Auth und werden im eigentlichen App-Backend nicht verarbeitet.

Problem zu 2.:
Wie kann nun beispielsweise ein Abteilungsverantwortlicher Urlaub für einen Mitarbeiter eintragen?

Dazu müsste er einen Mitarbeiternamen, Personalnummer oder so was nutzen. Eine uid reicht nicht, damit kann derjenige ja nichts anfangen. Bringt es aus Datensicherheitssicht etwas z.B. die Arbeitszeitdaten nur uid's zuzuordnen und für die administrativen Themen einen zusätzlichen Service mit zusätzlicher Datenbank für Zuordnung uid zu Mitarbeiter-Namen, Abteilung etc. zu erstellen? Und wie lege ich dann sowas wie den Namen sicher in der Datenbank ab und gestalte den Service so, dass die Bösewichte nichts mit den Daten anfangen können, wenn sie in deren Hände gelangen?
Da das Projekt ja Open Source werden soll und jeder dadurch auch die Möglichkeit bekommt, eigene Server zu betreiben und den Service auf eigener Infrastruktur anzubieten wäre es dazu natürlich auch klasse, wenn der Serverbetreiber möglichst wenige Daten in Klartext bekommt. Gut, einen Unternehmens-Accountinhaber wird der Serverbetreiber kennen (müssen). Aber Namen der Mitarbeiter und deren Arbeitszeiten und weitere persönliche Daten gehen den Serverbetreiber nichts an.
Andererseits wäre es zukünftig aber von Vorteil, wenn verloren gegangene Daten auch wiederhergestellt werden könnten. Ein verloren gegangener Key des "Kunden", der zum Entschlüsseln von Daten dringend benötigt würde, stelle ich mir problematisch vor, da die Daten damit unbrauchbar werden könnten.

Ich möchte im Moment nicht die 100% Lösung entwickeln. Ich möchte aber natürlich den Grundstein so legen, dass das auch irgendwann mal skaliert, wenn ich Funktionen erweitere und die verschiedenen Benutzerrollen implementiere.
Mir reichen erstmal so grundsätzliche Anreize, wie so sensible Daten behandelt und sicher gespeichert werden können. Gibt's da Best Practices, gute Tutorials, die ich mir mal ansehen könnte oder Praxiserfahrungen von euch? Was sind die richtigen Begriffe, nach denen ich recherchieren muss? Im Zusammenhang mit serverseitigem Speichern von Passwörtern hab ich mal was von Hashen, Salt und Pepper gehört - sind das die Begrifflichkeiten mit denen ich mich für meinen Use Case auseinandersetzen muss?
Bevor ich mich ans programmieren mache möchte ich mich erstmal sortieren, wie und mit welchen Methoden ich das umsetzen möchte.
Wie gesagt möchte ich den Service nicht großartig selber selber ausrollen, sondern "nur" mal einem Freund/Bekannten/Verwandten zur Verfügung stellen. Trotzdem (oder gerade deswegen?) ist die Datensicherheit das a und o.

Und während ich das schreibe gefällt mir die Idee mit Zeiterfassungsdaten z.B nur mit uid in Verbindung bringen und später irgendwann mal Datenbanken und Services für Mitarbeiterdaten und Userrollen und so hinzuzufügen. Momentan ist der Bedarf nicht da, weitere persönliche Daten mit den Arbeitszeiten in Verbindung zu bringen, wenn ich nur ein, zwei Nutzer (inkl. mir selbst zum Testen) habe.

Danke euch für's Lesen meines Romans
Freue mich auf Anregungen und ihr braucht mir nicht im Roman antworten

 

[BeBur]

Ich kann ein klein wenig programmieren

Also mit deinem "klein wenig" bezeichnen sich andere bereits als Software Entwickler. Hut ab dafür, in Eigenmotivation das so aufzuziehen.

Sinnvoll, zwingend erforderlich oder überflüssig?

Nicht überflüssig, aber auch nicht zwingend erforderlich. Es gibt auch "row level security" bei DBMS, also Datenbanksystemen, bei PostgreSQL heißt das Row Security Policies. Das würde man zusätlich dazu machen, das man natürlich auf Applikationsebene sowieso ebenfalls sicher stellen muss, dass ein Nutzer auf zugehörige Daten keinen Zugriff erhält. Der Übergriff dazu lautet "Authorization" (abzugrenzen von "Authentication". Authentication = "Wer bin ich?", Authorization = "Was darf ich?").
Ein dritter Weg besteht sicherlich darin, einen jeweils eigenen eigenen Datenbank Table zu nutzen und auf dieser Ebene dann die Autorisierung umzusetzen.

Bringt es aus Datensicherheitssicht etwas z.B. die Arbeitszeitdaten nur uid's zuzuordnen und für die administrativen Themen einen zusätzlichen Service mit zusätzlicher Datenbank für Zuordnung uid zu Mitarbeiter-Namen, Abteilung etc. zu erstellen?

Potentiell ja, aber du müsstest als ersten Schritt ganz konkret definieren, gegen welche Szenarien das helfen soll. Generell würde man so etwas aber eher weniger machen, da es auch die Komplexität erhöht. Sicherheit gibt es immer nur gegen definierte Szenarien "Threat Model", z.B. "Angreifer erlangt root-Zugriff auf Server X".

Und wie lege ich dann sowas wie den Namen sicher in der Datenbank ab und gestalte den Service so, dass die Bösewichte nichts mit den Daten anfangen können, wenn sie in deren Hände gelangen?

Einmal kannst du die Daten verschlüsselt in der Datenbank ablegen und den Schlüssel dazu im RAM lagern, z.B. als Umgebungsvariable des Betriebsystems. Das hilft bestimmt gegen einige Szenarien, aber mir fällt spontan keines ein. Es gibt dann noch Zero-Knowledge Ansätze wie sie z.B. bei PasswortSafe Anbietern umgesetzt werden. Dabei werden Teile des Schlüssels ausschließlich lokal beim Nutzer abgespeichert/abgeleitet und auch erst beim Nutzer lokal entschlüsselt. Wenn aber z.B. alles bei dir auf einem Server läuft und ein Angreifer root-Zugang zu diesem erhält, dann kann dieser natürlich manipulieren, welche Website ausgeliefert wird an den Nutzer und diesem eine Seite unterschieben, mit welcher der Angreifer an den Schlüssel kommt.

Mir reichen erstmal so grundsätzliche Anreize, wie so sensible Daten behandelt und sicher gespeichert werden können.

Die werden im Regelfall deutlich normaler und unaufgeregter gespeichert als du zu glauben scheinst. Es wird hauptsächlich aus IT-Admininstration Perspektive best practice umgesetzt, dass ein Angreifer gar nicht erst in Kontakt kommt mit der Datenbank. Aber an sich wird das meiste in Klartext in der Datenbank hinterlegt (bis auf das Passwort).

Im Zusammenhang mit serverseitigem Speichern von Passwörtern hab ich mal was von Hashen, Salt und Pepper gehört - sind das die Begrifflichkeiten mit denen ich mich für meinen Use Case auseinandersetzen muss?

Passwörter werden grundsätzlich als hash abgespeichert und es ist eigentlich eher schwer, das anders zu machen. Falls die Passwörter nicht schon gehasht abgespeichert werden hast du da was wesentliches übersehen.

wäre es dazu natürlich auch klasse, wenn der Serverbetreiber möglichst wenige Daten in Klartext bekommt.

Das ist ohne Zero-Knowledge Ansatz nicht möglich, wer vollen Zugriff auf den Server hat, der hat immer auch vollen Zugriff auf alle Daten, die der Server irgendwie als Klartext erhalten kann. Dabei spielt es in erster Linie auch keine Rolle, ob der Server die Daten erst von einem anderen Server anfragen muss.

 

[NPC]

Dazu nur kurz zwei Sachen:

• Was du beschreibst ist "Multitenancy" 😉. Dabei bitte beachten: mehrere kleine DBs verbrauchen mehr CPU/RAM als eine große DB.
• Wenn Daten verschlüsselt in der DB gespeichert werden, dann können diese nicht mehr so einfach durchsucht werden.

 

[floq0r]

Kurze Antwort zum Thema Hash, Salt, Pepper: Hashen auf jeden Fall, mit Salt beugst du der Nutzung von Hash/Rainbowtables vor falls jemand deine DB klaut. Wenn du die Sache auch noch pfefferst fängt der Attacker mit der DB alleine gar nichts mehr an. Überflieg es mal und entscheide dann je nachdem wie exposed du dich fühlst.

 

[BeBur]

Wenn Daten verschlüsselt in der DB gespeichert werden, dann können diese nicht mehr so einfach durchsucht werden

Das stimmt so ganz allgemein nicht, es gibt searchable und homomorphe Verschlüsselung. Andererseits, womöglich meintest du genau das mit "nicht mehr so einfach" ;-). Nicht das ich dem TE dazu raten würde.

 

[Piktogramm]

Wie gestalte ich denn die Datenbanken, dass die Daten möglichst sicher verstaut sind?
Meine Ideen bisher:
1. Jedes registrierte Unternehmen bekommt eigene Datenbanken, nicht alles von jedem Unternehmen in eine Datenbank. Die Datentrennung kommt mir irgendwie richtig vor, ich weiß aber noch nicht wofür. Sinnvoll, zwingend erforderlich oder überflüssig?

Getrennte DBs haben mehrere Vorteile. Die Logische Trennung erlaubt u.a. je DB Kundenspezifische Keys für Verschlüsselung einzusetzen. Du kannst Backups für jeden einzelnen Kunden erstellen und getrennt absichern, bei hoher Last lässt sich der Spaß einfacher auf verschiedene Hardwareserver verteilen, ...
Im operativen Betrieb steigt jedoch der Aufwand, ein Großteil lässt sich zwar automatisieren. Es braucht aber meist etwas mehr Aufwand bei der Rechteverwaltung.

2. Ich dachte im ersten Schritt, dass ich die Arbeitszeitdaten anonymisiert speichere mit Hilfe der uid von Firebase Auth. Für den einzelnen Nutzer der Gruppe Mitarbeiter wäre das ja ok. Der Mitarbeiter loggt sich ein und sieht und speichert seine Daten, dafür braucht es keine weiteren personenbezogenen Daten im App-Backend. Kommen die Datenbanken im Hintergrund in die falschen Hände, dann sehen die Bösewichte nur eine uid mit irgendwelchen Zeitdaten und werden es (hoffentlich) schwer haben das Personen zuzuordnen - Credentials mit Email Adresse liegen ja bei Firebase Auth und werden im eigentlichen App-Backend nicht verarbeitet.

Für Menschliche Interaktion müssen die UUID irgendwelchen natürlichen Namen zugeordnet sein, Menschen sind einfach schlecht im Umgang mit 128bit Integern. Diese Zuordnung ist in der Regel Teil des Datenbestandes. Wenn du die Zuordnung UUID zu natürlichem Namen außerhalb der Datenbank pflegst, hast du am Schluss zwei Datenbanken, die du absichern musst und einen Nachteil bei der Performance sowie erheblichen Mehraufwand den Spaß Konsistent zu halten.

Und wie lege ich dann sowas wie den Namen sicher in der Datenbank ab und gestalte den Service so, dass die Bösewichte nichts mit den Daten anfangen können, wenn sie in deren Hände gelangen?

Imho falscher Ansatz (referenz: RFC 2119).
1. Es MUSS sichergestellt sein, dass nur berechtigte Personen an Informationen kommen
2. Alle Sicherungsmaßnahmen MÜSSEN handhabbar sein, damit keine Motivation besteht sensible Daten außerhalb der Anwendung zu verarbeiten.
3. Im Falle unberechtigten Zugriffs Sollte der Abfluss von Daten möglichst gering sein.

Aber Namen der Mitarbeiter und deren Arbeitszeiten und weitere persönliche Daten gehen den Serverbetreiber nichts an.

Wer immer Herr über die physische Hardware ist, kommt prinzipiell an alle Cryptoschlüssel und schlussendlich an die Daten im Klartext heran. So ein Computer muss an irgend einer Stelle die Daten ja im Klartext verarbeiten können[1]. Der Ansatz sollte also sein sinnvolle Sicherheitsmaßnahmen anzuwenden und ausschließlich Serverbetreiber zu nutzen denen man vertrauen kann, und wo es einen gescheiten Datenverarbeitungsvertrag gibt (nach DSGVO).

[1] Es gibt Ausnahmen und Sonderfälle, wo auf verschlüsselten Daten gearbeitet werden kann. Das kannst du bei deinem Anwendungsfall jedoch als unrealistisch abhaken.

Andererseits wäre es zukünftig aber von Vorteil, wenn verloren gegangene Daten auch wiederhergestellt werden könnten. Ein verloren gegangener Key des "Kunden", der zum Entschlüsseln von Daten dringend benötigt würde, stelle ich mir problematisch vor, da die Daten damit unbrauchbar werden könnten.

Und wenn du als Hoster auftrittst, brauchst du ein gescheites Sicherheitskonzept um alle etwaige Wiederherstellungskeys sicher verwaren zu können und etwaige Änderungen der Keys dennoch jederzeit nachvollziehen kannst.

wenn ich Funktionen erweitere und die verschiedenen Benutzerrollen implementiere.

Verschiedene Rollen und Berechtigungsstufen brauchst du von Anfang an. Das nachträglich zu implementieren wird großer Käse oder endet im komplett neu implementieren vom Allen. Den goldenen Zwischenweg bekommen die Wenigsten hin.
Der größte Angiffsvektor ist in der Regel nicht ein externer, sondern intern! Benutzer pennt und löscht alles, Benutzer pennt und exportiert alle Daten, Benutzer pennt und importiert/überschreibt fehlerhafte Daten, Admin ist verärgert und trägt alles raus, Passwordpolicies sind so dass Hashes und Salts nicht helfen, ...
Es ist daher sinnvoll von Anfang an Berechtigungsstufen vorzusehen. Ein normaler Nutzer darf nur eigene Datensätze sehen/bearbeiten. Diese Sicherung MUSS auf Ebene des Servers geschehen und MUSS NIE beim Clienten erfolgen! Änderungen Müssen nachvollziehbar sein!

Abteilungsleiter dürfen nur in eigenen Abteilungen sehen, Daten nur so ändern, wie es normale Benutzer auch dürfen, ..

Mir reichen erstmal so grundsätzliche Anreize, wie so sensible Daten behandelt und sicher gespeichert werden können. Gibt's da Best Practices,

https://owasp.org/www-project-developer-guide/draft/11-Principles-Security-Engineering
OWASP hilft.
Der größte Gag in der IT-Sec ist ja, dass es die wichtigsten Ratschläge für Lau gibt, sich dennoch kaum einer dran hält und im Gegegnzug Geld auf IT-Sec schmeißt

Im Zusammenhang mit serverseitigem Speichern von Passwörtern hab ich mal was von Hashen, Salt und Pepper gehört - sind das die Begrifflichkeiten mit denen ich mich für meinen Use Case auseinandersetzen muss?

Das ist wichtig für ALLES. Niemand sollte Passwörter speichern, Niemand sollte davon reden/schreiben Passwörter zu speichern!
Passwörter werden samt Salt gehasht und nur Hashes werden gespeichert!

 

[IchBins237]

Danke euch für eure Mühe
Ich nehme einige mir neue Begriffe und Quellen mit, die ich mir nun die nächste Zeit ergoogeln kann.

Ich nehme mit, dass ich die db Einträge nicht hashen muss sondern als Klartext speichern kann, da sie eben keine Passwörter sind.
Nochmal ganz deutlich: Passwörter liegen im Firebase Auth, die liegen nicht im Zeiterfassungs Backend, weder im Klartext noch als Hash. Da vertraue ich drauf, dass die Credentials bei Firebase sicher sind und Google dort sichere Methoden zur Speicherung hat.
Da der Login selber im Frontend mit Firebase Auth direkt passiert, werde ich im meinem Zeiterfassungsbackend das Firebase Admin SDK nutzen, im den ID Token dort nochmal zu überprüfen.
Ich bin froh, dass ich mir darüber dank Firebase wenig Gedanken machen muss.
Die Berechtigungsstufen arbeite ich aber aus, bevor es ans weitere Programmieren geht, ich verstehe euch so, dass das essenziell ist und lieber direkt berücksichtigt werden sollte.

Insbesondere das hat mir die Augen geöffnet.

Imho falscher Ansatz (referenz: RFC 2119).
1. Es MUSS sichergestellt sein, dass nur berechtigte Personen an Informationen kommen
2. Alle Sicherungsmaßnahmen MÜSSEN handhabbar sein, damit keine Motivation besteht sensible Daten außerhalb der Anwendung zu verarbeiten.
3. Im Falle unberechtigten Zugriffs Sollte der Abfluss von Daten möglichst gering sein.

Der Punkt ist also nicht, jeden einzelnen db Eintrag zu sichern, sondern die Zugriffsberechtigung und die db selber maximal zu sichern.

Ich danke euch nochmals, eure Antworten sind genau auf dem Level, wie ich sie brauche, verständlich mit den richtigen Anregungen zum Weiterrecherchieren 😃

 

[Testa2014]

Möchtest du deinen Kunden zwingen Google Dienste zu nutzen?
Persönlich würde ich auf flexible IDP‘s setzen, Stichwort OpenID (Connect) bzw. OAuth. Damit überlässt du dem Kunden ob er nu ein AD oder andere Dienste dafür nutzen möchte (auch Google). Auf diesem Wege kannst du auch SSO realisieren, wenn der Benutzer einmal angemeldet ist, wird er auch bei dir automatisch angemeldet. Du arbeitest dann auch mit einer ID, die du aber selbst nochmal Mappen solltest. Anbieter sind hier sehr vielfältig. Nichts desto trotz, würde „ich“ mindestens eine Grundfunktionalität selbst mitliefern. Sei es für den Admin oder auch weil der Kunde keinen externen IDP implementieren will oder kann. Oder auch benötigte Infos nicht zu Verfügung stehen, siehe nächsten Absatz. Für den Anfang wahrscheinlich zu komplex, wenn entwickelt wird, kann es schon auf dem Schirm sein und die Schnittstelle entsprechend flexibel entworfen werden.

Bzgl. Namen, je nach IDP kannst du auch verschiedenste Informationen abgreifen. Namen und Mail ist das mindeste. Wenn du an das AD gehst, könntest du auch (vorausgesetzt es gibt die Berechtigung dafür) das Organigram, Abteilung, … lesen. Im IDP gibt es idR auch Rollen (AD auf jeden Fall, Paypal wäre ich mir nicht so sicher ), so wäre das gleich mit zentral geregelt.

Bzgl Datenbank, würde für jeden Kunden ein Schema machen. Row based ist ganz nice um Daten innerhalb des Unternehmens zu trennen. Ja, das wird auch für mehrere Kunden genutzt (Beispiel Mandanten SAP). Die Vorteile alles in eigenen Schemata zu haben, überwiegt aus meiner Sicht. Mit vielen kleinen lässt es sich meiner Meinung nach besser arbeiten als einem großen. Der Kunde will die Daten, kannst du die ganz plump exportieren. Backups wären ebenso schneller und granularer.

Und was Berechtigungen angeht, je nachdem wie du deine DB/Service aufbaust. Berechtigungen nur Granular vergeben. Also nicht das der DB User alles darf. Neumodisch sind ja diese Microservices, wenn der nur Zeiten erfassen und anzeigen darf, darf er noch immer nicht eine Auswertung machen. Falls hier ein Service eine Schwachstelle aufweisen würde, könnte der Schaden reduziert werden. Und Sachen wie Drop, Export, Create … gehört sowieso nicht in einen nicht-Admin/deployment Benutzer.

Sicher, nur die Insellösung ist sicher (also nicht am Netz und am besten in der letzten Ecke eines Bunkers, bestenfalls noch aus. Nicht das die Putzkolonne da mit einem USB Stick Musik hören möchte). Du kannst es potentiellen Angreifern nur maximal schwer machen. Alles ist knackbar, eine Frage des Aufwandes (Zeit) und Geldes. Die DB schonmal nicht ins Netz hängen und den Service davor gescheit sichern wäre die Basis. SQL Injection als Schlüsselwort, wo wir wieder bei Berechtigungen sind. Erwarte eigentlich, das jedes halbwegs moderne Framework die Grundprinzipien implementiert hat. Da geht es beim Client mit XSS los.

An deiner Stelle würde ich erstmal anfangen und schauen was mit der Zeit kommt. Sonst ist es unglaublich demotivierend. Für den Anfang wirst du wahrscheinlich keinen IDP oder anmeldeservice brauchen. Kleine Schritte führen auch zum Ziel. Sprache und Framework solltest du als erstes definieren. Das im Nachhinein zu ändern ist eher anstrengend.

 

[Piktogramm]

Ich nehme mit, dass ich die db Einträge nicht hashen muss sondern als Klartext speichern kann, da sie eben keine Passwörter sind.

BITTE lies dir die Definition von Hashing und Encryption durch! Danach ist die Frage zu beantworten:
Wieso können Nutzdaten keine Hashes sein?
Wieso wäre es dumm Passwörter als Cipher abzuspeichern?

Nochmal ganz deutlich: Passwörter liegen im Firebase Auth

NEIN, Passwörter liegen NIE Irgendwo in einer AnwendungsDB (Ausnahmen Passwortmanager, wenn du einen PW-Manager in ne ProduktiveDB integrierst soll dich der Blitz beim ..).
Wenn du das sprachlich so definierst denkst du das auch so. Gewöhn es dir ab! Wenn du sowas liest sollte das augenblicklich Schmerz auslösen.

, die liegen nicht im Zeiterfassungs Backend, weder im Klartext noch als Hash. Da vertraue ich drauf, dass die Credentials bei Firebase sicher sind und Google dort sichere Methoden zur Speicherung hat.

Aua, Schmerz!

Da der Login selber im Frontend mit Firebase Auth direkt passiert, werde ich im meinem Zeiterfassungsbackend das Firebase Admin SDK nutzen, im den ID Token dort nochmal zu überprüfen.

Firebase nutzt glaube OAuth2.0, also wird Authentifizierung über OAuth abgewickelt und dagegen implementierst du. Aber ganz ehrlich, mit deinen grundlegenden Fragen solltest du erstmal eine Anwendung schreiben die Passwortauth in ordentlich macht. Ohne die Absicht das ja Produktiv einzusetzen, nur um es zu lernen. Der Zweite Schritt sind dann der Einsatz von Sessiontokens, der Umgang mit diesen inkl. Revokation(!) und dann solltest du genug gelernt haben um OAuth sinnvoll einsetzen zu können.

Bonusfrage: Wieso ist Revokation von Sessiontokens wichtig?!

Ich bin froh, dass ich mir darüber dank Firebase wenig Gedanken machen muss.

Das ist eine fehlerhafte Annahme, OAuth nimmt dir ein paar Punkte ab, wo sich Viele in den Fuß schießen, macht aber neue Baustellen auf. Dein Ansatz ist ein wunderbarer Quell für Fehler.

Der Punkt ist also nicht, jeden einzelnen db Eintrag zu sichern, sondern die Zugriffsberechtigung und die db selber maximal zu sichern.

Wie willst du einzelne Datenbankeinträge auch sichern? An irgend einer Stelle arbeiten Menschen ja mit den Daten im Klartext. Da kannst du Cryptofoos auf die DB schmeißen bis zum umkippen und es ist sinnlos, wenn der Zugriff von Klartext ungesichert möglich ist.

 

[IchBins237]

BITTE lies dir die Definition von

NEIN

Aua, Schmerz!

Tut mir Leid, wenn ich dich mit meinem Unwissen verärgert und verletzt habe

Aber ganz ehrlich, mit deinen grundlegenden Fragen solltest du erstmal eine Anwendung schreiben die Passwortauth in ordentlich macht.

Ich weiß nicht, ob ich dich richtig verstehe.
Soll ich deiner Meinung nach auf Firebase Authentication verzichten und mir selbst Gedanken darüber machen, wie ich mir einen eigenen Authentifizierungsservice baue, weil Firebase das nicht gut macht?
Oder bemängelst du WIE ich Firebase Auth nutze (bisher im Backend für die Zeiterfassung gar nicht, da es das noch gar nicht gibt und im Frontend kann man sich als registrierter Nutzer einloggen)
Ich möchte mein Backend mit Hilfe dessen, was mir das Firebase Admin SDK bietet, sichern. Sprich, gewisse Services nur für authentifizierte user. Authorisierung muss ich selbst irgendwie schaffen, das geht mit Firebase Authentication nicht. Ist das grundlegend falsch und wie wäre es richtiger?
Das ist übrigens mein Startpunkt zu dem Thema https://firebase.google.com/docs/auth/admin/verify-id-tokens?hl=de

Dein Ansatz ist ein wunderbarer Quell für Fehler.

Welchen Ansatz meinst du genau?

Wenn du das sprachlich so definierst denkst du das auch so. Gewöhn es dir ab!

Einverstanden, aber ich weiß halt nicht, wie ich es anders ausdrücken soll, dass Logindaten bei mir im Backend mit den Zeiterfassungsservices nichts zu suchen haben sondern die Authentifizierung über den Dienst Firebase Authentication aktuell bei mir mittels Email und Passwort läuft und daher dort bei Firebase die Daten in irgendeiner Form liegen. Das hoffentlich sicher, da nicht nur ich Firebase Authentication fürs Hobbyprojekt nutze sondern der Service auch produktiv von Unternehmen genutzt wird.

Wie willst du einzelne Datenbankeinträge auch sichern?

Das frage ich euch, darum bin ich hier Das weiß ich nämlich nicht. Dass ich mein Backend sicher gestalten muss, ist mir klar. Dass ich die Datenbank so gestalten muss, dass sie selbst vor unauthorisierten Zugriffen gesichert ist und zusätzlich user nur diejenigen Einträge zu Gesicht bekommen sollen, die sie etwas angehen, ist mir auch soweit klar. Dass ich dafür db Einträge nicht zusätzlich nochmals einzeln sichern muss, war mir nicht klar und das ist die Antwort auf meine Frage, die ich gesucht habe.

Ergänzung (28. März 2023)

Möchtest du deinen Kunden zwingen Google Dienste zu nutzen?

Mit meinem aktuellen Kenntnisstand scheint es mir sinnvoll einen Service zu nutzen, der mir das Werkzeug für die Authentifizierung bereit stellt. Scheint mir sicherer zu sein, als wenn ich mein eigenes Süppchen koche.

Zudem hab ich ja schon gesagt, dass ich selbst den Service wahrscheinlich gar nicht anbieten möchte (außer einem konkreten Nutzer privat im engeren Umfeld und mir selbst zum Test), aber den Quellcode öffentlich zugänglich unter AGPL machen möchte. Damit hat jeder die Möglichkeit alles aus dem Projekt zu machen. Oder es verschwindet in der Bedeutungslosigkeit, ist für mich auch ok, denn dann hab ich dabei trotzdem was gelernt.

Für meinen jetzigen Zweck muss die Zeiterfassung selber nicht rechtssicher sein. Aber da die Daten auf einem Server liegen sollen sie sicher abliegen, selbst wenn es nur meine eigenen Daten sind.
Um die Rechtssicherheit in Bezug auf die Zeiterfassung kann sich derjenige kümmern, der eine Zeiterfassung auf Basis meines Projekts als Service anbieten möchte. Dafür hat man dank AGPL ja die Möglichkeit den Code zu modifizieren.

 

[Piktogramm]

Tut mir Leid, wenn ich dich mit meinem Unwissen verärgert und verletzt habe

Das ist etwas überzeichnet und wie gesagt, es sollte sich bei dir einstellen, dass wenn irgendwo angedeutet wird, dass Passwörter als solche gespeichert werden dein erster Gedanke ist: Wasn Scheiß!

Ich weiß nicht, ob ich dich richtig verstehe.
Soll ich deiner Meinung nach auf Firebase Authentication verzichten und mir selbst Gedanken darüber machen, wie ich mir einen eigenen Authentifizierungsservice baue, weil Firebase das nicht gut macht?

OAuth2.0 ist sehr gut. Das Problem ist, du bist es (noch) nicht. Daher die Programmieraufgabe erstmal unproduktiv, also zur reinen Übung ein PW Auth zu implementieren.
1. Also Passwort Hashing (Erste Frage an dich, auf dem Clienten oder auf dem Server und wieso?)
2. Was ist Salt, was ist kryptografisch brauchbarer Zufall
3. Absichern der Übertragung.
4. Sessiontokens
5. Viertens, das sicher(?) Speichern von Tokens auf Client und Server

Und danach kannst du es ja mal zeigen, kritisieren lassen und selbst die OWASP Top10 durchgehen bzw. dein Werk mit den üblichen Fehlern von Authimplementierungen vergleichen.

Danach sollten die Grundlagen da sein, um die Dokumentation von OAuth verstehen zu können. Gerade das was du da selbst verlinkt hast, dass richtet sich nicht an Anfänger. Wie Fehler abzufangen sind, herauszufinden welche Fehler es gibt und wie sie abzufangen sind sowie da Absichern der Verbindung wird da anscheinend als Wissen vorausgesetzt. Beim Erstversuch bekommen das die aller wenigsten Hin, also bitte besagten Umweg gehen.

Welchen Ansatz meinst du genau?

Na den

Ich bin froh, dass ich mir darüber dank Firebase wenig Gedanken machen muss.

. Wenn du sicherheitskritische Komponenten von Dritten einsetzt, solltest du genau verstehen WAS diese Komponente WIESO macht und wie der Spaß sicher eingesetzt werden kann. Ebenso ist wichtig zu verstehen, WAS die Komponente NICHT tut und was komplett in deiner Verantwortung liegt. Bei OAuth2.0 bedingt das also, dass du dir mindestens die Dokumentation antust und verstehst. Imho ist das sehr weit weg von "wenig Gedanken machen müssen".
Und der "Was erledigt OAuth nicht für mich", erschließt sich wahrscheinlich erst, wenn du ein PW-Login einmal selbst ordentlich implementiert hast.

Einverstanden, aber ich weiß halt nicht, wie ich es anders ausdrücken soll, dass Logindaten bei mir im Backend mit den Zeiterfassungsservices nichts zu suchen haben

Grundlegend, Logindaten und Kontexte von Sessions können in beliebigen Datenbanken (nicht nur Firebase) gespeichert sein. Es ist nur wichtig zu wissen, WIE entsprechende Daten sicher verwahrt werden.
Wenn du die Authentifizierung selbst baust, dann eben Nutzername im Klartext und gesalzene Hashes zu den Passwörtern der Nutzer.

 

[IchBins237]

Muss ich nochmal verinnerlichen, ob ich bildlich gesprochen wirklich erstmal wissen muss, wie ein beliebiges Transportmittel entwickelt und gebaut wird, bevor ich mein Auto als für mich passendes Werkzeug für die Fahrt in den Urlaub auswähle und dann auch nutze.
Muss ICH für mein Vorhaben wirklich zwingend wissen, WIE Firebase Authentication sicherstellt, dass Logindaten sicher und nach Stand der Technik verwahrt werden? Oder kann ich z.B. im Frontend einfach signInWithEmailAndPassword nutzen und vertrauen, dass die dahinterstehende Technik im Firebase Backend sicher durch ein etabliertes Unternehmen wie Google implementiert wurde.
Für jemanden der vor hat irgendwo im Bereich Web Entwicklung für seine Arbeit entlohnt zu werden und dessen Auftraggeber/Arbeitgeber auf dessen Expertise angewiesen ist, bin ich irgendwie noch bei dir. Das bin aber nicht ich und habe auch nicht die Ambition das zu werden.

 

[BeBur]

Ich plädiere schwer dafür, jetzt nicht hinzugehen und zu versuchen, ein authentication system nach modernen Maßstäben selber zu bauen. Wenn man ganz gewissenhaft an die Sache rangehen will, dann sollte man stattdessen die Best Practice von OAuth lesen und sich daran entlang hangeln (Kapitel 2 im Dokument und z.B. den oben verlinkten "modern guide").

 

[Piktogramm]

@oettinger31
Autovergleiche hinken immer. Aber wenn du ein Fahrzeug führst wird von dir erwartet einen Führerschein zu machen, also grundlegende Kenntnisse zu haben. Genauso wie von dir erwartet wird, dass du das Kfz in einem verkehrssicherem Zustand halten kannst und diesen vor der Fahrt kontrollierst sowie während der Fahrt auf Unregelmäßigkeiten achtest.

Und Google beherrscht ihr Backend, Google beherrscht auch OAuth sehr gut. Nur dir mangelt das Verständnis um den Kram gescheit einbinden zu können. Wie wichtig Sessionhandling ist wurde der populären Techszene ja erst wieder gezeigt, als LinusTechTips ihre Sessiontokens für Youtube und in Folge die Kontrolle über mehrere Youtubechannel verlor. Es bringt halt gar nichts, wenn Google theoretisch das Backend gescheit auf die Reihe bekommt, die Sessiontokens im Frontend ungesichert rumlungern, über ungesicherte Verbindungen ins Netz gebrüllt werden und in der Logik deines Backends keine Chance besteht Tokens zurückzurufen.

Oder um beim hinkendem Vergleich zu bleiben, wer vom Roller absteigt sollte kein Kfz führen, sondern erstmal in die Fahrschule die Grundregeln lernen, inkl. der inbegriffenen Technikschulung.