Avamar: Øktsikkerhet
Summary: Denne artikkelen beskriver hva Session Security er på Avamar, hvordan det fungerer, og hvordan du administrerer det.
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
Hva er øktsikkerhet?
Øktsikkerhet: Veiledning
for produktsikkerhetAvamar-klienter kan bruke øktsikkerhet til å sikre all kommunikasjon mellom Avamar-serveren og Avamar-klientprogramvaren. Avamar-serveren gir godkjenning til Avamar-klienten, og Avamar-klienten gir godkjenning til Avamar-serveren.
Sikkerhetsfunksjoner for økter inkluderer sikkerhetsforbedringer for kommunikasjon mellom Avamar-systemprosesser.
Avamar sikrer all kommunikasjon mellom Avamar-systemprosesser ved hjelp av øktforespørsler. En gyldig øktbillett kreves før en Avamar-prosess godtar en overføring fra en annen Avamar-prosess.
Øktbillettene har følgende generelle egenskaper:
Avamar-systemet installerer den offentlige nøkkelen for serversertifikatet på alle Avamar-klienter som er registrert på Avamar-serveren. Avamar-klienter bruker den offentlige nøkkelen til å godkjenne overføringer fra Avamar-systemet.
For klienter som er registrert, overføres fellesnøkkelen for serversertifikatet og andre nødvendige sertifikatfiler til klienten innen en time etter installasjonen.
Avamar-systemet deler også automatisk Avamar-serversertifikatet med Avamar-lagringsnodene. Deling av sertifikatet gjør det mulig for verktøynoden og lagringsnodene å gi samme sertifikat for godkjenning.
Et klientsertifikat genereres når Avamar-serveren registrerer en Avamar-klient.
Når et klientsertifikat er generert, bruker Avamar-systemet en kryptert tilkobling til Avamar-klienten til å installere sertifikatet på klienten. Avamar-systemet lagrer også fellesnøkkelen for klientsertifikatet. Den offentlige nøkkelen brukes til å autentisere klienten i all påfølgende kommunikasjon.
Hvordan fungerer øktsikkerhet?
Øktsikkerhet er aktivert på Avamar-serveren. Når dette alternativet er aktivert, går klienter, proxyer og Data Domain-systemer gjennom en spesiell sertifikatregistreringsprosess med Avamar.
På en Windows- eller Linux-klient og proxy ser den ved registrering at Avamar-serveren har øktsikkerhet aktivert. Avamar sender sin interne rotsertifiseringsinstans til klienten (chain.pem), slik at kunden kan lagre og klarere den. Klienten genererer en forespørsel om sertifikatsignering (CSR). CSR (avclient.csr) sendes fra klienten til Avamar-serverens MCS-prosess, som signerer CSR-en og gir tilbake et sertifikatnøkkelpar til klienten (key.pem &; cert.pem).
På et datadomene, når du kobler datadomenet til Avamar eller når SSL-kommunikasjonen oppdateres, ser Avamar at datadomenet ikke har et signert sertifikat fra seg selv eller et annet validert Avamar (imported-host ddboost). Avamar bruker Data Domain ssh private key til å logge på Data Domain for å kjøre ssh-kommandoer over Data Domin shell (ddsh). Avamar henter forespørselen om sertifikatsignering for Data Domain (CSR) over SCP og signerer CSR-en med Avamars interne rotsertifiseringsinstans. Når datadomenet har det signerte sertifikatet fra Avamar (imported-host ddboost), importerer Avamar rotsertifiseringsinstansen som signerte sertifikatet (chain.pem som imported-ca ddboost/login-auth).
Nå som en klient/proxy er registrert og har klientsidesertifikatene som kreves for å godkjennes med Avamars MCS, blir det forsøkt å ta en sikkerhetskopi. Avamar sender en arbeidsordre til klientens eller proxyens Avagent-lytter, som henter arbeidsordren. Klienten eller proxyen validerer og verifiserer deretter Avamar-serverens sertifikatkjede ved hjelp av Avamar-rotsertifiseringsinstansen som Avamar importerte til klienten ved registrering. På samme måte godkjenner Avamar klienten eller proxyen. Ingen data er sendt på dette tidspunktet.
Etter at godkjenningen er vellykket, starter arbeidsordren, og statusen til arbeidsordren endres fra 'Venter-klient' til 'Kjører'.
Nå kan klienter og proxyer til slutt flytte data til Avamar og Data Domain ved hjelp av avtar-binærfilen som er installert på dem. Avtar-binærfilen vil passere noen flagg som kontrollerer detaljene for hvordan dataene flyttes og hvilke data som flyttes.
Når avtar på en klient eller proxy går for å koble til Avamars GSAN, må den vite om verifypeer er aktivert. Verifypeer-innstillingen er en GSAN-serverinnstilling som en del av konfigurasjonen Session Security som kontrollerer GSANs SSL-sokkel på port 29000 ved å fortelle den om det skal kreves klientsertifikater for hver innkommende tilkobling. Heldigvis er TLS 1.2-protokollen implementert som automatisk håndterer hvordan en klient eller proxy skal presentere sine klientsertifikater til gsan under TLS-håndtrykket.
Følgende er en demonstrasjon av TLS gjensidig/toveis håndtrykk når verifypeer er aktivert.
Fra klient- eller proxy-synspunktet er en pil som peker mot høyre, en tilkobling til Avamar-serveren. En pil som peker mot venstre, er en tilkobling som kommer fra Avamar-serveren til klienten.
Den viktige delen er at klienten eller fullmektigen fikk de nødvendige sertifikatene på klientsiden for å kunne utføre et gjensidig TLS-håndtrykk hvis det kreves av GSAN.
Dette betyr at hvis Avamars interne rotsertifiseringsinstans endres, må klienten, proxyen eller datadomenet hente den nye rotsertifiseringsinstansen til å signere sertifikater for dem.
Når klienten eller proxyen er koblet til GSAN, forsøker den å koble til datadomenet.
Følgende logg viser en proxy som kobler til Data Domain med avtar. Verifypeer-innstillingen er deaktivert, men øktsikkerhet er aktivert (godkjent enkeltmodus).
Siden verifypeer er en Avamar GSAN-serverinnstilling, påvirker det ikke hvordan avtar kobler direkte til Data Domain hvis øktsikkerhet er aktivert. Dette betyr at det oppstår et gjensidig TLS-håndtrykk mellom klienten eller proxyen og datadomenet.
Klienten eller proxyen kan validere Data Domain-sertifikatkjeden fordi den deler samme interne Avamar-rotsertifiseringsinstans som ble importert av Avamar ved klientregistreringstidspunktet (eller DD-redigering eller vedleggstidspunktet).
Etter sertifikatvalidering fullføres håndtrykket, og sikkerhetskopierte data flyttes fra klienten til Data Domain og Avamar på nettverket.
Administrere sikkerhetsinnstillinger
for øktFølgende to artikler brukes til å administrere innstillingene for øktsikkerhet enten fra kommandolinjen eller Avinstaller-nettjenesten.
000222234 | Avamar: Administrer sikkerhetsinnstillinger for økt fra CLI
000222279 | Avamar: Administrer sikkerhetsinnstillinger for økt med AVP-installasjonsinstallasjonspakke (AVP)
Deaktivert
Innstillinger:
Når øktsikkerhet er deaktivert, kobler klienter bare til Avamars Avagent-tjeneste på port 28001, og klientene lytter på Avagent-port 28002 etter forespørsler fra Avamar.
En fullmektig lytter på 28009.
Port 28001 er en vanlig TCP-kontakt og utfører ikke TLS-håndtrykk.
Klienten kobler til Avamar GSAN på port 29000 og utfører et enveis TLS-håndtrykk. Dette betyr at selv når øktsikkerhet er deaktivert, krypteres de fortsatt under flyging når sikkerhetskopierte data overføres mellom klienten og Avamar.
Sertifikater for godkjenning med Avamar-programvare utveksles ikke mellom Avamar, proxyer, klienter og Data Domain.
Blandet singel
Innstillinger:
Blandet enkelt-modus ble brukt mer da øktsikkerhet først ble introdusert i Avamar 7.3, noe som spesifikt gjorde det mulig for klienter som ikke hadde versjonen 7.3 eller høyere, å registrere seg og sikkerhetskopiere til Avamar. I skrivende stund er Avamar 19.10 den nyeste versjonen, og Mixed-Single vil i hovedsak være den samme som neste modus å diskutere; Autentisert-singel.
Godkjent – enkel
Innstillinger:
I denne modusen er øktsikkerhet aktivert, og sertifikater sendes mellom Avamar, klienter, proxyer og datadomene for godkjenning før en sikkerhetskopiering.
Klienter lytter nå på port 30002 etter Avagent-forespørsler fra Avamar, og proxyene lytter på port 30009. Avamar lytter på port 30001 og 30003 etter tilkoblingsforespørsler fra klienter og proxyer. Dette er SSL-stikkontakter som utfører TLS-håndtrykk.
Authenticated-Single-modus tvinger alle klienter til å registrere seg ved hjelp av Session Security-metoder i motsetning til blandet enkeltmodus.
Denne modusen angir at verifypeer på Avamars GSAN er deaktivert, noe som betyr at GSAN ikke krever klientsertifikater fra en innkommende avtar-tilkobling.
Godkjent-dobbel
Innstillinger:
Authenticated-Dual er det samme som Authenticated-Single, bortsett fra at den aktiverer verifiseringsinnstillinger på Avamars GSAN-tjeneste.
Authenticated-Dual regnes som den sterkeste innstillingen som gjelder for en Avamar-server, og er standardvalget under Avamar-implementeringer.
Oversikt over: Avamar intern, selvsignert rotsertifiseringsinstans
Den interne rotsertifiseringsinstansen til Avamar er en internt klarert sertifiseringsinstans for Avamar og klientene, proxyene og datadomenene som Avamar importerer til dem.
Avamar er den interne sertifiseringsinstansen for seg selv fordi den utsteder sertifikater for forespørsler om sertifikatsignering (CSR).
Når Avamar bruker rotsertifiseringsinstansen til å signere sertifikater for GSAN, lagres de på følgende plassering:
Hvis en sikkerhetsskanner skanner port 29000 på Avamar, rapporterer den selvsignerte sertifikater på porten som behandler sikkerhetskopier til GSAN.
I noen miljøer er dette kanskje ikke akseptabelt, og det anbefales å se følgende KB-artikkel hvis du vil ha mer informasjon om hvordan du erstatter Avamars interne rotsertifiseringsinstans med en brukerangitt intern rotsertifiseringsinstans.
KB 000204629 | Avamar: Installere/erstatte Avamar Certificate Authority (CA) med brukerangitt sertifiseringsinstans (CA)
Prosessen inneholder informasjon om hvordan du bruker importcert.sh-skriptet til å installere en brukerangitt sertifiseringsinstans internt i firmaet. Den brukerleverte sertifiseringsinstansen administreres sannsynligvis av sikkerhetsteamet, da ingen offentlig sertifiseringsinstans vil gi bort den private nøkkelen for deres CA, da det er grunnen til at de tjener penger ved å signere sertifikater for andre og opprettholde en tillitskjede.
Et eksempel på en intern sertifiseringsinstans er Microsoft Active Directory-sertifikattjenester.
Hva er Active Directory-sertifikattjenester? | Microsoft Learn
Et eksempel på en offentlig sertifiseringsinstans er DigiCert.
Når du bytter ut Avamars interne rot-CA, byttes det ut rotnøkkelparet i Avamar-nøkkellageret med det brukerangitte CA-nøkkelparet. Deretter genererer GSAN en CSR og privat nøkkel, får CSR signert av det nye CA-nøkkelparet, og filene nevnt tidligere i denne delen erstattes. GSAN laster inn SSL-sokkelen på nytt på port 29000, og nye klienter som kobler seg til GSAN, kontakter den brukerleverte CA-en.
Sikkerhetsskannere vil nå vise signerte sertifikater på porten, og klienter, proxyer og Data Domain må registrere seg på nytt for å få den nye sertifiseringsinstansen.
Begrensninger
Sikkerhetsfunksjonene for Avamar-økten er underlagt noen begrensninger:
Planlegging av sikkerhetsendring for
øktFør du gjør en endring i innstillingene for øktsikkerhet, kan følgende trinn gjøres for å få muligheten til å gjenopprette tidligere konfigurasjon eller sertifikater før du gjør endringer.
Husk at hvis Avamars interne rotsertifiseringsinstans endres, må klienter, proxyer og Data Domain registrere seg på nytt. Avhengig av størrelsen på miljøet (antall klienter, proxyer og datadomener) kan dette være en tungvint oppgave som strekker seg over noen få dager.
Brukstilfellet vil være hvis sertifikater genereres på nytt, og nå er det registrerings- og sikkerhetskopieringsfeil.
Med antagelsen om at sertifikater ikke er utløpt eller i ferd med å gjøre det, og de regenereres kanskje ved et uhell, gir følgende trinn litt veiledning om hvordan du kan forhindre tap av data eller utilgjengelighetssituasjon.
Få de gjeldende sikkerhetsinnstillingene for økten og skriv dem ned:
Lag en kopi av Avamar-nøkkellageret:
Anta at sertifikater nå genereres på nytt, enten ved hjelp av metodene Session Security AVP eller CLI.
Dette betyr at Avamar-nøkkellageret er endret, og GSAN-sertifikatene signert på nytt.
Det opprinnelige Avamar-nøkkellageret kan enkelt flyttes tilbake på plass:
Generer GSAN-sertifikatene på nytt:
Øktsikkerhet: Veiledning
for produktsikkerhetAvamar-klienter kan bruke øktsikkerhet til å sikre all kommunikasjon mellom Avamar-serveren og Avamar-klientprogramvaren. Avamar-serveren gir godkjenning til Avamar-klienten, og Avamar-klienten gir godkjenning til Avamar-serveren.
Sikkerhetsfunksjoner for økter inkluderer sikkerhetsforbedringer for kommunikasjon mellom Avamar-systemprosesser.
Avamar sikrer all kommunikasjon mellom Avamar-systemprosesser ved hjelp av øktforespørsler. En gyldig øktbillett kreves før en Avamar-prosess godtar en overføring fra en annen Avamar-prosess.
Øktbillettene har følgende generelle egenskaper:
- Øktbilletten er kryptert og signert for å beskytte mot endring
- Øktbilletten er gyldig i kort tid
- Hver øktbillett inneholder en unik signatur og tilordnes bare én Avamar-prosess
- Integriteten til en øktbillett er beskyttet av kryptering
- Hver Avamar-systemnode verifiserer separat øktbillettsignaturen
- Når det er nødvendig, kan en økt forlenges utover øktbillettens levetid
Avamar-systemet installerer den offentlige nøkkelen for serversertifikatet på alle Avamar-klienter som er registrert på Avamar-serveren. Avamar-klienter bruker den offentlige nøkkelen til å godkjenne overføringer fra Avamar-systemet.
For klienter som er registrert, overføres fellesnøkkelen for serversertifikatet og andre nødvendige sertifikatfiler til klienten innen en time etter installasjonen.
Avamar-systemet deler også automatisk Avamar-serversertifikatet med Avamar-lagringsnodene. Deling av sertifikatet gjør det mulig for verktøynoden og lagringsnodene å gi samme sertifikat for godkjenning.
Et klientsertifikat genereres når Avamar-serveren registrerer en Avamar-klient.
Når et klientsertifikat er generert, bruker Avamar-systemet en kryptert tilkobling til Avamar-klienten til å installere sertifikatet på klienten. Avamar-systemet lagrer også fellesnøkkelen for klientsertifikatet. Den offentlige nøkkelen brukes til å autentisere klienten i all påfølgende kommunikasjon.
Hvordan fungerer øktsikkerhet?
Øktsikkerhet er aktivert på Avamar-serveren. Når dette alternativet er aktivert, går klienter, proxyer og Data Domain-systemer gjennom en spesiell sertifikatregistreringsprosess med Avamar.
På en Windows- eller Linux-klient og proxy ser den ved registrering at Avamar-serveren har øktsikkerhet aktivert. Avamar sender sin interne rotsertifiseringsinstans til klienten (chain.pem), slik at kunden kan lagre og klarere den. Klienten genererer en forespørsel om sertifikatsignering (CSR). CSR (avclient.csr) sendes fra klienten til Avamar-serverens MCS-prosess, som signerer CSR-en og gir tilbake et sertifikatnøkkelpar til klienten (key.pem &; cert.pem).
På et datadomene, når du kobler datadomenet til Avamar eller når SSL-kommunikasjonen oppdateres, ser Avamar at datadomenet ikke har et signert sertifikat fra seg selv eller et annet validert Avamar (imported-host ddboost). Avamar bruker Data Domain ssh private key til å logge på Data Domain for å kjøre ssh-kommandoer over Data Domin shell (ddsh). Avamar henter forespørselen om sertifikatsignering for Data Domain (CSR) over SCP og signerer CSR-en med Avamars interne rotsertifiseringsinstans. Når datadomenet har det signerte sertifikatet fra Avamar (imported-host ddboost), importerer Avamar rotsertifiseringsinstansen som signerte sertifikatet (chain.pem som imported-ca ddboost/login-auth).
Nå som en klient/proxy er registrert og har klientsidesertifikatene som kreves for å godkjennes med Avamars MCS, blir det forsøkt å ta en sikkerhetskopi. Avamar sender en arbeidsordre til klientens eller proxyens Avagent-lytter, som henter arbeidsordren. Klienten eller proxyen validerer og verifiserer deretter Avamar-serverens sertifikatkjede ved hjelp av Avamar-rotsertifiseringsinstansen som Avamar importerte til klienten ved registrering. På samme måte godkjenner Avamar klienten eller proxyen. Ingen data er sendt på dette tidspunktet.
Etter at godkjenningen er vellykket, starter arbeidsordren, og statusen til arbeidsordren endres fra 'Venter-klient' til 'Kjører'.
Nå kan klienter og proxyer til slutt flytte data til Avamar og Data Domain ved hjelp av avtar-binærfilen som er installert på dem. Avtar-binærfilen vil passere noen flagg som kontrollerer detaljene for hvordan dataene flyttes og hvilke data som flyttes.
Når avtar på en klient eller proxy går for å koble til Avamars GSAN, må den vite om verifypeer er aktivert. Verifypeer-innstillingen er en GSAN-serverinnstilling som en del av konfigurasjonen Session Security som kontrollerer GSANs SSL-sokkel på port 29000 ved å fortelle den om det skal kreves klientsertifikater for hver innkommende tilkobling. Heldigvis er TLS 1.2-protokollen implementert som automatisk håndterer hvordan en klient eller proxy skal presentere sine klientsertifikater til gsan under TLS-håndtrykket.
Følgende er en demonstrasjon av TLS gjensidig/toveis håndtrykk når verifypeer er aktivert.
Fra klient- eller proxy-synspunktet er en pil som peker mot høyre, en tilkobling til Avamar-serveren. En pil som peker mot venstre, er en tilkobling som kommer fra Avamar-serveren til klienten.
[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
Når verifypeer er deaktivert, trenger ikke klienten å sende et klientsertifikat til GSAN.
[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
Den viktige delen er at klienten eller fullmektigen fikk de nødvendige sertifikatene på klientsiden for å kunne utføre et gjensidig TLS-håndtrykk hvis det kreves av GSAN.
Dette betyr at hvis Avamars interne rotsertifiseringsinstans endres, må klienten, proxyen eller datadomenet hente den nye rotsertifiseringsinstansen til å signere sertifikater for dem.
Når klienten eller proxyen er koblet til GSAN, forsøker den å koble til datadomenet.
Følgende logg viser en proxy som kobler til Data Domain med avtar. Verifypeer-innstillingen er deaktivert, men øktsikkerhet er aktivert (godkjent enkeltmodus).
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
Siden verifypeer er en Avamar GSAN-serverinnstilling, påvirker det ikke hvordan avtar kobler direkte til Data Domain hvis øktsikkerhet er aktivert. Dette betyr at det oppstår et gjensidig TLS-håndtrykk mellom klienten eller proxyen og datadomenet.
Klienten eller proxyen kan validere Data Domain-sertifikatkjeden fordi den deler samme interne Avamar-rotsertifiseringsinstans som ble importert av Avamar ved klientregistreringstidspunktet (eller DD-redigering eller vedleggstidspunktet).
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
Etter sertifikatvalidering fullføres håndtrykket, og sikkerhetskopierte data flyttes fra klienten til Data Domain og Avamar på nettverket.
Administrere sikkerhetsinnstillinger
for øktFølgende to artikler brukes til å administrere innstillingene for øktsikkerhet enten fra kommandolinjen eller Avinstaller-nettjenesten.
000222234 | Avamar: Administrer sikkerhetsinnstillinger for økt fra CLI
000222279 | Avamar: Administrer sikkerhetsinnstillinger for økt med AVP-installasjonsinstallasjonspakke (AVP)
Det finnes fire mulige støttede konfigurasjoner:
- Deaktivert
- Blandet singel
- Godkjent – enkel
- Godkjent-dobbel
Deaktivert
Innstillinger:
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"
Når øktsikkerhet er deaktivert, kobler klienter bare til Avamars Avagent-tjeneste på port 28001, og klientene lytter på Avagent-port 28002 etter forespørsler fra Avamar.
En fullmektig lytter på 28009.
Port 28001 er en vanlig TCP-kontakt og utfører ikke TLS-håndtrykk.
Klienten kobler til Avamar GSAN på port 29000 og utfører et enveis TLS-håndtrykk. Dette betyr at selv når øktsikkerhet er deaktivert, krypteres de fortsatt under flyging når sikkerhetskopierte data overføres mellom klienten og Avamar.
Sertifikater for godkjenning med Avamar-programvare utveksles ikke mellom Avamar, proxyer, klienter og Data Domain.
Blandet singel
Innstillinger:
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"
Blandet enkelt-modus ble brukt mer da øktsikkerhet først ble introdusert i Avamar 7.3, noe som spesifikt gjorde det mulig for klienter som ikke hadde versjonen 7.3 eller høyere, å registrere seg og sikkerhetskopiere til Avamar. I skrivende stund er Avamar 19.10 den nyeste versjonen, og Mixed-Single vil i hovedsak være den samme som neste modus å diskutere; Autentisert-singel.
Godkjent – enkel
Innstillinger:
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"
I denne modusen er øktsikkerhet aktivert, og sertifikater sendes mellom Avamar, klienter, proxyer og datadomene for godkjenning før en sikkerhetskopiering.
Klienter lytter nå på port 30002 etter Avagent-forespørsler fra Avamar, og proxyene lytter på port 30009. Avamar lytter på port 30001 og 30003 etter tilkoblingsforespørsler fra klienter og proxyer. Dette er SSL-stikkontakter som utfører TLS-håndtrykk.
Authenticated-Single-modus tvinger alle klienter til å registrere seg ved hjelp av Session Security-metoder i motsetning til blandet enkeltmodus.
Denne modusen angir at verifypeer på Avamars GSAN er deaktivert, noe som betyr at GSAN ikke krever klientsertifikater fra en innkommende avtar-tilkobling.
Godkjent-dobbel
Innstillinger:
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"
Authenticated-Dual er det samme som Authenticated-Single, bortsett fra at den aktiverer verifiseringsinnstillinger på Avamars GSAN-tjeneste.
Authenticated-Dual regnes som den sterkeste innstillingen som gjelder for en Avamar-server, og er standardvalget under Avamar-implementeringer.
Oversikt over: Avamar intern, selvsignert rotsertifiseringsinstans
Den interne rotsertifiseringsinstansen til Avamar er en internt klarert sertifiseringsinstans for Avamar og klientene, proxyene og datadomenene som Avamar importerer til dem.
Avamar er den interne sertifiseringsinstansen for seg selv fordi den utsteder sertifikater for forespørsler om sertifikatsignering (CSR).
Når Avamar bruker rotsertifiseringsinstansen til å signere sertifikater for GSAN, lagres de på følgende plassering:
/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
Hvis en sikkerhetsskanner skanner port 29000 på Avamar, rapporterer den selvsignerte sertifikater på porten som behandler sikkerhetskopier til GSAN.
I noen miljøer er dette kanskje ikke akseptabelt, og det anbefales å se følgende KB-artikkel hvis du vil ha mer informasjon om hvordan du erstatter Avamars interne rotsertifiseringsinstans med en brukerangitt intern rotsertifiseringsinstans.
KB 000204629 | Avamar: Installere/erstatte Avamar Certificate Authority (CA) med brukerangitt sertifiseringsinstans (CA)
Prosessen inneholder informasjon om hvordan du bruker importcert.sh-skriptet til å installere en brukerangitt sertifiseringsinstans internt i firmaet. Den brukerleverte sertifiseringsinstansen administreres sannsynligvis av sikkerhetsteamet, da ingen offentlig sertifiseringsinstans vil gi bort den private nøkkelen for deres CA, da det er grunnen til at de tjener penger ved å signere sertifikater for andre og opprettholde en tillitskjede.
Et eksempel på en intern sertifiseringsinstans er Microsoft Active Directory-sertifikattjenester.
Hva er Active Directory-sertifikattjenester? | Microsoft Learn
Et eksempel på en offentlig sertifiseringsinstans er DigiCert.
Når du bytter ut Avamars interne rot-CA, byttes det ut rotnøkkelparet i Avamar-nøkkellageret med det brukerangitte CA-nøkkelparet. Deretter genererer GSAN en CSR og privat nøkkel, får CSR signert av det nye CA-nøkkelparet, og filene nevnt tidligere i denne delen erstattes. GSAN laster inn SSL-sokkelen på nytt på port 29000, og nye klienter som kobler seg til GSAN, kontakter den brukerleverte CA-en.
Sikkerhetsskannere vil nå vise signerte sertifikater på porten, og klienter, proxyer og Data Domain må registrere seg på nytt for å få den nye sertifiseringsinstansen.
Begrensninger
Sikkerhetsfunksjonene for Avamar-økten er underlagt noen begrensninger:
- Klienter
- Sikkerhetsfunksjoner for økt kan ikke brukes med noen av følgende Avamar-klienter:
- Avamar-klyngeklient for Solaris på Veritas-klyngeserver
- Avamar-klient for Solaris i Solaris-klynger
- Sikkerhetsfunksjoner for økt kan ikke brukes med noen av følgende Avamar-klienter:
- Andre produkter
- Det oppfordres til bruk av NTP-tidssynkronisering av Avamar-serveren, Avamar-klienter og Data Domain-systemet (hvis aktuelt). Hvis klokkeslettet ikke synkroniseres, kan det føre til at registreringen og sikkerhetskopieringen/gjenopprettingen mislykkes på grunn av sertifikatgyldighet og utløpstider. Endring av tidssonen på en vert kan ha en lignende innvirkning og kan kreve sertifikatregenerering.
- Sikkert token
- Godkjenning av sikre tokener fungerer ikke under følgende betingelser:
- Klientmaskinen er bak en NAT-brannmurenhet (Network Address Translation)
- Klientens vertsnavn er et virtuelt navn som er forskjellig fra FQDN løst fra IP-adressen
- Klientmaskinen har flere IP-grensesnitt, og hver av dem løses til et annet fullstendig kvalifisert domenenavn (FQDN). Se følgende KB hvis du vil ha mer informasjon: KB 000056252 | Avamar: Sikkerhetskopiering til datadomenet mislyktes med meldingen "DDR_GET_AUTH_TOKEN" på grunn av for mange IP-adresser
- Godkjenning av sikre tokener fungerer ikke under følgende betingelser:
Planlegging av sikkerhetsendring for
øktFør du gjør en endring i innstillingene for øktsikkerhet, kan følgende trinn gjøres for å få muligheten til å gjenopprette tidligere konfigurasjon eller sertifikater før du gjør endringer.
Husk at hvis Avamars interne rotsertifiseringsinstans endres, må klienter, proxyer og Data Domain registrere seg på nytt. Avhengig av størrelsen på miljøet (antall klienter, proxyer og datadomener) kan dette være en tungvint oppgave som strekker seg over noen få dager.
Brukstilfellet vil være hvis sertifikater genereres på nytt, og nå er det registrerings- og sikkerhetskopieringsfeil.
Med antagelsen om at sertifikater ikke er utløpt eller i ferd med å gjøre det, og de regenereres kanskje ved et uhell, gir følgende trinn litt veiledning om hvordan du kan forhindre tap av data eller utilgjengelighetssituasjon.
Få de gjeldende sikkerhetsinnstillingene for økten og skriv dem ned:
enable_secure_config.sh --showconfig
Lag en kopi av Avamar-nøkkellageret:
cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original
Anta at sertifikater nå genereres på nytt, enten ved hjelp av metodene Session Security AVP eller CLI.
Dette betyr at Avamar-nøkkellageret er endret, og GSAN-sertifikatene signert på nytt.
Det opprinnelige Avamar-nøkkellageret kan enkelt flyttes tilbake på plass:
cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore
Generer GSAN-sertifikatene på nytt:
enable_secure_config.sh --certs
Start MCS og Backup Scheduler på nytt:
mcserver.sh --restart --force dpnctl start sched
Dette gjenoppretter den opprinnelige interne Avamar-rotsertifiseringsinstansen som klienter, proxyer og Data Domain allerede stolte på.
Feilsøking
Mesteparten av tiden er det enkelt å endre innstillingene for øktsikkerhet eller regenerere sertifikater.
Denne delen tar sikte på å ta for seg hvordan du får alt til å fungere igjen etter at sertifikater er generert på nytt eller innstillingene er endret.
Lokale spylinger
I scenariet der verifypeer er aktivert, når alle Avamar-sertifikater genereres på nytt, oppdateres ikke klientsertifikatene som Avamar-serverens avtar og avmgr bruker, umiddelbart.
Dette betyr at når MCS kjører en planlagt flush (sikkerhetskopiering av MCS-konfigurasjonen til GSAN), vil den mislykkes på grunn av en TLS-håndtrykkfeil. Dette skyldes at klientsertifikatene for avtar som kjører på Avamar-serveren, ikke har fått den oppdaterte interne rotsertifiseringsinstansen for Avamar ennå og det nye settet med signerte klientsertifikater.
Se følgende KB hvis du vil ha mer informasjon:
000214340 | Avamar: Avtar kan ikke koble til Avamars GSAN-tjeneste, "Kritisk servertilkoblingsproblem, avbryter initialisering. Bekreft riktig serveradresse og påloggingsinformasjon."
Replikering
I scenariet der verifypeer er aktivert på replikeringsmålet, og sertifikater genereres på nytt på målet, må en lignende tilnærming fra delen "Local Flushes" ovenfor utføres.
Først må du kontrollere at replikeringsmålet Avagent er registrert, slik at den kan godta arbeidsordrer for replikering.
Kontroller Avagent-loggen på følgende sted på destinasjonen:
/usr/local/avamar/var/client/avagent.log
En sunn logg kan se slik ut:
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
Når du går lenger tilbake i loggen, kan det være en nylig vellykket omregistrering:
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
En usunn logg med registreringsproblemer forårsaket av sertifikatendringer kan se slik ut:
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.
I dette tilfellet må følgende trinn utføres
for å kunne registrere Avagent på nytt umiddelbart med MCS: Hent det MC_SYSTEM kontonavnet, som sannsynligvis vil være Avamar FQDN:
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
Deaktiver MC_SYSTEM kontoen:
mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false example: mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false
Registrer MC_SYSTEM kontoen på nytt:
/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM example: /etc/init.d/avagent register avamar.lab /MC_SYSTEM
Når registreringen er fullført, kan Avagent godta replikering på målet.
Hvis verifypeer er aktivert på replikeringsmålet Avamar, må vi nå generere klientsertifikatene som ble brukt til å koble til målområdet Avamar, på nytt.
Ligner på KB 000214340 | Avamar: Avtar kan ikke koble til Avamars GSAN-tjeneste, "Kritisk servertilkoblingsproblem, avbryter initialisering. Bekreft riktig serveradresse og påloggingsinformasjon."
Fjern den eksisterende mappen for Avamar-sertifikater fra kildeøkten for Avamar ssh:
rm -r /usr/local/avamar/etc/<destination_avamar_ip_address> rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>
Generer klientsertifikatene på nytt:
/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
Kommunikasjonen til destinasjonen Avamar kan testes fra Source Avamar ssh-kommandolinjen:
avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192
Klientregistrering
Sikkerhetskopieringer kan forsøkes etter at du har endret sikkerhetsinnstillingene for økten eller generert sertifikatene på nytt.
Dette kan føre til at mange agentbaserte klienter får statusen «Ventende klient» til de ikke sikkerhetskopierer med «Tidsbestemt start».
Etter at de nye sertifikatene er generert på nytt, bør det ta omtrent 23 timer for klienten å automatisk forsøke å registrere seg på nytt.
Følgende kommando kan brukes på Avamar-serveren til å sende en invitasjon til agentbaserte klienter om å registrere seg på nytt med Avamar MCS.
mccli client re-register-all
Kommandoen kan ta litt tid, avhengig av antall klienter, siden den sender en invitasjon til hver enkelt i sekvensiell rekkefølge. Vurder å kjøre kommandoen i bakgrunnen i tilfelle SSH-økten blir tidsavbrutt.
nohup mccli client re-register-all &
Merk at dette kanskje ikke fungerer for å registrere alle agentbaserte klienter på nytt, og noen må kanskje registreres på nytt manuelt.
Den manuelle prosessen for å registrere en klient på nytt på Windows vil være å:
- Fjern innholdet i følgende katalog som inneholder de gamle klientsertifikatene:
-
"C:\Program Files\avs\etc"
-
- Start "Backup Agent"-tjenesten på nytt
- Fjern innholdet i følgende katalog som inneholder de gamle klientsertifikatene:
-
/usr/local/avamar/etc
-
- Start Avagent-tjenesten på nytt:
-
service avagent restart
-
Omstart av klientmaskinen kan også gjøres for å prøve å utløse en fullstendig omregistrering.
Vær oppmerksom på at navneløsing spiller en viktig rolle ved registrering av klienter når Session Security er aktivert, må du sørge for at klientene kan utføre et videresendt og omvendt DNS-oppslag på Avamar-serveren og omvendt. Dette kan oppnås enten ved å konfigurere DNS A-poster eller vert oppføringer på klienten.
Avamar tilbyr ikke noen form for skript som kan nå ut til alle tilknyttede klienter for å utføre en manuell omregistrering. Den tidligere nevnte mccli-kommandoen er nærmest det.
Fullmaktsregistrering
Virtuelle maskiner som sikkerhetskopieres til Avamar ved hjelp av proxyer, har en fordel når det gjelder sikkerhetsendringer etter økter, siden det vanligvis er mange mindre proxyer enn agentbaserte klienter.
Proxyer bør også prøve en automatisk omregistrering innen 23 timer, men det kan være enklere og raskere å registrere dem umiddelbart.
Det er noen få alternativer tilgjengelig for å prøve en tvinge en omregistrering på fullmaktene.
Det første alternativet kan være å starte fullmaktene på nytt med følgende kommando:
mccli mcs reboot-proxy --all
Det andre alternativet ville være å bruke Goav-verktøyet til å administrere fullmaktene.
Angi proxy-passordet for Goav-verktøyet slik at det kan logge på fullmaktene når det må. Følgende kommando endrer ikke OS passordet til proxy, det bare lagrer passordet kryptert slik at Goav verktøyet kan bruke den til å logge på proxy når det må over ssh.
./goav proxy set-password
Utfør en omstart av Avagent på alle tilkoblede proxyer:
./goav proxy exec "service avagent restart"
Hvis du vil kontrollere Avagent-påloggingen i proxyen for å se om en vellykket omregistrering har skjedd, kjører du følgende kommando:
./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"
Vellykket utdata kan se slik ut:
============== 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.
Det tredje alternativet er å ssh til proxy og kjøre initialiseringsskriptet:
/usr/local/avamarclient/etc/initproxyappliance.sh start
Data Domain-synkronisering
Når sikkerhetsinnstillingene for økten er endret eller sertifikatene generert på nytt på Avamar, må datadomenet synkroniseres på nytt, eller SSL-tilkoblingen opprettes på nytt.
Følgende KB-artikkel dekker dette scenariet, og hvordan du utveksler de nye sertifikatene med Data Domain.
000197106 | Avamar- og Data Domain-integrering: DD viser rødt i Avamar AUI og/eller brukergrensesnitt Oppløsningsbane
Det anbefales på det sterkeste at du håndterer Avamar og Data Domain SSL-feilsøking med Goav-verktøyet.
Med Goav kan Data Domain SSL-tilkoblingen med Avamar diagnostiseres og løses automatisk. Se følgende kunnskapsbase:
000215679 | Avamar: Informasjon om Goav dd check-ssl-funksjon
Kjør følgende kommando for å reparere Avamar- og Data Domain-sertifikater automatisk:
./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.