[Java SDKs] SDK speichert Anlagen ohne Verschlüsselung im Dateisystem
Description of the bug:
- Es sollen große Anlagen versendet oder empfange werden
- In der Konfiguration wird ein Dateipfad (
.attachmentStoragePath(Path.of("/custom/path"))) gesetzt (siehe Anleitung) - Die Anlagen werden vor dem Versand bzw. nach dem Empfang unverschlüsselt in dem gesetzten Verzeichnis zwischengespeichert
Hinweis: Wird der Dateipfad nicht gesetzt, so wird das temporäre Verzeichnis des Systems genutzt.
Current behavior:
Anlagen werden unverschlüsselt im Dateisystem gespeichert.
Expected behavior:
Anlagen werden nur verschlüsselt gespeichert.
-
Abschließend sollten wir auch die Lasttests mit Team INF laufen lassen. (Unterschiedliche Chunk-Größen, wenig Arbeitsspeicher, etc.)
Environments:
Alle, betrifft SDK
Additional Information:
Je nach Grad der Vertraulichkeit dürfen Anlagen nicht unverschlüsselt gespeichert werden. Dies betrifft z.B. besonders schützenswerte Daten nach Art. 9 DSGVO. Da die Zwischenspeicherung im SDK nicht umgangen werden kann, muss der Betreiber eines Onlinedienstes oder Verwaltungssystems einen verschlüsselten Speicher zur Verfügung stellen und zusätzlich den Zugang zum System besonders sichern.
Es ist daher wünschenswert, dass das SDK eine oder mehrere der folgenden Verbesserungen umsetzt:
- Analgen nur verschlüsselt zwischenspeichern.
- Die Anlage wird als Stream in einen Puffer gelesen
- Sobald der Puffer gefüllt ist, wird er verschlüsselt
- Das verschlüsselte Fragment wird auf der Platte zwischengespeichert
- Der Stream wird weiter gelesen (zurück zu Schritt 1)
- Am Ende des Streams wird der Rest im Puffer verschlüsselt und als letztes Fragment übermittelt.
- Es wird ermöglicht, statt einem Pfad einen eigenen Storage Provider als Interface zu übergeben. Der Storage Provider erhält die zwischenzuspeichernden Daten und kann diese vor der Speicherung im Dateisystem verschlüsseln
- Es wird für jeden Sende- oder Empfangsvorgang ein AES-Key generiert, mit dem die unverschlüsselten Dateien verschlüsselt werden. Nach dem Ende des Vorgangs wird der Key verworfen.
Dependency / relationship to other issues:
Responsible person / team:
Contact persons including contact details:
Screenshots / Logs / Requests:
Checklist:
-
Add Severity label -
Add team label -
Related/affected issues/stories/epics linked and explained in the bug issue -
Creation of an automated test -
Bugfix deployed on DEV -
Bugfix tested on DEV -
Bugfix deployed on TEST -
Bugfix tested on TEST (possibly also by the connection project itself) -
Successful fix reported to Team Operations (Teams channel) -
Bugfix deployed on STAGE -
Bugfix tested on STAGE if necessary -
Bugfix deployed on PROD -
Bugfix tested on PROD (possibly also by the connection project itself) -
Final communication by Team Operations if necessary -
Internal documentation was checked and updated if necessary -
External documentation has been checked and updated if necessary -
Updated changelog if necessary
Approach/Solution:
Release version of the artifact:
Edited by Wojciech Gdaniec