အဖွဲ့များနှင့် ဝင်ရောက်အသုံးပြုခွင့်

သင့်အဖွဲ့ရှိ လူတိုင်းကို ၎င်းတို့လိုအပ်သော အသုံးပြုခွင့်ကိုသာ အတိအကျပေးပါ

သုံးစွဲသူ အခန်းကဏ္ဍ လေးခု၊ သင့်လုပ်ငန်း၏ အမှန်တကယ် ဖွဲ့စည်းပုံအတိုင်း ပုံတူကူးထားသည့် အကောင့်ခွဲများ၊ အဖွဲ့အစည်းအလိုက် API ကီးများ၊ Single Sign-On နှင့် လုပ်ပိုင်ခွင့်ရှိသော လုပ်ဆောင်ချက်တိုင်း၏ နောက်ကွယ်မှ စစ်ဆေးရေးမှတ်တမ်း (audit log) တို့ ပါဝင်သည်။ အလားတူ ဝင်ရောက်အသုံးပြုမှု ပုံစံကို ဒက်ရှ်ဘုတ်၊ API၊ CLI၊ Terraform နှင့် ကျွန်ုပ်တို့၏ MCP ဆာဗာတို့တစ်လျှောက် အသုံးပြုထားသည်။ ရရှိနိုင်မှု- Terraform provider မှာ လက်ရှိ တက်ကြွစွာ စာရေးသား ဖန်တီးနေဆဲဖြစ်ပြီး မရရှိနိုင်သေးပါ။ ဤနေရာတွင် ဖော်ပြထားသည့် အခြားအရာအားလုံးကို ယနေ့တွင် အသုံးပြုနိုင်ပြီ ဖြစ်သည်။

  • ၆၅၀,၀၀၀+ကမ္ဘာတစ်ဝန်းတွင် ဟို့စ်တင်လုပ်ထားသော ဆိုက်များ
  • Customer roles များ၊ ကြိုတင်ထည့်သွင်းပြီး အသုံးပြုရန် အသင့်ဖြစ်နေပါပြီ
  • ၃၅အသေးစိတ်ခွင့်ပြုချက် သော့ချက်များ
  • ၁၄ ရက်ကတ်မပါသော အခမဲ့အစမ်းသုံးမှု

လုပ်ငန်းခွဲဝေမှုအပေါ် မူတည်၍ ဖန်တီးထားသော အခန်းကဏ္ဍလေးခု

ဝင်ရောက်ခွင့်ဆိုသည်မှာ ရိုးရှင်းသည့် ဖွင့်/ပိတ် ခလုတ်တစ်ခု မဟုတ်ပါ။ ဖောက်သည်အဖွဲ့အစည်းတိုင်းတွင် အခန်းကဏ္ဍလေးခုစီ ပါရှိပြီး တစ်ခုစီသည် သေးငယ်တိကျသော module.action ခွင့်ပြုချက်များစွာဖြင့် ဖွဲ့စည်းထားသောကြောင့် ငွေကြေးဆိုင်ရာ အဆက်အသွယ်လုပ်သူက ဆာဗာကို ဘယ်တော့မှ မကိုင်တွယ်ရဘဲ ဆော့ဖ်ဝဲရေးသားသူကလည်း ငွေတောင်းခံလွှာကို လုံးဝမမြင်ရပါ။

ပိုင်ရှင်

အဖွဲ့အစည်းနှင့် ယင်း၏ အကောင့်ခွဲများအား အပြည့်အဝ ထိန်းချုပ်ခွင့်- အဖွဲ့အစည်းခွဲများ ဖန်တီးခြင်း၊ အဖွဲ့ဝင်များကို ဖိတ်ခေါ်ခြင်းနှင့် ဖယ်ရှားခြင်း၊ အခန်းကဏ္ဍများ ပြောင်းလဲခြင်း၊ API ကီးများကို စီမံခန့်ခွဲခြင်း၊ ဆိုက်များကို စီစဉ်ပေးခြင်း၊ ပြန်လည်စတင်ခြင်း၊ ဆိုင်းငံ့ခြင်းနှင့် ဖျက်ပစ်ခြင်း၊ အင်ဗွိုက်များနှင့် ငွေပေးချေမှု နည်းလမ်းများကို စီမံခန့်ခွဲခြင်းနှင့် အော်ဒစ်မှတ်တမ်းအား ဖတ်ရှုခြင်းတို့ ပါဝင်သည်။ အရာနှစ်ခုမှာမူ ဤနေရာတွင် ရည်ရွယ်ချက်ရှိရှိ ပါဝင်မည်မဟုတ်ပါ — အဖွဲ့အစည်းတစ်ခုအား ပိတ်သိမ်းခြင်းနှင့် ငွေပြန်အမ်းပေးခြင်းတို့သည် ဝန်ထမ်းများ၏ လုပ်ဆောင်ချက်များသာ ဖြစ်ပြီး သုံးစွဲသူ၏ အခန်းကဏ္ဍမဟုတ်ပါ။

ဘေလ်စီမံခန့်ခွဲသူ

ငွေကြေးဆိုင်ရာ အရာရာသာဖြစ်ပြီး အခြား မပါဝင်ပါ- ပြေစာများ၊ စာရင်းပေးသွင်းမှုများ၊ ငွေပေးချေမှု နည်းလမ်းများနှင့် ပလန် ကတ်တလောက်၊ ထို့အပြင် အဖွဲ့အစည်းနှင့် ၎င်း၏ အဖွဲ့ဝင်စာရင်းကို ကြည့်ရှုခြင်း။ ဆိုက်ကို လုံးဝ ဝင်ရောက်အသုံးပြုခွင့် မရှိပါ — ငွေကြေးဆိုင်ရာ ဆက်သွယ်ရန်ပုဂ္ဂိုလ် သို့မဟုတ် ပြင်ပ စာရင်းကိုင်တစ်ဦးသည် မည်သည့်အရာကိုမျှ ပြန်လည်စတင်ခြင်း၊ ရပ်ဆိုင်းခြင်း သို့မဟုတ် ဖျက်ဆီးခြင်း လုံးဝ မလုပ်နိုင်ပါ။

ဆော့ဖ်ဝဲလ်ဖန်တီးသူ

ငွေကြေးကိစ္စများကို မထိတွေ့ဘဲ ဝဘ်ဆိုက်များတွင် လုပ်ဆောင်ပါ- ဝဘ်ဆိုက်များကို ကြည့်ရှုခြင်းနှင့် ပြင်ဆင်ချိတ်ဆက်ခြင်း၊ ဝန်ဆောင်မှုများကို ပြန်လည်စတင်ခြင်း၊ ကက်ရှ်များကို ရှင်းလင်းခြင်း၊ API သော့များကို စီမံခန့်ခွဲခြင်း၊ နှင့် ပံ့ပိုးကူညီမှု လက်မှတ်များကို တင်ပြခြင်း သို့မဟုတ် ပြန်လည်ဖြေကြားခြင်းတို့ ပြုလုပ်နိုင်ပါသည်။ ငွေတောင်းခံလွှာ ကြည့်ရှုခြင်း၊ အဖွဲ့ဝင် စီမံခန့်ခွဲခြင်း၊ အကောင့်ရပ်ဆိုင်းခြင်းနှင့် ဖျက်ပစ်ခြင်းတို့ မပါဝင်ပါ — ဖျက်ဆီးနိုင်သော နှင့် စီးပွားဖြစ်လုပ်ဆောင်ချက်များကို ပိုင်ရှင်ကသာ ဆောင်ရွက်ပါမည်။

ဖတ်ရှုရန် သက်သက်

ဘာကိုမျှ ပြောင်းလဲရန်စွမ်းရည်မရှိဘဲ အရာအားလုံးကို အပြည့်အစုံ ကြည့်ရှုနိုင်ခြင်း — အဖွဲ့ဝင်များ၊ ဆိုက်များ၊ ဘီလ်ရှင်းတမ်းများ၊ အစီအစဉ်များ၊ တာ့ခ်ကစ်များ၊ ဘာသာပြန်ဆိုမှု အခြေအနေနှင့် စာရင်းစစ်မှတ်တမ်း (audit log) တို့ ဖြစ်သည်။ ၎င်းသည် ဖောက်ဘက်မှ ရှယ်ယာရှင်တစ်ဦး၊ အတွင်းရေး စာရင်းစစ်တစ်ဦး သို့မဟုတ် လုပ်ငန်းခွင်အစပြု လုပ်ကိုင်နေဆဲဖြစ်သူအတွက် သင့်လျော်သော အခန်းကဏ္ဍတစ်ခု ဖြစ်ပါသည်။

သင့်ရဲ့ တိုက်ရိုက်ဖွဲ့စည်းပုံနဲ့ ကိုက်ညီတဲ့ အောက်ခံအကောင့်များ

ငှားရမ်းသုံးစွဲမှုစနစ် (Tenancy) သည် ညီညာသော စာရင်းတစ်ခုမဟုတ်ဘဲ သစ်ပင်တစ်ပင်ကဲ့သို့ အဆင့်ဆင့်ရှိသည်။ ပြန်လည်ရောင်းချသူ အဖွဲ့အစည်းတစ်ခုသည် ၎င်း၏ ဝယ်ယူသူ အဖွဲ့အစည်းများ၏ အထက်တွင်ရှိပြီး၊ ဝဘ်ဆိုက်များသည် ထိုအဖွဲ့အစည်းများ၏ အောက်တွင် ရှိသည်။ အဖွဲ့ဝင်တစ်ဦးဆိုသည်မှာ အဖွဲ့ဝင်ဖြစ်မှုတစ်ခုဖြစ်သည် — သုံးစွဲသူတစ်ဦး၊ အဖွဲ့အစည်းတစ်ခု၊ ရာထူးတစ်ခု — ထို့ကြောင့် အခြေခံအကျဆုံး လုပ်ဆောင်ချက်တစ်ခုတည်းဖြင့်ပင် လူနှစ်ဦးပါ အဖွဲ့တစ်ဖွဲ့၊ ဝယ်ယူသူ အကောင့်ပေါင်းများစွာကို စီမံခန့်ခွဲနေသည့် အေဂျင်စီတစ်ခုနှင့် မိမိ၏ ကိုယ်ပိုင်အမှတ်တံဆိပ်အောက်တွင် အကောင့်ခွဲများကို စီမံခန့်ခွဲနေသည့် ပြန်လည်ရောင်းချသူတစ်ဦးတို့ပါ အသုံးပြုနိုင်မည်ဖြစ်သည်။

အခန်းကဏ္ဍများကို အဖွဲ့အစည်းတစ်ခုစီအလိုက် ပေးအပ်ခြင်းဖြစ်ပြီး ကျင့်သုံးမှုသည်လည်း အဖွဲ့အစည်းတစ်ခုစီအလိုက် ဖြစ်ပါသည်။ အဖွဲ့အစည်းတစ်ခုရှိ အခန်းကဏ္ဍသည် သီးခြားဖြစ်သော သက်ဆိုင်မှုမရှိသည့် အခြားအဖွဲ့အစည်းတစ်ခုတွင် မည်သည့်ဝင်ရောက်ကြည့်ရှုခွင့်ကိုမျှ မပေးပါ — ကန်ထရိုက်တာတစ်ဦးသည် အကောင့်ဝင်ရောက်မှု အကောင့်တစ်ခုတည်းမှပင် သုံးစွဲသူအကောင့်တစ်ခုတွင် Developer အဖြစ်နှင့် ဒုတိယအကောင့်တစ်ခုတွင် Read-only အဖြစ် ရှိနေနိုင်ပါသည်။ သို့သော် ဝင်ရောက်ကြည့်ရှုခွင့်သည် သင်၏ကိုယ်ပိုင် အဆင့်ဆင့်ဖွဲ့စည်းပုံအတိုင်း အောက်သို့ဆင်းသွားပါသည် - ပင်မအဖွဲ့အစည်းတစ်ခုရှိ အခန်းကဏ္ဍသည် ယင်း၏အောက်တွင် ပေါင်းစပ်ထည့်သွင်းထားသော အဖွဲ့အစည်းများအတွက် သက်ရောက်မှုရှိပြီး၊ ယင်းမှာ ပြန်လည်ရောင်းချသူများနှင့် အေဂျင်စီများက ၎င်းတို့၏ သုံးစွဲသူများကို စီမံခန့်ခွဲသည့် နည်းလမ်းဖြစ်ပါသည်။

အပလီကޭရှင်းကုဒ်တွင်သာမက ဒေတာဘေ့စ်တွင်ပါ သီးသန့်ခွဲထုတ်မှုကို တင်းတင်းကျပ်ကျပ် လုပ်ဆောင်ထားသည်။ Postgres ၏ စာကြောင်းအဆင့် လုံခြုံရေး (row-level security) က သုံးစွဲသူခေါ်ဆိုသည့် လက်အခံပင်စည် (subtree) အတွင်းသာ tenant မေးမြန်းချက်အားလုံးကို ကန့်သတ်ပေးပြီး၊ ယင်းလက်အခံပင်စည်ပြင်ပရှိ မည်သည့်အရာကိုမဆို ခွင့်ပြုချက်မရှိကြောင်း အမှားပြမည့်အစား ရှာမတွေ့ပါ အဖြစ် ပြန်ပေးသည်။ ထို့ကြောင့် အခြား tenant တစ်ခု၏ အဖွဲ့အစည်း သို့မဟုတ် ဆိုက် ရှိနေကြောင်းကိုပင် ပလက်ဖောင်းက အတည်ပြုပေးခြင်း မရှိပါ။

မျက်နှာပြင်အားလုံးတွင် တူညီသောခွင့်ပြုချက်များ

အခန်းကဏ္ဍများသည် ဒက်ရှ်ဘုတ်အတွက် သက်သက်သာသာ ပြုလုပ်ထားခြင်း မဟုတ်ပါ။ ပလပ်ဖောင်းဆီသို့ ဝင်ရောက်ရာ လမ်းကြောင်းတိုင်းသည် တူညီသော ခွင့်ပြုချက်သော့ချက်များဆီသို့သာ ဦးတည်သွားသောကြောင့် သင့်ဝင်ရောက်ခွင့် စည်းမျဉ်းများကို ကျော်သွားနိုင်သည့် နောက်ပေါက် မရှိပါ။

ဒက်ရှ်ဘုတ်

ဆိုဒ်များ၊ ငွေတောင်းခံလွှာများ၊ လက်မှတ်များ၊ အသိပေးချက်များ၊ အကြောင်းကြားချက်များ၊ API သော့များနှင့် အသင်း စီမံခန့်ခွဲမှုတို့ကို ပုံစံတူ တစ်ခုတည်းတွင် ပေါင်းစပ်ထားသည်။ အသုံးပြုသူ၏ ဝင်ရောက်ခွင့် အခန်းကဏ္ဍအရ ခွင့်ပြုထားသည်များကိုသာ အင်တာဖေ့စ်က ဖော်ပြပေးသောကြောင့် အသုံးပြုခွင့်မရှိသော ထိန်းချုပ်ခလုတ်များကို လူတိုင်း မမြင်ရပါ။

အများသုံး API နှင့် CLI

ထုတ်ဝေထားသော API သည် ဒက်ရှ်ဘုတ်အသုံးပြုနေသည့် အင်ဂျင် API ပင် ဖြစ်ပါသည်။ API သော့များကို အဖွဲ့အစည်းတစ်ခုချင်းစီအတွက် RBAC ခွင့်ပြုချက်များနှင့် ချိတ်ဆက်ထားသော အသေးစိတ်နယ်ပယ်များဖြင့် ထုတ်ပေးထားပြီး သီးခြား sandbox နှင့် live မုဒ်များပါရှိသဖြင့် စစ်မှန်သော ငွေတောင်းခံမှု သို့မဟုတ် ပရိုဗီးရှင်းကို မထိခိုက်စေဘဲ ပေါင်းစပ်မှုများကို စမ်းသပ်နိုင်ပါသည်။

Terraform ပrovider

ဆိုက်များ၊ ဒိုမိန်းများ၊ DNS၊ စာတိုက်ပုံးများနှင့် ပလန်များကို infrastructure-as-code အဖြစ် စီမံခန့်ခွဲပြီး ဟိုစတင်းပြင်ဆင်သတ်မှတ်ရန် terraform apply ကို ရန်းပါ — အခြားအရာအားလုံးကဲ့သို့ပင် တူညီသော စကိုပ်များဖြင့် ထိန်းချုပ်ထားသည်။

MCP ဆာဗာ

Claude Code၊ Cursor၊ ChatGPT၊ Claude Desktop သို့မဟုတ် MCP ကိုအသုံးပြုနိုင်သည့် မည်သည့်တူးလ်ကိုမဆို ချိတ်ဆက်ပါ။ တိုကင်များကို အဖွဲ့အစည်းတစ်ခုနှင့် ၎င်း၏ RBAC ခွင့်ပြုချက်များအပေါ် မူတည်ပြီး သတ်မှတ်ထားကာ၊ တူးလ်တစ်ခုချင်းအလိုက် ပြန်လည်ရုပ်သိမ်းနိုင်ပြီး၊ ဖျက်ဆီးမှုဖြစ်စေမည့် လုပ်ဆောင်ချက်များအတွက် အတည်ပြုချက်၊ သုံးစွဲမှုအထွတ်အထိပ် ကန့်သတ်ချက်များ (spend caps) နှင့် အပြည့်အစုံ စစ်ဆေးနိုင်သည့် မှတ်တမ်းအချက်အလက်များ ပါရှိသည်။

သော့ချက် စီမံခန့်ခွဲမှု

API သော့တစ်ခုစီ၏ ဟက်ခ် (hash) တန်ဖိုးကိုသာ သိမ်းဆည်းထားပြီး မူရင်းသော့ကို လုံးဝမသိမ်းဆည်းပါ။ သော့များကို တစ်ခုနှင့်တစ်ခု ခွဲခြားသိနိုင်ရန်၊ နောက်ဆုံးအသုံးပြုခဲ့သည့် အချိန်ကို မှတ်တမ်းတင်နိုင်ရန်နှင့် အခြားသော့များကို မထိခိုက်စေဘဲ တစ်ခုချင်းစီ ရုပ်သိမ်းနိုင်ရန်အတွက် သော့များတွင် အမည်နှင့် မြင်နိုင်သော ရှေ့ဆက် (prefix) တစ်ခု ပါရှိသည်။

အကောင့်ဝင်ခြင်း တစ်ခုတည်းဖြင့်၊ စံနှုန်းများအခြေခံ၍၊ အရာအားလုံးအတွက်

Identity သည် Keycloak ကို အခြေခံထားသောကြောင့် လက်လုပ်စပ်လုပ် လော့ဂ်အင်ပုံစံအစား စစ်မှန်သော OIDC နှင့် SAML တို့ကို အသုံးပြု၍ စစ်မှန်ကြောင်းအထောက်အထားပြသခြင်းကို လုပ်ဆောင်နိုင်ပါသည်။

  • မတ်ဂျစ်လင့်ခ် အီးမေးလ် အကောင့်ဝင်ခြင်းကို မူလအတိုင်း အသုံးပြုနိုင်ပြီး၊ ပိုနှစ်သက်သူများအတွက် အီးမေးလ်နှင့် စကားဝှက်ကို အရန်နည်းလမ်းအဖြစ် ထည့်သွင်းပေးထားပါသည်။
  • Passkeys နှင့် WebAuthn တို့သည် phishing ကို ခံနိုင်ရည်ရှိသော ဝင်ရောက်မှုအတွက်ဖြစ်ပြီး၊ မူဝါဒအရ လူတိုင်းအတွက် အတင်းအကျပ်သုံးခိုင်းထားသော TOTP နှစ်ဆင့် အတည်ပြုခြင်းလည်း ပါဝင်သည်။
  • Google, Microsoft, GitHub နှင့် အခြားသော အထောက်အထားစိစစ်ပေးသည့် ပံ့ပိုးပေးသူများမှတစ်ဆင့် လူမှုကွန်ရက်ဖြင့် အကောင့်ဝင်ခြင်း။
  • လုပ်ငန်းကြီးများနှင့် အေဂျင်စီဖောက်သည်များအတွက် SAML တစ်ခုတည်းဖြင့် အကောင့်ဝင်ခြင်း (single sign-on) ဖြစ်ပြီး သင့်အဖွဲ့၏ ဝင်ရောက်ခွင့်သည် သင်၏ရှိပြီးသား လမ်းညွှန် (directory) အတိုင်း ဖြစ်စေပါသည်။
  • ဒက်ရှ်ဘုတ်၊ အက်ဒမင် ကွန်ဆိုးလ်၊ ပရိုဂရမ်ဆိုင်ရာ ဝက်ဘ်ဆိုက်နှင့် အသိပညာဗဟုသုတ စုဆောင်းမှု၊ ထို့ပြင် အကူအညီတောင်းခံမှုများအတွက် ဆက်ရှင်တစ်ခုတည်းသာ သုံးသည် - ငါးကြိမ်တိုင် အကောင့်ဝင်စရာမလိုဘဲ တစ်ကြိမ်တည်းသာ အကောင့်ဝင်ပါ။
  • အကောင့်တစ်ခု မဖန်တီးမီ စာရင်းသွင်းမှုအီးမေးလ်တိုင်းကို စစ်ဆေးအတည်ပြုပေးသောကြောင့် ပို့၍မရသည့်နှင့် မမှန်ကန်သည့် လိပ်စာများသည် သင့်အဖွဲ့ထဲသို့ လုံးဝရောက်ရှိလာမည် မဟုတ်ပါ။
  • စံနှုန်းများကို အခြေခံထားခြင်းကြောင့် အခြားမည်သည့်အရာကိုမျှ ပုံစံပြန်မတည်ဆောက်ဘဲ အထောက်အထားစိစစ်ပေးသည့် ပံ့ပိုးပေးသူကိုပင် လဲလှယ်အသုံးပြုနိုင်ပါသည် — ဤသည်မှာ ကျွန်ုပ်တို့၏ အခြားသော ရောင်းချသူအားလုံးအပေါ် ကျင့်သုံးသည့် လော့ခ်ချမှုမရှိသော တူညီသည့်စည်းမျဉ်းပင် ဖြစ်ပါသည်။

စာရင်းစစ်တစ်ဦးအား ယုံကြည်စိတ်ချစွာ ပေးအပ်နိုင်သည့် တာဝန်ခံမှု

အခွင့်ထူးခံလုပ်ဆောင်ချက်တိုင်းသည် ထပ်ဖြည့်ရုံသာပြုလုပ်နိုင်သော (append-only) စာရင်းစစ်မှတ်တမ်းတစ်ခုကို ရေးသားသည်- မည်သူကလုပ်ဆောင်ခဲ့သည်၊ ၎င်းတို့ဘာလုပ်ခဲ့သည်၊ မည်သည့်အပေါ်တွင်လုပ်ဆောင်ခဲ့သည်၊ အထောက်အထားနှင့် မူလ IP လိပ်စာတို့ဖြစ်သည်။ အဆိုပါမှတ်တမ်းသည် ထပ်ဖြည့်ရုံသာဖြစ်သည် - ဖြစ်ရပ်များကို နေရာတကျတည်းဖြတ်ခြင်းမဟုတ်ဘဲ ထည့်သွင်းခြင်းသာဖြစ်ပြီး - ထုတ်လုပ်မှုပတ်ဝန်းကျင်တွင် ကြီးထွားလာသည်နှင့်အမျှ အမြန်နှုန်းမပျက်စေရန် အချိန်အလိုက်ပိုင်းခြားထားသည်။

ထိုမှတ်တမ်းကို ဖတ်ရှုခြင်းသည်ပင်လျှင် ခွင့်ပြုချက်တစ်ခု ဖြစ်ပါသည်။ အကောင့်အတွက် တာဝန်ရှိသူနှင့် စာရင်းစစ်ဆေးနေသူတို့အနေဖြင့် အထူးအခွင့်အရေးများ မလိုအပ်ဘဲ ရာဇဝင်အပြည့်အစုံကို ကြည့်ရှုနိုင်စေရန် ပိုင်ရှင်များနှင့် ဖတ်ရှုခွင့်သက်သက်ရှိသော အဖွဲ့ဝင်များက ၎င်းကို ကိုင်ဆောင်ထားကြသည်။

ထိုအရာများ၏ ပတ်လည်တွင် ပိုမိုကြီးမားသော အဖွဲ့များ တောင်းဆိုလေ့ရှိသည့် ထိန်းချုပ်မှုများ ရှိပါသည် - ၎င်းတို့မှာ စက်ရှင် မူဝါဒများ၊ အဖွဲ့အစည်းအလိုက် စိတ်ကြိုက် သတ်မှတ်နိုင်သော IP allowlist များနှင့် အရေးကြီးသော လုပ်ဆောင်ချက်များတွင် အဆင့်မြှင့် အတည်ပြုခြင်းတို့ ဖြစ်သဖြင့် သာမန် ဝင်ရောက်ထားဆဲ စက်ရှင်တစ်ခုတည်းဖြင့် အရေးကြီးသော လုပ်ဆောင်ချက်များကို ပြုလုပ်ရန် မလုံလောက်ပါ။

ခွင့်ပြုချက်များသည် သင်နှင့်အတူ မည်သို့တိုးတက်လာပုံ

ခွင့်ပြုချက် ကတ်တလောက်သည် ဟတ်ကုဒ်လုပ်ထားသော လိုဂျစ်မဟုတ်ဘဲ ဒေတာဖြစ်သည် — ထို့ကြောင့်ပင် ပလပ်ဖောင်းကို ပိုက်လိုင်းအသစ်ပြန်မသွယ်ဘဲ ၎င်းကို တိုးချဲ့နိုင်ခြင်း ဖြစ်သည်။

  • ယနေ့တွင် အဖွဲ့အစည်းများ၊ အဖွဲ့ဝင်များ၊ API ကီးများ၊ ဆိုဒ်များ၊ ငွေတောင်းခံလွှာများ၊ အစီအစဉ်များ၊ ဖလီးစ်၊ လက်မှတ်များ၊ သုံးစွဲသူများ၊ အလွဲသုံးစားမှု၊ ကမ်ပိန်းများ၊ ဘာသာပြန်ဆိုချက်များနှင့် စစ်ဆေးခြင်းတို့ ပါဝင်သော သီးခြား module.action ကီး ၃၅ ခု ရှိပါသည်။
  • ဖြန့်ကျက်မှု (deploy) ပြုလုပ်သည့် အကြိမ်တိုင်းတွင် ကတ်တလောက်ကို တွက်ချက်မှု ရလဒ်မပြောင်းလဲဘဲ မူလအတိုင်း ထည့်သွင်းပေးမည်ဖြစ်ပြီး၊ ရာထူးနေရာတစ်ခုခုက မရှိသော ခွင့်ပြုချက်တစ်ခုကို ရည်ညွှန်းကိုးကားပါက အတည်ပြုခြင်း ပျက်ကွက်ကြောင်း အသိပေးချက် ချက်ချင်းပြသမည်ဖြစ်သည် — စာလုံးပေါင်း အမှားတစ်ခုကြောင့် မည်သည့်ခွင့်ပြုချက်မျှ မရရှိဘဲ တိတ်ဆိတ်စွာ ပြီးသွားခြင်းမျိုး ဖြစ်ပေါ်နိုင်မည် မဟုတ်ပါ။
  • ထုတ်ကုန်၏ စွမ်းဆောင်ရည်သစ်များသည် အဆုံးသတ်အမှတ် (endpoint) စတင်မလွှင့်တင်မီ ၎င်းတို့၏ ခွင့်ပြုချက်ကီးများကို ကက်တလောက်ထဲသို့ ထည့်သွင်းပေးထားသဖြင့် လုပ်ဆောင်ချက်တစ်ခု စတင်အသုံးပြုနိုင်သည့်အခါ ဝင်ရောက်ခွင့် ထိန်းချုပ်မှုများအား နောက်မှပြန်လည် ပြင်ဆင်တပ်ဆင်ရန် မလိုအပ်တော့ပါ။
  • အသင်းဝင်ခွင့်တစ်ခုတည်းကို သီးခြားဆိုက်များ သို့မဟုတ် သီးခြားဒေသတစ်ခုခုအထိ သီးသန့်ကန့်သတ်ခြင်းသည် အနာဂတ်တွင် ပြုပြင်မွမ်းမံရန် စီစဉ်ထားသည့် အရာတစ်ခုဖြစ်ပြီး ယနေ့တွင် ချက်ချင်းဖွင့်၍ ရနိုင်သည့်အရာ မဟုတ်သေးပါ။ လက်ရှိလုပ်ဆောင်နိုင်သည့် ပုံစံမှာ အဆိုပါဆိုက်များကို အဖွဲ့အစည်းခွဲ (child organisation) တစ်ခုအောက်တွင် ထည့်သွင်းပြီး ထိုသူအား ထိုနေရာတွင် တာဝန်တစ်ရပ် သတ်မှတ်ပေးခြင်းဖြစ်သည် — ယင်းက အဖွဲ့အစည်းဖွဲ့စည်းပုံသစ်ပင် (tenancy tree) ကို အသုံးပြု၍ သီးခြားခွဲထုတ်မှုကို စာရင်းတူ ရရှိစေမည် ဖြစ်သည်။
  • API သော့များကို တစ်ဦးချင်းစီအစား အဖွဲ့အစည်းအဆင့်တွင် ထုတ်ပေးထားသောကြောင့် ၎င်းတို့ကို ပေါင်းစပ်မှုများအတွက် ဝန်ဆောင်မှုအထောက်အထားများအဖြစ် ဆက်ဆံပြီး လူသားများ ဝင်ရောက်အသုံးပြုရန်အတွက် အဖွဲ့ဝင်မှုများကို အသုံးပြုပါ။

မကြာခဏ မေးလေ့ရှိသော မေးခွန်းများ

အခန်းကဏ္ဍတစ်ခုချင်းစီက တကယ်တမ်း ဘာတွေလုပ်ဆောင်နိုင်သလဲ။

ပိုင်ရှင်သည် အဖွဲ့အစည်းနှင့် ၎င်း၏ အဖွဲ့ဝင်များ၊ API သော့များ၊ ဆိုက်များနှင့် ငွေပေးချေမှု နည်းလမ်းများ အပါအဝင် လုပ်ပိုင်ခွင့် အပြည့်အဝ ရှိသည်။ ဘီလ်မန်နေဂျာသည် ငွေတောင်းခံလွှာများ၊ စာရင်းသွင်းမှုများ၊ ငွေပေးချေမှု နည်းလမ်းများနှင့် အစီအစဉ်များကို ဆိုက်ဝင်ရောက်ခွင့်မရှိဘဲ ကြည့်ရှုနိုင်သည်။ Developer သည် ဆိုက်များနှင့် API သော့များကို စီမံခန့်ခွဲပြီး ဘီလ် သို့မဟုတ် အဖွဲ့ဝင် ထိန်းချုပ်ခွင့်မရှိဘဲ တာဝန်ခံလွှာများကို ကိုင်တွယ်သည်။ Read-only သည် မည်သည့်အရာကိုမျှ မပြောင်းလဲဘဲ အဖွဲ့ဝင်များ၊ ဆိုက်များ၊ ဘီလ်၊ အစီအစဉ်များ၊ တာဝန်ခံလွှာများနှင့် စာရင်းစစ်မှတ်တမ်းကို ကြည့်ရှုနိုင်သည်။

တစ်ဦးချင်းစီကို ဝဘ်ဆိုဒ်တစ်ခုတည်းအတွက်သာ ဝင်ရောက်ခွင့်ပေးလို့ရပါသလား။

ဆိုက်တစ်ခုချင်းစီအလိုက် သတ်မှတ်ပေးသည့် ဆက်တင်အဖြစ် မရသေးပါ — အဖွဲ့ဝင်တစ်ဦးတည်းကို သီးခြားဆိုက်များသို့ ကန့်သတ်ပေးခြင်းသည် အနာဂတ်တွင် ပြုပြင်မွမ်းမံရန် စီစဉ်ထားသည့် အရာဖြစ်ပါသည်။ ယနေ့တွင် ထိုသို့ သီးခြားခွဲထုတ်ခြင်းမျိုးရရှိရန် တည်ဆောက်ပုံသစ်ပင် (tenancy tree) ဖြင့် ဆောင်ရွက်နိုင်သည်- ထိုဆိုက်များကို လက်အောက်ခံ အဖွဲ့အစည်းတစ်ခုအတွင်း သို့ ထည့်သွင်းပြီး ထိုသူအား ထိုနေရာတွင် အခန်းကဏ္ဍ (role) တစ်ခု ပေးလိုက်ပါ။ အခန်းကဏ္ဍများကို အဖွဲ့အစည်းအလိုက် ခွင့်ပြုပေးခြင်းဖြစ်သောကြောင့် ထိုဝင်ရောက်ကြည့်ရှုခွင့်သည် သင်၏ အကောင့်ရှိ အခြားမည်သည့်အရာသို့မျှ ကူးစက်သွားမည် မဟုတ်ပါ။

API သော့များသည် တစ်ဦးချင်းစီ အဖွဲ့ဝင်များနှင့် သက်ဆိုင်ပါသလား။

မဟုတ္ပါ — API keys များကို အဖွဲ့အစည်းတစ်ခုစီအလိုက် ထုတ်ပေးထားပြီး တူညီသော RBAC ခွင့်ပြုချက်များနှင့် ချိတ်ဆက်ထားသည့် အသေးစိတ် လုပ်ပိုင်ခွင့်နယ်ပယ်များအပြင် သီးခြား sandbox နှင့် live မုဒ်များ ပါဝင်သည်။ ၎င်းတို့ကို ပေါင်းစပ်ဆက်သွယ်မှုများ၊ CI သို့မဟုတ် Terraform တို့အတွက် ဝန်ဆောင်မှု အထောက်အထားများအဖြစ် အသုံးပြုပြီး လူပုဂ္ဂိုလ်များအတွက် အဖွဲ့ဝင်ဖြစ်မှုများကို အသုံးပြုပါ။ Key တစ်ခုစီ၏ hash ကိုသာ သိမ်းဆည်းထားပြီး Key တစ်ခုစီအတွက် နောက်ဆုံးအသုံးပြုခဲ့သည့် အချိန်ကို မှတ်တမ်းတင်ထားကာ မည်သည့် Key ကိုမဆို သီးခြားစီ ပယ်ဖျက်နိုင်သည်။

မုဒ်လွှင့်ထားသော ဆိုက်သို့ တိုးတက်ပြောင်းလဲသူတစ်ဦးက ပြင်ဆင်မှုများကို ပေးပို့ (push) နိုင်ပါသလား။

Developer အခန်းကဏ္ဍတွင် ဆိုက်များကို ကြည့်ရှုခြင်းနှင့် ပြင်ဆင်သတ်မှတ်ခြင်း၊ ဝန်ဆောင်မှုများကို ပြန်လည်စတင်ခြင်း၊ cache များကို ရှင်းလင်းခြင်း၊ API သော့များကို စီမံခန့်ခွဲခြင်းနှင့် တောင်းဆိုချက်လက်မှတ်များကို ကိုင်တွယ်ခြင်းတို့ ပါဝင်သည်။ ၎င်းတွင် တိုက်ရိုက်လွှင့်ထားသော ဆိုက်တစ်ခုပေါ်တွင် ထုတ်ဝေနိုင်သည့် အခွင့်အရေး မပါဝင်ပါ၊ ထို့ကြောင့် ပြောင်းလဲမှုများကို လွှင့်တင်နိုင်စေရန် တစ်စုံတစ်ယောက်အား အခွင့်အရေးပေးလိုပါက ထိုလုပ်ပိုင်ခွင့်ကို ပိုင်ရှင်ထံတွင် ထားရှိရန် လိုအပ်သည်။ အခန်းကဏ္ဍများသည် အဖွဲ့အစည်းတစ်ခုစီအလိုက် ဖြစ်သောကြောင့် သင်သည် အကောင့်တစ်ခုနှင့်တစ်ခုတွင် အခန်းကဏ္ဍမတူညီဘဲ ရယူထားနိုင်သည်။

ကျွန်ုပ်တို့၏ ကုမ္ပဏီဒါရိုက်တာအတွက် SSO ကို သင်တို့ ပံ့ပိုးပေးပါသလား။

ဟုတ်ပါတယ်။ Identity ကို OIDC နှင့် SAML အသုံးပြုထားသည့် Keycloak ပေါ်တွင် လည်ပတ်ထားသောကြောင့် မူဝါဒအရ မဖြစ်မနေ အသုံးပြုရသည့် မော်ဂျူးဖြစ်သော မူပိုင်လင့်ခ်မှတစ်ဆင့် လော့ဂ်အင်ဝင်ခြင်း၊ အီးမေးလ်နှင့် စကားဝှက်၊ လူမှုကွန်ရက် အကောင့်များ၊ ပတ်စ်ကီးများနှင့် TOTP နှစ်ဆင့်စစစ်မှန်ကြောင်း အတည်ပြုခြင်းတို့အပြင် လုပ်ငန်းသုံးနှင့် အေဂျင်စီ သုံးစွဲသူများအတွက် SAML single sign-on ကိုလည်း ရရှိနိုင်ပါသည်။ စက်ရှင်တစ်ခုတည်းဖြင့် ဒက်ရှ်ဘုတ်၊ အများပြည်သူသုံး ဝဘ်ဆိုက်နှင့် ဗဟုသုတစခန်း၊ ထို့ပြင် ပံ့ပိုးကူညီမှု လက်မှတ်များကိုပါ အသုံးပြုနိုင်မည် ဖြစ်သည်။

တစ်ခုခုကို ဘယ်သူပြောင်းလဲခဲ့တယ်ဆိုတာ ဘယ်လိုသိနိုင်မလဲ။

အခွင့်ထူးခံ လုပ်ဆောင်ချက်တိုင်းကို လုပ်ဆောင်သူ၊ လုပ်ဆောင်ချက်၊ ပစ်မှတ်၊ ထောက်ပံ့ပေးသည့် အထောက်အထားနှင့် IP လိပ်စာတို့ကို မှတ်တမ်းတင်ထားသည့် ထပ်ထည့်ရုံသာ လုပ်ဆောင်နိုင်သော စာရင်းစစ်မှတ်တမ်း (audit log) တွင် ရေးသွင်းပါသည်။ ၎င်းကို ဖတ်ရှုခြင်းသည် ပိုင်ရှင် (Owner) နှင့် စာရင်းစစ်ရန်သာ ကြည့်ရှုနိုင်သော (Read-only) အခန်းကဏ္ဍနှစ်ခုစလုံးတွင် ရှိသည့် သီးသန့်ခွင့်ပြုချက်တစ်ခုဖြစ်သောကြောင့် အကောင့်ပိုင်ရှင်နှင့် စာရင်းစစ်တစ်ဦးတို့သည် တူညီသောမှတ်တမ်းရာဇဝင်ကို အတူတကွ ပြန်လည်စစ်ဆေးနိုင်ပါသည်။

အဖွဲ့ဝင်များ ထည့်ခြင်းက ကျွန်ုပ်ပေးချေရမည့် ငွေပမာဏကို ပြောင်းလဲစေပါသလား။

ဤစည်းမျဉ်းများသည် လူဦးရေထက် ဟိုစ့်တင်နိုင်စွမ်းပမာဏအပေါ်မူတည်၍ ဈေးနှုန်းသတ်မှတ်ထားသည်။ ဥပမာအားဖြင့် Footprint-Free လိုင်းတွင် အဆင့် 42 ခုစလုံးသည် အခွင့်အရေးအစုံအလင်ကို အတိအကျတူညီစွာ မျှဝေခံစားကြပြီး ၎င်းတို့ခွင့်ပြုထားသော ဆိုက်အရေအတွက်ဖြင့်သာ ကွာခြားကြသည်။ ဈေးနှုန်းများကို သင်၏ငွေကြေးဖြင့် တိုက်ရိုက်ထုတ်လွှင့်နေသော စာရင်းမှသာ အမြဲတမ်းဖော်ပြပေးသောကြောင့် ဈေးနှုန်းစာမျက်နှာတွင် သင်မြင်ရသည့်အတိုင်းသာ အမှန်တကယ် ကောက်ခံသွားမည်ဖြစ်သည်။

မဝယ်ယူမီ စမ်းသုံးကြည့်လို့ရပါသလား။

ဟုတ်ပါတယ်။ Footprint-Free အခမဲ့စမ်းသုံးခွင့်သည် ၁၄ ရက်ကြာမြင့်ပြီး ကတ်အသေးစိတ်အချက်အလက်များ ပေးရန်မလိုဘဲ ဝဘ်ဆိုက် ၅ ခုအထိ လွှမ်းခြုံထားသောကြောင့် ငွေမပေးချေမီ သင့်အဖွဲ့အစည်းကို စတင်သတ်မှတ်ခြင်း၊ သင့်အဖွဲ့အား ဖိတ်ခေါ်ခြင်းနှင့် စာရင်းဝင်လုပ်ငန်းစဉ်များအတိုင်း အခန်းကဏ္ဍများကို စမ်းသပ်ခြင်းတို့ ပြုလုပ်နိုင်ပါသည်။ သက်ဆိုင်ရာ အခပေး ပလန်များအတွက် ရက် ၃၀ အတွင်း ငွေပြန်အမ်းပေးမည့် အာမခံချက်လည်း ပါရှိပါသည်။

လက်မှတ်ဖြတ်ပိုင်းများမဟုတ်ဘဲ မိနစ်ပိုင်းအတွင်း သင့်အဖွဲ့ကို စနစ်ထည့်သွင်းပါ

ကတ်အသုံးပြုရန်မလိုဘဲ Footprint-Free လိုင်းတွင် ၁၄ ရက်ကြာ အခမဲ့စမ်းသုံးမှုကို စတင်ပါ၊ သင့်အဖွဲ့ကို ဖိတ်ကြားပါ၊ မည်သည့်ငွေမှမပေးချေရသေးမီ လက်တွေ့ဆိုက်များနှင့် ဆက်စပ်လုပ်ဆောင်နေသော လုပ်ဆောင်ချက်များကို ကြည့်ရှုပါ။

အခမဲ့ စတင်ပါ