কীভাবে নিরাপদ এন্টারপ্রাইজ WiFi এবং BYOD প্রভিশনিংয়ের জন্য SCEP কনফিগার করবেন

Purple-এর এই টেকনিক্যাল ব্রিফিং-এ আপনাকে স্বাগত জানাই। আমি আপনার হোস্ট, এবং আজ আমরা সুরক্ষিত এন্টারপ্রাইজ WiFi এবং BYOD প্রভিশনিংয়ের জন্য SCEP কনফিগারেশন সম্পর্কে বিস্তারিত আলোচনা করছি। হসপিটালিটি, রিটেইল এবং পাবলিক সেক্টরে কর্মরত IT ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট এবং CTO-দের জন্য, নেটওয়ার্ক অ্যাক্সেস পরিচালনা করা হলো নিরাপত্তা এবং অপারেশনাল দক্ষতার মধ্যে একটি ধ্রুবক ভারসাম্য রক্ষা করা। আপনি প্রতিদিন আপনার নেটওয়ার্কে সংযুক্ত শত শত, কখনও কখনও হাজার হাজার ডিভাইস পরিচালনা করছেন। কর্মীদের স্মার্টফোন, ঠিকাদারদের ল্যাপটপ, পয়েন্ট অফ সেল ট্যাবলেট। এবং এটি পরিচালনা করার পুরানো পদ্ধতিগুলো এখন আর যথেষ্ট ভালো নয়। কর্মী এবং BYOD WiFi-এর জন্য Pre-Shared Keys বা PSK-এর ওপর নির্ভর করা একটি নিরাপত্তা দুর্বলতা যা যেকোনো সময় অপব্যবহারের শিকার হতে পারে। একটি শেয়ার করা পাসওয়ার্ড একবার লিক হয়ে গেলে, তা যেকোনো ব্যক্তিকে আপনার নেটওয়ার্কে অ্যাক্সেস দেয়। এবং MAC Authentication Bypass বা MAB-ও এর চেয়ে ভালো কিছু নয়। আধুনিক স্মার্টফোনগুলো ডিফল্টভাবে র্যান্ডমাইজড MAC অ্যাড্রেস ব্যবহার করে, যা MAB-কে সম্পূর্ণরূপে অকার্যকর করে দেয় এবং MAC অ্যাড্রেসগুলো কয়েক সেকেন্ডের মধ্যে স্পুফ করা যেতে পারে। আধুনিক নেটওয়ার্ক আর্কিটেকচারের জন্য EAP-TLS ব্যবহার করে 802.1X অথেনটিকেশন প্রয়োজন। এটি নিশ্চিত করে যে প্রতিটি ডিভাইস নেটওয়ার্ক স্পর্শ করার আগেই ক্রিপ্টোগ্রাফিকভাবে যাচাই করা হয়েছে। কিন্তু চ্যালেঞ্জটি এখানে: আপনার হেল্পডেস্ককে অতিরিক্ত চাপে না ফেলে কীভাবে আপনি হাজার হাজার আনম্যানেজড ডিভাইসে অনন্য ক্লায়েন্ট সার্টিফিকেট বিতরণ করবেন? উত্তরটি হলো Simple Certificate Enrolment Protocol বা SCEP। আসুন আর্কিটেকচার দিয়ে শুরু করি। SCEP হলো এন্টারপ্রাইজ ডিভাইস এনরোলমেন্টের জন্য ইন্ডাস্ট্রি স্ট্যান্ডার্ড, যা RFC 8894-এ সংজ্ঞায়িত করা হয়েছে। এটি ১৯৯৯ সাল থেকে চলে আসছে, মূলত VeriSign দ্বারা তৈরি, এবং এটি সময়ের পরীক্ষায় উত্তীর্ণ হয়েছে কারণ এটি একটি অত্যন্ত জটিল সমস্যার মার্জিত সমাধান দেয়। একটি SCEP ওয়ার্কফ্লোতে, ডিভাইসটি স্থানীয়ভাবে তার নিজস্ব প্রাইভেট এবং পাবলিক কী পেয়ার তৈরি করে। এটি একটি Certificate Signing Request বা CSR তৈরি করে এবং একটি Network Device Enrolment Service বা NDES-এর মাধ্যমে আপনার Certificate Authority বা CA-তে পাঠায়। CA অনুরোধটি যাচাই করে এবং স্বাক্ষরিত পাবলিক সার্টিফিকেটটি ডিভাইসে ফেরত পাঠায়। এখানে সবচেয়ে গুরুত্বপূর্ণ নিরাপত্তা সুবিধা হলো যে প্রাইভেট কী কখনো ডিভাইস ছেড়ে যায় না। এটি স্থানীয়ভাবে তৈরি হয় এবং ডিভাইসের হার্ডওয়্যার সিকিউর এনক্লেভে সংরক্ষিত থাকে। একটি Windows ল্যাপটপে এটি হলো Trusted Platform Module বা TPM। একটি iPhone-এ এটি হলো Secure Enclave। প্রাইভেট কী কখনো নেটওয়ার্কের মাধ্যমে স্থানান্তরিত হয় না। নেটওয়ার্ক অথেনটিকেশনের জন্য PKCS-এর মতো বিকল্পগুলোর তুলনায় SCEP-কে যা ব্যাপকভাবে সেরা করে তোলে তা হলো এটিই, যেখানে CA কেন্দ্রীয়ভাবে কী পেয়ার তৈরি করে এবং তা ডিভাইসে স্থানান্তর করে। এখন আসুন BYOD সম্পর্কে কথা বলি। অপারেশনাল দৃষ্টিকোণ থেকে এটি সত্যিই আকর্ষণীয়। আপনি চান কর্মীরা যেন অভ্যন্তরীণ টুলগুলো অ্যাক্সেস করতে তাদের ব্যক্তিগত ডিভাইস ব্যবহার করতে পারেন, কিন্তু আপনি তাদের আপনার কর্পোরেট MDM-এ এনরোল করতে বাধ্য করতে চান না। এটি একটি প্রাইভেসি সংক্রান্ত উদ্বেগের বিষয় এবং কর্মীদের কাছ থেকে এর তীব্র প্রতিরোধ আসে।সমাধানটি হলো একটি স্ব-পরিষেবা অনবোর্ডিং পোর্টাল। এটি যেভাবে কাজ করে তা নিচে দেওয়া হলো। ব্যবহারকারী তাদের ব্যক্তিগত ডিভাইসটিকে একটি ডেডিকেটেড প্রভিশনিং SSID-এর সাথে সংযুক্ত করেন। এই নেটওয়ার্কটি একটি ওয়াল্ড গার্ডেন (walled garden), যা অনবোর্ডিং পোর্টাল এবং আপনার আইডেন্টিটি প্রোভাইডার ছাড়া অন্য সবকিছুর অ্যাক্সেস সীমাবদ্ধ করে। ব্যবহারকারী সাধারণত Microsoft Entra ID, Okta বা Google Workspace-এর সাথে SAML ইন্টিগ্রেশনের মাধ্যমে তাদের কর্পোরেট ক্রেডেনশিয়াল ব্যবহার করে প্রমাণীকরণ (authenticate) করেন। সফল প্রমাণীকরণের পর, সিস্টেমটি SCEP-এর মাধ্যমে একটি অনন্য, ডিভাইস-নির্দিষ্ট ক্লায়েন্ট সার্টিফিকেট তৈরি করে। ডিভাইসে একটি কনফিগারেশন প্রোফাইল পুশ করা হয় যাতে সার্টিফিকেট, রুট CA সার্টিফিকেট এবং নেটওয়ার্ক সেটিংস থাকে। ডিভাইসটি তখন স্বয়ংক্রিয়ভাবে EAP-TLS ব্যবহার করে সুরক্ষিত কর্পোরেট SSID-এর সাথে সংযুক্ত হয়। এটি ব্যবহারকারীর জন্য নির্বিঘ্ন এবং এন্টারপ্রাইজের জন্য নিরাপদ। সার্টিফিকেট বা 802.1X সম্পর্কে তাদের কিছু জানার প্রয়োজন নেই। তারা কেবল একবার লগইন করে এবং সংযুক্ত হয়ে যায়। এখন, বাস্তবায়ন প্রক্রিয়াটি বিস্তারিতভাবে দেখা যাক। ডেপ্লয়মেন্টের ধারাবাহিকতা অত্যন্ত গুরুত্বপূর্ণ এবং এটি ভুল করা হলো ব্যর্থতার সবচেয়ে সাধারণ কারণ। ধাপ এক: বিশ্বস্ত রুট সার্টিফিকেট (Trusted Root Certificate) ডেপ্লয় করুন। কোনো ডিভাইস ক্লায়েন্ট সার্টিফিকেটের জন্য অনুরোধ করার আগে বা আপনার RADIUS সার্ভারকে বিশ্বাস করার আগে, তাকে অবশ্যই ইস্যুকারী সার্টিফিকেট অথরিটিকে বিশ্বাস করতে হবে। আপনার রুট CA সার্টিফিকেটটিকে একটি .cer ফাইল হিসেবে এক্সপোর্ট করুন এবং আপনার লক্ষ্যযুক্ত ডিভাইস গ্রুপগুলোতে এটি ডেপ্লয় করুন। এই ধাপটি বাধ্যতামূলক। এটি ছাড়া পুরো চেইনটিই ব্যর্থ হবে। ধাপ দুই: SCEP সার্টিফিকেট প্রোফাইল কনফিগার করুন। এটি ডিভাইসগুলোকে নির্দেশনা দেয় যে কীভাবে তারা তাদের ক্লায়েন্ট সার্টিফিকেট পাবে। আপনাকে সাবজেক্ট নেম ফরম্যাট কনফিগার করতে হবে। ব্যবহারকারী-চালিত প্রমাণীকরণের জন্য, স্ট্যান্ডার্ড হলো CN equals UserPrincipalName। ডিভাইস প্রমাণীকরণের জন্য, CN equals Azure AD Device ID ব্যবহার করুন। কী (key) ব্যবহারকে ডিজিটাল সিগনেচার এবং কী এনসাইফারমেন্টে সেট করুন। বর্ধিত কী ব্যবহারের (extended key usage) অধীনে, OID 1.3.6.1.5.5.7.3.2 সহ ক্লায়েন্ট প্রমাণীকরণ (Client Authentication) নির্দিষ্ট করুন। এই প্রোফাইলটিকে ধাপ এক থেকে প্রাপ্ত বিশ্বস্ত রুট সার্টিফিকেট প্রোফাইলের সাথে লিঙ্ক করুন। এবং আপনার NDES সার্ভারের বাহ্যিক URL প্রদান করুন। ধাপ তিন: 802.1X WiFi প্রোফাইল ডেপ্লয় করুন। এটি নেটওয়ার্ক SSID-এর সাথে সার্টিফিকেটগুলোকে যুক্ত করে। আপনার অ্যাক্সেস পয়েন্ট দ্বারা প্রচারিত নেটওয়ার্কের নামটি হুবহু প্রবেশ করান। সিকিউরিটি টাইপ WPA2-Enterprise বা WPA3-Enterprise-এ সেট করুন। EAP টাইপ EAP-TLS-এ সেট করুন। ক্লায়েন্ট প্রমাণীকরণ সার্টিফিকেট হিসেবে SCEP সার্টিফিকেট প্রোফাইলটি নির্বাচন করুন। এবং সার্ভার যাচাইকরণের জন্য বিশ্বস্ত রুট সার্টিফিকেটটি নির্দিষ্ট করুন। এই সম্পূর্ণ ব্রিফিং থেকে মনে রাখার মতো সবচেয়ে গুরুত্বপূর্ণ বিষয় হলো এই ধারাবাহিকতা। প্রথমে ট্রাস্ট, তারপর সার্টিফিকেট, তারপর WiFi। প্রতিবারই এই ক্রমানুসারে কাজ করতে হবে। এখন আমি আপনাকে কিছু সেরা অনুশীলন দেখাবো যা আপনাকে প্রোডাকশনের ক্ষেত্রে অনেক ঝামেলা থেকে বাঁচাবে। প্রথমত, Azure AD Application Proxy-এর মাধ্যমে আপনার NDES সার্ভারটি প্রকাশ করুন। দূরবর্তী ডিভাইসগুলো সাইটে আসার আগেই যাতে সার্টিফিকেট প্রভিশন করতে পারে, সেজন্য ইন্টারনেট থেকে NDES সার্ভারটি অ্যাক্সেসযোগ্য হতে হবে। কিন্তু সরাসরি ইন্টারনেটে একটি অভ্যন্তরীণ সার্ভার উন্মুক্ত করা একটি বড় নিরাপত্তা ঝুঁকি। Application Proxy ইনবাউন্ড ফায়ারওয়াল পোর্ট না খুলেই আপনাকে সুরক্ষিত দূরবর্তী অ্যাক্সেস প্রদান করে।দ্বিতীয়ত, BYOD ডিভাইসের জন্য স্বল্পমেয়াদী সার্টিফিকেট প্রয়োগ করুন। তিন বছরের জন্য বৈধ সার্টিফিকেটের পরিবর্তে, ৯০ দিনের জন্য বৈধ সার্টিফিকেট ইস্যু করুন। সার্টিফিকেটের মেয়াদ শেষ হলে, ব্যবহারকারীকে অবশ্যই অনবোর্ডিং পোর্টালের মাধ্যমে আবার প্রমাণীকরণ করতে হবে। এটি স্বাভাবিকভাবেই নেটওয়ার্ক থেকে পুরোনো অব্যবহৃত ডিভাইসগুলিকে ছাঁটাই করে দেয়। ৯০ দিনের মধ্যে ব্যবহার করা হয়নি এমন একটি ডিভাইস কেবলই নেটওয়ার্ক থেকে বাদ পড়ে যায়। কোনো ম্যানুয়াল ক্লিনআপের প্রয়োজন হয় না। তৃতীয়ত, এবং এটি অত্যন্ত গুরুত্বপূর্ণ, কঠোর Certificate Revocation List চেকিং প্রয়োগ করার জন্য আপনার RADIUS সার্ভার কনফিগার করুন। যখন কোনো কর্মচারী সংস্থা ছেড়ে চলে যান, তখন তাদের Active Directory অ্যাকাউন্ট নিষ্ক্রিয় করার পরেও তাদের ক্লায়েন্ট সার্টিফিকেট বৈধ থাকলে তা অবিলম্বে তাদের WiFi অ্যাক্সেস বাতিল নাও করতে পারে। অ্যাক্সেস দেওয়ার আগে আপনার RADIUS সার্ভারকে অবশ্যই CRL চেক করতে হবে। আপনার CRL Distribution Points যাতে অত্যন্ত সহজলভ্য (highly available) থাকে তা নিশ্চিত করুন। যদি RADIUS সার্ভারটি CRL-এ পৌঁছাতে না পারে, তবে সকলের জন্য প্রমাণীকরণ ব্যর্থ হবে। এটি একটি ব্যাপক বিভ্রাট (outage) সৃষ্টি করতে পারে। এখন আসুন কিছু সাধারণ ব্যর্থতার ধরণ এবং কীভাবে সেগুলি এড়ানো যায় তা দেখে নেওয়া যাক। সবচেয়ে ঘন ঘন ঘটে যাওয়া সমস্যাটি হলো WiFi প্রোফাইল প্রয়োগ করতে ব্যর্থ হওয়া। ডিভাইসটি Trusted Root এবং SCEP সার্টিফিকেট গ্রহণ করে, কিন্তু MDM কনসোলে WiFi প্রোফাইলটি Error হিসেবে দেখায়। দশবারের মধ্যে নয়বারই এটি একটি গ্রুপ টার্গেটিং অমিলের কারণে ঘটে। যদি SCEP প্রোফাইলটি কোনো User Group-এ অ্যাসাইন করা হয়, কিন্তু WiFi প্রোফাইলটি কোনো Device Group-এ অ্যাসাইন করা থাকে, তবে MDM এই ডিপেনডেন্সি সমাধান করতে পারে না। আপনার অ্যাসাইনমেন্টগুলি অডিট করুন। নিশ্চিত করুন যে তিনটি প্রোফাইলই ঠিক একই গ্রুপকে টার্গেট করছে। দ্বিতীয় সাধারণ সমস্যাটি হলো NDES 403 Forbidden ত্রুটি। ডিভাইসগুলি SCEP সার্টিফিকেট রিট্রিভ করতে ব্যর্থ হয় এবং NDES IIS লগগুলিতে HTTP 403 ত্রুটি দেখায়। এটি সাধারণত ঘটে থাকে সার্টিফিকেট টেমপ্লেটে কানেক্টর সার্ভিস অ্যাকাউন্টের প্রয়োজনীয় পারমিশন না থাকার কারণে, অথবা SCEP দ্বারা ব্যবহৃত নির্দিষ্ট কোয়েরি স্ট্রিং প্যারামিটারগুলিকে কোনো ফায়ারওয়াল ব্লক করার কারণে। CA টেমপ্লেটে কানেক্টর অ্যাকাউন্টের Read এবং Enrol পারমিশন রয়েছে কিনা তা যাচাই করুন। operation equals GetCACaps প্যারামিটার ধারণকারী URL-গুলি ব্লক করা হচ্ছে না তা নিশ্চিত করতে আপনার ফায়ারওয়াল লগগুলি পরীক্ষা করুন। বাস্তব ক্ষেত্রে এটি কীভাবে কাজ করে তা ব্যাখ্যা করার জন্য আমি আপনাকে দুটি বাস্তব দৃশ্যপট দেখাই। দৃশ্যপট এক: ৫০ জন হাউসকিপিং স্টাফ সহ একটি ২০০-রুমের হোটেল, যারা শিডিউলিং অ্যাপ অ্যাক্সেস করতে ব্যক্তিগত স্মার্টফোন ব্যবহার করছেন। আইটি ম্যানেজার স্টাফদের গোপনীয়তাকে সম্মান জানাতে সম্পূর্ণ MDM এনরোলমেন্ট এড়াতে চান। এর সমাধান হলো Microsoft Entra ID-এর সাথে একীভূত একটি সেলফ-সার্ভিস পোর্টাল। কর্মীরা প্রোভিশনিং SSID-এর সাথে সংযুক্ত হন, তাদের Entra ID ক্রেডেনশিয়াল দিয়ে লগ ইন করেন এবং একটি SCEP প্রোফাইল ডাউনলোড করেন। SCEP সার্ভার সরাসরি ডিভাইসে একটি ৩০ দিনের ক্লায়েন্ট সার্টিফিকেট ইস্যু করে। ডিভাইসটি EAP-TLS ব্যবহার করে Staff WiFi SSID-এর সাথে সংযোগ স্থাপন করে। RADIUS সার্ভার এই ডিভাইসগুলিকে একটি সীমাবদ্ধ VLAN-এ অ্যাসাইন করে যা কেবল শিডিউলিং অ্যাপে অ্যাক্সেসের অনুমতি দেয়। যখন কোনো কর্মী পদত্যাগ করেন, তখন তাদের Entra ID অ্যাকাউন্ট নিষ্ক্রিয় করে দেওয়া হয় এবং RADIUS সার্ভার তাৎক্ষণিকভাবে নেটওয়ার্ক অ্যাক্সেস প্রত্যাখ্যান করে।পরিস্থিতি দুই: একটি জাতীয় রিটেইল চেইন যার ৫০০টি স্টোর রয়েছে, তারা কর্পোরেট মালিকানাধীন পয়েন্ট-অফ-সেল ট্যাবলেটের জন্য সুরক্ষিত WiFi মোতায়েন করছে। নেটওয়ার্ক আর্কিটেক্টকে নিশ্চিত করতে হবে যে কোনও ট্যাবলেট চুরি হয়ে গেলেও যাতে ক্রেডেনশিয়ালগুলো বের করা না যায়। সমাধানটি হলো Microsoft Intune যা SCEP-এর মাধ্যমে সার্টিফিকেট মোতায়েন করে। Intune প্রথমে ট্রাস্টেড রুট সার্টিফিকেট পুশ করে, তারপরে একটি SCEP প্রোফাইল যা ট্যাবলেটটিকে তার নিজস্ব হার্ডওয়্যার সিকিউর এনক্লেভে নিজস্ব প্রাইভেট কি তৈরি করার নির্দেশ দেয়। ট্যাবলেটটি NDES সার্ভারে একটি CSR জমা দেয়, ক্লায়েন্ট সার্টিফিকেট গ্রহণ করে এবং EAP-TLS ব্যবহার করে রিটেইল POS SSID-এর সাথে সংযোগ স্থাপন করে। যেহেতু প্রাইভেট কি-টি স্থানীয়ভাবে তৈরি হয় এবং কখনই স্থানান্তরিত হয় না, তাই চুরি হওয়া ট্যাবলেটের ক্রেডেনশিয়াল অন্য কোথাও ব্যবহার করা যাবে না। এটি PCI-DSS কমপ্লায়েন্সের প্রয়োজনীয়তা পূরণ করে। এখন, ব্যবসায়িক দিকটি নিয়ে কথা বলা যাক। SCEP 802.1X সার্টিফিকেট মোতায়েনে রূপান্তর সিকিউরিটি এবং অপারেশন উভয় ক্ষেত্রেই পরিমাপযোগ্য রিটার্ন প্রদান করে। পাসওয়ার্ড ভিত্তিক WiFi হেল্পডেস্কে উল্লেখযোগ্য সংখ্যক টিকিট তৈরি করে। পাসওয়ার্ডের মেয়াদ শেষ হওয়া, লকআউট, টাইপো। সার্টিফিকেট ভিত্তিক প্রমাণীকরণ ব্যবহারকারীর কাছে অদৃশ্য। ডিভাইসগুলো স্বয়ংক্রিয়ভাবে সংযুক্ত হয়। এটি সাধারণত WiFi সংক্রান্ত হেল্পডেস্কের কাজের চাপ ৭০% কমিয়ে দেয়। এটি পরিচালন ব্যয়ের ক্ষেত্রে একটি বাস্তবসম্মত হ্রাস। EAP-TLS ক্রেডেনশিয়াল হারভেস্টিং এবং ম্যান-ইন-দ্য-মিডল আক্রমণের ঝুঁকি দূর করে। রিটেইল পরিবেশে PCI-DSS এবং সমস্ত সেক্টরে GDPR কমপ্লায়েন্সের জন্য এটি অত্যন্ত গুরুত্বপূর্ণ। একটি ডেটা ফাঁসের ক্ষতি একটি সঠিক PKI অবকাঠামো মোতায়েনের খরচের চেয়ে অনেক বেশি। এবং যে সমস্ত সংস্থা ইতিমধ্যেই Purple-এর গেস্ট WiFi এবং অ্যানালিটিক্স প্ল্যাটফর্ম ব্যবহার করছে, তাদের কর্মীদের BYOD ডিভাইসের জন্য সুরক্ষিত অনবোর্ডিং সম্প্রসারণ করা একটি ইউনিফাইড নেটওয়ার্ক ম্যানেজমেন্ট স্ট্র্যাটেজি প্রদান করে। Purple-এর হার্ডওয়্যার-অ্যাগনস্টিক ক্লাউড ওভারলে Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks, এবং Fortinet-এর সাথে ইন্টিগ্রেট করে, তাই আপনি কোনও একক হার্ডওয়্যার ভেন্ডরের কাছে লকড থাকবেন না। Purple ৮০,০০০-এরও বেশি লাইভ ভেন্যুতে কাজ করে এবং ২০২৪ সালে ৪৪০ মিলিয়ন লগইন প্রসেস করেছে, যার অধীনে ISO 27001, GDPR, CCPA, এবং Cyber Essentials সার্টিফিকেট রয়েছে। আপনাকে যে মূল সিদ্ধান্তগুলো নিতে হবে তার একটি দ্রুত সংক্ষিপ্তসার দিয়ে আমি শেষ করছি। আপনার কি SCEP নাকি PKCS ব্যবহার করা উচিত? WiFi প্রমাণীকরণের জন্য SCEP ব্যবহার করুন। প্রাইভেট কি ডিভাইসেই থাকে। কেবল ইমেল এনক্রিপশনের জন্য PKCS ব্যবহার করুন যেখানে কি এসক্রো প্রয়োজন। সার্টিফিকেটের মেয়াদ কতদিন থাকা উচিত? BYOD-এর জন্য ৯০ দিন। কর্পোরেট পরিচালিত ডিভাইসের জন্য এক থেকে দুই বছর। আপনার MDM-এ ইউজার নাকি ডিভাইস টার্গেটিং ব্যবহার করা উচিত? কর্পোরেট ডিভাইসের জন্য ডিভাইস টার্গেটিং ব্যবহার করুন যা ব্যবহারকারী লগইন করার আগেই সংযুক্ত হওয়া প্রয়োজন। BYOD-এর জন্য ইউজার টার্গেটিং ব্যবহার করুন যেখানে সার্টিফিকেটটি ব্যক্তির সাথে যুক্ত থাকা উচিত। আপনি কীভাবে Android ফ্র্যাগমেন্টেশন পরিচালনা করবেন? যেখানে সম্ভব Passpoint ব্যবহার করুন। এটি সমস্ত Android প্রস্তুতকারকদের ডিভাইসজুড়ে একটি সামঞ্জস্যপূর্ণ সংযোগের অভিজ্ঞতা প্রদান করে। এবং পরিশেষে, সঠিকভাবে সম্পন্ন করার জন্য সবচেয়ে গুরুত্বপূর্ণ বিষয়টি কী? আপনার RADIUS সার্ভারে CRL চেকিং। এটি ছাড়া, একটি বাতিল করা সার্টিফিকেটও নেটওয়ার্কে অ্যাক্সেস মঞ্জুর করতে পারে। আজকের ব্রিফিং এখানেই শেষ। আপনি যদি এই বিষয়গুলোর কোনোটি সম্পর্কে আরও বিস্তারিত জানতে চান, তবে এন্টারপ্রাইজ WiFi সিকিউরিটি এবং EAP-TLS সার্টিফিকেট অথেন্টিকেশন সংক্রান্ত Purple-এর টেকনিক্যাল গাইডগুলো Purple-এর ওয়েবসাইট purple.ai-তে পেয়ে যাবেন। শোনার জন্য ধন্যবাদ।