Dokumentacja bezpiecznej konfiguracji

Wszystkie mechanizmy istotne z punktu widzenia bezpieczeństwa w jednym miejscu — jakie są ich ustawienia domyślne, gdzie można je zmienić i co chronią. Dokument przeznaczony do przeglądów bezpieczeństwa, audytów i list kontrolnych wzmacniania zabezpieczeń.

NetCrunch Security Features wyjaśnia działanie poszczególnych mechanizmów ochrony i przyczyny ich istnienia. Utwardzanie serwera NetCrunch opisuje sposób wdrożenia serwera tak, aby ograniczyć liczbę dostępnych punktów dostępu. Ta strona pełni inną funkcję niż tamte materiały: jest pojedynczą listą mechanizmów, ustawień domyślnych i lokalizacji, uporządkowaną według kolejności, w jakiej poprosi o nie osoba przeprowadzająca przegląd bezpieczeństwa.

surface

Czego nie trzeba konfigurować

Większość przewodników dotyczących wzmacniania zabezpieczeń platform monitoringu poświęca dużo miejsca komponentom, których NetCrunch nie dostarcza. Warto zacząć właśnie od nich, ponieważ najprostszym sposobem zabezpieczenia komponentu jest jego nieposiadanie.

NetCrunch korzysta z własnego serwera sieci Web opartego na node.js i przechowuje dane w osadzonej instancji PostgreSQL. Nie ma tu IIS, oddzielnego serwera aplikacji ani zewnętrznego SQL Server.

Eliminuje to pewną kategorię prac związanych z wdrożeniem, zamiast jedynie je upraszczać:

• Brak nagłówków banerów serwera sieci Web, mapowań programów obsługi i domyślnych witryn do usunięcia
• Brak zasad recyklingu puli aplikacji do dostrojenia
• Brak oddzielnego serwera bazy danych do odizolowania, aktualizowania, licencjonowania lub umieszczenia we własnej podsieci
• Brak konta usługi bazy danych do utworzenia i okresowej zmiany
• Brak pliku konfiguracyjnego brokera komunikatów, który kreator konfiguracji mógłby nadpisać

Pozostałe mechanizmy ochrony opisano poniżej.

authentication

Uwierzytelnianie i dostęp

Uwierzytelnianie wieloskładnikowe

Oprócz hasła do konta można wymagać drugiego składnika zarówno w Web Console, jak i w Desktop Console. Dotyczy to każdego typu połączenia — szyfrowanego połączenia TCP, HTTPS oraz połączeń przekazywanych przez NetCrunch Connection Cloud. Nie istnieje droga do konsoli, która pozwalałaby pominąć ten wymóg.

Składnikiem jest kod zależny od czasu generowany przez aplikację uwierzytelniającą. Nie ma możliwości korzystania z wiadomości SMS ani poczty e-mail.

User profileRequires Multi Factor Authentication

Jest to właściwość profilu użytkownika, a nie przełącznik globalny, dlatego można wymagać jej od kont, które mogą zmieniać konfigurację monitoringu lub odczytywać zapisane poświadczenia, bez nakładania tego wymogu na wszystkich użytkowników. Rejestracja jest wymuszana przy następnym logowaniu i nie można jej pominąć.

Informacje dotyczące rejestracji i resetowania utraconego drugiego składnika znajdują się w NetCrunch Security Features.

Źródła kont

Konta lokalne

Uwierzytelnianie za pomocą poświadczeń zdefiniowanych w NetCrunch.

Konta Active Directory

NetCrunch sprawdza członkostwo w grupach podczas logowania. Profile dostępu są przypisywane do grup AD, a dostęp jest odbierany, gdy użytkownik przestaje być członkiem grupy. Zobacz Zarządzanie profilami dostępu użytkowników NetCruncha.

Profile dostępu

Profile dostępu to wielokrotnego użytku zestawy uprawnień oparte na rolach, obejmujące funkcje programu, widoki atlasów i poszczególne węzły. Każdy użytkownik ma jeden profil, przypisany bezpośrednio lub odziedziczony za pośrednictwem grupy AD.

Uprawnienia mają wartości Deny, Access lub Manage i są oceniane od najdłuższej ścieżki do najkrótszej, dlatego szczegółowe reguły zastępują szersze ustawienia domyślne.

Zalecanym modelem jest domyślna odmowa dostępu: rozpocznij bez dostępu i dodaj wyłącznie to, czego wymaga dana rola. Alternatywa — przyznanie pełnego dostępu, a następnie odmowa dostępu do elementów poufnych — jest szybsza w konfiguracji, ale później trudniejsza do obrony.

Dwa uprawnienia wymagają szczególnej ostrożności, ponieważ oba mają w praktyce charakter administracyjny:

• Uprawnienie do edytowania profili użytkowników, które obejmuje usuwanie wymogu uwierzytelniania wieloskładnikowego z dowolnego konta, w tym własnego
• Uprawnienie do odczytywania zapisanych poświadczeń

Pełny model opisano w Zarządzanie profilami dostępu użytkowników NetCruncha.

Widoki udostępnione

Udostępniony widok to łącze do graficznego widoku tylko do odczytu, obsługiwanego przez dedykowanego użytkownika udostępniania, który nie może logować się do żadnej z konsol i może wyświetlać wyłącznie przypisane mu widoki. Poza tymi widokami nie ma nawigacji ani elementów konfiguracji, dzięki czemu jest to właściwy sposób udostępnienia komuś pulpitu bez tworzenia dla niego konta.

Użytkownik udostępniania jest tworzony dla każdego odbiorcy osobno i identyfikowany za pomocą jego adresu e-mail, dzięki czemu każde udostępnienie można niezależnie odebrać i poddać audytowi — nie ma wspólnego konta osoby wyświetlającej. Jego uprawnienia nie są konfigurowane; wynikają z przypisanych mu widoków. Zakres obejmuje dokładnie węzły umieszczone w tych widokach oraz, jeśli je uwzględniono, we wszystkich widokach połączonych. Dziedziczenie jest dynamiczne w obu kierunkach: dodanie węzła do widoku lub usunięcie go z widoku natychmiast przyznaje lub odbiera dostęp do niego, a w przypadku uwzględnionych widoków połączonych łącza są rozpoznawane podczas wyświetlania widoku, więc dodanie łącza rozszerza udostępnienie. Nie można rozszerzyć udostępnienia przez edycję profilu dostępu ani zawęzić go w ten sposób — granicę stanowi widok. Zobacz @sharing-embedding.

Podczas tworzenia udostępnienia ustawia się trzy mechanizmy kontroli:

Ochrona hasłem

Opcjonalna. Warto ją ustawić dla wszystkiego, co wykracza poza publiczną stronę stanu. Hasło należy przesłać innym kanałem niż łącze.

Data wygaśnięcia

Opcjonalna. Ustaw ją dla każdego udostępnienia tymczasowego.

Ograniczenie osadzania

Domyślnie ustawiona na *, co oznacza, że dowolne źródło może osadzić widok w ramce iframe. Wprowadź konkretną nazwę hosta, aby ograniczyć tę możliwość.

Administratorzy mogą wyświetlić każdego udostępnionego użytkownika, osobę, która go utworzyła, informację o ochronie hasłem oraz liczbę udostępnianych przez niego widoków w sekcji Users & Access Rights ManagerSharing. Ten panel służy do zapewnienia widoczności i przeprowadzania audytu — zmiany nadal wykonuje się z poziomu poszczególnych widoków.

transit

Szyfrowanie podczas przesyłania

Połączenie	Transport	Właściwości
Desktop Console i Probe do Server	Bezpośredni TCP, port 12009	Wymiana kluczy X25519, szyfrowanie AES-256-GCM, wzajemne uwierzytelnianie PSK. Certyfikaty nie są wymagane.
Web Console do Server	HTTPS	Wbudowany serwer sieci Web natywnie obsługuje TLS 1.3.
Console lub Probe przez Connection Cloud	Wychodzące HTTPS, port 443	TLS z walidacją certyfikatu i izolacją pojedynczego dzierżawcy. Połączenia przychodzące nie są wymagane.
Powiadomienie e-mail	SMTP z TLS	Włączane za pomocą opcji Encrypted connection (TLS).

Certyfikat serwera sieci Web

SettingsNetCrunch SystemConnections

Zainstaluj certyfikat nawet w przypadku użytku wyłącznie wewnętrznego. HTTPS nie służy tu wyłącznie do zapewnienia poufności: kilka funkcji konsoli jest dostępnych tylko na bezpiecznej stronie, w tym SSH Terminal oraz widoki osadzone lub udostępnione, ponieważ przeglądarki ograniczają ich działanie przy użyciu zwykłego HTTP.

Certyfikat z podpisem własnym jest dopuszczalny do użytku wewnętrznego i powoduje wyświetlanie ostrzeżeń w przeglądarce. Certyfikat zaufanego urzędu usuwa te ostrzeżenia i jest wymagany w przypadku bezpiecznych połączeń WebSocket.

Certyfikat można również wygenerować z poziomu wiersza poleceń:

nccli generate-web-certificate

Ufanie dodatkowym urzędom certyfikacji

NetCrunch używa node.js do wychodzących połączeń SSL/TLS i HTTPS, a niektóre urzędy certyfikacji nie są uwzględnione w jego domyślnym magazynie zaufania. Dodatkowe certyfikaty główne należy umieścić w folderze external\Root Certificates katalogu danych NetCrunch Server, w formacie PEM.

at-rest

Zapisane poświadczenia i dane przechowywane

NetCrunch przechowuje w Twoim imieniu poświadczenia — poświadczenia monitoringu, profile SNMP, profile integracji i profile użytkowników. Wszystkie są przechowywane w postaci zaszyfrowanej, zabezpieczone głównym kluczem szyfrowania. Każda instalacja ma taki klucz; różnica polega na tym, co go chroni.

Domyślne

Główny klucz jest chroniony wbudowanym hasłem systemowym. Dane są szyfrowane, a instalacja jest przenośna — kopia zapasowa może zostać przywrócona na innym komputerze, a poświadczenia zostaną przywrócone razem z nią. Ta przenośność jest również zagrożeniem: osoba, która uzyska kopię zapasową, uzyska także zawarte w niej poświadczenia.

Advanced Data Security

Główny klucz jest chroniony własnym hasłem głównym, a wszystkie kopie zapasowe są szyfrowane za pomocą AES-256 z użyciem tego hasła.

SettingsNetCrunch SystemServerAdvanced Data Security

Hasło główne musi mieć co najmniej 12 znaków oraz zawierać małą literę, wielką literę, cyfrę i znak specjalny. Można je później zmienić.

Uprawnienia do folderu danych

Folder danych zawiera główny klucz szyfrowania i bazę danych poświadczeń, dlatego całe drzewo ma jawnie określoną listę kontroli dostępu zamiast dziedziczyć uprawnienia z ProgramData.

Pełna kontrola jest przyznawana użytkownikom SYSTEM, BUILTIN\Administrators oraz service account, jeśli usługa nie działa jako LocalSystem. Użytkownikowi BUILTIN\Users nie przyznaje się żadnych uprawnień.

Instalator stosuje te ustawienia podczas instalacji, a po uruchomieniu serwer normalizuje pozostałą część drzewa w tle — dzięki temu zaktualizowana instalacja zostaje doprowadzona do zgodności. Celowo niestandardowe uprawnienia w katalogu głównym danych pozostają niezmienione.

api

Dostęp programistyczny

REST API i MCP Server korzystają z tego samego mechanizmu kluczy API, tego samego powiązania z użytkownikiem, tego samego zestawu uprawnień i tego samego ogranicznika szybkości. Klucz utworzony dla REST działa również dla MCP.

User ProfilesAPI Keys

Klucz API dziedziczy uprawnienia użytkownika NetCrunch, z którym jest powiązany, dlatego zakres klucza jest kontrolowany przez te same profile dostępu co dostęp do konsoli.

Dostępne ograniczenia:

Tryb tylko do odczytu

Klucz może odczytywać konfigurację, ale nie może jej zmieniać.

Ograniczenie adresu źródłowego

Klucz jest akceptowany wyłącznie z określonych adresów.

Data wygaśnięcia

Klucz przestaje działać w określonym dniu.

Ograniczanie szybkości

Liczba żądań jest ograniczana dla każdego klucza za pomocą zasobnika tokenów współdzielonego przez REST i MCP.

Zalecane praktyki:

• Do automatyzacji używaj dedykowanego konta użytkownika NetCrunch, a nie osobistego konta administratora — ułatwia to audytowanie użycia i zapobiega przerwaniu działania integracji po odejściu pracownika
• Używaj oddzielnego klucza dla każdego skryptu lub integracji
• Rozpocznij od trybu tylko do odczytu i przyznawaj dostęp do zapisu wyłącznie tam, gdzie skrypt musi zmieniać konfigurację
• Ograniczaj dostęp według adresu źródłowego wszędzie tam, gdzie wywołujący ma stały adres
• Przekazuj klucz w nagłówku x-api-key, a nie w adresie URL, ponieważ adresy URL pojawiają się w dziennikach i historii przeglądarki

Informacje o tworzeniu kluczy znajdują się w Wprowadzenie, a opis modelu właściwego dla MCP — w Automatyzacja zgodna z MCP i AI.

monitoring-credentials

Poświadczenia używane do monitoringu

Poświadczenia używane przez NetCrunch do uzyskiwania dostępu do monitorowanych systemów wymagają takiej samej kontroli jak poświadczenia używane do uzyskiwania dostępu do NetCrunch.

SNMP

Preferuj SNMPv3. Ciągi community v1 i v2c są przesyłane przez sieć bez ochrony. NetCrunch obsługuje SNMPv3 z prywatnością DES, 3DES, AES 128, AES 192 i AES 256. Odbieranie pułapek v3 wymaga oddzielnego profilu powiadomień SNMPv3 — bez niego nie można dekodować zaszyfrowanych pułapek. Zobacz Odbieranie powiadomień SNMPv3.

Windows

Używaj dedykowanego konta monitoringu zamiast administratora domeny i ogranicz reguły zapory zdalnego administrowania do adresu NetCrunch Server. Zobacz Konfiguracja Monitorowania Windows.

Cele chmurowe i API

Jeśli platforma oferuje rolę tylko do odczytu lub token o ograniczonym zakresie, używaj go. Monitoring Proxmox wymaga wyłącznie PVEAuditor; Azure wymaga wyłącznie Monitoring Reader.

auditing

Audytowanie

NetCrunch Audit monitoring pack

Śledzi dostęp użytkowników do konsoli, w tym logowania, wylogowania i nieudane próby logowania, zarówno w Desktop Console, jak i w Web Console. Włącz go, aby aktywność logowania generowała zdarzenia tak jak każdy inny monitorowany warunek.

Activity Log

ApplicationsServer rejestruje operacje udostępniania — kiedy widok został udostępniony i przez kogo, zdarzenia logowania i wylogowania użytkowników udostępnionych widoków oraz adresy IP uzyskujące dostęp do udostępnionych łączy.

Zdarzenia użycia API

Gdy klucz API wykonuje żądanie, dziennik zdarzeń rejestruje ten fakt, umożliwiając ustalenie, która integracja, skrypt lub klient MCP wykonał daną czynność.

Security Audit monitoring pack

Monitoruje zdarzenia kont, logowania i problemy z hasłami na monitorowanych komputerach Windows — w całym środowisku, a nie w samym NetCrunch, ale warto włączyć go również na serwerze NetCrunch.

deployment

Wdrożenie

Powyższe mechanizmy chronią instalację. Sposób wdrożenia serwera określa, ile elementów w ogóle trzeba chronić:

• Uruchamiaj na serwerze wyłącznie NetCrunch
• Monitoruj za pomocą Probe na oddzielnym komputerze; Probe serwera powinien monitorować wyłącznie sam NetCrunch i nic więcej
• Nie uruchamiaj sensorów skryptowych ani akcji alertów wykonujących programy z Probe serwera — działają one z uprawnieniami serwera, obok bazy danych poświadczeń
• Skrypt startowy jest stałym plikiem w katalogu instalacyjnym, dlatego zdefiniowanie elementów uruchamianych podczas startu serwera wymaga lokalnych uprawnień administratora na tym komputerze i nie może być ustawione zdalnie

Utwardzanie serwera NetCrunch obejmuje każdy z tych punktów, w tym sytuacje, gdy dostępny jest tylko jeden komputer.

summary

Podsumowanie ustawień

Mechanizm kontroli	Domyślne ustawienie	Lokalizacja
Uwierzytelnianie wieloskładnikowe	Wyłączone; ustawiane dla każdego profilu	User profile -> Requires Multi Factor Authentication
Model dostępu	Domyślna odmowa dostępu	Access profile -> Atlas Defaults
Advanced Data Security (hasło główne, kopie zapasowe AES-256)	Wyłączone; wbudowane hasło systemowe	Settings -> NetCrunch System -> Server -> Advanced Data Security
Certyfikat serwera sieci Web	Z podpisem własnym	Settings -> NetCrunch System -> Connections
ACL folderu danych	Stosowana przez instalator	System plików; normalizowana przez serwer podczas uruchamiania
Tryb tylko do odczytu klucza API	Wyłączony	User Profiles -> API Keys
Ograniczenie źródła klucza API	Brak	User Profiles -> API Keys
Wygaśnięcie klucza API	Brak	User Profiles -> API Keys
Ograniczanie szybkości API	Włączone	Dla każdego klucza, bez możliwości konfiguracji
Audytowanie logowania do konsoli	Wyłączone	NetCrunch Audit monitoring pack
Wersja SNMP	Zależna od profilu poświadczeń	Settings -> Monitoring -> SNMP Communities and Passwords
Tryb FIPS	Wyłączony	Windows Local Security Policy, nie NetCrunch

access profilesapi keyattack surfaceauditcertificatechecklistcompliancecontrolsdata at restdefaultsencryptionfipsfips modehardeningmaster passwordmfarate limitingsecure configurationsecuritysnmpv3tls