EAP-TLS WiFi Authentication-এর জন্য ডিজিটাল সার্টিফিকেট পরিচালনা

একটি আত্মবিশ্বাসী, কর্তৃত্বপূর্ণ এবং কথোপকথনমূলক টোনে ব্রিটিশ ইংরেজিতে কথা বলুন - ঠিক যেমন একজন সিনিয়র পরামর্শদাতা কোনো ক্লায়েন্টকে ব্রিফিং করছেন। পরিমিত গতি, স্পষ্ট উচ্চারণ, উষ্ণ কিন্তু সরাসরি। জোর দেওয়ার জন্য মাঝে মাঝে স্বাভাবিক বিরতি: Purple-এর টেকনিক্যাল ব্রিফিং সিরিজে আপনাকে স্বাগতম। আজ আমরা EAP-TLS সার্টিফিকেট ম্যানেজমেন্ট সম্পর্কে কথা বলছি - বিশেষ করে, কীভাবে একটি সার্টিফিকেট-ভিত্তিক WiFi অথেন্টিকেশন প্রোগ্রামকে কোনো ফুল-টাইম অপারেশনাল বোঝা ছাড়াই বড় স্কেলে পরিচালনা করা যায়। [medium pause] আপনি যদি একাধিক সাইট জুড়ে কর্পোরেট বা স্টাফদের WiFi-এর দায়িত্বে থাকেন - তা কোনো হোটেল গ্রুপ, রিটেইল এস্টেট, ইউনিভার্সিটি ক্যাম্পাস বা পাবলিক-সেক্টর এস্টেট যা-ই হোক না কেন - এই ব্রিফিংটি আপনার জন্য। আমরা সার্টিফিকেটের সম্পূর্ণ লাইফসাইকেল কভার করতে যাচ্ছি: আপনার CA হায়ারার্কি সেট আপ করা থেকে শুরু করে, SCEP এবং MDM-এর মাধ্যমে অটোমেটেড ডিপ্লয়মেন্ট হয়ে, রিনিউয়াল এবং রিভোকেশন পর্যন্ত। এবং আমরা আলোচনা করব কোথায় ভুল হতে পারে (কারণ ভুল সত্যিই হয়) এবং কীভাবে সবচেয়ে সাধারণ ফাঁদগুলো এড়ানো যায়। [medium pause] চলুন একদম মৌলিক বিষয়গুলো দিয়ে শুরু করা যাক। EAP-TLS - অর্থাৎ Extensible Authentication Protocol with Transport Layer Security - হলো 802.1X WiFi অথেন্টিকেশনের জন্য গোল্ড স্ট্যান্ডার্ড। PEAP-এর মতো নয়, যা ইউজারনেম এবং পাসওয়ার্ডের ওপর নির্ভর করে; EAP-TLS মিউচুয়াল সার্টিফিকেট-ভিত্তিক অথেন্টিকেশন ব্যবহার করে। ডিভাইসটি একটি ক্লায়েন্ট সার্টিফিকেটের মাধ্যমে নিজের পরিচয় প্রমাণ করে। RADIUS সার্ভারটি একটি সার্ভার সার্টিফিকেটের মাধ্যমে নিজের পরিচয় প্রমাণ করে। উভয় পক্ষই অপর পক্ষকে যাচাই করে। ফিশিং করার মতো কোনো পাসওয়ার্ড নেই। চুরি করার মতো কোনো ক্রেডেনশিয়াল নেই। এই কারণেই PCI DSS 4.0 এবং NCSC-এর জিরো-ট্রাস্ট গাইডেন্স উভয়ই স্টাফ নেটওয়ার্কের জন্য সার্টিফিকেট-ভিত্তিক অথেন্টিকেশনের দিকে ইঙ্গিত করে। [medium pause] এবার আসা যাক আর্কিটেকচারে। EAP-TLS কাজ করানোর জন্য আপনার তিনটি জিনিসের প্রয়োজন। প্রথমত, একটি Public Key Infrastructure - আপনার CA হায়ারার্কি। দ্বিতীয়ত, ডিভাইসে সার্টিফিকেট পাওয়ার একটি মেকানিজম - যা হলো SCEP বা আপনার MDM প্ল্যাটফর্ম। তৃতীয়ত, একটি RADIUS সার্ভার যা আপনার CA-কে ট্রাস্ট করে এবং রিয়েল টাইমে ক্লায়েন্ট সার্টিফিকেটগুলো ভ্যালিডেট করতে পারে। [medium pause] CA হায়ারার্কির ক্ষেত্রেই বেশিরভাগ প্রতিষ্ঠান প্রথম দিকে সমস্যায় পড়ে। সঠিক প্যাটার্নটি হলো একটি থ্রি-টায়ার মডেল। আপনার শীর্ষে রয়েছে একটি Root CA - এটি অফলাইন, এয়ার-গ্যাপড হওয়া উচিত এবং শুধুমাত্র আপনার Intermediate CA সার্টিফিকেটে স্বাক্ষর করার জন্য অনলাইনে আনা উচিত। Intermediate CA - যাকে কখনো কখনো Issuing CA বলা হয় - সেটিই আসলে দৈনন্দিন সার্টিফিকেটগুলোতে স্বাক্ষর করে। এটি অনলাইন থাকে, তবে এর প্রাইভেট কি (private key) সুরক্ষিত থাকে। এর নিচে, আপনি দুই ধরনের সার্টিফিকেট ইস্যু করেন: আপনার RADIUS ইনফ্রাস্ট্রাকচারের জন্য সার্ভার সার্টিফিকেট এবং আপনার ডিভাইস ও ব্যবহারকারীদের জন্য ক্লায়েন্ট সার্টিফিকেট। [medium pause] এটি কেন গুরুত্বপূর্ণ? কারণ আপনার Root CA যদি কম্প্রোমাইজড হয়, তবে আপনাকে স্ক্র্যাচ থেকে আপনার সম্পূর্ণ PKI পুনরায় তৈরি করতে হবে এবং প্রতিটি ডিভাইসকে পুনরায় এনরোল করতে হবে। এটিকে অফলাইনে রাখা সেই ঝুঁকি দূর করে। Root-কে স্পর্শ না করেই Intermediate CA প্রতিস্থাপন করা সম্ভব। এটিই হলো থ্রি-টায়ার মডেলের অপারেশনাল রেজিলিয়েন্সের পক্ষে যুক্তি। [medium pause] আসুন আমরা সার্টিফিকেটের বৈধতার মেয়াদ নিয়ে আলোচনা করি। এখানে ইন্ডাস্ট্রিতে একটি বড় পরিবর্তন এসেছে। Apple, Google এবং Mozilla সবাই সার্টিফিকেটের সর্বোচ্চ মেয়াদ কমিয়ে আনতে পদক্ষেপ নিয়েছে। TLS সার্ভার সার্টিফিকেটের ক্ষেত্রে সর্বোচ্চ মেয়াদ এখন ৩৯৮ দিন। এন্টারপ্রাইজ WiFi-এ ক্লায়েন্ট সার্টিফিকেটের জন্য আপনার কাছে আরও বেশি নমনীয়তা রয়েছে - এক থেকে দুই বছর সাধারণত দেখা যায় - তবে ম্যানুয়ালি পরিচালিত দীর্ঘস্থায়ী সার্টিফিকেটের পরিবর্তে স্বল্প মেয়াদ এবং স্বয়ংক্রিয় নবায়নের দিকেই ঝোঁক বেশি। এর কারণ সহজ: একটি সংক্ষিপ্ত মেয়াদ সার্টিফিকেট সংকটাপন্ন হলে ঝুঁকির সময়সীমাকে সীমিত করে। [medium pause] এটি আমাদের অটোমেশনের দিকে নিয়ে আসে। ম্যানুয়াল সার্টিফিকেট ম্যানেজমেন্ট বড় পরিসরে কাজ করে না। আপনার যদি ৫০০টি ডিভাইস থাকে, তবে আপনি কোনোমতে হাতেই নবায়নের কাজটি পরিচালনা করতে পারেন। কিন্তু আপনার যদি ৫০টি সাইট জুড়ে ৫,০০০টি ডিভাইস থাকে, তবে তা সম্ভব নয়। আপনার SCEP (Simple Certificate Enrolment Protocol) বা এর আধুনিক উত্তরসূরি EST প্রয়োজন। SCEP সরাসরি Microsoft Intune, Jamf Pro এবং VMware Workspace ONE সহ MDM প্ল্যাটফর্মগুলোর সাথে সংহত (integrate) হয়। MDM ডিভাইসে একটি SCEP কনফিগারেশন প্রোফাইল পাঠায়। ডিভাইসটি একটি কী-পেয়ার (key pair) তৈরি করে, আপনার SCEP সার্ভারে একটি সার্টিফিকেট সাইনিং রিকোয়েস্ট পাঠায় এবং একটি স্বাক্ষরিত সার্টিফিকেট ফিরে পায় - কোনো ব্যবহারকারীর হস্তক্ষেপ ছাড়াই। [medium pause] Active Directory পরিবেশে Windows ডিভাইসগুলোর জন্য আপনার কাছে একটি বিকল্প রয়েছে: Active Directory Certificate Services-এর মাধ্যমে গ্রুপ পলিসি-চালিত অটো-এনরোলমেন্ট। ডিভাইসটি ডোমেনে প্রমাণীকরণ (authenticate) করে, CA স্বয়ংক্রিয়ভাবে একটি সার্টিফিকেট ইস্যু করে এবং কোনো ম্যানুয়াল হস্তক্ষেপ ছাড়াই মেয়াদ শেষ হওয়ার আগে সার্টিফিকেটটি নবায়ন করা হয়। এটি প্রচুর Windows ডিভাইস চালিত প্রতিষ্ঠানের জন্য সবচেয়ে নির্বিঘ্ন পথ। [medium pause] এবার আসি রিভোকেশন (বাতিলকরণ) প্রসঙ্গে। এটি এমন একটি বিষয় যেখানে সংস্থাগুলো সাধারণত সবচেয়ে কম বিনিয়োগ করে, অথচ কোনো সমস্যা দেখা দিলে এটিই সবচেয়ে গুরুত্বপূর্ণ ভূমিকা পালন করে। কোনো ডিভাইস হারিয়ে গেলে, চুরি হলে বা কোনো কর্মচারী চলে গেলে, আপনাকে অবিলম্বে তাদের সার্টিফিকেট বাতিল করতে হবে। এর দুটি প্রক্রিয়া রয়েছে: CRL (Certificate Revocation Lists) এবং OCSP (Online Certificate Status Protocol)। [medium pause] CRL হলো অপেক্ষাকৃত পুরোনো প্রক্রিয়া। আপনার CA একটি পরিচিত URL-এ বাতিলকৃত সার্টিফিকেটের সিরিয়াল নম্বরের একটি তালিকা প্রকাশ করে। RADIUS সার্ভার পর্যায়ক্রমে এই তালিকাটি ডাউনলোড করে এবং এটির সাথে মিলিয়ে পরীক্ষা করে। CRL-এর সমস্যা হলো ল্যাটেন্সি (latency) - আপনার CRL-এর বৈধতার মেয়াদ যদি ২৪ ঘণ্টা হয়, তবে বাতিল করার পরেও একটি বাতিলকৃত সার্টিফিকেট ২৪ ঘণ্টা পর্যন্ত প্রমাণীকরণ সম্পন্ন করতে পারে। [medium pause] OCSP হলো এর রিয়েল-টাইম বিকল্প। প্রতিটি প্রমাণীকরণের চেষ্টার জন্য RADIUS সার্ভার OCSP রেসপন্ডারের কাছে একটি কোয়েরি পাঠায় এবং তাৎক্ষণিক 'সঠিক' বা 'বাতিল' প্রতিক্রিয়া লাভ করে। এর একমাত্র অসুবিধা হলো আপনার OCSP রেসপন্ডার একটি অত্যন্ত গুরুত্বপূর্ণ নির্ভরতা হয়ে ওঠে - যদি এটি অনুপলব্ধ থাকে, তবে আপনাকে সিদ্ধান্ত নিতে হবে যে আপনি অ্যাক্সেস উন্মুক্ত রাখবেন নাকি বন্ধ রাখবেন (fail open নাকি fail closed)। উচ্চ-নিরাপত্তাসম্পন্ন পরিবেশের জন্য fail closed-ই সঠিক সিদ্ধান্ত। যে সমস্ত অপারেশনাল পরিবেশের জন্য সিস্টেম সচল থাকা জরুরি, সেখানে আপনি একটি সংক্ষিপ্ত OCSP গ্রেস পিরিয়ড কনফিগার করতে পারেন। [medium pause] বিষয়টি আরও স্পষ্ট করতে আমি আপনাকে দুটি বাস্তব উদাহরণ দিই। [medium pause] প্রথম: একটি ১৫০-সম্পত্তির হোটেল গ্রুপ। তারা স্টাফ WiFi-এর জন্য একটি শেয়ারড পাসওয়ার্ড সহ PEAP চালাচ্ছিল। পাসওয়ার্ড পরিবর্তন করা হতো ত্রৈমাসিক ভিত্তিতে, যার অর্থ প্রতি কোয়ার্টারে দুই সপ্তাহের একটি উইন্ডো থাকতো যখন স্টাফরা লক আউট হয়ে যেতেন অথবা পুরোনো পাসওয়ার্ড ব্যবহার করতেন। তারা সার্টিফিকেট স্থাপনের জন্য Microsoft Intune ব্যবহার করে EAP-TLS-এ স্থানান্তরিত হয়। SCEP প্রোফাইলগুলো সমস্ত Windows এবং iOS ডিভাইসে পুশ করা হয়েছিল। CA হিসেবে Active Directory Certificate Services ব্যবহার করা হয়েছিল। ফলাফল: শূন্য পাসওয়ার্ড পরিবর্তন ইভেন্ট, মেয়াদ শেষ হওয়ার ৩০ দিন আগে সার্টিফিকেট নবায়ন স্বয়ংক্রিয়ভাবে সম্পন্ন হওয়া, এবং যখন কোনো স্টাফ সদস্য চলে যান, তখন Microsoft Entra ID-তে তাদের অ্যাকাউন্ট নিষ্ক্রিয় করার কয়েক মিনিটের মধ্যে MDM-এ তাদের সার্টিফিকেট বাতিল করা হয়েছিল। আইটি টিমের আনুমানিক হিসাব অনুযায়ী, তারা পাসওয়ার্ড রিসেট এবং হেল্পডেস্ক টিকিটের ক্ষেত্রে প্রতি কোয়ার্টারে প্রায় ৪০ ঘণ্টা সাশ্রয় করেছেন। [medium pause] দ্বিতীয়: ২০০০টি স্টোর জুড়ে ৩,০০০টি স্টাফ ডিভাইস সহ একটি মাল্টি-সাইট রিটেইল চেইন। এখানকার চ্যালেঞ্জটি ছিল ডিভাইসের বৈচিত্র্য - Windows ল্যাপটপ, Android হ্যান্ডহেল্ড এবং iOS ডিভাইসের মিশ্রণ। তারা Apple ডিভাইসের জন্য Jamf Pro এবং Windows ও Android-এর জন্য Microsoft Intune ব্যবহার করেছিল, উভয়ই একটি Microsoft ADCS Intermediate CA দ্বারা ব্যাকড একই SCEP সার্ভারকে নির্দেশ করছিল। WiFi অবকাঠামোটি ছিল Cisco Meraki, যেখানে RADIUS অথেন্টিকেশন পরিচালনা করা হতো Purple-এর সাথে সমন্বিত একটি ক্লাউড-হোস্টেড RADIUS সার্ভিসের মাধ্যমে। মূল ডিজাইনের সিদ্ধান্তটি ছিল ১২ মাসের মেয়াদের সার্টিফিকেট ইস্যু করা এবং মেয়াদ শেষ হওয়ার ৬০ দিন আগে স্বয়ংক্রিয় নবায়ন কনফিগার করা। এটি কোনো অপারেশনাল ওভারহেড তৈরি না করেই একটি আরামদায়ক নবায়ন উইন্ডো প্রদান করেছিল। [medium pause] এখন, ত্রুটিগুলো। এখানে এমন চারটি ত্রুটি রয়েছে যা আমি প্রতিনিয়ত দেখতে পাই। [medium pause] প্রথম: সার্টিফিকেট বাতিলকরণ পরীক্ষা না করা। সংস্থাগুলো তাদের PKI সেট আপ করে, সার্টিফিকেট মোতায়েন করে, কিন্তু বাতিলকরণ প্রক্রিয়াটি এন্ড-টু-এন্ড সঠিকভাবে কাজ করছে কিনা তা কখনই পরীক্ষা করে না। এটি পরীক্ষা করুন। একটি টেস্ট সার্টিফিকেট বাতিল করুন, আপনার প্রত্যাশিত উইন্ডোর মধ্যে RADIUS সার্ভার সেই বাতিলকরণটি সনাক্ত করছে কিনা তা নিশ্চিত করুন এবং ডিভাইসটির অ্যাক্সেস প্রত্যাখ্যান করা হয়েছে কিনা তা যাচাই করুন। [medium pause] দ্বিতীয়: একই সময়ে সমস্ত সার্টিফিকেটের মেয়াদ শেষ হওয়া। আপনি যদি আপনার সমস্ত সার্টিফিকেট একই সময়ে একই মেয়াদে ইস্যু করেন, তবে সেগুলোর মেয়াদ একই সময়ে শেষ হবে। আপনার ইস্যু করার সময়কালকে ধাপে ধাপে সাজান, অথবা অন্তত আপনার নবায়ন ট্রিগারগুলোকে ধাপে ধাপে নির্ধারণ করুন। একসাথে ৫,০০০ ডিভাইসের মধ্যে ১০% নবায়ন ব্যর্থতার হার একটি বড় ধরনের বিপর্যয়। [medium pause] তৃতীয়: EAP-TLS মোতায়েন করার আগে সমস্ত ডিভাইসে Root CA সার্টিফিকেট বিতরণ না করা। ডিভাইসটি যদি আপনার Root CA-কে বিশ্বাস না করে, তবে এটি RADIUS সার্ভারের সার্টিফিকেট প্রত্যাখ্যান করবে এবং অথেন্টিকেশন ব্যর্থ হবে। এটি শুনতে সহজ মনে হলেও, সংস্থাগুলো তখন বিপদে পড়ে যখন তাদের কাছে BYOD ডিভাইস বা ঠিকাদারদের ল্যাপটপ থাকে যা MDM-এ নিবন্ধিত নয়। [medium pause] চতুর্থ: OCSP রেসপন্ডারের উপলব্ধতা। যদি আপনার OCSP রেসপন্ডার ডাউন হয়ে যায় এবং আপনার RADIUS সার্ভারটি OCSP ত্রুটির ক্ষেত্রে সংযোগ বন্ধ করার জন্য কনফিগার করা থাকে, তবে আপনার সম্পূর্ণ WiFi সিস্টেম কাজ করা বন্ধ করে দেবে। আপনার OCSP অবকাঠামোতে রিডানডেন্সি তৈরি করুন, অথবা উপযুক্ত মনিটরিং সহ একটি সংক্ষিপ্ত গ্রেস পিরিয়ড কনফিগার করুন। [medium pause] ঠিক আছে, দ্রুত প্রশ্নোত্তর পর্ব শুরু করা যাক। [medium pause] আমি কি EAP-TLS ক্লায়েন্ট সার্টিফিকেটের জন্য একটি পাবলিক CA ব্যবহার করতে পারি? প্রযুক্তিগতভাবে হ্যাঁ, কিন্তু বাস্তবে না। পাবলিক CA-গুলো নির্বিচার ডিভাইসের জন্য ক্লায়েন্ট সার্টিফিকেট ইস্যু করবে না। ক্লায়েন্ট সার্টিফিকেটের জন্য আপনার নিজস্ব CA প্রয়োজন। RADIUS সার্ভার সার্টিফিকেটের জন্য, একটি পাবলিক CA ঠিক আছে এবং এটি ট্রাস্ট ডিস্ট্রিবিউশনকে সহজ করে তোলে। [medium pause] BYOD-এর ক্ষেত্রে কী হবে? BYOD একটি কঠিন পরিস্থিতি। আপনি MDM-এর মাধ্যমে অননুমোদিত ডিভাইসগুলোতে সার্টিফিকেট পুশ করতে পারবেন না। বিকল্পগুলোর মধ্যে রয়েছে একটি নেটওয়ার্ক অ্যাক্সেস কন্ট্রোল পোর্টাল যা ব্যবহারকারী যাচাইকরণের পরে স্বল্পমেয়াদী সার্টিফিকেট ইস্যু করে, অথবা সহজভাবে একটি ভিন্ন অথেনটিকেশন পদ্ধতির সাহায্যে BYOD-কে একটি পৃথক SSID-তে রাখা। [medium pause] এটি WPA3-এর সাথে কীভাবে কাজ করে? WPA3-Enterprise সংবেদনশীল পরিবেশের জন্য ১৯২-বিট সিকিউরিটি মোড বাধ্যতামূলক করে, যার জন্য নির্দিষ্ট সাইফার সুইট প্রয়োজন হয়। EAP-TLS পুরোপুরি WPA3-Enterprise-এর সাথে সামঞ্জস্যপূর্ণ এবং প্রকৃতপক্ষে এটিই সুপারিশকৃত অথেনটিকেশন পদ্ধতি। [medium pause] সংক্ষেপে বলতে গেলে। EAP-TLS সার্টিফিকেট পরিচালনা সহজ নয়, তবে শুরু থেকেই আর্কিটেকচারটি সঠিক হলে এটি পরিচালনা করা সম্ভব। থ্রি-টায়ার CA হায়ারার্কি। SCEP বা MDM-এর মাধ্যমে স্বয়ংক্রিয় এনরোলমেন্ট। স্বয়ংক্রিয় রিনিউয়াল সহ সার্টিফিকেটের স্বল্প মেয়াদ। OCSP-এর মাধ্যমে রিয়েল-টাইম রেভোকেশন। সবকিছু পরীক্ষা করুন, বিশেষ করে রেভোকেশন। এবং আপনার আইডেন্টিটি প্রোভাইডার - Microsoft Entra ID, Okta বা Google Workspace-এর সাথে আপনার সার্টিফিকেটের লাইফসাইকেল একীভূত করুন - যাতে কোনও অ্যাকাউন্ট ডিপ্রোভিশন করার সাথে সাথে সার্টিফিকেটের রেভোকেশন স্বয়ংক্রিয়ভাবে ট্রিগার হয়। [medium pause] আপনি যদি Purple-সংযুক্ত RADIUS সার্ভার চালান, তাহলে ইন্টিগ্রেশন পয়েন্টগুলো হলো আপনার SCEP সার্ভার URL, আপনার RADIUS সার্ভার সার্টিফিকেট এবং আপনার CRL বা OCSP এন্ডপয়েন্ট। Purple-এর হার্ডওয়্যার-অ্যাগনস্টিক আর্কিটেকচারের অর্থ হলো এটি Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist এবং বাকি সমস্ত প্রচলিত হার্ডওয়্যার তালিকায় কাজ করে - আপনি কোনো একক ভেন্ডরের PKI টুলের মধ্যে সীমাবদ্ধ থাকবেন না। [medium pause] পরবর্তী পদক্ষেপ: আপনার বর্তমান সার্টিফিকেটের তালিকা অডিট করুন। আপনার কাছে কতগুলো সার্টিফিকেট আছে, সেগুলো কখন শেষ হবে এবং কে ইস্যু করেছে তা যদি আপনার জানা না থাকে, তবে প্রথমে সেটি সমাধান করতে হবে। সেখান থেকে, সম্পূর্ণ স্বয়ংক্রিয়করণের পথটি সুনির্দিষ্ট। শোনার জন্য ধন্যবাদ।