Cześć, jak powinna wyglądać architektura aplikacji typu antywirus lub coś podobnego na system Windows?
Wymagania to logowanie użytkownika do aplikacji i zarządzanie swoimi ustawieniami sieci, systemem, aplikacjami. Czy coś takiego ma sens: aplikacja WebApi jako usługa windowsowa na uprawnieniach użytkownika LocalSystem, klient api jako WPF albo cokolwiek może być nawet MVC/Blazor/Razor jako UI, logowanie za pomocą JWT, szyfrowana baza danych żeby przetrzymywać użytkowników. Jak poradzić sobie z przetrzymywaniem wrażliwych danych jak np. hasło do certyfikatu żeby komunikacja była po https, albo token użytkownika? Zdaję sobie sprawę, że taka aplikacja desktopowa zawsze będzie do złamania, ale jak profesjonalnie do tego podejść żeby mieć pewność, że jest maksymalnie zabezpieczona?
Jeśli chcesz pisać desktop to zapomnij o webie. Wzorce, które opisujesz nijak do tego środowiska nie pasują.
Wszystko co jest na komputerze użytkownika jest jego własnością. Żadne pokraczne szyfrowania tego nie zmienią. W ogóle co tam zabezpieczać? Na desktop to można co najwyżej zabezpieczać dllki przed dekompilacja.
Nie za bardzo rozumiem co chcesz osiągnąć. Trochę mieszasz. Piszesz o aplikacji desktopowej (a przykładach podajesz webówkę), piszesz o usłudze Windowsowej, a w przykładzie podajesz WebApi. Jaki problem chcesz rozwiązać? Co chcesz osiągnąć?
Nie jestem pewien ale Op chce chyba napisać aplikacje webową działającą lokalnie do użytku jako desktopową. I jeszcze chce to pozabezpieczać. Tylko przed kim, jak cały ruch będzie lokalnie?
Żeby user-admin czegoś nie pozmieniał? Żeby nie wbił się do bazy do która jest u niego lokalnie na dysku? Jaki to ma mieć sens?
@KamilAdam @Juhas Już tłumaczę o co mi chodzi. Administrator lokalny przy pomocy aplikacji, ale też z poziomu serwisu zewnętrznego (ma konto w tym serwisie np. [email protected] i w aplikacji musi pozostać zalogowany) może zmieniać ustawienia tak jak wspomniałem sieci, np. ustawić proxy albo automatyczne wyłączanie Internetu od zadanej godziny, ale te ustawienia będą dotyczyć lokalnych użytkowników bez praw administratora.
Chciałbym żeby jakiś cwany użytkownik bez praw admina nie dobrał się do aplikacji, nie mógł jej zabić, nie mógł zmienić wprowadzonych ustawień etc. Ten użytkownik natomiast może podejrzeć aktualne ustawienia.
Krótko mówiąc apka to klient, który pobiera informacje z zewnątrz (dotyczące Internetu) i np. ucina Internet, ale tylko użytkownikom bez praw admina
A jak utnie internet to jak pobierze dane o jego przywróceniu? Jak admin zmieni ustawienia sieci to jak klient nawiąze połączenie z serwerem?
Masz tutaj wiele problemów do rozwiązania.
Przede wszystkim widzę, że chcesz mieć IdentityServer. Tutaj nie ma co zabezpieczać. Po prostu podczas uruchamiania aplikacji, użytkownik wpisuje login i hasło. To przechodzi do IdentityServer, który zwraca info, czy zalogowano, czy nie. Komunikacja po HTTPS w zupełności wystarczy.
Co do ustawień trzymanych gdzieś w jakiejś bazie... No mogą pojawić się problemy, o których pisze @gswidwa1
@gswidwa1 @Juhas Co do ustawień Internetu czy sieci to nie chodziło mi może o wszystkie możliwe ustawienia. "Odcinanie Internetu" realizuję przez systemowe proxy, gdzie do wyjątku dodaję domenę mojego serwisu, a resztę zapytań przekierowuję do proxy, która je odbija. W tych przypadkach wiem jak podejść do problemu, raczej w kwestiach bezpieczeństwa mam dylematy jak to zaplanować i przetrzymywać ustawienia aplikacji, gdzie trzymać hasło do szyfrowania bazy, gdzie trzymać certyfikaty do lokalnej komunikacji po https, klucze etc.
No to tak jak piszę. Niech po prostu user się loguje przy każdym uruchomieniu aplikacji i wtedy posługujesz się jedynie BearerTokenem. Nie trzymasz żadnych danych. Jeśli jednak z jakiegoś powodu musisz gdzieś przechować dane logowania, to Windows ma taki mechanizm: ProtectedData
Ja zrobiłem sobie taką prostą klasę z interfejsem:
class WindowsProtectionService : IProtectionService
{
public byte[] CreateKey()
{
return Encoding.UTF8.GetBytes(Randomizer.RandomString(16));
}
public byte[] Protect(byte[] data, byte[] key)
{
return ProtectedData.Protect(data, key, DataProtectionScope.CurrentUser);
}
public byte[] Unprotect(byte[] protectedData, byte[] key)
{
return ProtectedData.Unprotect(protectedData, key, DataProtectionScope.CurrentUser);
}
}
Następnie zwrotkę z Protect możesz zapisać gdzieś w rejestrze, czy w innym miejscu. Nie mówię, że jest to 100% bezpieczne, bo na pewno nie jest. Pytanie tylko, czy opłaca się to hackować.
Co do certyfikatów, to nie za bardzo rozumiem. Po prostu instalujesz je na kompie i tyle. Zresztą komunikacja https jest w standardzie. Ważne, żeby serwer to obsłużył np. za pomocą darmowego certyfikatu "Let's Encrypt". Bazę też chyba trzymasz na serwerze? Przynajmniej tak wynika z tego, co opisałeś.
@Juhas: Bazę też trzymam na serwerze, ale przy scenariuszu, że loguje się lokalnie zwykły użytkownik i akurat nie ma Internetu to i tak np. powinien zostać wylogowany o 18 albo mieć zablokowaną aplikację Chrome więc lokalnie też muszę trzymać te informacje, potem się zsynchronizują. No i lokalnie też muszę zabezpieczyć komunikację przez HTTPS, bo jeśli zwykły użytkownik poprosi admina o zmianę jakichś ustawień (np. tylko lokalnie bez zaciągania informacji z zewnątrz bo są offline) i admin przełączy się na swoje konto, to zwykły użytkownik nie powinien móc sobie podsłuchać czystego HTTP, ale to pewnie wiesz. I tutaj odpada Let's encrypt. Komunikacja z zewnętrznym serwisem oczywiście po HTTPS.
No i admin nie musi uczestniczyć w każdym uruchomieniu aplikacji więc jego token też muszę gdzieś trzymać
jarzi napisał(a):
No i admin nie musi uczestniczyć w każdym uruchomieniu aplikacji więc jego token też muszę gdzieś trzymać
W żadnym wypadku. Jeśli przychodzi nowy user, to musi zalogować się swoimi danymi.