Zero trust w 2026: uczciwy przewodnik dla mid-marketu

co zero trust naprawdę oznacza

Odrzuć marketing, a rdzeń jest prosty do wypowiedzenia. Przestań ufać sieci. Traktuj każdą sieć jako wrogą, łącznie z własnym biurem i własną chmurą. Uwierzytelniaj i autoryzuj każde żądanie od każdego użytkownika, każdego urządzenia i każdego obciążenia (workload). Przyznawaj tylko tyle uprawnień, ile potrzeba na to konkretne żądanie, i ani odrobiny więcej. Załóż, że już jesteś naruszony, i projektuj tak, żeby jedno przejęcie nie zamieniło się w swobodny spacer po całym budynku.

Definicją referencyjną jest NIST Special Publication 800-207, Zero Trust Architecture. Jej centralna teza mówi, że zaufanie nigdy nie jest przyznawane domyślnie i musi być stale weryfikowane. Architektura, która czyni to praktycznym, rozdziela decyzję od egzekwowania: policy decision point ocenia każde żądanie względem twoich reguł, korzystając z tożsamości, stanu urządzenia, lokalizacji i innego kontekstu, a policy enforcement point stoi przed zasobem i robi to, co każe mu decision point. Decision point może odpowiedzieć tak, nie, albo tak na razie, a zgoda jest ograniczona czasowo, więc gdy kontekst się zmieni, gdy urządzenie przestanie spełniać wymogi albo sesja zacznie wyglądać podejrzanie, zgodę można cofnąć bez czekania na kolejne logowanie. To rozdzielenie sprawia, że model jest czymś więcej niż sloganem: w starszym projekcie opartym na perymetrze decyzja zapadała raz, na brzegu, podczas gdy projekt zero trust przenosi decyzję obok każdego zasobu i wykonuje ją bez przerwy. CISA publikuje praktyczne uzupełnienie, swój Zero Trust Maturity Model, który daje etapy, względem których możesz się mierzyć, zamiast binarnego zdałeś/nie zdałeś.

Tożsamość jest dziś punktem kontrolnym. Perymetr sieciowy, na który zero trust było reakcją, się rozpłynął: ludzie pracują z domu, z kawiarni i z telefonów, a dane żyją w SaaS, którego sam nie hostujesz. Jedyną rzeczą obecną w każdym żądaniu dostępu jest tożsamość twierdząca, że jest kimś albo czymś, dlatego poważny wysiłek zero trust to w gruncie rzeczy wysiłek wokół tożsamości, tylko pod szerszą nazwą. Z nastawieniem łatwo się zgodzić; praca leży w architekturze, a to jest kierunek podróży, nie pudełko, które kupujesz.

nie zrobisz zero trust na mapie, której nie masz

Każde realne wdrożenie zaczyna się od odkrywania (discovery). Zanim cokolwiek wyegzekwujesz, mapujesz swoje tożsamości, urządzenia i faktyczne przepływy między systemami. To część, którą pomija prezentacja produktu, i jej pominięcie jest najczęstszym powodem, dla którego projekty upadają. Metoda, której używają praktycy, to najpierw logowanie, potem egzekwowanie: wdrażasz politykę w trybie tylko-obserwacja i patrzysz, jaki realny ruch by zablokowała, naprawiasz to, co legalne, a co by złamała, potem włączasz egzekwowanie, i dopiero gdy polityka jest naprawdę kompletna, przełączasz się na domyślną odmowę. Odwróć tę kolejność, a pierwszego dnia zablokujesz prawdziwym ludziom prawdziwą pracę.

Faza tylko-obserwacji to też moment, w którym odkrywasz, jak niewiele ze swojego realnego dostępu naprawdę rozumiałeś. Diagram na ścianie pokazuje czysty zestaw systemów, które sensownie się ze sobą komunikują; logi pokazują arkusz finansowy ciągnący dane z bazy, której nikt nie udokumentował, narzędzie marketingowe uwierzytelnione w CRM przez grant skonfigurowany przez kogoś, kto odszedł rok temu, i serwer, którego nikt nie jest właścicielem, a od którego zależy połowa firmy. Wszystko to trzeba dopuścić albo świadomie zrozumieć i wyłączyć, zanim domyślna odmowa stanie się bezpieczna. Migracja BeyondCorp w Google to przypadek referencyjny, pouczający właśnie dlatego, że Google miało wszystkie możliwe atuty, a i tak zajęło to ponad cztery lata, a najtrudniejszą częścią okazała się jakość danych, nie technologia: gdy decyzje o dostępie zależą od ewidencji urządzeń, niewielki odsetek niedopasowanych rekordów przekłada się na tysiące realnych użytkowników zablokowanych z dostępu. Silnik polityk może decydować tylko na podstawie danych, które ma, więc nakarm go niepełnym obrazem, a na dużą skalę będzie podejmował pewne siebie, błędne decyzje.

w 2026 większość podmiotów proszących o dostęp to nie ludzie

Tożsamość, która loguje się twarzą i hasłem, jest dziś mniejszością wśród tożsamości w twoim środowisku. Tożsamości maszynowe przewyższają liczebnie tożsamości ludzkie w stosunku około 82 do 1, a niemal połowa z nich ma dostęp wrażliwy lub uprzywilejowany, według raportu CyberArk 2025 State of Machine Identity Security. To samo badanie pokazało, że 79% liderów bezpieczeństwa spodziewa się wzrostu liczby tożsamości maszynowych nawet o 150% w nadchodzącym roku, że 72% organizacji miało w ostatnim roku co najmniej jedną awarię związaną z certyfikatem, a 50% zgłosiło incydent lub naruszenie wynikające z przejęcia tożsamości maszynowej. Większość twojego dostępu żyje na kontach, które nigdy nie zostały zaprojektowane do zarządzania jak ludzie, a spora ich część trzyma klucze do twoich najbardziej wrażliwych systemów.

Systemy tożsamości zbudowane z myślą o ludziach zawodzą tu ze strukturalnych powodów. Konto serwisowe, klucz API czy tożsamość obciążenia (workload) rzadko ma właściciela, rzadko przechodzi przegląd, bo proces przeglądu wyciąga listę ludzi, i zwykle nosi stałe uprawnienia bez terminu wygaśnięcia i bez nikogo, kto by je obserwował. Człowiek, który odchodzi, uruchamia proces offboardingu; konto serwisowe, które przeżyło swój cel, nie uruchamia nic. Poprawką jest traktowanie maszyn jako tożsamości pierwszej kategorii, a nie hydrauliki, czyli nadanie każdemu obciążeniu krótkotrwałej, kryptograficznie weryfikowalnej tożsamości, wydawanej w momencie uruchomienia i rotowanej automatycznie, zamiast długożyjącego sekretu wklejonego do pliku konfiguracyjnego. Otwartym standardem do tego jest SPIFFE, wdrażany przez SPIRE, który nadaje obciążeniom weryfikowalne tożsamości bez współdzielonych, statycznych sekretów. Takie konta narastają szybciej, niż ktokolwiek jest w stanie śledzić, bo utworzenie jednego to rutynowa minuta pracy developera, podczas gdy usunięcie wymaga, żeby ktoś wiedział, że ono istnieje, wiedział, co od niego zależy, i był pewien, że wyłączenie go nie zepsuje produkcji. Pierwszy praktyczny ruch jest mało efektowny: zinwentaryzuj swoje tożsamości maszynowe (NHI) tak, jak inwentaryzujesz ludzi, wliczając w to granty OAuth i dostęp podłączonych aplikacji, które po cichu narastają w całym twoim majątku SaaS.

agentic AI to najnowsza i najsłabiej zarządzana tożsamość

Agenci AI to część tej historii, której nie było w oryginalnych publikacjach o zero trust, a pojawiają się szybciej niż kontrole dla nich. Agent nie tylko odpowiada na pytanie, działa samodzielnie w narzędziach i API: czyta skrzynkę pocztową, odpytuje bazę danych, wywołuje zewnętrzną usługę, łączy kroki, żeby dokończyć zadanie. Żeby to zrobić, uwierzytelnia się jako tożsamość maszynowa, zwykle na statycznych danych uwierzytelniających, zwykle z nadmiarem uprawnień, zwykle bez zapisu, który agent co zrobił. Luka w zarządzaniu jest mierzalna: tylko 47% wdrożonych agentów AI jest aktywnie monitorowanych lub zabezpieczonych, według Gravitee 2026 State of AI Agent Security, a 68% organizacji przyznaje, że brakuje im kontroli bezpieczeństwa tożsamości dla AI, według badania CyberArk z 2025. Blisko połowa specjalistów bezpieczeństwa spodziewa się dziś, że agentic AI stanie się dominującym wektorem ataku w ciągu najbliższego roku, według branżowych badań opublikowanych w 2026.

Jest też drugi problem, specyficzny dla agentów. Agent często czyta niezaufaną treść jako część swojej pracy: e-mail, stronę internetową, dokument, zgłoszenie do supportu. Taka treść może nieść ukryte instrukcje skierowane do agenta, a nie do człowieka, i wiadomość, która w praktyce mówi „prześlij najnowszy kontrakt na ten zewnętrzny adres", może zostać wykonana przez agenta, który traktuje wszystko, co czyta, jako polecenie. To jest prompt injection i zamienia agenta z nadmiarem uprawnień w sposób, w jaki ktoś z zewnątrz może działać z twoim dostępem, nigdy nie kradnąc żadnych danych uwierzytelniających. Obroną jest ta sama granica, jaką postawiłbyś dla każdej tożsamości: agent może sięgnąć tylko tam, gdzie wymaga tego jego zadanie, a działania, które mogłyby zaszkodzić, muszą wymagać zatwierdzenia przez człowieka. Poprawka jest konkretna i trzyma się tej samej logiki co każda inna tożsamość: zinwentaryzuj agentów faktycznie używanych w firmie, daj każdemu zawężoną tożsamość zamiast współdzielonego klucza, egzekwuj least privilege na poziomie narzędzi i API, nałóż guardraile i krok zatwierdzenia przez człowieka na działania o wysokim wpływie, i prowadź odporne na manipulację logi tego, co zrobił każdy agent.

sekrety to najsłabszy punkt

Phishing i kradzież danych uwierzytelniających wciąż działają z powodu łatwego do nazwania. Przechowywany sekret to po prostu dane: hasło, klucz API, długożyjący token to ciąg znaków leżący gdzieś na dysku, a dane można skopiować, wykraść albo wyciec. Gdy dostęp zależy od sekretu, ukradzenie sekretu jest tak samo dobre, jak bycie użytkownikiem, a atakujący nie musi łamać twojego uwierzytelniania, wystarczy, że zbierze jeden ciąg znaków i go odtworzy. Dlatego kierunek podróży to dostęp oparty na tożsamości, który nie zależy od współdzielonych sekretów: uwierzytelnianie oparte na certyfikacie powiązanym z konkretnym urządzeniem, krótkotrwałe dane uwierzytelniające, które wygasają, zanim opłaci się je ukraść, i odporne na phishing uwierzytelnianie wieloskładnikowe (MFA), którego nie da się przekazać przez fałszywą stronę logowania. Jeśli nie ma sekretu wielokrotnego użytku do ukradzenia, e-mail phishingowy nie ma czego zebrać.

Nie każde uwierzytelnianie wieloskładnikowe jest równe. Kod z aplikacji uwierzytelniającej albo SMS to wciąż sekret, który przechodzi przez człowieka, którego można podstępem skłonić do wpisania go na przekonującej fałszywej stronie, a atakujący uruchamiają zestawy do przekazywania w czasie rzeczywistym, które przechwytują zarówno hasło, jak i kod, i odtwarzają je w kilka sekund. Metody odporne na phishing zamykają tę lukę: sprzętowe klucze bezpieczeństwa i passkeye zbudowane na standardzie FIDO2 wiążą logowanie z konkretną stroną i z kluczem prywatnym, który nigdy nie opuszcza urządzenia, więc fałszywa strona nie ma czego przekazać dalej. Skuteczność MFA przeciwko atakom na dane uwierzytelniające jest dobrze udokumentowana: opublikowane badanie Microsoftu wykazało, że blokuje ono ponad 99,2% ataków polegających na przejęciu konta (Microsoft, 2023), co zwykle czyni uporządkowane wdrożenie MFA pierwszą rzeczą wartą zrobienia. Postęp, do którego warto dążyć, to najpierw MFA wszędzie, potem odporne na phishing MFA na kontach, na których zależy najbardziej, a potem ruch w stronę dostępu, który w ogóle nie zależy od współdzielonego sekretu.

zero trust kończy się na twoim perymetrze, ale twoje dane nie

Tu wgryza się realia mid-marketu. Możesz zastosować zero trust do każdej sieci, którą prowadzisz, i każdego urządzenia, którym zarządzasz, a twoje najbardziej wrażliwe dane wciąż będą siedzieć w platformach SaaS, których nie hostujesz, dostępnych przez granty OAuth i integracje aplikacja-aplikacja, których nigdy nie zinwentaryzowałeś. Podłączona aplikacja z szerokimi scopes to stały dostęp: przeżywa osobę, która ją stworzyła, zachowuje swoje uprawnienia niezależnie od tego, czy ktokolwiek jej jeszcze używa, i leży całkowicie poza jakimikolwiek kontrolami zero trust, które nałożyłeś na własną sieć. Integracja autoryzowana dwa lata temu przez kontraktora, który już odszedł, wciąż ma dostęp do odczytu i zapisu w twoim magazynie plików, i nic w twojej architekturze tego nie obserwuje.

To jest luka, przez którą przeszły wprost największe naruszenia ostatnich lat. Atakujący coraz częściej nie zawracają sobie głowy włamaniem do sieci, której pilnujesz; przejmują integrację zewnętrzną, podłączoną aplikację albo dostawcę ze stałym dostępem do twojego SaaS, i wchodzą jako zaufana tożsamość maszynowa, którą twoje kontrole miały wpuszczać. Grant wygląda legalnie, bo jest legalny, po prostu przeżył powód swojego istnienia i swojego właściciela. Odpowiedzią jest rozciągnięcie tej samej zasady na majątek SaaS, i wygląda to jak reszta tej pracy: zinwentaryzuj podłączone aplikacje i scopes, które trzymają, zastosuj least privilege do grantów integracji, nadaj każdej integracji nazwanego właściciela i przeglądaj je w takim samym rytmie, w jakim przeglądasz dostęp ludzi.

dlaczego projekty zero trust utykają

Warto uczciwie nazwać typowe tryby porażki, bo ich unikanie to większość tej walki. Centralnym błędem jest kupienie produktu i uznanie pracy za skończoną: produkt to warstwa egzekwowania, a egzekwuje on wobec takiego obrazu twojego dostępu, jaki istnieje, więc jeśli ten obraz jest błędny, narzędzie wiernie wyegzekwuje błędną rzecz. Drugim częstym błędem jest cutover typu big-bang, bo polityka nigdy nie jest tak kompletna, jak wygląda, a szkody spadają na prawdziwych użytkowników. Potem jest problem danych: shadow IT i shadow AI oznaczają, że ewidencja zasobów jest niekompletna, więc silnik polityk dosłownie nie ma danych, żeby podjąć decyzję, a za każdym razem, gdy prawdziwy człowiek zostaje zablokowany w prawdziwej pracy, rośnie presja, żeby dodać szeroki wyjątek, i tak postawa domyślnej odmowy po cichu wraca do domyślnego zezwolenia. Ten wzorzec powtarza się na tyle często, że jest przewidywalny: zespół kupuje szanowany produkt, wdraża go, ogłasza kamień milowy, a rok później konta osierocone, konta serwisowe bez właściciela i granty OAuth, których dostawca tożsamości nie widzi, wciąż tam są, pod spodem nowego narzędzia. Gartner prognozował, że do 2026 tylko około 10% dużych przedsiębiorstw będzie mieć dojrzały, mierzalny program zero trust, a skoro nawet największe organizacje w większości tam nie są, lekcja dla mniejszego zespołu brzmi: bądź selektywny, wdrażaj przyrostowo w istniejącym środowisku, zacznij od najsłabszego ogniwa, tak jak definiuje je twój własny model zagrożeń, najpierw loguj, potem egzekwuj, i zdobądź autentyczne zaangażowanie zarządu.

czego zero trust nie naprawia

Wiarygodny opis obejmuje też to, czego dana rzecz nie robi. Zero trust samo w sobie niewiele daje przeciwko atakowi typu denial-of-service, bo to kwestia dostępności, nie dostępu. Nie chroni przejętej płaszczyzny kontroli: silnik polityk, który podejmuje każdą decyzję, jest celem o najwyższej wartości w tej architekturze, więc musi być odizolowany administracyjnie i strzeżony ściślej niż cokolwiek, co chroni. Nie oślepia atakującego, który potrafi obserwować, kto z kim rozmawia, nawet bez czytania treści, bo metadane zdradzają więcej, niż ludzie się spodziewają. I nie powstrzyma insidera, który został sphishowany, przekupiony albo zmuszony do użycia dostępu, który legalnie posiada. Wobec najbardziej zaawansowanych atakujących realistyczny cel przesuwa się z prewencji na szybką, trafną detekcję, dlatego ciągły monitoring i wykrywanie zagrożeń tożsamości (ITDR) stoją obok zero trust. Liczą się dwa praktyczne środki zaradcze: ułóż rzeczy tak, żeby najmniej wrażliwe dane były osiągalne przez pojedynczą osobę, ograniczając blast radius jednego przejętego konta, i wymagaj więcej niż jednej osoby do autoryzacji najbardziej krytycznych działań.

ścieżka dla mid-marketu: od czego naprawdę zacząć

Firma licząca od 50 do 500 osób nie ma czterech lat Google ani jego liczebności zespołu, i nie potrzebuje ich. Błędem byłoby traktowanie modelu dojrzałości jak wyścigu, żeby skończyć wszystkie filary naraz. Tożsamość to filar, który daje największy zwrot za włożony wysiłek, i od niego zaczyna się model CISA: włącz uwierzytelnianie wieloskładnikowe wszędzie, bez cichych wyjątków dla zarządu czy kont serwisowych, usuń stałe uprawnienia, tak żeby dostęp istniał wtedy, gdy jest potrzebny, a nie domyślnie, potem wprowadź tożsamości maszynowe i AI do tej samej ewidencji i tych samych reguł co ludzi, a potem rozciągnij to myślenie na zewnątrz, na SaaS i dostęp stron trzecich, gdzie faktycznie żyje większość twoich danych. Użyj pięciu filarów CISA jako miary, żeby zlokalizować siebie: tożsamość, urządzenia, sieci, aplikacje i obciążenia, oraz dane, i użyj jego etapów dojrzałości, od tradycyjnego przez początkowy i zaawansowany po optymalny, żeby uczciwie ocenić, gdzie leży każdy filar. Cel jest naprawdę wieloletni, ale pierwsze ruchy w stronę widoczności i tożsamości opłacają się same z siebie: znajomość każdej tożsamości, usunięcie stałych uprawnień i włączenie MFA wszędzie od razu obniżają ryzyko, niezależnie od tego, czy jeszcze kiedykolwiek użyjesz słów zero trust.

gdzie to cię zostawia

Zero trust w 2026 to w gruncie rzeczy problem tożsamości. Tożsamość obejmuje dziś ludzi, maszyny i agentów, a maszyny i agenci są większością. Nie da się żadnego z nich zweryfikować, posegmentować ani nim zarządzać, dopóki go nie widzisz, dlatego widoczność jest na pierwszym miejscu, a wszystko inne buduje się na niej. Nic z tego nie wymaga harmonogramu Google ani dużego zespołu bezpieczeństwa. Wymaga popatrzenia, zanim zaczniesz budować, i zaczęcia od tożsamości, bo tam żyje dostęp. Zespoły, którym zero trust wychodzi dobrze, to zwykle te, które najpierw uczciwie zmapowały swoje środowisko, a potem kupiły tylko to, co mapa im podpowiedziała, że jest potrzebne.