Przechowywanie danych wrażliwych w ASP.NET Core

W procesie implementacji systemu informatycznego zwykle przychodzi moment, gdzie w naszym kodzie zaczynają pojawiać się informacje niezbędne np. do połączenia z bazą danych lub integracją z zewnętrznymi dostawcami wszelakich usług jak np. mailing. Strategi radzenia sobie z tą niedogodnością jest kilka. Możemy temat uznać za mało ważny, który po prostu olejemy. Nie jest to dobrym pomysłem chociażby z tego względu, że w dzisiejszych czasach reverse engineering jest wszechobecny i dla wprawionych osób dekompilowanie kodu, który zawiera dane wrażliwe to nic specjalnego. Kolejną opcją jest trzymanie wszystkich danych w jednym miejscu np. pliku konfiguracyjnym. Owszem, nasze dane nie są wtedy trzymane jawnie w kodzie, ale mimo wszystko jest gdzieś plik, który przechowuje ich jawne definicje. Na szczęście nowa odsłona ASP.NET wychodzi programistom na przeciw, udostępniając narzędzie pozwalające na łatwe i przyjemne zarządzanie danymi wrażliwymi.

Narzędzie Secret Manager – bo o nim mowa – jest domyślnie zainstalowany w nowych projektach ASP.NET Core. Jeżeli jednak zechcecie zacząć od pustej solucji wtedy niezbędna będzie instalacja ręczna. Poniżej najszybszy sposób, czyli konsola:

 

dnu commands install Microsoft.Extensions.SecretManager

 

Jeżeli wszystko poszło po naszej myśli po wpisaniu user-secret -h powinniśmy ujrzeć spis dostępnych opcji:

 

help

 

Jak widać dostępne możliwości to:

  • Usunięcie wszystkich sekretów w ramach aplikacji.
  • Listowanie wszystkich sekretów.
  • Usunięcie konkretnego sekretu.
  • Dodanie nowego sekretu.

 

Za chwilę przejdziemy do testowania powyższych opcji. Wcześniej jednak musimy dokończyć konfigurację narzędzia. Aby wszystko działo poprawnie w pliku project.json należy zdefiniować userSecretsId. I znów, w przypadku gotowych szablonów aplikacji ASP.NET Core nie musimy się tym martwić, ponieważ jest to automatycznie generowane. W przeciwnym przypadku jesteśmy zobowiązani dodać to ręcznie. Przykład wygenerowany wygląda następująco:

 


"userSecretsId": "aspnet5-Secret-fc6951aa-6514-4c0d-9b68-452c7961740b"

 

Dodam, iż Id musi być unikatowe, ponieważ w przeciwnym przypadku Secret Manager nie byłby w stanie jednoznacznie określić źródła, z którego mają zostać pobrane dane. Dodajmy zatem kilka sekretów. Są one przetrzymywane jako para klucz-wartość:

 

secrets_add

 

Wszystko działa bez zarzutu jednak póki co posiadamy jedynie „magiczne pudełko”, do którego zapisujemy wrażliwe dane. Jak zatem korzystać z nich w kodzie aplikacji? W tym celu musimy pobrać drugą paczkę:

 


dnu install Microsoft.Extensions.Configuration.UserSecrets

 

Po kilku chwilach pobierania możemy przejść do klasy Startup.cs, gdzie w konstruktorze powinniśmy dodać następującą linię kodu:

 


builder.AddUserSecrets();

 

Od teraz w klasie Startup możemy pobierać nasze dane za pośrednictwem właściwości Configuration. Przykładowo:

 


var sqlServerPassword = Configuration["SQLServerPassword"];

 

Sprawdźmy tylko, czy wszystko działa. W tym celu uruchomimy sobie QuickWatch-a:

 

qw

 

Tu rodzi się kolejne pytanie. W jaki sposób i gdzie przechowywane są nasze dane? Odpowiedź znajduje się na stronie ASP.NET gdzie dowiadujemy się, że jest to zwykły JSON, który znajduje się pod ścieżką:


%APPDATA%\microsoft\UserSecrets\<userSecretsId>\secrets.json

 

Warto wspomnieć także, że pomimo fizycznej możliwości, odradzane jest odwoływanie się bezpośrednio do pliku, ponieważ aktualna wersja Secret Managera, może ulec zmianie. Jak pisze zespół developerski:

 

You should not write code that depends on the location or format of the data saved with the secret manager tool, as these implementation details might change. For example, the secret values are currently not encrypted today, but could be someday.

 

Na dziś to wszystko. Mam nadzieję, że Wasze sekrety zachowacie tylko dla siebie 😉 Jak zwykle zachęcam Was do śledzenia mnie na twitterze oraz facebooku 🙂

Na razie !

 

 

You may also like...