মূল কন্টেন্টে যান
বাংলা

কীভাবে স্বয়ংক্রিয় এন্টারপ্রাইজ WiFi সার্টিফিকেট এনরোলমেন্টের জন্য SCEP কনফিগার করবেন

এই নির্দেশিকাটি স্বয়ংক্রিয় এন্টারপ্রাইজ WiFi সার্টিফিকেট এনরোলমেন্টের জন্য SCEP (সিম্পল সার্টিফিকেট এনরোলমেন্ট প্রোটোকল) কীভাবে কনফিগার করতে হয় তা ব্যাখ্যা করে, যা PKI এবং NDES থেকে শুরু করে MDM প্রোফাইল ডিপ্লয়মেন্ট এবং RADIUS ভ্যালিডেশন পর্যন্ত সম্পূর্ণ আর্কিটেকচার কভার করে। এটি মূলত হোটেল, রিটেইল চেইন, স্টেডিয়াম, কনফারেন্স সেন্টার এবং পাবলিক-সেক্টর অর্গানাইজেশনের IT ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট এবং CTO-দের উদ্দেশ্যে তৈরি করা হয়েছে যাদের প্রি-শেয়ার্ড কী-এর বাইরে গিয়ে স্কেলযোগ্য, আইডেন্টিটি-ভিত্তিক 802.1X EAP-TLS অথেন্টিকেশন বাস্তবায়ন করা প্রয়োজন। Purple-এর হার্ডওয়্যার-অ্যাগনস্টিক, ক্লাউড ওভারলে প্ল্যাটফর্ম সরাসরি এই আর্কিটেকচারের সাথে সংহত হয়, যা আপনার সার্টিফিকেট-অথেন্টিকেটেড স্টাফ নেটওয়ার্কের পাশাপাশি গেস্ট এবং BYOD WiFi লেয়ার প্রদান করে।

📖 10 মিনিট পাঠ📝 2,282 শব্দ🔧 2 সমাধানকৃত উদাহরণ❓ 3 অনুশীলনী প্রশ্ন📚 9 মূল সংজ্ঞা

এই গাইডটি শুনুন

পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
Purple Technical Briefing সিরিজে আপনাকে স্বাগত। আজ আমি এমন একটি বিষয় নিয়ে কথা বলছি যা অনেক IT ইনবক্সে আসে কিন্তু খুব কমই এর সরাসরি উত্তর পাওয়া যায়: কীভাবে আপনি আসলে একটি বড় নেটওয়ার্ক জুড়ে SCEP ব্যবহার করে স্কেলে সার্টিফিকেট-ভিত্তিক WiFi অথেন্টিকেশন ডেপ্লয় করবেন। সেটি কোনো বিশ্ববিদ্যালয়ের ক্যাম্পাস, মাল্টি-সাইট হোটেল গ্রুপ বা বড় কোনো পাবলিক সেক্টর এস্টেট যাই হোক না কেন, চ্যালেঞ্জগুলো কিন্তু একই। আমরা সম্পূর্ণ বিষয়টি কভার করতে যাচ্ছি। SCEP আসলে কী করে, কীভাবে এটি একটি 802.1X আর্কিটেকচারের সাথে খাপ খায়, ডেপ্লয়মেন্টের সেই সিকোয়েন্স যা বেশিরভাগ টিম ভুল করে থাকে, দুটি বাস্তব-ক্ষেত্রের ইমপ্লিমেন্টেশন সিনারিও এবং এমন কিছু সমস্যা যা আপনি আগে থেকে পরিকল্পনা না করলে আপনার জীবনের একটি পুরো উইকএন্ড নষ্ট করে দিতে পারে। এটি একটি কনসালট্যান্ট ব্রিফিং, কোনো টিউটোরিয়াল নয়। আমি ধরে নিচ্ছি যে আপনি জানেন RADIUS সার্ভার কী এবং আপনি সম্ভবত ইতিমধ্যেই প্রি-শেয়ার্ড কি (pre-shared keys) থেকে সরে আসার সিদ্ধান্ত নিয়ে নিয়েছেন। আপনার এখন যা প্রয়োজন তা হলো ইমপ্লিমেন্টেশনের একটি ম্যাপ। চলুন শুরু করা যাক। প্রথম নীতি। 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) অ্যাটাক থেকে রক্ষা করে, যেখানে একজন আক্রমণকারী ক্রেডেনশিয়াল হাতিয়ে নেওয়ার জন্য একটি নকল অ্যাক্সেস পয়েন্ট তৈরি করে। সম্পূর্ণ চেইনটি যেভাবে কাজ করে তা এখানে দেওয়া হলো। একটি ম্যানেজড ডিভাইস, যেমন একজন শিক্ষার্থীর ল্যাপটপ, স্টাফদের ফোন বা হোটেলের পয়েন্ট-অফ-সেল টার্মিনালকে কর্পোরেট ওয়্যারলেস নেটওয়ার্কে যুক্ত হতে হবে। আপনার MDM প্ল্যাটফর্ম, যা Microsoft Intune বা Jamf হতে পারে, সেই ডিভাইসে একটি SCEP পে-লোড পুশ করে। পে-লোডে দুটি জিনিস থাকে: SCEP URL, যা আপনার NDES সার্ভার বা ক্লাউড SCEP গেটওয়েকে নির্দেশ করে, এবং একটি চ্যালেঞ্জ পাসওয়ার্ড বা শেয়ার্ড সিক্রেট। ডিভাইসটি স্থানীয়ভাবে নিজস্ব পাবলিক এবং প্রাইভেট কি (key) পেয়ার তৈরি করে। এটি অত্যন্ত গুরুত্বপূর্ণ। প্রাইভেট কি-টি কখনোই ডিভাইস থেকে বাইরে যায় না। এটি ডিভাইসেই তৈরি হয়, সিকিউর এনক্লেভ বা TPM-এ সংরক্ষিত থাকে এবং কখনোই নেটওয়ার্কের মাধ্যমে স্থানান্তরিত হয় না। এরপর ডিভাইসটি একটি সার্টিফিকেট সাইনিং রিকোয়েস্ট (CSR) তৈরি করে এবং সেটি SCEP গেটওয়েতে পাঠায়। গেটওয়ে চ্যালেঞ্জটি যাচাই করে, CSR-টি আপনার সার্টিফিকেট অথরিটির (CA) কাছে পাঠিয়ে দেয় এবং CA এটি সাইন করে পাবলিক সার্টিফিকেটটি ডিভাইসে ফেরত পাঠায়।সেই মুহূর্ত থেকে, যখন ডিভাইসটি আপনার WiFi SSID-এর সাথে সংযুক্ত হয়, এটি RADIUS সার্ভারের কাছে সেই সার্টিফিকেটটি উপস্থাপন করে। RADIUS সার্ভার আপনার CA ট্রাস্ট চেইনের বিপরীতে সার্টিফিকেটটি যাচাই করে, সার্টিফিকেটটি বাতিল করা হয়নি তা নিশ্চিত করতে Certificate Revocation List পরীক্ষা করে, এবং সবকিছু ঠিকঠাক থাকলে, অ্যাক্সেস পয়েন্টে একটি গ্রহণযোগ্য বার্তা পাঠায়। ডিভাইসটি নেটওয়ার্কে যুক্ত হয়ে যায়। সম্পূর্ণ প্রক্রিয়াটি ব্যবহারকারীর কাছে অদৃশ্য থাকে। এখন, আসুন আলোচনা করা যাক বিকল্প পদ্ধতি PKCS-এর তুলনায় SCEP-এর অবস্থান কোথায়। PKCS, বা Public Key Cryptography Standards, হলো Intune-এর মতো প্ল্যাটফর্ম দ্বারা সমর্থিত অন্য একটি সার্টিফিকেট ডেলিভারি পদ্ধতি। PKCS-এর ক্ষেত্রে, CA কেন্দ্রীয়ভাবে পাবলিক এবং প্রাইভেট উভয় কি (key) তৈরি করে, এবং সার্টিফিকেট কানেক্টর কি পেয়ারটিকে ডিভাইসে পুশ করে। এর অর্থ হলো প্রাইভেট কি-টি নেটওয়ার্কের মাধ্যমে স্থানান্তরিত হয়, যা একটি তাত্ত্বিক অ্যাটাক সারফেস তৈরি করে। 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 অ্যাক্সেস স্বয়ংক্রিয়ভাবে বন্ধ হয়ে যায়। এটি এমন একটি বাতিলের গল্প যা প্রি-শেয়ার্ড কি (pre-shared keys) কখনই দিতে পারে না। ঠিক আছে, এবার ডেপ্লয়মেন্ট সিকোয়েন্স বা স্থাপনার ধারাবাহিকতা নিয়ে কথা বলা যাক, কারণ এখানেই বেশিরভাগ টিম ভুল করে বসে। এই ধারাবাহিকতাটি অপরিবর্তনযোগ্য: প্রথমে Trusted Root সার্টিফিকেট, দ্বিতীয়ত SCEP সার্টিফিকেট প্রোফাইল, এবং তৃতীয়ত WiFi প্রোফাইল। Intune এবং Jamf উভয়ই প্রোফাইল ডিপেন্ডেন্সি বা নির্ভরতা প্রয়োগ করে। যদি আপনার WiFi প্রোফাইল এমন একটি SCEP সার্টিফিকেটকে নির্দেশ করে যা এখনও ডিভাইসে ডেপ্লয় করা হয়নি, তবে WiFi প্রোফাইলটি একটি রহস্যময় ত্রুটি সহ ব্যর্থ হবে যা দেখতে ভুল কনফিগারেশনের মতো মনে হলেও আসলে এটি কেবল টাইমিংয়ের একটি সমস্যা। দ্বিতীয় সমস্যাটি হলো গ্রুপ টার্গেটিং। তিনটি প্রোফাইলই—Trusted Root, SCEP, এবং WiFi—অবশ্যই হুবহু একই Azure AD বা Jamf গ্রুপে ডেপ্লয় করতে হবে। যদি SCEP প্রোফাইলটি কোনো ইউজার গ্রুপকে টার্গেট করে এবং WiFi প্রোফাইলটি কোনো ডিভাইস গ্রুপকে টার্গেট করে, তবে Intune এই ডিপেন্ডেন্সি সমাধান করতে পারে না এবং WiFi প্রোফাইলটি Not Applicable হিসেবে দেখাবে। এটি দলগুলোকে ক্রমাগত বিপদে ফেলে। তৃতীয়ত: NDES সার্ভারের অ্যাক্সেসিবিলিটি। আপনার NDES সার্ভারটি ইন্টারনেট থেকে অ্যাক্সেসযোগ্য হওয়া প্রয়োজন যাতে ডিভাইসগুলো অন-সাইটে পৌঁছানোর আগেই এনরোল করতে পারে। এটি করার সঠিক উপায় হলো Azure AD Application Proxy-এর মাধ্যমে, আপনার ফায়ারওয়ালে কোনো পোর্ট না খুলে। App Proxy আপনাকে ইনবাউন্ড পোর্ট ছাড়াই নিরাপদ রিমোট অ্যাক্সেস দেয় এবং এনরোলমেন্ট ফ্লোতে কন্ডিশনাল অ্যাক্সেস পলিসি প্রয়োগ করতে দেয়। চতুর্থত: CRL-এর প্রাপ্যতা। প্রতিবার কোনো ডিভাইস অথেন্টিকেট করার সময় আপনার RADIUS সার্ভার Certificate Revocation List চেক করে। যদি কোনো সার্ভার ডাউন থাকার কারণে বা URL পরিবর্তন হওয়ার কারণে আপনার CRL ডিস্ট্রিবিউশন পয়েন্ট অনুপলব্ধ হয়, তবে নেটওয়ার্কের প্রতিটি ডিভাইসের জন্য একসাথে অথেন্টিকেশন ব্যর্থ হবে। এটি একটি ক্যাম্পাস-ব্যাপী বিভ্রাট। আপনার CRL এন্ডপয়েন্টগুলোকে অত্যন্ত নির্ভরযোগ্য (highly available) করুন এবং লাইভ করার আগে রিভোকেশন পরীক্ষা করুন। বড় নেটওয়ার্কের জন্য, যা ৫০০-এর বেশি ডিভাইসের, অন-প্রিমিসেস NDES-এর পরিবর্তে একটি ক্লাউড SCEP গেটওয়ের কথা বিবেচনা করুন। ক্লাউড গেটওয়েগুলো NDES-এর সিঙ্গেল পয়েন্ট অফ ফেইলিওর দূর করে, অনুভূমিকভাবে স্কেল করে এবং সাধারণত সরাসরি ক্লাউড RADIUS সার্ভিসের সাথে একীভূত হয়, যা আরেকটি ইনফ্রাস্ট্রাকচার ডিপেন্ডেন্সি দূর করে। আসুন আমরা CTO-দের কাছ থেকে প্রায়শই শোনা কয়েকটি দ্রুত প্রশ্নের সমাধান করি। 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 লেয়ার, আপনাকে কোনো আপস ছাড়াই নিরাপত্তা এবং একটি দুর্দান্ত ব্যবহারকারীর অভিজ্ঞতা উভয়ই প্রদান করে। আপনি যদি আরও বিস্তারিত জানতে চান, তাহলে এন্টারপ্রাইজ WiFi অথেন্টিকেশন সংক্রান্ত Purple-এর গাইডটি ক্লাউড-নেটিভ পাথ কভার করে। আর কোনো কর্মী চলে গেলে কী ঘটে তা নিয়ে যদি আপনি ভাবছেন, তবে WiFi অ্যাক্সেস প্রত্যাহার করার বিষয়ে আমাদের গাইডটি সম্পূর্ণ রেভোকেশন ওয়ার্কফ্লো বিশদভাবে ব্যাখ্যা করে। শোনার জন্য ধন্যবাদ। আমি Purple টেকনিক্যাল টিম থেকে বলছি, এবং পরবর্তী ব্রিফিংয়ে আপনার সাথে দেখা হবে।

header_image.png

কার্যনির্বাহী সংক্ষিপ্তসার (Executive summary)

এন্টারপ্রাইজ ভেন্যুগুলোর জন্য - তা ২০০ কক্ষের হোটেল হোক, ৫০টি সাইটের রিটেইল চেইন হোক বা কোনো বড় কনফারেন্স সেন্টার হোক - কর্মীদের WiFi-এর জন্য প্রি-শেয়ার্ড কী-এর ওপর নির্ভর করা একটি নিরাপত্তা ঝুঁকি এবং অপারেশনাল বাধা। একটিমাত্র পাসওয়ার্ড ফাঁস হলে পুরো নেটওয়ার্ক ঝুঁকির মুখে পড়ে। IEEE 802.1X এবং EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)-এর মাধ্যমে সার্টিফিকেট-ভিত্তিক অথেন্টিকেশন এই ঝুঁকি সম্পূর্ণভাবে দূর করে। অ্যাক্সেস পয়েন্ট নেটওয়ার্ক অ্যাক্সেস দেওয়ার আগে প্রতিটি ডিভাইস ক্রিপ্টোগ্রাফিকভাবে তার পরিচয় প্রমাণ করে।

আসল চ্যালেঞ্জ হলো এটি বিতরণ করা। হাজার হাজার Windows, iOS, এবং Android ডিভাইসে ম্যানুয়ালি ইউনিক ক্লায়েন্ট সার্টিফিকেট স্থাপন করা সম্ভব নয়। SCEP (Simple Certificate Enrollment Protocol), যা ২০২০ সালে IETF দ্বারা RFC 8894 হিসেবে আনুষ্ঠানিকভাবে রূপ দেওয়া হয়েছে, এই সমস্যার সমাধান করে। এটি আপনার MDM প্ল্যাটফর্মের মাধ্যমে কোনো ব্যবহারকারীর হস্তক্ষেপ ছাড়াই ম্যানেজড ডিভাইসগুলোতে ডিজিটাল সার্টিফিকেট অনুরোধ, ইস্যু এবং ইনস্টল করার প্রক্রিয়াটিকে স্বয়ংক্রিয় করে।

এই গাইডটিতে সম্পূর্ণ আর্কিটেকচার কভার করা হয়েছে: SCEP কী করে, কীভাবে এটি Microsoft Intune, Jamf এবং অন্যান্য MDM প্ল্যাটফর্মের সাথে একীভূত হয়, সঠিক ডিপ্লয়মেন্ট সিকোয়েন্স যা বেশিরভাগ টিম ভুল করে এবং অপারেশনাল ত্রুটিগুলো যা বিভ্রাটের কারণ হয়। আমরা হসপিটালিটি এবং রিটেইল খাতের দুটি বাস্তবসম্মত ইমপ্লিমেন্টেশন সিনারিও কভার করেছি এবং আপনার সার্টিফিকেট-অথেন্টিকেটেড স্টাফ নেটওয়ার্কের পাশাপাশি Purple-এর Guest WiFi প্ল্যাটফর্মটি কীভাবে মানানসই হয় তা ব্যাখ্যা করেছি।

সহযোগী পডকাস্ট ব্রিফিংটি শুনুন:

টেকনিক্যাল ডিপ-ডাইভ: SCEP, PKI, এবং 802.1X

SCEP আসলে কী করে

SCEP আপনার Public Key Infrastructure (PKI)-এর বিকল্প নয়। এটি হলো স্বয়ংক্রিয় এনরোলমেন্ট লেয়ার যা এর ওপর কাজ করে। আপনার PKI - সাধারণত একটি অফলাইন রুট CA এবং একটি অনলাইন ইস্যুয়িং CA সহ একটি দ্বি-স্তর বিশিষ্ট হায়ারার্কি - ট্রাস্ট অ্যাঙ্কর হিসেবে কাজ করে। SCEP সেই CA থেকে একটি ডিভাইসের সার্টিফিকেটের অনুরোধ করার প্রক্রিয়াটিকে স্বয়ংক্রিয় করে, যার ফলে ম্যানুয়াল CSR জেনারেশন এবং সার্টিফিকেট ইনস্টলেশনের প্রয়োজন হয় না।

WiFi অথেন্টিকেশনের ক্ষেত্রে, টার্গেট প্রোটোকল হলো EAP-TLS। এটি হলো 802.1X অথেন্টিকেশন পদ্ধতি যার জন্য ক্লায়েন্ট ডিভাইস এবং RADIUS সার্ভার উভয়কেই বৈধ X.509 সার্টিফিকেট প্রদর্শন করতে হয়। ক্রিপ্টোগ্রাফিক প্রমাণ ছাড়া কোনো পক্ষই অপর পক্ষকে বিশ্বাস করে না। এই পারস্পরিক অথেন্টিকেশন মডেলটি ক্রেডেনশিয়াল চুরি রোধ করে এবং ইভিল টুইন অ্যাটাক থেকে রক্ষা করে, যেখানে আক্রমণকারী ইউজারনেম এবং পাসওয়ার্ড হাতিয়ে নেওয়ার জন্য একটি ক্ষতিকারক অ্যাক্সেস পয়েন্ট তৈরি করে।

EAP-TLS হ্যান্ডশেকের বিস্তারিত বিবরণের জন্য, আমাদের এই গাইডটি দেখুন WiFi Certificate Authentication: Secure Network Access ।

scep_architecture_overview.png

ধাপে ধাপে SCEP এনরোলমেন্ট ফ্লো

সম্পূর্ণ এনরোলমেন্ট চেইনটি যেভাবে কাজ করে তা নিচে দেওয়া হলো। আপনার MDM প্ল্যাটফর্ম - Microsoft Intune, Jamf, বা অন্য কোনো MDM - একটি ম্যানেজড ডিভাইসে SCEP পে-লোড পুশ করে। সেই পে-লোডে দুটি জিনিস থাকে: আপনার NDES (Network Device Enrollment Service) সার্ভার বা ক্লাউড SCEP গেটওয়েকে নির্দেশকারী SCEP URL এবং একটি চ্যালেঞ্জ পাসওয়ার্ড বা শেয়ার্ড সিক্রেট।

ডিভাইসটি স্থানীয়ভাবে নিজস্ব পাবলিক এবং প্রাইভেট কী পেয়ার তৈরি করে। এটি SCEP-এর একটি অত্যন্ত গুরুত্বপূর্ণ নিরাপত্তা বৈশিষ্ট্য: প্রাইভেট কী-টি অন-ডিভাইসে তৈরি হয়, সিকিউর এনক্লেভ বা TPM চিপে সংরক্ষিত থাকে এবং কখনোই নেটওয়ার্কের মাধ্যমে স্থানান্তরিত হয় না। এরপর ডিভাইসটি একটি Certificate Signing Request (CSR) তৈরি করে এবং SCEP গেটওয়েতে পাঠায়। গেটওয়ে চ্যালেঞ্জ পাসওয়ার্ডটি যাচাই করে, CSR-টি আপনার Certificate Authority-র কাছে ফরোয়ার্ড করে এবং CA এটি সাইন করে পাবলিক সার্টিফিকেটটি ডিভাইসে ফেরত পাঠায়।

সেই মুহূর্ত থেকে, ডিভাইসটি যখন আপনার WiFi SSID-এর সাথে সংযুক্ত হয়, তখন এটি RADIUS সার্ভারের কাছে সেই সার্টিফিকেটটি উপস্থাপন করে। RADIUS সার্ভার আপনার CA ট্রাস্ট চেইনের বিপরীতে সার্টিফিকেটটি যাচাই করে, সার্টিফিকেটটি বাতিল করা হয়েছে কিনা তা নিশ্চিত করতে Certificate Revocation List (CRL) পরীক্ষা করে এবং সবকিছু ঠিক থাকলে অ্যাক্সেস পয়েন্টে একটি Access-Accept মেসেজ পাঠায়। ডিভাইসটি নেটওয়ার্কে সংযুক্ত হয়ে যায়। সম্পূর্ণ প্রক্রিয়াটি ব্যবহারকারীর কাছে সম্পূর্ণ অদৃশ্য থাকে।

SCEP বনাম PKCS: WiFi-এর জন্য কোনটি ব্যবহার করবেন

Intune-এর মতো MDM প্ল্যাটফর্মগুলো দুটি সার্টিফিকেট ডেলিভারি মেকানিজম সমর্থন করে: SCEP এবং PKCS (Public Key Cryptography Standards)। এগুলোর আর্কিটেকচারাল পার্থক্য বেশ উল্লেখযোগ্য।

SCEP-এর ক্ষেত্রে, প্রাইভেট কী-টি ডিভাইসেই তৈরি হয় এবং এটি কখনোই ডিভাইস থেকে বাইরে যায় না। PKCS-এর ক্ষেত্রে, Certificate Authority কেন্দ্রীয়ভাবে পাবলিক এবং প্রাইভেট কী উভয়ই তৈরি করে এবং সার্টিফিকেট কানেক্টর নেটওয়ার্কের মাধ্যমে কী পেয়ারটি ডিভাইসে পুশ করে। এর অর্থ হলো প্রাইভেট কী-টি স্থানান্তরিত হয়, যা একটি তাত্ত্বিক অ্যাটাক সারফেস তৈরি করে।

PKCS এমন সব ব্যবহারের ক্ষেত্রে উপযুক্ত যেখানে কী এসক্রো (key escrow) প্রয়োজন, যেমন S/MIME ইমেল এনক্রিপশন। WiFi অথেন্টিকেশনের জন্য, SCEP-ই সঠিক পছন্দ। প্রাইভেট কী ডিভাইসেই থাকে।

বৈশিষ্ট্য SCEP PKCS
প্রাইভেট কী জেনারেশন অন-ডিভাইস (TPM/Secure Enclave) সেন্ট্রালাইজড (CA)
প্রাইভেট কী ট্রান্সমিশন কখনোই নয় নেটওয়ার্কের মাধ্যমে
NDES সার্ভার প্রয়োজন হ্যাঁ (অথবা ক্লাউড গেটওয়ে) না
WiFi-এর জন্য প্রস্তাবিত হ্যাঁ না
S/MIME-এর জন্য প্রস্তাবিত না হ্যাঁ

হার্ডওয়্যার সামঞ্জস্যতা

SCEP এবং EAP-TLS হলো ভেন্ডর-নিরপেক্ষ স্ট্যান্ডার্ড। এগুলো Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet অ্যাক্সেস পয়েন্ট জুড়ে কাজ করে। আপনার RADIUS কনফিগারেশন - তা Windows NPS, FreeRADIUS বা কোনো ক্লাউড RADIUS পরিষেবাই হোক না কেন - সেখানেই আপনি সার্টিফিকেট যাচাইকরণ নীতি এবং ডাইনামিক VLAN অ্যাসাইনমেন্ট নির্ধারণ করেন।

ডাইনামিক VLAN অ্যাসাইনমেন্টের মাধ্যমেই আপনি ডিভাইসের পরিচয় অনুযায়ী নেটওয়ার্ককে বিভক্ত করেন। একজন কর্মীর ডিভাইস VLAN 10 পায় যার মাধ্যমে অভ্যন্তরীণ সিস্টেমে অ্যাক্সেস পাওয়া যায়। একজন ঠিকাদারের ডিভাইস VLAN 20 পায় যাতে শুধুমাত্র ইন্টারনেট অ্যাক্সেস থাকে। একটি পয়েন্ট-অফ-সেল টার্মিনাল VLAN 30 পায় যাতে শুধুমাত্র পেমেন্ট প্রসেসিং সিস্টেমে অ্যাক্সেস থাকে। এই সমস্ত কিছুই সার্টিফিকেট অ্যাট্রিবিউট এবং RADIUS নীতি দ্বারা পরিচালিত হয়, যেখানে প্রতি ডিভাইসের জন্য কোনো ম্যানুয়াল হস্তক্ষেপের প্রয়োজন হয় না।

কীভাবে WiFi Analytics পরিচয়-ভিত্তিক নেটওয়ার্ক বিভাজনের সাথে একীভূত হয় সে সম্পর্কে আরও জানতে, আমাদের অ্যানালিটিক্স প্ল্যাটফর্মের ওভারভিউ দেখুন।

ইমপ্লিমেন্টেশন গাইড: ডেপ্লয়মেন্ট সিকোয়েন্স

এন্টারপ্রাইজ WiFi-এর জন্য SCEP সফলভাবে কনফিগার করার জন্য একটি নির্দিষ্ট ডেপ্লয়মেন্ট সিকোয়েন্স কঠোরভাবে মেনে চলা প্রয়োজন। MDM প্ল্যাটফর্মগুলো প্রোফাইল ডিপেন্ডেন্সি প্রয়োগ করে: একটি WiFi প্রোফাইল যা একটি SCEP সার্টিফিকেটকে নির্দেশ করে, সেটি ডিভাইসে সেই সার্টিফিকেটটি উপস্থিত না হওয়া পর্যন্ত প্রযোজ্য হতে পারে না। এই সিকোয়েন্স লঙ্ঘন করা হলো ডেপ্লয়মেন্ট ব্যর্থ হওয়ার সবচেয়ে সাধারণ কারণ।

সিকোয়েন্সটি হলো: প্রথমে Trusted Root, দ্বিতীয়ত SCEP প্রোফাইল, তৃতীয়ত WiFi প্রোফাইল। এই ক্রমটি অপরিবর্তনীয়।

deployment_checklist_infographic.png

ধাপ ১: Trusted Root Certificate প্রোফাইল ডেপ্লয় করুন

যেকোনো ডিভাইস ক্লায়েন্ট সার্টিফিকেটের জন্য অনুরোধ করার বা আপনার RADIUS সার্ভারকে বিশ্বাস করার আগে, সেটিকে অবশ্যই ইস্যুকারী Certificate Authority-কে বিশ্বাস করতে হবে। আপনার Root CA সার্টিফিকেট - এবং যেকোনো Intermediate CA সার্টিফিকেট - .cer ফাইল হিসেবে এক্সপোর্ট করুন। আপনার MDM অ্যাডমিন সেন্টারে, একটি Trusted Certificate প্রোফাইল তৈরি করুন, .cer ফাইলটি আপলোড করুন এবং এটি আপনার টার্গেট ডিভাইস গ্রুপে ডেপ্লয় করুন।

আপনার যদি একটি টু-টিয়ার PKI হায়ারার্কি (সুপারিশকৃত) থাকে, তবে আপনার MDM প্ল্যাটফর্মের ওপর ভিত্তি করে আপনাকে root CA এবং ইস্যুকারী CA সার্টিফিকেট উভয়কেই আলাদা Trusted Certificate প্রোফাইল হিসেবে অথবা একটি একক প্রোফাইলে চেইন হিসেবে ডেপ্লয় করতে হবে।

ধাপ ২: SCEP Certificate প্রোফাইল কনফিগার করুন

একবার ট্রাস্ট প্রতিষ্ঠিত হয়ে গেলে, ডিভাইসগুলো কীভাবে তাদের ক্লায়েন্ট সার্টিফিকেট পাবে তা নির্দেশ করতে SCEP প্রোফাইলটি কনফিগার করুন।

একটি নতুন কনফিগারেশন প্রোফাইল তৈরি করুন এবং SCEP সার্টিফিকেট প্রোফাইল টাইপটি নির্বাচন করুন। Subject নামের ফরম্যাট কনফিগার করুন। ব্যবহারকারী-চালিত প্রমাণীকরণের জন্য, CN={{UserPrincipalName}} হলো স্ট্যান্ডার্ড। ডিভাইস প্রমাণীকরণের জন্য (শেয়ার্ড ডিভাইস, IoT, POS টার্মিনাল), CN={{AAD_Device_ID}} ব্যবহার করুন। Key usage-কে Digital signature এবং Key encipherment-এ সেট করুন। Extended Key Usage-কে Client Authentication (OID: 1.3.6.1.5.5.7.3.2)-এ সেট করুন। এই প্রোফাইলটিকে ধাপ ১-এ তৈরি করা Trusted Root সার্টিফিকেট প্রোফাইলের সাথে লিঙ্ক করুন। আপনার NDES সার্ভারের এক্সটার্নাল URL প্রদান করুন। বিশেষ করে Microsoft Intune-এর জন্য, রিমোট ডিভাইসগুলো অন-সাইটে আসার আগেই যাতে এনরোল করতে পারে, সেজন্য NDES সার্ভারটি অবশ্যই Azure AD Application Proxy-র মাধ্যমে পাবলিশ করতে হবে। NDES-কে সরাসরি ইন্টারনেটের কাছে এক্সপোজ করবেন না।

ধাপ ৩: 802.1X WiFi প্রোফাইল ডেপ্লয় করুন

চূড়ান্ত ধাপ হলো WiFi কনফিগারেশন পুশ করা যা সার্টিফিকেটগুলোকে নেটওয়ার্ক SSID-এর সাথে যুক্ত করে। একটি Wi-Fi কনফিগারেশন প্রোফাইল তৈরি করুন। আপনার অ্যাক্সেস পয়েন্টগুলো যেভাবে নেটওয়ার্কের নাম (SSID) ব্রডকাস্ট করছে, ঠিক সেভাবেই সেটি লিখুন। সিকিউরিটি টাইপ হিসেবে WPA2-Enterprise বা WPA3-Enterprise সিলেক্ট করুন। EAP টাইপটি EAP-TLS-এ সেট করুন। অথেন্টিকেশন সেটিংসে, ক্লায়েন্ট অথেন্টিকেশন সার্টিফিকেট হিসেবে ধাপ ২-এ তৈরি করা SCEP সার্টিফিকেট প্রোফাইলটি সিলেক্ট করুন। সার্ভার ভ্যালিডেশনের জন্য Trusted Root সার্টিফিকেটটি নির্দিষ্ট করুন - এটি নিশ্চিত করে যে ডিভাইসটি শুধুমাত্র আপনার বৈধ RADIUS সার্ভারের সাথেই কানেক্ট হবে, কোনো অননুমোদিত অ্যাক্সেস পয়েন্টের সাথে নয়।

আইডেন্টিটি প্রোভাইডার ইন্টিগ্রেশন

SCEP সার্টিফিকেটের অ্যাট্রিবিউটগুলো - বিশেষ করে Subject Alternative Name (SAN) - Microsoft Entra ID, Okta, বা Google Workspace থেকে ইউজারের প্রিন্সিপাল নাম বহন করতে পারে। এটি সার্টিফিকেটটিকে একটি নির্দিষ্ট আইডেন্টিটির সাথে যুক্ত করে। আপনি যখন Entra ID-তে একটি অ্যাকাউন্ট ডিজেবল করেন এবং MDM ডিভাইসটিকে আন-এনরোল করে, তখন সার্টিফিকেটটি রিভোক হয়ে যায় এবং WiFi অ্যাক্সেস স্বয়ংক্রিয়ভাবে বন্ধ হয়ে যায়। এই স্বয়ংক্রিয় রিভোকেশন হলো এমন একটি সিকিউরিটি সুবিধা যা প্রি-শেয়ার্ড কি (pre-shared keys) কখনোই দিতে পারে না।

PEAP-MSCHAPv2 মাইগ্রেশন পাথসহ EAP Method WiFi: A Guide to Secure Network Access সম্পর্কে আরও জানতে, আমাদের ডেডিকেটেড গাইডটি দেখুন।

সেরা অনুশীলন এবং ইন্ডাস্ট্রির স্ট্যান্ডার্ডসমূহ

NDES সার্ভার প্লেসমেন্ট

NDES সার্ভারটি অবশ্যই ইন্টারনেট থেকে অ্যাক্সেসযোগ্য হতে হবে যাতে ডিভাইসগুলো অন-সাইটে আসার আগেই এনরোল করতে পারে। Azure AD Application Proxy-র মাধ্যমে NDES URL-টি পাবলিশ করুন। এটি ইনবাউন্ড ফায়ারওয়াল পোর্ট না খুলেই নিরাপদ রিমোট অ্যাক্সেস প্রদান করে এবং আপনাকে এনরোলমেন্ট ফ্লোতে কন্ডিশনাল অ্যাক্সেস পলিসি প্রয়োগ করার অনুমতি দেয়। NDES-কে কখনোই সরাসরি ইন্টারনেটের কাছে এক্সপোজ করবেন না।

৫০০-এর বেশি ম্যানেজড ডিভাইস রয়েছে এমন নেটওয়ার্কের জন্য, অন-প্রিমিসেস NDES-এর পরিবর্তে একটি ক্লাউড SCEP গেটওয়ে ব্যবহারের কথা বিবেচনা করুন। ক্লাউড গেটওয়েগুলো NDES-এর সিঙ্গেল পয়েন্ট অফ ফেইলিওর দূর করে, হরাইজন্টালি স্কেল করে এবং সাধারণত সরাসরি ক্লাউড RADIUS সার্ভিসের সাথে ইন্টিগ্রেট হয়।

CRL-এর প্রাপ্যতা

প্রতিবার কোনো ডিভাইস অথেন্টিকেট করার সময় আপনার RADIUS সার্ভারটি Certificate Revocation List চেক করে। কোনো সার্ভার ডাউন থাকার কারণে বা URL পরিবর্তন হওয়ার কারণে যদি আপনার CRL Distribution Point (CDP) অনুপলব্ধ থাকে - তবে নেটওয়ার্কের প্রতিটি ডিভাইসের অথেন্টিকেশন একসাথে ব্যর্থ হবে। কঠোরভাবে CRL চেকিং কার্যকর করতে আপনার NPS বা RADIUS সার্ভার কনফিগার করুন এবং আপনার CRL এন্ডপয়েন্টগুলোকে হাইলি অ্যাভেইলেবল রাখুন। লাইভ করার আগে রিভোকেশন পরীক্ষা করুন।

PCI DSS 4.0-এর Requirement 8.6 অনুযায়ী কার্ডহোল্ডার ডেটা এনভায়রনমেন্টের জন্য নেটওয়ার্ক লেয়ারে মাল্টি-ফ্যাক্টর অথেন্টিকেশন বাধ্যতামূলক। SCEP-প্রোভিশনড সার্টিফিকেটসহ EAP-TLS Retail এবং Hospitality এনভায়রনমেন্টে ওয়্যারলেস নেটওয়ার্কের জন্য এই প্রয়োজনীয়তা পূরণ করে।

WPA3 সামঞ্জস্যতা

EAP-TLS সম্পূর্ণরূপে WPA3-Enterprise-এর সাথে সামঞ্জস্যপূর্ণ। ১৯২-বিট সিকিউরিটি স্যুট (স্যুট বি) সহ WPA3-Enterprise-এ EAP-TLS বাধ্যতামূলক এবং এটি সরকারি, আর্থিক এবং স্বাস্থ্যসেবা নেটওয়ার্কের জন্য Wi-Fi Alliance দ্বারা সুপারিশকৃত একটি কম্বিনেশন। আপনি যদি কঠোর কমপ্লায়েন্স প্রয়োজনীয়তা সহ Healthcare বা Transport পরিবেশে ডেপ্লয় করেন, তবে EAP-TLS সহ WPA3-Enterprise হলো সঠিক টার্গেট আর্কিটেকচার।

BYOD এবং গেস্ট WiFi

সার্টিফিকেট পে-লোড পুশ করার জন্য SCEP-এর ক্ষেত্রে MDM এনরোলমেন্ট প্রয়োজন। এটি আনম্যানেজড BYOD ডিভাইস বা গেস্টদের কভার করে না। সেইসব ব্যবহারের ক্ষেত্রে, আপনার একটি Captive Portal এবং আইডেন্টিটি ভেরিফিকেশন সহ একটি পৃথক SSID প্রয়োজন। Purple-এর প্ল্যাটফর্ম সেই লেয়ারটি নিখুঁতভাবে পরিচালনা করে, যা আপনার সার্টিফিকেট-অথেন্টিকেটেড স্টাফ নেটওয়ার্কের পাশাপাশি কাজ করে। আমাদের Guest WiFi প্ল্যাটফর্ম কনশিয়াস-চয়েস অপ্ট-ইন, ফার্স্ট-পার্টি ডেটা ক্যাপচার এবং আইডেন্টিটি ভেরিফিকেশনের জন্য Microsoft Entra ID, Okta এবং Google Workspace-এর সাথে ইন্টিগ্রেশন সমর্থন করে।

ট্রাবলশুটিং এবং ঝুঁকি প্রশমন

WiFi প্রোফাইল প্রয়োগ করতে ব্যর্থ

লক্ষণ: ডিভাইসটি ট্রাস্টেড রুট এবং SCEP সার্টিফিকেট গ্রহণ করে, কিন্তু MDM-এ WiFi প্রোফাইলটি Error বা Not Applicable হিসেবে দেখায়।

মূল কারণ: গ্রুপ টার্গেটিং অমিল। যদি SCEP প্রোফাইলটি কোনো User গ্রুপকে টার্গেট করে এবং WiFi প্রোফাইলটি কোনো Device গ্রুপকে টার্গেট করে, তবে MDM এই ডিপেন্ডেন্সি সমাধান করতে পারে না।

সমাধান: আপনার অ্যাসাইনমেন্টগুলো অডিট করুন। ট্রাস্টেড রুট, SCEP এবং WiFi প্রোফাইলগুলো সব ঠিক একই ডিরেক্টরি গ্রুপকে টার্গেট করছে কিনা তা নিশ্চিত করুন।

NDES 403 Forbidden ত্রুটি

লক্ষণ: ডিভাইসগুলো SCEP সার্টিফিকেট রিট্রিভ করতে ব্যর্থ হয়। NDES IIS লগগুলোতে HTTP 403 ত্রুটি দেখায়।

মূল কারণ: MDM সার্টিফিকেট কানেক্টর সার্ভিস অ্যাকাউন্টে সার্টিফিকেট টেমপ্লেটের Read এবং Enroll পারমিশন নেই, অথবা ফায়ারওয়াল URL ফিল্টারিং SCEP কোয়েরি স্ট্রিং প্যারামিটারগুলোকে ব্লক করছে।

সমাধান: কানেক্টর অ্যাকাউন্টে CA টেমপ্লেটের Read এবং Enroll পারমিশন আছে কিনা তা যাচাই করুন। ?operation=GetCACaps ধারণকারী URLগুলো ব্লক করা হচ্ছে না তা নিশ্চিত করতে ফায়ারওয়াল লগগুলো পরীক্ষা করুন।

CRL মেয়াদ শেষ হওয়ার পর ব্যাপক অথেন্টিকেশন ব্যর্থতা

লক্ষণ: নেটওয়ার্কের সমস্ত ডিভাইস একসাথে অথেন্টিকেট হতে ব্যর্থ হয়।

মূল কারণ: CRL-এর মেয়াদ শেষ হয়ে গেছে অথবা CDP URL-এ পৌঁছানো যাচ্ছে না। RADIUS সার্ভার সার্টিফিকেটগুলো বৈধ কিনা তা নিশ্চিত করতে পারে না এবং কানেকশন বন্ধ করে দেয়।

সমাধান: CRL মনিটরিং এবং অ্যালার্টিং কনফিগার করুন। পাবলিকেশন ইন্টারভালের চেয়ে উল্লেখযোগ্যভাবে দীর্ঘ মেয়াদের বৈধতা সহ CRL প্রকাশ করুন। গো-লাইভ করার আগে RADIUS সার্ভার থেকে CDP রিচিবিলিটি পরীক্ষা করুন।

সার্টিফিকেটের মেয়াদ শেষ হওয়ার কারণে নীরব ব্যর্থতা

লক্ষণ: নির্দিষ্ট ডিভাইসগুলো কোনো স্পষ্ট প্যাটার্ন ছাড়াই মাঝে মাঝে কানেক্ট হতে ব্যর্থ হয়।

মূল কারণ: ক্লায়েন্ট সার্টিফিকেটের মেয়াদ শেষ হয়ে গেছে এবং MDM সফলভাবে সেগুলো রিনিউ করতে পারেনি।

সমাধান: সার্টিফিকেটের লাইফটাইমের ৮০% পূর্ণ হলে সার্টিফিকেট রিনিউয়াল ট্রিগার করার জন্য কনফিগার করুন। সার্টিফিকেট ত্রুটি থাকা ডিভাইসগুলোর জন্য MDM এনরোলমেন্ট স্ট্যাটাস রিপোর্ট মনিটর করুন। আপনার ডিভাইস রিফ্রেশ সাইকেলের সাথে মানানসই সার্টিফিকেটের বৈধতার মেয়াদ নির্ধারণ করুন - সাধারণত ম্যানেজড এন্ডপয়েন্টগুলোর জন্য এক থেকে দুই বছর।

ROI এবং ব্যবসায়িক প্রভাব

SCEP-ভিত্তিক 802.1X সার্টিফিকেট অথেন্টিকেশনে রূপান্তর নিরাপত্তা, অপারেশন এবং কমপ্লায়েন্স জুড়ে পরিমাপযোগ্য রিটার্ন প্রদান করে।

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

নিরাপত্তা ব্যবস্থা: EAP-TLS ক্রেডেনশিয়াল হার্ভেস্টিং এবং ম্যান-ইন-দ্য-মিডল আক্রমণ দূর করে। এটি রিটেইল এবং হসপিটালিটি নেটওয়ার্কের জন্য PCI DSS 4.0 কমপ্লায়েন্স এবং উপযুক্ত প্রযুক্তিগত নিরাপত্তা ব্যবস্থার জন্য GDPR-এর ধারা ৩২-এর প্রয়োজনীয়তাগুলোকে সরাসরি সমর্থন করে।

স্বয়ংক্রিয় প্রত্যাহার: যখন কোনো কর্মচারী চলে যান, তখন Microsoft Entra ID-তে তাদের অ্যাকাউন্ট নিষ্ক্রিয় করার সাথে সাথে স্বয়ংক্রিয়ভাবে সার্টিফিকেট প্রত্যাহার এবং MDM আনএনরোলমেন্ট শুরু হয়। নেটওয়ার্ক টিমের কোনো ম্যানুয়াল হস্তক্ষেপ ছাড়াই WiFi অ্যাক্সেস বন্ধ হয়ে যায়।

নেটওয়ার্ক সেগমেন্টেশন: RADIUS সার্টিফিকেট অ্যাট্রিবিউটের মাধ্যমে ডাইনামিক VLAN অ্যাসাইনমেন্ট আপনাকে ক্রিপ্টোগ্রাফিকভাবে প্রয়োগ করা নেটওয়ার্ক সেগমেন্টেশন প্রদান করে। ডিভাইসগুলো SSID সিলেকশন বা MAC অ্যাড্রেস ফিল্টারিংয়ের ওপর ভিত্তি করে নয়, বরং সার্টিফিকেট প্রোপার্টির ওপর ভিত্তি করে সঠিক নেটওয়ার্ক সেগমেন্টে পৌঁছায় - যার উভয়ই খুব সহজেই বাইপাস করা সম্ভব।

Purple ৮০,০০০+ লাইভ ভেন্যুতে ৯৯.৯৯৯% আপটাইম সহ কাজ করে এবং আমাদের প্ল্যাটফর্মটি ISO 27001, GDPR, CCPA এবং Cyber Essentials সার্টিফাইড। আমাদের হার্ডওয়্যার-অ্যাগনস্টিক ক্লাউড ওভারলে Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet-এর সাথে একীভূত হয় - যার ফলে আপনার সার্টিফিকেট-অথেন্টিকেটেড স্টাফ নেটওয়ার্ক এবং আমাদের গেস্ট WiFi লেয়ার একই ইনফ্রাস্ট্রাকচার থেকে কাজ করে।

কীভাবে Behavioral Analytics: Insights for WiFi Networks আপনার সুরক্ষিত নেটওয়ার্ক ডেপ্লয়মেন্টকে পরিপূরক করতে পারে সে সম্পর্কে আরও জানতে, আমাদের অ্যানালিটিক্স গাইডটি দেখুন।

তথ্যসূত্র

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council

মূল সংজ্ঞাসমূহ

SCEP (Simple Certificate Enrollment Protocol)

RFC 8894-এ প্রমিত একটি প্রোটোকল যা পরিচালিত ডিভাইসগুলিকে প্রাথমিক প্রমাণীকরণের জন্য একটি শেয়ার্ড চ্যালেঞ্জ পাসওয়ার্ড ব্যবহার করে HTTP-এর মাধ্যমে একটি সার্টিফিকেট অথরিটি থেকে স্বয়ংক্রিয়ভাবে X.509 ডিজিটাল শংসাপত্রের অনুরোধ করতে এবং গ্রহণ করতে দেয়। প্রাইভেট কীটি ডিভাইসে তৈরি হয় এবং কখনই স্থানান্তরিত হয় না।

Microsoft Intune এবং Jamf-এর মতো MDM প্ল্যাটফর্মগুলি দ্বারা স্কেলে পরিচালিত এন্ডপয়েন্টগুলিতে WiFi প্রমাণীকরণ শংসাপত্রগুলি স্থাপন করতে ব্যবহৃত স্ট্যান্ডার্ড প্রক্রিয়া।

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

সবচেয়ে নিরাপদ 802.1X প্রমাণীকরণ পদ্ধতি, যার জন্য ক্লায়েন্ট ডিভাইস এবং RADIUS সার্ভার উভয়কেই বৈধ X.509 শংসাপত্র উপস্থাপন করতে হয়। পারস্পরিক প্রমাণীকরণের অর্থ হল ক্রিপ্টোগ্রাফিক প্রমাণ ছাড়া কোনো পক্ষই অন্য পক্ষকে বিশ্বাস করে না।

এন্টারপ্রাইজ WiFi-এর জন্য লক্ষ্য প্রমাণীকরণ প্রোটোকল। সংবেদনশীল ডেটা হ্যান্ডেল করা ওয়্যারলেস নেটওয়ার্কগুলির জন্য PCI DSS 4.0, WPA3-Enterprise 192-bit (Suite B), এবং HIPAA দ্বারা বাধ্যতামূলক বা দৃঢ়ভাবে সুপারিশকৃত।

NDES (Network Device Enrollment Service)

একটি Microsoft Windows Server রোল যা SCEP-সক্ষম ডিভাইস এবং একটি সার্টিফিকেট অথরিটির মধ্যে একটি রেজিস্ট্রেশন অথরিটি (RA) হিসাবে কাজ করে। এটি চ্যালেঞ্জ পাসওয়ার্ড যাচাই করে এবং ডোমেন শংসাপত্রহীন ডিভাইসগুলির পক্ষে CA-তে CSR ফরোয়ার্ড করে।

Microsoft Intune-এর সাথে SCEP স্থাপনের জন্য প্রয়োজনীয় অবকাঠামো। সরাসরি ইন্টারনেটে উন্মুক্ত করার পরিবর্তে Azure AD Application Proxy-এর মাধ্যমে প্রকাশ করা উচিত।

PKI (Public Key Infrastructure)

ডিজিটাল শংসাপত্র ইস্যু, পরিচালনা এবং প্রত্যাহার করতে ব্যবহৃত সার্টিফিকেট অথরিটি, নীতি এবং পদ্ধতির অনুক্রম। একটি দ্বি-স্তর বিশিষ্ট PKI একটি অফলাইন রুট CA (প্রধান ট্রাস্ট অ্যাঙ্কর) এবং একটি অনলাইন ইস্যুয়িং CA (যা দৈনন্দিন শংসাপত্র ইস্যু করার কাজ পরিচালনা করে) নিয়ে গঠিত।

EAP-TLS এবং SCEP স্থাপনের জন্য অ-আলোচনাযোগ্য পূর্বশর্ত। রুট CA-কে এয়ার-গ্যাপড রাখা উচিত; এর প্রাইভেট কী হল আপনার সম্পূর্ণ শংসাপত্র ট্রাস্ট চেইনের ভিত্তি।

CSR (Certificate Signing Request)

একটি ডিভাইস দ্বারা তৈরি একটি বার্তা যাতে তার পাবলিক কী এবং পরিচয়ের তথ্য থাকে, যা একটি স্বাক্ষরিত ডিজিটাল শংসাপত্রের অনুরোধ করার জন্য একটি সার্টিফিকেট অথরিটিতে পাঠানো হয়। SCEP-এ, CSR ডিভাইসে তৈরি হয় এবং স্থানান্তরের আগে একটি PKCS খামে মোড়ানো হয়।

SCEP তালিকাভুক্তি প্রবাহের সময় ডিভাইস দ্বারা স্বয়ংক্রিয়ভাবে তৈরি হয়। CSR স্বাক্ষর করতে ব্যবহৃত প্রাইভেট কীটি কখনই ডিভাইস থেকে বের হয় না।

CRL (Certificate Revocation List)

সার্টিফিকেট অথরিটি দ্বারা প্রকাশিত একটি তালিকা যাতে শংসাপত্রগুলির সিরিয়াল নম্বর থাকে যা তাদের মেয়াদ শেষ হওয়ার তারিখের আগেই প্রত্যাহার করা হয়েছে। প্রত্যাহার করা শংসাপত্রগুলি যাতে নেটওয়ার্ক অ্যাক্সেস করতে না পারে তা নিশ্চিত করতে RADIUS সার্ভারগুলি প্রতিটি প্রমাণীকরণের প্রচেষ্টায় CRL পরীক্ষা করে।

CRL ডিস্ট্রিবিউশন পয়েন্ট (CDP) এর প্রাপ্যতা অত্যন্ত গুরুত্বপূর্ণ। RADIUS সার্ভার যদি CRL-এ পৌঁছাতে না পারে, তবে এটি বন্ধ হয়ে যায় এবং সমস্ত প্রমাণীকরণ প্রত্যাখ্যান করে - যার ফলে নেটওয়ার্ক-ব্যাপী বিভ্রাট ঘটে।

RADIUS (Remote Authentication Dial-In User Service)

একটি নেটওয়ার্কিং প্রোটোকল যা নেটওয়ার্ক অ্যাক্সেসের জন্য কেন্দ্রীভূত প্রমাণীকরণ, অনুমোদন এবং অ্যাকাউন্টিং (AAA) প্রদান করে। 802.1X WiFi-এ, RADIUS সার্ভার ক্লায়েন্ট শংসাপত্রগুলি যাচাই করে, CRL পরীক্ষা করে এবং অ্যাক্সেস পয়েন্টে একটি Access-Accept বা Access-Reject বার্তা ফেরত পাঠায়।

802.1X সাপ্লিক্যান্ট-অথেন্টিকেটর-সার্ভার মডেলের প্রমাণীকরণ সার্ভার। সাধারণ বাস্তবায়নের মধ্যে রয়েছে Windows NPS, FreeRADIUS, এবং ক্লাউড RADIUS পরিষেবা।

Dynamic VLAN assignment

একটি RADIUS বৈশিষ্ট্য যা SSID নির্বাচন বা MAC অ্যাড্রেস ফিল্টারিংয়ের উপর নির্ভর না করে শংসাপত্রের বৈশিষ্ট্য বা ডিরেক্টরি গ্রুপ মেম্বারশিপের উপর ভিত্তি করে একটি নির্দিষ্ট VLAN-এ একটি প্রমাণিত ডিভাইস স্থাপন করে। ডিভাইসের পরিচয় দ্বারা নেটওয়ার্ক বিভাজন প্রয়োগ করে।

একটি একক SSID-কে বিভিন্ন নেটওয়ার্ক অ্যাক্সেস লেভেল সহ একাধিক ডিভাইসের ধরন পরিবেশন করতে সক্ষম করে। একজন স্টাফ ডিভাইস VLAN 10 (অভ্যন্তরীণ অ্যাক্সেস) পায়; একজন ঠিকাদারের ডিভাইস VLAN 20 (শুধুমাত্র ইন্টারনেট) পায়; একটি POS টার্মিনাল VLAN 30 (শুধুমাত্র পেমেন্ট সিস্টেম) পায়।

MDM (Mobile Device Management)

SCEP-ভিত্তিক শংসাপত্র স্থাপনের পূর্বশর্ত। ডিভাইসগুলি SCEP এবং WiFi প্রোফাইলগুলি গ্রহণ করার আগে অবশ্যই MDM-নিবন্ধিত হতে হবে। অনিয়ন্ত্রিত BYOD ডিভাইসগুলির জন্য একটি পৃথক অনবোর্ডিং পদ্ধতির প্রয়োজন।

সমাধানকৃত উদাহরণসমূহ

একটি ২০০-রুমের Premier Inn প্রপার্টিতে পয়েন্ট-অফ-সেল ট্যাবলেট এবং হাউসকিপিং স্মার্টফোনের জন্য তাদের স্টাফ WiFi সুরক্ষিত করা প্রয়োজন। তারা বর্তমানে একটি প্রি-শেয়ার্ড কী ব্যবহার করছেন যা ঠিকাদারদের কাছে ফাঁস হয়ে গেছে। তারা Microsoft Intune-এর মাধ্যমে ডিভাইসগুলো পরিচালনা করেন এবং তাদের কাছে iOS এবং Android ডিভাইসের মিশ্রণ রয়েছে। প্রপার্টিটি HPE Aruba অ্যাক্সেস পয়েন্ট ব্যবহার করে।

১. একটি ইন্টারনাল Microsoft AD CS টু-টিয়ার PKI ডেপ্লয় করুন। একটি ডেডিকেটেড Windows Server-এ NDES কনফিগার করুন এবং Azure AD Application Proxy-এর মাধ্যমে এটি পাবলিশ করুন। ২. Intune-এ, Root CA এবং Issuing CA সার্টিফিকেট সম্বলিত একটি Trusted Root Certificate প্রোফাইল তৈরি করুন। এটি একটি 'Property Staff Devices' Azure AD গ্রুপে ডেপ্লয় করুন। ৩. NDES এক্সটারনাল URL-কে নির্দেশ করে Intune-এ একটি SCEP Certificate প্রোফাইল তৈরি করুন। যেহেতু এগুলো শেয়ার্ড ডিভাইস, তাই Subject Name ফরম্যাট CN={{AAD_Device_ID}} সেট করুন। Key Usage-কে Digital Signature এবং Key Encipherment হিসেবে এবং Extended Key Usage-কে Client Authentication হিসেবে সেট করুন। এটি 'Property Staff Devices'-এ ডেপ্লয় করুন। ৪. স্টাফ SSID-এর জন্য একটি Wi-Fi প্রোফাইল তৈরি করুন, যেখানে WPA2-Enterprise এবং EAP-TLS কনফিগার করা থাকবে। ক্লায়েন্ট অথেন্টিকেশনের জন্য SCEP প্রোফাইল এবং সার্ভার ভ্যালিডেশনের জন্য Root CA নির্বাচন করুন। এটি 'Property Staff Devices'-এ ডেপ্লয় করুন। ৫. Windows NPS-কে নির্দেশ করতে HPE Aruba RADIUS সেটিংস কনফিগার করুন। NPS-এ, একটি Network Policy কনফিগার করুন যার জন্য EAP-TLS প্রয়োজন হবে এবং স্টাফ ডিভাইসের জন্য VLAN 10 অ্যাসাইন করুন। ৬. ডিভাইসগুলো প্রোফাইল পাওয়ার পর এবং সফলভাবে কানেক্ট হওয়ার পর, পুরোনো SSID-এর PSK পরিবর্তন (rotate) করুন এবং এটি বন্ধ করার (decommission) সময়সূচী নির্ধারণ করুন।

পরীক্ষকের মন্তব্য: এই পদ্ধতিটি সঠিকভাবে চিহ্নিত করে যে শেয়ার্ড ডিভাইসগুলোর (POS, হাউসকিপিং) জন্য ইউজার-ভিত্তিক অথেন্টিকেশনের পরিবর্তে ডিভাইস-ভিত্তিক অথেন্টিকেশন (CN={{AAD_Device_ID}}) প্রয়োজন, কারণ একাধিক স্টাফ মেম্বার একই ডিভাইস ব্যবহার করেন। এটি বাধ্যতামূলক প্রোফাইল ডেপ্লয়মেন্ট সিকোয়েন্স অনুসরণ করে এবং নিশ্চিত করে যে তিনটি প্রোফাইলই একই Azure AD গ্রুপকে টার্গেট করছে। সরাসরি ইন্টারনেটে এক্সপোজ করার পরিবর্তে App Proxy-এর মাধ্যমে NDES পাবলিশ করা একটি হসপিটালিটি পরিবেশের জন্য সঠিক সিকিউরিটি পোশ্চার।

৫০টি লোকেশন বিশিষ্ট একটি রিটেইল চেইন সমস্ত সাইটে কর্পোরেট ল্যাপটপের জন্য 802.1X ডেপ্লয় করতে চায়। তারা Cisco Meraki অ্যাক্সেস পয়েন্ট এবং Microsoft Intune ব্যবহার করে। তারা প্রতিটি লোকেশনে বা তাদের ডেটা সেন্টারে অন-প্রিমিসেস NDES সার্ভার বা AD CS ইনফ্রাস্ট্রাকচার ডেপ্লয় এবং রক্ষণাবেক্ষণ করতে চায় না।

১. একটি ক্লাউড-ভিত্তিক PKI এবং SCEP গেটওয়ে সার্ভিস ইমপ্লিমেন্ট করুন যা SCEP প্রোটোকলের মাধ্যমে Intune-এর সাথে ইন্টিগ্রেট করে। ক্লাউড CA সার্টিফিকেট ইস্যু করে; ক্লাউড SCEP গেটওয়ে CSR ভ্যালিডেশন হ্যান্ডেল করে। ২. কর্পোরেট SSID-এর জন্য Cisco Meraki ড্যাশবোর্ডে Wireless > Access Control-এর অধীনে ক্লাউড RADIUS সার্ভিস (যা PKI ভেন্ডর দ্বারা সরবরাহকৃত) কনফিগার করুন। সিকিউরিটি WPA2-Enterprise সেট করুন এবং RADIUS-কে ক্লাউড সার্ভিসের দিকে নির্দেশ করুন। ৩. Intune-এ, ক্লাউড CA রুট সার্টিফিকেট সম্বলিত একটি Trusted Root Certificate প্রোফাইল তৈরি করুন। এটি 'Corporate Laptops' ডিভাইস গ্রুপে ডেপ্লয় করুন। ৪. ক্লাউড SCEP গেটওয়ে URL-কে নির্দেশ করে একটি SCEP Certificate প্রোফাইল তৈরি করুন। ইউজার-ভিত্তিক অথেন্টিকেশনের জন্য Subject Name-কে CN={{UserPrincipalName}} সেট করুন। এটি 'Corporate Laptops'-এ ডেপ্লয় করুন। ৫. EAP-TLS সহ কর্পোরেট SSID-এর জন্য একটি Wi-Fi প্রোফাইল তৈরি করুন, যা SCEP প্রোফাইল এবং ক্লাউড CA রুটকে রেফারেন্স করবে। এটি 'Corporate Laptops'-এ ডেপ্লয় করুন। ৬. ল্যাপটপগুলো যখন Intune-এ এনরোল হবে, তখন সেগুলো ক্লাউড SCEP গেটওয়ের মাধ্যমে ক্লাউড CA থেকে স্বয়ংক্রিয়ভাবে সার্টিফিকেটের জন্য রিকোয়েস্ট করবে। ৫০টি লোকেশনের কোনোটিতেই কোনো অন-প্রিমিসেস ইনফ্রাস্ট্রাকচারের প্রয়োজন নেই।

পরীক্ষকের মন্তব্য: ডিস্ট্রিবিউটেড রিটেইল পরিবেশের জন্য এটিই সর্বোত্তম আধুনিক আর্কিটেকচার। ক্লাউড PKI এবং ক্লাউড RADIUS ব্যবহারের মাধ্যমে, প্রতিষ্ঠানটি প্রতিটি সাইটে জটিল অন-প্রিমিসেস ইনফ্রাস্ট্রাকচার (NDES, AD CS, NPS) রক্ষণাবেক্ষণের প্রয়োজনীয়তা দূর করে। ক্লাউড SCEP গেটওয়ে হরাইজন্টালি স্কেল করে এবং এটি সহজাতভাবেই অত্যন্ত নির্ভরযোগ্য (highly available), যা অন-প্রিমিসেস NDES-এর একক ব্যর্থতার ঝুঁকি (single point of failure) দূর করে। Cisco Meraki-এর ক্লাউড-ম্যানেজড আর্কিটেকচার এই পদ্ধতির সাথে চমৎকারভাবে সামঞ্জস্যপূর্ণ।

অনুশীলনী প্রশ্নসমূহ

Q1. আপনার প্রতিষ্ঠান PEAP-MSCHAPv2 থেকে EAP-TLS-এ মাইগ্রেট করছে। আপনি সফলভাবে Intune-এ আপনার 'Corporate Users' Azure AD গ্রুপে Trusted Root এবং SCEP প্রোফাইলগুলো ডেপ্লয় করেছেন। আপনি 'All Corporate Devices'-এ WiFi প্রোফাইলটি ডেপ্লয় করেছেন। ব্যবহারকারীরা রিপোর্ট করছেন যে তারা কানেক্ট করতে পারছেন না এবং WiFi প্রোফাইলটি Not Applicable হিসেবে দেখাচ্ছে।

ইঙ্গিত: প্রোফাইল ডিপেন্ডেন্সি এবং গ্রুপ টার্গেটিং নিয়মগুলো পরীক্ষা করুন। Intune অ্যাসাইন করা গ্রুপের উপর ভিত্তি করে প্রোফাইল ডিপেন্ডেন্সি সমাধান করে।

মডেল উত্তর দেখুন

সমস্যাটি হলো গ্রুপ টার্গেটিংয়ের অমিল। WiFi প্রোফাইলটি SCEP প্রোফাইলের উপর নির্ভরশীল, যা একটি User গ্রুপকে ('Corporate Users') টার্গেট করেছিল। WiFi প্রোফাইলটি একটি Device গ্রুপকে ('All Corporate Devices') টার্গেট করেছিল। Intune বিভিন্ন গ্রুপ টাইপের মধ্যে এই ডিপেন্ডেন্সি সমাধান করতে পারে না। এর সমাধান হলো তিনটি প্রোফাইল অ্যাসাইনমেন্টই - Trusted Root, SCEP, এবং WiFi - একই গ্রুপকে টার্গেট করার জন্য পরিবর্তন করা। আপনার অথেন্টিকেশন মডেলের (ইউজার-ভিত্তিক বনাম ডিভাইস-ভিত্তিক) উপর ভিত্তি করে একটি User গ্রুপ নাকি Device গ্রুপ ব্যবহার করবেন তা সিদ্ধান্ত নিন এবং তিনটি প্রোফাইলেই এটি সামঞ্জস্যপূর্ণভাবে প্রয়োগ করুন।

Q2. একটি সিকিউরিটি অডিটে দেখা গেছে যে যখন একজন কর্মচারীকে বরখাস্ত করা হয় এবং তাদের Microsoft Entra ID অ্যাকাউন্ট নিষ্ক্রিয় করা হয়, তখনও তাদের কর্পোরেট স্মার্টফোনটি বরখাস্তের পর এক সপ্তাহ পর্যন্ত স্টাফ WiFi নেটওয়ার্কে কানেক্ট করতে পারে।

ইঙ্গিত: অ্যাকাউন্ট নিষ্ক্রিয় করার পর সার্টিফিকেটটি এখনও বৈধ আছে কিনা তা RADIUS সার্ভার কীভাবে নির্ধারণ করে তা বিবেচনা করুন। রেভোকেশন স্ট্যাটাস জানানোর মাধ্যমটি কী?

মডেল উত্তর দেখুন

RADIUS সার্ভার কঠোরভাবে Certificate Revocation List (CRL) পরীক্ষা করছে না, অথবা CRL খুব কম সময়ে পাবলিশ করা হচ্ছে। যখন একজন কর্মচারীকে বরখাস্ত করা হয়, তখন MDM-এর উচিত ডিভাইসটিকে আনএনরোল করা এবং CA-এর উচিত সার্টিফিকেটটি রিভোক (বাতিল) করা। তবে, RADIUS সার্ভার যদি প্রতিটি অথেন্টিকেশন চেষ্টার সময় CRL পরীক্ষা না করে - অথবা CRL যদি কেবল সাপ্তাহিক ভিত্তিতে পাবলিশ করা হয় - তবে রিভোক করা সার্টিফিকেটটি গৃহীত হতে থাকে। এর সমাধানে তিনটি ধাপ রয়েছে: প্রতিটি অথেন্টিকেশনে কঠোর CRL চেকিং কার্যকর করার জন্য RADIUS সার্ভার কনফিগার করুন; আরও কম সময়ের ব্যবধানে (দৈনিক বা আরও ঘন ঘন) CRL পাবলিশ করার জন্য CA কনফিগার করুন; এবং একটি ডিভাইস আনএনরোল করার সময় যাতে সার্টিফিকেট রেভোকেশন ট্রিগার হয় তা নিশ্চিত করতে MDM কনফিগার করুন।

Q3. আপনাকে হেডলেস IoT ডিভাইসগুলোর (স্মার্ট থার্মোস্ট্যাট, ডিজিটাল সাইনেজ প্লেয়ার) জন্য নিরাপদ WiFi অ্যাক্সেস প্রদান করতে হবে যা কোনো MDM এজেন্ট চালাতে পারে না এবং Captive Portal প্রদর্শন করতে পারে না। আপনি কি এই ডিভাইসগুলোর জন্য SCEP ব্যবহার করতে পারেন, এবং যদি না পারেন, তবে প্রস্তাবিত বিকল্পটি কী?

ইঙ্গিত: SCEP এনরোলমেন্টের পূর্বশর্তগুলো এবং যে ডিভাইসগুলো MDM-এনরোল করা যায় না বা ব্রাউজার ব্যবহার করতে পারে না সেগুলোর জন্য কী বিকল্প রয়েছে তা বিবেচনা করুন।

মডেল উত্তর দেখুন

এই ডিভাইসগুলোর জন্য SCEP ব্যবহার করা যাবে না। SCEP-এর জন্য একটি MDM এজেন্ট প্রয়োজন যা এনরোলমেন্ট URL এবং চ্যালেঞ্জ পাসওয়ার্ড গ্রহণ করবে, কি পেয়ার (key pair) তৈরি করবে এবং প্রাপ্ত সার্টিফিকেটটি ইনস্টল করবে। হেডলেস IoT ডিভাইস যা MDM এজেন্ট চালাতে পারে না, তারা SCEP এনরোলমেন্ট ফ্লোতে অংশ নিতে পারে না। প্রস্তাবিত বিকল্পগুলো হলো: (১) কঠোর VLAN সেগমেন্টেশনের সাথে MAC Authentication Bypass (MAB) - RADIUS সার্ভার ডিভাইসের MAC অ্যাড্রেসের উপর ভিত্তি করে এটিকে অনুমতি দেয় এবং কর্পোরেট সিস্টেমে কোনো অ্যাক্সেস ছাড়াই একটি আইসোলেটেড IoT VLAN-এ রাখে; (২) ডিভাইসটি যদি এটি সাপোর্ট করে, তবে EST (Enrollment over Secure Transport, RFC 7030) এমন ডিভাইসগুলোতে সার্টিফিকেট প্রদান করতে পারে যা HTTPS সাপোর্ট করে কিন্তু MDM সাপোর্ট করে না; (৩) ম্যানেজমেন্ট ইন্টারফেস আছে এমন ডিভাইসের ক্ষেত্রে, কিছু ভেন্ডর কোনো MDM এজেন্ট ছাড়াই সরাসরি ডিভাইসের ফার্মওয়্যারের মাধ্যমে SCEP এনরোলমেন্ট সাপোর্ট করে। সব ক্ষেত্রেই, অথেন্টিকেশন পদ্ধতি যাই হোক না কেন, IoT ডিভাইসগুলোকে একটি ডেডিকেটেড VLAN-এ আইসোলেট করে রাখা উচিত।

এই সিরিজে পড়া চালিয়ে যান

SCEP-এর জন্য এন্টারপ্রাইজ গাইড: স্বয়ংক্রিয় ক্যাম্পাস WiFi সুরক্ষার জন্য Simple Certificate Enrollment Protocol স্থাপন করা

এই প্রযুক্তিগত রেফারেন্স গাইডটি SCEP ব্যবহার করে এন্টারপ্রাইজ WiFi সার্টিফিকেট স্থাপনের জন্য একটি সুনির্দিষ্ট আর্কিটেকচারাল ব্লুপ্রিন্ট এবং ধাপে ধাপে বাস্তবায়ন কৌশল প্রদান করে। এটি SCEP এবং PKCS-এর মধ্যে গুরুত্বপূর্ণ পার্থক্য, সফলতার জন্য প্রয়োজনীয় সঠিক স্থাপনার ক্রম এবং IT লিডারদের জন্য বাস্তব-জগতের ঝুঁকি প্রশমন কৌশলগুলি কভার করে।

গাইডটি পড়ুন →

কীভাবে স্বয়ংক্রিয় WiFi সার্টিফিকেট এনরোলমেন্টের জন্য SCEP বাস্তবায়ন করবেন

এই নির্দেশিকাটি এন্টারপ্রাইজ ভেন্যু জুড়ে স্বয়ংক্রিয় WiFi সার্টিফিকেট এনরোলমেন্টের জন্য কীভাবে SCEP (সিম্পল সার্টিফিকেট এনরোলমেন্ট প্রোটোকল) বাস্তবায়ন করতে হয় তা ব্যাখ্যা করে। এটি PKI ডিজাইন এবং MDM ইন্টিগ্রেশন থেকে শুরু করে বাধ্যতামূলক তিন-ধাপের ডেপ্লয়মেন্ট সিকোয়েন্স পর্যন্ত সম্পূর্ণ আর্কিটেকচারাল ব্লুপ্রিন্ট কভার করে - এবং IT ম্যানেজার ও নেটওয়ার্ক আর্কিটেক্টদের দেখায় কীভাবে শেয়ার্ড ক্রেডেনশিয়াল দূর করতে হয়, সার্টিফিকেট লাইফসাইকেল ম্যানেজমেন্ট স্বয়ংক্রিয় করতে হয় এবং স্কেলে PCI DSS এবং GDPR প্রয়োজনীয়তা পূরণ করতে হয়।

গাইডটি পড়ুন →

Cisco SUDI বোঝা: নেটওয়ার্ক অ্যাক্সেস কন্ট্রোলে হার্ডওয়্যার-ভিত্তিক ডিভাইস আইডেন্টিটি

এই নির্দেশিকাটি Cisco SUDI-এর প্রযুক্তিগত আর্কিটেকচার বিস্তারিতভাবে বর্ণনা করে, যেখানে ব্যাখ্যা করা হয়েছে কীভাবে হার্ডওয়্যার-অ্যাঙ্করড আইডেন্টিটি নেটওয়ার্ক অ্যাক্সেস কন্ট্রোলকে সুরক্ষিত করে। এটি আইটি লিডারদের জন্য এন্টারপ্রাইজ ভেন্যু জুড়ে 802.1X EAP-TLS অথেন্টিকেশন স্থাপন এবং Zero Touch Provisioning স্বয়ংক্রিয় করার জন্য কার্যকর বাস্তবায়ন পদক্ষেপ প্রদান করে।

গাইডটি পড়ুন →