Hej,
Mam małą apkę firmową, do której użytkownicy logują się przy pomocy poświadczeń domenowych. I to jest OK, apka ma działać w obrębie firmowej sieci w tym VPNa.
Jednak korzysta ona z bazy MSSQL i póki co, dosyć prymitywnie trzymam hasło do bazy w Settingsach.
Ktoś mógłby mnie naprowadzić, czego mam szukać, aby móc bardziej zabezpieczyć/utrudnić dostęp do danych logowania do bazy?
Nie myślałeś żeby schowac bazę za jakimś api?
@kzkzg: Też mi przeszła taka myśl przez głowę, ale nie wiem, czy nie byłby to przerost formy - chciałbym się w razie czego zabezpieczyć, gdy przyjdzie jakiś hobbysta-programista na praktyki (firma nie pracuje w branży IT).
Nie myślałeś żeby schowac bazę za jakimś api?
Wydaje mi się, że to jest przysłowiowa armata na komara, skoro to tylko działa w obrębie sieci formowej, nie jest wystawione na świat.
trzymam hasło do bazy w Settingsach
[...]
chciałbym się w razie czego zabezpieczyć, gdy przyjdzie jakiś hobbysta-programista na praktyk
Czy chodzi o to, że jak wejdziesz w ustawienia aplikacji to masz to hasło podane plain-textem, czy raczej obawiasz się, że ktoś będzie sobie grzebać i odczyta to z jakiegoś pliku z ustawieniami?
Jeśli pierwsze - po prostu go nie pokazuj, jedynie pozwól wpisać nowe (ale i tak go nie pokazuj, tylko zamaskuj gwiazdkami).
A co do drugiej opcji - po prostu jakkolwiek zaszyfruj przed zapisem. Raczej wybitni hackerzy tam nie będą, więc jakiekolwiek szyfrowanie da radę i zapis w pliku konfiguracyjnym w stylu password = sdjhf098wh2038hjsdhfjksa rozwiąże temat. Nikt nie będzie Ci raczej robił reverse engineering aplikacji, żeby rozgryźć mechanizm szyfrowania hasła ;)
Nikt nie będzie Ci raczej robił reverse engineering aplikacji, żeby rozgryźć mechanizm szyfrowania hasła ;)
W ten sposób dobierałem się do aplikacji aby dobić się do bazy :D Trzymali hasło w plikach ini :D Akurat dostęp był potrzebny po to aby dowiedzieć się gdzie pewne rzeczy są trzymane aby je wyciągnąć z pominięciem GUI (beznajdziejne...), jednak gdybym chciał, to bym mógł coś uszkodzić.
Baza była trzymana na innym serwerze. Tak więc jak dla mnie takie api to niekoniecznie armata na komara, bo nigdy nie wiesz kogo masz w firmie ;) Zawsze się może trafić pracownik, który nie jest zadowolony z tego ile zarabia, jak jest traktowany ;)
A jeszcze teraz kiedy dochodzi RODO i te wszystkie kwestie z przetwarzaniem danych osobowych, to lepiej dmuchać na zimne, niż suszyć zmoczone gatki. :)
.andy napisał(a):
Nikt nie będzie Ci raczej robił reverse engineering aplikacji, żeby rozgryźć mechanizm szyfrowania hasła ;)
W ten sposób dobierałem się do aplikacji aby dobić się do bazy :D Trzymali hasło w plikach ini :D Akurat dostęp był potrzebny po to aby dowiedzieć się gdzie pewne rzeczy są trzymane aby je wyciągnąć z pominięciem GUI (beznajdziejne...), jednak gdybym chciał, to bym mógł coś uszkodzić.
Baza była trzymana na innym serwerze. Tak więc jak dla mnie takie api to niekoniecznie armata na komara, bo nigdy nie wiesz kogo masz w firmie ;) Zawsze się może trafić pracownik, który nie jest zadowolony z tego ile zarabia, jak jest traktowany ;)
A jeszcze teraz kiedy dochodzi RODO i te wszystkie kwestie z przetwarzaniem danych osobowych, to lepiej dmuchać na zimne, niż suszyć zmoczone gatki. :)
Ale jak zaszyfruje jakimś algorytmem i będzie trzymać w ini to nie rozumiem, jaki jest problem z tym? Też uważam, że robienie api dla samego schowania hasła, a nie np dla poprawy wydajności w komunikacji, jest zbędne. Spotkałem się z takim rozwiązaniem, że użytkownicy logowali się do bazy domeną i nie było potrzeby ukrywania haseł.
Zaraz, chwila - przecież korzystasz z poświadczeń domenowych.
To dlaczego nie logujesz się do bazy na podstawie tych właśnie poświadczeń?
MS SQL Windows Authentication
Poza tym, jest jeszcze coś takiego jak Application Roles, aczkolwiek tam trzeba podać hasło - ale nie jest to hasło użytkownika a roli aplikacyjnej.
Innymi słowy - znając to hasło nie da się zalogować do bazy danych. To możliwe, ale nie takie oczywiste i potrzebne będzie jeszcze hasło usera ;-)
@wloochacz: Pracownik podaje login i hasło do swojego konta, a ja następnie przy pomocy PrincipalContext sprawdzam, czy dane się zgadzają.
Następnie taki użytkownik ma dostęp do zasobów bazy. Ze względu na to, że wszyscy muszą mieć dostęp i operować na konkretnych danych w bazie postawiłem na jedno konto użytkownika DB (oprócz admina oczywiście).
GrzesiekP napisał(a):
@wloochacz: Pracownik podaje login i hasło do swojego konta,
Po co?
Przecież jak user zalogował się do domeny zanim uruchomi aplikację, to jest już zalogowany na własne konto.
a ja następnie przy pomocy PrincipalContext sprawdzam, czy dane się zgadzają.
Ale tu nie logujesz się de-facto do bazy danych, a do domeny i z domeny sprawdzasz te dane, tak?
Ty po prostu ponownie sprawdzasz, czy ten zalogowany ma odpowiednie poświadczanie w AD.
Hmm... Dziwne i niepotrzebne moim zdaniem.
Następnie taki użytkownik ma dostęp do zasobów bazy. Ze względu na to, że wszyscy muszą mieć dostęp i operować na konkretnych danych w bazie postawiłem na jedno konto użytkownika DB (oprócz admina oczywiście).
Ale wiesz, że ten user w bazie na poziomie bazy danych (chodzi mi o login w MS SQL, nie w domenie) nie jest do niczego potrzebny?
Poczytaj o o Windows Authentication w kontekście MSSQL, ponieważ IMHO poplątałeś tu co nieco.
A sprowadza się to jednej (JEDNEJ!) zmiany w ConnectionString i wszystko działa - w aplikacji nie prosisz o usera i haslo, bo user jest już zalogowany do domeny i to wystarcza.
Oczywiście możesz sobie dodatkowo sprawdzać usera i hasło na poziomie aplikacji, ale to będą tylko uprawnienia do Twojej aplikacji.
Znając takie dane nie da się zalogować nigdzie (na pewno nie do bazy danych np. z poziomu Management Studio), ale da się zalogować do Twojej aplikacji pod warunkiem, że najpierw ktoś się poprawnie zalogował do domeny. To uprawnienia domeny uprawniają danego usera do zalogowania do bazy danych i działa to transparentnie.
Uprawniania do bazy danych (tabel, widoków, itd.) musisz oczywiście dodać na poziome użytkowników/grup domenowych.
Ale tu (czyli w uprawnieniach AD, bazy danych, itd.) już w szczegółach nie pomogę, nie zajmowałem się już tym bardzo dawno.
Po co?
Przecież jak user zalogował się do domeny zanim uruchomi aplikację, to jest już zalogowany na własne konto.
(...)
Ale tu nie logujesz się de-facto do bazy danych, a do domeny i z domeny sprawdzasz te dane, tak?
Ty po prostu ponownie sprawdzasz, czy ten zalogowany ma odpowiednie poświadczanie w AD.
Hmm... Dziwne i niepotrzebne moim zdaniem.
Zgadza się.
U nas występuje czasem duża rotacja sprzętu i krzeseł w trakcie pracy;) więc chciałem dać możliwość zalogowania się do apki bez potrzeby wylogowywania obecnego użytkownika.
GrzesiekP napisał(a):
chciałem dać możliwość zalogowania się do apki bez potrzeby wylogowywania obecnego użytkownika.
takie coś już jest w systemie. Wejdź w edytor zasad grupy (gpedit.msc) i włącz to:
teraz każdy może uruchomić aplikację jako inny użytkownik
Ewentualnie możesz hasło bazy wrzucić w Windows Credential Menager i później odpytać o hasło dla konkretnego zdefiniowanego pola.
