CloudHSM বনাম KMS

এই লেসন শেষে তুমি পারবে

• AWS CloudHSM কী, বুঝিয়ে বলতে: তোমার নিজের VPC-তে বসানো dedicated, single-tenant hardware security module, যেখানে hardware সামলায় AWS আর user ও key সামলাও শুধু তুমি।
• দায়িত্ব ঠিকমতো ভাগ করতে: AWS কী করে, IAM কী নিয়ন্ত্রণ করে, কোন কাজ শুধু HSM user-রাই পারে, আর credential হারালে AWS কেন তোমার key ফিরিয়ে দিতে পারে না।
• পরীক্ষায় FIPS 140 নিয়ে যা আসে তা বলতে: এখনকার তথ্য (CloudHSM-এর hsm2m.medium আর KMS দুটোই FIPS 140-3 Level 3), আর যেসব পুরোনো প্রশ্ন এখনো “KMS = Level 2” বলে, সেগুলোর উত্তর কীভাবে দেবে।
• কয়েকটা Availability Zone জুড়ে HSM-এর cluster বানিয়ে CloudHSM-কে highly available করতে, আর একটা মাত্র HSM থাকলে কী বিপদ, বলতে।
• KMS custom key store দিয়ে S3, EBS, RDS আর অন্য service-এ নিজের HSM ব্যবহার করতে, এর শর্ত আর সীমা জানতে, আর কখন external key store লাগে বুঝতে।
• যেসব কাজে সরাসরি CloudHSM লাগে (PKCS#11, JCE, CNG, SSL/TLS offload, TDE, নিজের CA-র private key) সেগুলো চিনতে, আর scenario-র keyword দেখে KMS আর CloudHSM-এর মধ্যে ঠিকটা বাছতে।

#CloudHSM কেন: যখন KMS-এ কুলায় না

লেসন ২১.২-এ তুমি AWS KMS দেখেছ: AWS নিজের hardware security module-এ তোমার key বানায় আর পাহারা দেয়, সব AWS service সেগুলো ব্যবহার করতে পারে, আর key-প্রতি মাসে খরচ এক ডলার। বেশিরভাগ কাজে এটাই সঠিক উত্তর। এই লেসন সেইসব ক্ষেত্র নিয়ে, যেখানে এটা যথেষ্ট না, কারণ কোনো নিয়ম, কোনো auditor বা কোনো পুরোনো application এমন নিয়ন্ত্রণ চায় যা একটা shared, পুরোপুরি managed service দিতে পারে না। পরীক্ষায় KMS আর CloudHSM পাশাপাশি রেখে একটা বাছতে বলা খুব প্রিয় প্রশ্ন, তাই পুরো লেসন শেষ হবে একটা তুলনায়।

#HSM জিনিসটা কী

Hardware security module (HSM) হলো একটাই কাজের জন্য বানানো আলাদা একটা computer: cryptographic key বানানো, জমা রাখা আর ব্যবহার করা, এমনভাবে যে key কখনো খোলা অবস্থায় তার বাইরে যায় না। Application তাকে ডেটা পাঠায় আর ফল ফেরত পায় (ciphertext, plaintext, signature), key কখনো পায় না। এটা tamper-resistant: case খুললে, ফুটো করলে বা ভেতরে probe ঢোকালে সে নিজের key মুছে ফেলে। ব্যাংক, card network, certificate authority আর সরকার বহু বছর ধরে HSM ব্যবহার করছে। KMS নিজেও HSM-এর ওপরই চলে; পার্থক্য হলো HSM-এর মালিক কে আর নিয়ন্ত্রণ কার হাতে।

#CloudHSM তোমাকে কী দেয়

AWS CloudHSM তোমাকে AWS cloud-এ HSM ভাড়া দেয়:

• Dedicated, single-tenant hardware। প্রতিটা HSM শুধু তোমার; অন্য কোনো customer-এর key তাতে থাকে না। উল্টো দিকে KMS multi-tenant: অনেক customer-এর key একই AWS HSM-এর বহরে থাকে, software দিয়ে আলাদা করা।
• তোমার VPC-তে। প্রতিটা HSM তোমার বাছাই করা subnet-এ একটা elastic network interface হিসেবে বসে, private IP address নিয়ে। তোমার application নিজের network দিয়েই তার কাছে যায়।
• Hardware সামলায় AWS, key সামলাও তুমি। AWS device বসায়, firmware patch করে, ঠিক চলছে কি না নজর রাখে, নষ্ট hardware বদলে দেয় আর encrypted backup নেয়। HSM user আর key বানাও তুমি, আর সেগুলো ব্যবহার করতে পারো শুধু তুমিই: তোমার HSM-এ AWS-এর কোনো login নেই। Slide এক লাইনে বলে দেয়: KMS মানে encryption-এর software সামলায় AWS; CloudHSM মানে AWS encryption-এর hardware দেয়।
• Standard crypto interface। তোমার software HSM-এর সাথে কথা বলে CloudHSM client SDK দিয়ে: একটা PKCS#11 library, Java-র জন্য একটা JCE provider, Windows-এর জন্য CNG আর key storage provider, আর একটা OpenSSL engine। On-premises HSM-এর জন্য লেখা software অল্প বদলেই চলে আসে।
• Symmetric আর asymmetric দুই ধরনের key: AES key, RSA আর ECC key pair, HMAC key, signing আর hashing, random number। KMS-এও এই ধরনের key আছে, কিন্তু CloudHSM তার HSM যত algorithm আর key length সমর্থন করে সবই দেয়, আগে থেকে ঠিক করা ছোট তালিকা না।
• প্রতি HSM-এর প্রতি ঘণ্টা ধরে bill, আগাম কোনো খরচ নেই আর কোনো free tier নেই (us-east-1-এ HSM-ঘণ্টায় প্রায় ১.৬০ USD, কিছু Region-এ বেশি; high availability-র জন্য দুটো HSM মানে মাসে ২,০০০ USD-এর বেশ ওপরে)। KMS-এর free tier আছে, আর বেশিরভাগ কাজে খরচ কয়েক cent।

#কে কী করে

CloudHSM বোঝার সবচেয়ে কাজের ছবি হলো: কে কী ছুঁতে পারে তার একটা তালিকা।

এর তিনটা ফল:

• দুটো আলাদা permission ব্যবস্থা। AWS API দিয়ে কে cluster সামলাবে, তা ঠিক করে IAM। আর কে key ব্যবহার করবে, তা ঠিক করে HSM user, যারা আছে শুধু HSM-এর ভেতরে। CloudHSM-এর পুরো permission পাওয়া একজন IAM administrator-ও কিছু decrypt করতে পারে না; কিন্তু সে HSM মুছে ফেলতে পারে, তাই IAM-ও শক্ত রাখতে হবে।
• AWS তোমার key উদ্ধার করতে পারে না। HSM password-এর কোনো copy AWS রাখে না, কোনো গোপন দরজাও নেই। সব admin আর crypto user-এর credential হারালে key, আর সেই key দিয়ে encrypt করা সবকিছু, চিরতরে হারানো। কমপক্ষে দুজন admin রাখো, credential আলাদা আলাদা জায়গায় offline রাখো, আর quorum authentication চালু করো (স্পর্শকাতর কাজে N জন কর্মকর্তার মধ্যে M জনের অনুমোদন লাগবে)। Admin-রা multi-factor authentication-ও ব্যবহার করতে পারে।
• Channel-টা end-to-end encrypted। Client SDK HSM-এর সাথে এমন channel-এ কথা বলে যা AWS পড়তে পারে না (তোমার নিয়ন্ত্রণের certificate দিয়ে TLS)। HSM-এর security group-এ client-এর জন্য port 2223 থেকে 2225 খোলা থাকতে হবে।

#FIPS 140: level মানে কী, আর পরীক্ষা কী চায়

FIPS 140 হলো cryptographic module-এর জন্য মার্কিন সরকারের standard, NIST-এর validation program-এর অধীনে স্বীকৃত lab-এ যাচাই হয়। এর চারটা security level আছে; এখানে দরকারি দুটো:

• Level 2: tamper evidence (কেউ বাক্স খুললে seal দেখে বোঝা যায়) আর role-ভিত্তিক authentication।
• Level 3: tamper resistance (module হামলা টের পেয়ে নিজের key মুছে দেয়), পরিচয়-ভিত্তিক authentication, আর key যে interface দিয়ে যায় সেগুলোর শারীরিক আলাদা থাকা।

২০২১ সাল থেকে নতুন validation-এ FIPS 140-2-এর জায়গা নিয়েছে FIPS 140-3; level-গুলোর মানে মোটামুটি একই।

আজকের তথ্য:

• CloudHSM: এখনকার HSM type hsm2m.medium (২০২৪ থেকে) FIPS 140-3 Level 3 validated। পুরোনো hsm1.medium ছিল FIPS 140-2 Level 3; এপ্রিল ২০২৫ থেকে নতুন cluster-এ এটা নেওয়া যায় না, ৩১ মার্চ ২০২৬-এ এর support শেষ হয়েছে, আর চালু cluster-গুলো hsm2m.medium-এ সরিয়ে নেওয়া হয়েছে। Cluster বানানোর সময়ই বাছতে হয় FIPS mode (শুধু FIPS-অনুমোদিত algorithm) নাকি non-FIPS mode (আরও বেশি algorithm, শুধু hsm2m.medium-এ), পরে mode বদলানো যায় না।
• KMS: এর HSM ২০২৩ সালে FIPS 140-2 Level 3-এ validated হয়েছে, আর এখন FIPS 140-3 Level 3। ২০২৩-এর আগে ছিল Level 2; notes আর অনেক course-এর “KMS = Level 2” কথাটা সেখান থেকেই এসেছে।

#High availability: কয়েকটা Availability Zone জুড়ে cluster

একটা HSM মানে একটা Availability Zone-এ একটা device। তোমার একমাত্র HSM নষ্ট হলে key লাগে এমন প্রতিটা কাজ তার সাথে সাথেই ব্যর্থ, আর ওই key দিয়ে encrypt করা ডেটা নতুন HSM চালু না হওয়া পর্যন্ত decrypt করা যায় না। অর্থাৎ তুমি ব্যবস্থা না করলে CloudHSM highly available না।

তুমি যা বানাও তার একক হলো cluster:

• একটা cluster-এ থাকে ১ থেকে ২৮টা HSM (default quota প্রতি account-এ প্রতি Region-এ ৬টা HSM), একটা Region-এর আলাদা আলাদা AZ-এর subnet-এ বসানো।
• CloudHSM HSM-গুলোকে sync-এ রাখে: একটা HSM-এ বানানো key বা user নিজে থেকেই বাকিগুলোতে copy হয়। HSM থেকে HSM-এ key তোমাকে কখনো নিজে copy করতে হয় না।
• Client SDK সব HSM-এ load ভাগ করে দেয়, আর কোনোটা নষ্ট হলে সেটা বাদ দেয়, তাই বেশি HSM মানে বেশি কাজের ক্ষমতাও।
• CloudHSM কমপক্ষে প্রতি ২৪ ঘণ্টায় একবার cluster-এর encrypted backup নেয়, আর একই Region-এ তোমার হয়ে রেখে দেয়। Backup restore হয় শুধু CloudHSM hardware-এ; AWS তা পড়তে পারে না। Disaster recovery-র জন্য backup অন্য Region-এ copy করে সেখানে তা থেকে cluster বানাতে পারো।
• কোনো HSM নষ্ট হলে CloudHSM সেটা বদলে দেয়, আর নতুন HSM ভরে ওঠে cluster থেকে (একমাত্র HSM হলে সর্বশেষ backup থেকে, তাই ওই backup-এর পরে বানানো key হারিয়ে যায়)।

Production-এর জন্য AWS-এর পরামর্শ আলাদা AZ-এ কমপক্ষে দুটো HSM, আর বদলানোর সময়টুকুও একটা HSM-এ চালানো সম্ভব না হলে তিন বা তার বেশি। একটা cluster অন্য VPC থেকেও ব্যবহার করা যায় (যেমন VPC peering দিয়ে, লেসন ২২.১), যদি network-এর পথ থাকে আর security group client-কে অনুমতি দেয়।

#নিজের HSM দিয়ে AWS service চালানো: KMS custom key store

S3, EBS, RDS, DynamoDB, Lambda আর বাকিরা integrate করে KMS-এর সাথে, CloudHSM-এর সাথে না। তাদের কোনো “আমার HSM ব্যবহার করো” setting নেই। কোনো নিয়ম যদি বলে তোমার S3 bucket আর EBS volume যে key দিয়ে সুরক্ষিত সেগুলো dedicated hardware-এ থাকতে হবে, তাহলে সেতু হলো তোমার CloudHSM cluster-এর ওপর বসানো একটা KMS custom key store (KMS এর নাম দিয়েছে AWS CloudHSM key store):

1. Cluster তৈরি রাখো

   একই account আর Region-এ একটা সক্রিয় cluster, যাতে আলাদা AZ-এ কমপক্ষে দুটো সক্রিয় HSM। তাতে kmsuser নামে একটা আলাদা crypto user বানাও।

2. Key store বানাও আর connect করো

   KMS-এ একটা custom key store বানাও যেটা cluster-কে দেখায় (cluster-এর trust anchor certificate আর kmsuser-এর password দিয়ে), তারপর connect করো। KMS cluster পর্যন্ত network-এর পথ বানায়, kmsuser হয়ে login করে আর তার password বদলে ফেলে।

3. এতে KMS key বানাও

   এমন একটা symmetric KMS key বানাও যার origin এই key store। KMS তোমার HSM-এর ভেতরে একটা 256-bit AES key বানায়; সেটা বের করা যায় না, আর কখনো খোলা অবস্থায় HSM ছাড়ে না।

4. অন্য যেকোনো customer managed key-এর মতো ব্যবহার করো

   ওই key বেছে নাও S3 default encryption, EBS volume, RDS database বা Secrets Manager secret-এর জন্য। Service যথারীতি KMS-কে ডাকে; KMS key policy আর IAM দেখে, তারপর cryptographic কাজটা চালায় তোমার HSM-এ।

কী পাও: KMS-এর integration আর key policy-র নিয়ম, key-এর প্রতিটা ব্যবহারের CloudTrail log (key store-এর ID সহ), আর তোমার দিকে HSM audit log। যেকোনো সময় key store disconnect করতে পারো; disconnect থাকা অবস্থায় কেউ তার key ব্যবহার করতে পারে না, এটা ব্যাংকের নিজের হাতের kill switch।

সীমাগুলো, যেগুলো পরীক্ষায় ভালো ফাঁদ হয়:

• শুধু symmetric encryption key। Custom key store-এ asymmetric, HMAC বা multi-Region key নেই, import করা key material-ও নেই।
• নিজে থেকে key rotation নেই। Rotate করতে নতুন একটা KMS key বানাও আর alias সেটার দিকে সরাও (পুরোনো ডেটা KMS পুরোনো key দিয়েই decrypt করতে থাকে)।
• Key বানাতে আলাদা AZ-এ দুটো সক্রিয় HSM লাগে; বাকি সব কাজ একটাতেও চলে। প্রতিটা cluster কেবল একটা key store-এর পেছনে থাকতে পারে, আর একটা account-এ প্রতি Region-এ সর্বোচ্চ ১০টা custom key store।
• তোমার availability-ই এখন KMS-এর availability। Cluster-এর HSM চলে গেলে, key store disconnect হলে বা kmsuser-এর password বদলালে, ওই key ব্যবহার করা প্রতিটা service আর decrypt করতে পারে না।
• খরচ: KMS key-এর স্বাভাবিক দাম (key-প্রতি মাসে ১ USD আর request) আর HSM-এর ঘণ্টা।

#SSE-C আর Redshift-এর সাথে CloudHSM

Slide আরও দুটো পুরোনো integration যোগ করে:

• S3 SSE-C (লেসন ১০.৮): প্রতিটা request-এর সাথে তুমি যে key পাঠাও, S3 তা দিয়ে encrypt করে ভুলে যায়। তোমার application সেই key-গুলো CloudHSM-এ রাখতে পারে। তবে মনে রেখো: S3-কে পাঠাতে হলে key-কে HSM ছেড়ে বের হতেই হয়, তাই এতে জমা থাকা key সুরক্ষিত, কিন্তু ব্যবহারের সময়টা না। আজকের দিনে custom key store আর SSE-KMS key-কে HSM-এর ভেতরেই রাখে, সেটাই বেশি পরিচ্ছন্ন নকশা।
• Amazon Redshift (লেসন ১৭.২)-এর একটা option আছে cluster-এর encryption key একটা HSM-এ রাখার। কোন service দিয়ে Redshift তার key তোমার নিয়ন্ত্রণের hardware module-এ রাখতে পারে, প্রশ্ন এলে উত্তর CloudHSM। নতুন নকশায় Redshift সাধারণত একটা KMS key দিয়ে encrypt হয়, আর সেই key থাকতে পারে CloudHSM key store-এ।

#যেসব কাজে সরাসরি CloudHSM লাগে

কিছু software KMS-এর সাথে না, সরাসরি HSM-এর সাথে কথা বলে। এগুলোই CloudHSM-এর নিজের মাঠ:

• SSL/TLS offload। EC2-র web server (nginx, OpenSSL-সহ Apache, বা Windows-এ IIS) তাদের TLS private key রাখে CloudHSM-এ। প্রতিটা handshake-এর private key-এর ধাপটা server HSM-কে দিয়ে করায়; key কখনো server-এর disk-এ বসে থাকে না। চুরি হওয়া disk-এর copy-তে থাকে শুধু key-এর একটা reference। তোমার TLS যদি ALB, CloudFront বা API Gateway-তে শেষ হয়, সেখানে ACM certificate ব্যবহার করো (লেসন ২১.৪)।
• Transparent Data Encryption (TDE)। Oracle database আর SQL Server তাদের TDE master key রাখে CloudHSM-এ (Oracle PKCS#11 দিয়ে, SQL Server CNG দিয়ে)। এটা EC2-তে তুমি নিজে যে database চালাও তার জন্য; RDS-এর TDE-র নিজস্ব option আছে (লেসন ৭.৪)।
• তোমার নিজের certificate authority। তোমার CA যত certificate দেয় সবগুলো যে private key দিয়ে sign হয়, সেটাই তোমার সবচেয়ে দামি key; সেটা থাকে HSM-এ, sign-ও হয় সেখানে।
• Sign আর যাচাই: code signing, document signing, HMAC দিয়ে payment message-এর প্রমাণ।
• নিজস্ব application, যা PKCS#11, JCE বা CNG দিয়ে লেখা, প্রায়ই on-premises HSM থেকে সরিয়ে আনা।

#CloudHSM বনাম KMS

এবার নিজে সিদ্ধান্তটা নিয়ে দেখো: একটা workload-এর চাহিদায় টিক দাও, তারপর দেখো কোন option জেতে, কোন চাহিদা সেটা ঠিক করে দিল, আর কোন চাহিদাগুলো একে অন্যের সাথে মেলে না।

#কোথায় কোথায় গোলমাল হয়

• একমাত্র HSM নষ্ট। বদলি চালু না হওয়া পর্যন্ত সব কাজ বন্ধ, আর শেষ backup-এর পরে বানানো key হারানো। আলাদা AZ-এ দুই বা তার বেশি HSM চালাও।
• HSM credential হারানো। AWS reset করতে পারে না, key-ও উদ্ধার করতে পারে না। কমপক্ষে দুজন admin রাখো, credential offline রাখো, quorum authentication ব্যবহার করো।
• Client connect করতে পারে না। Cluster-এর security group client থেকে port 2223 থেকে 2225 খোলেনি, client এমন VPC-তে যেখান থেকে HSM-এর subnet-এ route নেই, বা client SDK-এর version hsm2m.medium-এর জন্য পুরোনো (Client SDK 5 লাগে)।
• Custom key store key বানাতে পারে না। আলাদা AZ-এ দুটোর কম সক্রিয় HSM, বা store disconnect করা।
• Custom key store-এর অধীনে সবকিছু decrypt হওয়া বন্ধ। Store disconnect হয়েছে, cluster-এ কোনো সক্রিয় HSM নেই, বা কেউ kmsuser-এর password বদলেছে। Connection state-এ নজর রাখো, আর kmsuser শুধু KMS-এর জন্য রাখো।
• কেউ custom key store-এ নিজে থেকে rotation বা multi-Region key আশা করছে। দুটোর কোনোটাই নেই; হাতে rotation-এর পরিকল্পনা করো, আর প্রতি Region-এ একটা করে key store রাখো।
• একজন IAM user cluster মুছে দিল। CloudHSM API-র IAM permission key ব্যবহার করতে না পারলেও infrastructure ধ্বংস করতে পারে। এগুলো সীমিত রাখো, আর backup রাখো (DR-এর জন্য অন্য Region-এ copy করা)।
• ভুল cluster mode। FIPS mode-এ বানানো cluster non-FIPS algorithm ব্যবহার করতে পারে না, আর mode বদলানো যায় না; backup-ও restore হয় শুধু একই mode-এর cluster-এ।
• বিশাল অপ্রত্যাশিত bill। ব্যবহার হোক বা না হোক, HSM যতক্ষণ আছে ততক্ষণ প্রতি ঘণ্টার bill। Test-এর HSM মুছে ফেলো, আর dedicated hardware-এর কোনো দরকার না থাকলে KMS নাও।

#System design-এ CloudHSM

• নিয়ন্ত্রিত core system: একটা ব্যাংক, একটা payment switch বা একটা সরকারি পরিচয়পত্রের system, যার key dedicated hardware-এ রাখতেই হবে, সে ব্যবহার করে তিন-AZ-এর একটা cluster, AWS service-এর জন্য একটা custom key store, আর নিজের payment ও signing software-এর জন্য সরাসরি PKCS#11 বা JCE access।
• Private PKI: ভেতরের certificate authority-র root বা issuing CA-র key থাকে CloudHSM-এ। নিজে HSM না চালিয়ে managed private CA চাইলে বিকল্প AWS Private CA (লেসন ২১.৪)।
• On-premises থেকে migration: যে application আগে থেকেই on-premises HSM-এর সাথে PKCS#11-এ কথা বলে, সে EC2-তে সরে এসে অল্প code বদলে CloudHSM-এর সাথে কথা বলে।
• KMS-এর সাথে স্তরে স্তরে সুরক্ষা: বেশিরভাগ ডেটায় সাধারণ KMS key; শুধু যেসব system-এর নাম নিয়ন্ত্রক সংস্থা বলেছে সেগুলোতে custom key store। এতে bill আর operational চাপ দুটোই কম থাকে।

#নিজে করে দেখো

CloudHSM-এ HSM-ঘণ্টা ধরে সত্যিকারের টাকা লাগে, তাই শেষে সব মুছে ফেলো। এই command-গুলো AWS CLI v2 আর Client SDK 5-এর CloudHSM CLI ব্যবহার করে। Password-গুলো শুধু placeholder: script-এ কখনো আসল password লিখবে না।

# 1. Create a cluster in FIPS mode across two private subnets in different AZs
aws cloudhsmv2 create-cluster --hsm-type hsm2m.medium --mode FIPS \
  --subnet-ids subnet-0a1b2c3d4e5f60001 subnet-0a1b2c3d4e5f60002
# { "Cluster": { "ClusterId": "cluster-1a23b4cdefg", "State": "CREATE_IN_PROGRESS", "HsmType": "hsm2m.medium", "Mode": "FIPS", ... } }

# 2. Add the first HSM, then read the cluster's certificate signing request
aws cloudhsmv2 create-hsm --cluster-id cluster-1a23b4cdefg --availability-zone ap-southeast-1a
aws cloudhsmv2 describe-clusters --filters clusterIds=cluster-1a23b4cdefg \
  --query 'Clusters[0].[State,Certificates.ClusterCsr]' --output text > cluster.csr
# UNINITIALIZED  -----BEGIN CERTIFICATE REQUEST----- ...

# 3. Sign it with your own CA (openssl here), then initialize the cluster
openssl x509 -req -days 3652 -in cluster.csr -CA customerCA.crt -CAkey customerCA.key \
  -CAcreateserial -out cluster.crt
aws cloudhsmv2 initialize-cluster --cluster-id cluster-1a23b4cdefg \
  --signed-cert file://cluster.crt --trust-anchor file://customerCA.crt

# 4. On an EC2 client with Client SDK 5: activate the cluster and create users
sudo /opt/cloudhsm/bin/configure-cli -a 10.0.1.25        # the HSM's private IP
/opt/cloudhsm/bin/cloudhsm-cli interactive
#   aws-cloudhsm > cluster activate                         (set the admin password)
#   aws-cloudhsm > login --username admin --role admin
#   aws-cloudhsm > user create --username kmsuser --role crypto-user
#   aws-cloudhsm > user create --username payments --role crypto-user

# 5. Add a second HSM in another AZ (needed for HA and for a custom key store)
aws cloudhsmv2 create-hsm --cluster-id cluster-1a23b4cdefg --availability-zone ap-southeast-1b
aws cloudhsmv2 describe-clusters --filters clusterIds=cluster-1a23b4cdefg \
  --query 'Clusters[0].Hsms[].[HsmId,AvailabilityZone,State]' --output table
# |  hsm-111aaa222bbb  |  ap-southeast-1a  |  ACTIVE  |
# |  hsm-333ccc444ddd  |  ap-southeast-1b  |  ACTIVE  |

# 6. Create and connect a KMS custom key store on the cluster
aws kms create-custom-key-store --custom-key-store-name bank-hsm-store \
  --cloud-hsm-cluster-id cluster-1a23b4cdefg \
  --trust-anchor-certificate file://customerCA.crt \
  --key-store-password '<kmsuser-password>'
# { "CustomKeyStoreId": "cks-1234567890abcdef0" }
aws kms connect-custom-key-store --custom-key-store-id cks-1234567890abcdef0
aws kms describe-custom-key-stores --custom-key-store-id cks-1234567890abcdef0 \
  --query 'CustomKeyStores[0].ConnectionState'
# "CONNECTED"

# 7. Create a KMS key whose material lives in your HSMs, and use it with S3
aws kms create-key --origin AWS_CLOUDHSM --custom-key-store-id cks-1234567890abcdef0 \
  --description "loan documents" --query 'KeyMetadata.[KeyId,Origin]'
# [ "1234abcd-12ab-34cd-56ef-1234567890ab", "AWS_CLOUDHSM" ]
aws s3 cp loan-2026-0042.pdf s3://bank-loans-example/ --sse aws:kms \
  --sse-kms-key-id 1234abcd-12ab-34cd-56ef-1234567890ab

# 8. Copy the latest backup to another Region for DR
aws cloudhsmv2 describe-backups --filters clusterIds=cluster-1a23b4cdefg \
  --query 'Backups[-1].BackupId' --output text
# backup-abcdefghijk
aws cloudhsmv2 copy-backup-to-region --destination-region ap-south-1 --backup-id backup-abcdefghijk

# 9. Clean up (keys in the store first, then the store, the HSMs and the cluster)
aws kms schedule-key-deletion --key-id 1234abcd-12ab-34cd-56ef-1234567890ab --pending-window-in-days 7
aws kms disconnect-custom-key-store --custom-key-store-id cks-1234567890abcdef0
aws cloudhsmv2 delete-hsm --cluster-id cluster-1a23b4cdefg --hsm-id hsm-333ccc444ddd
aws cloudhsmv2 delete-hsm --cluster-id cluster-1a23b4cdefg --hsm-id hsm-111aaa222bbb
aws cloudhsmv2 delete-cluster --cluster-id cluster-1a23b4cdefg

Console-এও চেষ্টা করো: cluster-এর CloudWatch Logs group খুলে তোমার login আর key বানানোর HSM audit log entry দেখো, তারপর একই key-এর KMS call খুঁজে বের করো CloudTrail-এ। Custom key store মোছা যায় শুধু তার key-গুলো চলে যাওয়ার পরে (waiting period শেষে)।

#সারসংক্ষেপ

মূল কথাগুলো

• CloudHSM = তোমার VPC-তে dedicated, single-tenant HSM। Hardware সামলায় AWS; user আর key সামলাও শুধু তুমি। AWS তোমার key ব্যবহার করতে পারে না, আর credential হারালে key উদ্ধারও করতে পারে না।
• IAM সামলায় cluster (API); key নিয়ন্ত্রণ করে HSM user (admin, crypto user)। Log: API call-এর জন্য CloudTrail, HSM audit log যায় CloudWatch Logs-এ।
• FIPS: CloudHSM-এর hsm2m.medium FIPS 140-3 Level 3; KMS-ও এখন Level 3 (২০২৩-এর আগে Level 2)। পুরোনো প্রশ্ন এখনো “KMS = Level 2” বলতে পারে; ভরসা রাখো এই keyword-গুলোয়: single-tenant, exclusive control, PKCS#11/JCE/CNG, SSL/TLS offload, TDE।
• High availability: কয়েকটা AZ-এ HSM নিয়ে একটা cluster, নিজে থেকেই sync হয় আর client SDK load ভাগ করে; একটা HSM মানে single point of failure। Backup কমপক্ষে দিনে একবার, অন্য Region-এ copy করা যায়।
• AWS service CloudHSM ব্যবহার করে শুধু KMS custom key store দিয়ে (শুধু symmetric key, নিজে থেকে rotation নেই, multi-Region key নেই, key বানাতে আলাদা AZ-এ দুটো সক্রিয় HSM)। Key পুরোপুরি AWS-এর বাইরে → external key store (XKS)।
• KMS: multi-tenant, প্রায় সব service-এর সাথে integrated, নিজে থেকে rotation, free tier, সস্তা। CloudHSM: HSM-ঘণ্টা ধরে দাম, free tier নেই, চালাও তুমি।

নিজেকে যাচাই করো: CloudHSM বনাম KMS৩০টি প্রশ্ন