Skip to content

လုပ်ငန်းလုံခြုံရေး

Operational Security သည် Iroha deployment အနီးရှိလူများ၊ အိမ်ရှင်များ၊ ခွင့်ပြုချက်များနှင့်လုပ်ငန်းစဉ်များကိုကာကွယ်သည်။ လက်မှတ်ရေးမှတ်တမ်းများတွင်အခြေအနေအပြောင်းအလဲများကိုလက်ခံထားရသည်။ လည်ပတ်သူများသည်သူတို့၏အလုပ်ရုံစခန်းများ၊ လက်မှတ်ထိုးသော သော့များနှင့်ဖြစ်ရပ်တုံ့ပြန်မှု လုပ်ငန်းစဉ်တို့ကို သီးခြားလုံခြုံရန်လိုအပ်သည်။

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

စီမံခန့်ခွဲမှု အခြေခံအဆင့်ကို ချမှတ်ရန်

  • validator host များ၊ peer identities များ၊ account authority များ၊ လက်မှတ်ထိုးရေး ကိရိယာများ၊ အများသုံး endpoints များနှင့် တာဝန်ရှိသူများကို စာရင်းပြုစုပါ။
  • ဖွံ့ဖြိုးရေး၊ စမ်းသပ်မှု၊ ထုတ်လုပ်မှုအတွက် သီးခြား ခွင့်ပြုချက်များကို အသုံးပြုပါ။ လက်မှတ်ထိုးသူတိုင်း၊ သယ်ဆောင်သူ token တစ်ခုစီနဲ့ ပုဂ္ဂလိက သော့ကို ပတ်ဝန်းကျင်တစ်ခုမှာ သတ်မှတ်ပေးပါ။
  • Configuration နဲ့ Deployment Automation ကို Reviewable Version Control မှာ ထိန်းထားပါ။ ခွင့်ပြုထားတဲ့ လျှို့ဝှက် သိုလှောင်ရုံ (သို့) လက်မှတ်ရေးထိုးတဲ့ ကိရိယာကနေ Runtime မှာ လျှို့၀ှက်ချက်တွေကို ထိုးထည့်ပါ။
  • release artifact များ၏ မျှော်လင့်ထားသော hash သို့မဟုတ် လက်မှတ်များကို မှတ်တမ်းတင်ပြီး deployment မတိုင်မီ စစ်ဆေးပါ။ binary များ၊ genesis material၊ configuration သို့မဟုတ် service definition များကို အစားထိုးနိုင်သူကို ကန့်သတ်ပါ။
  • Operating system account များ၊ Iroha ခွင့်ပြုချက်များနှင့် ကွန်ရက်စီမံခန့်ခွဲမှုများကို အနည်းဆုံး အခွင့်ထူးကို အသုံးချပါ။ role တစ်ခုစီအတွက် ၎င်း၏အလုပ်က လိုအပ်သော အာဏာကိုသာ ပေးပါ။
  • ထုတ်လုပ်မှု မစတင်မီ backup၊ restore၊ key replacement နှင့် peer recovery လုပ်ငန်းစဉ်များကို စမ်းသပ်ပါ။

အခြေခံအဆင့်ကို သတ်မှတ်ရာတွင် လုံခြုံရေးမူဝါဒများ နှင့် လွတ်မြောက်ရန် အသင့်ရှိမှု ကို ပြန်လည်သုံးသပ်ပါ။

သော့များနှင့် လက်မှတ်ရေးထိုးသူများကို ကာကွယ်ပေးပါ

  • Private key များ၊ seed material များ၊ bearer token များ၊ authorization header များနှင့် recovery secret များကို source control၊ issue tracker၊ chat transcript၊ screenshot နှင့် public documentation များထဲတွင် မထည့်ပါနှင့်။
  • တန်ဖိုးမြင့် အာဏာပိုင်များအတွက် hardware-backed သို့မဟုတ် သီးသန့် signing ကို အသုံးပြုပါ။ client က signing ကို လွှဲအပ်နိုင်သည့်အခါ raw key material ကို browser များနှင့် အထွေထွေသုံး application process များ၏ အပြင်ဘက်တွင် ထားပါ။
  • ပုံမှန် ငွေပေးချေမှုတွေ၊ အုပ်ချုပ်ရေး၊ ဖြန့်ဖြူးမှု၊ ပြန်လည်ထူထောင်ရေးအတွက် သီးခြားအာဏာပိုင်တွေကို သုံးပါ။
  • လျှို့ဝှက် သိုလှောင်မှုနှင့် ၎င်း၏ Backup များကို Encrypt လုပ်ပါ။ Live Key နှင့်တူသော Private-key Backup ကို Access Controls များကို အသုံးပြုပါ။
  • စစ်ဆေးထားတဲ့ အစားထိုးခြင်း (သို့) ပြန်လည်သိမ်းဆည်းခြင်း လုပ်ငန်းစဉ်ကို ထိန်းသိမ်းပါ။ မူဝါဒက တောင်းဆိုတဲ့အခါ သို့မဟုတ် ထိတွေ့မှု သံသယရှိတဲ့အခါ သော့တစ်ခုကို အစားထိုးပါ။
  • အတည်ပြုသူအဖွဲ့ဝင်၊ အခွင့်ထူးခံတာဝန်များ (သို့) တန်ဖိုးမြင့် အရင်းအမြစ်များကို ပြောင်းလဲမှုအတွက် လွတ်လပ်စွာ စစ်ဆေးရန် တောင်းဆိုပါ။

Generating Cryptographic Keys နှင့် Storing Cryptographic keys တို့ကို ကြည့်ပါ။

Harden Nodes နှင့် Operator Access များ

  • လက်ရှိမှာ ပေးသွင်းသူက ထောက်ပံ့တဲ့ စနစ်တွေမှာ node တွေနဲ့ operator tool တွေကို run လုပ်ပါ။ မလိုလားအပ်တဲ့ ဝန်ဆောင်မှုတွေ Disable လုပ်ပါ။
  • အမည်သတ်မှတ်ထားသော operator များကို audited၊ encrypted channel များမှသာ administrative access ပေးပါ။
  • public မဟုတ်သော interface များကို private network သို့မဟုတ် VPN တွင် ထားပါ။
  • deployment အတွက် လိုအပ်သော Torii၊ monitoring နှင့် application route များကိုသာ expose လုပ်ပါ။
  • public ingress တစ်ခုချင်းစီကို ပတ်ဝန်းကျင်နှင့် သင့်လျော်သော request rate limit နှင့် transport security ဖြင့် ကာကွယ်ပါ။
  • configuration file များနှင့် service credential များကို ကန့်သတ်ထားသော file permission များဖြင့် ကာကွယ်ပါ။ secret များကို command line၊ process listing သို့မဟုတ် shell history တွင် မထည့်ပါနှင့်။
  • အရဲစွန့်မှုပုံစံက လွတ်လပ်တဲ့ ထိန်းချုပ်မှုကို တောင်းဆိုတဲ့အခါ validator၊ client၊ monitoring နဲ့ backup တာဝန်တွေကို သီးခြားလုပ်ပါ။
  • ယုံကြည်စိတ်ချရတဲ့ အရင်းအမြစ်တွေကနေ အချိန်ကို နှိုင်းယှဉ်ပါ။ စုံစမ်းနိုင်ဖို့ စနစ်၊ ဝန်ဆောင်မှုနဲ့ ကွန်ရက်မှတ်တမ်းတွေ လုံလောက်စွာ ထိန်းသိမ်းပါ။

လုံခြုံသော Browser နှင့် Admin Workflows များ

Web interface ကိုသုံးတဲ့ operator အတွက်:

  • စီမံထားသော workstation ပေါ်တွင် လက်ရှိ vendor က ထောက်ပံ့ထားပြီး အပြည့်အဝ update လုပ်ထားသော browser ကို အသုံးပြုပါ။
  • လိုအပ်တဲ့ ဖြန့်ချိချက်တွေသာပါတဲ့ သီးသန့် operator profile (သို့) device ကိုသုံးပါ။
  • လျှောက်လွှာကို အတည်ပြုမပေးခင် မူလနေရာနဲ့ လက်မှတ်ကို စစ်ဆေးပါ။
  • lookalike domain များ၊ မမျှော်လင့်ထားသော redirect များနှင့် raw private-key material တောင်းဆိုမှုများကို incident အဖြစ် သတ်မှတ်ပါ။
  • Active operator session ကနေ ဆက်စပ်မှုမရှိတဲ့ site တွေနဲ့ extension တွေကို ပိတ်ထားပါ။
  • ခဏကြာတဲ့ အစည်းအဝေးတွေကို သုံးပါ။ အခွင့်ထူးခံ လုပ်ဆောင်ချက်တွေအတွက် ပြန်လည် စစ်ဆေးဖို့ လိုအပ်တယ်။
  • signer အား transaction အသေးစိတ်ကို ပြပါ။ operator သည် အတည်ပြုခြင်းမပြုမီ authority၊ network၊ instruction၊ asset နှင့် fee များကို စစ်ဆေးနိုင်ရမည်။

Browser isolation က exposure ကို လျှော့ချပေးပါတယ်။ Operator တွေက Transaction တွေကို ပြန်လည်စစ်ဆေးပြီး Secure Signing ကို အသုံးပြုဖို့လိုတယ်။

စောင့်ကြည့်ပြီး တုံ့ပြန်ခြင်း

ဒီအချက်ပြမှုတွေကို စောင့်ကြည့်ပါ။

  • validator နှင့် peer membership ပြောင်းလဲခြင်းများ
  • အထပ်ထပ် ခွင့်ပြုချက် ကျရှုံးမှု (သို့) ပုံမှန်မဟုတ်သော အခွင့်ထူးခံ ညွှန်ကြားချက်များ
  • မမျှော်လင့်တဲ့ ဆော့ဝဲ၊ ဖွဲ့စည်းပုံ (သို့) လမ်းကြောင်း ပြောင်းလဲမှု
  • လက်မှတ်ရေးထိုးခြင်း၊ မေးမြန်းခြင်းနှင့် ငွေချေးမှု ကျရှုံးမှုများ ပုံမှန်အခြေခံကိန်းအပြင်
  • ရင်းမြစ်ကုန်ဆုံးခြင်း၊ သဘောတူညီမှု ရပ်တန့်ခြင်း (သို့) မျှော်မှန်းထားသော အဖော်များ ဆုံးရှုံးခြင်း
  • ငွေလှည့်စားမှု စည်းမျဉ်းတွေနဲ့ ကိုက်ညီတဲ့ အရင်းအမြစ်၊ ခွင့်ပြုချက်နဲ့ အကောင့် ပြောင်းလဲမှု

သတင်းအချက်အလက်များကို သက်ရောက်မှုရှိသည့် အိမ်ရှင်ထံမှ လွတ်လပ်သော ချန်နယ်သို့ ပို့ပါ။ သက်ဆိုင်ရာမှတ်တမ်းများ၊ ဖွဲ့စည်းပုံ snapshots များ၊ စာရင်းအင်းဖြစ်ရပ်များနှင့် ငွေလဲလှယ်မှု hash များကို အချိန်တံဆိပ်ဖြင့် ထိန်းသိမ်းပါ။ Fraud Monitoring နှင့် Performance and Metrics ကိုကြည့်ရှု။

ပြန်လည်ထူထောင်ရေး အစီအစဉ်

ထုတ်လုပ်မှုကို မစတင်ခင် ပြန်လည်ထူထောင်ရေး အစီအစဉ်ကို ပြင်ဆင်ပါ။ ပြန်လည်ထူထပ်ရေး အစီအစဉ်မှာ

  • အဖြစ်အပျက်ကို ကြေညာပြီး ညှိနှိုင်းနိုင်သူ
  • အတည်ပြုသူများ၊ အခြေခံအဆောက်အအုံစီမံခန့်ခွဲသူများ၊ အက်ပ်ပိုင်ရှင်များနှင့် သက်ရောက်သော အသုံးပြုသူများနှင့် ဆက်သွယ်ရန် နည်းလမ်းများ
  • ဘယ်အာဏာပိုင်တွေက ခွင့်ပြုချက်တွေကို ပယ်ဖျက်နိုင်တယ်၊ သော့တွေ အစားထိုးနိုင်တယ်၊ (သို့) တူညီတဲ့ အဖွဲ့ဝင် အရေအတွက်ကို ပြောင်းနိုင်ပါတယ်။
  • ယုံကြည်ရတဲ့ ဘိုင်နရီများ၊ ဖွဲ့စည်းပုံများ၊ ဇီ၀ဖြစ်စဉ် မှတ်တမ်းများ၊ Backup များနှင့် Key Inventories တို့ကို သိမ်းဆည်းထားသည်။
  • ပြန်လည်ထူထောင်ပြီးနောက်ကွန်ရက်နဲ့ မှီခိုတဲ့ အက်ပ်တွေကို ဘယ်လို validate လုပ်ရမလဲ

မတော်တဆမှုတစ်ခုဖြစ်တဲ့အခါ

  1. ထိခိုက်ခံရတဲ့ အိမ်ရှင်၊ ခွင့်ပြုချက်၊ လမ်းကြောင်း (သို့) အာဏာကို သီးသန့်ထားပါ။ အထောက်အထားတွေကို သိမ်းထားပါ။
  2. log များနှင့် ledger reference များကို ထိန်းသိမ်းပါ။ recovery action တစ်ခုချင်းစီကို မှတ်တမ်းတင်ပါ။
  3. အသိအမှတ်ပြုသော အုပ်ချုပ်ရေးလုပ်ငန်းစဉ်မှတစ်ဆင့် ဖွင့်ဟထားသည့် ခွင့်ပြုချက်များနှင့် ခွင့်ပြုချက်ကို ပယ်ဖျက်ခြင်း သို့မဟုတ် အစားထိုးခြင်း။
  4. စစ်ဆေးထားတဲ့ လက်ရာတွေကနေ ဆော့ဖ်ဝဲနဲ့ ဖွဲ့စည်းမှုကို ပြန်လည်ထူထောင်ပါ။
  5. peer membership၊ consensus health၊ public route များ၊ monitoring နှင့် application read များကို အတည်ပြုပါ။ ဒီစစ်ဆေးမှုအားလုံး အောင်မြင်ပြီးမှသာ network write operation များကို ပြန်လည်စတင်ပါ။
  6. အဓိက အကြောင်းရင်းကို မှတ်တမ်းတင်ပါ။ ထိန်းချုပ်မှုတွေ၊ အလိုအလျောက်လုပ်ခြင်းနဲ့ လေ့ကျင့်ခန်းတွေကို မွမ်းမံလိုက်ပါ။

WARNING

နောက်ပြန်မပြောင်းနိုင်သော ledger action များအတွက် ကြိုတင် review လုပ်ထားသော လုပ်ငန်းစဉ်များကို လိုက်နာပါ။ သက်ရောက်သော authority နှင့် asset များအတွက် သင့်လျော်သော approval များကို တောင်းဆိုပါ။