পাসওয়ার্ড সুরক্ষিত রাখবেন কেন, যদি সেটি বাদই দেওয়া যায়?

যে সমস্যাকে আমরা স্বাভাবিক বলে মেনে নিয়েছি

প্রায় প্রতিটি ওয়েব অ্যাপ্লিকেশনেই একটি প্রশাসনিক প্যানেল থাকে। আর প্রশাসনিক প্যানেলে সাধারণত থাকে লগইন ঠিকানা, প্রমাণীকরণ ফর্ম, ব্যবহারকারীর নাম ও পাসওয়ার্ড।

এই কাঠামোর সঙ্গে আমরা এতটাই অভ্যস্ত হয়ে গেছি যে প্রায় প্রশ্ন করাই বন্ধ করে দিয়েছি: সবকিছু কি সত্যিই এভাবেই কাজ করতে হবে?

আপনার যখন একটি ওয়েবসাইট থাকে, তখন সমস্যাটি তেমন গুরুতর মনে হয় না। একটি জটিল পাসওয়ার্ড তৈরি করলেন, দ্বি-ধাপ প্রমাণীকরণ চালু করলেন, লগইন প্রচেষ্টার সীমা নির্ধারণ করলেন—তারপর কাজ চালিয়ে গেলেন।

কিন্তু যখন প্রকল্পের সংখ্যা দশ, বিশ বা ত্রিশে পৌঁছায়, তখন কী হয়?

আমার ক্ষেত্রে 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-এর গল্প শুরু হয়েছিল।