কীভাবে স্বয়ংক্রিয় WiFi সার্টিফিকেট এনরোলমেন্টের জন্য SCEP বাস্তবায়ন করবেন
এই নির্দেশিকাটি এন্টারপ্রাইজ ভেন্যু জুড়ে স্বয়ংক্রিয় WiFi সার্টিফিকেট এনরোলমেন্টের জন্য কীভাবে SCEP (সিম্পল সার্টিফিকেট এনরোলমেন্ট প্রোটোকল) বাস্তবায়ন করতে হয় তা ব্যাখ্যা করে। এটি PKI ডিজাইন এবং MDM ইন্টিগ্রেশন থেকে শুরু করে বাধ্যতামূলক তিন-ধাপের ডেপ্লয়মেন্ট সিকোয়েন্স পর্যন্ত সম্পূর্ণ আর্কিটেকচারাল ব্লুপ্রিন্ট কভার করে - এবং IT ম্যানেজার ও নেটওয়ার্ক আর্কিটেক্টদের দেখায় কীভাবে শেয়ার্ড ক্রেডেনশিয়াল দূর করতে হয়, সার্টিফিকেট লাইফসাইকেল ম্যানেজমেন্ট স্বয়ংক্রিয় করতে হয় এবং স্কেলে PCI DSS এবং GDPR প্রয়োজনীয়তা পূরণ করতে হয়।
এই গাইডটি শুনুন
পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
কার্যনির্বাহী সারসংক্ষেপ (Executive summary)
হোটেল, রিটেল এস্টেট, স্টেডিয়াম এবং কনফারেন্স সেন্টার জুড়ে Guest WiFi পরিচালনাকারী ভেন্যু অপারেটরদের জন্য, কর্মীদের নেটওয়ার্ক অ্যাক্সেসের জন্য প্রি-শেয়ার্ড কী বা বেসিক Captive Portal-এর উপর নির্ভর করা একটি নিরাপত্তা ঝুঁকি। আধুনিক নেটওয়ার্ক আর্কিটেকচারের জন্য EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) ব্যবহার করে 802.1X প্রমাণীকরণ প্রয়োজন, যা নেটওয়ার্ক স্পর্শ করার আগেই প্রতিটি ডিভাইস ক্রিপ্টোগ্রাফিকভাবে যাচাই করা নিশ্চিত করে। মূল চ্যালেঞ্জটি হলো বিতরণ: আপনার হেল্পডেস্ককে ব্যস্ত না রেখে কীভাবে হাজার হাজার Windows, iOS এবং Android ডিভাইসে অনন্য ক্লায়েন্ট সার্টিফিকেট স্থাপন করবেন?
এর উত্তর হলো SCEP - Simple Certificate Enrollment Protocol। ২০২০ সালে IETF দ্বারা RFC 8894 হিসেবে আনুষ্ঠানিকভাবে স্বীকৃত, SCEP পরিচালিত ডিভাইস ফ্লিট জুড়ে সার্টিফিকেট তালিকাভুক্তি স্বয়ংক্রিয় করে। যখন Microsoft Intune বা Jamf-এর মতো একটি MDM প্ল্যাটফর্মের সাথে একীভূত করা হয়, তখন SCEP জিরো-টাচ সার্টিফিকেট প্রভিশনিং প্রদান করে: ডিভাইসগুলো কোনো IT হস্তক্ষেপ ছাড়াই নিজস্ব সার্টিফিকেট অনুরোধ করে, গ্রহণ করে এবং নবায়ন করে। প্রাইভেট কী-টি ডিভাইসে স্থানীয়ভাবে তৈরি হয় এবং কখনই নেটওয়ার্কের মাধ্যমে স্থানান্তরিত হয় না - যা PKCS-ভিত্তিক বিতরণের চেয়ে একটি মৌলিক নিরাপত্তা সুবিধা।
এই নির্দেশিকাটি সম্পূর্ণ SCEP বাস্তবায়ন কর্মপ্রবাহের বিবরণ দেয়: PKI আর্কিটেকচার, NDES গেটওয়ে কনফিগারেশন, বাধ্যতামূলক তিন-ধাপের MDM স্থাপনা ক্রম এবং অপারেশনাল নিয়ন্ত্রণ - বিশেষ করে CRL চেকিং এবং গ্রুপ টার্গেটিং - যা নির্ধারণ করে যে একটি রোলআউট সফল হবে নাকি স্থবির হবে। দুটি বাস্তব-জগতের দৃশ্যপট আতিথেয়তা এবং খুচরা পরিবেশে এই পদ্ধতির চিত্র তুলে ধরে। Purple ৮০,০০০+ লাইভ ভেন্যু এবং ৩৫০ মিলিয়ন অনন্য ব্যবহারকারী জুড়ে কাজ করে; এখানে বর্ণিত প্যাটার্নগুলো সেই স্কেলে কী কাজ করে তা প্রতিফলিত করে।
প্রযুক্তিগত গভীর বিশ্লেষণ (Technical deep-dive)
SCEP আসলে কী করে
SCEP আপনার MDM প্ল্যাটফর্ম এবং আপনার Certificate Authority (CA)-এর মধ্যে অবস্থান করে। এটি ডোমেন-যুক্ত শংসাপত্র বা ম্যানুয়াল অ্যাডমিনিস্ট্রেটর সম্পৃক্ততা ছাড়াই ডিভাইসগুলোর জন্য X.509 সার্টিফিকেট অনুরোধ, গ্রহণ এবং নবায়ন করার জন্য একটি মানসম্মত HTTP-ভিত্তিক প্রক্রিয়া প্রদান করে। প্রোটোকলটি মূলত ২০০০-এর দশকের শুরুতে তৈরি করা হয়েছিল এবং IETF আনুষ্ঠানিকভাবে এটিকে RFC 8894 হিসেবে প্রকাশ করার আগে এন্টারপ্রাইজ MDM পরিবেশে ব্যাপক গ্রহণযোগ্যতা লাভ করেছিল।
ছয়-ধাপের এনরোলমেন্ট ফ্লোটি নিম্নরূপ কাজ করে। প্রথমত, ম্যানেজড ডিভাইসটি তার MDM প্রোফাইলে আগে থেকে কনফিগার করা SCEP গেটওয়ে URL-এর সাথে সংযুক্ত হয়। দ্বিতীয়ত, ডিভাইসটি স্থানীয়ভাবে একটি প্রাইভেট/পাবলিক কী পেয়ার তৈরি করে এবং একটি সার্টিফিকেট সাইনিং রিকোয়েস্ট (CSR) তৈরি করে। তৃতীয়ত, SCEP গেটওয়ে MDM পলিসিতে এমবেড করা একটি চ্যালেঞ্জ পাসওয়ার্ড বা OTP ব্যবহার করে ডিভাইসের অথরাইজেশন যাচাই করে। চতুর্থত, গেটওয়ে যাচাইকৃত CSR-টি CA-তে ফরোয়ার্ড করে। পঞ্চমত, CA সার্টিফিকেটটি সাইন করে এবং গেটওয়েতে ফেরত পাঠায়। ষষ্ঠত, গেটওয়ে সাইন করা সার্টিফিকেটটি ডিভাইসে পৌঁছে দেয়। ভবিষ্যতের রিনিউয়ালগুলো একই স্বয়ংক্রিয় পথ অনুসরণ করে - ডিভাইসটি কোনো ব্যবহারকারী বা অ্যাডমিনিস্ট্রেটরের হস্তক্ষেপ ছাড়াই মেয়াদ শেষ হওয়ার আগে পুনরায় এনরোল করে।
SCEP বনাম PKCS: যে সিদ্ধান্তটি গুরুত্বপূর্ণ
Microsoft Intune এবং বেশিরভাগ MDM প্ল্যাটফর্ম দুটি সার্টিফিকেট ডেলিভারি মেকানিজম সমর্থন করে: SCEP এবং PKCS। এই পার্থক্যটি আর্কিটেকচারাল, বাহ্যিক নয়।
SCEP-এর ক্ষেত্রে, প্রাইভেট কী-টি ডিভাইসে তৈরি হয় এবং সেখানেই থাকে। CA এটি কখনোই দেখতে পায় না। ডিভাইসের TPM (Windows-এ) বা সিকিউর এনক্লেভ (iOS/macOS-এ) হার্ডওয়্যার স্তরে কী-টিকে সুরক্ষিত রাখে। PKCS-এর ক্ষেত্রে, CA সেন্ট্রালভাবে কী পেয়ার তৈরি করে এবং নেটওয়ার্কের মাধ্যমে ডিভাইসে প্রেরণ করে। CA একটি কপি নিজের কাছে রেখে দেয়, যা কী এসক্রো (key escrow) সক্ষম করে - এটি S/MIME ইমেল এনক্রিপশনের জন্য দরকারী হলেও নেটওয়ার্ক অথেনটিকেশনের জন্য অপ্রয়োজনীয় ঝুঁকি তৈরি করে।
802.1X WiFi অথেনটিকেশনের জন্য, SCEP ব্যবহার করুন। প্রাইভেট কী কখনোই ডিভাইস থেকে বের হয় না। এটাই নিয়ম।
| মানদণ্ড | SCEP | PKCS |
|---|---|---|
| প্রাইভেট কী যেখানে তৈরি হয় | ডিভাইস | CA (সেন্ট্রালভাবে) |
| নেটওয়ার্কের মাধ্যমে প্রাইভেট কী প্রেরিত হয় | কখনোই নয় | হ্যাঁ |
| TPM / সিকিউর এনক্লেভ সমর্থন করে | হ্যাঁ | না |
| WiFi অথেনটিকেশনের জন্য প্রস্তাবিত | হ্যাঁ | না |
| ইমেল এনক্রিপশনের জন্য প্রস্তাবিত (S/MIME) | না | হ্যাঁ |
| কী এসক্রো সম্ভব | না | হ্যাঁ |
802.1X এবং EAP-TLS: অথেনটিকেশন ফ্রেমওয়ার্ক
IEEE 802.1X হলো পোর্ট-ভিত্তিক নেটওয়ার্ক অ্যাক্সেস কন্ট্রোল স্ট্যান্ডার্ড যা এন্টারপ্রাইজ WiFi সিকিউরিটির ভিত্তি। এটি তিনটি ভূমিকা নির্ধারণ করে: সাপ্লিক্যান্ট (ক্লায়েন্ট ডিভাইস), অথেনটিকেটর (অ্যাক্সেস পয়েন্ট - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, বা Fortinet), এবং অথেনটিকেশন সার্ভার (একটি RADIUS সার্ভার যেমন Microsoft NPS, FreeRADIUS, বা Cisco ISE)।
802.1X-এর জন্য EAP-TLS হলো সবচেয়ে নিরাপদ EAP পদ্ধতি। উভয় পক্ষই সার্টিফিকেট প্রদর্শন করে: RADIUS সার্ভার ক্লায়েন্টের কাছে তার সার্টিফিকেট প্রদর্শন করে এবং ক্লায়েন্ট RADIUS সার্ভারের কাছে তার SCEP-প্রভিশনড সার্টিফিকেট প্রদর্শন করে। বিশ্বস্ত CA অনুক্রম থেকে একটি বৈধ, অ-বাতিলকৃত সার্টিফিকেট ছাড়া কোনো পক্ষই অন্য পক্ষের ছদ্মবেশ ধারণ করতে পারে না। এই পারস্পরিক প্রমাণীকরণ (mutual authentication) মডেলটি একটিমাত্র আর্কিটেকচারাল সিদ্ধান্তের মাধ্যমে ক্রেডেনশিয়াল চুরি, Evil Twin আক্রমণ এবং অননুমোদিত অ্যাক্সেস পয়েন্টের ঝুঁকি দূর করে।
EAP-TLS নেটওয়ার্ক লেয়ারে মাল্টি-ফ্যাক্টর প্রমাণীকরণের জন্য PCI DSS 4.0-এর Requirement 8.6 পূরণ করে। WPA3 Enterprise 192-bit (Suite B) ডেপ্লয়মেন্টের জন্য এটি আবশ্যক। কার্ডহোল্ডার ডেটা প্রসেসিংয়ের আওতাভুক্ত যেকোনো ওয়্যারলেস নেটওয়ার্কের জন্য - যেমন রিটেল পয়েন্ট-অফ-সেল, হোটেলের ফ্রন্ট ডেস্ক, স্টেডিয়ামের টিকিট কাউন্টার - EAP-TLS হলো সঠিক পছন্দ।
secure WiFi আর্কিটেকচার এবং কীভাবে সার্টিফিকেট-ভিত্তিক প্রমাণীকরণ একটি বৃহত্তর সিকিউরিটি কাঠামোর সাথে খাপ খায় সে সম্পর্কে আরও বিস্তারিত জানতে, আমাদের প্রয়োজনীয় গাইডটি দেখুন।
ইমপ্লিমেন্টেশন গাইড
ডেপ্লয়মেন্টের ধারাবাহিকতা পরিবর্তনযোগ্য নয়। Intune এবং Jamf প্রোফাইলের নির্ভরশীলতা ক্রমানুসারে সমাধান করে: WiFi প্রোফাইলটি SCEP প্রোফাইলের ওপর নির্ভরশীল, যা আবার Trusted Root প্রোফাইলের ওপর নির্ভরশীল। এগুলো ক্রমানুসারে ডেপ্লয় না করলে WiFi প্রোফাইলটি প্রয়োগ করা যাবে না।
ধাপ ১: আপনার PKI ডিজাইন করুন
MDM কনসোলে কাজ শুরু করার আগে, আপনার সার্টিফিকেট অনুক্রম ডিজাইন করুন। একটি দ্বি-স্তর বিশিষ্ট PKI হলো স্ট্যান্ডার্ড: একটি অফলাইন রুট CA এবং একটি অনলাইন ইস্যুয়িং CA। রুট CA-এর প্রাইভেট কি হলো আপনার সম্পূর্ণ সার্টিফিকেট কাঠামোর মূল ট্রাস্ট অ্যাঙ্কর - এটিকে এয়ার-গ্যাপড (নেটওয়ার্ক থেকে বিচ্ছিন্ন) রাখুন। ইস্যুয়িং CA দৈনন্দিন সার্টিফিকেট ইস্যু করার কাজ পরিচালনা করে এবং সার্টিফিকেট রিভোকেশন লিস্ট (CRL) ও OCSP রেসপন্ডার প্রকাশ করে।
বেশিরভাগ এন্টারপ্রাইজ ভেন্যু ডেপ্লয়মেন্টের জন্য, Windows Server-এ চলমান Microsoft Active Directory Certificate Services (AD CS) ইস্যুয়িং CA প্রদান করে। SCEPman বা SecureW2-এর মতো প্রোভাইডারদের ক্লাউড-হোস্টেড PKI পরিষেবাগুলো অন-প্রেমিসেস পরিকাঠামোর প্রয়োজনীয়তা সম্পূর্ণরূপে দূর করে এবং হোটেল গ্রুপ, রিটেল চেইন বা একাধিক সাইট বিশিষ্ট পাবলিক-সেক্টর সংস্থাগুলোর মতো বিস্তৃত ডেপ্লয়মেন্টের ক্ষেত্রে এগুলো বিবেচনা করার মতো।
ধাপ ২: NDES সার্ভার (অথবা ক্লাউড SCEP গেটওয়ে) ডেপ্লয় করুন
NDES (Network Device Enrollment Service) হলো Microsoft Windows Server-এর একটি রোল যা আপনার MDM এবং CA-এর মধ্যে SCEP গেটওয়ে হিসেবে কাজ করে। মূল কনফিগারেশন প্রয়োজনীয়তাগুলো হলো:
- Azure AD Application Proxy (অথবা সমতুল্য রিভার্স প্রক্সি) এর মাধ্যমে NDES URL-টি বাহ্যিকভাবে প্রকাশ করুন। এটি দূরবর্তী ডিভাইসগুলোকে অন-সাইটে পৌঁছানোর আগেই এনরোল করার সুবিধা দেয়, যার জন্য ইনবাউন্ড ফায়ারওয়াল পোর্ট খোলার প্রয়োজন হয় না।
- NDES সার্ভিস অ্যাকাউন্টের জন্য CA সার্টিফিকেট টেমপ্লেটে Read এবং Enroll পারমিশন প্রয়োজন।
- Key Usage-কে Digital Signature এবং Key Encipherment হিসেবে এবং Extended Key Usage-কে Client Authentication (OID: 1.3.6.1.5.5.7.3.2) হিসেবে সেট করে সার্টিফিকেট টেমপ্লেটটি কনফিগার করুন।
- একটি উপযুক্ত সার্টিফিকেটের মেয়াদকাল নির্ধারণ করুন। ক্লায়েন্ট সার্টিফিকেটের জন্য এক বছর হলো স্ট্যান্ডার্ড; স্থিতিশীল ডিভাইসের ক্ষেত্রে দুই বছর গ্রহণযোগ্য।আপনি যদি অন-প্রিমিসেস NDES পরিকাঠামো এড়াতে চান, তবে ক্লাউড SCEP গেটওয়েগুলি API-এর মাধ্যমে সরাসরি Intune এবং আপনার CA-এর সাথে সংহত হয়, যা IIS-এর প্রয়োজনীয়তা সম্পূর্ণরূপে দূর করে।
ধাপ ৩: Trusted Root Certificate প্রোফাইলটি ডেপ্লয় করুন
আপনার MDM প্ল্যাটফর্মে, একটি Trusted Certificate প্রোফাইল তৈরি করুন এবং আপনার Root CA সার্টিফিকেট (এবং যেকোনো Intermediate CA সার্টিফিকেট) .cer ফাইল হিসেবে আপলোড করুন। অন্য যেকোনো সার্টিফিকেট বা WiFi প্রোফাইলের আগে আপনার টার্গেট ডিভাইস গ্রুপগুলিতে এই প্রোফাইলটি ডেপ্লয় করুন। এই ধাপটি ছাড়া, ডিভাইসগুলি EAP-TLS হ্যান্ডশেকের সময় RADIUS সার্ভারের সার্টিফিকেট যাচাই করতে পারে না এবং তাদের নিজস্ব SCEP সার্টিফিকেটের জন্য অনুরোধ করার সময় ইস্যুকারী CA-কে বিশ্বাস করতে পারে না।
সাধারণ নিয়ম: তিনটি সম্পর্কিত প্রোফাইল জুড়েই সর্বদা একই Azure AD গ্রুপকে (ব্যবহারকারী বা ডিভাইস) টার্গেট করুন। এখানে অমিল হওয়াটাই WiFi প্রোফাইল ডেপ্লয়মেন্ট ব্যর্থতার সবচেয়ে সাধারণ একক কারণ।
ধাপ ৪: SCEP Certificate প্রোফাইলটি কনফিগার করুন
আপনার MDM-এ একটি SCEP সার্টিফিকেট কনফিগারেশন প্রোফাইল তৈরি করুন:
- Subject name format: ব্যবহারকারী-চালিত প্রমাণীকরণের জন্য,
CN={{UserPrincipalName}}ব্যবহার করুন। ডিভাইস প্রমাণীকরণের জন্য (শেয়ার করা ডিভাইস এবং IoT-এর জন্য প্রস্তাবিত),CN={{AAD_Device_ID}}ব্যবহার করুন। - Key usage: Digital Signature, Key Encipherment।
- Extended key usage: Client Authentication (OID: 1.3.6.1.5.5.7.3.2)।
- SCEP server URL: বাহ্যিকভাবে প্রকাশিত NDES URL।
- Root certificate: ধাপ ৩ থেকে Trusted Root প্রোফাইলের সাথে লিঙ্ক করুন।
- Certificate validity period: CA-তে কনফিগার করা টেমপ্লেটের সাথে মেলান।
ধাপ ৫: 802.1X WiFi প্রোফাইলটি ডেপ্লয় করুন
একটি WiFi কনফিগারেশন প্রোফাইল তৈরি করুন:
- SSID: আপনার অ্যাক্সেস পয়েন্টগুলি দ্বারা যেভাবে ব্রডকাস্ট করা হচ্ছে ঠিক সেইভাবে নেটওয়ার্কের নামটি লিখুন।
- Security type: WPA2-Enterprise বা WPA3-Enterprise।
- EAP type: EAP-TLS।
- Client authentication certificate: ধাপ ৪ থেকে SCEP সার্টিফিকেট প্রোফাইলটি নির্বাচন করুন।
- Server validation: ধাপ ৩ থেকে Trusted Root সার্টিফিকেটটি নির্দিষ্ট করুন এবং প্রত্যাশিত RADIUS সার্ভারের নাম লিখুন। এটি ডিভাইসগুলিকে প্রতারণামূলক সার্টিফিকেট প্রদর্শনকারী অননুমোদিত অ্যাক্সেস পয়েন্টগুলির সাথে সংযোগ স্থাপন করা থেকে বিরত রাখে।
সর্বোত্তম অনুশীলনসমূহ
আপনার RADIUS সার্ভারে কঠোর CRL চেকিং প্রয়োগ করুন
সার্টিফিকেট প্রত্যাহার (Certificate revocation) হলো এমন একটি অপারেশনাল নিয়ন্ত্রণ যা কোনো অ্যাকাউন্ট নিষ্ক্রিয় করা এবং নেটওয়ার্ক অ্যাক্সেস ব্লক করার মধ্যকার ব্যবধান দূর করে। যখন কোনো ডিভাইস হারিয়ে যায়, চুরি হয় বা কোনো কর্মচারী চলে যান, তখন AD অ্যাকাউন্টটি নিষ্ক্রিয় করুন এবং CA-তে সার্টিফিকেটটি প্রত্যাহার করুন। প্রতিটি প্রমাণীকরণের প্রচেষ্টায় CRL চেক করার জন্য আপনার RADIUS সার্ভারটি কনফিগার করা আবশ্যক। CDP (CRL Distribution Point) নাগালের বাইরে থাকার কারণে যদি CRL অনুপলব্ধ হয় - তবে বেশিরভাগ RADIUS সার্ভার ডিফল্টরূপে অ্যাক্সেস উন্মুক্ত করে দেয়, যা একটি নিরাপত্তা ঝুঁকি। আপনার CDP-গুলি যাতে অত্যন্ত নির্ভরযোগ্যভাবে উপলব্ধ থাকে এবং CRL আনা না গেলে আপনার RADIUS সার্ভারটি যাতে অ্যাক্সেস বন্ধ করে দেওয়ার জন্য কনফিগার করা থাকে তা নিশ্চিত করুন।
রিয়েল-টাইম প্রত্যাহারের জন্য, CRL-এর পাশাপাশি OCSP (Online Certificate Status Protocol) কনফিগার করুন। OCSP সম্পূর্ণ CRL ডাউনলোড এবং পার্স করার জন্য RADIUS সার্ভারের প্রয়োজন ছাড়াই প্রতি-সার্টিফিকেট স্ট্যাটাস রেসপন্স প্রদান করে।
শেয়ার্ড এবং IoT ডিভাইসের জন্য ডিভাইস সার্টিফিকেট ব্যবহার করুন
শেয়ার্ড ডিভাইসের জন্য - হোটেলের হাউসকিপিং ট্যাবলেট, রিটেইল POS টার্মিনাল, স্টেডিয়াম অ্যাক্সেস কন্ট্রোল রিডার - ব্যবহারকারী সার্টিফিকেটের পরিবর্তে ডিভাইস সার্টিফিকেট ব্যবহার করুন। ডিভাইস সার্টিফিকেটগুলো মেশিন আইডেন্টিটির সাথে যুক্ত থাকে, কোনো ব্যবহারকারীর অ্যাকাউন্টের সাথে নয়। এর অর্থ হলো কোন ব্যবহারকারী লগ ইন করেছেন তা নির্বিশেষে ডিভাইসটি অথেন্টিকেট করে, এবং সার্টিফিকেট প্রত্যাহার কোনো কর্মচারীর চলে যাওয়ার পরিবর্তে ডিভাইস রেকর্ডের সাথে যুক্ত থাকে।
retail ডেপ্লয়মেন্টের জন্য, POS হার্ডওয়্যারে ডিভাইস সার্টিফিকেট পয়েন্ট অফ সেল-এ ব্যবহারকারীর ক্রেডেনশিয়াল জটিলতা তৈরি না করেই নেটওয়ার্ক-লেয়ার ডিভাইস আইডেন্টিটির জন্য PCI DSS প্রয়োজনীয়তা পূরণ করে।
সার্টিফিকেট রিনিউয়াল স্বয়ংক্রিয় করুন
SCEP স্বয়ংক্রিয় রিনিউয়াল সমর্থন করে: MDM ডিভাইসটিকে সার্টিফিকেট শেষ হওয়ার আগে পুনরায় তালিকাভুক্ত করার নির্দেশ দেয়। সার্টিফিকেটের অবশিষ্ট মেয়াদের ২০% সময় থাকতে রিনিউয়াল শুরু করার জন্য আপনার SCEP প্রোফাইল কনফিগার করুন। এক বছরের সার্টিফিকেটের জন্য, মেয়াদ শেষ হওয়ার প্রায় ৭৩ দিন আগে রিনিউয়াল শুরু হয়। এই সময়সীমাটি সার্টিফিকেটের মেয়াদ শেষ হওয়ার এবং ডিভাইসগুলোর নেটওয়ার্ক অ্যাক্সেস হারানোর আগে যেকোনো রিনিউয়াল ব্যর্থতার সমাধান করার জন্য যথেষ্ট সময় দেয়।
মেয়াদোত্তীর্ণ সার্টিফিকেটের কারণে ব্যাপক অথেন্টিকেশন ব্যর্থতা হলো 802.1X ডেপ্লয়মেন্টের সবচেয়ে সাধারণ অপারেশনাল সমস্যা। SCEP-এর মাধ্যমে স্বয়ংক্রিয় রিনিউয়াল এই ঝুঁকি সম্পূর্ণরূপে দূর করে।
সার্টিফিকেট অ্যাট্রিবিউট দ্বারা নেটওয়ার্ক সেগমেন্ট করুন
RADIUS সার্ভারগুলো সার্টিফিকেট অ্যাট্রিবিউট - Subject, SAN, বা কাস্টম OID - পড়তে পারে এবং ডিভাইসগুলোকে ডাইনামিকভাবে VLAN-এ অ্যাসাইন করতে এগুলো ব্যবহার করতে পারে। HousekeepingDevices টেমপ্লেট থেকে ইস্যু করা সার্টিফিকেট সহ একটি হাউসকিপিং ট্যাবলেট হাউসকিপিং VLAN-এ যুক্ত হয়। RetailPOS টেমপ্লেট থেকে সার্টিফিকেট সহ একটি POS টার্মিনাল PCI-স্কোপড VLAN-এ যুক্ত হয়। এটি ক্রিপ্টোগ্রাফিকভাবে প্রয়োগ করা নেটওয়ার্ক সেগমেন্টেশন - যা SSID-ভিত্তিক বা MAC-ভিত্তিক পদ্ধতির চেয়ে অনেক বেশি নির্ভরযোগ্য।
একই ফিজিক্যাল ইনফ্রাস্ট্রাকচারে Staff WiFi-এর পাশাপাশি Guest WiFi পরিচালনাকারী hospitality অপারেটরদের জন্য, সার্টিফিকেট অ্যাট্রিবিউটের মাধ্যমে VLAN অ্যাসাইনমেন্ট নিশ্চিত করে যে কোনো ডিভাইস কোন SSID-এ সংযুক্ত হচ্ছে তা নির্বিশেষে অতিথি এবং কর্মীরা সর্বদা পৃথক নেটওয়ার্ক সেগমেন্টে থাকবেন।
ট্রাবলশুটিং এবং ঝুঁকি প্রশমন
Intune-এ WiFi প্রোফাইল 'Error' বা 'Not Applicable' দেখাচ্ছে
মূল কারণ: গ্রুপ টার্গেটিং অমিল। SCEP প্রোফাইলটি WiFi প্রোফাইলের চেয়ে ভিন্ন একটি গ্রুপে অ্যাসাইন করা হয়েছে। Intune সার্টিফিকেট ডিপেন্ডেন্সি সমাধান করতে পারছে না।
সমাধান: তিনটি প্রোফাইলই (Trusted Root, SCEP, WiFi) অডিট করুন। নিশ্চিত করুন যে সেগুলো সবই হুবহু একই Azure AD গ্রুপে অ্যাসাইন করা হয়েছে। আপনি যদি Users-এ ডেপ্লয় করেন, তবে তিনটি প্রোফাইলই অবশ্যই একটি Users গ্রুপকে টার্গেট করবে। যদি Devices-এ ডেপ্লয় করেন, তবে তিনটিই অবশ্যই একটি Devices গ্রুপকে টার্গেট করবে।
NDES HTTP 403 ত্রুটি প্রদর্শন করছে
মূল কারণ: Intune Certificate Connector সার্ভিস অ্যাকাউন্টে CA সার্টিফিকেট টেমপ্লেটে Read বা Enroll পারমিশন নেই, অথবা ফায়ারওয়াল URL ফিল্টারিং SCEP কোয়েরি স্ট্রিং ব্লক করছে।সমাধান: CA কনসোলে টেমপ্লেটের উপর কানেক্টর অ্যাকাউন্টের Read এবং Enroll পারমিশন রয়েছে কিনা তা যাচাই করুন। ?operation=GetCACaps বা ?operation=PKIOperation যুক্ত ব্লক করা রিকোয়েস্টের জন্য ফায়ারওয়াল লগ পরীক্ষা করুন। এই কোয়েরি স্ট্রিংগুলো কোনো পরিবর্তন ছাড়াই পাস হতে হবে।
মেয়াদ শেষ হওয়ার আগে ডিভাইসগুলো সার্টিফিকেট রিনিউ করতে ব্যর্থ হচ্ছে
মূল কারণ: SCEP রিনিউয়াল উইন্ডোটি অত্যন্ত ছোট, অথবা রিনিউয়ালের সময় NDES সার্ভারটি অ্যাক্সেস করা যাচ্ছে না।
সমাধান: রিনিউয়াল থ্রেশহোল্ডটি সার্টিফিকেটের মেয়াদের ২০% এ সেট করুন। NDES URL-টি একটি হাইলি-অ্যাভেলেবল রিভার্স প্রক্সির মাধ্যমে পাবলিশ করা হয়েছে কিনা তা নিশ্চিত করুন। রিনিউয়াল রিকোয়েস্টের ব্যর্থতার জন্য NDES IIS লগ মনিটর করুন এবং প্রোঅ্যাক্টিভলি অ্যালার্ট সেট করুন।
RADIUS বৈধ সার্টিফিকেট রিজেক্ট করছে
মূল কারণ: RADIUS সার্ভারের ট্রাস্টেড CA স্টোরে ইস্যুকারী CA সার্টিফিকেট অন্তর্ভুক্ত নেই, অথবা CRL-টি পুরনো হয়ে গেছে।
সমাধান: RADIUS সার্ভারের ট্রাস্টেড স্টোরে সম্পূর্ণ CA চেইন (Root CA + Issuing CA) ইম্পোর্ট করুন। CRL সফলভাবে ফেচ করা হচ্ছে কিনা এবং RADIUS সার্ভার থেকে CDP URL-টি অ্যাক্সেস করা যাচ্ছে কিনা তা যাচাই করুন। CRL-এর next-update টাইমস্ট্যাম্প পরীক্ষা করুন - যদি এটি পার হয়ে গিয়ে থাকে, তবে CA-কে একটি নতুন CRL পাবলিশ করতে হবে।
নিরাপত্তার পাশাপাশি আরও ব্যাপক নেটওয়ার্ক পারফরম্যান্সের বিবেচনার জন্য, আমাদের ব্যান্ডউইথ ম্যানেজমেন্ট গাইড দেখুন।
ROI এবং ব্যবসায়িক প্রভাব
SCEP-ভিত্তিক সার্টিফিকেট এনরোলমেন্টের ব্যবসায়িক সুবিধা অত্যন্ত স্পষ্ট। পাসওয়ার্ড-ভিত্তিক WiFi হেল্পডেস্কে একটি অনুমানযোগ্য পরিমাণ টিকিট তৈরি করে: পাসওয়ার্ডের মেয়াদ শেষ হওয়া, লকআউট, স্টাফদের অতিথিদের সাথে ক্রেডেনশিয়াল শেয়ার করা এবং নতুনদের অনবোর্ডিংয়ের জটিলতা। সার্টিফিকেট-ভিত্তিক অথেন্টিকেশন শেষ ব্যবহারকারীর কাছে অদৃশ্য থাকে। ডিভাইসগুলো স্বয়ংক্রিয়ভাবে কানেক্ট হয়। মেয়াদ শেষ হওয়ার, শেয়ার করার বা ভুলে যাওয়ার মতো কোনো পাসওয়ার্ড থাকে না।
যেসব প্রতিষ্ঠান পাসওয়ার্ড-ভিত্তিক WiFi থেকে SCEP সহ EAP-TLS-এ মাইগ্রেট করে, তারা সাধারণত WiFi-সংক্রান্ত হেল্পডেস্ক টিকিটে ৭০-৮০% হ্রাসের রিপোর্ট করে (Purple-এর অভ্যন্তরীণ ডেটা, ২০২৪, হসপিটালিটি এবং রিটেল এস্টেট জুড়ে ডেপ্লয়মেন্টের ওপর ভিত্তি করে)। শুধুমাত্র হেল্পডেস্কের এই সাশ্রয়ই প্রায়শই প্রথম বছরের মধ্যে বাস্তবায়নের খরচ পুষিয়ে দেয়।
কমপ্লায়েন্সের প্রভাবও সমানভাবে বাস্তব। EAP-TLS নেটওয়ার্ক লেয়ারে মাল্টি-ফ্যাক্টর অথেন্টিকেশনের জন্য PCI DSS 4.0-এর Requirement 8.6 পূরণ করে। হেলথকেয়ার পরিবেশের জন্য, এটি ওয়্যারলেস নেটওয়ার্ক অ্যাক্সেসের জন্য HIPAA-এর টেকনিক্যাল সেফগার্ডের প্রয়োজনীয়তার সাথে সামঞ্জস্যপূর্ণ। পাবলিক-সেক্টর প্রতিষ্ঠানগুলোর জন্য, এটি নেটওয়ার্ক অ্যাক্সেস কন্ট্রোলের জন্য NCSC Cyber Essentials Plus সার্টিফিকেশনের প্রয়োজনীয়তাগুলোকে সমর্থন করে।
পরিবহন অপারেটরদের জন্য - রেল ফ্র্যাঞ্চাইজি, বিমানবন্দর অপারেটর, বাস নেটওয়ার্ক - স্টাফদের ডিভাইসে সার্টিফিকেট-ভিত্তিক অথেন্টিকেশন নিশ্চিত করে যে সেফটি-ক্রিটিক্যাল ডেটা বহনকারী অপারেশনাল নেটওয়ার্কগুলো প্যাসেঞ্জার WiFi থেকে সম্পূর্ণ আলাদা এবং ক্রেডেনশিয়াল-ভিত্তিক আক্রমণ থেকে সুরক্ষিত।Purple-এর WiFi Analytics প্ল্যাটফর্মটি 802.1X-সুরক্ষিত নেটওয়ার্কের সাথে একীভূত হয়ে অন্তর্নিহিত পরিকাঠামোর নিরাপত্তা ব্যবস্থার সাথে কোনো আপস না করেই ফার্স্ট-পার্টি ডেটা ইনসাইট প্রদান করে। Purple-এর নেটওয়ার্ক জুড়ে সংগৃহীত ২৯ বিলিয়ন ডেটা পয়েন্ট প্রমাণ করে যে নিরাপত্তা এবং অ্যানালিটিক্স একে অপরের পরিপূরক, কোনো প্রতিদ্বন্দ্বী উদ্দেশ্য নয়।
আপনার সুরক্ষিত নেটওয়ার্ক স্থাপনের পাশাপাশি ফিডব্যাক এবং অভিজ্ঞতা পরিচালনার জন্য, আমাদের venue feedback playbook দেখুন।
মূল সংজ্ঞাসমূহ
SCEP (Simple Certificate Enrollment Protocol)
একটি IETF-স্ট্যান্ডার্ডাইজড প্রোটোকল (RFC 8894) যা পরিচালিত ডিভাইসগুলোর জন্য X.509 সার্টিফিকেট এনরোলমেন্ট স্বয়ংক্রিয় করে। ডিভাইসটি স্থানীয়ভাবে নিজস্ব প্রাইভেট কি তৈরি করে এবং একটি গেটওয়ের মাধ্যমে CA-তে শুধুমাত্র একটি Certificate Signing Request পাঠায়। প্রাইভেট কি-টি কখনই ডিভাইস থেকে বাইরে যায় না।
IT টিমগুলো স্কেলে WiFi অথেন্টিকেশন সার্টিফিকেট ডিপ্লয় করার জন্য MDM প্ল্যাটফর্ম (Intune, Jamf) কনফিগার করার সময় SCEP-এর সম্মুখীন হয়। এটি 802.1X EAP-TLS ডিপ্লয়মেন্টের জন্য প্রস্তাবিত মেকানিজম কারণ প্রাইভেট কি-টি এন্ডপয়েন্টে হার্ডওয়্যার-সুরক্ষিত থাকে।
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
সবচেয়ে নিরাপদ 802.1X অথেন্টিকেশন পদ্ধতি। ক্লায়েন্ট ডিভাইস এবং RADIUS সার্ভার উভয়ই X.509 সার্টিফিকেট প্রদর্শন করে। বিশ্বস্ত CA হায়ারার্কি থেকে একটি বৈধ, নন-রিভোকড সার্টিফিকেট ছাড়া কোনো পক্ষই অথেন্টিকেট করতে পারে না।
EAP-TLS হলো টার্গেট অথেন্টিকেশন প্রোটোকল যা SCEP সার্টিফিকেট ডিপ্লয়মেন্ট সক্ষম করে। এটি PCI DSS 4.0 Requirement 8.6 পূরণ করে এবং WPA3 Enterprise 192-bit (Suite B) ডিপ্লয়মেন্টের জন্য প্রয়োজনীয়।
PKCS (Public Key Cryptography Standards)
একটি সার্টিফিকেট ডেলিভারি মেকানিজম যেখানে CA কেন্দ্রীয়ভাবে পাবলিক এবং প্রাইভেট কি পেয়ার উভয়ই তৈরি করে এবং এন্ডপয়েন্টে স্থানান্তর করে। CA প্রাইভেট কি-এর একটি কপি নিজের কাছে রেখে দেয়, যা কি এসক্রো সক্ষম করে।
Intune-এ সার্টিফিকেট প্রোফাইল কনফিগার করার সময় IT টিমগুলো SCEP এবং PKCS-এর মধ্যে একটি বেছে নেয়। PKCS হলো S/MIME ইমেল এনক্রিপশনের জন্য উপযুক্ত যেখানে কি এসক্রো (key escrow) প্রয়োজন। WiFi অথেন্টিকেশনের জন্য এটি সুপারিশ করা হয় না কারণ প্রাইভেট কি-টি নেটওয়ার্কের মাধ্যমে স্থানান্তরিত হয়।
NDES (Network Device Enrollment Service)
একটি Microsoft Windows Server রোল যা একটি MDM প্ল্যাটফর্ম এবং একটি Certificate Authority-এর মধ্যে SCEP গেটওয়ে হিসেবে কাজ করে। এটি ডিভাইস এনরোলমেন্টের অনুরোধগুলো যাচাই করে এবং CSR-গুলো CA-তে ফরোয়ার্ড করে।
Microsoft Intune-এর সাথে অন-প্রিমিসেস SCEP ডিপ্লয়মেন্টের জন্য NDES একটি প্রয়োজনীয় ইনফ্রাস্ট্রাকচার উপাদান। দূরবর্তী ডিভাইসগুলোকে এনরোল করার অনুমতি দিতে এটি একটি অ্যাপ্লিকেশন প্রক্সির মাধ্যমে বাহ্যিকভাবে প্রকাশ করতে হবে। ক্লাউড SCEP গেটওয়েগুলো একটি বিকল্প যা অন-প্রিমিসেস NDES-এর প্রয়োজনীয়তা দূর করে।
CRL (Certificate Revocation List)
CA দ্বারা প্রকাশিত একটি তালিকা যাতে মেয়াদ শেষ হওয়ার আগে বাতিল করা সার্টিফিকেটের সিরিয়াল নম্বরগুলো থাকে। বাতিল করা সার্টিফিকেট সহ ডিভাইসগুলো যাতে অথেন্টিকেট করতে না পারে তা নিশ্চিত করতে RADIUS সার্ভারগুলো CRL চেক করে।
CRL চেকিং হলো অপারেশনাল কন্ট্রোল যা সার্টিফিকেট রিভোকেশন কার্যকর করে। IT টিমগুলোকে অবশ্যই তাদের RADIUS সার্ভার কনফিগার করতে হবে যাতে প্রতিটি অথেন্টিকেশন প্রচেষ্টায় CRL চেক করা হয় এবং CRL ডিস্ট্রিবিউশন পয়েন্ট (CDP) অত্যন্ত সহজলভ্য থাকে।
802.1X
পোর্ট-ভিত্তিক নেটওয়ার্ক অ্যাক্সেস কন্ট্রোলের জন্য একটি IEEE স্ট্যান্ডার্ড। এটি এন্টারপ্রাইজ WiFi এবং ওয়্যার্ড নেটওয়ার্কে ব্যবহৃত থ্রি-পার্টি অথেন্টিকেশন ফ্রেমওয়ার্ক (supplicant, authenticator, authentication server) সংজ্ঞায়িত করে।
802.1X হলো সেই ফ্রেমওয়ার্ক যার মধ্যে EAP-TLS এবং SCEP কাজ করে। WPA2-Enterprise বা WPA3-Enterprise SSID কনফিগার করার সময় এবং RADIUS সার্ভার পলিসি সেট আপ করার সময় IT টিমগুলো এর সম্মুখীন হয়।
RADIUS (Remote Authentication Dial-In User Service)
একটি নেটওয়ার্কিং প্রোটোকল যা নেটওয়ার্ক অ্যাক্সেসের জন্য সেন্ট্রালাইজড অথেন্টিকেশন, অথরাইজেশন এবং অ্যাকাউন্টিং (AAA) প্রদান করে। 802.1X ডিপ্লয়মেন্টে, RADIUS সার্ভার ক্লায়েন্ট সার্টিফিকেট যাচাই করে এবং VLAN অ্যাসাইনমেন্ট পলিসি কার্যকর করে।
RADIUS সার্ভার হলো প্রতিটি 802.1X ডিপ্লয়মেন্টের অথেন্টিকেশন সিদ্ধান্ত নেওয়ার মূল বিন্দু। সাধারণ ইমপ্লিমেন্টেশনের মধ্যে রয়েছে Microsoft NPS, FreeRADIUS এবং Cisco ISE। এটি অবশ্যই বিশ্বস্ত CA চেইন এবং কঠোর CRL বা OCSP চেকিংয়ের সাথে কনফিগার করা উচিত।
CSR (Certificate Signing Request)
একটি ডিভাইস দ্বারা তৈরি এনকোড করা টেক্সটের একটি ব্লক যাতে ডিভাইসের পাবলিক কি এবং আইডেন্টিটি ইনফরমেশন থাকে। একটি স্বাক্ষরিত সার্টিফিকেটের অনুরোধ করতে ডিভাইসটি (SCEP গেটওয়ের মাধ্যমে) CA-তে CSR পাঠায়। সংশ্লিষ্ট প্রাইভেট কি-টি ডিভাইসে তৈরি এবং সংরক্ষিত হয়।
CSR হলো SCEP এনরোলমেন্ট ফ্লো-এর মূল উপাদান। IT টিমগুলো তাদের MDM প্ল্যাটফর্মের মধ্যে SCEP সার্টিফিকেট প্রোফাইলে CSR ফরম্যাট (subject name, key usage, EKU) কনফিগার করে।
PKI (Public Key Infrastructure)
ডিজিটাল সার্টিফিকেট তৈরি, পরিচালনা, বিতরণ এবং বাতিল করার জন্য প্রয়োজনীয় হার্ডওয়্যার, সফটওয়্যার, পলিসি এবং পদ্ধতির সমন্বয়। একটি স্ট্যান্ডার্ড এন্টারপ্রাইজ PKI একটি অফলাইন রুট CA এবং একটি অনলাইন ইস্যুয়িং CA নিয়ে গঠিত।
PKI হলো যেকোনো EAP-TLS ডিপ্লয়মেন্টের পূর্বশর্ত। SCEP কনফিগার করার আগে IT টিমগুলোকে অবশ্যই একটি টু-টায়ার CA হায়ারার্কি ডিজাইন এবং ডিপ্লয় করতে হবে। ক্লাউড-হোস্টেড PKI পরিষেবাগুলো ডিস্ট্রিবিউটেড এস্টেট ডিপ্লয়মেন্টের জন্য ইনফ্রাস্ট্রাকচারের বোঝা কমিয়ে দেয়।
VLAN (Virtual Local Area Network)
একটি লজিক্যাল নেটওয়ার্ক সেগমেন্ট যা লেয়ার ২-এ ট্রাফিককে আলাদা করে। 802.1X ডিপ্লয়মেন্টে, RADIUS সার্ভারগুলো সার্টিফিকেটের বৈশিষ্ট্য, ব্যবহারকারীর পরিচয় বা পলিসির ওপর ভিত্তি করে ডিভাইসগুলোকে ডাইনামিকভাবে VLAN-এ অ্যাসাইন করে।
RADIUS-এর মাধ্যমে VLAN অ্যাসাইনমেন্ট হলো এমন একটি মেকানিজম যা এন্টারপ্রাইজ WiFi-এ নেটওয়ার্ক সেগমেন্টেশন কার্যকর করে। IT টিমগুলো একটি একক ফিজিক্যাল ইনফ্রাস্ট্রাকচার থেকেই POS ডিভাইসগুলোকে PCI-স্কোপড VLAN-এ, গেস্ট ডিভাইসগুলোকে শুধুমাত্র ইন্টারনেট-ভিত্তিক VLAN-এ এবং কর্মীদের ডিভাইসগুলোকে কর্পোরেট VLAN-এ আলাদা করতে এটি ব্যবহার করে।
সমাধানকৃত উদাহরণসমূহ
একটি ২০০-রুমের প্রিমিয়ার ইন প্রপার্টিতে ১৫০টি iOS হাউসকিপিং ডিভাইসের জন্য নিরাপদ WiFi ডেপ্লয় করতে হবে। কর্মীরা বর্তমানে অতিথিদের সাথে একটি WPA2-Personal পাসওয়ার্ড শেয়ার করছেন, যা একটি কমপ্লায়েন্স এবং অপারেশনাল ঝুঁকি তৈরি করছে। IT ডিরেক্টরকে দৈনন্দিন ক্রিয়াকলাপে ব্যাঘাত না ঘটিয়ে এই শেয়ার্ড পাসওয়ার্ডটি দূর করতে হবে।
IT ডিরেক্টর তিনটি ধাপে একটি Jamf-চালিত SCEP ডেপ্লয়মেন্ট বাস্তবায়ন করেন। প্রথম ধাপ: Root CA সার্টিফিকেটটি একটি Jamf ট্রাস্টেড সার্টিফিকেট প্রোফাইলের মাধ্যমে 'হাউসকিপিং ডিভাইসেস' স্মার্ট গ্রুপকে লক্ষ্য করে সমস্ত ১৫০টি iOS ডিভাইসে পুশ করা হয়। দ্বিতীয় ধাপ: একটি SCEP সার্টিফিকেট প্রোফাইল ডেপ্লয় করা হয়, যা ডিভাইসগুলোকে একটি Azure AD অ্যাপ প্রক্সি-পাবলিশড NDES সার্ভারে নির্দেশ করে। সার্টিফিকেটের সাথে ডিভাইসের হার্ডওয়্যারকে যুক্ত করতে সাবজেক্ট নেমে CN={{SERIALNUMBER}} ব্যবহার করা হয়। তৃতীয় ধাপ: একটি WPA2-Enterprise WiFi প্রোফাইল পুশ করা হয়, যা EAP-TLS নির্দিষ্ট করে এবং SCEP সার্টিফিকেটের সাথে লিঙ্ক করে। ডিভাইসগুলো নীরবে অথেন্টিকেট করে। শেয়ার্ড পাসওয়ার্ড SSID-টি নিষ্ক্রিয় করা হয়। RADIUS সার্ভারটি কঠোর CRL চেকিং এবং VLAN অ্যাসাইনমেন্ট সহ কনফিগার করা হয়েছে: হাউসকিপিং ডিভাইসগুলো VLAN 20 (অপারেশনস) এবং গেস্ট ডিভাইসগুলো VLAN 10 (শুধুমাত্র-ইন্টারনেট)-এ যুক্ত হয়।
৫০০টি লোকেশন সহ একটি রিটেইল চেইনের পেমেন্ট প্রসেসিং সফটওয়্যার চালিত Windows POS ট্যাবলেটের জন্য কর্পোরেট WiFi সুরক্ষিত করতে হবে। PCI DSS 4.0 কমপ্লায়েন্সের জন্য নেটওয়ার্ক লেয়ারে মাল্টি-ফ্যাক্টর অথেন্টিকেশন প্রয়োজন। বর্তমান WPA2-Personal সেটআপটি PCI DSS রিকোয়ারমেন্ট ৮.৬ মূল্যায়নে ব্যর্থ হয়েছে।
নেটওয়ার্ক আর্কিটেক্ট সমস্ত ৫০০টি লোকেশন জুড়ে Microsoft Intune এবং SCEP-এর মাধ্যমে EAP-TLS ডেপ্লয় করেন। এই ডেপ্লয়মেন্টে সাবজেক্ট নেম হিসেবে CN={{AAD_Device_ID}} সহ ডিভাইস সার্টিফিকেট ব্যবহার করা হয়, যা প্রতিটি সার্টিফিকেটকে Intune ডিভাইস রেকর্ডের সাথে যুক্ত করে। তিন-প্রোফাইলের সিকোয়েন্সটি (ট্রাস্টেড রুট, SCEP, WiFi) 'POS ডিভাইসেস' Azure AD গ্রুপে ডেপ্লয় করা হয় - তিনটি প্রোফাইল জুড়েই একই গ্রুপ। RADIUS সার্ভারটি সার্টিফিকেটের ইস্যুয়িং টেমপ্লেটের উপর ভিত্তি করে POS ডিভাইসগুলোকে একটি ডেডিকেটেড PCI-স্কোপড VLAN (VLAN 100)-এ অ্যাসাইন করে। CRL-টি চার ঘণ্টার ভ্যালিডিটি উইন্ডো সহ একটি হাইলি অ্যাভেলেবল CDN-হোস্টেড এন্ডপয়েন্টে পাবলিশ করা হয়। রিয়েল-টাইম রিভোকেশন চেকিংয়ের জন্য OCSP সক্ষম করা হয়েছে। ডেপ্লয়মেন্টটি QSA দ্বারা PCI DSS 4.0 রিকোয়ারমেন্ট ৮.৬-এর বিপরীতে যাচাই করা হয়েছে।
অনুশীলনী প্রশ্নসমূহ
Q1. আপনি Intune-এ 'All Staff' ইউজার গ্রুপে Trusted Root এবং SCEP সার্টিফিকেট প্রোফাইল ডেপ্লয় করেছেন। এরপর আপনি 'Corporate Devices' ডিভাইস গ্রুপে WiFi প্রোফাইলটি ডেপ্লয় করেন। ডিভাইসগুলি সার্টিফিকেট পেলেও Intune কনসোলে WiFi প্রোফাইলটি 'Error' দেখাচ্ছে। এর সম্ভাব্য কারণ কী এবং আপনি কীভাবে এটি সমাধান করবেন?
ইঙ্গিত: Intune কীভাবে প্রোফাইলগুলির মধ্যে ডিপেন্ডেন্সি সমাধান করে এবং প্রোফাইলগুলি যখন বিভিন্ন গ্রুপ টাইপকে টার্গেট করে তখন কী ঘটে তা বিবেচনা করুন।
মডেল উত্তর দেখুন
এর মূল কারণ হলো গ্রুপ টার্গেটিংয়ের অমিল। WiFi প্রোফাইলটি SCEP প্রোফাইলের ওপর নির্ভরশীল, যা আবার Trusted Root প্রোফাইলের ওপর নির্ভরশীল। প্রোফাইলগুলি যখন বিভিন্ন গ্রুপ টাইপকে (ইউজার বনাম ডিভাইস) টার্গেট করে, তখন Intune এই ডিপেন্ডেন্সিগুলি সমাধান করতে পারে না। সমাধান: তিনটি প্রোফাইলই একই গ্রুপে পুনরায় ডেপ্লয় করুন। WiFi প্রোফাইলটি যদি 'Corporate Devices' (একটি ডিভাইস গ্রুপ)-কে টার্গেট করে, তবে SCEP এবং Trusted Root প্রোফাইলগুলিকেও অবশ্যই 'Corporate Devices'-কে টার্গেট করতে হবে। বিকল্পভাবে, ইউজার-ভিত্তিক অথেন্টিকেশনের প্রয়োজন হলে তিনটিকেই একটি ইউজার গ্রুপে স্থানান্তর করুন।
Q2. একটি হোটেলের হাউসকিপারের iPad চুরি গেছে বলে রিপোর্ট করা হয়েছে। আপনি অবিলম্বে হাউসকিপারের Active Directory অ্যাকাউন্টটি নিষ্ক্রিয় করে দিয়েছেন। পরের দিন সকালে, চুরি যাওয়া iPad-টি তখনও হোটেলের WPA2-Enterprise নেটওয়ার্কের সাথে সংযুক্ত হচ্ছে। কেন এমন হচ্ছে এবং এটি প্রতিরোধ করতে আপনি কোন দুটি পদক্ষেপ নেবেন?
ইঙ্গিত: EAP-TLS অথেন্টিকেশনের সময় RADIUS সার্ভার আসলে কী যাচাই করে এবং সার্টিফিকেটের বৈধতা কোন কন্ট্রোলগুলি দ্বারা পরিচালিত হয় তা ভাবুন।
মডেল উত্তর দেখুন
AD অ্যাকাউন্ট নিষ্ক্রিয় করলেই iPad-এ সংরক্ষিত ক্লায়েন্ট সার্টিফিকেট বাতিল হয়ে যায় না। EAP-TLS অথেন্টিকেশনের সময় RADIUS সার্ভার সার্টিফিকেট যাচাই করে, AD অ্যাকাউন্টের স্ট্যাটাস নয়। প্রয়োজনীয় দুটি পদক্ষেপ হলো: (১) CA-তে ডিভাইস সার্টিফিকেটটি বাতিল (revoke) করা - এটি CRL-এ সার্টিফিকেটের সিরিয়াল নম্বর যুক্ত করে; (২) RADIUS সার্ভারটি যাতে কঠোর CRL চেকিং সহ কনফিগার করা থাকে তা নিশ্চিত করা, যাতে এটি আপডেট হওয়া CRL সংগ্রহ করে এবং পরবর্তী অথেন্টিকেশনের চেষ্টায় বাতিল করা সার্টিফিকেটটি প্রত্যাখ্যান করে। দ্রুত বাতিলের জন্য, রিয়েল-টাইম সার্টিফিকেট স্ট্যাটাস চেকের জন্য RADIUS সার্ভারে OCSP কনফিগার করুন।
Q3. একটি রিটেইল চেইন ৫০০টি POS লোকেশনে 802.1X WiFi ডেপ্লয় করছে। সিকিউরিটি আর্কিটেক্ট একটি NDES সার্ভার ডেপ্লয় করা এড়াতে SCEP-এর পরিবর্তে PKCS সার্টিফিকেট ডেলিভারি ব্যবহার করার প্রস্তাব করেছেন। PCI DSS 4.0 অ্যাসেসমেন্ট পর্যালোচনা করা QSA একটি উদ্বেগ প্রকাশ করেছেন। উদ্বেগটি কী এবং সঠিক সুপারিশ কী?
ইঙ্গিত: প্রাইভেট কি হ্যান্ডলিং সম্পর্কে PCI DSS কী বলে এবং ডেলিভারির সময় PKCS প্রাইভেট কি-র সাথে কী করে তা বিবেচনা করুন।
মডেল উত্তর দেখুন
QSA-এর উদ্বেগ হলো PKCS নেটওয়ার্কের মাধ্যমে CA থেকে ডিভাইসে প্রাইভেট কি ট্রান্সমিট করে। PCI DSS 4.0 Requirement 3.5-এ বলা হয়েছে যে অথেন্টিকেশনের জন্য ব্যবহৃত প্রাইভেট কি-গুলিকে প্রকাশ হওয়া থেকে সুরক্ষিত রাখতে হবে। নেটওয়ার্কের মাধ্যমে প্রাইভেট কি ট্রান্সমিট করা - এমনকি এনক্রিপ্ট করা থাকলেও - এমন একটি ঝুঁকি তৈরি করে যা SCEP সম্পূর্ণরূপে দূর করে। সঠিক সুপারিশ হলো SCEP ব্যবহার করা, যেখানে প্রাইভেট কি POS ডিভাইসেই তৈরি হয় এবং এটি কখনই ডিভাইস থেকে বাইরে যায় না। অন-প্রিমিসেস NDES ইনফ্রাস্ট্রাকচার এড়াতে, আর্কিটেক্টের একটি ক্লাউড SCEP গেটওয়ে সার্ভিস মূল্যায়ন করা উচিত যা API-এর মাধ্যমে সরাসরি Intune এবং CA-এর সাথে ইন্টিগ্রেট করে।
Q4. আপনি একটি বড় কনফারেন্স সেন্টারের জন্য একটি WiFi নেটওয়ার্ক ডিজাইন করছেন যা বছরে ৫০টিরও বেশি ইভেন্ট হোস্ট করে। স্টাফ ডিভাইসগুলিকে একটি সুরক্ষিত 802.1X নেটওয়ার্কে থাকা প্রয়োজন। আপনি নিশ্চিত করতে চান যে কোনো কন্ট্রাক্টরের ডিভাইস হ্যাক হলে, সেটিকে যেন ১৫ মিনিটের মধ্যে নেটওয়ার্ক থেকে বিচ্ছিন্ন করা যায়। আপনি কোন সার্টিফিকেট রিভোকেশন মেকানিজম কনফিগার করবেন এবং কেন?
ইঙ্গিত: রিভোকেশন ল্যাটেন্সির ক্ষেত্রে CRL এবং OCSP-এর তুলনা করুন এবং একটি RADIUS সার্ভার কত দ্রুত বাতিলের বিরুদ্ধে ব্যবস্থা নেবে তা কী নির্ধারণ করে তা ভাবুন।
মডেল উত্তর দেখুন
RADIUS সার্ভারে OCSP (Online Certificate Status Protocol) কনফিগার করুন। CRL-ভিত্তিক বাতিলের ক্ষেত্রে একটি ল্যাটেন্সি থাকে যা CRL-এর বৈধতার সময়কাল দ্বারা নির্ধারিত হয় - সাধারণত ১ থেকে ২৪ ঘণ্টা - যার অর্থ RADIUS সার্ভার পরবর্তী CRL সংগ্রহ না করা পর্যন্ত একটি বাতিল করা সার্টিফিকেট তখনও অথেন্টিকেট হতে পারে। OCSP রিয়েল-টাইমে প্রতি-সার্টিফিকেট স্ট্যাটাস রেসপন্স প্রদান করে: যখন CA-তে একটি সার্টিফিকেট বাতিল করা হয়, তখন OCSP রেসপন্ডার পরবর্তী কোয়েরিতে অবিলম্বে একটি 'revoked' স্ট্যাটাস ফেরত দেয়। RADIUS সার্ভারে OCSP কনফিগার করা থাকলে, পরবর্তী অথেন্টিকেশনের চেষ্টায় একটি বাতিল করা কন্ট্রাক্টর সার্টিফিকেট ব্লক হয়ে যাবে, সাধারণত কয়েক সেকেন্ডের মধ্যে। নিশ্চিত করুন যে OCSP রেসপন্ডারটি অত্যন্ত নির্ভরযোগ্য (highly available) - যদি এটি অ্যাক্সেস করা না যায় এবং RADIUS সার্ভারটি ফেইল-ক্লোজড (fail closed) হিসেবে কনফিগার করা থাকে, তবে সমস্ত অথেন্টিকেশন ব্যর্থ হবে।
এই সিরিজে পড়া চালিয়ে যান
কীভাবে স্বয়ংক্রিয় এন্টারপ্রাইজ WiFi সার্টিফিকেট এনরোলমেন্টের জন্য SCEP কনফিগার করবেন
এই নির্দেশিকাটি স্বয়ংক্রিয় এন্টারপ্রাইজ WiFi সার্টিফিকেট এনরোলমেন্টের জন্য SCEP (সিম্পল সার্টিফিকেট এনরোলমেন্ট প্রোটোকল) কীভাবে কনফিগার করতে হয় তা ব্যাখ্যা করে, যা PKI এবং NDES থেকে শুরু করে MDM প্রোফাইল ডিপ্লয়মেন্ট এবং RADIUS ভ্যালিডেশন পর্যন্ত সম্পূর্ণ আর্কিটেকচার কভার করে। এটি মূলত হোটেল, রিটেইল চেইন, স্টেডিয়াম, কনফারেন্স সেন্টার এবং পাবলিক-সেক্টর অর্গানাইজেশনের IT ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট এবং CTO-দের উদ্দেশ্যে তৈরি করা হয়েছে যাদের প্রি-শেয়ার্ড কী-এর বাইরে গিয়ে স্কেলযোগ্য, আইডেন্টিটি-ভিত্তিক 802.1X EAP-TLS অথেন্টিকেশন বাস্তবায়ন করা প্রয়োজন। Purple-এর হার্ডওয়্যার-অ্যাগনস্টিক, ক্লাউড ওভারলে প্ল্যাটফর্ম সরাসরি এই আর্কিটেকচারের সাথে সংহত হয়, যা আপনার সার্টিফিকেট-অথেন্টিকেটেড স্টাফ নেটওয়ার্কের পাশাপাশি গেস্ট এবং BYOD WiFi লেয়ার প্রদান করে।
SCEP-এর জন্য এন্টারপ্রাইজ গাইড: স্বয়ংক্রিয় ক্যাম্পাস WiFi সুরক্ষার জন্য Simple Certificate Enrollment Protocol স্থাপন করা
এই প্রযুক্তিগত রেফারেন্স গাইডটি SCEP ব্যবহার করে এন্টারপ্রাইজ WiFi সার্টিফিকেট স্থাপনের জন্য একটি সুনির্দিষ্ট আর্কিটেকচারাল ব্লুপ্রিন্ট এবং ধাপে ধাপে বাস্তবায়ন কৌশল প্রদান করে। এটি SCEP এবং PKCS-এর মধ্যে গুরুত্বপূর্ণ পার্থক্য, সফলতার জন্য প্রয়োজনীয় সঠিক স্থাপনার ক্রম এবং IT লিডারদের জন্য বাস্তব-জগতের ঝুঁকি প্রশমন কৌশলগুলি কভার করে।
Cisco SUDI বোঝা: নেটওয়ার্ক অ্যাক্সেস কন্ট্রোলে হার্ডওয়্যার-ভিত্তিক ডিভাইস আইডেন্টিটি
এই নির্দেশিকাটি Cisco SUDI-এর প্রযুক্তিগত আর্কিটেকচার বিস্তারিতভাবে বর্ণনা করে, যেখানে ব্যাখ্যা করা হয়েছে কীভাবে হার্ডওয়্যার-অ্যাঙ্করড আইডেন্টিটি নেটওয়ার্ক অ্যাক্সেস কন্ট্রোলকে সুরক্ষিত করে। এটি আইটি লিডারদের জন্য এন্টারপ্রাইজ ভেন্যু জুড়ে 802.1X EAP-TLS অথেন্টিকেশন স্থাপন এবং Zero Touch Provisioning স্বয়ংক্রিয় করার জন্য কার্যকর বাস্তবায়ন পদক্ষেপ প্রদান করে।