EAP-TLS বনাম EAP-TTLS: আপনার কোন শংসাপত্র-ভিত্তিক WiFi প্রোটোকলটি বেছে নেওয়া উচিত?
এই নির্দেশিকাটি IEEE 802.1X এর অধীনে এন্টারপ্রাইজ WiFi প্রমাণীকরণের জন্য EAP-TLS এবং EAP-TTLS এর একটি নির্দিষ্ট মুখোমুখি তুলনা প্রদান করে। এটি পারস্পরিক শংসাপত্র প্রমাণীকরণ এবং কেবল সার্ভার-শংসাপত্র টানেলিংয়ের মধ্যে কাঠামোগত পার্থক্য ব্যাখ্যা করে, এবং আইটি ম্যানেজার, নেটওয়ার্ক স্থপতি এবং CISO দের ডিভাইস পরিচালন ক্ষমতা এবং সম্মতি প্রয়োজনীয়তার উপর ভিত্তি করে একটি স্পষ্ট সিদ্ধান্ত নেওয়ার কাঠামো দেয়। Purple কর্মী WiFi এর জন্য EAP-TLS এবং EAP-TTLS উভয় প্রমাণীকরণ পথকেই সমর্থন করে, এবং এই নির্দেশিকাটি সংস্থাগুলিকে যে কোনও একটি পদ্ধতি গ্রহণ করার আগে অবকাঠামোগত আপসগুলি বুঝতে সহায়তা করে।
Video overview
এই গাইডটি শুনুন
পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
আমাদের মূল সিরিজের অংশ: এন্টারপ্রাইজ WiFi সুরক্ষা নির্দেশিকা →
EAP-TLS vs EAP-TTLS decision and PKI sizing tool
Evaluate mutual certificate requirements, tunneled credential protocols, OS supplicant compatibility, and RADIUS directory integration for enterprise 802.1X WiFi.
EAP-TLS (Mutual Certificate-Based 802.1X)
Deploy mutual EAP-TLS with automated SCEP or ACME certificate enrolment via MDM.
Recommended implementation milestones
- Deploy trusted root and intermediate CA certificates via MDM profile
- Configure SCEP/NDES profile to issue client certificates into hardware TPM or Secure Enclave
- Configure Cloud RADIUS server certificate validation with Subject Alternative Name (SAN) mapping
Plan your enterprise 802.1X & Cloud RADIUS deployment with Purple
Whether migrating from legacy credentials to EAP-TTLS or rolling out passwordless EAP-TLS with Cloud PKI, Purple provides secure 802.1X Staff WiFi, dynamic VLAN segmentation, and enterprise access control across multi-vendor networks.
এক্সিকিউটিভ সামারি
আপনার 802.1X ডেপ্লয়মেন্টের জন্য সঠিক EAP পদ্ধতি নির্বাচন করা নির্ধারণ করে যে আপনার এন্টারপ্রাইজ WiFi কি সত্যিই নিরাপদ নাকি কেবল কাগজ-কলমে সম্মতিপূর্ণ। EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), যা RFC 5216 এ সংজ্ঞায়িত, এর জন্য মিউচুয়াল সার্টিফিকেট অথেন্টিকেশন প্রয়োজন: নেটওয়ার্ক অ্যাক্সেস দেওয়ার আগে ক্লায়েন্ট ডিভাইস এবং RADIUS সার্ভার উভয়কেই বৈধ X.509 সার্টিফিকেট উপস্থাপন করতে হয়। কোনো অবস্থাতেই পাসওয়ার্ড আদান-প্রদান করা হয় না। EAP-TTLS (Tunneled Transport Layer Security), যা RFC 5281 এ সংজ্ঞায়িত, একটি এনক্রিপ্টেড TLS টানেল স্থাপন করতে কেবল একটি সার্ভার-সাইড সার্টিফিকেটের প্রয়োজন হয়, যার ভেতরে ক্লায়েন্ট বিদ্যমান ডিরেক্টরি ক্রেডেনশিয়াল ব্যবহার করে অথেন্টিকেট করে।
রিটেল চেইন, হসপিটালিটি ভেন্যু এবং পাবলিক সেক্টরের প্রতিষ্ঠানজুড়ে অবকাঠামো পরিচালনাকারী CTO এবং নেটওয়ার্ক আর্কিটেক্টদের জন্য, এই সিদ্ধান্তটি একটি মাত্র প্রশ্নে এসে দাঁড়ায়: আপনি কি ডিভাইসগুলো পরিচালনা করেন? আপনি যদি MDM এর মাধ্যমে ডিভাইস ফ্লিট নিয়ন্ত্রণ করেন, তবে EAP-TLS হলো চূড়ান্ত পছন্দ। আপনি যদি একটি বৈচিত্র্যময় BYOD পরিবেশকে সমর্থন করেন বা আপনার একটি শক্তিশালী পাবলিক কি ইনফ্রাস্ট্রাকচার (PKI) এর অভাব থাকে, তবে EAP-TTLS একটি বাস্তবসম্মত, অত্যন্ত নিরাপদ বিকল্প প্রদান করে। Purple ৮০,০০০+ এরও বেশি লাইভ ভেন্যুজুড়ে Staff WiFi এর জন্য উভয় অথেন্টিকেশন পাথ সমর্থন করে।
টেকনিক্যাল ডিপ-ডাইভ
EAP-TLS এর আর্কিটেকচার
EAP-TLS IEEE 802.1X পোর্ট-ভিত্তিক অ্যাক্সেস কন্ট্রোল ফ্রেমওয়ার্কের মধ্যে একটি মিউচুয়াল অথেন্টিকেশন মডেলে কাজ করে। প্রতিটি অথেন্টিকেশন আদান-প্রদানে তিনটি মূল উপাদান জড়িত থাকে: সাপ্লিক্যান্ট (ক্লায়েন্ট ডিভাইস), অথেন্টিকেটর (ওয়্যারলেস অ্যাক্সেস পয়েন্ট), এবং অথেন্টিকেশন সার্ভার (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 (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 (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 টানেলটি রোগ অ্যাক্সেস পয়েন্টের বিরুদ্ধে কোনো সুরক্ষা প্রদান করে না।
আপনার নির্দিষ্ট সেটআপ নিয়ে কোনো প্রশ্ন আছে?
আমাদের টিম ৮০,০০০ ভেন্যুতে ভেন্যু অপারেটর, IT ম্যানেজার এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের সাথে কাজ করে। একটি ২০ মিনিটের কল বুক করুন এবং আপনার মতো অন্যরা কীভাবে এর সমাধান করেছেন তা আমরা আপনাকে দেখাব।
সর্বোত্তম অনুশীলন (Best Practices)
প্রতিটি ক্লায়েন্টে সার্ভার সার্টিফিকেট যাচাইকরণ বাধ্যতামূলক করুন
EAP-TLS এবং EAP-TTLS উভয়ের জন্যই সবচেয়ে গুরুত্বপূর্ণ কনফিগারেশন পদক্ষেপ হল ক্লায়েন্ট ডিভাইসে সার্ভার সার্টিফিকেট যাচাইকরণ বাধ্যতামূলক করা। যদি একটি ডিভাইস একটি নির্দিষ্ট বিশ্বস্ত CA-এর বিপরীতে RADIUS সার্ভারের সার্টিফিকেট যাচাই না করে, তবে এটি যেকোনো সার্টিফিকেট উপস্থাপনকারী যেকোনো সার্ভারের সাথে সংযুক্ত হবে - যার মধ্যে একটি অননুমোদিত অ্যাক্সেস পয়েন্টও রয়েছে। আপনার MDM-নিয়োজিত WiFi প্রোফাইলগুলিতে সর্বদা বিশ্বস্ত CA এবং প্রত্যাশিত সার্ভারের নাম উল্লেখ করুন। এই একক কনফিগারেশন চেকটি সবচেয়ে কার্যকর নিরাপত্তা উন্নতি যা আপনি আজই বাস্তবায়ন করতে পারেন।
সার্টিফিকেট লাইফসাইকেল ম্যানেজমেন্ট স্বয়ংক্রিয় করুন
সার্টিফিকেটের মেয়াদ শেষ হয়। আপনার যদি একটি স্বয়ংক্রিয় পুনর্নবীকরণ প্রক্রিয়া না থাকে, তবে সার্টিফিকেটগুলির মেয়াদ একসাথে শেষ হয়ে গেলে আপনি ব্যাপক প্রমাণীকরণ ব্যর্থতার সম্মুখীন হবেন। পুনর্নবীকরণ স্বয়ংক্রিয় করতে SCEP বা EST ব্যবহার করুন এবং মেয়াদের শেষ তারিখের অনেক আগে থেকেই মনিটরিং অ্যালার্ট কনফিগার করুন। যদি একটি ডিভাইস হারিয়ে যায় বা কোনো কর্মচারী চলে যান, তবে অবিলম্বে সার্টিফিকেটটি প্রত্যাহার করুন। রিয়েল-টাইম যাচাইকরণের জন্য CRL চেক করতে বা OCSP ব্যবহার করতে আপনার RADIUS সার্ভার কনফিগার করুন।
প্রমাণীকরণ পদ্ধতি দ্বারা আপনার নেটওয়ার্ক ভাগ করুন
বৃহৎ বা বিতরণ করা পরিবেশে, আলাদা SSIDs-এ উভয় প্রোটোকল চালানোর কথা বিবেচনা করুন। কর্পোরেট পরিচালিত ডিভাইসগুলি একটি ডেডিকেটেড স্টাফ WiFi SSID-এ EAP-TLS-এর মাধ্যমে প্রমাণীকরণ করে। ঠিকাদার এবং BYOD ডিভাইসগুলি উপযুক্ত VLAN বিভাজন সহ একটি পৃথক SSID-এ EAP-TTLS-এর মাধ্যমে প্রমাণীকরণ করে। এই প্যাটার্নটি Premier Inn এবং Whitbread-এর মতো আতিথেয়তা গ্রুপগুলিতে সাধারণ, যেখানে কর্মীদের ডিভাইসগুলি পরিচালনা করা হয় এবং সার্টিফিকেট প্রদান করা হয়, অন্যদিকে গেস্ট অবকাঠামো একটি পৃথক প্রমাণীকরণ পথ ব্যবহার করে। SSID আর্কিটেকচার সম্পর্কে আরও বিশদ বিবরণের জন্য, আমাদের গাইড Three SSIDs to rule them all: the WiFi design for guest, staff and IoT দেখুন।
সমস্ত অবকাঠামো জুড়ে সময় সিঙ্ক্রোনাইজ করুন
সার্টিফিকেট যাচাইকরণ সঠিক সিস্টেম টাইমের ওপর নির্ভর করে। ক্লায়েন্ট ডিভাইস বা RADIUS সার্ভারে সময়ের অমিল 'এখনও বৈধ নয়' বা 'মেয়াদ উত্তীর্ণ' সার্টিফিকেট ত্রুটি তৈরি করে যা নির্ণয় করা কঠিন। সমস্ত অবকাঠামো উপাদান নির্ভরযোগ্য NTP সার্ভারের সাথে সিঙ্ক্রোনাইজ করা হয়েছে তা নিশ্চিত করুন।
সমস্যা সমাধান এবং ঝুঁকি হ্রাস
অজানা CA ত্রুটি (Unknown CA Errors)
যদি RADIUS লগগুলি 'unknown CA' দেখায়, তবে ক্লায়েন্ট ডিভাইসটি RADIUS সার্ভারের সার্টিফিকেট প্রদানকারী CA-কে বিশ্বাস করে না। আপনার MDM প্রোফাইলে রুট CA সার্টিফিকেট অন্তর্ভুক্ত রয়েছে এবং সাপ্লিক্যান্ট এটিকে বিশ্বাস করার জন্য কনফিগার করা হয়েছে তা যাচাই করুন। একটি CA রোটেশন বা সার্টিফিকেট পুনর্নবীকরণের পরে, সমস্ত ডিভাইসে আপডেট করা CA বান্ডিলটি পুনরায় পুশ করুন।
EAP পদ্ধতি অমিল (EAP Method Mismatch)
যদি ডিভাইসগুলি অ্যাক্সেস পয়েন্টের সাথে সংযুক্ত হয় কিন্তু প্রমাণীকরণ ব্যর্থ হয়, তবে ক্লায়েন্টে কনফিগার করা EAP পদ্ধতিটি RADIUS সার্ভার দ্বারা গৃহীত পদ্ধতির সাথে মিলছে কিনা তা পরীক্ষা করুন। EAP-TLS-এর জন্য সেট করা একটি ডিভাইস প্রোফাইল কেবল PEAP-এর জন্য কনফিগার করা একটি RADIUS সার্ভারে ব্যর্থ হবে।
মেয়াদোত্তীর্ণ সার্টিফিকেটের কারণে ব্যাপক ব্যর্থতা
যদি বিপুল সংখ্যক ডিভাইস একসাথে প্রমাণীকরণ করতে ব্যর্থ হয়, তবে প্রথমে সার্টিফিকেট মেয়াদের তারিখগুলো পরীক্ষা করুন। EAP-TLS ডেপ্লয়মেন্টে গণহারে 802.1X ব্যর্থতার সবচেয়ে সাধারণ কারণ এটিই। এমন একটি মনিটরিং সিস্টেম চালু করুন যা মেয়াদ শেষ হওয়ার ৬০ দিন, ৩০ দিন এবং সাত দিন আগে সতর্কতা পাঠায়।
RADIUS ক্লায়েন্ট ভুল কনফিগারেশন
প্রতিটি অ্যাক্সেস পয়েন্ট বা ওয়্যারলেস কন্ট্রোলারকে সঠিক IP অ্যাড্রেস এবং শেয়ার্ড সিক্রেট সহ একটি RADIUS ক্লায়েন্ট হিসেবে সংজ্ঞায়িত করতে হবে। অমিল থাকলে প্রমাণীকরণে টাইমআউট ঘটে যা প্রায়শই ভুলভাবে EAP পদ্ধতির কারণে হয়েছে বলে মনে করা হয়। প্রথম দিন থেকেই বিস্তারিত RADIUS লগিং সক্ষম করুন। আরও ওয়াইফাই সমস্যার সমাধানের নির্দেশনার জন্য, আমাদের এই নির্দেশিকাটি দেখুন 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 ১.২ বা তার উচ্চতর সংস্করণ দাবি করে এবং 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)
আইটি বিভাগগুলি কর্তৃক কর্মীদের মোবাইল ডিভাইস এবং ল্যাপটপগুলি নিরীক্ষণ, পরিচালনা এবং সুরক্ষিত করতে ব্যবহৃত সফ্টওয়্যার। MDM প্ল্যাটফর্ম যেমন Microsoft Intune এবং Jamf তালিকাভুক্ত ডিভাইসগুলিতে সার্টিফিকেট এবং 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 সার্টিফিকেট বোঝায়।
Inner authentication method
EAP-TTLS দ্বারা প্রতিষ্ঠিত এনক্রিপ্ট করা TLS টানেলের ভেতরে ব্যবহৃত সেকেন্ডারি অথেন্টিকেশন প্রোটোকল। সাধারণ অভ্যন্তরীণ পদ্ধতির মধ্যে রয়েছে PAP (Password Authentication Protocol), 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 সক্ষম করুন। ধাপ ৫: Intune এর মাধ্যমে SSID, প্রমাণীকরণ পদ্ধতি হিসাবে EAP-TLS, বিশ্বস্ত রুট CA এবং প্রত্যাশিত RADIUS সার্ভারের নাম নির্দিষ্ট করে একটি WiFi প্রোফাইল পুশ করুন। ধাপ ৬: সমস্ত ৪০০টি সাইটে চালু করার আগে ১০টি ডিভাইসের একটি পাইলট গ্রুপের সাথে পরীক্ষা করুন। ধাপ ৭: মেয়াদ শেষ হওয়ার ৬০, ৩০ এবং সাত দিন আগে সতর্কতা সহ একটি শংসাপত্রের মেয়াদ শেষ হওয়ার পর্যবেক্ষণ প্রক্রিয়া স্থাপন করুন।
একটি বড় বিশ্ববিদ্যালয় ক্যাম্পাসে ব্যক্তিগত ল্যাপটপ, স্মার্টফোন এবং ট্যাবলেটের (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 প্রোফাইল কনফিগার করুন।
অনুশীলনী প্রশ্নসমূহ
Q1. আপনি ৫০টি অফিস লোকেশন জুড়ে ৫,০০০টি কর্পোরেট ল্যাপটপের জন্য EAP-TLS ডেপ্লয় করছেন। Microsoft Intune-এর মাধ্যমে WiFi প্রোফাইল পুশ করার পর, ডিভাইসগুলো কানেক্ট হতে ব্যর্থ হচ্ছে। RADIUS সার্ভার লগ প্রতিটি ব্যর্থ অথেন্টিকেশন প্রচেষ্টার জন্য 'Unknown CA' দেখাচ্ছে। এর সম্ভাব্য কারণ কী এবং কীভাবে আপনি এটি সমাধান করবেন?
ইঙ্গিত: ক্লায়েন্ট সাইডের সার্টিফিকেট ভ্যালিডেশন চেইনের কথা এবং শুধুমাত্র EAP মেথড সেটিংসের বাইরে MDM প্রোফাইলে কী অন্তর্ভুক্ত করা আবশ্যক তা বিবেচনা করুন।
মডেল উত্তর দেখুন
ক্লায়েন্ট ডিভাইসগুলো সেই ইন্টারনাল সার্টিফিকেট অথরিটিকে ট্রাস্ট করার জন্য কনফিগার করা নেই যা RADIUS সার্ভারের সার্টিফিকেটটি ইস্যু করেছিল। MDM WiFi প্রোফাইলে অবশ্যই রুট CA সার্টিফিকেট (এবং যেকোনো ইন্টারমিডিয়েট CA সার্টিফিকেট) অন্তর্ভুক্ত থাকতে হবে এবং সার্ভার ভ্যালিডেশনের জন্য সেগুলোকে ট্রাস্ট করতে সাপ্লিক্যান্টকে কনফিগার করতে হবে। এটি ছাড়া, ক্লায়েন্ট RADIUS সার্ভারের সার্টিফিকেট প্রত্যাখ্যান করে এবং হ্যান্ডশেক বাতিল করে। সমাধান: 'Root certificate for server validation' সেটিংসের অধীনে ট্রাস্টেড রুট CA সার্টিফিকেট অন্তর্ভুক্ত করতে Intune WiFi প্রোফাইলটি আপডেট করুন এবং সমস্ত ডিভাইসে প্রোফাইলটি পুনরায় পুশ করুন।
Q2. আপনার প্রতিষ্ঠান একটি মিশ্র BYOD এনভায়রনমেন্টের জন্য EAP-TTLS ডেপ্লয় করেছে। একটি সিকিউরিটি রিভিউ চলাকালীন, আপনার পেনিট্রেশন টেস্টিং টিম প্রমাণ করেছে যে তারা একটি সেলফ-স্বাক্ষরিত সার্টিফিকেট সহ একটি রোগ অ্যাক্সেস পয়েন্ট তৈরি করে ব্যবহারকারীর ক্রেডেনশিয়াল ক্যাপচার করতে পারে। EAP-TLS-এ মাইগ্রেট না করে কীভাবে আপনি এই দুর্বলতা দূর করবেন?
ইঙ্গিত: অভ্যন্তরীণ অথেন্টিকেশনের আগে কী ঘটে এবং ক্লায়েন্ট সাইডের কোন কনফিগারেশন একটি আনট্রাস্টেড সার্ভারের সাথে TLS টানেল তৈরি হতে বাধা দেয় তা চিন্তা করুন।
মডেল উত্তর দেখুন
দুর্বলতাটি বিদ্যমান থাকার কারণ হলো ক্লায়েন্ট ডিভাইসগুলো RADIUS সার্ভারের সার্টিফিকেট ভ্যালিডেট করার জন্য কনফিগার করা নেই। প্রতিকার: সার্ভার সার্টিফিকেট ভ্যালিডেশন বাধ্যতামূলক করতে সমস্ত WiFi প্রোফাইল আপডেট করুন (ম্যানেজড ডিভাইসের জন্য MDM-এর মাধ্যমে এবং BYOD-এর জন্য একটি নতুন অনবোর্ডিং গাইডের মাধ্যমে)। প্রোফাইলে ট্রাস্টেড CA এবং প্রত্যাশিত RADIUS সার্ভারের নাম নির্দিষ্ট করে দিন। এভাবে কনফিগার করা ক্লায়েন্টগুলো এমন যেকোনো সার্ভারের সাথে TLS টানেল তৈরি করতে অস্বীকার করবে যা নির্দিষ্ট ট্রাস্টেড CA দ্বারা স্বাক্ষরিত সার্টিফিকেট দেখাতে পারবে না, যা রোগ অ্যাক্সেস পয়েন্টের আক্রমণের ঝুঁকি দূর করবে।
Q3. একটি হাসপাতালের আইটি ডিরেক্টর তাদের মেডিকেল 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-এই সার্ভার সার্টিফিকেট ভ্যালিডেশন প্রয়োগ করা আবশ্যক। এই আর্কিটেকচারটি স্টাফদের সর্বোচ্চ নিরাপত্তা প্রদান করে এবং ঠিকাদারদের একটি ব্যবহারিক অথেন্টিকেশন পদ্ধতি দেয়, এবং নেটওয়ার্ক সেগমেন্টেশন নিশ্চিত করে যে কোনো আপোসকৃত ঠিকাদারের ক্রেডেনশিয়াল যেন হোটেলের অভ্যন্তরীণ ম্যানেজমেন্ট সিস্টেমে পৌঁছাতে না পারে।
প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী
What is the primary technical difference between EAP-TLS and EAP-TTLS?
EAP-TLS (RFC 5216) requires mutual authentication where both the RADIUS server and client device validate each other using X.509 digital certificates. EAP-TTLS (RFC 5281) requires a digital certificate only on the RADIUS server to build an encrypted TLS tunnel, through which the client authenticates using inner credentials such as PAP, CHAP, or MSCHAPv2.
Does EAP-TTLS require client certificates?
No. EAP-TTLS eliminates the need to issue or manage client-side certificates, requiring only a trusted server certificate on the RADIUS server. This simplifies onboarding for unmanaged BYOD devices while securing credentials inside the encrypted outer TLS tunnel.
Which protocol is more secure against rogue access points and evil twin attacks?
EAP-TLS is cryptographically immune to evil twin attacks because authentication relies on mutual private key verification. EAP-TTLS protects credentials inside the TLS tunnel, but requires client devices to strictly validate the RADIUS server root CA certificate and domain name to prevent rogue access points from intercepting inner credentials.
Why do organizations choose EAP-TTLS over EAP-TLS?
Organizations choose EAP-TTLS when they do not operate a mobile device management (MDM) or public key infrastructure (PKI) capable of enrolling client certificates on every device, or when authenticating against directory services and multi-factor authentication tokens using inner PAP without SCEP or EST overhead.
Do Windows, macOS, iOS, and Android support EAP-TTLS natively?
Apple macOS, iOS, and Android provide native out-of-the-box supplicant support for EAP-TTLS with inner PAP and MSCHAPv2. Windows 10 and 11 also support EAP-TTLS natively, though configuring inner PAP typically requires an XML network profile or automated onboarding tool.
এই সিরিজে পড়া চালিয়ে যান
iOS এবং macOS 802.1X ট্রাবলশুটিং: Intune, Jamf এবং Entra ID-এর জন্য একটি ডিপ্লয়মেন্ট চেকলিস্ট
iPhones, iPads এবং Macs কেন Intune বা Jamf Pro-তে 802.1X ব্যর্থ হয় তা সনাক্ত করতে এই চেকলিস্টটি ব্যবহার করুন। প্রতিটি ব্যর্থতার পিছনে চারটি কারণের যেকোনো একটি থাকে: সার্ভার ট্রাস্ট, আইডেন্টিটি সার্টিফিকেট, macOS মোড বা Entra ID গ্রুপ স্কোপিং। আপনি eapolclient এবং RADIUS লগ থেকে এর কারণ নিশ্চিত করবেন, সমাধান প্রয়োগ করবেন এবং ভবিষ্যতের সার্টিফিকেট রোটেশন পরিচালনা করবেন।
Intune WiFi প্রোফাইল সার্ভার ট্রাস্ট: Microsoft Entra ID -এর জন্য সার্টিফিকেট সার্ভার নাম এবং রুট CA চেকলিস্ট
আপনি একটি Intune WiFi প্রোফাইলের সার্ভার ভ্যালিডেশন অংশটি কনফিগার করতে পারবেন যাতে Windows, Apple এবং Android -এ EAP-TLS এবং PEAP কানেক্ট হয়। আপনি RADIUS সার্টিফিকেটের সাথে সার্টিফিকেট সার্ভারের নাম মেলাতে পারবেন, সঠিক রুট CA ডেপ্লয় করতে পারবেন, Microsoft Entra ID গ্রুপ অ্যাসাইনমেন্ট অ্যালাইন করতে পারবেন এবং সার্টিফিকেট রিনিউয়াল কানেকশন বন্ধ করার আগেই সেটিকে প্রস্তুত করতে পারবেন।
Android 802.1X এবং EAP-TLS ট্রাবলশুটিং: Intune এবং Entra ID-এর জন্য একটি ডিপ্লয়মেন্ট চেকলিস্ট
আপনি সহজেই সনাক্ত করতে পারবেন কেন ম্যানেজড Android ফোনগুলো আপনার স্টাফ SSID-এ EAP-TLS সংযোগ করতে ব্যর্থ হচ্ছে এবং তা Intune-এ ঠিক করতে পারবেন। প্রতিটি লক্ষণকে চারটি সাধারণ কারণের সাথে মেলান - অনুপস্থিত CA বা ডোমেন, ভুল প্রোফাইলে থাকা ক্লায়েন্ট সার্টিফিকেট, একটি অমিল RADIUS সার্ভার নামের মান, অথবা একটি অপৌঁছানো ট্রাস্টেড রুট। তারপর একটি রোলআউট চেকলিস্ট প্রয়োগ করুন যা বারবার বিভ্রাট হওয়া বন্ধ করে।
আপনার নির্দিষ্ট সেটআপ নিয়ে কোনো প্রশ্ন আছে?
আমাদের টিম ৮০,০০০ ভেন্যুতে ভেন্যু অপারেটর, IT ম্যানেজার এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের সাথে কাজ করে। একটি ২০ মিনিটের কল বুক করুন এবং আপনার মতো অন্যরা কীভাবে এর সমাধান করেছেন তা আমরা আপনাকে দেখাব।