একটি VPN-এর মাধ্যমে অংশীদারের HSM অ্যাক্সেস: মূল কী অপারেশনগুলি নির্ধারণ করুন

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

নির্দিষ্ট ঘটনাটি চোখের সামনে রাখুন: অংশীদার একটি নির্দিষ্ট নামযুক্ত কী দিয়ে স্বাক্ষরের জন্য একটি অনুমোদিত নথি জমা দেয়, আর কিছুই নয়। নিচের সবকিছু ওই একক বাক্য থেকেই আসে।

পৌঁছানোর সক্ষমতা, পরিচয় ও কী নীতি — তিনটি দরজা

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

প্রয়োজন লিখতে যাওয়ার আগে প্রতিটি দরজার একটি মালিক নির্ধারণ করুন। যখন দ্বিতীয়টির কোনো মালিক থাকে না, তখন সাধারণত একটি বিস্তৃত HSM প্রশাসক পরিচয় দেওয়া হয়, কারণ সেটিই একমাত্র শংসাপত্র যা কাজ করে।

প্রথম দরজা: অংশীদার যে নেটওয়ার্ক পথ পায়

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

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

দ্বিতীয় দরজা: HSM-এ আসলে কী প্রমাণিত হয়

একটি VPN পরিচয় এবং একটি HSM পরিচয় আলাদা বস্তু, যদি না কোনো সমর্থিত ইন্টিগ্রেশন সচেতনভাবে সেগুলিকে যুক্ত করে। PKCS#11 ক্লায়েন্টের ক্ষেত্রে অ্যাপ্লিকেশনটি অংশীদারের হোস্টে কোথাও সংরক্ষিত শংসাপত্র দিয়ে একটি স্লটে লগইন করে, আর HSM ঠিক সেই লগইনটিই মূল্যায়ন করে।

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

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

তৃতীয় দরজা: কোন কী, এবং কোন অপারেশন

স্বাক্ষর, ডিক্রিপশন, কী তৈরি, কী মোড়ানো এবং ব্যবহারকারী প্রশাসন আলাদা অনুমতি এবং আলাদাভাবে তালিকাভুক্ত করতে হবে। PKCS#11 পরিভাষায় CKA_SENSITIVE এবং CKA_EXTRACTABLE-এর মতো বৈশিষ্ট্য বলে কী উপাদান ব্যবহারযোগ্য আকারে মডিউল ছেড়ে যেতে পারে কি না, এবং সেগুলি যন্ত্র অনুযায়ী নয়, প্রতিটি কী অনুযায়ী সেট করা হয়। হার্ডওয়্যার শব্দটি বা টানেলের উপস্থিতি থেকে রপ্তানি-অযোগ্যতা অনুমান না করে কী-এর প্রকৃত নীতিটি পড়ুন।

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

একটি অনুমোদিত ক্লায়েন্ট যদি আপসগ্রস্ত হয়, তবে সে ব্যক্তিগত কী একবারও বের না করেই তার শংসাপত্র যে অপারেশনগুলির বৈধ অনুমতি দেয় সেগুলির অপব্যবহার করতে পারে। তাই সংরক্ষিত কী উপাদান রক্ষা করা এবং কী-এর ব্যবহার নিয়ন্ত্রণ করা দুটি পৃথক গ্রহণশর্ত, একটি নয়।

প্রত্যাখ্যানও গ্রহণ পরীক্ষার অংশ

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

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

সম্পন্ন একটি VPN হ্যান্ডশেক সেই রেকর্ডে থাকা উচিত। এটি HSM-নির্দিষ্ট একটি একক ফলাফলের বিকল্প হতে পারে না।