🥇ການຕິດຕາມຄວາມປອດໄພຂອງຄລາວ

ການເຄື່ອນຍ້າຍຂໍ້ມູນແລະແອັບພລິເຄຊັນໄປສູ່ຄລາວສະເຫນີສິ່ງທ້າທາຍໃຫມ່ສໍາລັບ SOCs ຂອງບໍລິສັດ, ເຊິ່ງບໍ່ສະເຫມີພ້ອມທີ່ຈະຕິດຕາມໂຄງສ້າງພື້ນຖານຂອງຄົນອື່ນ. ອີງຕາມ Netoskope, ວິສາຫະກິດສະເລ່ຍ (ປາກົດຂື້ນຢູ່ໃນສະຫະລັດ) ໃຊ້ 1246 ການບໍລິການຟັງທີ່ແຕກຕ່າງກັນ, ເຊິ່ງແມ່ນ 22% ຫຼາຍກວ່າປີກ່ອນ. 1246 ບໍລິການຄລາວ!!! 175 ຂອງພວກເຂົາກ່ຽວຂ້ອງກັບການບໍລິການ HR, 170 ແມ່ນກ່ຽວຂ້ອງກັບການຕະຫຼາດ, 110 ແມ່ນໃນຂົງເຂດການສື່ສານແລະ 76 ແມ່ນໃນດ້ານການເງິນແລະ CRM. Cisco ໃຊ້ "ພຽງແຕ່" 700 ບໍລິການຄລາວພາຍນອກ. ສະນັ້ນຂ້າພະເຈົ້າສັບສົນເລັກນ້ອຍໂດຍຕົວເລກເຫຼົ່ານີ້. ແຕ່ໃນກໍລະນີໃດກໍ່ຕາມ, ບັນຫາບໍ່ແມ່ນຢູ່ກັບພວກເຂົາ, ແຕ່ຄວາມຈິງທີ່ວ່າ cloud ກໍາລັງເລີ່ມຖືກນໍາໃຊ້ຢ່າງຫ້າວຫັນໂດຍບໍລິສັດຈໍານວນເພີ່ມຂຶ້ນທີ່ຢາກມີຄວາມສາມາດດຽວກັນໃນການກວດສອບໂຄງສ້າງພື້ນຖານຂອງຄລາວໃນເຄືອຂ່າຍຂອງຕົນເອງ. ແລະແນວໂນ້ມນີ້ແມ່ນການຂະຫຍາຍຕົວ - ອີງຕາມ ອີງຕາມສະພາການບັນຊີອາເມລິກາ ໃນປີ 2023, ສູນຂໍ້ມູນ 1200 ແຫ່ງຈະຖືກປິດໃນສະຫະລັດ (6250 ໄດ້ປິດແລ້ວ). ແຕ່ການຫັນປ່ຽນໄປສູ່ຄລາວບໍ່ພຽງແຕ່ "ໃຫ້ຍ້າຍເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາໄປຫາຜູ້ໃຫ້ບໍລິການພາຍນອກ." ສະຖາປັດຕະຍະກໍາ IT ໃຫມ່, ຊອບແວໃຫມ່, ຂະບວນການໃຫມ່, ຂໍ້ຈໍາກັດໃຫມ່ ... ທັງຫມົດນີ້ນໍາເອົາການປ່ຽນແປງທີ່ສໍາຄັນໃນການເຮັດວຽກຂອງບໍ່ພຽງແຕ່ IT, ແຕ່ຍັງຄວາມປອດໄພຂອງຂໍ້ມູນຂ່າວສານ. ແລະຖ້າຜູ້ໃຫ້ບໍລິການໄດ້ຮຽນຮູ້ວິທີການຮັບມືກັບການຮັບປະກັນຄວາມປອດໄພຂອງຄລາວເອງ (ໂຊກດີທີ່ມີຂໍ້ສະເຫນີແນະຫຼາຍຢ່າງ), ຫຼັງຈາກນັ້ນ, ດ້ວຍການຕິດຕາມຄວາມປອດໄພຂອງຂໍ້ມູນຄລາວ, ໂດຍສະເພາະໃນແພລະຕະຟອມ SaaS, ມີຄວາມຫຍຸ້ງຍາກຢ່າງຫຼວງຫຼາຍ, ເຊິ່ງພວກເຮົາຈະເວົ້າກ່ຽວກັບ.

ສົມມຸດວ່າບໍລິສັດຂອງເຈົ້າໄດ້ຍ້າຍສ່ວນຫນຶ່ງຂອງໂຄງສ້າງພື້ນຖານຂອງຕົນໄປສູ່ຄລາວ ... ຢຸດ. ບໍ່ແມ່ນທາງນີ້. ຖ້າຫາກວ່າໂຄງສ້າງພື້ນຖານໄດ້ຖືກຍົກຍ້າຍ, ແລະທ່ານພຽງແຕ່ໃນປັດຈຸບັນຄິດກ່ຽວກັບວິທີທີ່ທ່ານຈະຕິດຕາມກວດກາມັນ, ຫຼັງຈາກນັ້ນທ່ານໄດ້ສູນເສຍແລ້ວ. ເວັ້ນເສຍແຕ່ວ່າມັນເປັນ Amazon, Google, ຫຼື Microsoft (ແລະຫຼັງຈາກນັ້ນດ້ວຍການຈອງ), ທ່ານອາດຈະບໍ່ມີຄວາມສາມາດໃນການຕິດຕາມຂໍ້ມູນແລະຄໍາຮ້ອງສະຫມັກຂອງທ່ານ. ມັນດີຖ້າທ່ານໄດ້ຮັບໂອກາດທີ່ຈະເຮັດວຽກກັບບັນທຶກ. ບາງຄັ້ງຂໍ້ມູນເຫດການຄວາມປອດໄພຈະມີໃຫ້, ແຕ່ທ່ານຈະບໍ່ມີການເຂົ້າເຖິງມັນ. ຕົວຢ່າງເຊັ່ນ Office 365. ຖ້າທ່ານມີໃບອະນຸຍາດ E1 ລາຄາຖືກທີ່ສຸດ, ຫຼັງຈາກນັ້ນເຫດການຄວາມປອດໄພແມ່ນບໍ່ມີໃຫ້ທ່ານເລີຍ. ຖ້າທ່ານມີໃບອະນຸຍາດ E3, ຂໍ້ມູນຂອງທ່ານຖືກເກັບໄວ້ພຽງແຕ່ 90 ມື້, ແລະພຽງແຕ່ຖ້າທ່ານມີໃບອະນຸຍາດ E5, ໄລຍະເວລາຂອງບັນທຶກແມ່ນມີຢູ່ສໍາລັບປີ (ຢ່າງໃດກໍ່ຕາມ, ນີ້ຍັງມີ nuances ຂອງຕົນເອງທີ່ກ່ຽວຂ້ອງກັບຄວາມຕ້ອງການແຍກຕ່າງຫາກ. ຮ້ອງຂໍຈໍານວນຂອງຫນ້າທີ່ສໍາລັບການເຮັດວຽກກັບບັນທຶກຈາກສະຫນັບສະຫນູນ Microsoft). ໂດຍວິທີທາງການ, ໃບອະນຸຍາດ E3 ແມ່ນມີຄວາມອ່ອນແອຫຼາຍໃນແງ່ຂອງຫນ້າທີ່ຕິດຕາມຫຼາຍກ່ວາບໍລິສັດແລກປ່ຽນ. ເພື່ອບັນລຸລະດັບດຽວກັນ, ທ່ານຕ້ອງການໃບອະນຸຍາດ E5 ຫຼືໃບອະນຸຍາດການປະຕິບັດຕາມແບບພິເສດເພີ່ມເຕີມ, ເຊິ່ງອາດຈະຕ້ອງການເງິນເພີ່ມເຕີມທີ່ບໍ່ໄດ້ເຂົ້າໄປໃນຕົວແບບທາງດ້ານການເງິນຂອງທ່ານເພື່ອຍ້າຍໄປສູ່ພື້ນຖານໂຄງລ່າງຄລາວ. ແລະນີ້ແມ່ນພຽງແຕ່ຫນຶ່ງຕົວຢ່າງຂອງການປະເມີນຫນ້ອຍກ່ຽວກັບບັນຫາທີ່ກ່ຽວຂ້ອງກັບການຕິດຕາມຄວາມປອດໄພຂອງຂໍ້ມູນເມຄ. ໃນບົດຄວາມນີ້, ໂດຍບໍ່ມີການທໍາທ່າວ່າສົມບູນ, ຂ້າພະເຈົ້າຕ້ອງການທີ່ຈະດຶງດູດຄວາມສົນໃຈກັບ nuances ບາງຢ່າງທີ່ຄວນຈະໄດ້ຮັບການພິຈາລະນາໃນເວລາທີ່ເລືອກຜູ້ໃຫ້ບໍລິການຟັງຈາກຈຸດຄວາມປອດໄພຂອງທັດສະນະ. ແລະໃນຕອນທ້າຍຂອງບົດຄວາມ, ບັນຊີລາຍຊື່ການກວດສອບຈະໄດ້ຮັບທີ່ມີມູນຄ່າສໍາເລັດກ່ອນທີ່ຈະພິຈາລະນາວ່າບັນຫາການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນເມຄໄດ້ຖືກແກ້ໄຂແລ້ວ.

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

ບໍ່ມີບັນທຶກຄວາມປອດໄພ. ນີ້ແມ່ນສະຖານະການທີ່ພົບທົ່ວໄປ, ໂດຍສະເພາະແມ່ນໃນບັນດາຜູ້ນຈົວໃນຕະຫຼາດການແກ້ໄຂຟັງ. ແຕ່ທ່ານບໍ່ຄວນປະຖິ້ມພວກເຂົາທັນທີ. ຜູ້ນຂະຫນາດນ້ອຍ, ໂດຍສະເພາະແມ່ນພາຍໃນປະເທດ, ມີຄວາມອ່ອນໄຫວຕໍ່ກັບຄວາມຕ້ອງການຂອງລູກຄ້າແລະສາມາດປະຕິບັດບາງຫນ້າທີ່ທີ່ກໍານົດໄວ້ຢ່າງໄວວາໂດຍການປ່ຽນແປງແຜນທີ່ເສັ້ນທາງທີ່ໄດ້ຮັບການອະນຸມັດສໍາລັບຜະລິດຕະພັນຂອງພວກເຂົາ. ແມ່ນແລ້ວ, ນີ້ຈະບໍ່ເປັນການປຽບທຽບຂອງ GuardDuty ຈາກ Amazon ຫຼືໂມດູນ "Proactive Protection" ຈາກ Bitrix, ແຕ່ຢ່າງຫນ້ອຍບາງສິ່ງບາງຢ່າງ.
ຄວາມປອດໄພຂອງຂໍ້ມູນຂ່າວສານບໍ່ຮູ້ວ່າຂໍ້ມູນບັນທຶກໄດ້ຖືກເກັບຮັກສາໄວ້ຫຼືບໍ່ມີການເຂົ້າເຖິງໃຫ້ເຂົາເຈົ້າ. ໃນທີ່ນີ້ມັນຈໍາເປັນຕ້ອງເຂົ້າໄປໃນການເຈລະຈາກັບຜູ້ໃຫ້ບໍລິການຟັງ - ບາງທີລາວອາດຈະໃຫ້ຂໍ້ມູນດັ່ງກ່າວຖ້າລາວຖືວ່າລູກຄ້າມີຄວາມສໍາຄັນກັບລາວ. ແຕ່ໂດຍທົ່ວໄປ, ມັນບໍ່ດີຫຼາຍເມື່ອການເຂົ້າເຖິງບັນທຶກໄດ້ຖືກສະຫນອງໃຫ້ "ໂດຍການຕັດສິນໃຈພິເສດ."
ມັນຍັງເກີດຂື້ນວ່າຜູ້ໃຫ້ບໍລິການຟັງມີບັນທຶກ, ແຕ່ພວກເຂົາສະຫນອງການຕິດຕາມແລະບັນທຶກເຫດການທີ່ຈໍາກັດ, ເຊິ່ງບໍ່ພຽງພໍທີ່ຈະກວດພົບເຫດການທັງຫມົດ. ຕົວຢ່າງ, ທ່ານອາດຈະໄດ້ຮັບພຽງແຕ່ບັນທຶກການປ່ຽນແປງຢູ່ໃນເວັບໄຊທ໌ຫຼືບັນທຶກຂອງຄວາມພະຍາຍາມກວດສອບຜູ້ໃຊ້, ແຕ່ບໍ່ແມ່ນເຫດການອື່ນໆ, ເຊັ່ນວ່າການຈະລາຈອນໃນເຄືອຂ່າຍ, ເຊິ່ງຈະເຊື່ອງຈາກທ່ານທຸກຊັ້ນຂອງເຫດການທີ່ມີລັກສະນະຄວາມພະຍາຍາມທີ່ຈະ hack ໂຄງລ່າງຄລາວຂອງທ່ານ.
ມີບັນທຶກ, ແຕ່ການເຂົ້າເຖິງພວກມັນແມ່ນຍາກທີ່ຈະເຮັດໃຫ້ອັດຕະໂນມັດ, ເຊິ່ງບັງຄັບໃຫ້ພວກເຂົາຖືກຕິດຕາມຢ່າງຕໍ່ເນື່ອງ, ແຕ່ຢູ່ໃນຕາຕະລາງ. ແລະຖ້າທ່ານບໍ່ສາມາດດາວໂຫລດບັນທຶກອັດຕະໂນມັດ, ຕົວຢ່າງ, ການດາວໂຫລດບັນທຶກ, ໃນຮູບແບບ Excel (ເຊັ່ນດຽວກັບຜູ້ໃຫ້ບໍລິການແກ້ໄຂຄລາວຈໍານວນຫນຶ່ງ), ອາດຈະເຮັດໃຫ້ເກີດຄວາມລັງເລໃນສ່ວນຂອງການບໍລິການຄວາມປອດໄພຂອງຂໍ້ມູນຂອງບໍລິສັດທີ່ຈະ tinker ກັບພວກເຂົາ.
ບໍ່ມີການຕິດຕາມບັນທຶກ. ນີ້ແມ່ນບາງທີອາດເປັນເຫດຜົນທີ່ບໍ່ຊັດເຈນທີ່ສຸດສໍາລັບການປະກົດຕົວຂອງເຫດການຄວາມປອດໄພຂໍ້ມູນໃນສະພາບແວດລ້ອມຟັງ. ມັນເບິ່ງຄືວ່າມີບັນທຶກ, ແລະມັນເປັນໄປໄດ້ທີ່ຈະອັດຕະໂນມັດການເຂົ້າເຖິງພວກມັນ, ແຕ່ບໍ່ມີໃຜເຮັດສິ່ງນີ້. ເປັນຫຍັງ?

ແບ່ງປັນແນວຄວາມຄິດຄວາມປອດໄພຄລາວ

ການຫັນປ່ຽນໄປສູ່ຄລາວແມ່ນສະເຫມີຊອກຫາຄວາມສົມດູນລະຫວ່າງຄວາມປາຖະຫນາທີ່ຈະຮັກສາການຄວບຄຸມໂຄງສ້າງພື້ນຖານແລະການໂອນມັນໄປສູ່ມືທີ່ມີຄວາມເປັນມືອາຊີບຫຼາຍຂອງຜູ້ໃຫ້ບໍລິການຟັງທີ່ມີຄວາມຊ່ຽວຊານໃນການຮັກສາມັນ. ແລະໃນຂົງເຂດຄວາມປອດໄພຂອງເມຄ, ຄວາມສົມດຸນນີ້ຍັງຕ້ອງໄດ້ຮັບການຊອກຫາ. ຍິ່ງໄປກວ່ານັ້ນ, ອີງຕາມຮູບແບບການຈັດສົ່ງການບໍລິການຄລາວທີ່ໃຊ້ (IaaS, PaaS, SaaS), ຍອດເງິນນີ້ຈະແຕກຕ່າງກັນຕະຫຼອດເວລາ. ໃນກໍລະນີໃດກໍ່ຕາມ, ພວກເຮົາຕ້ອງຈື່ໄວ້ວ່າຜູ້ໃຫ້ບໍລິການຟັງທັງຫມົດໃນມື້ນີ້ປະຕິບັດຕາມອັນທີ່ເອີ້ນວ່າຄວາມຮັບຜິດຊອບຮ່ວມກັນແລະຮູບແບບຄວາມປອດໄພຂອງຂໍ້ມູນຮ່ວມກັນ. ຟັງແມ່ນຮັບຜິດຊອບບາງສິ່ງ, ແລະສໍາລັບຄົນອື່ນ, ລູກຄ້າຮັບຜິດຊອບ, ວາງຂໍ້ມູນຂອງລາວ, ຄໍາຮ້ອງສະຫມັກຂອງລາວ, ເຄື່ອງ virtual ຂອງລາວແລະຊັບພະຍາກອນອື່ນໆໃນຄລາວ. ມັນຄົງຈະເປັນເລື່ອງທີ່ບໍ່ຄາດຄິດທີ່ຈະຄາດຫວັງວ່າການໄປຟັງ, ພວກເຮົາຈະປ່ຽນຄວາມຮັບຜິດຊອບທັງໝົດໃຫ້ກັບຜູ້ໃຫ້ບໍລິການ. ແຕ່ມັນກໍ່ເປັນເລື່ອງທີ່ບໍ່ສະຫຼາດທີ່ຈະສ້າງຄວາມປອດໄພທັງໝົດດ້ວຍຕົວເອງເມື່ອຍ້າຍໄປຢູ່ຄລາວ. ການດຸ່ນດ່ຽງແມ່ນຕ້ອງການ, ເຊິ່ງຈະຂຶ້ນກັບຫຼາຍປັດໃຈ: - ຍຸດທະສາດການຄຸ້ມຄອງຄວາມສ່ຽງ, ຮູບແບບໄພຂົ່ມຂູ່, ກົນໄກຄວາມປອດໄພທີ່ມີຢູ່ກັບຜູ້ໃຫ້ບໍລິການຟັງ, ນິຕິກໍາ, ແລະອື່ນໆ.

ຕົວຢ່າງ, ການຈັດປະເພດຂອງຂໍ້ມູນທີ່ໂຮດຢູ່ໃນຄລາວແມ່ນຄວາມຮັບຜິດຊອບຂອງລູກຄ້າສະເຫມີ. ຜູ້ໃຫ້ບໍລິການຄລາວຫຼືຜູ້ໃຫ້ບໍລິການພາຍນອກພຽງແຕ່ສາມາດຊ່ວຍລາວດ້ວຍເຄື່ອງມືທີ່ຈະຊ່ວຍໃຫ້ເຄື່ອງຫມາຍຂໍ້ມູນໃນຄລາວ, ລະບຸການລະເມີດ, ລຶບຂໍ້ມູນທີ່ລະເມີດກົດຫມາຍ, ຫຼືປິດບັງມັນໂດຍໃຊ້ວິທີຫນຶ່ງຫຼືອື່ນ. ໃນທາງກົງກັນຂ້າມ, ຄວາມປອດໄພທາງດ້ານຮ່າງກາຍແມ່ນຄວາມຮັບຜິດຊອບຂອງຜູ້ໃຫ້ບໍລິການຟັງ, ເຊິ່ງມັນບໍ່ສາມາດແບ່ງປັນກັບລູກຄ້າໄດ້. ແຕ່ທຸກສິ່ງທຸກຢ່າງທີ່ຢູ່ລະຫວ່າງຂໍ້ມູນແລະໂຄງສ້າງທາງກາຍະພາບແມ່ນແນ່ນອນຂອງການສົນທະນາໃນບົດຄວາມນີ້. ຕົວຢ່າງ, ຄວາມພ້ອມຂອງຄລາວແມ່ນຄວາມຮັບຜິດຊອບຂອງຜູ້ໃຫ້ບໍລິການ, ແລະການຕັ້ງຄ່າກົດລະບຽບຂອງໄຟວໍຫຼືການເປີດໃຊ້ການເຂົ້າລະຫັດແມ່ນຄວາມຮັບຜິດຊອບຂອງລູກຄ້າ. ໃນບົດຄວາມນີ້ພວກເຮົາຈະພະຍາຍາມເບິ່ງວ່າກົນໄກການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນໃດທີ່ສະຫນອງໃຫ້ໂດຍຜູ້ໃຫ້ບໍລິການຟັງທີ່ນິຍົມໃນລັດເຊຍໃນມື້ນີ້, ຄຸນລັກສະນະຂອງການນໍາໃຊ້ຂອງພວກເຂົາແມ່ນຫຍັງ, ແລະເວລາໃດທີ່ມັນຄຸ້ມຄ່າທີ່ຈະຊອກຫາວິທີແກ້ໄຂພາຍນອກ (ຕົວຢ່າງ Cisco E- mail Security) ທີ່ຂະຫຍາຍຄວາມສາມາດຂອງ cloud ຂອງທ່ານໃນດ້ານຄວາມປອດໄພທາງໄຊເບີ. ໃນບາງກໍລະນີ, ໂດຍສະເພາະຖ້າຫາກວ່າທ່ານກໍາລັງປະຕິບັດຕາມຍຸດທະສາດຫຼາຍຄລາວ, ທ່ານຈະບໍ່ມີທາງເລືອກນອກຈາກການນໍາໃຊ້ວິທີແກ້ໄຂຄວາມປອດໄພຂອງຂໍ້ມູນພາຍນອກໃນສະພາບແວດລ້ອມຟັງຫຼາຍຄັ້ງ (ຕົວຢ່າງເຊັ່ນ Cisco CloudLock ຫຼື Cisco Stealthwatch Cloud). ດີ, ໃນບາງກໍລະນີ, ທ່ານຈະຮັບຮູ້ວ່າຜູ້ໃຫ້ບໍລິການຟັງທີ່ທ່ານເລືອກ (ຫຼືບັງຄັບໃຫ້ທ່ານ) ບໍ່ໄດ້ສະເຫນີຄວາມສາມາດໃນການກວດສອບຄວາມປອດໄພຂໍ້ມູນໃດໆ. ນີ້ແມ່ນຄວາມບໍ່ພໍໃຈ, ແຕ່ບໍ່ແມ່ນເລັກນ້ອຍ, ເພາະວ່າມັນຊ່ວຍໃຫ້ທ່ານສາມາດປະເມີນລະດັບຄວາມສ່ຽງທີ່ກ່ຽວຂ້ອງກັບການເຮັດວຽກກັບຟັງໄດ້ຢ່າງພຽງພໍ.

ວົງຈອນຊີວິດການຕິດຕາມຄວາມປອດໄພຄລາວ

ເພື່ອຕິດຕາມຄວາມປອດໄພຂອງເມຄທີ່ທ່ານໃຊ້, ທ່ານມີສາມທາງເລືອກເທົ່ານັ້ນ:

ອີງໃສ່ເຄື່ອງມືທີ່ສະໜອງໃຫ້ໂດຍຜູ້ໃຫ້ບໍລິການຄລາວຂອງທ່ານ,
ໃຊ້ວິທີແກ້ໄຂຈາກພາກສ່ວນທີສາມທີ່ຈະຕິດຕາມເວທີ IaaS, PaaS ຫຼື SaaS ທີ່ທ່ານໃຊ້,
ສ້າງພື້ນຖານໂຄງລ່າງການຕິດຕາມຟັງຄລາວຂອງທ່ານເອງ (ພຽງແຕ່ສໍາລັບແພລະຕະຟອມ IaaS/PaaS).

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

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

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

ການບໍລິການຄລາວໃນຕົວ

ຂ້າພະເຈົ້າໄດ້ຂຽນໄວ້ຂ້າງເທິງວ່າການບໍລິການຟັງຈໍານວນຫຼາຍໃນມື້ນີ້ບໍ່ໄດ້ສະຫນອງຄວາມສາມາດໃນການກວດສອບຄວາມປອດໄພຂໍ້ມູນໃດໆ. ໂດຍທົ່ວໄປ, ພວກເຂົາບໍ່ໄດ້ເອົາໃຈໃສ່ຫຼາຍກ່ຽວກັບຫົວຂໍ້ຄວາມປອດໄພຂອງຂໍ້ມູນ. ຕົວຢ່າງ, ຫນຶ່ງໃນການບໍລິການທີ່ນິຍົມລັດເຊຍສໍາລັບການສົ່ງບົດລາຍງານກັບອົງການຂອງລັດຖະບານຜ່ານທາງອິນເຕີເນັດ (ຂ້າພະເຈົ້າຈະບໍ່ໄດ້ກ່າວເຖິງຊື່ຂອງມັນໂດຍສະເພາະ). ພາກສ່ວນທັງຫມົດກ່ຽວກັບຄວາມປອດໄພຂອງການບໍລິການນີ້ revolves ປະມານການນໍາໃຊ້ຂອງ CIPF ຢັ້ງຢືນ. ພາກສ່ວນຄວາມປອດໄພຂໍ້ມູນຂ່າວສານຂອງບໍລິການຟັງພາຍໃນປະເທດອື່ນສໍາລັບການຄຸ້ມຄອງເອກະສານເອເລັກໂຕຣນິກແມ່ນບໍ່ແຕກຕ່າງກັນ. ມັນເວົ້າກ່ຽວກັບໃບຢັ້ງຢືນລະຫັດສາທາລະນະ, ການເຂົ້າລະຫັດລັບທີ່ໄດ້ຮັບການຮັບຮອງ, ການກໍາຈັດຄວາມອ່ອນແອຂອງເວັບ, ການປ້ອງກັນການໂຈມຕີ DDoS, ການໃຊ້ໄຟວໍ, ການສໍາຮອງຂໍ້ມູນ, ແລະແມ້ກະທັ້ງການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນປົກກະຕິ. ແຕ່ບໍ່ມີຄໍາເວົ້າກ່ຽວກັບການຕິດຕາມ, ຫຼືກ່ຽວກັບຄວາມເປັນໄປໄດ້ຂອງການເຂົ້າເຖິງເຫດການຄວາມປອດໄພຂອງຂໍ້ມູນທີ່ອາດຈະມີຄວາມສົນໃຈກັບລູກຄ້າຂອງຜູ້ໃຫ້ບໍລິການນີ້.

ໂດຍທົ່ວໄປແລ້ວ, ໂດຍວິທີການທີ່ຜູ້ໃຫ້ບໍລິການຟັງອະທິບາຍບັນຫາຄວາມປອດໄພຂອງຂໍ້ມູນຢູ່ໃນເວັບໄຊທ໌ແລະໃນເອກະສານຂອງມັນ, ທ່ານສາມາດເຂົ້າໃຈໄດ້ວ່າມັນເອົາບັນຫານີ້ຢ່າງຮຸນແຮງເທົ່າໃດ. ຕົວຢ່າງ, ຖ້າທ່ານອ່ານຄູ່ມືສໍາລັບຜະລິດຕະພັນ "ຫ້ອງການຂອງຂ້ອຍ", ບໍ່ມີຄໍາເວົ້າກ່ຽວກັບຄວາມປອດໄພທັງຫມົດ, ແຕ່ວ່າໃນເອກະສານສໍາລັບຜະລິດຕະພັນແຍກຕ່າງຫາກ "ຫ້ອງການຂອງຂ້ອຍ. KS3”, ຖືກອອກແບບມາເພື່ອປ້ອງກັນການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ, ມີລາຍການປົກກະຕິຂອງຈຸດຂອງຄໍາສັ່ງທີ 17 ຂອງ FSTEC, ເຊິ່ງ "My Office.KS3" ປະຕິບັດ, ແຕ່ມັນບໍ່ໄດ້ຖືກອະທິບາຍວ່າມັນປະຕິບັດມັນແນວໃດແລະ, ສໍາຄັນທີ່ສຸດ, ວິທີການ. ປະສົມປະສານກົນໄກເຫຼົ່ານີ້ກັບຄວາມປອດໄພຂອງຂໍ້ມູນຂອງບໍລິສັດ. ບາງທີເອກະສານດັ່ງກ່າວມີຢູ່, ແຕ່ຂ້ອຍບໍ່ພົບມັນຢູ່ໃນສາທາລະນະ, ຢູ່ໃນເວັບໄຊທ໌ "ຫ້ອງການຂອງຂ້ອຍ". ເຖິງແມ່ນວ່າບາງທີຂ້າພະເຈົ້າພຽງແຕ່ບໍ່ມີການເຂົ້າເຖິງຂໍ້ມູນລັບນີ້?

ສໍາລັບ Bitrix, ສະຖານະການແມ່ນດີຂຶ້ນຫຼາຍ. ເອກະສານອະທິບາຍຮູບແບບຂອງບັນທຶກເຫດການແລະ, ຫນ້າສົນໃຈ, ບັນທຶກການບຸກລຸກ, ເຊິ່ງປະກອບດ້ວຍເຫດການທີ່ກ່ຽວຂ້ອງກັບໄພຂົ່ມຂູ່ທີ່ອາດຈະເກີດຂຶ້ນກັບເວທີຟັງ. ຈາກນັ້ນທ່ານສາມາດດຶງອອກ IP, ຊື່ຜູ້ໃຊ້ຫຼືແຂກ, ແຫຼ່ງເຫດການ, ເວລາ, ຕົວແທນຜູ້ໃຊ້, ປະເພດເຫດການ, ແລະອື່ນໆ. ແທ້ຈິງແລ້ວ, ທ່ານສາມາດເຮັດວຽກກັບເຫດການເຫຼົ່ານີ້ໄດ້ຈາກແຜງຄວບຄຸມຂອງຄລາວເອງ, ຫຼືອັບໂຫລດຂໍ້ມູນໃນຮູບແບບ MS Excel. ໃນປັດຈຸບັນມັນເປັນການຍາກທີ່ຈະເຮັດໃຫ້ການເຮັດວຽກອັດຕະໂນມັດກັບບັນທຶກ Bitrix ແລະທ່ານຈະຕ້ອງເຮັດວຽກບາງຢ່າງດ້ວຍຕົນເອງ (ການອັບໂຫລດບົດລາຍງານແລະໂຫລດມັນເຂົ້າໄປໃນ SIEM ຂອງທ່ານ). ແຕ່ຖ້າພວກເຮົາຈື່ໄວ້ວ່າຈົນກ່ວາບໍ່ດົນມານີ້, ໂອກາດດັ່ງກ່າວບໍ່ມີ, ຫຼັງຈາກນັ້ນ, ນີ້ແມ່ນຄວາມຄືບຫນ້າທີ່ຍິ່ງໃຫຍ່. ໃນເວລາດຽວກັນ, ຂ້າພະເຈົ້າຢາກສັງເກດວ່າຜູ້ໃຫ້ບໍລິການຟັງຕ່າງປະເທດຈໍານວນຫຼາຍສະເຫນີຫນ້າທີ່ຄ້າຍຄືກັນ "ສໍາລັບຜູ້ເລີ່ມຕົ້ນ" - ເບິ່ງບັນທຶກດ້ວຍຕາຜ່ານກະດານຄວບຄຸມ, ຫຼືອັບໂຫລດຂໍ້ມູນໃຫ້ກັບຕົວເອງ (ຢ່າງໃດກໍ່ຕາມ, ຂໍ້ມູນສ່ວນໃຫຍ່ອັບໂຫລດໃນ . csv ຮູບແບບ, ບໍ່ແມ່ນ Excel).

ໂດຍບໍ່ມີການພິຈາລະນາທາງເລືອກທີ່ບໍ່ມີບັນທຶກ, ຜູ້ໃຫ້ບໍລິການຄລາວມັກຈະສະເຫນີໃຫ້ທ່ານມີສາມທາງເລືອກໃນການຕິດຕາມເຫດການຄວາມປອດໄພ - dashboards, ການອັບໂຫລດຂໍ້ມູນແລະການເຂົ້າເຖິງ API. ທໍາອິດເບິ່ງຄືວ່າຈະແກ້ໄຂບັນຫາຫຼາຍຢ່າງສໍາລັບທ່ານ, ແຕ່ນີ້ບໍ່ແມ່ນຄວາມຈິງທັງຫມົດ - ຖ້າທ່ານມີວາລະສານຫຼາຍ, ທ່ານຕ້ອງປ່ຽນລະຫວ່າງຫນ້າຈໍທີ່ສະແດງໃຫ້ພວກເຂົາ, ສູນເສຍພາບລວມ. ນອກຈາກນັ້ນ, ຜູ້ໃຫ້ບໍລິການເມຄບໍ່ຫນ້າຈະໃຫ້ທ່ານມີຄວາມສາມາດທີ່ຈະເຊື່ອມໂຍງເຫດການຄວາມປອດໄພແລະໂດຍທົ່ວໄປແລ້ວການວິເຄາະພວກມັນຈາກມຸມເບິ່ງຄວາມປອດໄພ (ປົກກະຕິແລ້ວທ່ານກໍາລັງຈັດການກັບຂໍ້ມູນດິບ, ເຊິ່ງທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈຕົວເອງ). ມີຂໍ້ຍົກເວັ້ນແລະພວກເຮົາຈະເວົ້າກ່ຽວກັບພວກມັນຕື່ມອີກ. ສຸດທ້າຍ, ມັນເປັນມູນຄ່າທີ່ຈະຖາມວ່າເຫດການໃດທີ່ຖືກບັນທຶກໂດຍຜູ້ໃຫ້ບໍລິການຟັງຂອງເຈົ້າ, ໃນຮູບແບບໃດ, ແລະພວກມັນສອດຄ່ອງກັບຂະບວນການຕິດຕາມຄວາມປອດໄພຂໍ້ມູນຂອງທ່ານແນວໃດ? ຕົວຢ່າງ, ການກໍານົດແລະການກວດສອບຜູ້ໃຊ້ແລະແຂກ. Bitrix ດຽວກັນອະນຸຍາດໃຫ້ທ່ານ, ອີງຕາມເຫດການເຫຼົ່ານີ້, ເພື່ອບັນທຶກວັນທີແລະເວລາຂອງເຫດການ, ຊື່ຂອງຜູ້ໃຊ້ຫຼືແຂກ (ຖ້າທ່ານມີໂມດູນ "Web Analytics"), ວັດຖຸທີ່ເຂົ້າເຖິງແລະອົງປະກອບອື່ນໆທີ່ປົກກະຕິສໍາລັບເວັບໄຊທ໌. . ແຕ່ການບໍລິການຄວາມປອດໄພຂໍ້ມູນຂອງບໍລິສັດອາດຈະຕ້ອງການຂໍ້ມູນກ່ຽວກັບວ່າຜູ້ໃຊ້ເຂົ້າເຖິງຄລາວຈາກອຸປະກອນທີ່ເຊື່ອຖືໄດ້ຫຼືບໍ່ (ຕົວຢ່າງເຊັ່ນໃນເຄືອຂ່າຍຂອງບໍລິສັດວຽກງານນີ້ແມ່ນປະຕິບັດໂດຍ Cisco ISE). ຈະເປັນແນວໃດກ່ຽວກັບວຽກງານທີ່ງ່າຍດາຍເຊັ່ນຟັງຊັນ geo-IP, ເຊິ່ງຈະຊ່ວຍກໍານົດວ່າບັນຊີຜູ້ໃຊ້ບໍລິການຄລາວໄດ້ຖືກລັກບໍ? ແລະເຖິງແມ່ນວ່າຜູ້ໃຫ້ບໍລິການຟັງໃຫ້ມັນກັບທ່ານ, ນີ້ບໍ່ພຽງພໍ. Cisco CloudLock ດຽວກັນບໍ່ພຽງແຕ່ວິເຄາະສະຖານທີ່ຕັ້ງພູມສາດ, ແຕ່ໃຊ້ການຮຽນຮູ້ເຄື່ອງຈັກສໍາລັບການນີ້ແລະວິເຄາະຂໍ້ມູນປະຫວັດສາດສໍາລັບຜູ້ໃຊ້ແຕ່ລະຄົນແລະຕິດຕາມຄວາມຜິດປົກກະຕິຕ່າງໆໃນຄວາມພະຍາຍາມກໍານົດແລະການກວດສອບ. ພຽງແຕ່ MS Azure ມີຫນ້າທີ່ຄ້າຍຄືກັນ (ຖ້າທ່ານມີການສະໝັກໃຊ້ທີ່ເຫມາະສົມ).

ມີຄວາມຫຍຸ້ງຍາກອີກຢ່າງຫນຶ່ງ - ນັບຕັ້ງແຕ່ສໍາລັບຜູ້ໃຫ້ບໍລິການຟັງຈໍານວນຫຼາຍ, ການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນແມ່ນຫົວຂໍ້ໃຫມ່ທີ່ພວກເຂົາພຽງແຕ່ເລີ່ມຕົ້ນທີ່ຈະຈັດການກັບ, ພວກເຂົາກໍາລັງປ່ຽນແປງຢ່າງຕໍ່ເນື່ອງໃນການແກ້ໄຂຂອງພວກເຂົາ. ມື້ນີ້ພວກເຂົາມີສະບັບຫນຶ່ງຂອງ API, ມື້ອື່ນ, ມື້ອື່ນເປັນສາມ. ທ່ານຍັງຈໍາເປັນຕ້ອງໄດ້ກະກຽມສໍາລັບການນີ້. ດຽວກັນນີ້ແມ່ນຄວາມຈິງທີ່ມີຫນ້າທີ່, ເຊິ່ງອາດຈະມີການປ່ຽນແປງ, ເຊິ່ງຕ້ອງໄດ້ຮັບການພິຈາລະນາໃນລະບົບການກວດສອບຄວາມປອດໄພຂໍ້ມູນຂອງທ່ານ. ຕົວຢ່າງ, Amazon ໃນເບື້ອງຕົ້ນມີບໍລິການຕິດຕາມເຫດການຄລາວແຍກຕ່າງຫາກ—AWS CloudTrail ແລະ AWS CloudWatch. ຫຼັງຈາກນັ້ນ, ການບໍລິການແຍກຕ່າງຫາກສໍາລັບການຕິດຕາມເຫດການຄວາມປອດໄພຂອງຂໍ້ມູນໄດ້ປາກົດ - AWS GuardDuty . ຫຼັງຈາກເວລາໃດຫນຶ່ງ, Amazon ໄດ້ເປີດຕົວລະບົບການຄຸ້ມຄອງໃຫມ່, Amazon Security Hub, ເຊິ່ງລວມມີການວິເຄາະຂໍ້ມູນທີ່ໄດ້ຮັບຈາກ GuardDuty, Amazon Inspector, Amazon Macie ແລະອື່ນໆຈໍານວນຫນຶ່ງ. ຕົວຢ່າງອື່ນແມ່ນເຄື່ອງມືການເຊື່ອມໂຍງບັນທຶກ Azure ກັບ SIEM - AzLog. ມັນຖືກນໍາໃຊ້ຢ່າງຫ້າວຫັນໂດຍຜູ້ຂາຍ SIEM ຫຼາຍຄົນ, ຈົນກ່ວາໃນປີ 2018 Microsoft ໄດ້ປະກາດການຢຸດເຊົາການພັດທະນາແລະການສະຫນັບສະຫນູນ, ເຊິ່ງໄດ້ປະເຊີນຫນ້າກັບລູກຄ້າຫຼາຍຄົນທີ່ໃຊ້ເຄື່ອງມືນີ້ມີບັນຫາ (ພວກເຮົາຈະສົນທະນາກ່ຽວກັບວິທີການແກ້ໄຂໃນພາຍຫລັງ).

ດັ່ງນັ້ນ, ລະມັດລະວັງຕິດຕາມທຸກລັກສະນະການຕິດຕາມທີ່ຜູ້ໃຫ້ບໍລິການຟັງຂອງທ່ານສະເຫນີໃຫ້ທ່ານ. ຫຼືອີງໃສ່ຜູ້ໃຫ້ບໍລິການແກ້ໄຂພາຍນອກທີ່ຈະເຮັດຫນ້າທີ່ເປັນຕົວກາງລະຫວ່າງ SOC ຂອງທ່ານແລະຟັງທີ່ທ່ານຕ້ອງການຕິດຕາມ. ແມ່ນແລ້ວ, ມັນຈະມີລາຄາແພງກວ່າ (ເຖິງແມ່ນວ່າບໍ່ແມ່ນສະເຫມີ), ແຕ່ເຈົ້າຈະປ່ຽນຄວາມຮັບຜິດຊອບທັງຫມົດໃສ່ບ່າຂອງຄົນອື່ນ. ຫຼືບໍ່ມັນທັງຫມົດ?.. ໃຫ້ຈື່ແນວຄວາມຄິດຂອງຄວາມປອດໄພຮ່ວມກັນແລະເຂົ້າໃຈວ່າພວກເຮົາບໍ່ສາມາດປ່ຽນແປງຫຍັງໄດ້ - ພວກເຮົາຈະຕ້ອງເຂົ້າໃຈຢ່າງເປັນອິດສະຫຼະວ່າຜູ້ໃຫ້ບໍລິການ cloud ທີ່ແຕກຕ່າງກັນໃຫ້ການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນ, ແອັບພລິເຄຊັນ, ເຄື່ອງ virtual ແລະຊັບພະຍາກອນອື່ນໆຂອງເຈົ້າແນວໃດ. ເປັນເຈົ້າພາບໃນຄລາວ. ແລະພວກເຮົາຈະເລີ່ມຕົ້ນດ້ວຍສິ່ງທີ່ Amazon ສະເຫນີໃນສ່ວນນີ້.

ຕົວຢ່າງ: ການຕິດຕາມຄວາມປອດໄພຂອງຂໍ້ມູນໃນ IaaS ໂດຍອີງໃສ່ AWS

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

ສິ່ງທໍາອິດທີ່ເວົ້າແມ່ນວ່າ Amazon ບໍ່ແມ່ນປ້ອມປາການທີ່ບໍ່ສາມາດຕ້ານທານໄດ້. ເຫດການຕ່າງໆເກີດຂຶ້ນເລື້ອຍໆກັບລູກຄ້າຂອງລາວ. ຕົວຢ່າງ, ຊື່, ທີ່ຢູ່, ວັນເດືອນປີເກີດ, ແລະເບີໂທລະສັບຂອງຜູ້ລົງຄະແນນ 198 ລ້ານຄົນຖືກລັກໄປຈາກ Deep Root Analytics. ບໍລິສັດ Israeli Nice Systems ໄດ້ລັກເອົາ 14 ລ້ານບັນທຶກຂອງຜູ້ຈອງ Verizon. ຢ່າງໃດກໍ່ຕາມ, ຄວາມສາມາດໃນຕົວຂອງ AWS ຊ່ວຍໃຫ້ທ່ານສາມາດກວດພົບເຫດການທີ່ຫຼາກຫຼາຍ. ຍົກຕົວຢ່າງ:

ຜົນກະທົບຕໍ່ໂຄງສ້າງພື້ນຖານ (DDoS)
node compromise (ສີດຄໍາສັ່ງ)
ການປະນີປະນອມບັນຊີ ແລະການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ
ການຕັ້ງຄ່າທີ່ບໍ່ຖືກຕ້ອງ ແລະຈຸດອ່ອນ
ການໂຕ້ຕອບທີ່ບໍ່ປອດໄພ ແລະ APIs.

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

ເພື່ອກໍານົດເຫດການ, ທ່ານສາມາດນໍາໃຊ້ບໍລິການຕິດຕາມກວດກາທີ່ຫລາກຫລາຍທີ່ພັດທະນາໂດຍ Amazon (ເຖິງແມ່ນວ່າສິ່ງເຫຼົ່ານີ້ມັກຈະຖືກເສີມໂດຍເຄື່ອງມືພາຍນອກເຊັ່ນ osquery). ດັ່ງນັ້ນ, ໃນ AWS, ທຸກໆການກະ ທຳ ຂອງຜູ້ໃຊ້ຈະຖືກຕິດຕາມ, ບໍ່ວ່າພວກມັນຖືກປະຕິບັດແນວໃດ - ຜ່ານ console ການຈັດການ, ເສັ້ນຄໍາສັ່ງ, SDK ຫຼືບໍລິການ AWS ອື່ນໆ. ບັນທຶກທັງໝົດຂອງແຕ່ລະກິດຈະກໍາຂອງບັນຊີ AWS (ລວມທັງຊື່ຜູ້ໃຊ້, ການປະຕິບັດ, ການບໍລິການ, ຕົວກໍານົດການກິດຈະກໍາ, ແລະຜົນໄດ້ຮັບ) ແລະການນໍາໃຊ້ API ແມ່ນມີຢູ່ຜ່ານ AWS CloudTrail. ທ່ານສາມາດເບິ່ງເຫດການເຫຼົ່ານີ້ (ເຊັ່ນ: ເຂົ້າສູ່ລະບົບ console AWS IAM) ຈາກ CloudTrail console, ວິເຄາະພວກມັນໂດຍໃຊ້ Amazon Athena, ຫຼື "outsource" ໃຫ້ເຂົາເຈົ້າກັບການແກ້ໄຂພາຍນອກເຊັ່ນ Splunk, AlienVault, ແລະອື່ນໆ. ບັນທຶກ AWS CloudTrail ດ້ວຍຕົວມັນເອງແມ່ນຖືກຈັດໃສ່ໃນຖັງ AWS S3 ຂອງທ່ານ.

ສອງບໍລິການ AWS ອື່ນໆໃຫ້ຄວາມສາມາດໃນການກວດສອບທີ່ສໍາຄັນຈໍານວນຫນຶ່ງ. ຫນ້າທໍາອິດ, Amazon CloudWatch ເປັນບໍລິການຕິດຕາມກວດກາສໍາລັບຊັບພະຍາກອນ AWS ແລະຄໍາຮ້ອງສະຫມັກທີ່, ໃນບັນດາສິ່ງອື່ນໆ, ອະນຸຍາດໃຫ້ທ່ານສາມາດກໍານົດຄວາມຜິດປົກກະຕິຕ່າງໆໃນເມຄຂອງທ່ານ. ການບໍລິການ AWS ທັງຫມົດທີ່ສ້າງຂຶ້ນ, ເຊັ່ນ Amazon Elastic Compute Cloud (ເຄື່ອງແມ່ຂ່າຍ), Amazon Relational Database Service (ຖານຂໍ້ມູນ), Amazon Elastic MapReduce (ການວິເຄາະຂໍ້ມູນ), ແລະ 30 ບໍລິການ Amazon ອື່ນໆ, ໃຊ້ Amazon CloudWatch ເພື່ອເກັບຮັກສາບັນທຶກຂອງພວກເຂົາ. ນັກພັດທະນາສາມາດໃຊ້ API ເປີດຈາກ Amazon CloudWatch ເພື່ອເພີ່ມການທໍາງານຂອງການກວດສອບບັນທຶກກັບຄໍາຮ້ອງສະຫມັກແລະການບໍລິການທີ່ກໍາຫນົດເອງ, ໃຫ້ພວກເຂົາຂະຫຍາຍຂອບເຂດຂອງການວິເຄາະເຫດການພາຍໃນສະພາບຄວາມປອດໄພ.

ອັນທີສອງ, ການບໍລິການບັນທຶກການໄຫຼເຂົ້າຂອງ VPC ຊ່ວຍໃຫ້ທ່ານສາມາດວິເຄາະການເຂົ້າຊົມເຄືອຂ່າຍທີ່ສົ່ງຫຼືໄດ້ຮັບໂດຍເຄື່ອງແມ່ຂ່າຍ AWS ຂອງທ່ານ (ພາຍນອກຫຼືພາຍໃນ), ເຊັ່ນດຽວກັນກັບລະຫວ່າງ microservices. ເມື່ອຊັບພະຍາກອນ AWS VPC ຂອງທ່ານພົວພັນກັບເຄືອຂ່າຍ, VPC Flow Logs ບັນທຶກລາຍລະອຽດກ່ຽວກັບການຈະລາຈອນເຄືອຂ່າຍ, ລວມທັງຕົວເຊື່ອມຕໍ່ເຄືອຂ່າຍຕົ້ນທາງແລະປາຍທາງ, ເຊັ່ນດຽວກັນກັບທີ່ຢູ່ IP, ພອດ, ໂປໂຕຄອນ, ຈໍານວນ bytes, ແລະຈໍານວນແພັກເກັດທີ່ທ່ານ ເຫັນ. ຜູ້ທີ່ມີປະສົບການກັບຄວາມປອດໄພຂອງເຄືອຂ່າຍທ້ອງຖິ່ນຈະຮັບຮູ້ວ່າມັນຄ້າຍຄືກັນກັບກະທູ້ NetFlow, ເຊິ່ງສາມາດສ້າງໄດ້ໂດຍສະຫຼັບ, routers ແລະ firewalls ລະດັບວິສາຫະກິດ. ບັນທຶກເຫຼົ່ານີ້ມີຄວາມສໍາຄັນສໍາລັບຈຸດປະສົງການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນເພາະວ່າ, ບໍ່ເຫມືອນກັບເຫດການກ່ຽວກັບການກະທໍາຂອງຜູ້ໃຊ້ແລະແອັບພລິເຄຊັນ, ພວກເຂົາຍັງຊ່ວຍໃຫ້ທ່ານບໍ່ພາດການໂຕ້ຕອບເຄືອຂ່າຍໃນສະພາບແວດລ້ອມຄລາວ virtual ຂອງ AWS.

ສະຫຼຸບແລ້ວ, ສາມບໍລິການ AWS ເຫຼົ່ານີ້—AWS CloudTrail, Amazon CloudWatch, ແລະ VPC Flow Logs—ຮ່ວມກັນໃຫ້ຄວາມເຂົ້າໃຈທີ່ມີປະສິດທິພາບພໍສົມຄວນໃນການນຳໃຊ້ບັນຊີຂອງທ່ານ, ພຶດຕິກຳຂອງຜູ້ໃຊ້, ການຈັດການໂຄງລ່າງພື້ນຖານ, ແອັບພລິເຄຊັ່ນ ແລະການບໍລິການ ແລະການເຄື່ອນໄຫວເຄືອຂ່າຍ. ຕົວຢ່າງ, ພວກມັນສາມາດໃຊ້ເພື່ອກວດຫາຄວາມຜິດປົກກະຕິຕໍ່ໄປນີ້:

ຄວາມພະຍາຍາມທີ່ຈະສະແກນເວັບໄຊທ໌, ຄົ້ນຫາ backdoors, ຄົ້ນຫາຈຸດອ່ອນໂດຍຜ່ານການລະເບີດຂອງ "404 ຂໍ້ຜິດພາດ".
ການໂຈມຕີດ້ວຍການສັກຢາ (ຕົວຢ່າງ, ການສັກຢາ SQL) ໂດຍຜ່ານການລະເບີດຂອງ "500 ຂໍ້ຜິດພາດ".
ເຄື່ອງມືການໂຈມຕີທີ່ຮູ້ຈັກແມ່ນ sqlmap, nikto, w3af, nmap, ແລະອື່ນໆ. ຜ່ານການວິເຄາະພາກສະຫນາມຕົວແທນຜູ້ໃຊ້.

Amazon Web Services ຍັງໄດ້ພັດທະນາການບໍລິການອື່ນໆເພື່ອຈຸດປະສົງຄວາມປອດໄພທາງອິນເຕີເນັດທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດແກ້ໄຂບັນຫາອື່ນໆຈໍານວນຫຼາຍ. ຕົວຢ່າງ, AWS ມີບໍລິການໃນຕົວສໍາລັບການກວດສອບນະໂຍບາຍແລະການຕັ້ງຄ່າ - AWS Config. ການບໍລິການນີ້ສະຫນອງການກວດສອບຢ່າງຕໍ່ເນື່ອງຂອງຊັບພະຍາກອນ AWS ຂອງທ່ານແລະການຕັ້ງຄ່າຂອງພວກເຂົາ. ເອົາຕົວຢ່າງງ່າຍໆ: ສົມມຸດວ່າທ່ານຕ້ອງການໃຫ້ແນ່ໃຈວ່າລະຫັດຜ່ານຂອງຜູ້ໃຊ້ຖືກປິດໃຊ້ງານຢູ່ໃນເຄື່ອງແມ່ຂ່າຍທັງຫມົດຂອງທ່ານແລະການເຂົ້າເຖິງນັ້ນແມ່ນເປັນໄປໄດ້ໂດຍອີງໃສ່ໃບຢັ້ງຢືນເທົ່ານັ້ນ. AWS Config ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການກວດສອບນີ້ສໍາລັບເຄື່ອງແມ່ຂ່າຍທັງຫມົດຂອງທ່ານ. ມີນະໂຍບາຍອື່ນໆທີ່ສາມາດນໍາໃຊ້ກັບເຄື່ອງແມ່ຂ່າຍຟັງຂອງທ່ານ: "ບໍ່ມີເຄື່ອງແມ່ຂ່າຍສາມາດໃຊ້ພອດ 22", "ພຽງແຕ່ຜູ້ບໍລິຫານສາມາດປ່ຽນກົດລະບຽບຂອງໄຟວໍ" ຫຼື "ຜູ້ໃຊ້ Ivashko ເທົ່ານັ້ນທີ່ສາມາດສ້າງບັນຊີຜູ້ໃຊ້ໃຫມ່, ແລະລາວສາມາດເຮັດໄດ້ພຽງແຕ່ໃນວັນອັງຄານເທົ່ານັ້ນ. " ໃນຊ່ວງລຶະເບິ່ງຮ້ອນຂອງປີ 2016, ການບໍລິການ AWS Config ໄດ້ຖືກຂະຫຍາຍເພື່ອອັດຕະໂນມັດການກວດພົບການລະເມີດນະໂຍບາຍທີ່ພັດທະນາແລ້ວ. ກົດລະບຽບຂອງ AWS Config ແມ່ນຄໍາຮ້ອງຂໍການຕັ້ງຄ່າຢ່າງຕໍ່ເນື່ອງສໍາລັບການບໍລິການ Amazon ທີ່ທ່ານໃຊ້, ເຊິ່ງສ້າງເຫດການຖ້ານະໂຍບາຍທີ່ສອດຄ້ອງກັນຖືກລະເມີດ. ຕົວຢ່າງ, ແທນທີ່ຈະດໍາເນີນການສອບຖາມ AWS Config ເປັນໄລຍະໆເພື່ອກວດສອບວ່າທຸກແຜ່ນໃນເຊີບເວີສະເໝືອນຖືກເຂົ້າລະຫັດ, ກົດລະບຽບ AWS Config ສາມາດໃຊ້ເພື່ອກວດສອບຮາດດິດເຊີບເວີຢ່າງຕໍ່ເນື່ອງເພື່ອຮັບປະກັນວ່າເງື່ອນໄຂນີ້ຖືກປະຕິບັດຕາມ. ແລະ, ສໍາຄັນທີ່ສຸດ, ໃນສະພາບການຂອງສິ່ງພິມນີ້, ການລະເມີດໃດໆເຮັດໃຫ້ເກີດເຫດການທີ່ສາມາດວິເຄາະໄດ້ໂດຍການບໍລິການຄວາມປອດໄພຂໍ້ມູນຂອງທ່ານ.

AWS ຍັງມີການປຽບທຽບກັບການແກ້ໄຂຄວາມປອດໄພຂໍ້ມູນຂອງບໍລິສັດແບບດັ້ງເດີມ, ເຊິ່ງຍັງສ້າງເຫດການຄວາມປອດໄພທີ່ເຈົ້າສາມາດ ແລະຄວນວິເຄາະ:

ການກວດຫາການບຸກລຸກ - AWS GuardDuty
ການຄວບຄຸມຂໍ້ມູນຮົ່ວໄຫຼ - AWS Macie
EDR (ເຖິງແມ່ນວ່າມັນເວົ້າກ່ຽວກັບຈຸດສິ້ນສຸດໃນຄລາວເລັກນ້ອຍ) - AWS Cloudwatch + open source osquery ຫຼື GRR solutions
ການວິເຄາະ Netflow - AWS Cloudwatch + AWS VPC Flow
ການວິເຄາະ DNS - AWS Cloudwatch + AWS Route53
AD - AWS Directory Service
ການຈັດການບັນຊີ - AWS IAM
SSO - AWS SSO
ການວິເຄາະຄວາມປອດໄພ - AWS Inspector
ການຈັດການການຕັ້ງຄ່າ - AWS Config
WAF - AWS WAF.

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

ໃນກໍລະນີໃດກໍ່ຕາມ, ມັນທັງຫມົດເລີ່ມຕົ້ນດ້ວຍແຫຼ່ງຂໍ້ມູນທີ່ສະຫນອງເຫດການຄວາມປອດໄພຂອງຂໍ້ມູນ. ແຫຼ່ງຂໍ້ມູນເຫຼົ່ານີ້ປະກອບມີ, ແຕ່ບໍ່ຈໍາກັດພຽງແຕ່:

CloudTrail - ການໃຊ້ API ແລະການປະຕິບັດຂອງຜູ້ໃຊ້
ທີ່ປຶກສາທີ່ເຊື່ອຖືໄດ້ - ການກວດສອບຄວາມປອດໄພຕໍ່ກັບການປະຕິບັດທີ່ດີທີ່ສຸດ
Config - inventory and configuration of account and service settings
ບັນທຶກການໄຫຼເຂົ້າຂອງ VPC - ການເຊື່ອມຕໍ່ກັບການໂຕ້ຕອບ virtual
IAM - ບໍລິການລະບຸຕົວຕົນ ແລະການກວດສອບຄວາມຖືກຕ້ອງ
ບັນທຶກການເຂົ້າເຖິງ ELB - Load Balancer
Inspector - ຊ່ອງໂຫວ່ຂອງແອັບພລິເຄຊັນ
S3 - ການເກັບຮັກສາໄຟລ໌
CloudWatch - ການເຄື່ອນໄຫວຂອງແອັບພລິເຄຊັນ
SNS ເປັນບໍລິການແຈ້ງເຕືອນ.

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

ຕົວຢ່າງ: ການຕິດຕາມຄວາມປອດໄພຂອງຂໍ້ມູນໃນ IaaS ໂດຍອີງໃສ່ Azure

ຂ້ອຍບໍ່ຕ້ອງການທີ່ຈະເຂົ້າໄປໃນການໂຕ້ວາທີທີ່ຍາວນານກ່ຽວກັບສາມຜູ້ໃຫ້ບໍລິການຟັງ (Amazon, Microsoft ຫຼື Google) ດີກວ່າ (ໂດຍສະເພາະພວກເຂົາແຕ່ລະຄົນຍັງມີຈຸດພິເສດສະເພາະຂອງຕົນເອງແລະເຫມາະສົມສໍາລັບການແກ້ໄຂບັນຫາຂອງຕົນເອງ); ໃຫ້ພວກເຮົາສຸມໃສ່ຄວາມສາມາດໃນການຕິດຕາມກວດກາຄວາມປອດໄພຂໍ້ມູນຂ່າວສານທີ່ຜູ້ນເຫຼົ່ານີ້ສະຫນອງໃຫ້. ມັນຕ້ອງໄດ້ຮັບການຍອມຮັບວ່າ Amazon AWS ແມ່ນຫນຶ່ງໃນບັນດາຄັ້ງທໍາອິດໃນສ່ວນນີ້ແລະດັ່ງນັ້ນຈຶ່ງໄດ້ກ້າວຫນ້າໃນຫນ້າທີ່ຄວາມປອດໄພຂອງຂໍ້ມູນຂອງມັນ (ເຖິງແມ່ນວ່າຫຼາຍໆຄົນຍອມຮັບວ່າພວກເຂົາມີຄວາມຫຍຸ້ງຍາກໃນການນໍາໃຊ້). ແຕ່ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າພວກເຮົາຈະບໍ່ສົນໃຈໂອກາດທີ່ Microsoft ແລະ Google ສະຫນອງໃຫ້ພວກເຮົາ.

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

AWS ມີຄວາມແປກປະຫຼາດທີ່ກ່ຽວຂ້ອງກັບຄວາມຈິງທີ່ວ່າເມື່ອທ່ານຕິດຕາມຊັບພະຍາກອນ virtual ຂອງທ່ານ, ຖ້າພວກເຂົາຕັ້ງຢູ່ໃນພາກພື້ນຕ່າງໆ, ທ່ານມີຄວາມຫຍຸ້ງຍາກໃນການລວມເອົາເຫດການທັງຫມົດແລະການວິເຄາະຄວາມສາມັກຄີຂອງພວກເຂົາ, ເພື່ອກໍາຈັດສິ່ງທີ່ທ່ານຈໍາເປັນຕ້ອງໃຊ້ tricks ຕ່າງໆ, ເຊັ່ນ: ສ້າງລະຫັດຂອງທ່ານເອງສໍາລັບ AWS Lambda ທີ່ຈະຂົນສົ່ງເຫດການລະຫວ່າງພາກພື້ນ. Azure ບໍ່ມີບັນຫານີ້ - ກົນໄກບັນທຶກກິດຈະກໍາຂອງມັນຕິດຕາມກິດຈະກໍາທັງຫມົດໃນທົ່ວອົງການໂດຍບໍ່ມີຂໍ້ຈໍາກັດ. ດຽວກັນໃຊ້ກັບ AWS Security Hub, ເຊິ່ງບໍ່ດົນມານີ້ໄດ້ພັດທະນາໂດຍ Amazon ເພື່ອລວບລວມຫນ້າທີ່ຄວາມປອດໄພຫຼາຍຢ່າງພາຍໃນສູນຄວາມປອດໄພດຽວ, ແຕ່ວ່າພຽງແຕ່ຢູ່ໃນພາກພື້ນຂອງມັນ, ເຊິ່ງ, ແນວໃດກໍ່ຕາມ, ບໍ່ກ່ຽວຂ້ອງກັບລັດເຊຍ. Azure ມີສູນຄວາມປອດໄພຂອງຕົນເອງ, ເຊິ່ງບໍ່ໄດ້ຖືກຜູກມັດໂດຍຂໍ້ຈໍາກັດຂອງພາກພື້ນ, ສະຫນອງການເຂົ້າເຖິງຄຸນນະສົມບັດຄວາມປອດໄພທັງຫມົດຂອງແພລະຕະຟອມຟັງ. ຍິ່ງໄປກວ່ານັ້ນ, ສໍາລັບທີມງານທ້ອງຖິ່ນທີ່ແຕກຕ່າງກັນ, ມັນສາມາດສະຫນອງຊຸດຄວາມສາມາດປ້ອງກັນຂອງຕົນເອງ, ລວມທັງເຫດການຄວາມປອດໄພທີ່ຄຸ້ມຄອງໂດຍພວກເຂົາ. AWS Security Hub ຍັງຢູ່ໃນເສັ້ນທາງທີ່ຈະກາຍເປັນຄ້າຍຄືກັນກັບສູນຄວາມປອດໄພ Azure. ແຕ່ມັນຄຸ້ມຄ່າທີ່ຈະເພີ່ມແມງວັນໃນຢາຂີ້ເຜິ້ງ - ທ່ານສາມາດບີບອອກຈາກ Azure ຫຼາຍສິ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນ AWS ກ່ອນຫນ້ານີ້, ແຕ່ນີ້ແມ່ນເຮັດໄດ້ສະດວກທີ່ສຸດສໍາລັບ Azure AD, Azure Monitor ແລະ Azure Security Center ເທົ່ານັ້ນ. ກົນໄກຄວາມປອດໄພ Azure ອື່ນໆທັງຫມົດ, ລວມທັງການວິເຄາະເຫດການຄວາມປອດໄພ, ຍັງບໍ່ທັນຖືກຄຸ້ມຄອງໃນວິທີທີ່ສະດວກທີ່ສຸດ. ບັນຫາແມ່ນການແກ້ໄຂບາງສ່ວນໂດຍ API, ເຊິ່ງ permeates ການບໍລິການ Microsoft Azure ທັງຫມົດ, ແຕ່ນີ້ຈະຕ້ອງໃຊ້ຄວາມພະຍາຍາມເພີ່ມເຕີມຈາກເຈົ້າເພື່ອປະສົມປະສານ cloud ຂອງທ່ານກັບ SOC ຂອງທ່ານແລະມີຜູ້ຊ່ຽວຊານທີ່ມີຄຸນວຸດທິ (ໃນຄວາມເປັນຈິງ, ເຊັ່ນດຽວກັນກັບ SIEM ອື່ນໆທີ່ເຮັດວຽກກັບ cloud. APIs). ບາງ SIEMs, ເຊິ່ງຈະໄດ້ຮັບການປຶກສາຫາລືຕໍ່ມາ, ສະຫນັບສະຫນູນ Azure ແລ້ວແລະສາມາດອັດຕະໂນມັດວຽກງານຂອງການກວດສອບມັນ, ແຕ່ມັນຍັງມີຄວາມຫຍຸ້ງຍາກຂອງຕົນເອງ - ບໍ່ແມ່ນທັງຫມົດສາມາດເກັບບັນທຶກທັງຫມົດທີ່ Azure ມີ.

ການລວບລວມແລະການຕິດຕາມເຫດການໃນ Azure ແມ່ນສະຫນອງໃຫ້ໂດຍການບໍລິການ Azure Monitor, ເຊິ່ງເປັນເຄື່ອງມືຕົ້ນຕໍສໍາລັບການລວບລວມ, ເກັບຮັກສາແລະການວິເຄາະຂໍ້ມູນໃນ Microsoft cloud ແລະຊັບພະຍາກອນຂອງມັນ - Git repositories, containers, virtual machines, applications, etc. ຂໍ້ມູນທັງຫມົດທີ່ເກັບກໍາໂດຍ Azure Monitor ແບ່ງອອກເປັນສອງປະເພດ - metrics, ເກັບກໍາຂໍ້ມູນໃນເວລາທີ່ແທ້ຈິງແລະອະທິບາຍຕົວຊີ້ວັດການປະຕິບັດທີ່ສໍາຄັນຂອງ Azure cloud, ແລະບັນທຶກ, ປະກອບດ້ວຍຂໍ້ມູນທີ່ຖືກຈັດເຂົ້າໃນບັນທຶກທີ່ມີລັກສະນະບາງຢ່າງຂອງກິດຈະກໍາຂອງຊັບພະຍາກອນແລະການບໍລິການຂອງ Azure. ນອກຈາກນັ້ນ, ການນໍາໃຊ້ API ການເກັບຂໍ້ມູນ, ບໍລິການ Azure Monitor ສາມາດເກັບກໍາຂໍ້ມູນຈາກແຫຼ່ງ REST ໃດໆເພື່ອສ້າງສະຖານະການຕິດຕາມຂອງຕົນເອງ.

ນີ້ແມ່ນແຫຼ່ງເຫດການຄວາມປອດໄພຈຳນວນໜຶ່ງທີ່ Azure ສະເໜີໃຫ້ທ່ານ ແລະທ່ານສາມາດເຂົ້າເຖິງໄດ້ຜ່ານ Azure Portal, CLI, PowerShell, ຫຼື REST API (ແລະບາງອັນຜ່ານ Azure Monitor/Insight API):

ບັນທຶກການເຄື່ອນໄຫວ - ບັນທຶກນີ້ຕອບຄໍາຖາມຄລາສສິກຂອງ "ໃຜ," "ຫຍັງ," ແລະ "ເວລາ" ກ່ຽວກັບການດໍາເນີນງານການຂຽນໃດໆ (PUT, POST, DELETE) ໃນຊັບພະຍາກອນຄລາວ. ເຫດການທີ່ກ່ຽວຂ້ອງກັບການເຂົ້າເຖິງການອ່ານ (GET) ບໍ່ໄດ້ຖືກລວມຢູ່ໃນບັນທຶກນີ້, ເຊັ່ນດຽວກັບຈໍານວນອື່ນໆ.
ບັນທຶກການວິນິໄສ - ປະກອບມີຂໍ້ມູນກ່ຽວກັບການດໍາເນີນການທີ່ມີຊັບພະຍາກອນສະເພາະທີ່ລວມຢູ່ໃນການສະໝັກໃຊ້ຂອງທ່ານ.
Azure AD ລາຍງານ - ມີທັງກິດຈະກໍາຂອງຜູ້ໃຊ້ແລະກິດຈະກໍາລະບົບທີ່ກ່ຽວຂ້ອງກັບການຄຸ້ມຄອງກຸ່ມແລະຜູ້ໃຊ້.
Windows Event Log ແລະ Linux Syslog - ປະກອບມີເຫດການຈາກເຄື່ອງ virtual ທີ່ໂຮດຢູ່ໃນຄລາວ.
Metrics - ມີ telemetry ກ່ຽວກັບການປະຕິບັດແລະສະຖານະພາບສຸຂະພາບຂອງການບໍລິການຟັງແລະຊັບພະຍາກອນຂອງທ່ານ. ວັດແທກທຸກໆນາທີແລະເກັບໄວ້. ພາຍໃນ 30 ມື້.
Network Security Group Flow Logs - ປະກອບມີຂໍ້ມູນກ່ຽວກັບເຫດການຄວາມປອດໄພຂອງເຄືອຂ່າຍທີ່ເກັບກໍາໂດຍການບໍລິການ Network Watcher ແລະການຕິດຕາມຊັບພະຍາກອນໃນລະດັບເຄືອຂ່າຍ.
ບັນທຶກການເກັບຮັກສາ - ປະກອບມີເຫດການທີ່ກ່ຽວຂ້ອງກັບການເຂົ້າເຖິງສະຖານທີ່ເກັບຮັກສາ.

ສໍາລັບການຕິດຕາມ, ທ່ານສາມາດນໍາໃຊ້ SIEMs ພາຍນອກຫຼື Azure Monitor ທີ່ມີໃນຕົວແລະສ່ວນຂະຫຍາຍຂອງມັນ. ພວກເຮົາຈະເວົ້າກ່ຽວກັບລະບົບການຈັດການເຫດການຄວາມປອດໄພຂໍ້ມູນໃນພາຍຫລັງ, ແຕ່ສໍາລັບຕອນນີ້ໃຫ້ເບິ່ງສິ່ງທີ່ Azure ຕົວມັນເອງສະເຫນີໃຫ້ພວກເຮົາສໍາລັບການວິເຄາະຂໍ້ມູນໃນແງ່ຂອງຄວາມປອດໄພ. ຫນ້າຈໍຫຼັກສໍາລັບທຸກສິ່ງທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບຄວາມປອດໄພໃນ Azure Monitor ແມ່ນ Log Analytics Security ແລະ Audit Dashboard (ສະບັບຟຣີສະຫນັບສະຫນູນຈໍານວນຈໍາກັດຂອງການເກັບຮັກສາເຫດການພຽງແຕ່ຫນຶ່ງອາທິດ). dashboard ນີ້ແບ່ງອອກເປັນ 5 ພື້ນທີ່ຕົ້ນຕໍທີ່ສະແດງສະຖິຕິສະຫຼຸບຂອງສິ່ງທີ່ເກີດຂຶ້ນໃນສະພາບແວດລ້ອມຄລາວທີ່ທ່ານກໍາລັງໃຊ້:

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

ສ່ວນຂະຫຍາຍຂອງ Azure Monitor ລວມມີ Azure Key Vault (ການປົກປ້ອງລະຫັດ cryptographic ໃນເມຄ), Malware Assessment (ການວິເຄາະການປ້ອງກັນລະຫັດອັນຕະລາຍໃນ virtual machines), Azure Application Gateway Analytics (ການວິເຄາະ, ໃນບັນດາສິ່ງອື່ນໆ, ບັນທຶກ firewall cloud), ແລະອື່ນໆ. . ເຄື່ອງມືເຫຼົ່ານີ້, ອຸດົມດ້ວຍກົດລະບຽບບາງຢ່າງສໍາລັບການປະມວນຜົນເຫດການ, ອະນຸຍາດໃຫ້ທ່ານສາມາດເບິ່ງເຫັນລັກສະນະຕ່າງໆຂອງກິດຈະກໍາຂອງການບໍລິການຄລາວ, ລວມທັງຄວາມປອດໄພ, ແລະກໍານົດ deviations ສະເພາະໃດຫນຶ່ງຈາກການດໍາເນີນງານ. ແຕ່, ດັ່ງທີ່ເກີດຂື້ນເລື້ອຍໆ, ຫນ້າທີ່ເພີ່ມເຕີມຮຽກຮ້ອງໃຫ້ມີການສະຫມັກທີ່ຈ່າຍທີ່ສອດຄ້ອງກັນ, ເຊິ່ງຈະຮຽກຮ້ອງໃຫ້ມີການລົງທຶນທາງດ້ານການເງິນທີ່ສອດຄ້ອງກັນຈາກທ່ານ, ເຊິ່ງທ່ານຈໍາເປັນຕ້ອງວາງແຜນລ່ວງຫນ້າ.

Azure ມີຄວາມສາມາດໃນການຕິດຕາມໄພຂົ່ມຂູ່ທີ່ສ້າງຂຶ້ນໃນຈໍານວນທີ່ປະສົມປະສານເຂົ້າໃນ Azure AD, Azure Monitor ແລະ Azure Security Center. ໃນບັນດາພວກມັນ, ສໍາລັບຕົວຢ່າງ, ການກວດສອບການໂຕ້ຕອບຂອງເຄື່ອງ virtual ກັບ IPs ທີ່ເປັນອັນຕະລາຍທີ່ຮູ້ຈັກ (ເນື່ອງຈາກການເຊື່ອມໂຍງກັບບໍລິການ Threat Intelligence ຈາກ Microsoft), ການກວດພົບ malware ໃນໂຄງສ້າງພື້ນຖານຂອງຄລາວໂດຍການຮັບສັນຍານເຕືອນຈາກເຄື່ອງ virtual ທີ່ໂຮດຢູ່ໃນຄລາວ, ລະຫັດຜ່ານ. ການຄາດເດົາການໂຈມຕີ ” ໃນເຄື່ອງ virtual, ຊ່ອງໂຫວ່ໃນການຕັ້ງຄ່າລະບົບການກໍານົດຕົວຜູ້ໃຊ້, ການເຂົ້າສູ່ລະບົບຈາກຜູ້ປິດບັງຊື່ຫຼື nodes ທີ່ຕິດເຊື້ອ, ການຮົ່ວໄຫລຂອງບັນຊີ, ເຂົ້າສູ່ລະບົບຈາກສະຖານທີ່ຜິດປົກກະຕິ, ແລະອື່ນໆ. Azure ໃນມື້ນີ້ແມ່ນຫນຶ່ງໃນຜູ້ໃຫ້ບໍລິການຟັງຈໍານວນຫນ້ອຍທີ່ສະເຫນີໃຫ້ທ່ານມີຄວາມສາມາດໃນການ Threat Intelligence ເພື່ອສ້າງຄວາມເຂັ້ມແຂງໃນເຫດການຄວາມປອດໄພຂອງຂໍ້ມູນທີ່ເກັບກໍາ.

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

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

ຖ້າທ່ານຕ້ອງການບໍ່ພຽງແຕ່ຄວາມສາມາດໃນການເຮັດວຽກກັບບັນທຶກ, ແຕ່ສູນຄວາມປອດໄພທີ່ສົມບູນແບບສໍາລັບແພລະຕະຟອມຟັງ Azure ຂອງທ່ານ, ລວມທັງການຄຸ້ມຄອງນະໂຍບາຍຄວາມປອດໄພຂໍ້ມູນ, ຫຼັງຈາກນັ້ນທ່ານສາມາດສົນທະນາກ່ຽວກັບຄວາມຕ້ອງການທີ່ຈະເຮັດວຽກກັບ Azure Security Center, ຫນ້າທີ່ທີ່ເປັນປະໂຫຍດຫຼາຍທີ່ສຸດ. ສາມາດໃຊ້ໄດ້ສໍາລັບເງິນຈໍານວນຫນຶ່ງ, ສໍາລັບການຍົກຕົວຢ່າງ, ການກວດສອບໄພຂົ່ມຂູ່, ການຕິດຕາມນອກ Azure, ການປະເມີນການປະຕິບັດຕາມ, ແລະອື່ນໆ. (ໃນສະບັບຟຣີ, ທ່ານພຽງແຕ່ສາມາດເຂົ້າເຖິງການປະເມີນຄວາມປອດໄພແລະຂໍ້ສະເຫນີແນະສໍາລັບການກໍາຈັດບັນຫາທີ່ກໍານົດ). ມັນລວມບັນຫາຄວາມປອດໄພທັງຫມົດຢູ່ໃນສະຖານທີ່ດຽວ. ໃນຄວາມເປັນຈິງ, ພວກເຮົາສາມາດເວົ້າກ່ຽວກັບຄວາມປອດໄພຂອງຂໍ້ມູນສູງກວ່າ Azure Monitor ໃຫ້ທ່ານ, ເພາະວ່າໃນກໍລະນີນີ້ຂໍ້ມູນທີ່ເກັບກໍາໃນທົ່ວໂຮງງານຟັງຂອງເຈົ້າແມ່ນອຸດົມສົມບູນໂດຍໃຊ້ຫຼາຍແຫຼ່ງ, ເຊັ່ນ: Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX , outlook .com , MSN.com , Microsoft Digital Crimes Unit (DCU) ແລະ Microsoft Security Response Center (MSRC), ເຊິ່ງມີການນຳໃຊ້ເຄື່ອງຈັກການຮຽນຮູ້ ແລະ ການວິເຄາະພຶດຕິກຳທີ່ທັນສະໄໝ, ເຊິ່ງໃນທີ່ສຸດຄວນປັບປຸງປະສິດທິພາບຂອງການກວດຫາ ແລະ ຕອບສະໜອງຕໍ່ໄພຂົ່ມຂູ່. .

Azure ຍັງມີ SIEM ຂອງຕົນເອງ - ມັນປາກົດຢູ່ໃນຕົ້ນປີ 2019. ນີ້ແມ່ນ Azure Sentinel, ເຊິ່ງອີງໃສ່ຂໍ້ມູນຈາກ Azure Monitor ແລະຍັງສາມາດປະສົມປະສານກັບ. ການແກ້ໄຂຄວາມປອດໄພພາຍນອກ (ຕົວຢ່າງ, NGFW ຫຼື WAF), ບັນຊີລາຍຊື່ຂອງການຂະຫຍາຍຕົວຢ່າງຕໍ່ເນື່ອງ. ນອກຈາກນັ້ນ, ໂດຍຜ່ານການປະສົມປະສານຂອງ Microsoft Graph Security API, ທ່ານມີຄວາມສາມາດໃນການເຊື່ອມຕໍ່ Threat Intelligence feeds ຂອງທ່ານເອງກັບ Sentinel, ເຊິ່ງເພີ່ມຄວາມສາມາດໃນການວິເຄາະເຫດການໃນ Azure cloud ຂອງທ່ານ. ມັນສາມາດໂຕ້ຖຽງໄດ້ວ່າ Azure Sentinel ແມ່ນ SIEM "ພື້ນເມືອງ" ທໍາອິດທີ່ປາກົດຈາກຜູ້ໃຫ້ບໍລິການຟັງ (Splunk ດຽວກັນຫຼື ELK, ເຊິ່ງສາມາດຖືກໂຮດຢູ່ໃນຄລາວ, ຕົວຢ່າງເຊັ່ນ AWS, ຍັງບໍ່ຖືກພັດທະນາໂດຍຜູ້ໃຫ້ບໍລິການຟັງແບບດັ້ງເດີມ). Azure Sentinel ແລະສູນຄວາມປອດໄພສາມາດເອີ້ນວ່າ SOC ສໍາລັບ Azure cloud ແລະສາມາດຈໍາກັດໃຫ້ພວກເຂົາ (ດ້ວຍການຈອງທີ່ແນ່ນອນ) ຖ້າທ່ານບໍ່ມີໂຄງສ້າງພື້ນຖານໃດໆແລະທ່ານໂອນຊັບພະຍາກອນຄອມພິວເຕີ້ທັງຫມົດຂອງທ່ານໄປໃສ່ຄລາວແລະມັນຈະເປັນ Microsoft cloud Azure.

ແຕ່ເນື່ອງຈາກຄວາມສາມາດໃນຕົວຂອງ Azure (ເຖິງແມ່ນວ່າທ່ານມີການສະຫມັກກັບ Sentinel) ມັກຈະບໍ່ພຽງພໍສໍາລັບຈຸດປະສົງຂອງການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນແລະການລວມຂະບວນການນີ້ກັບແຫຼ່ງອື່ນໆຂອງເຫດການຄວາມປອດໄພ (ທັງຟັງແລະພາຍໃນ), ມີ. ຈໍາເປັນຕ້ອງໄດ້ສົ່ງອອກຂໍ້ມູນທີ່ເກັບກໍາກັບລະບົບພາຍນອກ, ເຊິ່ງອາດຈະປະກອບມີ SIEM. ນີ້ແມ່ນເຮັດໄດ້ທັງການນໍາໃຊ້ API ແລະການນໍາໃຊ້ການຂະຫຍາຍພິເສດ, ເຊິ່ງປະຈຸບັນມີຢ່າງເປັນທາງການພຽງແຕ່ສໍາລັບ SIEMs ຕໍ່ໄປນີ້ - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight ແລະ ELK. ຈົນກ່ວາບໍ່ດົນມານີ້, ມີ SIEMs ດັ່ງກ່າວຫຼາຍຂຶ້ນ, ແຕ່ວັນທີ 1 ມິຖຸນາ 2019, Microsoft ໄດ້ຢຸດການສະຫນັບສະຫນູນເຄື່ອງມືການເຊື່ອມໂຍງຂອງ Azure Log (AzLog), ເຊິ່ງໃນຕອນເຊົ້າຂອງການມີຢູ່ຂອງ Azure ແລະໃນເວລາທີ່ບໍ່ມີມາດຕະຖານປົກກະຕິຂອງການເຮັດວຽກກັບບັນທຶກ (Azure Monitor ຍັງບໍ່ທັນມີເທື່ອ) ເຮັດໃຫ້ມັນເຊື່ອມໂຍງກັບ SIEM ພາຍນອກກັບ Microsoft cloud ໄດ້ງ່າຍ. ໃນປັດຈຸບັນສະຖານະການໄດ້ມີການປ່ຽນແປງແລະ Microsoft ແນະນໍາເວທີ Azure Event Hub ເປັນເຄື່ອງມືການເຊື່ອມໂຍງຕົ້ນຕໍສໍາລັບ SIEMs ອື່ນໆ. ຫຼາຍຄົນໄດ້ປະຕິບັດການປະສົມປະສານດັ່ງກ່າວແລ້ວ, ແຕ່ຄວນລະວັງ - ພວກເຂົາອາດຈະບໍ່ຈັບບັນທຶກ Azure ທັງຫມົດ, ແຕ່ວ່າມີພຽງແຕ່ບາງ (ເບິ່ງໃນເອກະສານສໍາລັບ SIEM ຂອງທ່ານ).

ສະຫຼຸບການຍ່າງທາງສັ້ນໆໃນ Azure, ຂ້າພະເຈົ້າຢາກຈະໃຫ້ຄໍາແນະນໍາທົ່ວໄປກ່ຽວກັບການບໍລິການຟັງນີ້ - ກ່ອນທີ່ທ່ານຈະເວົ້າຫຍັງກ່ຽວກັບຫນ້າທີ່ຕິດຕາມຄວາມປອດໄພຂອງຂໍ້ມູນໃນ Azure, ທ່ານຄວນຕັ້ງຄ່າພວກມັນຢ່າງລະມັດລະວັງແລະທົດສອບວ່າພວກເຂົາເຮັດວຽກຕາມທີ່ຂຽນໄວ້ໃນເອກະສານແລະ. ດັ່ງທີ່ປຶກສາບອກທ່ານ Microsoft (ແລະພວກເຂົາອາດມີທັດສະນະທີ່ແຕກຕ່າງກັນກ່ຽວກັບຫນ້າທີ່ຂອງ Azure). ຖ້າທ່ານມີຊັບພະຍາກອນທາງດ້ານການເງິນ, ທ່ານສາມາດບີບເອົາຂໍ້ມູນທີ່ເປັນປະໂຫຍດຫຼາຍຈາກ Azure ໃນແງ່ຂອງການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນ. ຖ້າຊັບພະຍາກອນຂອງທ່ານມີຈໍາກັດ, ເຊັ່ນດຽວກັບໃນກໍລະນີຂອງ AWS, ທ່ານຈະຕ້ອງອີງໃສ່ພຽງແຕ່ຄວາມເຂັ້ມແຂງຂອງທ່ານເອງແລະຂໍ້ມູນດິບທີ່ Azure Monitor ໃຫ້ທ່ານ. ແລະຈື່ໄວ້ວ່າຫຼາຍຫນ້າທີ່ຕິດຕາມຄ່າໃຊ້ຈ່າຍແລະມັນກໍ່ດີກວ່າທີ່ຈະຄຸ້ນເຄີຍກັບນະໂຍບາຍລາຄາລ່ວງຫນ້າ. ສໍາລັບຕົວຢ່າງ, ສໍາລັບການຟຣີທ່ານສາມາດເກັບຮັກສາ 31 ມື້ຂອງຂໍ້ມູນໄດ້ສູງສຸດຂອງ 5 GB ຕໍ່ລູກຄ້າ - ເກີນມູນຄ່າເຫຼົ່ານີ້ຈະຕ້ອງໃຫ້ທ່ານ fork ອອກເງິນເພີ່ມເຕີມ (ປະມານ $2+ ສໍາລັບການເກັບຮັກສາແຕ່ລະ GB ເພີ່ມເຕີມຈາກລູກຄ້າແລະ $0,1 ສໍາລັບ. ການເກັບຮັກສາ 1 GB ໃນແຕ່ລະເດືອນເພີ່ມເຕີມ). ການເຮັດວຽກກັບຄໍາຮ້ອງສະຫມັກ telemetry ແລະ metrics ອາດຈະຕ້ອງການເງິນເພີ່ມເຕີມ, ເຊັ່ນດຽວກັນກັບການເຮັດວຽກກັບການແຈ້ງເຕືອນແລະການແຈ້ງເຕືອນ (ຂອບເຂດຈໍາກັດທີ່ແນ່ນອນແມ່ນສາມາດໃຊ້ໄດ້ຟຣີ, ເຊິ່ງອາດຈະບໍ່ພຽງພໍກັບຄວາມຕ້ອງການຂອງທ່ານ).

ຕົວຢ່າງ: ການຕິດຕາມຄວາມປອດໄພຂອງຂໍ້ມູນໃນ IaaS ໂດຍອີງໃສ່ Google Cloud Platform

Google Cloud Platform ເບິ່ງຄືວ່າເດັກນ້ອຍເມື່ອທຽບກັບ AWS ແລະ Azure, ແຕ່ນີ້ແມ່ນສ່ວນຫນຶ່ງທີ່ດີ. ບໍ່ເຫມືອນກັບ AWS, ເຊິ່ງເພີ່ມຄວາມສາມາດຂອງຕົນ, ລວມທັງຄວາມປອດໄພ, ຄ່ອຍໆ, ມີບັນຫາກັບສູນກາງ; GCP, ເຊັ່ນ Azure, ແມ່ນການຄຸ້ມຄອງທີ່ດີກວ່າຫຼາຍສູນກາງ, ເຊິ່ງຫຼຸດຜ່ອນຄວາມຜິດພາດແລະເວລາການປະຕິບັດໃນທົ່ວວິສາຫະກິດ. ຈາກທັດສະນະຄວາມປອດໄພ, GCP ແມ່ນ, oddly ພຽງພໍ, ລະຫວ່າງ AWS ແລະ Azure. ລາວຍັງມີການລົງທະບຽນເຫດການດຽວສໍາລັບອົງການຈັດຕັ້ງທັງຫມົດ, ແຕ່ມັນບໍ່ຄົບຖ້ວນ. ບາງຫນ້າທີ່ຍັງຢູ່ໃນໂຫມດເບຕ້າ, ແຕ່ຄ່ອຍໆຂາດແຄນນີ້ຄວນຈະຖືກລົບລ້າງແລະ GCP ຈະກາຍເປັນແພລະຕະຟອມທີ່ໃຫຍ່ກວ່າໃນການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນ.

ເຄື່ອງມືຕົ້ນຕໍສໍາລັບການບັນທຶກເຫດການໃນ GCP ແມ່ນ Stackdriver Logging (ຄ້າຍກັບ Azure Monitor), ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດເກັບກໍາເຫດການໃນທົ່ວໂຄງສ້າງພື້ນຖານຂອງຟັງທັງຫມົດຂອງທ່ານ (ເຊັ່ນດຽວກັນກັບ AWS). ຈາກທັດສະນະຄວາມປອດໄພໃນ GCP, ແຕ່ລະອົງການຈັດຕັ້ງ, ໂຄງການຫຼືໂຟນເດີມີສີ່ບັນທຶກ:

ກິດຈະກໍາ Admin - ປະກອບມີເຫດການທັງຫມົດທີ່ກ່ຽວຂ້ອງກັບການເຂົ້າເຖິງການບໍລິຫານ, ສໍາລັບການຍົກຕົວຢ່າງ, ການສ້າງ virtual machine, ການປ່ຽນແປງສິດທິການເຂົ້າເຖິງ, ແລະອື່ນໆ. ບັນທຶກນີ້ຖືກຂຽນຢູ່ສະເໝີ, ໂດຍບໍ່ຄໍານຶງເຖິງຄວາມປາຖະຫນາຂອງເຈົ້າ, ແລະເກັບຮັກສາຂໍ້ມູນຂອງມັນໄວ້ເປັນເວລາ 400 ມື້.
ການເຂົ້າເຖິງຂໍ້ມູນ - ປະກອບດ້ວຍເຫດການທັງຫມົດທີ່ກ່ຽວຂ້ອງກັບການເຮັດວຽກກັບຂໍ້ມູນໂດຍຜູ້ໃຊ້ຟັງ (ການສ້າງ, ການດັດແກ້, ການອ່ານ, ແລະອື່ນໆ). ໂດຍຄ່າເລີ່ມຕົ້ນ, ບັນທຶກນີ້ບໍ່ໄດ້ຖືກຂຽນ, ເພາະວ່າປະລິມານຂອງມັນຈະບວມຢ່າງໄວວາ. ສໍາລັບເຫດຜົນນີ້, ຊີວິດ shelf ຂອງມັນແມ່ນພຽງແຕ່ 30 ມື້. ນອກຈາກນັ້ນ, ບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງແມ່ນຂຽນຢູ່ໃນວາລະສານນີ້. ຕົວຢ່າງ, ເຫດການທີ່ກ່ຽວຂ້ອງກັບຊັບພະຍາກອນທີ່ຜູ້ໃຊ້ທຸກຄົນສາມາດເຂົ້າເຖິງໄດ້ໂດຍສາທາລະນະຫຼືທີ່ສາມາດເຂົ້າເຖິງໄດ້ໂດຍບໍ່ມີການເຂົ້າສູ່ລະບົບ GCP ບໍ່ໄດ້ຖືກຂຽນໃສ່ມັນ.
ເຫດການລະບົບ - ປະກອບມີເຫດການລະບົບທີ່ບໍ່ກ່ຽວຂ້ອງກັບຜູ້ໃຊ້, ຫຼືການກະທໍາຂອງຜູ້ບໍລິຫານທີ່ປ່ຽນແປງການຕັ້ງຄ່າຂອງຊັບພະຍາກອນຄລາວ. ມັນຖືກຂຽນແລະເກັບໄວ້ຕະຫຼອດເວລາ 400 ມື້.
ຄວາມໂປ່ງໃສໃນການເຂົ້າເຖິງເປັນຕົວຢ່າງທີ່ເປັນເອກະລັກຂອງບັນທຶກທີ່ຈັບເອົາທຸກການກະທໍາຂອງພະນັກງານ Google (ແຕ່ຍັງບໍ່ທັນສໍາລັບການບໍລິການ GCP ທັງຫມົດ) ຜູ້ທີ່ເຂົ້າເຖິງໂຄງສ້າງພື້ນຖານຂອງທ່ານເປັນສ່ວນຫນຶ່ງຂອງຫນ້າທີ່ວຽກເຮັດງານທໍາຂອງເຂົາເຈົ້າ. ບັນທຶກນີ້ຖືກເກັບໄວ້ເປັນເວລາ 400 ມື້ແລະບໍ່ມີໃຫ້ລູກຄ້າ GCP ທຸກໆຄົນ, ແຕ່ວ່າພຽງແຕ່ຖ້າເງື່ອນໄຂຈໍານວນຫນຶ່ງຖືກບັນລຸ (ບໍ່ວ່າຈະເປັນການສະຫນັບສະຫນູນລະດັບ Gold ຫຼື Platinum, ຫຼືການປະກົດຕົວຂອງ 4 ບົດບາດຂອງບາງປະເພດເປັນສ່ວນຫນຶ່ງຂອງການສະຫນັບສະຫນູນຂອງບໍລິສັດ). ມີຟັງຊັນທີ່ຄ້າຍຄືກັນ, ຕົວຢ່າງ, ໃນ Office 365 - Lockbox.

ຕົວຢ່າງບັນທຶກ: ຄວາມໂປ່ງໃສໃນການເຂົ້າເຖິງ

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

ການເຂົ້າເຖິງບັນທຶກເຫຼົ່ານີ້ເປັນໄປໄດ້ໃນຫຼາຍວິທີ (ໃນຫຼາຍວິທີດຽວກັນກັບ Azure ແລະ AWS ທີ່ໄດ້ສົນທະນາຜ່ານມາ) - ຜ່ານການໂຕ້ຕອບ Log Viewer, ຜ່ານ API, ຜ່ານ Google Cloud SDK, ຫຼືຜ່ານຫນ້າກິດຈະກໍາຂອງໂຄງການທີ່ທ່ານ. ມີຄວາມສົນໃຈໃນເຫດການ. ໃນທາງດຽວກັນ, ພວກເຂົາສາມາດຖືກສົ່ງອອກໄປສູ່ການແກ້ໄຂພາຍນອກສໍາລັບການວິເຄາະເພີ່ມເຕີມ. ອັນສຸດທ້າຍແມ່ນເຮັດໄດ້ໂດຍການສົ່ງອອກບັນທຶກໄປຍັງ BigQuery ຫຼື Cloud Pub/Sub storage.

ນອກເຫນືອໄປຈາກ Stackdriver Logging, ແພລະຕະຟອມ GCP ຍັງສະຫນອງການເຮັດວຽກຂອງ Stackdriver Monitoring, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດຕິດຕາມຕົວຊີ້ວັດທີ່ສໍາຄັນ (ການປະຕິບັດ, MTBF, ສຸຂະພາບໂດຍລວມ, ແລະອື່ນໆ) ຂອງບໍລິການຟັງແລະຄໍາຮ້ອງສະຫມັກ. ຂໍ້ມູນທີ່ຖືກປະມວນຜົນແລະເປັນພາບສາມາດເຮັດໃຫ້ມັນງ່າຍຂຶ້ນໃນການຊອກຫາບັນຫາໃນໂຄງສ້າງພື້ນຖານຄລາວຂອງທ່ານ, ລວມທັງໃນແງ່ຂອງຄວາມປອດໄພ. ແຕ່ຄວນສັງເກດວ່າຫນ້າທີ່ນີ້ຈະບໍ່ອຸດົມສົມບູນຫຼາຍໃນແງ່ຂອງຄວາມປອດໄພຂອງຂໍ້ມູນ, ນັບຕັ້ງແຕ່ມື້ນີ້ GCP ບໍ່ມີ analogue ຂອງ AWS GuardDuty ດຽວກັນແລະບໍ່ສາມາດກໍານົດສິ່ງທີ່ບໍ່ດີໃນບັນດາເຫດການທີ່ລົງທະບຽນທັງຫມົດ (Google ໄດ້ພັດທະນາການກວດພົບໄພຂົ່ມຂູ່ຕໍ່ເຫດການ, ແຕ່ມັນຍັງຢູ່ໃນການພັດທະນາຢູ່ໃນເບຕ້າແລະມັນໄວເກີນໄປທີ່ຈະເວົ້າກ່ຽວກັບປະໂຫຍດຂອງມັນ). Stackdriver Monitoring ສາມາດຖືກນໍາໃຊ້ເປັນລະບົບໃນການກວດສອບຄວາມຜິດປົກກະຕິ, ເຊິ່ງຫຼັງຈາກນັ້ນຈະຖືກສືບສວນເພື່ອຊອກຫາສາເຫດຂອງການປະກົດຕົວຂອງມັນ. ແຕ່ເນື່ອງຈາກຂາດບຸກຄະລາກອນທີ່ມີຄຸນສົມບັດໃນດ້ານຄວາມປອດໄພຂອງຂໍ້ມູນ GCP ໃນຕະຫຼາດ, ວຽກງານນີ້ເບິ່ງຄືວ່າມີຄວາມຫຍຸ້ງຍາກໃນປັດຈຸບັນ.

ມັນຍັງມີມູນຄ່າໃຫ້ບັນຊີລາຍຊື່ຂອງບາງໂມດູນຄວາມປອດໄພຂໍ້ມູນທີ່ສາມາດຖືກນໍາໃຊ້ພາຍໃນ GCP cloud ຂອງທ່ານ, ແລະຄ້າຍຄືກັນກັບສິ່ງທີ່ AWS ສະເຫນີ:

Cloud Security Command Center ເປັນການປຽບທຽບຂອງ AWS Security Hub ແລະ Azure Security Center.
Cloud DLP - ການຄົ້ນພົບ ແລະແກ້ໄຂອັດຕະໂນມັດ (ເຊັ່ນ: ການປິດບັງ) ຂໍ້ມູນທີ່ຖືກໂຮດຢູ່ໃນຄລາວໂດຍໃຊ້ຫຼາຍກວ່າ 90 ນະໂຍບາຍການຈັດປະເພດທີ່ກໍານົດໄວ້ກ່ອນ.
Cloud Scanner ເປັນເຄື່ອງສະແກນຫາຊ່ອງໂຫວ່ທີ່ຮູ້ຈັກ (XSS, Flash Injection, unpatched libraries, ແລະອື່ນໆ) ໃນ App Engine, Compute Engine ແລະ Google Kubernetes.
Cloud IAM - ຄວບຄຸມການເຂົ້າເຖິງຊັບພະຍາກອນ GCP ທັງໝົດ.
Cloud Identity - ຈັດການຜູ້ໃຊ້ GCP, ອຸປະກອນ ແລະບັນຊີແອັບພລິເຄຊັນຈາກຄອນໂຊນດຽວ.
Cloud HSM - ການປົກປ້ອງລະຫັດລັບ.
ບໍລິການຈັດການກະແຈຄລາວ - ການຈັດການລະຫັດລັບໃນ GCP.
ການຄວບຄຸມການບໍລິການ VPC - ສ້າງຂອບເຂດທີ່ປອດໄພຮອບຊັບພະຍາກອນ GCP ຂອງທ່ານເພື່ອປົກປ້ອງພວກເຂົາຈາກການຮົ່ວໄຫຼ.
ກະແຈຄວາມປອດໄພ Titan - ປ້ອງກັນການຫຼອກເອົາຂໍ້ມູນ.

ຫຼາຍໆໂມດູນເຫຼົ່ານີ້ສ້າງເຫດການຄວາມປອດໄພທີ່ສາມາດຖືກສົ່ງໄປຫາບ່ອນເກັບຂໍ້ມູນ BigQuery ສໍາລັບການວິເຄາະຫຼືສົ່ງອອກໄປຍັງລະບົບອື່ນໆ, ລວມທັງ SIEM. ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, GCP ເປັນແພລະຕະຟອມທີ່ກໍາລັງພັດທະນາຢ່າງຫ້າວຫັນແລະ Google ກໍາລັງພັດທະນາໂມດູນຄວາມປອດໄພຂໍ້ມູນໃຫມ່ສໍາລັບເວທີຂອງຕົນ. ໃນບັນດາພວກມັນແມ່ນການກວດຫາໄພຂົ່ມຂູ່ຕໍ່ເຫດການ (ປະຈຸບັນມີຢູ່ໃນເບຕ້າ), ເຊິ່ງສະແກນບັນທຶກ Stackdriver ໃນການຊອກຫາການຕິດຕາມຂອງກິດຈະກໍາທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ (ປຽບທຽບກັບ GuardDuty ໃນ AWS), ຫຼື Policy Intelligence (ມີຢູ່ໃນ alpha), ເຊິ່ງຈະຊ່ວຍໃຫ້ທ່ານສາມາດພັດທະນານະໂຍບາຍອັດສະລິຍະສໍາລັບ ການເຂົ້າເຖິງຊັບພະຍາກອນ GCP.

ຂ້າພະເຈົ້າໄດ້ສະຫຼຸບສັ້ນໆກ່ຽວກັບຄວາມສາມາດໃນການຕິດຕາມທີ່ສ້າງຂຶ້ນໃນເວທີຄລາວທີ່ນິຍົມ. ແຕ່ທ່ານມີຜູ້ຊ່ຽວຊານທີ່ສາມາດເຮັດວຽກກັບບັນທຶກຂອງຜູ້ໃຫ້ບໍລິການ IaaS "ດິບ" (ບໍ່ແມ່ນທຸກຄົນພ້ອມທີ່ຈະຊື້ຄວາມສາມາດຂັ້ນສູງຂອງ AWS ຫຼື Azure ຫຼື Google) ບໍ? ນອກຈາກນັ້ນ, ຫຼາຍຄົນຍັງຄຸ້ນເຄີຍກັບຄໍາສຸພາສິດ "ໄວ້ວາງໃຈ, ແຕ່ຢືນຢັນ," ເຊິ່ງແມ່ນຄວາມຈິງກວ່າທີ່ເຄີຍຢູ່ໃນພາກສະຫນາມຂອງຄວາມປອດໄພ. ເຈົ້າເຊື່ອໝັ້ນຄວາມສາມາດໃນຕົວຂອງຜູ້ໃຫ້ບໍລິການຄລາວຫຼາຍປານໃດທີ່ສົ່ງເຫດການຄວາມປອດໄພຂໍ້ມູນໃຫ້ທ່ານ? ພວກເຂົາເຈົ້າສຸມໃສ່ຄວາມປອດໄພຂອງຂໍ້ມູນຫຼາຍປານໃດ?

ບາງຄັ້ງມັນຄຸ້ມຄ່າໃນການເບິ່ງໂຊລູຊັນການຕິດຕາມໂຄງສ້າງພື້ນຖານຂອງຄລາວທີ່ຊ້ອນກັນ ທີ່ສາມາດເສີມຄວາມປອດໄພໃນຄລາວໃນຕົວໄດ້, ແລະບາງຄັ້ງການແກ້ໄຂດັ່ງກ່າວເປັນທາງເລືອກດຽວທີ່ຈະໄດ້ຮັບຄວາມເຂົ້າໃຈກ່ຽວກັບຄວາມປອດໄພຂອງຂໍ້ມູນ ແລະແອັບພລິເຄຊັນທີ່ໂຮດຢູ່ໃນຄລາວ. ນອກຈາກນັ້ນ, ພວກເຂົາພຽງແຕ່ສະດວກກວ່າ, ຍ້ອນວ່າພວກເຂົາປະຕິບັດວຽກງານທັງຫມົດຂອງການວິເຄາະບັນທຶກທີ່ຈໍາເປັນທີ່ສ້າງຂຶ້ນໂດຍບໍລິການຟັງທີ່ແຕກຕ່າງກັນຈາກຜູ້ໃຫ້ບໍລິການຟັງທີ່ແຕກຕ່າງກັນ. ຕົວຢ່າງຂອງການແກ້ໄຂການຊ້ອນກັນດັ່ງກ່າວແມ່ນ Cisco Stealthwatch Cloud, ເຊິ່ງໄດ້ສຸມໃສ່ວຽກງານດຽວ - ການຕິດຕາມຄວາມຜິດປົກກະຕິຂອງຄວາມປອດໄພຂອງຂໍ້ມູນໃນສະພາບແວດລ້ອມຟັງ, ລວມທັງບໍ່ພຽງແຕ່ Amazon AWS, Microsoft Azure ແລະ Google Cloud Platform, ແຕ່ຍັງຟັງເອກະຊົນ.

ຕົວຢ່າງ: ການຕິດຕາມຄວາມປອດໄພຂອງຂໍ້ມູນໂດຍໃຊ້ Stealthwatch Cloud

AWS ສະຫນອງແພລະຕະຟອມຄອມພິວເຕີ້ທີ່ມີຄວາມຍືດຫຍຸ່ນ, ແຕ່ຄວາມຍືດຫຍຸ່ນນີ້ເຮັດໃຫ້ມັນງ່າຍຂຶ້ນສໍາລັບບໍລິສັດທີ່ຈະເຮັດຄວາມຜິດພາດທີ່ນໍາໄປສູ່ບັນຫາຄວາມປອດໄພ. ແລະຮູບແບບຄວາມປອດໄພຂອງຂໍ້ມູນທີ່ແບ່ງປັນພຽງແຕ່ປະກອບສ່ວນກັບເລື່ອງນີ້. ແລ່ນຊອບແວໃນຄລາວດ້ວຍຊ່ອງໂຫວ່ທີ່ບໍ່ຮູ້ຈັກ (ອັນທີ່ຮູ້ຈັກສາມາດຕໍ່ສູ້ກັບໄດ້, ຕົວຢ່າງ, ໂດຍ AWS Inspector ຫຼື GCP Cloud Scanner), ລະຫັດຜ່ານທີ່ອ່ອນແອ, ການຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ, ພາຍໃນ, ແລະອື່ນໆ. ແລະທັງຫມົດນີ້ແມ່ນສະທ້ອນໃຫ້ເຫັນໃນພຶດຕິກໍາຂອງຊັບພະຍາກອນເມຄ, ເຊິ່ງສາມາດຕິດຕາມໄດ້ໂດຍ Cisco Stealthwatch Cloud, ເຊິ່ງເປັນລະບົບການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນແລະການໂຈມຕີ. ຟັງສາທາລະນະ ແລະເອກະຊົນ.

ຫນຶ່ງໃນລັກສະນະທີ່ສໍາຄັນຂອງ Cisco Stealthwatch Cloud ແມ່ນຄວາມສາມາດໃນການສ້າງແບບຈໍາລອງຫນ່ວຍງານ. ດ້ວຍມັນ, ທ່ານສາມາດສ້າງແບບຈໍາລອງຊໍແວ (ນັ້ນຄືການຈໍາລອງເວລາທີ່ແທ້ຈິງ) ຂອງແຕ່ລະຊັບພະຍາກອນຄລາວຂອງທ່ານ (ມັນບໍ່ສໍາຄັນບໍ່ວ່າຈະເປັນ AWS, Azure, GCP, ຫຼືສິ່ງອື່ນ). ເຫຼົ່ານີ້ສາມາດປະກອບມີເຄື່ອງແມ່ຂ່າຍແລະຜູ້ໃຊ້, ເຊັ່ນດຽວກັນກັບປະເພດຊັບພະຍາກອນສະເພາະກັບສະພາບແວດລ້ອມຟັງຂອງທ່ານ, ເຊັ່ນ: ກຸ່ມຄວາມປອດໄພແລະກຸ່ມຂະຫນາດອັດຕະໂນມັດ. ຮູບແບບເຫຼົ່ານີ້ໃຊ້ການຖ່າຍທອດຂໍ້ມູນທີ່ມີໂຄງສ້າງທີ່ສະໜອງໃຫ້ໂດຍການບໍລິການຄລາວເປັນການປ້ອນຂໍ້ມູນ. ຕົວຢ່າງ, ສໍາລັບ AWS ເຫຼົ່ານີ້ຈະເປັນ VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda, ແລະ AWS IAM. ການສ້າງແບບຈໍາລອງນິຕິບຸກຄົນຈະຄົ້ນພົບບົດບາດ ແລະພຶດຕິກໍາຂອງຊັບພະຍາກອນໃດໜຶ່ງຂອງເຈົ້າໂດຍອັດຕະໂນມັດ (ທ່ານສາມາດສົນທະນາກ່ຽວກັບການສ້າງໂປຣໄຟລ໌ທັງໝົດການເຄື່ອນໄຫວໃນຄລາວ). ບົດບາດເຫຼົ່ານີ້ລວມມີອຸປະກອນມືຖື Android ຫຼື Apple, Citrix PVS server, RDP server, mail gateway, VoIP client, terminal server, domain controller, etc. ຫຼັງຈາກນັ້ນ, ມັນຕິດຕາມພຶດຕິກໍາຂອງພວກເຂົາຢ່າງຕໍ່ເນື່ອງເພື່ອກໍານົດເວລາທີ່ພຶດຕິກໍາທີ່ມີຄວາມສ່ຽງຫຼືໄພຂົ່ມຂູ່ຕໍ່ຄວາມປອດໄພເກີດຂື້ນ. ທ່ານສາມາດກໍານົດການຄາດເດົາລະຫັດຜ່ານ, ການໂຈມຕີ DDoS, ການຮົ່ວໄຫລຂອງຂໍ້ມູນ, ການເຂົ້າເຖິງຫ່າງໄກສອກຫຼີກທີ່ຜິດກົດຫມາຍ, ກິດຈະກໍາລະຫັດທີ່ເປັນອັນຕະລາຍ, ການສະແກນຊ່ອງໂຫວ່ແລະໄພຂົ່ມຂູ່ອື່ນໆ. ຕົວຢ່າງ, ນີ້ແມ່ນສິ່ງທີ່ກວດພົບຄວາມພະຍາຍາມໃນການເຂົ້າເຖິງຫ່າງໄກສອກຫຼີກຈາກປະເທດທີ່ຜິດປົກກະຕິສໍາລັບອົງການຂອງເຈົ້າ (ເກົາຫລີໃຕ້) ໄປຫາກຸ່ມ Kubernetes ຜ່ານ SSH ເບິ່ງຄືວ່າ:

ແລະນີ້ແມ່ນສິ່ງທີ່ຖືກກ່າວຫາວ່າຮົ່ວໄຫລຂອງຂໍ້ມູນຈາກຖານຂໍ້ມູນ Postgress ໄປຫາປະເທດທີ່ພວກເຮົາບໍ່ເຄີຍພົບການໂຕ້ຕອບກ່ອນຫນ້ານີ້ເບິ່ງຄືວ່າ:

ສຸດທ້າຍ, ນີ້ແມ່ນຄວາມພະຍາຍາມ SSH ທີ່ລົ້ມເຫລວຫຼາຍເກີນໄປຈາກຈີນແລະອິນໂດເນເຊຍຈາກອຸປະກອນຫ່າງໄກສອກຫຼີກພາຍນອກເບິ່ງຄືວ່າ:

ຫຼື, ສົມມຸດວ່າຕົວຢ່າງເຊີຟເວີໃນ VPC ແມ່ນ, ໂດຍນະໂຍບາຍ, ບໍ່ເຄີຍເປັນຈຸດຫມາຍປາຍທາງການເຂົ້າສູ່ລະບົບຫ່າງໄກສອກຫຼີກ. ໃຫ້ສົມມຸດຕື່ມອີກວ່າຄອມພິວເຕີເຄື່ອງນີ້ປະສົບກັບການເຂົ້າສູ່ລະບົບທາງໄກເນື່ອງຈາກການປ່ຽນແປງທີ່ຜິດພາດໃນນະໂຍບາຍກົດລະບຽບຂອງໄຟວໍ. ຄຸນສົມບັດການສ້າງແບບຈໍາລອງ Entity ຈະກວດຫາ ແລະລາຍງານການເຄື່ອນໄຫວນີ້ (“ການເຂົ້າຫາທາງໄກທີ່ຜິດປົກກະຕິ”) ໃນເວລາຈິງໃກ້ໆ ແລະຊີ້ໄປທີ່ການເອີ້ນສະເພາະ AWS CloudTrail, Azure Monitor, ຫຼື GCP Stackdriver Logging API (ລວມທັງຊື່ຜູ້ໃຊ້, ວັນທີ ແລະເວລາ, ໃນບັນດາລາຍລະອຽດອື່ນໆ. ) ເຊິ່ງກະຕຸ້ນໃຫ້ມີການປ່ຽນແປງກົດລະບຽບ ITU. ແລະຫຼັງຈາກນັ້ນຂໍ້ມູນນີ້ສາມາດຖືກສົ່ງໄປຫາ SIEM ສໍາລັບການວິເຄາະ.

ຄວາມສາມາດທີ່ຄ້າຍຄືກັນໄດ້ຖືກປະຕິບັດສໍາລັບສະພາບແວດລ້ອມຄລາວໃດກໍ່ຕາມທີ່ສະຫນັບສະຫນູນໂດຍ Cisco Stealthwatch Cloud:

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

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

ເຫດການຄວາມປອດໄພຂອງຂໍ້ມູນທີ່ກວດພົບສາມາດຖືກສົ່ງໃນຮູບແບບຂອງປີ້ທີ່ສອດຄ້ອງກັນກັບ Slack, Cisco Spark, ລະບົບການຈັດການເຫດການ PagerDuty, ແລະຍັງຖືກສົ່ງໄປຫາ SIEMs ຕ່າງໆ, ລວມທັງ Splunk ຫຼື ELK. ເພື່ອສະຫຼຸບ, ພວກເຮົາສາມາດເວົ້າໄດ້ວ່າຖ້າບໍລິສັດຂອງທ່ານໃຊ້ກົນລະຍຸດຫຼາຍເມຄແລະບໍ່ຈໍາກັດກັບຜູ້ໃຫ້ບໍລິການ cloud ໃດຫນຶ່ງ, ຄວາມສາມາດໃນການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ, ຫຼັງຈາກນັ້ນການນໍາໃຊ້ Cisco Stealthwatch Cloud ເປັນທາງເລືອກທີ່ດີທີ່ຈະໄດ້ຮັບຊຸດການຕິດຕາມແບບປະສົມປະສານ. ຄວາມສາມາດສໍາລັບຜູ້ນຟັງຊັ້ນນໍາ - Amazon , Microsoft ແລະ Google. ສິ່ງທີ່ຫນ້າສົນໃຈທີ່ສຸດແມ່ນວ່າຖ້າທ່ານປຽບທຽບລາຄາຂອງ Stealthwatch Cloud ທີ່ມີໃບອະນຸຍາດຂັ້ນສູງສໍາລັບການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນໃນ AWS, Azure ຫຼື GCP, ມັນອາດຈະເຫັນວ່າການແກ້ໄຂ Cisco ຈະມີລາຄາຖືກກວ່າຄວາມສາມາດໃນຕົວຂອງ Amazon, Microsoft. ແລະວິທີແກ້ໄຂ Google. ມັນເປັນ paradoxical, ແຕ່ວ່າມັນເປັນຄວາມຈິງ. ແລະມີຟັງຫຼາຍແລະຄວາມສາມາດຂອງພວກມັນທີ່ທ່ານໃຊ້, ຄວາມໄດ້ປຽບຂອງການແກ້ໄຂລວມຈະເຫັນໄດ້ຊັດເຈນ.

ນອກຈາກນັ້ນ, Stealthwatch Cloud ສາມາດຕິດຕາມຟັງຄລາວສ່ວນຕົວທີ່ນຳໃຊ້ຢູ່ໃນອົງກອນຂອງທ່ານ, ຕົວຢ່າງ, ອີງໃສ່ຕູ້ຄອນເທນເນີ Kubernetes ຫຼືໂດຍການຕິດຕາມກະແສຂອງ Netflow ຫຼືການສັນຈອນຂອງເຄືອຂ່າຍທີ່ໄດ້ຮັບຜ່ານການສະທ້ອນໃນອຸປະກອນເຄືອຂ່າຍ (ແມ້ແຕ່ຜະລິດພາຍໃນປະເທດ), ຂໍ້ມູນ AD ຫຼື ເຊີບເວີ DNS ແລະອື່ນໆ. ຂໍ້ມູນທັງໝົດນີ້ຈະຖືກເພີ່ມຕື່ມດ້ວຍຂໍ້ມູນ Threat Intelligence ທີ່ເກັບກຳໂດຍ Cisco Talos, ກຸ່ມນັກຄົ້ນຄວ້າດ້ານຄວາມປອດໄພທາງອິນເຕີເນັດທີ່ໃຫຍ່ທີ່ສຸດໃນໂລກ.

ນີ້ອະນຸຍາດໃຫ້ທ່ານປະຕິບັດລະບົບການຕິດຕາມແບບປະສົມປະສານສໍາລັບທັງຟັງສາທາລະນະແລະປະສົມປະສານທີ່ບໍລິສັດຂອງທ່ານອາດຈະໃຊ້. ຂໍ້ມູນທີ່ເກັບກໍາຫຼັງຈາກນັ້ນສາມາດຖືກວິເຄາະໂດຍໃຊ້ຄວາມສາມາດໃນຕົວຂອງ Stealthwatch Cloud ຫຼືຖືກສົ່ງໄປຫາ SIEM ຂອງທ່ານ (Splunk, ELK, SumoLogic ແລະອື່ນໆຈໍານວນຫນຶ່ງແມ່ນສະຫນັບສະຫນູນໂດຍຄ່າເລີ່ມຕົ້ນ).

ດ້ວຍນີ້, ພວກເຮົາຈະເຮັດສໍາເລັດສ່ວນທໍາອິດຂອງບົດຄວາມ, ໃນທີ່ຂ້ອຍໄດ້ທົບທວນຄືນເຄື່ອງມືໃນຕົວແລະພາຍນອກສໍາລັບການກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນຂອງແພລະຕະຟອມ IaaS / PaaS, ເຊິ່ງຊ່ວຍໃຫ້ພວກເຮົາສາມາດກວດສອບແລະຕອບສະຫນອງໄດ້ໄວຕໍ່ເຫດການທີ່ເກີດຂຶ້ນໃນສະພາບແວດລ້ອມຟັງ. ວິສາຫະກິດຂອງພວກເຮົາໄດ້ເລືອກ. ໃນພາກທີສອງ, ພວກເຮົາຈະສືບຕໍ່ຫົວຂໍ້ແລະເບິ່ງທາງເລືອກໃນການກວດສອບແພລະຕະຟອມ SaaS ໂດຍໃຊ້ຕົວຢ່າງຂອງ Salesforce ແລະ Dropbox, ແລະພວກເຮົາຍັງຈະພະຍາຍາມສະຫຼຸບແລະວາງທຸກສິ່ງທຸກຢ່າງຮ່ວມກັນໂດຍການສ້າງລະບົບການຕິດຕາມຄວາມປອດໄພຂອງຂໍ້ມູນສໍາລັບຜູ້ໃຫ້ບໍລິການຟັງທີ່ແຕກຕ່າງກັນ.

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

ການຕິດຕາມຄວາມປອດໄພຄລາວ