Sytuacja wygląda tak:
- jest aplikacja w Javie, która korzysta z gołego"JDBC i zaczytuje hasła z pliku konfiguracyjnego, w którym wszystko jest otwartym tekstem, a następnie buduje z tego "connection stringa" (autorzy przyznają, że "logika nawiązywania połączenia jest dość mocno rozsmarowana w kodzie źródłowym", czyt. "wielka qpa")
- brak realnych możliwości ingerowania w aplikację ("zmienimy, ale zajmie to dużo czasu i na pewno nie będzie w tym roku, bo dbamy o jakość produktu i potrzebujemy czasu na testy" :P)
- OS: Linux
- klient nie chce haseł otwartym tekstem
Cel:
- przechowywanie hasła w formie, która nie jest otwartym tekstem
Jakieś pomysły jak wprowadzić warstwę bezpieczeństwa, która uniemożliwi odczyt pliku osobom postronnym / wprowadzi przezroczyste deszyfrowanie?
Szukam jakiegoś rozwiązania dla leniwych, najlepiej istniejącego pudełka, a nie pisanie własnego wrappera.
Jak do tej pory rozważam:
-
chmod 600 plik_z_hasłami
- proste zabezpieczenie, ale zbyt proste - SE Linux i ograniczenie open() per konkretny użytkownik i konkretny proces użytkownika
- wprowadzenie jakiegoś wrappera na system calle (LD_PRELOAD) i tam szyfrowanie/deszyfrowanie w locie (minus - zmieni się coś w strukturze konfiguracji -> wrapper leży)
Może ktoś słyszał o jakimś wrapperze na sterownik JDBC ? np. ładujemy oryginalny sterownik do osobnego class loadera, a podmieniamy "gotowiec", któremu hasła można by podawać z innego źródła?