২-গ) প্রাইভেট কী নিরাপদে সংরক্ষণ

আগের পোস্টে আমি বিভিন্ন প্রকার ক্রিপ্টোগ্রাফিক কী নিয়ে আলোচনা করেছি।  সেই কী গুলোকে যদি গোপনভাবে সুরক্ষিত করতে হয়।  এই পোস্টে সেটা নিয়েই আলোচনা করব।

In Amazon Web Services (AWS)

Secrets Manager: সংবেদনশীল তথ্য যেমন ডাটাবেজ ক্রেডেনশিয়াল, API কী, OAuth টোকেন এবং অন্যান্য অ্যাপ্লিকেশনের গোপন তথ্য নিরাপদে ম্যানেজ ও রোটেট করার জন্য তৈরি। এটি স্বয়ংক্রিয় সিক্রেট রোটেশন (নিয়মিত নতুন secret জেনারেট ও পুরোনোটি রিমুভ করা) সমর্থন করে।  সাধারন অ্যাপ্লিকেশনের ক্রিপ্টোগ্রাফিক কী সংরক্ষন করার জন্য এটি ভাল।

Parameter Store: মূলত সাধারণ কনফিগারেশন ডেটা সংরক্ষণ ও ম্যানেজ করার জন্য ব্যবহৃত হয়, যেমন অ্যাপ্লিকেশনের সেটিংস, ডাটাবেজ কানেকশন স্ট্রিং (যা সিক্রেট নয়) এবং AMI ID।  ক্রিপ্টোগ্রাফিক কী এখানে রাখা উচিত নয়।

AppConfig: মূলত নিরাপদ ও নিয়ন্ত্রিতভাবে অ্যাপ্লিকেশন কনফিগারেশন ডিপ্লয় করার জন্য তৈরি, যেমন ফিচার ফ্ল্যাগ, এলাউ লিস্ট বা অ্যাপ্লিকেশন টিউনিং প্যারামিটার।  এটি সেফ ডিপ্লয়মেন্টকে অগ্রাধিকার দেয়।  এটিও ক্রিপ্টোগ্রাফিক কী রাখার জন্য নয়।

In Azure Web services

Key Vault : মূলত সংবেদনশীল তথ্য যেমন সিক্রেট পাসওয়ার্ড, API কী, কানেকশন স্ট্রিং, এবং SSL/TLS সার্টিফিকেট নিরাপদে সংরক্ষণ ও ম্যানেজ করার জন্য ব্যবহৃত হয়। এটি সূক্ষ্ম অ্যাক্সেস কন্ট্রোল পলিসি এবং সিক্রেট ও সার্টিফিকেটের লাইফসাইকেল ম্যানেজমেন্ট (যেমন রোটেশন) সুবিধা প্রদান করে।  এটি AWS Secrets Manager  এর মত সাধারন অ্যাপ্লিকেশনের ক্রিপ্টোগ্রাফিক কী সংরক্ষন করার জন্য ভাল।

App Configuration: মূলত অ্যাপ্লিকেশনের কনফিগারেশন ও ফিচার ফ্ল্যাগ কেন্দ্রীয়ভাবে ম্যানেজ করার জন্য তৈরি।  এর ফলে কোড পুনঃডিপ্লয় না করেই অ্যাপ্লিকেশনের আচরণ ডাইনামিকভাবে আপডেট করা যায়।  এটি AWS AppConfig  এর মত সাধারণত অ্যাপ্লিকেশনের সেটিংস কেন্দ্রীয়ভাবে ম্যানেজ করতে পারে, তবে ক্রিপ্টোগ্রাফিক কী এখানে রাখা উচিত নয়।

এছাড়াও Google Cloud Platform-এর Secret Manager এবং HashiCorp (যেটা এখন IBM অধীনে) এর HashiCorp Vault ও ক্রিপ্টোগ্রাফিক কী সংরক্ষন করার জন্য ভাল, কিন্তু এগুলো সম্পর্কে আমার প্রাকটিক্যাল অভিজ্ঞতা নেই।

In Kubernetes

Kubernetes Secrets: Secret অবজেক্টগুলো Kubernetes-এর etcd ডাটাবেজে এনক্রিপ্টেড অবস্থায় থাকে। পড (Pod) বা কন্টেইনার runtime environment-এ secret মাউন্ট করা হয় (ফাইল/এনভায়রনমেন্ট ভ্যারিয়েবল হিসেবে)।  ডকার কন্টেইনারের ভিতরে API key, টোকেন বা সার্টিফিকেট ইনজেক্ট করার জন্য ব্যাবহার করা হয়।  

যদিও Azure Kubernetes Service (AKS) এর Secrets কে Azure Key Vault এর সাথে লিংক করা যায়,কিন্তু আমার মতে সাধারন অ্যাপ্লিকেশনের ক্রিপ্টোগ্রাফিক কী রাখার জন্য এটি নিরাপদ নয়।  কারণ Kubernetes-এর ক্লাস্টার বিভিন্ন কারণে অনেকই একসেস দিতে হয় এবং তারা চাইলে Secret ব্রাউজ করে ক্রিপ্টোগ্রাফিক কী দেখে ফেলতে পারবে।  

মজার বিষয় হল, উপরের একটি সার্ভিসও পেমেন্ট সিস্টেমের উপযোগী না কারণ PCI DSS এবং PCI PIN স্ট্যান্ডার্ড অনুযায়ী ক্রিপ্টোগ্রাফিক কী Hardware Security Module (HSM)-এ সংরক্ষন করতে হয়। 

Payment HSM

এটি PCI-certified HSM ডিভাইস ব্যবহার করে, যা ব্যাংক ও ফিনটেক ইন্ডাস্ট্রির জন্য প্রয়োজনীয়।  পেমেন্ট লেনদেনের জন্য কী জেনারেশন, এনক্রিপশন, ডিক্রিপশন ও কী এক্সচেঞ্জ নিরাপদে করে এবং মূল কথা হল HSM থেকে কখনই Clear/ Original কী পাওয়া সম্ভব নয়।  কার্ড নেটওয়ার্ক (Visa/Mastercard/Amex) এর ট্রান্স্যাকশন প্রসেসিং, PIN ও CVV এনক্রিপশন এবং ব্যাংকিং/পেমেন্ট গেটওয়ে সিস্টেমের কী ম্যানেজমেন্ট এর জন্য বিশেষভাবে ব্যাবহার করা হয়।  Key storage, encryption/decryption, digital signature সব কিছু FIPS 140-2 Level 3 compliant হয়।

FIPS 140-2 Level 3-এর মূল বৈশিষ্ট্যসমূহ

ট্যাম্পার-রেজিস্ট্যান্স (Tamper-Resistance):
মডিউল এমনভাবে ডিজাইন করা হয় যে এতে শক্তিশালী সুরক্ষিত কাঠামো এবং জিরোইজেশন সার্কিট থাকে।  এগুলো মডিউলের কভার খোলা হলে সাথে সাথে সব প্লেইনটেক্সট ডেটা এবং গুরুত্বপূর্ণ সিকিউরিটি প্যারামিটার (CSP) ধ্বংস করে দেয়।

আইডেন্টিটি-ভিত্তিক অথেন্টিকেশন (Identity-Based Authentication):
শুধুমাত্র অনুমোদিত ব্যবহারকারীরাই, যাদের পরিচয় যাচাই করা হয়েছে, মডিউলের ফাংশন ব্যবহার করতে পারে।  এটি Level 2-এর Role-Based Authentication থেকে এক ধাপ উন্নত।

ইন্টারফেসের পৃথকীকরণ (Separation of Interfaces):
গুরুত্বপূর্ণ সিকিউরিটি প্যারামিটার (CSP) মডিউলে প্রবেশ ও প্রস্থান করে এমন ইন্টারফেসগুলোকে শারীরিক বা যৌক্তিকভাবে আলাদা রাখতে হবে।

এনক্রিপ্টেড কী এক্সচেঞ্জ (Encrypted Key Exchange):
প্রাইভেট কী শুধুমাত্র এনক্রিপ্টেড আকারেই মডিউল থেকে বের হতে পারবে, যাতে অননুমোদিতভাবে তা সংগ্রহ করা না যায়।

পরিবেশ সুরক্ষা (Environmental Protection):
মডিউলকে ভোল্টেজ বা তাপমাত্রার মতো অস্বাভাবিক পরিবেশগত পরিবর্তন শনাক্ত করে তার প্রতিক্রিয়া জানাতে হবে, কারণ এগুলো সম্ভাব্য আক্রমণের ইঙ্গিত হতে পারে।

Payment HSM মুলত দুই রকমের হয়

Physical HSM (Offline HSM) অন-প্রিমাইস ডাটা সেন্টার বা ব্যাংকের ভল্টে রাখা ফিজিক্যাল হার্ডওয়্যার ডিভাইস, যা পুরোপুরি অফলাইনে ব্যবহার করা যায়।  এটি সাধারণত ব্যাংক, সরকার ও প্রতিরক্ষা সংস্থায় ব্যবহৃত হয়। Keys offline এ জেনারেট ও সুরক্ষিতভাবে সংরক্ষণ করা হয় এবং এটি একটি Tamper-resistant ডিভাইস, মানে কেউ যদি ভাঙার চেষ্টা করে, ভেতরের কী অটোমেটিক ডিলিট হয়ে যায়।

যেমন Atalla, Thales, SafeNet etc   

Cloud HSM (Online HSM) Cloud provider (AWS, Azure, GCP)-এর দেওয়া Hardware Security Module সার্ভিস, যেটি পুরোপুরি অনলাইনে এবং স্কেলেবল।  Hardware Security Module আসলে একটি ফিজিক্যাল ডিভাইস, তবে ক্লাউড সার্ভিস প্রোভাইডার API দিয়ে এক্সেস দেয়।  

যেমন Azure payment HSM, Utimaco HSM, MyHSM ইত্যাদি।  এই Cloud HSM গুলো ভিতরে ভিতের কোন না কোন Physical HSM এর উপর বানানো।  পরের পোস্টে এগুলো নিয়ে আরও বিস্তারিত আলোচনা করব।