একটি সোমবার সকালের আউটপুট খুব কমই একটি নাটকীয় PKI ব্যর্থতার সাথে শুরু হয়। এটি এমন একটি সার্টিফিকেটের মাধ্যমে শুরু হয় যার অস্তিত্ব সম্পর্কে কেউ জানত না। একটি WiFi অথেন্টিকেশন সার্ভারে RADIUS সার্টিফিকেট উইকএন্ডে এক্সপায়ার হয়ে যায়, প্রথম শিফটের কর্মীরা পৌঁছায় এবং শত শত ব্যবহারকারী কানেক্ট করতে পারেন না। অন-কল ইঞ্জিনিয়ার আসল কারণটি আবিষ্কার করার আগে ড্যাশবোর্ড, ভেন্ডর পোর্টাল, পুরানো স্প্রেডশিট এবং সার্ভার স্টোরগুলিতে খোঁজ করেন।
সেই ঘটনাটি প্রশ্নটিকে বদলে দেয়। কীভাবে সার্টিফিকেট পরিচালনা করবেন তা মূলত কি জেনারেট করা বা রিনিউ ক্লিক করার প্রশ্ন নয়। এটি নেটওয়ার্ক, আইডেন্টিটি, অ্যাপ্লিকেশন এবং ডিভাইস টিম জুড়ে ভিজিবিলিটি, ওনারশিপ, ডিপেন্ডেন্সি এবং নির্ভরযোগ্য অ্যাকশনের একটি প্রশ্ন। একটি সার্টিফিকেট লাইফসাইকেল কেবল তখনই কাজ করে যখন কেউ প্রতিটি সার্টিফিকেট সনাক্ত করতে পারে, এটির উপর কী নির্ভর করে তা বুঝতে পারে এবং এটি প্রতিস্থাপনের জন্য দায়ী ব্যক্তি বা অটোমেশনের কাছে পৌঁছাতে পারে।
কেন সার্টিফিকেট স্প্রল আসল সমস্যা
মিশ্র অবকাঠামো বিশিষ্ট সংস্থাগুলোতে সার্টিফিকেটের বিস্তার স্বাভাবিকভাবেই ঘটে। নেটওয়ার্ক ইঞ্জিনিয়াররা RADIUS এবং VPN সার্টিফিকেট পরিচালনা করেন। সিকিউরিটি টিম SAML এবং OIDC সাইনিং সার্টিফিকেট তদারকি করে। DevOps টিম ক্লাউড প্ল্যাটফর্ম বা CI/CD পাইপলাইনের মাধ্যমে অ্যাপ্লিকেশন TLS সার্টিফিকেট ইস্যু করে। আইটি অ্যাডমিনিস্ট্রেটররা এন্ডপয়েন্ট ম্যানেজমেন্ট সিস্টেমের মাধ্যমে ডিভাইস এনরোলমেন্ট সার্টিফিকেট প্রভিশন করেন।
প্রতিটি টিম আলাদাভাবে বুদ্ধিমানের সাথে কাজ করতে পারে এবং তারপরেও এমন একটি এস্টেট তৈরি করতে পারে যা সামগ্রিকভাবে কেউ দেখতে পায় না।
বাস্তবসম্মত নিয়ম: প্রতিটি সার্টিফিকেটকে একটি প্রোডাকশন ডিপেনডেন্সি হিসাবে বিবেচনা করুন, সার্ভারে থাকা কোনো সাধারণ ফাইল হিসাবে নয়।
স্প্রেডশিটগুলো ব্যর্থ হয় কারণ সেগুলো কেবল কেউ যা মনে রেখেছে তা রেকর্ড করে, পরিবেশটি আসলে কী ব্যবহার করছে তা নয়। এগুলো খুব কমই স্বয়ংক্রিয়ভাবে সার্টিফিকেট সনাক্ত করে, লিফ সার্টিফিকেট থেকে ইন্টারমিডিয়েট এবং রুট CA পর্যন্ত চেইনটিকে নির্ভরযোগ্যভাবে উপস্থাপন করে না এবং একটি সার্টিফিকেট দ্বিতীয় কোনো লোড ব্যালেন্সার, অ্যাপ্লায়েন্স বা ভেন্ডর-ম্যানেজড সার্ভিসে কপি করা হয়েছে কিনা তা আপনাকে জানাতে পারে না। একটি স্প্রেডশিট রিভিউ করার ক্ষেত্রে সহায়তা করতে পারে, কিন্তু এটি এমন কোনো সিস্টেম হওয়া উচিত নয় যা আপনাকে কোনো বিভ্রাট সম্পর্কে সতর্ক করে।
অপারেশনাল ঝুঁকি UK রিপোর্টিংয়ে স্পষ্টভাবে প্রমাণিত হয়েছে। জরিপকৃত উত্তরদাতাদের মধ্যে মাত্র ৩৪% এর কাছে তাদের ডিজিটাল সার্টিফিকেটের একটি সম্পূর্ণ ও আপ-টু-ডেট ভিউ ছিল, যেখানে ৭৪% মেয়াদ শেষ হওয়া সার্টিফিকেটের কারণে সৃষ্ট বিভ্রাট নিয়ে অত্যন্ত বা মারাত্মকভাবে উদ্বিগ্ন ছিলেন। একই রিপোর্টে দেখা গেছে যে ৫১% উত্তরদাতা সাইলো করা টুলগুলোকে একটি বড় চ্যালেঞ্জ হিসেবে উল্লেখ করেছেন, এবং ৪৭% জরিপকৃত লিডাররা ম্যানুয়াল ট্র্যাকিংয়ের জন্য এখনও স্প্রেডশিটের ওপর নির্ভর করেন। এই পরিসংখ্যানগুলো UK certificate visibility and sprawl reporting থেকে নেওয়া হয়েছে।
দীর্ঘ এবং সংক্ষিপ্ত লাইফটাইমের মধ্যে আপস-মীমাংসা
দীর্ঘমেয়াদী সার্টিফিকেট রক্ষণাবেক্ষণের কাজ কমিয়ে দেয়। তবে তারা একটি বড় উইন্ডোও তৈরি করে যার মধ্যে একটি আপস করা প্রাইভেট কি কার্যকর থেকে যেতে পারে এবং একটি ভুলে যাওয়া সার্টিফিকেট অলক্ষ্যে পড়ে থাকতে পারে যতক্ষণ না একটি সম্পর্কহীন সিস্টেম পরিবর্তন এটিকে প্রকাশ করে।
স্বল্পস্থায়ী সার্টিফিকেট সেই ঝুঁকি কমায়, তবে তার জন্য নির্ভরযোগ্য অটোমেশন প্রয়োজন। রিনিউয়ালের ক্ষেত্রে অবশ্যই একটি নতুন কি (key) তৈরি হতে হবে, প্রতিস্থাপন সার্টিফিকেট পেতে হবে, সম্পূর্ণ চেইন বিতরণ করতে হবে, সঠিক এন্ডপয়েন্টে ডেপ্লয় করতে হবে এবং ক্লায়েন্টরা নতুন ফলাফলকে ট্রাস্ট করছে কিনা তা যাচাই করতে হবে। UK DWP PKI standard রুট, পলিসি, সাবঅর্ডিনেট এবং এন্ড-এন্টিটি কি-এর জন্য ভিন্ন ভিন্ন সর্বোচ্চ লাইফটাইম নির্ধারণ করে, যা ব্যাখ্যা করে যে কেন একটি একক পলিসি সাধারণত প্রতিটি সার্টিফিকেট ক্লাসের ক্ষেত্রে কাজ করে না।
তাই প্রথম বাস্তবসম্মত পদক্ষেপ অটোমেশন নয়। এটি হল একটি একীভূত ইনভেন্টরি যা ডিসকভারি, মালিকানা, ডিপেন্ডেন্সি, ঝুঁকির শ্রেণীবিভাগ এবং ডেপ্লয়মেন্টের প্রমাণকে একত্রিত করে। সেই ভিত্তি ছাড়া, অটোমেশন কেবল সেই সার্টিফিকেটগুলোই রিনিউ করে যা একটি টুল দেখতে পায়, যেখানে শ্যাডো সার্টিফিকেটগুলো অন্য কোথাও পুরনো হতে থাকে।
একটি সম্পূর্ণ সার্টিফিকেট ইনভেন্টরি তৈরি করা
একটি প্রোডাকশন ইনভেন্টরি ডিসকভারি দিয়ে শুরু হয়, ম্যানুয়াল ডেটা এন্ট্রি দিয়ে নয়। আপনার অর্গানাইজেশন পরিচালনা করে এমন সার্ভিসগুলোর বিরুদ্ধে অথেনটিকেটেড স্ক্যান চালান, যার মধ্যে TLS এবং ডিরেক্টরি-সার্ভিস এন্ডপয়েন্টগুলো অন্তর্ভুক্ত, তারপর সার্টিফিকেট ইস্যু বা সংরক্ষণ করা প্ল্যাটফর্মগুলোকে কোয়েরি করুন। নেটওয়ার্ক স্ক্যানগুলো 443, 636, 8443, এবং 1812-এর মতো পোর্টে এক্সপোজড সার্টিফিকেট শনাক্ত করতে পারে। সার্ভার-সাইড কালেকশনের ক্ষেত্রে Windows সার্টিফিকেট স্টোর, Linux ফাইলসিস্টেম লোকেশন, Java কি-স্টোর, রিভার্স প্রক্সি, লোড ব্যালেন্সার, ফায়ারওয়াল, ওয়্যারলেস কন্ট্রোলার এবং ম্যানেজড অ্যাপ্লায়েন্সগুলো পরীক্ষা করা উচিত।
ডিরেক্টরি সার্ভিসগুলোকে একটি পৃথক ডিসকভারি সোর্স হিসাবে বিবেচনা করুন। Microsoft Entra ID, Active Directory, Google Workspace, Okta এবং এন্ডপয়েন্ট ম্যানেজমেন্ট প্ল্যাটফর্মগুলোতে সার্টিফিকেট অবজেক্ট এবং প্রোফাইলগুলো কোয়েরি করুন। একটি সার্টিফিকেট কোনো লিসেনিং পোর্টে কখনই প্রদর্শিত নাও হতে পারে, তবুও সেটি ডিভাইস অথেনটিকেশন বা WiFi অ্যাক্সেস নিয়ন্ত্রণ করতে পারে। নেটওয়ার্ক ভেন্ডররা আরেকটি ব্লাইন্ড স্পট তৈরি করে: ওয়্যারলেস কন্ট্রোলার, ফায়ারওয়াল, VPN গেটওয়ে এবং RADIUS প্ল্যাটফর্মগুলোর প্রতিটির কাছে আলাদা রিনিউয়াল প্রক্রিয়া এবং মালিকানা সহ তাদের নিজস্ব কপি থাকতে পারে।
অ্যাসাইন করার আগে নরমালাইজ করুন
ডিসকভারি টুলগুলি বেমানান ফর্ম্যাট প্রদান করে। তাদের ফলাফলগুলিকে প্রতি সার্টিফিকেটের জন্য একটি রেকর্ডে রূপান্তর করুন, তারপর যেখানে উপযুক্ত সেখানে সিরিয়াল নম্বর, ফিঙ্গারপ্রিন্ট এবং পাবলিক-কী আইডেন্টিটি ব্যবহার করে ডুপ্লিকেটগুলি সরান। একটি অব্যবহৃত ফাইলকে একটি সক্রিয় প্রোডাকশন নির্ভরতা থেকে আলাদা করার জন্য যথেষ্ট প্রসঙ্গ রাখুন। প্রদানকারী এবং ডিসকভারি পদ্ধতিও রেকর্ড করুন, যাতে একটি অনুপস্থিত ফলাফলকে অনুপস্থিতি হিসেবে ভুল না করে একটি উৎস সিস্টেমের মাধ্যমে সনাক্ত করা যায়।
| ক্ষেত্র | উদাহরণের মান | উদ্দেশ্য |
|---|---|---|
| Subject | সার্ভিস বা ডিভাইসের পরিচয় | সার্টিফিকেট বিষয়বস্তু শনাক্ত করে |
| Issuer | ইন্টারমিডিয়েট CA-এর নাম | কোন অথরিটি এটি স্বাক্ষর করেছে তা দেখায় |
| SANs | DNS, ইমেল, URI, বা ডিভাইসের আইডেন্টিফায়ারসমূহ | ক্লায়েন্টরা যে পরিচয়গুলো যাচাই করে তা রেকর্ড করে |
| Key usage | সার্ভার অথেন্টিকেশন বা ক্লায়েন্ট অথেন্টিকেশন | ভুল ভূমিকায় ব্যবহার প্রতিরোধ করে |
| Expiration | বৈধতার শেষ তারিখ | রিনিউয়াল পরিকল্পনার দিকনির্দেশনা দেয় |
| Serial number | CA-কর্তৃক ইস্যুকৃত আইডেন্টিফায়ার | অডিট এবং রিভোকেশন সমর্থন করে |
| Storage location | সার্ভার স্টোর, অ্যাপ্লায়েন্স, ডিরেক্টরি প্রোফাইল, বা ভল্ট | কোথায় প্রতিস্থাপন করতে হবে তা দেখায় |
| Owner and contact | নির্দিষ্ট টিম এবং এসকেলেশন কন্টাক্ট | পদক্ষেপ গ্রহণ করা সম্ভব করে তোলে |
| Dependency chain | ইন্টারমিডিয়েট এবং রুট সম্পর্কসমূহ | শেয়ার্ড ফেইলিওর পয়েন্টগুলো প্রকাশ করে |
| Status | অ্যাক্টিভ, স্টেজড, এক্সপায়ার্ড, রিভোকড, বা অব্যবহৃত | ঐতিহাসিক বিশৃঙ্খলা থেকে ঝুঁকিকে আলাদা করে |
মালিকানা নির্ধারণ করে যে একটি ইনভেন্টরি কোনো পদক্ষেপ গ্রহণ করাতে পারে কিনা। "নেটওয়ার্ক" বা "আইটি" দিয়ে এটি চিহ্নিত করা যায় না যে কে পরিবর্তন অনুমোদন করে, ডেপ্লয়মেন্ট সম্পন্ন করে, বা ব্যর্থতায় সাড়া দেয়। একজন সার্ভিস ওনার, অপারেশনাল টিম, এস্কেলেশন কন্ট্যাক্ট এবং বিজনেস ক্রিটিক্যালিটি নির্ধারণ করুন। যদি একটি RADIUS সার্টিফিকেট স্টাফ WiFi-কে সাপোর্ট করে, তবে নেটওয়ার্ক সার্ভিস, ব্যাকআপ অপারেটর, প্ল্যাটফর্ম ওনার এবং ডেপ্লয়মেন্টের অনুমোদনকারী পরিবর্তন প্রক্রিয়ার লেখককে রেকর্ড করুন।
চেইনগুলো ম্যাপ করুন এবং ঝুঁকি ক্লাসিফাই করুন
একটি লিফ (leaf) সার্টিফিকেট ব্যর্থ হতে পারে কারণ এটির মেয়াদ শেষ হয়ে গেছে, সার্ভার একটি ইন্টারমিডিয়েট বাদ দিয়েছে, অথবা কোনো ক্লায়েন্ট আর রুটকে বিশ্বাস করে না। প্রতিটি লিফকে তার ইন্টারমিডিয়েটের সাথে এবং প্রতিটি ইন্টারমিডিয়েটকে তার রুটের সাথে ম্যাপ করুন। তারপর শেয়ার্ড ডিপেন্ডেন্সিগুলো ফ্ল্যাগ করুন। একটি ইন্টারমিডিয়েট CA সম্পর্কহীন পরিষেবাগুলোকে সাপোর্ট করতে পারে, যা এর প্রতিস্থাপনকে ডিরেক্টরি সার্ভিস, সার্ভার এবং নেটওয়ার্ক ভেন্ডর জুড়ে একটি সমন্বিত পরিবর্তনে রূপান্তর করে।
এমন শ্রেণীবিভাগ ব্যবহার করুন যা অপারেশনাল ফলাফলগুলোকে প্রতিফলিত করে:
- প্রোডাকশন-গুরুত্বপূর্ণ: WiFi অথেন্টিকেশন, VPN অ্যাক্সেস, আইডেন্টিটি গেটওয়ে, পেমেন্ট সার্ভিস এবং তাৎক্ষণিক ব্যবহারকারীর প্রভাব সহ অন্যান্য সিস্টেম।
- অ্যাপ্লিকেশন-মুখী: পাবলিক ওয়েব TLS, API, রিভার্স প্রক্সি, ইনগ্রেস কন্ট্রোলার এবং কাস্টমার পোর্টাল।
- অভ্যন্তরীণ: সার্ভিস-টু-সার্ভিস mTLS, মেশিন আইডেন্টিটি, অ্যাডমিনিস্ট্রেটিভ ইন্টারফেস এবং ডেভেলপমেন্ট এনভায়রনমেন্ট।
শ্যাডো সার্টিফিকেটের জন্য একটি পৃথক সমন্বয় প্রক্রিয়ার প্রয়োজন। অ্যাপ্লিকেশন টিম, ম্যানেজড সার্ভিস প্রোভাইডার এবং নেটওয়ার্ক ভেন্ডরদের জিজ্ঞাসা করুন কোথায় প্রাইভেট কি-গুলো সংরক্ষিত আছে, কোন প্রোভাইডার প্রতিটি সার্টিফিকেট ইস্যু করেছে এবং কীভাবে রিনিউয়াল করা হয়। ডিরেক্টরি সার্ভিস রেকর্ড, অ্যাপ্লায়েন্স এক্সপোর্ট এবং স্ক্যানিং ফলাফলের সাথে সেই উত্তরগুলো তুলনা করুন।
একটি সম্পূর্ণ ইনভেন্টরি হলো একটি রক্ষণাবেক্ষণ করা নিয়ন্ত্রণ রেকর্ড, কোনো এককালীন তালিকা নয়। এটি সিস্টেম, ব্যক্তি, প্রদানকারী, নির্ভরশীলতা এবং ডেপ্লয়মেন্ট প্রমাণের সাথে সার্টিফিকেটগুলোকে সংযুক্ত করে, যা প্রতিটি টুলকে কেবল তার নিজের দৃশ্যমান সার্টিফিকেটগুলো পরিচালনা করতে দেওয়ার পরিবর্তে লাইফসাইকেল অটোমেশনকে একটি নির্ভরযোগ্য উৎস প্রদান করে।
ডিরেক্টরি সার্ভিসের মাধ্যমে সার্টিফিকেট ইস্যু এবং প্রভিশন করা
সার্টিফিকেট-ভিত্তিক অ্যাক্সেস ব্যর্থ হওয়া সত্ত্বেও একটি ডিভাইস পরিচালনা করা হচ্ছে বলে দেখাতে পারে। প্রোডাকশনে, সাধারণত সমস্যাটি আইডেন্টিটি, কি জেনারেশন, ট্রাস্ট ইনস্টলেশন এবং সার্ভিস ডিপ্লয়মেন্টের মধ্যে ঘটে থাকে। ইস্যুয়েন্সকে একটি নিয়ন্ত্রিত ওয়ার্কফ্লো হিসাবে বিবেচনা করুন: কি পেয়ার জেনারেট করুন, CSR তৈরি করুন, আইডেন্টিটি এবং পলিসি ভ্যালিডেট করুন, অনুমোদিত CA-র মাধ্যমে সাইন করুন, তারপরে সার্টিফিকেটটি তার চেইন সহ ইনস্টল করুন। যখনই সম্ভব এন্ডপয়েন্টে বা তার কাছাকাছি প্রাইভেট-কি জেনারেশন রাখুন। CSR সেই কি-র অধিকার প্রমাণ করে, তাই কি-টি ইমেল, টিকিটিং সিস্টেম বা শেয়ার্ড অ্যাডমিনিস্ট্রেটর ফোল্ডারের মাধ্যমে পাঠানো উচিত নয়।
Microsoft Entra ID ডেপ্লয়মেন্টে সাধারণত SCEP বা PKCS12 এর সাথে Intune সার্টিফিকেট প্রোফাইল ব্যবহার করা হয়। SCEP ম্যানেজড ডিভাইসের জন্য উপযুক্ত যা তাদের নিজস্ব কি (key) তৈরি করে এবং একটি নিয়ন্ত্রিত কানেক্টরের মাধ্যমে সার্টিফিকেটের অনুরোধ করে। যখন প্রোভিশনিং মডেলের প্রয়োজন হয় তখন PKCS12 একটি সার্টিফিকেট এবং প্রাইভেট কি প্যাকেজ করতে পারে, তবে সেই প্যাকেজটি পরিবহন বা সংরক্ষণ করার জন্য আরও কঠোর নিয়ন্ত্রণের প্রয়োজন হয়। প্রতিটি প্রোফাইলকে ডিভাইস বা ইউজার আইডেন্টিটির সাথে বাইন্ড করুন, কি ব্যবহার নির্ধারণ করুন এবং কেন্দ্রীয় ইনভেন্টরিতে ইস্যুকারী CA এবং ট্রাস্ট চেইন রেকর্ড করুন। এই রেকর্ডটিই একটি প্রোভাইডারের সার্টিফিকেট ভিউকে একমাত্র সোর্স অফ ট্রুথ হতে বাধা দেয়।
Google Workspace পরিবেশের ক্ষেত্রেও পরিচয় এবং সার্টিফিকেটের উপকরণের মধ্যে একই ধরনের পার্থক্যের প্রয়োজন হয়। ম্যানেজড-ডিভাইস পলিসির জন্য Google এন্ডপয়েন্ট ম্যানেজমেন্ট ব্যবহার করুন, তারপর প্রতিটি সার্টিফিকেটকে তার ডিভাইস বা ব্যবহারকারী এবং এটি পরিচালনাকারী পলিসির সাথে যুক্ত করতে ডিরেক্টরি API এবং অর্গানাইজেশনাল-ইউনিট কনটেক্সট ব্যবহার করুন। একটি এক্সপোর্ট করা সার্টিফিকেট ফাইল সফল প্রোভিশনিং প্রমাণ করে না। এন্ডপয়েন্টটি প্রোফাইলটি পেয়েছে, ট্রাস্টেড রুট ইনস্টল করেছে এবং রিলাইং সার্ভিসের কাছে ক্লায়েন্ট সার্টিফিকেট উপস্থাপন করতে পারছে কিনা তা নিশ্চিত করুন।
Okta সার্টিফিকেট-ভিত্তিক ডিভাইস-ট্রাস্ট সিদ্ধান্তে অবদান রাখতে পারে, তবে শুধুমাত্র সার্টিফিকেটের উপস্থিতি অথেন্টিকেশন সম্পূর্ণ করে না। সার্টিফিকেট ভ্যালিডেশন এবং ডিভাইস পোস্চারকে প্রযোজ্য সাইন-অন এবং মাল্টি-ফ্যাক্টর পলিসির সাথে একত্রিত করুন। কোনো ডিভাইস যদি ম্যানেজড পপুলেশন থেকে বাদ পড়ে যায়, তবে ডিরেক্টরি ইভেন্টটিকে সার্টিফিকেট নিষ্ক্রিয়করণ বা রিভোকেশনের সাথে সংযুক্ত করুন। ম্যানুয়াল ডিসকভারি অরফ্যানড ক্রেডেন্সিয়াল রেখে দেয় এবং ডিরেক্টরি রেকর্ড, CA কনসোল এবং নেটওয়ার্ক অ্যাপ্লায়েন্সের মধ্যে ব্যবধান তৈরি করে।
ব্যবহারের ক্ষেত্রের ওপর ভিত্তি করে CA নির্বাচন করুন
ইন্টারনেট-মুখী নাম এবং পরিষেবার জন্য একটি পাবলিক CA ব্যবহার করুন যার জন্য ব্যাপক ক্লায়েন্ট ট্রাস্ট প্রয়োজন। ইন্টারনাল ডিভাইস আইডেন্টিটি, mTLS এবং নিয়ন্ত্রিত এন্টারপ্রাইজ ট্রাস্টের জন্য একটি প্রাইভেট CA ব্যবহার করুন। একটি হাইব্রিড মডেল পাবলিক ওয়েব সার্টিফিকেটকে ইন্টারনাল আইডেন্টিটি সার্টিফিকেট থেকে আলাদা রাখে, যখন প্রতিটি PKI উপযুক্ত ইস্যুয়েন্স এবং রিভোকেশন কন্ট্রোল অনুসরণ করে। প্রতিটি প্রোভাইডারের জন্য ওনারশিপ এবং ডেপ্লয়মেন্ট ইন্টারফেসের নথি তৈরি করুন যাতে রিনিউয়াল অটোমেশন সার্ভার, ডিরেক্টরি পরিষেবা এবং নেটওয়ার্ক ভেন্ডরদের কাছে পৌঁছাতে পারে।
কি (key) স্টোরেজ রিকভারি এবং ঘটনার প্রতিক্রিয়াকেও প্রভাবিত করে। TPMs-এ হার্ডওয়্যার-ব্যাকড কি-গুলো এক্সট্র্যাকশন কঠিন করে তোলে এবং ম্যানেজড ল্যাপটপ ও নির্দিষ্ট উদ্দেশ্যের ডিভাইসের জন্য উপযুক্ত যেখানে প্ল্যাটফর্মটি একটি স্থিতিশীল হার্ডওয়্যার আইডেন্টিটি প্রদান করে। সফটওয়্যার কি-স্টোরগুলো বিভিন্ন হার্ডওয়্যার এবং রিকভারি ওয়ার্কফ্লোতে কাজ করা সহজ করে তোলে, তবে এর জন্য আরও শক্তিশালী এন্ডপয়েন্ট সুরক্ষা এবং অ্যাক্সেস কন্ট্রোল প্রয়োজন।
WiFi একটি বাস্তবসম্মত ট্রেড-অফ নিয়ে আসে। অ্যাক্সেসে বাধা না দিয়ে একটি ডিভাইস সার্টিফিকেটকে অবশ্যই রুটিন অপারেটিং সিস্টেম মেইনটেইন্যান্সের মুখোমুখি হয়ে টিকে থাকতে হবে, একই সময়ে অর্গানাইজেশনের আপস বা মালিকানা পরিবর্তনের পরে এটি প্রতিস্থাপন করার একটি উপায়ও প্রয়োজন। Windows, macOS, iOS, এবং Android-এ রিনিউয়াল পরীক্ষা করুন, যার মধ্যে প্রোফাইল আপডেটের পরে সাপ্লিক্যান্ট কীভাবে আচরণ করে তাও অন্তর্ভুক্ত। অন-প্রিমিসেস RADIUS অ্যাডমিনিস্ট্রেশন কমাতে চাওয়া টিমগুলো সেলফ-ম্যানেজড ডিপ্লয়মেন্টের পাশাপাশি সার্টিফিকেট-ভিত্তিক WiFi-এর জন্য RADIUS-as-a-Service মূল্যায়ন করতে পারে।
রোটেশন রিনিউয়াল এবং রিভোকেশন পরিচালনা করা
রাত ২টায়, একটি সার্টিফিকেট CA-তে সফলভাবে রিনিউ হতে পারে এবং তারপরেও কোনো সার্ভিস অফলাইন রেখে দিতে পারে। অ্যাপ্লায়েন্সটি চেইনটি প্রত্যাখ্যান করতে পারে, প্রাইভেট কি-টি মিল নাও হতে পারে, অথবা অ্যাপ্লিকেশনটি ম্যানুয়ালি রিস্টার্ট করার প্রয়োজন হতে পারে। তাই রোটেশন, রিনিউয়াল এবং রিভোকেশন তিনটি আলাদা টিকিটের পরিবর্তে একটি অপারেশনাল ওয়ার্কফ্লোর অন্তর্ভুক্ত। রিনিউয়াল একটি মেয়াদোত্তীর্ণ সার্টিফিকেট প্রতিস্থাপন করে। রোটেশনের ক্ষেত্রে সাধারণত একটি নতুন কি তৈরি করা উচিত, কারণ পুরানো প্রাইভেট কি রেখে দিলে সেটি এক্সপোজ হওয়ার ঝুঁকি বজায় থাকে। রিভোকেশন মূলত কোনো আপস, ডিকমিশনিং বা মেয়াদের শেষ হওয়ার আগেই একটি সার্টিফিকেট বাতিল করার পলিসি সিদ্ধান্তের ক্ষেত্রে ব্যবহৃত হয়।
মেয়াদ শেষ হওয়ার আগে ডেপ্লয়মেন্টের ব্যর্থতাগুলো নির্ণয় করতে রিনিউয়াল উইন্ডোটি যথেষ্ট আগে সেট করুন। ইনস্টলেশন এবং সার্ভিস রিলোড স্ট্যাটাস থেকে আলাদাভাবে CA অনুমোদন ট্র্যাক করুন। সেই পার্থক্যের মাধ্যমেই সার্টিফিকেটের বিস্তার দৃশ্যমান হয়: বিভিন্ন প্রোভাইডার, ডিরেক্টরি সার্ভিস, অ্যাপ্লায়েন্স এবং অ্যাপ্লিকেশন মালিকরা প্রায়শই একই লাইফসাইকেলের বিভিন্ন অংশের রিপোর্ট করেন।
রিনিউয়ালকে একটি ডেপ্লয়মেন্ট ওয়ার্কফ্লো হিসেবে ডিজাইন করুন
একটি নির্ভরযোগ্য ওয়ার্কফ্লোর যা করা উচিত:
- রিনিউয়াল উইন্ডো শনাক্তকরণ: বৈধতা, সার্ভিসের গুরুত্ব, প্রোভাইডার এবং ডেপ্লয়মেন্টের জটিলতা মূল্যায়ন করুন।
- CSR এবং কী পুনরায় তৈরি করা: একটি নতুন প্রাইভেট কী তৈরি করুন এবং UK DWP PKI লাইফসাইকেলের প্রয়োজনীয়তা অনুসরণ করুন।
- একটি অনুমোদন গেট প্রয়োগ করা: উচ্চ-প্রভাবশালী সিস্টেমের জন্য সার্ভিস-মালিকের নিশ্চিতকরণ বাধ্যতামূলক করুন, আর পলিসি-সম্মত কম-ঝুঁকিপূর্ণ রিনিউয়ালগুলো স্বয়ংক্রিয়ভাবে এগিয়ে নেওয়ার অনুমতি দিন।
- প্রতিস্থাপনের প্রস্তুতি (Stage) নেওয়া: একটি সেকেন্ডারি এন্ডপয়েন্ট, নোড, লিসেনার বা টেস্ট প্রোফাইলে সার্টিফিকেট এবং সম্পূর্ণ চেইন ইনস্টল করুন।
- কাটওভারের আগে যাচাই করা: নাম, কী-এর ব্যবহার, চেইন তৈরি, ক্লায়েন্ট ট্রাস্ট এবং অ্যাপ্লিকেশনের আচরণ পরীক্ষা করুন।
- একটি নিয়ন্ত্রিত পরিবর্তন সম্পাদন করা: সার্ভিসটি অফলাইনে না নিয়ে ট্রাফিক বা অথেন্টিকেশন রিনিউ হওয়া এন্ডপয়েন্টে স্থানান্তর করুন।
- প্রমাণ রেকর্ড করা: সিরিয়াল নম্বর, ফিঙ্গারপ্রিন্ট, প্রোভাইডার, স্টোরেজ লোকেশন, মালিক, অনুমোদন এবং ডেপ্লয়মেন্টের ফলাফল সহ শেয়ার্ড ইনভেন্টরি আপডেট করুন।
হাই-অ্যাভেলেবিলিটি সার্ভিসের জন্য, একসাথে একটি করে নোড পরিবর্তন করুন। বাকি নোডগুলির কাজ চালিয়ে যাওয়ার আগে প্রকৃত ক্লায়েন্টের আচরণ যাচাই করুন। নীতি যেখানে অনুমতি দেয় ঠিক সেখানেই রোলব্যাক করার জন্য আগের সার্টিফিকেটটি রাখুন, তারপর রূপান্তরের পর অপ্রচলিত প্রাইভেট কীগুলি সরিয়ে ফেলুন। ইনভেন্টরিতে প্রতিটি ভেন্ডর স্বয়ংক্রিয় ইনস্টলেশন এবং পুনরায় লোড করা সমর্থন করে কিনা তাও রেকর্ড করা উচিত, কারণ শুধুমাত্র একটি CA রিনিউয়াল পরিবর্তনটিকে সম্পন্ন করে না।
রিভোকেশন পর্যবেক্ষণযোগ্য করে তুলুন
বাতিলকরণ (revocation) কেবল তখনই কাজ করে যখন নির্ভরশীল ক্লায়েন্টরা স্ট্যাটাস পুনরুদ্ধার এবং প্রয়োগ করতে পারে। উচ্চ প্রাপ্যতা সহ কেন্দ্রীয়ভাবে বাতিলের তথ্য হোস্ট করুন, তারপর পরিবেশ অনুযায়ী CRL ডিস্ট্রিবিউশন, OCSP রেসপন্ডার, বা উভয়ই পরিচালনা করুন। ফেইলিউর বিহেভিয়ারও পরীক্ষা করুন। স্ট্যাটাস সার্ভিসগুলো অনুপলব্ধ থাকলে লেগ্যাসি ক্লায়েন্টরা কাজ চালিয়ে যেতে পারে, যা ইন্সিডেন্ট রেসপন্ডারদের একটি বিভ্রান্তিকর নিয়ন্ত্রণের অনুভূতি দেয়।
অনাথ (orphaned) সার্টিফিকেটগুলোকে একটি তদন্ত হিসেবে বিবেচনা করুন, কেবল কোনো পরিচ্ছন্নতার কাজ হিসেবে নয়। ডিকমিশন হিসেবে চিহ্নিত করার আগে নিশ্চিত করুন যে কোনো পরিষেবা, ডিভাইস, ব্যাকআপ প্রক্রিয়া, ডিরেক্টরি ওয়ার্কফ্লো, বা ভেন্ডর ইন্টিগ্রেশন এখনও সেই সার্টিফিকেটের ওপর নির্ভর করছে না। একটি এন্ডপয়েন্ট থেকে কোনো বাতিল করা সার্টিফিকেট সরিয়ে দিলেই সমস্যার সমাধান হয় না যদি অন্য কোনো সিস্টেম এখনও সেটিকে বিশ্বাস করে বা একই আইডেন্টিটি বিশিষ্ট একটি বিকল্প সার্টিফিকেট সক্রিয় থাকে।
UK ডিজিটাল আইডেন্টিটি সার্টিফিকেশন মডেলটি সার্টিফিকেট ম্যানেজমেন্টকে প্রমাণ এবং পর্যালোচনার সময়সীমার সাথেও যুক্ত করে। UK Digital Identity and Attributes Trust Framework-এর আওতাধীন পরিষেবাগুলির জন্য একটি অনুমোদিত কনফর্মিটি অ্যাসেসমেন্ট বডি দ্বারা সার্টিফিকেশন প্রয়োজন। সার্টিফিকেটগুলি সাধারণত তিন বছরের জন্য বৈধ থাকে, যেখানে প্রতি ১২ মাসে নজরদারির আশা করা হয়, সাধারণত সার্টিফিকেশন বার্ষিকীর উভয় পাশে ৩০ দিনের মধ্যে। UK সার্টিফিকেশন স্কিমের প্রয়োজনীয়তা উল্লেখ করে যে সার্টিফিকেট মেয়াদের অবসান ঘটার আগে পরিষেবাগুলিকে পুনরায় প্রত্যয়িত করতে হবে। সার্টিফিকেশনটি মূল্যায়নকৃত পরিষেবার ক্ষেত্রে প্রযোজ্য হয়, স্বয়ংক্রিয়ভাবে সম্পূর্ণ প্রতিষ্ঠানের জন্য নয়।
বাস্তব ভেন্যুতে সার্টিফিকেট-ভিত্তিক WiFi অ্যাক্সেস ডেপ্লয় করা
সার্টিফিকেট-ভিত্তিক WiFi ভেন্যুগুলোতে তখন ভালো কাজ করে যখন আইডেন্টিটি, ট্রাস্ট চেইন এবং সাপ্লিক্যান্ট কনফিগারেশন একসঙ্গে ডিজাইন করা হয়। EAP-TLS শেয়ার্ড-পাসওয়ার্ডের সমস্যা দূর করে, কিন্তু এটি একটি সিক্রেটকে এমন একটি লাইফসাইকেল দিয়ে প্রতিস্থাপন করে যা অবশ্যই ক্লায়েন্ট সার্টিফিকেট প্রভিশন করবে, সঠিক রুট CA ইনস্টল করবে, ওয়ারলেস প্রোফাইল কনফিগার করবে এবং ডিরেক্টরি আইডেন্টিটি বা ডিভাইসের সম্পর্ক পরিবর্তিত হলে অ্যাক্সেস বাতিল করবে।
একটি কর্পোরেট ক্যাম্পাসে, সবচেয়ে পরিচ্ছন্ন প্যাটার্ন হলো সাধারণত ডিরেক্টরি-ব্যাকড ডিভাইস সার্টিফিকেট সহ EAP-TLS ব্যবহার করে একটি স্টাফ SSID এবং একটি পৃথক গেস্ট এক্সপেরিয়েন্স তৈরি করা। Passpoint ম্যানেজড ডিভাইসগুলোকে বারবার ক্রেডেন্সিয়াল ইনপুট না করেই উপযুক্ত নেটওয়ার্ক ডিসকভার এবং জয়েন করতে দিতে পারে। পুরোনো ইকুইপমেন্ট যা প্রয়োজনীয় সার্টিফিকেট ফ্লো সম্পূর্ণ করতে পারে না, সেগুলোর জন্য একটি iPSK সেগমেন্ট ডিভাইস-নির্দিষ্ট কি প্রদান করতে পারে যখন মূল স্টাফ নেটওয়ার্ক আরও শক্তিশালী আইডেন্টিটি কন্ট্রোল ধরে রাখে।
একটি হাসপাতালের পরিস্থিতি আরও জটিল। ম্যানেজড ক্লিনিকাল ওয়ার্কস্টেশনগুলো EAP-TLS সমর্থন করতে পারে, অন্যদিকে স্পেশালিস্ট ডিভাইস, স্ক্যানার, পাম্প এবং ভেন্ডর-দ্বারা পরিচালিত সরঞ্জামগুলোর supplicant ক্ষমতা সীমিত হতে পারে। এই ডিভাইসগুলোকে কঠোরভাবে সীমাবদ্ধ নেটওয়ার্ক সেগমেন্টে রাখুন, তাদের ট্রাস্ট মডেল ডকুমেন্ট করুন এবং প্রতিটি ক্লায়েন্টের জন্য স্টাফ SSID দুর্বল না করে একটি ক্ষতিপূরণমূলক নিয়ন্ত্রণ সংজ্ঞায়িত করুন।
একটি রিটেইল চেইনে, স্থানীয় সুইচিং এবং ওয়্যারলেস বৈচিত্র্যের সাথে কেন্দ্রীয় নীতির সহাবস্থান থাকা আবশ্যক। Meraki, Aruba, Ruckus এবং অন্যান্য ভেন্ডররা বিভিন্ন সার্টিফিকেট, RADIUS, Passpoint এবং অনবোর্ডিং নিয়ন্ত্রণ প্রদর্শন করে। সার্টিফিকেটের নীতি ভেন্ডর-নিরপেক্ষ রাখুন, তারপর প্রতিটি হার্ডওয়্যার ফ্যামিলিতে সঠিক প্রোফাইলটি পরীক্ষা করুন। Aruba-compatible WiFi hardware options এই মাল্টি-ভেন্ডর ডিজাইনের অংশ হিসেবে মূল্যায়ন করা যেতে পারে।
| বিক্রেতা (Vendor) | EAP Method | RADIUS Integration | Passpoint সমর্থন | অনবোর্ডিং জটিলতা |
|---|---|---|---|---|
| Cisco Meraki | EAP-TLS, প্ল্যাটফর্ম কনফিগারেশন সাপেক্ষে | বাহ্যিক RADIUS বিকল্প সহ ক্লাউড-ম্যানেজড ওয়্যারলেস | সমর্থিত ওয়্যারলেস ফিচারের মাধ্যমে উপলব্ধ | মাঝারি |
| Aruba | EAP-TLS এবং অন্যান্য এন্টারপ্রাইজ EAP মেথড | কন্ট্রোলার বা ক্লাউড-ম্যানেজড RADIUS ইন্টিগ্রেশন | সমর্থিত WLAN ফিচারের মাধ্যমে উপলব্ধ | মাঝারি |
| Ruckus | EAP-TLS এবং বিক্রেতা-সমর্থিত এন্টারপ্রাইজ মেথড | WLAN ম্যানেজমেন্টের মাধ্যমে RADIUS ইন্টিগ্রেশন | সমর্থিত ডিপ্লয়মেন্টের মাধ্যমে উপলব্ধ | মাঝারি |
| মিশ্র এস্টেট (Mixed estate) | যেখানে ক্লায়েন্টরা সমর্থন করে সেখানে EAP-TLS-এ স্ট্যান্ডার্ডাইজ করুন | পলিসি কেন্দ্রীভূত করুন, প্রতিটি বিক্রেতার অ্যাট্রিবিউট পরীক্ষা করুন | প্রতিটি প্ল্যাটফর্মের জন্য রোমিং এবং প্রোফাইল আচরণ যাচাই করুন | উচ্চ |
শুধুমাত্র জয়েন নয়, ব্যর্থতাগুলোও পরীক্ষা করুন
একটি সফল প্রথম সংযোগ খুব সামান্যই প্রমাণ করে। ভুল SAN, একটি অনুপস্থিত ইন্টারমিডিয়েট, ডিভাইস ট্রাস্ট স্টোরে মেয়াদ শেষ হয়ে যাওয়া রুট, একটি রিভোক করা ক্লায়েন্ট সার্টিফিকেট, একটি RADIUS টাইমআউট এবং একটি অপারেটিং সিস্টেম আপডেটের পরে ফিরে আসা ডিভাইসের সাহায্যে একটি সার্টিফিকেট পরীক্ষা করুন। নিশ্চিত করুন যে ব্যবহারকারী একটি অবিরাম অথেনটিকেশন লুপের পরিবর্তে একটি কার্যকর রিকভারি পথ দেখতে পাচ্ছেন।
যেসব ডিভাইস EAP-TLS সমর্থন করতে পারে না সেগুলোর জন্য একটি বিকল্প ব্যবস্থা রাখুন, তবে সেটিকে ভূমিকা অনুযায়ী আলাদা করুন এবং একটি প্রতিস্থাপন পরিকল্পনা কার্যকর করুন। প্রোডাকশনের ক্ষেত্রে সাধারণ ভুল হলো অনবোর্ডিং তড়িঘড়ি করার কারণে ব্যতিক্রমী নেটওয়ার্কটিকে ডিফল্ট নেটওয়ার্ক হতে দেওয়া।
অটোমেটিং মনিটরিং এবং মাল্টি-প্রোভাইডার গভর্নেন্স
একটি কেন্দ্রীয় ড্যাশবোর্ডের প্রতিটি সার্টিফিকেটের জন্য চারটি প্রশ্নের উত্তর দেওয়া উচিত: এটি কী, এটি কোথায় ব্যবহৃত হয়, এর মালিক কে, এবং এরপর কী হবে। এটি পাবলিক CAs, প্রাইভেট PKI, ক্লাউড-নেটিভ সার্ভিস যেমন AWS ACM, Google Certificate Manager এবং Azure Key Vault, এর পাশাপাশি ডিরেক্টরি প্ল্যাটফর্ম, নেটওয়ার্ক কন্ট্রোলার, লোড ব্যালেন্সার এবং অ্যাপ্লিকেশন স্টোর থেকে স্টেট গ্রহণ করবে।
মনিটরিংয়ের জন্য কেবল একটি এক্সপায়ারি ডেট বা মেয়াদের তারিখের চেয়েও বেশি কিছু প্রয়োজন। চেইনের সম্পূর্ণতা, কী এবং সার্টিফিকেটের মিল, SAN কভারেজ, কী ব্যবহার, রিলিজ বা বাতিলের অ্যাক্সেসযোগ্যতা, ডিপ্লয়মেন্টের ধারাবাহিকতা এবং এন্ডপয়েন্টে দেখা সার্টিফিকেটটি ইনভেন্টরিতে রেকর্ড করা সার্টিফিকেটের সাথে মেলে কিনা তা পরীক্ষা করুন। ব্যবহারকারীরা ইতিমধ্যেই যে সিস্টেমটি ব্যবহার করছেন তার মাধ্যমে তাদের সতর্ক করুন, এবং তখনই বিষয়টি আরও উপরে জানান যখন মালিক সেটি স্বীকার করেন না বা অবশিষ্ট সময় উচ্চতর ঝুঁকির সীমা অতিক্রম করে।
UK সার্টিফিকেশন কাজের চাপের ক্ষেত্রে অটোমেশনের প্রয়োজনীয়তা অত্যন্ত জোরালো। Cyber Essentials মূল্যায়নের ডেটা অনুসারে স্কিমটি শুরু হওয়ার পর থেকে ১৩২,০৯৪টি সার্টিফিকেট প্রদান করা হয়েছে, পূর্ববর্তী ১২ মাসে UK-তে ২৭,০২৭টি অনন্য প্রত্যয়িত প্রতিষ্ঠান ছিল এবং ওই সময়কালে মোট ৩৫,৪৩৪টি সার্টিফিকেশন সম্পন্ন হয়েছে। UK Cyber Essentials স্কিম মূল্যায়ন অনুসারে, ২০২২ সালে স্কিমটিতে ২৪,৩০০টি সার্টিফিকেশন রেকর্ড করা হয়েছে, যার মধ্যে ১৬,৫৫৪টি পুনঃসার্টিফিকেশন এবং ৭,৭৪৬টি নতুন সার্টিফিকেশন রয়েছে। কাজের চাপ মূলত নবায়ন-কেন্দ্রিক, তাই ক্যালেন্ডার, প্রমাণ সংগ্রহ, মূল্যায়নকারী কাজ এবং অনুস্মারকগুলি এককালীন ইস্যু করার পরিবর্তে পুনঃসার্টিফিকেশনকে কেন্দ্র করে ডিজাইন করা উচিত।
নতুন কোনো সিলো তৈরি না করেই প্রদানকারীদের পরিচালনা করুন
একটি একক CA-তে সংহত করা নীতি, চুক্তি, টেমপ্লেট এবং সহায়তা সহজ করতে পারে। এটি কনসেনট্রেশন রিস্ক বা ঘনত্বের ঝুঁকি তৈরি করতে পারে এবং মাইগ্রেশনকে ব্যয়বহুল করে তুলতে পারে। একটি মাল্টি-প্রোভাইডার মডেল স্থিতিস্থাপকতা উন্নত করে এবং বিভিন্ন ব্যবহারের ক্ষেত্রে উপযুক্ত হতে পারে, তবে শুধুমাত্র তখনই যদি সংস্থাটি ইনভেন্টরি ফিল্ড, মালিকানার নিয়ম, অনুমোদন গেট, কী-জেনারেশন নীতি এবং রিপোর্টিং মানসম্মত করে।
একটি বাস্তবসম্মত ম্যাচিউরিটি পাথ ঠিক এইরকম দেখায়:
- প্রতিক্রিয়াশীল (Reactive): কোনো ঘটনার পর টিমগুলো মেয়াদ শেষ হওয়া সার্টিফিকেট খুঁজে পায়।
- রেকর্ডকৃত (Recorded): একটি শেয়ার্ড ইনভেন্টরি বিদ্যমান থাকে, তবে ডিসকভারি এবং আপডেটগুলো ম্যানুয়ালই থেকে যায়।
- মনিটরকৃত (Monitored): এন্ডপয়েন্ট স্ক্যান এবং প্রোভাইডার ইন্টিগ্রেশন পরিবর্তন সনাক্ত করে এবং অনার-ভিত্তিক অ্যালার্ট পাঠায়।
- অরকেস্ট্রেটেড (Orchestrated): অনুমোদিত অটোমেশন কি (key) তৈরি করে, সার্টিফিকেট অনুরোধ করে, প্রতিস্থাপন ডেপ্লয় করে, পরিষেবাগুলো যাচাই করে এবং রেকর্ড আপডেট করে।
- পরিচালিত (Governed): পুরো এস্টেট জুড়ে পলিসি-অ্যাস-কোড, অডিট প্রমাণ, প্রোভাইডার রিডান্ডেন্সি, ব্যতিক্রম হ্যান্ডলিং এবং লাইফসাইকেল অ্যানালিটিক্স কাজ করে।
প্রথম দিনেই প্রতিটি রিনিউয়াল স্বয়ংক্রিয় করবেন না। ডিসকভারি এবং ওনারশিপ দিয়ে শুরু করুন, কম ঝুঁকিপূর্ণ সার্টিফিকেটগুলো স্বয়ংক্রিয় করুন এবং অথেন্টিকেশন ইনফ্রাস্ট্রাকচার ও শেয়ার্ড ইন্টারমিডিয়েটের জন্য অ্যাপ্রুভাল গেট রাখুন। ওয়্যারলেস এন্ডপয়েন্ট পরিচালনা করা টিমগুলোর জন্য, একটি WiFi SSL সার্টিফিকেট চেকার টার্গেটেড ভ্যালিডেশন সমর্থন করতে পারে, তবে এটি অথরিটেটিভ ইনভেন্টরির বিকল্প হওয়ার পরিবর্তে তার পরিপূরক হওয়া উচিত।
Purple মিশ্র নেটওয়ার্ক এনভায়রনমেন্ট জুড়ে আইডেন্টিটি-ভিত্তিক WiFi অথেন্টিকেশন, সার্টিফিকেট-গ্রেড স্টাফ অ্যাক্সেস, ডিরেক্টরি ইন্টিগ্রেশন, Passpoint এবং iPSK সহায়তা প্রদান করে, যা টিমগুলোকে সার্টিফিকেট প্রভিশনিং এবং রিভোকেশনকে আসল ভেন্যু অপারেশনের সাথে সংযুক্ত করতে সহায়তা করে। আপনার WiFi সার্টিফিকেট লাইফসাইকেলের সাথে Purple কীভাবে খাপ খায় তা পর্যালোচনা করুন, তারপর আপনার ডিরেক্টরি পরিষেবা, নেটওয়ার্ক ভেন্ডর এবং অনবোর্ডিং প্রয়োজনীয়তার উপর ভিত্তি করে একটি ইমপ্লিমেন্টেশন নিয়ে আলোচনা করতে Purple-এ ভিজিট করুন।
