ເຄື່ອງຈັກຊອກຫາຖືກສ້າງຂຶ້ນມາເພື່ອຈັດດັດສະນີເນື້ອຫາ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ຜູ້ໂຈມຕີໃຊ້ພວກມັນເພື່ອຈັດດັດສະນີຄວາມຜິດພາດຂອງທ່ານ. ຄຳຖາມ ຂໍ້ຄວາມທັງົດ:login ປະເພດໄຟລ໌:ບັນທຶກ ອາດຈະເບິ່ງຄືວ່າບໍ່ເປັນອັນຕະລາຍ. ໃນຄວາມເປັນຈິງແລ້ວ, ມັນເປັນໜຶ່ງໃນວິທີທີ່ງ່າຍທີ່ສຸດໃນການຄົ້ນພົບໄຟລ໌ບັນທຶກທີ່ຖືກເປີດເຜີຍທີ່ມີຂັ້ນຕອນການພິສູດຢືນຢັນຕົວຕົນ, ຂໍ້ມູນປະຈຳຕົວ, ໂທເຄັນ ແລະ ຂໍ້ມູນພື້ນຖານໂຄງລ່າງພາຍໃນ.
ຖ້າ Google ສາມາດເຫັນບັນທຶກເຫຼົ່ານັ້ນໄດ້, ຜູ້ໂຈມຕີກໍ່ສາມາດເຮັດໄດ້ຄືກັນ. ເມື່ອຖືກດັດສະນີແລ້ວ, ການເປີດເຜີຍກໍ່ຈະກາຍເປັນສິ່ງທີ່ຫຼີກລ່ຽງບໍ່ໄດ້. ຍິ່ງໄປກວ່ານັ້ນ, ເມື່ອຂໍ້ມູນປະຈຳຕົວປາກົດຢູ່ໃນໄຟລ໌ທີ່ສາມາດເຂົ້າເຖິງໄດ້ໂດຍສາທາລະນະ, ການລະເມີດດັ່ງກ່າວກໍ່ເລີ່ມມີການເຄື່ອນໄຫວແລ້ວ.
1. ເປັນຫຍັງຕ້ອງ allintext:login filetype:log ເປັນອັນຕະລາຍຫຼາຍກວ່າທີ່ຄິດ
Google dork ເປັນຄຳຄົ້ນຫາທີ່ໃຊ້ຕົວດຳເນີນການຂັ້ນສູງເພື່ອຊອກຫາເນື້ອຫາທີ່ລະອຽດອ່ອນ ຫຼື ເນື້ອຫາທີ່ຕັ້ງຄ່າບໍ່ຖືກຕ້ອງທີ່ຖືກດັດສະນີໂດຍເຄື່ອງຈັກຊອກຫາ. ມັນບໍ່ໄດ້ໃຊ້ປະໂຫຍດຈາກ Google. ແທນທີ່ຈະ, ມັນໃຊ້ປະໂຫຍດຈາກການເປີດເຜີຍຂອງທ່ານ.
ຄຳຖາມນີ້ລວມເອົາສອງຕົວດຳເນີນການເຂົ້າກັນ:
- ຂໍ້ຄວາມທັງົດ: ສົ່ງຄືນໜ້າເວັບທີ່ຄຳສັບທັງໝົດປາກົດຢູ່ໃນຂໍ້ຄວາມ
- ປະເພດໄຟລ໌:ບັນທຶກ ຈຳກັດຜົນໄດ້ຮັບໄວ້ທີ່
.logໄຟ
ດັ່ງນັ້ນ:
ໝາຍຄວາມວ່າ: "ສະແດງໄຟລ໌ບັນທຶກທີ່ມີຄຳວ່າ login. "
ເມື່ອເບິ່ງຜ່ານໆ, ສິ່ງນັ້ນເບິ່ງຄືວ່າບໍ່ສຳຄັນ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ໃນທາງປະຕິບັດ, ມັນມັກຈະສົ່ງຜົນຕອບແທນຄືນມາ:
- ບັນທຶກເຊີບເວີເວັບທີ່ເປີດເຜີຍຕໍ່ສາທາລະນະ
- CI/CD ບັນທຶກທີ່ອັບໂຫຼດເປັນສິ່ງປະດິດ
- ແກ້ໄຂບັນທຶກໂດຍບໍ່ໄດ້ຕັ້ງໃຈ commitໄປຫາບ່ອນເກັບມ້ຽນ
- ບັນທຶກແອັບພລິເຄຊັນທີ່ມີຂໍ້ມູນປະຈຳຕົວແບບ plaintext
ນີ້ບໍ່ແມ່ນຂໍ້ຜິດພາດຂອງເຄື່ອງຈັກຊອກຫາ. ແທນທີ່ຈະ, ມັນແມ່ນ ຄວາມສ່ຽງດ້ານການເປີດເຜີຍຂໍ້ມູນ ເກີດຈາກການຕັ້ງຄ່າທີ່ບໍ່ຖືກຕ້ອງ. Google ພຽງແຕ່ຈັດດັດສະນີສິ່ງທີ່ສາມາດເຂົ້າເຖິງໄດ້ໂດຍສາທາລະນະ.
2. ສິ່ງທີ່ຜູ້ໂຈມຕີພົບໃນໄຟລ໌ບັນທຶກທີ່ຖືກເປີດເຜີຍ
ເມື່ອຜູ້ໂຈມຕີແລ່ນໜີ ຂໍ້ຄວາມທັງົດ:login ປະເພດໄຟລ໌:ບັນທຶກ, ພວກເຂົາບໍ່ໄດ້ທ່ອງເວັບແບບສຸ່ມ. ພວກເຂົາກຳລັງຊອກຫາຮ່ອງຮອຍການພິສູດຢືນຢັນຕົວຕົນ.
2.1 ໃບຢັ້ງຢືນທີ່ເປັນຂໍ້ຄວາມທຳມະດາ
ບັນທຶກມັກຈະມີລາຍການຕ່າງໆເຊັ່ນ:
or
ຫຼືແມ້ກະທັ້ງຂໍ້ມູນປະຈຳຕົວ SMTP:
ການບັນທຶກການພິສູດຢືນຢັນຕົວຕົນແມ່ນໜຶ່ງໃນວິທີທີ່ໄວທີ່ສຸດໃນການຮົ່ວໄຫຼຂໍ້ມູນປະຈຳຕົວການຜະລິດ. ດັ່ງນັ້ນ, ໄຟລ໌ບັນທຶກດຽວທີ່ເປີດເຜີຍສາມາດເຮັດໃຫ້ຮູບແບບການຄວບຄຸມການເຂົ້າເຖິງທັງໝົດຂອງທ່ານບໍ່ຖືກຕ້ອງ.
2.2 ໂທເຄັນ ແລະ JWT ຂອງເຊດຊັນ
ເຖິງແມ່ນວ່າລະຫັດຜ່ານຈະບໍ່ຖືກບັນທຶກໄວ້, ແຕ່ໂທເຄັນກໍ່ມັກຈະຖືກບັນທຶກໄວ້.
ຍົກຕົວຢ່າງ:
JWT ຫຼື ຄຸກກີ້ເຊດຊັນທີ່ຖືກຕ້ອງພາຍໃນ .log ໄຟລ໌ສາມາດເຮັດໃຫ້:
- ການລັກລອບເຊສຊັນ
- ສິດທິພິເສດເພີ່ມຂື້ນ
- ການເຄື່ອນໄຫວທາງຂ້າງຂ້າມລະບົບພາຍໃນ
ເວົ້າອີກຢ່າງໜຶ່ງ, ໂທເຄັນໃນບັນທຶກຈະປ່ຽນຜົນຜະລິດຂອງການແກ້ໄຂຂໍ້ຜິດພາດໃຫ້ເປັນເວັກເຕີຂ້າມການພິສູດຢືນຢັນຕົວຕົນ.
2.3 CI/CD ປອມ
ທ່ອນໄມ້ກໍ່ສ້າງແມ່ນເປັນອັນຕະລາຍໂດຍສະເພາະ. ໃນຄວາມເປັນຈິງ, CI/CD ລະບົບມັກຈະພິມຕົວແປສະພາບແວດລ້ອມໃນລະຫວ່າງຂັ້ນຕອນການສ້າງ.
ຜູ້ໂຈມຕີມັກຈະຄົ້ນພົບ:
ປະກອບດ້ວຍສາຍຕ່າງໆເຊັ່ນ:
If CI/CD ສິ່ງປະດິດຕ່າງໆແມ່ນເປີດເຜີຍຕໍ່ສາທາລະນະ, ຫຼັງຈາກນັ້ນຄວາມລັບກໍ່ເປັນສາທາລະນະ. Google dork ພຽງແຕ່ເລັ່ງການຄົ້ນພົບ.
2.4 ຂໍ້ມູນຄລາວ ແລະ ໂຄງສ້າງພື້ນຖານ
ບັນທຶກທີ່ຖືກເປີດເຜີຍມັກຈະເປີດເຜີຍ:
- ລະຫັດການເຂົ້າເຖິງ AWS
- ສະຕຣິງການເຊື່ອມຕໍ່ບ່ອນເກັບຂໍ້ມູນ Azure
- URL ການບໍລິການພາຍໃນ
- ຂໍ້ມູນປະຈໍາຕົວຂອງຖານຂໍ້ມູນ
- ຈຸດສິ້ນສຸດ Redis
ເຖິງແມ່ນວ່າຂໍ້ມູນປະຈຳຕົວຈະຖືກໝູນວຽນໃນພາຍຫຼັງ, ຜູ້ໂຈມຕີໃນປັດຈຸບັນມີ:
- ການສ້າງແຜນທີ່ພື້ນຖານໂຄງລ່າງ
- ສົນທິສັນຍາການຕັ້ງຊື່
- ສືບລັບເປົ້າໝາຍສຳລັບການໂຈມຕີໃນອະນາຄົດ
ດັ່ງນັ້ນ, ບັນທຶກທີ່ຖືກເປີດເຜີຍໃຫ້ທັງການເຂົ້າເຖິງ ແລະ ການສຳຫຼວດ.
3. ບັນທຶກເຫຼົ່ານີ້ກາຍເປັນສາທາລະນະໄດ້ແນວໃດໃນຕອນທຳອິດ
ບັນທຶກບໍ່ໄດ້ປາກົດຢູ່ໃນ Google ຢ່າງມະຫັດສະຈັນ. ພວກມັນຈະຖືກດັດສະນີເພາະວ່າພວກມັນສາມາດເຂົ້າເຖິງໄດ້ໂດຍສາທາລະນະ.
3.1 ເຊີບເວີເວັບທີ່ຖືກຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ
ຮູບແບບທົ່ວໄປປະກອບມີ:
/logs/ໄດເລກະທໍລີທີ່ສາມາດເຂົ້າເຖິງໄດ້ໂດຍບໍ່ມີການກວດສອບຄວາມຖືກຕ້ອງ- ເປີດໃຊ້ລາຍຊື່ໄດເລກະທໍລີແລ້ວ
- Nginx ຫຼື Apache ຮັບໃຊ້ດິບ
.logໄຟ
ຖ້າສາມາດເຂົ້າເຖິງບັນທຶກໄດ້ຜ່ານ HTTP, ມັນຈະສາມາດຈັດດັດສະນີໄດ້.
3.2 CI/CD ການເປີດເຜີຍສິ່ງປະດິດ
ຄວາມຜິດພາດທົ່ວໄປ:
- ສິ່ງປະດິດສາທາລະນະທີ່ເປີດໃຊ້ງານໃນ ການກະ ທຳ ຂອງ GitHub
- ບັນທຶກທີ່ອັບໂຫຼດໃສ່ຖັງ S3 ທີ່ເປີດຢູ່
- Pipeline ສາມາດເຂົ້າເຖິງຮ່ອງຮອຍໄດ້ໂດຍບໍ່ຕ້ອງມີການພິສູດຢືນຢັນຕົວຕົນ
A pipeline ທີ່ເກັບຮັກສາບັນທຶກໄວ້ໃນຖັງສາທາລະນະເຜີຍແຜ່ຄວາມລັບຂອງມັນຢ່າງມີປະສິດທິພາບ.
3.3 ໂໝດດີບັກໃນການຜະລິດ
ຄ່າເລີ່ມຕົ້ນຂອງ Framework ອາດເປັນອັນຕະລາຍ:
ນອກຈາກນັ້ນ, ການບັນທຶກການຮ້ອງຂໍຫຼາຍເກີນໄປອາດຈະພິມອອກ:
- Headers
- Tokens
- ໜ່ວຍງານຮ້ອງຂໍເຕັມຮູບແບບ
ການບັນທຶກການແກ້ໄຂຂໍ້ຜິດພາດໃນໂປຣແກຣມຜະລິດຈະປ່ຽນແອັບພລິເຄຊັນຂອງທ່ານໃຫ້ກາຍເປັນຕົວສົ່ງອອກຂໍ້ມູນປະຈຳຕົວ.
3.4 ບັນທຶກ Docker ແລະ Container
ສະພາບແວດລ້ອມທີ່ມີຕູ້ຄອນເທນເນີນຳສະເໜີເສັ້ນທາງການສຳຜັດໃໝ່:
- ບັນທຶກທີ່ຕິດຕັ້ງເຂົ້າໃນໂວລູມທີ່ໃຊ້ຮ່ວມກັນ
- ລົດຂ້າງສົ່ງບັນທຶກໄປຫາຈຸດສິ້ນສຸດທີ່ບໍ່ປອດໄພ
- ຕົວເຊັນເຂົ້າ dashboards ທີ່ມີການເຂົ້າເຖິງສາທາລະນະ
ຖ້າບັນທຶກຂອງຕູ້ຄອນເທນເນີຖືກເປີດເຜີຍຜ່ານ HTTP ຫຼື ບ່ອນເກັບຂໍ້ມູນເປີດ, ພວກມັນສາມາດຄົ້ນຫາໄດ້. ໃນທີ່ສຸດ, ພວກມັນຈະຖືກດັດສະນີ.
4. ກະແສການໂຈມຕີທີ່ສົມຈິງ: ຈາກ Dork ຫາ Breach
ລະບົບຕ່ອງໂສ້ການໂຈມຕີທົ່ວໄປມີລັກສະນະແບບນີ້:
ຜູ້ໂຈມຕີແລ່ນ:
- ການຄົ້ນພົບທີ່ເປີດເຜີຍ
.logເອກະສານ - ສານສະກັດຈາກ:
- JWT token
- ຫົວຂໍ້ການອະນຸຍາດພື້ນຖານ
- ສະຕຣິງການເຊື່ອມຕໍ່ຖານຂໍ້ມູນ
ພະຍາຍາມກວດສອບຄວາມຖືກຕ້ອງຕໍ່ກັບ:
- ຈຸດສິ້ນສຸດ API
- ແຜງຄວບຄຸມຜູ້ເບິ່ງແຍງລະບົບ
- ການບໍລິການພາຍໃນ
ຖ້າການພິສູດຢືນຢັນຕົວຕົນສຳເລັດ, ຜູ້ໂຈມຕີສາມາດ:
- ຂະຫຍາຍສິດທິພິເສດ
- ເຄື່ອນທີ່ໄປທາງຂ້າງ
- ການເຂົ້າເຖິງ CI/CD
- ປະນີປະນອມລະບົບຕ່ອງໂສ້ການສະໜອງ
ສິ່ງທີ່ເລີ່ມຕົ້ນເປັນຄຳຖາມຄົ້ນຫາໄດ້ກາຍເປັນ:
- ການລັກລອບເຊສຊັນ
- ການຕື່ມຂໍ້ມູນປະຈຳຕົວພາຍໃນ
- Pipeline ຍາດເອົາ
- ການເປັນພິດຈາກສິ່ງປະດິດ
ທັງໝົດມາຈາກໄຟລ໌ບັນທຶກທີ່ມີການຈັດດັດສະນີສາທາລະນະ.
5. ເປັນຫຍັງການບັນທຶກ "ຫຼາຍເກີນໄປ" ຈຶ່ງເປັນບັນຫາຂອງ AppSec
ການບັນທຶກບໍ່ແມ່ນຄວາມເປັນກາງ. ແທນທີ່ຈະ, ມັນສ້າງ ບ່ອນເກັບຂໍ້ມູນສຳຮອງ.
ຖ້າທ່ານບັນທຶກຂໍ້ມູນທີ່ລະອຽດອ່ອນ, ທ່ານຈະສ້າງສຳເນົາຄວາມລັບອັນທີສອງຂອງທ່ານໄດ້ຢ່າງມີປະສິດທິພາບ.
ເຖິງຢ່າງໃດກໍ່ຕາມ, ບັນທຶກມັກຈະຖືກຍົກເວັ້ນຈາກການສ້າງແບບຈຳລອງໄພຂົ່ມຂູ່. ພາຍໃຕ້ STRIDE, ສິ່ງນີ້ຈະສະແດງແຜນທີ່ຢ່າງຊັດເຈນເຖິງ:
ການເປີດເຜີຍຂໍ້ມູນ
ດັ່ງນັ້ນ, ຮັບປະກັນຄວາມປອດໄພ SDLC ການປະຕິບັດຄວນປະຕິບັດຕໍ່ບັນທຶກດັ່ງນີ້:
- ສິ່ງປະດິດທີ່ກ່ຽວຂ້ອງກັບຄວາມປອດໄພ
- ຊັບສິນທີ່ລະອຽດອ່ອນ
- ອົງປະກອບພື້ນຖານໂຄງລ່າງທີ່ຕ້ອງການການປົກປ້ອງ
ຖ້າຮູບແບບໄພຂົ່ມຂູ່ຂອງທ່ານບໍ່ສົນໃຈບັນທຶກ, ມັນກໍ່ບໍ່ຄົບຖ້ວນ.
6. ວິທີການປ້ອງກັນການຮົ່ວໄຫຼຂອງຂໍ້ມູນປະຈຳຕົວໃນໄຟລ໌ບັນທຶກ
6.1 ຢຸດການບັນທຶກຄວາມລັບ
ຢ່າບັນທຶກ:
- ລະຫັດຜ່ານ
- Tokens
- ກະແຈ API
- ID ເຊດຊັນ
- ຫົວຂໍ້ການອະນຸຍາດ
ເຖິງແມ່ນວ່າຈະຢູ່ໃນໂໝດ debug ກໍຕາມ.
ເມື່ອໃດກໍຕາມທີ່ເປັນໄປໄດ້, ໃຫ້ໃຊ້ການແກ້ໄຂອັດຕະໂນມັດ.
6.2 ການບັນທຶກທີ່ມີໂຄງສ້າງ ແລະ ປອດໄພ
ໃຊ້ການບັນທຶກທີ່ມີໂຄງສ້າງພ້ອມດ້ວຍການປິດບັງ ແລະ ການກັ່ນຕອງ.
ຕົວຢ່າງ (Node.js):
ຕົວຢ່າງ (Python):
ຫຼັກການຫຼັກແມ່ນງ່າຍດາຍ: ຄວາມລັບຕ້ອງບໍ່ໄປເຖິງອ່າງລ້າງໄມ້.
6.3 ການເກັບຮັກສາທ່ອນໄມ້ແບບລັອກລົງ
ການຄວບຄຸມຄວາມປອດໄພຄວນປະກອບມີ:
- ປິດການໃຊ້ງານລາຍຊື່ໄດເລກະທໍລີ
- ປົກປັກຮັກສາ
/logs/ເສັ້ນທາງທີ່ມີການກວດສອບຄວາມຖືກຕ້ອງ - ຈຳກັດການເຂົ້າເຖິງຖັງ
- ນຳໃຊ້ນະໂຍບາຍການເກັບຮັກສາ
- ເຂົ້າລະຫັດບັນທຶກໃນເວລາບໍ່ເຄື່ອນໄຫວ
ບັນທຶກຕ້ອງບໍ່ສາມາດເຂົ້າເຖິງໄດ້ໂດຍສາທາລະນະຜ່ານທາງ HTTP.
6.4 CI/CD Guardrails
ການທົບທວນດ້ວຍຕົນເອງແມ່ນບໍ່ພຽງພໍ. ແທນທີ່ຈະ, ໃຫ້ໃຊ້ການຄວບຄຸມອັດຕະໂນມັດ:
- ການສະແກນບັນທຶກຢ່າງລັບໆກ່ອນການເຜີຍແຜ່ສິ່ງປະດິດ
- ການສ້າງລົ້ມເຫຼວຖ້າກວດພົບໂທເຄັນ
- ປ້ອງກັນການອັບໂຫຼດສິ່ງປະດິດທີ່ມີຂໍ້ມູນປະຈຳຕົວ
- ການກວດສອບຄວາມຖືກຕ້ອງຂອງແຮຊສຳລັບສິ່ງປະດິດ
CI/CD ຄວນສະກັດກັ້ນການເປີດເຜີຍກ່ອນທີ່ຈະມີການຈັດດັດສະນີ.
7. Xygeni ປ້ອງກັນ allintext ໄດ້ແນວໃດ:login ປະເພດໄຟລ໌: ເຫດການບັນທຶກ
ບັນຫາບໍ່ແມ່ນ Google dork. ບັນຫາແມ່ນການເປີດເຜີຍ. ດັ່ງນັ້ນ, ການປ້ອງກັນຕ້ອງເກີດຂຶ້ນກ່ອນທີ່ຈະດັດສະນີ.
7.1 ການກວດຫາຄວາມລັບໃນທ່ອນໄມ້ ແລະ ສິ່ງປະດິດ
ການສະແກນ Xygeni:
- ບັນທຶກຄໍາຮ້ອງສະຫມັກ
- CI/CD ຮ່ອງຮອຍວຽກ
- ສ້າງສິ່ງປະດິດ
- ຊັ້ນ Docker
- ຜົນຜະລິດທີ່ເປັນລຳດັບ
ຖ້າຂໍ້ມູນປະຈຳຕົວ, ໂທເຄັນ ຫຼື ຄ່າທີ່ລະອຽດອ່ອນປາກົດຢູ່ໃນ .log ໄຟລ໌ຕ່າງໆ, Xygeni ຈະລາຍງານພວກມັນທັນທີ.
7.2 CI/CD Guardrails ການເປີດເຜີຍບລັອກນັ້ນ
ແທນທີ່ຈະອີງໃສ່ການທົບທວນຄືນດ້ວຍຕົນເອງ, Xygeni ບັງຄັບໃຊ້ຄວາມປອດໄພຢູ່ທີ່ pipeline ລະດັບ:
ນີ້:
- ຄວາມລົ້ມເຫຼວຖືກສ້າງຂຶ້ນເມື່ອຄວາມລັບປາກົດຢູ່ໃນບັນທຶກ
- ການເຜີຍແຜ່ສິ່ງປະດິດຂອງບລັອກ
- ປ້ອງກັນການສຳຜັດກັບສາທາລະນະໂດຍບັງເອີນ
- ຢຸດການລວມຕົວທີ່ບໍ່ປອດໄພກ່ອນທີ່ຈະໄປຮອດຈຸດໝາຍປາຍທາງຫຼັກ
ຖ້າວຽກ CI ພິມໂທເຄັນ, pipeline ລົ້ມເຫລວ.
ບໍ່ມີການຈັດດັດສະນີ.
ບໍ່ມີການເປີດເຜີຍ.
ບໍ່ມີເຫດການໃດໆເກີດຂຶ້ນ.
7.3 ການປ້ອງກັນ Shift-Left ກ່ອນທີ່ Google ຈະເຫັນມັນ
ເລື່ອງເວລາ.
ແທນທີ່ຈະຕອບສະໜອງຕໍ່:
Xygeni ຢຸດບັນຫາ:
- At commit ທີ່ໃຊ້ເວລາ
- ໃນລະຫວ່າງການ pull request ການກວດສອບ
- ໃນລະຫວ່າງການ pipeline ການປະຕິບັດ
- ກ່ອນການພິມເຜີຍແຜ່ສິ່ງປະດິດ
ຖ້າບັນທຶກບໍ່ເຄີຍກາຍເປັນສາທາລະນະ, Google ຈະບໍ່ດັດສະນີມັນ.
ສະຫຼຸບສຸດທ້າຍ: ຖ້າ Google ສາມາດຈັດດັດສະນີມັນໄດ້, ຜູ້ໂຈມຕີໄດ້ເຮັດແລ້ວ
ບັນທຶກບໍ່ໄດ້ເປັນອັນຕະລາຍ. ໃນຄວາມເປັນຈິງ, ພວກມັນບໍ່ຄ່ອຍຈະເປັນຊົ່ວຄາວ. ຕາມຄ່າເລີ່ມຕົ້ນ, ພວກມັນບໍ່ແມ່ນສ່ວນຕົວ. ດັ່ງນັ້ນ, ໄຟລ໌ບັນທຶກທຸກອັນຄວນຖືກປະຕິບັດເປັນຊັບສິນທີ່ກ່ຽວຂ້ອງກັບຄວາມປອດໄພ, ບໍ່ແມ່ນພຽງແຕ່ຜົນການດີບັກເທົ່ານັ້ນ.
ຖ້າຂໍ້ມູນທີ່ລະອຽດອ່ອນໄປຮອດ .log ໄຟລ໌ ແລະ ສາມາດເຂົ້າເຖິງໄດ້ໂດຍສາທາລະນະ, ມັນທັນທີກາຍເປັນໜ້າດິນໂຈມຕີ. ຍິ່ງໄປກວ່ານັ້ນ, ເມື່ອເຄື່ອງຈັກຊອກຫາຖືກດັດສະນີແລ້ວ, ການເປີດເຜີຍຈະເກີນກວ່າການຄວບຄຸມຂອງທ່ານ.
ວິທີແກ້ໄຂບໍ່ແມ່ນການຢຸດການບັນທຶກ. ແທນທີ່ຈະ, ມັນແມ່ນການບັນທຶກຢ່າງມີຄວາມຮັບຜິດຊອບ ແລະ ບັງຄັບໃຊ້ການຄວບຄຸມທີ່ເຂັ້ມງວດກ່ຽວກັບການເກັບຮັກສາ ແລະ ການແຈກຢາຍ. ເວົ້າອີກຢ່າງໜຶ່ງ, ຄວາມປອດໄພຕ້ອງຂະຫຍາຍອອກໄປນອກເໜືອຈາກຕົວແອັບພລິເຄຊັນເອງ ແລະ ເຂົ້າໄປໃນຊັ້ນການສັງເກດການ.
ແທນທີ່:
- ຢຸດການບັນທຶກຄວາມລັບ
- ລັອກບ່ອນເກັບມ້ຽນບັນທຶກ
- ບັງຄັບໃຊ້ pipeline guardrails
- ການກວດສອບ ແລະ ການບັງຄັບໃຊ້ນະໂຍບາຍໂດຍອັດຕະໂນມັດ
ສຸດທ້າຍ, ການປ້ອງກັນແມ່ນກ່ຽວກັບເວລາ. ເພາະວ່າເມື່ອ ຂໍ້ຄວາມທັງົດ:login ປະເພດໄຟລ໌:ບັນທຶກ ສົ່ງຄືນໂດເມນຂອງທ່ານ, ເຫດການໄດ້ເລີ່ມຕົ້ນແລ້ວ.
