Bezpieczeństwo danych poza własną infrastrukturą. Jak kontrolować ryzyko?

Powierzchnia ataku Twojej organizacji obejmuje wszystkie aplikacje, z których korzystasz – nie tylko te, którymi zarządzasz samodzielnie. Jeśli dostawca SaaS przechowuje Twoje dane, podatność w jego aplikacji webowej może mieć konsekwencje również dla Twojej organizacji.

Ta zależność działa w obie strony. Jeśli dostarczasz oprogramowanie w modelu SaaS, bezpieczeństwo Twojej aplikacji ma bezpośredni wpływ na bezpieczeństwo klientów. Incydent związany z MyDr dobrze pokazuje, jak mocno obie strony są ze sobą powiązane.

Co wydarzyło się w przypadku MyDr?

W sierpniu 2026 roku doszło do incydentu dotyczącego MyDr, polskiego dostawcy oprogramowania do elektronicznej dokumentacji medycznej, z którego korzysta około 12 tys. placówek ochrony zdrowia. Placówki nie zostały zaatakowane bezpośrednio – dostęp uzyskany po stronie dostawcy mógł potencjalnie otworzyć drogę do danych pacjentów wielu z nich.

Według relacji osób deklarujących przeprowadzenie ataku punktem wejścia była podatność XML External Entity (XXE) związana ze sposobem, w jaki aplikacja obsługiwała certyfikaty PKCS#12. Według tej relacji umożliwiło to zdalne wykonanie kodu. Następnie osoby te miały odnaleźć klucz API GitHub, uzyskać dostęp do kodu źródłowego, a później do infrastruktury chmurowej firmy. Ani MyDr, ani polskie organy nie potwierdziły, że właśnie w ten sposób doszło do incydentu.

Opisany mechanizm jest jednak dobrze znany specjalistom zajmującym się bezpieczeństwem aplikacji. Nieprawidłowa obsługa niezaufanych danych XML może prowadzić do wykonania kodu, uzyskania dostępu do danych uwierzytelniających, a następnie do kolejnych elementów infrastruktury.

XXE należy do kategorii Security Misconfiguration w OWASP Top 10. Jest to znana klasa podatności, dla której istnieją sprawdzone metody wykrywania i zabezpieczania aplikacji. Jej identyfikacja jest jednym z elementów standardowej oceny bezpieczeństwa aplikacji webowych.

Incydent u dostawcy danych dotyczy również Twojej organizacji

Zgodnie z RODO MyDr jest podmiotem przetwarzającym dane, natomiast około 12 tys. placówek ochrony zdrowia korzystających z jego oprogramowania pozostaje administratorami tych danych.

To rozróżnienie ma znaczenie w przypadku incydentu. To administrator ocenia ryzyko związane z naruszeniem oraz – jeśli zachodzą odpowiednie przesłanki – dokonuje zgłoszenia i informuje osoby, których dane dotyczą.

Nie masz pełnej kontroli nad aplikacją swojego dostawcy. Masz jednak wpływ na to, jakich zabezpieczeń od niego wymagasz, zanim rozpoczniesz współpracę, oraz jakie warunki znajdą się w umowie:

1. Zapytaj, jak często dostawca sprawdza bezpieczeństwo aplikacji. Jak często prowadzone są testy? Czy obejmują również testy z uwierzytelnieniem? Jak szybko usuwane są wykryte podatności krytyczne?
2. Ustal zasady postępowania w przypadku incydentu. Określ, w jakim czasie dostawca powinien Cię o nim poinformować, jakie informacje techniczne powinien przekazać oraz jakie materiały otrzymasz, aby móc wypełnić własne obowiązki wobec osób, których dane dotyczą.
3. Sprawdź, gdzie przechowywane są dane. Lokalizacja infrastruktury oraz obowiązująca jurysdykcja mają znaczenie zarówno dla bezpieczeństwa, jak i obowiązków regulacyjnych.
4. Zapisz wymagania w umowie powierzenia przetwarzania danych. Częstotliwość testów bezpieczeństwa, sposób postępowania z wykrytymi podatnościami oraz terminy informowania o incydentach powinny być jasno określone.
5. Ustal, co możesz zweryfikować samodzielnie. Warto określić możliwość przeprowadzenia audytu, wykonania testów w wydzielonym środowisku lub uzyskania dostępu do raportów z testów bezpieczeństwa przeprowadzanych przez dostawcę.

Ciągła ocena bezpieczeństwa pozwala ograniczyć ryzyko między kolejnymi testami

Niezależnie od tego, jak wyglądały procesy bezpieczeństwa stosowane w MyDr, podatności należące do klasy wskazywanej w opisie tego incydentu są właśnie tym, czego poszukuje się podczas testów bezpieczeństwa aplikacji webowych.

Test wykonywany raz w roku pokazuje stan aplikacji w konkretnym momencie. Tymczasem aplikacja cały czas się zmienia – pojawiają się nowe wersje kodu, funkcje i konfiguracje. Każda taka zmiana może oznaczać pojawienie się nowej podatności. Ciągła ocena bezpieczeństwa pozwala kontrolować te zmiany również pomiędzy okresowymi testami.

Web Application Security jest częścią Holm Security Next-Gen Vulnerability Management Platform. Pozwala regularnie identyfikować podatności w aplikacjach webowych i jednocześnie zapewnia aktualny obraz podatności występujących także w środowiskach chmurowych oraz API.

Dzięki temu organizacja może na bieżąco obserwować zmiany w poziomie bezpieczeństwa i reagować na wykryte podatności, zamiast opierać się wyłącznie na wynikach okresowych testów.

Dowiedz się więcej o Web Application Security w Holm Security