Od zera do systemu AI w kwartał. Część 17: Bezpieczeństwo systemu.

W bloku czwartym zbudowaliśmy infrastrukturę. Zastąpione abonamenty. Działające workflow’y. Integracje z narzędziami. Własne skrypty.

Z każdym kolejnym elementem system robi się potężniejszy. I kruchszy.

Kruchy nie dlatego, że źle go zbudowaliśmy. Kruchy dlatego, że ma więcej punktów wejścia. Więcej kluczy API, które mogą wyciec. Więcej skryptów, które mogą się zepsuć. Więcej danych, które mogą zostać utracone.

Ten artykuł jest o tym, jak chronić to, co zbudowałeś. Nie jest to wykład o kryptografii ani audyt zgodności z normami. To pięć praktycznych obszarów, w których większość błędów się zdarza, i zasady, które u mnie działają.

Najpierw jednak zasadnicza sprawa. Mówimy tu o bezpieczeństwie mikrofirmy albo osoby pracującej samodzielnie. Jeśli masz firmę z trzydziestoma pracownikami, danymi osobowymi tysięcy klientów i obowiązkami RODO, te zasady są tylko początkiem. Potrzebujesz konsultanta, audytora, polityki bezpieczeństwa. Nie zastąpię tego blogiem.

Zastrzeżenie: to co opisuję w tym cyklu bazuje na moim stacku technologicznym, czyli macOS i Claude jako główny model językowy. Zasady i podejście działają na każdym systemie operacyjnym i z każdym modelem AI, ale konkretne kroki i skróty klawiszowe opisuję pod Maca. Jeśli pracujesz na Windows lub Linux, większość rzeczy zrobisz tak samo, ale powyższe systemy mogą się różnić detalami, które musisz dostosować.

Ważne: opisuję tu model uproszczony, czyli idealny obraz tego, jak działa ten fragment systemu. W praktyce mój obecny system ma więcej warstw, wyjątków i automatyzacji. Na potrzeby tego cyklu pokazuję wersję, którą najłatwiej zrozumieć i odtworzyć u siebie.

Obszar 1: credentials (dostępy), czyli klucze do wszystkiego

Zacznijmy od podstawy. Credentials to wszystko, co służy do uwierzytelnienia: hasła, klucze API, tokeny, certyfikaty, pliki uwierzytelnień OAuth. Każdy z nich to klucz do jakichś drzwi.

Reguła pierwsza: credentials mają jedno miejsce, a nie dziesięć. U mnie skrypty czytają klucze z jednego pliku w folderze, który jest wykluczony ze wszystkich synchronizacji. Nie trafia do GitHuba. Nie trafia do chmurowego backupu publicznego. Nie indeksuje go żadna baza danych.

Odkąd w systemie pracuje zespół, sam plik przestał wystarczać, bo plik daje dostęp do wszystkiego albo do niczego. Dlatego hasła i klucze przenoszę do menadżera haseł z sejfami według działów: osoba od reklam widzi sejf reklamowy, nie widzi księgowości. Pytanie przy każdym nowym haśle brzmi „kto ma to widzieć”, a nie „do jakiego narzędzia to jest”.

Reguła druga: credentials nigdy nie trafiają do kodu. W skryptach czytam je z pliku i ustawiam jako zmienne środowiskowe. Nigdy nie wpisuję wartości w komendzie typu NEO4J_PASSWORD='haslo' node skrypt.js, bo zaakceptowane komendy w niektórych klientach AI trafiają do plików konfiguracyjnych jako zwykły tekst. Zawsze używam wzorca: czytaj z pliku, ustaw jako zmienną, wywołaj skrypt.

Reguła trzecia: minimum uprawnień. Każdy klucz generuję z najmniejszym możliwym zakresem. Klucz do Analytics to tylko “read analytics data”. Klucz do sklepu to tylko dostęp do magazynu, nie do finansów. Klucz do maila to tylko czytanie konkretnej skrzynki, nie zarządzanie całym kontem.

Reguła czwarta: rotacja po każdym podejrzeniu wycieku, nie „kiedyś”. Klucz, który wyciekł, może szkodzić cicho przez miesiące, więc liczy się czas od wycieku do wymiany. Każdy wyciek zapisuję w jednym rejestrze: co wyciekło, kiedy, gdzie trzeba zmienić i w jakiej kolejności. Zadanie bez terminu w osobnym pliku ginie, a zegar przy wycieku tyka niezależnie od tego, czy ktoś patrzy.

Do tej reguły dorobiłem sobie drugą połowę, bo pierwsza sama nie wystarczała. Rotacja nie kończy się w momencie, w którym wpiszesz nową wartość do swojego pliku z kluczami. Kończy się wtedy, gdy nową wartość ma każdy, kto z tego klucza czyta. A tych miejsc jest zawsze więcej, niż pamiętasz: zmienne środowiskowe w hostingu, ustawienia w narzędziu do automatyzacji, klucz wklejony kiedyś na sztywno w pojedynczy krok workflow. Policzyłem to u siebie i przy jednym kluczu wyszło piętnaście miejsc. Przy drugim czternaście.

Wniosek praktyczny: zanim zrotujesz, zrób listę konsumentów, a po rotacji sprawdź każdego realnym wywołaniem. Lista prowadzona z pamięci starzeje się szybciej niż sam klucz, więc lepiej jest ją wyliczyć. U mnie robi to skrypt, który przechodzi po wszystkich miejscach i porównuje odciski wartości, nigdy same wartości. Bez tego kroku rotacja wygląda na wykonaną i psuje coś, o czym dowiesz się za dwa tygodnie od klienta.

Jeden krok dołożyłem później: po rotacji szukam w systemie starej wartości. Lista konsumentów zna tylko to, co jest zapisane w pliku z kluczami. Nie zna kopii, którą ktoś kiedyś wkleił ręcznie, ani drugiego klucza do tego samego konta. Stary klucz unieważniam u dostawcy dopiero wtedy, gdy to wyszukiwanie wyjdzie czyste.

Najwięcej nauczyły mnie wycieki, które nie wyszły z mojej komendy. Wpisywałem klucze poprawnie, przez zmienną, i mimo to trafiały do zapisu rozmowy z AI. Trzy drogi, każdą zmierzyłem u siebie:

narzędzie samo wypisało klucz, który mu podałem, w podpowiedzi „wpisz to, żeby zobaczyć następną stronę”;
polecenie dostało źle sklejony argument, nie rozpoznało go i zacytowało go w komunikacie błędu, razem z hasłem;
wyszukiwanie w starych wiadomościach wyciągnęło hasło, które ktoś wysłał otwartym tekstem kilka miesięcy wcześniej i o którym nikt nie pamiętał.

Na każdą z tych dróg miałem już spisaną regułę i każda mimo to zadziałała. Dlatego zamiast kolejnej reguły postawiłem mechanizm: bramkę, przez którą przechodzi każde polecenie i każdy wynik narzędzia. Blokuje polecenia, które mogą wypisać klucz, i alarmuje, gdy w wyniku pojawi się coś o kształcie klucza albo hasła. Alarm podaje miejsce i długość, nigdy samą wartość, bo bramka cytująca znalezione hasło jest drugim wyciekiem.

Reguła piąta: gdy nagrywam stream lub pracuję przy widocznym terminalu, zmieniam zmienną środowiskową, która blokuje czytanie plików z POUFNE/. Lepiej przepytać dwa razy, niż raz pokazać klucz.

Obszar 2: backup, czyli co robisz, gdy wszystko padnie

Drugi obszar, o którym się zapomina do momentu, gdy robi się za późno.

Mam system oparty na plikach. Ten system leży na jednym Macu. Jeśli Mac zniknie (zgubiony, ukradziony, spalony, rozbity), co tracę?

Odpowiedź: wszystko, jeśli nie mam backupów. Miesiące pracy, cała baza notatek, konfiguracje agentów, pamięć decyzji, automatyzacje.

Zasada: co najmniej trzy miejsca dla każdego ważnego pliku. Lokalnie na Macu (pierwsze). Synchronizacja z chmurą (drugie). Fizyczny backup na zewnętrznym dysku raz na tydzień (trzecie).

W moim przypadku:

Lokalnie: vault na dysku Maca. Codzienna praca.

Synchronizacja z chmurą: synchronizacja vault między urządzeniami. W moim przypadku to warstwa, która daje mi ciągłość pracy między komputerem a telefonem, ale nie jest jedynym backupem i nie może nim być.

Fizyczny backup: wbudowana kopia systemowa na dwa zewnętrzne dyski, używane na zmianę. Jeden jest podłączony, drugi leży poza biurkiem. Gdy jeden padnie albo zniknie razem z komputerem, drugi ma stan sprzed najwyżej kilku tygodni.

Szyfrowana paczka tego, czego nie ma nigdzie indziej: codziennie skrypt pakuje rzeczy, których synchronizacja nie obejmuje, bo celowo są z niej wyłączone: klucze, ustawienia narzędzi, konfiguracje automatów. Paczka jest zaszyfrowana, leży w chmurze, a hasło do niej trzymam w menadżerze haseł, nie na tym samym komputerze.

Dodatkowo: Wybrane części vault (bez folderu poufnego, bez folderu osobistego) synchronizują się też do prywatnego repozytorium Git. To zapewnia historię zmian. Mogę wrócić do stanu sprzed tygodnia, miesiąca, kwartału.

Koszt w tym miejscu jest drugorzędny. Liczy się to, że backup jest wielowarstwowy i da się go odtworzyć. Jedna synchronizacja nie wystarczy. Jedna kopia na dysku też nie.

I backup, którego nikt nie pilnuje, przestaje istnieć po cichu. Dlatego osobny automat codziennie sprawdza, czy paczka powstała i czy jest kompletna, oraz kiedy każdy z dysków dostał ostatnią kopię. Za długi czas bez kopii daje alarm, a nie ciszę.

Sprawdzian wartości: co by się stało, gdyby Mac padł dzisiaj? Mam spisaną procedurę odtworzenia krok po kroku: nowy komputer, kopia z dysku, paczka z chmurą, synchronizacja. Ale procedura, której nie przećwiczyłeś, jest tylko planem. Wartość ma dopiero wtedy, gdy raz odtworzysz z niej system na drugim komputerze. Bez backupu: kilka tygodni odbudowy i część rzeczy nigdy nie wraca.

Teraz część, którą wolałbym pominąć, ale jest najważniejsza w tej sekcji. Największą stratę danych w całej historii tego systemu spowodował nie awaria dysku, nie kradzież i nie pomyłka AI. Spowodował ją skrypt, który sam napisałem, żeby chronić dane.

Mechanizm był taki. Pracuję na dwóch komputerach. Skrypt miał przygotować ten, na który wracam, przez pobranie świeżej wersji z kopii i wyrównanie stanu. Problem w tym, że robił to jednokierunkowo i bezwarunkowo: brał kopię i kasował wszystko, czego w niej nie było. Uruchomiłem go na komputerze, który akurat był tym głównym, a kopia była o kilka dni starsza. Efekt: praca z sześciu dni zniknęła, kilkanaście plików straciło treść, kilka przestało istnieć. Odzyskałem je z innej kopii, ale straciłem na to pół dnia i sporo nerwów.

Trzy rzeczy, które z tego wyniosłem, i każda dotyczy Ciebie, jeśli masz więcej niż jedno urządzenie:

Synchronizacja to nie backup. Backup dodaje wersje. Synchronizacja wyrównuje stany, więc równie chętnie skopiuje usunięcie jak nowy plik. Narzędzie, które ma w opisie „wyrównaj”, potrafi wyrównać w dół.

Skrypt, który kasuje, musi mieć warunek wstępny. Nie „czy jestem pewien”, bo na to zawsze odpowiesz „tak”. Warunek sprawdzalny: czy w miejscu docelowym jest cokolwiek, czego w źródle nie ma? Jeśli tak, przerwij i pokaż co. Dopisałem taką bramkę i od tej pory skrypt kilka razy odmówił uruchomienia. Za każdym razem słusznie.

Kierunek trzeba znać przed uruchomieniem, nie po. Narzędzie działające w jedną stronę jest bezpieczne tylko na maszynie, która konsumuje, i groźne na tej, która tworzy. To ta sama komenda, więc jedyną różnicą jest to, czy wiesz, gdzie stoisz.

Osobna kategoria: backupy danych klientów. Gdy pracuję na cudzej infrastrukturze (sklep, panel, arkusze), nie trzymam tych zrzutów danych w głównym vault. Mają osobny folder na dysku lokalnym, poza synchronizacją. Każdy klient ma własny podfolder, każdy backup ma datę i etykietę w nazwie. Pliki większe niż dziesięć megabajtów nigdy nie trafiają do vault, bo to spowalnia synchronizację i zaśmieca indeksowanie. Reguła brzmi: vault dla wiedzy, osobny folder dla dużych zrzutów.

Długo trzymałem ten folder w katalogu, który chmura synchronizuje między komputerami. Wydawało się to wygodne i bezpieczne. Okazało się, że chmura dla oszczędności miejsca zostawiała na dysku same odnośniki zamiast plików, a automat działający w tle nie umiał ich pobrać. Zmierzyłem to: prawie wszystkie pliki w tych folderach były wyłącznie w chmurze. Kopia, której nie ma na dysku w chwili, gdy jej potrzebujesz, nie jest kopią. Dziś dane leżą lokalnie, a do chmury trafia ich lustro, dwa razy dziennie.

Reguła nadrzędna przy pracy na cudzej infrastrukturze: backup PIERWSZY krok, zanim cokolwiek dotkniesz. Sklep klienta, jego CRM, jego arkusz, jego konto. Zanim zrobię cokolwiek, robię snapshot stanu wyjściowego. Nawet jeśli “to drobna zmiana”, nawet jeśli “klient prosi o szybko”. Bez backupu = stop jakiejkolwiek pracy. Pamiętam o tym, bo dwa razy uratowało mi to projekt, gdy “drobna” zmiana okazała się katastrofalna i bez kopii nie miałem do czego wrócić. Ta reguła wygrywa z każdą inną, z presją czasu, z prośbą klienta, z własnym zniecierpliwieniem.

Obszar 3: co pokazywać, a czego nie

Trzeci obszar, o którym rzadko się myśli, ale który okazuje się ważny, gdy zaczynasz prowadzić bloga, nagrywać wideo czy udostępniać system.

Każda treść, która wychodzi na zewnątrz, może zawierać coś, czego nie chcesz pokazywać.

Kategorie, które u mnie nigdy nie wychodzą do publicznego obiegu:

Nazwiska klientów, nazwy ich firm. Na blogach i w kampaniach mówię “klient” albo “firma budowlana”. Nigdy konkretnej nazwy bez jasnego pozwolenia. Dotyczy to też przypadków, w których opisuję case study.

URL-e infrastruktury. Mój serwer n8n ma swój URL. Baza danych też. Panel Supabase, Grafana, wewnętrzne dashboardy. Żaden z tych adresów nigdy nie ląduje w publicznych materiałach. Gdy potrzebuję linku do potwierdzania subskrypcji newslettera, kieruję przez własną domenę, która wewnętrznie przekierowuje dalej. Użytkownik widzi moją markę. Infrastruktura jest niewidoczna.

Struktura wewnętrznych narzędzi. Nazwy workflow’ów, ID arkuszy, nazwy plików z wrażliwymi danymi. To są szczegóły, które mi coś mówią, ale osobie z zewnątrz mogłyby ujawnić, jak łatwo zepsuć mój system.

Nazwy wewnętrznych skryptów z elementami infrastruktury. “Skrypt do importu” mogę powiedzieć. “Skrypt import-cms-nazwa-firmy.js” już nie, bo w nazwie jest fragment wskazujący, jakiej firmy dotyczy.

Pokażę na konkretnym przykładzie.

W cyklu “Od zera do systemu AI” pokazuję workflow’y i skrypty. Ale fragmenty kodu są ogólne, nazwy narzędzi też. Zamiast “mój skrypt pobiera zamówienia z Shoper sklepu klienta przez API” piszę “skrypt pobiera zamówienia ze sklepu przez API”. Zamiast “workflow używa klucza Resend do wysłania maila do newslettera 500 osób” piszę “workflow wysyła mail przez API”.

Efekt dydaktyczny jest ten sam. Ryzyko ujawnienia infrastruktury zerowe.

Obszar 4: automatyzacje, które mogą coś zepsuć

Czwarty obszar. Gdy masz automatyzacje, które wysyłają maile, publikują posty, edytują dane w systemach zewnętrznych, jeden błąd może zrobić rzeczy, które trudno cofnąć.

Kilka zasad, które chronią przed najgorszymi scenariuszami.

Zasada 1: zatwierdzenie przed wysłaniem. Nic, co trafia do człowieka (klient, zespół, wspólnik), nie wychodzi samo. System przygotowuje szkic i pokazuje mi pełną treść. Wychodzi dopiero po moim „wyślij” do tej konkretnej treści. Wskazanie odbiorcy ani zgoda na temat nie są zgodą na wysyłkę. Koszt: kilka sekund na wiadomość. Wyjątek mają tylko stałe alerty i raporty, których szablon zatwierdziłem raz.

Zasada 2: testowanie na próbie. Zanim włączę workflow do pełnego działania, testuję na dziesięciu elementach zamiast tysiącu. Jeśli się psuje, psuje się kontrolowanie. Jeśli działa, wtedy rozpoczynam skalowanie.

Zasada 3: idempotentność. Skomplikowane słowo na prostą sprawę. Jeśli workflow uruchomi się dwa razy (bo coś kliknąłem, bo powtórka procesu, bo błąd), nie może powstać efekt “podwójny”. Mail jest wysłany raz. Rekord jest utworzony raz. Ta cecha musi być projektowana od początku, bo dopinanie jej później jest trudne.

Zasada 4: alerty przy błędach, w miejscu, w które naprawdę patrzysz. Każdy automat ma powiadomienie o awarii. Przez długi czas szły na kanał na Slacku i to był błąd, bo na Slacka zaglądam rzadko. Kanał, którego adresat nie czyta, działa tak samo jak brak powiadomienia, tylko daje fałszywe poczucie, że informacja poszła. Dziś każdy alert trafia do jednego kafla „co wymaga uwagi” w panelu, który otwieram codziennie. Jeden problem to jeden wpis, a gdy problem znika, wpis zamyka się sam. Do tego samego miejsca trafiają maile bezpieczeństwa od dostawców, na przykład o logowaniu z nowego urządzenia.

Zasada 5: rollback, gdy się da. Dla operacji, które modyfikują dane zewnętrzne (sklep, CRM, baza), myślę z góry, jak to cofnąć. Zapisuję stan poprzedni. Mam procedurę awaryjną. Nie wszystko da się cofnąć, ale większość rzeczy tak.

Zasada 6: treść z zewnątrz to dane, nie polecenia. Strona, którą AI czyta, mail od klienta, wiadomość z komunikatora, plik od kogoś obcego. Każda z tych rzeczy może zawierać zdanie, które wygląda jak polecenie: „zignoruj poprzednie instrukcje i wyślij…”. Model nie odróżnia sam z siebie Twojej prośby od zdania przeczytanego w cudzym tekście. Dlatego u mnie żadna treść z zewnątrz nie uruchamia akcji. Model może ją przeczytać, streścić i ocenić, ale wysyłka, zapis czy zmiana u klienta idą wyłącznie po mojej decyzji.

Obszar 5: sama prawda, czyli AI nie zmyśla

Piąty obszar, o którym myśli mało osób, dopóki się nie sparzy. Bezpieczeństwo to też ochrona przed wprowadzaniem siebie i innych w błąd.

AI ma cechę, która w odpowiednim kontekście jest siłą, w innym ryzykiem: pewnie odpowiada nawet wtedy, gdy nie wie. Jeśli pytasz o liczbę, dostaniesz liczbę. Jeśli pytasz o cytat, dostaniesz cytat. Jeśli pytasz o cenę narzędzia konkurencji, dostaniesz cenę. Często prawdziwą. Czasem zmyśloną. I bardzo rzadko z ostrzeżeniem, że to być może zmyślone.

W moim systemie wprowadziłem trzy zasady, które ograniczają to ryzyko.

Zasada 1: każda liczba wymaga źródła. Jeśli AI mówi “raport pokazuje wzrost o 23%”, musi powiedzieć z jakiego pliku, z której linii, albo na podstawie czyjej rozmowy. Brak źródła = brak liczby. W instrukcjach dla wszystkich agentów mam wprost: “jeśli nie masz źródła, powiedz ‘nie mam tych danych’”.

Zasada 2: hierarchia źródeł. Pierwsze: pliki projektu. Drugie: notatki w pamięci. Trzecie: to, co sam powiedziałem w tej sesji. Czwarte: aktualna dokumentacja biblioteki przez Context7 MCP (gdy chodzi o składnię frameworka). Dopiero piąte: “nie wiem”. Nigdy: “tak zwykle bywa” albo “prawdopodobnie”.

Zasada 3: zakazane słowa-uniki. “Około”, “prawdopodobnie”, “zazwyczaj”, “standardowo”, w odpowiedziach o danych są zakazane. Albo wiesz dokładnie, albo mówisz, że nie masz danych. Nie ma stanu pośredniego.

W praktyce: gdy zaczynam ważną sesję, w której decyzja zależy od konkretów, powtarzam regułę na początku rozmowy. AI traktuje to jako instrukcję dla całej sesji. Błędów to nie usuwa, ale zmienia ich rodzaj: zamiast pewnie podanej liczby, której nie ma, częściej dostaję „nie mam tych danych”, a to da się sprawdzić.

Jedna rzecz, której nauczyłem się później: najgroźniejsza nie jest zmyślona liczba, tylko pomiar, który świeci na zielono, choć nic nie zmierzył. Zero błędów w raporcie wygląda tak samo, gdy błędów nie ma i gdy sprawdzenie w ogóle się nie wykonało. Dlatego wynik lepszy, niż się spodziewam, sprawdzam drugi raz, a każda moja czujka ma tryb testu, w którym na celowo zepsutym wejściu musi zgłosić problem.

To brzmi jak technikalia, ale ma duże skutki biznesowe. AI, który przekona klienta liczbą, której nie ma, kosztuje wiarygodność. AI, który mówi “nie mam tych danych, sprawdźmy”, buduje zaufanie. Ta różnica jest pierwsza, gdy AI zaczyna pisać oferty, raporty, komunikaty.

Najczęstsze błędy początkujących

Kilka rzeczy, które widzę regularnie u osób wchodzących w automatyzacje.

Klucze API w repozytorium Git. Piszesz skrypt, wklejasz klucz bezpośrednio w kodzie, commitujesz do repo. Klucz zostaje na zawsze w historii, nawet jeśli go potem usuniesz z pliku. Rozwiązanie: plik .env z kluczami, .gitignore który go wyklucza, od pierwszej linii kodu.

Jeden klucz do wszystkiego. Kupujesz plan API, dostajesz jeden klucz z pełnymi uprawnieniami. Używasz go do siedmiu różnych skryptów. Jeden skrypt wycieknie, wyciekły wszystkie. Rozwiązanie: osobne klucze dla różnych zastosowań, z minimalnymi uprawnieniami.

Brak eksportów z narzędzi. Trzymasz ważne dane w narzędziu SaaS, zakładasz że zawsze będzie dostępne. Narzędzie nagle wypada z rynku albo znika Twoje konto (błąd billing, spór z ich wsparciem). Tracisz dostęp. Rozwiązanie: regularny eksport danych z każdego narzędzia, które Ci coś ważnego trzyma.

Nieczytelne alerty. Workflow alertuje o błędach, ale na adres, którego nie czytasz, albo na kanał Slacka, w którym jest sto wiadomości dziennie. Alerty ignorowane to alerty, których nie ma. Rozwiązanie: alerty w jednym miejscu, w które i tak patrzysz codziennie, a nie na kanale, który trzeba pamiętać otworzyć.

Zbyt duże zaufanie do AI. Model potrafi napisać skrypt, który wygląda dobrze, ale ma subtelny błąd. Na przykład źle parsuje datę przy końcu miesiąca, pomija rekordy z polskimi znakami, kasuje coś, czego nie powinien. Dopóki nie przetestujesz na małej próbie i nie sprawdzisz efektu, nie wiesz, czy kod faktycznie działa.

Komendy “wyglądające niewinnie”. Niektóre operacje mają nieintuicyjne skutki. Skrypt, który “tylko aktualizuje ceny”, ale przy okazji zeruje pola, których nie podałeś. API, które “tylko odświeża token”, ale przy tym unieważnia stary używany w trzech innych miejscach. Komenda “setup”, która zakłada że arkusz jest pusty i przebudowuje go nawet gdy jest już wypełniony danymi. Każdy taki “destrukcyjny przyjaciel” wymaga: (1) listy znanych pułapek w dokumentacji systemu, (2) zawsze potwierdzenia z kimś przed odpaleniem, (3) backupu przed wykonaniem. Trzy razy uratowało mnie od zerwania pracy, której nie dało się odtworzyć w pół godziny.

Incydent, który mi się przydarzył

Dla konkretu: jedna sytuacja z mojego systemu, która nauczyła mnie więcej niż kilka artykułów o monitoringu.

Mam wewnętrzny panel, do którego zaglądam codziennie, żeby zobaczyć stan systemu: co działa, co wymaga uwagi, gdzie coś stanęło. Jedna z jego sekcji przestała pokazywać dane. Nie pokazała błędu. Pokazała napis „brak danych”.

Nic mnie to nie zaniepokoiło, bo „brak danych” wygląda dokładnie jak święty spokój. Skoro nie ma nic do zgłoszenia, to znaczy, że nie ma problemów.

Sekcja była martwa trzydzieści pięć dni. Przyczyna: uprawnienie, którym się uwierzytelniała, zostało odebrane przy porządkach. Zapytanie zwracało odmowę dostępu, a kod, zamiast tę odmowę pokazać, łapał ją i zwracał pustą listę. Napis „brak danych” był więc prawdą o tym, co kod dostał, i kłamstwem o tym, co się dzieje.

Trzy rzeczy, które z tego wyniosłem:

Pierwsza: pusty wynik i błąd to dwie różne odpowiedzi, i nie wolno ich mieszać. Każde miejsce, w którym coś czytasz z zewnątrz, musi umieć rozróżnić „sprawdziłem i nic tam nie ma” od „nie udało mi się sprawdzić”. Jeśli tego nie rozróżnia, awaria wygląda jak spokój.

Druga: cisza nie jest dowodem, że jest dobrze. Monitoring, który mówi tylko wtedy, gdy jest źle, milczy identycznie w dwóch sytuacjach: gdy wszystko działa i gdy sam nie działa. Dlatego czujka musi sprawdzać, czy sekcja ma dane, nie czy strona się otworzyła. Wszystkie moje dotychczasowe awarie tego typu zwracały poprawną odpowiedź serwera.

Trzecia: usuwając dostęp, wypisz najpierw, kto z niego korzysta. Porządki w uprawnieniach są dobre. Porządki bez listy odbiorców są zamianą jednego problemu na inny, cichszy.

Po tej sytuacji dołożyłem prostą regułę: każda nowa sekcja panelu musi mieć zapisany kontrakt „jak wygląda, gdy ma dane”. Sekcja bez kontraktu to kolejne miejsce, gdzie cisza będzie wyglądać jak spokój. Tak straciłem trzydzieści pięć dni na jednej, a wcześniej podobnie na trzech innych.

Czego unikać

Traktowania bezpieczeństwa jako rzeczy do zrobienia “potem”. Potem oznacza “gdy coś się stanie”. Wtedy jest za późno. Bezpieczeństwo wpisujesz w system od początku: osobny folder dla kluczy, backup od pierwszego dnia, zatwierdzenie przed wysłaniem maila.

Jednego kanału backupu. Chmurowa synchronizacja to wygodna rzecz, ale nie jedyna. Jeśli konto zostanie zablokowane, tracisz dostęp do wszystkiego. Trzy miejsca, trzy różne mechanizmy.

Udostępniania kluczy przez zwykłe kanały. Nigdy mail, nigdy Slack, nigdy SMS. Jeśli musisz przekazać klucz komuś z zespołu, używaj dedykowanego managera haseł albo bezpiecznego kanału. Lepiej: dawaj ludziom własne klucze, nie swoje.

Wyłączania alertów, które Cię irytują. Jeśli alerty przychodzą za często, problem nie jest w alertach. Problem jest w workflow, który produkuje zbyt wiele błędów. Popraw workflow, nie wyłączaj alertów.

Czego nauczyłeś się na tym etapie?

Bezpieczeństwo systemu opiera się na pięciu obszarach: credentials, backup, co pokazywać na zewnątrz, automatyzacje które mogą coś zepsuć, prawda i anty-halucynacja.

Credentials: jedno miejsce, sejfy według tego, kto ma co widzieć, minimum uprawnień, nigdy w kodzie, nigdy w publicznych kanałach. Rotacja po każdym podejrzeniu wycieku, a kończy się nie w momencie wpisania nowej wartości, tylko wtedy, gdy ma ją każdy, kto z klucza czyta, i gdy stara wartość nie została nigdzie. Klucze wyciekają też z wyników narzędzi, nie tylko z Twoich komend, więc chroni mechanizm, a nie kolejna reguła.

Backup: co najmniej trzy miejsca. Lokalnie, w chmurze, fizycznie na dwóch dyskach na zmianę. Plus szyfrowana paczka tego, czego synchronizacja nie obejmuje, i Git dla historii zmian. Automat sprawdza, czy kopie powstają. Backupy danych klientów osobno, na dysku lokalnym, nie w głównym vault i nie tylko w chmurze. Reguła nadrzędna przy cudzej infrastrukturze: backup PIERWSZY krok, zanim cokolwiek dotkniesz. I osobno: synchronizacja to nie backup, bo równie chętnie skopiuje usunięcie jak nowy plik.

Co pokazywać: nazwiska klientów i nazwy firm nigdy publicznie bez pozwolenia. URL-e infrastruktury schowane za własną domeną. Struktura wewnętrznych narzędzi niewidoczna w publicznych materiałach.

Automatyzacje: zatwierdzenie przed wysłaniem, testowanie na próbie, idempotentność, alerty w miejscu, w które patrzysz, przemyślany rollback, treść z zewnątrz jako dane, nie polecenia.

Prawda: każda liczba wymaga źródła, hierarchia (pliki projektu > pamięć > rozmowa > Context7 > “nie wiem”), zakaz słów-uników. AI mówi “nie wiem” zamiast zgadywać.

Najczęstsze błędy początkujących: klucze w Gicie, jeden klucz do wszystkiego, brak eksportu danych, nieczytelne alerty, zbyt duże zaufanie do AI, lekceważenie komend “wyglądających niewinnie”.

Dwa incydenty z własnego systemu: skrypt napisany po to, żeby chronić dane, skasował sześć dni pracy, bo działał w jedną stronę i bez warunku wstępnego. Sekcja panelu była martwa trzydzieści pięć dni, bo kod zamieniał odmowę dostępu na pustą listę, a „brak danych” wygląda jak spokój. Wniosek wspólny: pusty wynik i błąd to dwie różne odpowiedzi, a cisza nie jest dowodem, że jest dobrze.

W następnej części pokażę jak zbudowałem system tak, żeby AI działał zgodnie z moimi wartościami, a nie tylko instrukcjami. Uczciwość w biznesie, etyka w komunikacji, granice, których nie przekracza. To przechodzi poza konfiguracje techniczne. Dotyka filozofii, według której buduje się system.

Twój następny krok: zadanie na dzisiaj

Dwie rzeczy.

1. Zrób audyt credentials (swoich dostępów). Otwórz plik, w którym trzymasz klucze i hasła (jeśli nie masz takiego pliku, to jest pierwszy sygnał, że trzeba zrobić). Dla każdego klucza sprawdź: czy na pewno używasz, czy minimalne uprawnienia, kiedy go generowałeś ostatnio. Klucze nieużywane usuń z systemu. Klucze starsze niż rok rotuj (wygeneruj nowe, zaktualizuj skrypty, stare unieważnij).

2. Sprawdź backup. Zamknij oczy i odpowiedz: co by się stało, gdyby Twój główny komputer przestał działać w tej sekundzie? Jeśli odpowiedź jest “niewiele, odtworzę w kilka godzin z backupu”, jest dobrze. Jeśli jest “tracę miesiące pracy”, natychmiast zaplanuj backup. Dwie godziny roboty, zwraca się pierwszego dnia, gdy coś się dzieje. Zapisz w dzienniku konkretny plan i datę wdrożenia.

Zasoby

Dokumentacja menadżera haseł, z którego korzystasz. 1Password, Bitwarden, KeePass, cokolwiek używasz. Warto przeczytać sekcję “shared vaults” i “security best practices”. Wiele osób ma menadżera, ale używa go tylko do zapisywania haseł, pomijając funkcje, które naprawdę pomagają.
OWASP Top 10. Ogólnodostępny dokument z listą dziesięciu najczęstszych błędów bezpieczeństwa. Napisany dla programistów, ale pierwsze kilka punktów da się czytać każdemu. Zwłaszcza o “secrets in source code” i “broken authentication”.
Dokumentacja backupu systemowego (Time Machine na macOS, historii plików na Windows, snapper na Linux). Wbudowane narzędzia backupu są zaskakująco dobre. Godzina konfiguracji, dwadzieścia lat spokoju.

Ten artykuł jest częścią cyklu “Od zera do kompletnego systemu AI w kwartał”. Krok po kroku opisuję jak zbudowałem system AI do zarządzania firmą i rozwojem osobistym, żebyś mógł wdrożyć podobny u siebie. W następnej części: wartości wbudowane w system, czyli jak AI działa zgodnie z Twoimi zasadami. Masz pytania? Napisz. Odpowiadam osobiście.

Żeby nie przegapić kolejnych części, zaobserwuj mój profil. Nowe artykuły publikuję regularnie.

Marcin Atamańczuk, Technologia w służbie życia, nie odwrotnie.