ວິທີການສ້າງເພື່ອນກັບ GOST R 57580 ແລະ container virtualization. ຄໍາຕອບຂອງທະນາຄານກາງ (ແລະຄວາມຄິດຂອງພວກເຮົາກ່ຽວກັບເລື່ອງນີ້)

ບໍ່ດົນກ່ອນຫນ້ານີ້ພວກເຮົາໄດ້ດໍາເນີນການປະເມີນການປະຕິບັດຕາມຂໍ້ກໍານົດຂອງ GOST R 57580 (ຕໍ່ໄປນີ້ເອີ້ນວ່າ GOST ງ່າຍໆ). ລູກຄ້າແມ່ນບໍລິສັດທີ່ພັດທະນາລະບົບການຈ່າຍເງິນເອເລັກໂຕຣນິກ. ລະບົບແມ່ນຮ້າຍແຮງ: ຫຼາຍກວ່າ 3 ລ້ານຄົນ, ຫຼາຍກວ່າ 200 ພັນທຸລະກໍາປະຈໍາວັນ. ພວກເຂົາເອົາຄວາມປອດໄພດ້ານຂໍ້ມູນຢ່າງຈິງຈັງຢູ່ທີ່ນັ້ນ.

ໃນລະຫວ່າງການປະເມີນຜົນ, ລູກຄ້າໄດ້ປະກາດວ່າພະແນກພັດທະນາ, ນອກເຫນືອຈາກເຄື່ອງຈັກ virtual, ວາງແຜນທີ່ຈະນໍາໃຊ້ເຄື່ອງບັນຈຸ. ແຕ່ກັບເລື່ອງນີ້, ລູກຄ້າໄດ້ເພີ່ມ, ມີບັນຫາຫນຶ່ງ: ໃນ GOST ບໍ່ມີຄໍາສັບກ່ຽວກັບ Docker ດຽວກັນ. ຂ້ອຍ​ຄວນ​ເຮັດ​ແນວ​ໃດ? ວິທີການປະເມີນຄວາມປອດໄພຂອງຕູ້ຄອນເທນເນີ?

ມັນເປັນຄວາມຈິງ, GOST ພຽງແຕ່ຂຽນກ່ຽວກັບການ virtualization ຮາດແວ - ກ່ຽວກັບວິທີການປົກປ້ອງ virtual machines, hypervisor, ແລະເຄື່ອງແມ່ຂ່າຍ. ພວກເຮົາຮ້ອງຂໍໃຫ້ທະນາຄານກາງເພື່ອຄວາມກະຈ່າງແຈ້ງ. ຄໍາຕອບເຮັດໃຫ້ພວກເຮົາສັບສົນ.

GOST ແລະ virtualization

ເພື່ອເລີ່ມຕົ້ນ, ໃຫ້ພວກເຮົາຈື່ວ່າ GOST R 57580 ແມ່ນມາດຕະຖານໃຫມ່ທີ່ກໍານົດ "ຄວາມຕ້ອງການສໍາລັບການຮັບປະກັນຄວາມປອດໄພຂອງຂໍ້ມູນຂອງອົງການຈັດຕັ້ງທາງດ້ານການເງິນ" (FI). FIs ເຫຼົ່ານີ້ລວມມີຜູ້ປະຕິບັດການແລະຜູ້ເຂົ້າຮ່ວມຂອງລະບົບການຈ່າຍເງິນ, ອົງການຈັດຕັ້ງສິນເຊື່ອແລະບໍ່ແມ່ນສິນເຊື່ອ, ສູນປະຕິບັດງານແລະການເກັບກູ້.

ຕັ້ງແຕ່ວັນທີ 1 ມັງກອນ 2021, FIs ຈໍາເປັນຕ້ອງດໍາເນີນການ ການປະເມີນການປະຕິບັດຕາມຂໍ້ກໍານົດຂອງ GOST ໃຫມ່. ພວກເຮົາ, ITGLOBAL.COM, ເປັນບໍລິສັດກວດສອບທີ່ດໍາເນີນການປະເມີນຜົນດັ່ງກ່າວ.

GOST ມີສ່ວນຍ່ອຍທີ່ອຸທິດຕົນເພື່ອການປົກປ້ອງສະພາບແວດລ້ອມ virtualized - ສະບັບເລກທີ 7.8. ຄໍາວ່າ "virtualization" ບໍ່ໄດ້ລະບຸໄວ້ຢູ່ທີ່ນັ້ນ; ບໍ່ມີການແບ່ງອອກເປັນຮາດແວແລະ container virtualization. ຜູ້ຊ່ຽວຊານດ້ານໄອທີຈະເວົ້າວ່າຈາກມຸມເບິ່ງດ້ານວິຊາການນີ້ແມ່ນບໍ່ຖືກຕ້ອງ: ເຄື່ອງ virtual (VM) ແລະຕູ້ຄອນເທນເນີແມ່ນສະພາບແວດລ້ອມທີ່ແຕກຕ່າງກັນ, ມີຫຼັກການໂດດດ່ຽວທີ່ແຕກຕ່າງກັນ. ຈາກທັດສະນະຂອງຊ່ອງໂຫວ່ຂອງເຈົ້າພາບທີ່ VM ແລະ Docker containers ຖືກນໍາໄປໃຊ້, ນີ້ແມ່ນຄວາມແຕກຕ່າງທີ່ໃຫຍ່ຫຼວງ.

ມັນ turns ໃຫ້ ເຫັນ ວ່າ ການ ປະ ເມີນ ຄວາມ ປອດ ໄພ ຂອງ ຂໍ້ ມູນ ຂ່າວ ສານ ຂອງ VMs ແລະ containers ຄວນ ຈະ ແຕກ ຕ່າງ ກັນ.

ຄໍາຖາມຂອງພວກເຮົາຕໍ່ກັບທະນາຄານກາງ

ພວກເຮົາໄດ້ສົ່ງພວກເຂົາໄປຫາພະແນກຄວາມປອດໄພຂໍ້ມູນຂ່າວສານຂອງທະນາຄານກາງ (ພວກເຮົາສະເຫນີຄໍາຖາມໃນຮູບແບບຫຍໍ້).

1. ວິທີການພິຈາລະນາ Docker-type virtual containers ເມື່ອປະເມີນການປະຕິບັດຕາມ GOST? ມັນຖືກຕ້ອງບໍທີ່ຈະປະເມີນເຕັກໂນໂລຢີຕາມຂໍ້ຍ່ອຍ 7.8 ຂອງ GOST?
2. ວິທີການປະເມີນເຄື່ອງມືການຈັດການຕູ້ຄອນເທນເນີ virtual? ມັນເປັນໄປໄດ້ທີ່ຈະສົມທຽບພວກມັນກັບອົງປະກອບ virtualization ຂອງເຄື່ອງແມ່ຂ່າຍແລະປະເມີນພວກມັນຕາມພາກຍ່ອຍດຽວກັນຂອງ GOST?
3. ຂ້ອຍຈໍາເປັນຕ້ອງໄດ້ປະເມີນຄວາມປອດໄພຂອງຂໍ້ມູນພາຍໃນ Docker containers ແຍກຕ່າງຫາກບໍ? ຖ້າເປັນດັ່ງນັ້ນ, ການປ້ອງກັນອັນໃດທີ່ຄວນພິຈາລະນາສໍາລັບການນີ້ໃນລະຫວ່າງການປະເມີນຜົນ?
4. ຖ້າການບັນຈຸບັນຈຸແມ່ນເທົ່າກັບໂຄງສ້າງພື້ນຖານ virtual ແລະຖືກປະເມີນຕາມພາກຍ່ອຍ 7.8, ຂໍ້ກໍານົດ GOST ສໍາລັບການປະຕິບັດເຄື່ອງມືຄວາມປອດໄພຂໍ້ມູນພິເສດແມ່ນປະຕິບັດແນວໃດ?

ການຕອບໂຕ້ຂອງທະນາຄານກາງ

ຂ້າງລຸ່ມນີ້ແມ່ນບົດຄັດຫຍໍ້ຕົ້ນຕໍ.

"GOST R 57580.1-2017 ກໍານົດຄວາມຕ້ອງການສໍາລັບການຈັດຕັ້ງປະຕິບັດໂດຍຜ່ານການນໍາໃຊ້ມາດຕະການດ້ານວິຊາການທີ່ກ່ຽວຂ້ອງກັບມາດຕະການດັ່ງຕໍ່ໄປນີ້ ZI ຍ່ອຍ 7.8 ຂອງ GOST R 57580.1-2017, ໃນຄວາມຄິດເຫັນຂອງພະແນກ, ສາມາດຂະຫຍາຍໄດ້ກັບກໍລະນີຂອງການນໍາໃຊ້ virtualization ຕູ້ຄອນເທນເນີ. ເຕັກໂນໂລຊີ, ພິຈາລະນາດັ່ງຕໍ່ໄປນີ້:

• ການປະຕິບັດມາດຕະການ ZSV.1 - ZSV.11 ສໍາລັບການຈັດຕັ້ງການກໍານົດ, ການກວດສອບຄວາມຖືກຕ້ອງ, ການອະນຸຍາດ (ການຄວບຄຸມການເຂົ້າເຖິງ) ເມື່ອປະຕິບັດການເຂົ້າເຖິງຢ່າງມີເຫດຜົນກັບເຄື່ອງ virtual ແລະອົງປະກອບເຊີຟເວີ virtualization ອາດຈະແຕກຕ່າງຈາກກໍລະນີທີ່ໃຊ້ເທກໂນໂລຍີ virtualization container. ການພິຈາລະນານີ້, ເພື່ອປະຕິບັດມາດຕະການຈໍານວນຫນຶ່ງ (ຕົວຢ່າງ, ZVS.6 ແລະ ZVS.7), ພວກເຮົາເຊື່ອວ່າມັນເປັນໄປໄດ້ທີ່ຈະແນະນໍາໃຫ້ສະຖາບັນການເງິນພັດທະນາມາດຕະການຊົດເຊີຍທີ່ຈະປະຕິບັດເປົ້າຫມາຍດຽວກັນ;
• ການປະຕິບັດມາດຕະການ ZSV.13 - ZSV.22 ສໍາລັບອົງການຈັດຕັ້ງແລະການຄວບຄຸມການໂຕ້ຕອບຂໍ້ມູນຂ່າວສານຂອງເຄື່ອງຈັກ virtual ສະຫນອງການແບ່ງສ່ວນຂອງເຄືອຂ່າຍຄອມພິວເຕີຂອງອົງການຈັດຕັ້ງທາງດ້ານການເງິນເພື່ອຈໍາແນກລະຫວ່າງວັດຖຸຂໍ້ມູນຂ່າວສານທີ່ປະຕິບັດເຕັກໂນໂລຊີ virtualization ແລະເປັນຂອງວົງຈອນຄວາມປອດໄພທີ່ແຕກຕ່າງກັນ. ການພິຈາລະນານີ້, ພວກເຮົາເຊື່ອວ່າມັນສົມຄວນທີ່ຈະສະຫນອງການແບ່ງສ່ວນທີ່ເຫມາະສົມໃນເວລາທີ່ການນໍາໃຊ້ເທກໂນໂລຍີ virtualization ຕູ້ຄອນເທນເນີ (ທັງກ່ຽວຂ້ອງກັບຖັງ virtual ທີ່ສາມາດປະຕິບັດໄດ້ແລະກ່ຽວຂ້ອງກັບລະບົບ virtualization ທີ່ໃຊ້ໃນລະດັບລະບົບປະຕິບັດການ);
• ການປະຕິບັດມາດຕະການ ZSV.26, ZSV.29 - ZSV.31 ເພື່ອຈັດຕັ້ງການປົກປ້ອງຮູບພາບຂອງເຄື່ອງ virtual ຄວນປະຕິບັດໂດຍການປຽບທຽບເພື່ອປົກປ້ອງຮູບພາບພື້ນຖານແລະປະຈຸບັນຂອງຖັງ virtual;
• ການປະຕິບັດມາດຕະການ ZVS.32 - ZVS.43 ສໍາລັບການບັນທຶກເຫດການຄວາມປອດໄພຂອງຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັບການເຂົ້າເຖິງເຄື່ອງ virtual ແລະອົງປະກອບ virtualization ຂອງເຄື່ອງແມ່ຂ່າຍຄວນໄດ້ຮັບການປະຕິບັດໂດຍການປຽບທຽບກັບອົງປະກອບຂອງສະພາບແວດລ້ອມ virtualization ທີ່ປະຕິບັດເທກໂນໂລຍີ virtualization container.

ມັນ ໝາຍ ຄວາມວ່າແນວໃດ

ສອງບົດສະຫຼຸບຕົ້ນຕໍຈາກການຕອບໂຕ້ຂອງກົມຄວາມປອດໄພຂໍ້ມູນຂ່າວສານທະນາຄານກາງ:

• ມາດຕະການປົກປ້ອງເຄື່ອງບັນຈຸບໍ່ແຕກຕ່າງຈາກມາດຕະການປ້ອງກັນເຄື່ອງ virtual;
• ມັນປະຕິບັດຕາມນີ້ວ່າ, ໃນສະພາບການຄວາມປອດໄພຂອງຂໍ້ມູນ, ທະນາຄານກາງເທົ່າກັບສອງປະເພດຂອງ virtualization - Docker containers ແລະ VMs.

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

ຕໍາແໜ່ງທະນາຄານກາງແມ່ນຫຍັງ?

ຖ້າທ່ານໃຊ້ຄໍາແນະນໍາຂອງທະນາຄານກາງໃນລະຫວ່າງການປະເມີນ (ແລະການປະເມີນຕົນເອງ), ທ່ານຈໍາເປັນຕ້ອງແກ້ໄຂຄວາມຫຍຸ້ງຍາກທາງດ້ານເຕັກນິກແລະເຫດຜົນຈໍານວນຫນຶ່ງ.

• ແຕ່ລະຕູ້ຄອນເທນເນີທີ່ສາມາດປະຕິບັດໄດ້ຮຽກຮ້ອງໃຫ້ມີການຕິດຕັ້ງຊອບແວປ້ອງກັນຂໍ້ມູນ (IP) ເທິງມັນ: antivirus, ການກວດສອບຄວາມສົມບູນ, ການເຮັດວຽກກັບບັນທຶກ, ລະບົບ DLP (ການປ້ອງກັນຂໍ້ມູນຮົ່ວໄຫຼ), ແລະອື່ນໆ. ທັງຫມົດນີ້ສາມາດຕິດຕັ້ງຢູ່ໃນ VM ໂດຍບໍ່ມີບັນຫາໃດໆ, ແຕ່ໃນກໍລະນີຂອງຕູ້ຄອນເທນເນີ, ການຕິດຕັ້ງຄວາມປອດໄພຂອງຂໍ້ມູນແມ່ນການເຄື່ອນໄຫວທີ່ໂງ່. ຖັງບັນຈຸມີຈໍານວນຕໍາ່ສຸດທີ່ຂອງ "ຊຸດຮ່າງກາຍ" ທີ່ຈໍາເປັນສໍາລັບການບໍລິການເຮັດວຽກ. ການຕິດຕັ້ງ SZI ໃນມັນກົງກັນຂ້າມກັບຄວາມຫມາຍຂອງມັນ.
• ຮູບພາບຕູ້ຄອນເທນເນີຄວນໄດ້ຮັບການປົກປ້ອງຕາມຫຼັກການດຽວກັນ, ວິທີການປະຕິບັດນີ້ແມ່ນບໍ່ຊັດເຈນ.
• GOST ຮຽກຮ້ອງໃຫ້ມີການຈໍາກັດການເຂົ້າເຖິງອົງປະກອບ virtualization ຂອງເຄື່ອງແມ່ຂ່າຍ, i.e., ກັບ hypervisor. ສິ່ງທີ່ຖືວ່າເປັນອົງປະກອບຂອງເຄື່ອງແມ່ຂ່າຍໃນກໍລະນີຂອງ Docker? ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າແຕ່ລະ container ຈໍາເປັນຕ້ອງດໍາເນີນການຢູ່ໃນ host ແຍກຕ່າງຫາກ?
• ຖ້າສໍາລັບການ virtualization ທໍາມະດາມັນເປັນໄປໄດ້ທີ່ຈະຈໍາກັດ VMs ໂດຍ contours ຄວາມປອດໄພແລະສ່ວນເຄືອຂ່າຍ, ຫຼັງຈາກນັ້ນໃນກໍລະນີຂອງ Docker containers ພາຍໃນ host ດຽວກັນ, ນີ້ບໍ່ແມ່ນກໍລະນີ.

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

ໃນກໍລະນີໃດກໍ່ຕາມ, ພວກເຮົາຈະເພີ່ມວ່າຕັ້ງແຕ່ວັນທີ 1 ມັງກອນ 2021, ຄະແນນຕໍ່າສຸດຈະຕ້ອງບໍ່ຕໍ່າກວ່າ 0,7.

ໂດຍວິທີທາງການ, ພວກເຮົາປະກາດຄໍາຕອບແລະຄໍາເຫັນຢ່າງເປັນປົກກະຕິຈາກຜູ້ຄວບຄຸມທີ່ກ່ຽວຂ້ອງກັບຂໍ້ກໍານົດຂອງ GOST 57580 ແລະກົດລະບຽບຂອງທະນາຄານກາງຂອງພວກເຮົາ. ຊ່ອງ Telegram.

ສິ່ງທີ່ຕ້ອງເຮັດ

ໃນຄວາມຄິດເຫັນຂອງພວກເຮົາ, ອົງການຈັດຕັ້ງທາງດ້ານການເງິນມີພຽງແຕ່ສອງທາງເລືອກໃນການແກ້ໄຂບັນຫາ.

1. ຫຼີກເວັ້ນການປະຕິບັດພາຊະນະ

ການແກ້ໄຂສໍາລັບຜູ້ທີ່ກຽມພ້ອມທີ່ຈະໃຊ້ພຽງແຕ່ຮາດແວ virtualization ແລະໃນເວລາດຽວກັນຢ້ານການຈັດອັນດັບຕໍ່າຕາມ GOST ແລະການປັບໄຫມຈາກທະນາຄານກາງ.

ບວກ: ມັນງ່າຍຕໍ່ການປະຕິບັດຕາມຂໍ້ກໍານົດຂອງພາກຍ່ອຍ 7.8 ຂອງ GOST.

ລົບ: ພວກເຮົາຈະຕ້ອງປະຖິ້ມເຄື່ອງມືພັດທະນາໃໝ່ໂດຍອີງໃສ່ container virtualization, ໂດຍສະເພາະ Docker ແລະ Kubernetes.

2. ປະຕິເສດການປະຕິບັດຕາມຂໍ້ກໍານົດຂອງພາກຍ່ອຍ 7.8 ຂອງ GOST

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

• ຄວາມປອດໄພຂອງ host OS, ການຕັດໄມ້ທີ່ຖືກຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ, ການຫ້າມການແລກປ່ຽນຂໍ້ມູນລະຫວ່າງບັນຈຸ, ແລະອື່ນໆ;
• ການນໍາໃຊ້ຟັງຊັນ Docker Trust ເພື່ອກວດເບິ່ງຄວາມສົມບູນຂອງຮູບພາບແລະການນໍາໃຊ້ຕົວສະແກນຊ່ອງໂຫວ່ໃນຕົວ;
• ພວກເຮົາຕ້ອງບໍ່ລືມກ່ຽວກັບຄວາມປອດໄພຂອງການເຂົ້າເຖິງຫ່າງໄກສອກຫຼີກແລະຮູບແບບເຄືອຂ່າຍທັງຫມົດ: ການໂຈມຕີເຊັ່ນ: ARP-spoofing ແລະ MAC-flooding ບໍ່ໄດ້ຖືກຍົກເລີກ.

ບວກ: ບໍ່ມີຂໍ້ຈໍາກັດດ້ານວິຊາການກ່ຽວກັບການນໍາໃຊ້ virtualization ຕູ້ຄອນເທນເນີ.

ລົບ: ມີຄວາມເປັນໄປໄດ້ສູງທີ່ຜູ້ຄວບຄຸມຈະລົງໂທດສໍາລັບການບໍ່ປະຕິບັດຕາມຂໍ້ກໍານົດຂອງ GOST.

ສະຫລຸບ

ລູກຄ້າຂອງພວກເຮົາໄດ້ຕັດສິນໃຈທີ່ຈະບໍ່ໃຫ້ບັນຈຸບັນຈຸ. ໃນເວລາດຽວກັນ, ລາວຕ້ອງໄດ້ພິຈາລະນາຄືນໃຫມ່ຢ່າງຫຼວງຫຼາຍກ່ຽວກັບຂອບເຂດຂອງການເຮັດວຽກແລະໄລຍະເວລາຂອງການຫັນປ່ຽນໄປສູ່ Docker (ພວກເຂົາໃຊ້ເວລາຫົກເດືອນ). ລູກຄ້າເຂົ້າໃຈຄວາມສ່ຽງໄດ້ດີ. ລາວຍັງເຂົ້າໃຈວ່າໃນລະຫວ່າງການປະເມີນຜົນຕໍ່ໄປຂອງການປະຕິບັດຕາມ GOST R 57580, ສ່ວນຫຼາຍແມ່ນຂຶ້ນກັບຜູ້ກວດສອບ.

ເຈົ້າຈະເຮັດແນວໃດໃນສະຖານະການນີ້?

ແຫຼ່ງຂໍ້ມູນ: www.habr.com