ແພລດຟອມຂໍ້ມູນ CISCO HyperFlex HX

ຂໍ້ມູນຜະລິດຕະພັນ

• ຊື່ຜະລິດຕະພັນ: ການເຂົ້າລະຫັດຄວາມປອດໄພ HX
• ລຸ້ນ: HXDP 5.01b
• ການແກ້ໄຂການເຂົ້າລະຫັດ: ການແກ້ໄຂໂດຍອີງໃສ່ຊອບແວໂດຍໃຊ້ Intersight Key Manager
• ປະເພດການເຂົ້າລະຫັດ: Drives ການເຂົ້າລະຫັດຕົນເອງ (SEDs)
• ປະເພດ Drive ທີ່ຮອງຮັບ: HDD ແລະ SSD SEDs ຈາກ Micron
• ມາດຕະຖານການປະຕິບັດຕາມ: FIPS 140-2 ລະດັບ 2 (ຜູ້ຜະລິດຂັບ) ແລະ FIPS 140-2 ລະດັບ 1 (ເວທີ)
• ການເຂົ້າລະຫັດກຸ່ມກວ້າງ: ການເຂົ້າລະຫັດໃນ HX ແມ່ນຖືກປະຕິບັດຢູ່ໃນຮາດແວສໍາລັບຂໍ້ມູນໃນເວລາທີ່ພັກຜ່ອນພຽງແຕ່ນໍາໃຊ້ SEDs
• ການເຂົ້າລະຫັດ VM ສ່ວນບຸກຄົນ: ຈັດການໂດຍຊອບແວພາກສ່ວນທີສາມເຊັ່ນ: Hytrust ຫຼືລູກຄ້າໂປ່ງໃສຂອງ Vormetric
• ການເຂົ້າລະຫັດ VM ເດີມ VMware: ສະຫນັບສະຫນູນໂດຍ HX ສໍາລັບການນໍາໃຊ້ກັບການເຂົ້າລະຫັດ SED
• ການຈັດການທີ່ ສຳ ຄັນ: Media Encryption Key (MEK) ແລະ Key Encryption Key (KEK) ແມ່ນໃຊ້ສໍາລັບແຕ່ລະ SED
• ການນຳໃຊ້ໜ່ວຍຄວາມຈຳ: ກະແຈການເຂົ້າລະຫັດບໍ່ເຄີຍມີຢູ່ໃນຫນ່ວຍຄວາມຈໍາຂອງ node
• ຜົນກະທົບດ້ານປະສິດທິພາບ: ການ​ເຂົ້າ​ລະ​ຫັດ/ຖອດ​ລະ​ຫັດ​ດິ​ສ​ກ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ຈັດ​ການ​ໃນ​ຮາດ​ແວ​ຂັບ, ການ​ປະ​ຕິ​ບັດ​ຂອງ​ລະ​ບົບ​ໂດຍ​ລວມ​ບໍ່​ໄດ້​ຮັບ​ຜົນ​ກະ​ທົບ
• ຜົນປະໂຫຍດເພີ່ມເຕີມຂອງ SEDs:
  • ການລຶບລະຫັດລັບໃນທັນທີເພື່ອຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການບໍານານຂອງໄດ ແລະການໃຊ້ຄືນໃຫມ່
  • ການປະຕິບັດຕາມກົດລະບຽບຂອງລັດຖະບານຫຼືອຸດສາຫະກໍາສໍາລັບຄວາມເປັນສ່ວນຕົວຂອງຂໍ້ມູນ
  • ຫຼຸດຜ່ອນຄວາມສ່ຽງຕໍ່ການລັກແຜ່ນດິສກ໌ ແລະການລັກຂະໂມຍໂນດ ເນື່ອງຈາກຂໍ້ມູນບໍ່ສາມາດອ່ານໄດ້ເມື່ອຮາດແວຖືກຖອດອອກ

ຄໍາແນະນໍາການນໍາໃຊ້ຜະລິດຕະພັນ

ເພື່ອໃຊ້ HX Security Encryption, ປະຕິບັດຕາມຄໍາແນະນໍາເຫຼົ່ານີ້:

1. ໃຫ້​ແນ່​ໃຈວ່​າ​ລະ​ບົບ​ຂອງ​ທ່ານ​ສະ​ຫນັບ​ສະ​ຫນູນ​ການ​ເຂົ້າ​ລະ​ຫັດ​ທີ່​ອີງ​ໃສ່​ຮາດ​ແວ​ຫຼື​ວ່າ​ທ່ານ​ຕ້ອງ​ການ​ການ​ແກ້​ໄຂ​ຊອບ​ແວ​ໂດຍ​ການ​ນໍາ​ໃຊ້ Intersight Key Manager​.
2. ອ້າງອີງໃສ່ເອກະສານບໍລິຫານ ຫຼືເຈ້ຍຂາວສຳລັບຂໍ້ມູນກ່ຽວກັບການເຂົ້າລະຫັດຊອບແວ.
3. ຖ້າທ່ານເລືອກທີ່ຈະໃຊ້ການເຂົ້າລະຫັດແບບຮາດແວກັບ SEDs, ໃຫ້ແນ່ໃຈວ່າ HX cluster ຂອງທ່ານປະກອບດ້ວຍ nodes ເອກະພາບ (SEDs ຫຼືບໍ່ແມ່ນ SEDs).
4. ສໍາລັບ SEDs, ເຂົ້າໃຈວ່າມີສອງກະແຈທີ່ໃຊ້: ລະຫັດການເຂົ້າລະຫັດສື່ (MEK) ແລະກະແຈການເຂົ້າລະຫັດລັບ (KEK).
5. MEK ຄວບຄຸມການເຂົ້າລະຫັດແລະການຖອດລະຫັດຂອງຂໍ້ມູນໃສ່ແຜ່ນແລະຖືກຮັກສາຄວາມປອດໄພແລະຈັດການໃນຮາດແວ.
6. KEK ຮັບປະກັນ MEK/DEK ແລະຖືກຮັກສາໄວ້ໃນບ່ອນເກັບກະແຈທ້ອງຖິ່ນຫຼືທາງໄກ.
7. ຢ່າກັງວົນກ່ຽວກັບກະແຈທີ່ມີຢູ່ໃນຫນ່ວຍຄວາມຈໍາຂອງ node, ເພາະວ່າກະແຈການເຂົ້າລະຫັດບໍ່ເຄີຍຖືກເກັບໄວ້ຢູ່ທີ່ນັ້ນ.
8. ກະລຸນາຮັບຊາບວ່າການເຂົ້າລະຫັດ/ຖອດລະຫັດດິສກ໌ແມ່ນຖືກຈັດການຢູ່ໃນຮາດແວຂອງໄດຣຟ໌, ຮັບປະກັນວ່າປະສິດທິພາບຂອງລະບົບໂດຍລວມບໍ່ໄດ້ຮັບຜົນກະທົບ.
9. ຖ້າທ່ານມີຂໍ້ກໍານົດສະເພາະສໍາລັບມາດຕະຖານການປະຕິບັດຕາມ, ຈົ່ງຮູ້ວ່າໄດທີ່ເຂົ້າລະຫັດ HX SED ຕອບສະຫນອງມາດຕະຖານ FIPS 140-2 ລະດັບ 2 ຈາກຜູ້ຜະລິດໄດ, ໃນຂະນະທີ່ HX Encryption ໃນເວທີຕອບສະຫນອງມາດຕະຖານ FIPS 140-2 ລະດັບ 1.
10. ຖ້າທ່ານຕ້ອງການເຂົ້າລະຫັດ VMs ສ່ວນບຸກຄົນ, ພິຈາລະນານໍາໃຊ້ຊອບແວພາກສ່ວນທີສາມເຊັ່ນ: Hytrust ຫຼືລູກຄ້າໂປ່ງໃສຂອງ Vormetric. ອີກທາງເລືອກ, ທ່ານສາມາດນໍາໃຊ້ການເຂົ້າລະຫັດ VM ພື້ນເມືອງຂອງ VMware ທີ່ນໍາສະເຫນີໃນ vSphere 3.
11. ຈົ່ງຈື່ໄວ້ວ່າການໃຊ້ລູກຂ່າຍການເຂົ້າລະຫັດ VM ຢູ່ເທິງສຸດຂອງການເຂົ້າລະຫັດ HX SED ຈະເຮັດໃຫ້ມີການເຂົ້າລະຫັດສອງເທົ່າຂອງຂໍ້ມູນ.
12. ໃຫ້ແນ່ໃຈວ່າກຸ່ມ HX ຂອງທ່ານເຊື່ອມຕໍ່ຜ່ານເຄືອຂ່າຍທີ່ເຊື່ອຖືໄດ້ ຫຼືອຸໂມງທີ່ເຂົ້າລະຫັດໄວ້ສໍາລັບການຈໍາລອງທີ່ປອດໄພ, ເນື່ອງຈາກການຈໍາລອງ HX ບໍ່ໄດ້ຖືກເຂົ້າລະຫັດ.

ຄຳຖາມທີ່ຖາມເລື້ອຍໆກ່ຽວກັບການເຂົ້າລະຫັດລັບ HX

ໃນຖານະເປັນຂອງ HXDP 5.01b, HyperFlex ສະຫນອງການແກ້ໄຂຊອບແວໂດຍອີງໃສ່ Intersight Key Manager ສໍາລັບລະບົບທີ່ບໍ່ສະຫນັບສະຫນູນການເຂົ້າລະຫັດທີ່ອີງໃສ່ຮາດແວຫຼືສໍາລັບຜູ້ໃຊ້ທີ່ຕ້ອງການການທໍາງານນີ້ຫຼາຍກວ່າການແກ້ໄຂຮາດແວ. FAQ ນີ້ສຸມໃສ່ການແກ້ໄຂບັນຫາຮາດແວ SED ສໍາລັບການເຂົ້າລະຫັດ HX ເທົ່ານັ້ນ. ເບິ່ງເອກະສານການບໍລິຫານ ຫຼືເຈ້ຍຂາວສຳລັບຂໍ້ມູນກ່ຽວກັບການເຂົ້າລະຫັດຊອບແວ.

ຖະແຫຼງການ Bias
ເອກະສານທີ່ກໍານົດໄວ້ສໍາລັບຜະລິດຕະພັນນີ້ພະຍາຍາມໃຊ້ພາສາທີ່ບໍ່ມີອະຄະຕິ. ສໍາລັບຈຸດປະສົງຂອງເອກະສານສະບັບນີ້, ການບໍ່ມີອະຄະຕິແມ່ນໄດ້ກໍານົດເປັນພາສາທີ່ບໍ່ຫມາຍເຖິງການຈໍາແນກໂດຍອີງໃສ່ອາຍຸ, ຄວາມພິການ, ເພດ, ເຊື້ອສາຍ, ເອກະລັກຊົນເຜົ່າ, ປະຖົມນິເທດທາງເພດ, ສະຖານະພາບເສດຖະກິດສັງຄົມ, ແລະຈຸດຕັດກັນ. ຂໍ້ຍົກເວັ້ນອາດຈະມີຢູ່ໃນເອກະສານເນື່ອງຈາກພາສາທີ່ຖືກ hardcoded ໃນການໂຕ້ຕອບຜູ້ໃຊ້ຂອງຊອບແວຜະລິດຕະພັນ, ພາສາທີ່ໃຊ້ໂດຍອີງໃສ່ເອກະສານມາດຕະຖານ, ຫຼືພາສາທີ່ຖືກນໍາໃຊ້ໂດຍຜະລິດຕະພັນພາກສ່ວນທີສາມອ້າງອີງ.

ເປັນຫຍັງ Cisco ສໍາລັບຄວາມປອດໄພແລະການເຂົ້າລະຫັດ HX 

• ຄໍາຖາມ 1.1: ມີຂະບວນການໃດແດ່ສໍາລັບການພັດທະນາທີ່ປອດໄພ?
  A 1.1: ເຊີບເວີ Cisco ປະຕິບັດຕາມ Cisco Secure Development Lifecycle (CSDL):
  • Cisco ສະໜອງຂະບວນການ, ວິທີການ, ກອບເພື່ອພັດທະນາຄວາມປອດໄພທີ່ຝັງຢູ່ໃນເຊີບເວີ Cisco, ບໍ່ພຽງແຕ່ການວາງຊ້ອນກັນເທົ່ານັ້ນ.
  • ທີມງານ Cisco ອຸທິດຕົນເພື່ອການສ້າງແບບຈໍາລອງໄພຂົ່ມຂູ່ / ການວິເຄາະຄົງທີ່ກ່ຽວກັບຫຼັກຊັບຜະລິດຕະພັນ UCS
  • Cisco Advanced Security Initiative Group (ASIG) ດໍາເນີນການທົດສອບການເຈາະຢ່າງຕັ້ງໜ້າເພື່ອເຂົ້າໃຈວ່າໄພຂົ່ມຂູ່ເຂົ້າມາແນວໃດ ແລະແກ້ໄຂບັນຫາໂດຍການເພີ່ມ HW & SW ຜ່ານ CDETS ແລະວິສະວະກໍາ.
  • ທີມງານ Cisco ອຸທິດຕົນເພື່ອທົດສອບ ແລະຈັດການຊ່ອງໂຫວ່ຂອງຕ່າງປະເທດ ແລະຕິດຕໍ່ສື່ສານເປັນທີ່ປຶກສາດ້ານຄວາມປອດໄພໃຫ້ກັບລູກຄ້າ
  • ຜະລິດຕະພັນທີ່ຕິດພັນທັງໝົດແມ່ນຜ່ານຄວາມຕ້ອງການພື້ນຖານຄວາມປອດໄພຂອງຜະລິດຕະພັນ (PSB) ເຊິ່ງຄວບຄຸມມາດຕະຖານຄວາມປອດໄພຂອງຜະລິດຕະພັນ Cisco
  • Cisco ດໍາເນີນການທົດສອບຄວາມແຂງແຮງຂອງ Vulnerability/Protocol ໃນທຸກລຸ້ນ UCS
• Q 1.2: ເປັນຫຍັງ SEDs ຈຶ່ງມີຄວາມສໍາຄັນ?
  A 1.2: SEDs ຖືກນໍາໃຊ້ສໍາລັບການເຂົ້າລະຫັດຂໍ້ມູນຢູ່ທີ່ພັກຜ່ອນແລະເປັນຂໍ້ກໍານົດສໍາລັບຫຼາຍໆຄົນ, ຖ້າບໍ່ແມ່ນທັງຫມົດ, ລັດຖະບານກາງ, ການແພດ, ແລະສະຖາບັນການເງິນ.

ຂໍ້ມູນທົ່ວໄປຫຼາຍກວ່າview

• Q 2.1: SEDs ແມ່ນຫຍັງ?
  A 2.1: SED (Self-Encrypting Drives) ມີຮາດແວພິເສດທີ່ເຂົ້າລະຫັດຂໍ້ມູນຂາເຂົ້າ ແລະຖອດລະຫັດຂໍ້ມູນຂາອອກໃນເວລາຈິງ.
• Q 2.2: ຂອບເຂດຂອງການເຂົ້າລະຫັດໃນ HX ແມ່ນຫຍັງ?
  A 2.2: ການເຂົ້າລະຫັດໃນ HX ໄດ້ຖືກປະຕິບັດໃນປັດຈຸບັນຢູ່ໃນຮາດແວສໍາລັບຂໍ້ມູນໃນເວລາທີ່ພັກຜ່ອນພຽງແຕ່ການນໍາໃຊ້ drives ທີ່ຖືກເຂົ້າລະຫັດ (SEDs). ການເຂົ້າລະຫັດ HX ແມ່ນກວ້າງກຸ່ມ. ການເຂົ້າລະຫັດ VM ສ່ວນບຸກຄົນແມ່ນຈັດການໂດຍຊອບແວພາກສ່ວນທີສາມເຊັ່ນ: Hytrust ຫຼືລູກຄ້າທີ່ມີຄວາມໂປ່ງໃສຂອງ Vormetric ແລະຢູ່ນອກຂອບເຂດຄວາມຮັບຜິດຊອບຂອງ HX. HX ຍັງຮອງຮັບການໃຊ້ການເຂົ້າລະຫັດ VM ເດີມຂອງ VMware ທີ່ນຳສະເໜີໃນ vSphere 3. ການໃຊ້ລູກຂ່າຍການເຂົ້າລະຫັດ VM ຢູ່ເທິງສຸດຂອງການເຂົ້າລະຫັດ HX SED ຈະເຮັດໃຫ້ມີການເຂົ້າລະຫັດສອງເທົ່າຂອງຂໍ້ມູນ. ການຈຳລອງ HX ບໍ່ໄດ້ຖືກເຂົ້າລະຫັດ ແລະອາໄສເຄືອຂ່າຍທີ່ເຊື່ອຖືໄດ້ ຫຼືອຸໂມງທີ່ເຂົ້າລະຫັດໄວ້ໂດຍຜູ້ໃຊ້ສຸດທ້າຍ.
• ຄໍາຖາມ 2.3: ມາດຕະຖານການປະຕິບັດຕາມອັນໃດທີ່ມີການເຂົ້າລະຫັດ HX?
  A 2.3: ໄດທີ່ເຂົ້າລະຫັດ HX SED ຕອບສະໜອງໄດ້ມາດຕະຖານ FIPS 140-2 ລະດັບ 2 ຈາກຜູ້ຜະລິດໄດຣຟ໌. ການເຂົ້າລະຫັດ HX ຢູ່ໃນເວທີຕອບສະຫນອງມາດຕະຖານ FIPS 140-2 ລະດັບ 1.
• Q 2.4: ພວກເຮົາສະຫນັບສະຫນູນທັງ HDD ແລະ SSD ສໍາລັບການເຂົ້າລະຫັດບໍ?
  A 2.4: ແມ່ນແລ້ວ ພວກເຮົາຮອງຮັບທັງ HDD ແລະ SSD SEDs ຈາກ Micron.
• ຄໍາຖາມ 2.5: ກຸ່ມ HX ສາມາດມີ drives ທີ່ເຂົ້າລະຫັດແລະບໍ່ເຂົ້າລະຫັດໃນເວລາດຽວກັນບໍ?
  A 2.5: ທຸກໆ nodes ໃນ cluster ຕ້ອງເປັນເອກະພາບ (SEDs ຫຼື non-SEDs)
• ຄໍາຖາມ 2.6: ໃຊ້ກະແຈໃດສໍາລັບ SED ແລະໃຊ້ແນວໃດ?
  A 2.6: ມີສອງກະແຈທີ່ໃຊ້ສໍາລັບແຕ່ລະ SED. Media Encryption Key (MEK) ຍັງເອີ້ນວ່າ Disk Encryption Key (DEK), ຄວບຄຸມການເຂົ້າລະຫັດ ແລະຖອດລະຫັດຂໍ້ມູນໃສ່ແຜ່ນ ແລະຖືກຮັກສາຄວາມປອດໄພ ແລະຈັດການໃນຮາດແວ. ກະແຈການເຂົ້າລະຫັດລັບ (KEK) ຮັກສາຄວາມປອດໄພ DEK/MEK ແລະຖືກຮັກສາໄວ້ໃນບ່ອນເກັບກະແຈພາຍໃນ ຫຼືທາງໄກ.
• ຄໍາຖາມ 2.7: ຄີມີຢູ່ໃນຄວາມຊົງຈໍາບໍ?
  A 2.7: ກະແຈການເຂົ້າລະຫັດບໍ່ເຄີຍມີຢູ່ໃນຫນ່ວຍຄວາມຈໍາຂອງ node
• ຄໍາຖາມ 2.8: ປະສິດທິພາບຖືກກະທົບຈາກຂະບວນການເຂົ້າລະຫັດ/ຖອດລະຫັດແນວໃດ?
  A 2.8: ການເຂົ້າລະຫັດ/ຖອດລະຫັດດິສຖືກຈັດການຢູ່ໃນຮາດແວຂອງໄດຣຟ໌. ປະສິດທິພາບຂອງລະບົບໂດຍລວມບໍ່ໄດ້ຮັບຜົນກະທົບ ແລະບໍ່ມີການໂຈມຕີທີ່ແນໃສ່ອົງປະກອບອື່ນໆຂອງລະບົບ
• ຄໍາຖາມ 2.9: ນອກເຫນືອຈາກການເຂົ້າລະຫັດທີ່ພັກຜ່ອນ, ເຫດຜົນອື່ນໃດທີ່ຈະໃຊ້ SEDs?
  A 2.9: SEDs ສາມາດຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການບໍານານແລະການໃຊ້ຈ່າຍຄືນໃຫມ່ໂດຍຜ່ານການລຶບລະຫັດລັບທັນທີ. ພວກເຂົາຍັງໃຫ້ບໍລິການເພື່ອປະຕິບັດຕາມກົດລະບຽບຂອງລັດຖະບານຫຼືອຸດສາຫະກໍາສໍາລັບຄວາມເປັນສ່ວນຕົວຂອງຂໍ້ມູນ. ແອັດວັນອື່ນtage ແມ່ນຄວາມສ່ຽງທີ່ຫຼຸດລົງຂອງການລັກແຜ່ນດິດແລະການລັກຂະໂມຍຕັ້ງແຕ່ຂໍ້ມູນ, ເມື່ອຮາດແວຖືກໂຍກຍ້າຍອອກຈາກລະບົບນິເວດ, ແມ່ນບໍ່ສາມາດອ່ານໄດ້.
• Q2.10: ຈະເກີດຫຍັງຂຶ້ນກັບການຊໍ້າຊ້ອນແລະການບີບອັດ SEDs? ຈະເກີດຫຍັງຂຶ້ນກັບການເຂົ້າລະຫັດຊອບແວພາກສ່ວນທີສາມ?
  A2.10: ການຊໍ້າຊ້ອນແລະການບີບອັດດ້ວຍ SEDs ໃນ HX ແມ່ນຖືກຮັກສາໄວ້ນັບຕັ້ງແຕ່ຂໍ້ມູນທີ່ພັກຜ່ອນການເຂົ້າລະຫັດເກີດຂຶ້ນເປັນຂັ້ນຕອນສຸດທ້າຍໃນຂະບວນການຂຽນ. ການຊໍ້າຊ້ອນແລະການບີບອັດໄດ້ເກີດຂຶ້ນແລ້ວ. ດ້ວຍຜະລິດຕະພັນການເຂົ້າລະຫັດທີ່ອີງໃສ່ຊອບແວພາກສ່ວນທີສາມ, VMs ຈັດການການເຂົ້າລະຫັດຂອງເຂົາເຈົ້າ ແລະຜ່ານການຂຽນເຂົ້າລະຫັດໄປຫາ hypervisor ແລະ HX ຕໍ່ມາ. ເນື່ອງຈາກການຂຽນເຫຼົ່ານີ້ຖືກເຂົ້າລະຫັດແລ້ວ, ພວກມັນບໍ່ໄດ້ຮັບການຊໍ້າຊ້ອນ ຫຼືຖືກບີບອັດ. HX Software Based Encryption (ໃນ codeline 3.x) ຈະເປັນໂຊລູຊັ່ນການເຂົ້າລະຫັດຊອບແວທີ່ປະຕິບັດໃນ stack ຫຼັງຈາກການຂຽນ optimization (deduplication ແລະ compression) ເກີດຂຶ້ນດັ່ງນັ້ນຜົນປະໂຫຍດຈະຖືກຮັກສາໄວ້ໃນກໍລະນີນີ້.

ຮູບຂ້າງລຸ່ມນີ້ແມ່ນຈົບແລ້ວview ການປະຕິບັດ SED ກັບ HX.

ລາຍລະອຽດ Drive 

• ຄຳຖາມ 3.1: ໃຜເປັນຜູ້ຜະລິດໄດຣຟ໌ທີ່ຖືກເຂົ້າລະຫັດທີ່ໃຊ້ໃນ HX?
  A 3.1: HX ໃຊ້ໄດທີ່ຜະລິດໂດຍ Micron: ເອກະສານສະເພາະຂອງ Micron ແມ່ນເຊື່ອມຕໍ່ຢູ່ໃນພາກສ່ວນເອກະສານສະຫນັບສະຫນູນຂອງ FAQ ນີ້.
• Q 3.2: ພວກເຮົາສະຫນັບສະຫນູນ SEDs ໃດໆທີ່ບໍ່ສອດຄ່ອງກັບ FIPS ບໍ?
  A 3.2: ພວກເຮົາຍັງສະຫນັບສະຫນູນບາງໄດທີ່ບໍ່ແມ່ນ FIPS, ແຕ່ສະຫນັບສະຫນູນ SED (TCGE).
• ຄໍາຖາມ 3.3: TCG ແມ່ນຫຍັງ?
  A 3.3: TCG ແມ່ນກຸ່ມຄອມພິວເຕີທີ່ເຊື່ອຖືໄດ້, ເຊິ່ງສ້າງ ແລະຄຸ້ມຄອງມາດຕະຖານສະເພາະສຳລັບການເກັບຮັກສາຂໍ້ມູນທີ່ເຂົ້າລະຫັດໄວ້.
• Q 3.4: ແມ່ນຫຍັງຖືວ່າເປັນຄວາມປອດໄພລະດັບວິສາຫະກິດເມື່ອເວົ້າເຖິງ SAS SSDs ສໍາລັບສູນຂໍ້ມູນ? ໄດຣຟ໌ເຫຼົ່ານີ້ມີຄຸນສົມບັດສະເພາະໃດແດ່ທີ່ຮັບປະກັນຄວາມປອດໄພ ແລະປ້ອງກັນການໂຈມຕີ?
  A 3.4: ບັນຊີລາຍຊື່ນີ້ສະຫຼຸບລັກສະນະລະດັບວິສາຫະກິດຂອງ SEDs ທີ່ໃຊ້ໃນ HX ແລະວິທີການທີ່ເຂົາເຈົ້າກ່ຽວຂ້ອງກັບມາດຕະຖານ TCG.
  1. ໄດການເຂົ້າລະຫັດຕົນເອງ (SEDs) ສະຫນອງຄວາມປອດໄພທີ່ເຂັ້ມແຂງສໍາລັບຂໍ້ມູນທີ່ພັກຜ່ອນຢູ່ໃນ SED ຂອງທ່ານ, ປ້ອງກັນການເຂົ້າເຖິງຂໍ້ມູນທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ. ກຸ່ມຄອມພິວເຕີທີ່ເຊື່ອຖືໄດ້ (TCG) ໄດ້ພັດທະນາບັນຊີລາຍຊື່ຂອງຄຸນສົມບັດ ແລະຜົນປະໂຫຍດຂອງໄດການເຂົ້າລະຫັດຕົນເອງສໍາລັບທັງ HDD ແລະ SSDs. TCG ສະຫນອງມາດຕະຖານທີ່ເອີ້ນວ່າ TCG Enterprise SSC (Security Subsystem Class) ແລະເນັ້ນໃສ່ຂໍ້ມູນໃນເວລາພັກຜ່ອນ. ນີ້ແມ່ນຄວາມຕ້ອງການສໍາລັບ SEDs ທັງຫມົດ. ຂໍ້ມູນຈໍາເພາະໃຊ້ກັບອຸປະກອນເກັບຂໍ້ມູນ ແລະຕົວຄວບຄຸມທີ່ເຮັດວຽກຢູ່ໃນບ່ອນເກັບຂໍ້ມູນວິສາຫະກິດ. ບັນຊີລາຍຊື່ປະກອບມີ:
     • ຄວາມໂປ່ງໃສ: ບໍ່​ມີ​ການ​ດັດ​ແກ້​ລະ​ບົບ​ຫຼື​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​; ລະ​ຫັດ​ການ​ເຂົ້າ​ລະ​ຫັດ​ທີ່​ຜະ​ລິດ​ໂດຍ​ການ​ຂັບ​ຕົວ​ມັນ​ເອງ​, ການ​ນໍາ​ໃຊ້​ໃນ​ຄະ​ນະ​ກໍາ​ເນີດ​ຈໍາ​ນວນ Random ທີ່​ແທ້​ຈິງ​; drive ຖືກເຂົ້າລະຫັດຢູ່ສະ ເໝີ.
     • ຄວາມ​ງ່າຍ​ຂອງ​ການ​ຄຸ້ມ​ຄອງ​: ບໍ່ມີລະຫັດການເຂົ້າລະຫັດເພື່ອຈັດການ; ຜູ້ຂາຍຊອບແວໃຊ້ສ່ວນຕິດຕໍ່ມາດຕະຖານເພື່ອຈັດການ SEDs, ລວມທັງການຈັດການທາງໄກ, ການພິສູດຢືນຢັນກ່ອນການບູດ, ແລະການຟື້ນຕົວລະຫັດຜ່ານ.
     • ຄ່າ​ໃຊ້​ຈ່າຍ​ໃນ​ການ​ກໍາ​ຈັດ​ຫຼື re-purposing​: ດ້ວຍ SED, ລຶບກະແຈການເຂົ້າລະຫັດຢູ່ເທິງເຮືອ
     • ການເຂົ້າລະຫັດຄືນໃໝ່: ດ້ວຍ SED, ບໍ່ຈໍາເປັນຕ້ອງເຂົ້າລະຫັດຂໍ້ມູນຄືນໃໝ່
     • ປະສິດທິພາບ: ບໍ່ມີການເຊື່ອມໂຊມໃນການປະຕິບັດ SED; ອີງໃສ່ຮາດແວ
     • ມາດຕະຖານ: ອຸດສາຫະກໍາການຂັບລົດທັງຫມົດກໍາລັງສ້າງກັບ TCG / SED Specifications
     • ຫຍໍ້: ບໍ່ມີການແຊກແຊງກັບຂະບວນການຕົ້ນນ້ໍາ
  2. SSD SEDs ສະຫນອງແມ່ນຄວາມສາມາດໃນການ cryptographically ລົບ drive. ນີ້ຫມາຍຄວາມວ່າຄໍາສັ່ງທີ່ມີຄວາມຖືກຕ້ອງງ່າຍດາຍສາມາດຖືກສົ່ງໄປຫາໄດເພື່ອປ່ຽນລະຫັດການເຂົ້າລະຫັດ 256-bit ທີ່ເກັບໄວ້ໃນໄດ. ນີ້ຮັບປະກັນວ່າໄດຖືກເຊັດໃຫ້ສະອາດແລະບໍ່ມີຂໍ້ມູນເຫຼືອຢູ່. ເຖິງແມ່ນວ່າລະບົບໂຮດຕົ້ນສະບັບບໍ່ສາມາດອ່ານຂໍ້ມູນໄດ້, ດັ່ງນັ້ນລະບົບອື່ນຈະບໍ່ສາມາດອ່ານໄດ້ຢ່າງແທ້ຈິງ. ການດໍາເນີນງານໃຊ້ເວລາພຽງແຕ່ສອງສາມວິນາທີ, ກົງກັນຂ້າມກັບເວລາຫຼາຍນາທີຫຼືຫຼາຍຊົ່ວໂມງທີ່ມັນໃຊ້ເວລາເພື່ອປະຕິບັດການປຽບທຽບກັບ HDD ທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດລັບແລະຫຼີກເວັ້ນຄ່າໃຊ້ຈ່າຍຂອງອຸປະກອນຫຼືການບໍລິການ HDD ທີ່ມີລາຄາແພງ.
  3. FIPS (ມາດຕະຖານການປະມວນຜົນຂໍ້ມູນຂອງລັດຖະບານກາງ) 140-2 ແມ່ນມາດຕະຖານຂອງລັດຖະບານສະຫະລັດທີ່ອະທິບາຍເຖິງການເຂົ້າລະຫັດ ແລະຄວາມຕ້ອງການຄວາມປອດໄພທີ່ກ່ຽວຂ້ອງທີ່ຜະລິດຕະພັນ IT ຄວນຕອບສະໜອງໄດ້ສໍາລັບການນໍາໃຊ້ທີ່ລະອຽດອ່ອນ, ແຕ່ບໍ່ໄດ້ຈັດປະເພດ. ນີ້ມັກຈະເປັນຄວາມຕ້ອງການສໍາລັບອົງການຂອງລັດຖະບານແລະບໍລິສັດໃນການບໍລິການທາງດ້ານການເງິນແລະອຸດສາຫະກໍາການດູແລສຸຂະພາບເຊັ່ນດຽວກັນ. SSD ທີ່ມີຄວາມຖືກຕ້ອງຂອງ FIPS-140-2 ໃຊ້ການປະຕິບັດຄວາມປອດໄພທີ່ເຂັ້ມແຂງລວມທັງລະບົບການເຂົ້າລະຫັດທີ່ໄດ້ຮັບການອະນຸມັດ. ມັນຍັງກໍານົດວິທີການບຸກຄົນຫຼືຂະບວນການອື່ນໆຕ້ອງໄດ້ຮັບການອະນຸຍາດເພື່ອນໍາໃຊ້ຜະລິດຕະພັນ, ແລະວິທີການໂມດູນຫຼືອົງປະກອບຕ້ອງໄດ້ຮັບການອອກແບບເພື່ອປະຕິສໍາພັນຢ່າງປອດໄພກັບລະບົບອື່ນໆ. ໃນຄວາມເປັນຈິງ, ຫນຶ່ງໃນຂໍ້ກໍານົດຂອງ FIPS-140-2 validated SSD drive ແມ່ນວ່າມັນເປັນ SED. ຈົ່ງຈື່ໄວ້ວ່າເຖິງແມ່ນວ່າ TCG ບໍ່ແມ່ນວິທີດຽວທີ່ຈະໄດ້ຮັບໄດທີ່ຖືກເຂົ້າລະຫັດທີ່ໄດ້ຮັບການຮັບຮອງ, ຂໍ້ມູນຈໍາເພາະຂອງ TCG Opal ແລະ Enterprise SSC ໃຫ້ພວກເຮົາເປັນຈຸດກ້າວໄປສູ່ການກວດສອບ FIPS. 4. ຄຸນ​ນະ​ສົມ​ບັດ​ທີ່​ສໍາ​ຄັນ​ອີກ​ປະ​ການ​ຫນຶ່ງ​ແມ່ນ​ການ​ດາວ​ໂຫຼດ​ທີ່​ປອດ​ໄພ​ແລະ​ການ​ວິ​ນິດ​ໄສ​. ຄຸນສົມບັດເຟີມແວນີ້ປົກປ້ອງໄດຈາກການໂຈມຕີຂອງຊອບແວຜ່ານລາຍເຊັນດິຈິຕອນທີ່ສ້າງຂຶ້ນໃນເຟີມແວ. ເມື່ອຕ້ອງການການດາວໂຫຼດ, ລາຍເຊັນດິຈິຕອລປ້ອງກັນການເຂົ້າເຖິງໄດຣຟ໌ໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ, ປ້ອງກັນບໍ່ໃຫ້ເຟີມແວປອມຖືກໂຫລດໃສ່ໄດຣຟ໌.

ການຕິດຕັ້ງ Hyperflex ກັບ SEDs

• ຄໍາຖາມ 4.1: ຜູ້ຕິດຕັ້ງຈັດການກັບການຕິດຕັ້ງ SED ແນວໃດ? ມີການກວດສອບພິເສດບໍ?
  A 4.1: ຕົວຕິດຕັ້ງຕິດຕໍ່ສື່ສານກັບ UCSM ແລະຮັບປະກັນວ່າເຟີມແວຂອງລະບົບຖືກຕ້ອງ ແລະຮອງຮັບຮາດແວທີ່ກວດພົບ. ຄວາມເຂົ້າກັນໄດ້ຂອງການເຂົ້າລະຫັດຖືກກວດສອບ ແລະບັງຄັບໃຊ້ (ເຊັ່ນ: ບໍ່ມີການປະສົມຂອງ SED ແລະ ບໍ່ແມ່ນ SED).
• ຄໍາຖາມ 4.2: ການປະຕິບັດແມ່ນແຕກຕ່າງກັນບໍ?
  A 4.2: ການຕິດຕັ້ງແມ່ນຄ້າຍຄືກັນກັບການຕິດຕັ້ງ HX ປົກກະຕິ, ແນວໃດກໍ່ຕາມ, ຂະບວນການເຮັດວຽກທີ່ກໍາຫນົດເອງບໍ່ສະຫນັບສະຫນູນ SEDs. ການປະຕິບັດງານນີ້ຕ້ອງການໃບຢັ້ງຢືນ UCSM ສໍາລັບ SEDs ເຊັ່ນກັນ.
• ຄໍາຖາມ 4.3: ໃບອະນຸຍາດເຮັດວຽກກັບການເຂົ້າລະຫັດແນວໃດ? ມີອັນໃດອັນໜຶ່ງທີ່ຈຳເປັນທີ່ຈະຕ້ອງຢູ່ນຳບໍ?
  A 4.3: ຮາດແວ SED (ສັ່ງຈາກໂຮງງານ, ບໍ່ແມ່ນ retrofit) + HXDP 2.5 + UCSM (3.1(3x)) ແມ່ນສິ່ງດຽວທີ່ຈໍາເປັນເພື່ອໃຫ້ສາມາດເຂົ້າລະຫັດລັບກັບການຄຸ້ມຄອງທີ່ສໍາຄັນ. ບໍ່​ມີ​ການ​ອອກ​ອະ​ນຸ​ຍາດ​ເພີ່ມ​ເຕີມ​ນອກ​ຈາກ​ການ​ສະ​ຫມັກ HXDP ພື້ນ​ຖານ​ທີ່​ຕ້ອງ​ການ​ໃນ​ການ 2.5 ປ່ອຍ​.
• ຄໍາຖາມ 4.4: ຈະເກີດຫຍັງຂຶ້ນເມື່ອຂ້ອຍມີລະບົບ SED ທີ່ມີ drives ທີ່ບໍ່ມີຢູ່ແລ້ວ? ຂ້ອຍຈະຂະຫຍາຍກຸ່ມນີ້ໄດ້ແນວໃດ?
  A 4.4: ເມື່ອໃດກໍ່ຕາມທີ່ພວກເຮົາມີ PID ໃດໆທີ່ສິ້ນສຸດຊີວິດຈາກຜູ້ສະຫນອງຂອງພວກເຮົາ, ພວກເຮົາມີ PID ທົດແທນທີ່ເຫມາະສົມກັບ PID ເກົ່າ. PID ທົດແທນນີ້ສາມາດຖືກນໍາໃຊ້ສໍາລັບ RMA, ການຂະຫຍາຍພາຍໃນ node, ແລະການຂະຫຍາຍຕົວຂອງກຸ່ມ (ກັບ nodes ໃຫມ່). ວິທີການທັງຫມົດແມ່ນສະຫນັບສະຫນູນທັງຫມົດ, ຢ່າງໃດກໍຕາມ, ພວກເຂົາເຈົ້າອາດຈະຮຽກຮ້ອງໃຫ້ມີການຍົກລະດັບເປັນການປ່ອຍສະເພາະທີ່ຍັງຖືກກໍານົດຢູ່ໃນບັນທຶກການປ່ອຍການປ່ຽນແປງ.

ການບໍລິຫານຫຼັກ

• Q 5.1: ການຄຸ້ມຄອງຫຼັກແມ່ນຫຍັງ?
  A 5.1: ການ​ຄຸ້ມ​ຄອງ​ກະ​ແຈ​ແມ່ນ​ວຽກ​ງານ​ທີ່​ກ່ຽວ​ຂ້ອງ​ກັບ​ການ​ປົກ​ປ້ອງ​, ການ​ເກັບ​ຮັກ​ສາ​, ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ແລະ​ການ​ຈັດ​ຕັ້ງ​ລະ​ຫັດ​ການ​ເຂົ້າ​ລະ​ຫັດ​. HX ປະຕິບັດສິ່ງນີ້ໃນນະໂຍບາຍ UCSM ເປັນສູນກາງ.
• Q 5.2: ກົນໄກໃດທີ່ສະຫນອງການສະຫນັບສະຫນູນສໍາລັບການຕັ້ງຄ່າທີ່ສໍາຄັນ?
  A 5.2: UCSM ໃຫ້ການສະໜັບສະໜູນເພື່ອກຳນົດຄ່າກະແຈຄວາມປອດໄພ.
• ຄໍາຖາມ 5.3: ປະເພດຂອງການຈັດການຫຼັກທີ່ມີຢູ່?
  A 5.3: ການຈັດການກະແຈທ້ອງຖິ່ນໄດ້ຮັບການສະໜັບສະໜູນ, ພ້ອມກັບການຈັດການກະແຈທາງໄກລະດັບວິສາຫະກິດກັບເຊີບເວີການຈັດການຫຼັກຂອງພາກສ່ວນທີສາມ.
• ຄໍາຖາມ 5.4: ໃຜເປັນຄູ່ຮ່ວມງານການຄຸ້ມຄອງທີ່ສໍາຄັນຫ່າງໄກສອກຫຼີກ?
  A 5.4: ໃນປັດຈຸບັນພວກເຮົາສະຫນັບສະຫນູນ Vormetric ແລະ Gemalto (Safenet) ແລະປະກອບມີຄວາມພ້ອມສູງ (HA). HyTrust ແມ່ນຢູ່ໃນການທົດສອບ.
• Q 5.5: ການຈັດການກະແຈທາງໄກຖືກປະຕິບັດແນວໃດ?
  A 5.5: ການຈັດການກະແຈທາງໄກແມ່ນຈັດການຜ່ານ KMIP 1.1.
• Q 5.6: ການຈັດການທ້ອງຖິ່ນຖືກຕັ້ງຄ່າແນວໃດ?
  A 5.6: ກະແຈຄວາມປອດໄພ (KEK) ຖືກຕັ້ງຄ່າໃນ HX Connect, ໂດຍຜູ້ໃຊ້ໂດຍກົງ.
• Q 5.7: ການຈັດການທາງໄກຖືກຕັ້ງຄ່າແນວໃດ?
  A 5.7: ຂໍ້ມູນທີ່ຢູ່ເຊີບເວີການຈັດການກະແຈທາງໄກ (KMIP) ພ້ອມກັບຂໍ້ມູນການເຂົ້າສູ່ລະບົບຖືກກຳນົດຄ່າໃນ HX Connect ໂດຍຜູ້ໃຊ້.
• Q 5.8: ພາກສ່ວນໃດຂອງ HX ສື່ສານກັບເຄື່ອງແມ່ຂ່າຍ KMIP ສໍາລັບການຕັ້ງຄ່າ?
  A 5.8: CIMC ໃນແຕ່ລະ node ໃຊ້ຂໍ້ມູນນີ້ເພື່ອເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ KMIP ແລະດຶງລະຫັດຄວາມປອດໄພ (KEK) ຈາກມັນ.
  
• ຄໍາຖາມ 5.9: ໃບຢັ້ງຢືນປະເພດໃດແດ່ທີ່ໄດ້ຮັບການສະຫນັບສະຫນູນໃນຂະບວນການຜະລິດ / ຖອນຄືນ / ການປັບປຸງທີ່ສໍາຄັນ?
  A 5.9: ໃບຢັ້ງຢືນທີ່ເຊັນ CA ແລະເຊັນດ້ວຍຕົນເອງແມ່ນສະຫນັບສະຫນູນທັງສອງ.
  
• Q 5.10: ຂັ້ນຕອນການເຮັດວຽກໃດທີ່ສະຫນັບສະຫນູນກັບຂະບວນການເຂົ້າລະຫັດ?
  A 5.10: ປ້ອງກັນ/ບໍ່ປ້ອງກັນໂດຍໃຊ້ລະຫັດຜ່ານແບບກຳນົດເອງແມ່ນຮອງຮັບພ້ອມກັບການປ່ຽນການຈັດການລະຫັດຈາກທ້ອງຖິ່ນຫາໄລຍະໄກ. ການ​ດໍາ​ເນີນ​ງານ​ທີ່​ສໍາ​ຄັນ​ແມ່ນ​ສະ​ຫນັບ​ສະ​ຫນູນ​. ການ​ດໍາ​ເນີນ​ງານ​ການ​ລົບ​ແຜ່ນ​ທີ່​ປອດ​ໄພ​ແມ່ນ​ສະ​ຫນັບ​ສະ​ຫນູນ​.
  

ຂະບວນການເຮັດວຽກຂອງຜູ້ໃຊ້: ທ້ອງຖິ່ນ

• Q 6.1: ໃນ HX Connect, ບ່ອນທີ່ຂ້ອຍຕັ້ງຄ່າການຈັດການລະຫັດທ້ອງຖິ່ນ?
  A 6.1: ໃນ dashboard ການເຂົ້າລະຫັດເລືອກປຸ່ມ configure ແລະປະຕິບັດຕາມຕົວຊ່ວຍສ້າງ.
• ຄໍາຖາມ 6.2: ຂ້ອຍຈໍາເປັນຕ້ອງມີຄວາມພ້ອມທີ່ຈະໄປເຮັດຫຍັງເພື່ອເລີ່ມຕົ້ນ?
  A 6.2: ທ່ານຈະຕ້ອງໃຫ້ລະຫັດຜ່ານຄວາມປອດໄພ 32 ຕົວອັກສອນ.
• ຄໍາຖາມ 6.3: ຈະເກີດຫຍັງຂຶ້ນຖ້າຂ້ອຍຕ້ອງໃສ່ SED ໃຫມ່?
  A 6.3: ໃນ UCSM ທ່ານຈະຕ້ອງແກ້ໄຂນະໂຍບາຍຄວາມປອດໄພທ້ອງຖິ່ນ ແລະຕັ້ງກະແຈທີ່ນຳໃຊ້ກັບປຸ່ມ node ທີ່ມີຢູ່ແລ້ວ.
• ຄຳຖາມ 6.4: ຈະເກີດຫຍັງຂຶ້ນເມື່ອຂ້ອຍໃສ່ແຜ່ນໃຫມ່?
  A 6.4: ຖ້າກະແຈຄວາມປອດໄພຢູ່ໃນແຜ່ນກົງກັບເຊີບເວີ (ໂນດ) ມັນຈະຖືກປົດລັອກໂດຍອັດຕະໂນມັດ. ຖ້າກະແຈຄວາມປອດໄພແຕກຕ່າງກັນ, ແຜ່ນຈະສະແດງເປັນ “Locked”. ທ່ານສາມາດລຶບລ້າງດິສກ໌ເພື່ອລຶບຂໍ້ມູນທັງໝົດ ຫຼືປົດລັອກໄດ້ໂດຍການໃຫ້ກະແຈທີ່ຖືກຕ້ອງ. ນີ້ແມ່ນເວລາທີ່ດີທີ່ຈະເຂົ້າຮ່ວມ TAC.

User Workflow: ໄລຍະໄກ

• ຄຳຖາມ 7.1: ມີຫຍັງແດ່ທີ່ຂ້ອຍຕ້ອງລະວັງກັບການຕັ້ງຄ່າການຈັດການກະແຈທາງໄກ?
  A 7.1: ການສື່ສານລະຫວ່າງກຸ່ມ ແລະເຊີບເວີ KMIP ເກີດຂຶ້ນຜ່ານ CIMC ໃນແຕ່ລະ node. ນີ້ຫມາຍຄວາມວ່າຊື່ໂຮດສາມາດນໍາໃຊ້ສໍາລັບເຄື່ອງແມ່ຂ່າຍ KMIP ພຽງແຕ່ຖ້າທີ່ຢູ່ IP Inband ແລະ DNS ຖືກຕັ້ງຄ່າໃນການຈັດການ CIMC.
• ຄໍາຖາມ 7.2: ຈະເກີດຫຍັງຂຶ້ນຖ້າຂ້ອຍຕ້ອງການປ່ຽນ ຫຼືໃສ່ SED ໃຫມ່?
  A 7.2: ກຸ່ມຈະອ່ານຕົວລະບຸຈາກແຜ່ນ ແລະພະຍາຍາມປົດລັອກມັນໂດຍອັດຕະໂນມັດ. ຖ້າການປົດລັອກອັດຕະໂນມັດລົ້ມເຫລວ, ດິສກ໌ຂຶ້ນມາເປັນ “ລັອກ” ແລະຜູ້ໃຊ້ຕ້ອງປົດລັອກດິສດ້ວຍຕົນເອງ. ທ່ານຈະຕ້ອງສຳເນົາໃບຮັບຮອງໄປໃສ່ເຊີບເວີ KMIP ເພື່ອແລກປ່ຽນຂໍ້ມູນຮັບຮອງ.
• ຄຳຖາມ 7.3: ຂ້ອຍຈະສຳເນົາໃບຢັ້ງຢືນຈາກກຸ່ມໄປໃສ່ເຊີບເວີ KMIP ໄດ້ແນວໃດ?
  A 7.3: ມີສອງວິທີທີ່ຈະເຮັດແນວນີ້. ທ່ານສາມາດຄັດລອກໃບຢັ້ງຢືນຈາກ BMC ກັບເຄື່ອງແມ່ຂ່າຍ KMIP ໂດຍກົງຫຼືທ່ານສາມາດນໍາໃຊ້ CSR ເພື່ອເອົາໃບຢັ້ງຢືນທີ່ເຊັນ CA ແລະຄັດລອກໃບຢັ້ງຢືນທີ່ເຊັນ CA ກັບ BMC ໂດຍໃຊ້ຄໍາສັ່ງ UCSM.
• ຄໍາຖາມ 7.4: ມີການພິຈາລະນາອັນໃດສໍາລັບການເພີ່ມໂຫນດທີ່ຖືກເຂົ້າລະຫັດໃສ່ກຸ່ມທີ່ໃຊ້ການຈັດການກະແຈທາງໄກ?
  A 7.4: ເມື່ອເພີ່ມໂຮສໃໝ່ໃສ່ເຊີບເວີ KMIP, ຊື່ໂຮສທີ່ໃຊ້ຄວນເປັນໝາຍເລກຊີຣຽວຂອງເຊີບເວີ. ເພື່ອໃຫ້ໄດ້ຮັບໃບຢັ້ງຢືນຂອງເຊີບເວີ KMIP, ທ່ານສາມາດນໍາໃຊ້ຕົວທ່ອງເວັບເພື່ອເອົາໃບຢັ້ງຢືນຮາກຂອງເຄື່ອງແມ່ຂ່າຍ KMIP.

ຂະບວນການເຮັດວຽກຂອງຜູ້ໃຊ້: ທົ່ວໄປ

• ຄໍາຖາມ 8.1: ຂ້ອຍຈະລຶບແຜ່ນດິດໄດ້ແນວໃດ?
  A 8.1: ໃນ dashboard HX Connect, ເລືອກຂໍ້ມູນລະບົບ view. ຈາກ​ນັ້ນ​ທ່ານ​ສາ​ມາດ​ເລືອກ​ເອົາ​ແຜ່ນ​ແຕ່​ລະ​ຄົນ​ສໍາ​ລັບ​ການ​ລົບ​ທີ່​ປອດ​ໄພ​.
• Q 8.2: ຈະເປັນແນວໃດຖ້າຂ້ອຍລຶບແຜ່ນໂດຍບັງເອີນ?
  A 8.2: ເມື່ອການລຶບທີ່ປອດໄພຖືກນໍາໃຊ້, ຂໍ້ມູນຈະຖືກທໍາລາຍຢ່າງຖາວອນ
• ຄຳຖາມ 8.3: ຈະເກີດຫຍັງຂຶ້ນເມື່ອຂ້ອຍຕ້ອງການຍົກເລີກການຕັ້ງຂໍ້ ຫຼື dissociate pro servicefile?
  A 8.3: ບໍ່ມີການປະຕິບັດເຫຼົ່ານີ້ຈະເອົາການເຂົ້າລະຫັດໃນແຜ່ນ/ຕົວຄວບຄຸມອອກ.
• ຄຳຖາມ 8.4: ການເຂົ້າລະຫັດຖືກປິດການນຳໃຊ້ແນວໃດ?
  A 8.4: ຜູ້ໃຊ້ຕ້ອງປິດການເຂົ້າລະຫັດຢ່າງຈະແຈ້ງໃນ HX Connect. ຖ້າຜູ້ໃຊ້ພະຍາຍາມລຶບນະໂຍບາຍຄວາມປອດໄພໃນ UCSM ເມື່ອເຊີບເວີທີ່ກ່ຽວຂ້ອງໄດ້ຮັບຄວາມປອດໄພ, UCSM ຈະສະແດງການຕັ້ງຄ່າຄວາມລົ້ມເຫຼວແລະບໍ່ອະນຸຍາດໃຫ້ດໍາເນີນການ. ນະໂຍບາຍຄວາມປອດໄພຕ້ອງຖືກປິດໃຊ້ງານກ່ອນ.

User Workflow: ການຈັດການໃບຢັ້ງຢືນ

• Q 9.1: ໃບຢັ້ງຢືນຖືກຈັດການແນວໃດໃນລະຫວ່າງການຕັ້ງການຈັດການທາງໄກ?
  A 9.1: ໃບຮັບຮອງຖືກສ້າງໂດຍໃຊ້ HX Connect ແລະເຊີບເວີ KMIP ຫ່າງໄກສອກຫຼີກ. ໃບຮັບຮອງເມື່ອສ້າງແລ້ວເກືອບຈະບໍ່ຖືກລຶບ.
• Q 9.2: ຂ້ອຍສາມາດໃຊ້ໃບຢັ້ງຢືນປະເພດໃດແດ່?
  A 9.2: ທ່ານ​ສາ​ມາດ​ນໍາ​ໃຊ້​ທັງ​ໃບ​ຢັ້ງ​ຢືນ​ການ​ເຊັນ​ຕົນ​ເອງ​ຫຼື​ໃບ​ຢັ້ງ​ຢືນ CA​. ທ່ານຕ້ອງເລືອກໃນລະຫວ່າງການຕັ້ງ. ສໍາລັບໃບຢັ້ງຢືນການເຊັນ CA ທ່ານຈະສ້າງຊຸດຂອງຄໍາຮ້ອງຂໍການເຊັນໃບຢັ້ງຢືນ (CSRs). ໃບຢັ້ງຢືນທີ່ໄດ້ເຊັນຖືກອັບໂຫລດໄປຍັງເຊີບເວີ KMIP.
• ຄໍາຖາມ 9.3: ຂ້ອຍຄວນໃຊ້ຊື່ໂຮດໃດໃນເວລາສ້າງໃບຢັ້ງຢືນ?
  A 9.3: ຊື່ເຈົ້າພາບທີ່ໃຊ້ໃນການສ້າງໃບຢັ້ງຢືນຄວນເປັນໝາຍເລກ Serial ຂອງເຊີບເວີ.

ອັບເດດເຟີມແວ

• ຄໍາຖາມ 10.1: ມີຂໍ້ຈໍາກັດໃດໆກ່ຽວກັບການອັບເກຣດເຟີມແວຂອງແຜ່ນບໍ?
  A 10.1: ຖ້າກວດພົບໄດຣຟ໌ທີ່ສາມາດເຂົ້າລະຫັດໄດ້, ການປ່ຽນແປງເຟີມແວຂອງດິສກ໌ຈະບໍ່ໄດ້ຮັບອະນຸຍາດສຳລັບດິສກ໌ນັ້ນ.
• ຄໍາຖາມ 10.2: ມີຂໍ້ຈໍາກັດໃດໆກ່ຽວກັບການອັບເກຣດເຟີມແວ UCSM?
  A 10.2: ດາວເກຣດຂອງ UCSM/CIMC ເປັນ pre-UCSM 3.1(3x) ຖືກຈຳກັດຫາກມີຕົວຄວບຄຸມທີ່ຢູ່ໃນສະຖານະທີ່ປອດໄພ.

ລາຍລະອຽດການລຶບທີ່ປອດໄພ

• Q 11.1: Secure Erase ແມ່ນຫຍັງ?
  A 11.1: ການລຶບທີ່ປອດໄພແມ່ນການລຶບຂໍ້ມູນໃນໄດຣຟ໌ທັນທີ (ເຊັດລະຫັດການເຂົ້າລະຫັດດິສກ໌). ນີ້ຫມາຍຄວາມວ່າຄໍາສັ່ງທີ່ມີຄວາມຖືກຕ້ອງງ່າຍດາຍສາມາດຖືກສົ່ງໄປຫາໄດເພື່ອປ່ຽນລະຫັດການເຂົ້າລະຫັດ 256-bit ທີ່ເກັບໄວ້ໃນໄດ. ນີ້ຮັບປະກັນວ່າໄດຖືກເຊັດໃຫ້ສະອາດແລະບໍ່ມີຂໍ້ມູນເຫຼືອຢູ່. ເຖິງແມ່ນວ່າລະບົບໂຮດຕົ້ນສະບັບບໍ່ສາມາດອ່ານຂໍ້ມູນໄດ້, ສະນັ້ນມັນຈະບໍ່ສາມາດອ່ານໄດ້ໂດຍລະບົບອື່ນ. ການປະຕິບັດການໃຊ້ເວລາພຽງແຕ່ສອງສາມວິນາທີ, ກົງກັນຂ້າມກັບຫຼາຍນາທີຫຼືແມ້ກະທັ້ງຊົ່ວໂມງທີ່ມັນໃຊ້ເວລາເພື່ອປະຕິບັດການປຽບທຽບໃນແຜ່ນ unencrypted ແລະຫຼີກເວັ້ນການຄ່າໃຊ້ຈ່າຍຂອງອຸປະກອນ degaussing ລາຄາແພງຫຼືການບໍລິການ.
• ຄຳຖາມ 11.2: ການລຶບທີ່ປອດໄພຖືກປະຕິບັດແນວໃດ?
  A 11.2: ນີ້ແມ່ນການດໍາເນີນການ GUI ທີ່ປະຕິບັດຫນຶ່ງໄດໃນເວລານັ້ນ.
• ຄຳຖາມ 11.3: ການລຶບທີ່ປອດໄພຕາມປົກກະຕິຖືກປະຕິບັດເມື່ອໃດ?
  A 11.3: ການລຶບທີ່ປອດໄພທີ່ລິເລີ່ມໂດຍຜູ້ໃຊ້ຂອງແຜ່ນດຽວເປັນການດໍາເນີນງານທີ່ຫາຍາກ. ນີ້ສ່ວນຫຼາຍແມ່ນເຮັດໃນເວລາທີ່ທ່ານຕ້ອງການເອົາແຜ່ນອອກເພື່ອທົດແທນ, ໂອນມັນໄປຫາໂຫນດອື່ນ, ຫຼືຫຼີກເວັ້ນຄວາມລົ້ມເຫຼວໃນອະນາຄົດ.
• ຄຳຖາມ 11.4: ມີຂໍ້ຈຳກັດອັນໃດໃນການລຶບຢ່າງປອດໄພ?
  A 11.4: ການປະຕິບັດການລຶບທີ່ປອດໄພສາມາດປະຕິບັດໄດ້ພຽງແຕ່ຖ້າກຸ່ມມີສຸຂະພາບດີເພື່ອຮັບປະກັນວ່າຄວາມຕ້ານທານຄວາມຜິດຂອງ cluster ບໍ່ໄດ້ຮັບຜົນກະທົບ.
• ຄໍາຖາມ 11.5: ຈະເກີດຫຍັງຂຶ້ນຖ້າຂ້ອຍຈໍາເປັນຕ້ອງເອົາໂຫນດທັງຫມົດອອກ?
  A 11.5: ມີ node remove ແລະ node ແທນ workflows ເພື່ອສະຫນັບສະຫນູນການລຶບ drives ທັງຫມົດຢ່າງປອດໄພ. ເບິ່ງຄໍາແນະນໍາຂອງຜູ້ເບິ່ງແຍງສໍາລັບລາຍລະອຽດຫຼືປຶກສາ Cisco TAC.
• ຄຳຖາມ 11.6: ແຜ່ນທີ່ລຶບແລ້ວປອດໄພສາມາດນຳມາໃຊ້ໃໝ່ໄດ້ບໍ?
  A 11.6: ແຜ່ນທີ່ໄດ້ຖືກລຶບຢ່າງປອດໄພສາມາດຖືກນໍາມາໃຊ້ຄືນໃນກຸ່ມອື່ນເທົ່ານັ້ນ. ການລຶບ SED ທີ່ປອດໄພແມ່ນເຮັດໄດ້ໂດຍການເຊັດລະຫັດການເຂົ້າລະຫັດດິສກ໌ (DEK). ຂໍ້ມູນໃນດິສກ໌ບໍ່ສາມາດຖອດລະຫັດໄດ້ຫາກບໍ່ມີ DEK. ນີ້ອະນຸຍາດໃຫ້ທ່ານໃຊ້ຄືນໃຫມ່ຫຼື decommission ແຜ່ນໂດຍບໍ່ມີການປະນີປະນອມຂອງຂໍ້ມູນໃດໆ.
• ຄຳຖາມ 11.7: ຈະເກີດຫຍັງຂຶ້ນຖ້າແຜ່ນທີ່ຂ້ອຍຕ້ອງການລຶບມີສຳເນົາຂໍ້ມູນກຸ່ມຫຼັກສຸດທ້າຍ?
  A 11.7: ຂໍ້ມູນໃນດິສກ໌ຄວນມີສຳເນົາອື່ນຢູ່ໃນກຸ່ມເພື່ອຫຼີກເວັ້ນການສູນເສຍຂໍ້ມູນ. ແນວໃດກໍ່ຕາມ, ຖ້າການລຶບທີ່ປອດໄພຖືກຮ້ອງຂໍຢູ່ໃນແຜ່ນທີ່ເປັນສໍາເນົາຕົ້ນຕໍສຸດທ້າຍ, ການດໍາເນີນງານນີ້ຈະຖືກປະຕິເສດຈົນກ່ວາມີຢ່າງຫນ້ອຍຫນຶ່ງສໍາເນົາທີ່ມີຢູ່. Rebalance ຄວນເຮັດສໍາເນົານີ້ຢູ່ໃນພື້ນຫລັງ.
• ຄໍາຖາມທີ 11.8: ຂ້ອຍຈໍາເປັນຕ້ອງລຶບແຜ່ນຢ່າງປອດໄພ, ແຕ່ກຸ່ມບໍ່ມີສຸຂະພາບດີ. ຂ້ອຍສາມາດເຮັດໄດ້ແນວໃດ?
  A 11.8: ແຖວຄຳສັ່ງ (STCLI/HXCLI) ຈະອະນຸຍາດໃຫ້ລຶບລ້າງຢ່າງປອດໄພ ເມື່ອກຸ່ມບໍ່ມີສຸຂະພາບດີ ແລະດິສກ໌ບໍ່ມີສຳເນົາຫຼັກສຸດທ້າຍ, ຖ້າບໍ່ດັ່ງນັ້ນ ຈະບໍ່ອະນຸຍາດ.
• ຄຳຖາມ 11.9: ຂ້ອຍສາມາດລຶບ node ທັງໝົດຢ່າງປອດໄພໄດ້ແນວໃດ?
  A 11.9: ນີ້ແມ່ນສະຖານະການທີ່ຫາຍາກ. ການລຶບລ້າງດິສທັງໝົດໃນ node ທີ່ປອດໄພແມ່ນເຮັດໄດ້ເມື່ອຕ້ອງການເອົາ node ອອກຈາກ cluster. ຄວາມຕັ້ງໃຈແມ່ນເພື່ອປັບໃຊ້ node ໃນກຸ່ມທີ່ແຕກຕ່າງກັນ ຫຼື decommission the node. ພວກ​ເຮົາ​ສາ​ມາດ​ຈັດ​ປະ​ເພດ​ການ​ລົບ​ຂໍ້​ມູນ​ໃນ​ສະ​ຖາ​ນະ​ການ​ນີ້​ໃນ​ສອງ​ວິ​ທີ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​:
  1. ຮັບປະກັນການລຶບແຜ່ນທັງໝົດໂດຍບໍ່ຕ້ອງປິດການເຂົ້າລະຫັດ
  2. ການລຶບລ້າງດິສກ໌ທັງໝົດທີ່ປອດໄພຕາມມາດ້ວຍການປິດການເຂົ້າລະຫັດລັບຂອງໂນດນັ້ນ (ແລະແຜ່ນ). ກະລຸນາຕິດຕໍ່ Cisco TAC ສໍາລັບການຊ່ວຍເຫຼືອ.

ການຂະຫຍາຍທີ່ປອດໄພຂອງກຸ່ມ

• ຄໍາຖາມ 12.1: ປະເພດໃດແດ່ທີ່ຂ້ອຍສາມາດຂະຫຍາຍກຸ່ມທີ່ຖືກເຂົ້າລະຫັດໄດ້?
  A 12.1: ມີພຽງແຕ່ nodes ທີ່ມີຄວາມສາມາດ SED ສາມາດຖືກເພີ່ມໃສ່ HX Cluster ທີ່ມີ SEDs.
• ຄໍາຖາມ 12.2: ການຂະຫຍາຍຕົວກັບການຈັດການທີ່ສໍາຄັນໃນທ້ອງຖິ່ນຖືກຈັດການແນວໃດ?
  A 12.2: ການຂະຫຍາຍກະແຈໃນທ້ອງຖິ່ນແມ່ນການເຮັດວຽກແບບບໍ່ມີຮອຍຕໍ່ທີ່ບໍ່ຈຳເປັນຕ້ອງມີການຕັ້ງຄ່າພາຍນອກ.
• Q 12.3: ການຂະຫຍາຍດ້ວຍການຈັດການກະແຈທາງໄກຖືກຈັດການແນວໃດ?
  A 12.3: ການຂະຫຍາຍກະແຈທາງໄກຕ້ອງການ lockstep ດ້ວຍໃບຢັ້ງຢືນ/ໂຄງສ້າງພື້ນຖານການຈັດການກະແຈ:
  • ຕ້ອງມີໃບຮັບຮອງເພື່ອເພີ່ມ node ໃໝ່ຢ່າງປອດໄພ
  • ການນຳໃຊ້ຈະສະແດງຄຳເຕືອນພ້ອມກັບຂັ້ນຕອນເພື່ອດຳເນີນການ ລວມທັງການເຊື່ອມຕໍ່ສຳລັບການດາວໂຫຼດໃບຢັ້ງຢືນ
  • ຜູ້ໃຊ້ປະຕິບັດຕາມຂັ້ນຕອນເພື່ອອັບໂຫລດໃບຮັບຮອງ ແລະຈາກນັ້ນພະຍາຍາມນຳໃຊ້ຄືນໃໝ່

ເອກະສານສະໜັບສະໜູນ

ໄມໂຄຣນ:

• 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

• ບັນຊີລາຍຊື່ຂອງສູດການຄິດໄລ່ crypto ອະນຸມັດສໍາລັບ FIPS 140-2: https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf

CDETS:

• ໂຄງການ: CSC.nuova ຜະລິດຕະພັນ: ucs-blade-server ອົງປະກອບ: ucsm

ຂໍ້ມູນຈໍາເພາະຫນ້າທີ່ SED:

• EDCS: 1574090

ຂໍ້ມູນຈໍາເພາະຂອງ SED CIMC:

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

ລາຍຊື່ທາງໄປສະນີ:

• ucsm-dev@cisco.com
• ຖາມ-hci-tme@cisco.com
• ຖາມ-hci-pm@cisco.com

ເອກະສານ / ຊັບພະຍາກອນ

ແພລດຟອມຂໍ້ມູນ CISCO HyperFlex HX [pdf] ຄໍາແນະນໍາ ເວທີຂໍ້ມູນ HyperFlex HX, HyperFlex, HX Data Platform, Data Platform, Platform

ເອກະສານອ້າງອີງ

• ຄູ່ມືຜູ້ໃຊ້