Czy appsettings.json jest bezpieczne?

Witam.
Microsoft, w dokumentacji, sugeruje, że można wpisywać connectionStringi do appsettings.json. Nawet widziałem jakiś jeden tutorial, że ktoś wpisywał secret do JWT w appsettings. Mam wrażenie, że wpisywanie danych wrażliwych do pliku jest mało bezpieczne. Wiadomo, że jest bezpiecznie pod kątem próby pobrania pliku i dostęp do pliku będzie tylko możliwy jak ktoś będzie miał dostęp do maszyny hostującej w przypadku IIS, doker, czy innych systemów do ASP. Problem zaczyna się gdy .NET wszedł w świat WinForms, w którym jeszcze bardzo często piszę (wraz z DevExpressem). Tutaj też jest ten plik konfiguracyjny i Microsoft nawet zaleca przejść z AppConfig.xml na appsettings.json. Rozumiem, że jak to jest jakaś aplikacja serwerowa to robi to mniejszy problem, ale aplikacja dla użytkowników końcowych już mają pewno podatność, zwłaszcza jak Pani Basia otworzy plik faktura.zip.

Co w takim pliku chce trzymać:

1. ConnectionString
2. Access Token - to jakiś serwisów zewnętrznych
3. Konfiguracja poczty
4. Konfiguracja samej aplikacji - dane kompletnie niewrażliwe

Do lokalnej pracy zazwyczaj używam user secrets i wtedy wpisujesz sobie w pliku co tam chcesz, a na produkcji możesz użyć azure key vault.

No ale ja nie chce za to płacić. Czy wtedy jedynym rozwiązaniem jest trzymać connectionString w appsettings, a resztę ustawień w bazie?

Dlaczego miałbyś trzymać nazwę użytkownika i hasło do bazy w connection stringu? Są metody uwierzytelniania które tego nie wymagają kwestia właściwej architektury rozwiązania. Masz też do dyspozycji zmienne środowiskowe - tak działa Azure AppService, jak w konfiguracji AppService podasz jakąś informację to nie trafia ona do appsettings.json tylko właśnie trzymana jest jako env variable. To samo możesz zrobić on-premises. W ostateczności zostaje ci trzymanie konfiguracji w bazie danych.

Czemu wszyscy piszą o Azure. Nie używam Azure i nie mogę użyć Azure, ponieważ większość moim aplikacji webowych, czy winforms są pod jakiś system ERP. Muszę mieć "lokalnie" dostęp do tej bazy. Płacenie Microsoftowi parę dolców tylko po to żeby trzymać tam konfigurację do swoich aplikacji jest lekko bezsensu. Jak ściągnę konfigurację jak klienta serwer będzie offline?

Umiesz czytać? W którym miejscu napisałem ci że masz użyć Azure? Napisałem tylko JAKO PRZYKŁAD że w oparciu o zmienne środowiskowe działa konfiguracja Azure AppService i że możesz sobie to zrobić w ten sposób też on-premises. Nie mówiąc że podałem ci inne możliwości które nie wymagają chmury.

Aplikacja desktopowa WinForms ma bezpośredni dostęp do bazy?

Panie drogi - zmienne środowiskowe biorą precedens nad tym, co jest w appsettings.json, więc jeśli będziesz miał na swoim środowisku zmienną z takim kluczem, a inna wartością to przy uruchomieniu, to co masz w jsonie w rozwiązaniu zostanie nadpisane.

Nie, appsettings.json nie jest bezpieczne.

W przypadku aplikacji desktopowej można pójść w DPAPI:

https://learn.microsoft.com/en-us/dotnet/standard/security/how-to-use-data-protection
https://learn.microsoft.com/en-us/windows/win32/secbp/threat-mitigation-techniques

Problem jest taki, że to będzie się dało odczytać dla wszystkich aplikacji działających w danej sesji użytkownika, więc złośliwy program byłby w stanie odczytać twoje dane i tak.

Zależnie od poziomu paranoi myślę, że zaszyte hasło w kodzie aplikacji i jakieś szyfrowanie danych trzymanych w appsettings.json by wystarczyło, chyba, że zakładasz, że ktoś się będzie bawił w dekompilację twojej aplikacji, aby je odnaleźć.

Nie jest bezpieczne tak samo jak AppConfig.xml czy jakikolwiek inny sposób trzymania connection stringa po stronie klienta. Nawet jeśli to zaszyfrujesz to skoro aplikacja jest w stanie to zrobić to tak samo ty możesz się bezpośrednio połączyć z bazą. Szyfrowanie i ukrywanie hasła do bazy to tylko iluzja bezpieczeństwa choć w połączeniu z zakazem instalowania zewnętrznego oprogramowania na komputerach i ograniczonego dostępu może być wystarczające

Tu jest chyba jakiś problem ze zrozumieniem architektury tego rozwiązania. Skoro piszesz aplikacje desktopową, to logiczne jest, że jeśli Twoja aplikacja ma się łączyć bezpośrednio do bazy danych, to MUSISZ dostarczyć na maszynę usera jakiś klucz. Czy to będzie login+hasło, czy token do jakiegoś vaulta + zabezpieczenie po IP, czy jeszcze inny certyfikat to bez znaczenia, bo musisz dostarczyć COŚ, co daje bezpośrednio dostęp do bazy danych z tego komputera.
Dlatego z reguły tworzy się webowe API do którego komunikuje się aplikacja i wymaga się od użytkownika uwierzytelnienia swojej osoby w tym API. Tylko to porządnie rozwiązuje problem dostępu do bazy. Wszystko inne to prowizorka, na którą szkoda czasu.
Jeśli mówimy o bezpieczeństwie aplikacji webowej na środowisku produkcyjnym, to czy zapiszemy secrety do pliku czy zmiennych środowiskowych czy w zewnętrzym vaulcie z odpowiednim kluczem do niego to bez znaczenia. Każdy kto zaloguje się odpowiednim kontem na maszynę/kontener/cokolwiek, automatycznie ma dostęp do secretów. Różnica jest tylko w wyogodzie dostarczania konfiguracji.

A może użycie loginu i hasła logowania do aplikacji desktopowej jako jakiegoś klucza odszyfrujacego dane do bazy?
Luźny pomysł.

LagMan napisał(a):

Dlatego z reguły tworzy się webowe API do którego komunikuje się aplikacja i wymaga się od użytkownika uwierzytelnienia swojej osoby w tym API. Tylko to porządnie rozwiązuje problem dostępu do bazy. Wszystko inne to prowizorka, na którą szkoda czasu.

Ale że co? Tworzy się webowe api do lokalnej bazy? Piłeś coś dziś?

To jest temat rzeka. MS też coś o tym pisze: https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/connection-strings-and-configuration-files#encrypting-configuration-file-sections-using-protected-configuration

Ja kiedyś robiłem różne cuda na kiju, żeby usera i hasło kodować w rejestrze. Działało. Było bezpieczne? Tak. Dopóki nie spotka się wytrwałego hackera. Pytanie jakie dane chcesz ukryć. W sensie, czy w tej bazie jest coś znaczącego, czy nie bardzo. Każdy system da się shackować. Pytanie "czy warto tracić na ten system czas".

No i działanie przez apkę na koncie sa jest bardzo poronionym pomysłem. Do tego konta powinien mieć dostęp tylko administrator, ewentualnie programista. Natomiast aplikacja powinna mieć swojego użytkownika z odpowiednimi uprawnieniami.