Bezpieczeństwo API bez paranoi: klucze i uprawnienia

Kiedy mówimy o bezpieczeństwie, wyobrażamy sobie ataki rodem z filmów. Tymczasem większość incydentów związanych z API wygląda banalnie: klucz wklejony do komunikatora, plik z hasłami w repozytorium, jedno konto z dostępem do wszystkiego. Teza wpisu: bezpieczeństwo integracji to przede wszystkim higiena, a nie zaawansowana technologia. Kilka dyscyplin załatwia większość ryzyka.

Klucz API to hasło do firmy

Klucz API działa jak hasło dla programu. Kto go ma, może robić to, na co klucz pozwala: wysyłać wiadomości w Twoim imieniu, czytać zamówienia, wystawiać dokumenty. Dlatego obowiązują te same zasady co przy hasłach, a nawet ostrzejsze, bo klucz zwykle nie ma drugiego składnika uwierzytelniania.

Siedem zasad higieny

1. Klucze tylko na serwerze. Nigdy w kodzie, który trafia do przeglądarki, nigdy w aplikacji mobilnej bez pośrednika. Co widzi przeglądarka, widzi każdy.
2. Nigdy w repozytorium. Klucze wpisane do kodu zostają w historii, nawet po usunięciu. Używaj zmiennych środowiskowych lub menedżera sekretów.
3. Minimalne uprawnienia. Osobny klucz do każdej integracji, z najmniejszym potrzebnym zakresem. Klucz „do odczytu” nie może zapisywać.
4. Osobne klucze dla środowisk. Test i produkcja mają różne klucze. Pomyłka w teście nie ma wtedy skutków dla klientów.
5. Rotacja. Zmieniaj klucze regularnie i po każdej zmianie osób, które je znały. Proces rotacji ma być prosty, bo skomplikowany nie będzie stosowany.
6. Ograniczenia sieciowe. Jeśli program to umożliwia, zawęź użycie klucza do adresów IP lub domeny.
7. Monitorowanie. Alarm przy nietypowym ruchu, np. gwałtownym wzroście liczby zapytań albo użyciu klucza z nowego miejsca.

Dane klientów w API: RODO bez straszenia

Integracja często przenosi dane osobowe. Wystarczy kilka reguł:

• Zbieraj tylko to, co potrzebne. Jeśli faktura nie wymaga numeru telefonu, nie wysyłaj go dalej.
• Wiedz, gdzie dane trafiają. Każdy zewnętrzny serwis w przepływie to odbiorca danych. Sprawdź umowę powierzenia i lokalizację przetwarzania.
• Nie loguj danych wrażliwych. Logi są potrzebne do diagnozy, ale nie powinny zawierać pełnych danych klientów ani kluczy.
• Szyfruj połączenia. Wszystko po HTTPS, bez wyjątków.

Co robić, gdy klucz wyciekł

1. Natychmiast go unieważnij i wygeneruj nowy.
2. Sprawdź logi użycia starego klucza z okresu, w którym był narażony.
3. Oceń skutki: do jakich danych klucz miał dostęp.
4. Jeśli dotyczy to danych osobowych, zastanów się nad obowiązkiem zgłoszenia naruszenia. W razie wątpliwości skonsultuj to z osobą odpowiedzialną za ochronę danych.
5. Napraw przyczynę, nie tylko skutek: skąd klucz się wziął w złym miejscu.

Ukrywanie szczegółów nie jest ochroną

Tak samo jak w sklepach headless, ukrycie platformy utrudnia automatyczne skanowanie, ale nie zastępuje higieny. To jedna warstwa, nie cała ochrona. Więcej o tej logice: backend sklepu poza internetem.

Mini-audyt integracji w godzinę

Nie potrzebujesz zespołu bezpieczeństwa, żeby zrobić pierwszy przegląd. Weź listę swoich integracji i dla każdej wypełnij tabelę:

Pytanie	Dlaczego ważne
Gdzie jest zapisany klucz?	klucz w kodzie, arkuszu lub komunikatorze to klucz jawny
Kto ma do niego dostęp?	każda osoba, która go zna, to ryzyko
Jakie ma uprawnienia?	czy musi móc usuwać i czytać wszystko?
Kiedy był ostatnio zmieniony?	stary klucz bywa już poza kontrolą
Czy działa osobno dla testu i produkcji?	pomyłka w teście nie może dotknąć klientów
Kto dostaje alarm przy nietypowym ruchu?	bez tego wyciek zobaczysz po fakturze

Zaznacz na czerwono każdą odpowiedź „nie wiem”. Zwykle jest ich więcej niż się spodziewasz, i to jest dobry wynik, bo masz listę zadań.

Typowe błędy, które widzimy w małych firmach

• Jeden klucz do wszystkiego, wpisany w trzech miejscach.
• Klucz w mailu do wykonawcy „żeby było szybciej”.
• Konto byłego pracownika lub wykonawcy wciąż z dostępem.
• Brak rozdzielenia środowiska testowego i produkcyjnego.
• Panel administracyjny dostępny z każdego miejsca bez dodatkowego zabezpieczenia.

Co poprawić w pierwszej kolejności

1. Usuń nieużywane klucze i konta. Najtańsza i najskuteczniejsza zmiana.
2. Włącz uwierzytelnianie dwuskładnikowe wszędzie, gdzie jest dostępne, zwłaszcza w panelach administracyjnych.
3. Rozdziel klucze według integracji i środowiska.
4. Przenieś klucze do zmiennych środowiskowych lub menedżera sekretów.
5. Ustal osobę odpowiedzialną za przegląd raz na kwartał.

Te pięć kroków załatwia większość realnego ryzyka. Resztę (podpisywanie żądań, ograniczanie adresów IP, monitorowanie anomalii) dokłada się stopniowo, tam gdzie stawka jest najwyższa.

Podsumowanie

Bezpieczne API to nie tajemna wiedza, tylko kilka konsekwentnie stosowanych nawyków: klucze na serwerze, minimalne uprawnienia, rotacja i monitoring. Jeśli chcesz, żebyśmy przejrzeli integracje w Twojej firmie pod tym kątem, zobacz outsourcing IT. Poprzedni wpis cyklu: Zapier, Make czy własne API.