এন্টারপ্রাইজ SCEP সেটআপ গাইড: উচ্চশিক্ষা এবং বৃহৎ নেটওয়ার্কের জন্য সার্টিফিকেট-ভিত্তিক Wi-Fi অথেন্টিকেশন

Enterprise SCEP Setup Guide: Certificate-Based WiFi Authentication for Higher Education and Large Networks A Purple Technical Briefing - Podcast Script (approximately 10 minutes) --- INTRODUCTION AND CONTEXT - approximately 1 minute Purple Technical Briefing সিরিজে আপনাকে স্বাগত। আমি আজ এমন একটি বিষয় নিয়ে কথা বলছি যা অনেক IT ইনবক্সে আসে কিন্তু খুব কমই সরাসরি উত্তর পাওয়া যায়: কীভাবে আপনি আসলে একটি বড় নেটওয়ার্ক জুড়ে—তা কোনো বিশ্ববিদ্যালয়ের ক্যাম্পাস, একটি মাল্টি-সাইট হোটেল গ্রুপ, বা একটি বড় পাবলিক সেক্টর এস্টেটই হোক না কেন—SCEP ব্যবহার করে স্কেলে সার্টিফিকেট-ভিত্তিক WiFi অথেন্টিকেশন স্থাপন করবেন? আমরা সম্পূর্ণ বিষয়টি কভার করতে যাচ্ছি। SCEP আসলে কী করে, কীভাবে এটি একটি 802.1X আর্কিটেকচারের সাথে খাপ খায়, ডিপ্লয়মেন্ট সিকোয়েন্স যা বেশিরভাগ টিম ভুল করে, দুটি বাস্তব-জগতের ইমপ্লিমেন্টেশন সিনারিও এবং এমন কিছু সমস্যা যা আপনি আগে থেকে পরিকল্পনা না করলে আপনার জীবনের একটি উইকএন্ড নষ্ট করে দেবে। এটি একটি কনসালট্যান্ট ব্রিফিং, কোনো টিউটোরিয়াল নয়। আমি ধরে নিচ্ছি যে আপনি জানেন RADIUS সার্ভার কী এবং আপনি সম্ভবত ইতিমধ্যেই সিদ্ধান্ত নিয়েছেন যে আপনাকে প্রি-শেয়ার্ড কি (pre-shared keys) থেকে সরে আসতে হবে। আপনার এখন যা প্রয়োজন তা হলো ইমপ্লিমেন্টেশন ম্যাপ। চলুন শুরু করা যাক। --- TECHNICAL DEEP-DIVE - approximately 5 minutes তাহলে, প্রথম নীতি। SCEP-এর পূর্ণরূপ হলো Simple Certificate Enrollment Protocol। ২০২০ সালে IETF দ্বারা এটি RFC 8894 হিসেবে আনুষ্ঠানিকভাবে রূপ পায়, যদিও এর আগে এক দশকেরও বেশি সময় ধরে এন্টারপ্রাইজে এর ব্যাপক ব্যবহার ছিল। এর কাজ অত্যন্ত সহজ: কোনো মানুষের স্পর্শ ছাড়াই একটি ম্যানেজড ডিভাইসে ডিজিটাল সার্টিফিকেট পাওয়ার প্রক্রিয়াটিকে স্বয়ংক্রিয় করা। WiFi অথেন্টিকেশনের ক্ষেত্রে, SCEP হলো ডেলিভারি মেকানিজম। আপনি যে আসল অথেন্টিকেশন প্রোটোকলটিকে লক্ষ্য করছেন তা হলো EAP-TLS - Extensible Authentication Protocol with Transport Layer Security - যা 802.1X ফ্রেমওয়ার্কের ভেতরে থাকে। এন্টারপ্রাইজ ওয়্যারলেস নেটওয়ার্কের জন্য EAP-TLS-কে ব্যাপকভাবে সবচেয়ে নিরাপদ অথেন্টিকেশন পদ্ধতি হিসেবে বিবেচনা করা হয় কারণ এর জন্য ক্লায়েন্ট ডিভাইস এবং RADIUS সার্ভার উভয়কেই বৈধ সার্টিফিকেট প্রদর্শন করতে হয়। ক্রিপ্টোগ্রাফিক প্রমাণ ছাড়া কোনো পক্ষই অপর পক্ষকে বিশ্বাস করে না। এই পারস্পরিক অথেন্টিকেশনই আপনাকে ইভিল টুইন অ্যাটাক (evil twin attacks) থেকে রক্ষা করে—যেখানে একজন আক্রমণকারী ক্রেডেনশিয়াল হাতিয়ে নেওয়ার জন্য একটি ক্ষতিকারক অ্যাক্সেস পয়েন্ট তৈরি করে। সম্পূর্ণ চেইনটি যেভাবে কাজ করে তা এখানে দেওয়া হলো। একটি ম্যানেজড ডিভাইস—যেমন একজন শিক্ষার্থীর ল্যাপটপ, স্টাফের ফোন, বা হোটেলের পয়েন্ট-অফ-সেল টার্মিনাল—কর্পোরেট ওয়্যারলেস নেটওয়ার্কে যুক্ত হওয়া প্রয়োজন। আপনার MDM প্ল্যাটফর্ম, যা Microsoft Intune বা Jamf হতে পারে, সেই ডিভাইসে একটি SCEP পে-লোড পাঠায়। পে-লোডে দুটি জিনিস থাকে: SCEP URL, যা আপনার NDES সার্ভার বা ক্লাউড SCEP গেটওয়েকে নির্দেশ করে, এবং একটি চ্যালেঞ্জ পাসওয়ার্ড বা শেয়ার্ড সিক্রেট। ডিভাইসটি স্থানীয়ভাবে নিজস্ব পাবলিক এবং প্রাইভেট কি (key) পেয়ার তৈরি করে। এটি অত্যন্ত গুরুত্বপূর্ণ। প্রাইভেট কি কখনই ডিভাইস থেকে বাইরে যায় না। এটি অন-ডিভাইসে তৈরি হয়, সিকিউর এনক্লেভ বা TPM-এ সংরক্ষিত হয় এবং কখনই নেটওয়ার্কের মাধ্যমে স্থানান্তরিত হয় না। ডিভাইসটি তখন একটি Certificate Signing Request - একটি CSR - তৈরি করে এবং SCEP গেটওয়েতে পাঠায়। গেটওয়ে চ্যালেঞ্জটি যাচাই করে, CSR-টি আপনার Certificate Authority (CA)-তে ফরোয়ার্ড করে এবং CA এটি স্বাক্ষর করে পাবলিক সার্টিফিকেটটি ডিভাইসে ফেরত পাঠায়। সেই মুহূর্ত থেকে, ডিভাইসটি যখন আপনার WiFi SSID-এর সাথে সংযুক্ত হয়, তখন এটি RADIUS সার্ভারের কাছে সেই সার্টিফিকেটটি প্রদর্শন করে। RADIUS সার্ভার আপনার CA-এর ট্রাস্ট চেইনের বিপরীতে সার্টিফিকেটটি যাচাই করে, সার্টিফিকেটটি বাতিল করা হয়েছে কিনা তা নিশ্চিত করতে Certificate Revocation List পরীক্ষা করে এবং সবকিছু ঠিক থাকলে, অ্যাক্সেস পয়েন্টে একটি অ্যাকসেপ্ট মেসেজ পাঠায়। ডিভাইসটি নেটওয়ার্কে যুক্ত হয়ে যায়। সম্পূর্ণ প্রক্রিয়াটি ব্যবহারকারীর কাছে অদৃশ্য থাকে। এখন, বিকল্প পদ্ধতি অর্থাৎ PKCS-এর তুলনায় SCEP-এর অবস্থান নিয়ে কথা বলা যাক। PKCS - Public Key Cryptography Standards - হলো Intune-এর মতো প্ল্যাটফর্ম দ্বারা সমর্থিত অন্য একটি সার্টিফিকেট ডেলিভারি পদ্ধতি। PKCS-এর ক্ষেত্রে, CA কেন্দ্রীয়ভাবে পাবলিক এবং প্রাইভেট কি উভয়ই তৈরি করে এবং সার্টিফিকেট কানেক্টর কি পেয়ারটিকে ডিভাইসে পাঠিয়ে দেয়। এর অর্থ হলো প্রাইভেট কি নেটওয়ার্কের ওপর দিয়ে যাতায়াত করে, যা একটি তাত্ত্বিক অ্যাটাক সারফেস তৈরি করে। S/MIME ইমেল এনক্রিপশনের মতো ব্যবহারের ক্ষেত্রে PKCS ঠিক আছে যেখানে কি এসক্রো (key escrow) আসলে বাঞ্ছনীয়। WiFi অথেন্টিকেশনের জন্য, SCEP-ই সঠিক পছন্দ। প্রাইভেট কি ডিভাইসেই থাকে, ব্যস। এবার আসি হার্ডওয়্যার লেয়ারে। SCEP এবং EAP-TLS হলো ভেন্ডর-নিরপেক্ষ স্ট্যান্ডার্ড, যার অর্থ এগুলো Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet অ্যাক্সেস পয়েন্ট জুড়ে কাজ করে। আপনার RADIUS কনফিগারেশন—তা Windows NPS, FreeRADIUS, বা কোনো ক্লাউড RADIUS সার্ভিসই হোক না কেন—সেখানেই আপনি সার্টিফিকেট ভ্যালিডেশন পলিসি নির্ধারণ করেন এবং অত্যন্ত গুরুত্বপূর্ণভাবে, ডাইনামিক VLAN অ্যাসাইনমেন্ট কনফিগার করেন। ডাইনামিক VLAN হলো সেই উপায় যার মাধ্যমে আপনি পরিচয় অনুযায়ী নেটওয়ার্ককে বিভক্ত করেন। একজন শিক্ষার্থীর ডিভাইস VLAN 20 পায়—শুধুমাত্র ইন্টারনেট অ্যাক্সেস। একজন ফ্যাকাল্টির ডিভাইস VLAN 10 পায়—অভ্যন্তরীণ গবেষণা সিস্টেমে অ্যাক্সেস। একটি ফ্যাসিলিটিজ ম্যানেজমেন্ট ডিভাইস VLAN 30 পায়—বিল্ডিং ম্যানেজমেন্ট সিস্টেমে অ্যাক্সেস। এই সমস্ত কিছুই সার্টিফিকেট অ্যাট্রিবিউট এবং RADIUS পলিসি দ্বারা পরিচালিত হয়, যেখানে প্রতি ডিভাইসে কোনো ম্যানুয়াল হস্তক্ষেপের প্রয়োজন হয় না। আইডেন্টিটি প্রোভাইডার ইন্টিগ্রেশনের জন্য, SCEP সার্টিফিকেট অ্যাট্রিবিউট—বিশেষ করে Subject Alternative Name—Microsoft Entra ID, Okta, বা Google Workspace থেকে ব্যবহারকারীর প্রিন্সিপাল নেম বহন করতে পারে। এটি সার্টিফিকেটটিকে একটি নির্দিষ্ট পরিচয়ের সাথে যুক্ত করে, যার অর্থ হলো যখন আপনি Entra ID-তে একটি অ্যাকাউন্ট নিষ্ক্রিয় করেন এবং MDM ডিভাইসটিকে আন-এনরোল করে, তখন সার্টিফিকেটটি বাতিল হয়ে যায় এবং WiFi অ্যাক্সেস স্বয়ংক্রিয়ভাবে বন্ধ হয়ে যায়। এটি এমন একটি রিভোকেশন সুবিধা যা প্রি-শেয়ার্ড কি কোনোভাবেই দিতে পারে না। --- IMPLEMENTATION RECOMMENDATIONS AND PITFALLS - approximately 2 minutes ঠিক আছে, এবার ডিপ্লয়মেন্ট সিকোয়েন্স নিয়ে কথা বলা যাক, কারণ এখানেই বেশিরভাগ টিম ভুল করে বসে। এই সিকোয়েন্সটি পরিবর্তনযোগ্য নয়: প্রথমে Trusted Root সার্টিফিকেট, দ্বিতীয়ত SCEP সার্টিফিকেট প্রোফাইল, তৃতীয়ত WiFi প্রোফাইল। Intune এবং Jamf উভয়ই প্রোফাইল ডিপেনডেন্সি প্রয়োগ করে। যদি আপনার WiFi প্রোফাইল এমন একটি SCEP সার্টিফিকেটকে নির্দেশ করে যা এখনও ডিভাইসে ডিপ্লয় করা হয়নি, তবে WiFi প্রোফাইলটি একটি রহস্যময় ত্রুটি সহ ব্যর্থ হবে যা দেখতে ভুল কনফিগারেশনের মতো মনে হতে পারে, কিন্তু আসলে এটি কেবল টাইমিংয়ের সমস্যা। দ্বিতীয় সমস্যাটিl হলো গ্রুপ টার্গেটিং। তিনটি প্রোফাইলই - Trusted Root, SCEP, এবং WiFi - অবশ্যই ঠিক একই Azure AD বা Jamf গ্রুপে ডেপ্লয় করতে হবে। যদি SCEP প্রোফাইলটি কোনো ইউজার গ্রুপকে টার্গেট করে এবং WiFi প্রোফাইলটি কোনো ডিভাইস গ্রুপকে টার্গেট করে, তবে Intune এই ডিপেন্ডেন্সি সমাধান করতে পারে না এবং WiFi প্রোফাইলটি Not Applicable হিসেবে দেখাবে। এটি টিমগুলোকে ক্রমাগত সমস্যায় ফেলে। তৃতীয়: NDES সার্ভারের অ্যাক্সেসিবিলিটি। আপনার NDES সার্ভারটি ইন্টারনেট থেকে অ্যাক্সেসযোগ্য হতে হবে যাতে ডিভাইসগুলো অন-সাইটে পৌঁছানোর আগেই এনরোল করতে পারে। এটি করার সঠিক উপায় হলো Azure AD Application Proxy-এর মাধ্যমে, আপনার ফায়ারওয়ালে কোনো হোল তৈরি করে নয়। App Proxy আপনাকে ইনবাউন্ড পোর্ট ছাড়াই নিরাপদ রিমোট অ্যাক্সেস দেয় এবং এনরোলমেন্ট ফ্লোতে Conditional Access পলিসি প্রয়োগ করতে দেয়। চতুর্থ: CRL-এর প্রাপ্যতা। প্রতিবার কোনো ডিভাইস অথেন্টিকেট করার সময় আপনার RADIUS সার্ভার Certificate Revocation List চেক করে। যদি আপনার CRL Distribution Point অনুপলব্ধ থাকে - কোনো সার্ভার ডাউন থাকার কারণে, অথবা URL পরিবর্তিত হওয়ার কারণে - তবে নেটওয়ার্কের প্রতিটি ডিভাইসের জন্য একসাথে অথেন্টিকেশন ব্যর্থ হয়। এটি একটি ক্যাম্পাস-ব্যাপী আউটএজ। আপনার CRL এন্ডপয়েন্টগুলোকে অত্যন্ত নির্ভরযোগ্য (highly available) করুন এবং লাইভ করার আগে রিভোকেশন পরীক্ষা করুন। বড় নেটওয়ার্কের জন্য - ৫০০টির বেশি যেকোনো ডিভাইসের ক্ষেত্রে - অন-প্রিমিসেস NDES-এর পরিবর্তে একটি ক্লাউড SCEP গেটওয়ে বিবেচনা করুন। ক্লাউড গেটওয়েগুলো NDES-এর সিঙ্গেল পয়েন্ট অফ ফেইলিওর দূর করে, হরাইজন্টালি স্কেল করে এবং সাধারণত সরাসরি ক্লাউড RADIUS সার্ভিসের সাথে ইন্টিগ্রেট হয়, যা আরেকটি ইনফ্রাস্ট্রাকচার ডিপেন্ডেন্সি দূর করে। --- র‌্যাপিড-ফায়ার প্রশ্নোত্তর - প্রায় ১ মিনিট SCEP কি এমন BYOD ডিভাইসগুলো হ্যান্ডেল করতে পারে যা MDM-এনরোলড নয়? সরাসরি নয়। সার্টিফিকেট পে-লোড পুশ করার জন্য SCEP-এর MDM এনরোলমেন্ট প্রয়োজন। আনম্যানেজড BYOD-এর জন্য আপনার একটি ভিন্ন পদ্ধতির প্রয়োজন - হয় একটি সেলফ-সার্ভিস অনবোর্ডিং পোর্টাল, অথবা আইডেন্টিটি ভেরিফিকেশন সহ একটি Captive Portal ব্যবহার করে একটি পৃথক SSID। Purple-এর প্ল্যাটফর্ম সেই গেস্ট এবং BYOD লেয়ারটি চমৎকারভাবে হ্যান্ডেল করে, যা আপনার সার্টিফিকেট-অথেন্টিকেটেড স্টাফ নেটওয়ার্কের পাশাপাশি কাজ করে। iOS এবং Android-এর ক্ষেত্রে কী হবে? উভয় প্ল্যাটফর্মই নেটিভভাবে SCEP সাপোর্ট করে। iOS 4 থেকে iOS-এ SCEP সাপোর্ট রয়েছে। Android Enterprise, Intune এবং অন্যান্য MDM-এর মাধ্যমে SCEP সাপোর্ট করে। প্রতিটি প্ল্যাটফর্মের জন্য কনফিগারেশন কিছুটা আলাদা হলেও মূল প্রোটোকলটি অভিন্ন। EAP-TLS কি WPA3-এর সাথে কাজ করে? হ্যাঁ। WPA3-Enterprise সংবেদনশীল পরিবেশের জন্য ১৯২-বিট সিকিউরিটি মোড বাধ্যতামূলক করে এবং EAP-TLS এর সাথে সম্পূর্ণ সামঞ্জস্যপূর্ণ। প্রকৃতপক্ষে, EAP-TLS সহ WPA3-Enterprise হলো সরকারি ও আর্থিক নেটওয়ার্কের জন্য Wi-Fi Alliance দ্বারা সুপারিশকৃত কম্বিনেশন। --- সারসংক্ষেপ এবং পরবর্তী পদক্ষেপ - প্রায় ১ মিনিট সবকিছু একসাথে গুছিয়ে আনতে: ৫০টির বেশি ম্যানেজড ডিভাইস রয়েছে এমন যেকোনো নেটওয়ার্কের জন্য SCEP সার্টিফিকেট WiFi অথেন্টিকেশন হলো সঠিক আর্কিটেকচার। এটি শেয়ার্ড ক্রেডেনশিয়াল দূর করে, আপনাকে প্রতি-ডিভাইস আইডেন্টিটি দেয়, ডায়নামিক VLAN সেগমেন্টেশন সক্ষম করে এবং স্বয়ংক্রিয় রিভোকেশনের জন্য সরাসরি আপনার আইডেন্টিটি প্রোভাইডারের সাথে ইন্টিগ্রেট হয়। ডেপ্লয়মেন্ট সিকোয়েন্স - প্রথমে Trusted Root, তারপর SCEP প্রোফাইল, তারপর WiFi প্রোফাইল - এটি নির্ধারিত। গ্রুপ টার্গেটিং সামঞ্জস্যপূর্ণ হতে হবে। CRL-এর প্রাপ্যতা ঐচ্ছিক নয়। বিশেষ করে উচ্চশিক্ষার জন্য, স্টাফ এবং ফ্যাকাল্টি ডিভাইসের জন্য SCEP-এর কম্বিনেশন এবং ব্যক্তিগত ডিভাইসে থাকা শিক্ষার্থীদের জন্য একটি পৃথক গেস্ট WiFi লেয়ার আপনাকে কোনো আপস ছাড়াই নিরাপত্তা এবং একটি দুর্দান্ত ইউজার এক্সপেরিয়েন্স উভয়ই প্রদান করে। আপনি যদি আরও বিস্তারিত জানতে চান, তবে Active Directory বা অন-প্রিমিসেস সার্ভার ছাড়াই এন্টারপ্রাইজ WiFi অথেন্টিকেশনের বিষয়ে Purple-এর গাইডটি ক্লাউড-নেটিভ পথটি কভার করে। আর কোনো কর্মী চলে গেলে কী ঘটে তা যদি আপনি ভাবছেন, তবে WiFi অ্যাক্সেস রিভোক করার বিষয়ে আমাদের গাইডটি সম্পূর্ণ রিভোকেশন ওয়ার্কফ্লো বিস্তারিত দেখায়। শোনার জন্য ধন্যবাদ। আমি Purple টেকনিক্যাল টিম থেকে বলছি, এবং পরবর্তী ব্রিফিংয়ে আপনার সাথে দেখা হবে। --- স্ক্রিপ্টের সমাপ্তি