CISCO HyperFlex HX Data Platform

Produktinformation

• Produktnavn: HX sikkerhedskryptering
• Version: HXDP 5.01b
• Krypteringsløsning: Softwarebaseret løsning ved hjælp af Intersight Key Manager
• Krypteringstype: Selvkrypterende drev (SED'er)
• Understøttede drevtyper: HDD og SSD SED'er fra Micron
• Overholdelsesstandarder: FIPS 140-2 niveau 2 (drevfabrikanter) og FIPS 140-2 niveau 1 (platform)
• Klyngedækkende kryptering: Kryptering på HX er implementeret i hardware til hvilende data kun ved brug af SED'er
• Individuel VM-kryptering: Håndteres af 3. parts software såsom Hytrust eller Vormetrics transparente klient
• VMware Native VM-kryptering: Understøttet af HX til brug med SED-kryptering
• Nøglehåndtering: Media Encryption Key (MEK) og Key Encryption Key (KEK) bruges til hver SED
• Hukommelsesbrug: Krypteringsnøgler er aldrig til stede i nodehukommelsen
• Effektivitet: Diskkryptering/dekryptering håndteres i drevets hardware, den samlede systemydelse påvirkes ikke
• Yderligere fordele ved SED'er:
  • Øjeblikkelig kryptografisk sletning for reducerede omkostninger til drevpensionering og omfordeling
  • Overholdelse af regerings- eller industribestemmelser for databeskyttelse
  • Reduceret risiko for disktyveri og nodetyveri, da data bliver ulæselige, når hardware er fjernet

Produktbrugsvejledning

Følg disse instruktioner for at bruge HX Security Encryption:

1. Sørg for, at dit system understøtter hardwarebaseret kryptering, eller at du foretrækker den softwarebaserede løsning ved hjælp af Intersight Key Manager.
2. Se administrationsdokumenterne eller whitepaper(erne) for information om softwarebaseret kryptering.
3. Hvis du vælger at bruge hardwarebaseret kryptering med SED'er, skal du sørge for, at din HX-klynge består af ensartede noder (SED'er eller ikke-SED'er).
4. For SED'er skal du forstå, at der er to nøgler i brug: Media Encryption Key (MEK) og Key Encryption Key (KEK).
5. MEK'en styrer kryptering og dekryptering af data til disken og er sikret og administreret i hardware.
6. KEK'en sikrer MEK/DEK'en og vedligeholdes enten i et lokalt eller eksternt nøglelager.
7. Du skal ikke bekymre dig om, at nøglerne er til stede i nodehukommelsen, da krypteringsnøgler aldrig gemmes der.
8. Bemærk, at diskkryptering/dekryptering håndteres i drevets hardware, hvilket sikrer, at den overordnede systemydelse ikke påvirkes.
9. Hvis du har specifikke krav til compliance-standarder, skal du være opmærksom på, at HX SED-krypterede drev opfylder FIPS 140-2 niveau 2-standarder fra drevproducenterne, mens HX Encryption på platformen opfylder FIPS 140-2 niveau 1-standarder.
10. Hvis du har brug for at kryptere individuelle VM'er, kan du overveje at bruge tredjepartssoftware såsom Hytrust eller Vormetrics transparente klient. Alternativt kan du bruge VMwares native VM-kryptering introduceret i vSphere 3.
11. Husk, at brug af en VM-krypteringsklient oven i HX SED-baseret kryptering vil resultere i dobbeltkryptering af dataene.
12. Sørg for, at din HX-klynge er forbundet via betroede netværk eller krypterede tunneler for sikker replikering, da HX-replikering ikke er krypteret.

Ofte stillede spørgsmål om HX-sikkerhedskryptering

Fra HXDP 5.01b tilbyder HyperFlex en softwarebaseret løsning, der bruger Intersight Key Manager til systemer, der enten ikke understøtter hardwarebaseret kryptering, eller til brugere, der ønsker denne funktionalitet frem for hardwareløsninger. Denne FAQ fokuserer kun på SED-baserede hardwareløsninger til HX-kryptering. Se administrationsdokumenterne eller whitepaper(erne) for information om softwarebaseret kryptering.

Bias Statement
Dokumentationssættet til dette produkt bestræber sig på at bruge skævhedsfrit sprog. I dette dokumentationssæt er bias-free defineret som sprog, der ikke indebærer diskrimination baseret på alder, handicap, køn, raceidentitet, etnisk identitet, seksuel orientering, socioøkonomisk status og intersektionalitet. Der kan være undtagelser i dokumentationen på grund af sprog, der er hårdkodet i produktsoftwarens brugergrænseflader, sprog, der er baseret på standarddokumentation, eller sprog, der bruges af et refereret tredjepartsprodukt.

Hvorfor Cisco til sikkerhed og HX-kryptering 

• Q 1.1: Hvilke processer er på plads for sikker udvikling?
  A 1.1: Cisco-servere overholder Cisco Secure Development Lifecycle (CSDL):
  • Cisco leverer processer, metoder, rammer til at udvikle indlejret sikkerhed på Cisco-servere, ikke kun en overlejring
  • Dedikeret Cisco-team til trusselsmodellering/statisk analyse på UCS produktportefølje
  • Cisco Advanced Security Initiative Group (ASIG) udfører proaktiv penetrationstest for at forstå, hvordan trusler kommer ind og løse problemer ved at forbedre HW & SW gennem CDETS og teknik
  • Dedikeret Cisco-team til at teste og håndtere udgående sårbarhed og kommunikere som sikkerhedsrådgivere til kunder
  • Alle underliggende produkter gennemgår produktsikkerhedsbaseline-krav (PSB), som styrer sikkerhedsstandarderne for Cisco-produkter
  • Cisco udfører sårbarheds-/protokol robusthedstest på alle UCS-udgivelser
• Spørgsmål 1.2: Hvorfor er SED'er vigtige?
  A 1.2: SED'er bruges til data-at-rest-kryptering og er et krav for mange, hvis ikke alle, føderale, medicinske og finansielle institutioner.

Generel information forbiview

• Q 2.1: Hvad er SED'er?
  A 2.1: SED (Self-Encrypting Drives) har speciel hardware, der krypterer indgående data og dekrypterer udgående data i realtid.
• Q 2.2: Hvad er omfanget af kryptering på HX?
  A 2.2: Kryptering på HX er i øjeblikket implementeret i hardware til hvilende data kun ved brug af krypterede drev (SED'er). HX-kryptering er klyngedækkende. Individuel VM-kryptering håndteres af tredjepartssoftware såsom Hytrust eller Vormetrics transparente klient og er uden for rammerne af HX-ansvar. HX understøtter også brugen af ​​VMwares native VM-kryptering introduceret i vSphere 3. Brug af en VM-krypteringsklient oven på HX SED-baseret kryptering vil resultere i dobbeltkryptering af dataene. HX-replikering er ikke krypteret og er afhængig af betroede netværk eller krypterede tunneler implementeret af slutbrugeren.
• Q 2.3: Hvilke overholdelsesstandarder opfyldes med HX-kryptering?
  A 2.3: HX SED-krypterede drev opfylder FIPS 140-2 niveau 2-standarder fra drevproducenterne. HX-kryptering på platformen opfylder FIPS 140-2 niveau 1-standarder.
• Q 2.4: Understøtter vi både HDD og SSD til kryptering?
  A 2.4: Ja, vi understøtter både HDD og SSD SED'er fra Micron.
• Q 2.5: Kan en HX-klynge have krypterede og ikke-krypterede drev på samme tid?
  A 2.5: Alle noder i klyngen skal være ensartede (SED'er eller ikke-SED'er)
• Q 2.6: Hvilke nøgler er i brug til en SED, og ​​hvordan bruges de?
  A 2.6: Der er to nøgler i brug for hver SED. Media Encryption Key (MEK) også kaldet Disk Encryption Key (DEK), styrer kryptering og dekryptering af data til disken og er sikret og administreret i hardware. Nøglekrypteringsnøglen (KEK) sikrer DEK/MEK og vedligeholdes i enten et lokalt eller eksternt nøglelager.
• Spørgsmål 2.7: Er nøglerne nogensinde til stede i hukommelsen?
  A 2.7: Krypteringsnøgler er aldrig til stede i nodehukommelsen
• Q 2.8: Hvordan påvirkes ydeevnen af ​​krypterings-/dekrypteringsprocessen?
  A 2.8: Diskkryptering/dekryptering håndteres i drevets hardware. Systemets overordnede ydeevne påvirkes ikke og er ikke genstand for angreb rettet mod andre komponenter i systemet
• Spørgsmål 2.9: Hvad er andre grunde til at bruge SED'er end kryptering i hvile?
  A 2.9: SED'er kan reducere omkostningerne til pensionering og omplacering gennem øjeblikkelig kryptografisk sletning. De tjener også til at overholde regeringens eller industriens regler for databeskyttelse. Endnu en advantage er den reducerede risiko for disktyveri og nodetyveri, da dataene, når først hardwaren er fjernet fra økosystemet, er ulæselige.
• Q2.10: Hvad sker der med deduplikering og komprimering med SED'er? Hvad sker der med 3. parts softwarebaseret kryptering?
  A2.10: Deduplikering og komprimering med SED'er på HX opretholdes, da kryptering af data i hvile finder sted som et sidste trin i skriveprocessen. Deduplikering og komprimering har allerede fundet sted. Med 3. parts softwarebaserede krypteringsprodukter administrerer VM'erne deres kryptering og videregiver krypterede skrivninger til hypervisoren og efterfølgende HX. Da disse skrivninger allerede er krypteret, bliver de ikke dedupliceret eller komprimeret. HX Software Based Encryption (i 5.x-kodelinjen) vil være en softwarekrypteringsløsning, der implementeres i stakken efter skriveoptimeringer (deduplikering og komprimering), så fordelen bevares i så fald.

Figuren nedenfor er en overview af implementeringen af ​​SED med HX.

Drevdetaljer 

• Q 3.1: Hvem fremstiller de krypterede drev, der bruges i HX?
  A 3.1: HX bruger drev fremstillet af Micron: Micron-specifikke dokumenter er linket til i sektionen med understøttende dokumenter i denne FAQ.
• Spørgsmål 3.2: Understøtter vi nogen SED'er, der ikke er FIPS-kompatible?
  A 3.2: Vi understøtter også nogle drev, som ikke er FIPS, men som understøtter SED (TCGE).
• Q 3.3: Hvad er TCG?
  A 3.3: TCG er Trusted Computing Group, som skaber og administrerer specifikationsstandarden for krypteret datalagring
• Spørgsmål 3.4: Hvad betragtes som sikkerhed i virksomhedsklassen, når det kommer til SAS SSD'er til datacentret? Hvilke specifikke funktioner har disse drev, der sikrer sikkerhed og beskytter mod angreb?
  A 3.4: Denne liste opsummerer funktionerne i virksomhedsklassen for de SED'er, der bruges i HX, og hvordan de relaterer til TCG-standarden.
  1. Selvkrypterende drev (SED'er) giver stærk sikkerhed for hvilende data på din SED, hvilket forhindrer uautoriseret dataadgang. Trusted Computing Group (TCG) har udviklet en liste over funktionerne og fordelene ved selvkrypterende drev til både HDD'er og SSD'er. TCG'en leverer en standard, der kaldes TCG Enterprise SSC (Security Subsystem Class) og er fokuseret på data i hvile. Dette er et krav for alle SED'er. Specifikationen gælder for datalagringsenheder og controllere, der opererer i virksomhedslagring. Listen omfatter:
     • Gennemsigtighed: Ingen system- eller applikationsændringer påkrævet; krypteringsnøgle genereret af selve drevet ved hjælp af en indbygget ægte tilfældig talgenerator; drevet krypterer altid.
     • Nem administration: Ingen krypteringsnøgle at administrere; softwareleverandører udnytter standardiseret grænseflade til at administrere SED'er, herunder fjernstyring, pre-boot-godkendelse og adgangskodegendannelse
     • Omkostninger til bortskaffelse eller genbrug: Slet indbygget krypteringsnøgle med en SED
     • Genkryptering: Med SED er der ingen grund til nogensinde at genkryptere dataene
     • Præstation: Ingen forringelse af SED-ydelse; hardware-baseret
     • Standardisering: Hele drevindustrien bygger efter TCG/SED-specifikationerne
     • Forenklet: Ingen interferens med upstream-processer
  2. SSD SED'er giver mulighed for kryptografisk at slette drevet. Det betyder, at der kan sendes en simpel autentificeret kommando til drevet for at ændre den 256-bit krypteringsnøgle, der er gemt på drevet. Dette sikrer, at drevet tørres rent, og at der ikke er nogen data tilbage. Selv det originale værtssystem kan ikke læse dataene, så det vil absolut være ulæseligt af noget andet system. Operationen tager kun et par sekunder, i modsætning til de mange minutter eller endda timer, det tager at udføre en analog operation på en ukrypteret HDD og undgår omkostningerne ved dyrt HDD-afgaussingsudstyr eller -tjenester.
  3. FIPS (Federal Information Processing Standard) 140-2 er en amerikansk regeringsstandard, der beskriver de krypterings- og relaterede sikkerhedskrav, som it-produkter skal opfylde for følsom, men uklassificeret brug. Dette er ofte også et krav til offentlige myndigheder og virksomheder i de finansielle tjenesteydelser og sundhedssektoren. En SSD, der er FIPS-140-2-valideret, bruger stærk sikkerhedspraksis, herunder godkendte krypteringsalgoritmer. Det specificerer også, hvordan enkeltpersoner eller andre processer skal autoriseres for at bruge produktet, og hvordan moduler eller komponenter skal designes til sikkert at interagere med andre systemer. Faktisk er et af kravene til et FIPS-140-2-valideret SSD-drev, at det er en SED. Husk på, at selvom TCG ikke er den eneste måde at få et certificeret krypteret drev på, giver TCG Opal- og Enterprise SSC-specifikationerne os et springbræt til FIPS-validering. 4. En anden væsentlig funktion er sikre downloads og diagnosticering. Denne firmwarefunktion beskytter drevet mod softwareangreb gennem en digital signatur, der er indbygget i firmwaren. Når der er behov for downloads, forhindrer den digitale signatur uautoriseret adgang til drevet, hvilket forhindrer forfalsket firmware i at blive indlæst på drevet.

Hyperflex-installation med SED'er

• Q 4.1: Hvordan håndterer installationsprogrammet en SED-implementering? Er der nogen særlige kontroller?
  A 4.1: Installationsprogrammet kommunikerer med UCSM og sikrer, at systemets firmware er korrekt og understøttet for den detekterede hardware. Krypteringskompatibilitet kontrolleres og håndhæves (f.eks. ingen blanding af SED og ikke-SED).
• Spørgsmål 4.2: Er implementeringen anderledes ellers?
  A 4.2: Installationen ligner en almindelig HX-installation, men tilpasset arbejdsgang understøttes ikke for SED'er. Denne operation kræver også UCSM-legitimationsoplysninger for SED'erne.
• Q 4.3: Hvordan fungerer licensering med kryptering? Er der noget ekstra, der skal på plads?
  A 4.3: SED-hardware (bestilt fra fabrikken, ikke eftermonteret) + HXDP 2.5 + UCSM (3.1(3x)) er de eneste ting, der er nødvendige for at aktivere kryptering med nøglehåndtering. Der er ingen yderligere licenser uden for det grundlæggende HXDP-abonnement, der kræves i 2.5-udgivelsen.
• Spørgsmål 4.4: Hvad sker der, når jeg har et SED-system, der har drev, der ikke længere er tilgængelige? Hvordan kan jeg udvide denne klynge?
  A 4.4: Når vi har en PID, der er udtjent fra vores leverandører, har vi en erstatnings-PID, der er kompatibel med den gamle PID. Dette erstatnings-PID kan bruges til RMA, udvidelse i en knude og udvidelse af klynge (med nye knudepunkter). Alle metoder er alle understøttet, men de kan kræve opgradering til en specifik udgivelse, som også er identificeret i overgangsudgivelsesbemærkningerne.

Nøglehåndtering

• Q 5.1: Hvad er Key Management?
  A 5.1: Nøglestyring er de opgaver, der er involveret i at beskytte, opbevare, sikkerhedskopiere og organisere krypteringsnøgler. HX implementerer dette i en UCSM-centreret politik.
• Q 5.2: Hvilken mekanisme understøtter nøglekonfiguration?
  A 5.2: UCSM giver support til at konfigurere sikkerhedsnøgler.
• Spørgsmål 5.3: Hvilken type nøglestyring er tilgængelig?
  A 5.3: Lokal styring af nøgler understøttes sammen med fjernnøglestyring i virksomhedsklassen med tredjeparts nøglestyringsservere.
• Spørgsmål 5.4: Hvem er eksterne nøgleadministrationspartnere?
  A 5.4: Vi understøtter i øjeblikket Vormetric og Gemalto (Safenet) og inkluderer høj tilgængelighed (HA). HyTrust er i test.
• Q 5.5: Hvordan implementeres fjernnøglestyring?
  A 5.5: Fjernnøglehåndtering håndteres via KMIP 1.1.
• Q 5.6: Hvordan er lokal administration konfigureret?
  A 5.6: Sikkerhedsnøglen (KEK) konfigureres i HX Connect, direkte af brugeren.
• Q 5.7: Hvordan er fjernstyring konfigureret?
  A 5.7: Remote Key Management (KMIP) serveradresseoplysningerne sammen med loginoplysninger konfigureres i HX Connect af brugeren.
• Q 5.8: Hvilken del af HX kommunikerer med KMIP-serveren til konfiguration?
  A 5.8: CIMC'en på hver node bruger disse oplysninger til at oprette forbindelse til KMIP-serveren og hente sikkerhedsnøglen (KEK) fra den.
  
• Spørgsmål 5.9: Hvilke typer certifikater understøttes i nøglegenerering/-hentning/opdateringsprocessen?
  A 5.9: CA-signerede og selvsignerede certifikater understøttes begge.
  
• Q 5.10: Hvilke arbejdsgange understøttes med krypteringsprocessen?
  A 5.10: Beskyt/fjern beskyttelse ved hjælp af en brugerdefineret adgangskode understøttes sammen med konvertering af lokal til fjernnøglestyring. Re-key operationer er understøttet. Sikker disksletning er også understøttet.
  

Bruger Workflow: Lokal

• Q 6.1: I HX Connect, hvor skal jeg så konfigurere lokal nøglestyring?
  A 6.1: I krypteringsdashboardet skal du vælge knappen Konfigurer og følge guiden.
• Spørgsmål 6.2: Hvad skal jeg have klar til at komme i gang med?
  A 6.2: Du skal angive en sikkerhedsadgangssætning på 32 tegn.
• Q 6.3: Hvad sker der, hvis jeg skal indsætte en ny SED?
  A 6.3: I UCSM skal du redigere den lokale sikkerhedspolitik og indstille den installerede nøgle til den eksisterende nodenøgle.
• Q 6.4: Hvad sker der, når jeg indsætter den nye disk?
  A 6.4: Hvis sikkerhedsnøglen på disken matcher serverens (noden) låses den automatisk op. Hvis sikkerhedsnøglerne er forskellige, vil disken blive vist som "Låst". Du kan enten rydde disken for at slette alle data eller låse den op ved at angive den korrekte nøgle. Dette er et godt tidspunkt at engagere sig i TAC.

Bruger Workflow: Fjernbetjening

• Spørgsmål 7.1: Hvad er nogle ting, jeg skal være opmærksom på med fjernstyringskonfigurationen?
  A 7.1: Kommunikation mellem klyngen og KMIP-serveren(e) sker over CIMC'en på hver node. Dette betyder, at værtsnavnet kun kan bruges til KMIP-server, hvis Inband IP-adressen og DNS er konfigureret på CIMC-administrationen
• Q 7.2: Hvad sker der, hvis jeg skal udskifte eller indsætte en ny SED?
  A 7.2: Klyngen vil læse identifikatoren fra disken og forsøge at låse den op automatisk. Hvis den automatiske oplåsning mislykkes, vises disken som "låst", og brugeren skal låse disken op manuelt. Du bliver nødt til at kopiere certifikaterne til KMIP-server(e) for at udveksle legitimationsoplysninger.
• Q 7.3: Hvordan kopierer jeg certifikater fra klyngen til KMIP-serveren(e)?
  A 7.3: Der er to måder at gøre dette på. Du kan kopiere certifikatet fra BMC'en til KMIP-serveren direkte, eller du kan bruge CSR'en til at få et CA-signeret certifikat og kopiere det CA-signerede certifikat til BMC'en ved hjælp af UCSM-kommandoer.
• Spørgsmål 7.4: Hvilke overvejelser er der for at tilføje krypterede noder til en klynge, der bruger fjernnøglestyring?
  A 7.4: Når du tilføjer nye værter til KMIP-serveren(e), skal det anvendte værtsnavn være serverens serienummer. For at få KMIP-serverens certifikat kan du bruge en browser til at få rodcertifikatet for KMIP-serverne.

Bruger Workflow: Generelt

• Q 8.1: Hvordan sletter jeg en disk?
  A 8.1: I HX Connect-dashboardet skal du vælge systemoplysningerne view. Derfra kan du vælge individuelle diske til sikker sletning.
• Q 8.2: Hvad hvis jeg slettede en disk ved et uheld?
  A 8.2: Når sikker sletning bruges, destrueres dataene permanent
• Q 8.3: Hvad sker der, når jeg vil dekommissionere en node eller adskille en serviceprofffile?
  A 8.3: Ingen af ​​disse handlinger vil fjerne krypteringen på disken/controlleren.
• Q 8.4: Hvordan bliver kryptering deaktiveret?
  A 8.4: Brugeren skal eksplicit deaktivere kryptering i HX Connect. Hvis brugeren forsøger at slette en sikkerhedspolitik i UCSM, når den tilknyttede server er blevet sikret, vil UCSM vise en konfigurationsfejl og afvise handlingen. Sikkerhedspolitikken skal først deaktiveres.

Brugerarbejdsgang: Certifikatstyring

• Q 9.1: Hvordan håndteres certifikater under fjernstyringsopsætning?
  A 9.1: Certifikater oprettes ved hjælp af HX Connect og den eller de eksterne KMIP-servere. Når certifikater først er oprettet, vil de næsten aldrig blive slettet.
• Q 9.2: Hvilken slags certifikater kan jeg bruge?
  A 9.2: Du kan bruge enten selvsignerede certifikater eller CA-certifikater. Du skal vælge under opsætningen. For CA-signerede certifikater vil du generere et sæt Certificate Signing Requests (CSR'er). De signerede certifikater uploades til KMIP-serveren(e).
• Q 9.3: Hvilket værtsnavn skal jeg bruge, når jeg genererer certifikaterne?
  A 9.3: Det værtsnavn, der bruges til at generere certifikatet, skal være serienummeret på serveren.

Firmware opdateringer

• Sp 10.1: Er der nogen begrænsninger for opgradering af diskens firmware?
  A 10.1: Hvis der registreres et krypteringskompatibelt drev, tillades eventuelle ændringer af diskfirmwaren ikke for den pågældende disk.
• Sp 10.2: Er der nogen begrænsninger for opgradering af UCSM-firmware?
  A 10.2: Nedgradering af UCSM/CIMC til præ-UCSM 3.1(3x) er begrænset, hvis der er en controller, der er i sikret tilstand.

Sikker sletning af detaljer

• Q 11.1: Hvad er Sikker sletning?
  A 11.1: Sikker sletning er øjeblikkelig sletning af data på drevet (sletning af diskkrypteringsnøglen). Det betyder, at der kan sendes en simpel autentificeret kommando til drevet for at ændre den 256-bit krypteringsnøgle, der er gemt på drevet. Dette sikrer, at drevet tørres rent, og at der ikke er nogen data tilbage. Selv det originale værtssystem kan ikke læse dataene, så de vil være ulæselige af noget andet system. Operationen tager kun et par sekunder, i modsætning til de mange minutter eller endda timer, det tager at udføre en analog operation på en ukrypteret disk og undgår omkostningerne ved dyrt afmagnetiseringsudstyr eller -tjenester.
• Sp 11.2: Hvordan udføres sikker sletning?
  A 11.2: Dette er en GUI-operation, der udføres et drev ad gangen.
• Sp 11.3: Hvornår udføres sikker sletning normalt?
  A 11.3: Brugerinitieret sikker sletning af en enkelt disk er en sjælden operation. Dette gøres for det meste, når du fysisk vil fjerne disken til udskiftning, overføre den til en anden node eller undgå en nær fremtidig fejl.
• Sp 11.4: Hvilke begrænsninger er der for sikker sletning?
  A 11.4: Sikker sletteoperationer kan kun udføres, hvis klyngen er sund for at sikre, at klyngens fejlmodstandsdygtighed ikke påvirkes.
• Sp 11.5: Hvad sker der, hvis jeg skal fjerne en hel node?
  A 11.5: Der er node remove og node replace workflows for at understøtte sikker sletning af alle drev. Se administratorvejledningen for detaljer, eller kontakt Cisco TAC.
• Q 11.6: Kan en sikkert slettet disk genbruges?
  A 11.6: En disk, der er blevet sikkert slettet, kan kun genbruges i en anden klynge. Den sikre sletning af SED'en udføres ved at slette diskkrypteringsnøglen (DEK). Dataene på disken kan ikke dekrypteres uden DEK. Dette giver dig mulighed for at genbruge eller dekommissionere disken uden at kompromittere dataene.
• Q 11.7: Hvad sker der, hvis den disk, jeg vil slette, indeholder den sidste primære kopi af klyngedata?
  A 11.7: Dataene på disken bør have andre kopier i klyngen for at undgå datatab. Men hvis der anmodes om sikker sletning på en disk, der er den sidste primære kopi, vil denne handling blive afvist, indtil der er mindst én kopi mere tilgængelig. Rebalance burde lave denne kopi i baggrunden.
• Sp 11.8: Jeg har virkelig brug for at slette en disk sikkert, men klyngen er ikke sund. Hvordan kan jeg gøre det?
  A 11.8: Kommandolinjen (STCLI/HXCLI) tillader sikker sletning, når klyngen ikke er sund, og disken ikke indeholder den sidste primære kopi, ellers er det ikke tilladt.
• Q 11.9: Hvordan kan jeg sikkert slette en hel node?
  A 11.9: Dette er et sjældent scenarie. Sikker sletning af alle diske i en node udføres, når man ønsker at tage noden ud af klyngen. Hensigten er enten at implementere noden i en anden klynge eller nedlægge noden. Vi kan klassificere nodefjernelse i dette scenarie på to forskellige måder:
  1. Sikker sletning af alle diske uden at deaktivere kryptering
  2. Sikker sletning af alle diske efterfulgt af deaktivering af kryptering for den node (og diske). Kontakt venligst Cisco TAC for at få hjælp.

Sikker udvidelse af en klynge

• Q 12.1: Hvilken slags node kan jeg udvide en krypteret klynge med?
  A 12.1: Kun SED-kompatible noder kan tilføjes til en HX-klynge med SED'er.
• Sp 12.2: Hvordan håndteres udvidelse med lokal nøglestyring?
  A 12.2: Udvidelse af lokal nøgle er en problemfri operation uden behov for ekstern konfiguration.
• Sp 12.3: Hvordan håndteres udvidelse med fjernstyring af nøgler?
  A 12.3: Fjernnøgleudvidelse kræver låsetrin med certifikater/nøgleadministrationsinfrastruktur:
  • Der kræves certifikater for at tilføje ny node sikkert
  • Implementeringen vil vise en advarsel med trin til at fortsætte, herunder et link til certifikatdownload
  • Brugeren følger trinene for at uploade certifikater og prøver derefter implementeringen igen

Understøttende dokumenter

Micron:

• https://www.micron.com/about/blogs/2016/may/selfencrypting-drives-understanding-the-strategy-of-security
• https://www.micron.com/~/media/documents/products/technical-marketing-brief/5100_sed_tcg-e_tech_brief.pdf
• https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2667.pdf
• https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2382.pdf

FIPS

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

CDETS:

• Projekt: CSC.nuova Produkt: ucs-blade-server Komponent: ucsm

SED funktionel specifikation:

• EDCS: 1574090

SED CIMC-specifikation:

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

Postlister:

• ucsm-dev@cisco.com
• ask-hci-tme@cisco.com
• ask-hci-pm@cisco.com

Dokumenter/ressourcer

CISCO HyperFlex HX Data Platform [pdf] Instruktioner HyperFlex HX Data Platform, HyperFlex, HX Data Platform, Data Platform, Platform

Referencer

• Brugermanual