ရှာဖွေရေးအင်ဂျင်များကို အကြောင်းအရာများကို အညွှန်းပြုလုပ်ရန် တည်ဆောက်ထားသည်။ သို့သော် တိုက်ခိုက်သူများသည် သင့်အမှားများကို အညွှန်းရန်အတွက် ၎င်းတို့ကို အသုံးပြုကြသည်။ မေးမြန်းချက် စာသားlogin ဖိုင်အမျိုးအစား: မှတ်တမ်း အန္တရာယ်မရှိပုံပေါ်နိုင်သည်။ အမှန်တကယ်တွင်၊ ၎င်းသည် အထောက်အထားစိစစ်ခြင်း စီးဆင်းမှုများ၊ အထောက်အထားများ၊ တိုကင်များနှင့် အတွင်းပိုင်း အခြေခံအဆောက်အအုံဒေတာများပါ၀င်သည့် ဖော်ထုတ်ခံရသည့် log ဖိုင်များကို ရှာဖွေတွေ့ရှိရန် အရိုးရှင်းဆုံးနည်းလမ်းများထဲမှ တစ်ခုဖြစ်သည်။
Google က အဲဒီမှတ်တမ်းတွေကို မြင်နိုင်ရင် တိုက်ခိုက်သူတွေလည်း မြင်နိုင်ပါတယ်။ index လုပ်လိုက်တာနဲ့ ပေါက်ကြားမှု မလွဲမသွေ ဖြစ်လာပါတယ်။ ထို့အပြင်၊ အထောက်အထားများသည် အများပြည်သူ ဝင်ရောက်ကြည့်ရှုနိုင်သော ဖိုင်တွင် ပေါ်လာသောအခါ၊ ချိုးဖောက်မှုသည် စတင်နေပြီဖြစ်သည်။
၁။ အဘယ်ကြောင့် allintext ကို ရွေးချယ်သင့်သနည်း။login filetype:log သည် မြင်ရတာထက် ပိုအန္တရာယ်များပါသည်
Google dork ဆိုတာ ရှာဖွေရေးအင်ဂျင်တွေက index လုပ်ထားတဲ့ အရေးကြီးတဲ့ ဒါမှမဟုတ် မှားယွင်းစွာ configure လုပ်ထားတဲ့ အကြောင်းအရာတွေကို ရှာဖွေဖို့ အဆင့်မြင့် operator တွေကို အသုံးပြုတဲ့ search query တစ်ခုပါ။ Google ကို အမြတ်ထုတ်တာမျိုး မလုပ်ပါဘူး။ အဲဒီအစား သင့်ရဲ့ exposure ကို အမြတ်ထုတ်တာပါ။
ဤ query သည် operator နှစ်ခုကို ပေါင်းစပ်ထားသည်-
- စာသား စာသားရဲ့ body text မှာ အသုံးအနှုန်းအားလုံး ပေါ်လာတဲ့ စာမျက်နှာတွေကို ပြန်ပေးပါတယ်။
- ဖိုင်အမျိုးအစား: မှတ်တမ်း ရလဒ်များကို ကန့်သတ်ထားသည်
.logဖိုင်တွေ
ထို့ကြောင့်:
ဆိုလိုတာက: "ဒီစကားလုံးပါတဲ့ မှတ်တမ်းဖိုင်တွေကို ပြပါ login။ "
ပထမတစ်ချက်ကြည့်လိုက်ရင် အဲဒါက အရေးမကြီးဘူးလို့ ထင်ရတယ်။ ဒါပေမယ့် လက်တွေ့မှာတော့ ဒီလိုပဲ ပြန်ဖြစ်လေ့ရှိပါတယ်။
- လူသိရှင်ကြား ပေါက်ကြားခဲ့သော ဝဘ်ဆာဗာမှတ်တမ်းများ
- CI/CD ရှေးဟောင်းပစ္စည်းများအဖြစ် အပ်လုဒ်လုပ်ထားသော မှတ်တမ်းများ
- မတော်တဆ အမှားပြင်ဆင်မှု မှတ်တမ်းများ commitrepositories များသို့ ted လုပ်သည်
- plaintext အထောက်အထားများပါရှိသော အပလီကေးရှင်းမှတ်တမ်းများ
ဒါက ရှာဖွေရေးအင်ဂျင် bug မဟုတ်ဘူး။ ඒ වෙනුවට၊ ဒေတာထုတ်ဖော်မှု အားနည်းချက် မှားယွင်းစွာ configure လုပ်မိလို့ ဖြစ်ရတာပါ။ Google က အများပြည်သူ ဝင်ရောက်ကြည့်ရှုနိုင်တာတွေကို ရိုးရိုးလေး index လုပ်ပြခဲ့ပါတယ်။
၂။ ပေါက်ကြားသွားသော Log Files များတွင် တိုက်ခိုက်သူများ အမှန်တကယ်တွေ့ရှိသည့်အရာများ
တိုက်ခိုက်သူတွေ ထွက်ပြေးတဲ့အခါ စာသားlogin ဖိုင်အမျိုးအစား: မှတ်တမ်း၊ သူတို့က ကျပန်းကြည့်ရှုနေတာ မဟုတ်ပါဘူး။ အထောက်အထားစိစစ်ခြင်း መልእክትတွေကို ရှာဖွေနေကြတာပါ။
၂.၁ ရိုးရိုးစာသား အထောက်အထားများ
မှတ်တမ်းများတွင် မကြာခဏ အောက်ပါကဲ့သို့သော မှတ်တမ်းများ ပါဝင်လေ့ရှိသည်-
or
ဒါမှမဟုတ် SMTP အထောက်အထားတွေတောင်မှ-
အထောက်အထားစိစစ်ခြင်း payload များကို မှတ်တမ်းတင်ခြင်းသည် ထုတ်လုပ်မှုအထောက်အထားများကို ပေါက်ကြားရန် အမြန်ဆုံးနည်းလမ်းများထဲမှ တစ်ခုဖြစ်သည်။ ထို့ကြောင့်၊ ဖော်ထုတ်ခံရသော log file တစ်ခုတည်းသည် သင်၏ access control model တစ်ခုလုံးကို ပျက်ပြယ်စေနိုင်သည်။
၂.၂ အစည်းအဝေးတိုကင်များနှင့် JWT များ
စကားဝှက်များကို မှတ်တမ်းတင်မထားသည့်အခါတွင်ပင် တိုကင်များကို မကြာခဏ မှတ်တမ်းတင်ထားလေ့ရှိသည်။
ဥပမာ:
အတွင်းရှိ တရားဝင် JWT သို့မဟုတ် session cookie တစ်ခု .log ဖိုင်က အောက်ပါတို့ကို ဖွင့်နိုင်သည်-
- Session ပြန်ပေးဆွဲခြင်း
- အခွင့်ထူးမြင့်တက်
- အတွင်းပိုင်းစနစ်များတစ်လျှောက် ဘေးတိုက်ရွေ့လျားမှု
တစ်နည်းအားဖြင့်ဆိုရသော် log များရှိ token များသည် debugging output ကို authentication bypass vector အဖြစ်သို့ ပြောင်းလဲပေးသည်။
2.3 CI/CD အပိုငျးအ
သစ်လုံးတွေ တည်ဆောက်တာက အထူးအန္တရာယ်များပါတယ်။ တကယ်တော့ CI/CD စနစ်များသည် တည်ဆောက်မှုအဆင့်များအတွင်း ပတ်ဝန်းကျင်ပြောင်းလဲမှုများကို မကြာခဏ print ထုတ်လေ့ရှိသည်။
တိုက်ခိုက်သူများသည် မကြာခဏ ရှာဖွေတွေ့ရှိကြသည်-
အောက်ပါကဲ့သို့သော လိုင်းများပါဝင်သည်-
If CI/CD ရှေးဟောင်းပစ္စည်းတွေက အများပြည်သူသိပြီးရင် လျှို့ဝှက်ချက်တွေက အများပြည်သူသိပါတယ်။ Google dork က ရှာဖွေတွေ့ရှိမှုကို မြန်ဆန်စေပါတယ်။
၂.၄ Cloud နှင့် အခြေခံအဆောက်အအုံဒေတာ
ဖော်ထုတ်ထားသော မှတ်တမ်းများက မကြာခဏ ဖော်ပြလေ့ရှိသည်-
- AWS ဝင်ရောက်ခွင့်သော့များ
- Azure သိုလှောင်မှု ချိတ်ဆက်မှု စာကြောင်းများ
- အတွင်းပိုင်းဝန်ဆောင်မှု URL များ
- ဒေတာဘေ့စ်အထောက်အထားများ
- Redis အဆုံးမှတ်များ
နောက်ပိုင်းတွင် အထောက်အထားများကို အလှည့်ကျပြောင်းလဲသည့်တိုင် တိုက်ခိုက်သူသည် ယခုအခါ အောက်ပါတို့ကို ပိုင်ဆိုင်ထားသည်-
- အခြေခံအဆောက်အအုံ မြေပုံရေးဆွဲခြင်း
- အမည်ပေးခြင်း သဘောတူညီချက်များ
- အနာဂတ်တိုက်ခိုက်မှုများအတွက် ပစ်မှတ်ထောက်လှမ်းရေး
ထို့ကြောင့်၊ ဖော်ထုတ်ထားသော မှတ်တမ်းများသည် ဝင်ရောက်ခွင့်နှင့် ထောက်လှမ်းရေး နှစ်မျိုးလုံးကို ပေးစွမ်းသည်။
၃။ ဤမှတ်တမ်းများသည် မည်သို့ အများသူငှာ သိရှိနိုင်ပုံ
မှတ်တမ်းများသည် Google တွင် မှော်ဆန်စွာ မပေါ်လာပါ။ ၎င်းတို့ကို အများပြည်သူ ဝင်ရောက်ကြည့်ရှုနိုင်သောကြောင့် အညွှန်းအဖြစ် ထည့်သွင်းထားသည်။
၃.၁ မှားယွင်းစွာ ဖွဲ့စည်းထားသော ဝဘ်ဆာဗာများ
အဖြစ်များသော ပုံစံများတွင် အောက်ပါတို့ ပါဝင်သည်-
/logs/စစ်မှန်ကြောင်းအထောက်အထားပြခြင်းမရှိဘဲ ဝင်ရောက်နိုင်သော လမ်းညွှန်များ- လမ်းညွှန်စာရင်းဖွင့်ထားသည်
- Nginx သို့မဟုတ် Apache သည် raw ကို ကျွေးမွေးသည်
.logဖိုင်တွေ
မှတ်တမ်းတစ်ခုကို HTTP မှတစ်ဆင့် ဝင်ရောက်ကြည့်ရှုနိုင်ပါက ၎င်းကို indexable လုပ်နိုင်ပါသည်။
3.2 CI/CD ရှေးဟောင်းပစ္စည်း ဖော်ထုတ်ခြင်း
ပုံမှန်အမှားများ-
- အများပြည်သူဆိုင်ရာ ရှေးဟောင်းပစ္စည်းများကို ဖွင့်ထားသည် GitHub လုပ်ဆောင်ချက်များ
- ပွင့်လင်းသော S3 ဘတ်ကက်များသို့ အပ်လုဒ်လုပ်ထားသော မှတ်တမ်းများ
- Pipeline အထောက်အထားစိစစ်ခြင်းမရှိဘဲ ခြေရာခံမှုများကို ဝင်ရောက်နိုင်သည်
A pipeline မှတ်တမ်းများကို အများသုံးပုံးထဲတွင် သိမ်းဆည်းထားသော မှတ်တမ်းများသည် ၎င်း၏ လျှို့ဝှက်ချက်များကို ထိရောက်စွာ ထုတ်ပြန်သည်။
၃.၃ ထုတ်လုပ်မှုတွင် Debug မုဒ်
Framework default များသည် အန္တရာယ်ရှိနိုင်သည်-
ထို့အပြင်၊ အလွန်အကျွံ တောင်းဆိုမှု မှတ်တမ်းတင်ခြင်းများသည်-
- ခေါင်းစီးများ
- တိုကင်
- တောင်းဆိုချက်အပြည့်အစုံကို အဖွဲ့အစည်းများက
ထုတ်လုပ်မှုတွင် debug logging သည် သင့်အပလီကေးရှင်းကို credential exporter အဖြစ်သို့ ပြောင်းလဲပေးသည်။
၃.၄ Docker နှင့် Container မှတ်တမ်းများ
ကွန်တိန်နာပုံစံပတ်ဝန်းကျင်များသည် ထိတွေ့မှုလမ်းကြောင်းအသစ်များကို မိတ်ဆက်ပေးသည်-
- မျှဝေထားသော volume များထဲသို့ မှတ်တမ်းများကို ထည့်သွင်းထားသည်
- ဘေးတွဲကားများသည် မှတ်တမ်းများကို လုံခြုံမှုမရှိသော အဆုံးမှတ်များသို့ တင်ပို့နေသည်
- တုံး dashboardအများပြည်သူဝင်ရောက်ခွင့်ရှိသော s
HTTP သို့မဟုတ် open storage မှတစ်ဆင့် container log များကို ထုတ်ဖော်ပြသပါက ရှာဖွေနိုင်ပါသည်။ နောက်ဆုံးတွင် ၎င်းတို့ကို index လုပ်ပါသည်။
၄။ လက်တွေ့ကျသော တိုက်ခိုက်မှု စီးဆင်းမှု- Dork မှ Breach အထိ
ပုံမှန်တိုက်ခိုက်မှုကွင်းဆက်သည် ဤကဲ့သို့ဖြစ်သည်-
တိုက်ခိုက်သူ ပြေးသည်-
- ဖော်ထုတ်တွေ့ရှိမှုများ
.logဖိုင် - ကောက်နှုတ်ချက်များ-
- JWT တိုကင်
- အခြေခံ Auth ခေါင်းစဉ်
- ဒေတာဘေ့စ်ချိတ်ဆက်မှု string
အောက်ပါတို့ကို အထောက်အထားစိစစ်ရန် ကြိုးစားသည်-
- API အဆုံးမှတ်များ
- အက်ဒမင် ပန်နယ်များ
- အတွင်းပိုင်းဝန်ဆောင်မှုများ
အထောက်အထားစိစစ်ခြင်း အောင်မြင်ပါက၊ တိုက်ခိုက်သူသည် အောက်ပါတို့ကို လုပ်ဆောင်နိုင်သည်-
- အထူးအခွင့်အရေးများကို မြှင့်တင်ပါ
- ဘေးတိုက်ရွှေ့ပါ
- ဝင်ရောက်ခွင့် CI/CD
- ထောက်ပံ့ရေးကွင်းဆက်ကို ထိခိုက်စေခြင်း
ရှာဖွေမှုမေးခွန်းတစ်ခုအဖြစ် စတင်ခဲ့သည်မှာ-
- Session ပြန်ပေးဆွဲခြင်း
- အတွင်းပိုင်း အထောက်အထားများ ဖြည့်သွင်းခြင်း
- Pipeline လွှဲယူသည်
- ရှေးဟောင်းပစ္စည်း အဆိပ်သင့်ခြင်း
အားလုံးသည် အများသူငှာ အညွှန်းပြုထားသော မှတ်တမ်းဖိုင်မှ ဖြစ်သည်။
၅။ “အလွန်အကျွံ” မှတ်တမ်းတင်ခြင်းသည် AppSec ပြဿနာတစ်ခုဖြစ်ရသည့် အကြောင်းရင်း
မှတ်တမ်းတင်ခြင်းသည် ကြားနေမဟုတ်ပါ။ ယင်းအစား၊ ၎င်းသည် ဒုတိယဒေတာသိုလှောင်ရာ.
အရေးကြီးဒေတာများကို သင်မှတ်တမ်းတင်ပါက သင့်လျှို့ဝှက်ချက်များ၏ ဒုတိယမိတ္တူကို ထိထိရောက်ရောက် ဖန်တီးပါသည်။
သို့သော်၊ မှတ်တမ်းများကို ခြိမ်းခြောက်မှုပုံစံထုတ်ခြင်းမှ မကြာခဏ ဖယ်ထုတ်ထားလေ့ရှိသည်။ STRIDE အောက်တွင်၊ ၎င်းသည် အောက်ပါနေရာသို့ ရှင်းရှင်းလင်းလင်း မြေပုံဆွဲထားသည်-
သတင်းအချက်အလက်ထုတ်ဖော်
ထို့ကြောင့် လုံခြုံစိတ်ချရသော SDLC အလေ့အကျင့်များသည် မှတ်တမ်းများကို အောက်ပါအတိုင်း ကိုင်တွယ်သင့်သည်-
- လုံခြုံရေးနှင့်သက်ဆိုင်သော ရှေးဟောင်းပစ္စည်းများ
- ထိလွယ်ရှလွယ်သော ပိုင်ဆိုင်မှုများ
- ကာကွယ်မှုလိုအပ်သော အခြေခံအဆောက်အအုံ အစိတ်အပိုင်းများ
သင့်ရဲ့ threat model က log တွေကို လျစ်လျူရှုထားရင် မပြည့်စုံပါဘူး။
၆။ Log ဖိုင်များတွင် အထောက်အထားများ ယိုစိမ့်မှုကို မည်သို့ကာကွယ်ရမည်နည်း
၆.၁ လျှို့ဝှက်ချက်များကို မှတ်တမ်းတင်ခြင်းကို ရပ်တန့်ပါ
ဘယ်တော့မှ မှတ်တမ်းမတင်ပါနှင့်-
- passwords များကို
- တိုကင်
- API သော့များ
- စက်ရှင် ID များ
- ခွင့်ပြုချက်ခေါင်းစဉ်များ
debug mode မှာတောင်။
ဖြစ်နိုင်သည့်အခါတိုင်း အလိုအလျောက် တည်းဖြတ်ခြင်းကို အကောင်အထည်ဖော်ပါ။
၆.၂ စနစ်တကျနှင့် ဘေးကင်းသော မှတ်တမ်းတင်ခြင်း
ဖုံးအုပ်ခြင်းနှင့် စစ်ထုတ်ခြင်းပါရှိသော စနစ်တကျ မှတ်တမ်းတင်ခြင်းကို အသုံးပြုပါ။
ဥပမာ (Node.js):
ဥပမာ (Python):
အဓိကမူက ရိုးရှင်းပါတယ်- လျှို့ဝှက်ချက်တွေက သစ်လုံးရေကန်ထဲ ဘယ်တော့မှ မရောက်ရဘူး။
၆.၃ လော့ချထားသော သစ်လုံးသိုလှောင်မှု
လုံခြုံရေးထိန်းချုပ်မှုများတွင် အောက်ပါတို့ ပါဝင်သင့်သည်-
- လမ်းညွှန်စာရင်းကို ပိတ်ပါ
- ကာကွယ်သည်
/logs/အထောက်အထားစိစစ်ခြင်းပါရှိသော လမ်းကြောင်းများ - ဘတ်ကက်ဝင်ရောက်ခွင့်ကို ကန့်သတ်ပါ
- ထိန်းသိမ်းမှုမူဝါဒများကို ကျင့်သုံးပါ
- အသုံးမပြုတော့သည့်အချိန်တွင် မှတ်တမ်းများကို ကုဒ်ဝှက်ပါ
မှတ်တမ်းများကို HTTP မှတစ်ဆင့် အများပြည်သူထံ ဘယ်တော့မှ ဝင်ရောက်ကြည့်ရှု၍မရပါ။
6.4 CI/CD Guardrails
လူကိုယ်တိုင် ပြန်လည်သုံးသပ်ခြင်းသည် မလုံလောက်ပါ။ ယင်းအစား၊ အလိုအလျောက် ထိန်းချုပ်မှုများကို အကောင်အထည်ဖော်ပါ-
- ရှေးဟောင်းပစ္စည်းထုတ်ဝေခြင်းမပြုမီ မှတ်တမ်းများကို လျှို့ဝှက်စကင်ဖတ်ခြင်း
- တိုကင်များကို တွေ့ရှိပါက တည်ဆောက်မှုများ မအောင်မြင်ပါ
- အထောက်အထားများပါ၀င်သော artifact အပ်လုဒ်များကို ကာကွယ်ပါ
- artifacts များအတွက် Hash အတည်ပြုခြင်း
CI/CD အညွှန်းမပြုလုပ်မီ ထိတွေ့မှုကို ပိတ်ဆို့သင့်သည်။
၇။ Xygeni က allintext ကို ဘယ်လိုကာကွယ်ပေးသလဲ။login ဖိုင်အမျိုးအစား: မှတ်တမ်း ဖြစ်ရပ်များ
ပြဿနာက Google dork မဟုတ်ဘူး။ ပြဿနာက exposure ပါ။ ဒါကြောင့် indexing မလုပ်ခင်မှာ ကြိုတင်ကာကွယ်မှုတွေ လုပ်ရပါမယ်။
၇.၁ မှတ်တမ်းများနှင့် ရှေးဟောင်းပစ္စည်းများတွင် လျှို့ဝှက်ထောက်လှမ်းခြင်း
Xygeni စကင်န်များ-
- လျှောက်လွှာမှတ်တမ်းများ
- CI/CD အလုပ်အကိုင် ခြေရာခံချက်များ
- ရှေးဟောင်းပစ္စည်းများ တည်ဆောက်ပါ
- Docker အလွှာများ
- အစီအရီပြုလုပ်ထားသော အထွက်များ
အထောက်အထားများ၊ တိုကင်များ သို့မဟုတ် အရေးကြီးသော တန်ဖိုးများ ပေါ်လာပါက .log ဖိုင်များကို Xygeni သည် ၎င်းတို့ကို ချက်ချင်းအလံပြသည်။
7.2 CI/CD Guardrails အဲဒီ Block Exposure
ကိုယ်တိုင်သုံးသပ်ချက်များကို အားကိုးမည့်အစား၊ Xygeni မှာ လုံခြုံရေးကို တင်းကြပ်စွာ တင်းကျပ်ထားပါတယ် pipeline အဆငျ့:
ဒီ:
- လျှို့ဝှက်ချက်များ မှတ်တမ်းများတွင် ပေါ်လာသောအခါ မအောင်မြင်မှုများ တည်ဆောက်သည်
- ဘလောက်စ် ရှေးဟောင်းပစ္စည်း ထုတ်ဝေခြင်း
- မတော်တဆ အများပြည်သူနှင့် ထိတွေ့မှုကို ကာကွယ်ပေးသည်
- အဓိကနေရာသို့ မရောက်မီ မလုံခြုံသော ပေါင်းစည်းမှုများကို ရပ်တန့်စေသည်
CI အလုပ်တစ်ခုက တိုကင်တစ်ခုကို ရိုက်နှိပ်ရင်၊ pipeline မအောင်မြင်ဘူး
အညွှန်းကိန်း မရှိပါ။
ထိတွေ့မှု မရှိပါ။
အဖြစ်အပျက် မရှိပါ။
၇.၃ Google မမြင်မီ Shift-Left ကာကွယ်မှု
အချိန်အခါ အရေးကြီးပါတယ်။
တုံ့ပြန်မည့်အစား-
Xygeni က ပြဿနာကို ရပ်တန့်စေပါတယ်-
- At commit အချိန်
- စဉ်အတွင်း pull request validation ကို
- စဉ်အတွင်း pipeline သတ်ခြင်း
- ရှေးဟောင်းပစ္စည်းထုတ်ဝေခြင်းမပြုမီ
မှတ်တမ်းသည် ဘယ်တော့မှ အများသူငှာ မဖြစ်လာပါက Google သည် ၎င်းကို ဘယ်သောအခါမှ အညွှန်းမတင်ပါ။
နောက်ဆုံးအချက်- Google က ၎င်းကို Index လုပ်နိုင်ပါက၊ တိုက်ခိုက်သူများသည် Index လုပ်ပြီးသားဖြစ်သည်
မှတ်တမ်းတွေက အန္တရာယ်မရှိပါဘူး။ တကယ်တော့၊ သူတို့ဟာ ယာယီဖြစ်ခဲပါတယ်။ မူရင်းအားဖြင့် သူတို့ဟာ သီးသန့်မဟုတ်ပါဘူး။ ဒါကြောင့် မှတ်တမ်းဖိုင်တိုင်းကို debugging output တစ်ခုတည်းအနေနဲ့မဟုတ်ဘဲ လုံခြုံရေးနဲ့သက်ဆိုင်တဲ့ asset အနေနဲ့ သဘောထားသင့်ပါတယ်။
အရေးကြီးဒေတာတစ်ခုသို့ ရောက်ရှိသွားပါက .log ဖိုင်တင်ပြီး အများပြည်သူ ဝင်ရောက်ကြည့်ရှုနိုင်ပါပြီ၊ ၎င်းသည် ချက်ချင်းပင် တိုက်ခိုက်ရေး မျက်နှာပြင်အဖြစ်သို့ ပြောင်းလဲသွားသည်။ ထို့အပြင်၊ ရှာဖွေရေးအင်ဂျင်တစ်ခုမှ index လုပ်လိုက်သည်နှင့်၊ exposure သည် သင့်ထိန်းချုပ်မှုထက် ကျော်လွန်သွားပါသည်။
ဖြေရှင်းချက်မှာ မှတ်တမ်းတင်ခြင်းကို ရပ်တန့်ရန်မဟုတ်ပါ။ ယင်းအစား၊ တာဝန်သိစွာ မှတ်တမ်းတင်ပြီး သိုလှောင်မှုနှင့် ဖြန့်ဖြူးမှုနှင့်ပတ်သက်၍ တင်းကျပ်သော ထိန်းချုပ်မှုများကို ပြဋ္ဌာန်းရန်ဖြစ်သည်။ တစ်နည်းအားဖြင့် လုံခြုံရေးသည် အပလီကေးရှင်းကိုယ်တိုင်ထက် ကျော်လွန်၍ လေ့လာနိုင်သောအလွှာအထိ တိုးချဲ့ရမည်။
အစား:
- လျှို့ဝှက်ချက်များကို မှတ်တမ်းတင်ခြင်းကို ရပ်တန့်ပါ
- မှတ်တမ်းသိုလှောင်မှုကို သော့ခတ်ထားပါ
- ပြforce္ဌာန်း pipeline guardrails
- အလိုအလျောက် ထောက်လှမ်းခြင်းနှင့် မူဝါဒ ပြဋ္ဌာန်းခြင်း
နောက်ဆုံးတွင်, ကာကွယ်ခြင်းသည် အချိန်ကိုက်ခြင်းအကြောင်းဖြစ်သည်။ အဘယ်ကြောင့်ဆိုသော် တစ်ကြိမ်တွင် စာသားlogin ဖိုင်အမျိုးအစား: မှတ်တမ်း သင့်ဒိုမိန်းကို ပြန်ပေးပါသည်၊ အဖြစ်အပျက် စတင်နေပါပြီ။
