Jak wybrać narzędzia do zarządzania dostępem uprzywilejowanym: przewodnik zakupowy PAM

do czego naprawdę służy PAM

Dostęp uprzywilejowany to dostęp, który może coś zmienić. Administrator, który może zresetować hasła, konto serwisowe, które może wdrażać na produkcję, rola chmurowa, która może uruchomić lub usunąć infrastrukturę, inżynier sieciowy, który może przekonfigurować firewall. To konta, na których zależy atakującemu, bo przejęcie jednego z nich to niemal przejęcie całej firmy. Skradzione dane uwierzytelniające pojawiają się w dużej części naruszeń, a skradziony dostęp, który akurat jest uprzywilejowany, to najkrótsza droga od punktu zaczepienia do katastrofy.

Zadaniem PAM jest sprawić, że te potężne konta trudniej ukraść, trudniej nadużyć i łatwiej rozliczyć. Robi to przez połączenie kilku elementów: zamknięcie danych uwierzytelniających pod kluczem, przyznawanie dostępu tylko wtedy, gdy jest naprawdę potrzebny, obserwowanie, co dzieje się podczas uprzywilejowanej sesji, i usuwanie stałych uprawnień admina, które czekają, aż ktoś je nadużyje. Różne narzędzia kładą nacisk na różne elementy tego zestawu i to pierwsza rzecz, którą trzeba sobie wyjaśnić, zanim zaczniesz kupować.

gdzie kupujący popełniają błędy

Największy błąd to kupno platformy dopasowanej do organizacji, którą nie jesteś. Enterprise'owe pakiety PAM buduje się z myślą o środowiskach z dedykowanymi zespołami identity, które są w stanie je prowadzić. Wrzuć taki pakiet do firmy bez takich rąk do pracy, a dostaniesz shelfware: drogi vault trzymający ułamek kont uprzywilejowanych, podczas gdy reszta dalej działa na stałych uprawnieniach admina i współdzielonych hasłach.

Drugi to myślenie, że PAM to tylko sejf na hasła i nic więcej. Vaulting uprzywilejowanych danych uwierzytelniających jest przydatny, ale jeśli konto cały czas ma stały dostęp, a vault po prostu wydaje hasło na żądanie, dodałeś krok wypożyczenia, a nie usunąłeś ryzyko u źródła. Cenniejsza jest idea redukcji stałych uprawnień od samego początku, tak by potężny dostęp nie istniał, dopóki ktoś go nie potrzebuje.

Trzeci to pokrycie serwerów i zignorowanie reszty. Klasyczny PAM wyrósł wokół logowania się na serwery. Twój dostęp uprzywilejowany dziś jest rozproszony po konsolach chmurowych, panelach admina SaaS, pipeline'ach CI/CD, Kubernetesie, urządzeniach sieciowych i roju tożsamości maszynowych. Narzędzie, które zabezpiecza adminów Windows i Linux, podczas gdy twój root w chmurze i sekrety DevOps stoją niezabezpieczone, pokryło część najłatwiejszą do zademonstrowania i pominęło miejsce, w którym faktycznie żyje spora część dzisiejszego ryzyka.

Czwarty to niedocenienie wdrożenia. PAM dotyka codziennej pracy ludzi, którzy mają najmniej cierpliwości do tarcia. Jeśli narzędzie spowalnia im pracę, a mają moc, by je omijać, będą to robić, a twoje pokrycie będzie się po cichu kruszyć. Wdrożenie to trudna część i to ta część, której nigdy nie pokazuje demo.

Pod tymi czterema błędami leży ten sam warunek wstępny: nie da się chronić dostępu uprzywilejowanego, którego nie potrafisz wypisać. Znajomość każdego konta uprzywilejowanego, ludzkiego i maszynowego, tego, gdzie żyje, do czego sięga i czy ma stałe uprawnienia, to dane wejściowe, które nadają reszcie decyzji realny kształt.

zanim zaczniesz kupować: znajdź swój dostęp uprzywilejowany

Zanim spojrzysz na choćby jedno narzędzie, zbuduj obraz sytuacji. Znajdź swoich ludzkich adminów, w tym prywatne konta admina, które ludzie stworzyli sobie dla wygody, i wspólne konta, których hasło siedzi w arkuszu. Znajdź konta serwisowe i tożsamości maszynowe z uprawnieniami, których w większości firm jest znacznie więcej niż tych ludzkich. Znajdź role chmurowe z szeroką mocą: odpowiedniki roota, ownera i globalnego admina. Znajdź, kto ma dostęp do twoich najcenniejszych systemów i czy ten dostęp jest stały, czy przyznawany na żądanie.

To zwykle ludzi zaskakuje, bo dostęp uprzywilejowany narasta dokładnie tak samo jak każdy inny dostęp. Ktoś potrzebował admina do projektu, dostał go i nigdy nie stracił. Konto serwisowe stworzono z szerokimi uprawnieniami, bo zawężanie ich było kłopotliwe. Kontraktora zrobiono adminem, a współpraca się skończyła. Tożsamości maszynowych jest dziś mniej więcej 82 razy więcej niż ludzkich, a prawie połowa z nich ma wrażliwy lub uprzywilejowany dostęp (CyberArk, 2025), co oznacza, że populacja uprzywilejowana, którą najbardziej musisz ogarnąć, w dużej mierze to nie ludzie i w dużej mierze jest niewidoczna, dopóki nie zaczniesz szukać.

Zorientuj się też, w jakim przedziale jesteś. Dziesięcioosobowy startup, który wszystko trzyma na jednym koncie chmurowym, ma zupełnie inny problem z PAM niż tysiącosobowa firma z centrami danych, organizacją DevOps i regulowanymi obciążeniami. Decyzja o zakresie liczy się tu bardziej niż marka.

kategoria w prostych słowach

vaulting i rotacja danych uwierzytelniających

Klasyczny rdzeń. Uprzywilejowane hasła, klucze i sekrety trzymane są w vaulcie, a nie w głowach ludzi czy w arkuszu, wypożyczane na żądanie i automatycznie rotowane, tak by wyciekłe dane uwierzytelniające miały krótką żywotność. Naprawdę przydatne przy kontach współdzielonych i kontach break-glass. Sam w sobie nie redukuje stałych uprawnień, więc traktuj go jako jeden element, a nie całą odpowiedź.

zarządzanie sesją, monitorowanie i nagrywanie

Narzędzie pośredniczy w uprzywilejowanej sesji przez proxy albo bramkę, więc admin łączy się przez nie, a nie bezpośrednio. Dzięki temu możesz nagrać, co się wydarzyło, monitorować to na żywo i przerwać sesję, jeśli coś wygląda podejrzanie. Tu leży spora część wartości audytowej i rozliczalnej, i często właśnie tego chce regulator albo osoba prowadząca dochodzenie: zapisu, kto co zrobił z dostępem uprzywilejowanym i kiedy.

dostęp just-in-time i zero stałych uprawnień

Dzisiejszy środek ciężkości i część, w stronę której warto zmierzać. Zamiast trzymać przy adminie uprawnienia uprzywilejowane cały czas, prosi on o dostęp, gdy go potrzebuje, dostaje go na ograniczone okno czasowe z podanym powodem, a potem dostęp jest automatycznie odbierany. To zmniejsza powierzchnię ataku w sposób, jakiego sam vaulting nie daje, bo przez większość czasu po prostu nie ma stałych uprawnień do kradzieży. Jeśli narzędzie nie potrafi zrobić sensownego dostępu just-in-time, sprzedaje ci model sprzed lat.

endpoint privilege management

Usunięcie uprawnień lokalnego administratora z codziennych laptopów i zastąpienie ich podnoszeniem uprawnień per aplikacja. To jeden z ruchów o najwyższym zwrocie, jaki jest dostępny, bo lokalny admin na maszynie zwykłego użytkownika to ulubiony punkt oparcia dla ransomware i malware. Niektóre pakiety PAM mają to wbudowane, inne traktują to jako osobny produkt. Tak czy inaczej, odebranie lokalnego admina ludziom, którzy nie potrzebują go na co dzień, warto zrobić wcześnie.

zarządzanie sekretami dla maszyn i DevOps

Klucze API, tokeny, certyfikaty i dane uwierzytelniające, których pipeline'y CI/CD i aplikacje używają do komunikacji między sobą. To mocno pokrywa się z bezpieczeństwem tożsamości maszynowych (NHI) i ma znaczenie, bo systemy zautomatyzowane często działają z najszerszymi uprawnieniami i najgorszą higieną. Jeśli twoje środowisko jest cloud-native albo mocno DevOps-owe, ta część może mieć większe znaczenie niż klasyczny vaulting kont ludzkich adminów.

dostęp uprzywilejowany w chmurze i zdalny

Platformy chmurowe mają własny model uprawnień, a zarządzanie tam entitlementami (czasem osobna kategoria, cloud infrastructure entitlement management) coraz częściej wchodzi w skład tego obrazu. Podobnie jak dostęp uprzywilejowany dostawców i stron trzecich: danie zewnętrznemu kontraktorowi albo dostawcy dostępu admina do jednego systemu, z nagrywaniem i limitem czasowym, bez oddawania mu VPN-a i swobody po całej sieci.

jak to jest wdrażane

Dwie szerokie architektury. Narzędzia oparte na agentach instalują oprogramowanie na celach albo endpointach, co umożliwia głębszą kontrolę, jak endpoint privilege management, ale dokłada footprint do zarządzania. Narzędzia oparte na proxy albo bramce pośredniczą w połączeniach bez agenta na każdym celu, co jest lżejsze, ale pokrywa węższy zestaw działań. Większość realnych wdrożeń kończy się na mieszance obu, a właściwa proporcja zależy od tego, co chronisz.

co pasuje do twojej wielkości i sytuacji

• Lean / mała firma (poniżej ~50 osób) · Jak wygląda dobre podejście: Możesz jeszcze w ogóle nie potrzebować platformy PAM. Oddziel konta admina od kont do codziennego użytku, włącz MFA na każdym adminie, usuń lokalnego admina z laptopów i przenieś współdzielone dane uwierzytelniające oraz konta break-glass do porządnego menedżera haseł. Korzystaj z funkcji ról uprzywilejowanych, które już ma twoja chmura. · Czego unikać: Pełna platforma PAM. Przerośnie twoją zdolność, by nią zarządzać.
• Rosnący mid-market (50 do 500) · Jak wygląda dobre podejście: PAM dopasowany do skali, skoncentrowany na twoich najcenniejszych zasobach: umieść w vaultcie krytyczne współdzielone dane uwierzytelniające, nagrywaj sesje na systemach, które mają największe znaczenie, i używaj dostępu just-in-time tam, gdzie pozwala na to twój stack. Endpoint privilege management, by szeroko usunąć lokalnego admina. · Czego unikać: Próba podłączenia wszystkich kont uprzywilejowanych naraz. Zawęź zakres do tego, co zabolałoby najbardziej.
• Większa firma / wiele podmiotów (500 do 2000) · Jak wygląda dobre podejście: Pełna platforma PAM z dostępem just-in-time jako domyślnym trybem, nagrywaniem sesji, zarządzaniem sekretami dla DevOps i zarządzanym dostępem dostawców. Wyznaczony właściciel, który faktycznie nią zarządza. · Czego unikać: Stałe uprawnienia pozostawione obok vaulta, co po cichu podważa cały sens.
• Enterprise / regulowane (2000+, finanse) · Jak wygląda dobre podejście: Dostęp uprzywilejowany zarządzany od początku do końca: zero stałych uprawnień, nagrywanie i przegląd, rozdzielenie obowiązków, sekrety tożsamości maszynowych i dowody audytowe, których na żądanie oczekuje twój regulator. · Czego unikać: Wszystko, co nie potrafi dostarczyć takich dowodów, albo co da się obsłużyć małym zespołem.

Niektóre sytuacje zmieniają kształt rozwiązania niezależnie od wielkości firmy:

Cloud-native i mocno DevOps-owe. Jeśli większość twoich uprawnień żyje w rolach chmurowych, pipeline'ach i tożsamościach maszynowych, a nie w ludzkim logowaniu na serwery, postaw na zarządzanie sekretami i entitlementy chmurowe bardziej niż na klasyczny vaulting. Stary, skoncentrowany na serwerach model PAM może pominąć większość twojej realnej ekspozycji.

Dostawcy usług zarządzanych i każdy, kto trzyma klucze klientów. Jeśli twój zespół ma dostęp uprzywilejowany do środowisk innych organizacji, twój problem z PAM jest większy, niż sugeruje liczba osób w zespole, a nagrywanie sesji i ścisły dostęp just-in-time przestają być miłym dodatkiem.

Dostawcy i strony trzecie z dostępem admina. Częste i niedoceniane ryzyko. Jeśli zewnętrzne strony potrzebują dostępu uprzywilejowanego, pośredniczony i nagrywany dostęp dostawców jest często pojedynczą najcenniejszą zdolnością PAM, jaką możesz wdrożyć.

Technologia operacyjna i systemy legacy. Fabryki, zakłady użyteczności publicznej i stare systemy, które nie przyjmą agenta ani nowoczesnego protokołu, potrzebują PAM, który spotka je tam, gdzie są, zwykle przez bramkę. Jeśli to twój przypadek, zrób z tego jawne kryterium oceny.

skąd to wziąć: cztery drogi

Wykorzystaj to, co już masz. Platformy chmurowe mają wbudowane zarządzanie rolami uprzywilejowanymi i ograniczone czasowo podnoszenie uprawnień. Twój dostawca tożsamości (IdP) może oferować role just-in-time. Dobry menedżer haseł obsłuży współdzielone dane uwierzytelniające i konta break-glass w małej firmie. Dla lean organizacji oddzielenie kont admina, wymuszenie na nich MFA, usunięcie lokalnego admina i użycie tych wbudowanych funkcji pokrywa większość realnego ryzyka.

Kup skoncentrowaną, punktową zdolność. Endpoint privilege management, by usunąć lokalnego admina, albo vault na współdzielone dane uwierzytelniające, można kupić i wdrożyć samodzielnie. To często najlepiej zwracające się pieniądze na PAM, jakie może wydać firma z mid-marketu, właśnie dlatego, że zakres jest wystarczająco wąski, by go domknąć.

Kup pełną platformę PAM. Uzasadnione, gdy masz duży i zróżnicowany zbiór zasobów uprzywilejowanych, realną presję regulacyjną i zespół do jej prowadzenia. Możliwości są realne. Ciężar operacyjny też.

Sięgnij po pomoc z zewnątrz. PAM to kategoria bezpieczeństwa, w której zewnętrzna pomoc najczęściej się zwraca, bo wdrożenie to trudna część, a spartaczone wdrożenie jest gorsze niż brak wdrożenia. Ustalenie co-managed albo wdrożenie prowadzone przez doradcę może być różnicą między platformą w pełni wdrożoną a taką, która dołącza do klubu trzyletnich wdrożeń.

kryteria decyzyjne, które faktycznie mają znaczenie

• Szerokość pokrycia · Na co zwrócić uwagę: Czy sięga do całego twojego dostępu uprzywilejowanego: serwerów, konsol chmurowych, admina SaaS, urządzeń sieciowych, DevOps i tożsamości maszynowych oraz ewentualnej technologii operacyjnej, czy tylko do tych łatwych?
• Dostęp just-in-time · Na co zwrócić uwagę: Czy potrafi przyznawać dostęp uprzywilejowany na żądanie i automatycznie go odbierać, tak byś mógł zmierzać w stronę zera stałych uprawnień, zamiast po prostu trzymać stałe uprawnienia w vaultcie?
• Kontrola sesji · Na co zwrócić uwagę: Czy potrafi nagrywać, monitorować i przerywać sesje uprzywilejowane oraz dostarczyć ten zapis na potrzeby audytu?
• Endpoint privilege management · Na co zwrócić uwagę: Czy potrafi usunąć lokalnego admina i podnosić uprawnienia per aplikacja, czy potrzebujesz do tego osobnego narzędzia?
• Sekrety maszynowe i DevOps · Na co zwrócić uwagę: Czy obsługuje uprzywilejowane dane uwierzytelniające tożsamości maszynowych, które zwykle stanowią większą populację?
• Model wdrożenia · Na co zwrócić uwagę: Agent czy bramka i czy to pasuje do twojego środowiska, w tym systemów, które nie przyjmą agenta?
• Możliwość wdrożenia · Na co zwrócić uwagę: Jak realne jest pełne wdrożenie z zespołem, który masz? To kryterium, które najlepiej przewiduje sukces i to, które kupujący najczęściej pomijają.
• Break-glass · Na co zwrócić uwagę: Co się dzieje w sytuacji awaryjnej, gdy sam system PAM jest niedostępny? Ścieżka break-glass musi istnieć i być bezpieczna.
• Integracja · Na co zwrócić uwagę: Czy pasuje do twojego dostawcy tożsamości, chmury i procesów, czy dokłada kolejne silosy?
• Dowody i UE · Na co zwrócić uwagę: Czy potrafi wygenerować raportowanie, jakiego chce regulator albo ubezpieczyciel, i gdzie fizycznie żyją te dane?

Jeśli masz zapamiętać jeden wiersz, niech to będzie możliwość wdrożenia. Skromne narzędzie w pełni wdrożone bije potężne narzędzie, które pokrywa jedną trzecią twoich kont uprzywilejowanych, bo konta, których nie pokrywa, to dokładnie te, których użyje atakujący.

jak wycenia się PAM i ile to naprawdę kosztuje

PAM wycenia się zwykle za uprzywilejowanego użytkownika, za zarządzane konto albo cel, albo za moduł, a platformy plasują się w droższym końcu narzędzi identity. Licencja to często mniejsza część realnego kosztu. Zaplanuj budżet na resztę uczciwie:

• Usługi profesjonalne. Wdrożenia enterprise'owego PAM słyną z długich, drogich zaangażowań usługowych. Znalezienie kont uprzywilejowanych, podłączenie ich, integracja i dostrajanie polityk to prawdziwa praca i to często tam idzie większość wydatków pierwszego roku.
• Bieżąca obsługa. Ktoś musi to prowadzić: vault, polityki, podłączanie nowych systemów, wyjątki, testy break-glass. Wlicz do budżetu osobę, nie tylko platformę.
• Footprint agenta. Jeśli narzędzie jest oparte na agentach, zarządzasz teraz agentami w całym środowisku, co samo w sobie generuje narzut.
• Odnowienie. Uważaj na podwyżkę i na to, co z twoim rachunkiem robi przejście na wyższy poziom, by dostać just-in-time albo pokrycie DevOps.

Myśl w kategoriach całkowitego kosztu na przestrzeni dwóch, trzech lat, wliczając usługi i wysiłek operacyjny, a argument za rozpoczęciem wąsko i domknięciem tego zwykle bije argument za kupieniem szeroko i utknięciem w połowie.

jak przeprowadzić ewaluację

Trzymaj wąski zakres i udowadniaj trudne rzeczy wcześnie. Zbuduj shortlistę, która obejmuje opcję mniejszą, niż myślisz: natywne role uprzywilejowane chmury plus endpoint privilege management, zestawione ze skoncentrowaną albo pełną platformą.

Wysyłaj celne pytania, a nie ogólne RFP. Te, które odróżniają narzędzia od siebie: Jak realizujecie dostęp just-in-time i jak faktycznie wygląda odbieranie uprawnień? Jakie macie pokrycie dla uprawnień w chmurze i DevOps, a nie tylko na serwerach? Czy potrzebujecie agenta na każdym celu, a co z systemami, które go nie przyjmą? Jak działa break-glass, gdy wasz system nie działa? Jak realistycznie wygląda harmonogram wdrożenia dla środowiska takiego jak nasze i ile z tego to usługi?

Potem przeprowadź proof of concept na swoim prawdziwym środowisku. Podłącz kilka najważniejszych systemów krytycznych, nie zabawkę. Przyznaj i odbierz sesję uprzywilejowaną just-in-time i zobacz, jak to wygląda z perspektywy admina. Włącz nagrywanie sesji dla jednego najcenniejszego systemu. Przetestuj ścieżkę break-glass, udając, że system PAM nie działa. Jeśli sekrety DevOps mają dla ciebie znaczenie, podłącz jeden prawdziwy pipeline. Ustal kryteria sukcesu, zanim zaczniesz.

I zbierz referencje z jednym konkretnym pytaniem: ile faktycznie trwało wasze wdrożenie, co utknęło i co wciąż nie zostało podłączone. Luka między zamierzonym a faktycznym zakresem to najbardziej szczera rzecz, jaką może ci powiedzieć referencja.

pułapki, które zatrzymują wdrożenie

Typowa porażka PAM to zatrzymane wdrożenie: kupione z dobrymi intencjami, wdrożone na łatwych systemach i nigdy niedokończone, przez co najbardziej ryzykowne konta zostają dokładnie tak samo odsłonięte jak wcześniej, podczas gdy dashboard świeci na zielono na tych, które nigdy nie były problemem.

Tuż za nią jest vault, który staje się wąskim gardłem. Jeśli wypożyczenie danych uwierzytelniających jest wolne albo niewygodne, inżynierowie znajdą sposób, by to ominąć, a twoje pokrycie wydrąża się od środka. Potem jest stałe uprawnienie zostawione obok vaulta, więc dodałeś krok, nie usuwając ryzyka u źródła. Jest uprawnienie w chmurze i DevOps po cichu pozostawione poza zakresem, bo narzędzie wyrosło wokół serwerów. I jest konto break-glass, awaryjny admin, który omija cały system, co jest zarówno konieczne, jak i ulubionym celem, i co wiele wdrożeń traktuje jako refleksję po fakcie.

Kształt tych wszystkich pułapek jest ten sam: dostęp uprzywilejowany jest zarządzany tylko tak dobrze, jak jego najsłabiej pokryty zakątek, a to właśnie w zakątki idą atakujący.

gdzie to spotyka się z przepisami

Dostęp uprzywilejowany siedzi wprost w środku regulacji. Środki zarządzania ryzykiem NIS2 na mocy artykułu 21 obejmują kontrolę dostępu i szersze oczekiwanie, że zarządzasz tym, kto może dotrzeć do systemów krytycznych. DORA dla podmiotów finansowych wymaga kontroli dostępu uprzywilejowanego i zdalnego przez swoje standardy techniczne, w tym least privilege i rozliczalność. ISO 27001 oczekuje, że dostęp uprzywilejowany będzie ograniczony i przeglądany. A ubezpieczyciele cybernetyczni coraz częściej pytają wprost o kontrole dostępu uprzywilejowanego, bo wiedzą, że to jest droga, którą idzie ekipa ransomware. Żadna z tych regulacji nie narzuca konkretnego produktu, ale wszystkie wskazują w tę samą stronę: to stały, nienadzorowany, współdzielony dostęp uprzywilejowany trzeba wyeliminować.

To kontekst do priorytetyzacji, nie porada prawna, a szczegóły zależą od twojego sektora i kraju.

ścieżka etapami

Raczkowanie: zinwentaryzuj swoje konta uprzywilejowane, ludzkie i maszynowe. Oddziel konta admina od kont codziennych, by nikt nie przeglądał maila jako administrator domeny. Włącz MFA na każdym koncie uprzywilejowanym. Usuń lokalnego admina z laptopów przez endpoint privilege management. Wyciągnij współdzielone dane uwierzytelniające i konta break-glass z arkuszy do porządnego vaulta albo menedżera haseł. Większość z tego nie wymaga platformy klasy enterprise, a usuwa dużą część ryzyka.

Chodzenie: umieść w vaultcie i rotuj dane uwierzytelniające dla najbardziej krytycznych systemów. Włącz nagrywanie sesji tam, gdzie rozliczalność ma największe znaczenie. Wprowadź dostęp just-in-time na systemach, które go wspierają, tak by stałe uprawnienia zaczęły się kurczyć. Wciągnij w obraz uprzywilejowane role chmurowe, bo to tam żyje spora część dzisiejszego ryzyka.

Bieganie: zmierzaj w stronę zera stałych uprawnień, tak by dostęp uprzywilejowany był przyznawany na żądanie i automatycznie odbierany jako norma, a nie wyjątek. Weź pod zarządzanie sekrety DevOps i maszynowe. Pośrednicz w dostępie dostawców i go nagrywaj. Nieprzerwanie obserwuj nadużycia kont uprzywilejowanych. Na tym etapie dostęp uprzywilejowany przestaje być stosem ryzykownych stałych uprawnień, a staje się czymś, co przyznajesz, obserwujesz i za co się rozliczasz.

od czego zacząć

PAM to jedna z najbardziej wartościowych rzeczy, jakie możesz zrobić dla swojego bezpieczeństwa, i jedna z tych, które najłatwiej zrobić źle, a różnicę niemal zawsze robi zakres. Firmy, którym się udaje, wybierają granicę, którą da się domknąć, zwykle zaczynając od oddzielenia kont admina, wymuszenia na nich MFA i usunięcia lokalnego admina, a po platformę sięgają dopiero wtedy, gdy dokładnie wiedzą, co ma ona pokryć.