Tak na zakończenie serii o bezpieczeństwie sekretów w aplikacjach mam dla Ciebie listę. To błędy zarządzania sekretami.

Potraktuj ją jak checklistę. Przy każdym punkcie pomyśl, jak jest u Ciebie, w Waszym zespole czy firmie. Upewnij się, że nie popełniasz żadnego z wymienionych tu błędów.

Od razu uprzedzam — jest to lista mocno subiektywna i nie opiera się na żadnych badaniach. Jest to moje własne opracowanie, przygotowane na bazie mojej wiedzy i doświadczenia zawodowego.

Mam nadzieję, że takie błędy zarządzania sekretami Ci się nie zdarzą. Zostawiam też kilka wskazówek, co zrobić, jeśli dany błąd u Was obecnie występuje.

To przejdźmy już do rzeczy.

1. Hardcodowanie sekretów w kodzie

Zapisywanie sekretów w kodzie to zły pomysł. Dlaczego?

Ponieważ:

• możemy je łatwo upublicznić,
• może mieć do nich dostęp ktoś nie powołany,
• ciężko jest zrotować sekret, bo wymaga to pełnego wdrożenia całego systemu.

Szerzej opisuje to w artykule “Co się stanie, jak umieszczę sekret w kodzie?”

Co zamiast tego?

Lepiej jest je przechowywać w dedykowanych serwisach jak Azure KeyVault lub AKS KMS.

2. Brak możliwości rotowania hasła bez niedostępności systemu

To bardzo ważny aspekt, który niejeden raz przysporzył ludziom stresu.

W momencie, gdy dowiemy się, że pewien sekret został skompromitowany, czyli wpadł w niepowołane ręce lub został upubliczniony, zależy nam na czasie. Powinniśmy jak najszybciej go zrotować.

Tylko jak to zrobić szybko i sprawnie, jeżeli musimy do tego wyłączyć na czas wdrożenia nasz system? Czyli musimy dostać zgodę właścicieli biznesowych systemu do wyłączenia go.

Praktyka pokazuje, że takie zdobywanie zgód trochę trwa. Zwykle za długo w momencie, gdy tak bardzo zależy nam na czasie.

Zdecydowanie lepiej będzie zadbać o przygotowanie tej możliwości “na wszelki wypadek”. Jako forma inwestycji albo ubezpieczenia.

Większy opis możesz znaleźć w “Cykl życia sekretu”

3. Złe przechowywanie sekretów

Zdarza się, że sekrety są przechowywane w zbyt dostępnych miejscach, na przykład w bazie danych. To tworzy tak zwane Single Point o Fail. W momencie gdy ktoś uzyska dostęp do bazy danych, w gratisie dostaje równie ogromną ilość dostępów do naszych zależności (i do wszystkich danych, które tam są).

Gdzie prawidłowo przechowywać sekrety?

Tak jak już wspomniałem w punkcie 1. – w dedykowanych serwisach jak Azure KeyVault lub AKS KMS.

4. Pełne uprawnienia sekretów w systemie zależnym

Często sekrety, z których korzystamy, mają pełne uprawnienia w systemie zależnym. Jeżeli dana usługa na to pozwala, powinniśmy jak najbardziej ograniczać możliwości sekretów. Tylko do tych, których rzeczywiście używamy. Na przykładzie Stripe: gdy nie korzystamy przez API ze zmiany numeru konta do wypłat, klucz do API Stripe nie powinien umożliwiać takich akcji.

Korzyści?

To redukuje nam skutki ewentualnego ataku (Lateral Movements — ruchy boczne), gdy już ktoś zdobędzie dany sekret.

Sprawdź, które usługi w systemach zależnych pozwalają ograniczać możliwości sekretów i dostosuj uprawnienia do potrzeb Waszego systemu. Większy opis jest w [???] [zarządzanie sekretami]

5. Wszyscy programiści mają dostęp do sekretu

Tego typu sytuacje przekazują trochę zbyt wiele władzy w ręce programisty. Przez to jesteśmy podatni na:

• przypadkowe upublicznienie sekretu — na kanale chat lub podczas prezentacji,
• celowe złośliwe wykorzystanie sekretu — żeby zdobyć pewne dane lub wywołać konkretną akcję.

Dostosowuj zakresy uprawnień. Pamiętaj, że jeśli ktoś już raz znał sekret, to trzeba zrotować hasło, żeby anulować to, które posiadał.

6. Brak audytu zmian i użycia sekretów

Bez odpowiedniego monitorowania cyklu życia (link) sekretu, dużo trudniej będzie nam zweryfikować, co popsuło się w komunikacji z określonym dostawcą.

Kiedy to może być istotne?

Na przykład, gdy będziemy w potrzebie udowodnienia komuś złych intencji, gdy podejrzy istotny sekret lub go zmodyfikuje, tak żeby wszystko przestało działać.

Jak prowadzić audyt zmian i użycia sekretów?

Tu polecam Ci zestawienie efektywnych zasad logowania zdarzeń dookoła zarządzania sekretami “Zarządzanie sekretami”

7. Używanie tych samych sekretów dla środowisk Testowych i Produkcyjnych

Brak oddzielnego konta lub środowiska do testów prowokuje groźne sytuacje. Na przykład pracując cały czas na środowisku TEST, można wykonać akcje na zewnętrznej zależności, która może mieć konsekwencje dotykająca naszych Klientów.

Dobry przykład to korzystanie z serwisu do wysyłki maili. Maile produkcyjne są wysłane jako konkretna osoba w imieniu naszej firmy (zweryfikowanej). Korzystając więc ze środowiska TEST, możemy wysłać złośliwe (lub po prostu niepotrzebne) maile do naszych Klientów, gdzie w mailu nadawcą nadal jest nasza firma. Nie muszę chyba dodawać, że to może poważnie zaszkodzić naszej reputacji.

Także koniecznie oddzielamy sekrety dla środowisk Testowych i Produkcyjnych. Najlepiej od razu sprawdzić, czy już dziś możemy ograniczyć deweloperom dostęp do tych Produkcyjnych.

8. Niebezpieczne przesyłanie sekretów

Każdy sekret musi w jakiś sposób znaleźć się w naszych rękach, żeby można go było użyć w docelowym systemie.

Cały cykl życia sekretu może być bardzo bezpieczny, jednak gdy samo przesyłanie sekretu jest niebezpieczne, łatwo o kompromitację. Spotkałem się z historiami o tym, że klucz do API był podany w czacie spotkania na Teamsach czy w Slacku. A następnie taka wiadomość była przekazywana dalej do różnych ludzi.

Pomyśl, czy mamy wówczas jakąś możliwość kontroli nad tym, co dzieje się z naszym sekretem?

Jak bezpiecznie przekazać sekret?

• przede wszystkim bezpiecznym kanałem,
• tak, żeby trudno było przypadkowo udostępnić go innym osobom,
• oraz tak, żeby zminimalizować liczbę osób, które go widziały.

9. Brak procedury na wypadek kompromitacji sekretu

Często w momencie gdy dowiadujemy się o wycieku konkretnego sekretu, zależy nam na czasie. Żeby jak najszybciej pozbyć się tego problemu.

Gdy zależy nam na czasie, cały proces analizy problemu i wymyślenie mitygacji (szczególnie w przypadku, gdy staniemy przed takim problemem po raz pierwszy) może potrwać zbyt długo. Dlatego to też warto ulepszać.

Czy macie ustalony plan działania na wypadek takiej sytuacji? Warto to przemyśleć i zaplanować ewentualne działania już teraz, gdy nam się nie spieszy.

10. Brak edukacji deweloperów

Bez wiedzy na temat tego czym są sekrety oraz jak je chronić, deweloperzy z pewnością nie będą w stanie sprawnie ich zabezpieczyć, jeśli będą znali dobrych wzorców pochodzących z innych systemów. Ciężej im też będzie wyłapać problematyczne w tym zakresie miejsca w kodzie.

Sposoby na edukację w tym zakresie?

Tu zdecydowanie polecam tworzenie wewnętrznych społeczności Security Champions, które wymieniałyby się wiedzą i wspólnie pracowały nad ulepszeniem bezpieczeństwa na poziomie poszczególnych projektów, jak i całej organizacji.

Polecam też śledzenie bieżących informacji w branży bezpieczeństwa. Lub jeżeli nie masz czasu, to skorzystanie z wyselekcjonowanych treści dostępnych na https://securitychampions.pl/

Podsumowanie

Jak widać, zasad jest sporo.

Odpowiedz na pytanie i zlicz błędy zarządzania sekretami — ilu błędów nie popełniasz. W komentarzu napisz, ile Ci wyszło.

Jeśli mniej niż 10, zaplanuj działania w obszarach, które wymagają naprawy. Zapisanie obecnego wyniku i przygotowanie planu pozwolą na ocenę postępów w przyszłości.

Opisane błędy zarządzania sekretami wydają się być trudne do uniknięcia, jednak zdecydowanie warto.