CISCO HyperFlex HX-dataplattforminstruksjoner

Innhold gjemme

1 CISCO HyperFlex HX Dataplattform

2 Produktinformasjon

3 Produktbruksinstruksjoner

4 Vanlige spørsmål om HX-sikkerhetskryptering

5 Støttedokumenter

6 Dokumenter / Ressurser

6.1 Referanser

7 Relaterte innlegg

CISCO HyperFlex HX Dataplattform

Produktinformasjon

Produktnavn: HX sikkerhetskryptering
Versjon: HXDP 5.01b
Krypteringsløsning: Programvarebasert løsning med Intersight Key Manager
Krypteringstype: Selvkrypterende stasjoner (SED-er)
Støttede stasjonstyper: HDD og SSD SED-er fra Micron
Samsvarsstandarder: FIPS 140-2 nivå 2 (stasjonsprodusenter) og FIPS 140-2 nivå 1 (plattform)

Klyngeomfattende kryptering: Kryptering på HX er implementert i maskinvare for data i hvile kun ved bruk av SED-er
Individuell VM-kryptering: Håndteres av tredjepartsprogramvare som Hytrust eller Vormetric sin transparente klient

VMware Native VM-kryptering: Støttes av HX for bruk med SED-kryptering
Nøkkeladministrasjon: Media Encryption Key (MEK) og Key Encryption Key (KEK) brukes for hver SED

Minnebruk: Krypteringsnøkler er aldri til stede i nodeminnet
Ytelsespåvirkning: Diskkryptering/dekryptering håndteres i harddiskens maskinvare, den generelle systemytelsen påvirkes ikke

Ytterligere fordeler med SED-er:
- Øyeblikkelig kryptografisk sletting for reduserte pensjonerings- og omdistribueringskostnader
- Overholdelse av myndighets- eller industriforskrifter for personvern
- Redusert risiko for disktyveri og nodetyveri ettersom data blir uleselige når maskinvaren er fjernet

Produktbruksinstruksjoner

Følg disse instruksjonene for å bruke HX Security Encryption:

Sørg for at systemet ditt støtter maskinvarebasert kryptering eller at du foretrekker den programvarebaserte løsningen med Intersight Key Manager.

Se administrasjonsdokumentene eller hvitboken(e) for informasjon om programvarebasert kryptering.
Hvis du velger å bruke maskinvarebasert kryptering med SED-er, sørg for at HX-klyngen består av enhetlige noder (SED-er eller ikke-SED-er).

For SED-er, forstå at det er to nøkler i bruk: Media Encryption Key (MEK) og Key Encryption Key (KEK).
MEK kontrollerer kryptering og dekryptering av data til disken og er sikret og administrert i maskinvare.

KEK sikrer MEK/DEK og opprettholdes enten i et lokalt eller eksternt nøkkellager.
Ikke bekymre deg for at nøklene finnes i nodeminnet, siden krypteringsnøkler aldri lagres der.

Merk at diskkryptering/dekryptering håndteres i stasjonsmaskinvaren, og sikrer at den generelle systemytelsen ikke påvirkes.
Hvis du har spesifikke krav til samsvarsstandarder, vær oppmerksom på at HX SED-krypterte stasjoner oppfyller FIPS 140-2 nivå 2-standarder fra stasjonsprodusentene, mens HX Encryption på plattformen oppfyller FIPS 140-2 nivå 1-standarder.

Hvis du trenger å kryptere individuelle VM-er, bør du vurdere å bruke tredjepartsprogramvare som Hytrust eller Vormetrics transparente klient. Alternativt kan du bruke VMwares native VM-kryptering introdusert i vSphere 3.
Husk at bruk av en VM-krypteringsklient på toppen av HX SED-basert kryptering vil resultere i dobbel kryptering av dataene.

Sørg for at HX-klyngen din er tilkoblet gjennom pålitelige nettverk eller krypterte tunneler for sikker replikering, siden HX-replikering ikke er kryptert.

Vanlige spørsmål om HX-sikkerhetskryptering

Fra og med HXDP 5.01b tilbyr HyperFlex en programvarebasert løsning som bruker Intersight Key Manager for systemer som enten ikke støtter maskinvarebasert kryptering eller for brukere som ønsker denne funksjonaliteten fremfor maskinvareløsninger. Denne FAQ-en fokuserer kun på SED-baserte maskinvareløsninger for HX-kryptering. Se administrasjonsdokumentene eller hvitboken(e) for informasjon om programvarebasert kryptering.

Bias Statement
Dokumentasjonssettet for dette produktet streber etter å bruke skrånende språk. For formålet med dette dokumentasjonssettet er bias-free definert som språk som ikke innebærer diskriminering basert på alder, funksjonshemming, kjønn, raseidentitet, etnisk identitet, seksuell legning, sosioøkonomisk status og interseksjonalitet. Unntak kan være til stede i dokumentasjonen på grunn av språk som er hardkodet i brukergrensesnittene til produktprogramvaren, språk som brukes basert på standarddokumentasjon, eller språk som brukes av et referert tredjepartsprodukt.

Hvorfor Cisco for sikkerhet og HX-kryptering

Spørsmål 1.1: Hvilke prosesser er på plass for sikker utvikling?
A 1.1: Cisco-servere overholder Cisco Secure Development Lifecycle (CSDL):
- Cisco leverer prosesser, metoder, rammeverk for å utvikle innebygd sikkerhet på Cisco-servere, ikke bare et overlegg
- Dedikert Cisco-team for trusselmodellering/statisk analyse på UCS produktportefølje
- Cisco Advanced Security Initiative Group (ASIG) utfører proaktiv penetrasjonstesting for å forstå hvordan trusler kommer inn og fikse problemer ved å forbedre HW og SW gjennom CDETS og engineering
- Dedikert Cisco-team til å teste og håndtere utgående sårbarhet og kommunisere som sikkerhetsrådgivere til kunder
- Alle underliggende produkter går gjennom basiskrav for produktsikkerhet (PSB) som styrer sikkerhetsstandarder for Cisco-produkter
- Cisco utfører sårbarhets-/protokoll robusthetstesting på alle UCS-utgivelser
Spørsmål 1.2: Hvorfor er SED-er viktige?
A 1.2: SED-er brukes for data-at-rest-kryptering og er et krav for mange, om ikke alle, føderale, medisinske og finansinstitusjoner.

Generell informasjon overview

Spørsmål 2.1: Hva er SED-er?
A 2.1: SED (Self-Encrypting Drives) har spesiell maskinvare som krypterer innkommende data og dekrypterer utgående data i sanntid.
Spørsmål 2.2: Hva er omfanget av kryptering på HX?
A 2.2: Kryptering på HX er for øyeblikket implementert i maskinvare for data i hvile kun ved bruk av krypterte stasjoner (SED-er). HX-kryptering er klyngeomfattende. Individuell VM-kryptering håndteres av tredjepartsprogramvare som Hytrust eller Vormetrics transparente klient og er utenfor HX-ansvaret. HX støtter også bruken av VMwares native VM-kryptering introdusert i vSphere 3. Bruk av en VM-krypteringsklient på toppen av HX SED-basert kryptering vil resultere i dobbel kryptering av dataene. HX-replikering er ikke kryptert og er avhengig av pålitelige nettverk eller krypterte tunneler distribuert av sluttbrukeren.
Spørsmål 2.3: Hvilke samsvarsstandarder oppfylles med HX-kryptering?
A 2.3: HX SED-krypterte stasjoner oppfyller FIPS 140-2 nivå 2-standarder fra stasjonsprodusentene. HX-kryptering på plattformen oppfyller FIPS 140-2 nivå 1-standarder.
Spørsmål 2.4: Støtter vi både HDD og SSD for kryptering?
A 2.4: Ja, vi støtter både HDD og SSD SED-er fra Micron.
Spørsmål 2.5: Kan en HX-klynge ha krypterte og ikke-krypterte stasjoner samtidig?
A 2.5: Alle noder i klyngen må være ensartede (SED-er eller ikke-SED-er)
Spørsmål 2.6: Hvilke nøkler er i bruk for en SED og hvordan brukes de?
A 2.6: Det er to nøkler i bruk for hver SED. Media Encryption Key (MEK) også kalt Disk Encryption Key (DEK), kontrollerer kryptering og dekryptering av dataene til disken og er sikret og administrert i maskinvare. Nøkkelkrypteringsnøkkelen (KEK) sikrer DEK/MEK og opprettholdes enten i et lokalt eller eksternt nøkkellager.
Spørsmål 2.7: Er nøklene noen gang til stede i minnet?
A 2.7: Krypteringsnøkler er aldri til stede i nodeminnet
Spørsmål 2.8: Hvordan påvirkes ytelsen av krypterings-/dekrypteringsprosessen?
A 2.8: Diskkryptering/dekryptering håndteres i harddiskens maskinvare. Samlet systemytelse påvirkes ikke og er ikke utsatt for angrep rettet mot andre komponenter i systemet
Q 2.9: Annet enn kryptering i hvile, hva er andre grunner til å bruke SED-er?
A 2.9: SED-er kan redusere pensjonerings- og omdistribueringskostnader gjennom øyeblikkelig kryptografisk sletting. De tjener også til å overholde myndighets- eller industriforskrifter for personvern. En annen advantage er den reduserte risikoen for disktyveri og nodetyveri siden dataene, når maskinvaren er fjernet fra økosystemet, er uleselige.
Q2.10: Hva skjer med deduplisering og komprimering med SED-er? Hva skjer med tredjeparts programvarebasert kryptering?
A2.10: Deduplisering og komprimering med SED-er på HX opprettholdes siden data i hvile-kryptering finner sted som et siste trinn i skriveprosessen. Deduplisering og komprimering har allerede funnet sted. Med tredjeparts programvarebaserte krypteringsprodukter administrerer VM-ene kryptering og sender krypterte skrivinger til hypervisoren og deretter HX. Siden disse skriftene allerede er kryptert, blir de ikke deduplisert eller komprimert. HX Software Based Encryption (i 3.x-kodelinjen) vil være en programvarekrypteringsløsning som implementeres i stabelen etter at skriveoptimaliseringer (deduplisering og komprimering) har skjedd, så fordelen beholdes i så fall.

Figuren nedenfor er en overview av implementeringen av SED med HX.

Diskdetaljer

Spørsmål 3.1: Hvem produserer de krypterte stasjonene som brukes i HX?
A 3.1: HX bruker stasjoner produsert av Micron: Micron-spesifikke dokumenter er koblet til under støttedokumenter i denne vanlige spørsmål.
Spørsmål 3.2: Støtter vi noen SED-er som ikke er FIPS-kompatible?
A 3.2: Vi støtter også noen stasjoner som ikke er FIPS, men som støtter SED (TCGE).
Spørsmål 3.3: Hva er TCG?
A 3.3: TCG er Trusted Computing Group, som lager og administrerer spesifikasjonsstandarden for kryptert datalagring
Spørsmål 3.4: Hva regnes som sikkerhet i bedriftsklassen når det gjelder SAS SSD-er for datasenteret? Hvilke spesifikke funksjoner har disse stasjonene som sikrer sikkerhet og beskytter mot angrep?
A 3.4: Denne listen oppsummerer funksjonene i bedriftsklassen til SED-ene som brukes i HX og hvordan de forholder seg til TCG-standarden.
1. Selvkrypterende stasjoner (SED-er) gir sterk sikkerhet for data som hviler på SED-en din, og forhindrer uautorisert datatilgang. Trusted Computing Group (TCG) har utviklet en liste over funksjonene og fordelene med selvkrypterende stasjoner for både HDD-er og SSD-er. TCG gir en standard som kalles TCG Enterprise SSC (Security Subsystem Class) og er fokusert på data i hvile. Dette er et krav for alle SED-er. Spesifikasjonen gjelder for datalagringsenheter og kontrollere som opererer i bedriftslagring. Listen inkluderer:
  - Åpenhet: Ingen system- eller applikasjonsendringer kreves; krypteringsnøkkel generert av selve stasjonen, ved hjelp av en innebygd generator for sanne tilfeldige tall; stasjonen krypterer alltid.
  - Enkel administrasjon: Ingen krypteringsnøkkel å administrere; programvareleverandører utnytter standardisert grensesnitt for å administrere SED-er, inkludert fjernadministrasjon, autentisering før oppstart og passordgjenoppretting
  - Avhendings- eller gjenbrukskostnader: Slett innebygd krypteringsnøkkel med en SED
  - Ny kryptering: Med SED er det ikke nødvendig å kryptere dataene på nytt
  - Ytelse: Ingen forringelse i SED-ytelse; maskinvarebasert
  - Standardisering: Hele drivindustrien bygger etter TCG/SED-spesifikasjonene
  - Forenklet: Ingen interferens med oppstrømsprosesser
2. SSD SED-er gir er muligheten til å kryptografisk slette stasjonen. Dette betyr at en enkel autentisert kommando kan sendes til stasjonen for å endre 256-bits krypteringsnøkkelen som er lagret på stasjonen. Dette sikrer at stasjonen tørkes ren og at det ikke er data igjen. Selv det originale vertssystemet kan ikke lese dataene, så det vil absolutt være uleselig av noe annet system. Operasjonen tar bare et par sekunder, i motsetning til de mange minuttene eller til og med timene det tar å utføre en analog operasjon på en ukryptert HDD og unngår kostnadene for dyrt HDD-degaussingsutstyr eller -tjenester.
3. FIPS (Federal Information Processing Standard) 140-2 er en amerikansk regjeringsstandard som beskriver krypterings- og relaterte sikkerhetskrav som IT-produkter skal oppfylle for sensitiv, men uklassifisert bruk. Dette er ofte et krav også for offentlige etater og selskaper innen finans- og helsenæringen. En SSD som er FIPS-140-2-validert bruker sterk sikkerhetspraksis inkludert godkjente krypteringsalgoritmer. Den spesifiserer også hvordan enkeltpersoner eller andre prosesser må autoriseres for å kunne bruke produktet, og hvordan moduler eller komponenter må utformes for å samhandle sikkert med andre systemer. Faktisk er et av kravene til en FIPS-140-2-validert SSD-stasjon at det er en SED. Husk at selv om TCG ikke er den eneste måten å få en sertifisert kryptert stasjon på, gir TCG Opal- og Enterprise SSC-spesifikasjonene oss et springbrett til FIPS-validering. 4. En annen viktig funksjon er sikker nedlasting og diagnostikk. Denne fastvarefunksjonen beskytter stasjonen mot programvareangrep gjennom en digital signatur som er innebygd i fastvaren. Når nedlastinger er nødvendig, forhindrer den digitale signaturen uautorisert tilgang til stasjonen, og forhindrer at forfalsket fastvare lastes inn på stasjonen.

Hyperflex-installasjon med SED-er

Spørsmål 4.1: Hvordan håndterer installatøren en SED-distribusjon? Er det noen spesielle kontroller?
A 4.1: Installasjonsprogrammet kommuniserer med UCSM og sikrer at systemfastvaren er korrekt og støttet for den oppdagede maskinvaren. Krypteringskompatibilitet kontrolleres og håndheves (f.eks. ingen blanding av SED og ikke-SED).
Spørsmål 4.2: Er distribusjonen annerledes ellers?
A 4.2: Installasjonen ligner på en vanlig HX-installasjon, men tilpasset arbeidsflyt støttes ikke for SED-er. Denne operasjonen krever også UCSM-legitimasjon for SED-ene.
Spørsmål 4.3: Hvordan fungerer lisensiering med kryptering? Er det noe ekstra som må på plass?
A 4.3: SED-maskinvare (bestilt fra fabrikk, ikke ettermontert) + HXDP 2.5 + UCSM (3.1(3x)) er de eneste tingene som trengs for å aktivere kryptering med nøkkeladministrasjon. Det er ingen ekstra lisensiering utenom det grunnleggende HXDP-abonnementet som kreves i 2.5-utgivelsen.

Spørsmål 4.4: Hva skjer når jeg har et SED-system som har stasjoner som ikke lenger er tilgjengelige? Hvordan kan jeg utvide denne klyngen?
A 4.4: Når vi har en PID som er utgått fra våre leverandører, har vi en erstatnings-PID som er kompatibel med den gamle PID. Denne erstatnings-PIDen kan brukes til RMA, utvidelse innenfor en node og utvidelse av klynge (med nye noder). Alle metoder støttes, men de kan kreve oppgradering til en spesifikk utgivelse som også er identifisert i overgangsutgivelsesnotatene.

Nøkkeladministrasjon

Spørsmål 5.1: Hva er nøkkelstyring?
A 5.1: Nøkkelhåndtering er oppgavene involvert i å beskytte, lagre, sikkerhetskopiere og organisere krypteringsnøkler. HX implementerer dette i en UCSM-sentrisk policy.
Spørsmål 5.2: Hvilken mekanisme gir støtte for nøkkelkonfigurasjon?
A 5.2: UCSM gir støtte for å konfigurere sikkerhetsnøkler.

Spørsmål 5.3: Hvilken type nøkkelhåndtering er tilgjengelig?
A 5.3: Lokal administrering av nøkler støttes, sammen med ekstern nøkkeladministrasjon i bedriftsklassen med tredjeparts nøkkeladministrasjonsservere.
Spørsmål 5.4: Hvem er partnerne for ekstern nøkkeladministrasjon?
A 5.4: Vi støtter for tiden Vormetric og Gemalto (Safenet) og inkluderer høy tilgjengelighet (HA). HyTrust er i testing.
Spørsmål 5.5: Hvordan implementeres fjernstyring av nøkkel?
A 5.5: Ekstern nøkkelhåndtering håndteres via KMIP 1.1.

Spørsmål 5.6: Hvordan er lokal administrasjon konfigurert?
A 5.6: Sikkerhetsnøkkelen (KEK) konfigureres i HX Connect, direkte av brukeren.
Spørsmål 5.7: Hvordan er fjernadministrasjon konfigurert?
A 5.7: Den eksterne nøkkeladministrasjonen (KMIP) serveradresseinformasjonen sammen med påloggingsinformasjon konfigureres i HX Connect av brukeren.
Spørsmål 5.8: Hvilken del av HX kommuniserer med KMIP-serveren for konfigurering?
A 5.8: CIMC på hver node bruker denne informasjonen til å koble til KMIP-serveren og hente sikkerhetsnøkkelen (KEK) fra den.

Spørsmål 5.9: Hvilke typer sertifikater støttes i prosessen for nøkkelgenerering/henting/oppdatering?
A 5.9: CA-signerte og selvsignerte sertifikater støttes begge.
Spørsmål 5.10: Hvilke arbeidsflyter støttes med krypteringsprosessen?
A 5.10: Beskytt/opphev beskyttelse ved hjelp av et tilpasset passord støttes sammen med konvertering av lokal til ekstern nøkkeladministrasjon. Re-key operasjoner støttes. Sikker disksletting støttes også.

Brukerarbeidsflyt: Lokal

Spørsmål 6.1: Hvor konfigurerer jeg lokal nøkkeladministrasjon i HX Connect?
A 6.1: I krypteringsdashbordet velger du konfigurer-knappen og følger veiviseren.

Spørsmål 6.2: Hva må jeg ha klart for å komme i gang?
A 6.2: Du må oppgi en sikkerhetspassordfrase på 32 tegn.
Spørsmål 6.3: Hva skjer hvis jeg må sette inn en ny SED?
A 6.3: I UCSM må du redigere den lokale sikkerhetspolicyen og sette den distribuerte nøkkelen til den eksisterende nodenøkkelen.
Q 6.4: Hva skjer når jeg setter inn den nye disken?
A 6.4: Hvis sikkerhetsnøkkelen på disken samsvarer med serveren (noden) låses den opp automatisk. Hvis sikkerhetsnøklene er forskjellige, vil disken vises som "Låst". Du kan enten tømme disken for å slette alle data eller låse den opp ved å oppgi riktig nøkkel. Dette er et godt tidspunkt å engasjere TAC.

Brukerarbeidsflyt: Ekstern

Spørsmål 7.1: Hva er noen ting jeg må passe på med konfigurasjon av ekstern nøkkeladministrasjon?
A 7.1: Kommunikasjon mellom klyngen og KMIP-serveren(e) skjer over CIMC på hver node. Dette betyr at vertsnavnet kan brukes for KMIP-server bare hvis Inband IP-adressen og DNS er konfigurert på CIMC-administrasjonen
Spørsmål 7.2: Hva skjer hvis jeg må bytte ut eller sette inn en ny SED?
A 7.2: Klyngen vil lese identifikatoren fra disken og prøve å låse den opp automatisk. Hvis automatisk opplåsing mislykkes, vises disken som "låst", og brukeren må låse opp disken manuelt. Du må kopiere sertifikatene til KMIP-server(e) for utveksling av legitimasjon.
Spørsmål 7.3: Hvordan kopierer jeg sertifikater fra klyngen til KMIP-serveren(e)?
A 7.3: Det er to måter å gjøre dette på. Du kan kopiere sertifikatet fra BMC til KMIP-serveren direkte, eller du kan bruke CSR for å få et CA-signert sertifikat og kopiere det CA-signerte sertifikatet til BMC ved hjelp av UCSM-kommandoer.

Spørsmål 7.4: Hvilke hensyn er det for å legge til krypterte noder til en klynge som bruker ekstern nøkkeladministrasjon?
A 7.4: Når du legger til nye verter til KMIP-serveren(e), bør vertsnavnet som brukes være serienummeret til serveren. For å få KMIP-serverens sertifikat kan du bruke en nettleser for å få rotsertifikatet til KMIP-serveren(e).

Brukerarbeidsflyt: Generelt

Spørsmål 8.1: Hvordan sletter jeg en disk?
A 8.1: I HX Connect-dashbordet velger du systeminformasjonen view. Derfra kan du velge individuelle disker for sikker sletting.
Spørsmål 8.2: Hva om jeg slettet en disk ved et uhell?
A 8.2: Når sikker sletting brukes, blir dataene ødelagt permanent

Spørsmål 8.3: Hva skjer når jeg ønsker å avvikle en node eller fjerne en tjenesteprofffile?
A 8.3: Ingen av disse handlingene vil fjerne krypteringen på disken/kontrolleren.
Spørsmål 8.4: Hvordan blir kryptering deaktivert?
A 8.4: Brukeren må eksplisitt deaktivere kryptering i HX Connect. Hvis brukeren prøver å slette en sikkerhetspolicy i UCSM når den tilknyttede serveren er sikret, vil UCSM vise en konfigurasjonsfeil og ikke tillate handlingen. Sikkerhetspolicyen må deaktiveres først.

Brukerarbeidsflyt: Sertifikatbehandling

Spørsmål 9.1: Hvordan håndteres sertifikater under oppsett av ekstern administrasjon?
A 9.1: Sertifikater opprettes ved hjelp av HX Connect og den(e) eksterne KMIP-serveren(e). Når sertifikater er opprettet, vil nesten aldri bli slettet.

Spørsmål 9.2: Hva slags sertifikater kan jeg bruke?
A 9.2: Du kan bruke enten selvsignerte sertifikater eller CA-sertifikater. Du må velge under oppsett. For CA-signerte sertifikater vil du generere et sett med Certificate Signing Requests (CSR-er). De signerte sertifikatene lastes opp til KMIP-serveren(e).
Spørsmål 9.3: Hvilket vertsnavn bør jeg bruke når jeg genererer sertifikatene?
A 9.3: Vertsnavnet som brukes for å generere sertifikatet skal være serienummeret til serveren.

Firmware oppdateringer

Sp 10.1: Er det noen begrensninger for oppgradering av diskens fastvare?
A 10.1: Hvis det oppdages en krypteringskompatibel stasjon, vil ingen fastvareendringer på disken tillates for den disken.

Sp 10.2: Er det noen restriksjoner på oppgradering av UCSM-fastvare?
A 10.2: Nedgradering av UCSM/CIMC til pre-UCSM 3.1(3x) er begrenset hvis det er en kontroller som er i sikret tilstand.

Sikker slettingsdetaljer

Q 11.1: Hva er sikker sletting?
A 11.1: Sikker sletting er umiddelbar sletting av data på stasjonen (tørk av diskkrypteringsnøkkelen). Dette betyr at en enkel autentisert kommando kan sendes til stasjonen for å endre 256-bits krypteringsnøkkelen som er lagret på stasjonen. Dette sikrer at stasjonen tørkes ren og at det ikke er data igjen. Selv det originale vertssystemet kan ikke lese dataene, så de vil være uleselige for andre systemer. Operasjonen tar bare et par sekunder, i motsetning til de mange minuttene eller til og med timene det tar å utføre en analog operasjon på en ukryptert disk og unngår kostnadene for dyrt avmagnetiseringsutstyr eller -tjenester.
Spørsmål 11.2: Hvordan utføres sikker sletting?
A 11.2: Dette er en GUI-operasjon som utføres én stasjon om gangen.

Spørsmål 11.3: Når utføres vanligvis sikker sletting?
A 11.3: Brukerinitiert sikker sletting av en enkelt disk er en sjelden operasjon. Dette gjøres for det meste når du fysisk vil fjerne disken for erstatning, overføre den til en annen node, eller unngå nær fremtidig feil.
Spørsmål 11.4: Hvilke begrensninger er det for sikker sletting?
A 11.4: Sikre sletteoperasjoner kan bare utføres hvis klyngen er sunn for å sikre at klyngens feilmotstandsdyktighet ikke påvirkes.
Spørsmål 11.5: Hva skjer hvis jeg må fjerne en hel node?
A 11.5: Det er arbeidsflyter for fjerning av noder og utskifting av noder for å støtte sikker sletting av alle stasjoner. Se administrasjonsveiledningen for detaljer eller kontakt Cisco TAC.

Sp 11.6: Kan en sikkert slettet disk gjenbrukes?
A 11.6: En disk som er sikkert slettet kan bare brukes på nytt i en annen klynge. Sikker sletting av SED gjøres ved å tørke av diskkrypteringsnøkkelen (DEK). Dataene på disken kan ikke dekrypteres uten DEK. Dette lar deg gjenbruke eller ta ut disken uten at det går på bekostning av dataene.
Spørsmål 11.7: Hva skjer hvis disken jeg vil slette inneholder den siste primære kopien av klyngedata?
A 11.7: Dataene på disken bør ha andre kopier i klyngen for å unngå tap av data. Imidlertid, hvis sikker sletting er forespurt på en disk som er den siste primære kopien, vil denne operasjonen bli avvist inntil det er minst én ekstra kopi tilgjengelig. Rebalance bør lage denne kopien i bakgrunnen.
Sp 11.8: Jeg trenger virkelig å slette en disk på en sikker måte, men klyngen er ikke sunn. Hvordan kan jeg gjøre det?
A 11.8: Kommandolinjen (STCLI/HXCLI) vil tillate sikker sletting når klyngen ikke er frisk og disken ikke inneholder den siste primærkopien, ellers er den ikke tillatt.

Q 11.9: Hvordan kan jeg sikkert slette en hel node?
A 11.9: Dette er et sjeldent scenario. Sikker sletting av alle disker i en node gjøres når man ønsker å ta noden ut av klyngen. Hensikten er enten å distribuere noden i en annen klynge eller ta ut noden. Vi kan klassifisere nodefjerning i dette scenariet på to forskjellige måter:
1. Sikker sletting av alle diskene uten å deaktivere kryptering
2. Sikker sletting av alle diskene etterfulgt av deaktivering av kryptering for den noden (og diskene). Ta kontakt med Cisco TAC for å få hjelp.

Sikker utvidelse av en klynge

Q 12.1: Hva slags node kan jeg utvide en kryptert klynge med?
A 12.1: Kun SED-kompatible noder kan legges til en HX-klynge med SED-er.

Sp 12.2: Hvordan håndteres utvidelse med lokal nøkkelhåndtering?
A 12.2: Lokal nøkkelutvidelse er en sømløs operasjon uten behov for ekstern konfigurasjon.
Spørsmål 12.3: Hvordan håndteres utvidelse med ekstern nøkkeladministrasjon?
A 12.3: Ekstern nøkkelutvidelse krever låsetrinn med sertifikater/nøkkeladministrasjonsinfrastruktur:
- Sertifikater kreves for å legge til ny node sikkert
- Implementeringen vil vise en advarsel med trinn for å fortsette, inkludert en lenke for sertifikatnedlasting
- Brukeren følger trinnene for å laste opp sertifikater og prøver deretter distribusjonen på nytt

Støttedokumenter

Mikron:

FIPS

Liste over kryptoalgoritmer godkjent for FIPS 140-2: https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf

CDETTER:

Prosjekt: CSC.nuova Produkt: ucs-blade-server Komponent: ucsm

SED funksjonell spesifikasjon:

EDCS: 1574090

SED CIMC-spesifikasjon:

http://wwwin-eng.cisco.com/Eng/SAVBU/Projects/Rackmount/Freel_Peak/SW_Specs/Remote_Key_Mgmt_sw_design_spec.doc

E-postlister:

Dokumenter / Ressurser

CISCO HyperFlex HX Dataplattform [pdf] Instruksjoner
HyperFlex HX Data Platform, HyperFlex, HX Data Platform, Data Platform, Platform

Referanser

Brukerhåndbok