CISCO HyperFlex HX Data Platform Instruksies

CISCO HyperFlex HX Data Platform

Produk inligting

• Produk Naam: HX Sekuriteit Enkripsie
• Weergawe: HXDP 5.01b
• Enkripsie oplossing: Sagteware-gebaseerde oplossing met behulp van Intersight Key Manager
• Enkripsie Tipe: Self-enkripteer aandrywers (SED's)
• Ondersteunde Drive Tipes: HDD en SSD SED's van Micron
• Voldoeningstandaarde: FIPS 140-2 vlak 2 (aandrywingvervaardigers) en FIPS 140-2 vlak 1 (platform)
• Troswye enkripsie: Enkripsie op HX word in hardeware geïmplementeer vir data in rus slegs deur gebruik te maak van SED's
• Individuele VM-enkripsie: Hanteer deur derdeparty-sagteware soos Hytrust of Vormetric se deursigtige kliënt
• VMware Native VM Encryption: Ondersteun deur HX vir gebruik met SED-enkripsie
• Sleutelbestuur: Media-enkripsiesleutel (MEK) en Sleutel-enkripsiesleutel (KEK) word vir elke SED gebruik
• Geheuegebruik: Enkripsiesleutels is nooit in nodusgeheue teenwoordig nie
• Prestasie-impak: Skyfkodering/dekripsie word in die hardeware van die aandrywer hanteer, algehele stelselwerkverrigting word nie beïnvloed nie
• Bykomende voordele van SED's:
  • Onmiddellike kriptografiese uitwissing vir verminderde dryfaftrede en herontplooiingskoste
  • Voldoening aan regerings- of industrieregulasies vir dataprivaatheid
  • Verminderde risiko van skyfdiefstal en nodusdiefstal aangesien data onleesbaar word sodra hardeware verwyder is

Produkgebruiksinstruksies

Om HX Security Encryption te gebruik, volg hierdie instruksies:

1. Maak seker dat jou stelsel hardeware-gebaseerde enkripsie ondersteun of dat jy die sagteware-gebaseerde oplossing verkies wat Intersight Key Manager gebruik.
2. Verwys na die administrasiedokumente of witskrif(te) vir inligting oor sagteware-gebaseerde enkripsie.
3. As jy kies om hardeware-gebaseerde enkripsie met SED's te gebruik, maak seker dat jou HX-kluster uit eenvormige nodusse (SED's of nie-SED's) bestaan.
4. Vir SED's, verstaan ​​dat daar twee sleutels in gebruik is: die Media Encryption Key (MEK) en die Key Encryption Key (KEK).
5. Die MEK beheer die enkripsie en dekripsie van die data na die skyf en word in hardeware beveilig en bestuur.
6. Die KEK beveilig die MEK/DEK en word in 'n plaaslike of afgeleë sleutelstoor onderhou.
7. Moenie bekommerd wees dat die sleutels in die nodusgeheue teenwoordig is nie, aangesien enkripsiesleutels nooit daar gestoor word nie.
8. Let daarop dat skyf-enkripsie/dekripsie in die aandrywer-hardeware hanteer word, om te verseker dat algehele stelselwerkverrigting nie geraak word nie.
9. As jy spesifieke vereistes het vir voldoeningstandaarde, wees bewus daarvan dat HX SED-geënkripteerde aandrywers voldoen aan FIPS 140-2 vlak 2-standaarde van die aandrywingvervaardigers, terwyl HX Encryption op die platform voldoen aan FIPS 140-2 vlak 1-standaarde.
10. As jy individuele VM's moet enkripteer, oorweeg dit om derdeparty-sagteware soos Hytrust of Vormetric se deursigtige kliënt te gebruik. Alternatiewelik kan u VMware se inheemse VM-enkripsie gebruik wat in vSphere 3 bekendgestel is.
11. Hou in gedagte dat die gebruik van 'n VM-enkripsiekliënt bo-op HX SED-gebaseerde enkripsie tot dubbele enkripsie van die data sal lei.
12. Maak seker dat jou HX-groepering deur betroubare netwerke of geënkripteerde tonnels gekoppel is vir veilige replikasie, aangesien HX-replikasie nie geïnkripteer is nie.

HX Sekuriteit Enkripsie Gereelde Vrae

Vanaf HXDP 5.01b bied HyperFlex 'n sagteware-gebaseerde oplossing wat Intersight Key Manager gebruik vir stelsels wat óf nie hardeware-gebaseerde enkripsie ondersteun nie óf vir gebruikers wat hierdie funksionaliteit oor hardeware-oplossings verlang. Hierdie algemene vrae fokus slegs op SED-gebaseerde hardeware-oplossings vir HX-enkripsie. Sien die administrasiedokumente of witskrif(te) vir inligting oor sagteware-gebaseerde enkripsie.

Vooroordeelverklaring
Die dokumentasiestel vir hierdie produk streef daarna om vooroordeelvrye taal te gebruik. Vir doeleindes van hierdie dokumentasiestel word vooroordeelvry gedefinieer as taal wat nie diskriminasie impliseer op grond van ouderdom, gestremdheid, geslag, rasse-identiteit, etniese identiteit, seksuele oriëntasie, sosio-ekonomiese status en interseksionaliteit nie. Uitsonderings kan teenwoordig wees in die dokumentasie as gevolg van taal wat hardkodeer is in die gebruikerskoppelvlakke van die produksagteware, taal wat gebruik word op grond van standaarddokumentasie, of taal wat gebruik word deur 'n verwysde derdepartyproduk.

Waarom Cisco vir sekuriteit en HX-enkripsie 

• V 1.1: Watter prosesse is in plek vir veilige ontwikkeling?
  A 1.1: Cisco-bedieners voldoen aan Cisco Secure Development Lifecycle (CSDL):
  • Cisco verskaf prosesse, metodologieë, raamwerke om ingebedde sekuriteit op Cisco-bedieners te ontwikkel, nie net 'n oorleg nie
  • Toegewyde Cisco-span vir bedreigingsmodellering/statiese analise op UCS-produkportefeulje
  • Cisco Advanced Security Initiative Group (ASIG) voer proaktiewe penetrasietoetse uit om te verstaan ​​hoe bedreigings inkom en probleme reg te stel deur HW & SW te verbeter deur CDETS en ingenieurswese
  • Toegewyde Cisco-span om uitgaande kwesbaarheid te toets en te hanteer en as sekuriteitsadviseurs aan kliënte te kommunikeer
  • Alle onderliggende produkte gaan deur produksekuriteit basislynvereistes (PSB) wat sekuriteitstandaarde vir Cisco-produkte beheer
  • Cisco voer kwesbaarheids-/protokol-robuustheidstoetse op alle UCS-vrystellings uit
• V 1.2: Hoekom is SED's belangrik?
  A 1.2: SED's word gebruik vir data-in-rus-enkripsie en is 'n vereiste vir baie, indien nie alle nie, federale, mediese en finansiële instellings.

Algemene inligting verbyview

• V 2.1: Wat is SED's?
  A 2.1: SED (Self-Encrypting Drives) het spesiale hardeware wat inkomende data enkripteer en uitgaande data intyds dekripteer.
• V 2.2: Wat is die omvang van enkripsie op HX?
  A 2.2: Enkripsie op HX word tans in hardeware geïmplementeer vir data in rus slegs deur gebruik te maak van geënkripteerde aandrywers (SED's). HX-enkripsie is groepwyd. Individuele VM-enkripsie word deur derdeparty-sagteware soos Hytrust of Vormetric se deursigtige kliënt hanteer en is buite die bestek van HX-verantwoordelikhede. HX ondersteun ook die gebruik van VMware se inheemse VM-enkripsie wat in vSphere 3 bekendgestel is. Gebruik van 'n VM-enkripsiekliënt bo-op HX SED-gebaseerde enkripsie sal tot dubbele enkripsie van die data lei. HX-replikasie is nie geïnkripteer nie en maak staat op vertroude netwerke of geënkripteerde tonnels wat deur die eindgebruiker ontplooi word.
• V 2.3: Aan watter voldoeningstandaarde word met HX-enkripsie voldoen?
  A 2.3: HX SED-geënkripteerde aandrywers voldoen aan FIPS 140-2 vlak 2-standaarde van die aandrywingvervaardigers. HX-enkripsie op die platform voldoen aan FIPS 140-2 vlak 1-standaarde.
• V 2.4: Ondersteun ons beide HDD en SSD vir enkripsie?
  A 2.4: Ja, ons ondersteun beide HDD en SSD SED's van Micron.
• V 2.5: Kan 'n HX-kluster gelyktydig geïnkripteer en nie-geënkripteerde aandrywers hê?
  A 2.5: Alle nodusse in groepering moet uniform wees (SED's of nie-SED's)
• V 2.6: Watter sleutels word vir 'n SED gebruik en hoe word dit gebruik?
  A 2.6: Daar is twee sleutels in gebruik vir elke SED. Die Media Encryption Key (MEK) ook genoem die Disk Encryption Key (DEK), beheer enkripsie en dekripsie van die data na die skyf en word in hardeware beveilig en bestuur. Die Sleutel-enkripsiesleutel (KEK) beveilig die DEK/MEK en word in óf 'n plaaslike óf 'n afgeleë sleutelstoor onderhou.
• V 2.7: Is die sleutels ooit in die geheue teenwoordig?
  A 2.7: Enkripsiesleutels is nooit in nodusgeheue teenwoordig nie
• V 2.8: Hoe word prestasie deur die enkripsie-/dekripsieproses beïnvloed?
  A 2.8: Skyf-enkripsie/dekripsie word in die hardeware van die aandrywer hanteer. Algehele stelselprestasie word nie geraak nie en is nie onderhewig aan aanvalle wat ander komponente van die stelsel teiken nie
• V 2.9: Behalwe enkripsie in rus, wat is ander redes om SED's te gebruik?
  A 2.9: SED's kan aftree- en herontplooiingskoste verminder deur onmiddellike kriptografiese uitvee. Hulle dien ook om te voldoen aan regerings- of industrieregulasies vir dataprivaatheid. Nog 'n advantage is die verminderde risiko van skyfdiefstal en nodusdiefstal aangesien die data, sodra die hardeware uit die ekosisteem verwyder is, onleesbaar is.
• V2.10: Wat gebeur met deduplisering en kompressie met SED's? Wat gebeur met derdeparty-sagteware-gebaseerde enkripsie?
  A2.10: Deduplisering en kompressie met SED's op HX word gehandhaaf aangesien die data in rus enkripsie as 'n laaste stap in die skryfproses plaasvind. Deduplisering en kompressie het reeds plaasgevind. Met derdeparty-sagteware-gebaseerde enkripsieprodukte bestuur die VM's hul enkripsie en gee geënkripteerde skrywes aan die hipervisor en daarna HX deur. Aangesien hierdie skrywes reeds geënkripteer is, word hulle nie gededupliseer of saamgepers nie. HX-sagteware-gebaseerde enkripsie (in die 3.x-kodelyn) sal 'n sagteware-enkripsie-oplossing wees wat in die stapel geïmplementeer word nadat skryfoptimerings (deduplisering en kompressie) plaasgevind het, so die voordeel sal in daardie geval behou word.

Die figuur hieronder is 'n verbyview van die implementering van SED met HX.

Drive Besonderhede 

• V 3.1: Wie vervaardig die geënkripteerde aandrywers wat in HX gebruik word?
  A 3.1: HX gebruik aandrywers wat deur Micron vervaardig word: Mikron-spesifieke dokumente word in die ondersteunende dokumente-afdeling van hierdie Gereelde Vrae gekoppel.
• V 3.2: Ondersteun ons enige SED's wat nie FIPS voldoen nie?
  A 3.2: Ons ondersteun ook sommige aandrywers wat nie-FIPS is nie, maar ondersteun SED (TCGE).
• V 3.3: Wat is die TCG?
  A 3.3: TCG is die Trusted Computing Group, wat die spesifikasiestandaard vir geënkripteerde databerging skep en bestuur
• V 3.4: Wat word beskou as ondernemingsklas-sekuriteit wanneer dit kom by SAS SSD's vir die datasentrum? Watter spesifieke kenmerke het hierdie aandrywers wat sekuriteit verseker en teen aanvalle beskerm?
  A 3.4: Hierdie lys gee 'n opsomming van die ondernemingsklas-kenmerke van die SED's wat in HX gebruik word en hoe dit verband hou met die TCG-standaard.
  1. Self-enkripteer-aandrywers (SED's) bied sterk sekuriteit vir data wat op jou SED rus, wat ongemagtigde datatoegang voorkom. Die Trusted Computing Group (TCG) het 'n lys van die kenmerke en voordele van self-enkripteer-aandrywers vir beide HDD's en SSD's ontwikkel. Die TCG verskaf 'n standaard wat die TCG Enterprise SSC (Security Subsystem Class) genoem word en is gefokus op data in rus. Dit is 'n vereiste vir alle SED's. Die spesifikasie is van toepassing op databergingstoestelle en beheerders wat in ondernemingberging werk. Die lys sluit in:
     • Deursigtigheid: Geen stelsel- of toepassingswysigings benodig nie; enkripsiesleutel gegenereer deur die aandrywer self, met behulp van 'n ware ewekansige getalgenerator aan boord; drive is altyd besig om te enkripteer.
     • Gemak van bestuur: Geen enkripsiesleutel om te bestuur nie; Sagtewareverkopers ontgin gestandaardiseerde koppelvlak om SED's te bestuur, insluitend afstandbestuur, voorlaai-verifikasie en wagwoordherwinning
     • Weggooi- of herbestemmingskoste: Met 'n SED, vee aan boord enkripsiesleutel uit
     • Herenkripsie: Met SED is dit nie nodig om die data ooit weer te enkripteer nie
     • Prestasie: Geen agteruitgang in SED-prestasie nie; hardeware-gebaseerde
     • Standaardisering: Die hele aandrywingbedryf bou volgens die TCG/SED-spesifikasies
     • Vereenvoudig: Geen inmenging met stroomop-prosesse nie
  2. SSD SED's bied die vermoë om die skyf kriptografies uit te vee. Dit beteken dat 'n eenvoudige geverifieerde opdrag na die skyf gestuur kan word om die 256-bis-enkripsiesleutel wat op die skyf gestoor is, te verander. Dit verseker dat die skyf skoongevee word en dat daar geen data oor is nie. Selfs die oorspronklike gasheerstelsel kan nie die data lees nie, so dit sal absoluut onleesbaar wees deur enige ander stelsel. Die operasie neem net 'n paar sekondes, in teenstelling met die baie minute of selfs ure wat dit neem om 'n analoog operasie op 'n ongeënkripteerde HDD uit te voer en vermy die koste van duur HDD-ontgassingtoerusting of -dienste.
  3. FIPS (Federal Information Processing Standard) 140-2 is 'n Amerikaanse regeringstandaard wat die enkripsie en verwante sekuriteitsvereistes beskryf waaraan IT-produkte moet voldoen vir sensitiewe, maar ongeklassifiseerde, gebruik. Dit is dikwels ook 'n vereiste vir regeringsagentskappe en maatskappye in die finansiëledienste- en gesondheidsorgbedrywe. 'n SSD wat FIPS-140-2-gevalideer is, gebruik sterk sekuriteitspraktyke, insluitend goedgekeurde enkripsiealgoritmes. Dit spesifiseer ook hoe individue of ander prosesse gemagtig moet word om die produk te gebruik, en hoe modules of komponente ontwerp moet word om veilige interaksie met ander stelsels te hê. Trouens, een van die vereistes van 'n FIPS-140-2-gevalideerde SSD-aandrywer is dat dit 'n SED is. Hou in gedagte dat alhoewel TCG nie die enigste manier is om 'n gesertifiseerde geënkripteerde aandrywer te kry nie, die TCG Opal en Enterprise SSC spesifikasies ons 'n stap vir FIPS-bekragtiging bied. 4. Nog 'n noodsaaklike kenmerk is Veilige aflaaie en diagnose. Hierdie firmware-funksie beskerm die skyf teen sagteware-aanvalle deur 'n digitale handtekening wat in die firmware ingebou is. Wanneer aflaaie nodig is, verhoed die digitale handtekening ongemagtigde toegang tot die skyf, wat verhoed dat vervalste firmware na die skyf gelaai word.

Hyperflex installeer met SED's

• V 4.1: Hoe hanteer die installeerder 'n SED-ontplooiing? Is daar enige spesiale tjeks?
  A 4.1: Die installeerder kommunikeer met UCSM en verseker dat stelselfirmware korrek is en ondersteun word vir die bespeurde hardeware. Enkripsieversoenbaarheid word nagegaan en afgedwing (bv. geen vermenging van SED en nie-SED nie).
• V 4.2: Is die ontplooiing anders anders?
  A 4.2: Die installering is soortgelyk aan 'n gewone HX-installasie, maar pasgemaakte werkvloei word nie vir SED's ondersteun nie. Hierdie operasie vereis ook UCSM-bewyse vir die SED's.
• V 4.3: Hoe werk lisensiëring met enkripsie? Is daar iets ekstra wat in plek moet wees?
  A 4.3: SED-hardeware (bestel vanaf die fabriek, nie retrofit nie) + HXDP 2.5 + UCSM (3.1(3x)) is die enigste dinge wat nodig is om enkripsie met sleutelbestuur moontlik te maak. Daar is geen bykomende lisensiëring buite die basis HXDP-intekening wat in die 2.5-weergawe vereis word nie.
• V 4.4: Wat gebeur as ek 'n SED-stelsel het wat aandrywers het wat nie meer beskikbaar is nie? Hoe kan ek hierdie groep uitbrei?
  A 4.4: Wanneer ons enige PID wat einde-van-lewe van ons verskaffers het, het ons 'n vervanging PID wat versoenbaar is met die ou PID. Hierdie vervangings-PID kan gebruik word vir RMA, uitbreiding binne 'n nodus en uitbreiding van groepering (met nuwe nodusse). Alle metodes word almal ondersteun, maar dit kan egter opgradering vereis na 'n spesifieke vrystelling wat ook in die oorgangsvrystellingsnotas geïdentifiseer word.

Sleutelbestuur

• V 5.1: Wat is sleutelbestuur?
  A 5.1: Sleutelbestuur is die take betrokke by die beskerming, berging, rugsteun en organisering van enkripsiesleutels. HX implementeer dit in 'n UCSM-gesentreerde beleid.
• V 5.2: Watter meganisme bied ondersteuning vir sleutelkonfigurasie?
  A 5.2: UCSM bied ondersteuning om sekuriteitsleutels op te stel.
• V 5.3: Watter tipe sleutelbestuur is beskikbaar?
  A 5.3: Plaaslike bestuur van sleutels word ondersteun, saam met ondernemingklas afstandsleutelbestuur met derdeparty-sleutelbestuurbedieners.
• V 5.4: Wie is die afgeleë sleutelbestuurvennote?
  A 5.4: Ons ondersteun tans Vormetric en Gemalto (Safenet) en sluit hoë beskikbaarheid (HA) in. HyTrust is besig om te toets.
• V 5.5: Hoe word afstandsleutelbestuur geïmplementeer?
  A 5.5: Afgeleë sleutelbestuur word via KMIP 1.1 hanteer.
• V 5.6: Hoe word plaaslike bestuur opgestel?
  A 5.6: Die sekuriteitsleutel (KEK) word in HX Connect gekonfigureer, direk deur die gebruiker.
• V 5.7: Hoe word afstandbestuur opgestel?
  A 5.7: Die afstandsleutelbestuur (KMIP)-bedieneradresinligting saam met aanmeldbewyse word deur die gebruiker in HX Connect opgestel.
• V 5.8: Watter deel van HX kommunikeer met die KMIP-bediener vir konfigurasie?
  A 5.8: Die CIMC op elke nodus gebruik hierdie inligting om aan die KMIP-bediener te koppel en die sekuriteitsleutel (KEK) daaruit te haal.
  
• V 5.9: Watter tipe sertifikate word ondersteun in die sleutelgenerering/herwinning/bywerkingsproses?
  A 5.9: CA-getekende en self-ondertekende sertifikate word albei ondersteun.
  
• V 5.10: Watter werkvloeie word met die enkripsieproses ondersteun?
  A 5.10: Beskerm/ontskerm met 'n pasgemaakte wagwoord word ondersteun saam met plaaslike na afgeleë sleutelbestuuromskakeling. Hersleutelbewerkings word ondersteun. Veilige skyfvee-operasie word ook ondersteun.
  

Gebruikerswerkvloei: Plaaslik

• V 6.1: Waar stel ek plaaslike sleutelbestuur op in HX Connect?
  A 6.1: Kies die konfigurasieknoppie in die Enkripsie-kontroleskerm en volg die towenaar.
• V 6.2: Wat moet ek gereed hê om te begin?
  A 6.2: Jy sal 'n sekuriteitswagfrase van 32 karakters moet verskaf.
• V 6.3: Wat gebeur as ek 'n nuwe SED moet invoeg?
  'n 6.3: In UCSM sal jy die plaaslike sekuriteitsbeleid moet wysig en die ontplooide sleutel op die bestaande nodussleutel stel.
• V 6.4: Wat gebeur wanneer ek die nuwe skyf insit?
  A 6.4: As die sekuriteitsleutel op die skyf ooreenstem met dié van die bediener (nodus) word dit outomaties ontsluit. As die sekuriteitsleutels anders is, sal die skyf as 'n "Gesluit" wys. Jy kan óf die skyf uitvee om alle data uit te vee óf dit ontsluit deur die korrekte sleutel te verskaf. Dit is 'n goeie tyd om TAC te betrek.

Gebruikerswerkvloei: afstandbeheer

• V 7.1: Wat is 'n paar dinge waarvoor ek moet oppas met afstandsleutelbestuurkonfigurasie?
  A 7.1: Kommunikasie tussen die groepering en die KMIP-bediener(s) vind plaas oor die CIMC op elke nodus. Dit beteken dat die gasheernaam slegs vir KMIP-bediener gebruik kan word as die binneband-IP-adres en DNS op die CIMC-bestuur opgestel is
• V 7.2: Wat gebeur as ek 'n nuwe SED moet vervang of invoeg?
  A 7.2: Die groep sal die identifiseerder vanaf die skyf lees en probeer om dit outomaties te ontsluit. As outomatiese ontsluiting misluk, verskyn die skyf as "gesluit" en die gebruiker moet die skyf met die hand ontsluit. Jy sal die sertifikate na KMIP-bediener(s) moet kopieer vir geloofsbriewe.
• V 7.3: Hoe kopieer ek sertifikate van die groep na die KMIP-bediener(s)?
  A 7.3: Daar is twee maniere om dit te doen. Jy kan die sertifikaat direk vanaf die BMC na KMIP-bediener kopieer of jy kan die CSR gebruik om 'n CA-getekende sertifikaat te kry en die CA-getekende sertifikaat na die BMC kopieer deur UCSM-opdragte te gebruik.
• V 7.4: Watter oorwegings is daar vir die byvoeging van geënkripteerde nodusse by 'n groepering wat afstandsleutelbestuur gebruik?
  A 7.4: Wanneer nuwe gashere by die KMIP-bediener(s) gevoeg word, moet die gasheernaam wat gebruik word die reeksnommer van die bediener wees. Om die KMIP-bediener se sertifikaat te kry, kan jy 'n blaaier gebruik om die wortelsertifikaat van die KMIP-bediener(s) te kry.

Gebruikerswerkvloei: Algemeen

• V 8.1: Hoe vee ek 'n skyf uit?
  A 8.1: Kies die stelselinligting in die HX Connect-kontroleskerm view. Van daar af kan jy individuele skywe kies vir veilige uitvee.
• V 8.2: Wat as ek 'n skyf per ongeluk uitgevee het?
  A 8.2: Wanneer veilige uitvee gebruik word, word die data permanent vernietig
• V 8.3: Wat gebeur wanneer ek 'n nodus wil uitskakel of 'n diensprof wil dissosieerfile?
  A 8.3: Geen van hierdie aksies sal die enkripsie op die skyf/beheerder verwyder nie.
• V 8.4: Hoe word enkripsie gedeaktiveer?
  A 8.4: Die gebruiker moet enkripsie uitdruklik in HX Connect deaktiveer. As die gebruiker probeer om 'n sekuriteitsbeleid in UCSM uit te vee wanneer die geassosieerde bediener beveilig is, sal UCSM 'n konfigurasie-fout vertoon en die aksie verbied. Die sekuriteitsbeleid moet eers gedeaktiveer word.

Gebruikerswerkvloei: Sertifikaatbestuur

• V 9.1: Hoe word sertifikate tydens afstandbestuuropstelling hanteer?
  A 9.1: Sertifikate word geskep deur HX Connect en die afgeleë KMIP-bediener(s) te gebruik. Sertifikate wat eers geskep is, sal byna nooit uitgevee word nie.
• V 9.2: Watter soort sertifikate kan ek gebruik?
  A 9.2: Jy kan óf self-ondertekende sertifikate óf CA-sertifikate gebruik. Jy moet kies tydens opstelling. Vir CA-ondertekende sertifikate sal jy 'n stel sertifikaatondertekeningversoeke (CSR'e) genereer. Die ondertekende sertifikate word na die KMIP-bediener(s) opgelaai.
• V 9.3: Watter gasheernaam moet ek gebruik wanneer ek die sertifikate genereer?
  A 9.3: Die gasheernaam wat gebruik word om die sertifikaat te genereer, moet die reeksnommer van die bediener wees.

Firmware-opdaterings

• V 10.1: Is daar enige beperkings op die opgradering van die skyffirmware?
  A 10.1: As 'n enkripsie-geskikte aandrywer bespeur word, sal enige skyffirmwareveranderinge nie vir daardie skyf toegelaat word nie.
• V 10.2: Is daar enige beperkings op die opgradering van UCSM-firmware?
  A 10.2: Afgradering van UCSM/CIMC na pre-UCSM 3.1(3x) word beperk as daar 'n beheerder is wat in 'n veilige toestand is.

Veilige Vee Besonderhede uit

• V 11.1: Wat is Veilige Erase?
  A 11.1: Veilige uitvee is onmiddellike uitvee van data op die skyf (vee van die skyf-enkripsiesleutel uit). Dit beteken dat 'n eenvoudige geverifieerde opdrag na die skyf gestuur kan word om die 256-bis-enkripsiesleutel wat op die skyf gestoor is, te verander. Dit verseker dat die skyf skoongevee word en dat daar geen data oor is nie. Selfs die oorspronklike gasheerstelsel kan nie die data lees nie, so dit sal onleesbaar wees deur enige ander stelsel. Die operasie neem slegs 'n paar sekondes, in teenstelling met die baie minute of selfs ure wat dit neem om 'n analoog operasie op 'n ongeënkripteerde skyf uit te voer en vermy die koste van duur ontmagnetiseringstoerusting of -dienste.
• V 11.2: Hoe word veilige uitvee uitgevoer?
  A 11.2: Dit is 'n GUI-bewerking wat een aandrywer op 'n slag uitgevoer word.
• V 11.3: Wanneer word veilige uitvee gewoonlik uitgevoer?
  A 11.3: Gebruiker-geïnisieerde veilige uitvee van 'n enkele skyf is 'n seldsame operasie. Dit word meestal gedoen wanneer jy die skyf fisies wil verwyder vir vervanging, dit na 'n ander nodus wil oordra, of nabye toekomstige mislukking wil vermy.
• V 11.4: Watter beperkings is daar op veilige uitvee?
  A 11.4: Veilige uitveebewerkings kan slegs uitgevoer word as die groep gesond is om te verseker dat die foutveerkragtigheid van die groep nie beïnvloed word nie.
• V 11.5: Wat gebeur as ek 'n hele nodus moet verwyder?
  A 11.5: Daar is nodus verwyder en node vervang werkvloei om veilige uitvee van alle aandrywers te ondersteun. Sien die administrasiegids vir besonderhede of raadpleeg Cisco TAC.
• V 11.6: Kan 'n veilig uitgevee skyf hergebruik word?
  A 11.6: 'n Skyf wat veilig uitgevee is, kan slegs in 'n ander groep hergebruik word. Die veilige uitvee van die SED word gedoen deur die skyf-enkripsiesleutel (DEK) uit te vee. Die data in die skyf kan nie sonder DEK gedekripteer word nie. Dit laat jou toe om die skyf te hergebruik of uit diens te stel sonder enige kompromie van die data.
• V 11.7: Wat gebeur as die skyf wat ek wil uitvee die laaste primêre kopie van groepdata bevat?
  A 11.7: Die data op die skyf moet ander kopieë in die groep hê om dataverlies te voorkom. As veilige uitvee egter versoek word op 'n skyf wat die laaste primêre kopie is, sal hierdie bewerking verwerp word totdat daar ten minste een meer kopie beskikbaar is. Herbalanseer behoort hierdie kopie op die agtergrond te maak.
• V 11.8: Ek moet regtig 'n skyf veilig uitvee, maar die groep is nie gesond nie. Hoe kan ek dit doen?
  A 11.8: Die opdragreël (STCLI/HXCLI) sal veilige uitvee toelaat wanneer die groep nie gesond is nie en die skyf nie die laaste primêre kopie bevat nie, anders word dit nie toegelaat nie.
• V 11.9: Hoe kan ek 'n hele nodus veilig uitvee?
  A 11.9: Dit is 'n seldsame scenario. Veilige uitvee van alle skywe in 'n nodus word gedoen wanneer 'n mens die nodus uit die groep wil haal. Die bedoeling is óf om die knoop in 'n ander groepering te ontplooi óf om die knoop uit te skakel. Ons kan nodusverwydering in hierdie scenario op twee verskillende maniere klassifiseer:
  1. Vee al die skywe veilig uit sonder om enkripsie te deaktiveer
  2. Vee al die skywe veilig uit, gevolg deur die deaktivering van enkripsie vir daardie nodus (en skywe). Kontak asseblief Cisco TAC vir bystand.

Veilige uitbreiding van 'n groep

• V 12.1: Met watter soort nodus kan ek 'n geënkripteerde groep uitbrei?
  A 12.1: Slegs SED-geskikte nodusse kan by 'n HX Cluster met SED's gevoeg word.
• V 12.2: Hoe word uitbreiding met plaaslike sleutelbestuur hanteer?
  A 12.2: Plaaslike sleuteluitbreiding is 'n naatlose operasie met geen eksterne konfigurasie nodig nie.
• V 12.3: Hoe word uitbreiding met afstandsleutelbestuur hanteer?
  A 12.3: Sleuteluitbreiding op afstand vereis sluitstap met sertifikate/sleutelbestuurinfrastruktuur:
  • Sertifikate word vereis om nuwe nodus veilig by te voeg
  • Die ontplooiing sal 'n waarskuwing wys met stappe om voort te gaan, insluitend 'n skakel vir sertifikaataflaai
  • Die gebruiker volg stappe om sertifikaat(e) op te laai en probeer dan weer die ontplooiing

Ondersteunende dokumente

Mikron:

• 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

• Lys van kripto-algoritmes wat goedgekeur is vir FIPS 140-2: https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf

CDETS:

• Projek: CSC.nuova Produk: ucs-blade-server Komponent: ucsm

SED funksionele spesifikasie:

• EDCS: 1574090

SED CIMC spesifikasie:

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

Poslyste:

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