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

Purple-এর এই প্রযুক্তিগত ব্রিফিংয়ে আপনাকে স্বাগতম। আমি আপনার হোস্ট, এবং আজ আমরা সুরক্ষিত এন্টারপ্রাইজ WiFi এবং BYOD প্রভিশনিংয়ের জন্য SCEP কনফিগারেশনের গভীরে প্রবেশ করছি। হসপিটালিটি, রিটেল এবং পাবলিক সেক্টরে কর্মরত আইটি ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট এবং CTO-দের জন্য, নেটওয়ার্ক অ্যাক্সেস পরিচালনা করা নিরাপত্তা এবং অপারেশনাল দক্ষতার মধ্যে একটি ধ্রুবক ভারসাম্য বজায় রাখার কাজ। আপনি প্রতিদিন আপনার নেটওয়ার্কের সাথে সংযুক্ত শত শত, কখনও কখনও হাজার হাজার ডিভাইস নিয়ে কাজ করছেন। স্টাফদের স্মার্টফোন, ঠিকাদারদের ল্যাপটপ, পয়েন্ট-অফ-সেল ট্যাবলেট। এবং এগুলো পরিচালনা করার পুরোনো পদ্ধতিগুলো এখন আর যথেষ্ট ভালো নয়। স্টাফ এবং BYOD WiFi-এর জন্য প্রি-শেয়ার্ড কি বা PSK-এর ওপর নির্ভর করা একটি নিরাপত্তা দুর্বলতা যা যেকোনো সময় অপব্যবহারের শিকার হতে পারে। একটি শেয়ার করা পাসওয়ার্ড একবার আপোসকৃত হলে যে কাউকে আপনার নেটওয়ার্কে অ্যাক্সেস দেয়। এবং MAC Authentication Bypass বা MAB-ও এর চেয়ে ভালো কিছু নয়। আধুনিক স্মার্টফোনগুলো ডিফল্টরূপে র্যান্ডমাইজড MAC অ্যাড্রেস ব্যবহার করে, যা MAB-কে সম্পূর্ণরূপে অকার্যকর করে তোলে এবং MAC অ্যাড্রেস কয়েক সেকেন্ডের মধ্যে স্পুফ করা যেতে পারে। আধুনিক নেটওয়ার্ক আর্কিটেকচারের জন্য EAP-TLS ব্যবহার করে 802.1X প্রমাণীকরণ প্রয়োজন। এটি নিশ্চিত করে যে প্রতিটি ডিভাইস নেটওয়ার্ক স্পর্শ করার আগে ক্রিপ্টোগ্রাফিকভাবে যাচাই করা হয়েছে। কিন্তু চ্যালেঞ্জটি এখানে: আপনার হেল্পডেস্ককে অতিরিক্ত ব্যস্ত না করে কীভাবে আপনি হাজার হাজার অপরিচালিত ডিভাইসে অনন্য ক্লায়েন্ট সার্টিফিকেট বিতরণ করবেন? উত্তরটি হলো সিম্পল সার্টিফিকেট এনরোলমেন্ট প্রোটোকল বা SCEP। আসুন আর্কিটেকচার দিয়ে শুরু করা যাক। SCEP হলো এন্টারপ্রাইজ ডিভাইস এনরোলমেন্টের জন্য ইন্ডাস্ট্রি স্ট্যান্ডার্ড, যা RFC 8894-এ সংজ্ঞায়িত। এটি ১৯৯৯ সাল থেকে রয়েছে, মূলত VeriSign দ্বারা তৈরি করা হয়েছিল এবং এটি সময়ের পরীক্ষায় উত্তীর্ণ হয়েছে কারণ এটি একটি সত্যিকারের কঠিন সমস্যার চমৎকার সমাধান করে। একটি SCEP ওয়ার্কফ্লোতে, ডিভাইসটি স্থানীয়ভাবে নিজস্ব প্রাইভেট এবং পাবলিক কি পেয়ার তৈরি করে। এটি একটি Certificate Signing Request বা CSR তৈরি করে এবং এটি Network Device Enrollment Service বা NDES-এর মাধ্যমে আপনার Certificate Authority বা CA-এর কাছে পাঠায়। CA অনুরোধটি যাচাই করে এবং সাইন করা পাবলিক সার্টিফিকেটটি ডিভাইসে ফেরত পাঠায়। এখানে গুরুত্বপূর্ণ নিরাপত্তা সুবিধা হলো প্রাইভেট কি কখনই ডিভাইস থেকে বাইরে যায় না। এটি স্থানীয়ভাবে তৈরি হয় এবং ডিভাইসের হার্ডওয়্যার সিকিউর এনক্লেভে সংরক্ষিত হয়। একটি উইন্ডোজ ল্যাপটপে, এটি হলো Trusted Platform Module বা TPM। একটি আইফোনে, এটি হলো Secure Enclave। প্রাইভেট কি কখনই নেটওয়ার্কের মাধ্যমে স্থানান্তরিত হয় না। এটিই নেটওয়ার্ক প্রমাণীকরণের জন্য PKCS-এর মতো বিকল্পগুলোর চেয়ে SCEP-কে অনেক বেশি উন্নত করে তোলে, যেখানে CA কেন্দ্রীয়ভাবে কি পেয়ার তৈরি করে এবং এটি ডিভাইসে স্থানান্তর করে। এখন, আসুন BYOD নিয়ে কথা বলি। অপারেশনাল দৃষ্টিকোণ থেকে এটি সত্যিই আকর্ষণীয়। আপনি চান স্টাফরা তাদের ব্যক্তিগত ডিভাইসগুলো অভ্যন্তরীণ সরঞ্জাম অ্যাক্সেস করতে ব্যবহার করতে পারুক, কিন্তু আপনি তাদের আপনার কর্পোরেট MDM-এ এনরোল করতে বাধ্য করতে চান না। এটি একটি গোপনীয়তার উদ্বেগ এবং এটি স্টাফদের কাছ থেকে তীব্র প্রতিরোধের সম্মুখীন হয়। সমাধানটি হলো একটি সেলফ-সার্ভিস অনবোর্ডিং পোর্টাল। এটি যেভাবে কাজ করে তা এখানে দেওয়া হলো। ব্যবহারকারী তাদের ব্যক্তিগত ডিভাইসটিকে একটি ডেডিকেটেড প্রভিশনিং SSID-এর সাথে সংযুক্ত করেন। এই নেটওয়ার্কটি একটি ওয়াল্ড গার্ডেন, যা অনবোর্ডিং পোর্টাল এবং আপনার আইডেন্টিটি প্রোভাইডার ছাড়া অন্য সব কিছুতে অ্যাক্সেস সীমাবদ্ধ করে। ব্যবহারকারী তাদের কর্পোরেট ক্রেডেনশিয়াল ব্যবহার করে প্রমাণীকরণ করেন, সাধারণত Microsoft Entra ID, Okta বা Google Workspace-এর সাথে SAML ইন্টিগ্রেশনের মাধ্যমে। সফল প্রমাণীকরণের পর, সিস্টেমটি SCEP-এর মাধ্যমে একটি অনন্য, ডিভাইস-নির্দিষ্ট ক্লায়েন্ট সার্টিফিকেট তৈরি করে। ডিভাইসে একটি কনফিগারেশন প্রোফাইল পুশ করা হয় যাতে সার্টিফিকেট, রুট CA সার্টিফিকেট এবং নেটওয়ার্ক সেটিংস থাকে। ডিভাইসটি তখন EAP-TLS ব্যবহার করে স্বয়ংক্রিয়ভাবে সুরক্ষিত কর্পোরেট SSID-এর সাথে সংযুক্ত হয়। এটি ব্যবহারকারীর জন্য নির্বিঘ্ন এবং এন্টারপ্রাইজের জন্য সুরক্ষিত। তাদের সার্টিফিকেট বা 802.1X সম্পর্কে কিছু জানার প্রয়োজন নেই। তারা কেবল একবার লগইন করে এবং সংযুক্ত হয়ে যায়। এখন, আসুন বিস্তারিতভাবে বাস্তবায়ন প্রক্রিয়াটি দেখে নেওয়া যাক। ডেপ্লয়মেন্ট সিকোয়েন্সটি অত্যন্ত গুরুত্বপূর্ণ এবং এটি ভুল করা ব্যর্থতার সবচেয়ে সাধারণ কারণ। ধাপ এক: Trusted Root Certificate ডেপ্লয় করুন। যেকোনো ডিভাইস ক্লায়েন্ট সার্টিফিকেটের জন্য অনুরোধ করার আগে বা আপনার RADIUS সার্ভারকে বিশ্বাস করার আগে, তাকে অবশ্যই ইস্যুকারী সার্টিফিকেট অথরিটিকে বিশ্বাস করতে হবে। আপনার Root CA সার্টিফিকেটটি একটি .cer ফাইল হিসেবে এক্সপোর্ট করুন এবং এটি আপনার টার্গেট ডিভাইস গ্রুপগুলোতে ডেপ্লয় করুন। এই ধাপটি অপরিবর্তনীয়। এটি ছাড়া, সম্পূর্ণ চেইনটি ব্যর্থ হয়। ধাপ দুই: SCEP Certificate Profile কনফিগার করুন। এটি ডিভাইসগুলোকে নির্দেশ দেয় কীভাবে তাদের ক্লায়েন্ট সার্টিফিকেট পেতে হবে। আপনাকে সাবজেক্ট নেম ফরম্যাট কনফিগার করতে হবে। ব্যবহারকারী-চালিত প্রমাণীকরণের জন্য, স্ট্যান্ডার্ড হলো CN equals UserPrincipalName। ডিভাইস প্রমাণীকরণের জন্য, CN equals the Azure AD Device ID ব্যবহার করুন। কি ব্যবহার ডিজিটাল সিগনেচার এবং কি এনসাইফারমেন্টে সেট করুন। এক্সটেন্ডেড কি ব্যবহারের অধীনে, OID 1.3.6.1.5.5.7.3.2 সহ Client Authentication নির্দিষ্ট করুন। এই প্রোফাইলটিকে ধাপ একের Trusted Root সার্টিফিকেট প্রোফাইলের সাথে লিঙ্ক করুন। এবং আপনার NDES সার্ভারের বাহ্যিক URL প্রদান করুন। ধাপ তিন: 802.1X WiFi Profile ডেপ্লয় করুন। এটি সার্টিফিকেটগুলোকে নেটওয়ার্ক SSID-এর সাথে সংযুক্ত করে। আপনার অ্যাক্সেস পয়েন্টগুলো দ্বারা যেভাবে ব্রডকাস্ট করা হয় ঠিক সেভাবে নেটওয়ার্কের নাম লিখুন। সিকিউরিটি টাইপ WPA2-Enterprise বা WPA3-Enterprise-এ সেট করুন। EAP টাইপ EAP-TLS-এ সেট করুন। ক্লায়েন্ট প্রমাণীকরণ সার্টিফিকেট হিসেবে SCEP সার্টিফিকেট প্রোফাইলটি নির্বাচন করুন। এবং সার্ভার যাচাইকরণের জন্য Trusted Root সার্টিফিকেটটি নির্দিষ্ট করুন। এই সম্পূর্ণ ব্রিফিং থেকে মনে রাখার মতো সবচেয়ে গুরুত্বপূর্ণ বিষয় হলো এই সিকোয়েন্সটি। প্রথমে ট্রাস্ট, তারপর সার্টিফিকেট, তারপর WiFi। প্রতিবার এই ক্রমানুসারে। এখন আমি আপনাকে কিছু সর্বোত্তম অনুশীলন দেখাব যা আপনাকে প্রোডাকশনে বড় ধরনের ঝামেলা থেকে বাঁচাবে। প্রথমত, Azure AD Application Proxy-এর মাধ্যমে আপনার NDES সার্ভার প্রকাশ করুন। দূরবর্তী ডিভাইসগুলো অন-সাইটে পৌঁছানোর আগে যাতে সার্টিফিকেট প্রভিশন করতে পারে সেজন্য NDES সার্ভারটি ইন্টারনেট থেকে অ্যাক্সেসযোগ্য হতে হবে। কিন্তু একটি অভ্যন্তরীণ সার্ভার সরাসরি ইন্টারনেটে উন্মুক্ত করা একটি বড় নিরাপত্তা ঝুঁকি। Application Proxy আপনাকে ইনবাউন্ড ফায়ারওয়াল পোর্ট না খুলেই সুরক্ষিত দূরবর্তী অ্যাক্সেস প্রদান করে। দ্বিতীয়ত, BYOD ডিভাইসের জন্য স্বল্পস্থায়ী সার্টিফিকেট বাস্তবায়ন করুন। তিন বছরের জন্য বৈধ সার্টিফিকেটের পরিবর্তে, ৯০ দিনের জন্য বৈধ সার্টিফিকেট ইস্যু করুন। যখন সার্টিফিকেটের মেয়াদ শেষ হয়ে যায়, তখন ব্যবহারকারীকে অবশ্যই অনবোর্ডিং পোর্টালের মাধ্যমে পুনরায় প্রমাণীকরণ করতে হবে। এটি প্রাকৃতিকভাবে নেটওয়ার্ক থেকে নিষ্ক্রিয় ডিভাইসগুলোকে ছেঁটে ফেলে। ৯০ দিনের মধ্যে ব্যবহার না করা একটি ডিভাইস কেবল বাদ পড়ে যায়। কোনো ম্যানুয়াল ক্লিনআপের প্রয়োজন হয় না। তৃতীয়ত, এবং এটি অত্যন্ত গুরুত্বপূর্ণ, কঠোর Certificate Revocation List চেকিং প্রয়োগ করতে আপনার RADIUS সার্ভার কনফিগার করুন। যখন কোনো কর্মী প্রতিষ্ঠান ছেড়ে চলে যান, তখন তার Active Directory অ্যাকাউন্ট নিষ্ক্রিয় করা হলেও তার ক্লায়েন্ট সার্টিফিকেট বৈধ থাকলে তার WiFi অ্যাক্সেস অবিলম্বে বাতিল নাও হতে পারে। অ্যাক্সেস মঞ্জুর করার আগে আপনার RADIUS সার্ভারকে অবশ্যই CRL পরীক্ষা করতে হবে। নিশ্চিত করুন যে আপনার CRL ডিস্ট্রিবিউশন পয়েন্টগুলো অত্যন্ত সহজলভ্য। যদি RADIUS সার্ভার CRL-এ পৌঁছাতে না পারে, তবে সবার জন্য প্রমাণীকরণ ব্যর্থ হয়। এটি একটি ব্যাপক বিভ্রাট তৈরি করবে। এখন আসুন কিছু সাধারণ ব্যর্থতার মোড এবং কীভাবে সেগুলো এড়ানো যায় তা দেখে নেওয়া যাক। সবচেয়ে ঘন ঘন ঘটা সমস্যাটি হলো 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 এবং Enroll পারমিশন আছে কিনা তা যাচাই করুন। 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 Trusted Root সার্টিফিকেট পুশ করে, তারপরে একটি SCEP প্রোফাইল পাঠায় যা ট্যাবলেটটিকে তার হার্ডওয়্যার সিকিউর এনক্লেভে নিজস্ব প্রাইভেট কি তৈরি করার নির্দেশ দেয়। ট্যাবলেটটি NDES সার্ভারে একটি CSR জমা দেয়, ক্লায়েন্ট সার্টিফিকেট গ্রহণ করে এবং EAP-TLS ব্যবহার করে Retail POS SSID-এর সাথে সংযুক্ত হয়। যেহেতু প্রাইভেট কি স্থানীয়ভাবে তৈরি হয় এবং কখনই স্থানান্তরিত হয় না, তাই চুরি হওয়া ট্যাবলেটের ক্রেডেনশিয়াল অন্য কোথাও ব্যবহার করা যাবে না। এটি PCI DSS কমপ্লায়েন্সের প্রয়োজনীয়তা পূরণ করে। এখন, আসুন বিজনেস কেস নিয়ে কথা বলি। SCEP 802.1X সার্টিফিকেট ডেপ্লয়মেন্টে রূপান্তর নিরাপত্তা এবং অপারেশন জুড়ে পরিমাপযোগ্য রিটার্ন প্রদান করে। পাসওয়ার্ড-ভিত্তিক WiFi প্রচুর পরিমাণে হেল্পডেস্ক টিকিট তৈরি করে। পাসওয়ার্ডের মেয়াদ শেষ হওয়া, লকআউট, টাইপো। সার্টিফিকেট-ভিত্তিক প্রমাণীকরণ ব্যবহারকারীর কাছে অদৃশ্য। ডিভাইসগুলো স্বয়ংক্রিয়ভাবে সংযুক্ত হয়। এটি সাধারণত WiFi-সম্পর্কিত হেল্পডেস্কের কাজের পরিমাণ ৭০% কমিয়ে দেয়। এটি অপারেশনাল খরচে একটি উল্লেখযোগ্য হ্রাস। EAP-TLS ক্রেডেনশিয়াল হার্ভেস্টিং এবং ম্যান-ইন-দ্য-মিডল আক্রমণের ঝুঁকি দূর করে। এটি রিটেল পরিবেশে PCI DSS এবং সমস্ত সেক্টর জুড়ে GDPR কমপ্লায়েন্সের জন্য অত্যন্ত গুরুত্বপূর্ণ। একটি ডেটা ব্রিচের খরচ একটি সঠিক PKI অবকাঠামো ডেপ্লয় করার খরচের চেয়ে অনেক বেশি। এবং যে সমস্ত সংস্থা ইতিমধ্যে Purple-এর Guest WiFi এবং অ্যানালিটিক্স প্ল্যাটফর্ম ব্যবহার করছে, তাদের জন্য স্টাফদের BYOD ডিভাইসে সুরক্ষিত অনবোর্ডিং প্রসারিত করা একটি সমন্বিত নেটওয়ার্ক ব্যবস্থাপনা কৌশল প্রদান করে। Purple-এর হার্ডওয়্যার-নিরপেক্ষ ক্লাউড ওভারলে Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet-এর সাথে একীভূত হয়, তাই আপনি কোনো একক হার্ডওয়্যার ভেন্ডরের কাছে আটকে থাকবেন না। Purple ৮০,০০০-এরও বেশি লাইভ ভেন্যুতে কাজ করে এবং ২০২৪ সালে ৪৪০ মিলিয়ন লগইন প্রসেস করেছে, যার কাছে ISO 27001, GDPR, CCPA এবং Cyber Essentials সার্টিফিকেট রয়েছে। আপনাকে যে মূল সিদ্ধান্তগুলো নিতে হবে তার একটি দ্রুত সারসংক্ষেপ দিয়ে আমি শেষ করতে চাই। আপনার কি SCEP নাকি PKCS ব্যবহার করা উচিত? WiFi প্রমাণীকরণের জন্য SCEP ব্যবহার করুন। প্রাইভেট কি ডিভাইসেই থাকে। PKCS কেবল ইমেল এনক্রিপশনের জন্য ব্যবহার করুন যেখানে কি এসক্রো প্রয়োজন। সার্টিফিকেট কতক্ষণ বৈধ হওয়া উচিত? BYOD-এর জন্য ৯০ দিন। কর্পোরেট-পরিচালিত ডিভাইসের জন্য এক থেকে দুই বছর। আপনার কি MDM-এ ব্যবহারকারী নাকি ডিভাইস টার্গেটিং ব্যবহার করা উচিত? ব্যবহারকারী লগইন করার আগে সংযুক্ত হতে হবে এমন কর্পোরেট ডিভাইসের জন্য ডিভাইস টার্গেটিং ব্যবহার করুন। BYOD-এর জন্য ব্যবহারকারী টার্গেটিং ব্যবহার করুন যেখানে সার্টিফিকেটটি ব্যক্তির সাথে সংযুক্ত থাকা উচিত। আপনি কীভাবে Android ফ্র্যাগমেন্টেশন পরিচালনা করবেন? যেখানে সম্ভব Passpoint ব্যবহার করুন, যা Hotspot 2.0 নামেও পরিচিত। এটি Android নির্মাতাদের ডিভাইস জুড়ে একটি সামঞ্জস্যপূর্ণ সংযোগের অভিজ্ঞতা প্রদান করে। এবং সবশেষে, সঠিকভাবে সম্পন্ন করার জন্য সবচেয়ে গুরুত্বপূর্ণ একক বিষয়টি কী? আপনার RADIUS সার্ভারে CRL চেকিং। এটি ছাড়া, একটি বাতিল করা সার্টিফিকেটও নেটওয়ার্ক অ্যাক্সেস মঞ্জুর করতে পারে। আজকের ব্রিফিং এখানেই শেষ। আপনি যদি এই বিষয়গুলোর যেকোনো একটি সম্পর্কে আরও গভীরে জানতে চান, তবে এন্টারপ্রাইজ WiFi নিরাপত্তা এবং EAP-TLS সার্টিফিকেট প্রমাণীকরণ সম্পর্কে Purple-এর প্রযুক্তিগত নির্দেশিকাগুলো Purple-এর ওয়েবসাইট purple.ai-তে উপলব্ধ রয়েছে। শোনার জন্য আপনাকে ধন্যবাদ।