Sekrety w naszym systemie są niezwykle istotne. Te, które są używane do komunikacji z naszym systemem, otwierają drzwi do danych i akcji w naszym systemie. Zaś te, które są używane do komunikacji z innymi systemami, również mogą narobić nam sporo problemów. Na przykład upublicznić dane naszych Klientów lub zmodyfikować dane w niewłaściwy sposób. Dlatego warto zadbać o poprawne zarządzanie sekretami.

Wyobraź sobie, że wyciekły szczegóły połączenia do naszej bazy danych. Ktoś teraz ma pełen dostęp do naszych danych. I to nie tylko do odczytu, ale również do zapisu!

Jak zadbać o zarządzanie sekretami w naszej aplikacji?

Podstawowa sprawa — bezpieczne przechowywanie

1. Najlepiej w dedykowanym narzędziu np. Azure KeyVault, AWS KMS, itp. To wygodna opcja, bo dedykowane narzędzia szyfrują sekrety oraz ułatwiają zarządzanie ich cyklem życia np. rotowaniem.
2. Pliki konfiguracyjne — nieidealnie, bo admin może je podejrzeć, ale przynajmniej wspierają łatwe podmienianie tych sekretów.

Oddzielenie sekretów Produkcyjnych od Testowych

Podstawowa kwestia to nieudostępnianie sekretów produkcyjnych deweloperom, jeżeli nie ma takiej konieczności. Im mniej osób ma dostęp tym lepiej (to bardzo uniwersalna zasada), ale mam lepszy powód. Wiele razy widziałem sytuację, że przez przypadek (przez błąd systemu) akcje na środowisku testowym (gdzie testerzy dość swobodnie robią różne dziwne operacje — i dobrze, taka ich praca) wywołują skutki w Produkcyjnych systemach.

Czyli na przykład działanie na środowisku testowym spowodowało wysłanie niepokojących maili (o braku środków na koncie) do prawdziwych Klientów.

Wniosek jest prosty: lepiej nie ryzykować. Bezpieczniej jest odseparować od siebie takie środowiska.

Ograniczenie dostępu w ramach sekretu

W duchu zasady Least privilige każdy sekret powinien również mieć określony zakres możliwości, które nam on udostępnia.

Dobrym przykładem tu jest GitHub, który przy generowaniu Personal Access Token (PAT), pozwala na precyzyjne określenie uprawnień, które on będzie dostarczał.

Pilnowanie zakresów uprawnień jest też świetnym wsparciem w rozwijaniu systemu. Wiemy dokładnie kto i z czego korzysta, znamy także moduły, do których nikt już od dawna nie zagląda.

Monitorowanie

Gdy zarządzamy sekretami w systemie, powinniśmy mieć je na oku. Warto dodać odpowiednie informacje do logów, związane z sekretami.

Jako udostępniający sekret (do naszego systemu):

• kto uzyskał dostęp do sekretu w czystym tekście? – dla celów audytowych,
• kiedy był użyty dany sekret i przez kogo? – na potrzeby potencjalnego śledzenia użycia sekretu, który wyciekł,
• kto i kiedy zrotował sekret? – dla historii zmian,
• wszystkie próby wykorzystania nieważnego już sekretu — żeby wykryć, kto jeszcze używa starego sekretu,
• kiedy sekret wygasł? – żeby być w stanie szybko zareagować.

Jako wykorzystujący sekret (do innego systemu):

• kto i kiedy zmienił sekret? – na wypadek prób ukrycia wykorzystania takiego sekretu lub podmiany konta w zewnętrznej usłudze na inne.

Dlaczego to istotne?

Chcemy jak najszybciej dowiedzieć się o wszystkim, jeśli coś złego zadzieje się z naszym systemem.

A Ty co byś dodał/a do tej listy najważniejszych zasad zarządzania sekretami?

Jeśli interesuje Cię temat sekretów, zapraszam do przeczytania innych artykułów w tej mini serii. Jeśli wolisz posłuchać na ten temat — możesz zajrzeć na mój kanał na YouTube.