Bezpieczeństwo integracji systemów: dostęp do API i ochrona danych

Integracja sklepu internetowego z magazynem i księgowością skraca obsługę zamówień, ale tworzy też nowe drogi dostępu do firmowych danych. Jeśli połączenie korzysta z konta administratora, a jego klucz API trafia do dziennika błędów, pojedynczy wyciek może zagrozić kilku systemom jednocześnie. Bezpieczeństwo integracji systemów zaczyna się więc od konkretnych decyzji: jakie operacje dopuścić, gdzie przechowywać dane uwierzytelniające i jak wycofać dostęp, gdy przestaje być potrzebny.

Przyznawaj uprawnienia dostępu zgodnie z zadaniem

Podstawą jest zasada najmniejszych uprawnień. Każda integracja powinna otrzymać wyłącznie taki dostęp, jakiego wymaga jej zadanie biznesowe. Połączenie pobierające stany magazynowe zazwyczaj nie potrzebuje możliwości zmiany cen, usuwania produktów ani przeglądania danych klientów.

Przed konfiguracją warto opisać trzy elementy:

  • Zakres danych — do jakich zasobów integracja ma dostęp, np. produktów z wybranego magazynu.
  • Dozwolone operacje — czy może odczytywać, dodawać, aktualizować lub usuwać dane.
  • Kontekst działania — której firmy, oddziału lub grupy dokumentów dotyczy dostęp.

Osobne konto techniczne albo osobny zestaw danych uwierzytelniających dla każdego połączenia ułatwia kontrolę. Pozwala ustalić źródło operacji i wyłączyć jedną integrację bez zatrzymywania pozostałych. Nie należy opierać automatyzacji na prywatnym koncie pracownika, którego rola może się zmienić lub który może odejść z firmy.

Sprawdzaj dostęp również do konkretnych rekordów

Uwierzytelnianie potwierdza tożsamość aplikacji, a autoryzacja określa, co wolno jej zrobić. Poprawny token nie powinien automatycznie otwierać dostępu do wszystkich danych.

API musi sprawdzać uprawnienia przy każdym żądaniu, również względem wskazanego rekordu. Integracja obsługująca jeden oddział nie powinna pobrać dokumentów innego oddziału po zmianie identyfikatora w zapytaniu. Ukrycie przycisku w panelu użytkownika nie zapewnia takiej kontroli.

Przechowuj klucze i tokeny poza kodem aplikacji

Hasła kont technicznych, tajne klucze API i tokeny dostępu należy traktować jak dane umożliwiające wejście do systemu. Nie powinny trafiać do repozytorium kodu, dokumentacji projektowej, zgłoszeń serwisowych ani wiadomości na firmowym komunikatorze.

W środowisku produkcyjnym warto korzystać z menedżera sekretów, czyli usługi przechowującej poufne wartości i kontrolującej ich udostępnianie aplikacjom. Dostęp do niej również powinien być ograniczony: aplikacja pobierająca jeden klucz nie potrzebuje prawa odczytu wszystkich firmowych sekretów.

Plik konfiguracyjny poza repozytorium może być rozwiązaniem w prostszym środowisku, ale sam brak pliku w Git nie wystarcza. Potrzebne są odpowiednie prawa dostępu, ochrona kopii zapasowych i zabezpieczenie przed udostępnieniem pliku przez serwer WWW. Zmienne środowiskowe również wymagają ostrożności — mogą pojawić się w zrzutach diagnostycznych lub panelach administracyjnych.

Oddzielaj dane uwierzytelniające środowiska testowego i produkcyjnego. Testy powinny korzystać z danych syntetycznych, a dostęp do rzeczywistych danych wymaga osobnego uzasadnienia i zabezpieczeń.

Zaplanuj wymianę i unieważnianie sekretów

Każdy sekret powinien mieć właściciela, określony cel oraz procedurę wymiany. Jeśli dostawca obsługuje krótkotrwałe tokeny, warto je wykorzystać. Trzeba przy tym chronić również mechanizm ich odnawiania, ponieważ token odświeżający może zapewniać dłuższy dostęp niż sam token używany do wywołań API.

Planową wymianę klucza można przeprowadzić przez wdrożenie nowego, sprawdzenie działania i unieważnienie starego. Przy podejrzeniu wycieku priorytetem jest szybkie odcięcie zagrożonego dostępu. Usunięcie klucza z bieżącej wersji kodu nie wystarcza, jeśli nadal działa lub pozostał w historii repozytorium.

Szyfruj transmisję i weryfikuj certyfikaty

Połączenia z API powinny korzystać z HTTPS z prawidłowo skonfigurowanym TLS. Dotyczy to także komunikacji między usługami wewnątrz infrastruktury firmy.

Szyfrowanie musi iść w parze ze sprawdzaniem tożsamości serwera. Aplikacja powinna weryfikować ważność certyfikatu, zgodność nazwy hosta oraz zaufanie do wystawcy. Wyłączenie tych kontroli w celu obejścia błędu może umożliwić przechwycenie komunikacji. Szczegóły konfiguracji opisują zalecenia CERT Polska dotyczące zabezpieczenia transmisji TLS.

Warto monitorować terminy ważności certyfikatów i automatyzować ich odnawianie. Zabezpieczenie powinno obejmować całą drogę danych, także odcinek między serwerem pośredniczącym a aplikacją docelową.

Poufnych tokenów nie należy umieszczać w adresach URL, które często trafiają do logów infrastruktury. Trzeba przekazywać je zgodnie z dokumentacją mechanizmu uwierzytelniania i chronić przed zapisem także w nagłówkach.

Ochrona danych w API obejmuje również logi

Dzienniki zdarzeń pomagają wykrywać awarie i nadużycia. Jednocześnie mogą stać się dodatkową bazą danych klientów, jeśli aplikacja zapisuje pełną treść każdego żądania i odpowiedzi.

Do ustalenia, dlaczego nie udała się synchronizacja zamówienia, zwykle wystarczą czas zdarzenia, nazwa integracji, rodzaj operacji, kod odpowiedzi i identyfikator pozwalający powiązać wpisy dotyczące tej samej operacji. Adres dostawy, numer telefonu czy pełna faktura często są zbędne.

Najbezpieczniej określić listę pól dopuszczonych do zapisu. Filtrowanie należy stosować również do komunikatów błędów, narzędzi monitoringu, serwerów pośredniczących i zgłoszeń wysyłanych do wsparcia technicznego.

Szczególnej ochrony wymagają:

  • hasła, klucze API i tokeny — należy wykluczyć ich wartości z logów;
  • dane osobowe — zapisywać je wyłącznie w zakresie potrzebnym do konkretnego celu;
  • treść dokumentów i załączników — nie rejestrować jej automatycznie podczas zwykłej diagnostyki.

Zastąpienie nazwiska identyfikatorem nie musi oznaczać anonimizacji, jeśli nadal można powiązać wpis z osobą. Same logi potrzebują kontroli dostępu, ochrony przed nieuprawnioną zmianą i ustalonego okresu przechowywania. Tymczasowe rozszerzenie diagnostyki powinno mieć termin zakończenia.

Odbieraj dostęp nieużywanym połączeniom

Wyłączenie zadania synchronizującego dane nie unieważnia jego klucza. Nieużywana integracja może zachować dostęp przez wiele miesięcy, mimo że nikt już jej nie nadzoruje.

Prowadź rejestr połączeń zawierający ich cel, właściciela, systemy źródłowe i docelowe, zakres uprawnień oraz datę ostatniego użycia. W rejestrze zapisuj identyfikator sekretu, bez jego poufnej wartości.

Przy zamykaniu integracji:

  1. Potwierdź, czy nie obsługuje procesu uruchamianego rzadko, np. rozliczenia rocznego.
  2. Zatrzymaj zadania i powiadomienia automatycznie wywołujące połączenie.
  3. Unieważnij klucze, tokeny i inne powiązane metody dostępu.
  4. Usuń zbędne sekrety z konfiguracji i sprawdź, czy stare dane uwierzytelniające są odrzucane.

Przegląd jest szczególnie potrzebny po zmianie dostawcy, zakończeniu pilotażu lub zastąpieniu aplikacji nowym rozwiązaniem.

Sprawdź zabezpieczenia przed uruchomieniem integracji

Test odbiorowy powinien potwierdzać zarówno prawidłową wymianę danych, jak i skuteczną odmowę dostępu. W środowisku testowym sprawdź, czy integracja nie wykona operacji spoza swojego zakresu, nie odczyta cudzego rekordu i nie połączy się po unieważnieniu tokenu. Wywołaj też kontrolowany błąd i przejrzyj logi pod kątem ujawnionych danych.

Na etapie utrzymania przypisz osobę odpowiedzialną za alerty o nietypowej liczbie wywołań, odmowach dostępu i zmianach uprawnień. Przygotuj procedurę awaryjnego odcięcia połączenia oraz wznowienia synchronizacji. Dzięki temu zespół będzie wiedział, jak ograniczyć incydent i bezpiecznie obsłużyć dane oczekujące na przesłanie.