ຮຸກ: ມື້ທີ່ Pipeline ຫັກ (Chmod 777)
ໃນເວລາທີ່ມັນມາກັບການ CI/CD ຄວາມປອດໄພ, ມີຄວາມຜິດພາດໜ້ອຍຢ່າງທີ່ເປັນອັນຕະລາຍເທົ່າກັບການໃຊ້ງານ chmod 777. ການໃຊ້ມັນໃນທາງທີ່ຜິດຈະລົບລ້າງສິດອະນຸຍາດຂອງ Linux, ເຮັດໃຫ້ການປ້ອງກັນຫາຍໄປ ແລະ ເປີດປະຕູສູ່ການໂຈມຕີທາງຫຼັງທີ່ອາດເກີດຂຶ້ນ. ມັນເລີ່ມຕົ້ນແບບນີ້: ການ CI/CD pipeline ເປັນສີແດງ, ທີມຖືກບລັອກ, ແລະເຄື່ອງໝາຍໄດ້ຖົ່ມຂໍ້ຄວາມທີ່ໜ້າຢ້ານກົວອອກມາ:
nginx
ການອະນຸຍາດຖືກປະຕິເສດ
ແທນທີ່ຈະຕິດຕາມສາເຫດຕົ້ນຕໍ, ນັກພັດທະນາໄດ້ເຂົ້າຫາທາງເລືອກນິວເຄຼຍ:
⚠️ ຕົວຢ່າງທີ່ບໍ່ປອດໄພ: ໃຫ້ສິດການເຂົ້າເຖິງຢ່າງເຕັມທີ່ແກ່ທຸກຄົນ. ຫ້າມໃຊ້ໃນຮຸ່ນທີ່ໃຊ້ງານ.
chmod 777 deploy.sh
ການກໍ່ສ້າງກາຍເປັນສີຂຽວ. ຄວາມກົດດັນຫຼຸດລົງ. ທຸກຄົນກັບຄືນໄປເຮັດວຽກ. ແຕ່ໃນພື້ນຫຼັງ, ຄຳສັ່ງດຽວນັ້ນໄດ້ຂ້າມສິດອະນຸຍາດໃນການປົກປ້ອງທຸກຢ່າງທີ່ Linux ໃຫ້, ເຊິ່ງເປັນການວາງພື້ນຖານສຳລັບການໂຈມຕີທາງຫຼັງທີ່ອາດຈະເຮັດໃຫ້ລະບົບທັງໝົດເສຍຫາຍ.
ຜົນກະທົບທີ່ແທ້ຈິງຂອງ chmod 777 ຕໍ່ການອະນຸຍາດ Linux
ສິດອະນຸຍາດຂອງ Linux ແມ່ນພື້ນຖານຂອງຄວາມປອດໄພລະດັບໄຟລ໌ໃນລະບົບທີ່ຄ້າຍຄືກັບ Unix. ພວກມັນກຳນົດວ່າໃຜສາມາດອ່ານ, ຂຽນ ຫຼື ປະຕິບັດໄຟລ໌ໄດ້. ທຸກໆໄຟລ໌ມີ:
- ສາມປະເພດການອະນຸຍາດ: ອ່ານ (r), ຂຽນ (w), ແລະປະຕິບັດ (x).
- ສາມກຸ່ມອະນຸຍາດ: ເຈົ້າຂອງ, ກຸ່ມ, ແລະອື່ນໆ.
ເມື່ອທ່ານແລ່ນ chmod 777, ທ່ານກຳລັງໃຫ້ສິດໃນການອ່ານ, ຂຽນ ແລະ ປະຕິບັດແກ່ທັງສາມກຸ່ມ. ມັນເທົ່າກັບການປະໄວ້ທຸກໆປະຕູໃນເຮືອນຂອງທ່ານໂດຍບໍ່ລັອກ, ບໍ່ພຽງແຕ່ສຳລັບໝູ່ເພື່ອນເທົ່ານັ້ນ, ແຕ່ສຳລັບຄົນແປກໜ້າ ແລະ ຜູ້ໃດກໍຕາມທີ່ຜ່ານໄປມາ.
ການສາທິດທີ່ປອດໄພ:
ໃນເຄື່ອງພັດທະນາທີ່ໂດດດ່ຽວ, ສິ່ງນີ້ອາດເບິ່ງຄືວ່າບໍ່ເປັນອັນຕະລາຍ. ແຕ່ໃນຕົວແທນການສ້າງທີ່ໃຊ້ຮ່ວມກັນ, ສະພາບແວດລ້ອມທີ່ມີຕູ້ຄອນເທນເນີ, ຫຼືລະບົບ Linux ທີ່ມີຜູ້ໃຊ້ຫຼາຍຄົນ, chmod 777 ປ່ຽນທຸກໆໄຟລ໌ທີ່ມັນແຕະຕ້ອງໃຫ້ກາຍເປັນການເຊື້ອເຊີນທີ່ເປີດຢູ່ສຳລັບການແຊກແຊງ, ການຕັ້ງຄ່າທີ່ສົມບູນແບບສຳລັບການໂຈມຕີທາງຫຼັງ.
ເວັກເຕີໂຈມຕີ: ຈາກ chmod 777 ຈົນເຖິງການໂຈມຕີ Backdoor
ນີ້ແມ່ນວິທີການດຽວ chmod 777 ສາມາດກາຍເປັນປະຕູຫລັງໄດ້ ການໂຈມຕີ:
- ຊຸດນັກພັດທະນາ chmod 777 ໃນການນຳໃຊ້ ຫຼື ສະຄຣິບສ້າງເພື່ອແກ້ໄຂຂໍ້ຜິດພາດຂອງການອະນຸຍາດ
- ໄຟລ໌ສາມາດຂຽນໄດ້ທົ່ວໂລກ; ຜູ້ໃຊ້ ຫຼື ຂະບວນການໃດໆກໍ່ສາມາດດັດແປງມັນໄດ້
- ຜູ້ໂຈມຕີໃສ່ລະຫັດທີ່ເປັນອັນຕະລາຍເຂົ້າໄປໃນສະຄຣິບ
- ໄດ້ CI/CD pipeline ດໍາເນີນການ script ທີ່ຖືກປ່ຽນແປງ, ປະຕິບັດ payload ຂອງຜູ້ໂຈມຕີດ້ວຍສິດທິພິເສດທີ່ສູງຂຶ້ນ
⚠️ ຕົວຢ່າງທີ່ບໍ່ປອດໄພ: ຫ້າມເຮັດວຽກໃນຮຸ່ນທີ່ໃຊ້ງານ. ໃຊ້ຢູ່ທີ່ນີ້ເພື່ອສະແດງສິດອະນຸຍາດທີ່ມີຄວາມສ່ຽງ.
chmod 777 build.sh
ຂັ້ນຕອນການໂຈມຕີແບບງ່າຍໆ:
ບ່ອນທີ່ສິ່ງນີ້ກາຍເປັນອັນຕະລາຍໂດຍສະເພາະ:
- ຕົວແທນການສ້າງທີ່ໃຊ້ຮ່ວມກັນ ກັບຫຼາຍທີມງານ ຫຼື ຫຼາຍໂຄງການ
- ຕິດຕັ້ງໂວລູມຂອງໂຮສ ໃນ Docker ຫຼື Kubernetes pods
- ບ່ອນເກັບມ້ຽນຂໍ້ມູນແບບໂອເພນຊອສ ບ່ອນທີ່ຜູ້ປະກອບສ່ວນສາມາດຊຸກຍູ້ ຫຼື ຮວມການປ່ຽນແປງຕ່າງໆເຂົ້າກັນໄດ້
ເມື່ອລະບົບຕ່ອງໂສ້ນີ້ເລີ່ມຕົ້ນ, ການໂຈມຕີທາງຫຼັງສາມາດຫັນໄປສູ່ການຜະລິດ, ຮົ່ວໄຫຼຂໍ້ມູນປະຈຳຕົວ, ປ່ຽນແປງສິ່ງປະດິດ, ຫຼືເປີດຈຸດເຂົ້າເຖິງທີ່ຍືນຍົງ.
ການສຶກສາກໍລະນີ: ການໂຈມຕີ Backdoor ຜ່ານ Script ທີ່ຖືກຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ
ຂໍໃຫ້ຕັດມັນລົງມາເປັນສິ່ງຈຳເປັນ:
- ນັກພັດທະນາດໍາເນີນການ chmod 777 build.sh ເພື່ອຫຼີກລ້ຽງ CI/CD ຄວາມຜິດພາດ
- ຜູ້ໃຊ້ອື່ນ ຫຼື ຂະບວນການທີ່ເປັນອັນຕະລາຍໃນສະພາບແວດລ້ອມດຽວກັນແກ້ໄຂສະຄຣິບ
- ໄດ້ pipeline ປະຕິບັດສະຄຣິບທີ່ຖືກທຳລາຍດ້ວຍ CI/CD ການອະນຸຍາດບັນຊີບໍລິການ
- ຖ້າແພັກເກດແຫຼ່ງເປີດທີ່ມີຄວາມສ່ຽງຖືກອັບເດດໃນລະຫວ່າງຂະບວນການນີ້, ການໂຈມຕີທາງຫຼັງສາມາດແຜ່ລາມໄປສູ່ການຜະລິດໄດ້.
ນີ້ແມ່ນວິທີການ chmod 777 ບວກກັບການອະນຸຍາດ Linux ທີ່ຫຼວມສາມາດເຮັດໃຫ້ຜູ້ໂຈມຕີສາມາດຜ່ານເຂົ້າໄປໃນຂັ້ນຕອນການນຳໃຊ້ຂອງທ່ານໄດ້ໂດຍບໍ່ເສຍຄ່າ.
ເປັນຫຍັງນັກພັດທະນາຍັງໃຊ້ chmod 777 (ແລະເປັນຫຍັງມັນຈຶ່ງເປັນກັບດັກ)
ເຖິງແມ່ນວ່ານັກພັດທະນາທີ່ມີປະສົບການກໍ່ຕົກຢູ່ໃນກັບດັກນີ້, ເພາະວ່າ chmod 777 ຮູ້ສຶກຄືກັບການແກ້ໄຂດ່ວນເມື່ອ:
- ການຫຸ້ມຫໍ່ສິ່ງປະດິດສະແດງຂໍ້ຜິດພາດກ່ຽວກັບການປະຕິເສດການອະນຸຍາດ
- ສະຄຣິບ Shell ລົ້ມເຫຼວໃນ Docker ເພາະວ່າມັນບໍ່ສາມາດປະຕິບັດໄດ້
- ບໍ່ສາມາດຂຽນໄຟລ໌ບັນທຶກໃນໂວລູມທີ່ໃຊ້ຮ່ວມກັນໄດ້.
ແຕ່ນີ້ແມ່ນຂໍ້ແກ້ຕົວ: ເຈົ້າຮ້ອງ chmod 777 ບໍ່ສົນໃຈສາເຫດຕົ້ນຕໍ, ລົບລ້າງການຄວບຄຸມສິດອະນຸຍາດຂອງ Linux, ແລະ ລະເມີດຫຼັກການຂອງສິດທິພິເສດໜ້ອຍທີ່ສຸດ. ແທນທີ່ຈະເອົາອຸປະສັກອອກ, ມັນເຊື້ອເຊີນການໂຈມຕີທາງຫຼັງ.
ທາງເລືອກທີ່ປອດໄພຕໍ່ກັບ chmod 777
If chmod 777 ແມ່ນທາງເລືອກນິວເຄຼຍ, ນີ້ແມ່ນການໂຈມຕີທາງການຜ່າຕັດ:
dockerfile ການປະຕິບັດທີ່ດີທີ່ສຸດ:
dockerfile
ການກະ ທຳ ຂອງ GitHub ຍົກຕົວຢ່າງ:
ສິ່ງເຫຼົ່ານີ້ບັງຄັບໃຊ້ສິດອະນຸຍາດຂອງ Linux ຢ່າງຖືກຕ້ອງ, ສະກັດກັ້ນການປ່ຽນແປງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ ແລະ ຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງການໂຈມຕີທາງຫຼັງ.
ວິທີການກວດຫາ ແລະ ປ້ອງກັນການຕັ້ງຄ່າຜິດພາດຂອງ chmod 777
Pre-commit ຂັ້ນຕອນຂອງການ
- Git hooks ປະຕິເສດ commits ປະກອບດ້ວຍ chmod 777:
ຂັ້ນຕອນການສ້າງ
- ຜະສົມຜະສານ SAST ເພື່ອໝາຍເຖິງຄຳສັ່ງທີ່ບໍ່ປອດໄພ
- ວຽກ CI ລົ້ມເຫຼວຖ້າ ຊອກຫາ ກວດພົບໄຟລ໌ທີ່ສາມາດຂຽນໄດ້ທົ່ວໂລກ
ຂັ້ນຕອນການແລ່ນ
ສະແກນຫາໄຟລ໌ທີ່ມີການເຂົ້າເຖິງການຂຽນທົ່ວໂລກ:
ລາຍຊື່ລະຫັດລັບ:
ການບັງຄັບໃຊ້ນະໂຍບາຍ
- ໃຊ້ Policy-as-Code ເພື່ອກຳນົດສິດອະນຸຍາດ Linux ທີ່ໄດ້ຮັບອະນຸຍາດ
- ສົ່ງການແຈ້ງເຕືອນກ່ອນການນຳໃຊ້ທີ່ມີຄວາມສ່ຽງຈະເລີ່ມໃຊ້ງານ
ເມື່ອທ່ານເຮັດການກວດສອບເຫຼົ່ານີ້ໂດຍອັດຕະໂນມັດ, ທ່ານຈະຫຼຸດຜ່ອນໂອກາດທີ່ chmod 777 ເຄີຍຮອດການຜະລິດ, ແລະດ້ວຍມັນ, ໂອກາດທີ່ຈະໂຈມຕີທາງຫຼັງ.
DevSecOps ແລະ ວັດທະນະທຳ: ການປ້ອງກັນ chmod 777 ຢູ່ທີ່ຕົ້ນທາງ
ການສ້າງຄວາມປອດໄພໃນ ວັດທະນະທຳ DevSecOps ມີປະສິດທິພາບຫຼາຍກ່ວາການແກ້ໄຂມັນໃນພາຍຫຼັງ:
- ນະໂຍບາຍເປັນລະຫັດເພື່ອບັງຄັບໃຊ້ສິດອະນຸຍາດ Linux ທີ່ປອດໄພໃນທຸກໆ pipeline
- ການທົບທວນສະຄຣິບທີ່ປະກອບມີການກວດສອບການອະນຸຍາດສຳລັບສະຄຣິບການນຳໃຊ້
- ແມ່ແບບທີ່ປອດໄພສຳລັບ Docker, Kubernetes ແລະ CI/CD ສັບສົນ
ການຝຶກອົບຮົມກ່ຽວກັບວິທີການ chmod 777 ສ້າງເວັກເຕີສຳລັບການໂຈມຕີທາງຫຼັງ.
ເປັນຫຍັງ chmod 777 ຈຶ່ງບໍ່ເຄີຍແກ້ໄຂໄດ້?
Chmod 777 ບໍ່ແມ່ນທາງລັດ; ມັນເປັນຕົວຄູນຄວາມສ່ຽງ. ມັນລົບລ້າງສິດອະນຸຍາດຂອງ Linux ທີ່ອອກແບບຢ່າງລະມັດລະວັງ, ລຶບລ້າງມາດຕະການປ້ອງກັນ, ແລະ ປູທາງໃຫ້ແກ່ການໂຈມຕີທາງຫຼັງທີ່ສາມາດປະນີປະນອມໄດ້. CI/CD pipelines ແລະລະບົບການຜະລິດ.
ການແກ້ໄຂບໍ່ພຽງແຕ່ປ່ຽນຄຳສັ່ງເທົ່ານັ້ນ; ມັນຍັງເປັນການຮັບຮອງເອົາສິດອະນຸຍາດທີ່ປອດໄພ, ການກວດສອບອັດຕະໂນມັດ, ແລະ ການຝັງແນວຄິດທີ່ມີສິດພິເສດໜ້ອຍທີ່ສຸດເຂົ້າໃນ... ຂະບວນການ DevSecOps. ເຄື່ອງມືເຊັ່ນ ຊີເກນີ ສາມາດຊ່ວຍກວດຫາການຕັ້ງຄ່າທີ່ບໍ່ປອດໄພ ແລະ ໄຟລ໌ທີ່ສາມາດຂຽນໄດ້ທົ່ວໂລກກ່ອນທີ່ພວກມັນຈະຮອດການຜະລິດ, ເຊິ່ງເຮັດໃຫ້ທ່ານມີຄວາມປອດໄພໂດຍບໍ່ເຮັດໃຫ້ການສົ່ງສິນຄ້າຊ້າລົງ.
