Bezpieczeństwo w pracy z AI: automatyzacje i agenty — Transcript

Lekcja o bezpieczeństwie pracy z AI, automatyzacjach i agentach AI, z praktycznymi poradami dotyczącymi ochrony kluczy API i zapobiegania atakom.

Key Takeaways

Bezpieczne zarządzanie kluczami API to podstawa ochrony danych i środków.
Self-hosted narzędzia zmniejszają ryzyko ataków, ale wymagają odpowiedniej administracji.
Zasada najmniejszych przywilejów i allowlisty IP znacząco podnoszą bezpieczeństwo.
Wielowarstwowa ochrona (defense in depth) jest konieczna przeciw atakom finansowym.
Monitorowanie i limitowanie zużycia API pomaga uniknąć niekontrolowanych kosztów.

Summary

Omówienie bezpieczeństwa zaawansowanych rozwiązań AI i integracji z agentami AI.
Zalecenie używania narzędzi self-hosted, np. n8n, aby zmniejszyć ryzyko ataków.
Wskazówki dotyczące bezpiecznego przechowywania i przesyłania kluczy API, w tym korzystanie z menadżerów sekretów.
Zasada najmniejszych przywilejów – ograniczanie dostępu do baz danych i stosowanie allowlist IP.
Tworzenie dedykowanych użytkowników z ograniczonymi uprawnieniami zamiast kont administratora.
Używanie kluczy API per projekt z dodatkowymi ograniczeniami, np. limitami kosztowymi.
Ochrona przed atakami Denial of Wallet przez wielowarstwowe zabezpieczenia (defense in depth).
Ustawianie limitów dziennych i powiadomień o zbliżających się limitach API.
Możliwość ograniczenia wydatków przez kontrolę kart płatniczych podpiętych do API.
Monitorowanie i ograniczanie zasobożernych zapytań na poziomie użytkownika systemu.

Full Transcript — Download SRT & Markdown

Speaker A

Witaj w kolejnej lekcji, w której odpowiadam na pytania dotyczące bezpieczeństwa, pytania, które najczęściej zadawali uczestnicy poprzednich edycji programu "Umiejętności Jutra". Tym razem skupimy się na bezpieczeństwie bardziej zaawansowanych rozwiązań i integracji z wykorzystaniem agentów AI. Gdyby niektóre z tych

Speaker A

dzisiaj poruszanych zagadnień brzmiały dla ciebie zbyt przerażająco albo zbyt skomplikowanie, no to nie przejmuj się, dobrym pomysłem może być nawet powrót do tej lekcji w późniejszym etapie programu, kiedy już sam zaczniesz budować rozwiązania z wykorzystaniem agentów AI. Moim celem jest pokazać ci dobre i sprawdzone

Speaker A

praktyki, a wdrożenie nawet części z nich na pewno skutecznie zminimalizuje ryzyka, o których dzisiaj będziemy rozmawiać.

Speaker A

Pamiętaj, że to pytania zadane przez uczestników poprzednich edycji, to są pytania, które pojawiły im się, kiedy zaczęli budować swoje własne rozwiązania do automatyzacji pracy z AI. I jeśli ty masz podobny plan, no to prawdopodobnie też staniesz przed tymi

Speaker A

samymi dylematami, ale będziesz już na nie przygotowany. Pytanie pierwsze: tworzę automatyzację w narzędziach typu n8n czy Make.

Speaker A

Jakie dobre praktyki wdrożyć przy przechowywaniu i przesyłaniu kluczy API, aby nie wystawić baz danych i innych informacji na widok publiczny?

Speaker A

Narzędzia z kategorii no-code albo low-code, takie jak właśnie n8n czy Make, to są bardzo popularne rozwiązania, jeśli chodzi o tak zwaną orkiestrację agentów AI. No ale z racji posiadanych przez te narzędzia dostępów, to jest także bardzo łakomy kąsek

Speaker A

dla wszelkiej maści atakujących, no bo przecież przejęcie nad tego typu narzędziem kontroli to nie tylko jest dostęp do kluczy API, czy też ryzyko kradzieży albo defraudacji twoich pieniędzy, ale często zdecydowanie bardziej katastrofalna w skutkach kradzież wrażliwych danych, które są podpięte i obsługiwane przez te narzędzia.

Speaker A

Dlatego, jeśli możesz, to do orkiestracji używaj narzędzi, które instalujesz na własnej infrastrukturze. Na przykład n8n ma wersję self-hosted, to jest taka wersja do własnej instalacji. Jeśli z niej skorzystasz, to ten celownik hakerski na twoich plecach stanie się zdecydowanie mniejszy. Ale, no tutaj trzeba poczynić

Speaker A

jedno bardzo ważne zastrzeżenie, w takim scenariuszu musisz sam zadbać o aktualizacje, konfigurację i bezpieczeństwo serwera, na którym n8n postawisz, albo przynajmniej musisz wiedzieć, jak poprawnie go schować przed botami i różnego rodzaju narzędziami skanującymi internet w poszukiwaniu dziurawych systemów i usług.

Speaker A

Jeśli nie masz doświadczenia z tymi podstawami administracji serwerami i systemami, no to jednak może lepiej nie brać na siebie aż takiej odpowiedzialności i skorzystać z gotowych rozwiązań w chmurze. Druga rada: niezależnie od tego, z jakiego podejścia finalnie skorzystasz,

Speaker A

poświęć chwilę na analizę możliwości wybranego narzędzia w kontekście zarządzania tak zwanymi sekretami, czyli na przykład hasłami czy też właśnie kluczami API.

Speaker A

Podawanie ich w modułach jako tak zwany zwykły tekst, plain text, to nie jest najlepszy pomysł, a sporo osób popełnia dokładnie ten błąd.

Speaker A

Takie sekrety to jest pierwsza rzecz, jakiej szukają włamywacze. Zarówno n8n, jak i Make mają dedykowane moduły do obsługi takich sekretów.

Speaker A

Korzystaj z nich, to jest bardzo dobra praktyka. Sekrety nigdy nie powinny być widoczne ani w logach, ani w samym interfejsie graficznym, ani też w komunikatach z błędami, które bardzo często orkiestrator śle na przykład na jakiś kanał deweloperski na Slacku. Rozważ dorzucenie takiego

Speaker A

dodatkowego węzła, który będzie czyścił tego typu logi lub właśnie komunikaty z błędami z tych sekretów.

Speaker A

Najbardziej profesjonalne, chociaż trzeba powiedzieć wprost, też bardziej pracochłonne podejście to jest użycie zewnętrznych, profesjonalnych menadżerów sekretów, takich jak Ingiscal, albo Google Secret Manager, albo AWS Secret Manager, albo Vault, albo inne tego typu rozwiązania. Dzięki nim te sekrety są bardziej

Speaker A

zabezpieczone, a automatyzacja, chociażby ta z n8n, może do nich sięgnąć tylko wtedy, kiedy faktycznie są potrzebne. No i rada trzecia to jest przywoływana przeze mnie już wielokrotnie, zwłaszcza w poprzedniej lekcji, zasada najmniejszych przywilejów, czyli chociażby allowlisty albo tunele.

Speaker A

Jeśli narzędziami no-code stukasz z chmury do bazy, która znajduje się w twojej infrastrukturze, no to sprawdź, z jakich adresów IP korzysta ta chmurowa usługa.

Speaker A

Listę tych adresów najczęściej znajdziesz w dokumentacji, i teraz, mając te adresy, po prostu ogranicz na swoim firewallu dostęp do danego zasobu tylko do tych adresów, no i oczywiście do innych zaufanych adresów, takich jak chociażby twój domowy adres IP. Chodzi o to,

Speaker A

aby nie pozwolić wszystkim łączyć się z twoimi zabawkami. Alternatywnie możesz też wykorzystać rozwiązania typu Cloudflare Tunnels, Tailscale albo WireGuard, no i skonfigurować bezpieczne, takie bezpośrednie połączenia między wszystkimi elementami twojego rozwiązania agentowego.

Speaker A

To podniesie również prywatność twojego środowiska. A na koniec jeszcze dwie uwagi, także z tej stajni takich najmniejszych przywilejów, pamiętaj, że modele czasem mogą zwariować i żeby ograniczyć im możliwość działań destrukcyjnych, nie stawiaj bazy na koncie administratora albo roota, ale stwórz jej takiego

Speaker A

dedykowanego użytkownika z uprawnieniami w systemie, które możesz dodatkowo ograniczać i kontrolować. Uruchamianie usług na zbyt wysokich uprawnieniach bez tak zwanego hardeningu, czyli konfiguracji usługi właśnie pod kątem bezpieczeństwa, to jest jeden z najczęstszych błędów, jakie widzimy w trakcie audytów bezpieczeństwa

Speaker A

środowisk IT, i ten błąd zdarza się nawet największym firmom. Sprawdź też, czy usługi, do których się podpinasz, pozwalają wygenerować klucze API per projekt.

Speaker A

Właśnie to jest najważniejsze, per projekt, bo dzięki temu możesz skorzystać z bezpieczniejszego rozwiązania niż korzystanie wszędzie z jednego i tego samego globalnego klucza. Zwłaszcza te klucze per projekt są ciekawym rozwiązaniem, jeśli dostawca pozwala na nie nałożyć dodatkowe ograniczenia, takie jak chociażby limity

Speaker A

kosztowe albo ograniczenia tylko i wyłącznie do konkretnych endpointów czy też modeli AI. Pytanie drugie: mój agent AI korzysta z płatnego API.

Speaker A

Jakie zabezpieczenia wdrożyć, aby atakujący nie wygenerował mi gigantycznych rachunków za zużycie tokenów? Przede wszystkim zapamiętajcie, że ataki Denial of Wallet, czy to właśnie jest nazwa na te ataki, które drenują wasze kredyty, wasze portfele, to niekoniecznie tego typu ataki wymagają wielu zapytań

Speaker A

ze strony atakującego. Czasem wystarczy jedno zapytanie, ale bardzo sprytne, takie, które na przykład wprowadzi agenta w pętlę. Ochrona przed tego typu atakami nie jest prosta i zazwyczaj wymaga wprowadzenia zabezpieczeń na kilku różnych warstwach. W branży takie podejście nazywamy Defense in depth.

Speaker A

Przykładowo, warstwa pierwsza, taka najbliższa chronionego zasobu, no to może być twarde ustawienie limitów, na przykład dziennych dla danego klucza API albo dla konkretnego modelu. Wielu z dostawców pozwala też na ustawienie powiadomienia SMS-owego albo mailowego, kiedy zbliża się liczba zapytań do tego kulminacyjnego punktu,

Speaker A

punktu ograniczenia do limitu. To jest bardzo przydatna funkcja, która może uratować twoje rozwiązanie w tych dniach, kiedy pojawi się ono na portalach społecznościowych albo stanie się jakimś wiralem na IRC-u.

Speaker A

Jeśli dany dostawca nie umożliwia ustawienia limitów, to warto jako taki ostatni cyfrowy bezpiecznik ustawić sobie limity bezpośrednio na karcie płatniczej, podpiętej pod usługę, albo tę kartę płatniczą w ogóle odpiąć od konta zaraz po dokonaniu przedpłaty.

Speaker A

Kolejną warstwą może być coś wbudowanego już bezpośrednio w twoje rozwiązanie - to dodatkowe funkcje programistyczne, które na przykład analizują płatne albo zasobożerne żądania w kontekście każdego użytkownika twojego systemu. To pozwoli ci wykryć, no i przyciąć tylko to jednogłośnie konto,

Speaker A

tego jednego użytkownika, bez ograniczania działania aplikacji innym użytkownikom, którzy nie zrobili.

Speaker A

wywoływania przez twojego agenta różnych narzędzi zewnętrznych i, aby uniknąć pętli, na przykład siłowo ograniczyć liczbę wywołań do maksymalnie 10 w ramach jednej sesji. Możesz też obudować swoją aplikację tak zwanymi guardrailsami, to są rozwiązania dostarczane przez różne firmy, jak chociażby NVIDIA

Speaker A

bardzo popularny framework NeMo. Jego celem jest wykrywanie, czy prompty kierowane do twojej usługi nie mają na celu jej nadużycia albo zaatakowania. I na koniec warstwa trzecia - to może być ochrona przed nadużyciami ze strony botów.

Speaker A

Możliwości jest tutaj bardzo dużo, od tak zwanego ratelimitingu, czyli ograniczania w czasie liczby żądań do twojej usługi poprzez sprawdzanie reputacji konkretnych adresów IP, aż do bardzo nowoczesnych testów à la CAPTCHA, oferowanych chociażby przez usługę Cloudflare.

Speaker A

Możesz też sięgnąć po silniejsze metody polegające na weryfikacji użytkownika poprzez chociażby wymuszenie podania numeru telefonu albo podpięcia karty płatniczej.

Speaker A

Ważne, aby każde z tych ograniczeń było dopasowane do twojego modelu ryzyka i żeby minimalizowało negatywny wpływ na prawdziwych użytkowników.

Speaker A

Jak zapewne się domyślasz, żadna z tych warstw zabezpieczeń nie jest idealna, no i nie zawsze wyłapie wszystko to, co złe. No ale właśnie dlatego ochrona przed nadużyciami jest wielowarstwowa, im więcej zabezpieczeń na tych różnych poziomach, tym bardziej poirytowany będzie atakujący

Speaker A

i większa szansa, że taki cyberłajdak poirytowany pójdzie sobie męczyć i nadużywać inną, łatwiejszą do pokonania usługę niż twoja.

Speaker A

Pytanie trzecie: mój agent ma dostęp do skrzynki mailowej i sam wysyła wyceny do klientów. Co zrobić, żeby bot nie podjął samodzielnie katastrofalnej w skutkach akcji?

Speaker A

A to akurat jest bardzo proste, niech bot tworzy tylko i wyłącznie szkice e-maili, a przycisk "wyślij" niech naciska tylko i wyłącznie człowiek - białkowy, mięsny mechanizm.

Speaker A

Oczywiście taki człowiek, który wcześniej ten szkic przeczytał. Tworzenie oferty i pisanie maila to rzeczywiście jest najdłuższa część całego tego procesu, dlatego nawet dodanie człowieka w tak zwanej pętli mimo wszystko będzie wydajniejszym rozwiązaniem. Oczywiście, jeśli po pół roku ręcznej akceptacji

Speaker A

i ewentualnych poprawek działania bota uznasz, że w zasadzie to nie masz już żadnych zastrzeżeń do tworzonych przez bota e-maili, no to możesz rozważyć umożliwienie mu wysyłki ofert samodzielnie. No ale ja, jako zdrowy paranoik, zalecałbym jednak podejść do sprawy troszeczkę ostrożniej. Dodaj na przykład do tego

Speaker A

swojego procesu drugiego bota AI-owego, który będzie czytał oferty stworzone przez pierwszego bota, oczywiście przed ich wysłaniem. Taki bezpiecznik może robić kilka podstawowych sprawdzeń, jak chociażby weryfikacja, czy wycena przypadkiem nie zawiera 200% rabatu, albo może wstrzymać wysyłkę takiego maila

Speaker A

poza godzinami pracy. I na koniec rozważyłbym też konsultacje z prawnikami w zakresie dodania do wyceny informacji w stylu: "Niniejsza wycena została przygotowana przez AI i może zawierać błędy, a finalna cena zostanie potwierdzona na etapie zamówienia". To może być całkiem sensowna

Speaker A

ostatnia deska ratunku, gdyby botowi coś nagle mocno odhalucynowało. Pytanie czwarte: na jakie punkty styku w workflow programisty AI trzeba uważać najmocniej, aby uniknąć przejęcia środowiska?

Speaker A

Ostatnie ataki na konta deweloperów rozwijających bardzo popularne projekty, takie jak LiteLLM czy Axios, pokazały, że nawet ci najbardziej doświadczeni programiści czasem bardzo lekkodusznie podchodzą do tematu bezpieczeństwa swojego środowiska.

Speaker A

A to naraża na wyciek zarówno ich dane, jak również dane ich klientów czy użytkowników.

Speaker A

Dlatego jeśli korzystasz z zewnętrznych bibliotek w swoich projektach, a robisz to na pewno, to przygotuj się zawczasu na najgorsze.

Speaker A

Przede wszystkim odseparuj swój prywatny komputer od środowiska deweloperskiego. Jeśli tego nie zrobisz, to wystarczy, że ktoś zainfekuje kod jednej z dziesiątek bibliotek, z jakiej korzysta twoja aplikacja, i problem dotknie nie tylko samej twojej apki, ale również danych, które ona przetwarza, i wszystkiego,

Speaker A

co masz u siebie na dysku, w tym twoich danych prywatnych. Możesz rozważyć przeniesienie takiego środowiska deweloperskiego na osobny serwer, do którego będziesz się łączył na przykład poprzez tunel SSH, no albo chociaż do dedykowanej maszyny wirtualnej.

Speaker A

I tu drobna uwaga dla tych, którzy będą korzystać z Dockera: pamiętajcie, że w niektórych konfiguracjach kontener dockerowy współdzieli jądro z hostem, co może się na was bardzo boleśnie zemścić. Jak masz już serwer albo maszynę pod development, no to nie pracuj i nie instaluj

Speaker A

na niej wszystkiego jako administrator. Stosuj zasadę najmniejszych przywilejów: zawsze i wszędzie wszystkiemu, co można, przydziel osobnego użytkownika i kontroluj, do czego taki użytkownik ma dostęp. Pamiętaj też, żeby podczas instalacji jakiegoś oprogramowania nie przeklejać bezmyślnie komend typu CURL, skrypt z jakiegoś adresu,

Speaker A

prosto do sudo bash. Takie komendy mogą zawierać złośliwe instrukcje, albo na takie złośliwe instrukcje mogą zostać zamienione w schowku, kiedy je skopiujesz, za pomocą JavaScriptu, a efekt?

Speaker A

Po wklejeniu i zaenterowaniu takiej komendy zainfekujesz sobie system. Dlatego do instalacji oprogramowania używaj menadżerów pakietów. To jest zdecydowanie lepsze rozwiązanie, chociaż jak pokazały ostatnie ataki, nawet tą drogą można pobrać zainfekowaną paczkę.

Speaker A

Ale żeby zminimalizować to ryzyko, możesz skorzystać z pinningu wersji albo tak zwanego okresu cooldown.

Speaker A

Pinning to jest wymuszanie stosowania jednej konkretnej wersji projektu, biblioteki, zamiast od razu najnowszej wersji. Cooldown z kolei pozwala ci wskazać okres, przez jaki od momentu premiery dana wersja nie będzie brana pod uwagę, będzie ignorowana. Opóźnienie możesz ustawić na przykład na 7 dni, bo to raczej nie wpłynie

Speaker A

negatywnie na funkcjonalność twojego projektu, natomiast może cię uchronić przed zhakowaniem. Dlaczego? Bo większość tych złośliwych paczek jest wykrywana już w pierwszych kilkunastu godzinach, a często nawet po kilkunastu minutach, w związku z czym po 7 dniach, to po takim ataku nie będzie już żadnego śladu.

Speaker A

Tam, gdzie to jest możliwe, blokuj też skrypty postinstalowe, i generalnie dobrze poznaj wszystkie opcje bezpieczeństwa, jakie udostępniają narzędzia, z których korzystasz do zarządzania albo wytwarzania oprogramowania.

Speaker A

O funkcje bezpieczeństwa tych narzędzi możesz zapytać swojego asystenta AI, a następnie wspólnie z tym asystentem możesz skonfigurować każdą z takich opcji, niezależnie od tego, czy ona wymaga sięgnięcia do jakiegoś pliku konfiguracyjnego i zmiany tam jakiegoś parametru albo zmiennej, czy też może

Speaker A

korekty ustawień w innych miejscach w systemie. To jest tylko kilka podstawowych, ale obowiązkowych rad. Zbudowanie bezpiecznego środowiska wymaga zdecydowanie większego zaangażowania, ale przede wszystkim uwzględnienia konkretnych potrzeb wynikających z twojego stacku technologicznego i charakterystyki twojego projektu.

Speaker A

Coś, co będzie dobre dla Karola, nie zawsze będzie dobre dla Julii. Te rozwiązania muszą być dopasowane do twoich potrzeb.

Speaker A

Dlatego zachęcam cię do znalezienia i wdrożenia tak zwanych hardening guides dla każdej technologii, każdego z narzędzi, z których korzystasz.

Speaker A

Te dokumenty to są takie proste pliki tekstowe, które opisują wszystkie możliwe ustawienia mające wpływ na bezpieczeństwo danej technologii albo jakiegoś rozwiązania. Jeśli twórcy narzędzi, z których korzystasz, takich dokumentów, takich wskazówek nie udostępniają, nie stworzyli ich, no to po prostu wpisz w Google nazwę twojego narzędzia

Speaker A

plus hardening. Na przykład wprowadź npm + hardening guide albo docker + hardening. Sugerowane w tych poradnikach ustawienia to często pierwsza rzecz, którą sprawdzamy podczas wykonywanych przez nas testów bezpieczeństwa.

Speaker A

I na koniec jeszcze jedna wskazówka: firewall na wyjściu. Nie zezwalaj wszystkim procesom na możliwość swobodnego nawiązywania połączeń wychodzących. Wtedy, nawet jeśli taki proces okazałby się złośliwy, miałby dostęp do twoich danych i te dane ci wykradł, no to niekoniecznie będzie

Speaker A

w stanie, jeśli to ograniczenie jest w mocy, wysłać je, wytransferować z twojej maszyny na maszynę atakującego. Mała podpowiedź, zwłaszcza jeśli pracujesz w środowisku graficznym, na przykład na systemie macOS albo Linux, możesz tu wykorzystać bardzo ciekawe narzędzie o nazwie

Speaker A

LittleSnitch, które ostrzega w interaktywny sposób, jeśli jakiś proces albo program próbuje nawiązać połączenie wychodzące z internetem albo do innej maszyny w sieci lokalnej. Ale oczywiście tego typu rozwiązań jest więcej na różne systemy.

Speaker A

Możesz sięgnąć po Portmaster albo GlassWire, albo Lulu. Pytanie piąte: stworzyłem nową automatyzację AI w firmie.

Speaker A

Jak samodzielnie przeprowadzić AI-owy pentest, zanim wypuszczę tego typu rozwiązanie do użytkowników? Samodzielne testowanie własnych projektów pod kątem bezpieczeństwa to nie jest najlepsze podejście, choćby ze względu na tak zwane błędy poznawcze, takie jak efekt potwierdzenia czy klątwa wiedzy. Mówiąc wprost,

Speaker A

włamywacze często wykorzystują do ataku technikę, o istnieniu której twórca danego oprogramowania w ogóle nie wiedział, a zatem nie miał szans na etapie tworzenia oprogramowania czy jego testowania, aby przed tą techniką się zabezpieczyć.

Speaker A

Istnieją co prawda zarówno statyczne, jak i dynamiczne skanery bezpieczeństwa, a nawet dedykowane modele AI i narzędzia do tak zwanego red teamingu AI, takie jak Garak, PyRIT, DeepTeam albo Promptfoo, ale każde z tych rozwiązań ma swoje wady i ograniczenia,

Speaker A

no i zwłaszcza w rękach niedoświadczonych osób nie da 100% pewności, że wszystkie istotne problemy związane z bezpieczeństwem zostaną namierzone, no i poprawnie obsłużone. Co więcej, nieumiejętne użycie tych rozwiązań może ci wręcz dołożyć zupełnie niepotrzebnej pracy, bo wiele z tych skanerów bezpieczeństwa w swoich

Speaker A

raportach zawiera masę tak zwanych false positives, czyli błędów, które w rzeczywistości nie są istotne, albo w ogóle nie istnieją, albo, jak to mówimy w branży, nie są eksploitowane, czyli nie da się za ich pomocą wykonać jakiegoś udanego ataku, który zabolałby daną aplikację

Speaker A

czy środowisko. Obsługując takie błędy, stracisz czas na adresowanie problemów, które problemami w ogóle nie są. Samodzielne testowanie swoich projektów jest potrzebne, ale niewystarczające.

Speaker A

Dlatego, choć wiem, że nie zabrzmi to turbo wiarygodnie z moich ust, czyli właściciela firmy, która od ponad 16 lat realizuje takie profesjonalne usługi testów bezpieczeństwa, to ja mimo wszystko gorąco zachęcam cię do zlecania takich testów na zewnątrz, do ekspertów od cybersecurity, ludzi, którzy żyją z psucia

Speaker A

rozwiązań i na bieżąco, dzień za dniem, śledzą coraz to nowsze i sprytniejsze techniki atakujących i różnego rodzaju narzędzia, które im w atakach pomagają. Tacy ludzie na twój projekt spojrzą z boku, bez emocji, no i często w zdecydowanie bardziej niszczycielski sposób niż ty kiedykolwiek byłbyś

Speaker A

w stanie spojrzeć na swój kod. Pamiętaj też, że takim rynkowym standardem jest to, że klienci, którzy będą kiedyś od ciebie wymagać raportów z testów bezpieczeństwa, oni będą oczekiwać, że te testy zostały przeprowadzone przez profesjonalny i niezależny zespół. Zlecenie testów na zewnątrz

Speaker A

nie oznacza jednak, że ty nie powinieneś przejmować się bezpieczeństwem twojego projektu w ogóle. No wręcz przeciwnie, jeśli chcesz sprawić, aby twój projekt faktycznie był bardzo bezpieczny, to wprowadź do niego dobre praktyki cybersecurity na jak najwcześniejszym możliwym etapie tworzenia,

Speaker A

czyli już na przykład podczas projektowania, zanim napisana lub wyvibecodowana zostanie pierwsza linijka kodu. Jakie pytania warto sobie wtedy zadać i na co zwrócić uwagę?

Speaker A

No tu wskazówki znajdziesz na stronach projektu GenAI Security, rozwijanego przez Fundację OWASP, rzuć okiem zwłaszcza na AI SVS.

Speaker A

Poczytaj też dokumentację NIST AI RMF. Pamiętaj, w temacie cyberbezpieczeństwa nie ma żartów. Nawet przeoczenie czegoś bardzo drobnego może skutkować potężnymi, poważnymi szkodami, nie tylko na twoim wizerunku.

Speaker A

Wierz mi, że nie chcesz, aby premierę twojego projektu, ten bardzo ważny dzień, przyćmił jakiś incydent polegający na przykład na wycieku danych.

Speaker A

Dlatego zawsze wykonuj testy bezpieczeństwa, zanim zdeployujesz swoją aplikację do internetu, bo w internecie może czaić się zło, a licho nigdy nie śpi.

Topics:bezpieczeństwo AIautomatyzacjaagenty AIklucze APIn8nMakemenadżer sekretówallowlista IPDenial of Walletdefense in depth

Frequently Asked Questions

Jak bezpiecznie przechowywać klucze API w narzędziach no-code?

Należy korzystać z dedykowanych modułów do zarządzania sekretami, unikać przechowywania kluczy w plain text, a najlepiej używać profesjonalnych menadżerów sekretów jak Google Secret Manager czy Vault.

Dlaczego warto korzystać z wersji self-hosted narzędzi takich jak n8n?

Self-hosted wersje zmniejszają ryzyko ataków, ponieważ kontrolujesz infrastrukturę, ale wymagają samodzielnej administracji i zabezpieczenia serwera przed nieautoryzowanym dostępem.

Jak chronić się przed atakami generującymi wysokie koszty API?

Warto ustawić limity dzienne na klucze API, korzystać z powiadomień o zbliżających się limitach, stosować wielowarstwowe zabezpieczenia oraz monitorować i ograniczać zasobożerne zapytania użytkowników.

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →