Zarządzanie sekretami tożsamości nieosobowych na potrzeby audytów w 2026 roku

Alert o 02:13, którego nikt nie potrafił przypisać

O 02:13 we wtorkowy poranek kanał operacji bezpieczeństwa zaczyna się zapełniać. Z wewnętrznego konta automatyzacji uruchomiono eksport produkcyjnej bazy danych. Ścieżka dostępu jest uprawniona. Token jest ważny. Źródłowy adres IP należy do runnera w chmurze używanego przez zespół inżynierski. Nie widać złośliwego oprogramowania. Nie ma zgłoszenia phishingowego.

Dyrektor ds. bezpieczeństwa informacji zadaje pierwsze oczywiste pytanie: „Kto jest właścicielem tej tożsamości?”

Cisza.

Lider DevOps przypomina sobie, że token utworzono podczas migracji klienta dwa lata temu. Zespół platformowy twierdzi, że może być używany przez integrację rozliczeniową. Administrator bazy danych mówi, że ma dostęp tylko do odczytu, ponieważ jego usunięcie kiedyś zepsuło nocne zadanie. Dział prawny pyta, czy chodziło o dane osobowe. Funkcja zgodności pyta, czy jest to incydent podlegający zgłoszeniu na gruncie NIS2, DORA lub GDPR. Audytor prosi o dowody, że konta serwisowe, klucze API, certyfikaty i sekrety CI/CD są zinwentaryzowane, przeglądane, rotowane, monitorowane i unieważniane.

Do 09:00 projekt ustalenia audytowego zaczyna już nabierać kształtu. W zapomnianej mikrousłudze znaleziono twardo zakodowany, nierotowany klucz API. Nadaje on szeroki dostęp do produkcyjnej bazy transakcji klientów. Programista, który go utworzył, odszedł dwa lata temu. System nie ma wskazanego właściciela, udokumentowanego celu, zapisu rotacji ani reguły monitorowania.

To jest problem tożsamości nieosobowych w 2026 roku.

Większość organizacji poprawiła kontrolę dostępu dla ludzi. Mają MFA, procesy JML, przeglądy dostępu uprzywilejowanego i logi dostawcy tożsamości. Tożsamości maszynowe rozmnożyły się jednak szybciej niż nadzór nad nimi. Konta serwisowe, tożsamości obciążeń, klucze API, tokeny OAuth, klucze SSH, certyfikaty, sekrety Kubernetes, tokeny integracji SaaS, konta robotycznej automatyzacji procesów i poświadczenia wdrożeniowe CI/CD wykonują dziś krytyczne działania biznesowe, nie będąc „użytkownikami” w ludzkim znaczeniu.

Dla dostawców SaaS, fintechów, dostawców usług zarządzanych, operatorów chmury i MŚP intensywnie przetwarzających dane niezarządzane tożsamości nieosobowe nie są już kwestią technicznej higieny. Są ryzykiem odporności i zgodności na poziomie zarządu. NIS2 traktuje kontrolę dostępu, zarządzanie aktywami, bezpieczeństwo łańcucha dostaw, obsługę incydentów i cyberhigienę jako podstawowe środki zarządzania ryzykiem cyberbezpieczeństwa. DORA obejmuje ryzyko ICT, odporność operacyjną, zgłaszanie incydentów i ryzyko stron trzecich ICT odpowiedzialnością organu zarządzającego w podmiotach finansowych. GDPR wymaga od administratorów i podmiotów przetwarzających ochrony danych osobowych oraz wykazania rozliczalności.

Najtrudniejsze nie jest wykazanie, że sekrety istnieją. Najtrudniejsze jest wykazanie, że każda tożsamość nieosobowa ma właściciela, cel, cykl życia, ocenę ryzyka, zatwierdzony dostęp, bezpieczną metodę przechowywania, regułę rotacji, pokrycie monitorowaniem i ścieżkę unieważnienia.

Dlaczego tożsamości nieosobowe stały się nowym problemem dostępu uprzywilejowanego

Tożsamość nieosobowa, czyli NHI, to każda tożsamość cyfrowa używana przez oprogramowanie, infrastrukturę lub procesy zautomatyzowane, a nie przez osobę. W praktyce obejmuje to konta serwisowe używane przez aplikacje, klucze API używane przez integracje SaaS, tokeny OAuth i tokeny odświeżania używane przez aplikacje stron trzecich, klucze SSH używane przez automatyzację, certyfikaty TLS i klucze prywatne, sekrety CI/CD, tożsamości obciążeń w chmurze, ciągi połączeń do baz danych, osadzone dane uwierzytelniające, konta botów RPA oraz poświadczenia integracyjne zarządzane przez dostawców.

Te tożsamości mają zwykle trzy cechy, które niepokoją audytorów.

Po pierwsze, są długotrwałe. Użytkownik będący osobą może rotować dane uwierzytelniające, zmieniać role i odejść w ramach formalnego procesu zakończenia współpracy. Token API utworzony w oknie wdrożeniowym może pozostać aktywny przez lata, ponieważ nikt nie chce ryzykować awarii środowiska produkcyjnego.

Po drugie, są silnie uprawnione. Token wdrożeniowy może zmieniać infrastrukturę. Podmiot usługi w chmurze może tworzyć zasoby pamięci masowej. Konto bazy danych może eksportować rejestry klientów. Klucz podpisujący może naruszyć integralność łańcucha dostaw oprogramowania.

Po trzecie, trudno je przypisać. Tożsamości ludzkie są powiązane z zapisami HR. Tożsamości nieosobowe często są powiązane ze skryptami, potokami, dostawcami, zapomnianymi projektami lub nieudokumentowanymi integracjami.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint wskazuje to bezpośrednio w fazie Controls in Action, Step 22:

Nie zapominaj też o tożsamościach nieosobowych. To właśnie tu audyty często ujawniają cichą ekspozycję. Czy tokeny API są ewidencjonowane? Czy konta integracyjne są przypisane do osób, czy dryfują bez właściciela? Kiedy ostatnio zrotowano ciąg dostępu do bazy danych osadzony w skrypcie sprzed dekady?

Zarządzanie tożsamością nie jest efektowne, ale jest strukturalne. Bez niego twój SZBI jest tylko zbiorem zamkniętych drzwi bez możliwości potwierdzenia, kto trzyma klucze.

Ostatnie zdanie jest sednem problemu. Organizacja może mieć dopracowaną Politykę kontroli dostępu, a mimo to nie przejść audytu, jeśli tożsamości maszynowe są niezarządzane. SZBI, który nie potrafi wyjaśnić, kto jest właścicielem sekretu, dlaczego sekret istnieje i kiedy został ostatnio przejrzany, nie działa jeszcze jako system kontrolowany.

ISO/IEC 27001:2022 przekształca zarządzanie sekretami w dowody

ISO/IEC 27001:2022 jest skuteczna, ponieważ nie traktuje zarządzania sekretami jako odrębnego zadania inżynierskiego. Wymaga opartego na ryzyku SZBI z określonym zakresem, wymaganiami stron zainteresowanych, odpowiedzialnością kierownictwa, oceną ryzyka, postępowaniem z ryzykiem, doborem zabezpieczeń, Deklaracją stosowania i ciągłym doskonaleniem.

W przypadku tożsamości nieosobowych organizacja nie powinna zaczynać od zakupu narzędzia. Powinna zacząć od zakresu i odpowiedzialności.

Zgodnie z klauzulami ISO/IEC 27001:2022 od 4.1 do 4.4 organizacja określa kwestie wewnętrzne i zewnętrzne, strony zainteresowane, wymagania prawne, regulacyjne i umowne, interfejsy oraz zależności. W kontekście NHI zakres SZBI powinien wskazywać środowiska chmurowe, platformy SaaS, systemy CI/CD, aplikacje produkcyjne, integracje z klientami, podmioty przetwarzające dane, dostawców usług zarządzanych i usługi kryptograficzne, w których występują poświadczenia maszynowe.

Klauzule od 5.1 do 5.3 czynią kierownictwo odpowiedzialnym za politykę, zasoby, role i raportowanie wyników. Ma to znaczenie, ponieważ remediacja NHI często powoduje napięcia operacyjne. Rotacja poświadczenia produkcyjnej bazy danych, zastąpienie współdzielonego konta serwisowego w systemie legacy albo wymuszenie wstrzykiwania sekretów ze skarbca może przerwać kruche przepływy pracy. Bez sponsora na poziomie kierownictwa zespoły odkładają porządki.

Klauzule od 6.1.1 do 6.1.3 oraz 6.2 zapewniają mechanizm kontroli. Organizacja definiuje kryteria ryzyka, identyfikuje ryzyka dotyczące poufności, integralności i dostępności, przypisuje właścicieli ryzyka, ocenia prawdopodobieństwo i wpływ, wybiera opcje postępowania z ryzykiem, dobiera zabezpieczenia, przygotowuje Deklarację stosowania i śledzi mierzalne cele.

W praktyce plan postępowania z ryzykiem dla tożsamości nieosobowych powinien odpowiadać na pytania:

• Które systemy i usługi biznesowe zależą od NHI?
• Które sekrety mogą uzyskiwać dostęp do danych osobowych, regulowanych usług finansowych, infrastruktury produkcyjnej lub krytycznych usług dla klientów?
• Które tożsamości są uprzywilejowane, uśpione, współdzielone, zarządzane przez dostawcę albo niezarządzane?
• Które zabezpieczenia ograniczają ryzyko, takie jak przechowywanie w skarbcu, rotacja, zasada najmniejszych uprawnień, wygaśnięcie, zarządzanie cyklem życia certyfikatów, skanowanie CI/CD, monitorowanie i unieważnienie awaryjne?
• Które ryzyka rezydualne wymagają akceptacji biznesowej?

ISO/IEC 27002:2022 zapewnia następnie katalog zabezpieczeń z Załącznika A. Najbardziej istotne zabezpieczenia obejmują 5.9 inwentarz informacji i innych powiązanych aktywów, 5.15 kontrolę dostępu, 5.16 zarządzanie tożsamością, 5.17 informacje uwierzytelniające, 5.18 prawa dostępu, 5.19 bezpieczeństwo informacji w relacjach z dostawcami, 5.20 uwzględnianie bezpieczeństwa informacji w umowach z dostawcami, 5.21 zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT, 5.23 bezpieczeństwo informacji przy korzystaniu z usług w chmurze, 5.24 planowanie i przygotowanie zarządzania incydentami, 5.28 gromadzenie dowodów, 8.2 uprawnienia dostępu uprzywilejowanego, 8.3 ograniczenie dostępu do informacji, 8.5 bezpieczne uwierzytelnianie, 8.15 rejestrowanie, 8.16 działania monitorujące, 8.24 stosowanie kryptografii, 8.25 bezpieczny cykl życia rozwoju oprogramowania, 8.26 wymagania bezpieczeństwa aplikacji, 8.28 bezpieczne kodowanie oraz 8.31 separację środowisk rozwojowych, testowych i produkcyjnych.

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls odwzorowuje te relacje ISO/IEC 27002:2022 w sposób użyteczny dla audytorów i właścicieli kontroli. Dla zabezpieczenia 5.16, zarządzanie tożsamością, Zenith Controls wyjaśnia związek między tożsamością a poświadczeniami:

Zarządzanie tożsamością określa „kto”, natomiast informacje uwierzytelniające zapewniają „jak”, potwierdzając, że osoba podająca się za daną tożsamość jest uprawniona. 5.16 reguluje zarządzanie cyklem życia tożsamości, a 5.17 zapewnia, że hasła, tokeny, certyfikaty i inne poświadczenia są bezpiecznie powiązane z tymi tożsamościami oraz właściwie zarządzane, aby wspierać silne uwierzytelnianie.

Ta relacja jest kluczowa dla NHI. Token bez właściciela tożsamości nie jest możliwy do prześledzenia w audycie. Konto serwisowe bez przeglądu dostępu nie spełnia zasady najmniejszych uprawnień. Certyfikat bez statusu cyklu życia nie jest kontrolowaną kryptografią. Poświadczenie integracji dostawcy bez postanowień umownych nie stanowi skutecznego zarządzania ryzykiem strony trzeciej.

Wzorzec kontroli Clarysec: tożsamość, sekret, uprawnienie, dowód

Clarysec wdraża zarządzanie tożsamościami nieosobowymi i sekretami przez powtarzalny wzorzec kontroli. Nie traktujemy „sekretów” wyłącznie jako tematu DevOps ani „kont serwisowych” wyłącznie jako tematu IAM. Łączymy tożsamość, sekret, uprawnienie i dowód.

Warstwa polityki sprawia, że staje się to egzekwowalne.

Dla MŚP Clarysec User Account and Privilege Management Policy-sme User Account and Privilege Management Policy-sme stanowi:

Konta serwisowe (używane przez systemy lub aplikacje) muszą być udokumentowane, ograniczone do określonych systemów i nigdy nie mogą być używane do logowań interaktywnych.

Zapobiega to klasycznemu antywzorcowi, w którym konto serwisowe staje się współdzielonym loginem administratora. Daje to również audytorowi jasny test: pokaż inwentarz kont serwisowych, pokaż ograniczenie do systemu i pokaż, że logowanie interaktywne jest wyłączone albo technicznie uniemożliwione.

Clarysec Asset Management Policy-sme Asset Management Policy-sme rozszerza definicję aktywów o:

Poświadczenia i usługi cyfrowe: nazwy domen, certyfikaty cyfrowe, klucze API, konta e-mail, loginy do chmury

Ma to znaczenie, ponieważ wiele organizacji inwentaryzuje wyłącznie serwery, laptopy i aplikacje. W 2026 roku klucz API może być bardziej wrażliwy niż laptop. Klucz prywatny certyfikatu może być produkcyjnym aktywem uwierzytelniającym. Login chmurowy używany przez automatyzację może stworzyć ekspozycję danych regulowanych. Traktowanie poświadczeń jako aktywów jest fundamentem gotowego do audytu zarządzania sekretami.

W środowiskach enterprise Clarysec User Account and Privilege Management Policy User Account and Privilege Management Policy podnosi poprzeczkę dowodową:

Organizacja musi utrzymywać szczegółowy inwentarz wszystkich aktywnych i uśpionych poświadczeń, kont uprzywilejowanych oraz kont serwisowych na poziomie systemowym. Inwentarz ten musi być aktualizowany w sposób ciągły i przeglądany kwartalnie.

Kwartalny przegląd ujawnia wiele luk. Uśpione poświadczenia, osierocone podmioty usługowe, starzy użytkownicy integracyjni, niezarządzane konta dostawców i tokeny awaryjne stają się widoczne dopiero wtedy, gdy ktoś porówna rejestr z rzeczywistymi zapisami IAM, skarbca, CI/CD i chmury.

Sekrety są informacjami uwierzytelniającymi, a nie wygodą programisty

Najbardziej niebezpiecznym sformułowaniem w zarządzaniu sekretami jest „klucz tymczasowy”.

Klucze tymczasowe stają się stałe. Poświadczenia testowe trafiają do produkcji. Kod źródłowy ujawnia tokeny. Logi buildów eksponują hasła. Zespoły wsparcia udostępniają certyfikaty przez zgłoszenia. Programiści kopiują pliki środowiskowe do czatu. Wykonawca tworzy podmiot usługi w chmurze i odchodzi.

Zenith Blueprint, faza Controls in Action, Step 22, szeroko opisuje informacje uwierzytelniające:

Ten środek kontrolny nie dotyczy wyłącznie haseł, choć hasła są oczywiście częścią obrazu. Dotyczy każdego poświadczenia używanego do potwierdzenia tożsamości: haseł, kodów PIN, kluczy kryptograficznych, szablonów biometrycznych, kart inteligentnych, tokenów, certyfikatów, tokenów OAuth, kluczy SSH, sekretów API. To klucze do królestwa, a środek kontrolny 5.17 zapewnia, że są traktowane z należytą powagą.

Powiedzmy jasno: słabe zarządzanie uwierzytelnianiem pozostaje jedną z głównych przyczyn źródłowych naruszeń. Słabe lub współdzielone hasła. Twardo zakodowane dane uwierzytelniające w kodzie źródłowym. Niezmienione domyślne loginy w portalach administracyjnych. Certyfikaty z wygasłą lub nieznaną własnością. W każdym z tych przypadków nie zawiodła tożsamość, lecz ochrona i nadzór nad mechanizmem używanym do potwierdzenia tej tożsamości.

Polityki Clarysec przekładają to na zasady operacyjne.

Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme stanowi:

Klucze nie mogą być przechowywane w postaci jawnego tekstu ani osadzane w kodzie źródłowym, dokumentach lub wiadomościach e-mail

Secure Development Policy-sme Secure Development Policy-sme stanowi:

Brak twardo zakodowanych poświadczeń lub sekretów w kodzie źródłowym

Dla zespołów enterprise Secure Development Policy Secure Development Policy stanowi:

Sekrety nie mogą być twardo zakodowane ani przechowywane w postaci jawnego tekstu w repozytoriach.

A Application Security Requirements Policy Application Security Requirements Policy jest jeszcze bardziej bezpośrednia:

Przechowywanie haseł lub kluczy kryptograficznych w postaci jawnego tekstu jest surowo zabronione.

Te klauzule polityk tworzą jasną ścieżkę audytową. Zespoły bezpieczeństwa mogą testować repozytoria, zmienne CI/CD, obrazy kontenerów, magazyny konfiguracji, systemy zgłoszeniowe, platformy dokumentacji i logi względem jednoznacznych wymagań. Wspierają również bezpieczeństwo przetwarzania z Article 32 GDPR, ponieważ ekspozycja sekretów może bezpośrednio prowadzić do nieuprawnionego dostępu do danych osobowych.

Korporacyjny nadzór kryptograficzny także wymaga własności. Clarysec Cryptographic Controls Policy Cryptographic Controls Policy wymaga:

Należy utrzymywać scentralizowany Rejestr zarządzania kluczami w celu ewidencjonowania wszystkich kluczy kryptograficznych, ich statusu cyklu życia, przypisanych opiekunów i kontekstów użycia.

W przypadku tożsamości nieosobowych ten rejestr powinien łączyć klucze certyfikatów, klucze podpisujące, klucze API i klucze zarządzane w chmurze z szerszym rejestrem NHI. Audytor powinien móc prześledzić certyfikat produkcyjny od usługi biznesowej, przez właściciela, opiekuna, wygaśnięcie i dowody rotacji, po procedurę reagowania na incydenty.

NIS2, DORA i GDPR: jeden model dowodowy, wielu regulatorów

Nadzór nad tożsamościami nieosobowymi jest problemem zgodności przekrojowej, ponieważ ta sama awaria może uruchomić wiele obowiązków.

Wyciek tokenu API u dostawcy SaaS może spowodować zakłócenie usługi na gruncie NIS2, ujawnienie danych osobowych na gruncie GDPR oraz umowne zgłaszanie incydentów klientom finansowym zgodnie z oczekiwaniami DORA dotyczącymi łańcucha dostaw. Naruszony sekret CI/CD u dostawcy usług ICT może wpłynąć na odporność klientów, integralność oprogramowania i ciągłość operacyjną. Zapomniane konto integracyjne dostawcy może utworzyć dostęp do systemów regulowanych bez właściwego due diligence lub kontroli umownych.

NIS2 Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych. Minimalne obszary obejmują analizę ryzyka, polityki bezpieczeństwa systemów informatycznych, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczne nabywanie, rozwój i utrzymanie, obsługę podatności, ocenę skuteczności, cyberhigienę, kryptografię, bezpieczeństwo HR, kontrolę dostępu i zarządzanie aktywami oraz, w stosownych przypadkach, MFA lub ciągłe uwierzytelnianie. Tożsamości nieosobowe przecinają niemal wszystkie te obszary. NIS2 Article 23 tworzy również etapowe zgłaszanie istotnych incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie incydentu w ciągu 72 godzin oraz raport końcowy nie później niż miesiąc po zgłoszeniu incydentu.

DORA obowiązuje od 17 stycznia 2025 r. i obejmuje zarządzanie ryzykiem ICT, zgłaszanie poważnych incydentów związanych z ICT, testowanie odporności operacyjnej, wymianę informacji oraz ryzyko stron trzecich ICT. Articles 5 i 6 wymagają ładu, odpowiedzialności organu zarządzającego oraz udokumentowanych ram zarządzania ryzykiem ICT. Article 8 wymaga identyfikacji funkcji biznesowych wspieranych przez ICT, aktywów informacyjnych i zależności. Articles 17 do 19 wymagają zarządzania incydentami, klasyfikacji i raportowania. Articles 28 do 30 wymagają zarządzania ryzykiem stron trzecich ICT, rejestrów umownych, due diligence, standardów bezpieczeństwa, praw do audytu, wsparcia incydentowego, kontroli podwykonawstwa i strategii wyjścia.

GDPR ma zastosowanie wszędzie tam, gdzie dane osobowe są przetwarzane w jego zakresie terytorialnym. Article 5 wymaga integralności, poufności i rozliczalności. Article 32 wymaga odpowiednich środków technicznych i organizacyjnych dla bezpieczeństwa przetwarzania. Jeżeli konto serwisowe lub klucz API może uzyskiwać dostęp do danych osobowych, niezarządzane sekrety stają się nieskutecznością kontroli prywatności, a nie tylko problemem IT.

Te same dowody mogą wspierać certyfikację ISO/IEC 27001:2022, nadzór NIS2, badania DORA i rozliczalność GDPR, jeśli są właściwie ustrukturyzowane.

NIST CSF 2.0 może służyć jako warstwa komunikacyjna dla tych samych dowodów. Funkcja GOVERN obejmuje oczekiwania interesariuszy, obowiązki prawne i umowne, apetyt na ryzyko, odpowiedzialność kierownictwa, politykę i nadzór. Jej wyniki operacyjne obejmują inwentarze aktywów, usługi dostarczane przez dostawców, zarządzanie tożsamościami i poświadczeniami, zasadę najmniejszych uprawnień, bezpieczeństwo danych, rejestrowanie, monitorowanie, reagowanie na incydenty i odzyskiwanie.

Zespoły zapewnienia zgodne z podejściem COBIT 2019 i ISACA zwykle analizują ład i dojrzałość procesów. Będą pytać, czy odpowiedzialność została przypisana, czy zabezpieczenia są osadzone w procesach operacyjnych, czy wyjątki są zatwierdzane, czy wskaźniki są raportowane kierownictwu i czy dowody potwierdzają powtarzalność, a nie jednorazowe porządki.

Praktyczny sprint budowy rejestru tożsamości nieosobowych

Praktyczne zaangażowanie Clarysec często zaczyna się od skoncentrowanego sprintu, a nie sześciomiesięcznego programu narzędziowego. Celem jest przygotowanie możliwego do obrony rejestru NHI, rankingu ryzyka i planu działań naprawczych, które mogą zasilić plan postępowania z ryzykiem ISO/IEC 27001:2022 oraz Deklarację stosowania.

Zacznij od jednej usługi biznesowej, takiej jak platforma rozliczeń klientów, aplikacja tradingowa, portal pacjenta albo system zarządzania tenantami SaaS. Uwzględnij produkcję, staging, CI/CD, infrastrukturę chmurową, narzędzia monitorowania, bazy danych, integracje SaaS i usługi zarządzane przez dostawców.

Powiąż to z Zenith Blueprint, fazą Risk Management, Step 14, w której Clarysec dostosowuje polityki postępowania z ryzykiem do odniesień regulacyjnych. W tym kroku zabezpieczenia dotyczące bezpiecznego rozwoju oprogramowania i potoków obejmują brak twardo zakodowanych sekretów, wzajemny przegląd kodu, zautomatyzowaną analizę statyczną, skanowanie zależności, separację rozwoju, testów i produkcji, MFA dla dostępu do potoków, integralność artefaktów budowania oraz rejestrowanie CI/CD.

Zbierz tożsamości i sekrety z dostawcy tożsamości, IAM w chmurze, skarbca sekretów, Kubernetes, zmiennych CI/CD, ustawień repozytoriów, użytkowników baz danych, konsol administracyjnych SaaS, narzędzi do zarządzania certyfikatami i dokumentacji dostawców.

Oceń ryzyko tożsamości, które mają dostęp do środowiska produkcyjnego, prawa uprzywilejowane, dostęp do danych osobowych, zależność od funkcji krytycznej lub ważnej, kontrolę dostawcy, długotrwałe tokeny, brak właściciela, brak rotacji, brak monitorowania albo twardo zakodowane przechowywanie. Użyj kryteriów ryzyka ISO/IEC 27001:2022 do oceny prawdopodobieństwa i wpływu. Tam, gdzie ma to zastosowanie, użyj analizy funkcji krytycznych lub ważnych DORA. Uwzględnij skutki GDPR tam, gdzie dostępne są dane osobowe. Uwzględnij wpływ na usługę NIS2 tam, gdzie prawdopodobne jest zakłócenie lub szkoda dla klienta.

Dla każdej NHI wysokiego ryzyka zastosuj działania w zakresie postępowania z ryzykiem. Przenieś sekrety z kodu źródłowego, dokumentów i zmiennych CI/CD w postaci jawnego tekstu do skarbca lub zarządzanego magazynu sekretów. Zastąp współdzielone konta serwisowe unikalnymi tożsamościami obciążeń. Wyłącz logowanie interaktywne dla kont serwisowych. Zastosuj zasadę najmniejszych uprawnień i poświadczenia specyficzne dla środowiska. Skonfiguruj rotację, wygaśnięcie i unieważnienie awaryjne. Powiąż sekrety z właścicielami i opiekunami. Dodaj rejestrowanie uwierzytelniania, użycia tokenów i działań wrażliwych. Dodaj alertowanie dla nietypowej geolokalizacji, nietypowego czasu, nietypowego wolumenu lub dostępu do nowych zasobów. Zaktualizuj umowy z dostawcami w zakresie postępowania z poświadczeniami, wsparcia incydentowego i prawa do audytu. Dokumentuj wyjątki z akceptacją właściciela ryzyka i datą wygaśnięcia.

Test Data and Test Environment Policy Test Data and Test Environment Policy wspiera separację środowisk:

Integracja z potokami CI/CD musi wymuszać separację środowisk i danych uwierzytelniających.

Ta klauzula często jest rozstrzygająca. Jeśli środowiska rozwojowe, testowe i produkcyjne współdzielą sekrety, środowisko niższego ryzyka może stać się ścieżką naruszenia produkcji.

Sprint powinien zakończyć się pakietem dowodowym, a nie tylko listą ustaleń. Uwzględnij eksport rejestru NHI, wpisy oceny ryzyka, plan postępowania z ryzykiem, mapowanie Deklaracji stosowania, odniesienia do polityk, zrzuty ekranu ze skarbca, logi rotacji, akceptacje przeglądów dostępu, wyniki skanowania sekretów CI/CD, definicje reguł monitorowania, macierz odpowiedzialności za poświadczenia dostawców, podręcznik operacyjny incydentu oraz wyjątki z właścicielami i datami wygaśnięcia.

Rejestrowanie i wykrywanie: wykazanie widoczności użycia tożsamości maszynowych

Tożsamość maszynowa, która jest dobrze zinwentaryzowana, ale niewidoczna w logach, pozostaje niebezpieczna. Wykrywanie jest częścią historii kontroli.

Clarysec Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme obejmuje dowody uwierzytelniania:

Logi uwierzytelniania: udane i nieudane próby logowania, czas trwania sesji, użycie MFA

W przypadku NHI dostosuj to wymaganie do uwierzytelniania maszynowego. Dla tożsamości obciążenia możesz nie mieć użycia MFA, ale powinieneś mieć zdarzenia uwierzytelniania, użycie tokenów, użycie certyfikatów, metadane wywołań API, obciążenie źródłowe, usługę docelową, czas życia tokenu, zdarzenia niepowodzeń i działania uprzywilejowane.

W Zenith Controls zabezpieczenie ISO/IEC 27002:2022 8.2, uprawnienia dostępu uprzywilejowanego, jest powiązane z rejestrowaniem i monitorowaniem, ponieważ konta uprzywilejowane wymagają szczegółowych zapisów i nadzoru. Zenith Controls łączy również 8.2 z zarządzaniem tożsamością, prawami dostępu, ograniczeniem dostępu do informacji i bezpiecznym uwierzytelnianiem. Dla audytorów oznacza to, że uprzywilejowane tożsamości nieosobowe powinny być przeglądane i monitorowane z taką samą powagą jak administratorzy będący ludźmi, a czasem większą.

Dobre pytania monitorujące obejmują:

• Czy konto serwisowe uwierzytelniło się z nieoczekiwanego obciążenia lub zakresu IP?
• Czy klucz API uzyskał dostęp do nowego punktu końcowego lub zbioru danych?
• Czy certyfikat został użyty po wymianie?
• Czy token CI/CD wdrożył zmianę poza zatwierdzonym potokiem?
• Czy konto tylko do odczytu próbowało wykonywać operacje zapisu?
• Czy uśpione poświadczenie stało się aktywne?
• Czy integracja dostawcy uzyskała dostęp do danych poza uzgodnionymi godzinami lub wolumenami?

Gdy pojawi się alert o 02:13, trzeba odpowiedzieć, jaka tożsamość została użyta, jaki sekret ją uwierzytelnił, jakie prawa dostępu zostały wykorzystane, jakie dane lub systemy zostały dotknięte, czy aktywność była oczekiwana, który właściciel może ją zweryfikować i czy spełniono progi zgłaszania incydentów.

Perspektywa audytora: ten sam proces, różne pytania

Najsilniejszą pozycją audytową nie jest stwierdzenie „spełniamy wszystkie wymagania”. Jest nią stwierdzenie: „obsługujemy jeden kontrolowany proces, który wytwarza dowody dla wielu obowiązków”. Różni audytorzy będą sprawdzać ten proces w różny sposób.

We wszystkich tych perspektywach powtarzające się ustalenia są przewidywalne: brak jednego inwentarza NHI, brak właściciela tożsamości maszynowych, sekrety przechowywane w kodzie lub dokumentacji, współdzielone poświadczenia między środowiskami, brak rotacji lub wygaśnięcia, poświadczenia zarządzane przez dostawców poza przeglądami dostępu, monitorowanie obejmujące ludzi, ale nie maszyny, oraz podręczniki operacyjne incydentów ignorujące wyciek sekretów.

Każde ustalenie naturalnie mapuje się na zabezpieczenia, polityki i szablony remediacji Clarysec. Co ważniejsze, każde z nich można przekształcić w mierzalne dowody w ramach SZBI.

Jak Clarysec pomaga osiągnąć gotowość do audytu

Podejście Clarysec jest praktyczne, ponieważ zaczyna od dowodów, których zażądają audytorzy, i przechodzi wstecz do zabezpieczeń, polityk i rutyn operacyjnych.

W Zenith Blueprint, faza Controls in Action, Step 19, Clarysec podaje bezpośrednie wytyczne dotyczące uwierzytelniania machine-to-machine:

W przypadku uwierzytelniania między maszynami, takiego jak konta serwisowe lub wywołania API, klucze, certyfikaty i tokeny muszą być chronione równie rygorystycznie. Unikaj osadzania poświadczeń w kodzie. Używaj systemów zarządzania sekretami lub skarbców, aby bezpiecznie je przechowywać i rotować.

Typowy strumień prac Clarysec dotyczący tożsamości nieosobowych obejmuje wykrywanie NHI w chmurze, SaaS, CI/CD, repozytoriach, skarbcach i bazach danych, ocenę luk w politykach względem zestawów polityk Clarysec dla MŚP lub enterprise, ocenę ryzyka ISO/IEC 27001:2022 i mapowanie postępowania z ryzykiem, aktualizacje Deklaracji stosowania, mapowanie dowodów dla NIS2, DORA, GDPR i NIST CSF, projekt rejestru NHI, dostosowanie Rejestru zarządzania kluczami, skanowanie sekretów, procesy przeglądów dostępu, macierze odpowiedzialności za poświadczenia dostawców, podręczniki operacyjne incydentów oraz pakiety audytowe ze zrzutami ekranu, eksportami, logami, zatwierdzeniami i zapisami wyjątków.

Dla MŚP podejście jest proporcjonalne. Dostawca SaaS zatrudniający 70 osób nie potrzebuje takiego samego zestawu narzędzi jak globalny bank, ale potrzebuje własności, polityki, postępowania z ryzykiem i dowodów. W przypadku regulowanych podmiotów finansowych i dostawców ICT ten sam model skaluje się do mapowania funkcji krytycznych DORA, nadzoru nad ryzykiem stron trzecich i testowania odporności.

Jeśli kolejny audyt przypada w 2026 roku, nie czekaj, aż audytor odkryje tożsamości nieosobowe za ciebie. Zacznij od jednej usługi krytycznej i zadaj pięć pytań:

1. Czy znamy każde konto serwisowe, klucz API, token, certyfikat i sekret CI/CD używany przez tę usługę?
2. Czy każda NHI ma wskazanego właściciela, opiekuna, cel i ocenę ryzyka?
3. Czy sekrety są przechowywane w skarbcu, rotowane i chronione przed kodem źródłowym, dokumentami, wiadomościami e-mail oraz przechowywaniem w postaci jawnego tekstu?
4. Czy uprzywilejowane tożsamości maszynowe są przeglądane, monitorowane i zabezpieczone przed użyciem interaktywnym?
5. Czy możemy wytworzyć dowody dla ISO/IEC 27001:2022, NIS2, DORA i GDPR z jednego kontrolowanego procesu?

Użyj Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, aby ustrukturyzować ścieżkę wdrożenia SZBI. Użyj Zenith Controls: The Cross-Compliance Guide Zenith Controls, aby połączyć zabezpieczenia ISO/IEC 27002:2022 dotyczące tożsamości, uwierzytelniania, uprawnień, rejestrowania, kryptografii, bezpiecznego rozwoju oprogramowania i dostawców z dowodami regulacyjnymi. Użyj biblioteki polityk Clarysec dla MŚP i enterprise, w tym User Account and Privilege Management Policy-sme User Account and Privilege Management Policy-sme, Cryptographic Controls Policy Cryptographic Controls Policy, Secure Development Policy Secure Development Policy oraz Application Security Requirements Policy Application Security Requirements Policy, aby przekształcić dobre intencje w egzekwowalne wymagania.

Alert o 02:13 wydarzy się gdzieś na pewno. Pytanie brzmi, czy twoja organizacja potrafi odpowiedzieć, z dowodami, kto trzymał klucz, co nim otworzył, dlaczego klucz istniał i jak szybko można przywrócić bezpieczeństwo.