ପାସୱାର୍ଡକୁ ସୁରକ୍ଷା ଦେବା କାହିଁକି, ଯଦି ତାହାକୁ ବ୍ୟବହାର ନ କରିହେବ?

ଯେଉଁ ସମସ୍ୟାକୁ ଆମେ ସ୍ୱାଭାବିକ ବୋଲି ଧରିନେଇଛୁ

ପ୍ରାୟ ପ୍ରତ୍ୟେକ ୱେବ୍ ଆପ୍ଲିକେସନ୍‌ରେ ଏକ ପ୍ରଶାସନିକ ପ୍ୟାନେଲ୍ ଥାଏ। ଆଉ ପ୍ରଶାସନିକ ପ୍ୟାନେଲ୍‌ରେ ସାଧାରଣତଃ ପ୍ରବେଶ ଠିକଣା, ଅଥେଣ୍ଟିକେସନ୍ ଫର୍ମ, ଲଗଇନ୍ ଏବଂ ପାସୱାର୍ଡ ଥାଏ।

ଆମେ ଏହି ବ୍ୟବସ୍ଥାରେ ଏତେ ଅଭ୍ୟସ୍ତ ହୋଇଯାଇଛୁ ଯେ ପ୍ରାୟ ଏହି ପ୍ରଶ୍ନ ପଚାରିବା ବନ୍ଦ କରିଦେଇଛୁ: ସବୁକିଛି ଠିକ୍ ଏହିପରି ହିଁ କାମ କରିବା ଆବଶ୍ୟକ କି?

ତୁମର ଯଦି ଗୋଟିଏ ୱେବ୍‌ସାଇଟ୍ ଥାଏ, ତେବେ ସମସ୍ୟାଟି ବିଶେଷ ଗମ୍ଭୀର ଲାଗେନାହିଁ। ଏକ ଜଟିଳ ପାସୱାର୍ଡ ତିଆରି କର, ଦୁଇ-ସ୍ତରୀୟ ଅଥେଣ୍ଟିକେସନ୍ ଚାଲୁ କର, ଲଗଇନ୍ ଚେଷ୍ଟାର ସୀମା ଧାର୍ଯ୍ୟ କର—ତା’ପରେ କାମ କର।

କିନ୍ତୁ ପ୍ରୋଜେକ୍ଟ ସଂଖ୍ୟା ଦଶ, କୋଡ଼ିଏ କିମ୍ବା ତିରିଶି ହେଲେ କ’ଣ ହୁଏ?

ମୋ କ୍ଷେତ୍ରରେ, ଏହା DigiMeld ଇକୋସିଷ୍ଟମ୍ ସମ୍ବନ୍ଧୀୟ, ଯାହା ତିରିଶରୁ ଅଧିକ ସ୍ୱତନ୍ତ୍ର ସଫ୍ଟୱେର୍ ପ୍ରୋଜେକ୍ଟକୁ ଏକାଠି କରେ। ପ୍ରତ୍ୟେକର ନିଜସ୍ୱ ଆର୍କିଟେକ୍ଚର୍, ସର୍ଭର ଲଜିକ୍ ଏବଂ ପ୍ରଶାସନିକ ଇଣ୍ଟରଫେସ୍ ଅଛି।

ତେଣୁ ପ୍ରତ୍ୟେକଟିକୁ ପ୍ରଶାସନିକ ପ୍ରବେଶ ପାଇଁ ଏକ ବ୍ୟବସ୍ଥା ଦରକାର।

ଦୀର୍ଘ ସମୟ ଧରି ମୁଁ ଏକ ସାଧାରଣ ପଦ୍ଧତି ବ୍ୟବହାର କରୁଥିଲି: ଅଲଗା ପ୍ରଶାସନିକ ଆକାଉଣ୍ଟ୍ ବିବରଣୀ, ଜଟିଳ ପାସୱାର୍ଡ ଏବଂ ସେଗୁଡ଼ିକୁ ବ୍ରାଉଜର୍‌ରେ ସଞ୍ଚୟ କରିବା।

ଏହା କାମ କରୁଥିଲା।

କିନ୍ତୁ ଗୋଟିଏ ସମୟରେ ମୁଁ ଭାବିଲି: ମୋତେ ଏତେଗୁଡ଼ିଏ ପ୍ରଶାସନିକ ପାସୱାର୍ଡ ସଞ୍ଚୟ କରିବାକୁ କାହିଁକି ପଡ଼ିବ? ମୋତେ କେବଳ ସର୍ଭରଗୁଡ଼ିକୁ ନୁହେଁ, ସେଗୁଡ଼ିକରେ ପ୍ରବେଶ ପାଇବାର ଉପାୟଗୁଡ଼ିକୁ ମଧ୍ୟ କାହିଁକି ସୁରକ୍ଷା ଦେବାକୁ ପଡ଼ିବ?

ଏହି ଆବଶ୍ୟକତାକୁ ଏଡ଼ାଇବା ସମ୍ଭବ ନୁହେଁ କି?

ଜଟିଳ ପାସୱାର୍ଡ ମୂଳ ସମସ୍ୟାକୁ ଦୂର କରେନାହିଁ

ଆଧୁନିକ ଉପକରଣଗୁଡ଼ିକ ଅତ୍ୟଧିକ ଏଣ୍ଟ୍ରୋପି ଥିବା ପାସୱାର୍ଡ ତିଆରି କରିବାକୁ ଦିଏ। ଠିକ୍ ଭାବେ ତିଆରି ହୋଇଥିବା ଲମ୍ବା, ଅନିୟମିତ ପାସୱାର୍ଡକୁ ସମସ୍ତ ସମ୍ଭାବନା ଗୋଟିଏ ପରେ ଗୋଟିଏ ଚେଷ୍ଟା କରି ଖୋଜିବା ପ୍ରାୟ ଅସମ୍ଭବ।

କିନ୍ତୁ ପାସୱାର୍ଡ ଯେତେ ଜଟିଳ ହେଉନା କାହିଁକି, ତାହାକୁ କେଉଁଠି ନା କେଉଁଠି ସଞ୍ଚୟ କରିବାକୁ ହୁଏ ଏବଂ ପରେ ବ୍ୟବହାର କରିବାକୁ ହୁଏ।

ପାସୱାର୍ଡ ମ୍ୟାନେଜର୍, ହାର୍ଡୱେର୍ କି, ବହୁ-ସ୍ତରୀୟ ଅଥେଣ୍ଟିକେସନ୍ ଏବଂ ଅତିରିକ୍ତ ସୀମାବଦ୍ଧତା ବ୍ୟବହାର କରିହେବ। ଏସବୁ ନିଶ୍ଚିତ ଭାବେ ସୁରକ୍ଷା ବଢ଼ାଏ।

ତଥାପି ଆର୍କିଟେକ୍ଚର୍‌ର ମୂଳ ଗଠନ ରହିଯାଏ: ଏକ ନିର୍ଦ୍ଦିଷ୍ଟ ଇଣ୍ଟରଫେସ୍ ଥାଏ, ଯାହା ମାଧ୍ୟମରେ ଉପଯୋଗକର୍ତ୍ତା ନିଜ ଆକାଉଣ୍ଟ୍ ବିବରଣୀ ଦାଖଲ କରନ୍ତି।

ସେଠାକୁ ଅନୁରୋଧ ପଠାଯାଇପାରେ। ତାହାକୁ ସ୍କାନ୍ କରାଯାଇପାରେ। ଏହା ସ୍ୱୟଂଚାଳିତ ଆକ୍ରମଣର ଲକ୍ଷ୍ୟ ହୋଇପାରେ।

ପ୍ରଶାସନିକ ପ୍ୟାନେଲ୍‌ର ଠିକଣା ଲୁଚାଇହେବ, ସାଧାରଣ ପଥକୁ ଅକ୍ଷରର ଏକ ଲମ୍ବା ଅନିୟମିତ ଧାରାରେ ବଦଳାଇହେବ କିମ୍ବା IP ଆଧାରରେ ପ୍ରବେଶ ସୀମିତ କରାଯାଇପାରେ।

କିନ୍ତୁ ତା’ପରେ ଆଉ ଏକ ପ୍ରଶ୍ନ ଆସେ: ଏହି ଠିକଣାକୁ କେଉଁଠି ସଞ୍ଚୟ କରିବା ଏବଂ କିପରି ବ୍ୟବହାର କରିବା?

ଆଉ ସବୁଠାରୁ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ କଥା—ପ୍ରଶାସନିକ ପ୍ରବେଶ କେବଳ ନିର୍ଦ୍ଦିଷ୍ଟ ସମୟରେ ଦରକାର ହେଉଥିବାବେଳେ, ଏକ ସ୍ଥାୟୀ ପ୍ରବେଶ ପଥ କାହିଁକି ରଖିବା?

ମୁଁ ଏପରି ଏକ ଧାରଣାରେ ପହଞ୍ଚିଲି, ଯାହା ପରେ ମୋ ସମାଧାନର ମୂଳ ହେଲା:

ହୁଏତ ଏକ ସ୍ଥାୟୀ ପ୍ରବେଶ ପଥକୁ ସୁରକ୍ଷା ଦେବା ବଦଳରେ, ସାମୟିକ ଭାବେ ପ୍ରବେଶ ପାଇବାର ଅଧିକାରକୁ ସୁରକ୍ଷା ଦେବା ଉଚିତ।

ଯଦି ପ୍ରଚଳିତ ଲଗଇନ୍ ପୃଷ୍ଠା ଆଦୌ ନଥାଏ ତେବେ?

ମୁଁ ମୋ ପ୍ରୋଜେକ୍ଟଗୁଡ଼ିକରେ ପାରମ୍ପରିକ ପ୍ରଶାସନିକ ଅଥେଣ୍ଟିକେସନ୍ ମଡେଲ୍‌କୁ ଛାଡ଼ିବାକୁ ନିଷ୍ପତ୍ତି ନେଲି।

କେବଳ ଲଗଇନ୍ ଫର୍ମକୁ ଲୁଚାଇବା ନୁହେଁ।

ଠିକଣାର ନାମ ବଦଳାଇବା ନୁହେଁ।

ପାସୱାର୍ଡ ବଦଳରେ ଆହୁରି ଜଟିଳ ପାସୱାର୍ଡ ରଖିବା ନୁହେଁ।

ବରଂ ସବୁବେଳେ ଉପଲବ୍ଧ ପାସୱାର୍ଡ ଆଧାରିତ ଲଗଇନ୍‌ର ଆବଶ୍ୟକତାକୁ ହଟାଇବା।

ନିଶ୍ଚୟ, ପ୍ରଶାସନିକ ଇଣ୍ଟରଫେସ୍‌ଗୁଡ଼ିକ ଉଭାନ ହୋଇନାହିଁ। ଆପ୍ଲିକେସନ୍‌ଗୁଡ଼ିକୁ ପରିଚାଳନା କରିବା ପାଇଁ ସେଗୁଡ଼ିକ ଏବେ ମଧ୍ୟ ଆବଶ୍ୟକ।

ସେଗୁଡ଼ିକରେ ପ୍ରବେଶ ପାଇବାର ପଦ୍ଧତି ବଦଳିଛି।

ଏବେ ସଂଯୁକ୍ତ ପ୍ରୋଜେକ୍ଟଗୁଡ଼ିକର ପ୍ରଶାସନିକ ପ୍ୟାନେଲ୍‌ରେ ପ୍ରବେଶ କରିବା ପାଇଁ ସଞ୍ଚୟ ହୋଇଥିବା ଲଗଇନ୍ ଏବଂ ପାସୱାର୍ଡ ଦେବା ଦରକାର ନାହିଁ।

ଏହା ବଦଳରେ ମୁଁ ନିଜର MeldID ପରିଚୟ ଏବଂ ପ୍ରବେଶ ପରିଚାଳନା ପ୍ରଣାଳୀ ବ୍ୟବହାର କରେ।

ଏହାର ଉଦ୍ଦେଶ୍ୟ ସରଳ: ପ୍ରଶାସନିକ ପ୍ରବେଶ କେବଳ ସେତେବେଳେ ଦିଆଯାଏ, ଯେତେବେଳେ ତାହା ସତରେ ଆବଶ୍ୟକ—ନିର୍ଦ୍ଦିଷ୍ଟ ଉପଯୋଗକର୍ତ୍ତାଙ୍କୁ, ନିର୍ଦ୍ଦିଷ୍ଟ ପ୍ରୋଜେକ୍ଟ ପାଇଁ।

ଏବଂ କେବଳ ଏକ ଆକାଉଣ୍ଟ୍ ଥିବାରୁ ପ୍ରଶାସନିକ ପ୍ୟାନେଲ୍ ଖୋଲିବାର ଅଧିକାର ମିଳେନାହିଁ।

ସେହି ଅଧିକାର ଅଲଗା ଭାବେ ଦେବାକୁ ପଡ଼େ।

ଏମିତି ପ୍ରବେଶ, ଯାହା ଗୋଟିଏ ମିନିଟ୍ ପୂର୍ବରୁ ନଥିଲା

ବୋଧହୁଏ ଏହା ହିଁ ସମଗ୍ର ଧାରଣାର ସବୁଠାରୁ ଆକର୍ଷଣୀୟ ଅଂଶ।

ପାରମ୍ପରିକ ମଡେଲ୍‌ରେ ପ୍ରଶାସକଙ୍କ ପାଖରେ ସବୁବେଳେ ଲଗଇନ୍ କରିବାର ସାଧନ ଥାଏ। ସେଗୁଡ଼ିକ ବୈଧ ରହିଥିବା ପର୍ଯ୍ୟନ୍ତ ସେ ଆଜି, କାଲି କିମ୍ବା ମାସେ ପରେ ବ୍ୟବହାର କରିପାରନ୍ତି।

ମୁଁ ଏହି ନୀତିକୁ ବଦଳାଇବାକୁ ନିଷ୍ପତ୍ତି ନେଲି।

ସ୍ଥାୟୀ ପ୍ରଶାସନିକ ଆକାଉଣ୍ଟ୍ ବିବରଣୀ ବଦଳରେ, ଲଗଇନ୍ ଆରମ୍ଭ କରିବାର ଏକ ସାମୟିକ ସୁଯୋଗ ବ୍ୟବହାର କରାଯାଏ।

ଏହା ଏକ ବିଶ୍ୱସ୍ତ ମୋବାଇଲ୍ ଉପକରଣ ମାଧ୍ୟମରେ ଅନୁରୋଧ କରି ତିଆରି କରାଯାଏ, ଏଥିରେ କ୍ରିପ୍ଟୋଗ୍ରାଫିକ୍ ଭାବେ ଦୃଢ଼ ଅନିୟମିତ ଉପାଦାନ ଥାଏ ଏବଂ ଏହାର ବୈଧତା ଅବଧି ସୀମିତ।

କିନ୍ତୁ ଏପରି ସାମୟିକ ଲିଙ୍କ୍ ଥିବାରୁ ମାତ୍ର ପ୍ରବେଶ ମିଳିଯାଏ ନାହିଁ।

ଏହା ଏକ ମୌଳିକ କଥା।

ଧର, କେହି କୌଣସି ଉପାୟରେ ଏହି ଲିଙ୍କ୍ ପାଇଗଲେ। କେବଳ ଠିକଣା ଗୋପନ ରଖିବା ଉପରେ ନିର୍ଭର କରୁଥିବା ସାଧାରଣ ସିଷ୍ଟମ୍‌ରେ, ଏପରି ଲିଙ୍କ୍ ଫାଶ ହେବା ଗମ୍ଭୀର ସମସ୍ୟା ହୋଇପାରେ।

ମୋ ମଡେଲ୍‌ରେ, ଏହି ଲିଙ୍କ୍ କେବଳ ନିଶ୍ଚିତକରଣ ପ୍ରକ୍ରିୟା ଆରମ୍ଭ କରିବାକୁ ଦିଏ।

ଆଗକୁ ବଢ଼ିବା ପାଇଁ MeldIDର ଏକ ବିଶ୍ୱସ୍ତ ମୋବାଇଲ୍ ଉପକରଣ ମାଧ୍ୟମରେ ଅଲଗା ଅନୁମତି ଆବଶ୍ୟକ।

ଉପଯୁକ୍ତ ନିଶ୍ଚିତକରଣ ବିନା ପ୍ରଶାସନିକ ସେସନ୍ ତିଆରି ହୁଏନାହିଁ।

ଏହି କାରଣରୁ ମୁଁ ସାମୟିକ ଲିଙ୍କ୍‌କୁ ପାସୱାର୍ଡର ବିକଳ୍ପ ଭାବେ ନୁହେଁ, ବରଂ ପ୍ରବେଶ ଦେବା ପ୍ରକ୍ରିୟାର ଏକ ଅଂଶ ଭାବେ ଦେଖେ।

କେଉଁଠି ଯିବାକୁ ହେବ ଜାଣିବା ଏବଂ ପ୍ରବେଶ କରିବାର ଅଧିକାର ଥିବା—ଏ ଦୁଇଟି ସମ୍ପୂର୍ଣ୍ଣ ଭିନ୍ନ କଥା।

ଫୋନ୍ ପ୍ରବେଶ ପରିଚାଳନାର ଉପକରଣ ହୋଇଯାଏ

ଏହି ମଡେଲ୍‌ରେ, ମୋବାଇଲ୍ ଉପକରଣର ଭୂମିକା ସାଧାରଣ ଏକକ-ବ୍ୟବହାର କୋଡ୍ ଜେନେରେଟର୍‌ଠାରୁ ଯଥେଷ୍ଟ ଅଧିକ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ।

ପ୍ରଶାସନିକ ପ୍ରବେଶ ସହିତ ଜଡ଼ିତ କାର୍ଯ୍ୟଗୁଡ଼ିକୁ ନିଶ୍ଚିତ କରିବା ପାଇଁ ଏହା ବ୍ୟବହୃତ ହୁଏ।

ମୁଁ ପ୍ରଶାସନିକ ପ୍ୟାନେଲ୍ ଖୋଲିବାକୁ ଚାହିଁଲେ, ସିଷ୍ଟମ୍ MeldID ମାଧ୍ୟମରେ ନିଶ୍ଚିତକରଣ ମାଗେ।

ମୁଁ ବିଶ୍ୱସ୍ତ ଉପକରଣରେ ସମ୍ପୃକ୍ତ ଅନୁରୋଧ ଦେଖେ ଏବଂ କାର୍ଯ୍ୟଟିକୁ ନିଶ୍ଚିତ କରେ।

ସଫଳ ଯାଞ୍ଚ ପରେ ହିଁ ସିଷ୍ଟମ୍ ଲଗଇନ୍ ପ୍ରକ୍ରିୟା ଜାରି ରଖିବାକୁ ଅନୁମତି ଦିଏ।

ଏହି ନିଶ୍ଚିତକରଣ ଏକ ନିର୍ଦ୍ଦିଷ୍ଟ କାର୍ଯ୍ୟ ସହିତ ଜଡ଼ିତ, କେବଳ ଫୋନ୍‌ଟି ଅନଲକ୍ ହୋଇଥିବା ସହିତ ନୁହେଁ।

ମୋବାଇଲ୍ ବାୟୋମେଟ୍ରିକ୍ସ ଉପକରଣରେ ଉପଯୋଗକର୍ତ୍ତାଙ୍କୁ ସ୍ଥାନୀୟ ଭାବେ ଯାଞ୍ଚ କରେ, ଏବଂ ସର୍ଭର ପକ୍ଷରେ ପଞ୍ଜିକୃତ ଉପକରଣର କ୍ରିପ୍ଟୋଗ୍ରାଫିକ୍ ନିଶ୍ଚିତକରଣ ଯାଞ୍ଚ ହୁଏ।

ଏହି ପଦ୍ଧତି ଦ୍ୱାରା କେବଳ ପାସୱାର୍ଡ କିମ୍ବା ଉପଯୋଗକର୍ତ୍ତା ଲଗଇନ୍ ନିଶ୍ଚିତ କରିଛନ୍ତି ବୋଲି କୁହାଯାଉଥିବା ସନ୍ଦେଶ ଉପରେ ନିର୍ଭର କରିବାକୁ ପଡ଼େନାହିଁ।

ଏଠାରେ ଆଉ ଏକ ସୁବିଧା ମିଳେ: ବିଶ୍ୱସ୍ତ ଉପକରଣଗୁଡ଼ିକୁ ପରିଚାଳନା କରିହେବ।

କୌଣସି ଉପକରଣକୁ ଆଉ ପ୍ରବେଶ ନିଶ୍ଚିତ କରିବା ପାଇଁ ବ୍ୟବହାର କରିବା ଉଚିତ ନହେଲେ, ତାହାର ବିଶ୍ୱସ୍ତ ସ୍ଥିତିକୁ ପ୍ରତ୍ୟାହାର କରିହେବ।

ଏହା ପରେ, ସମ୍ପୃକ୍ତ କାର୍ଯ୍ୟଗୁଡ଼ିକୁ ଅଥେଣ୍ଟିକେଟ୍ କରିବାର ଏକ ବୈଧ ସାଧନ ଭାବେ ଏହା ଆଉ କାମ କରିବ ନାହିଁ।

ଗୋଟିଏ ସିଷ୍ଟମ୍—ଅନେକ ସ୍ୱତନ୍ତ୍ର ପ୍ରୋଜେକ୍ଟ

ମୁଁ ଏହି ବ୍ୟବସ୍ଥା ବିକାଶ କରିବା ଆରମ୍ଭ କଲାବେଳେ, ପ୍ରତ୍ୟେକ ପ୍ରୋଜେକ୍ଟର ସ୍ୱତନ୍ତ୍ରତା ବଜାୟ ରଖିବା ମୁଖ୍ୟ କାର୍ଯ୍ୟଗୁଡ଼ିକ ମଧ୍ୟରୁ ଗୋଟିଏ ଥିଲା।

ମୁଁ ସମସ୍ତ ପ୍ରଶାସନିକ ପ୍ୟାନେଲ୍‌କୁ ଗୋଟିଏ ବିଶାଳ ଆପ୍ଲିକେସନ୍‌ରେ ମିଶାଇବାକୁ ଚାହୁଁନଥିଲି।

ପ୍ରତ୍ୟେକ DigiMeld ସେବା ନିଜର ଲଜିକ୍, ସେଟିଂସ୍, ଉପଯୋଗକର୍ତ୍ତା ଏବଂ ତଥ୍ୟକୁ ନିଜେ ପରିଚାଳନା କରିବା ଜାରି ରଖିବା ଉଚିତ।

ତେଣୁ ମୁଁ ଦୁଇଟି କାର୍ଯ୍ୟକୁ ଅଲଗା କଲି।

MeldID ପରିଚୟ ନିର୍ଦ୍ଧାରଣ ଏବଂ ପ୍ରଶାସନିକ ପ୍ରବେଶ ଅନୁମତି ଦେବାର ଦାୟିତ୍ୱ ନିଏ।

ପ୍ରୋଜେକ୍ଟ ନିଜର ପ୍ରଶାସନିକ କାର୍ଯ୍ୟ ଏବଂ ବର୍ତ୍ତମାନ ବୈଧ ଅଧିକାରର ଯାଞ୍ଚ ଦାୟିତ୍ୱ ନିଏ।

ଏହା ଫଳରେ ଆପ୍ଲିକେସନ୍‌ଗୁଡ଼ିକୁ କେନ୍ଦ୍ରୀକୃତ କରିବାର ଆବଶ୍ୟକତା ବିନା, ପ୍ରବେଶ ପରିଚାଳନା ପାଇଁ ଏକ କେନ୍ଦ୍ରୀକୃତ ମଡେଲ୍ ତିଆରି ହେଲା।

ଏହା ସହିତ, ଅଧିକାରଗୁଡ଼ିକୁ ଅଲଗା ଭାବେ ଦିଆଯାଏ।

କେବଳ MeldID ଆକାଉଣ୍ଟ୍ ଥିବାରୁ ଗୋଟିଏ ପ୍ରୋଜେକ୍ଟର ପ୍ରଶାସକ ଅନ୍ୟ ପ୍ରୋଜେକ୍ଟଗୁଡ଼ିକରେ ସ୍ୱତଃସ୍ଫୂର୍ତ୍ତ ଭାବେ ପ୍ରବେଶ ପାଆନ୍ତି ନାହିଁ।

ପ୍ରତ୍ୟେକ ପ୍ରଶାସନିକ କ୍ଷେତ୍ର ପାଇଁ ଅନୁମତିପ୍ରାପ୍ତ ଉପଯୋଗକର୍ତ୍ତାଙ୍କ ନିଜସ୍ୱ ଗୋଷ୍ଠୀ ଧାର୍ଯ୍ୟ କରିହେବ।

ଏହି ସମୟରେ, ସାଧାରଣ ଉପଯୋଗକର୍ତ୍ତାଙ୍କ ଅଧିକାର ଏବଂ ପ୍ରଶାସନିକ କ୍ଷମତା ଅଲଗା ରହେ।

ଦଶ ଦଶଟି ସେବା ଥିବା ଏକ ଇକୋସିଷ୍ଟମ୍ ପାଇଁ ଏହା ବିଶେଷ ଉପଯୋଗୀ ହେଲା।

ସ୍ଥାୟୀ ପ୍ରବେଶ ଅପେକ୍ଷା ସାମୟିକ ପ୍ରବେଶ ମୋତେ କାହିଁକି ଅଧିକ ପସନ୍ଦ

ଆଉ ଗୋଟିଏ ନୀତି ଅଛି, ଯାହାକୁ ମୁଁ ଜାଣିଶୁଣି ସିଷ୍ଟମ୍‌ରେ ରଖିଛି।

ପ୍ରଶାସନିକ ପ୍ରବେଶ ଅନିର୍ଦ୍ଦିଷ୍ଟ କାଳ ପର୍ଯ୍ୟନ୍ତ ରହିବା ଉଚିତ ନୁହେଁ।

ଅନୁମତି ସୀମିତ ସମୟ ପର୍ଯ୍ୟନ୍ତ ରହେ ଏବଂ ଉପଯୋଗକର୍ତ୍ତା ବ୍ରାଉଜର୍‌ରେ କାମ ଜାରି ରଖିଛନ୍ତି କି ନାହିଁ, ତାହା ନିର୍ବିଶେଷରେ ସମାପ୍ତ ହୋଇଯାଏ।

ସମୟସୀମା ଶେଷ ହେବା ପରେ କାମ ଜାରି ରଖିବାକୁ ନୂଆ ନିଶ୍ଚିତକରଣ ପ୍ରକ୍ରିୟା ଦରକାର।

ଏହା ଦ୍ୱାରା ଥରେ ହୋଇଥିବା ଅଥେଣ୍ଟିକେସନ୍‌କୁ ସବୁବେଳେ ବୈଧ ରହୁଥିବା ଅଧିକାରରେ ପରିଣତ ହେବାରୁ ରୋକାଯାଏ।

କିନ୍ତୁ କେବଳ ସମୟସୀମା ଯଥେଷ୍ଟ ନୁହେଁ।

ପୂର୍ବରୁ ଦିଆଯାଇଥିବା ପ୍ରବେଶକୁ ଅବଧି ପୂର୍ବରୁ ବନ୍ଦ କରିବାର ସୁଯୋଗ ମଧ୍ୟ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ।

ତେଣୁ MeldIDରେ ପ୍ରଶାସନିକ ଅନୁମତିକୁ କେନ୍ଦ୍ରୀୟ ଭାବେ ପ୍ରତ୍ୟାହାର କରିବାର ବ୍ୟବସ୍ଥା ରହିଛି।

ଅନୁମତି ପ୍ରତ୍ୟାହାର ହେଲେ, ସଂଯୁକ୍ତ ପ୍ରୋଜେକ୍ଟଗୁଡ଼ିକ ସମ୍ପୃକ୍ତ ଇଭେଣ୍ଟ୍ ପାଆନ୍ତି ଏବଂ ସେହି ଅନୁମତି ସହ ଜଡ଼ିତ ପ୍ରଶାସନିକ ସେସନ୍‌ଗୁଡ଼ିକୁ ଅବୈଧ କରନ୍ତି।

ଏହିପରି ଭାବେ, ଉପଯୋଗକର୍ତ୍ତା ସଫଳତାର ସହ ଲଗଇନ୍ କରିବା ମାତ୍ରେ ପ୍ରବେଶ ପରିଚାଳନା ଶେଷ ହୋଇଯାଏନାହିଁ।

ଅଧିକାର ଦେବାର ସୁଯୋଗ ଯେତିକି ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ, ମୋ ପାଇଁ ସେଗୁଡ଼ିକୁ ପ୍ରତ୍ୟାହାର କରିବାର ସୁଯୋଗ ମଧ୍ୟ ସେତିକି ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ।

ଏହି ସମୟରେ, ଏକ ବିତରିତ ସିଷ୍ଟମ୍‌କୁ ଇଭେଣ୍ଟ୍ ପହଞ୍ଚିବାରେ ବିଳମ୍ବ, କିଛି ଉପାଦାନ ସାମୟିକ ଭାବେ ଅନୁପଲବ୍ଧ ହେବା ଏବଂ ଅନ୍ୟାନ୍ୟ ପରିଚାଳନାଗତ ପରିସ୍ଥିତିକୁ ଧ୍ୟାନରେ ରଖିବାକୁ ପଡ଼େ। ସେସନ୍‌ର ବୈଧତା ଅବଧି ସୀମିତ ରଖିବା ଏକ ଅତିରିକ୍ତ ସୁରକ୍ଷା ସୀମା ଭାବେ କାମ କରେ।

ଦୈନନ୍ଦିନ କାମରେ କ’ଣ ବଦଳିଲା?

ସର୍ବପ୍ରଥମେ, ସଞ୍ଚୟ ହୋଇଥିବା ପ୍ରଶାସନିକ ପାସୱାର୍ଡଗୁଡ଼ିକୁ ବାରମ୍ବାର ଖୋଜିବାର ଆବଶ୍ୟକତା ଦୂର ହେଲା।

ପ୍ରତ୍ୟେକ ସଂଯୁକ୍ତ ପ୍ରଶାସନିକ ପ୍ୟାନେଲ୍‌ରେ ଲଗଇନ୍ କରିବା ପାଇଁ ଆଉ ବ୍ରାଉଜର୍‌ରେ ଆକାଉଣ୍ଟ୍ ବିବରଣୀର ଏକ ସଂଗ୍ରହ ରଖିବାକୁ ପଡ଼େନାହିଁ।

ଏହା ବଦଳରେ ମୁଁ ଗୋଟିଏ କେନ୍ଦ୍ରୀୟ ବ୍ୟବସ୍ଥା ମାଧ୍ୟମରେ ଅନୁମତିଗୁଡ଼ିକୁ ପରିଚାଳନା କରେ।

ଆବଶ୍ୟକ ପ୍ରୋଜେକ୍ଟ ବାଛେ, ପ୍ରବେଶ ନିଶ୍ଚିତ କରେ ଏବଂ କାମ କରେ।

ପ୍ରଶାସନିକ ପ୍ରବେଶ ଆଉ ଆବଶ୍ୟକ ନହେଲେ, ତାହାକୁ ପ୍ରତ୍ୟାହାର କରିହେବ।

ନୂଆ ପ୍ରୋଜେକ୍ଟ ଆସିଲେ, ପ୍ରଶାସନିକ ଅଥେଣ୍ଟିକେସନ୍‌ର ସମଗ୍ର ସିଷ୍ଟମ୍‌କୁ ପୁଣିଥରେ ଡିଜାଇନ୍ କରିବାକୁ ପଡ଼େନାହିଁ—ଏହା ବିଶେଷ ଉପଯୋଗୀ।

ଏହାକୁ ଥିବା ମଡେଲ୍‌ ସହ ଯୋଡ଼ି ଆବଶ୍ୟକ ଅନୁମତିଗୁଡ଼ିକୁ ଧାର୍ଯ୍ୟ କରିଦେଲେ ଯଥେଷ୍ଟ।

ନିଶ୍ଚୟ, ଏହାର ଅର୍ଥ ନୁହେଁ ଯେ ସମସ୍ତ ସୁରକ୍ଷା ବିପଦ ଦୂର ହୋଇଗଲା।

ସାମୟିକ ଅନୁମତି, ବିଶ୍ୱସ୍ତ ଉପକରଣ, ସର୍ଭର ସେସନ୍ ଏବଂ କେନ୍ଦ୍ରୀୟ ଭିତ୍ତିଭୂମିକୁ ମଧ୍ୟ ସୁରକ୍ଷା ଦେବା ଆବଶ୍ୟକ।

କିନ୍ତୁ ପ୍ରତ୍ୟେକ ଆପ୍ଲିକେସନ୍ ପାଇଁ ଅଲଗା ଭାବେ ପ୍ରଶାସନିକ ପାସୱାର୍ଡ ପରିଚାଳନାର ସମାନ ସମସ୍ୟାକୁ ଆଉ ସମାଧାନ କରିବାକୁ ପଡ଼େନାହିଁ।

ଏହା ହିଁ ମୋର ପ୍ରାରମ୍ଭିକ ଲକ୍ଷ୍ୟଗୁଡ଼ିକ ମଧ୍ୟରୁ ଗୋଟିଏ ଥିଲା।

ଏପରି ପ୍ରଯୁକ୍ତି ଆଗରୁ ନାହିଁ କି?

ନିଶ୍ଚୟ, ଅଛି।

ପାସୱାର୍ଡବିହୀନ ଅଥେଣ୍ଟିକେସନ୍, ସୁବିଧାପ୍ରାପ୍ତ ପ୍ରବେଶ ପରିଚାଳନା, ସାମୟିକ ଅନୁମତି ଏବଂ ବିଶ୍ୱସ୍ତ ଉପକରଣ ମାଧ୍ୟମରେ ନିଶ୍ଚିତକରଣ—ଏସବୁ ସୂଚନା ସୁରକ୍ଷା ଶିଳ୍ପରେ ବହୁଦିନରୁ ଜଣାଶୁଣା।

ଏପରି ପଦ୍ଧତି Identity and Access Management, Privileged Access Management ସିଷ୍ଟମ୍ ଏବଂ Zero Trust ଧାରଣାରେ ଦେଖିବାକୁ ମିଳେ।

ଏହି ନୀତିଗୁଡ଼ିକର ଉଦ୍ଭାବକ ମୁଁ ବୋଲି ଦାବି କରୁନାହିଁ।

ମୋର ଲକ୍ଷ୍ୟ ଭିନ୍ନ ଥିଲା।

DigiMeld ଭିତ୍ତିଭୂମିର ନିର୍ଦ୍ଦିଷ୍ଟ ସମସ୍ୟାଗୁଡ଼ିକର ସମାଧାନ କରିବା ଏବଂ ଅନେକ ସ୍ୱତନ୍ତ୍ର ପ୍ରୋଜେକ୍ଟର ପ୍ରଶାସନିକ ପ୍ରବେଶ ପରିଚାଳନା କରିବାକୁ ମୋତେ ଏକ ନିଜସ୍ୱ, ସମନ୍ୱିତ ସିଷ୍ଟମ୍ ତିଆରି କରିବାକୁ ଥିଲା।

ଫଳରେ, ମୋ ଆବଶ୍ୟକତା ପୂରଣ କରୁଥିବା ଗୋଟିଏ ଆର୍କିଟେକ୍ଚର୍‌ରେ ମୁଁ ଅନେକ ଜଣାଶୁଣା ପଦ୍ଧତିକୁ ଏକାଠି କଲି।

ମୋ ମତରେ, ଇଞ୍ଜିନିୟରିଂ କାମର ମୂଲ୍ୟ ସବୁବେଳେ ସମ୍ପୂର୍ଣ୍ଣ ନୂଆ ପ୍ରଯୁକ୍ତି ଉଦ୍ଭାବନ କରିବାରେ ନଥାଏ।

କେବେ କେବେ ଏହାର ମୂଲ୍ୟ ହେଉଛି ସମସ୍ୟାଟିକୁ ଠିକ୍ ଭାବେ ଚିହ୍ନଟ କରିବା ଏବଂ ତାହାର ଉପଯୁକ୍ତ ସମାଧାନ ଖୋଜିବା।

MeldID କେବଳ ପ୍ରଶାସନିକ ପ୍ୟାନେଲ୍ ପାଇଁ ନୁହେଁ

ଏଠାରେ ଗୋଟିଏ କଥା ସ୍ପଷ୍ଟ କରିବା ଆବଶ୍ୟକ।

MeldID କେବଳ ମୋ ନିଜ ପ୍ରଶାସନିକ ପ୍ରବେଶ ପାଇଁ ତିଆରି ହୋଇନଥିଲା।

ଏହା ବିକାଶକାରୀମାନଙ୍କୁ ନିଜ ଆପ୍ଲିକେସନ୍‌ରେ ପରିଚୟ ନିର୍ଦ୍ଧାରଣ ଏବଂ ଲଗଇନ୍ ନିଶ୍ଚିତକରଣ ବ୍ୟବସ୍ଥା ସଂଯୁକ୍ତ କରିବା ପାଇଁ SDK ମଧ୍ୟ ଦିଏ।

ଏହି SDK ମାଗଣାରେ ଉପଲବ୍ଧ।

ଉଦାହରଣ ସ୍ୱରୂପ, ଜଣେ ବାହ୍ୟ ବିକାଶକାରୀ ଉପଯୋଗକର୍ତ୍ତା ଅଥେଣ୍ଟିକେସନ୍‌କୁ ନିଶ୍ଚିତ କରିବାର ଏକ ଅତିରିକ୍ତ ସ୍ତର ଭାବେ MeldID ବ୍ୟବହାର କରିପାରନ୍ତି।

ଆପ୍ଲିକେସନ୍‌ରେ ପାରମ୍ପରିକ ଲଗଇନ୍ ଏବଂ ପାସୱାର୍ଡ ଆଧାରିତ ପ୍ରବେଶ ରହିଲେ ମଧ୍ୟ, ସେହି ବିବରଣୀଗୁଡ଼ିକ ସଫଳତାର ସହ ଦାଖଲ କରିବା ଅଥେଣ୍ଟିକେସନ୍ ସମାପ୍ତ କରିବା ପାଇଁ ଯଥେଷ୍ଟ ନ ହୋଇପାରେ।

ଉପଯୋଗକର୍ତ୍ତାଙ୍କ ବିଶ୍ୱସ୍ତ ମୋବାଇଲ୍ ଉପକରଣକୁ ଏକ ଅନୁରୋଧ ପଠାଯାଏ, ଯେଉଁଠାରେ ସେ ଲଗଇନ୍ ଚେଷ୍ଟାକୁ ନିଶ୍ଚିତ କିମ୍ବା ପ୍ରତ୍ୟାଖ୍ୟାନ କରନ୍ତି।

ଏହା ଆକାଉଣ୍ଟ୍ ବିବରଣୀ ହ୍ୟାକ୍ ହୋଇଗଲେ ଅନଧିକୃତ ପ୍ରବେଶର ବିପଦ କମାଇବାରେ ସାହାଯ୍ୟ କରେ।

MeldIDର ଏହି ସର୍ବସାଧାରଣ ସୁବିଧା ଏବଂ DigiMeld ପ୍ରୋଜେକ୍ଟଗୁଡ଼ିକ ପାଇଁ ମୁଁ ବିକାଶ କରିଥିବା ପ୍ରଶାସନିକ ପ୍ରବେଶ ମଡେଲ୍‌କୁ ଅଲଗା ଭାବେ ଦେଖିବା ଜରୁରୀ।

ଉଭୟ ବିଶ୍ୱାସ ଏବଂ କାର୍ଯ୍ୟ ନିଶ୍ଚିତକରଣର ସାଧାରଣ ନୀତି ବ୍ୟବହାର କରନ୍ତି, କିନ୍ତୁ ଭିନ୍ନ ସମସ୍ୟାର ସମାଧାନ କରନ୍ତି।

ସୁରକ୍ଷାର ଅର୍ଥ କେବଳ ଥିବା ବ୍ୟବସ୍ଥାକୁ ସୁରକ୍ଷା ଦେବା ନୁହେଁ

ଏହି ସିଷ୍ଟମ୍‌ରେ କାମ କରିବା ମୋତେ ପ୍ରଚଳିତ ଅଥେଣ୍ଟିକେସନ୍ ବ୍ୟବସ୍ଥାକୁ ଏକ ଭିନ୍ନ ଦୃଷ୍ଟିରେ ଦେଖିବାକୁ ବାଧ୍ୟ କଲା।

ଆମେ ପ୍ରାୟତଃ ଐତିହାସିକ କାରଣରୁ ଥିବା ବ୍ୟବସ୍ଥାକୁ ସୁରକ୍ଷା ଦେବାକୁ ଚେଷ୍ଟା କରୁ।

ନୂଆ ଯାଞ୍ଚ, ସୀମାବଦ୍ଧତା, ଅତିରିକ୍ତ ପାସୱାର୍ଡ ଏବଂ ସୁରକ୍ଷା ସ୍ତର ଯୋଡ଼ୁ।

କେତେକ ସମୟରେ ଏହା ନିଶ୍ଚୟ ଆବଶ୍ୟକ।

କିନ୍ତୁ ବେଳେବେଳେ ଏକ ଭିନ୍ନ ପ୍ରଶ୍ନ ପଚାରିବା ଅଧିକ ଉପଯୋଗୀ:

ଯେଉଁ ବ୍ୟବସ୍ଥାକୁ ଆମେ ସୁରକ୍ଷା ଦେଉଛୁ, ତାହା ପୂର୍ବଭଳି ରହିବା ଆଦୌ ଆବଶ୍ୟକ କି?

ମୋ କ୍ଷେତ୍ରରେ ଉତ୍ତର ଥିଲା—ନା।

ମୋତେ ସବୁବେଳେ ଉପଲବ୍ଧ ପ୍ରଶାସନିକ ଲଗଇନ୍ ଫର୍ମର ଆବଶ୍ୟକତା ନଥିଲା।

ମୋତେ ଆବଶ୍ୟକ ଥିଲା, ଯେତେବେଳେ ପ୍ରଶାସନିକ ଅଧିକାର ଦରକାର ସେତେବେଳେ ତାହାକୁ ସୁରକ୍ଷିତ ଭାବେ ପାଇବାର ସୁଯୋଗ।

ଏଗୁଡ଼ିକ ଦୁଇଟି ଭିନ୍ନ କାର୍ଯ୍ୟ।

ପ୍ରଥମ କାର୍ଯ୍ୟରୁ ଦ୍ୱିତୀୟଟିକୁ ଯିବା ଫଳରେ କେବଳ ପ୍ରାଯୁକ୍ତିକ ଆର୍କିଟେକ୍ଚର୍ ନୁହେଁ, ପ୍ରୋଜେକ୍ଟଗୁଡ଼ିକ ସହ ଦୈନନ୍ଦିନ କାମ କରିବାର ପଦ୍ଧତି ମଧ୍ୟ ବଦଳିଗଲା।

ଏହା ଶେଷ ନୁହେଁ, ବାଛିଥିବା ଦିଗ

ଆଜି ଏହି ଆର୍କିଟେକ୍ଚର୍ DigiMeld ଇକୋସିଷ୍ଟମ୍‌ର ଏକ ବଡ଼ ଅଂଶରେ କାମ କରୁଛି।

ବାକି ପ୍ରୋଜେକ୍ଟଗୁଡ଼ିକୁ ଧୀରେ ଧୀରେ ନୂଆ ପ୍ରଶାସନିକ ପ୍ରବେଶ ମଡେଲ୍‌କୁ ନିଆଯାଉଛି।

ମୁଁ ପର୍ଯ୍ୟାୟକ୍ରମେ ମାଇଗ୍ରେସନ୍ କରୁଛି, ପ୍ରତ୍ୟେକ ଆପ୍ଲିକେସନ୍‌ର କାର୍ଯ୍ୟପ୍ରଣାଳୀ ଯାଞ୍ଚ କରୁଛି, ଏବଂ ପରିବର୍ତ୍ତନ ଶେଷ ହେବା ପରେ ସମଗ୍ର ସିଷ୍ଟମ୍‌ର ଅତିରିକ୍ତ ଅଡିଟ୍ କରିବାକୁ ଯୋଜନା କରୁଛି।

ଇଣ୍ଟରଫେସ୍‌ର କିଛି ଅଂଶ ଏବଂ ସେସନ୍ ପରିଚାଳନା ନିୟମ ଏବେ ମଧ୍ୟ ବଦଳିପାରେ।

କିନ୍ତୁ ମୂଳ ଧାରଣା ଏବେ ସ୍ପଷ୍ଟ ହୋଇସାରିଛି।

ନିଜର ଦଶ ଦଶଟି ପ୍ରୋଜେକ୍ଟ ପରିଚାଳନା କରିବା ପାଇଁ ମୋତେ ଲଗାତାର ଦଶ ଦଶଟି ପ୍ରଶାସନିକ ପାସୱାର୍ଡ ସଞ୍ଚୟ ଏବଂ ବ୍ୟବହାର କରିବାକୁ ପଡ଼ୁଥିବା ମଡେଲ୍‌କୁ ମୁଁ ଫେରିବାକୁ ଚାହୁଁନାହିଁ।

ଏହି ସମୟରେ, ମୋର ନିଜସ୍ୱ ସମାଧାନ ସମସ୍ତଙ୍କ ପାଇଁ ସାର୍ବଜନୀନ ଉପାୟ ବୋଲି ମୁଁ ଭାବେନାହିଁ।

ଭିନ୍ନ ସଂସ୍ଥାର ଆବଶ୍ୟକତା, ଭିତ୍ତିଭୂମି, ବିପଦ ମଡେଲ୍ ଏବଂ ପ୍ରଶାସନିକ ପଦ୍ଧତି ଭିନ୍ନ ହୋଇଥାଏ।

DigiMeld ଇକୋସିଷ୍ଟମ୍ ପାଇଁ ଯାହା ସୁବିଧାଜନକ ଏବଂ ଯଥାର୍ଥ, ତାହା ଅନ୍ୟ ଜଣେ ବିକାଶକାରୀଙ୍କ ପାଇଁ ସର୍ବୋତ୍ତମ ହେବ ବୋଲି ନିଶ୍ଚିତ ନୁହେଁ।

ତଥାପି, ଅଧିକାରକୁ ସାମୟିକ ଭାବେ ପ୍ରଦାନ କରିବାର ନୀତିଟି ବିଚାରଯୋଗ୍ୟ।

ଉପସଂହାର ପୂର୍ବରୁ

ମୁଁ ଏହି ଅଭିଜ୍ଞତା ବାଣ୍ଟିବାକୁ ନିଷ୍ପତ୍ତି ନେଲି ଏହି କାରଣରୁ ନୁହେଁ ଯେ ମୁଁ ନିଜକୁ ଅଥେଣ୍ଟିକେସନ୍‌ର ଏକ ନୂଆ ପଦ୍ଧତିର ଉଦ୍ଭାବକ ବୋଲି ଭାବେ।

କିମ୍ବା ଏହି କାରଣରୁ ମଧ୍ୟ ନୁହେଁ ଯେ ଆଉ ଏକ ସିଷ୍ଟମ୍‌କୁ ସମ୍ପୂର୍ଣ୍ଣ ସୁରକ୍ଷିତ ବୋଲି ଉପସ୍ଥାପନ କରିବାକୁ ଚାହୁଁଛି।

ସମ୍ପୂର୍ଣ୍ଣ ସୁରକ୍ଷା ବୋଲି କିଛି ନାହିଁ।

ମୋତେ କେବଳ ଏହି ପ୍ରଶ୍ନଟି ଆକର୍ଷଣୀୟ ଲାଗେ।

ସ୍ଥାୟୀ ପ୍ରଶାସନିକ ଲଗଇନ୍‌କୁ ଅସୀମିତ ଭାବେ ସୁରକ୍ଷା ଦେବା ବଦଳରେ, ତାହା ରହିବା ଆବଶ୍ୟକ କି ନାହିଁ ପୁନର୍ବିଚାର କରିହେବ।

ଅନେକ ପାସୱାର୍ଡ ସଞ୍ଚୟ କରିବା ବଦଳରେ—ସାମୟିକ ଅନୁମତି ବ୍ୟବହାର କରିହେବ।

ପ୍ରଥମ ଅଥେଣ୍ଟିକେସନ୍ ପରେ ସ୍ୱତଃସ୍ଫୂର୍ତ୍ତ ବିଶ୍ୱାସ କରିବା ବଦଳରେ—ନିର୍ଦ୍ଦିଷ୍ଟ ଅଧିକାର ଦେବାକୁ ନିଶ୍ଚିତ କରିହେବ।

ସେସନ୍ ଶେଷ ହେବାକୁ ଅପେକ୍ଷା କରିବା ବଦଳରେ—ପ୍ରବେଶକୁ କେନ୍ଦ୍ରୀୟ ଭାବେ ପ୍ରତ୍ୟାହାର କରିବାର ବ୍ୟବସ୍ଥା ରଖିହେବ।

ଶେଷରେ, ପ୍ରତ୍ୟେକ ପ୍ରୋଜେକ୍ଟରେ ଅଲଗା ଲଗଇନ୍ ବ୍ୟବସ୍ଥା ରଖିବା ବଦଳରେ—ଆପ୍ଲିକେସନ୍‌ଗୁଡ଼ିକର ସ୍ୱତନ୍ତ୍ରତା ବଜାୟ ରଖି ଏକ ସମନ୍ୱିତ ପ୍ରଶାସନିକ ପ୍ରବେଶ ପରିଚାଳନା ସିଷ୍ଟମ୍ ତିଆରି କରିହେବ।

ଏହି ପଦ୍ଧତି ସୁରକ୍ଷା ଭଙ୍ଗର ସମ୍ଭାବନାକୁ ସମ୍ପୂର୍ଣ୍ଣ ଦୂର କରେ ବୋଲି ମୁଁ ଦାବି କରୁନାହିଁ।

ଏହା କେବଳ ସବୁବେଳେ ଥିବା ଆକାଉଣ୍ଟ୍ ବିବରଣୀକୁ ସୁରକ୍ଷା ଦେବାରୁ ଧ୍ୟାନକୁ ନିୟନ୍ତ୍ରିତ ଭାବେ ଅଧିକାର ପ୍ରଦାନ ଏବଂ ତାହାକୁ ସମାପ୍ତ କରିବା ଦିଗକୁ ସ୍ଥାନାନ୍ତର କରେ।

ହୁଏତ ବେଳେବେଳେ ଆକ୍ରମଣର ସମ୍ଭାବ୍ୟ କ୍ଷେତ୍ର କମାଇବାର ସବୁଠାରୁ ପ୍ରଭାବଶାଳୀ ଉପାୟ ଆଉ ଏକ ସୁରକ୍ଷା ବ୍ୟବସ୍ଥା ଯୋଡ଼ିବା ନୁହେଁ, ବରଂ ଯାହା ବିନା ସିଷ୍ଟମ୍ ସହଜରେ କାମ କରିପାରେ ତାହାକୁ ଛାଡ଼ିଦେବା।

ଏହି ଚିନ୍ତାରୁ ହିଁ ମୋ ପାଇଁ MeldID Admin Gatewayର କାହାଣୀ ଆରମ୍ଭ ହୋଇଥିଲା।