Revocation List Certificate: একটি ব্যবহারিক WiFi নির্দেশিকা

ট্রেনে একটি কোম্পানির ল্যাপটপ চুরি হয়ে গেছে। হেল্পডেস্ক কর্মচারীর Active Directory অ্যাকাউন্ট নিষ্ক্রিয় করে দেয়, ডিভাইসটি অ্যাসেট রেজিস্টার থেকে মুছে ফেলা হয় এবং সবাই ধরে নেয় যে ঝুঁকিটি দূর হয়েছে। দুই দিন পরেও, ল্যাপটপটি কর্পোরেট SSID-এ প্রদর্শিত হতে থাকে কারণ এর 802.1X সাপ্লিক্যান্টে একটি ক্লায়েন্ট সার্টিফিকেট রয়েছে যার মেয়াদ শেষ হয়নি এবং কেউ এটি রিভোক করেনি।

একটি রিভোকেশন লিস্ট সার্টিফিকেট প্রক্রিয়া ঠিক এই ফাঁকটি পূরণ করার জন্যই ডিজাইন করা হয়েছে। সার্টিফিকেটের মেয়াদ শেষ হওয়া ট্রাস্টের বাইরের সীমা নির্ধারণ করে, অন্যদিকে কোনো কি (key) কম্প্রোমাইজ হলে, ডিভাইস হারিয়ে গেলে বা ব্যবহারকারী চলে গেলে রিভোকেশন সেই ট্রাস্টটি আগেই বাতিল করে দেয়। একজন এন্টারপ্রাইজ WiFi অ্যাডমিনিস্ট্রেটরের জন্য গুরুত্বপূর্ণ প্রশ্নটি এটি নয় যে সার্টিফিকেট বিদ্যমান আছে কিনা। বরং প্রশ্নটি হলো, RADIUS এবং সংশ্লিষ্ট নেটওয়ার্ক নিয়ন্ত্রণগুলো কোনো রিভোকড সার্টিফিকেট সম্পর্কে দ্রুত জানতে পারছে কিনা এবং নিরাপদে ফেইল (fail safe) করছে কিনা।

সেই WiFi অ্যাক্সেস যা চলে যেতে চায়নি

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

চুরি যাওয়া ল্যাপটপের উদাহরণে, Active Directory থেকে অ্যাকাউন্টটি সরিয়ে দিলে তা হয়তো ভবিষ্যতের ডিরেক্টরি অথেন্টিকেশন বন্ধ করতে পারে, কিন্তু এটি ডিভাইসে ইতিমধ্যেই ইনস্টল করা সার্টিফিকেটকে অবশ্যই বাতিল করে না। WiFi পরিষেবা যদি শুধুমাত্র সার্টিফিকেটের চেইন এবং মেয়াদের তারিখের উপর ভিত্তি করে সেটিকে বিশ্বাস করে, তবে ল্যাপটপটি আপাতদৃষ্টিতে বৈধ ক্রেডেনশিয়াল প্রদর্শন করা চালিয়ে যেতে পারে। সার্টিফিকেটের notAfter date নির্দেশ করে যে এটি এখনও তার নির্ধারিত মেয়াদের মধ্যে রয়েছে। এটি নির্দেশ করে না যে ইস্যুকারী প্রতিষ্ঠান এখনও এটিকে বিশ্বাস করতে চায়।

ব্যবহারিক নিয়ম: সার্টিফিকেট এক্সপায়ারি এবং সার্টিফিকেট রিভোকেশনকে আলাদা নিয়ন্ত্রণ হিসেবে বিবেচনা করুন। এক্সপায়ারি হলো পরিকল্পিত লাইফসাইকেল ম্যানেজমেন্ট। রিভোকেশন হলো ইমার্জেন্সি ব্রেক।

UK পাবলিক-সেক্টর PKI মডেল এই পার্থক্যটিকে স্পষ্টভাবে তুলে ধরে। একটি Certificate Revocation List বা CRL হলো মেয়াদ শেষ হওয়ার আগেই রিভোক করা সার্টিফিকেটের সিরিয়াল নম্বরের একটি স্বাক্ষরিত তালিকা, যা রিলাইং পার্টিগুলোকে জানায় যে এই সার্টিফিকেটগুলোকে আর বিশ্বাস করা উচিত নয়। UK পাবলিক-কি ইনফ্রাস্ট্রাকচার নির্দেশিকাও CRL-কে অন্যতম সাধারণ রেভোকেশন পদ্ধতি হিসেবে চিহ্নিত করে এবং ক্লায়েন্টদের কাছ থেকে প্রত্যাশা করে যে তারা যাচাই করবে উপস্থাপিত সার্টিফিকেটটি ইস্যুকারী CA-এর তালিকায় রয়েছে কিনা।

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

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

রিভোকেশন লিস্ট সার্টিফিকেট আসলে কী

সহজ ভাষায়, একটি Certificate Revocation List হলো একটি সার্টিফিকেট অথরিটি থেকে প্রেরিত একটি অফিসিয়াল নোটিশ যা জানায় "এই সার্টিফিকেটগুলোকে আর বিশ্বাস করবেন না"। এটি সার্টিফিকেটগুলোকে তাদের সিরিয়াল নম্বর দ্বারা সনাক্ত করে, কোনো পরিচিত ডিভাইসের নাম বা কর্মচারীর ইমেল ঠিকানা দ্বারা নয়। কোনো ক্লায়েন্ট যদি সংশ্লিষ্ট তালিকায় উপস্থাপিত সার্টিফিকেটের সিরিয়াল নম্বরটি খুঁজে পায়, তবে সার্টিফিকেটের মেয়াদ শেষ হওয়ার তারিখ ভবিষ্যতে থাকলেও সেটিকে অবশ্যই প্রত্যাখ্যান করতে হবে।

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

তিনটি পক্ষ এই প্রক্রিয়াটিকে কার্যকর করে তোলে:

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

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

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

এই শেষ পয়েন্টটি অনেক ঘটনার কারণ হয়ে দাঁড়ায়। একটি সার্টিফিকেট কোনো পুরনো ক্যাশ করা তালিকায় অনুপস্থিত থাকতে পারে এবং কোনো নতুন তালিকায় উপস্থিত থাকতে পারে। নেটওয়ার্কের সিদ্ধান্ত তাই CA কী প্রকাশ করেছে এবং অথেন্টিকেটর সর্বশেষ কখন এটি সংগ্রহ করেছে উভয়ের ওপরই নির্ভর করে।

পর্দার আড়ালে কীভাবে একটি CRL কাজ করে

একটি CRL লাইফসাইকেল ইভেন্টের একটি অনুমানযোগ্য চেইন অনুসরণ করে। প্রথমত, CA তার সার্টিফিকেট নীতি অনুযায়ী একটি বেস তালিকা তৈরি করে। এটি তালিকায় স্বাক্ষর করে, প্রকাশনা ও মেয়াদের ক্ষেত্রগুলি যোগ করে এবং একটি ডিস্ট্রিবিউশন পয়েন্টের মাধ্যমে এটি উপলব্ধ করে। ইস্যু করা সার্টিফিকেটগুলি সাধারণত CRL Distribution Points এক্সটেনশনের মাধ্যমে সেই অবস্থানগুলিকে নির্দেশ করে, যা একটি ভ্যালিডেটরকে স্ট্যাটাসের তথ্য কোথায় রয়েছে তা খুঁজে বের করতে দেয়।

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

কিছু PKI পরিবেশ ডেল্টা CRL-ও ব্যবহার করে। একটি ডেল্টাতে একটি বেস CRL-এর পর থেকে হওয়া পরিবর্তনগুলি থাকে, যা সম্পূর্ণ তালিকাটি বড় হলে স্থানান্তর এবং প্রক্রিয়াকরণের কাজ কমাতে পারে। তবে এই দক্ষতা বেস তালিকা পরিচালনা করা, সিগনেচার যাচাই করা, নতুনত্ব ট্র্যাক করা, বা প্রতিটি নেটওয়ার্ক উপাদান নির্বাচিত প্রকাশনা মডেলটি বুঝতে পারছে কিনা তা নিশ্চিত করার প্রয়োজনীয়তা দূর করে না।

তাজা থাকার সময়সীমা

যুক্তরাজ্যের (UK) নীতিগুলো প্রপাগেশন সম্পর্কে চিন্তা করার জন্য দরকারী রেফারেন্স পয়েন্ট প্রদান করে। UK সরকারের CVCA প্র্যাকটিস স্টেটমেন্ট অনুযায়ী অনধিক প্রতি ৯০ দিন পর পর CRL ইস্যু করা প্রয়োজন, এবং একটি রিভোকড সার্টিফিকেট রিভোকেশনের ৭২ ঘণ্টার মধ্যে সংশ্লিষ্ট CRL-এ দৃশ্যমান হতে হবে। এই সীমাবদ্ধতাগুলো UK national certificate policy-তে বর্ণনা করা হয়েছে।

অন্যান্য UK পলিসিগুলো ভিন্ন ধরনের সার্ভিস প্রত্যাশা ব্যবহার করে। HM Land Registry উল্লেখ করে যে বাতিল এবং স্থগিত সার্টিফিকেটের জন্য তাদের রিভোকেশন লিস্ট অবশ্যই প্রতিদিন অন্তত একবার আপডেট করতে হবে, যেখানে University of York-এর সার্টিফিকেট প্র্যাকটিস স্টেটমেন্ট বাতিলকরণ এবং CRL ইস্যু করার মধ্যে সর্বোচ্চ ১০ দিন বিলম্বের কথা বলে। এই উদাহরণগুলো, যার মধ্যে HMPO Country Signing Certificate Authority পাবলিকেশন পয়েন্ট অন্তর্ভুক্ত, দেখায় যে কেন একজন অ্যাডমিনিস্ট্রেটরকে প্রতিটি CRL অভিন্ন আচরণ করবে তা ধরে না নিয়ে ইস্যুকারী CA-এর প্রকৃত পলিসি পড়তে হবে।

অথেন্টিকেশনের সময়, RADIUS সার্ভার তার স্থানীয়ভাবে উপলব্ধ CRL-এর সাথে সার্টিফিকেটের সিরিয়াল চেক করে। এটি আরও পরীক্ষা করে যে CRL-টি তার মেয়াদের মধ্যে আছে কিনা, সিগনেচার চেইনটি প্রত্যাশিত ইস্যুকারীর সাথে মিলে কিনা এবং রিফ্রেশ করার সময় ডিস্ট্রিবিউশন পয়েন্টে পৌঁছানো যায় কিনা। সার্ভার তখন তার বাস্তবায়ন এবং CRL-এর nextUpdate মান অনুযায়ী ফলাফল ক্যাশ করে রাখে।

এটি জটিল গণিত ছাড়াই একটি বাস্তবসম্মত ঝুঁকির সমীকরণ তৈরি করে: রিভোকেশন ল্যাটেন্সির মধ্যে CA প্রকাশের সময়, ডিস্ট্রিবিউশন বিলম্ব, ক্যাশ স্থায়িত্ব এবং অথেন্টিকেশনের ফ্রিকোয়েন্সি অন্তর্ভুক্ত থাকে। একটি পলিসি দ্রুত প্রকাশ করতে পারে, কিন্তু একটি ডিসকানেক্টেড বা বাসি RADIUS ক্যাশ তবুও এটি কার্যকরের ক্ষেত্রে বিলম্ব ঘটাতে পারে।

CRL বনাম OCSP এবং WiFi-তে কেন এটি গুরুত্বপূর্ণ

CRL এবং OCSP একই মৌলিক সমস্যার সমাধান ভিন্ন উপায়ে করে। একটি CRL ভ্যালিডেটরকে রিভোক করা সিরিয়াল নম্বরগুলির একটি সাইন করা ব্যাচ প্রদান করে। OCSP চেক করার সময়ে একটি নির্দিষ্ট সার্টিফিকেটের স্ট্যাটাস জানার জন্য একজন অনুমোদিত রেসপন্ডারের কাছে জিজ্ঞাসা করে।

একটি এন্টারপ্রাইজ WiFi অ্যাডমিনিস্ট্রেটরের জন্য, এই পছন্দটি কেবল PKI দক্ষতার চেয়েও বেশি কিছুকে প্রভাবিত করে। এটি একটি ভিড়যুক্ত WAN জুড়ে কীভাবে একটি কন্ট্রোলার আচরণ করে, CA ইনফ্রাস্ট্রাকচারকে কী পরিচালনা করতে হবে এবং যখন একটি রেসপন্ডার বা ডিস্ট্রিবিউশন পয়েন্ট অ্যাক্সেস করা যায় না তখন একটি অথেনটিকেশন প্রচেষ্টা সম্পন্ন হতে পারে কিনা তা পরিবর্তন করে।

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

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

OCSP এমন একটি ডিজাইনের জন্য উপযুক্ত হতে পারে যেখানে অপারেটরের প্রতি-সার্টিফিকেট উত্তরের প্রয়োজন হয় এবং রেসপন্ডারের উপর নির্ভরতা স্বীকার করে নেয়। এটি সম্পূর্ণ তালিকা স্থানান্তরের প্রয়োজনীয়তা কমাতে পারে, তবে এটি অথেন্টিকেশনের সময় একটি লাইভ নেটওয়ার্ক নির্ভরতা তৈরি করে। স্ট্যাপলিং কিছু প্রোটোকলে রেসপন্ডার ইন্টারঅ্যাকশনকে অন্য কোথাও সরিয়ে নিয়ে যেতে পারে, তবুও WiFi ডিজাইনে অনুপলব্ধ বা বাসি স্ট্যাটাস ডেটার জন্য একটি স্পষ্ট উত্তরের প্রয়োজন রয়েছে।

UK-এর নির্দেশিকা এখানে বেশ উপযোগী কারণ এটি CRL-কে একমাত্র পদ্ধতি হিসেবে উপস্থাপন করে না। UK-এর নীতিতে CRL-কে সাধারণ বাতিলকরণ প্রক্রিয়াগুলির একটি হিসেবে বর্ণনা করা হয়েছে, যেখানে বিচার বিভাগীয় নির্দেশিকা এটিকে একটি প্রাথমিক অফলাইন প্রক্রিয়া হিসেবে বিবেচনা করে এবং PKI disclosure statement-এ বাতিলকরণ পরিষেবাগুলির উপলব্ধতার প্রয়োজনীয়তার ওপর জোর দেয়।

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

একটি Purple WiFi নেটওয়ার্কে বাস্তবে রিভোকেশন প্রক্রিয়া

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

একটি সাধারণ ফ্লো এইরকম দেখায়:

1. ডিরেক্টরি আইডেন্টিটি স্টেট রেকর্ড করে। Active Directory, Entra ID, অথবা Google Workspace-এ একটি অ্যাকাউন্ট তৈরি, পরিবর্তন, স্থগিত বা নিষ্ক্রিয় করা হয়।
2. WiFi আইডেন্টিটি সার্ভিস পরিবর্তনটি গ্রহণ করে। এই সার্ভিস ডিরেক্টরি স্টেটকে প্রতিষ্ঠানের অথেন্টিকেশন পলিসির সাথে ম্যাপ করে।
3. পরবর্তী অথেন্টিকেশন সেই স্টেটের বিপরীতে যাচাই করা হয়। একটি নিষ্ক্রিয় আইডেন্টিটি আর অ্যাক্সেস রুল পূরণ করে না, এমনকি যদি পূর্বে ইস্যু করা ক্রেডেনশিয়াল তার সার্টিফিকেটের মেয়াদের মধ্যে থাকে তবুও।
4. নেটওয়ার্ক অ্যাক্সেস প্রত্যাখ্যান করে। RADIUS সিদ্ধান্ত নিষ্ক্রিয় আইডেন্টিটির অধীনে একটি নতুন 802.1X সেশন অথরাইজড হতে বাধা দেয়।

এই মডেলটি শুধুমাত্র CRL-ভিত্তিক অপারেশনের একটি দুর্বলতার সমাধান করে। একটি CRL নির্ভর করে CA পাবলিকেশন, ডিস্ট্রিবিউশন পয়েন্ট, ক্যাশ রিফ্রেশ এবং রিল্যায়িং পার্টির চেকিংয়ের উপর। ডিরেক্টরি-চালিত এনফোর্সমেন্ট আইডেন্টিটি সিস্টেমকে অ্যাকাউন্টের স্ট্যাটাসের জন্য অপারেশনাল সোর্স অফ ট্রুথ হিসেবে তৈরি করে, যা একজন বিদায়ী ব্যবহারকারীর সাথে সম্পর্কিত প্রতিটি সার্টিফিকেট সিরিয়াল খুঁজে বের করার অ্যাডমিনিস্ট্রেটরের প্রয়োজনীয়তা হ্রাস করে।

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

Purple ডিরেক্টরি ইন্টিগ্রেশনের সাথে ম্যানেজড RADIUS এবং সার্টিফিকেট-ভিত্তিক এন্টারপ্রাইজ WiFi নিয়ন্ত্রণ প্রদান করে, যেমন Microsoft Entra ID এবং Google Workspace। যেখানে কোনো সংস্থা প্রতিটি অন-প্রিমিসেস RADIUS এবং বাতিলকরণ উপাদান নিজে রক্ষণাবেক্ষণ না করেই 802.1X অথেন্টিকেশনের সাথে পরিচয়ের স্ট্যাটাস সংযুক্ত করতে চায়, সেখানে এর RADIUS-as-a-Service সুবিধাটি প্রাসঙ্গিক।

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

এন্টারপ্রাইজ WiFi-এর জন্য কার্যকরী সেরা অনুশীলনগুলি

একটি নির্ভরযোগ্য রেভোকেশন ডিজাইন সাধারণ অপারেশনাল শৃঙ্খলার সাথে ক্রিপ্টোগ্রাফিক নিয়ন্ত্রণকে একত্রিত করে। সার্টিফিকেটের মেয়াদ দিয়ে শুরু করুন। ম্যানেজড WiFi ডিভাইসের জন্য, সরবরাহকৃত ডেপ্লয়মেন্ট নির্দেশিকায় সাধারণত ১২ থেকে ২৪ মাস মেয়াদের সার্টিফিকেট ব্যবহারের পরামর্শ দেওয়া হয়, তবে সঠিক সিদ্ধান্তটি ডিভাইসের মালিকানা, রিনিউয়াল করার ক্ষমতা এবং একটি এক্সপোজড প্রাইভেট কি যে ক্ষতি করতে পারে তার উপর নির্ভর করে। গেস্ট স্পন্সর সার্টিফিকেটের মেয়াদ সাধারণত আরও কম হওয়া উচিত কারণ তাদের অ্যাক্সেসের প্রসঙ্গ ঘন ঘন পরিবর্তিত হয়।

ডিভাইস লাইফসাইকেলের মধ্যে রিনিউয়াল যুক্ত করুন

সার্টিফিকেটগুলির মেয়াদ শেষ হওয়ার আগে সেগুলি রিনিউ করতে SCEP, একটি MDM প্ল্যাটফর্ম, বা অন্য কোনও স্বয়ংক্রিয় তালিকাভুক্তি পথ ব্যবহার করুন। ম্যানুয়াল রিনিউয়াল একটি পাইলট প্রকল্পের সময় কাজ করলেও একটি বিস্তৃত এস্টেট জুড়ে তা ভঙ্গুর হয়ে পড়ে। স্লিপ মোডে থাকা ল্যাপটপ, রিমোট ডিভাইস, পুনর্নির্মিত ডিভাইস এবং যে ডিভাইসগুলি সম্প্রতি কর্পোরেট নেটওয়ার্কের সাথে সংযুক্ত হয়নি সেগুলিতে রিনিউয়াল প্রক্রিয়া পরীক্ষা করুন।

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

RADIUS সাইটটি পরিষ্কার রাখুন

RADIUS সার্ভার সার্টিফিকেটের বর্তমান মেয়াদ, একটি বিশ্বস্ত ইস্যুয়িং চেইন এবং এমন একটি রিনিউয়াল প্রসেস থাকা প্রয়োজন যা শেষ মুহূর্তের মেইনটেইন্যান্স উইন্ডোর ওপর নির্ভর করে না। সার্ভার, কন্ট্রোলার এবং ম্যানেজড ক্লায়েন্টদের ট্রাস্ট স্টোরগুলো পর্যালোচনা করুন যাতে একটি পুরোনো CA সার্টিফিকেট বিভিন্ন সাইটে অসঙ্গতিপূর্ণ সিদ্ধান্তের কারণ না হয়ে দাঁড়ায়।

অন-কল ইঞ্জিনিয়ার অনুসরণ করতে পারেন এমন ভাষায় রেভোকেশন রানবুকটি নথিভুক্ত করুন:

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

HR ট্রিগারগুলিকে ডিরেক্টরি পরিবর্তনের সাথে সামঞ্জস্যপূর্ণ করুন। সার্ভিস ডেস্ককে যদি একটি পৃথক PKI টিকেটের জন্য অপেক্ষা করতে হয়, তবে নেটওয়ার্ক এমন একটি পরিচয়কে বিশ্বাস করা চালিয়ে যেতে পারে যাকে সংস্থা ইতিমধ্যেই নিষ্ক্রিয় হিসেবে চিহ্নিত করেছে। স্বয়ংক্রিয় প্রোভিশনিং এবং রিনিউয়াল এই অসঙ্গতি কমিয়ে দেয়, এবং চুরি হওয়া ডিভাইস বা সন্দেহজনক কী আপোষের ক্ষেত্রে একটি নথিভুক্ত ম্যানুয়াল পথ অত্যন্ত গুরুত্বপূর্ণ থাকে।

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

সাধারণ রিভোকেশন সমস্যাগুলির সমাধান করা

অধিকাংশ CRL ঘটনা তিনটি বিভাগের মধ্যে পড়ে: ভ্যালিডেটরের কাছে পুরানো তথ্য রয়েছে, এটি সঠিক পাবলিকেশন পয়েন্ট খুঁজে পাচ্ছে না, অথবা রিভোকেশন স্টোর পরিচালনা করা কঠিন হয়ে পড়েছে। সার্টিফিকেট পুনরায় ইস্যু করার মাধ্যমে শুরু করার পরিবর্তে সিদ্ধান্তের পথটি নির্ণয় করুন।

একটি বাসি লোকাল ক্যাশে

একটি RADIUS সার্ভার বা কন্ট্রোলার এখনও একটি CRL ধরে রাখতে পারে যা রিভোকেশনের পূর্বের হতে পারে। CRL-এর thisUpdate এবং nextUpdate ফিল্ডগুলি নিশ্চিত করুন, ইস্যুকারী CA-এর বিপরীতে এর সিগনেচার যাচাই করুন এবং প্রমাণীকরণকারীতে ক্যাশ করা কপিটি পরীক্ষা করুন। ক্লায়েন্ট দ্বারা উপস্থাপিত সিরিয়াল নম্বরের সাথে নতুন প্রকাশিত CRL-এর এন্ট্রিগুলি তুলনা করুন।

তাত্ক্ষণিক সমাধান হলো প্ল্যাটফর্মটি সমর্থন করলে একটি CRL রিফ্রেশ জোরপূর্বক করা, তারপর প্রভাবিত সার্টিফিকেট দিয়ে একটি অথেনটিকেশন পরীক্ষা পুনরাবৃত্তি করা। যদি ক্যাশ ক্রমাগত পুরানো ডেটা ফেরত দিতে থাকে, তবে প্রক্সি আচরণ, ডিস্ট্রিবিউশন-পয়েন্ট ক্যাশিং এবং ভ্যালিডেটরের রিফ্রেশ পলিসি পরীক্ষা করুন।

একটি অনুপস্থিত ডিস্ট্রিবিউশন পয়েন্ট

ইস্যু করা সার্টিফিকেটের CDP এবং AIA এক্সটেনশনগুলো পড়ুন। CDP রিলায়িং পার্টিকে জানায় যে কোথায় রিভোকেশন সংক্রান্ত তথ্য পাওয়া যাবে, অন্যদিকে AIA চেইন ভ্যালিডেশনের জন্য প্রয়োজনীয় ইস্যুকারী সংক্রান্ত তথ্য সনাক্ত করতে সাহায্য করতে পারে। URL-টি সঠিক কিনা, RADIUS নেটওয়ার্ক থেকে অ্যাক্সেসযোগ্য কিনা এবং প্রত্যাশিত ইস্যুকারী দ্বারা স্বাক্ষরিত একটি CRL প্রদান করছে কিনা তা নিশ্চিত করুন।

যদি CA টেমপ্লেটে ভুল লোকেশন থাকে, তবে টেমপ্লেটটি সংশোধন করুন এবং প্রতিস্থাপন সার্টিফিকেট ইস্যু করুন। শুধুমাত্র এন্ডপয়েন্ট আপডেট করলে সেই সার্টিফিকেটগুলি মেরামত হবে না যেগুলিতে ইতিমধ্যেই একটি অব্যবহারযোগ্য ডিস্ট্রিবিউশন পয়েন্ট রয়েছে।

একটি অনিয়ন্ত্রিত রেভোকেশন স্টোর

পুরোনো এন্ট্রিগুলো অ্যাডমিনিস্ট্রেশনকে জটিল করতে পারে এবং প্রসেসিংয়ের কাজ বাড়িয়ে দিতে পারে। এন্ট্রিগুলো কেবল CA-এর রিটেনশন পলিসি অনুযায়ী এবং সংশ্লিষ্ট সার্টিফিকেটের লাইফটাইম ও অডিট প্রয়োজনীয়তাগুলো বিবেচনা করার পরেই ছাঁটাই করুন। ইনসিডেন্ট টিকিট বন্ধ হয়ে গেছে বলেই কোনো সিরিয়াল নম্বর মুছে ফেলবেন না।

যুক্তরাজ্যের পলিসির উদাহরণগুলো দেখায় যে কেন "ফ্রেশ" বা সাম্প্রতিক তথ্যকে স্থানীয়ভাবে সংজ্ঞায়িত করা উচিত। যুক্তরাজ্যের কিছু অথরিটির দৈনিক আপডেটের প্রয়োজন হয়, যেখানে জাতীয় CVCA পলিসির জন্য একটি রিভোক করা সার্টিফিকেটের ক্ষেত্রে ৭২ ঘণ্টার মধ্যে এটি প্রকাশ করা আবশ্যক এবং একটি সর্বোচ্চ ৯০ দিনের ইস্যু করার মেয়াদ নির্ধারণ করা থাকে। এগুলোকে পলিসির বেসলাইন হিসেবে বিবেচনা করুন, বাসি এন্টারপ্রাইজ ডেটা গ্রহণ করার অনুমতি হিসেবে নয়।

একটি সার্টিফিকেট বিশ্লেষণ টুল ইস্যুকারী, বৈধতা, CDP এবং চেইন বিবরণ পরীক্ষা করতে সাহায্য করতে পারে। সার্টিফিকেটের কার্যকারিতা পরীক্ষা করার জন্য Purple-এর SSL certificate checker একটি বিকল্প হতে পারে, অন্যদিকে ডিরেক্টরি চালিত প্রয়োগ ব্যবহারকারী অফবোর্ডিংয়ের জন্য শুধুমাত্র একটি বিলম্বিত CRL রিফ্রেশের উপর নির্ভর করা এড়াতে পারে।

এই সপ্তাহে সব একসাথে করা হচ্ছে

রিভোকেশনকে কেবল একটি নীতিমালার অনুচ্ছেদ হিসেবে না রেখে একটি নির্দিষ্ট দায়িত্বে পরিণত করুন। এই কাজগুলিকে পরবর্তী পরিবর্তন উইন্ডোতে অন্তর্ভুক্ত করুন এবং প্রতিটির জন্য একজন নামধারী মালিক নিযুক্ত করুন।

• PKI টিম, সার্টিফিকেট পাথ অডিট করুন: প্রতিটি WiFi ক্লায়েন্ট সার্টিফিকেট টেমপ্লেট, ইস্যুকারী CA, CDP এবং RADIUS ট্রাস্ট সম্পর্ক তালিকাভুক্ত করুন। প্রতিটি অথেনটিকেশন সাইট থেকে প্রতিটি ডিস্ট্রিবিউশন পয়েন্ট অ্যাক্সেসযোগ্য কিনা তা নিশ্চিত করুন।
• PKI এবং এন্ডপয়েন্ট টিম, একটি সমর্থনযোগ্য লাইফটাইম নির্ধারণ করুন: ডিভাইস রিনিউয়াল প্রক্রিয়া যেখানে এটি সমর্থন করে সেখানে WiFi ক্লায়েন্ট সার্টিফিকেট ১২ মাস বা তার কম সময়ের দিকে নিয়ে যান। সংক্ষিপ্ত লাইফটাইম জরুরি রিভোকেশন-এর উপর নির্ভরতা কমায়, তবে এটি কেবল তখনই কার্যকর যদি রিনিউয়াল স্বয়ংক্রিয় এবং পরীক্ষিত হয়।
• এন্ডপয়েন্ট টিম, রিনিউয়াল স্বয়ংক্রিয় করুন: ব্যবহারকারীর হস্তক্ষেপ ছাড়াই সার্টিফিকেট তালিকাভুক্ত এবং রিনিউ করতে MDM বা SCEP ব্যবহার করুন। ডিভাইস রিবিল্ড, দীর্ঘ সময় অফলাইন থাকা এবং ব্যবহারকারী পরিবর্তনের পর প্রক্রিয়াটি পরীক্ষা করুন।
• সার্ভিস ডেস্ক এবং আইডেন্টিটি টিম, অফবোর্ডিং-কে অ্যাক্সেস ডিনায়ালের সাথে সংযুক্ত করুন: HR বা সার্ভিস-ডেস্কের নিষ্ক্রিয় অবস্থা সরাসরি WiFi অথেনটিকেশনে ব্যবহৃত ডিরেক্টরি নিয়ন্ত্রণের সাথে যুক্ত করুন। যাচাই করুন যে একটি নিষ্ক্রিয় আইডেন্টিটি যেন নতুন কোনো 802.1X সেশন স্থাপন করতে না পারে।
• নেটওয়ার্ক টিম, রিভোকেশন নির্ভরতা মনিটর করুন: অনুপলব্ধ ডিস্ট্রিবিউশন পয়েন্ট, মেয়াদোত্তীর্ণ CRL, অবৈধ স্বাক্ষর এবং ব্যর্থ স্ট্যাটাস চেকের ক্ষেত্রে অ্যালার্ট সেট করুন। CA পরিবর্তন বিজ্ঞপ্তিতে সাবস্ক্রাইব করুন যাতে কোনো পাবলিকেশন পরিবর্তন অলক্ষ্যে অথেনটিকেশনের মান হ্রাস না করে।

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

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