Avamar: Session Security
Summary: Tento článek popisuje funkci Session Security v systému Avamar, jak funguje a jak ji spravovat.
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Instructions
Co je funkce Session Security?
Session Security: Průvodce zabezpečením produktu
Klienti Avamar mohou pomocí funkce Session Security zabezpečit veškerou komunikaci mezi serverem Avamar a softwarem klientem Avamar. Server Avamar zajišťuje ověřování klienta Avamar a klient Avamar zajišťuje ověřování serveru Avamar.
Mezi možnosti funkce Session Security patří vylepšení zabezpečení komunikace mezi procesy systému Avamar.
Systém Avamar zabezpečuje veškerou komunikaci mezi procesy systému Avamar pomocí tiketů relace. Než proces Avamar přijme přenos z jiného procesu Avamar, je vyžadován platný tiket relace.
Tikety relace mají následující obecné charakteristiky:
Systém Avamar nainstaluje veřejný klíč pro certifikát serveru do každého klienta Avamar, který je zaregistrován na serveru Avamar. Klienti Avamar používají veřejný klíč k ověření přenosů ze systému Avamar.
U klientů, kteří jsou aktuálně registrováni, se veřejný klíč pro certifikát serveru a další požadované soubory certifikátů přenesou do klienta do jedné hodiny od instalace.
Systém Avamar také automaticky sdílí certifikát serveru Avamar s uzly úložiště Avamar. Sdílení certifikátu umožňuje uzlu nástroje a uzlům úložiště poskytovat stejný certifikát pro ověření.
Certifikát klienta se vygeneruje, když server Avamar zaregistruje klienta Avamar.
Po vygenerování certifikátu klienta systém Avamar použije šifrované připojení ke klientovi Avamar k instalaci certifikátu do klienta. Systém Avamar také ukládá veřejný klíč certifikátu klienta. Veřejný klíč se používá k ověření klienta při veškeré následné komunikaci.
Jak funguje Session Security?
Funkce Session Security se povoluje na serveru Avamar. Když ji aktivujete, klienti, proxy servery a systémy Data Domain projdou speciálním procesem registrace certifikátu u systému Avamar.
V klientovi se systémem Windows nebo Linux a proxy serveru se při registraci zobrazí, že server má Avamar povolenou funkci Session Security. Software Avamar odešle klientovi svou interní kořenovou certifikační autoritu (chain.pem), aby ji klient mohl uložit a důvěřovat jí. Klient vygeneruje žádost o podpis certifikátu (CSR). Požadavek CSR (avclient.csr) se odešle z klienta do procesu MCS serveru Avamar, který požadavek CSR podepíše a vrátí klientovi pár klíčů certifikátu (key.pem a cert.pem).
Při připojování systému Data Domain k systému Avamar nebo při obnovení komunikace SSL systém Avamar zjistí, že systém Data Domain nemá podepsaný certifikát od sebe ani od jiného ověřeného systému Avamar (imported-host ddboost). Software Avamar použije soukromý klíč ssh systému Data Domain k přihlášení do systému Data Domain za účelem spuštění příkazů ssh přes prostředí ddsh (Data Domain shell). Software Avamar převezme žádost o podpis certifikátu (CSR) systému Data Domain přes SCP a podepíše žádost CSR pomocí interní kořenové certifikační autority Avamar. Jakmile má systém Data Domain podepsaný certifikát od systému Avamar (imported-host ddboost), software Avamar naimportuje kořenovou certifikační autoritu, která certifikát podepsala (chain.pem jako imported-ca ddboost/login-auth).
Nyní, když je klient / proxy server zaregistrován a má certifikáty na straně klienta potřebné k ověření pomocí MCS systému Avamar, dojde k pokusu o zálohu. Systém Avamar odešle pracovní příkaz naslouchacímu procesu Avagent klienta nebo proxy serveru, který pracovní příkaz převezme. Klient nebo proxy server poté ověří řetězec certifikátů serveru Avamar pomocí kořenové certifikační autority Avamar, kterou software Avamar importoval do klienta při registraci. Podobně software Avamar ověří klienta nebo proxy server. V tomto okamžiku nebyla předána žádná data.
Po úspěšném ověření se spustí pracovní příkaz a stav pracovního příkazu se změní z „Waiting-Client“ na „Running“.
Nyní klienti a proxy servery nakonec přesunou data do systému Avamar a Data Domain pomocí nainstalovaného binárního souboru avtar. Binární soubor avtar předá některé příznaky, které určují podrobnosti o tom, jak a jaká data se přesouvají.
Když se služba avtar v klientovi nebo proxy serveru připojí ke službě GSAN systému Avamar, musí vědět, zda je povolena funkce verifypeer. Nastavení verifypeer je nastavení serveru GSAN jako součást konfigurace funkce Session Security, která řídí soket SSL GSAN na portu 29000 tím, že mu říká, zda má nebo nemá vyžadovat certifikáty klienta pro každé příchozí připojení. Naštěstí je implementován protokol TLS 1.2, který automaticky zpracovává, jak klient nebo proxy server předloží své certifikáty klienta službě GSAN během handshaku TLS.
Následuje ukázka vzájemného/obousměrného handshaku protokolu TLS, když je povolená funkce verifypeer.
Z pohledu klienta nebo proxy serveru představuje šipka vpravo připojení k serveru Avamar. Šipka vlevo představuje připojení přicházející ze serveru Avamar do klienta.
Důležitou součástí je, že klient nebo proxy server získal potřebné certifikáty na straně klienta, aby mohl provést vzájemný handshake TLS, pokud to GSAN vyžaduje.
To znamená, že pokud se změní interní kořenová certifikační autorita Avamar, klient, proxy server nebo systém Data Domain musí získat novou kořenovou certifikační autoritu, aby pro ně mohla podepsat certifikáty.
Po úspěšném připojení klienta nebo proxy serveru ke GSAN se pokusí o připojení k systému Data Domain.
Následující protokol ukazuje proxy server, který se připojuje k systému Data Domain pomocí služby avtar. Nastavení verifypeer je zakázáno, ale funkce Session Security je povolena (režim Authenticated-Single).
Vzhledem k tomu, že verifypeer je nastavení serveru Avamar GSAN, nemá vliv na přímé připojení služby avtar k systému Data Domain, když je povolena funkce Session Security. To znamená, že mezi klientem nebo proxy serverem a systémem Data Domain dojde ke vzájemnému handshaku TLS.
Klient nebo proxy server může ověřit řetězec certifikátů Data Domain, protože sdílí stejnou interní kořenovou certifikační autoritu Avamar, kterou software Avamar importoval při registraci klienta (nebo při úpravě či připojení systému DD).
Po ověření certifikátu se handshake dokončí a zálohovaná data se přesunou z klienta do systému Data Domain a Avamar v síti.
Správa nastavení funkce Session Security
Následující dva články slouží ke správě nastavení funkce Session Security z příkazového řádku nebo webové služby Avinstaller.
000222234 | Avamar: Správa nastavení funkce Session Security z rozhraní příkazového řádku
000222279 | Avamar: Správa nastavení funkce Session Security pomocí instalačního balíčku Avinstaller (AVP)
Disabled
Nastavení:
Když je funkce Session Security zakázána, klienti se připojují ke službě Avagent systému Avamar pouze na portu 28001 a klienti naslouchají požadavkům Avamar na portu 28002.
Proxy server naslouchá na portu 28009.
Port 28001 je prostý socket TCP a neprovádí handshake TLS.
Klient se připojí k Avamar GSAN na portu 29000 a provede jednosměrný handshake TLS. To znamená, že i když je funkce Session Security zakázána, při přenosu zálohovaných dat mezi klientem a softwarem Avamar se data zálohy stále šifrují za běhu.
Mezi softwarem Avamar, servery proxy, klienty a systémem Data Domain se nevyměňují certifikáty pro ověření pomocí softwaru Avamar.
Mixed-Single
Nastavení:
Režim Mixed-Single se více používal, když byla v softwaru Avamar 7.3 poprvé představena funkce Session Security, což výslovně umožňovalo klientům, jejichž verze nebyla 7.3 nebo vyšší, zaregistrovat se a zálohovat do systému Avamar. V době psaní tohoto článku je nejnovější verzí Avamar 19.10 a režim Mixed-Single je v podstatě stejný jako další režim, který si popíšeme.
Authenticated-Single
Nastavení:
V tomto režimu je povolena funkce Session Security a certifikáty se předávají mezi systémem Avamar, klienty, servery proxy a systémem Data Domain za účelem ověření před zálohováním.
Klienti nyní na portu 30002 naslouchají požadavkům na pracovní příkazy Avagent ze systému Avamar a proxy servery naslouchají na portu 30009. Systém Avamar naslouchá na portech 30001 a 30003 požadavkům na připojení od klientů a proxy serverů. Jedná se o sokety SSL, které provádějí handshake TLS.
Režim Authenticated-Single na rozdíl od režimu Mixed-Single vynutí, aby se všichni klienti zaregistrovali pomocí metod funkce Session Security.
Tento režim nastaví možnost verifypeer ve službě GSAN systému Avamar na hodnotu Disabled, což znamená, že GSAN nebude vyžadovat certifikáty klientů z příchozího připojení AVTAR.
Authenticated-Dual
Nastavení:
Režim Authenticated-Dual je stejný jako režim Authenticated-Single s tím rozdílem, že umožňuje povolit nastavení verifypeer ve službě GSAN systému Avamar.
Authenticated-Dual se považuje za nejsilnější nastavení pro server Avamar a je výchozí volbou při nasazování softwaru Avamar.
Přehled: Interní kořenová certifikační autorita Avamar podepsaná držitelem
Interní kořenová certifikační autorita Avamar je interně důvěryhodnou certifikační autoritou pro systém Avamar a klienty, proxy servery a systémy Data Domain, které do nich software Avamar importuje.
Avamar je interní certifikační autoritou sám pro sebe, protože vystavuje certifikáty pro žádosti o podpis certifikátů (CSR).
Když software Avamar používá kořenovou certifikační autoritu k podepisování certifikátů pro službu GSAN, uloží se certifikáty do následujícího umístění:
Pokud bezpečnostní skener naskenuje port 29000 na systému Avamar, nahlásí certifikáty podepsané držitelem na tomto portu, který zpracovává zálohy do služby GSAN.
V některých prostředích to nemusí být přijatelné a doporučujeme přečíst si následující článek znalostní databáze, který obsahuje další informace o nahrazení interní kořenové certifikační autority Avamar interní kořenovou certifikační autoritou poskytnutou uživatelem.
Článek znalostní databáze 000204629 | Avamar: Instalace/nahrazení certifikační autority Avamar za certifikační autoritu dodanou uživatelem
Tento proces podrobně popisuje, jak pomocí skriptu importcert.sh nainstalovat interní certifikační autoritu pro danou společnost poskytnutou uživatelem. Certifikační autorita poskytnutá uživatelem je pravděpodobně spravována bezpečnostním týmem, protože žádná veřejná certifikační autorita neprozradí svůj soukromý klíč – vydělává peníze podepisováním certifikátů pro ostatní a udržováním řetězce důvěry.
Příkladem interní certifikační autority může být služba Microsoft Active Directory Certificate Services.
Co je služba Active Directory Certificate Services? | Microsoft Learn
Příkladem veřejné certifikační autority může být DigiCert.
Výměna interní kořenové certifikační autority Avamar funguje tak, že kořenový pár klíčů v úložišti klíčů Avamar nahradíte párem klíčů certifikační autority poskytnuté uživatelem. Poté služba GSAN vygeneruje požadavek CSR a soukromý klíč, podepíše požadavek CSR novým párem klíčů certifikační autority a nahradí soubory zmíněné výše v této části. Služba GSAN znovu načte socket SSL na portu 29000 a noví klienti, kteří se připojují ke službě GSAN, uvidí certifikační autoritu poskytnutou uživatelem.
Bezpečnostní skenery nyní na portu zobrazují podepsané certifikáty a klienti, proxy servery a systém Data Domain se budou muset znovu zaregistrovat a získat tak novou certifikační autoritu.
Omezení
Funkce Avamar Session Security mají určitá omezení:
Plánování změn funkce Session Security
Před změnou nastavení funkce Session Security lze provést následující kroky, abyste měli možnost obnovit předchozí konfiguraci nebo certifikáty před provedením jakýchkoli změn.
Nezapomeňte, že pokud dojde ke změně interní kořenové certifikační autority Avamar, klienti, proxy servery a systém Data Domain se musí znovu zaregistrovat. V závislosti na velikosti prostředí (počet klientů, proxy serverů a systémů Data Domain) se může jednat o složitý úkol, který zabere několik dní.
Možný případ použití je například takový, kdyby se certifikáty znovu vygenerovaly a poté došlo k selhání registrace a zálohování.
Za předpokladu, že certifikáty jsou stále platné a že se znovu vygenerovaly možná náhodou, nabízí následující kroky určité pokyny, jak zabránit ztrátě nebo nedostupnosti dat.
Získejte aktuální nastavení funkce Session Security a poznamenejte si je:
Vytvořte kopii úložiště klíčů Avamar:
Předpokládejme, že certifikáty jsou nyní znovu vygenerovány, a to pomocí metody AVP nebo rozhraní příkazového řádku funkce Session Security.
To znamená, že úložiště klíčů Avamar se změnilo a certifikáty GSAN byly znovu podepsány.
Původní úložiště klíčů Avamar lze jednoduše přesunout zpět na místo:
Znovu vygenerujte certifikáty GSAN:
Session Security: Průvodce zabezpečením produktu
Klienti Avamar mohou pomocí funkce Session Security zabezpečit veškerou komunikaci mezi serverem Avamar a softwarem klientem Avamar. Server Avamar zajišťuje ověřování klienta Avamar a klient Avamar zajišťuje ověřování serveru Avamar.
Mezi možnosti funkce Session Security patří vylepšení zabezpečení komunikace mezi procesy systému Avamar.
Systém Avamar zabezpečuje veškerou komunikaci mezi procesy systému Avamar pomocí tiketů relace. Než proces Avamar přijme přenos z jiného procesu Avamar, je vyžadován platný tiket relace.
Tikety relace mají následující obecné charakteristiky:
- Tiket relace je zašifrován a podepsán, aby byl chráněn před změnami.
- Tiket relace je krátkodobý.
- Každý tiket relace obsahuje jedinečný podpis a je přiřazen pouze k jednomu procesu Avamar.
- Integrita tiketu relace je chráněna šifrováním.
- Každý uzel systému Avamar samostatně ověřuje podpis tiketu relace.
- V případě potřeby lze relaci prodloužit nad dobu životnosti tiketu relace.
Systém Avamar nainstaluje veřejný klíč pro certifikát serveru do každého klienta Avamar, který je zaregistrován na serveru Avamar. Klienti Avamar používají veřejný klíč k ověření přenosů ze systému Avamar.
U klientů, kteří jsou aktuálně registrováni, se veřejný klíč pro certifikát serveru a další požadované soubory certifikátů přenesou do klienta do jedné hodiny od instalace.
Systém Avamar také automaticky sdílí certifikát serveru Avamar s uzly úložiště Avamar. Sdílení certifikátu umožňuje uzlu nástroje a uzlům úložiště poskytovat stejný certifikát pro ověření.
Certifikát klienta se vygeneruje, když server Avamar zaregistruje klienta Avamar.
Po vygenerování certifikátu klienta systém Avamar použije šifrované připojení ke klientovi Avamar k instalaci certifikátu do klienta. Systém Avamar také ukládá veřejný klíč certifikátu klienta. Veřejný klíč se používá k ověření klienta při veškeré následné komunikaci.
Jak funguje Session Security?
Funkce Session Security se povoluje na serveru Avamar. Když ji aktivujete, klienti, proxy servery a systémy Data Domain projdou speciálním procesem registrace certifikátu u systému Avamar.
V klientovi se systémem Windows nebo Linux a proxy serveru se při registraci zobrazí, že server má Avamar povolenou funkci Session Security. Software Avamar odešle klientovi svou interní kořenovou certifikační autoritu (chain.pem), aby ji klient mohl uložit a důvěřovat jí. Klient vygeneruje žádost o podpis certifikátu (CSR). Požadavek CSR (avclient.csr) se odešle z klienta do procesu MCS serveru Avamar, který požadavek CSR podepíše a vrátí klientovi pár klíčů certifikátu (key.pem a cert.pem).
Při připojování systému Data Domain k systému Avamar nebo při obnovení komunikace SSL systém Avamar zjistí, že systém Data Domain nemá podepsaný certifikát od sebe ani od jiného ověřeného systému Avamar (imported-host ddboost). Software Avamar použije soukromý klíč ssh systému Data Domain k přihlášení do systému Data Domain za účelem spuštění příkazů ssh přes prostředí ddsh (Data Domain shell). Software Avamar převezme žádost o podpis certifikátu (CSR) systému Data Domain přes SCP a podepíše žádost CSR pomocí interní kořenové certifikační autority Avamar. Jakmile má systém Data Domain podepsaný certifikát od systému Avamar (imported-host ddboost), software Avamar naimportuje kořenovou certifikační autoritu, která certifikát podepsala (chain.pem jako imported-ca ddboost/login-auth).
Nyní, když je klient / proxy server zaregistrován a má certifikáty na straně klienta potřebné k ověření pomocí MCS systému Avamar, dojde k pokusu o zálohu. Systém Avamar odešle pracovní příkaz naslouchacímu procesu Avagent klienta nebo proxy serveru, který pracovní příkaz převezme. Klient nebo proxy server poté ověří řetězec certifikátů serveru Avamar pomocí kořenové certifikační autority Avamar, kterou software Avamar importoval do klienta při registraci. Podobně software Avamar ověří klienta nebo proxy server. V tomto okamžiku nebyla předána žádná data.
Po úspěšném ověření se spustí pracovní příkaz a stav pracovního příkazu se změní z „Waiting-Client“ na „Running“.
Nyní klienti a proxy servery nakonec přesunou data do systému Avamar a Data Domain pomocí nainstalovaného binárního souboru avtar. Binární soubor avtar předá některé příznaky, které určují podrobnosti o tom, jak a jaká data se přesouvají.
Když se služba avtar v klientovi nebo proxy serveru připojí ke službě GSAN systému Avamar, musí vědět, zda je povolena funkce verifypeer. Nastavení verifypeer je nastavení serveru GSAN jako součást konfigurace funkce Session Security, která řídí soket SSL GSAN na portu 29000 tím, že mu říká, zda má nebo nemá vyžadovat certifikáty klienta pro každé příchozí připojení. Naštěstí je implementován protokol TLS 1.2, který automaticky zpracovává, jak klient nebo proxy server předloží své certifikáty klienta službě GSAN během handshaku TLS.
Následuje ukázka vzájemného/obousměrného handshaku protokolu TLS, když je povolená funkce verifypeer.
Z pohledu klienta nebo proxy serveru představuje šipka vpravo připojení k serveru Avamar. Šipka vlevo představuje připojení přicházející ze serveru Avamar do klienta.
[avtar] --> SSL [avtar] --> TLS 1.2 Handshake, ClientHello [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, ServerHello [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, Certificate [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, ServerKeyExchange [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, CertificateRequest [avtar] <-- TLS 1.2 Handshake, ServerHelloDone [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, Certificate [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, ClientKeyExchange [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, CertificateVerify [avtar] --> SSL [avtar] --> TLS 1.2 ChangeCipherSpec [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, Finished [avtar] <-- SSL [avtar] <-- TLS 1.2 ChangeCipherSpec [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, Finished
Když je funkce verifypeer zakázána, klient nemusí do GSAN odesílat klientský certifikát.
[avtar] --> SSL [avtar] --> TLS 1.2 Handshake, ClientHello [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, ServerHello [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, Certificate [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, ServerKeyExchange [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, ServerHelloDone [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, ClientKeyExchange [avtar] --> SSL [avtar] --> TLS 1.2 ChangeCipherSpec [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, Finished [avtar] <-- SSL [avtar] <-- TLS 1.2 ChangeCipherSpec [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, Finished
Důležitou součástí je, že klient nebo proxy server získal potřebné certifikáty na straně klienta, aby mohl provést vzájemný handshake TLS, pokud to GSAN vyžaduje.
To znamená, že pokud se změní interní kořenová certifikační autorita Avamar, klient, proxy server nebo systém Data Domain musí získat novou kořenovou certifikační autoritu, aby pro ně mohla podepsat certifikáty.
Po úspěšném připojení klienta nebo proxy serveru ke GSAN se pokusí o připojení k systému Data Domain.
Následující protokol ukazuje proxy server, který se připojuje k systému Data Domain pomocí služby avtar. Nastavení verifypeer je zakázáno, ale funkce Session Security je povolena (režim Authenticated-Single).
2024-02-22 17:37:32 avtar Info <40058>: - Client connecting to the Avamar Server using authentication, client connecting to the Data Domain system using two-way authentication 2024-02-22 17:37:33 avtar Info <44068>: - Data Domain Engine Set FIPS OFF 2024-02-22 17:37:33 avtar Info <16684>: - Data Domain Engine (7.11.0.0 build 1033042) 2024-02-22 17:37:33 avtar Info <40174>: Multi-stream restore via cloning is enabled. 2024-02-22 17:37:33 avtar Info <10632>: Using Client-ID='6bf19b025be80a12da2e7b932da60079709906ae' 2024-02-22 17:37:33 avtar Info <40062>: GSAN connected via: IPv4, retrieved Data Domain IPv4 hostname = lab.dd.com 2024-02-22 17:37:33 avtar Info <10539>: Connecting to Data Domain Server "lab.dd.com"(1) (LSU: avamar-1704339590) with auth token 2024-02-22 17:37:33 avtar Info <10540>: - Resolved Data Domain Server name "lab.dd.com" to the IP address "10.x.x.x" 2024-02-22 17:37:33 avtar Info <41236>: - Connecting to Data Domain Server name "lab.dd.com" with token:e2602cc64ce8c4782ca877cabe355191042d0fb4 2024-02-22 17:37:33 avtar Info <0000>: - Connecting to: DataDomain: lab.dd.com encryption strength: 2 auth_mode: 2 client_cert /usr/local/avamarclient/etc/cert.pem client_key: /usr/local/avamarclient/etc/key.pem server_cert: /tmp/.tmp_avamar/MOD-1708623043157#1_65d7865c_68ce32dc.pem chain_cert: /usr/local/avamarclient/etc/chain.pem
Vzhledem k tomu, že verifypeer je nastavení serveru Avamar GSAN, nemá vliv na přímé připojení služby avtar k systému Data Domain, když je povolena funkce Session Security. To znamená, že mezi klientem nebo proxy serverem a systémem Data Domain dojde ke vzájemnému handshaku TLS.
Klient nebo proxy server může ověřit řetězec certifikátů Data Domain, protože sdílí stejnou interní kořenovou certifikační autoritu Avamar, kterou software Avamar importoval při registraci klienta (nebo při úpravě či připojení systému DD).
Proxy ------ Avamar internal root CA /usr/local/avamarclient/etc/chain.pem Data Domain -------------- Avamar internal root CA run command to view certificate list on DD: adminaccess certificate show imported-ca ddboost /usr/local/avamarclient/etc/chain.pem == imported-ca ddboost
Po ověření certifikátu se handshake dokončí a zálohovaná data se přesunou z klienta do systému Data Domain a Avamar v síti.
Správa nastavení funkce Session Security
Následující dva články slouží ke správě nastavení funkce Session Security z příkazového řádku nebo webové služby Avinstaller.
000222234 | Avamar: Správa nastavení funkce Session Security z rozhraní příkazového řádku
000222279 | Avamar: Správa nastavení funkce Session Security pomocí instalačního balíčku Avinstaller (AVP)
Existují čtyři možné podporované konfigurace:
- Disabled
- Mixed-Single
- Authenticated-Single
- Authenticated-Dual
Disabled
Nastavení:
Current Session Security Settings ---------------------------------- "encrypt_server_authenticate" ="false" "secure_agent_feature_on" ="false" "session_ticket_feature_on" ="false" "secure_agents_mode" ="unsecure_only" "secure_st_mode" ="unsecure_only" "secure_dd_feature_on" ="false" "verifypeer" ="no"
Když je funkce Session Security zakázána, klienti se připojují ke službě Avagent systému Avamar pouze na portu 28001 a klienti naslouchají požadavkům Avamar na portu 28002.
Proxy server naslouchá na portu 28009.
Port 28001 je prostý socket TCP a neprovádí handshake TLS.
Klient se připojí k Avamar GSAN na portu 29000 a provede jednosměrný handshake TLS. To znamená, že i když je funkce Session Security zakázána, při přenosu zálohovaných dat mezi klientem a softwarem Avamar se data zálohy stále šifrují za běhu.
Mezi softwarem Avamar, servery proxy, klienty a systémem Data Domain se nevyměňují certifikáty pro ověření pomocí softwaru Avamar.
Mixed-Single
Nastavení:
Current Session Security Settings ---------------------------------- "encrypt_server_authenticate" ="true" "secure_agent_feature_on" ="true" "session_ticket_feature_on" ="true" "secure_agents_mode" ="mixed" "secure_st_mode" ="mixed" "secure_dd_feature_on" ="true" "verifypeer" ="no"
Režim Mixed-Single se více používal, když byla v softwaru Avamar 7.3 poprvé představena funkce Session Security, což výslovně umožňovalo klientům, jejichž verze nebyla 7.3 nebo vyšší, zaregistrovat se a zálohovat do systému Avamar. V době psaní tohoto článku je nejnovější verzí Avamar 19.10 a režim Mixed-Single je v podstatě stejný jako další režim, který si popíšeme.
Authenticated-Single
Nastavení:
Current Session Security Settings ---------------------------------- "encrypt_server_authenticate" ="true" "secure_agent_feature_on" ="true" "session_ticket_feature_on" ="true" "secure_agents_mode" ="secure_only" "secure_st_mode" ="secure_only" "secure_dd_feature_on" ="true" "verifypeer" ="no"
V tomto režimu je povolena funkce Session Security a certifikáty se předávají mezi systémem Avamar, klienty, servery proxy a systémem Data Domain za účelem ověření před zálohováním.
Klienti nyní na portu 30002 naslouchají požadavkům na pracovní příkazy Avagent ze systému Avamar a proxy servery naslouchají na portu 30009. Systém Avamar naslouchá na portech 30001 a 30003 požadavkům na připojení od klientů a proxy serverů. Jedná se o sokety SSL, které provádějí handshake TLS.
Režim Authenticated-Single na rozdíl od režimu Mixed-Single vynutí, aby se všichni klienti zaregistrovali pomocí metod funkce Session Security.
Tento režim nastaví možnost verifypeer ve službě GSAN systému Avamar na hodnotu Disabled, což znamená, že GSAN nebude vyžadovat certifikáty klientů z příchozího připojení AVTAR.
Authenticated-Dual
Nastavení:
Current Session Security Settings ---------------------------------- "encrypt_server_authenticate" ="true" "secure_agent_feature_on" ="true" "session_ticket_feature_on" ="true" "secure_agents_mode" ="secure_only" "secure_st_mode" ="secure_only" "secure_dd_feature_on" ="true" "verifypeer" ="yes"
Režim Authenticated-Dual je stejný jako režim Authenticated-Single s tím rozdílem, že umožňuje povolit nastavení verifypeer ve službě GSAN systému Avamar.
Authenticated-Dual se považuje za nejsilnější nastavení pro server Avamar a je výchozí volbou při nasazování softwaru Avamar.
Přehled: Interní kořenová certifikační autorita Avamar podepsaná držitelem
Interní kořenová certifikační autorita Avamar je interně důvěryhodnou certifikační autoritou pro systém Avamar a klienty, proxy servery a systémy Data Domain, které do nich software Avamar importuje.
Avamar je interní certifikační autoritou sám pro sebe, protože vystavuje certifikáty pro žádosti o podpis certifikátů (CSR).
Když software Avamar používá kořenovou certifikační autoritu k podepisování certifikátů pro službu GSAN, uloží se certifikáty do následujícího umístění:
/home/admin/chain.pem /home/admin/cert.pem /home/admin/key.pem /usr/local/avamar/etc/chain.pem /usr/local/avamar/etc/cert.pem /usr/local/avamar/etc/key.pem
Pokud bezpečnostní skener naskenuje port 29000 na systému Avamar, nahlásí certifikáty podepsané držitelem na tomto portu, který zpracovává zálohy do služby GSAN.
V některých prostředích to nemusí být přijatelné a doporučujeme přečíst si následující článek znalostní databáze, který obsahuje další informace o nahrazení interní kořenové certifikační autority Avamar interní kořenovou certifikační autoritou poskytnutou uživatelem.
Článek znalostní databáze 000204629 | Avamar: Instalace/nahrazení certifikační autority Avamar za certifikační autoritu dodanou uživatelem
Tento proces podrobně popisuje, jak pomocí skriptu importcert.sh nainstalovat interní certifikační autoritu pro danou společnost poskytnutou uživatelem. Certifikační autorita poskytnutá uživatelem je pravděpodobně spravována bezpečnostním týmem, protože žádná veřejná certifikační autorita neprozradí svůj soukromý klíč – vydělává peníze podepisováním certifikátů pro ostatní a udržováním řetězce důvěry.
Příkladem interní certifikační autority může být služba Microsoft Active Directory Certificate Services.
Co je služba Active Directory Certificate Services? | Microsoft Learn
Příkladem veřejné certifikační autority může být DigiCert.
Výměna interní kořenové certifikační autority Avamar funguje tak, že kořenový pár klíčů v úložišti klíčů Avamar nahradíte párem klíčů certifikační autority poskytnuté uživatelem. Poté služba GSAN vygeneruje požadavek CSR a soukromý klíč, podepíše požadavek CSR novým párem klíčů certifikační autority a nahradí soubory zmíněné výše v této části. Služba GSAN znovu načte socket SSL na portu 29000 a noví klienti, kteří se připojují ke službě GSAN, uvidí certifikační autoritu poskytnutou uživatelem.
Bezpečnostní skenery nyní na portu zobrazují podepsané certifikáty a klienti, proxy servery a systém Data Domain se budou muset znovu zaregistrovat a získat tak novou certifikační autoritu.
Omezení
Funkce Avamar Session Security mají určitá omezení:
- Klienti
- Funkce Session Security nelze použít se žádným z následujících klientů Avamar:
- Clusterový klient Avamar pro systém Solaris na clusterovém serveru Veritas
- Klient Avamar pro systém Solaris v clusterech Solaris
- Funkce Session Security nelze použít se žádným z následujících klientů Avamar:
- Ostatní produkty
- Doporučujeme používat synchronizaci času NTP serveru Avamar, klientů Avamar a systému Data Domain (pokud je to možné). Pokud se čas nesynchronizuje, může to způsobit selhání registrace a zálohování/obnovení z důvodu platnosti certifikátu a doby vypršení platnosti. Změna časového pásma na hostiteli může mít podobný dopad a může vyžadovat opětovné vygenerování certifikátu.
- Zabezpečený token
- Ověřování zabezpečeného tokenu nefunguje za následujících podmínek:
- Klientský počítač se nachází za zařízením firewallu pro překlad síťových adres (NAT).
- Název hostitele klienta je virtuální název, který se liší od plně kvalifikovaného názvu domény přeloženého z jeho IP adresy.
- Klientský počítač má více rozhraní IP a každé z nich se překládá na jiný plně kvalifikovaný název domény (FQDN). Další informace naleznete v následujícím článku: KB 000056252 | Avamar: Zálohování do systému Data Domain selhalo se zprávou „DDR_GET_AUTH_TOKEN“ kvůli příliš velkému počtu IP adres
- Ověřování zabezpečeného tokenu nefunguje za následujících podmínek:
Plánování změn funkce Session Security
Před změnou nastavení funkce Session Security lze provést následující kroky, abyste měli možnost obnovit předchozí konfiguraci nebo certifikáty před provedením jakýchkoli změn.
Nezapomeňte, že pokud dojde ke změně interní kořenové certifikační autority Avamar, klienti, proxy servery a systém Data Domain se musí znovu zaregistrovat. V závislosti na velikosti prostředí (počet klientů, proxy serverů a systémů Data Domain) se může jednat o složitý úkol, který zabere několik dní.
Možný případ použití je například takový, kdyby se certifikáty znovu vygenerovaly a poté došlo k selhání registrace a zálohování.
Za předpokladu, že certifikáty jsou stále platné a že se znovu vygenerovaly možná náhodou, nabízí následující kroky určité pokyny, jak zabránit ztrátě nebo nedostupnosti dat.
Získejte aktuální nastavení funkce Session Security a poznamenejte si je:
enable_secure_config.sh --showconfig
Vytvořte kopii úložiště klíčů Avamar:
cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original
Předpokládejme, že certifikáty jsou nyní znovu vygenerovány, a to pomocí metody AVP nebo rozhraní příkazového řádku funkce Session Security.
To znamená, že úložiště klíčů Avamar se změnilo a certifikáty GSAN byly znovu podepsány.
Původní úložiště klíčů Avamar lze jednoduše přesunout zpět na místo:
cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore
Znovu vygenerujte certifikáty GSAN:
enable_secure_config.sh --certs
Restartujte službu MCS a plánovač záloh:
mcserver.sh --restart --force dpnctl start sched
Tím se obnoví původní interní kořenová certifikační autorita Avamar, které klienti, proxy servery a systém Data Domain již důvěřovali.
Odstraňování problémů
Ve většině případů je změna nastavení funkce Session Security nebo opětovné vygenerování certifikátů jednoduché.
Tato část se zaměřuje na to, jak zajistit, aby vše opět fungovalo po opětovném vygenerování certifikátů nebo změně nastavení.
Místní čištění
V případě, kdy je povolena funkce verifypeer a po opětovném vygenerování všech certifikátů Avamar se klientské certifikáty, které používají služby avtar a avmgr serveru Avamar, neaktualizují okamžitě.
To znamená, že když služba MCS spustí plánované čištění (zálohování konfigurace MCS do služby GSAN), dojde k selhání kvůli chybě handshaku TLS. Důvodem je to, že klientské certifikáty pro službu avtar spuštěnou na serveru Avamar dosud nedostaly aktualizovanou interní kořenovou certifikační autoritu Avamar a novou sadu podepsaných certifikátů klienta.
Další informace naleznete v následujícím článku znalostní databáze:
000214340 | Avamar: Služba avtar se nemůže připojit ke službě Avamar GSAN s chybou „Fatal server connection problem, aborting initialization. Verify correct server address and login credentials.“
Replikace
V případě, kdy je v cíli replikace povolena funkce verifypeer a v cíli dochází k opětovnému vygenerování certifikátů, je třeba použít podobný přístup z výše uvedené části „Místní čištění“.
Nejprve se ujistěte, že je cíl replikace Avagent zaregistrován, aby mohl přijímat pracovní příkazy replikace.
V cíli zkontrolujte protokol Avagent v následujícím umístění:
/usr/local/avamar/var/client/avagent.log
Protokol, který je v pořádku, může vypadat takto:
2024-02-22 15:31:57 avagent Info <5964>: Requesting work from avamar.lab 2024-02-22 15:31:57 avagent Info <5264>: Workorder received: sleep 2024-02-22 15:31:57 avagent Info <5996>: Sleeping 15 seconds 2024-02-22 15:32:12 avagent Info <40019>: Checking certificate status. 2024-02-22 15:32:12 avagent Info <43701>: agent_message::resolve_client_ip ping to MCS avamar.lab:10.x.x.x using local IP:10.x.x.x failed, timed out on receive 2024-02-22 15:32:12 avagent Info <5964>: Requesting work from avamar.lab 2024-02-22 15:32:12 avagent Info <5264>: Workorder received: sleep 2024-02-22 15:32:12 avagent Info <5996>: Sleeping 15 seconds
Při přechodu dále do protokolu můžete najít záznam o nedávné úspěšné opětovné registraci:
2024-02-22 15:09:00 avagent Info <7502>: Registration of client /MC_SYSTEM/avamar.lab with MCS avamar.lab:30001 successful. 2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1008 Replicate successful. 2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1038 vmir successful. 2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1046 Migrate successful. 2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1051 Tiering successful. 2024-02-22 15:09:00 avagent Info <5619>: Registration of client and plugins complete. 2024-02-22 15:09:00 avagent Info <5996>: Sleeping 60 seconds
Protokol, který není v pořádku a obsahuje problémy s registrací způsobené změnami certifikátu, může vypadat takto:
2024-02-22 15:04:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure 2024-02-22 15:04:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001. 2024-02-22 15:04:57 avagent Info <5059>: unable to connect, sleep(60) then retrying 2024-02-22 15:05:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure 2024-02-22 15:05:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001. 2024-02-22 15:05:57 avagent Info <5059>: unable to connect, sleep(60) then retrying 2024-02-22 15:06:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure 2024-02-22 15:06:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001.
V tomto případě je k vynucené opětovné registraci Avagent u služby MCS nutné provést následující kroky:
Získejte název účtu MC_SYSTEM, který bude pravděpodobně plně kvalifikovaným názvem domény Avamar:
mccli client show --domain=/MC_SYSTEM | grep MC_SYSTEM | awk '{print $1}'
example:
root@avamar:/usr/local/avamar/lib/#: mccli client show --domain=/MC_SYSTEM | grep MC_SYSTEM | awk '{print $1}'
avamar.lab
Deaktivujte účet MC_SYSTEM:
mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false example: mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false
Opět zaregistrujte účet MC_SYSTEM:
/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM example: /etc/init.d/avagent register avamar.lab /MC_SYSTEM
Po úspěšné registraci může služba Avagent přijmout replikaci v cíli.
Pokud je v cíli replikace Avamar povolena funkce verifypeer, je třeba ve zdrojovém systému Avamar znovu vygenerovat certifikáty klienta používané pro připojení k cílovému systému Avamar.
Podobné článku KB 000214340 | Avamar: Služba avtar se nemůže připojit ke službě Avamar GSAN s chybou „Fatal server connection problem, aborting initialization. Verify correct server address and login credentials.“
Odeberte stávající složku s certifikáty z cílového systému Avamar ze relace ssh zdrojového systému Avamar:
rm -r /usr/local/avamar/etc/<destination_avamar_ip_address> rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>
Znovu vygenerujte certifikáty klienta:
/usr/local/avamar/bin/avagent.bin --gencerts=true --mcsaddr=<destination_avamar_ip_address> /usr/local/avamar/bin/avagent.bin --gencerts=true --mcsaddr=<destination_avamar_ip_address> --sysdir=/usr/local/avamar/etc/client
Komunikaci s cílovým systémem Avamar lze otestovat z příkazového řádku ssh zdrojového systému Avamar:
avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192
Registrace klienta
Po změně nastavení funkce Session Security nebo opětovném vygenerování certifikátů můžete zkusit provést zálohu.
To může vést k tomu, že mnoho klientů na bázi agenta bude ve stavu „Waiting-Client“, dokud zálohování neselže se stavem „Timed-Out Start“.
Po opětovném vygenerování nových certifikátů by mělo trvat přibližně 23 hodin, než se klient automaticky pokusí o opětovnou registraci.
Následující příkaz lze použít na serveru Avamar k odeslání pozvánky klientům na bázi agentů k opětovné registraci u systému Avamar MCS.
mccli client re-register-all
Příkaz může nějakou dobu trvat v závislosti na počtu klientů, protože pozvánku pošle postupně každému z nich. Zvažte spuštění příkazu na pozadí pro případ, že vyprší časový limit relace ssh.
nohup mccli client re-register-all &
Upozorňujeme, že to nemusí fungovat při opětovné registraci všech klientů na bázi agenta a některé může být nutné znovu zaregistrovat ručně.
Ruční proces opětovné registrace klienta v systému Windows:
- Odeberte obsah následujícího adresáře, který obsahuje staré certifikáty klienta:
-
"C:\Program Files\avs\etc"
-
- Restartujte službu „Backup Agent“.
- Odeberte obsah následujícího adresáře, který obsahuje staré certifikáty klienta:
-
/usr/local/avamar/etc
-
- Restartujte službu Avagent:
-
service avagent restart
-
Lze také restartovat klientský počítač a pokusit se tak spustit úplnou opětovnou registraci.
Mějte na paměti, že překlad názvů hraje důležitou roli při registraci klientů, když je povolená funkce Session Security. Ujistěte se, že klienti mohou provádět dopředné a zpětné vyhledávání DNS serveru Avamar a naopak. Toho lze dosáhnout konfigurací DNS záznamů typu A nebo položek hostitelů v klientovi.
Software Avamar neposkytuje žádný druh skriptu, který by mohl kontaktovat každého připojeného klienta za účelem provedení ruční opětovné registrace. Nejblíže tomu má výše uvedený příkaz mccli.
Registrace proxy serveru
Virtuální počítače zálohované do systému Avamar pomocí proxy serverů, jsou poněkud ve výhodě, pokud jde o změny zabezpečení po relaci, protože obvykle existuje mnohem méně proxy serverů než klientů na bázi agenta.
Proxy servery by se také měly pokusit o automatickou opětovnou registraci do 23 hodin, ale může být jednodušší a rychlejší je znovu zaregistrovat okamžitě.
Existuje několik možností, jak zkusit vynutit opětovnou registraci na proxy serverech.
První možností může být restartovat proxy servery pomocí následujícího příkazu:
mccli mcs reboot-proxy --all
Druhou možností by bylo použít ke správě proxy serverů nástroj Goav.
Nastavte heslo proxy serveru pro nástroj Goav, aby se mohl přihlásit k proxy serverům, kdykoli bude potřebovat. Následující příkaz nezmění heslo operačního systému proxy serveru, pouze uloží zašifrované heslo, aby jej nástroj Goav mohl použít k přihlášení k proxy serveru přes ssh, kdykoli to bude třeba.
./goav proxy set-password
Restartujte službu Avagent na všech připojených proxy serverech:
./goav proxy exec "service avagent restart"
Chcete-li zkontrolovat protokol Avagent na proxy serveru a zjistit, zda došlo k úspěšné opětovné registraci, spusťte následující příkaz:
./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"
Úspěšný výstup může vypadat takto:
============== proxy.lab.emc.com ========================= Executing grep -i registration /usr/local/avamarclient/var/avagent.log on proxy.lab.emc.com 2024-02-23 17:54:06 avagent Info <18918>: Registration: Processing secure registration with the MCS. 2024-02-23 17:54:06 avagent Info <18923>: Registration: Certificate files are present. 2024-02-23 17:54:09 avagent Info <5470>: Updating registration information with the MCS (10.x.x.x), paging enabled 2024-02-23 17:54:09 avagent Info <7501>: Client registration updated 3cbe29134da771ac547b7105743e66633ff12d40 10.x.x.x(1704339590) 2024-02-23 17:54:09 avagent Info <7502>: Registration of client /clients/proxy.lab.emc.com with MCS 10.x.x.x:30001 successful. 2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1019 vmwfilel successful. 2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 3019 vmwfilew successful. 2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1016 vmimagel successful. 2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 3016 vmimagew successful. 2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1001 Unix successful. 2024-02-23 17:54:09 avagent Info <5619>: Registration of client and plugins complete.
Třetí možností je připojit se přes ssh k proxy serveru a spustit inicializační skript:
/usr/local/avamarclient/etc/initproxyappliance.sh start
Synchronizace systému Data Domain
Po změně nastavení funkce Session Security nebo opětovného vygenerování certifikátů v systému Avamar je nutné znovu synchronizovat systém Data Domain nebo obnovit připojení SSL.
Následující článek znalostní databáze popisuje tento scénář a postup výměny nových certifikátů se systémem Data Domain.
000197106 | Integrace systému Avamar a Data Domain: Systém DD se v rozhraní Avamar AUI nebo v uživatelském rozhraní zobrazuje červeně (řešení)
Důrazně doporučujeme řešit problémy s připojením SSL systému Avamar a Data Domain pomocí nástroje Goav.
Pomocí nástroje Goav lze automaticky diagnostikovat a vyřešit připojení SSL systému Data Domain k systému Avamar. Další informace naleznete v následujícím článku znalostní databáze:
000215679 | Avamar: Informace o funkci dd check-ssl nástroje Goav
Spuštěním následujícího příkazu automaticky opravíte certifikáty Avamar a Data Domain:
./goav dd check-ssl --fix
Affected Products
Avamar, Data DomainArticle Properties
Article Number: 000222278
Article Type: How To
Last Modified: 06 Feb 2025
Version: 3
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.