Virtuelle Datei erstellen

[Sekundentakt]

Hallo Gemeinde,

für meine ersten JavaEE - Erfahrungen habe ich mir ein recht komplexes Projekt gesucht.
Dabei geht es darum, eine Anwendung in ein Servlet einzubetten, wobei das Servlet Zugriffe etc. auf die Anwendung verifiziert und ggf. anpasst.

Leider benötigt die einzubettende Anwendung eine Konfigurationsdatei, welche sie entweder via File-Objekt im Konstruktor oder Dateipfad einliest.

In dieser Konfigurationsdatei befinden sich allerdings sensible Daten. Meine Idee war daher die Datei zu verschlüsseln und bei der Initialisierung des Servlets zu entschlüsseln. Statt die verschlüsselte Datei dann ins lokale Dateisystem zu schreiben, was das gesamte Sicherheitskonzept über den Haufen wirft, möchte ich diese stattdessen in eine virtuelle Datei schreiben.

Diese Datei existiert nur im Arbeitsspeicher.

Ich weiß aber nicht, ob sowas möglich ist und ob die in der Anwendung sicherlich irgendwo vorkommenden Reader so etwas akzeptieren.

Btw: Die einzubettende Anwendung darf bei alledem nicht modifiziert werden. Diese greift intern aber via FileInputStream auf die Datei zu.

Hat jemand eine Idee, wie man so etwas umsetzen könnte?

Danke!

Grüße

 

[Marcinek]

Hallo,

mir erschließt sich der Sinn dieses vorgehens nicht so ganz.

Du möchtest verschlüsselte Daten innerhalb einer Instanz deines Programs haben.

Wieso nimmst du dafür nicht einfach ein X Belibiges Objekt? - Diese existieren immer nur im Arbeitsspeicher.

Warum kann man auf diese Daten nur mit einem Input Stream zugreifen? - Eventuell musst du für diese Zwecke dann deinen eigenen InputReader schreiben.

Gruß,

Martin

 

[Sekundentakt]

Hi Martin,

guten Morgen erst mal !

Wieso nimmst du dafür nicht einfach ein X Belibiges Objekt?

Ich darf an der Applikation nicht schrauben. Diese ist so wie sie ist fertig.
Das letzte, wenn alles versagt, was gemacht werden würde, wäre an dieser Anwendung herumzuschrauben. So lange da nicht alle Möglichkeiten ausgeschöpft sind, versuche ich das Ganze noch über Tricks etc. zu umgehen.

Beste Grüße

 

[FArt]

Ich verstehe dein Vorgehen auch nicht. Sieht aus wie vorgetäuschte Sicherheit: unnötig kompliziert ohne Mehrwert.

Zum eigentlichen Anliegen: du kannst beliebige Daten in ein byte[] serialisieren und auch mit Streams darauf zugreifen.

 

[Sekundentakt]

Sieht aus wie vorgetäuschte Sicherheit: unnötig kompliziert ohne Mehrwert.

Klingt als hätten die Entwickler der ursprünglichen Software bereits einiges unbedacht gelassen...

Ich sag mal so: Wenn die Datei im Arbeitsspeicher entschlüsselt vorliegt, reicht das. Spätestens dann, wenn der Angreifer nämlich auf diesen zugreifen könnte, liegt das was ich schützen möchte, schon längst auf dem silbernen Tablett - auch ohne die Software an der ich gerade schreibe. Das ist aber nicht mein Problem oder meine Aufgabe. Dann wurden an anderer Stelle schon Fehler gemacht.

Hier geht es wirklich nur darum, dass ggf. ein Systemadministrator oder ein neugieriger Mitarbeiter mit Zugriff auf den entsprechenden Ordner, nicht einfach auf die Datei klicken können soll und dann Passwörter zu Bereichen ausspähen kann, die ihn nichts angehen.
Das ist keine 100%ige Sicherheit, wenn man es drauf anlegt kommt man auch so dahinter, was sich in den Dateien verbirgt.
Aber so ist die Hürde zumindest schon mal so gesetzt worden, dass es sich um böswillige Absicht und nicht nur einen dummen Zufall handeln kann.
Das reicht hier tatsächlich aus.

Soweit wie ich das sehe, gibt es also keine Möglichkeit eine Datei in den Arbeitsspeicher zu schreiben und anschließend über einen Pseudo-Dateipfad zugänglich zu machen?

Gruß

 

[Marcinek]

Doch man kann sowas machen

Verschlüsselte Datei > InputReader, der die Datei entschlüsselt.

Fertig

 

[tuxedo]

Aber:

welche sie entweder via File-Objekt im Konstruktor oder Dateipfad einliest.

Glaub nicht dass das so einfach geht. Denn die Implementierung wird dann sicher den Inputstream zu dieser File öffnen. Das File-Objekt gibt ja nur bekannt, wo die File zu finden ist (Pfad auf der Platte).

Einen Pfad im Arbeitsspeicher kennt weder das Fileobjekt, noch der bereits in der Implementierung deiner Anwednung verwendete Inputstream ...

- Alex

 

[Marcinek]

new EncryptedFileInputReader (new File());

Das wird er schon iwo hinschreiben müssen, sonst wird es nicht klappen.

Natürlich muss er den EncryptedFileInputReader implementieren

Also einen Umweg über viruelle Dateien muss man da nicht machen.

 

[tuxedo]

Wenn aber die einzige Schnittstelle zur Anwendung - welche das File benötigt - ein Fileobjekt oder ein Dateipfad ist, und er die Anwendung nicht modifizieren kann/darf/soll, dann ist hier das Ende der Fahnenstange erreicht ... :-(

 

[Sekundentakt]

Danke für euer Feedback!

Dann sind solche Extra-Wünsche einfach nicht umsetzbar, jedenfalls nicht beim geplanten Aufwand.

Wenn es aber nur am InputStreamReader legen sollte, ist der Zusatz-Aufwand vielleicht doch nicht so groß, da hier lediglich eine Klasse implementiert und eine Code-Zeile in einer Client-Klasse modifiziert werden müssen. Ich denke, dass das auch bei kommenden Updates der Applikation leicht zu berücksichtigen bleibt.

Beste Grüße