EAP-TLS বনাম PEAP: সিকিউরিটি, সার্টিফিকেট এবং এর উপযুক্ততা
Published
eap tls vs peap নিয়ে সবচেয়ে প্রচলিত পরামর্শটি বেশ সাজানো গুছানো, কিন্তু ভুল। EAP-TLS বেছে নিন কারণ এটি "বেশি সুরক্ষিত," এবং PEAP-কে সেই দলগুলোর জন্য ছেড়ে দিন যারা এখনও পিছিয়ে আছে। এই ধারণাটি সেই মূল প্রশ্নটিকেই এড়িয়ে যায় যা নির্ধারণ করে যে সোমবারে একটি বহু-সাইট WLAN চালু থাকবে কিনা। আপনি কি প্রতিটি ডিভাইসের জন্য সার্টিফিকেট ইস্যু, নবায়ন এবং বাতিল করতে সক্ষম যা এটি ব্যবহার করার কথা?
আমি পুরো এস্টেটে একটি পদ্ধতি প্রয়োগ করব না। EAP-TLS সেই ডিভাইসগুলোর জন্য প্রযোজ্য যা আপনি এনরোল এবং রিনিউ করতে পারেন। PEAP, প্রায় সবসময়ই ইনার EAP-MSCHAPv2 সহ, সেখানে প্রযোজ্য যেখানে একটি ডিরেক্টরি পাসওয়ার্ড ইতিমধ্যে বিদ্যমান এবং সার্টিফিকেট এনরোলমেন্ট ব্যবহারিক নয়। কঠিন পদ্ধতিটিই সবসময় সেই পদ্ধতি নয় যা আপনি চালাতে পারেন। একটি হোটেলের ব্যাক অফিসে একটি মেয়াদোত্তীর্ণ সার্টিফিকেট কর্মীদের লক আউট করে দেয়, যদিও তাদের অ্যাকাউন্টগুলো বৈধ থাকে। একটি PEAP প্রোফাইল যা সার্ভার চেক এড়িয়ে যায় তা একটি রোগে অ্যাক্সেস পয়েন্টে ডিরেক্টরি পাসওয়ার্ড হস্তান্তর করতে পারে। উভয় ব্যর্থতাই অপারেশনাল। নেটওয়ার্ক-ব্যাপী একটি বিজয়ী খোঁজার বদলে জনসংখ্যার ওপর ভিত্তি করে পদ্ধতি নির্ধারণ করুন।
সূচিপত্র
- EAP-TLS এবং PEAP পাশাপাশি তুলনা
- প্রতিটি পদ্ধতি কীভাবে অথেন্টিকেট করে এবং কোথায় পাসওয়ার্ড ফাঁস হয়
- রোলআউটের আগে সার্টিফিকেট সংক্রান্ত প্রয়োজনীয়তা
- সার্টিফিকেট লাইফসাইকেল এবং রোলআউটের প্রচেষ্টা
- বাতিলকরণ রোমিং স্পিড এবং ক্লায়েন্ট সাপোর্ট
- প্রতিটি পপুলেশন বরাদ্দ করুন এবং বিভাজনটি প্রমাণ করুন
EAP-TLS এবং PEAP পাশাপাশি
EAP-TLS এবং PEAP-এর মধ্যে ব্যবহারিক পার্থক্য হলো প্রতিটি এন্ডপয়েন্ট যে ক্রিডেনশিয়াল সাপোর্ট করতে পারে এবং এটি ব্যবহারযোগ্য রাখার জন্য প্রয়োজনীয় কাজ। যে ডিভাইসগুলো আপনি এনরোল এবং রিনিউ করতে পারেন সেগুলোর জন্য EAP-TLS ব্যবহার করুন। যেখানে ব্যবহারকারীদের ইতিমধ্যে ডিরেক্টরি পাসওয়ার্ড রয়েছে এবং সার্টিফিকেট এনরোলমেন্ট ব্যবহারিক নয়, সেখানে PEAP ব্যবহার করুন। কোনো পদ্ধতিই প্রতিটি ব্যবহারকারী গোষ্ঠীর জন্য সঠিক উত্তর নয়।
| মানদণ্ড | EAP-TLS | PEAP |
|---|---|---|
| EAP টাইপ ID | 13 | 26 |
| ক্লায়েন্ট ক্রেডেনশিয়াল | X.509 ক্লায়েন্ট সার্টিফিকেট | ব্যবহারকারীর নাম এবং পাসওয়ার্ড, সাধারণত EAP-MSCHAPv2 বা EAP-GTC |
| সার্ভার ক্রেডেনশিয়াল | RADIUS সার্ভার সার্টিফিকেট | আউটার TLS টানেলে RADIUS সার্ভার সার্টিফিকেট |
| মিউচুয়াল অথেন্টিকেশন | ক্লায়েন্ট এবং সার্ভার সার্টিফিকেট | সার্ভার সার্টিফিকেট প্লাস ইনার ব্যবহারকারী বা ডিভাইস অথেন্টিকেশন |
| ওয়্যারে পাসওয়ার্ড | কোনোটিই নয় | হ্যাঁ, TLS টানেলের ভেতরে |
| ক্লায়েন্ট সার্ভার চেক এড়িয়ে গেলে একটি রোগ AP যা চুরি করতে পারে | পাসওয়ার্ডের মতো কিছুই নয়; অথেন্টিকেশন ক্লোজড হয়ে ব্যর্থ হয় | ডিরেক্টরি পাসওয়ার্ড |
| একটি ডিভাইস রিভোক করা | সেই সার্টিফিকেট রিভোক বা মেয়াদ শেষ করুন | অ্যাকাউন্ট নিষ্ক্রিয় করুন বা পুুনরায় ব্যবহার করা যেতে পারে এমন পাসওয়ার্ড রিসেট করুন |
| PKI কাজ | সার্ভার এবং ক্লায়েন্ট সার্টিফিকেট, রিনিউয়াল এবং রিকভারি | শুধুমাত্র সার্ভার সার্টিফিকেট |
| প্রথমে ব্যবহারের জন্য সেরা | MDM দ্বারা পরিচালিত কর্মী এবং বিশেষ সুবিধাপ্রাপ্ত ডিভাইস | অপরিচালিত এন্ডপয়েন্ট যা সার্টিফিকেট এনরোল করতে পারে না |
একটি 2025 Authentik কারিগরি নিবন্ধ EAP-TLS-কে EAP টাইপ ID 13 এবং PEAP-কে টাইপ ID 26 হিসেবে চিহ্নিত করে। এই ID-গুলো RADIUS এবং সাপ্লিক্যান্টের কাছে মেথডগুলোকে সনাক্ত করে। কোন ব্যক্তি বা ডিভাইসের সেগুলো ব্যবহার করা উচিত তা এগুলো নির্ধারণ করে না।
সারিগুলো প্রকৃতপক্ষে কী পরিবর্তন করে
ক্লায়েন্ট শংসাপত্রটি অপারেশনাল সীমা নির্ধারণ করে। EAP-TLS একটি X.509 ক্লায়েন্ট সার্টিফিকেট উপস্থাপন করে। PEAP সাধারণত EAP-MSCHAPv2 বা EAP-GTC-এর মাধ্যমে একটি ব্যবহারকারীর নাম এবং পাসওয়ার্ড ব্যবহার করে। এটি পদ্ধতির তাত্ত্বিক র্যাঙ্কিংয়ের বদলে সার্টিফিকেট এনরোলমেন্ট এবং পুনর্নবীকরণকে মূল কাজের চাপ হিসেবে তৈরি করে।
ট্রাস্ট চেকগুলোও আলাদা। EAP-TLS ক্লায়েন্ট এবং সার্ভার উভয় সার্টিফিকেট যাচাই করে। PEAP বাইরের TLS টানেলে RADIUS সার্ভার সার্টিফিকেট ভ্যালিডেট করে, তারপর একটি ইনার মেথডের মাধ্যমে ব্যবহারকারী বা ডিভাইসকে প্রামাণিক করে।
পাসওয়ার্ডের ঝুঁকি সাপ্লিক্যান্ট কনফিগারেশনের ওপর নির্ভর করে। EAP-TLS-এ নেটওয়ার্কে কোনো পাসওয়ার্ড প্রেরিত হয় না। PEAP তার টানেলের ভেতরে পাসওয়ার্ড বহন করে, তাই যে ক্লায়েন্ট সার্ভার যাচাইকরণ এড়িয়ে যায় সে একটি ভুয়া অ্যাক্সেস পয়েন্টের কাছে ডিরেক্টরি পাসওয়ার্ড প্রকাশ করে দিতে পারে। EAP-TLS-এর ক্ষেত্রে, ক্লায়েন্ট সার্টিফিকেট অনুপস্থিত বা বিশ্বস্ত না হলে অথেন্টিকেশন ব্যর্থ হয়।
অফবোর্ডিংও নির্ভর করে কী ম্যানেজ করা হচ্ছে তার ওপর। কোনো ব্যক্তির ডিরেক্টরি পাসওয়ার্ড রিসেট না করেই একটি ডিভাইস সার্টিফিকেট বাতিল করা বা মেয়াদ শেষ হতে দেওয়া যেতে পারে। একটি অ্যাকাউন্ট নিষ্ক্রিয় করা বা পুনরায় ব্যবহৃত পাসওয়ার্ড পরিবর্তন করা সেই ক্রেডেনশিয়ালের সাথে যুক্ত অন্যান্য লগইনকে প্রভাবিত করতে পারে।
অপারেশনাল ট্রেড-অফটি স্পষ্ট: EAP-TLS-এর জন্য ক্লায়েন্ট সার্টিফিকেট, রিনিউয়াল এবং একটি রিকভারি পাথের প্রয়োজন হয়, অন্যদিকে PEAP-এর জন্য সার্ভার সার্টিফিকেট এবং সতর্ক সাপ্লিক্যান্ট কনফিগারেশনের প্রয়োজন হয়। এনরোল করা কর্মী এবং প্রিভিলেজড ডিভাইসগুলোতে EAP-TLS অ্যাসাইন করুন; সার্টিফিকেট ম্যানেজমেন্টে যোগ দিতে পারে না এমন আনম্যানেজড এন্ডপয়েন্টগুলোর জন্য PEAP রাখুন। serverless infrastructure for membership platforms চালানো টিমগুলোর আলাদা মেম্বার, কর্মী এবং ডিভাইস পপুলেশন থাকতে পারে, তবে হোস্ট করার মডেলটি অ্যাথেন্টিকেশন পদ্ধতি বেছে নেয় না। ক্রেডেনশিয়ালটি আপনি কাকে ম্যানেজ করতে পারেন তার সাথে মিলতে হবে।
প্রতিটি পদ্ধতি কীভাবে প্রামাণিক করে এবং কোথায় পাসওয়ার্ড লিক হয়
EAP-TLS প্রতিটি ব্যবহারকারীর জন্য স্বয়ংক্রিয়ভাবে সঠিক উত্তর নয়। মূল সিদ্ধান্ত হল আপনার টিম প্রতিটি ব্যবহারকারী দলের জন্য নির্ভরযোগ্যভাবে সার্টিফিকেট ইস্যু, নবায়ন এবং বাতিল করতে পারে কিনা। PEAP আনম্যানেজড ব্যবহারকারীদের জন্য অনবোর্ডিং সহজ রাখে, তবে এর পাসওয়ার্ড সঠিক সাপ্লিক্যান্ট কনফিগারেশনের ওপর নির্ভর করে।
উভয় মেথডই 802.1X ব্যবহার করে। সাপ্লিক্যান্ট হল অ্যাক্সেসের অনুরোধকারী ডিভাইস, অথেন্টিকেটর হল অ্যাক্সেস পয়েন্ট বা সুইচ যা সেই অনুরোধটি রিলে করে এবং RADIUS server এটি গ্রহণ বা প্রত্যাখ্যান করে। তারা EAP ফ্রেমওয়ার্ক ভাগ করে নেয়, কোনো ক্রেডেনশিয়াল নয়।
IETF EAP স্পেসিফিকেশন ইনডেক্স IETF RFC 5216-এ সংজ্ঞায়িত EAP-TLS-কে সার্টিফিকেট-ভিত্তিক ক্লায়েন্ট এবং সার্ভার অথেন্টিকেশন, মিউচুয়াল অথেন্টিকেশন, ইন্টিগ্রিটি-প্রোটেক্টেড সাইফার-স্যুট নেগোশিয়েশন এবং কী ডেরিভেশন হিসেবে বর্ণনা করে। স্পেসিফিকেশনটি মার্চ ২০০৮-এ প্রকাশিত হয়েছিল। বাস্তবে, EAP-TLS-এর জন্য RADIUS সার্ভার সার্টিফিকেটের পাশাপাশি PKI-এর মাধ্যমে ইস্যু করা একটি ক্লায়েন্ট সার্টিফিকেট প্রয়োজন।
দুটি সিকোয়েন্স, একটি ফ্রেমওয়ার্ক
EAP-TLS একটি TLS এক্সচেঞ্জে উভয় এন্ডপয়েন্ট প্রামাণিক করে:
- সাপ্লিক্যান্ট প্রমাণীকরণকারীর সাথে EAP শুরু করে, যা অনুরোধটিকে RADIUS-এ রিলে করে।
- TLS বিনিময়ের সময় সার্ভার এবং ক্লায়েন্ট সার্টিফিকেট পরীক্ষা করা হয়।
- এই বিনিময়টি ফিশিং, রিপ্লে বা ব্রুট-ফোর্স করা যেতে পারে এমন কোনও পাসওয়ার্ড না পাঠিয়েই সাইফার-স্যুট আলোচনাকে সুরক্ষিত করে এবং কী (key) তৈরি করে।
- একটি নিখোঁজ বা অবিশ্বাস্য ক্লায়েন্ট সার্টিফিকেট থাকার অর্থ হলো ডিভাইসটি প্রত্যাখ্যান করা হয়েছে। এটি পাসওয়ার্ড টাইপ করার বিকল্পে ফিরে যেতে পারে না।
PEAP একটি বাইরের TLS টানেল তৈরি করে যা সার্ভারকে প্রমানিত করে, তারপর একটি অভ্যন্তরীণ পদ্ধতি পরিচালনা করে, সাধারণত EAP-MSCHAPv2 বা EAP-GTC। যেহেতু অভ্যন্তরীণ পদ্ধতিটি একটি ব্যবহারকারীর নাম এবং পাসওয়ার্ড ব্যবহার করতে পারে, তাই শেষ বিন্দুগুলির (endpoints) সাধারণত ক্লায়েন্ট সার্টিফিকেটের প্রয়োজন হয় না। IETF EAP স্পেসিফিকেশন সূচকটি মানক ফ্রেমওয়ার্ক বর্ণনা করে যা এই পদ্ধতিগুলি ব্যবহার করে।
ব্যবহারকারীরা PEAP এর বাইরের টানেলটি দেখতে পান না। অভ্যন্তরীণ পরিচয়, যা সাধারণত একটি ইউজারনেম এবং পাসওয়ার্ড বা একটি টোকেন, শুধুমাত্র TLS প্রতিষ্ঠিত হওয়ার পরেই পাঠানো হয়। এটি ডিরেক্টরি-ভিত্তিক সাপ্লিক্যান্টদের কাছে PEAP-কে পরিচিত করে তোলে, কিন্তু ক্লায়েন্ট যদি টানেলটি সঠিকভাবে যাচাই না করে তবে পাসওয়ার্ডটি অনাবৃত রেখে দেয়।
ইনার EAP-TLS সহ PEAP হল একটি বিশেষ কেস, যা একটি সার্টিফিকেট মেথডকে একটি বাইরের TLS টানেলের সাথে সংযুক্ত করে। "PEAP" লেবেলযুক্ত একটি ডিপ্লয়মেন্ট বলতে সাধারণত PEAP-MSCHAPv2 বোঝায়।
যেখানে সাপ্লিক্যান্ট ফলাফল নির্ধারণ করে
একটি enterprise wireless EAP methods write-up এই পার্থক্যটি ব্যাখ্যা করে: EAP-TLS পারস্পরিক X.509 প্রমাণীকরণ ব্যবহার করে। RADIUS ক্লায়েন্ট সার্টিফিকেট যাচাই করে এবং ক্লায়েন্ট সার্ভার সার্টিফিকেট যাচাই করে। ফিশিং, রিপ্লে বা ব্রুট-ফোর্স করার জন্য কোনো পাসওয়ার্ড উপলব্ধ থাকে না। রাইট-আপে এটাও বলা হয়েছে যে NIST-এর নীতি অনুযায়ী ওয়্যারলেস স্টেশন এবং প্রমাণীকরণ সার্ভার উভয়েরই বৈধ সার্টিফিকেট থাকা আবশ্যক।
PEAP এর মাধ্যমে, ক্লায়েন্টকে অবশ্যই RADIUS সার্টিফিকেট চেইন এবং প্রত্যাশিত সার্ভার নাম পরীক্ষা করতে হবে। উভয় পরীক্ষার যেকোনো একটি মিস হলে, একটি অননুমোদিত অ্যাক্সেস পয়েন্ট ডিরেক্টরি পাসওয়ার্ডের দাবি করতে পারে। "যাচাই করবেন না" সেট করা একটি সাপ্লিক্যান্ট প্রোফাইল পাসওয়ার্ড সুরক্ষিত করে না।
ব্যবহারিক নিয়ম: WiFi প্রোফাইলে RADIUS সার্ভারের নাম এবং ইস্যুকারী CA পিন করুন। এই চেকগুলো না থাকলে, PEAP কোনো ভুয়া সার্ভারে পাসওয়ার্ড প্রদান করতে পারে।
সংগৃহীত MS-CHAPv2 রেসপন্সগুলো একজন আক্রমণকারী একটি রোগে টানেলের মাধ্যমে পাওয়ার পর অফলাইনে ক্র্যাক করা যেতে পারে। টানেল ভ্যালিড করা হলো আসল নিয়ন্ত্রণ; ইনার পদ্ধতিটি এমন একটি প্রোফাইলকে রক্ষা করতে পারে না যা একটি বিশ্বস্ত নয় এমন সার্ভারকে গ্রহণ করে। একই পাসওয়ার্ডের ঝুঁকি WiFi-এর বাইরেও বিস্তৃত। compromised credentials in Australian small businesses সম্পর্কিত রিপোর্টগুলো ব্যাখ্যা করে যে কেন একটি পুনরায় ব্যবহৃত ডিরেক্টরি পাসওয়ার্ড একজন আক্রমণকারীর কাছে মূল্যবান থেকে যায়।
ম্যানেজড ডিভাইস এবং যে সকল ব্যবহারকারীদের সার্টিফিকেট লাইফসাইকেল আপনি পরিচালনা করতে পারেন, তাদের EAP-TLS বরাদ্দ করুন। যেখানে ব্যবহারকারী বা ডিভাইসগুলো নির্ভরযোগ্যভাবে সার্টিফিকেট গ্রহণ ও নবায়ন করতে পারে না, সেখানে PEAP ব্যবহার করুন, তবে সাপ্লিক্যান্ট প্রোফাইলের মাধ্যমে সার্ভার-নেম এবং CA যাচাইকরণ বাধ্যতামূলক করুন। অপারেশনাল সুবিধা ও অসুবিধার হিসাবটি সরাসরি: সার্টিফিকেট এনরোলমেন্ট এবং রিকভারির কাজের প্রয়োজন হয়, অন্যদিকে পাসওয়ার্ড আপনাকে পুনরায় ব্যবহার এবং অ্যাকাউন্ট পরিবর্তনের বিষয়টি পরিচালনায় ব্যস্ত রাখে। সবচেয়ে ভালো পদ্ধতি কোনটি তা নির্ভর করে আপনি কাকে পরিচালনা করতে পারছেন তার ওপর, প্রতিটি SSID-এর জন্য একটিমাত্র বিজয়ী ঘোষণা করার ওপর নয়।
রোলআউটের আগে সার্টিফিকেট প্রয়োজনীয়তা
প্রথম প্রোডাকশন জয়েনের আগে ল্যাবে এই ছয়টি আইটেম নিশ্চিত করুন। একটি মিসিং চেইন বা ভুল নাম দেখতে সার্টিফিকেট ভুলের মতো মনে হবে না, বরং মনে হবে "WiFi ডাউন আছে।"
- RADIUS সার্ভার সার্টিফিকেট। এটি আপনার প্রাইভেট CA থেকে ইস্যু করুন। supplicant প্রোফাইল পিন করা নামটি subject বা SAN-এ রাখুন। সার্ভার অথেন্টিকেশন ব্যবহার সেট করুন, এবং সার্টিফিকেটের সাথে সম্পূর্ণ ইন্টারমিডিয়েট চেইন সার্ভ করুন। যেকোনো ম্যাচিং নামে সাইন করা পাবলিক CA একটি অভ্যন্তরীণ RADIUS নামের জন্য ভুল ট্রাস্ট মডেল।
- ক্লায়েন্ট সার্টিফিকেট। ডিভাইস বা ব্যবহারকারী প্রতি একটি, ক্লায়েন্ট অথেন্টিকেশন ব্যবহার সহ। SAN-এ একটি অনন্য পরিচয় রাখুন, যেমন একটি ইউজার প্রিন্সিপাল নাম বা একটি ডিভাইস সিরিয়াল। প্ল্যাটফর্ম সাপোর্ট করলে প্রাইভেট কী TPM বা সিকিউর এনক্লেভে সংরক্ষণ করুন।
- ট্রাস্ট অ্যাঙ্কর। MDM প্রোফাইলের মাধ্যমে অভ্যন্তরীণ রুট বা ইস্যুইং CA ইনস্টল করুন। ডিভাইসগুলিকে পাবলিক রুটের দিকে নির্দেশ করবেন না এবং নামটি যাচাই করাই যথেষ্ট হবে এমন আশা করবেন না।
- বৈধতা এবং নবায়ন। সার্ভার সার্টিফিকেট এবং ক্লায়েন্ট সার্টিফিকেটের জন্য একটি জীবনকাল প্রকাশ করুন। একটি ওভারল্যাপ উইন্ডো তৈরি করুন যাতে পুরোনোটির মেয়াদ শেষ হওয়ার আগেই নতুনটি ইনস্টল হয়ে যায়।
- বাতিলকরণ (Revocation)। RADIUS সার্ভারকে একটি CRL বা OCSP এন্ডপয়েন্ট দিন যা এটি অ্যাক্সেস করতে পারে। ওই এন্ডপয়েন্টটি অফলাইনে থাকলে অথেন্টিকেশন ব্যর্থ হবে নাকি চলবে তা লিখিতভাবে সিদ্ধান্ত নিন। অফলাইন কেসটি পরীক্ষা করুন। একটি WAN সমস্যা চলার সময় এটি আবিষ্কার করবেন না।
- এনরোলমেন্ট চ্যানেল। MDM-এর মাধ্যমে SCEP বা একটি PKCS#12 দিয়ে সার্টিফিকেট বিতরণ করুন। কোনো গ্রুপকে টার্গেট করার আগে একটি ডিভাইসে নবায়নসহ এটি পরীক্ষা করে প্রমাণ করুন।
ধরা যাক একটি ক্লিনিক সাইট কর্মী পরিচয়ের জন্য Okta এবং ল্যাপটপের জন্য Intune ব্যবহার করে। প্রোফাইলে থাকা RADIUS নামটি সার্টিফিকেটের সাথে মিলতে হবে, এবং যে Okta গ্রুপটির ক্লিনিকাল VLAN-এ আসা উচিত, সেটি সেই একই গ্রুপ হতে হবে যা MDM এনরোলমেন্টের জন্য ব্যবহার করে। Okta WiFi authentication সম্পর্কিত আমাদের নোটগুলি ল্যাবটিকে একটি পাসওয়ার্ড SSID-এ পরিণত না করেই সেই পরিচয় স্থানান্তর প্রক্রিয়া সম্পন্ন করে।
লাইভ ফ্লোরে কাজ শুরু করার আগে একটি টেস্ট ল্যাপটপ যুক্ত করুন, এর সার্টিফিকেট রিভোক করুন এবং নিশ্চিত করুন যে পরবর্তী অ্যাসোসিয়েশন ব্যর্থ হচ্ছে।
সার্টিফিকেট লাইফসাইকেল এবং রোলআউট প্রচেষ্টা
EAP-TLS সুরক্ষা একটি বিভ্রাটে পরিণত হয় যখন একটি সার্টিফিকেটের মেয়াদ শেষ হয়ে যায়, অথবা যখন একটি ক্লায়েন্ট বাতিলকরণের তথ্য জানতে পারে না, অথচ ব্যবহারকারীর অ্যাকাউন্টটি তখনও সম্পূর্ণ বৈধ থাকে। এটিই জিজ্ঞাসা করার মতো প্রশ্ন। "সার্টিফিকেট পরিচালনা আরও কঠিন" কোনো আর্কিটেকচার ডিজাইন হতে পারে না।
NIST Special Publication 800-120 একই দায়বদ্ধতা তুলে ধরে। EAP-TLS-এর জন্য নির্ভরযোগ্য ইস্যুয়েন্স, ডিস্ট্রিবিউশন, রিনিউয়াল, ট্রাস্ট-চেইন ম্যানেজমেন্ট এবং রেভোকেশন চেকিং প্রয়োজন। মেয়াদোত্তীর্ণ সার্টিফিকেটযুক্ত বা অলভ্য রেভোকেশন সার্ভিসসহ একটি ডিভাইস নেটওয়ার্ক অ্যাক্সেস হারাতে পারে, এমনকি ব্যবহারকারীর আইডেন্টিটি বৈধ থাকলেও। PEAP সাধারণত আউটার TLS ফেজে সার্ভারকে এবং একটি ইনার মেথড যেমন MS-CHAPv2-এর মাধ্যমে ব্যবহারকারীর নাম ও পাসওয়ার্ড অথেন্টিকেট করে, তাই এটি সেই ক্লায়েন্ট লাইফসাইকেল এড়িয়ে যায়। প্রথম দিনের সহজ কাজটি পরবর্তীকালে পাসওয়ার্ড রিসেট এবং ভুল প্রোফাইলের ঝামেলায় রূপ নেয়।
সার্টিফিকেট যেন আউটেজের কারণ না হয় তা নিশ্চিত করুন
ডিজাইনের সমাধান হলো অটোমেশন, দীর্ঘ কোনো রানবুক নয়।
- MDM এর মাধ্যমে এনরোল করুন। প্রোফাইল, ট্রাস্ট অ্যাঙ্কর এবং সার্টিফিকেট একসাথে পুশ করুন। ম্যানুয়াল WiFi সেটআপের কারণে সার্ভার-নাম যাচাইয়ের টিক উঠে যায়।
- ওভারল্যাপ নবায়ন। পুরনো সার্টিফিকেটের মেয়াদ শেষ হওয়ার আগেই নতুন সার্টিফিকেট ইনস্টল করুন। এমন একটি উইকএন্ড যেখানে সব ল্যাপটপ একসাথে কাজ বন্ধ করে দেয়, তা হলো ওভারল্যাপ সময় খুব কম হওয়ার ফল।
- অফলাইন বাতিলকরণ পরীক্ষা করুন। CRL বা OCSP ফেচ করা না গেলে RADIUS ফেইল-ক্লোজড হয় নাকি ফেইল-ওপেন হয় তা জেনে নিন।
- একটি রিকভারি পথ রাখুন। একটি ব্যর্থ এন্ডপয়েন্টের ফিরে আসার এমন একটি উপায়ের প্রয়োজন যা "কারো PEAP পাসওয়ার্ড ধার করা" নয়। হোয়াইটবোর্ডে লেখা একটি শেয়ার করা সিক্রেটের চেয়ে তারযুক্ত হেল্পডেস্ক পোর্ট বা কঠোরভাবে স্কোপ করা রিকভারি SSID অনেক ভালো।
Purple Access SCEP-এর মাধ্যমে Microsoft Intune, Jamf Pro, JumpCloud, Kandji, Hexnode, Iru, এবং Addigy থেকে EAP-TLS সার্টিফিকেট গ্রহণ করে, যা প্রতি ডিভাইসের পরিবর্তে পুরো প্রতিষ্ঠানের জন্য একবারে পাঁচ থেকে দশ মিনিটের মধ্যে সেটআপ করা যায়। এই সুরক্ষিত নেটওয়ার্কটি পাসওয়ার্ডহীন এবং সার্টিফিকেট-ভিত্তিক, এবং যে ডিভাইস পোস্টার পরীক্ষায় ব্যর্থ হয় সেটিকে Conditional Access-এর মাধ্যমে প্রমাণীকরণের সময় প্রত্যাখ্যান করা হয়। এটি একটি কম্প্লায়েন্স-গেটেড সংযোগ, কোনো দ্বিতীয় পাসওয়ার্ড প্রম্পট নয়।
যখন PKI উন্নত নয়, যখন ঠিকাদারদের MDM-এ অন্তর্ভুক্ত করা যায় না, অথবা যখন মিশ্র BYOD পরিবেশ সার্টিফিকেট গ্রহণ করবে না, তখন PEAP একটি সহজ ও সরাসরি পছন্দ হিসেবে থেকে যায়। স্বাস্থ্যসেবা, শিক্ষা, আতিথেয়তা এবং অন্যান্য বহু-সাইট বিশিষ্ট প্রতিষ্ঠান প্রায়শই একই সাথে এই তিনটি চ্যালেঞ্জেরই সম্মুখীন হয়। ম্যানেজড কর্পোরেট, কর্মী এবং উচ্চ-ঝুঁকিপূর্ণ ডিভাইসের জন্য EAP-TLS ব্যবহার করুন। আনম্যানেজড বা অস্থায়ী এন্ডপয়েন্টের জন্য একটি কঠোরভাবে নিয়ন্ত্রিত বিকল্প বজায় রাখুন। ভেন্যু-স্কেল আইডেন্টিটি নির্ধারণ করাই মূল সিদ্ধান্ত, TLS পাসওয়ার্ডকে হারিয়ে দিয়েছে - এই ধরনের কোনো স্লোগান নয়।
RADIUS নিজেই যদি ভঙ্গুর অংশ হয়, তবে একটি হোস্ট করা ব্যাকএন্ড "হেডকোয়ার্টার ক্লসেটের একটি সার্ভার" সংক্রান্ত ব্যর্থতা দূর করে। EAP মেথডকে দোষ দেওয়ার আগে পৌঁছানোযোগ্যতা এবং রেডানডেন্সি পরীক্ষা করার জন্য আমাদের RADIUS-as-a-Service সংক্রান্ত নিবন্ধটি উপযুক্ত স্থান।
নিচের সংক্ষিপ্ত ওয়াকথ্রুটি একটি পাসওয়ার্ড ইনার মেথডের পাশাপাশি সার্টিফিকেট এনরোলমেন্ট দেখায়, যা রিনিউয়াল দেরি হলে হেল্পডেস্কগুলো যে পার্থক্যটি দেখতে পায়।
রিভোকেশন রোমিং স্পিড এবং ক্লায়েন্ট সাপোর্ট
সাপোর্ট এবং স্পিড হলো লুকআপ সংক্রান্ত বিষয়। বর্তমান Windows, macOS, iOS, Android, এবং ChromeOS supplicant উভয় পদ্ধতিতেই কাজ করে। কেবল ব্যর্থ হওয়ার মোডটি আলাদা।
EAP-TLS ব্যর্থ হয় যখন প্রোফাইল, ইস্যুকারী CA বা মেয়াদের তারিখ ভুল থাকে। PEAP ব্যর্থ হয় যখন অভ্যন্তরীণ পদ্ধতি, পরিচয়ের বিন্যাস বা সার্ভার-নামের পরীক্ষা RADIUS পলিসির সাথে মেলে না। এর কোনো ব্যর্থতার অর্থই এটি নয় যে অ্যাক্সেস পয়েন্টটি "এন্টারপ্রাইজ সাপোর্ট করে না।"
বাতিলকরণের ক্ষেত্রেও একই পার্থক্য রয়েছে। একটি ডিভাইস সার্টিফিকেট নিষ্ক্রিয় করলে ব্যবহারকারীর অন্যান্য লগইনে প্রভাব না ফেলেই সেই ল্যাপটপটির সংযোগ বিচ্ছিন্ন হয়ে যায়। একটি ডিরেক্টরি পাসওয়ার্ড রিসেট করলে এটি ব্যবহার করা প্রতিটি অব্যবস্থাপনাধীন ক্লায়েন্টে প্রভাব ফেলে। তাৎক্ষণিক, ডিভাইস নির্দিষ্ট সংযোগ বিচ্ছিন্নকরণ হল EAP-TLS-এর সুবিধা। মেয়াদ শেষ হওয়া সার্টিফিকেট থেকে হওয়া মারাত্মক ব্যর্থতাগুলো এর মাশুল।
হ্যান্ডশেক, ব্র্যান্ডের নাম নয়
ওয়্যারলেস অ্যাথেন্টিকেশন ল্যাটেন্সির ওপর একটি ACM paper on wireless authentication latency-এ দেখা গেছে যে পারফর্ম্যান্স পদ্ধতির নামের চেয়ে হ্যান্ডশেক সংখ্যা, রোমিং, সার্টিফিকেট ভ্যালিডেশন এবং ব্যাকএন্ড ল্যাটেন্সি বেশি অনুসরণ করে। স্ট্যান্ডার্ড EAP-TLS তার TLS এক্সচেঞ্জে ক্লায়েন্ট এবং সার্ভার সার্টিফিকেট অ্যাথেন্টিকেশন সম্পন্ন করে। PEAP একটি TLS টানেল তৈরি করে এবং তারপর ইনার অ্যাথেন্টিকেশন চালায়, যা একটি আলাদা ফেজ যুক্ত করে। সেই পেপারে উল্লিখিত Cisco টেকনিক্যাল মেটেরিয়ালে বলা হয়েছে যে ইনার EAP-TLS সহ PEAP-এ দুটি TLS হ্যান্ডশেক জড়িত থাকে এবং রোমিংয়ের সময় সম্পূর্ণ রি-অ্যাথেন্টিকেশন হলে এটি ধীরগতির হতে পারে।
এগুলি আলাদাভাবে পরিমাপ করুন। একটি গড় লগইন সময় থেকে কাউকেই বিজয়ী ঘোষণা করবেন না।
- ৯৫তম-পার্সেন্টাইল অ্যাসোসিয়েশন-টু-IP সময়
- সম্পূর্ণ প্রমাণীকরণ বনাম রোম-পুনরায় শুরুর ল্যাটেন্সি
- RADIUS রাউন্ড-ট্রিপ সময়
- প্রমাণীকরণ ব্যর্থতার হার
- সার্টিফিকেট-নবায়ন ব্যর্থতা
সেশন রেসাম্পশন, PMK ক্যাশিং বা 802.11r, স্থানীয় RADIUS অ্যাক্সেসেবিলিটি এবং একটি ছোট সার্টিফিকেট চেইন একটি সাইফার স্যুট অদলবদল করার চেয়ে এই সংখ্যাগুলিকে বেশি প্রভাবিত করে। PEAP প্রথম দিনে সহজ মনে হতে পারে এবং তবুও বারবার পাসওয়ার্ড বিনিময় এবং ব্যবহারকারীর সমস্যা সমাধানের মাধ্যমে বিলম্ব তৈরি করতে পারে। EAP-TLS এনরোলমেন্টের পর তাৎক্ষণিক মনে হতে পারে এবং তারপরে একটি মেয়াদোত্তীর্ণ সার্টিফিকেটের কারণে মারাত্মকভাবে ব্যর্থ হতে পারে।
| লক্ষণ | অধিক সম্ভাব্য পদ্ধতি | সাধারণ কারণ | ব্যবহারিক সমাধান |
|---|---|---|---|
| একটি অজানা AP-এর কাছে পাসওয়ার্ড প্রম্পট পুনরাবৃত্তি করে | PEAP | Supplicant সার্ভারের নাম বা চেইন যাচাই করছে না | একটি প্রোফাইল পুশ করুন যা RADIUS এর নাম এবং CA পিন করে |
| একটি ভূমিকা পরিবর্তনের পরে একটি ল্যাপটপে অ্যাক্সেস বন্ধ হয়ে যায় | EAP-TLS | সার্টিফিকেট বাতিল করা হয়েছে বা MDM থেকে ডিভাইস সরানো হয়েছে | বাতিলকরণ নিশ্চিত করুন এবং কেবল সেই ডিভাইসটি পুনরায় এনরোল করুন |
| সোমবার পুরো টিমের অ্যাক্সেস লক হয়ে গেছে | EAP-TLS | সার্টিফিকেটের মেয়াদ একসাথে শেষ হয়ে গেছে বা নবায়নের ওভারল্যাপ সময় খুব কম ছিল | মেয়াদ শেষ হওয়ার আগেই নবায়নের ব্যবস্থা করুন এবং একটি রিকভারি পথ রাখুন |
| কেবল সম্পূর্ণ পুনর্দৃষ্টির (reauth) সময় রোম ধীর মনে হয় | ইনার EAP-TLS সহ PEAP | দুটি TLS হ্যান্ডশেক | Resumption, PMK ক্যাশিং বা 802.11r অগ্রাধিকার দিন; প্রয়োজন না হলে ইনার EAP-TLS এড়িয়ে চলুন |
| শুধুমাত্র একটি সাইটে র্যান্ডম রিজেক্ট হচ্ছে | যেকোনো একটি | RADIUS রাউন্ড-ট্রিপ বা চেইন ফেচ, EAP নাম নয় | পদ্ধতি পরিবর্তন করার আগে RTT এবং 95ম-পার্সেন্টাইল অ্যাসোসিয়েশন-টু-IP পরিমাপ করুন |
একটি সাইটে ধীরগতির রোমিং সাধারণত RADIUS দূরত্ব বা চেইন ফেচের কারণে হয়, এটি আপনি ভুল EAP টাইপ বেছে নিয়েছেন তার প্রমাণ নয়।
প্রতিটি পপুলেশন অ্যাসাইন করুন এবং বিভাজন প্রমাণ করুন
একটি ভবনে স্টাফের ল্যাপটপ, কনফারেন্সের অতিথি, ঠিকাদারের Mac এবং একটি ক্যাশ রেজিস্টার থাকতে পারে। তাদের একই ধরনের ক্রেডেনশিয়াল শেয়ার করা উচিত নয়। প্রতিটি ব্যবহারকারী দলকে ম্যাপ করুন, আপনার বর্তমান নেটওয়ার্কের পাশাপাশি একটি সাইটে পাইলট চালান এবং ডিজাইনটি অনুলিপি করার আগে টিকিট এবং প্রমাণীকরণ লগ বিচার করুন।
| জনসংখ্যা | ব্যবহার করুন | ব্যবহার করবেন না | কেন |
|---|---|---|---|
| MDM দ্বারা পরিচালিত কর্মী এবং বিশেষ সুবিধা প্রাপ্ত ব্যবহারকারী | একটি WPA-Enterprise SSID-এ EAP-TLS | শেয়ার করা PSK বা PEAP | সার্টিফিকেট আইডেন্টিটি, গ্রুপ অনুযায়ী VLAN, অ্যাকাউন্ট নিষ্ক্রিয় হলে অ্যাক্সেস শেষ হয়ে যায় |
| স্বল্প মেয়াদের অতিথি এবং দর্শনার্থী | একটি অতিথি VLAN-এ Captive Portal বা Passpoint | ডেস্কে PEAP বা EAP-TLS এনরোলমেন্ট | কোনো সার্টিফিকেট লাইফসাইকেল নেই এবং ফিশিং করার মতো কোনো ডিরেক্টরি পাসওয়ার্ড নেই |
| অপরিচালিত ল্যাপটপ এবং ঠিকাদার | শুধুমাত্র ফোর্সড সার্ভার ভ্যালিডেশন সহ PEAP-MSCHAPv2 | EAP-TLS যদি আপনি সেগুলি এনরোল বা রিনিউ করতে না পারেন | পাসওয়ার্ড ইতিমধ্যেই বিদ্যমান, তবে প্রোফাইলটিকে অবশ্যই RADIUS সার্টিফিকেট পরীক্ষা করতে হবে|
| প্রিন্টার, টিভি, টিল, CCTV এবং সেন্সর | নিজস্ব VLAN সহ প্রতি ডিভাইসে PSK | EAP-TLS বা একটি শেয়ার করা PEAP পাসওয়ার্ড | এই ডিভাইসগুলি সাধারণত সার্টিফিকেট সংরক্ষণ করতে পারে না, এবং একটি শেয়ার করা কী রোটেট করা কঠিন |
| একটি ভবনে মিশ্র ভেন্যু | পার্থক্যসূচক VLAN জুড়ে আইডেন্টিটি অনুসারে বিভক্ত | সবার জন্য একটি SSID এবং একটি পদ্ধতি | কর্মী, অতিথি এবং জিনিসপত্র আলাদাভাবে ব্যর্থ হয় এবং তাদের একই ধরণের ক্রেডেনশিয়াল শেয়ার করা উচিত নয় |
কারা পাসওয়ার্ডে থাকবে, এবং কাদের থাকা উচিত নয়
ব্যবস্থাপনাধীন কর্মী এবং বিশেষ অধিকারপ্রাপ্ত ব্যবহারকারীরা একটি WPA-Enterprise SSID-এ EAP-TLS পান। হাউস কিপিং, অভ্যর্থনা এবং অপারেশন কর্মীরা SCEP-এর মাধ্যমে একটি MDM থেকে সার্টিফিকেটের সাহায্যে অথেন্টিকেট করতে পারেন, ডিরেক্টরি গ্রুপ দ্বারা একটি VLAN-এ প্রবেশ করতে পারেন এবং অ্যাকাউন্টটি নিষ্ক্রিয় হলে অ্যাক্সেস হারাতে পারেন। একটি সংযোজিত PSK বা একটি PEAP পাসওয়ার্ড ঠিক সেই জিনিসটিকেই ফিরিয়ে আনে যা আপনি সরিয়ে দেওয়ার চেষ্টা করছিলেন।
মেহমান এবং দর্শনার্থীরা একটি গেস্ট VLAN-এ ক্যাফটিভ পোর্টাল বা Passpoint-এ থাকবেন। ফ্রন্ট ডেস্কে সার্টিফিকেট নথিভুক্ত করবেন না এবং সেগুলোকে PEAP-এ রাখবেন না। এমন কোনো লাইফসাইকেল নেই যা আপনি পরিচালনা করবেন এবং এমন কোনো ডিরেক্টরি পাসওয়ার্ডও নেই যা আপনি ফিশিংয়ের ঝুঁকিতে ফেলতে চান। একটি Passpoint প্রোফাইল নতুন টিকিট ছাড়াই পরবর্তী পরিদর্শনের সময় পুনরায় সংযুক্ত হতে পারে।
অব্যবস্থাপনাধীন ল্যাপটপ এবং ঠিকাদাররা PEAP-MSCHAPv2-এ থাকতে পারেন, তবে কেবল তখনই যদি প্রোফাইলটি সার্ভার ভ্যালিডেশন বাধ্য করে। আপনি যদি সেগুলোকে এনরোল বা রিনিউ করতে না পারেন, তবে EAP-TLS সেগুলোকে আটকে রাখবে। আপনি যদি সার্ভার চেক বাধ্য করতে না পারেন, তবে পাসওয়ার্ডের ঝুঁকিটি সুবিধার চেয়ে অনেক বেশি হয়ে দাঁড়ায় এবং তাদের কর্মী SSID-এ মোটেই থাকা উচিত নয়।
প্রিন্টার, টিভি, টিল, EPOS, CCTV, সেন্সর এবং ডোর কন্ট্রোলার একটি per-device PSK এবং তাদের নিজস্ব VLAN পায়। এগুলো সাধারণত সার্টিফিকেট সংরক্ষণ করতে পারে না। একটি শেয়ার করা PEAP পাসওয়ার্ড আবার শেয়ার্ড-কী সমস্যা ফিরিয়ে আনে। PCI DSS v4.0.1 Req 2.3.2 অনুযায়ী পাসওয়ার্ড জানা কেউ প্রতিষ্ঠান ছেড়ে গেলে ওয়্যারলেস কী পরিবর্তন করা প্রয়োজন, যা একটি শেয়ার্ড কী-এর ক্ষেত্রে অসম্ভব হয়ে পড়ে। এই ডিভাইসগুলোর জন্য xPSK-ই উপযুক্ত সমাধান। রুমের টিভি, থার্মোস্ট্যাট এবং টিলগুলো এমন কী-বাউন্ড VLAN-এ থাকা উচিত যা গেস্টরা কখনোই দেখতে পায় না।
একটি সাইটেই এটি প্রমাণ করুন
সেই সাইটে আগে থেকেই থাকা অ্যাক্সেস পয়েন্টগুলোতে আজকের নেটওয়ার্কের পাশাপাশি নতুন ডিজাইন সেটআপ করুন। ডেমো লগইনের বদলে টিকিট এবং অডিট প্রমাণের ভিত্তিতে এটি মূল্যায়ন করুন।
একটি প্রমানীকরণ লগ আবশ্যক যা প্রতিটি অনুমোদন এবং প্রত্যাখ্যানকে পরিচয়, ডিভাইস, MDM এনরোলমেন্ট স্ট্যাটাস, পদ্ধতি, অ্যাক্সেস পয়েন্ট, SSID, সাইট, VLAN, ভূমিকা, কারণ এবং সময় সহ রেকর্ড করে। একই লগ হলো ISO 27001 অ্যাক্সেস এবং লগিং নিয়ন্ত্রণ এবং PCI-DSS এর ৮ ও ১০ নম্বর প্রয়োজনীয়তাগুলির জন্য প্রমাণ সেট। MDM ছাড়া, প্রথমে PEAP প্রোফাইলগুলি সুরক্ষিত করুন এবং কেবল পরিচালিত জনগোষ্ঠীর জন্য সার্টিফিকেটের সময়সূচী নির্ধারণ করুন।
আমরা প্রতিটি প্রপার্টিতে তিনটি নেটওয়ার্ক হিসেবে এই বিভাজনটি চালাতে পারি। অতিথিরা পোর্টাল ব্যবহার করে, যার মধ্যে প্রপার্টিতে একটি বিদ্যমান থাকলে PMS রুম চেক অন্তর্ভুক্ত থাকে। কর্মীরা EAP-TLS বা Passpoint ব্যবহার করে। জিনিসপত্র প্রতি-ডিভাইস কী ব্যবহার করে। Cloud RADIUS আইডেন্টিটি অনুযায়ী প্রতিটি ডিভাইসকে সঠিক নেটওয়ার্ক এবং VLAN-এ পাঠায়, এবং এমন একজন ত্যাগকারীকে প্রত্যাখ্যান করে যার অ্যাকাউন্ট ডিজেবল করা আছে। একটি শেয়ার করা কর্মী পাসওয়ার্ড থেকে স্থানান্তরের পথটি আমাদের গাইড move multi-site staff WiFi onto 802.1X-এ বর্ণিত পথের মতোই।
আমি ম্যানেজড স্টাফ SSID এবং ক্যাশ রেজিস্টারের জন্য ডিভাইস-ভিত্তিক কি দিয়ে পাইলট শুরু করব, এবং এনরোলমেন্ট বাস্তবায়ন না হওয়া পর্যন্ত ঠিকাদারদের একটি যাচাইকৃত PEAP প্রোফাইলে রাখব। ডায়াগ্রামে সবার জন্য একটি একক পদ্ধতি দেখতে সুন্দর লাগে, কিন্তু কাজের ক্ষেত্রে তা তিনভাবে ব্যর্থ হয়।
Purple Access আপনার ইতিমধ্যে মালিকানাধীন অ্যাক্সেস পয়েন্টগুলিতে থাকা জিনিসগুলির জন্য সার্টিফিকেট-ভিত্তিক কর্মী WiFi এবং ডিভাইস-প্রতি কী পরিচালনা করে, তাই eap tls vs peap পুরো এস্টেট-জুড়ে জুয়া খেলার পরিবর্তে একটি জনসংখ্যাগত পছন্দে পরিণত হয়। আপনি একটি একক সাইটে ওপেন, সুরক্ষিত এবং xPSK প্রমাণ করতে পারেন, তারপরে একটি বৃহত্তর রোলআউটের আগে টিকিট এবং প্রমাণীকরণ লগ বিচার করতে পারেন। আপনার কর্মী, অতিথি এবং ডিভাইস নেটওয়ার্কগুলি ম্যাপ করতে Purple Access-এ যান।
