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

Speak in British English with a confident, authoritative, and conversational tone - like a senior consultant briefing a client. Measured pace, clear diction, warm but direct. Occasional natural pauses for emphasis: 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 বলা হয় - হলো সেটি যা আসলে প্রতিদিনের সার্টিফিকেটগুলোতে স্বাক্ষর করে। এটি অনলাইন, তবে এর প্রাইভেট কী ভালোভাবে সুরক্ষিত থাকে। এর নিচে, আপনি দুই ধরণের সার্টিফিকেট ইস্যু করেন: আপনার 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 প্ল্যাটফর্মগুলোর সাথে ইন্টিগ্রেট করে। MDM ডিভাইসে একটি SCEP কনফিগারেশন প্রোফাইল পুশ করে। ডিভাইসটি একটি কী পেয়ার তৈরি করে, আপনার SCEP সার্ভারে একটি সার্টিফিকেট সাইনিং রিকোয়েস্ট পাঠায় এবং একটি স্বাক্ষরিত সার্টিফিকেট ফেরত পায় - কোনো ব্যবহারকারীর হস্তক্ষেপ ছাড়াই। [medium pause] একটি Active Directory পরিবেশে Windows ডিভাইসগুলোর জন্য, আপনার একটি বিকল্প রয়েছে: Active Directory Certificate Services-এর মাধ্যমে Group Policy-চালিত অটো-এনরোলমেন্ট। ডিভাইসটি ডোমেনে অথেন্টিকেট করে, CA স্বয়ংক্রিয়ভাবে একটি সার্টিফিকেট ইস্যু করে এবং কোনো ম্যানুয়াল হস্তক্ষেপ ছাড়াই মেয়াদ শেষ হওয়ার আগে সার্টিফিকেটটি রিনিউ করা হয়। Windows-প্রধান এস্টেটগুলোর জন্য এটি সবচেয়ে নির্বিঘ্ন পথ। [medium pause] এখন, রিভোকেশন। এটি এমন একটি অংশ যেখানে প্রতিষ্ঠানগুলো প্রায়শই কম বিনিয়োগ করে, এবং কোনো কিছু ভুল হলে এটিই সবচেয়ে বেশি গুরুত্বপূর্ণ হয়ে দাঁড়ায়। যদি কোনো ডিভাইস হারিয়ে যায়, চুরি হয়ে যায় বা কোনো কর্মচারী চলে যান, তবে আপনাকে অবিলম্বে তাদের সার্টিফিকেট রিভোক করতে হবে। দুটি মেকানিজম রয়েছে: CRL - Certificate Revocation Lists - এবং OCSP - Online Certificate Status Protocol। [medium pause] CRL হলো পুরানো মেকানিজম। আপনার CA একটি পরিচিত URL-এ রিভোকড সার্টিফিকেটের সিরিয়াল নম্বরের একটি তালিকা প্রকাশ করে। RADIUS সার্ভার পর্যায়ক্রমে এই তালিকাটি ডাউনলোড করে এবং এর বিপরীতে পরীক্ষা করে। CRL-এর সমস্যা হলো লেটেন্সি - যদি আপনার CRL-এর ২৪ ঘণ্টার মেয়াদের সময়কাল থাকে, তবে একটি রিভোকড সার্টিফিকেট রিভোকেশনের পরেও ২৪ ঘণ্টা পর্যন্ত অথেন্টিকেট করতে পারে। [medium pause] OCSP হলো রিয়েল-টাইম বিকল্প। RADIUS সার্ভার প্রতিটি অথেন্টিকেশনের চেষ্টার জন্য OCSP রেসপন্ডারকে একটি কুয়েরি পাঠায় এবং একটি লাইভ গুড বা রিভোকড রেসপন্স পায়। এর অসুবিধা হলো যে আপনার OCSP রেসপন্ডার একটি গুরুত্বপূর্ণ ডিপেন্ডেন্সি হয়ে ওঠে - যদি এটি অনুপলব্ধ হয়, তবে আপনাকে সিদ্ধান্ত নিতে হবে যে ফেইল ওপেন হবে নাকি ফেইল ক্লোজড হবে। উচ্চ-নিরাপত্তা পরিবেশের জন্য, ফেইল ক্লোজড হলো সঠিক উত্তর। অপারেশনাল পরিবেশের জন্য যেখানে প্রাপ্যতা গুরুত্বপূর্ণ, আপনি একটি সংক্ষিপ্ত OCSP গ্রেস পিরিয়ড কনফিগার করতে পারেন। [medium pause] এটি বাস্তবসম্মত করতে আমাকে দুটি সুনির্দিষ্ট দৃশ্যপট দিতে দিন। [medium pause] প্রথম: একটি ১৫০-প্রপার্টির হোটেল গ্রুপ। তারা স্টাফ WiFi-এর জন্য একটি শেয়ার্ড পাসওয়ার্ড সহ PEAP চালাচ্ছিল। পাসওয়ার্ড রোটেশন ছিল ত্রৈমাসিক, যার অর্থ প্রতি কোয়ার্টারে দুই সপ্তাহের একটি উইন্ডো ছিল যেখানে স্টাফরা লক আউট হয়ে যেত বা পুরানো পাসওয়ার্ড ব্যবহার করত। তারা সার্টিফিকেট ডেপ্লয়মেন্টের জন্য Microsoft Intune ব্যবহার করে EAP-TLS-এ স্থানান্তরিত হয়েছে। SCEP প্রোফাইলগুলো সমস্ত Windows and iOS ডিভাইসে পুশ করা হয়েছে। CA হিসেবে Active Directory Certificate Services। ফলাফল: শূন্য পাসওয়ার্ড রোটেশন ইভেন্ট, মেয়াদ শেষ হওয়ার ৩০ দিন আগে সার্টিফিকেট রিনিউয়াল স্বয়ংক্রিয়ভাবে পরিচালিত হয় এবং যখন কোনো স্টাফ সদস্য চলে যান, তখন Microsoft Entra ID-তে তাদের অ্যাকাউন্ট নিষ্ক্রিয় করার কয়েক মিনিটের মধ্যে MDM-এ তাদের সার্টিফিকেট রিভোক করা হয়। IT টিম অনুমান করেছে যে তারা পাসওয়ার্ড রিসেট এবং হেল্পডেস্ক টিকিটে প্রতি কোয়ার্টারে প্রায় ৪০ ঘণ্টা সাশ্রয় করেছে। [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 ব্যবহার করতে পারি? টেকনিক্যালি হ্যাঁ, কিন্তু বাস্তবে না। পাবলিক CAs নির্বিচার ডিভাইসের জন্য ক্লায়েন্ট সার্টিফিকেট ইস্যু করবে না। ক্লায়েন্ট সার্টিফিকেটের জন্য আপনার নিজস্ব CA প্রয়োজন। RADIUS সার্ভার সার্টিফিকেটের জন্য, একটি পাবলিক CA ঠিক আছে এবং ট্রাস্ট বিতরণকে সহজ করে। [medium pause] BYOD-এর কী হবে? BYOD হলো একটি কঠিন ক্ষেত্র। আপনি MDM-এর মাধ্যমে আনম্যানেজড ডিভাইসে সার্টিফিকেট পুশ করতে পারবেন না। বিকল্পগুলোর মধ্যে রয়েছে একটি নেটওয়ার্ক অ্যাক্সেস কন্ট্রোল পোর্টাল যা ব্যবহারকারীর অথেন্টিকেশনের পরে স্বল্পস্থায়ী সার্টিফিকেট ইস্যু করে, অথবা কেবল একটি ভিন্ন অথেন্টিকেশন পদ্ধতি সহ একটি পৃথক SSID-তে BYOD রাখা। [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] পরবর্তী পদক্ষেপ: আপনার বর্তমান সার্টিফিকেট ইনভেন্টরি অডিট করুন। আপনার কতগুলো সার্টিফিকেট আছে, কখন সেগুলোর মেয়াদ শেষ হবে এবং কে সেগুলো ইস্যু করেছে তা যদি আপনি না জানেন, তবে প্রথমে সেটি ঠিক করতে হবে। সেখান থেকে, সম্পূর্ণ অটোমেশনের পথটি সুনির্দিষ্ট। শোনার জন্য ধন্যবাদ।