Recherche¶

MariaDB (Daten automatisch verschlüsseln/entschlüsseln):

MariaDB besitzt eine eigene Funktion zur Verschlüsselung der Tabellen. Es ist eine Data-at-Rest Encryption und nennt sich "Transparent Data Encryption (TDE)".
Es wird davon ausgegangen, dass die Keys auf einem anderen System gespeichert werden.
Die Verschlüsselung benötigt einen Performance Aufwand von 3-5%.

Support ist ab MariaDB 10.1 gegeben für folgende Storage Engines ( https://mariadb.com/kb/en/data-at-rest-encryption-overview/ ):

• XtraDB
• InnoDB ( https://mariadb.com/kb/en/innodb-enabling-encryption/ )
• Aria (Nur für Tabellen, erstellt mit ROW_FORMAT=PAGE (der Standard))
  Konfigurationsmöglichkeiten (Auswahl: Was soll verschlüsselt werden):
• Alles -- Alle Tablespaces (mit allen Tabellen)
• Individuelle Tabellen
• Alles, ausgenommen individuelle Tabellen

Limitierung:

• Nur die Daten in der DB sind verschlüsselt und nicht der Transport der Daten (An den Client gesendete Daten sind nicht mehr verschlüsselt)
• Nur die MariaDB Server wissen wie die Daten entschlüsselt werden.
  Voraussetzung:
• Verwendung von Key Management und Verschlüsselungsplugin (Plugin für Key-Management und Verschlüsselung/Entschlüsselung der Daten gebraucht)
• Multiple Verschlüsselungs-Keys werden unterstützt und Key Rotation möglich (abhängig vom Plugin)
• Folgende Plugins stehen für MariaDB zur Verfügung ( https://mariadb.com/kb/en/encryption-key-management/ ):

• File Key Management Plugin
• AWS Key Management Plugin
• Eperi Key Management Plugin

Nice to know:

• Verschlüsselung der Tablespaces wurde durch Spenden von Google finanziert.
• Verschlüsselung der einzelnen und Support für die Key Identifizierung wurde durch Spenden von eperi finanziert.

In-Transit Encryption ( https://severalnines.com/blog/exploring-different-ways-encrypt-your-mariadb-data ):
Auch wenn MariaDB standardmässig keine Verschlüsselung für den Verkehr der Daten zwischen SQL-Server und Client benutzt, erlaubt es die Verwendung von TLS (Zuerst muss überprüft werden ob der verwendete MariaDB Server dies unterstützt-> SHOW GLOBAL VARIABLES LIKE 'version_ssl_library'). Wie auf der verlinkten Seite beschrieben müssen die drei Zertifikate und deren Keys dazu generiert werden (CA,Server,Client). Dem DB-User kann nun via GRANT das REQUIRE SSL Attribut vergeben werden.

Nutzen für QFQ:

Es ist die einfachste Variante, um Daten auf der DB sicher zu halten. Grundsätzlich ist man damit abgesichert, falls jemand Daten aus den DB Files stiehlt. Daten können von niemandem mehr direkt in der DB gelesen werden.
Der Verkehr der Daten zwischen QFQ und SQL ist jedoch ungesichert mit Ausnahme der Verwendung von TLS (Mehraufwand für Konfiguration), was in unserem Fall noch keine hohe Priorität hat.

Der Verlust der Keys bedeutet auch Verlust der Daten. Es kann nur die komplette Tabelle oder die ganze DB verschlüsselt werden aber nicht einzelne Spalten einer Tabelle. Somit wäre die Implementierung der Auswahl von einzelnen FE-Elementen zur Verschlüsselung hinfällig da alle Daten der entsprechenden Tabelle automatisch verschlüsselt werden.

Dadurch entfällt auch die Möglichkeit den Zugriff individuell für einzelne Personen oder Gruppen zu gestalten da nur ein Schlüssel pro Tabelle zur Verfügung steht. Jedoch kann für jede Tabelle ein anderer Key verwendet werden.

Dies ist eine Lösung falls nur die Sicherung der Daten auf der lokalen Hardware der DB sicherstellen soll.

BitWarden (Open source password manager):

Die Gratisversion von BitWarden bietet nur das Managen von eigenen Passwörtern.
Für die Verwendung von User Groups wird ein Teams Abonnement (3$ pro User im Monat) verlangt.
Ebenfalls gibt es noch die Features Custom Roles und Enterprise Policies die nur im höheren Enterprise Abo (5$ pro User im Monat) zur Verfügung steht.

Neben dem Browser und der nativen Applikation kann auch die CLI - Variante verwendet werden (Login mit Personal API Key auch möglich).

Infos über Gruppen: https://bitwarden.com/help/about-groups/
Infos über Bitwarden Public API: https://bitwarden.com/help/public-api/

Die Public API kommuniziert via JSON:
1. Der Organization API Key aus der Applikation wird benötigt, um den Zugriff zu ermöglichen (Falls eingeloggter User im Bitwarden zu einer Organisation gehört, ist der Key dort verfügbar.)

2. Ein POST Request mit Angabe des Content-Type und der Client ID + Client Secret sendet ein Access Token zurück mit Angabe der Gültigkeitsdauer als JSON.
3. GET Request zur Autorisierung kann mit dem erhaltenen Access Token gemacht werden. Als Resultat wird ein JSON Inhalt mit mehreren Informationen zurückgegeben.

Fragen in Verbindung zu QFQ:

Jeder User würde eine Registrierung beim Bitwarden benötigen?
Eigentlich bräuchten wir nur ein Login für den Admin, welcher Zugriff in die Liste der verschiedenen User und deren verschlüsselten Passwörter hat.
Für uns würde die Vault Funktion von Bitwarden reichen:
Speichern von einzelnen Logindaten in verschiedenen Ordnern. Mögliche Angaben: Name, Folder, Username, Password. Wäre keine richtige Verwaltung von Berechtigungen.
Via PHP müsste auf die CLI von Bitwarden Befehle ausgeführt werden können (system()?), um die Daten vom Frontend automatisch entgegen nehmen zu können. Die eingegebenen Werte müssen mit dem vorbereiteten Befehl in der CLI ausgeführt werden wie z.b. ein neuer Item (Logininfo) Eintrag in die Vault.

Beispiel: Im Frontend ist ein FE Input Feld speziell für das Eintragen eines Passwortes für die Verschlüsselung der Daten vorgegeben. User gibt Passwort ein und drückt auf Speichern. Das Form Save wird ausgeführt und im PHP nehmen wir den Wert entgegen und speichern diesen nicht in der DB, sondern überprüfen den eingegebenen Passwort mit dem eingeloggten Username auf Vorhandensein, indem wir einen CLI Command für Bitwarden zusammen bauen um ein vorhandenes Passwort auf den Username zu finden: bw get password Username

Falls erfolgreich bekommen wir das Passwort als Resultat zurück und vergleichen ihn mit dem eingegebenen Passwort, falls sie nicht übereinstimmen wird ein Command aufgebaut um das Passwort zur neuen Eingabe zu ändern:
Dabei wird die Item Id für diesen Vorgang gebraucht: bw get item Username
Anschliessend kann die Änderung gemacht werden:

bw get item 7ac9cae8-5067-4faf-b6ab-acfd00e2c328 | jq '.login.password="newp@ssw0rd"' | bw encode | bw edit item 7ac9cae8-5067-4faf-b6ab-acfd00e2c328

Falls kein Passwort unter dem Username gefunden wurde, dann brauchen wir folgenden Command für das Eintragen eines neuen Items in der Vault:

bw get template item | jq ".name=\"My Login Item\" | .login=$(bw get template item.login | jq '.username="jdoe" | .password="myp@ssword123"')" | bw encode | bw create item - Ablegung des Items in bestimmtem Folder muss überlegt werden und dazu werden weitere Angaben benötigt wie Rolle und vielleicht Domain.

Eine weitere Frage ist die Begrenzung der Anzahl Items in der Vault. Es würde sehr viele User geben, die ein Passwort für die Verschlüsselung setzen würden und die Frage ob Bitwarden eine Begrenzung für die Anzahl der abgelegten Items stellt (Da nicht für diese Art von Benutzung ausgelegt).

Das zweite Problem wäre die Unterscheidung der Logindaten in der Vault nach Gruppierungen. Es bräuchte eine umfangreiche Ordnerstruktur um für jedes Tool, jede darin befindlichen Gruppen und die enthaltenen Logins zu verwalten (Organisierung von Zugriffen). Komplett eigene Logik wäre nötig. Die Vault selbst ist nur für das Verwalten von Daten eines User gedacht und nicht für mehrere.
Bitwarden ist darauf ausgerichtet, dass jeder User ein eigenes Bitwarden Konto besitzt, welche dann zusammen die Organization und User Groups Features verwenden können. Es wäre eine Logik die von QFQ getrennt funktioniert. Müsste für jeden User ein Konto gebraucht werden dann hat man hohe monatliche Fixkosten.

JS Crypto Libraries (für Verschlüsselung/Entschlüsselung):

- crypto-js (Node.js) https://www.npmjs.com/package/crypto-js/v/4.1.1
- node-forge https://openbase.com/js/node-forge#installation
- SimpleCrypto.min.js https://simplecrypto.js.org/docs/
- jsaes.js http://point-at-infinity.org/jsaes/
- sjcl.js https://bitwiseshiftleft.github.io/sjcl/doc/