VBR 13.1 - zmiany bezpieczeństwa, które administrator zauważy na co dzień 🔐

Cześć wszystkim,

po części o zdalnym BMR dla Windows wracam do administrowania samym Veeamem. W tej części biorę na warsztat uprawnienia, MFA i zatwierdzanie zmian. Szczególnie w VSA łatwo się tu potknąć: mamy konta w HMC, role w VBR i dwa mechanizmy wymagające udziału drugiej osoby.

Najwięcej uwagi poświęcam tutaj kontom i ciągłości dostępu. Dalej zebrałem zmiany dotyczące audytu, Malware Detection i portów. Dodatkowe MFA w Users and Roles oraz usprawnienia opisane w dalszej części to nowości 13.1. Sam Security Officer, recovery token i rozdzielenie ról HMC nie pojawiły się dopiero w tej wersji - opisuję je, bo przy wdrażaniu i aktualizowaniu VSA warto od razu uporządkować również ten obszar.

👤 Zmiana uprawnień wymaga ponownego potwierdzenia MFA

Jeżeli MFA jest włączone, zmiany w Users and Roles serwera VBR wymagają teraz dodatkowego potwierdzenia. Dotyczy to miejsca, w którym nadajemy dostęp do całego środowiska backupowego. Nie należy mylić tego ustawienia z osobną stroną Users and Roles w HMC.

Nie zastępuje to jednak kontroli organizacyjnej. Nadal sprawdzam, kto wykonał zmianę, z jakiego powodu i czy przyznane uprawnienia odpowiadają zakresowi pracy. MFA potwierdza tożsamość zalogowanej osoby, ale nie ocenia zasadności decyzji.

Po aktualizacji warto wykonać kontrolowaną zmianę na koncie testowym albo roli bez wpływu na produkcję i potwierdzić cały przebieg. Samo poprawne logowanie z MFA nie dowodzi jeszcze, że dodatkowe potwierdzenie działa również w Users and Roles.

🐧 Konta lokalne VSA: HMC i VBR to dwie warstwy uprawnień

W VSA dochodzi jeszcze zarządzanie lokalnymi kontami appliance w Veeam Host Management Console. Kreator Add New User prowadzi przez rolę w HMC, ustawienie MFA oraz - jeżeli wybrany typ konta na to pozwala - rolę w VBR i oznaczenie konta jako serwisowego.

W praktyce trzeba pilnować kilku zasad. Jedno konto może dostać tylko jedną rolę HMC. Host Administrator może otrzymać w VBR wyłącznie rolę Backup Administrator. Konta Security Officer i Service Account nie mogą dostać roli VBR. Security Officer nie ma dostępu do TUI. Z kolei konto typu User albo Service Account nie służy do logowania do HMC. Po utworzeniu konta nie można również zmienić jego nazwy.

Przy dodawaniu nowego Security Officera w HMC nie można wyłączyć MFA. Jest jednak ważny wyjątek dla początkowej konfiguracji appliance: jeśli wtedy MFA zostało wyłączone, kreator pierwszego logowania SO pomija jego rejestrację. Dlatego przy przeglądzie kont SO sprawdzam również stan MFA. Ten wyjątek opisuje procedura pierwszego logowania SO.

MFA w HMC i MFA w VBR włącza się osobno, ale Host Administrator używa wspólnego kodu. Dokumentacja wskazuje, że przy aktualizacji do 13.1 wcześniej osobne kody HMC i VBR są łączone; po aktualizacji używamy kodu skonfigurowanego w HMC. Przy przeglądzie dostępu sprawdzam więc oba ustawienia, a nie tylko to, czy aplikacja na telefonie generuje kod.

Przy nowym koncie kończę też pierwsze logowanie i wymaganą zmianę hasła, zanim podłączę je do skryptu. Aktualne hasło zapisuję w Vault, a dostęp do VBR sprawdzam osobno. W ostatniej próbie konto było już aktywne w HMC, ale połączenie PowerShell udało się dopiero po przejściu zmiany hasła i aktualizacji wpisu w sejfie.

Kreator pozwala też oznaczyć konto jako VBR service account. Jest to ustawienie przeznaczone dla połączeń nieinteraktywnych używanych przez aplikacje i komponenty. Jego zaznaczenie wyłącza MFA przy logowaniu tego konta do VBR, dlatego nie używam go jako wygodnego wyjątku dla zwykłego konta administratora.

Tu nazewnictwo może zmylić: rola Service Account w HMC i opcja VBR service account to dwa różne ustawienia. Sprawdziłem to w kreatorze na buildzie 13.1.1.18. Po wybraniu roli Service Account kreator przechodził od razu do podsumowania, bez kroków MFA i VBR Role. W podsumowaniu pole VBR role było puste, a VBR service account miało wartość No. Dla roli User pojawiał się natomiast wybór uprawnień VBR i osobny checkbox wyłączający MFA przy logowaniu do VBR.

Podczas sprawdzania tego mechanizmu trafiłem na ograniczenie przy włączonym four-eyes authorization w VBR. Tworzyłem konto z rolą Host Administrator w HMC, rolą Backup Administrator w VBR i zaznaczoną opcją VBR service account. Kreator pozwolił przejść do podsumowania, ale po wybraniu Finish zwrócił błąd: Unable to create user while four-eyes authorization is enabled. Nie otrzymałem potwierdzenia utworzenia konta.

To warto uwzględnić już na etapie wdrożenia. Konta potrzebne do administracji i integracji najlepiej przygotować przed włączeniem four-eyes. Jeżeli zabezpieczenie działa już w środowisku, nie wyłączam go doraźnie przy okazji tworzenia użytkownika. Najpierw planuję zmianę, zapewniam udział drugiego administratora, zapisuję stan wyjściowy i po operacji ponownie sprawdzam role, MFA oraz stan four-eyes.

Sprawdziłem też pozostałe role na 13.1.1.18, już przy potwierdzonym włączeniu four-eyes. Wyniki nie były jednakowe:

Odznaczenie VBR service account nie usunęło więc problemu z utworzeniem Host Administratora. Jednocześnie zwykły User bez uprawnień VBR i Service Account w HMC powstały poprawnie. Nie opisywałbym tego jako ogólnej blokady zakładania kont w appliance.

Samo wyłączenie four-eyes również wymaga drugiej osoby. Po odznaczeniu opcji przez jednego Backup Administratora VBR utworzył wniosek Disable four-eyes authorization. Ustawienie zmieniło się dopiero po zatwierdzeniu wniosku przez drugiego Backup Administratora w konsoli VBR. To dobry bezpiecznik, ale też rzecz, którą trzeba uwzględnić w oknie serwisowym. Nie wystarczy dostęp do HMC i jednego konta administracyjnego.

Żeby rozstrzygnąć, czy blokadę powodowała właśnie aktywna autoryzacja four-eyes, dokończyłem cały scenariusz. Po zatwierdzonym wyłączeniu four-eyes ponowiłem utworzenie konta Host Administrator + Backup Administrator. Tym razem konto powstało, było aktywne w HMC, miało włączone MFA i pojawiło się w VBR jako Backup Administrator. Następnie ponownie włączyłem four-eyes i po ponownym otwarciu okna Authorization sprawdziłem, że ustawienie pozostało aktywne.

Pierwsze przygotowane hasło nie przeszło przy tym polityki DISA STIG, ponieważ zawierało więcej niż cztery kolejne znaki tej samej klasy. W generatorze haseł trzeba więc uwzględnić również limit kolejnych znaków tej samej klasy.

Przy okazji zauważyłem coś ważnego dla audytu: w HMC Events pojawił się wpis Create user również dla odrzuconej próby Host Administratora. Sprawdzam więc rezultat kreatora i obecność konta na liście, a nie tylko nazwę zdarzenia. Wyniki dotyczą tego buildu i tych konkretnych ustawień. Sam status Active oraz MFA Enabled nowego SO nie wystarczył mi za test - pierwsze logowanie i procedurę odzyskiwania sprawdziłem osobno.

Warto też rozdzielić dwa mechanizmy zatwierdzania: Security Officer w HMC zatwierdza określone operacje na appliance, natomiast four-eyes w VBR korzysta z uprawnień Backup Administrator lub Security Administrator. Security Officer i Security Administrator to różne role. Drugie konto SO nie zastępuje automatycznie drugiej osoby z odpowiednią rolą VBR. W opisie okna Authorization na pokazanych zrzutach VBR występuje nazwa Security Officer. To rozbieżność z dokumentacją VBR 13, która wskazuje Security Administrator. W praktyce sprawdzam rolę przypisaną użytkownikowi w VBR.

🧯 Security Officer: telefon nie może być jedynym planem odzyskania

Security Officer w VSA nie jest zapasowym kontem administratora. Host Administrator wykonuje zmiany techniczne, a Security Officer zatwierdza część operacji i chroni rozdzielenie obowiązków. Utrata dostępu do tego konta potrafi więc zatrzymać nie tylko logowanie, ale też zmianę, do której potrzebna jest zgoda drugiej osoby.

Pierwsze logowanie Security Officera traktuję jako osobną procedurę wdrożeniową. Kreator prowadzi przez zmianę hasła, rejestrację MFA, zapis recovery tokenu oraz ustawienie hasła chroniącego wrażliwe dane w zaszyfrowanym backupie konfiguracji. Obowiązuje przy tym opisany wcześniej wyjątek dotyczący MFA podczas początkowej konfiguracji. Przed logowaniem przygotowuję aplikację TOTP i odblokowany Vault, żeby nie szukać miejsca na zapis tokenu w połowie operacji.

Przy dodawaniu kolejnego SO kreator wyświetla komunikat MFA is mandatory for the Security Officer role, a przełącznik pozostaje zablokowany. Rejestrację MFA i odzyskanie konta sprawdziłem osobno.

Po zakończeniu warto wylogować konto i sprawdzić MFA w nowej sesji. Recovery token powinien dać się odczytać z firmowego sejfu haseł, bez kopiowania go do notatek, dokumentacji czy zrzutów ekranu. Następnie przeprowadzam próbę odzyskania dostępu z użyciem zapisanego tokenu.

Backup konfiguracji też wymaga udziału SO

Przy VSA pilnuję jeszcze configuration backup passphrase ustawianej przez Security Officera. To osobny element procedury, obok hasła logowania, MFA i recovery tokenu. Włączenie szyfrowania backupu w VBR nie zastępuje tego kroku: bez passphrase SO zadanie może zakończyć się błędem już podczas przygotowywania konfiguracji do szyfrowania.

Security Officer zarządza tym hasłem w HMC > Configuration > Configuration Backup. Po jego ustawieniu zapisujemy je w odpowiednio chronionym Vault i uruchamiamy backup konfiguracji, sprawdzając wynik całej sesji. Dopiero poprawne wykonanie daje podstawę do dalszych prób odzyskiwania. Potrzebny jest jeszcze dostęp do samego pliku kopii poza serwerem, którego awarię rozważamy.

Jeżeli Security Officer zapomni hasła, konto zablokuje się po nieudanych logowaniach albo straci dostęp do aplikacji MFA, wspieraną ścieżką jest Forgot password? > I have a password recovery token. Po użyciu tokenu kreator wymaga ustawienia nowego hasła, ponownej rejestracji MFA i wydaje nowy recovery token. W praktyce traktuję to jako jedną operację: nowy token trafia do Vault, a poprzedni przestaje być używany.

Sprawdziłem cały przebieg na dodatkowym koncie SO w VSA 13.1.1.18. Token zapisany po pierwszej inicjalizacji został przyjęty, konto przeszło ponownie przez zmianę hasła i rejestrację MFA, a nowy token zastąpił poprzedni w Vault. Po zakończeniu zalogowałem się jeszcze raz z MFA. HMC Events zapisało oddzielnie autoryzację recovery tokenem, kontrolę nowego hasła i reset hasła. Ponowne logowanie z MFA sprawdziłem osobno.

Warto tu uważać na LiveOS. KB4761 pozwala awaryjnie odblokować lokalne konto lub zmienić jego hasło, ale taki reset nie usuwa MFA. Dla Security Officera MFA można odzyskać tylko recovery tokenem. Jeżeli stracimy jednocześnie dostęp do aplikacji MFA i tokenu, Veeam wprost ostrzega, że konto może być nieodzyskiwalne, a dostęp utracony na stałe.

Ilu Security Officerów?

W zarządzanym środowisku nie chcę opierać tej roli na jednej osobie i jednym telefonie. Moją praktyczną rekomendacją są co najmniej dwa imienne konta Security Officer, każde przypisane do innej osoby, z osobnym hasłem i własną rejestracją MFA. To nie jest minimalny wymóg producenta, tylko sposób na usunięcie pojedynczego punktu awarii.

Nowe konto Security Officer tworzy Host Administrator, a istniejący Security Officer zatwierdza taki wniosek. Domyślnego konta veeamso nie można usunąć, ale nie jest to powód, aby wszyscy korzystali z jednego współdzielonego hasła i tego samego sekretu TOTP. Wspólne konto zaciera odpowiedzialność i sprawia, że utrata jednego urządzenia dotyczy całego procesu zatwierdzania.

Aplikacja uwierzytelniająca też wymaga decyzji

Veeam nie wymusza konkretnej aplikacji uwierzytelniającej. Rejestruje kod w aplikacji TOTP, więc wybór zależy od polityki organizacji. Synchronizacja zwiększa dostępność, ale powiększa też liczbę urządzeń i kont, których bezpieczeństwo trzeba kontrolować.

Z popularnych możliwości:

• Google Authenticator to najczęstszy wybór, bo zwykle jest już na telefonie. Kody synchronizują się przez konto Google, ale aplikacji można używać też lokalnie i przenieść wpisy na nowy telefon kodem QR. Cena za wygodę jest jedna: przy włączonej synchronizacji konto Google wchodzi do procedury odzyskiwania MFA i powinno podlegać tym samym rygorom co reszta kont uprzywilejowanych.
• Microsoft Authenticator ma sens tam, gdzie organizacja i tak stoi na Microsoft 365. Kopia kont TOTP trafia do chmury, natomiast odtworzenie działa w obrębie jednej platformy: z Androida na Androida albo z iOS na iOS. Zmiana telefonu na inny system to osobne zadanie do zaplanowania wcześniej, a nie rzecz do załatwienia w dniu migracji.
• Proton Authenticator rozwiązuje dokładnie ten problem. Synchronizacja end-to-end działa między Androidem, iOS, Windows, macOS i Linuksem, więc telefon i komputer nie muszą być z tej samej rodziny. Aplikacja jest darmowa, z otwartym kodem, działa też całkowicie lokalnie, bez zakładania konta. Ma import z innych aplikacji i szyfrowany eksport, czyli nie zamyka drogi wyjścia, gdyby za rok wybór okazał się zły. Jest osobna od Proton Pass i dobrze, że tak jest, bo hasło i kod TOTP nie lądują w jednym sejfie. Jeżeli włączam synchronizację, konto Proton dopisuję do listy rzeczy, które same muszą mieć mocne uwierzytelnienie i sprawdzony sposób odzyskania.
• Aegis Authenticator idzie w drugą stronę: tylko Android, otwarty kod i świadomie bez żadnej chmury. Wpisy leżą w sejfie zamykanym własnym hasłem, a kopie zapasowe są szyfrowane i zapisywane tam, gdzie wskażemy, także automatycznie po każdej zmianie. W procedurze odzyskiwania nie pojawia się więc żaden dostawca ani trzecie konto, co przy koncie Security Officer jest realną zaletą: odzyskanie zależy wyłącznie od naszego procesu. Odpowiedzialność też jest w całości nasza, więc pilnuję dwóch rzeczy - żeby aktualna kopia leżała poza telefonem i żeby hasło do niej dało się odczytać z Vault, gdy telefonu już nie ma.

Przechowywanie hasła logowania i sekretu TOTP w tym samym menedżerze haseł osłabia rozdzielenie składników. Dla konta Security Officer wolę, aby dostęp do hasła, MFA i recovery tokenu nie zależał od jednej osoby i jednego mechanizmu.

Jeżeli włączam synchronizację, konto używane do jej ochrony samo musi mieć mocne uwierzytelnienie, a urządzenia powinny być szyfrowane i objęte możliwością zdalnego zablokowania lub wyczyszczenia. Nie skanuję też jednego kodu QR na telefony kilku administratorów. Ciągłość zapewniają osobne konta Security Officer, a nie wspólny sekret MFA.

Niezależnie od wybranej aplikacji robię jeszcze próbę awaryjną: drugi uprawniony Security Officer loguje się własnym kontem, recovery token da się odczytać z właściwego Vault, a organizacja wie, kto może uzyskać do niego dostęp i jak jest to rejestrowane.

🧾 Security & Compliance Analyzer trafia do Windows Event Log

Na serwerze VBR działającym na Windows wyniki oraz zmiany stanu Security & Compliance Analyzer mogą być publikowane w Windows Event Log. Dzięki temu nie trzeba budować całego monitorowania wyłącznie wokół konsoli Veeam. Zdarzenia można odebrać przez Windows Event Forwarding albo narzędzie SIEM używane już w organizacji.

To usprawnienie dotyczy VBR na Windows. VSA zapisuje zdarzenia w swoim środowisku linuksowym, więc istniejącej procedury opartej na Windows Event Log nie można przenieść na appliance bez zmiany sposobu zbierania danych.

Sam analizator mogę uruchomić także przez PowerShell, bez otwierania konsoli graficznej. Po połączeniu z VBR wykonuję:

$scan = Start-VBRSecurityComplianceAnalyzer -Wait
Get-VBRSecurityComplianceAnalyzerResults -Session $scan

Sprawdziłem ten przebieg na VSA. Przekazanie sesji do drugiego polecenia pozwala odczytać wyniki właśnie uruchomionego skanu. To przydatne przy zbieraniu dowodów po aktualizacji, ale nie potwierdza jeszcze, że zdarzenia dotarły do SIEM. Odbiór po stronie monitorowania sprawdzam oddzielnie.

Przed włączeniem alertów produkcyjnych sprawdzam trzy rzeczy: jakie zdarzenia faktycznie powstają, które z nich powinny być alarmem, a które tylko informacją, oraz jak długo przechowujemy ich historię. Bez tego SIEM szybko zacznie zbierać dużo danych, z których niewiele wynika.

Na VSA odbiorcę syslog dodaję przez Configuration > Settings > Event Forwarding > Syslog Servers. W kreatorze dostępne są UDP, TCP i TLS; po wybraniu TLS podpowiadany jest port 6514. Port i transport uzgadniam z konfiguracją odbiorcy. Samo dodanie adresu nie potwierdza ani odbioru zdarzeń, ani poprawnego rozpoznawania ich przez SIEM.

🔑 Zmiana hasła szyfrowania zostawia wyraźniejszy ślad

Zmiana hasła szyfrowania backupu jest teraz zapisywana w sesji odpowiedniego zadania i generuje zdarzenie. To drobna zmiana, ale przy rotacji kluczy albo analizie incydentu ma znaczenie. Łatwiej ustalić, kiedy zmieniono ustawienie i z którym zadaniem było związane.

Nie wykonywałbym takiego testu przez zmianę hasła w ważnym łańcuchu tylko po to, żeby zobaczyć zdarzenie. Najbezpieczniej sprawdzić to podczas planowanej rotacji albo na zadaniu testowym, a później upewnić się, że informacja dotarła do przyjętego systemu monitorowania.

🛡️ Malware Detection jest wygodniejsze w codziennej obsłudze

W 13.1 rozbudowano również bieżącą pracę z Malware Detection. Zdarzenia oparte na wzroście entropii zawierają więcej informacji o plikach, które uruchomiły detekcję. Wykluczenia można ustawiać osobno dla konkretnej maszyny, a Web UI obejmuje zarządzanie zdarzeniami, wykluczeniami i analizę detekcji.

W Web UI wchodzę w Configuration > Malware Detection. Na jednej stronie mam analizę entropii, aktywności systemu plików, wskaźników kompromitacji i aktualizację definicji. Niżej, przez Configure exclusions, otwieram ustawienia dla wybranych maszyn. Przy fałszywym alarmie zaczynam od konkretnego komputera i rodzaju detekcji, zamiast od razu wyłączać analizę dla całego środowiska.

Producent podaje także znaczne ograniczenie zużycia pamięci podczas analizy indeksu systemu plików gościa - w niektórych przypadkach nawet do 90%. Nie traktuję tej liczby jako gwarancji. W większym środowisku najlepiej porównać użycie RAM i czas analizy dla tej samej grupy maszyn przed aktualizacją i po niej.

🌐 Web UI, REST API i integracje po aktualizacji

W instalacji VBR na Windows port Web UI można ustawić podczas wdrożenia albo zmienić później. REST API odpowiada teraz również na porcie 443. Port 9419 pozostaje dostępny dla zgodności ze starszymi integracjami, ale Veeam zapowiada jego wycofanie w przyszłym wydaniu.

To dobry moment, żeby wyszukać skrypty, systemy monitorowania i integracje nadal korzystające z 9419. Działający endpoint na 443 nie przełączy ich automatycznie. Najpierw testuję klienta na nowym porcie, później zmieniam konfigurację, a dopiero na końcu rozważam ograniczenie starego dostępu.

🔌 Port 6162 nie zamyka całej macierzy sieciowej

VBR 13.1 upraszcza komunikację backupową, używając TCP 6162 jako podstawowego portu Veeam Transport Service i Data Mover. To może ograniczyć liczbę reguł pomiędzy segmentami.

Nie oznacza to jednak, że po aktualizacji można bez sprawdzenia usunąć wszystkie dotychczasowe reguły. Bieżąca tabela portów nadal opisuje TCP 2500-3300 jako zakres zapasowy dla części połączeń, gdy 6162 jest niedostępny. Osobne wymagania mają też między innymi wdrażanie komponentów, obsługa systemu gościa, vPower NFS, NDMP, taśma i konkretne platformy wirtualizacyjne.

W praktyce najpierw potwierdzam ruch dla używanych ról: serwera VBR, proxy, repozytoriów, mount serverów, gatewayów, agentów i hostów. Następnie wykonuję backup oraz odtwarzanie właściwe dla danego środowiska. Dopiero na tej podstawie ograniczam reguły zapory.

🔐 Zmiana, której administrator prawie nie widzi: PQC

13.1 wprowadza hybrydowy model FIPS i kryptografii postkwantowej dla uzgadniania połączeń i wymiany kluczy. AES nadal odpowiada za szyfrowanie danych. W istniejących wdrożeniach PQC jest włączane bez migracji backupów i bez przebudowy infrastruktury.

Wyjątkiem jest ścisły tryb zgodności FIPS - wtedy mechanizmy PQC są wyłączane. To ważne przy dokumentowaniu zgodności: nie należy jednocześnie deklarować wymuszonego strict FIPS i aktywnego PQC bez sprawdzenia rzeczywistej konfiguracji.

✅ Co sprawdzam po przejściu na 13.1?

Moja lista po aktualizacji wygląda dziś tak:

1. Logowanie z MFA i dodatkowe potwierdzenie przy kontrolowanej zmianie w Users and Roles.
2. W VSA przegląd kont HMC, przypisanych ról, MFA i kont serwisowych oraz sprawdzenie wpływu four-eyes na planowane zmiany.
3. Dla Security Officerów kontrola liczby imiennych kont, poprawnego logowania MFA, aktualności recovery tokenów i dostępu do nich w sytuacji awaryjnej.
4. Uruchomienie Security & Compliance Analyzer oraz potwierdzenie zdarzeń w używanym systemie monitorowania.
5. Weryfikacja retencji i poziomów alarmowania dla zdarzeń przekazywanych do SIEM.
6. Sprawdzenie obsługi Malware Detection w Web UI oraz istniejących wykluczeń.
7. Test używanych klientów REST na porcie 443 i inwentaryzacja zależności od 9419.
8. Sprawdzenie TCP 6162 na wszystkich wymaganych ścieżkach.
9. Backup, odtwarzanie, SureBackup, obsługa systemu gościa i zadania taśmowe - oczywiście tylko te, które występują w danym środowisku.
10. Zmiana reguł zapory dopiero po analizie logów i wykonaniu testów.

Nie każda instalacja używa SIEM, SAML, taśmy albo osobnych segmentów dla wszystkich komponentów. Dlatego nie mam jednej checklisty, którą kopiuję do każdego projektu bez zmian. Rdzeń jest wspólny, ale testy muszą wynikać z faktycznej architektury.

💬 Co sprawdziliście u siebie?

Jak rozwiązujecie u siebie dostęp awaryjny do Security Officera? Macie drugą osobę z osobnym kontem i sprawdzony dostęp do recovery tokenu? Chętnie poznam też Wasze doświadczenia z zakładaniem kont HMC przy włączonym four-eyes - szczególnie dla innych kombinacji ról niż pokazana powyżej.

Jeśli macie wyniki z konkretnych ról albo integracji, wystarczy krótki opis bez adresów i nazw środowiska. To będzie znacznie bardziej przydatne niż samo potwierdzenie, że aktualizacja zakończyła się sukcesem.

🔗 Źródła

• What's New - Security
• VSA - Configuring Users
• VSA - Managing User Authentication
• VSA - Performing Initial Security Officer Login
• VSA - Performing Security Officer Tasks
• KB4761 - How to use Veeam Live OS ISO
• Four-Eyes Authorization
• What's New - Malware Detection
• Security & Compliance Analyzer
• Ports - VBR User Guide
• VBR 13.1 Release Notes
• Microsoft Authenticator - tworzenie kopii kont
• Google Authenticator - synchronizacja i przenoszenie kont
• Proton Authenticator - szyfrowanie i synchronizacja
• Aegis Authenticator - funkcje i kopie zapasowe