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

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

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

📖 9 মিনিট পাঠ📝 2,090 শব্দ🔧 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 দিয়ে শুরু করা যাক, যার পূর্ণরূপ হলো ট্রান্সপোর্ট লেয়ার সিকিউরিটি (Transport Layer Security)। EAP-TLS প্রোটোকলটি RFC 5216-এ সংজ্ঞায়িত করা হয়েছে এবং এটিকে ওয়্যারলেস অথেনটিকেশনের গোল্ড স্ট্যান্ডার্ড হিসেবে বিবেচনা করা হয়। এর মূল নীতি হলো মিউচুয়াল অথেনটিকেশন। নেটওয়ার্ক অ্যাক্সেস দেওয়ার আগে ক্লায়েন্ট ডিভাইস এবং RADIUS সার্ভার উভয়কেই তাদের পরিচয় প্রমাণ করতে বৈধ X.509 ডিজিটাল সার্টিফিকেট প্রদর্শন করতে হবে। এই প্রক্রিয়ার কোনো পর্যায়েই কোনো পাসওয়ার্ডের প্রয়োজন হয় না। একেবারে শূন্য। নিরাপত্তার দিক থেকে এটি অত্যন্ত গুরুত্বপূর্ণ। পাসওয়ার্ড ফিশিংয়ের শিকার হতে পারে। ব্রুট ফোর্সের মাধ্যমে অনুমান করা যেতে পারে। কোনো থার্ড-পার্টি সার্ভিসে ডাটা ব্রিচ বা তথ্য ফাঁসের মাধ্যমে চুরি হতে পারে যেখানে আপনার কোনো কর্মচারী একই পাসওয়ার্ড পুনরায় ব্যবহার করেছেন। সার্টিফিকেট ফিশিংয়ের শিকার হতে পারে না, অনুমান করা যায় না এবং এগুলো একটি নির্দিষ্ট ডিভাইসের সাথে যুক্ত থাকে। কোনো ক্ষতিকারক ব্যক্তি যদি আপনার নেটওয়ার্কে প্রবেশ করতে চায়, তবে তাদের ফিজিক্যাল ডিভাইস এবং এর মধ্যে থাকা ক্রিপ্টোগ্রাফিক প্রাইভেট কির প্রয়োজন হবে। এটি সম্পূর্ণ ভিন্ন ধরনের একটি থ্রেট মডেল।আমি আপনাকে বিস্তারিতভাবে EAP-TLS হ্যান্ডশেকটি বুঝিয়ে বলি, কারণ এটি বুঝতে পারলে স্পষ্ট হবে কেন এই প্রোটোকলটি এতটা নিরাপদ। যখন একটি ডিভাইস WiFi নেটওয়ার্কের সাথে সংযোগ করার চেষ্টা করে, তখন অ্যাক্সেস পয়েন্টটি ডিভাইসের পরিচয়ের জন্য একটি EAP-Request পাঠায়। ডিভাইসটি সাড়া দেয়। অ্যাক্সেস পয়েন্ট এটি RADIUS সার্ভারে ফরোয়ার্ড করে। RADIUS সার্ভার একটি Server Hello মেসেজের পাশাপাশি তার X.509 সার্টিফিকেট পাঠিয়ে TLS হ্যান্ডশেক শুরু করে। ক্লায়েন্ট তার বিশ্বস্ত রুট Certificate Authority স্টোরের বিপরীতে এই সার্ভার সার্টিফিকেটটি যাচাই করে। যদি যাচাইকরণ ব্যর্থ হয়, তবে হ্যান্ডশেকটি অবিলম্বে শেষ হয়ে যায়। ডিভাইসটি সংযোগ করতে অস্বীকার করে। এটিই Evil Twin আক্রমণ থেকে রক্ষা করে, যেখানে একজন হ্যাকার আপনার নেটওয়ার্কের ছদ্মবেশ ধারণ করার জন্য একটি নকল অ্যাক্সেস পয়েন্ট তৈরি করে। যদি সার্ভার সার্টিফিকেটটি বৈধ হয়, তবে ক্লায়েন্ট RADIUS সার্ভারের কাছে তার নিজস্ব X.509 সার্টিফিকেট উপস্থাপন করে। RADIUS সার্ভার ক্লায়েন্ট সার্টিফিকেটটি যাচাই করে: এটি বিশ্বস্ত রুট CA পর্যন্ত সিগনেচার চেইনটি পরীক্ষা করে, সার্টিফিকেটটির মেয়াদ শেষ হয়নি তা যাচাই করে এবং সার্টিফিকেটটি বাতিল করা হয়নি তা নিশ্চিত করতে Certificate Revocation List পরীক্ষা করে। উভয় পক্ষ সন্তুষ্ট হলেই কেবল TLS টানেলটি প্রতিষ্ঠিত হয় এবং EAP-Success মেসেজটি পাঠানো হয়, যা নেটওয়ার্ক অ্যাক্সেস প্রদান করে। সম্পূর্ণ আদান-প্রদানটি TLS 1.2 বা 1.3 ব্যবহার করে, যা নিখুঁত ফরোয়ার্ড সিক্রেসি প্রদান করে। এখন, এই স্তরের নিরাপত্তার জন্য একটি অপারেশনাল প্রয়োজনীয়তা রয়েছে: আপনার একটি Public Key Infrastructure বা PKI প্রয়োজন। অন্ততপক্ষে, আপনার একটি অফলাইন রুট Certificate Authority এবং একটি অনলাইন ইস্যুকারী Certificate Authority প্রয়োজন। রুট CA-টি এয়ার-গ্যাপড (air-gapped) হওয়া উচিত, কারণ এর প্রাইভেট কি (private key) হল আপনার সম্পূর্ণ সার্টিফিকেট অনুক্রমের প্রধান ট্রাস্ট অ্যাঙ্কর। ইস্যুকারী CA প্রতিদিনের সার্টিফিকেট প্রদান পরিচালনা করে এবং Certificate Revocation List প্রকাশ করে। এবং অত্যন্ত গুরুত্বপূর্ণভাবে, নেটওয়ার্কের প্রতিটি ডিভাইসে ক্লায়েন্ট সার্টিফিকেট স্থাপন করার জন্য আপনার একটি মেকানিজম প্রয়োজন। হাজার হাজার ডিভাইসের জন্য, এর অর্থ হল SCEP (Simple Certificate Enrollment Protocol) ব্যবহার করে একটি Mobile Device Management প্ল্যাটফর্মের সাথে আপনার PKI সংহত করা। যখন একটি কর্পোরেট ডিভাইস আপনার MDM-এ নথিভুক্ত হয়, তখন এটি কোনো ব্যবহারকারীর হস্তক্ষেপ ছাড়াই স্বয়ংক্রিয়ভাবে তার সার্টিফিকেটের জন্য অনুরোধ করে এবং তা গ্রহণ করে। বাস্তবায়ন সিনারিও (5:30 - 8:00) তাহলে, আপনার কোন প্রোটোকলটি স্থাপন করা উচিত? সিদ্ধান্তটি প্রায় সম্পূর্ণরূপে আপনার ডিভাইস ম্যানেজমেন্টের সক্ষমতা এবং আপনার কমপ্লায়েন্স প্রয়োজনীয়তার ওপর নির্ভর করে। আমি আপনাকে একটি ব্যবহারিক সিদ্ধান্ত গ্রহণের ফ্রেমওয়ার্ক প্রদান করি। নিজেকে তিনটি প্রশ্ন করুন। প্রথমত: এই নেটওয়ার্কের সাথে সংযুক্ত সমস্ত ডিভাইস কি Microsoft Intune বা Jamf-এর মতো একটি MDM প্ল্যাটফর্মের মাধ্যমে কর্পোরেট-পরিচালিত? যদি উত্তর হ্যাঁ হয়, তবে ক্লায়েন্ট সার্টিফিকেট স্থাপন করার জন্য আপনার প্রয়োজনীয় অবকাঠামো রয়েছে এবং EAP-TLS হল সঠিক পছন্দ। দ্বিতীয়ত: এই নেটওয়ার্কটিকে কি PCI DSS 4.0, HIPAA, বা WPA3 Enterprise 192-bit এর প্রয়োজনীয়তাগুলি পূরণ করতে হবে? যদি উত্তর হ্যাঁ হয়, তবে EAP-TLS হল প্রয়োজনীয় পছন্দ। তৃতীয়ত: আপনার কি অনিয়ন্ত্রিত বা BYOD ডিভাইসের একটি উল্লেখযোগ্য অংশ রয়েছে? যদি উত্তর হ্যাঁ হয়, তবে আপনার নেটওয়ার্কের সেই অংশের জন্য EAP-TTLS হল বাস্তবসম্মত পছন্দ। আমি আপনাকে দুটি সুনির্দিষ্ট বাস্তব জীবনের দৃশ্যপট বলি। দৃশ্যপট এক: চারশত স্টোর বিশিষ্ট একটি জাতীয় রিটেল চেইন। প্রতিটি পয়েন্ট-অফ-সেল টার্মিনাল এবং কর্মীদের হ্যান্ডহেল্ড স্ক্যানার Microsoft Intune-এ নথিভুক্ত রয়েছে। নেটওয়ার্কটি PCI DSS 4.0-এর আওতাভুক্ত। এই পরিবেশে, আপনি EAP-TLS মোতায়েন করবেন। আপনি একটি প্রাইভেট PKI প্রতিষ্ঠা করবেন, SCEP-এর মাধ্যমে প্রতিটি ডিভাইসে অনন্য ক্লায়েন্ট সার্টিফিকেট পাঠাতে Intune ব্যবহার করবেন এবং সার্টিফিকেট রিভোকেশন লিস্ট (Certificate Revocation List) যাচাই করার জন্য আপনার RADIUS সার্ভার কনফিগার করবেন। যদি কোনো ডিভাইস চুরি হয়ে যায়, আপনি সেটির সার্টিফিকেট প্রত্যাহার করে নেবেন এবং কয়েক মিনিটের মধ্যে এটি নেটওয়ার্ক থেকে বিচ্ছিন্ন হয়ে যাবে। কোনো পাসওয়ার্ড রিসেট করার প্রয়োজন নেই। চারশত সাইট জুড়ে কোনো শেয়ার্ড সিক্রেট পরিবর্তন বা রোটেট করার ঝামেলা নেই। দৃশ্যপট দুই: বিশ হাজার শিক্ষার্থী বিশিষ্ট একটি বিশাল বিশ্ববিদ্যালয় ক্যাম্পাস, যারা ব্যক্তিগত ল্যাপটপ, স্মার্টফোন এবং ট্যাবলেট ব্যবহার করে। আইটি টিমের পক্ষে ব্যক্তিগত ডিভাইসে সার্টিফিকেট ইনস্টল করা সম্ভব নয়। এই পরিবেশে, EAP-TTLS হলো একটি বাস্তবসম্মত পছন্দ। আপনি আপনার RADIUS সার্ভারে একটি বিশ্বস্ত সার্টিফিকেট ইনস্টল করবেন, আপনার বিশ্ববিদ্যালয়ের ডিরেক্টরি পরিষেবার সাথে এটি যুক্ত করবেন এবং শিক্ষার্থীরা সুরক্ষিত টানেলের মধ্যে তাদের বিদ্যমান ক্রেডেনশিয়াল ব্যবহার করে প্রমাণীকরণ (authenticate) করবে। এটি ক্লায়েন্ট সাইডে কোনো অতিরিক্ত সফটওয়্যার ছাড়াই Windows, macOS, Linux, Android এবং iOS সমর্থন করে। অনেক বড় এন্টারপ্রাইজে, সমাধানটি আসলে উভয়ই। আপনি আপনার পরিচালিত কর্পোরেট ডিভাইসের জন্য EAP-TLS মোতায়েন করবেন এবং ঠিকাদার, ভিজিটর ও BYOD-এর জন্য EAP-TTLS বা একটি পৃথক সুরক্ষিত নেটওয়ার্ক ব্যবহার করবেন। হসপিটালিটি গ্রুপগুলোর ক্ষেত্রে এটি একটি সাধারণ প্যাটার্ন, যেখানে কর্মীদের ডিভাইসগুলো পরিচালনা করা হয় এবং সেগুলোতে সার্টিফিকেট দেওয়া হয়, অন্যদিকে অতিথিদের জন্য ব্যবহৃত অবকাঠামো সম্পূর্ণ ভিন্ন একটি প্রমাণীকরণ পথ ব্যবহার করে। র‌্যাপিড-ফায়ার প্রশ্নোত্তর (৮:০০ - ৯:০০) চলুন CTO এবং নেটওয়ার্ক আর্কিটেক্টদের কাছ থেকে আমরা প্রায়শই যে প্রশ্নগুলো শুনি, সেগুলোর কয়েকটি দ্রুত উত্তর দেওয়া যাক। প্রশ্ন এক: WPA3 Enterprise-এর জন্য কি EAP-TLS প্রয়োজন? আপনি যদি WPA3 Enterprise ১৯২-বিট সিকিউরিটি স্যুট প্রয়োগ করতে চান, তবে হ্যাঁ, EAP-TLS হলো একমাত্র অনুমোদিত পদ্ধতি। এটিই একমাত্র EAP পদ্ধতি যা Wi-Fi Alliance-এর WPA3-Enterprise ১৯২-বিট প্রয়োজনীয়তা পূরণ করে। প্রশ্ন দুই: আমরা কি IoT ডিভাইসের জন্য EAP-TTLS ব্যবহার করতে পারি? সাধারণত, না। স্ক্রিন বা ইন্টারফেসহীন (Headless) IoT ডিভাইস, যেমন ইনফিউশন পাম্প বা পরিবেশগত সেন্সরগুলোতে সাধারণত জটিল অভ্যন্তরীণ প্রমাণীকরণ পদ্ধতিগুলো পরিচালনা করার মতো ইন্টারফেস থাকে না। IoT-এর জন্য আসলে EAP-TLS বেশি উপযোগী, কারণ আপনি ডিভাইসটি প্রস্তুত করার সময়ই সার্টিফিকেটটি সরবরাহ করতে পারেন। কোনো ব্যবহারকারীর ইন্টারঅ্যাকশন ছাড়াই ডিভাইসটি স্বয়ংক্রিয়ভাবে প্রমাণীকরণ সম্পন্ন করে। প্রশ্ন তিন: EAP-TLS নেটওয়ার্কে BYOD-এর ক্ষেত্রে কী হবে? অনিয়ন্ত্রিত ব্যক্তিগত ডিভাইসের ক্ষেত্রে, EAP-TLS পরিচালনা করা বেশ কঠিন। আপনি সাময়িক সার্টিফিকেট দেওয়ার জন্য অনবোর্ডিং পোর্টাল ব্যবহার করতে পারেন, তবে এটি ব্যবহারের জটিলতা বাড়ায়। BYOD-এর জন্য, EAP-TTLS অথবা উপযুক্ত সেগমেন্টেশন সহ একটি ডেডিকেটেড গেস্ট নেটওয়ার্ক সাধারণত সঠিক সমাধান। প্রশ্ন চার: হার্ডওয়্যার ভেন্ডরদের সাথে এর সম্পর্ক কী? EAP-TLS এবং EAP-TTLS উভয়ই সমস্ত প্রধান এন্টারপ্রাইজ WiFi হার্ডওয়্যার প্ল্যাটফর্ম—যেমন Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist এবং Ubiquiti UniFi দ্বারা সমর্থিত। প্ল্যাটফর্ম অনুযায়ী কনফিগারেশনের বিবরণ ভিন্ন হতে পারে, তবে মূল স্ট্যান্ডার্ডগুলো কোনো নির্দিষ্ট ভেন্ডরের ওপর নির্ভরশীল নয়।সারসংক্ষেপ এবং পরবর্তী পদক্ষেপ (৯:০০ - ১০:০০) সংক্ষেপে বলতে গেলে, এখানে আপনার জন্য মূল শিক্ষণীয় বিষয়গুলো দেওয়া হলো। EAP-TLS পারস্পরিক সার্টিফিকেট অথেনটিকেশনের মাধ্যমে সর্বোচ্চ নিরাপত্তা প্রদান করে। এটি পাসওয়ার্ডের ঝুঁকি সম্পূর্ণভাবে দূর করে এবং এটি ম্যানেজড ডিভাইস ফ্লীট ও নিয়ন্ত্রিত পরিবেশের জন্য সঠিক পছন্দ। EAP-TTLS সার্ভার-সাইড সার্টিফিকেট এবং এনক্রিপ্ট করা ক্রেডেনশিয়াল টানেলিংয়ের মাধ্যমে শক্তিশালী নিরাপত্তা প্রদান করে। এটি মিশ্র বা BYOD পরিবেশের জন্য সঠিক পছন্দ। উভয় প্রোটোকলের ক্ষেত্রেই আপনাকে প্রতিটি ক্লায়েন্টে সার্ভার সার্টিফিকেট ভ্যালিডেশন বাধ্যতামূলক করতে হবে। এটি ছাড়া, কোনো প্রোটোকলই আপনাকে ক্ষতিকারক অ্যাক্সেস পয়েন্ট (rogue access points) থেকে রক্ষা করতে পারবে না। এবং সার্টিফিকেট লাইফসাইকেল ম্যানেজমেন্ট হলো EAP-TLS-এর প্রধান পরিচালনগত চ্যালেঞ্জ - প্রথম দিন থেকেই MDM এবং SCEP-এর মাধ্যমে এটি স্বয়ংক্রিয় করুন। আপনার পরবর্তী পদক্ষেপগুলো কী? আপনার বর্তমান 802.1X ডেপ্লয়মেন্ট অডিট করুন। আপনি যদি এখনও শেয়ার করা পাসওয়ার্ডের ওপর নির্ভর করে থাকেন, তবে আপনার মাইগ্রেশনের পরিকল্পনা করুন। আপনার ক্লায়েন্ট সাপ্লিক্যান্টগুলো সার্ভার সার্টিফিকেট যাচাই করছে কিনা তা পরীক্ষা করুন। এবং আপনি যদি একাধিক ভেন্যু বা একটি বিস্তৃত এস্টেটে ডেপ্লয় করতে চান, তবে পরিচালনগত চাপ কমাতে একটি ক্লাউড-হোস্টেড RADIUS সার্ভিসের কথা বিবেচনা করুন। Purple-এর এই টেকনিক্যাল ব্রিফিং শোনার জন্য আপনাকে ধন্যবাদ। Purple আমাদের ৮০,০০০-এরও বেশি লাইভ ভেন্যুতে Staff WiFi-এর জন্য EAP-TLS এবং EAP-TTLS উভয় অথেন্টিকেশন পাথ সমর্থন করে। আরও বিস্তারিত ডেপ্লয়মেন্ট গাইড এবং আমাদের অ্যানালিটিক্স ও আইডেন্টিটি প্ল্যাটফর্মগুলো কীভাবে আপনার সুরক্ষিত নেটওয়ার্কের সাথে সংযুক্ত হয় তা জানতে, purple dot ai ভিজিট করুন।

header_image.png

कार्यकारी सारांश (Executive summary)

अपने 802.1X डिप्लॉयमेंट के लिए सही EAP विधि चुनना यह तय करता है कि आपका एंटरप्राइज WiFi वास्तव में सुरक्षित है या केवल कागजों पर ही अनुपालन करता है। EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), जो RFC 5216 में परिभाषित है, को आपसी प्रमाणपत्र प्रमाणीकरण (mutual certificate authentication) की आवश्यकता होती है: नेटवर्क एक्सेस मिलने से पहले क्लाइंट डिवाइस और RADIUS सर्वर दोनों वैध X.509 प्रमाणपत्र प्रस्तुत करते हैं। किसी भी समय पासवर्ड का आदान-प्रदान नहीं किया जाता है। EAP-TTLS (Tunneled Transport Layer Security), जो RFC 5281 में परिभाषित है, को एक एन्क्रिप्टेड TLS टनल स्थापित करने के लिए केवल एक सर्वर-साइड प्रमाणपत्र की आवश्यकता होती है, जिसके अंदर क्लाइंट मौजूदा निर्देशिका क्रेडेंशियल का उपयोग करके प्रमाणित होता है।

रिटेल चेन, हॉस्पिटैलिटी स्थलों और सार्वजनिक क्षेत्र के संगठनों में बुनियादी ढांचे का प्रबंधन करने वाले CTOs और नेटवर्क आर्किटेक्ट्स के लिए, यह निर्णय केवल एक प्रश्न पर निर्भर करता है: क्या आप उपकरणों का प्रबंधन करते हैं? यदि आप MDM के माध्यम से डिवाइस बेड़े को नियंत्रित करते हैं, तो EAP-TLS निश्चित विकल्प है। यदि आप एक विविध BYOD वातावरण का समर्थन करते हैं या एक मजबूत पब्लिक की इन्फ्रास्ट्रक्चर (PKI) की कमी है, तो EAP-TTLS एक व्यावहारिक, अत्यधिक सुरक्षित विकल्प प्रदान करता है। Purple 80,000+ से अधिक लाइव स्थलों पर Staff WiFi के लिए दोनों प्रमाणीकरण पथों का समर्थन करता है।

comparison_chart.png


तकनीकी गहन विश्लेषण (Technical deep-dive)

EAP-TLS की वास्तुकला

EAP-TLS, IEEE 802.1X पोर्ट-आधारित एक्सेस कंट्रोल फ्रेमवर्क के भीतर एक आपसी प्रमाणीकरण (mutual authentication) मॉडल पर काम करता है। प्रत्येक प्रमाणीकरण विनिमय में तीन मुख्य कारक होते हैं: सप्लिकेंट (क्लाइंट डिवाइस), ऑथेंटिकेटर (वायरलेस एक्सेस पॉइंट), और ऑथेंटिकेशन सर्वर (RADIUS सर्वर)। एक्सेस पॉइंट स्वयं प्रमाणीकरण निर्णय नहीं लेता है। यह एक पारदर्शी रिले के रूप में कार्य करता है, जो EAP संदेशों को RADIUS पैकेटों में समाहित करता है और उन्हें ऑथेंटिकेशन सर्वर पर भेजता है।

EAP-TLS हैंडशेक इस प्रकार आगे बढ़ता है। एक्सेस पॉइंट कनेक्ट होने वाले डिवाइस को एक EAP-Request/Identity भेजता है। डिवाइस अपनी पहचान के साथ प्रतिक्रिया देता है। RADIUS सर्वर EAP-TLS/Start संदेश के साथ TLS हैंडशेक शुरू करता है। क्लाइंट एक ClientHello भेजता है, जो इसके समर्थित TLS साइफर सुइट्स का विज्ञापन करता है। RADIUS सर्वर ServerHello, अपने X.509 सर्वर सर्टिफिकेट और एक सर्टिफिकेट अनुरोध के साथ प्रतिक्रिया देता है। क्लाइंट अपने विश्वसनीय रूट CA स्टोर के खिलाफ सर्वर सर्टिफिकेट को सत्यापित करता है। यदि सत्यापन विफल हो जाता है, तो हैंडशेक समाप्त हो जाता है - जो अनधिकृत (rogue) एक्सेस पॉइंट से सुरक्षा प्रदान करता है। इसके बाद क्लाइंट अपना स्वयं का 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 एयर-गैप्ड होना चाहिए, क्योंकि इसकी प्राइवेट की (private key) आपके संपूर्ण सर्टिफिकेट पदानुक्रम के लिए मास्टर ट्रस्ट एंकर है। जारी करने वाला CA दैनिक सर्टिफिकेट जारी करने का काम संभालता है और CRL प्रकाशित करता है। क्लाइंट सर्टिफिकेट व्यक्तिगत उपकरणों को जारी किए जाते हैं, उपयोगकर्ताओं को नहीं - यह एक डिवाइस-आइडेंटिटी मॉडल है। यह अंतर IoT उपकरणों, साझा टर्मिनलों और हेडलेस सिस्टम के लिए महत्वपूर्ण है।

EAP-TTLS की संरचना

EAP-TTLS को हर क्लाइंट डिवाइस पर सर्टिफिकेट तैनात करने के परिचालन बोझ के बिना मजबूत 802.1X सुरक्षा प्रदान करने के लिए डिज़ाइन किया गया था। यह दो चरणों में काम करता है। पहले चरण में, RADIUS सर्वर अपना सर्टिफिकेट प्रस्तुत करता है और एक सुरक्षित TLS टनल स्थापित करता है। केवल सर्वर को ही सर्टिफिकेट की आवश्यकता होती है। दूसरे चरण में, क्लाइंट एक आंतरिक प्रमाणीकरण पद्धति का उपयोग करके उस एन्क्रिप्टेड टनल के भीतर प्रमाणित होता है। सामान्य आंतरिक तरीकों में PAP (Password Authentication Protocol), 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 (रूट CA + जारीकर्ता CA + MDM) केवल सर्वर प्रमाणपत्र
WPA3-Enterprise 192-bit आवश्यक विधि समर्थित नहीं
PCI DSS 4.0 संरेखण दृढ़ता से अनुशंसित मजबूत आंतरिक प्रमाणीकरण के साथ स्वीकार्य
BYOD उपयुक्तता कम (क्लाइंट प्रमाणपत्र की आवश्यकता होती है) उच्च (केवल क्रेडेंशियल्स)
IoT डिवाइस उपयुक्तता उच्च (स्टेजिंग पर प्रमाणपत्र प्रदान किया गया) कम (क्रेडेंशियल इनपुट के लिए कोई UI नहीं)
Windows मूल समर्थन हाँ आंशिक (अक्सर तृतीय-पक्ष सप्लीकेंट की आवश्यकता होती है)
macOS/Linux/Android समर्थन हाँ हाँ
परिनियोजन जटिलता उच्च मध्यम

कार्यान्वयन गाइड

प्रबंधित फ़्लीट के लिए EAP-TLS तैनात करना

EAP-TLS को तैनात करने के लिए एक कार्यात्मक PKI और एक MDM प्लेटफॉर्म की आवश्यकता होती है। मैन्युअल प्रमाणपत्र स्थापना एंटरप्राइज़ स्तर पर व्यवहार्य नहीं है। आपको SCEP (सिंपल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल) या EST (एनरोलमेंट ओवर सिक्योर ट्रांसपोर्ट) का उपयोग करके अपने PKI को अपने MDM के साथ एकीकृत करना होगा। जब एक कॉर्पोरेट डिवाइस नामांकित होता है, तो यह उपयोगकर्ता के हस्तक्षेप के बिना स्वचालित रूप से अपने प्रमाणपत्र का अनुरोध करता है और प्राप्त करता है।

पहचान प्रबंधन के लिए, Connect लाइसेंस के तहत OpenRoaming जैसी सेवाओं के लिए Purple एक निःशुल्क पहचान प्रदाता के रूप में कार्य करता है, जो अंतर्निहित प्रमाणपत्र और पहचान ढांचे का उपयोग करके विभिन्न स्थानों पर सुरक्षित रोमिंग की सुविधा प्रदान करता है।

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 - के साथ एकीकृत हो। अपने MDM-तैनात WiFi प्रोफाइल को अपने विशिष्ट विश्वसनीय CA के विरुद्ध सर्वर प्रमाणपत्र सत्यापन लागू करने के लिए कॉन्फ़िगर करें। इस चरण के बिना, 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 विफलताओं का सबसे आम कारण है। ऐसा मॉनिटरिंग सिस्टम लागू करें जो समाप्ति से 60 दिन, 30 दिन और सात दिन पहले अलर्ट भेजे।

RADIUS क्लाइंट का गलत कॉन्फ़िगरेशन

प्रत्येक एक्सेस पॉइंट या वायरलेस कंट्रोलर को सही IP एड्रेस और शेयर्ड सीक्रेट के साथ RADIUS क्लाइंट के रूप में परिभाषित किया जाना चाहिए। बेमेल होने के कारण प्रमाणीकरण टाइमआउट होता है जिसे अक्सर गलत तरीके से EAP विधि के कारण मान लिया जाता है। पहले दिन से ही विस्तृत RADIUS लॉगिंग सक्षम करें। अधिक WiFi समस्या निवारण मार्गदर्शन के लिए, हमारी गाइड Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures देखें।


अनुपालन और नियामक संरेखण

CISOs और नेटवर्क आर्किटेक्ट्स के लिए EAP-TLS बनाम EAP-TTLS का निर्णय लेने के लिए नियामक परिदृश्य को समझना आवश्यक है। EAP विधि का चयन सीधे कई प्रमुख फ्रेमवर्क में आपके अनुपालन की स्थिति को प्रभावित करता है।

PCI DSS 4.0 (पेमेंट कार्ड इंडस्ट्री डेटा सिक्योरिटी स्टैंडर्ड) को कार्डधारक डेटा परिवेश में वायरलेस नेटवर्क के लिए मजबूत क्रिप्टोग्राफिक प्रमाणीकरण की आवश्यकता होती है। आवश्यकता 8.3 CDE तक की सभी पहुंच के लिए मल्टी-फैक्टर प्रमाणीकरण को अनिवार्य बनाती है, और दायरे में आने वाले वायरलेस नेटवर्क को मजबूत प्रमाणीकरण तंत्र का उपयोग करना चाहिए। सर्टिफिकेट-आधारित म्यूचुअल प्रमाणीकरण के साथ EAP-TLS इस आवश्यकता को निश्चित रूप से पूरा करता है। MS-CHAPv2 के साथ EAP-TTLS स्वीकार्य है यदि आंतरिक प्रमाणीकरण ठीक से सुरक्षित है और सर्वर सर्टिफिकेट सत्यापन लागू किया गया है, लेकिन EAP-TLS अधिक मजबूत और ऑडिटर-अनुकूल विकल्प है।

HIPAA (हेल्थ इंश्योरेंस पोर्टेबिलिटी एंड अकाउंटेबिलिटी एक्ट) के तहत कवर की गई संस्थाओं के लिए तकनीकी सुरक्षा उपाय लागू करना आवश्यक है जो इलेक्ट्रॉनिक संचार नेटवर्क पर प्रसारित होने वाली इलेक्ट्रॉनिक संरक्षित स्वास्थ्य जानकारी (ePHI) की रक्षा करते हैं। HIPAA सुरक्षा नियम विशिष्ट प्रोटोकॉल को अनिवार्य नहीं करता है, लेकिन ePHI ले जाने वाले वायरलेस नेटवर्क के लिए एन्क्रिप्शन और एक्सेस कंट्रोल की उम्मीद प्रबंधित चिकित्सा उपकरण बेड़े के लिए EAP-TLS और स्टाफ उपकरणों के लिए लागू सर्वर सर्टिफिकेट सत्यापन के साथ EAP-TTLS के पक्ष में मजबूती से झुकी हुई है।

WPA3-Enterprise 192-bit (जिसे सुइट B या CNSA मोड के रूप में भी जाना जाता है) Wi-Fi Alliance के WPA3 सर्टिफिकेशन का उच्चतम सुरक्षा स्तर है। यह एकमात्र अनुमत प्रमाणीकरण विधि के रूप में EAP-TLS को अनिवार्य करता है, विशिष्ट सिफर सुइट्स (P-384 के साथ ECDHE, AES-256-GCM) के साथ TLS 1.2 या उच्चतर की आवश्यकता होती है, और ECDSA या RSA-3072 सर्टिफिकेट की आवश्यकता होती है। सरकारी, रक्षा, या महत्वपूर्ण बुनियादी ढांचा अनुप्रयोगों के लिए WPA3-Enterprise 192-bit तैनात करने वाले संगठनों को EAP-TLS का उपयोग करना चाहिए। ISO/IEC 27001 विशिष्ट प्रोटोकॉल को अनिवार्य नहीं करता है, लेकिन संगठनों को नेटवर्क संसाधनों के लिए उपयुक्त एक्सेस नियंत्रण लागू करने की आवश्यकता होती है। EAP-TLS या EAP-TTLS (लागू सर्वर प्रमाणपत्र सत्यापन के साथ) में से किसी एक के साथ 802.1X परिनियोजन (deployment) Annex A.9.1 और A.13.1 की नेटवर्क एक्सेस नियंत्रण आवश्यकताओं को पूरा करता है।


ROI और व्यावसायिक प्रभाव

EAP-TLS पर माइग्रेट करने के लिए PKI और MDM एकीकरण में शुरुआती निवेश की आवश्यकता होती है, लेकिन यह पासवर्ड रीसेट के परिचालन ओवरहेड और क्रेडेंशियल से समझौता होने के कारण होने वाले नेटवर्क ब्रीच के वित्तीय जोखिम को समाप्त करता है। 400 स्टोर वाली एक रिटेल चेन के लिए, साझा PSK नेटवर्क पर एक सिंगल कॉम्प्रोमाइज्ड पासवर्ड पूरे एस्टेट को खतरे में डाल सकता है। EAP-TLS उस अटैक वेक्टर को पूरी तरह से समाप्त कर देता है।

मल्टी-टेनेंट वातावरण और ट्रैवल हब के लिए, सुरक्षित प्रमाणीकरण (authentication) यह सुनिश्चित करता है कि केवल अधिकृत उपयोगकर्ता ही नेटवर्क बैंडविड्थ का उपयोग करें, जिससे बुनियादी ढांचे (infrastructure) के उपयोग को अनुकूलित किया जा सके। RADIUS प्रमाणपत्र विशेषताओं के माध्यम से डायनामिक VLAN असाइनमेंट क्रिप्टोग्राफिक रूप से लागू नेटवर्क सेगमेंटेशन को सक्षम बनाता है, जिससे SSID चयन या MAC address फ़िल्टरिंग पर निर्भर रहने के बजाय प्रमाणपत्र गुणों के आधार पर उपकरणों को सही नेटवर्क सेगमेंट पर रखा जा सकता है।

Purple का WiFi Analytics प्लेटफ़ॉर्म दोनों प्रमाणीकरण पथों के साथ एकीकृत होता है, जो आपके पूरे एस्टेट में डिवाइस की संख्या, सत्र की अवधि (session durations) और नेटवर्क उपयोग की दृश्यता प्रदान करता है। क्षेत्र-विशिष्ट परिनियोजन मार्गदर्शन के लिए, हॉस्पिटैलिटी , रिटेल , हेल्थकेयर , और ट्रांसपोर्ट के लिए हमारे संसाधनों को एक्सप्लोर करें।

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

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)

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

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

X.509

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

সমস্ত এন্টারপ্রাইজ PKI ডেপ্লয়মেন্টে ব্যবহৃত সার্টিফিকেট ফরম্যাট। যখন IT টিমগুলো 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 স্থাপন করা সত্ত্বেও ডিভাইসগুলোকে Evil Twin আক্রমণের ঝুঁকিতে ফেলে দেয়।

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

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

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

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

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

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

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

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

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

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

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

Server RADIUS: ব্যবসার জন্য একটি বিস্তৃত নির্দেশিকা

এই নির্দেশিকাটি IT ম্যানেজার, নেটওয়ার্ক স্থপতি এবং CTO-দের এন্টারপ্রাইজ WiFi-এর জন্য server RADIUS প্রমাণীকরণ (authentication) সংক্রান্ত একটি সুনির্দিষ্ট প্রযুক্তিগত রেফারেন্স প্রদান করে। এতে AAA ফ্রেমওয়ার্ক, 802.1X আর্কিটেকচার, EAP পদ্ধতি নির্বাচন, ক্লাউড বনাম অন-প্রিমিসেস ডেপ্লয়মেন্টের সুবিধা-অসুবিধা এবং ডাইনামিক VLAN অ্যাসাইনমেন্ট অন্তর্ভুক্ত রয়েছে। আতিথেয়তা (hospitality), রিটেইল, ইভেন্ট এবং পাবলিক সেক্টর জুড়ে ভেন্যু অপারেটররা এখানে কার্যকরী বাস্তবায়ন নির্দেশিকা, বাস্তব-জগতের কেস স্টাডি এবং অনিরাপদ প্রি-শেয়ার্ড কি (PSK) থেকে একটি নিরাপদ, পরিচয়-ভিত্তিক নেটওয়ার্ক অ্যাক্সেস কন্ট্রোল আর্কিটেকচারে স্থানান্তরিত হওয়ার জন্য প্রয়োজনীয় সিদ্ধান্ত গ্রহণের ফ্রেমওয়ার্ক পাবেন।

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

Aruba ClearPass বনাম Purple WiFi: ফিচার এবং সহ-স্থাপনার তুলনা

Aruba ClearPass এবং Purple WiFi-এর সহ-স্থাপনা আর্কিটেকচারের বিবরণ সম্বলিত একটি ব্যাপক প্রযুক্তিগত নির্দেশিকা। এটি এন্টারপ্রাইজ NAC-এর পাশাপাশি সুরক্ষিত, অ্যানালিটিক্স-চালিত গেস্ট নেটওয়ার্ক প্রদানের জন্য RADIUS proxy কনফিগারেশন, ডায়নামিক VLAN অ্যাসাইনমেন্ট এবং সর্বোত্তম অনুশীলনগুলি কভার করে।

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

Cisco ISE বনাম Purple WiFi: কীভাবে তারা তুলনা করে এবং একসাথে কাজ করে

এই নির্দেশিকাটি ব্যাখ্যা করে যে কীভাবে Cisco ISE এবং Purple WiFi এন্টারপ্রাইজ নেটওয়ার্কে আলাদা কিন্তু পরিপূরক ভূমিকা পালন করে। এটি নিরাপদ 802.1X কর্পোরেট অ্যাক্সেসের জন্য Cisco ISE কীভাবে ব্যবহার করবেন তা বিস্তারিতভাবে বর্ণনা করে, পাশাপাশি GDPR-সম্মত গেস্ট WiFi, মার্কেটিং অ্যানালিটিক্স এবং CRM ইন্টিগ্রেশনের জন্য Purple-কে কাজে লাগায়।

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