Najczęstsze klauzule w licencjach oprogramowania security i narzędziach pentesterskich

Na czym polega szczególna wrażliwość licencji w narzędziach security

Narzędzia „podwójnego zastosowania” – kiedy pentest przypomina nóż w kieszeni

Oprogramowanie security i narzędzia pentesterskie należą do kategorii tzw. narzędzi podwójnego zastosowania. Technicznie mogą służyć do dwóch skrajnie różnych celów: legalnych testów bezpieczeństwa oraz ataków cyberprzestępczych. Ten sam skaner podatności może pomóc organizacji załatać luki, ale też ułatwić włamanie na cudze serwery. Ten sam framework exploitów może być użyty w uporządkowanym red teamingu lub w klasycznym „włamie” na zlecenie przestępców.

Z tego powodu dostawcy narzędzi security bardzo precyzyjnie opisują w licencjach, co uważają za dozwolone użycie oprogramowania bezpieczeństwa, a czego kategorycznie zabraniają. Drobne przeoczenie – np. brak formalnej zgody właściciela systemu na testy – może spowodować, że ten sam techniczny scenariusz z punktu widzenia prawa staje się już atakiem, a nie testem.

Dlaczego dostawcy zaostrzają klauzule w licencjach security

Twórcy narzędzi pentesterskich mają kilka powodów, aby w licencjach formułować ostrzejsze klauzule niż w „zwykłym” oprogramowaniu biurowym czy developerskim:

• Ryzyko nadużyć – jeśli ktoś wykorzysta narzędzie do włamania, poszkodowany może próbować obarczyć również producenta. Klauzule „lawful use only” i „no malicious use” mają minimalizować tę ścieżkę.
• Wizerunek – pojawienie się nazwy narzędzia w akcie oskarżenia albo w doniesieniach o ataku może zaszkodzić reputacji dostawcy. Jasne ograniczenia w licencji są argumentem: „sprzedajemy narzędzie do legalnych testów, nie do przestępstw”.
• Odpowiedzialność cywilna – wyłączenia gwarancji i limity odpowiedzialności (np. „as is”, cap na odszkodowania) chronią dostawcę przed milionowymi roszczeniami, jeśli atakujący użyje legalnego narzędzia w nielegalny sposób.
• Regulacje eksportowe – część narzędzi może podpadać pod przepisy o kontroli eksportu (np. dual-use). Odpowiednie klauzule pomagają wykazać, że producent „dokłada starań”, aby nie sprzedawać do sankcjonowanych zastosowań.

Dla użytkownika oznacza to, że licencje narzędzi pentesterskich rzadko są „luźne”. Przypominają raczej kontrakt z zestawem hamulców bezpieczeństwa, które trzeba znać i świadomie respektować.

Techniczna możliwość vs prawne prawo użycia

W świecie security częsty błąd to mylenie dwóch faktów: „narzędzie to potrafi” i „ja mogę tak zrobić”. Samo posiadanie możliwości technicznych, aby uruchomić skan na cudzej infrastrukturze, nie tworzy automatycznie prawa, aby to zrobić. Licencja EULA, przepisy karne, regulaminy usługodawców chmurowych oraz umowy z klientami – wszystkie te warstwy nakładają dodatkowe warunki.

Prosty przykład: oprogramowanie do łamania haseł jest w stanie przeciągnąć przez atak słownikowy dowolny plik z hashami. Jednak wiele licencji wprost zastrzega, że:

• możesz z niego korzystać tylko na zbiorach haseł pozyskanych legalnie (np. z własnych systemów),
• nie możesz używać go do odzyskiwania danych osób trzecich bez ich wyraźnej zgody,
• nie wolno sprzedawać usług łamania haseł, jeśli licencja jest wyłącznie „non-commercial”.

Jeśli narzędzie potrafi coś zrobić, ale licencja tego zabrania, to prawnie jesteś w sytuacji podobnej do kierowcy, który ma bardzo szybki samochód, ale jedzie 150 km/h po osiedlu – technicznie da się, ale prawo jest po drugiej stronie.

Krótki scenariusz: skaner podatności odpalony bez zgody

Wyobraźmy sobie konsultanta, który testuje nową wersję skanera podatności i dla „realnych danych” odpala go na infrastrukturze dużego sklepu internetowego, którego nie obsługuje zawodowo. Skan wykonuje się z domowej sieci konsultanta, bez żadnej formalnej zgody właściciela sklepu.

Co się dzieje z punktu widzenia licencji i prawa:

• naruszone mogą być klauzule „authorized use only” – bo nie ma zgody właściciela systemu,
• jeśli skaner obciąży serwery lub spowoduje niedostępność, można mówić o ingerencji w cudzy system (w niektórych krajach – czyn zabroniony),
• dostawca narzędzia ma argument: użytkownik złamał EULA, używając go w sposób wyraźnie zakazany.

Tego typu „niewinne testy” w praktyce często wychodzą na jaw, bo w logach systemów internetowych widać podpis narzędzia, zakres skanowania, adres IP. Wtedy licencja przestaje być abstrakcją – staje się podstawą do oceny, czy działanie mieściło się w granicach umowy.

Podstawowe typy licencji w narzędziach bezpieczeństwa

Komercyjna licencja zamknięta (EULA) – standard w produktach klasy enterprise

Większość komercyjnych skanerów, EDR-ów, narzędzi do DAST/SAST czy platform red teamingowych jest udostępniana na podstawie zamkniętej licencji typu EULA (End User License Agreement). Użytkownik nie otrzymuje prawa do kodu źródłowego, a jedynie ograniczone prawo do korzystania z oprogramowania zgodnie z określonymi warunkami.

Typowe elementy takiej licencji:

• precyzyjne określenie, kto jest „użytkownikiem końcowym” – firma, konsorcjum, konkretny dział,
• opis pola eksploatacji – np. testy wyłącznie na własnych systemach lub także na systemach klientów z pisemną zgodą,
• zakaz dekompilacji, modyfikacji, reverse engineeringu, chyba że prawo lokalne stanowi inaczej,
• ograniczenia terytorialne – zakaz eksportu do niektórych krajów,
• zakaz sublicencjonowania bez zgody producenta.

Przy narzędziach security w EULA często dochodzą dodatkowe zastrzeżenia: brak zgody na użycie „for offensive purposes outside lawful testing”, wymóg respektowania prawa lokalnego i międzynarodowego oraz czasem klauzule o braku wsparcia, jeśli narzędzie było użyte niezgodnie z celem (np. masowy skan Internetu, którego licencja wprost zabrania).

Open source w security – GPL, MIT, Apache, BSD

Narzędzia pentesterskie mają bogatą reprezentację w świecie open source: od skanerów sieciowych, przez frameworki exploitów, po zaawansowane narzędzia do analizy malware. Licencje wolnego i otwartego oprogramowania (FLOSS) dają szeroką swobodę użycia, ale każda z nich wprowadza inny zestaw obowiązków.

Najpopularniejsze rodziny licencji open source w security:

• MIT, BSD, Apache 2.0 – tzw. licencje permiswne; pozwalają na szerokie użycie komercyjne, modyfikacje, łączenie z kodem zamkniętym, przy niewielkiej liczbie obowiązków (np. zachowanie informacji o autorach, dołączenie pliku licencji).
• GPL (GNU General Public License) – licencja copyleft; wymaga udostępnienia kodu źródłowego pochodnych dzieł (jeśli dystrybuujesz zmodyfikowaną wersję lub łączysz narzędzie z innym kodem w jedną całość).
• AGPL (Affero GPL) – rozszerzenie GPL na model sieciowy; obowiązek udostępnienia kodu może powstać nawet wtedy, gdy użytkownik korzysta z narzędzia przez sieć (SaaS), a nie poprzez instalację lokalną.

Samo prowadzenie komercyjnej usługi pentesterskiej z użyciem narzędzi open source (bez ich dystrybucji) z reguły jest dozwolone także pod GPL. Problem pojawia się, gdy budujesz własny produkt (np. platformę testową) oparty o kod GPL i chcesz go dystrybuować jako zamknięty. Wtedy klauzule copyleft mogą wymusić otwarcie kodu – wbrew biznesowym założeniom.

Licencje freemium, trial i community edition – „za darmo”, ale nie „bez ograniczeń”

Wiele firm oferuje narzędzia security w modelu freemium lub w wersjach „community edition”. Kuszą brakiem opłat, ale rekompensują to czasem dość ostrymi ograniczeniami licencyjnymi. Powszechne są zapisy typu:

• „do użytku wyłącznie osobistego i edukacyjnego”,
• „zakaz wykorzystania w usługach komercyjnych, konsultingu i testach świadczonych na rzecz klientów”,
• „limit liczby hostów/IP do skanowania”,
• „brak odpowiedzialności i wsparcia technicznego dla wersji bezpłatnej”.

W kontekście usług pentesterskich kluczowe jest rozróżnienie: kto jest beneficjentem użycia narzędzia. Jeśli wykorzystujesz wersję community, aby za darmo sprawdzić własne zasoby, zwykle mieści się to w licencji. Gdy jednak używasz jej do projektu komercyjnego dla klienta, łatwo przekroczyć granicę „non-commercial use”, nawet jeśli sam nie pobierasz dodatkowej opłaty bezpośrednio za to narzędzie.

Licencje edukacyjne i non-commercial w cyberbezpieczeństwie

Narzędzia security często mają osobne edycje dla uczelni, laboratoriów trainingowych i indywidualnych pasjonatów. Charakterystyczne ograniczenia takich licencji:

• zakaz używania w środowiskach produkcyjnych (np. można używać w labie studenckim, ale nie w realnej infrastrukturze firmy),
• zakaz świadczenia usług na rzecz osób trzecich, jeśli opierają się one na tym narzędziu,
• wymóg powiązania z programem nauczania lub kursem certyfikującym,
• czasowe ograniczenia – licencja ważna np. tylko przez czas trwania kursu lub roku akademickiego.

Zdarza się, że konsultanci próbują używać licencji edukacyjnych do realizacji płatnych zleceń. Nawet jeśli dostawca nie zauważy tego od razu, w razie audytu licencyjnego lub sporu z klientem taki manewr jest bardzo trudny do obrony. Wystarczy, że klient zażąda dowodu legalności używanych narzędzi, a dostawca potwierdzi, iż licencja edukacyjna nie obejmuje działalności komercyjnej.

Zakres dozwolonego użycia – kluczowe klauzule w licencjach security

„Authorized use only” i „lawful use only” – sens praktyczny

Dwie frazy występują w licencjach narzędzi pentesterskich wyjątkowo często: „authorized use only” oraz „lawful use only”. Brzmią ogólnie, ale w praktyce wiele znaczą.

„Authorized use only” oznacza, że możesz korzystać z narzędzia wyłącznie wobec systemów i danych, do których masz odpowiednie upoważnienie. W security oznacza to zwykle:

• pisemną zgodę właściciela systemu na przeprowadzenie testów,
• umowę z klientem, która precyzyjnie określa zakres testów (zakres IP, aplikacje, okna czasowe),
• w dużych organizacjach – wewnętrzne upoważnienia (np. od właściciela aplikacji lub działu IT).

„Lawful use only” to z kolei zastrzeżenie, że narzędzie ma być używane wyłącznie w sposób zgodny z prawem krajowym i międzynarodowym. Dostawca sygnalizuje: nie bierzemy odpowiedzialności za to, że w twoim kraju pewne działania są penalizowane; musisz to sam sprawdzić. To ważne zwłaszcza w projektach transgranicznych, kiedy zespół pentesterski działa z innego państwa niż infrastruktura klienta.

Zakaz użycia „malicious” lub „offensive” – a co z red teamingiem?

Wiele licencji narzędzi security zawiera sformułowania w stylu „You shall not use the Software for any malicious, offensive or illegal purposes”. Na pierwszy rzut oka wydaje się to sprzeczne z naturą red teamingu, który symuluje „offensive operations”. Kluczowy jest jednak kontekst, w jakim rozumiane są te słowa.

Producenci w praktyce rozróżniają:

• działania ofensywne w środowisku kontrolowanym i na podstawie zgody – typowy red teaming lub testy penetracyjne,
• działania ofensywne bez zgody właściciela systemu lub niezgodne z prawem – klasyczne „malicious use”.

Red teaming mieszczący się w granicach umowy i przepisów zazwyczaj nie jest traktowany jako „malicious use”, nawet jeśli technicznie wygląda jak atak. Jednak niektóre licencje zastrzegają wprost, że „offensive security testing” jest dozwolone tylko w określonych scenariuszach (np. na własnej infrastrukturze lub u klientów z podpisanym kontraktem). W takim przypadku warto przechować kopię licencji i korespondencję z producentem, jeśli pojawia się jakakolwiek wątpliwość interpretacyjna.

Typy celów objęte lub wyłączone z licencji

Przy narzędziach security licencje nierzadko różnicują dozwolone użycie w zależności od rodzaju testowanych systemów. Spotyka się między innymi:

• dozwolenie testów tylko na własnej infrastrukturze licencjobiorcy (brak prawa świadczenia usług na rzecz osób trzecich),
• konieczność odrębnej zgody producenta na użycie w instytucjach publicznych, systemach rządowych lub infrastrukturze krytycznej,

Ograniczenia branżowe i sektorowe

Przy bardziej wrażliwych sektorach pojawiają się klauzule, które same w sobie są „filtrami” dla klientów. Niektóre narzędzia security są objęte ograniczeniami eksportowymi (np. z uwagi na klasyfikację kryptografii), inne – wymagają specjalnej zgody producenta przy wdrożeniach w obszarach wrażliwych.

Przykładowo licencja może zawierać postanowienia, że użycie oprogramowania wymaga osobnego uzgodnienia, jeśli dotyczy:

• podmiotów z sektora zbrojeniowego lub obronnego,
• operatorów infrastruktury krytycznej (energetyka, telekomunikacja, wodociągi),
• instytucji finansowych podlegających restrykcyjnym regulacjom (np. banków państwowych),
• podmiotów znajdujących się na listach sankcyjnych lub w państwach objętych embargiem.

W praktyce może to oznaczać, że firma pentesterska nie może po prostu „przenieść” swojej licencji z komercyjnego klienta do projektu dla instytucji rządowej. Producent zastrzega sobie prawo do weryfikacji takiego wdrożenia, czasem dodaje też inne warunki – np. wymóg wykorzystania konkretnej chmury lub zakaz przenoszenia danych poza określony region.

Warto przed dużym przetargiem lub projektem dla sektora publicznego sprawdzić, czy licencja nie wymaga dodatkowych uzgodnień. Zdarzają się sytuacje, w których dostawca po prostu odmawia udostępnienia narzędzia do niektórych zastosowań, aby nie ryzykować konfliktu z przepisami eksportowymi swojego kraju.

Symulacja malware a ograniczenia „dual use”

Narzędzia używane do budowy payloadów, exploitów czy symulacji malware bywają traktowane jako tzw. technologie „dual use” – mogą służyć zarówno obronie, jak i atakowi. To odbija się w licencjach.

Spotykane są m.in. klauzule:

• zakazujące użycia narzędzia do tworzenia malware przeznaczonego do dystrybucji „na wolności”, nawet w celach badawczych,
• ograniczające użycie do „kontrolowanych środowisk” (sandbox, lab, sieć testowa),
• wymagające, aby wszystkie wygenerowane artefakty (np. próbki malware) były przechowywane w odseparowanej infrastrukturze.

W komercyjnych red teamach czy Purple Teaming takie klauzule są szczególnie istotne. Jeśli scenariusz obejmuje budowę niestandardowych ładunków, licencja może wręcz wymagać pisemnego rozszerzenia zakresu albo nowszej wersji licencji. Producenci bronią się w ten sposób przed zarzutem „ułatwiania cyberprzestępczości”.

Liczba użytkowników, stanowisk i środowisk – klauzule ilościowe

Model „per user”, „per seat”, „per tester”

Najprostsza intuicja: ilu ludzi faktycznie korzysta z narzędzia? Tu zaczyna się cała zabawa z definicjami. Ten sam zapis „user” może oznaczać w różnych licencjach coś innego.

Najczęstsze warianty:

• Named user – imiennie wskazana osoba (np. konkretny pentester). Licencja jest przypisana do człowieka, czasem z możliwością ograniczonej liczby „przepisania” rocznie (np. przy rotacji kadry).
• Concurrent user – liczy się liczba jednocześnie zalogowanych użytkowników. Zespoły lubią ten model, bo można mieć więcej kont niż licencji, byle nie przekroczyć limitu równoczesnych sesji.
• Per tester/consultant – pojęcie zbliżone do named user, ale powiązane z rolą (osoba faktycznie prowadząca testy). Może wykluczać np. analityków, którzy tylko przeglądają raporty.

Przy projektach z doskoku, gdzie w jednym tygodniu narzędzie używa pięć osób, a w następnym dwie inne, warto sprawdzić, czy licencja pozwala na taką „karruzelę” użytkowników. Zdarzają się klauzule zakazujące częstych zmian przypisania licencji, aby uniemożliwić obejście modelu per seat.

Licencje „per installation” i „per device”

Drugi poziom to kwestia: na ilu maszynach narzędzie faktycznie działa. W security rzadko kończy się na jednym laptopie – są maszyny skanujące w DMZ, jump hosty, czasem dedykowane appliance’y.

Popularne podejścia:

• Per device – każda instalacja na fizycznym lub wirtualnym urządzeniu wymaga osobnej licencji, niezależnie od liczby użytkowników.
• Per scanner/engine – licencjonowane są „silniki” skanujące, które można potem kontrolować z centralnej konsoli.
• Per appliance – licencja przypisana do konkretnego urządzenia dostarczanego przez producenta, z ograniczoną możliwością przeniesienia.

W praktyce dochodzi do sporów, czy np. 10 maszyn wirtualnych uruchamianych kolejno na jednym hypervisorze to „jedno urządzenie” czy „10 instalacji”. Czasami licencja zawiera szczegółowe definicje instancji, gniazda CPU, rdzeni – zwłaszcza tam, gdzie wydajność ma duży wpływ na cenę.

Środowiska: produkcyjne, testowe, labowe

Bezpieczeństwo niemal zawsze testuje się w kilku środowiskach. Dostawcy licencji bardzo chętnie różnicują je cenowo i formalnie.

Spotyka się np. konstrukcje:

• jedna licencja produkcyjna + jedna testowa „gratis”,
• pełnoprawna licencja produkcyjna, ale środowiska labowe tylko do użytku wewnętrznego (bez usług dla klientów),
• tanie licencje „non-production” z zastrzeżeniem, że nie mogą brać udziału w komercyjnych projektach pentesterskich.

Dla firm konsultingowych kluczowe jest rozróżnienie, czy testy prowadzone w labie na rzecz zewnętrznego klienta są już traktowane jako „produkcja” w rozumieniu licencji. Wenn dostawca odpowie „tak” – potrzebna jest pełna licencja, nawet jeśli środowisko to tylko symulacja.

Ograniczenia skali: liczba hostów, aplikacji, zasobów

Duża część narzędzi security licencjonowana jest nie według ludzi, ale według tego, co analizują – hostów, adresów IP, aplikacji, zasobów chmurowych.

Najczęstsze parametry ilościowe:

• liczba unikalnych IP lub hostów skanowanych w zadanym okresie,
• liczba aplikacji webowych przypisanych do licencji,
• liczba assetów chmurowych (kont, subskrypcji, klastrów),
• próg przepustowości (np. maksymalna liczba żądań na godzinę) przy skanerach w modelu SaaS.

Przy testach u wielu klientów łatwo nieświadomie przekroczyć limit – szczególnie w modelach subskrypcyjnych, gdzie liczy się „łączna liczba obiektów w miesiącu”. Niektórzy producenci tolerują okazjonalne skoki, inni naliczają opłaty dodatkowe lub żądają podniesienia planu licencyjnego.

Klauzule odpowiedzialności, odszkodowań i ograniczenia ryzyka

Ograniczenie odpowiedzialności dostawcy („limitation of liability”)

W narzędziach security skutki błędu bywają kosztowne: fałszywie negatywny wynik skanu, źle zaimplementowany agent EDR, który blokuje krytyczny proces, czy nieudany exploit, który zawiesza serwer produkcyjny. Nic dziwnego, że licencje bardzo mocno tną odpowiedzialność producenta.

Standardowe klauzule obejmują:

• ograniczenie maksymalnej odpowiedzialności finansowej do wysokości zapłaconych opłat licencyjnych z ostatniego okresu (np. 12 miesięcy),
• wyłączenie odpowiedzialności za tzw. szkody pośrednie (utracone zyski, utratę renomy, kary regulacyjne),
• brak odpowiedzialności za szkody wynikające z użycia niezgodnego z dokumentacją lub licencją.

Dla użytkownika oznacza to tyle, że w razie poważnego incydentu wywołanego przez narzędzie security, odzyskanie pełnych kosztów od producenta jest najczęściej mało realne. Zespół pentesterski, który korzysta z danego narzędzia, pozostaje pierwszym adresatem roszczeń klienta – niezależnie od tego, co „psuje się” pod spodem.

Wyłączenie odpowiedzialności za zgodność z przepisami

Coraz częściej narzędzia security są reklamowane jako „pomoc w spełnieniu wymogów RODO, NIS2, PCI DSS”. W licencjach jednocześnie pojawia się wyraźne zastrzeżenie, że producent nie gwarantuje zgodności z jakimkolwiek standardem czy regulacją.

Typowy zapis głosi, że narzędzie jedynie wspiera procesy compliance, ale końcowa odpowiedzialność za ich poprawne zaprojektowanie i wdrożenie spoczywa na kliencie. W projektach pentesterskich trzeba to jasno komunikować – raport z testów nie „robi” zgodności z normą, jedynie dostarcza dane do dalszych decyzji. Zbyt odważne obietnice handlowe mogą potem boleśnie zderzyć się z treścią licencji.

Klauzule odszkodowawcze („indemnification”)

Klauzule indemnifikacyjne to wyższa szkoła jazdy prawniczej, ale mają bardzo praktyczny wymiar. Najczęściej dotyczą dwóch scenariuszy:

• roszczeń stron trzecich z tytułu naruszenia praw własności intelektualnej (np. ktoś twierdzi, że narzędzie narusza jego patent),
• roszczeń wynikających z nielegalnego użycia narzędzia przez licencjobiorcę.

W pierwszym przypadku producent często zobowiązuje się do obrony klienta i pokrycia kosztów, jeśli pojawi się pozew związany z IP. W zamian oczekuje jednak ścisłej współpracy i natychmiastowego powiadomienia o roszczeniu. W drugim – sytuacja się odwraca. To klient (np. firma pentesterska) ma chronić producenta przed konsekwencjami swojego nielegalnego użycia narzędzia.

Jeżeli zespół wykorzysta narzędzie niezgodnie z licencją – na przykład do skanowania infrastruktury bez zgody – producent będzie się powoływał właśnie na taką klauzulę. Kolejny powód, by jasno rozdzielać odpowiedzialności w umowach z klientami i dokumentować zgody na testy.

„Use at your own risk” i brak gwarancji rezultatów

Licencje narzędzi security praktycznie zawsze zawierają rozbudowane zastrzeżenie, że:

• oprogramowanie dostarczane jest „as is” (w stanie, w jakim się znajduje),
• producent nie udziela gwarancji, że narzędzie wykryje wszystkie podatności lub że testy nie wywołają skutków ubocznych,
• odpowiedzialność za konfigurację, dobór scenariuszy i interpretację wyników spoczywa na użytkowniku.

Dla praktyków bezpieczeństwa brzmi to brutalnie, ale uczciwie. Żadne narzędzie nie da 100% pewności, a agresywne skanowanie zawsze niesie ryzyko zakłóceń. Zespół pentesterski powinien mieć własne procedury oceny ryzyka i akceptacji skutków potencjalnych testów – licencja producenta tego nie zastąpi.

Dane, logi i prywatność – klauzule przy modelu SaaS

Zakres przetwarzanych danych i cel ich użycia

Narzędzia security w modelu SaaS widzą często znacznie więcej niż tradycyjne aplikacje: ruch sieciowy, konfigurację systemów, niekiedy nawet fragmenty danych produkcyjnych. Licencja i regulamin usługi opisują, co dzieje się z tym materiałem.

Typowe elementy to:

• katalog kategorii danych – logi, metadane, zrzuty konfiguracji, próbki malware,
• cele przetwarzania – świadczenie usługi, rozwój produktu (np. trening modeli detekcji), statystyki,
• zasady anonimizacji lub pseudonimizacji – czy dane operacyjne są używane dalej w formie możliwej do powiązania z klientem.

Jeśli narzędzie ma dostęp do danych osobowych, zwykle konieczna jest dodatkowa umowa powierzenia przetwarzania (DPA). Niekiedy dostawca wręcz zastrzega, że usługa nie jest przeznaczona do użycia na danych osobowych lub danych szczególnie chronionych. W security bywa to trudne do spełnienia, więc ważne jest ustalenie, czy choćby fragmenty danych produkcyjnych mogą trafić do chmury.

Lokalizacja danych i transfer poza EOG

Przy usługach chmurowych prawie zawsze pojawia się pytanie: gdzie fizycznie leżą dane i logi? Licencje i umowy serwisowe coraz częściej zawierają sekcje o lokalizacji centrów danych oraz mechanizmach legalnego transferu (np. standardowe klauzule umowne UE).

Kluczowe elementy to:

• wykaz regionów, w których mogą być przechowywane dane,
• informacja, czy dane mogą być rutynowo kopiowane poza EOG (np. na potrzeby wsparcia technicznego),
• możliwość wyboru regionu lub wyłączenia niektórych lokalizacji.

Przy projektach dla sektora publicznego lub regulowanego (np. bankowość) niekiedy konieczne jest utrzymanie logów wyłącznie w określonym kraju. Część dostawców oferuje specjalne warianty usługi („EU-only”, „government cloud”), ale są one zwykle droższe i mają oddzielne warunki.

Logi, telemetryka i „improvement of services”

Automatyczne zbieranie danych a trenowanie modeli bezpieczeństwa

Dostawcy usług security w chmurze intensywnie wykorzystują automatycznie zbierane dane – nie tylko do obsługi konkretnego klienta, lecz także do „uczenia” swoich mechanizmów detekcji. Dla użytkownika brzmi to dobrze, bo system z czasem staje się skuteczniejszy, ale od strony licencji pociąga za sobą szereg konsekwencji.

W regulaminach często pojawiają się zapisy, że:

• dostawca może przetwarzać logi i metadane w celu ulepszania algorytmów,
• dane mogą być agregowane z innymi klientami i używane do tworzenia „threat intelligence” (baz sygnatur, wskaźników ataków, wzorców zachowań),
• tak przetworzone informacje nie są już traktowane jako dane klienta, lecz jako dane pochodne dostawcy.

W praktyce oznacza to, że dostawca buduje swój know‑how także na bazie ataków i incydentów, które dotykają twoje środowisko. Nie jest to nic niezwykłego, ale w sektorach wrażliwych (np. administracja publiczna, infrastruktura krytyczna) bywa przedmiotem osobnych negocjacji: jak daleko może sięgać anonimizacja, czy możliwe jest wyłączenie danych z „globalnych” modeli, jak długo przechowywane są próbki malware.

Przy wdrożeniach pentesterskich warto doprecyzować, czy dane z kampanii testowej też mogą zasilać takie modele. Dla dostawcy to cenne, bo symulowane ataki często są bardziej „kreatywne” niż przeciętna kampania malware, ale klient końcowy może nie chcieć, aby szczegóły jego architektury pośrednio trafiły do globalnych baz.

Dostęp do danych przez podwykonawców i wsparcie techniczne

W SaaS‑ach security mało która firma działa całkowicie samodzielnie. Pod spodem są dostawcy chmury, podwykonawcy od monitoringu 24/7, firmy obsługujące zgłoszenia supportowe. Licencje i umowy serwisowe regulują, kto i na jakich zasadach może dotykać twoich logów.

Najczęściej spotykane elementy to:

• lista kategorii podwykonawców (np. operator chmury, SOC jako usługa, podmiot realizujący analizy malware),
• zasada „need to know” – dostęp do danych tylko, gdy jest niezbędny do realizacji usługi lub wsparcia,
• obowiązek objęcia podwykonawców tym samym reżimem poufności co główną umowę.

W kontekście testów penetracyjnych może się okazać, że inżynier wsparcia po drugiej stronie globu ma wgląd w szczegółowe payloady exploitów i strukturę testowanych aplikacji. Zdarza się, że wrażliwe projekty (np. dla wojska) wprowadzają dodatkowe klauzule – wsparcie tylko z określonych jurysdykcji, brak zdalnego dostępu do niezanonimizowanych logów czy obowiązek prowadzenia wsparcia wyłącznie przez personel przetestowany bezpieczeństwem (background check).

Czas przechowywania, usuwanie i eksport danych

Logi security są złotem – pomagają w dochodzeniu incydentów, ale jednocześnie ich nadmiar bywa obciążeniem prawnym. Regulacje ochrony danych oraz standardy branżowe wymuszają świadome zarządzanie retencją, co licencje i regulaminy SaaS próbują ująć w ramy.

Typowo spotyka się:

• z góry określony okres retencji (np. 30, 90, 365 dni) w zależności od planu subskrypcyjnego,
• mechanizm automatycznego usuwania lub archiwizacji po przekroczeniu limitu,
• zapis, że po zakończeniu umowy dane są usuwane w określonym czasie, ale część informacji zanonimizowanych może pozostać w systemach dostawcy.

Przy projektach pentesterskich kluczowa jest jeszcze jedna rzecz: możliwość eksportu danych przed ich skasowaniem. Raport główny to jedno, a surowe logi, PCAP‑y czy artefakty z analiz to drugie. Jeżeli licencja ogranicza możliwość pobierania całości danych (np. tylko przez API z limitami), może to utrudnić późniejszą analizę incydentów, które wyjdą na jaw długo po zakończeniu testów.

Rozsądna praktyka to wpisanie w umowę projektu krótkiego „okna bezpieczeństwa” po testach, kiedy dane jeszcze pozostają w SaaS, ale równolegle są sukcesywnie kopiowane do wewnętrznego repozytorium klienta w uzgodnionym formacie.

Udostępnianie danych w ramach „community” i threat intelligence

Część narzędzi bezpieczeństwa oferuje funkcje społecznościowe: współdzielone listy IOC (indicator of compromise), reputacje adresów IP, reputacje domen, a nawet bazy reguł przygotowywane przez użytkowników. To realnie podnosi poziom ochrony, ale jednocześnie rodzi pytanie, co dokładnie staje się „wspólnym zasobem”.

W licencjach wielokrotnie pojawiają się zapisy, że dostawca może:

• wykorzystywać wybrane dane (np. hashe plików, adresy IP atakujących, domeny C&C) do globalnych źródeł threat intelligence,
• publikować zagregowane informacje o kampaniach ataków bez ujawniania tożsamości klienta,
• udostępniać część takich danych partnerom i innym klientom.

Problem zaczyna się wtedy, gdy z pozornie anonimowych danych da się odtworzyć konkretnego klienta – np. po unikalnej strukturze subdomen lub rzadkim stosie technologii. W projektach pentesterskich, gdzie symuluje się zaawansowanych atakujących, nawet sama informacja, że „ktoś” testował daną kombinację wektorów, może być wrażliwa biznesowo.

Jeżeli projekt dotyczy infrastruktury klienta o wysokim profilu, czasem rozsądniejsze jest wyłączenie udziału w „community feeds” dla danego tenant’a albo wykorzystanie oddzielnego środowiska testowego bez realnych domen i adresów IP.

Open source w pentestach – swobody i pułapki licencji FLOSS

Dlaczego licencja open source to wciąż licencja

Narzędzia open source są fundamentem współczesnych pentestów: od klasyków typu Nmap i Metasploit, po wyspecjalizowane frameworki do red teamingu i testów aplikacji webowych. Poczucie „darmowości” bywa jednak zgubne. Fakt, że kod jest dostępny, nie oznacza dowolności użycia w każdym modelu komercyjnym.

Licencje open source przyznają szerokie swobody, ale jednocześnie stawiają określone warunki – od obowiązku zachowania informacji o autorach, przez udostępnianie zmian, po ograniczenia dotyczące łączenia z kodem o zamkniętym źródle. Przy projektach pentesterskich staje się to istotne, gdy narzędzie jest intensywnie modyfikowane lub integrowane z własną platformą usługową.

„Permissive” vs „copyleft” – co to oznacza dla zespołu security

Intuicyjny podział licencji open source to dwa główne obozy: permissive (bardziej elastyczne) i copyleft (z bardziej rygorystycznym podejściem do dzielenia się zmianami).

Licencje permissive – takie jak MIT, BSD czy Apache 2.0 – w praktyce pozwalają:

• używać kodu w dowolnych zastosowaniach, także komercyjnych i zamkniętych,
• modyfikować narzędzia i nie udostępniać zmian publicznie (o ile spełni się warunki dotyczące informacji o licencji i autorach),
• dołączać fragmenty kodu do własnego oprogramowania jako komponenty.

Licencje copyleft – przede wszystkim różne warianty GPL – stawiają ostrzejsze wymagania:

• jeżeli zmodyfikujesz program objęty GPL i będziesz go dystrybuować, musisz udostępnić kod zmian na tej samej licencji,
• łączenie kodu GPL z zamkniętymi komponentami aplikacji może wymusić otwarcie całości (zależnie od sposobu integracji),
• część społeczności interpretuje „udostępnienie jako usługa” (SaaS) jako obejście intencji GPL, co doprowadziło do powstania licencji AGPL rozszerzającej obowiązek udostępnienia kodu także przy świadczeniu usługi przez sieć.

Dla typowego pentestera używającego gotowego narzędzia „z półki” zwykle nie ma to większego znaczenia – nie następuje formalna dystrybucja. Problem pojawia się, gdy firma security zaczyna budować własną platformę testową w chmurze i oferuje ją jako usługę wielu klientom, korzystając głęboko z komponentów GPL lub AGPL.

AGPL i „SaaS jako dystrybucja” w środowisku pentesterskim

AGPL (Affero GPL) powstała po to, aby „zamknąć lukę” w klasycznym GPL, gdzie kod mógł być modyfikowany i używany jako usługa webowa bez obowiązku publikowania zmian. Dla dostawców narzędzi security w modelu SaaS ma to bardzo konkretne skutki.

Jeżeli platforma pentesterska opiera się na komponentach AGPL, to użytkownicy uzyskują prawo do wglądu w kod źródłowy samego komponentu oraz jego modyfikacji – nawet jeżeli nigdy nie pobierają binariów, a jedynie korzystają z usługi online. W praktyce wiele firm stara się unikać AGPL w komercyjnych ofertach, chyba że świadomie przyjmują model „otwartej” platformy.

Od strony licencyjnej istotne jest też to, jak głęboka jest integracja. Użycie narzędzia AGPL jako oddzielnego procesu wywoływanego skryptem (np. przez CLI, jak klasyczny skaner linii komend) jest zwykle mniej problematyczne niż łączenie biblioteki AGPL bezpośrednio w kodzie serwera aplikacyjnego. Granica nie zawsze jest oczywista, stąd w większych organizacjach nad tego typu kwestiami czuwa dział compliance open source, a nie sam zespół pentesterski.

Narzędzia dual‑licencjonowane i „community vs enterprise”

Coraz częściej twórcy narzędzi security rozwijają projekt open source, a równolegle oferują płatną wersję „enterprise” z dodatkowymi funkcjami lub wsparciem. Z prawnego punktu widzenia oznacza to dwie (lub więcej) różne licencje na pozornie to samo narzędzie.

Popularne modele obejmują:

• rdzeń narzędzia na licencji copyleft (np. GPL), rozszerzenia komercyjne na licencji zamkniętej,
• wersja community na licencji open source, wersja enterprise na licencji własnościowej, mimo wspólnej bazy kodu,
• „czasowe” licencje open source: nowe funkcje są przez pewien czas dostępne tylko w wersji płatnej, po czym trafiają do gałęzi otwartej.

W praktyce zespół pentesterski powinien jasno ustalić, z której gałęzi korzysta i jakie są warunki. Zdarza się, że w projektach RFP lub przetargach klient oczekuje wskazania, czy używane narzędzia są objęte płatnym wsparciem producenta. Sam fakt, że narzędzie ma komercyjną wersję, nie oznacza jeszcze, że posiadasz do niej licencję – a nieporozumienia na tym tle bywają bolesne przy incydentach.

Obowiązki informacyjne i atrybucja w raportach

Wielu pentesterów korzysta równolegle z kilkunastu narzędzi open source i nie zastanawia się, czy ma z tego powodu jakiekolwiek dodatkowe obowiązki. W klasycznych licencjach permissive głównym wymogiem jest zachowanie informacji o autorach i licencji w kodzie i dokumentacji.

W kontekście usług pentesterskich pojawiają się jednak dodatkowe pytania:

• czy w raportach należy wskazywać konkretne narzędzia i ich licencje,
• czy można usunąć z interfejsu informacje o autorach przy budowie zautomatyzowanych dashboardów opartych o open source,
• czy klient ma prawo żądać listy komponentów (tzw. SBOM – software bill of materials) użytych przy testach.

Większość licencji FLOSS nie wymusza ujawniania takich szczegółów w raportach, ale bywa to wymagane w umowach z klientami z sektora regulowanego. Dla zespołu pentesterskiego oznacza to dodatkową papierkologię: inwentaryzację narzędzi, zapis wersji, śledzenie zmian licencji. W zamian jednak łatwiej udokumentować, że użyte oprogramowanie ma legalne pochodzenie — co z kolei zmniejsza ryzyko sporów przy audytach.

Łączenie narzędzi open source z własnym know‑how

Firma pentesterska często dodaje nad narzędziami open source własną warstwę: skrypty automatyzujące, gotowe scenariusze ataków, autorskie słowniki, integracje z systemami ticketowymi. To właśnie ta warstwa bywa głównym „produktem” – narzędzia są tylko silnikami pod spodem.

Z licencyjnego punktu widzenia trzeba rozstrzygnąć, czy:

• ta warstwa jest jedynie konfiguracją/automatyzacją (i może pozostać zamknięta),
• czy powstaje dzieło zależne od komponentów copyleft, które pociąga za sobą obowiązki udostępnienia kodu.

Przykładowo: zbiór autorskich skryptów, które wywołują narzędzie GPL z linii komend i przetwarzają wyniki, zwykle może być licencjonowany dowolnie. Natomiast modyfikacja wewnętrznych modułów narzędzia i wbudowanie ich w własny framework webowy może oznaczać już konieczność otwarcia całości. Granica jest techniczna, ale niesie poważne skutki biznesowe, dlatego przy większych projektach sensowne jest zaangażowanie prawnika znającego zarówno licencje FLOSS, jak i praktykę security.

Zabronione zastosowania także w open source

Najczęściej zadawane pytania (FAQ)

Czy mogę legalnie używać narzędzi pentesterskich bez pisemnej zgody właściciela systemu?

Technicznie prawie zawsze się da, ale prawnie to proszenie się o kłopoty. Bez wyraźnej zgody właściciela systemu skanowanie, fuzzowanie czy próby exploitacji mogą być potraktowane jak atak, a nie test bezpieczeństwa – nawet jeśli robisz to „dla dobra sprawy”.

Większość licencji na narzędzia security zawiera klauzule typu „authorized use only” lub „lawful use only”. Łamiąc je, jednocześnie naruszasz umowę licencyjną i ryzykujesz odpowiedzialność karną lub cywilną. Minimalny standard to zgoda w formie pisemnej (mail, ticket, umowa), opis zakresu testów i zdefiniowane ramy czasowe.

Czym różni się techniczna możliwość użycia narzędzia od prawnego prawa do jego użycia?

Narzędzie „umie” coś zrobić, bo tak zostało zaprojektowane – to poziom techniczny. Prawo do użycia tej funkcji wynika z licencji, przepisów karnych, regulaminów usług (np. chmury) oraz umów z klientami – to zupełnie inny poziom.

Przykład: narzędzie do łamania haseł bez problemu przyjmie dowolny plik z hashami. Ale licencja może zastrzegać, że wolno go używać wyłącznie na danych pozyskanych legalnie, z własnych systemów albo za zgodą posiadacza kont. Jeśli zignorujesz ten warunek, jesteś w sytuacji kierowcy jadącego 150 km/h po osiedlu – samochód może, ale prawo jest przeciwko tobie.

Czy narzędzia security na licencji open source (GPL, MIT itp.) mogę wykorzystywać komercyjnie?

W większości przypadków tak. Samo świadczenie płatnych usług pentesterskich przy użyciu open‑source’owych narzędzi (bez ich dalszej dystrybucji) jest dopuszczalne zarówno przy licencjach permiswnych (MIT, BSD, Apache), jak i copyleft (GPL, AGPL). Zarabiasz na usłudze, nie na samym programie.

Ostrożność jest potrzebna, gdy budujesz własny produkt oparty na takim narzędziu. Licencje copyleft (GPL, AGPL) mogą wymagać udostępnienia kodu źródłowego twoich modyfikacji lub całego połączonego dzieła. Licencje permiswne są pod tym względem znacznie łagodniejsze – zwykle wystarczy zachować informację o autorach i dołączyć plik licencji.

Czy wersje „community”, trial i freemium narzędzi pentesterskich mogę stosować w płatnych projektach?

Często nie. Wiele „darmowych” edycji ma w licencji jednoznaczny zakaz użycia komercyjnego, konsultingu czy świadczenia usług bezpieczeństwa na rzecz klientów. Darmowa wersja bywa przeznaczona wyłącznie do celów osobistych, edukacyjnych albo testów wewnętrznych w organizacji.

Przed wykorzystaniem takiego narzędzia w projekcie komercyjnym trzeba sprawdzić sekcje „Permitted use” lub „Restrictions” w licencji. Typowe ograniczenia to: limit wielkości skanowanych środowisk, zakaz użycia w ramach usług dla osób trzecich, brak prawa do integracji z komercyjną platformą. Ignorowanie tych zapisów może oznaczać łamanie licencji nawet wtedy, gdy z technicznego punktu widzenia wszystko działa.

Jakie klauzule w licencjach oprogramowania security są najbardziej ryzykowne do zignorowania?

Najczęściej problematyczne są zapisy, które użytkownicy traktują jako „formalność”, a mają realne skutki prawne. W narzędziach pentesterskich są to zwłaszcza:

• klauzule „lawful use only / no malicious use” – zakaz użycia w sposób sprzeczny z prawem lub do ataków ofensywnych poza legalnym testem,
• „authorized use only” – wymóg posiadania zgody właściciela testowanego systemu,
• ograniczenia terytorialne i eksportowe – zakaz użycia w niektórych krajach lub dla określonych podmiotów,
• zakaz świadczenia usług komercyjnych przy licencjach oznaczonych jako „non‑commercial” lub „personal use only”.

Naruszenie takich zapisów to nie tylko złamanie umowy z producentem. W razie incydentu dostawca narzędzia może łatwo wskazać, że działałeś wbrew licencji, a odpowiedzialność spada wyłącznie na ciebie lub twoją firmę.

Czy producent narzędzia odpowiada za to, że ktoś użyje go do włamania?

Licencje oprogramowania security są pisane tak, by tę odpowiedzialność maksymalnie ograniczyć. Powszechne są klauzule wyłączające gwarancję („as is”), limitujące wysokość ewentualnych odszkodowań oraz wprost stwierdzające, że dostawca nie ponosi odpowiedzialności za skutki użycia narzędzia w sposób niezgodny z prawem lub licencją.

W praktyce, jeśli ktoś wykorzysta legalne narzędzie pentesterskie do nielegalnego ataku, producent pokaże zapisy licencji: zakaz złośliwego użycia, wymóg posiadania zgody, obowiązek respektowania lokalnego prawa. To jeden z powodów, dla których te klauzule są tak wyraźne i często powtarzane w dokumentacji.

Jak udokumentować legalne użycie narzędzia pentesterskiego, żeby być „krytym” licencyjnie?

Najbezpieczniej jest mieć spójny pakiet dokumentów: umowę z klientem opisującą zakres testów, pisemną zgodę właściciela systemów (lub odpowiedni zapis w kontrakcie), uzgodnione okno czasowe oraz procedurę reagowania na incydenty. Warto też zachować korespondencję mailową czy zgłoszenia w systemie ticketowym, które potwierdzają, że druga strona wiedziała o testach.

Dodatkowo dobrze jest udokumentować, że korzystasz z narzędzia w zgodzie z licencją: wewnętrzne procedury, lista wykorzystywanych narzędzi z ich typem licencji, ewentualne szkolenia zespołu z zasad „lawful use only”. W razie sporu taka „papierologia” staje się silnym argumentem, że działanie rzeczywiście było testem bezpieczeństwa, a nie nieuprawnionym atakiem.

Najważniejsze wnioski

• Narzędzia security i pentesterskie to typowe „narzędzia podwójnego zastosowania” – technicznie pozwalają na legalne testy, ale w tych samych scenariuszach mogą ułatwiać przestępcze włamania, dlatego licencje są znacznie bardziej restrykcyjne niż przy zwykłym oprogramowaniu biurowym.
• Dostawcy zaostrzają klauzule licencyjne, aby ograniczyć ryzyko nadużyć, chronić swój wizerunek, minimalizować odpowiedzialność cywilną („as is”, limity odszkodowań) i spełnić wymogi regulacji eksportowych dotyczących narzędzi dual-use.
• Kluczowe jest rozróżnienie między tym, co narzędzie „potrafi technicznie”, a tym, co użytkownik „ma prawo zrobić” – o legalności decydują licencja, prawo karne, umowy z klientami i regulaminy usług (np. chmurowych), a nie sama funkcjonalność programu.
• Typowe ograniczenia licencyjne obejmują wymóg działania wyłącznie na systemach, do których ma się formalną zgodę, zakaz użycia w celach ofensywnych poza legalnym testowaniem, zakaz odzyskiwania danych osób trzecich bez ich zgody oraz zakaz komercyjnego świadczenia usług, gdy licencja jest „non‑commercial”.
• Scenariusz „testów na żywym organizmie” bez zgody (np. skanowanie sklepu internetowego z domowego łącza) może naruszać klauzule „authorized use only”, podpadać pod ingerencję w cudzy system i jednocześnie dawać producentowi podstawę do stwierdzenia, że użytkownik złamał EULA.