Klucze API i uprawnienia w sklepie - jak je nadawać i bezpiecznie przechowywać

Zasada najmniejszych uprawnień w praktyce integracji

Zasada najmniejszych uprawnień brzmi prosto, ale w sklepach często jest łamana z wygody. Programista prosi o klucz „z pełnym dostępem, żeby nic nie blokowało”, a po wdrożeniu nikt go już nie ogranicza. Poniżej przykładowe zakresy dla typowych integracji, które warto ustalić jeszcze przed wygenerowaniem klucza:

Zakres uprawnień warto zapisać w briefie dla programisty i sprawdzić przy odbiorze, razem z listą kluczy, które integracja zostawia w sklepie. Jak przygotować taki brief i kryteria odbioru, opisujemy we wpisie o tym, jak zlecić integrację programiście.

Osobne konto techniczne dla każdej integracji

Klucz API w wielu platformach jest powiązany z kontem użytkownika. Jeśli integracja korzysta z konta konkretnego pracownika, odejście tej osoby i usunięcie jej konta zatrzyma integrację, a w logach nie da się odróżnić działań człowieka od działań programu. Lepiej utworzyć osobne konto techniczne dla każdej integracji, z nazwą wskazującą jej przeznaczenie, z minimalną rolą i bez możliwości logowania do panelu, jeśli platforma na to pozwala, jak w Shoperze przy wyborze dostępu tylko do webapi.

Gdzie przechowywać klucze API - bezpieczne przechowywanie sekretów

OWASP Secrets Management Cheat Sheet, czyli zbiór zaleceń fundacji OWASP dotyczących zarządzania sekretami, wskazuje kilka zasad, które dobrze przekładają się na sklepy internetowe: scentralizowane przechowywanie, ograniczony dostęp, automatyzację rotacji, audyt użycia, szyfrowanie oraz wykrywanie wycieków. Najważniejsza praktyczna rada jest prosta: sekret nie powinien znaleźć się w kodzie źródłowym ani w obrazie kontenera.

[#chart:wpr75b]

Dla małego sklepu wystarczą zwykle zmienne środowiskowe na serwerze lub w usłudze hostingowej, menedżer sekretów dostawcy chmury dla integracji uruchamianych w chmurze oraz menedżer haseł dla zespołu do przekazywania kluczy między ludźmi. Kluczy nie wysyła się mailem ani komunikatorem, a jeśli już tak się stało, traktuje się je jako ujawnione i wymienia. Pliki konfiguracyjne z sekretami muszą być wykluczone z repozytorium, a repozytorium warto skanować narzędziem do wykrywania sekretów.

Klucze zapisane w bazie danych sklepu i w kopiach zapasowych

Klucze do usług zewnętrznych, np. przewoźników, bramek płatności czy narzędzi mailingowych, wpisuje się często w ustawieniach wtyczek i modułów, a te zapisują je w bazie danych sklepu. Oznacza to, że każdy, kto ma dostęp do bazy, jej eksportu albo kopii zapasowej, ma też dostęp do tych kluczy. Dlatego kopie zapasowe sklepu trzeba chronić tak samo jak hasła, nie udostępniać pełnego zrzutu bazy wykonawcom, którzy go nie potrzebują, a do testów używać kopii z kluczami podmienionymi na testowe. Przy wyborze wtyczki warto sprawdzić, czy pozwala przechowywać klucze poza bazą, np. w pliku konfiguracyjnym lub zmiennej środowiskowej.

[#uwaga] Częstym źródłem wycieków są logi. Integracja, która przy błędzie zapisuje całe zapytanie HTTP, zapisuje też nagłówek z kluczem lub tokenem. Logi trafiają potem do zgłoszeń serwisowych, zrzutów ekranu i plików wysyłanych zewnętrznym firmom. Przy przeglądzie integracji zawsze sprawdzamy, czy logi maskują dane uwierzytelniające.

Rotacja kluczy API bez przestoju integracji

Klucz, który działa od kilku lat i był przekazywany kolejnym programistom, warto regularnie wymieniać. Wymiana nie musi zatrzymywać integracji, jeśli przeprowadzi się ją w odpowiedniej kolejności:

1. wygeneruj nowy klucz z tym samym lub węższym zakresem uprawnień,

2. podmień klucz w menedżerze sekretów lub zmiennych środowiskowych integracji,

3. sprawdź w logach, że integracja używa już nowego klucza i zapytania przechodzą,

4. odbierz dostęp staremu kluczowi i zapisz datę wymiany w rejestrze kluczy.

Ten sam schemat pokazuje diagram poniżej. Kluczowe jest to, żeby stary klucz wyłączać dopiero po potwierdzeniu w logach, że integracja korzysta z nowego. Odwrotna kolejność to najczęstsza przyczyna przestojów przy wymianie kluczy.

[#chart:wpr75c]

Tam, gdzie platforma nie pozwala mieć dwóch aktywnych kluczy naraz albo, jak w przypadku aplikacji tworzonych w panelu Shopify, nowy token wymaga ponownej instalacji, wymianę planuje się na okres najmniejszego ruchu i uprzedza wszystkie osoby, które korzystają z integracji. Przy tokenach OAuth wydawanych na czas określony, jak w API marketplace'ów, rotacja odbywa się automatycznie przy odświeżaniu, ale trzeba pilnować, by nowy token był poprawnie zapisywany.

Rejestr kluczy i audyt dostępów API w sklepie

Większość sklepów po kilku latach nie wie, ile kluczy API jest aktywnych i kto z nich korzysta. Prosty rejestr rozwiązuje ten problem. Dla każdego klucza warto zapisać: platformę i nazwę klucza, integrację, która go używa, zakres uprawnień, konto, do którego jest przypisany, osobę odpowiedzialną, datę utworzenia i ostatniej wymiany oraz miejsce przechowywania. Raz na kwartał porównaj rejestr z listą kluczy w panelu sklepu i odbierz dostęp tym, których nie da się przypisać do działającej integracji.

Do audytu przydaje się też lista integracji, które otrzymują dane od sklepu w inny sposób, np. przez webhooki. Adres odbiorcy webhooka i sekret do podpisu to również dane, które trzeba chronić i wymieniać. Zasady bezpiecznego przyjmowania webhooków opisujemy we wpisie o tym, jak działają webhooki w e-commerce.

Klucze API przy współpracy z agencją i zmianie programisty

Najwięcej niekontrolowanych kluczy powstaje przy współpracy z zewnętrznymi firmami. Agencja reklamowa potrzebuje feedu, firma od mailingu podłącza swoją wtyczkę, freelancer testuje integrację na produkcji. Każda z tych osób dostaje klucz, a po zakończeniu współpracy nikt go nie wyłącza. Dlatego przy każdej nowej współpracy warto od razu ustalić, kto generuje klucz, jaki ma zakres i kiedy dostęp zostanie odebrany.

Klucze powinien generować właściciel sklepu lub osoba odpowiedzialna za IT po jego stronie, a nie zewnętrzny wykonawca na koncie administratora. Wykonawca dostaje klucz przez menedżer haseł lub inny bezpieczny kanał i zapisuje go w środowisku integracji. Po zakończeniu projektu lub zmianie programisty wszystkie klucze, które znał poprzedni wykonawca, wymienia się według procedury rotacji, a nieużywane wyłącza. To samo dotyczy kont technicznych, haseł do serwera i dostępu do repozytorium.

Dodatkowe zabezpieczenia - HTTPS i ograniczenie adresów IP

Klucze API przesyła się wyłącznie przez połączenie szyfrowane HTTPS. Sklep, w którym API działa także po zwykłym HTTP, naraża klucze na przechwycenie. Jeśli integracja łączy się zawsze z tych samych serwerów, warto rozważyć ograniczenie dostępu do API do znanych adresów IP na poziomie serwera, zapory lub usługi pośredniczącej. Nie każda platforma i nie każdy hosting na to pozwala, a przy usługach chmurowych adresy mogą się zmieniać, więc to rozwiązanie uzupełnia, a nie zastępuje minimalne uprawnienia i bezpieczne przechowywanie kluczy.

Co zrobić, gdy klucz API wycieknie

Jeśli klucz trafił do publicznego repozytorium, maila do niewłaściwej osoby albo na zrzut ekranu, działaj od razu, nie czekając na potwierdzenie nadużycia:

• odbierz dostęp ujawnionemu kluczowi w panelu sklepu i wygeneruj nowy dla integracji,

• sprawdź w logach serwera i platformy, jakie zapytania wykonano tym kluczem od momentu ujawnienia,

• oceń, czy klucz dawał dostęp do danych osobowych klientów, i skonsultuj z prawnikiem lub inspektorem ochrony danych, czy incydent wymaga zgłoszenia,

• usuń sekret z historii repozytorium lub dokumentów i ustal, jak do wycieku doszło.

Jak Vinson pomaga z kluczami API i uprawnieniami w sklepie

Programiści Vinson przeglądają dostępy API w sklepach na WooCommerce, PrestaShop, Shoperze i Shopify oraz w integracjach z marketplace'ami i ERP. Tworzymy rejestr kluczy, ograniczamy uprawnienia do potrzebnego minimum, zakładamy osobne konta techniczne, przenosimy sekrety z kodu do zmiennych środowiskowych lub menedżera sekretów, wyłączamy zapisywanie kluczy w logach i przeprowadzamy wymianę kluczy bez przestoju. Pomagamy też uporządkować dostępy po zmianie programisty lub agencji. Więcej znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Jakie uprawnienia nadać kluczowi API dla integratora?

Tylko te, których integrator potrzebuje do swoich zadań, zwykle odczyt produktów i zamówień oraz zapis stanów, cen i statusów. Nie nadawaj dostępu do ustawień sklepu ani usuwania danych, jeśli integracja tego nie wymaga. Zakres warto zapisać i sprawdzić po wdrożeniu.

Gdzie bezpiecznie przechowywać klucze API?

W menedżerze sekretów, zmiennych środowiskowych na serwerze lub w menedżerze haseł zespołu. Nigdy w kodzie źródłowym, repozytorium, mailach, komunikatorach ani arkuszach. Dostęp do sekretów powinny mieć tylko osoby i systemy, które ich potrzebują.

Jak często wymieniać klucze API w sklepie?

Nie ma jednego terminu dla wszystkich sklepów, ale klucz warto wymienić zawsze po zmianie programisty lub agencji, po odejściu osoby, która go znała, i po każdym podejrzeniu wycieku. Dobrą praktyką jest też regularna wymiana według planu zapisanego w rejestrze kluczy.

Czy jeden klucz API może obsługiwać kilka integracji?

Technicznie tak, ale to zły pomysł. Przy wspólnym kluczu nie da się ograniczyć uprawnień każdej integracji osobno, w logach nie widać, która z nich wykonała zapytanie, a odebranie dostępu jednej integracji wyłącza wszystkie.

Co zrobić, gdy zgubię Consumer Secret w WooCommerce?

Dokumentacja WooCommerce podaje, że Consumer Secret wyświetla się tylko raz. Jeśli go nie zapisałeś, wygeneruj nowy klucz, wpisz go w integracji i odbierz dostęp staremu kluczowi przez opcję Revoke Key.

Klucze API to niewidoczne drzwi do sklepu, przez które przechodzą zamówienia, ceny i dane klientów. Osobny klucz dla każdej integracji, minimalne uprawnienia, bezpieczne przechowywanie, rejestr i plan wymiany to kilka prostych zasad, które znacząco zmniejszają ryzyko. Jeśli chcesz uporządkować dostępy API w swoim sklepie, sprawdź wsparcie programistyczne Vinson.