Witajcie, pisze aplikacje (Spring Boot) ktora docelowo bedzie smigala na Amazonie - Elastic Beans,
w niej mam plik application.properties (ten defaultowy generowany wraz z projektem przez initializr),
w tym pliku mam haslo do bazy danych i wiadomo reszte roznych configow.
Pytanie, czy takie rozwiazanie jest bezpieczne?
Czy jest jakas mozliwosc ze ktorys z uzytkownikow apki dobierze sie do tych poufnych danych?
"Czy jest jakas mozliwosc ze ktorys z uzytkownikow apki dobierze sie do tych poufnych danych?" - jeśli jedynie w propertiesach umieszczasz te dane oraz manualnie z nich nie korzystasz w aplikacji, to przecież użytkownik nie będzie miał do nich dostępu przez aplikację.
System jest bezpieczny na tyle, na ile bezpieczne jest jego najsłabsze ogniwo, często nie ma sensu brnięcie w security through obscurity w miejscach gdzie nie jest to konieczne.
Jeśli ktoś dostanie się do środka maszyny fizycznej, to naturalnie będzie miał dostęp do tych danych.
Istnieją rozwiązania, które umożliwiają szyfrowanie propertiesów (np. Jasypt dla aplikacji javowych), ale w dalszym ciągu trzeba skonfigurować użycie klucza szyfrującego, który gdzieś się musi znajdować.
To zależy. Jak np publicznie masz tam wystawiony /actuator z którego można czytać properties to niekoniecznie (chociaż spring akurat gwiazdkuje hasła :P). Ale w normalnej sytuacji nie da się do tego pliku dostać bez jakiejś podatności bezpieczeństwa.
Inna dyskusja, ale gdzie trzymasz hasła do proda? W gicie?
Krótko – nie. Ten plik nie powinien zawierać haseł. Ma on dziwną właściwość przeciekania do przestrzeni publicznej.
Poprawne rozwiązanie to wykorzystanie mechanizmu zmiennych środowiskowych zarządzanych z poziomu chmury. Wtedy hasła są przekazywane do instancji z zewnątrz. W pliku będziesz miał coś w rodzaju
spring.datasource.url = ${OPENSHIFT_MYSQL_DB_HOST}:${OPENSHIFT_MYSQL_DB_PORT}/"nameofDB"
spring.datasource.username = ${OPENSHIFT_MYSQL_DB_USERNAME}
spring.datasource.password = ${OPENSHIFT_MYSQL_DB_PASSWORD}
i tyle
Rozwiązanie ze zmiennymi działa, jednak cały czas zostaje problem Actuatora gdzie możesz swoje hasła udostępnić przez /env endpoint-a. Problem, jest taki, że endpointy/configi zmieniają się czasami razem z wersjami Springa i można sobie narobić problemów. Jeżeli, chcesz używać zmiennych to upewnij się, że /env (Jakkolwiek by się nie nazywał) jest zablokowany(domyślne). Upewnij się też, że config keys-to-sanitize jest dobrze ustawiony (https://stackoverflow.com/questions/28300232/spring-boot-actuator-hides-property-values-in-env-endpoint).
Alternatywą w AWS jest np IAM role do Secret Manager i konkretnego secreta i wyciągać hasła stamtąd. Możesz, też użyć jakiegoś Spring Cloud Config (Tylko bez refresha :) ), jednak wtedy możesz spotkać się z takim samym problemem jak wyżej. (W zależności od implementacji, i źródła secretow).
Jeżeli, chcesz używać zmiennych to upewnij się, że /env (Jakkolwiek by się nie nazywał) jest zablokowany
Ja bym jednak zrobił to sensowniej i postawił /actuator na innym porcie, który w ogóle nie jest publicznie widziany za load balancerem czy reverse proxy, czyli ustawić odpowiednio springowe management.server.port. Wtedy możemy sobie wystawić actuatorem co nam potrzebne.
Dla mnie endpointy, z których można wyciągnąć jakiekolwiek secrety powinny być zablokowane. Regresja może się zdarzyć na poziomie Springa(Zmiana configu itd.), ale może zdarzyć się też na poziomie LB/RP. Połączenie tych 2 rozwiązań wydaje się optymalne.
Masz hasła w pliku priperties, który leży w jakimś artefakcie, który lezy na jakimś serwerze artefaktów, każdy kto ma dostęp do tego serwera i zip'a ma dostęp do produkcyjnej bazy danych. Na AWS musisz mieć jakieś dedykowane rozwiązanie do trzymania sekretów, albo umożliwiać np. połączenie do bazy danych bez użycia hasła, ale tylko z odpowiedniej usługi. Nie używałem nigdy tej chmury.
http trace (który może leakować tokeny i cookie) czy heapdump (który na dobrą sprawę leakuje wszystko). Nie mówiąc już o jakichś customowych endpointach które można tam dodać. Nie jestem pewien czy podejście zaorać actuatora to nie jest wylewanie dziecka z kąpielą.
Poczytaj o tym produkcie: https://www.vaultproject.io/