শুধু CSR মানে নথিভুক্তি নয়: একটি VPN CA-কে কী যাচাই করতে হবে

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

দুটি নথিভুক্তি মডেল কী বাঁধে সেই বিচারে তুলনা করা উচিত, তারা কোন প্রোটোকল বলে তা দিয়ে নয়।

অনুরোধ একটি নাম দাবি করে, প্রমাণ করে না

অনুরোধটি আসলে কী ধারণ করে তা পড়ুন: একটি পাবলিক কী, অনুরোধকারীর বেছে নেওয়া একটি সাবজেক্ট, এবং দুটির উপর একটি স্ব-স্বাক্ষর। সেই কাঠামোতে আপনার ইনভেন্টরি, অ্যাকাউন্ট ডিরেক্টরি বা অনুমোদন প্রবাহের কোনো উল্লেখ নেই। cn=finance-laptop সাবজেক্টটি কেউ টাইপ করা একটি স্ট্রিং। যতক্ষণ না ইস্যু করার প্রক্রিয়া সেই স্ট্রিংটি তার বিশ্বস্ত কোনো রেকর্ডের সঙ্গে মেলায়, সার্টিফিকেটটি স্বাক্ষরযুক্ত একটি দাবি মাত্র। এই পার্থক্যই নথিভুক্তি প্রক্রিয়ার অস্তিত্বের সম্পূর্ণ কারণ।

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

মডেলগুলি কী বাঁধে তা দিয়ে তুলনা করুন

ম্যানুয়াল স্বাক্ষর অপারেটর যা যাচাই করতে মনে রাখে তাই বাঁধে। স্বয়ংক্রিয় নথিভুক্তি সেবা একটি প্রমাণিত অনুরোধকে এমন সিদ্ধান্তের সঙ্গে বাঁধে যা সেবা প্রয়োগ করতে পারে, আর RFC 7030 এমন একটি নকশা বর্ণনা করে যেখানে সার্টিফিকেট ফেরত দেওয়ার আগে ক্লায়েন্ট প্রমাণিত হয়। নিরীক্ষা টিকে থাকা পার্থক্যটি স্বয়ংক্রিয়তা নয়; পার্থক্য হলো পরিচয় যাচাই ইস্যু করার পথের ভিতরে হয় কি পাশে।

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

যতগুলি নথিভুক্তি আশা করছেন এবং ডিভাইসের পরিবর্তনের হার দেখে মডেল বেছে নিন। বছরে কয়েকটি সার্ভার লিখিত চেকলিস্টসহ ম্যানুয়াল পর্যালোচনায় টিকতে পারে। ল্যাপটপের বহর পারে না।

প্রথম ইস্যু থেকেই জীবনচক্র লিখে রাখুন

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

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

ইস্যু করা সার্টিফিকেট, তারপর অ্যাক্সেস যাচাই করুন

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

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

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

ভুল কারণে কাজ করা প্রোফাইল, যেমন মিলে যাওয়া সাধারণ নাম আর কোনো পরিচয় যাচাই না থাকা, আপনি যে নিয়ন্ত্রণ আছে ভেবেছিলেন তা সরানোর পরেও কাজ করতে থাকবে।