Cykl życia sekretu

Cykl życia sekretu

Opowiem Ci dzisiaj o sekretach w kodzie aplikacji. Przyjrzymy się temu, o czym należy pamiętać, gdy korzystamy z sekretów i o tym jak zadbać o cykl życia sekretu.

Zacznijmy od tego, czym w ogóle są sekrety w aplikacji?

Nazwa “sekret” jest bardzo intuicyjna. Sekrety, czyli to wszystko, co nie powinno być dostępne dla żadnych osób postronnych oraz dla użytkowników naszej aplikacji (z wyjątkiem danych ich konta w naszym systemie).

Na przykład:

  • hasła,
  • klucze do API różnych serwisów,
  • klucze SSH,
  • hasła,
  • certyfikaty.

Różne perspektywy na sekrety

Na sekrety możemy spojrzeć z różnych perspektyw.

Kto z nich korzysta?

  • użytkownik — ma swoje hasła,
  • system — tu mamy np. klucze do komunikacji API to API.

Kogo one dotyczą?

  • naszego systemu — kontrolują one dostęp do naszego systemu,
  • innego systemu — pozwalają nam skomunikować się z takim innym systemem.

Można by pomyśleć, że powinniśmy je traktować podobnie, ale na pierwszą kategorię mamy dużo więcej wpływu. W końcu jeżeli sami je tworzymy, to możemy wymusić więcej reguł.

Istotność sekretu

Pomyśl, co by było gdyby taki sekret został upubliczniony? Rozważmy kilka przypadków, jeśli ktoś miałby:

  • hasło użytkownika — zdobyłby dostęp do konta tego użytkownika,
  • hasło do Stripe — zdobyłby dostęp do danych finansowych naszych Klientów,
  • hasło do serwisu wysyłającego maile — może wysyłać złośliwe maile do Klientów w naszym imieniu,
  • klucz do naszego API — mógłby wykonywać nieautoryzowane operacje w naszym API.

Widzimy już, jak wielowymiarowy jest temat sekretów. Na potrzeby dalszych rozważań, przyjmijmy trzy główne kategorie:

  • hasła użytkownika,
  • sekrety systemowe do naszego systemu,
  • sekrety systemowe do innych systemów.

Cykl życia sekretu — analogia

Zacznijmy od przykładu — małej podróży w czasie.

Wyobraźmy sobie, że jesteśmy w średniowiecznym zamku. Chcemy zabezpieczyć skarbiec przed intruzami, więc stawiamy przed nim dwóch strażników i wymyślamy zasadę, że mogą wpuścić tylko ludzi, którzy znają hasło — klucz.

Co zrobić, żeby ta metoda była bezpieczna?

Każdy sekret powinien spełniać następujący cykl życia:

  • stworzenie — wymyślenie nieoczywistego hasła wejściowego – „żyrafy wchodzą do szafy”;
  • rotowanie — na wypadek, gdyby ktoś nas podsłuchał, raz na jakiś czas musimy zmienić hasło wejściowe;
  • zablokowanie — jak wymyślimy nowe hasło, to poprzednie powinno jak najszybciej przestać działać;
  • data ważności — ustalamy, jak długo jest ważne dane hasło. Dzięki temu nawet jak nie zablokujemy hasła, to nie pozostanie długo aktualne.

I dokładnie tak samo jest z naszym, współczesnym sekretem. To właśnie cykl życia sekretu.

Przejdziemy teraz przez wyróżnione wyżej trzy kategorie i odpowiemy na pytanie: jak zadbać o bezpieczny cykl życia tych sekretów?

Hasła użytkowników

Cykl życia sekretu dla haseł definiowanych przez użytkownika.

Krok 1 – stworzenie

Skoro użytkownik będzie się nim sam posługiwał, najlepiej żeby mógł je samodzielnie zdefiniować. Oczywiście przy pilnowaniu określonej złożoności.

Dodatkowo warto tu od początku wspierać MFA.

Krok 2 – rotowanie / zmiana

Użytkownik powinien być w stanie szybko zmienić swoje hasło w sytuacji, gdy odkryje, że jego obecne hasło jest skompromitowane (czyli ktoś poza nim je zna). Również warto wspierać odzyskanie konta w przypadku jego przejęcia.

Warto jednak pamiętać, że zmiana hasła powinna być zweryfikowana. Nie pozwólmy, żeby sama znajomość starego hasła pozwoliła na przejęcie konta.

Krok 3 – zablokowanie

Zakładając, że użytkownik przy zmianie sam poda swoje nowe hasło, poprzednie możemy natychmiast zablokować.

Krok 4 – data ważności

To dyskusyjna sprawa. Wiele standardów bezpieczeństwa nadal zaleca wymuszanie jego okresowej zmiany, jednak powoli to się zmienia. Dlaczego? Gdyż badania (https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf) wykazały, że wymuszanie zmiany haseł wcale nie sprzyja ich bezpieczeństwu. Wręcz przeciwnie — powoduje, że użytkownicy wymyślają schematyczne hasła.

Jednak jeśli tylko jako twórcy systemu odkryjemy, że baza haseł w naszym systemie wyciekła, powinniśmy jak najszybciej zablokować wszystkie hasła i wymusić ich zmianę.

Sekrety systemowe do naszego systemu

To brama wejściowa do naszego systemu, wiec sami musimy o nią jak najlepiej zadbać. Omówimy więc cykl życia sekretu dla tej kategorii.

Krok 1 – stworzenie

Sekret dostępowy do naszego systemu musi być bezpieczny, trudny do złamania.

Najlepiej, żeby miał odpowiednią długość i poziom skomplikowania. To będzie używane przez system, więc spokojnie możemy tu poszaleć i generować 64-znakowe sekrety. Nikt się nie obrazi, że musi tyle zapamiętać.

Co więcej, mechanizm generowania powinien być bezpieczny kryptograficznie. Generowanie liczb losowych, może tu być problemem, ponieważ wówczas korzystamy ze zwykłych algorytmów losowych, możemy być w stanie przewidzieć wynik losowania, a w ten sposób również wygenerowane hasło.

Kolejna kwestia — sekret musimy bezpiecznie dostarczyć do tego, kto będzie go używał. Najlepiej odpowiednio zabezpieczonym kanałem.

Krok 2 – rotowanie / zmiana

Wiedząc, że każdy sekret może zostać skompromitowany, musimy udostępnić możliwość jego zmiany w naszym systemie.

Krok 3 – zablokowanie

Tu bez wyjątku. Każdy sekret, którego nie używamy, powinien zostać wyłączony. Nie powinny istnieć żadne kanały wejścia do systemu, które są niepotrzebnie otwarte. Jak nikt nie używa danych drzwi, to trzeba je zamknąć.

Tylko uwaga. Ważne jest, żeby podczas rotowania sekretu nie było konieczności wstrzymywania działania systemu Klienta. Dzięki temu nie będzie on zwlekał z rotowaniem. Warto więc tu zrobić zmianę hasła na zakładkę. Stare działa jeszcze przez jakiś czas.

Krok 4 – data ważności

Każde wygenerowane przez nas hasło powinno mieć zdefiniowaną datę ważności.

Dzięki temu łatwiej nam będzie kontrolować, które drzwi potrzebują być jeszcze otwarte i znaleźć te, które można zamknąć.

Sekrety systemowe do innych systemów

Tu oczywiście sprawa wygląda adekwatnie do poprzedniego przykładu, ale tym razem jesteśmy odbiorcą. Niestety jesteśmy tu też ograniczeni tym, co umożliwia nam system, który zarządza tymi sekretami.

Jednak nadal musimy nimi dobrze zarządzać po naszej stronie implementując mądry cykl życia sekretu.

Krok 1 – stworzenie

Gdy ktoś nam dostarczy sekret, musimy go bezpiecznie przechować. Najlepiej tak, żeby jak najmniej ludzi miało do niego dostęp.

Na pewno nie w kodzie ani w żadnym wspólnym miejscu.

Najlepiej w dedykowanych do tego usługach: Azure KeyVault czy AWS KMS

Krok 2 – rotowanie / zmiana

Gdy dany sekret zostanie upubliczniony, musimy jak najszybciej go zrotować — zastąpić go przez inny, który nie został upubliczniony. Na przykład świeżo wygenerowany.

W naszym systemie musimy być gotowi na łatwe rotowanie sekretów.

Krok 3 – zablokowanie

Żeby jak najbardziej ułatwić decyzje o rotowaniu, warto wspierać rotowanie bez downtime (niedostępności naszego systemu). Tak, żeby wymiana sekretu nie niosła negatywnych konsekwencji dla naszego systemu.

Krok 4 – data ważności

Powinna wymuszać rotowanie hasła. Warto to uwzględnić w procesach utrzymaniowych. Czyli być świadomym tych dat ważności i zrotować sekrety, zanim staną się zbyt stare.

O czym więc warto pamiętać?

Jako ktoś, kto tworzy sekrety:

  • tworzymy je bezpiecznie (długie, skomplikowane, z bezpiecznym losowaniem),
  • dajemy możliwość rotowania, bez wyłączenia systemu i upraszamy całość procesu.

Jako ktoś, kto używa sekretów

  • nie daj im wycieknąć (repozytorium, maile, itp.),
  • regularnie rotuj.

Mała myśl na koniec.

Czy w ogóle potrzebujemy sekretów?

Niekoniecznie, korzystając z zasobów chmurowych możemy skorzystać z wbudowanego zarządzania tożsamościami pomiędzy usługami. Jest to bardzo wygodne i nie wymaga zarządzania żadnymi sekretami.

Jak zainteresował Cię temat, to zapraszam do kolejnych artykułów w tej tematyce.

%d bloggers like this: