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

EAP-TLS বনাম EAP-TTLS: আপনার কোন শংসাপত্র-ভিত্তিক WiFi প্রোটোকলটি বেছে নেওয়া উচিত?

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

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

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

পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
ভূমিকা এবং প্রেক্ষাপট (০:০০ - ২:০০) হ্যালো, এবং Purple-এর এই টেকনিক্যাল ব্রিফিংয়ে আপনাকে স্বাগত। আমি আপনাদের হোস্ট, এবং আজ আমরা এন্টারপ্রাইজ WiFi অথেন্টিকেশনের জন্য EAP-TLS এবং EAP-TTLS-এর মধ্যে গুরুত্বপূর্ণ পার্থক্যগুলো বিশদভাবে আলোচনা করছি। আপনি যদি একজন নেটওয়ার্ক আর্কিটেক্ট, আইটি ডিরেক্টর হন বা রিটেইল চেইন, হাসপাতাল বা স্টেডিয়ামের মতো বড় ভেন্যুগুলোর ইনফ্রাস্ট্রাকচার ম্যানেজ করেন, তবে এই ব্রিফিংটি বিশেষভাবে আপনার জন্যই তৈরি করা হয়েছে। আমরা কোনো জটিলতা ছাড়াই সরাসরি এর সিকিউরিটি আর্কিটেকচার, ইমপ্লিমেন্টেশনের সুবিধা-অসুবিধা এবং কীভাবে আপনার পরিবেশের জন্য সঠিক প্রোটোকলটি বেছে নেবেন তা নিয়ে আলোচনা করব। চলুন সরাসরি মূল বিষয়ে যাওয়া যাক। প্রোটোকলগুলো সম্পর্কে বিস্তারিত জানার আগে, প্রেক্ষাপটটি একটু বুঝে নেওয়া যাক। বেশিরভাগ এন্টারপ্রাইজ WiFi ডিপ্লয়মেন্ট আজও একটি মাত্র শেয়ার্ড পাসওয়ার্ড - অর্থাৎ Pre-Shared Key বা PSK-এর ওপর নির্ভর করে। নেটওয়ার্কের প্রতিটি ডিভাইস একই ক্রেডেনশিয়াল ব্যবহার করে। যখন কোনো কর্মচারী চলে যান, বা কোনো ডিভাইস হারিয়ে যায়, তখন আপনার কাছে দুটি বিকল্প থাকে: সবার জন্য পাসওয়ার্ড পরিবর্তন করা, অথবা কোনো সাবেক কর্মচারী বা চোরের কাছে এখনও বৈধ ক্রেডেনশিয়াল রয়েছে এই ঝুঁকিটি মেনে নেওয়া। কোনো নির্ভরযোগ্য এন্টারপ্রাইজের জন্য এর কোনোটিই গ্রহণযোগ্য নয়। এর সমাধান হলো 802.1X, যা পোর্ট-ভিত্তিক নেটওয়ার্ক অ্যাক্সেস কন্ট্রোলের জন্য IEEE স্ট্যান্ডার্ড। 802.1X প্রতিটি ডিভাইসকে তার নিজস্ব আলাদা অথেন্টিকেশন ক্রেডেনশিয়াল দেয়। যখন কোনো ডিভাইস কানেক্ট হয়, তখন অ্যাক্সেস পয়েন্ট সরাসরি অ্যাক্সেস দেয় না। এটি অথেন্টিকেশন রিকোয়েস্টটিকে একটি সেন্ট্রালাইজড RADIUS সার্ভারে ফরোয়ার্ড করে, যা ক্রেডেনশিয়াল যাচাই করে এবং পোর্টটি ওপেন করা হবে কিনা তা অ্যাক্সেস পয়েন্টকে জানায়। এর ফলে একটি অডিটেবল, বাতিলযোগ্য এবং প্রতি-ডিভাইস ভিত্তিক অ্যাক্সেস কন্ট্রোল পাওয়া যায়। এটিই হলো সেই ভিত্তি যার ওপর EAP-TLS এবং EAP-TTLS উভয়ই গড়ে উঠেছে। উভয় প্রোটোকলই হলো এক্সটেনসিবল অথেন্টিকেশন প্রোটোকল মেথড, বা EAP মেথড, যা এই 802.1X ফ্রেমওয়ার্কের মধ্যে কাজ করে। প্রশ্নটি এটি নয় যে আপনি 802.1X ব্যবহার করবেন কিনা। প্রশ্নটি হলো এর ভেতরে কোন EAP মেথডটি ব্যবহার করবেন। আর আজ আমরা এখানে সেই প্রশ্নেরই উত্তর দিতে এসেছি। EAP-TLS টেকনিক্যাল ডিপ-ডাইভ (২:০০ - ৫:৩০) চলুন শুরু করা যাক EAP-TLS দিয়ে, যার পূর্ণরূপ হলো ট্রান্সপোর্ট লেয়ার সিকিউরিটি। EAP-TLS-কে RFC 5216-এ সংজ্ঞায়িত করা হয়েছে এবং এটিকে ওয়্যারলেস অথেন্টিকেশনের জন্য গোল্ড স্ট্যান্ডার্ড হিসেবে ব্যাপকভাবে বিবেচনা করা হয়। এর মূল নীতি হলো পারস্পরিক অথেন্টিকেশন। নেটওয়ার্ক অ্যাক্সেস পাওয়ার আগে ক্লায়েন্ট ডিভাইস এবং RADIUS সার্ভার উভয়কেই তাদের পরিচয় প্রমাণ করতে বৈধ X.509 ডিজিটাল সার্টিফিকেট প্রদর্শন করতে হবে। এই প্রক্রিয়ার কোনো পর্যায়েই কোনো পাসওয়ার্ডের প্রয়োজন হয় না। একদম শূন্য। সিকিউরিটির দৃষ্টিকোণ থেকে এটি অত্যন্ত গুরুত্বপূর্ণ। পাসওয়ার্ড ফিশিংয়ের মাধ্যমে হাতিয়ে নেওয়া যেতে পারে। ব্রুট ফোর্সের মাধ্যমে অনুমান করা যেতে পারে। অথবা কোনো থার্ড-পার্টি সার্ভিসে ডেটা ব্রিচ হলে সেখান থেকে চুরি হতে পারে যেখানে আপনার কর্মচারী একই পাসওয়ার্ড পুনরায় ব্যবহার করেছিলেন। সার্টিফিকেট ফিশিং করা যায় না, অনুমান করা যায় না এবং এটি একটি নির্দিষ্ট ডিভাইসের সাথে যুক্ত থাকে। কোনো ক্ষতিকারক ব্যবহারকারী যদি আপনার নেটওয়ার্কে প্রবেশ করতে চায়, তবে তার সেই ফিজিক্যাল ডিভাইস এবং তার মধ্যে থাকা ক্রিপ্টোগ্রাফিক প্রাইভেট কী প্রয়োজন হবে। এটি সম্পূর্ণ আলাদা একটি থ্রেট মডেল।আসুন আমি আপনাকে বিস্তারিতভাবে EAP-TLS হ্যান্ডশেকটি বুঝিয়ে বলি, কারণ এটি বুঝতে পারলে এই প্রোটোকলটি কেন এত নিরাপদ তা পরিষ্কার হয়ে যায়। যখন একটি ডিভাইস WiFi নেটওয়ার্কে সংযোগ করার চেষ্টা করে, তখন অ্যাক্সেস পয়েন্টটি ডিভাইসের পরিচয়ের জন্য একটি EAP-Request পাঠায়। ডিভাইসটি সাড়া দেয়। অ্যাক্সেস পয়েন্টটি এটিকে RADIUS সার্ভারে ফরোয়ার্ড করে। RADIUS সার্ভার একটি Server Hello মেসেজ এবং সেইসাথে তার X.509 সার্টিফিকেট পাঠিয়ে TLS হ্যান্ডশেক শুরু করে। ক্লায়েন্ট তার বিশ্বস্ত রুট সার্টিফিকেট অথরিটি স্টোরের বিপরীতে এই সার্ভার সার্টিফিকেটটি যাচাই করে। যদি যাচাইকরণ ব্যর্থ হয়, হ্যান্ডশেকটি অবিলম্বে বন্ধ হয়ে যায়। ডিভাইসটি সংযোগ করতে অস্বীকার করে। এটিই Evil Twin আক্রমণ থেকে রক্ষা করে, যেখানে একজন হ্যাকার আপনার নেটওয়ার্কের ছদ্মবেশ ধারণ করার জন্য একটি নকল অ্যাক্সেস পয়েন্ট সেট আপ করে। যদি সার্ভার সার্টিফিকেটটি বৈধ হয়, তাহলে ক্লায়েন্ট তার নিজস্ব X.509 সার্টিফিকেট RADIUS সার্ভারের কাছে উপস্থাপন করে। RADIUS সার্ভার ক্লায়েন্ট সার্টিফিকেটটি যাচাই করে: এটি বিশ্বস্ত রুট CA পর্যন্ত সিগনেচার চেইন পরীক্ষা করে, সার্টিফিকেটটির মেয়াদ শেষ হয়ে যায়নি তা যাচাই করে এবং সার্টিফিকেটটি প্রত্যাহার করা হয়নি তা নিশ্চিত করতে সার্টিফিকেট রেভোকেশন লিস্ট পরীক্ষা করে। যখন উভয় পক্ষই সন্তুষ্ট হয়, কেবল তখনই TLS টানেলটি প্রতিষ্ঠিত হয় এবং EAP-Success মেসেজটি পাঠানো হয়, যা নেটওয়ার্ক অ্যাক্সেস প্রদান করে। সম্পূর্ণ আদান-প্রদানটি TLS 1.2 বা 1.3 ব্যবহার করে, যা পারফেক্ট ফরোয়ার্ড সিক্রেসি প্রদান করে। এখন, এই স্তরের নিরাপত্তার জন্য একটি অপারেশনাল প্রয়োজনীয়তা রয়েছে: আপনার একটি পাবলিক কি ইনফ্রাস্ট্রাকচার বা PKI প্রয়োজন। ন্যূনতমভাবে, আপনার একটি অফলাইন রুট সার্টিফিকেট অথরিটি এবং একটি অনলাইন ইস্যুকারী সার্টিফিকেট অথরিটি প্রয়োজন। রুট CA-টি এয়ার-গ্যাপড হওয়া উচিত, কারণ এর প্রাইভেট কি আপনার সমগ্র সার্টিফিকেট অনুক্রমের জন্য মাস্টার ট্রাস্ট অ্যাঙ্কর। ইস্যুকারী CA প্রতিদিনের সার্টিফিকেট ইস্যু করার কাজ পরিচালনা করে এবং সার্টিফিকেট রেভোকেশন লিস্ট প্রকাশ করে। এবং অত্যন্ত গুরুত্বপূর্ণভাবে, নেটওয়ার্কের প্রতিটি ডিভাইসে ক্লায়েন্ট সার্টিফিকেট স্থাপন করার জন্য আপনার একটি মেকানিজম প্রয়োজন। হাজার হাজার ডিভাইসের একটি বহরের জন্য, এর অর্থ হল SCEP - Simple Certificate Enrolment Protocol ব্যবহার করে আপনার PKI-কে একটি মোবাইল ডিভাইস ম্যানেজমেন্ট প্ল্যাটফর্মের সাথে একীভূত করা। যখন একটি কর্পোরেট ডিভাইস আপনার MDM-এ নথিভুক্ত হয়, তখন এটি কোনো ব্যবহারকারীর হস্তক্ষেপ ছাড়াই স্বয়ংক্রিয়ভাবে তার সার্টিফিকেটের জন্য অনুরোধ করে এবং সেটি গ্রহণ করে। বাস্তবায়ন পরিস্থিতি (5:30 - 8:00) তাহলে, আপনার কোন প্রোটোকলটি স্থাপন করা উচিত? সিদ্ধান্তটি প্রায় সম্পূর্ণভাবে আপনার ডিভাইস ম্যানেজমেন্টের সক্ষমতা এবং আপনার কমপ্লায়েন্স সংক্রান্ত প্রয়োজনীয়তার ওপর নির্ভর করে। আমি আপনাকে একটি ব্যবহারিক সিদ্ধান্ত নেওয়ার কাঠামো দিই। নিজেকে তিনটি প্রশ্ন করুন। প্রথম: এই নেটওয়ার্কের সাথে সংযুক্ত সমস্ত ডিভাইস কি Microsoft Intune বা Jamf-এর মতো একটি MDM প্ল্যাটফর্মের মাধ্যমে কর্পোরেট-পরিচালিত? যদি হ্যাঁ হয়, তবে ক্লায়েন্ট সার্টিফিকেট স্থাপন করার জন্য আপনার কাছে ইনফ্রাস্ট্রাকচার রয়েছে এবং EAP-TLS হল সঠিক পছন্দ। দ্বিতীয়: এই নেটওয়ার্কের কি PCI-DSS 4.0, HIPAA, বা WPA3 Enterprise 192-বিট প্রয়োজনীয়তা পূরণ করতে হবে? যদি হ্যাঁ হয়, তবে EAP-TLS হল প্রয়োজনীয় পছন্দ। তৃতীয়: আপনার কি একটি উল্লেখযোগ্য অনুপাতে অনিয়ন্ত্রিত বা BYOD ডিভাইস রয়েছে? যদি হ্যাঁ হয়, তবে আপনার নেটওয়ার্কের সেই অংশের জন্য EAP-TTLS হল বাস্তবসম্মত পছন্দ। আমি আপনাকে দুটি বাস্তবসম্মত দৃশ্যপট দিয়ে বুঝিয়ে বলি। দৃশ্যপট এক: চারশত স্টোর বিশিষ্ট একটি জাতীয় রিটেইল চেইন। প্রতিটি পয়েন্ট-অফ-সেল টার্মিনাল এবং কর্মীদের হ্যান্ডহেল্ড স্ক্যানার Microsoft Intune-এ নথিভুক্ত রয়েছে। নেটওয়ার্কটি PCI-DSS 4.0-এর আওতাভুক্ত। এই পরিবেশে, আপনি EAP-TLS মোতায়েন করবেন। আপনি একটি প্রাইভেট PKI স্থাপন করেন, SCEP-এর মাধ্যমে প্রতিটি ডিভাইসে অনন্য ক্লায়েন্ট সার্টিফিকেট পুশ করতে Intune ব্যবহার করেন এবং Certificate Revocation List পরীক্ষা করার জন্য আপনার RADIUS সার্ভার কনফিগার করেন। কোনো ডিভাইস চুরি হলে, আপনি সেটির সার্টিফিকেট বাতিল করে দেন এবং মাত্র কয়েক মিনিটের মধ্যে সেটি নেটওয়ার্কের বাইরে চলে যায়। কোনো পাসওয়ার্ড রিসেট করার ঝামেলা নেই। চারশত সাইট জুড়ে কোনো শেয়ার্ড সিক্রেট রোটেট করারও প্রয়োজন নেই। দৃশ্যপট দুই: একটি বড় বিশ্ববিদ্যালয়ের ক্যাম্পাস যেখানে বিশ হাজার শিক্ষার্থী ব্যক্তিগত ল্যাপটপ, স্মার্টফোন এবং ট্যাবলেট ব্যবহার করছে। আইটি টিমের পক্ষে ব্যক্তিগত ডিভাইসগুলোতে সার্টিফিকেট ইনস্টল করা সম্ভব নয়। এই পরিবেশে, EAP-TTLS হলো একটি বাস্তবসম্মত পছন্দ। আপনি আপনার RADIUS সার্ভারগুলোতে একটি বিশ্বস্ত সার্টিফিকেট ইনস্টল করেন, আপনার বিশ্ববিদ্যালয়ের ডিরেক্টরি সার্ভিসের সাথে এটি সংহত করেন এবং শিক্ষার্থীরা সুরক্ষিত টানেলের মধ্যে তাদের বিদ্যমান ক্রেডেনশিয়াল ব্যবহার করে প্রমাণীকরণ সম্পন্ন করে। এটি ক্লায়েন্ট সাইডে অতিরিক্ত কোনো সফটওয়্যার ছাড়াই Windows, macOS, Linux, Android এবং iOS সমর্থন করে। অনেক বড় এন্টারপ্রাইজে, সমাধানটি আসলে উভয়ই। আপনি আপনার পরিচালিত কর্পোরেট ডিভাইসগুলোর জন্য EAP-TLS মোতায়েন করেন এবং ঠিকাদার, ভিজিটর ও BYOD-এর জন্য EAP-TTLS বা একটি পৃথক সুরক্ষিত নেটওয়ার্ক ব্যবহার করেন। এটি হসপিটালিটি গ্রুপগুলোতে একটি সাধারণ প্যাটার্ন, যেখানে স্টাফদের ডিভাইসগুলো পরিচালিত হয় এবং সার্টিফিকেট দিয়ে ইস্যু করা হয়, যেখানে অতিথি-মুখী পরিকাঠামো সম্পূর্ণ ভিন্ন একটি প্রমাণীকরণ পথ ব্যবহার করে। চটজলদি প্রশ্নোত্তর (৮:০০ - ৯:০০) চলুন CTO এবং নেটওয়ার্ক আর্কিটেক্টদের কাছ থেকে প্রায়শই শোনা কিছু প্রশ্নের চটজলদি উত্তর দেওয়া যাক। প্রশ্ন এক: WPA3 Enterprise-এর জন্য কি EAP-TLS প্রয়োজন? আপনি যদি WPA3 Enterprise ১৯২-বিট সিকিউরিটি স্যুট বাস্তবায়ন করেন, তবে হ্যাঁ, EAP-TLS হলো একমাত্র অনুমোদিত পদ্ধতি। Wi-Fi Alliance-এর WPA3 Enterprise ১৯২-বিট প্রয়োজনীয়তা পূরণকারী একমাত্র EAP পদ্ধতি হলো এটিই। প্রশ্ন দুই: আমরা কি IoT ডিভাইসের জন্য EAP-TTLS ব্যবহার করতে পারি? সাধারণত, না। হেডলেস IoT ডিভাইস, যেমন ইনফিউশন পাম্প বা এনভায়রনমেন্টাল সেন্সরগুলোতে সাধারণত জটিল অভ্যন্তরীণ প্রমাণীকরণ পদ্ধতি পরিচালনা করার মতো ইন্টারফেস থাকে না। EAP-TLS আসলে IoT-এর জন্য আরও বেশি উপযুক্ত, কারণ আপনি ডিভাইস স্টেজিংয়ের সময় সার্টিফিকেট প্রভিশন করতে পারেন। কোনো ব্যবহারকারীর হস্তক্ষেপ ছাড়াই ডিভাইসটি স্বয়ংক্রিয়ভাবে প্রমাণীকরণ সম্পন্ন করে। প্রশ্ন তিন: একটি EAP-TLS নেটওয়ার্কে BYOD-এর ক্ষেত্রে কী হবে? অপরীক্ষিত ব্যক্তিগত ডিভাইসগুলোর জন্য, EAP-TLS পরিচালনা করা কঠিন। আপনি একটি অস্থায়ী সার্টিফিকেট প্রভিশন করতে অনবোর্ডিং পোর্টাল ব্যবহার করতে পারেন, তবে এটি প্রক্রিয়াটিকে জটিল করে তোলে। BYOD-এর জন্য, EAP-TTLS বা উপযুক্ত সেগমেন্টেশন সহ একটি ডেডিকেটেড গেস্ট নেটওয়ার্ক সাধারণত সঠিক সমাধান। প্রশ্ন চার: হার্ডওয়্যার ভেন্ডরদের সাথে এটি কীভাবে সম্পর্কিত? EAP-TLS এবং EAP-TTLS উভয়ই সমস্ত প্রধান এন্টারপ্রাইজ WiFi হার্ডওয়্যার প্ল্যাটফর্ম - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist এবং Ubiquiti UniFi জুড়ে সমর্থিত। প্ল্যাটফর্ম ভেদে কনফিগারেশনের বিবরণ ভিন্ন হতে পারে, তবে অন্তর্নিহিত মানদণ্ডগুলো ভেন্ডর-নিরপেক্ষ। সারসংক্ষেপ এবং পরবর্তী পদক্ষেপ (9:00 - 10:00) উপসংহার হিসেবে, এখানে আপনার জন্য প্রধান শিক্ষণীয় বিষয়গুলো দেওয়া হলো। EAP-TLS পারস্পরিক সার্টিফিকেট অথেন্টিকেশন এর মাধ্যমে সর্বোচ্চ নিরাপত্তা প্রদান করে। এটি পাসওয়ার্ডের ঝুঁকি সম্পূর্ণরূপে দূর করে এবং ম্যানেজড ডিভাইস ফ্লিট ও নিয়ন্ত্রিত পরিবেশের জন্য এটিই সঠিক পছন্দ। EAP-TTLS সার্ভার-সাইড সার্টিফিকেট এবং এনক্রিপ্ট করা ক্রেডেনশিয়াল টানেলিংয়ের মাধ্যমে শক্তিশালী নিরাপত্তা প্রদান করে। এটি মিশ্র অথবা BYOD পরিবেশের জন্য সঠিক পছন্দ। উভয় প্রোটোকলের ক্ষেত্রেই আপনাকে প্রতিটি ক্লায়েন্টে সার্ভার সার্টিফিকেট ভ্যালিডেশন বাধ্যতামূলক করতে হবে। এটি ছাড়া, কোনো প্রোটোকলই আপনাকে রোগ (rogue) অ্যাক্সেস পয়েন্টের বিরুদ্ধে সুরক্ষা দিতে পারবে না। এবং সার্টিফিকেট লাইফসাইকেল ম্যানেজমেন্ট হলো EAP-TLS এর প্রধান অপারেশনাল চ্যালেঞ্জ - প্রথম দিন থেকেই MDM এবং SCEP এর মাধ্যমে এটিকে অটোমেট করুন। আপনার পরবর্তী পদক্ষেপ? আপনার বর্তমান 802.1X ডেপ্লয়মেন্ট অডিট করুন। আপনি যদি এখনও শেয়ার করা পাসওয়ার্ডের ওপর নির্ভর করে থাকেন, তবে আপনার মাইগ্রেশনের পরিকল্পনা করুন। আপনার ক্লায়েন্ট সাপ্লিক্যান্টগুলো সার্ভার সার্টিফিকেট ভ্যালিডেট করছে কিনা তা পরীক্ষা করুন। এবং আপনি যদি একাধিক ভেন্যু বা কোনো ডিস্ট্রিবিউটেড এস্টেটে ডেপ্লয়মেন্ট করছেন, তবে অপারেশনাল বোঝা কমাতে একটি ক্লাউড-হোস্টেড RADIUS সার্ভিস ব্যবহারের কথা বিবেচনা করুন। Purple এর এই টেকনিক্যাল ব্রিফিংটি শোনার জন্য আপনাকে ধন্যবাদ। Purple আমাদের ৮০,০০০ এরও বেশি লাইভ ভেন্যু জুড়ে স্টাফ WiFi এর জন্য EAP-TLS এবং EAP-TTLS উভয় অথেন্টিকেশন পাথ সমর্থন করে। আরও বিস্তারিত ডেপ্লয়মেন্ট গাইড এবং আমাদের অ্যানালিটিক্স ও আইডেন্টিটি প্ল্যাটফর্মগুলো কীভাবে আপনার সুরক্ষিত নেটওয়ার্কের সাথে ইন্টিগ্রেট করে তা জানতে purple dot ai ভিজিট করুন।

📚 আমাদের মূল সিরিজের অংশ: Enterprise WiFi Security Guide →

header_image.png

কার্যনির্বাহী সংক্ষিপ্তসার

আপনার 802.1X স্থাপনার জন্য সঠিক EAP পদ্ধতি নির্বাচন করা নির্ধারণ করে যে আপনার এন্টারপ্রাইজ WiFi কি সত্যিই নিরাপদ নাকি কাগজে-কলমে কেবল অনুগত। RFC 5216-এ সংজ্ঞায়িত EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), পারস্পরিক সার্টিফিকেট প্রমাণীকরণের দাবি করে: নেটওয়ার্ক অ্যাক্সেস দেওয়ার আগে ক্লায়েন্ট ডিভাইস এবং RADIUS সার্ভার উভয়কেই বৈধ X.509 সার্টিফিকেট উপস্থাপন করতে হয়। কোনো অবস্থাতেই পাসওয়ার্ড বিনিময় করা হয় না। RFC 5281-এ সংজ্ঞায়িত EAP-TTLS (Tunneled Transport Layer Security), একটি এনক্রিপ্ট করা TLS টানেল স্থাপন করতে শুধুমাত্র একটি সার্ভার-সাইড সার্টিফিকেটের প্রয়োজন হয়, যার ভিতরে ক্লায়েন্ট বিদ্যমান ডিরেক্টরি শংসাপত্র ব্যবহার করে প্রমাণীকরণ সম্পন্ন করে।

খুচরা চেইন, আতিথেয়তা স্থান এবং পাবলিক সেক্টর প্রতিষ্ঠান জুড়ে অবকাঠামো পরিচালনাকারী CTO এবং নেটওয়ার্ক আর্কিটেক্টদের জন্য এই সিদ্ধান্তটি একটি প্রশ্নে এসে দাঁড়ায়: আপনি কি ডিভাইসগুলো পরিচালনা করেন? আপনি যদি MDM-এর মাধ্যমে ডিভাইস বহর নিয়ন্ত্রণ করেন, তবে EAP-TLS হল চূড়ান্ত পছন্দ। আপনি যদি একটি বৈচিত্র্যময় BYOD পরিবেশকে সমর্থন করেন বা একটি শক্তিশালী Public Key Infrastructure (PKI) এর অভাব থাকে, তবে EAP-TTLS একটি বাস্তবসম্মত, অত্যন্ত নিরাপদ বিকল্প প্রদান করে। Purple ৮০,০০০+ সরাসরি ভেন্যু জুড়ে কর্মীদের WiFi এর জন্য উভয় প্রমাণীকরণ পথকেই সমর্থন করে।

comparison_chart.png

প্রযুক্তিগত গভীর বিশ্লেষণ

EAP-TLS এর আর্কিটেকচার

EAP-TLS IEEE 802.1X পোর্ট-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ কাঠামোর মধ্যে একটি পারস্পরিক প্রমাণীকরণ মডেলে কাজ করে। প্রতিটি প্রমাণীকরণ বিনিময়ের সাথে তিনটি মূল উপাদান জড়িত থাকে: supplicant (ক্লায়েন্ট ডিভাইস), authenticator (ওয়্যারলেস অ্যাক্সেস পয়েন্ট), এবং authentication server (RADIUS সার্ভার)। অ্যাক্সেস পয়েন্ট নিজেই প্রমাণীকরণের সিদ্ধান্ত নেয় না। এটি একটি স্বচ্ছ রিলে হিসাবে কাজ করে, যা EAP বার্তাগুলোকে RADIUS প্যাকেটে এনক্যাপসুলেট করে এবং সেগুলোকে প্রমাণীকরণ সার্ভারে প্রেরণ করে।EAP-TLS হ্যান্ডশেক নিম্নলিখিত উপায়ে অগ্রসর হয়। অ্যাক্সেস পয়েন্ট সংযোগকারী ডিভাইসে একটি EAP-Request/Identity পাঠায়। ডিভাইসটি তার পরিচয় দিয়ে সাড়া দেয়। RADIUS সার্ভার একটি EAP-TLS/Start বার্তার মাধ্যমে TLS হ্যান্ডশেক শুরু করে। ক্লায়েন্ট তার সমর্থিত TLS সাইফার সুইটগুলির বিজ্ঞাপন দিয়ে একটি ClientHello পাঠায়। RADIUS সার্ভার একটি ServerHello, তার X.509 সার্ভার সার্টিফিকেট এবং একটি সার্টিফিকেটের অনুরোধ সহ সাড়া দেয়। ক্লায়েন্ট তার বিশ্বস্ত রুট CA স্টোরের বিপরীতে সার্ভার সার্টিফিকেটটি যাচাই করে। যাচাইকরণ ব্যর্থ হলে, হ্যান্ডশেকটি বন্ধ হয়ে যায় - যা ক্ষতিকারক অ্যাক্সেস পয়েন্টগুলির বিরুদ্ধে সুরক্ষা প্রদান করে। ক্লায়েন্ট তখন তার নিজস্ব X.509 সার্টিফিকেট উপস্থাপন করে। RADIUS সার্ভার ক্লায়েন্ট সার্টিফিকেটটি যাচাই করে, বিশ্বস্ত রুট CA পর্যন্ত সিগনেচার চেইন পরীক্ষা করে, সার্টিফিকেটটির মেয়াদ শেষ হয়ে যায়নি তা যাচাই করে এবং সার্টিফিকেট রিভোকেশন লিস্ট (CRL) পরীক্ষা করে বা OCSP কুয়েরি করে। কেবল যখন উভয় পক্ষ সন্তুষ্ট হয়, তখনই TLS টানেলটি প্রতিষ্ঠিত হয় এবং নেটওয়ার্ক অ্যাক্সেস মঞ্জুর করা হয়।

যেহেতু কোনও পাসওয়ার্ড বিনিময় করা হয় না, তাই EAP-TLS অফলাইন ডিকশনারি অ্যাটাক, ক্রেডেনশিয়াল স্টাফিং এবং ফিশিং থেকে সুরক্ষিত। এটি একমাত্র EAP পদ্ধতি যা WPA3-Enterprise 192-bit (Suite B) প্রয়োজনীয়তা পূরণ করে এবং এটি কার্ডহোল্ডার ডেটা এনভায়রনমেন্টের জন্য PCI-DSS 4.0 দ্বারা এবং উচ্চ-নিরাপত্তা সম্পন্ন ওয়্যারলেস ডিপ্লয়মেন্টের জন্য NIST SP 800-120 দ্বারা বাধ্যতামূলক বা জোরালোভাবে সুপারিশকৃত।

EAP-TLS এর জন্য একটি PKI প্রয়োজন। আপনার অন্তত একটি অফলাইন রুট CA এবং একটি অনলাইন ইস্যুয়িং CA প্রয়োজন। রুট CA-টি অবশ্যই এয়ার-গ্যাপড হতে হবে, কারণ এর প্রাইভেট কী হল আপনার সম্পূর্ণ সার্টিফিকেট হায়ারার্কির জন্য মাস্টার ট্রাস্ট অ্যাঙ্কর। ইস্যুয়িং CA দৈনন্দিন সার্টিফিকেট ইস্যু করা পরিচালনা করে এবং CRL প্রকাশ করে। ক্লায়েন্ট সার্টিফিকেটগুলি পৃথক ডিভাইসে ইস্যু করা হয়, ব্যবহারকারীদের নয় - এটি একটি ডিভাইস-আইডেন্টিটি মডেল। এই পার্থক্যটি IoT ডিভাইস, শেয়ার্ড টার্মিনাল এবং হেডলেস সিস্টেমের জন্য অত্যন্ত গুরুত্বপূর্ণ।

EAP-TTLS এর গঠন

EAP-TTLS ডিজাইন করা হয়েছিল প্রতিটি ক্লায়েন্ট ডিভাইসে সার্টিফিকেট ডিপ্লয় করার অপারেশনাল বোঝা ছাড়াই শক্তিশালী 802.1X নিরাপত্তা প্রদান করার জন্য। এটি দুটি ধাপে কাজ করে। প্রথম ধাপে, RADIUS সার্ভার তার সার্টিফিকেট উপস্থাপন করে এবং একটি নিরাপদ TLS টানেল স্থাপন করে। শুধুমাত্র সার্ভারের একটি সার্টিফিকেট প্রয়োজন হয়। দ্বিতীয় ধাপে, একটি অভ্যন্তরীণ প্রমাণীকরণ পদ্ধতি ব্যবহার করে সেই এনক্রিপ্ট করা টানেলের মধ্যে ক্লায়েন্টকে অনুমোদিত করা হয়। সাধারণ অভ্যন্তরীণ পদ্ধতিগুলির মধ্যে রয়েছে PAP (পাসওয়ার্ড অথেন্টিকেশন প্রোটোকল), CHAP এবং MS-CHAPv2। ক্লায়েন্ট তার ইউজারনেম এবং পাসওয়ার্ড পাঠায়, কিন্তু যেহেতু এই বিনিময়টি TLS টানেলের মধ্যে ঘটে, তাই ট্রানজিটে ক্রেডেনশিয়ালগুলি এনক্রিপ্ট করা থাকে এবং কখনই বাতাসে উন্মুক্ত হয় না।

EAP-TTLS, macOS, Linux, Android এবং iOS জুড়ে চমৎকার ক্রস-প্ল্যাটফর্ম সমর্থন প্রদান করে। সতর্কতাটি কেবল Windows এর ক্ষেত্রে প্রযোজ্য: বিল্ট-ইন Windows সাপ্লিক্যান্ট ওয়্যারলেস 802.1X এর জন্য ডিফল্টভাবে EAP-TTLS সমর্থন করে না। প্রচুর পরিমাণে Windows ডিভাইস রয়েছে এমন এনভায়রনমেন্টে একটি থার্ড-পার্টি সাপ্লিক্যান্টের প্রয়োজন হতে পারে, যা অপারেশনাল জটিলতা বাড়ায়। Windows-কেন্দ্রিক এনভায়রনমেন্টের জন্য, MS-CHAPv2 সহ PEAP প্রায়শই আরও বাস্তবসম্মত পছন্দ।EAP-TTLS এর সবচেয়ে বড় সীমাবদ্ধতা হলো এটি পাসওয়ার্ডের সহজাত ঝুঁকিগুলিকে দূর করে না। কোনো ব্যবহারকারী যদি একটি দুর্বল পাসওয়ার্ড বেছে নেন, তবে এটি অফলাইন ব্রুট ফোর্স অ্যাটাকের ঝুঁকিতেই থেকে যায়। অভ্যন্তরীণ অথেনটিকেশন যদি PAP ব্যবহার করে, তবে পাসওয়ার্ডটি টানেলের মধ্যে প্লেইন টেক্সট হিসেবে পাঠানো হয় - যা গ্রহণযোগ্য যদি আপনি আপনার RADIUS পরিকাঠামোকে বিশ্বাস করেন, তবে এটি বোঝা একটি অপরিহার্য ট্রাস্ট মডেল।

পাশাপাশি তুলনা

বৈশিষ্ট্য EAP-TLS EAP-TTLS
RFC স্ট্যান্ডার্ড RFC 5216 RFC 5281
ক্লায়েন্ট সার্টিফিকেট প্রয়োজন হ্যাঁ না
সার্ভার সার্টিফিকেট প্রয়োজন হ্যাঁ হ্যাঁ
অথেনটিকেশন মডেল পারস্পরিক (উভয় পক্ষ) শুধুমাত্র-সার্ভার
পাসওয়ার্ড ঝুঁকি কোনোটিই নয় - পাসওয়ার্ডহীন এনক্রিপ্ট করা টানেলে পাসওয়ার্ড
PKI প্রয়োজনীয়তা সম্পূর্ণ PKI (Root CA + Issuing CA + MDM) শুধুমাত্র সার্ভার সার্টিফিকেট
WPA3-Enterprise 192-bit প্রয়োজনীয় পদ্ধতি সমর্থিত নয়
PCI DSS 4.0 সারিবদ্ধতা দৃঢ়ভাবে প্রস্তাবিত শক্তিশালী অভ্যন্তরীণ অথেনটিকেশন সহ গ্রহণযোগ্য
BYOD উপযুক্ততা কম (ক্লায়েন্ট সার্টিফিকেট প্রয়োজন) উচ্চ (শুধুমাত্র ক্রেডেনশিয়াল)
IoT ডিভাইসের উপযুক্ততা উচ্চ (স্টেজিংয়ে সার্টিফিকেট প্রোভিশন করা হয়) কম (ক্রেডেনশিয়াল ইনপুটের জন্য কোনো UI নেই)
Windows নেটিভ সাপোর্ট হ্যাঁ আংশিক (প্রায়শই থার্ড-পার্টি সাপ্লিক্যান্টের প্রয়োজন হয়)
macOS/Linux/Android সাপোর্ট হ্যাঁ হ্যাঁ
স্থাপনার জটিলতা উচ্চ মাঝারি

বাস্তবায়ন নির্দেশিকা

পরিচালিত ফ্লিটের জন্য EAP-TLS স্থাপন করা

EAP-TLS স্থাপনের জন্য একটি কার্যকরী PKI এবং একটি MDM প্ল্যাটফর্মের প্রয়োজন। এন্টারপ্রাইজ স্কেলে ম্যানুয়াল সার্টিফিকেট ইনস্টলেশন কার্যকর নয়। SCEP (Simple Certificate Enrolment Protocol) বা EST (Enrolment over Secure Transport) ব্যবহার করে আপনাকে অবশ্যই আপনার PKI-কে আপনার MDM-এর সাথে ইন্টিগ্রেট করতে হবে। যখন একটি কর্পোরেট ডিভাইস এনরোল করা হয়, এটি ব্যবহারকারীর হস্তক্ষেপ ছাড়াই স্বয়ংক্রিয়ভাবে তার সার্টিফিকেটের জন্য অনুরোধ করে এবং তা গ্রহণ করে।

আইডেন্টিটি ম্যানেজমেন্টের জন্য, Purple Connect লাইসেন্সের অধীনে OpenRoaming এর মতো পরিষেবাগুলির জন্য একটি ফ্রি আইডেন্টিটি প্রোভাইডার হিসেবে কাজ করে, যা অন্তর্নিহিত সার্টিফিকেট এবং আইডেন্টিটি ফ্রেমওয়ার্ক ব্যবহার করে বিভিন্ন লোকেশন জুড়ে নিরাপদ রোমিং সহজতর করে।

RADIUS-এর ক্ষেত্রে, আপনার ইন্টারনাল CA-র বিপরীতে ক্লায়েন্ট সার্টিফিকেট যাচাই করতে এবং রিয়েল-টাইম রেভোকেশন চেকিংয়ের জন্য CRL চেক করতে অথবা OCSP ব্যবহার করতে আপনার সার্ভারটি কনফিগার করুন। সমর্থিত RADIUS প্ল্যাটফর্মগুলির মধ্যে রয়েছে FreeRADIUS, Microsoft NPS, এবং Cisco ISE। Purple-এর ক্লাউড ওভারলে Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, এবং Fortinet হার্ডওয়্যারের সাথে ইন্টিগ্রেট করে।

মিশ্র পরিবেশের জন্য EAP-TTLS স্থাপন করা

অপরিচালিত ডিভাইস আছে এমন পরিবেশের জন্য EAP-TTLS হলো সর্বোত্তম পছন্দ। আপনাকে শুধুমাত্র আপনার RADIUS সার্ভারে একটি বিশ্বস্ত সার্টিফিকেট স্থাপন করতে হবে। অভ্যন্তরীণ অথেনটিকেশন ক্রেডেনশিয়াল যাচাই করতে আপনার RADIUS সার্ভারটি যাতে সরাসরি আপনার ডিরেক্টরি পরিষেবা - Microsoft Entra ID, Okta, বা Google Workspace - এর সাথে ইন্টিগ্রেট করে তা নিশ্চিত করুন। আপনার নির্দিষ্ট বিশ্বস্ত CA-র বিপরীতে সার্ভার সার্টিফিকেট ভ্যালিডেশন জোরদার করতে আপনার MDM-স্থাপিত WiFi প্রোফাইলগুলি কনফিগার করুন। এই পদক্ষেপটি ছাড়া, TLS টানেলটি রোগ অ্যাক্সেস পয়েন্টের বিরুদ্ধে কোনো সুরক্ষা প্রদান করে না। decision_framework.png

সর্বোত্তম অনুশীলনসমূহ

প্রতিটি ক্লায়েন্টে সার্ভার সার্টিফিকেট যাচাইকরণ প্রয়োগ করুন

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

সার্টিফিকেট লাইফসাইকেল ম্যানেজমেন্ট স্বয়ংক্রিয় করুন

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

প্রমাণীকরণ পদ্ধতি দ্বারা আপনার নেটওয়ার্ক সেগমেন্ট করুন

বৃহৎ বা বিতরণ করা পরিবেশে, আলাদা SSID-তে উভয় প্রোটোকল চালানোর কথা বিবেচনা করুন। কর্পোরেট পরিচালিত ডিভাইসগুলো একটি ডেডিকেটেড স্টাফ WiFi SSID-তে EAP-TLS-এর মাধ্যমে প্রমাণীকরণ করে। ঠিকাদার এবং BYOD ডিভাইসগুলো উপযুক্ত VLAN সেগমেন্টেশন সহ একটি পৃথক SSID-তে EAP-TTLS-এর মাধ্যমে প্রমাণীকরণ করে। এই প্যাটার্নটি প্রিমিয়ার ইন এবং হুইটব্রেডের মতো আতিথেয়তা গ্রুপগুলোতে সাধারণ, যেখানে স্টাফদের ডিভাইসগুলো পরিচালনা করা হয় এবং সার্টিফিকেট প্রদান করা হয়, অন্যদিকে গেস্ট ইনফ্রাস্ট্রাকচার একটি পৃথক প্রমাণীকরণ পথ ব্যবহার করে। SSID আর্কিটেকচার সম্পর্কে আরও বিশদ বিবরণের জন্য, আমাদের গাইড Three SSIDs to rule them all: the WiFi design for guest, staff and IoT দেখুন।

সমস্ত ইনফ্রাস্ট্রাকচার জুড়ে সময় সিঙ্ক্রোনাইজ করুন

সার্টিফিকেট যাচাইকরণ সঠিক সিস্টেম সময়ের ওপর নির্ভর করে। ক্লায়েন্ট ডিভাইস বা RADIUS সার্ভারে ঘড়ির সময়ের অমিল 'এখনও বৈধ নয়' বা 'মেয়াদ উত্তীর্ণ' সার্টিফিকেটের ত্রুটি তৈরি করে যা নির্ণয় করা কঠিন। সমস্ত ইনফ্রাস্ট্রাকচার উপাদানগুলো নির্ভরযোগ্য NTP সার্ভারের সাথে সিঙ্ক্রোনাইজ করা আছে কিনা তা নিশ্চিত করুন।

সমস্যা সমাধান এবং ঝুঁকি প্রশমন

অজানা CA ত্রুটি

যদি RADIUS লগগুলো 'অজানা CA' দেখায়, তবে ক্লায়েন্ট ডিভাইসটি সেই CA-কে বিশ্বাস করে না যা RADIUS সার্ভারের সার্টিফিকেট ইস্যু করেছে। আপনার MDM প্রোফাইলে রুট CA সার্টিফিকেট অন্তর্ভুক্ত রয়েছে এবং সাপ্লিক্যান্ট এটিকে বিশ্বাস করার জন্য কনফিগার করা হয়েছে কিনা তা যাচাই করুন। একটি CA পরিবর্তন বা সার্টিফিকেট পুনর্নবীকরণের পরে, আপডেট করা CA বান্ডিলটি সমস্ত ডিভাইসে পুনরায় পুশ করুন।

EAP পদ্ধতির অমিল

যদি ডিভাইসগুলি অ্যাক্সেস পয়েন্টের সাথে সংযুক্ত হয় কিন্তু প্রমাণীকরণ ব্যর্থ হয়, তাহলে ক্লায়েন্টে কনফিগার করা EAP পদ্ধতিটি RADIUS সার্ভার দ্বারা গৃহীত পদ্ধতির সাথে মিলছে কিনা তা পরীক্ষা করুন। EAP-TLS-এর জন্য সেট করা একটি ডিভাইস প্রোফাইল শুধুমাত্র PEAP-এর জন্য কনফিগার করা একটি RADIUS সার্ভারে ব্যর্থ হবে।

মেয়াদোত্তীর্ণ সার্টিফিকেটের কারণে ব্যাপক ব্যর্থতা

যদি একসাথে বিপুল সংখ্যক ডিভাইস প্রমাণীকরণ করতে ব্যর্থ হয়, তবে প্রথমে সার্টিফিকেটের মেয়াদ শেষ হওয়ার তারিখগুলি পরীক্ষা করুন। এটি EAP-TLS ডেপ্লয়মেন্টে ব্যাপক 802.1X ব্যর্থতার সবচেয়ে সাধারণ কারণ। এমন একটি মনিটরিং সিস্টেম চালু করুন যা মেয়াদ শেষ হওয়ার ৬০ দিন, ৩০ দিন এবং সাত দিন আগে সতর্কতা পাঠায়।

RADIUS ক্লায়েন্ট ভুল কনফিগারেশন

প্রতিটি অ্যাক্সেস পয়েন্ট বা ওয়্যারলেস কন্ট্রোলারকে সঠিক IP ঠিকানা এবং শেয়ার্ড সিক্রেট সহ একটি RADIUS ক্লায়েন্ট হিসাবে সংজ্ঞায়িত করতে হবে। অমিল থাকলে প্রমাণীকরণে টাইমআউট ঘটে যা প্রায়শই ভুলবশত EAP পদ্ধতির জন্য দায়ী করা হয়। প্রথম দিন থেকেই বিস্তারিত RADIUS লগিং সক্ষম করুন। আরও WiFi সমস্যা সমাধানের নির্দেশনার জন্য, আমাদের এই গাইডটি দেখুন Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures ।

কমপ্লায়েন্স এবং রেগুলেটরি সারিবদ্ধতা

CISO এবং নেটওয়ার্ক আর্কিটেক্টদের জন্য, EAP-TLS এবং EAP-TTLS-এর মধ্যে সিদ্ধান্ত নেওয়ার সময় রেগুলেটরি ল্যান্ডস্কেপ বোঝা অত্যন্ত জরুরি। EAP পদ্ধতির পছন্দটি সরাসরি বেশ কয়েকটি মূল ফ্রেমওয়ার্ক জুড়ে আপনার কমপ্লায়েন্স অবস্থাকে প্রভাবিত করে।

PCI DSS 4.0 (পেমেন্ট কার্ড ইন্ডাস্ট্রি ডাটা সিকিউরিটি স্ট্যান্ডার্ড) কার্ডহোল্ডার ডেটা এনভায়রনমেন্টে ওয়্যারলেস নেটওয়ার্কের জন্য শক্তিশালী ক্রিপ্টোগ্রাফিক প্রমাণীকরণ দাবি করে। রিকোয়ারমেন্ট ৮.৩ অনুযায়ী CDE-তে সমস্ত অ্যাক্সেসের জন্য মাল্টি-ফ্যাক্টর প্রমাণীকরণ বাধ্যতামূলক এবং ইন-স্কোপ ওয়্যারলেস নেটওয়ার্কগুলিতে অবশ্যই শক্তিশালী প্রমাণীকরণ ব্যবস্থা ব্যবহার করতে হবে। সার্টিফিকেট-ভিত্তিক পারস্পরিক প্রমাণীকরণ সহ EAP-TLS নিশ্চিতভাবেই এই প্রয়োজনীয়তা পূরণ করে। MS-CHAPv2 সহ EAP-TTLS গ্রহণযোগ্য হতে পারে যদি অভ্যন্তরীণ প্রমাণীকরণ সঠিকভাবে সুরক্ষিত থাকে এবং সার্ভার সার্টিফিকেট যাচাইকরণ প্রয়োগ করা হয়, তবে EAP-TLS হল আরও বেশি শক্তিশালী এবং অডিটর-বান্ধব পছন্দ। HIPAA (হেলথ ইন্স্যুরেন্স পোর্টেবিলিটি অ্যান্ড অ্যাকাউন্টেবিলিটি অ্যাক্ট) কভারড এন্টিটিগুলিকে প্রযুক্তিগত সুরক্ষা ব্যবস্থা বাস্তবায়নের নির্দেশ দেয় যা ইলেকট্রনিক যোগাযোগ নেটওয়ার্কের মাধ্যমে প্রেরিত ইলেকট্রনিক প্রটেক্টেড হেলথ ইনফরমেশন (ePHI) রক্ষা করে। HIPAA সিকিউরিটি রুল নির্দিষ্ট কোনও প্রোটোকল বাধ্যতামূলক করে না, তবে ePHI বহনকারী ওয়্যারলেস নেটওয়ার্কের জন্য এনক্রিপশন এবং অ্যাক্সেস নিয়ন্ত্রণের প্রত্যাশাটি ম্যানেজড মেডিকেল ডিভাইস ফ্লিটের জন্য EAP-TLS এবং কর্মীদের ডিভাইসের জন্য এনফোর্সড সার্ভার সার্টিফিকেট যাচাইকরণ সহ EAP-TTLS-এর পক্ষে জোরালো সমর্থন জানায়।WPA3-Enterprise 192-bit (যা Suite B বা CNSA মোড নামেও পরিচিত) হলো Wi-Fi Alliance-এর WPA3 সার্টিফিকেশনের সর্বোচ্চ নিরাপত্তা স্তর। এটি একমাত্র অনুমোদিত প্রমাণীকরণ পদ্ধতি হিসেবে EAP-TLS-কে বাধ্যতামূলক করে, নির্দিষ্ট সাইফার স্যুটসহ (ECDHE সহ P-384, AES-256-GCM) TLS 1.2 বা তার উচ্চতর সংস্করণের প্রয়োজন হয় এবং ECDSA বা RSA-3072 সার্টিফিকেটের প্রয়োজন হয়। সরকারি, প্রতিরক্ষা বা অত্যন্ত গুরুত্বপূর্ণ অবকাঠামো অ্যাপ্লিকেশনের জন্য WPA3-Enterprise 192-bit স্থাপনকারী প্রতিষ্ঠানগুলোকে অবশ্যই EAP-TLS ব্যবহার করতে হবে। ISO 27001 কোনো নির্দিষ্ট প্রোটোকল বাধ্যতামূলক করে না, তবে নেটওয়ার্ক রিসোর্সের জন্য প্রতিষ্ঠানগুলোকে উপযুক্ত অ্যাক্সেস কন্ট্রোল প্রয়োগ করতে বলে। EAP-TLS বা EAP-TTLS (বাধ্যতামূলক সার্ভার সার্টিফিকেট যাচাইকরণ সহ) যেকোনো একটির সাথে 802.1X স্থাপন Annex A.9.1 এবং A.13.1 এর নেটওয়ার্ক অ্যাক্সেস কন্ট্রোল প্রয়োজনীয়তাগুলো পূরণ করে।

-

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

EAP-TLS-এ স্থানান্তরের জন্য PKI এবং MDM ইন্টিগ্রেশনে একটি প্রাথমিক বিনিয়োগের প্রয়োজন হয়, তবে এটি পাসওয়ার্ড রিসেট করার কার্যক্ষম ঝামেলা এবং দুর্বল ক্রেডেনশিয়ালের কারণে নেটওয়ার্ক লঙ্ঘনের আর্থিক ঝুঁকি দূর করে। ৪০০টি স্টোর রয়েছে এমন একটি রিটেল চেইনের জন্য, একটি শেয়ার করা PSK নেটওয়ার্কে একটি মাত্র আপোসকৃত পাসওয়ার্ড পুরো সম্পত্তিকে ঝুঁকিতে ফেলতে পারে। EAP-TLS সেই আক্রমণের পথটিকে সম্পূর্ণরূপে নির্মূল করে।

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

Purple-এর WiFi Analytics প্ল্যাটফর্মটি উভয় প্রমাণীকরণ পাথের সাথেই একীভূত হয়, যা আপনার সম্পূর্ণ সম্পত্তি জুড়ে ডিভাইসের সংখ্যা, সেশনের সময়কাল এবং নেটওয়ার্ক ব্যবহারের দৃশ্যমানতা প্রদান করে। খাত-নির্দিষ্ট স্থাপনার নির্দেশনার জন্য, Hospitality , Retail , Healthcare , এবং Transport -এর জন্য আমাদের রিসোর্সগুলো এক্সপ্লোর করুন।

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

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

RFC 5216-এ সংজ্ঞায়িত একটি 802.1X অথেন্টিকেশন পদ্ধতি যেখানে ক্লায়েন্ট ডিভাইস এবং RADIUS সার্ভার উভয়েরই বৈধ X.509 সার্টিফিকেট প্রদর্শন করা প্রয়োজন। এখানে কোনো পাসওয়ার্ড আদান-প্রদান করা হয় না। অথেন্টিকেশন পারস্পরিক এবং ক্রিপ্টোগ্রাফিকভাবে আবদ্ধ থাকে।

এন্টারপ্রাইজ ওয়্যারলেস নিরাপত্তার জন্য গোল্ড স্ট্যান্ডার্ড। WPA3-Enterprise 192-bit-এর জন্য প্রয়োজনীয় এবং PCI-DSS 4.0 কার্ডহোল্ডার ডেটা এনভায়রনমেন্টের জন্য দৃঢ়ভাবে সুপারিশকৃত।

EAP-TTLS (Extensible Authentication Protocol - Tunneled Transport Layer Security)

RFC 5281-এ সংজ্ঞায়িত একটি 802.1X অথেন্টিকেশন পদ্ধতি যেখানে একটি এনক্রিপ্টেড TLS টানেল স্থাপন করার জন্য শুধুমাত্র একটি সার্ভার-সাইড সার্টিফিকেটের প্রয়োজন হয়। ক্লায়েন্ট টানেলের ভেতরে একটি সেকেন্ডারি অভ্যন্তরীণ অথেন্টিকেশন পদ্ধতি ব্যবহার করে অথেন্টিকেট করে, যা সাধারণত একটি ইউজারনেম এবং পাসওয়ার্ড হয়ে থাকে।

BYOD এনভায়রনমেন্ট এবং মিশ্র-OS নেটওয়ার্কের জন্য সবচেয়ে পছন্দের বিকল্প যেখানে ক্লায়েন্ট সার্টিফিকেট স্থাপন করা কার্যকারীভাবে অবাস্তব।

802.1X

পোর্ট-ভিত্তিক নেটওয়ার্ক অ্যাক্সেস নিয়ন্ত্রণের জন্য একটি IEEE স্ট্যান্ডার্ড যা LAN বা WLAN-এর সাথে সংযুক্ত ডিভাইসের জন্য একটি অথেন্টিকেশন মেকানিজম প্রদান করে। এটি সাপ্লিক্যান্ট, অথেন্টিকেটর এবং অথেন্টিকেশন সার্ভারের ভূমিকা সংজ্ঞায়িত করে।

ভিত্তিমূলক ফ্রেমওয়ার্ক যা এন্টারপ্রাইজ নেটওয়ার্কগুলোকে একটি একক শেয়ার্ড পাসওয়ার্ডের ওপর নির্ভর না করে প্রতিটি ডিভাইসকে আলাদাভাবে অথেন্টিকেট করতে সক্ষম করে। EAP-TLS এবং EAP-TTLS উভয়ই এই ফ্রেমওয়ার্কের মধ্যে কাজ করে।

RADIUS (Remote Authentication Dial-In User Service)

একটি নেটওয়ার্কিং প্রোটোকল যা একটি নেটওয়ার্ক সার্ভিসের সাথে সংযুক্ত ব্যবহারকারীদের জন্য সেন্ট্রালাইজড অথেন্টিকেশন, অথরাইজেশন এবং অ্যাকাউন্টিং ম্যানেজমেন্ট প্রদান করে। 802.1X ডেপ্লয়মেন্টে, RADIUS সার্ভার হলো সেই অথেন্টিকেশন সার্ভার যা সার্টিফিকেট বা ক্রেডেনশিয়াল যাচাই করে।

সার্ভার উপাদান যা সার্টিফিকেট বা পাসওয়ার্ড যাচাই করে এবং অ্যাক্সেস পয়েন্টকে নেটওয়ার্ক অ্যাক্সেস দেওয়ার বা প্রত্যাখ্যান করার নির্দেশ দেয়। সমর্থিত প্ল্যাটফর্মগুলোর মধ্যে রয়েছে FreeRADIUS, Microsoft NPS এবং Cisco ISE।

PKI (Public Key Infrastructure)

ডিজিটাল সার্টিফিকেট তৈরি, পরিচালনা, বিতরণ, ব্যবহার, সংরক্ষণ এবং বাতিল করার জন্য প্রয়োজনীয় ভূমিকা, নীতি, হার্ডওয়্যার, সফটওয়্যার এবং পদ্ধতির একটি সেট। একটি সাধারণ এন্টারপ্রাইজ PKI-তে একটি অফলাইন রুট CA এবং একটি অনলাইন ইস্যুয়িং CA থাকে।

EAP-TLS অথেন্টিকেশনে ব্যবহৃত ক্লায়েন্ট এবং সার্ভার সার্টিফিকেট ইস্যু করার জন্য প্রয়োজনীয় ব্যাকএন্ড ইনফ্রাস্ট্রাকচার। PKI ছাড়া EAP-TLS ডেপ্লয় করা অসম্ভব।

MDM (Mobile Device Management)

আইটি বিভাগ কর্তৃক কর্মীদের মোবাইল ডিভাইস এবং ল্যাপটপ নিরীক্ষণ, পরিচালনা এবং সুরক্ষিত করার জন্য ব্যবহৃত সফটওয়্যার। Microsoft Intune এবং Jamf-এর মতো MDM প্ল্যাটফর্মগুলো নিবন্ধিত ডিভাইসগুলোতে সার্টিফিকেট এবং WiFi প্রোফাইলের ডেপ্লয়মেন্ট স্বয়ংক্রিয় করতে পারে।

বড় পরিসরে EAP-TLS-এর জন্য ক্লায়েন্ট সার্টিফিকেট ডেপ্লয়মেন্ট স্বয়ংক্রিয় করার জন্য অপরিহার্য। MDM ইন্টিগ্রেশন ছাড়া, হাজার হাজার ডিভাইসে ম্যানুয়ালি সার্টিফিকেট ইনস্টল করা কার্যকারীভাবে অসম্ভব।

SCEP (Simple Certificate Enrollment Protocol)

একটি প্রোটোকল যা নেটওয়ার্ক ডিভাইসগুলোতে ডিজিটাল সার্টিফিকেট ইস্যু করার প্রক্রিয়া স্বয়ংক্রিয় করতে ব্যবহৃত হয়। MDM প্ল্যাটফর্মগুলো SCEP ব্যবহার করে ব্যবহারকারীর হস্তক্ষেপ ছাড়াই নিবন্ধিত কর্পোরেট ডিভাইসগুলোতে নীরবে সার্টিফিকেটের অনুরোধ ও ইনস্টল করে।

EAP-TLS ডেপ্লয়মেন্টে জিরো-টাচ সার্টিফিকেট প্রভিশনিং-এর আদর্শ মেকানিজম। এটি Microsoft Intune, Jamf এবং বেশিরভাগ এন্টারপ্রাইজ MDM প্ল্যাটফর্ম দ্বারা সমর্থিত।

CRL (Certificate Revocation List)

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

একটি মেকানিজম যা আপনাকে কোনো চুরি হওয়া বা ক্ষতিগ্রস্থ ডিভাইসের সার্টিফিকেট বাতিল করে নেটওয়ার্ক থেকে তাৎক্ষণিকভাবে ব্লক করার সুবিধা দেয়। RADIUS সার্ভারগুলোকে ঘন ঘন CRL চেক করার জন্য কনফিগার করা উচিত, অথবা রিয়েল-টাইম যাচাইকরণের জন্য OCSP ব্যবহার করা উচিত।

X.509

একটি ITU-T স্ট্যান্ডার্ড যা পাবলিক কি সার্টিফিকেটের ফরম্যাট নির্ধারণ করে। EAP-TLS এবং EAP-TTLS উভয়ই সার্ভার অথেনটিকেশনের জন্য X.509 সার্টিফিকেট ব্যবহার করে। EAP-TLS-এর ক্ষেত্রে ক্লায়েন্ট ডিভাইসেও X.509 সার্টিফিকেট থাকা আবশ্যক।

সমস্ত এন্টারপ্রাইজ PKI ডেপ্লয়মেন্টে ব্যবহৃত সার্টিফিকেট ফরম্যাট। 802.1X এর প্রসঙ্গে আইটি টিম যখন 'ডিজিটাল সার্টিফিকেট' উল্লেখ করে, তখন তারা X.509 সার্টিফিকেটকে বোঝায়।

ইনার অথেনটিকেশন মেথড

EAP-TTLS দ্বারা প্রতিষ্ঠিত এনক্রিপ্ট করা TLS টানেলের ভেতরে ব্যবহৃত সেকেন্ডারি অথেনটিকেশন প্রোটোকল। সাধারণ ইনার মেথডগুলোর মধ্যে রয়েছে PAP (পাসওয়ার্ড অথেনটিকেশন প্রোটোকল), CHAP এবং MS-CHAPv2।

ইনার অথেনটিকেশন মেথড নির্বাচন করার বিষয়টি একটি EAP-TTLS ডেপ্লয়মেন্টের সিকিউরিটি বৈশিষ্ট্যের ওপর প্রভাব ফেলে। PAP টানেলের ভেতরে প্লেইনটেক্সট আকারে পাসওয়ার্ড পাঠায়; MS-CHAPv2 একটি চ্যালেঞ্জ-রেসপন্স মেকানিজম ব্যবহার করে। টানেল সমস্ত ইনার অথেনটিকেশন ট্রাফিক এনক্রিপ্ট করে।

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

৪০০টি স্টোর সহ একটি জাতীয় খুচরা চেইনের তাদের পয়েন্ট-অফ-সেল (POS) টার্মিনাল এবং কর্মীদের হ্যান্ডহেল্ড স্ক্যানারগুলি সুরক্ষিত করা প্রয়োজন। পরিবেশটি PCI-DSS 4.0-এর আওতাভুক্ত। সমস্ত ডিভাইস Microsoft Intune-এ নথিভুক্ত। তাদের কোন প্রোটোকল স্থাপন করা উচিত এবং মূল কনফিগারেশন পদক্ষেপগুলি কী কী?

EAP-TLS স্থাপন করুন। ধাপ ১: একটি এয়ার-গ্যাপড অফলাইন রুট CA এবং একটি অনলাইন ইস্যুয়িং CA সহ একটি দ্বি-স্তরের PKI স্থাপন করুন। ধাপ ২: সমস্ত POS এবং স্ক্যানার ডিভাইসগুলিকে লক্ষ্য করে একটি SCEP শংসাপত্র প্রোফাইল সহ Microsoft Intune কনফিগার করুন। ধাপ ৩: একটি RADIUS সার্ভার (Microsoft NPS বা ক্লাউড RADIUS) স্থাপন করুন এবং অভ্যন্তরীণ CA-এর বিপরীতে ক্লায়েন্ট শংসাপত্রগুলি যাচাই করার জন্য এটি কনফিগার করুন। ধাপ ৪: RADIUS সার্ভারে CRL চেকিং বা OCSP সক্ষম করুন। ধাপ ৫: SSID, প্রমাণীকরণ পদ্ধতি হিসাবে EAP-TLS, বিশ্বস্ত রুট CA এবং প্রত্যাশিত RADIUS সার্ভারের নাম নির্দিষ্ট করে Intune-এর মাধ্যমে একটি WiFi প্রোফাইল পুশ করুন। ধাপ ৬: সমস্ত ৪০০টি সাইটে রোল আউট করার আগে ১০টি ডিভাইসের একটি পাইলট গ্রুপের সাথে পরীক্ষা করুন। ধাপ ৭: মেয়াদ শেষ হওয়ার ৬০, ৩০ এবং সাত দিন আগে সতর্কতা সহ একটি শংসাপত্রের মেয়াদ শেষ হওয়ার পর্যবেক্ষণ প্রক্রিয়া স্থাপন করুন।

পরীক্ষকের মন্তব্য: EAP-TLS হল সঠিক পছন্দ কারণ PCI-DSS 4.0 কার্ডহোল্ডার ডেটা পরিবেশে ওয়্যারলেস নেটওয়ার্কগুলির জন্য পারস্পরিক শংসাপত্র প্রমাণীকরণের দৃঢ়ভাবে সুপারিশ করে। POS ডিভাইসগুলির জন্য পাসওয়ার্ডের (EAP-TTLS) উপর নির্ভর করা অগ্রহণযোগ্য শংসাপত্র চুরির ঝুঁকি তৈরি করে। SCEP-এর মাধ্যমে MDM একীকরণ অপরিহার্য - ৪০০টি সাইট জুড়ে ম্যানুয়াল শংসাপত্র ইনস্টলেশন করা কার্যকারিতার দিক থেকে অসম্ভব। এই পরিস্থিতিতে সবচেয়ে সাধারণ ব্যর্থতার পয়েন্ট হল Intune WiFi প্রোফাইলে সার্ভার শংসাপত্র যাচাইকরণ প্রয়োগ করতে ভুলে যাওয়া, যা EAP-TLS স্থাপন করা সত্ত্বেও ডিভাইসগুলিকে ইভিল টুইন আক্রমণের ঝুঁকিতে ফেলে দেবে।

একটি বৃহৎ বিশ্ববিদ্যালয় ক্যাম্পাসে ব্যক্তিগত ল্যাপটপ, স্মার্টফোন এবং ট্যাবলেটের (BYOD) মিশ্রণ ব্যবহার করে ২০,০০০ শিক্ষার্থীর জন্য নিরাপদ WiFi প্রদান করা প্রয়োজন। আইটি দল ব্যক্তিগত ডিভাইসে শংসাপত্র ইনস্টল করতে পারে না। বিশ্ববিদ্যালয় পরিচয় ব্যবস্থাপনার জন্য Microsoft Entra ID ব্যবহার করে। তাদের কোন প্রোটোকল স্থাপন করা উচিত?

অভ্যন্তরীণ প্রমাণীকরণ পদ্ধতি হিসাবে MS-CHAPv2 সহ EAP-TTLS স্থাপন করুন, যা RADIUS-এর মাধ্যমে Microsoft Entra ID-এর সাথে একীভূত। ধাপ ১: সমস্ত বড় অপারেটিং সিস্টেম দ্বারা বিশ্বস্ত একটি সর্বজনীন CA থেকে একটি সার্ভার শংসাপত্র প্রাপ্ত করুন, অথবা একটি অভ্যন্তরীণ CA স্থাপন করুন এবং পরিচালিত ডিভাইসগুলির জন্য বিশ্ববিদ্যালয়ের ডিভাইস পরিচালন সরঞ্জামগুলির মাধ্যমে রুট শংসাপত্রটি বিতরণ করুন। ধাপ ২: LDAP বা RADIUS প্রক্সির মাধ্যমে Microsoft Entra ID-এর বিপরীতে প্রমাণীকরণ করতে RADIUS সার্ভার কনফিগার করুন। ধাপ ৩: শিক্ষার্থীদের জন্য SSID, EAP-TTLS, MS-CHAPv2 এবং বিশ্বস্ত CA নির্দিষ্ট করে একটি WiFi অনবোর্ডিং নির্দেশিকা তৈরি করুন। ধাপ ৪: Entra ID স্তরে শক্তিশালী পাসওয়ার্ড নীতি প্রয়োগ করুন এবং প্রাথমিক নথিপত্রের জন্য মাল্টি-ফ্যাক্টর প্রমাণীকরণ সক্ষম করার কথা বিবেচনা করুন। ধাপ ৫: সার্ভার শংসাপত্র যাচাইকরণ প্রয়োগ করতে এবং বিশ্বস্ত CA এবং RADIUS সার্ভারের নাম নির্দিষ্ট করতে WiFi প্রোফাইলটি কনফিগার করুন।

পরীক্ষকের মন্তব্য: এখানে EAP-TTLS হলো একটি বাস্তবসম্মত পছন্দ। ২০,০০০ অনিয়ন্ত্রিত ব্যক্তিগত ডিভাইসের জন্য একটি PKI পরিচালনা করা কার্যকারীভাবে অসম্ভব। EAP-TTLS ক্রেডেনশিয়ালগুলোর জন্য একটি নিরাপদ টানেল প্রদান করে, যা সেগুলোকে ওভার-দ্য-এয়ার ইন্টারসেপ্ট হওয়া থেকে রক্ষা করে এবং একই সাথে Windows, macOS, Linux, Android এবং iOS সহ বিভিন্ন অপারেটিং সিস্টেম সমর্থন করে। এই পরিস্থিতিতে সবচেয়ে বড় ঝুঁকি হলো শিক্ষার্থীরা সার্ভার সার্টিফিকেট যাচাইকরণ এড়িয়ে যাওয়ার জন্য তাদের ডিভাইসগুলো ভুলভাবে কনফিগার করতে পারে। নিখুঁত কনফিগারেশন ধাপসহ একটি স্পষ্ট অনবোর্ডিং গাইড প্রকাশ করা এবং একটি বিশ্বস্ত পাবলিক সার্ভার সার্টিফিকেট ব্যবহার করা এই ঝুঁকি উল্লেখযোগ্যভাবে হ্রাস করে।

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

Q1. আপনি ৫০টি অফিস লোকেশন জুড়ে ৫,০০০ কর্পোরেট ল্যাপটপের জন্য EAP-TLS ডেপ্লয় করছেন। Microsoft Intune-এর মাধ্যমে WiFi প্রোফাইল পুশ করার পর, ডিভাইসগুলো কানেক্ট হতে ব্যর্থ হচ্ছে। RADIUS সার্ভার লগ প্রতিটি ব্যর্থ অথেনটিকেশন চেষ্টার জন্য 'Unknown CA' দেখাচ্ছে। এর সম্ভাব্য কারণ কী এবং আপনি কীভাবে এটি সমাধান করবেন?

ইঙ্গিত: ক্লায়েন্ট সাইডের সার্টিফিকেট ভ্যালিডেশন চেইনের কথা এবং MDM প্রোফাইলে EAP মেথড সেটিংস ছাড়াও আর কী অন্তর্ভুক্ত থাকা আবশ্যক তা বিবেচনা করুন।

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

ক্লায়েন্ট ডিভাইসগুলো RADIUS সার্ভারের সার্টিফিকেট ইস্যুকারী ইন্টারনাল সার্টিফিকেট অথরিটিকে বিশ্বাস (trust) করার জন্য কনফিগার করা নেই। MDM WiFi প্রোফাইলে অবশ্যই রুট CA সার্টিফিকেট (এবং যেকোনো ইন্টারমিডিয়েট CA সার্টিফিকেট) অন্তর্ভুক্ত থাকতে হবে এবং সার্ভার ভ্যালিডেশনের জন্য সেগুলোকে বিশ্বাস করতে সাপ্লিক্যান্টকে কনফিগার করতে হবে। এটি ছাড়া, ক্লায়েন্ট RADIUS সার্ভারের সার্টিফিকেট প্রত্যাখ্যান করে এবং হ্যান্ডশেক বাতিল করে। সমাধান: 'Root certificate for server validation' সেটিংসের অধীনে ট্রাস্টেড রুট CA সার্টিফিকেট অন্তর্ভুক্ত করতে Intune WiFi প্রোফাইল আপডেট করুন এবং সমস্ত ডিভাইসে প্রোফাইলটি পুনরায় পুশ করুন।

Q2. আপনার প্রতিষ্ঠান একটি মিশ্র BYOD এনভায়রনমেন্টের জন্য EAP-TTLS ডেপ্লয় করেছে। একটি সিকিউরিটি রিভিউর সময়, আপনার পেনিট্রেসণ টেস্টিং টিম দেখিয়েছে যে তারা একটি সেলফ-সাইনড সার্টিফিকেট সহ রোগ (rogue) অ্যাক্সেস পয়েন্ট তৈরি করে ব্যবহারকারীর ক্রেডেনশিয়াল সংগ্রহ করতে পারে। EAP-TLS-এ মাইগ্রেট না করে আপনি কীভাবে এই দুর্বলতা দূর করবেন?

ইঙ্গিত: ইনার অথেনটিকেশনের আগে কী ঘটে এবং ক্লায়েন্ট সাইডের কোন কনফিগারেশন একটি অবিশ্বস্ত সার্ভারের সাথে TLS টানেল তৈরি হতে বাধা দেয় তা চিন্তা করুন।

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

দুর্বলতাটি বিদ্যমান কারণ ক্লায়েন্ট ডিভাইসগুলো RADIUS সার্ভারের সার্টিফিকেট যাচাই করার জন্য কনফিগার করা নেই। প্রতিকার: সার্ভার সার্টিফিকেট ভ্যালিডেশন বাধ্যতামূলক করতে সমস্ত WiFi প্রোফাইল আপডেট করুন (ম্যানেজড ডিভাইসের জন্য MDM-এর মাধ্যমে এবং BYOD-এর জন্য একটি নতুন অনবোর্ডিং গাইডের মাধ্যমে)। প্রোফাইলে ট্রাস্টেড CA এবং প্রত্যাশিত RADIUS সার্ভারের নাম নির্দিষ্ট করে দিন। এভাবে কনফিগার করা ক্লায়েন্টগুলো এমন যেকোনো সার্ভারের সাথে TLS টানেল তৈরি করতে অস্বীকার করবে যা নির্দিষ্ট ট্রাস্টেড CA দ্বারা সাইন করা সার্টিফিকেট প্রদর্শন করতে পারে না, যা রোগ (rogue) অ্যাক্সেস পয়েন্টের অ্যাটাক ভেক্টরকে দূর করে।

Q3. একটি হাসপাতালের আইটি ডিরেক্টর তাদের মেডিকেল IoT ডিভাইসের (ইনফিউশন পাম্প, পেশেন্ট মনিটর, এনভায়রনমেন্টাল সেন্সর) জন্য 802.1X ডেপ্লয় করতে চান। তারা EAP-TTLS বিবেচনা করছেন কারণ তারা মনে করেন সার্টিফিকেট ম্যানেজমেন্ট অত্যন্ত জটিল। এই যুক্তিটি কেন ত্রুটিযুক্ত এবং সঠিক পদ্ধতি কী?

ইঙ্গিত: হেডলেস IoT ডিভাইসগুলো কীভাবে অথেনটিকেশন প্রম্পট হ্যান্ডেল করে এবং একটি ডিভাইস যখন ক্রেডেনশিয়াল ইনপুট করতে পারে না তখন কী ঘটে তা বিবেচনা করুন।

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

এই যুক্তিটি দুটি কারণে ত্রুটিপূর্ণ। প্রথমত, বেশিরভাগ স্ক্রিনহীন (headless) মেডিকেল IoT ডিভাইসে ক্রেডেনশিয়াল ইনপুট করার জন্য কোনো ইউজার ইন্টারফেস থাকে না, যার ফলে ইউজারনেম/পাসওয়ার্ড ভিত্তিক ইনার অথেন্টিকেশন সহ EAP-TTLS ব্যবহার করা কার্যক্ষমভাবে অসম্ভব। দ্বিতীয়ত, অনুশীলনে IoT-এর জন্য EAP-TLS আসলে সহজ: ডেপ্লয়মেন্টের আগে ডিভাইস স্টেজিং করার সময় সার্টিফিকেট প্রভিশন করা যেতে পারে এবং কোনো ব্যবহারকারীর ইন্টারঅ্যাকশন ছাড়াই ডিভাইসটি স্বয়ংক্রিয়ভাবে অথেন্টিকেট হয়। সঠিক পদ্ধতি হলো স্টেজিংয়ের সময় ব্যবহৃত ডিভাইস ম্যানেজমেন্ট সিস্টেমের মাধ্যমে সার্টিফিকেট প্রভিশন সহ EAP-TLS ব্যবহার করা। এটি স্বাস্থ্যসেবা পরিবেশে শক্তিশালী ওয়্যারলেস অথেন্টিকেশনের জন্য HIPAA প্রয়োজনীয়তাও পূরণ করে।

Q4. আপনি ২০০টি প্রপার্টি বিশিষ্ট একটি হোটেল গ্রুপের নেটওয়ার্ক আর্কিটেক্ট। ৩,০০০টি ম্যানেজড স্টাফ ডিভাইসের (Intune-এ নথিভুক্ত) জন্য আপনাকে Staff WiFi সুরক্ষিত করতে হবে এবং একই সাথে নিজস্ব ল্যাপটপ ব্যবহারকারী ঠিকাদার ও থার্ড-পার্টি ভেন্ডরদের জন্য সুরক্ষিত WiFi প্রদান করতে হবে। এই অথেন্টিকেশন আর্কিটেকচারটি ডিজাইন করুন।

ইঙ্গিত: একটি একক SSID এবং একটি একক EAP পদ্ধতি উভয় ধরনের ব্যবহারকারীকে পরিষেবা দিতে পারে কিনা এবং এই দুই ধরনের ব্যবহারকারীর কারণে নেটওয়ার্ক সেগমেন্টেশনে কী প্রভাব পড়তে পারে তা বিবেচনা করুন।

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

ভিন্ন অথেন্টিকেশন পদ্ধতি এবং VLAN অ্যাসাইনমেন্ট সহ দুটি পৃথক SSID ডেপ্লয় করুন। SSID 1 (Staff WiFi): EAP-TLS, Intune SCEP-এর মাধ্যমে সার্টিফিকেট পুশ করা হবে, হোটেল ম্যানেজমেন্ট সিস্টেমে সম্পূর্ণ অ্যাক্সেস সহ স্টাফ নেটওয়ার্ক সেগমেন্টে VLAN অ্যাসাইন করা হবে। SSID 2 (Contractor WiFi): MS-CHAPv2 সহ EAP-TTLS, একটি পৃথক ডিরেক্টরি বা Microsoft Entra ID-তে সময়-সীমিত ঠিকাদার অ্যাকাউন্টের বিপরীতে ক্রেডেনশিয়াল যাচাই করা হবে, অভ্যন্তরীণ সিস্টেমে কোনো অ্যাক্সেস ছাড়াই একটি আইসোলেটেড কেবল-ইন্টারনেট সেগমেন্টে VLAN অ্যাসাইন করা হবে। উভয় SSID-এই অবশ্যই সার্ভার সার্টিফিকেট ভ্যালিডেশন প্রয়োগ করতে হবে। এই আর্কিটেকচারটি কর্মীদের সর্বোচ্চ নিরাপত্তা প্রদান করে এবং ঠিকাদারদের একটি ব্যবহারিক অথেন্টিকেশন পদ্ধতি দেয়, এবং নেটওয়ার্ক সেগমেন্টেশন নিশ্চিত করে যে কোনো আপসকৃত ঠিকাদার ক্রেডেনশিয়াল অভ্যন্তরীণ হোটেল ম্যানেজমেন্ট সিস্টেমে পৌঁছাতে পারবে না।

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

Guest এবং Staff WiFi নেটওয়ার্কের জন্য RADIUS Authentication কনফিগার করা

এই টেকনিক্যাল রেফারেন্স গাইডটি এন্টারপ্রাইজ guest এবং staff WiFi নেটওয়ার্কের জন্য RADIUS authentication-এর আর্কিটেকচার, কনফিগারেশন এবং ডিপ্লয়মেন্টের রূপরেখা প্রদান করে। এটি নেটওয়ার্ক আর্কিটেক্ট এবং IT ম্যানেজারদের সুরক্ষিত, স্কেলযোগ্য ওয়্যারলেস অ্যাক্সেস কন্ট্রোল সিস্টেম তৈরি করার জন্য প্রয়োজনীয় সঠিক প্রোটোকল, সিকিউরিটি স্ট্যান্ডার্ড এবং ট্রাবলশুটিং মেথডোলজি প্রদান করে।

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

Passpoint এবং OpenRoaming: সম্পূর্ণ নির্দেশিকা

এই প্রযুক্তিগত রেফারেন্স নির্দেশিকাটি এন্টারপ্রাইজ WiFi নেটওয়ার্কের মধ্যে Passpoint (Hotspot 2.0) এবং WBA OpenRoaming ফ্রেমওয়ার্কের একটি বিস্তৃত বিশ্লেষণ প্রদান করে। এটি একটি নিরাপদ, ঝামেলামুক্ত অতিথি সংযোগ স্থাপন করার জন্য প্রয়োজনীয় অন্তর্নিহিত প্রমাণীকরণ প্রোটোকল, আর্কিটেকচারাল উপাদান এবং স্থাপনার কৌশলগুলি বিস্তারিতভাবে বর্ণনা করে। নেটওয়ার্ক স্থপতি এবং IT লিডাররা এন্টারপ্রাইজ-গ্রেড নিরাপত্তা বজায় রেখে ম্যানুয়াল লগইন বাধাগুলি দূর করতে কীভাবে এই মানগুলি ডিজাইন, বাস্তবায়ন এবং সমস্যা সমাধান করবেন তা শিখবেন।

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

উচ্চশিক্ষায় সুরক্ষিত BYOD এবং নেটওয়ার্ক এনরোলমেন্টের জন্য কীভাবে SCEP বাস্তবায়ন করবেন

এই প্রযুক্তিগত নির্দেশিকাটি নেটওয়ার্ক আর্কিটেক্ট এবং IT ম্যানেজারদের উচ্চশিক্ষার ক্যাম্পাস নেটওয়ার্ক সুরক্ষিত করতে SCEP ভিত্তিক সার্টিফিকেট এনরোলমেন্ট স্থাপনের জন্য একটি ভেন্ডর - নিরপেক্ষ ব্লুপ্রিন্ট প্রদান করে। এটি কীভাবে পাসওয়ার্ড ভিত্তিক PEAP থেকে 802.1X EAP-TLS-এ স্থানান্তরিত হতে হবে, BYOD অনবোর্ডিং স্বয়ংক্রিয় করতে হবে এবং শক্তিশালী VLAN সেগমেন্টেশন কার্যকর করতে হবে তা বিস্তারিতভাবে বর্ণনা করে।

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