Klucz API pozwala aplikacji komunikować się z giełdą bez przekazywania loginu, hasła i kodu 2FA przy każdej operacji. To wygodne rozwiązanie dla monitoringu oraz automatyzacji, ale zakres dostępu musi odpowiadać konkretnemu zadaniu. Klucz z nadmiernymi uprawnieniami zwiększa skutki błędu lub wycieku.
Ogólne zasady ochrony konta opisaliśmy w artykule Bezpieczeństwo konta i API: siedem zasad ochrony kapitału. Poniżej koncentrujemy się na konfiguracji integracji z giełdą.
Z czego składa się dostęp API
Giełda zwykle generuje identyfikator klucza oraz sekret. Identyfikator może wskazywać integrację, natomiast sekret służy do podpisywania żądań i powinien pozostać poufny. Część platform pokazuje sekret tylko raz.
Nie należy wysyłać pełnego klucza przez e-mail, komunikator ani formularz wsparcia. Zespół pomocy nie potrzebuje sekretu, aby sprawdzić status konta lub wyjaśnić konfigurację.
Uprawnienie do odczytu
Zakres read-only pozwala zwykle pobierać saldo, historię zleceń, status wpłat i inne dane konta. Nie umożliwia składania transakcji. Jest właściwym wyborem dla raportowania, alertów i integracji analitycznych.
Odczyt również ujawnia informacje wrażliwe: wartość portfela, strukturę aktywów i historię aktywności. Dlatego klucz read-only nadal wymaga bezpiecznego przechowywania i nie powinien trafiać do kodu aplikacji ani publicznego repozytorium.
Uprawnienie do tradingu
Zakres trade pozwala składać, zmieniać i anulować zlecenia. Jest potrzebny botowi wykonującemu strategię. Nie oznacza to jednak, że integracja powinna otrzymać dostęp do wszystkich rynków i funkcji.
Jeżeli giełda oferuje bardziej szczegółowe ustawienia, należy ograniczyć klucz do potrzebnego rachunku, na przykład spot, bez margin i futures. Po stronie bota potrzebne są dodatkowe limity: maksymalna wartość zlecenia, dzienna ekspozycja, dozwolone symbole oraz awaryjne zatrzymanie.
Uprawnienie do wypłat
Bot, który analizuje rynek i składa zlecenia, zazwyczaj nie potrzebuje prawa do wypłaty aktywów. To uprawnienie powinno pozostać wyłączone. Oddzielenie tradingu od wypłat znacząco ogranicza możliwe skutki przejęcia klucza.
Jeżeli osobny proces biznesowy rzeczywiście wymaga wypłat, powinien używać oddzielnego klucza, zatwierdzonych adresów i dodatkowej autoryzacji. Łączenie automatycznego tradingu i swobodnych wypłat w jednym sekrecie nie jest rozsądnym ustawieniem domyślnym.
Whitelista adresów IP
Ograniczenie klucza do adresów IP serwera sprawia, że podpisane żądanie wysłane z innej lokalizacji zostanie odrzucone. Nie zastępuje to ochrony sekretu, ale tworzy dodatkową warstwę.
Przed aktywacją whitelisty trzeba upewnić się, że infrastruktura używa stałych adresów wyjściowych. Po zmianie serwera lub sieci stary wpis należy usunąć, a nowy dodać kontrolowanym procesem.
Gdzie przechowywać sekret
Sekret nie powinien znajdować się bezpośrednio w kodzie, pliku eksportowanym razem z aplikacją, logach ani treści zgłoszenia. Bezpieczniejsze są przeznaczone do tego magazyny sekretów lub zaszyfrowana konfiguracja z ograniczonym dostępem.
Aplikacja nie powinna wyświetlać pełnego sekretu po zapisaniu. Logi żądań również muszą maskować nagłówki i parametry uwierzytelniające. Kopie zapasowe wymagają takiej samej ochrony jak aktywna baza.
Rotacja i rozdzielenie kluczy
Każda integracja powinna otrzymać własny klucz. Dzięki temu można wyłączyć jeden system bez zatrzymywania pozostałych i dokładniej ustalić źródło zdarzenia.
Klucz należy wymienić po zmianie operatora, migracji infrastruktury, podejrzeniu wycieku albo pojawieniu się sekretu w logach. Okresowa rotacja jest wartościowa, jeśli organizacja potrafi przeprowadzić ją bezpiecznie i potwierdzić usunięcie starego klucza.
Sygnały możliwej kompromitacji
Niepokojące są nieznane adresy IP, zlecenia poza dozwolonymi parami, nagły wzrost liczby żądań, błędy podpisu oraz utworzenie nowego klucza bez zgody użytkownika. Monitoring powinien odróżniać zwykły błąd aplikacji od aktywności wymagającej natychmiastowej reakcji.
Co zrobić po podejrzeniu wycieku
- unieważnij podejrzany klucz na giełdzie,
- zatrzymaj powiązaną automatyzację,
- sprawdź historię zleceń, sesji i zmian bezpieczeństwa,
- zmień dane dostępowe, jeżeli mogły zostać ujawnione,
- utwórz nowy klucz z minimalnym zakresem i nowym sekretem,
- ustal źródło incydentu przed ponownym uruchomieniem.
Samo wygenerowanie nowego klucza bez usunięcia przyczyny może powtórzyć problem.
Bezpieczna konfiguracja dla bota
Typowa konfiguracja automatyzacji spot obejmuje odczyt salda i zleceń, prawo do handlu, wyłączone wypłaty oraz whitelistę IP. Do tego dochodzą limity po stronie aplikacji i alerty. Więcej o mechanizmach zatrzymania znajduje się w artykule Automatyzacja tradingu: co powinien kontrolować dobry bot.
Bezpieczeństwo API nie opiera się na jednym przełączniku. Najlepszy efekt daje połączenie minimalnych uprawnień, ograniczenia źródła połączeń, ochrony sekretu, obserwacji zdarzeń i gotowego planu reakcji.