কেন একটি OTP Wi-Fi, VPN আর রেজিস্ট্রিকে ঢাকতে পারে না

একক সাইন-ইন একটি পরিচয় আর কম জিজ্ঞাসার প্রতিশ্রুতি দেয়, আর সেই প্রতিশ্রুতি তৃতীয় প্রোটোকলে ভাঙে। ফাঁদ হলো ধরে নেওয়া যে একটি সফল প্রমাণীকরণ এমন টোকেন তৈরি করে যা অন্য প্রতিটি প্রোটোকল উপস্থাপন করতে পারে। Wi-Fi প্রবেশ, VPN প্রবেশ আর কন্টেইনার রেজিস্ট্রি প্রত্যেকে আলাদা বিনিময় চালায়, আলাদা দর্শক ও আয়ু নিয়ে। অ্যাকাউন্ট ভাগ করা ডিরেক্টরির সিদ্ধান্ত; ক্রেডেনশিয়াল ভাগ করা প্রোটোকলের সিদ্ধান্ত, আর প্রোটোকলগুলো খুব কমই একমত হয়।

তিন বিনিময়, তিন মালিক

এন্টারপ্রাইজ Wi-Fi 802.1X-এর ভিতরে EAP পদ্ধতি চালায়, সাধারণত ব্যবহারকারী বা ডিভাইস সম্পর্কে নিজস্ব দৃষ্টিভঙ্গি আছে এমন একটি RADIUS সেবা তা শেষ করে। VPN গেটওয়ে নিজের সমর্থিত প্রবাহ দিয়ে প্রমাণীকরণ করে এবং পরে নিজের পুনঃপ্রমাণীকরণ টাইমারসহ সেশন রাখে। রেজিস্ট্রি অপ্রমাণিত অনুরোধের উত্তর দেয় এমন চ্যালেঞ্জ দিয়ে যা টোকেন সেবা, দর্শক আর পরিধির নাম বলে, আর ক্লায়েন্ট তার ক্রেডেনশিয়াল স্বল্পস্থায়ী টোকেনের বিনিময়ে বদলায়।

এগুলো একই সেশনের তিনটি দৃশ্য নয়। প্রত্যেকের নিজস্ব যাচাইকারী, নিজস্ব আয়ু আর নিজস্ব রদ করার পথ আছে, তাই ডিরেক্টরিতে পাসওয়ার্ড বদলালে একটি চালু আর অন্যটি ভাঙা থেকে যেতে পারে। এগুলোকে এমন তিনটি সংহতি হিসেবে দেখুন যা কাকতালীয়ভাবে একটি ব্যবহারকারী ডিরেক্টরি ভাগ করে।

ব্রাউজার SSO কী বহন করে আর কী বহন করে না

পরিচয় প্রদানকারীর কাছে ব্রাউজার সেশন সত্যিই উপকারী: যে অ্যাপ্লিকেশন সেখানে পুনঃনির্দেশ করে তারা ব্যবহারকারীর আগেই সম্পন্ন করা লগইন উত্তরাধিকার পায়। এটি কাজ করে কারণ সেই অ্যাপ্লিকেশনগুলো একই পুনঃনির্দেশ ও টোকেন প্রোটোকল বলে এবং একই দর্শক গ্রহণ করে। EAP বলা অনুরোধকারীর অনুসরণ করার কোনো পুনঃনির্দেশ নেই, আর রেজিস্ট্রি চ্যালেঞ্জ পাওয়া Docker ক্লায়েন্ট OIDC পরিচয় টোকেন চায় না। পরিচয় প্রদানকারী কেবল সেই প্রোটোকলের জামিন দিতে পারে যেগুলোর জন্য তাকে বানানো হয়েছে।

কোথায় দেখতে হবে জানলে লগে ব্যর্থতা দেখা সহজ। পরিচয় প্রদানকারী সফল লগইনের প্রতিবেদন দেয় অথচ Wi-Fi সংযোগ এখনও ব্যর্থ হয়, বা ব্রাউজার কখনও দেখেনি এমন টোকেন বিনিময়ের পর রেজিস্ট্রি 401 ফেরত দেয়। দুটি সাফল্য আর একটি ব্যর্থতা বিরোধ নয়; এগুলো তিনটি আলাদা প্রমাণীকরণ।

যেখানে সার্টিফিকেট পুনরাবৃত্ত কোডের জায়গা নেয়

ব্যবস্থাপিত ডিভাইসের জন্য, সার্টিফিকেটভিত্তিক EAP পরিচয় না সরিয়ে মানবিক ধাপ সরিয়ে দেয়: ডিভাইস সার্টিফিকেট উপস্থাপন করে, RADIUS সেবা তা ইস্যুকারী কর্তৃপক্ষের কাছে যাচাই করে, আর রদ হয় সেই কর্তৃপক্ষেই, কোনো ভাগ করা গোপনীয়তায় নয়। মূল্য হলো জীবনচক্রের কাজ, কারণ সার্টিফিকেটের মেয়াদ শেষ হয় আর তার আগে নবায়ন করতে হয়।

রেজিস্ট্রিগুলোরও সমতুল্য ভাগ আছে। ইন্টারঅ্যাকটিভ ব্যবহারকারী একবার লগইন করে ফলাফল টোকেন একটি ক্রেডেনশিয়াল সহায়ককে সংরক্ষণ করতে দিতে পারে, আর অটোমেশন ব্যবহার করা উচিত সংকীর্ণ পরিধির সেবা ক্রেডেনশিয়াল বা ওয়ার্কলোড পরিচয়। এর কোনোটিই পাইপলাইনে অনুলিপি করা মানুষের এককালীন কোড হওয়া উচিত নয়। সহায়ক নির্দিষ্ট রেজিস্ট্রি দর্শকের জন্য টোকেন সংরক্ষণ করে, তাই কনফিগারেশন ফাইল সম্পাদনা করে তাকে VPN গেটওয়ের দিকে ঘুরিয়ে দেওয়া যায় না।

docker login registry.example.com

রক্ষণাবেক্ষণ খরচ তুলনা করুন, জিজ্ঞাসার সংখ্যা নয়

ভাগ করা ক্রেডেনশিয়াল সস্তা মনে হয় কারণ কাজ ব্যর্থ হওয়ার আগে অদৃশ্য থাকে। এর বদলে গুনুন প্রতিটি বিকল্প এক বছরে কী খরচ করে: নথিভুক্তি, নবায়ন, রদ, ফাঁসের প্রভাবের ব্যাসার্ধ আর কেউ চলে গেলে স্পর্শ করা সিস্টেমের সংখ্যা। সার্টিফিকেটের বহর তৈরি করতে বেশি আর বড় মাপে চালাতে কম খরচ করে; অনুলিপি করা কোড শুরু করতে কিছুই আর খুলতে সবকিছু খরচ করে।

তারপর বৈশ্বিকভাবে নয়, প্রতিটি অংশের জন্য বেছে নিন। Wi-Fi সার্টিফিকেটে যেতে পারে, VPN MFA-সহ সমর্থিত SSO রাখতে পারে, আর রেজিস্ট্রি স্পষ্ট পরিধির টোকেন ব্যবহার করতে পারে। প্রত্যেকের জন্য মালিক, দর্শক, পরিধি, মেয়াদ আর রদ করার পথ লিখে রাখুন, আর জিজ্ঞাসাগুলো একসঙ্গে সব জায়গায় নয়, যেখানে দরকার সেখানে পড়বে। সেই নথি তখনই উত্তর যখন কোনো নিরীক্ষক জিজ্ঞাসা করেন কোন সিস্টেমগুলো এখনও পাসওয়ার্ডে ভরসা করে।