Systemy PAM a licencjonowanie Microsoft CAL

RDS, RDS CAL, User CAL, RDP i realne ryzyka audytowe

Wprowadzenie

Wraz z rosnącą dojrzałością organizacji w obszarze cyberbezpieczeństwa coraz częściej wdrażane są systemy klasy PAM (Privileged Access Management). Rozwiązania takie jak Syteca PAM porządkują dostęp uprzywilejowany, eliminują hasła znane użytkownikom, wprowadzają audyt i nagrywanie sesji oraz znacząco podnoszą poziom kontroli nad infrastrukturą.

Równolegle jednak bardzo często pojawia się pytanie:

czy sposób realizacji dostępu – np. przez PAM, konto współdzielone lub bastion – wpływa na licencjonowanie Microsoft?

Krótka odpowiedź brzmi: nie.

Dłuższa – i praktycznie istotna – wymaga dokładnego wyjaśnienia, ponieważ właśnie w tym miejscu organizacje najczęściej wpadają w niedolicencjonowanie, które wychodzi na jaw dopiero podczas audytów.

Ten artykuł porządkuje:

• czym są systemy PAM i jaka jest ich rola,
• jak Microsoft interpretuje dostęp do Windows Server,
• kiedy wymagane są Windows Server CAL i RDS CAL,
• dlaczego konta współdzielone nie zmniejszają obowiązków licencyjnych,
• oraz jak wygląda to w praktyce podczas audytów.

Czym są systemy PAM i jaka jest ich rola

PAM (Privileged Access Management) to systemy służące do zarządzania dostępem uprzywilejowanym – głównie kontami administratorów, kontami technicznymi oraz dostępem do krytycznych systemów (serwery, bazy danych, systemy operacyjne, urządzenia sieciowe).

W praktyce system PAM:

• pośredniczy w dostępie do systemów docelowych,
• przechowuje poświadczenia w sejfie (vault),
• bardzo często wymusza użycie kont współdzielonych,
• rejestruje i audytuje sesje (RDP, SSH, itp.),
• eliminuje bezpośredni dostęp do haseł.

Syteca PAM jest przykładem takiego rozwiązania – pełni rolę kontrolowanego punktu dostępu (bastiona), przez który użytkownicy łączą się z systemami Windows, Linux czy urządzeniami sieciowymi.

I tu pojawia się kluczowe nieporozumienie.

System PAM a licencjonowanie Microsoft

Z punktu widzenia Microsoft:

• system PAM nie jest przedmiotem licencjonowania,
• nie zastępuje licencji Microsoft,
• nie zmienia zasad licencjonowania,
• nie tworzy wyjątków.

Microsoft nie licencjonuje:

• bastionów,
• jump serverów,
• systemów PAM,
• narzędzi nagrywających sesje,
• narzędzi pośredniczących.

Microsoft licencjonuje wyłącznie:

• dostęp do Windows Server,
• sposób, w jaki realni użytkownicy z tego systemu korzystają.

Efekt końcowy po stronie systemu docelowego jest jedynym kryterium.

Jeżeli użytkownik końcowy pracuje na Windows Server – licencjonowanie obowiązuje tak samo, niezależnie od tego, czy dostęp realizowany jest:

• bezpośrednio przez RDP / MSTSC,
• przez VPN,
• przez portal,
• czy przez Syteca PAM.

Windows Server CAL – podstawy

Windows Server CAL (Client Access License) jest wymagana zawsze, gdy użytkownik lub urządzenie:

• loguje się do domeny,
• korzysta z zasobów serwera,
• administruje serwerem,
• łączy się z nim zdalnie,
• wykonuje jakiekolwiek operacje wymagające usług Windows Server.

CAL może być:

• User CAL – przypisana do osoby,
• Device CAL – przypisana do urządzenia.

Kluczowe jest to, że:

Microsoft nie licencjonuje kont – licencjonuje ludzi albo urządzenia.

To rozróżnienie staje się krytyczne przy systemach PAM.

Konto współdzielone – jak patrzy na to Microsoft

W środowiskach PAM bardzo często stosuje się konta współdzielone:

• jedno konto administracyjne,
• przechowywane w vault,
• używane przez wielu administratorów,
• naprzemiennie lub równolegle.

Z punktu widzenia bezpieczeństwa – to dobra praktyka.
Z punktu widzenia licencjonowania – nie zmienia to absolutnie nic.

Microsoft:

• nie licencjonuje kont w Active Directory,
• nie licencjonuje kont technicznych,
• nie licencjonuje „sesji”.

Microsoft licencjonuje:

• realnych użytkowników (people),
• albo urządzenia.

Jeżeli:

• 1 konto,
• 5 osób,
• nawet jeśli pracują na zmiany,

to:

• licencyjnie nadal jest to 5 użytkowników.

Konto współdzielone nie jest bytem licencyjnym.

Windows Server CAL przy koncie współdzielonym

Model User CAL

Jeżeli organizacja stosuje User CAL:

• liczba wymaganych CAL = liczba realnych osób,
• nie liczba kont,
• nie liczba sesji.

Przykład:

• 1 konto administracyjne w PAM,
• 5 administratorów korzystających z tego konta, → wymagane: 5 × Windows Server User CAL.

Model Device CAL

Jeżeli stosowany jest Device CAL:

• licencjonowane są urządzenia,
• liczba kont i użytkowników nie ma znaczenia,
• konto współdzielone nadal niczego nie zmienia.

RDS, RDP i RDS CAL – przypomnienie

• RDP (Remote Desktop Protocol) to protokół zdalnego pulpitu.

• MSTSC to klient RDP w Windows.

• RDS (Remote Desktop Services) to rola Windows Server umożliwiająca pracę wielu użytkowników na jednym serwerze.

• RDS CAL są wymagane, gdy:
  • użytkownik loguje się interaktywnie do Windows Server,
  • korzysta z GUI,
  • pracuje na aplikacjach uruchomionych na serwerze.

I tu ponownie – metoda dostępu nie ma znaczenia.

RDS CAL przy kontach współdzielonych – gdzie organizacje najczęściej się mylą

W praktyce najwięcej nieporozumień dotyczy RDS CAL, szczególnie w środowiskach, gdzie wdrożono system PAM i zrezygnowano z indywidualnych kont administracyjnych na rzecz kont współdzielonych przechowywanych w sejfie.

Pojawia się wtedy założenie, że skoro:

• jest jedno konto,
• jedna sesja,
• jeden serwer,

to wystarczy jedna licencja RDS CAL.

To założenie jest błędne.

Microsoft w ogóle nie bierze pod uwagę:

• liczby kont,
• liczby sesji,
• faktu, że dostęp realizowany jest przez PAM.

Licencjonowanie RDS opiera się wyłącznie na pytaniu:

ile realnych osób wykonuje interaktywną pracę na Windows Server?

Jeżeli kilka osób:

• łączy się przez RDP (bezpośrednio lub pośrednio),
• korzysta z pulpitu graficznego,
• uruchamia aplikacje na serwerze,

to:

• każda z tych osób musi być objęta RDS CAL (User) lub
• każde urządzenie, z którego się łączą – RDS CAL (Device).

To pozostaje prawdą nawet wtedy, gdy:

• wszyscy używają jednego konta technicznego,
• PAM ukrywa przed nimi hasło,
• sesje są nagrywane,
• dostęp jest ograniczony czasowo.

Z perspektywy Microsoftu:

jedno konto ≠ jeden użytkownik.

Dostęp administracyjny a RDS CAL – jedyny rzeczywisty wyjątek

Istnieje jeden często przywoływany wyjątek, który bywa źródłem kolejnych nieporozumień.

Windows Server umożliwia:

• maksymalnie dwie jednoczesne sesje RDP
• w trybie czysto administracyjnym
• bez instalowania roli RDS
• i bez konieczności posiadania RDS CAL.

Ten wyjątek obowiązuje wyłącznie wtedy, gdy:

• dostęp ma charakter administracyjny,
• użytkownicy mają uprawnienia administratora,
• nie jest wykonywana praca użytkowa ani aplikacyjna,
• serwer nie jest wykorzystywany jako środowisko robocze,
• liczba jednoczesnych sesji nie przekracza dwóch.

W praktyce oznacza to typowe czynności utrzymaniowe:

• konfiguracja systemu,
• aktualizacje,
• zarządzanie usługami,
• administracja rolami i funkcjami.

Ten wyjątek:

• nie znosi obowiązku posiadania Windows Server CAL,
• nie rozszerza się na pracę użytkową,
• nie dotyczy środowisk, gdzie serwer jest używany jak terminal.

Wystarczy, że administrator:

• otworzy aplikację biurową,
• wykona pracę operacyjną,
• zacznie korzystać z serwera jak z własnej stacji roboczej,

a z punktu widzenia licencyjnego:

• RDS CAL staje się wymagana.

Techniczne konta i automatyzacje – gdzie RDS CAL faktycznie nie powstaje

Warto rozróżnić jeszcze jeden scenariusz, który często bywa wrzucany do jednego worka z kontami współdzielonymi, a nim nie jest.

Konta używane do:

• automatyzacji,
• integracji system–system,
• harmonogramów zadań,
• usług działających w tle,

nie generują obowiązku RDS CAL, o ile:

• nie dochodzi do logowania interaktywnego,
• nie jest używany RDP,
• nie ma GUI,
• nie ma człowieka wykonującego pracę na pulpicie.

To są czysto techniczne operacje.

Problem pojawia się w momencie, gdy:

• to samo konto techniczne,
• zaczyna być używane przez człowieka,
• do logowania RDP,
• do pracy na pulpicie.

W tym momencie:

• znika charakter techniczny,
• pojawia się użytkownik,
• a wraz z nim wraca obowiązek licencyjny.

Microsoft nie uznaje „intencji konta”.

Liczy się sposób użycia.

Jak to wygląda w praktyce – dlaczego firmy są niedolicencjonowane

W ogromnej liczbie organizacji:

• środowisko działa technicznie poprawnie,
• RDP działa,
• użytkownicy się logują,
• PAM pośredniczy,
• audyt sesji działa.

I to przez lata.

Problem polega na tym, że:

• Microsoft nie wymaga technicznego sprawdzania posiadania CAL,
• system nie blokuje dostępu przy ich braku,
• brak CAL nie powoduje błędu ani awarii.

Dlatego:

• niedolicencjonowanie jest niewidoczne operacyjnie,
• wychodzi dopiero przy audycie,
• często po kilku latach.

W audycie Microsoft:

• nie analizuje liczby kont,
• nie interesuje się bastionem,
• nie pyta, czy był PAM.

Analizuje natomiast:

• liczbę realnych użytkowników,
• zakres ich pracy,
• harmonogramy,
• logi RDP,
• nagrania sesji,
• dokumentację procesów.

I wtedy bardzo często okazuje się, że:

• liczba CAL jest znacząco zaniżona,
• konta współdzielone maskowały problem,
• PAM – paradoksalnie – dostarczył dowodów w postaci logów.

PAM jako punkt ryzyka audytowego

Systemy PAM, takie jak Syteca PAM:

• zwiększają bezpieczeństwo,
• porządkują dostęp,
• są bardzo dobrą praktyką.

Jednocześnie:

• centralizują logi,
• pokazują, kto faktycznie pracował,
• eliminują anonimowość.

Z perspektywy audytu licencyjnego:

• PAM nie chroni przed obowiązkami licencyjnymi,
• wręcz ułatwia ich weryfikację.

Dlatego w dojrzałych organizacjach:

• wdrożenie PAM powinno iść w parze
• z uporządkowaniem licencjonowania Microsoft.

Dlaczego brak licencji jest realnym problemem, nawet jeśli „wszystko działa”

Jednym z najbardziej mylących aspektów licencjonowania Microsoft jest fakt, że brak wymaganych licencji CAL lub RDS CAL nie powoduje żadnych problemów technicznych. System działa poprawnie niezależnie od tego, czy organizacja posiada:

• 5,
• 50,
• czy 500 wymaganych licencji.

Nie istnieje mechanizm, który:

• blokuje połączenia RDP,
• ogranicza liczbę użytkowników,
• wymusza instalację licencji CAL po stronie systemu.

Z technicznego punktu widzenia:

• Windows Server nie weryfikuje legalności dostępu,
• RDP działa niezależnie od stanu licencji,
• PAM również nie „widzi” licencji.

To powoduje bardzo powszechny efekt fałszywego bezpieczeństwa:

„Skoro działa od lat, to pewnie jest OK”.

Problem polega na tym, że licencjonowanie Microsoft jest obowiązkiem prawnym, a nie technicznym. Brak licencji:

• nie zatrzymuje systemu,
• ale stanowi naruszenie warunków licencyjnych.

I właśnie dlatego:

• temat wraca dopiero przy audycie,
• często obejmuje kilka lat wstecz,
• kończy się koniecznością jednorazowego, kosztownego „domknięcia” licencji.

Audyt Microsoft – na czym naprawdę się koncentruje

Wbrew obiegowym opiniom audyt licencyjny:

• nie polega na liczeniu kont w Active Directory,
• nie opiera się na liczbie skonfigurowanych użytkowników RDP,
• nie interesuje się, czy był używany PAM.

Audyt koncentruje się na:

• realnych użytkownikach,
• realnym czasie pracy,
• faktycznym sposobie użycia systemu.

W praktyce analizowane są:

• logi logowań,
• harmonogramy pracy,
• zakres obowiązków użytkowników,
• nagrania sesji (jeśli istnieją),
• opisy procesów operacyjnych.

Konta współdzielone:

• nie chronią przed audytem,
• nie upraszczają sytuacji,
• bardzo często ją komplikują.

System PAM:

• porządkuje dostęp,
• ale jednocześnie usuwa anonimowość,
• co z perspektywy audytu licencyjnego oznacza większą przejrzystość.

To nie jest wada PAM – to naturalna konsekwencja dojrzałego zarządzania dostępem.

PAM i licencje – jak to powinno wyglądać w dojrzałej organizacji

W praktyce najlepiej funkcjonujące środowiska IT traktują:

• PAM jako warstwę bezpieczeństwa,
• licencjonowanie Microsoft jako osobny, równoległy obszar zgodności.

Dojrzałe podejście zakłada, że:

• wdrożenie PAM nie służy „optymalizacji” licencji,
• konta współdzielone nie są narzędziem redukcji CAL,
• każda osoba wykonująca pracę na Windows Server jest policzona licencyjnie.

W takim modelu:

• PAM porządkuje kto i jak ma dostęp,
• licencje odpowiadają na pytanie ile osób i urządzeń z niego korzysta.

Te dwa obszary:

• nie konkurują ze sobą,
• nie znoszą się nawzajem,
• muszą być spójne.

Najważniejsze wnioski

Z punktu widzenia licencjonowania Microsoft:

• system PAM nie zmienia nic,
• konto współdzielone nie redukuje liczby wymaganych licencji,
• Microsoft licencjonuje ludzi albo urządzenia, nie konta,
• jedna sesja ≠ jeden użytkownik,
• RDS CAL są wymagane zawsze, gdy występuje interaktywna praca na Windows Server,
• wyjątki techniczne nie są wyjątkami licencyjnymi.

Z punktu widzenia praktyki rynkowej:

• niedolicencjonowanie jest bardzo powszechne,
• wynika głównie z mylenia kont z użytkownikami,
• przez lata pozostaje niewidoczne,
• wychodzi dopiero przy audycie.

Z punktu widzenia bezpieczeństwa:

• PAM jest właściwym kierunkiem,
• ale powinien iść w parze z uporządkowaniem zgodności licencyjnej,
• szczególnie w środowiskach opartych o RDP i Windows Server.

Podsumowanie

Systemy klasy PAM, takie jak Syteca PAM, są dziś jednym z kluczowych elementów dojrzałej architektury bezpieczeństwa. Pozwalają uporządkować dostęp uprzywilejowany, wyeliminować hasła znane użytkownikom, wprowadzić pełną rozliczalność działań administratorów oraz spełnić wymagania audytowe i compliance. Coraz więcej organizacji decyduje się na ich wdrożenie – i słusznie.

Jednocześnie bardzo często w tym samym momencie wychodzą na jaw niejasności związane z licencjonowaniem Microsoft, w szczególności w obszarze:

• Windows Server CAL,
• RDS CAL,
• pracy zdalnej przez RDP / Zdalny Pulpit / MSTSC,
• kont współdzielonych i kont technicznych,
• środowisk opartych o bastiony i PAM.

Jak pokazuje praktyka, system PAM:

• nie zmienia zasad licencjonowania,
• nie redukuje liczby wymaganych licencji,
• nie jest „obejściem” dla CAL ani RDS CAL.

Microsoft licencjonuje realnych użytkowników albo urządzenia, a nie konta, sesje czy narzędzia pośredniczące. Konto współdzielone – nawet jeśli jest dobrą praktyką bezpieczeństwa – nie obniża obowiązków licencyjnych i bardzo często wręcz maskuje niedolicencjonowanie, które ujawnia się dopiero podczas audytu.

Dodatkowym problemem jest fakt, że brak wymaganych licencji:

• nie powoduje błędów technicznych,
• nie blokuje dostępu,
• nie jest widoczny operacyjnie.

Dlatego wiele środowisk funkcjonuje przez lata w stanie niezgodnym licencyjnie, aż do momentu kontroli, w której analizowane są rzeczywiste scenariusze użycia, logi, harmonogramy pracy oraz – coraz częściej – dane z systemów PAM.

Z tego powodu bezpieczeństwo i licencjonowanie powinny być traktowane łącznie, a nie jako dwa niezależne światy. Wdrożenie PAM to bardzo dobry moment, aby:

• zweryfikować realne scenariusze dostępu do Windows Server,
• uporządkować licencje CAL i RDS CAL,
• dobrać właściwy model (User vs Device),
• zamknąć potencjalne ryzyka audytowe zanim staną się problemem formalnym i finansowym.

Jeżeli Twoja organizacja:

• korzysta z RDP lub usług RDS,
• używa kont współdzielonych lub kont technicznych,
• wdraża lub planuje wdrożenie systemu PAM,
• ma wątpliwości, czy obecne licencjonowanie Microsoft jest poprawne,
• potrzebuje wsparcia w doborze i zakupie licencji,

warto podejść do tego tematu świadomie i całościowo.

Pomagamy zarówno w analizie scenariuszy licencyjnych, jak i we wdrożeniach systemów PAM, w tym Syteca PAM. Jako partner Microsoft wspieramy również w doborze i dostarczeniu odpowiednich licencji, tak aby środowisko było nie tylko bezpieczne, ale też zgodne z zasadami licencyjnymi.

To podejście pozwala uniknąć kosztownych korekt w przyszłości i budować infrastrukturę IT w sposób przewidywalny, uporządkowany i odporny na audyty.

Zobacz, jak Syteca PAM działa w praktyce

🎯 Umów się na indywidualną prezentację z inżynierem:
https://hs.securivy.com/meetings/securivy/prezentacja-ekran-system

🧪 Rozpocznij darmowe 30-dniowe testy:
https://share.hsforms.com/2BnvUBY55RZygQn1XS3qbowyio8

🎥 Obejrzyj webinar VOD: Demo Syteca
https://www.youtube.com/watch?v=7w5dlinO5dE

Źródła: Dokumentacja Microsoft (Windows Server, RDS, CAL, Product Terms), oficjalne warunki licencyjne Microsoft (Microsoft Licensing & Product Use Rights), dokumentacja i materiały techniczne Syteca PAM, materiały eksperckie Securivy, praktyka audytowa Microsoft (SAM/LSA), doświadczenia projektowe z wdrożeń PAM i RDS w środowiskach produkcyjnych.

FAQ – najczęściej zadawane pytania