AWS KMS খুঁটিয়ে

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

• AWS KMS কী করে, বুঝিয়ে বলতে: তোমার হয়ে encryption key বানায়, জমা রাখে আর ব্যবহার করে; প্রতিটা ব্যবহার IAM আর key policy দিয়ে যাচাই হয়, আর প্রতিটা ব্যবহার CloudTrail-এ log হয়।
• Symmetric key (AES-256, প্রতিটা AWS service যেটা ব্যবহার করে) আর asymmetric key (AWS-এর বাইরে encryption আর digital signature-এর জন্য RSA ও ECC pair) আলাদা করতে, আর HMAC key কোথায় বসে জানতে।
• AWS owned key, AWS managed key আর customer managed key-এর মধ্যে খরচ, rotation, policy-র নিয়ন্ত্রণ আর শেয়ার করা নিয়ে তুলনা করতে, আর imported key material হলে কী বদলায় জানতে।
• Rotation (৯০ থেকে ২,৫৬০ দিন পরপর নিজে নিজে, on-demand, বা alias দিয়ে হাতে), alias, grant আর নিরাপদে delete (৭ থেকে ৩০ দিন অপেক্ষা) ঠিকঠাক সেট করতে।
• একটা key policy পড়তে, default key policy বুঝিয়ে বলতে, আর অন্য account-কে key policy আর সেই account-এর IAM policy দুটো দিয়েই access দিতে।
• Encrypt করা snapshot অন্য Region-এ কপি করতে, encrypt করা snapshot আর AMI অন্য account-এ শেয়ার করতে, আর multi-Region key ও SSE-KMS object-এর S3 replication ঠিকভাবে ব্যবহার করতে।

#KMS কেন: সব key-এর জন্য একটাই জায়গা

Encryption ততটাই নিরাপদ, যতটা নিরাপদ তার key। লেসন ২১.১-এ দেখেছ ডেটা কোথায় encrypt হয়: পথে চলার সময়, server-এ জমা রাখার সময়, নাকি client-এর হাতেই। প্রতিটা পদ্ধতিতে এমন key লাগে, যেটা ঠিকমতো বানানো, এমন জায়গায় রাখা যেখান থেকে কেউ কপি করতে পারবে না, শুধু ঠিক লোকেরা ব্যবহার করতে পারবে, মাঝে মাঝে বদলাবে, আর কখনো হারাবে না। শত শত database, volume আর bucket-এর জন্য এই কাজ নিজে করা মানে পুরো একজন মানুষের চাকরি, আর ভুল করাও খুব সহজ।

#KMS জিনিসটা কী

AWS Key Management Service (KMS) হলো AWS-এর সেই service, যেটা তোমার হয়ে encryption key বানায়, জমা রাখে, সামলায় আর ব্যবহার করে:

• কঠিন অংশটা AWS চালায়। Key বানানো আর রাখা হয় KMS-এর hardware security module (HSM)-এর ভেতরে। KMS key-এর key material কখনো খোলা অবস্থায় সেখান থেকে বের হয় না; key ব্যবহার করতে তুমি KMS API ডাকো, key download করো না।
• IAM-এর সাথে পুরোপুরি জোড়া। প্রতিটা call-এর অনুমতি দেয় key-এর key policy আর IAM policy মিলে, তাই কোন role কোন key দিয়ে encrypt, decrypt বা manage করতে পারবে, ঠিক তুমিই ঠিক করো।
• Audit করা যায়। Key-এর প্রতিটা ব্যবহার, তুমি করো বা তোমার হয়ে কোনো AWS service করুক, CloudTrail-এ লেখা থাকে (লেসন ১৯.৬): কে, কোন key, কোন কাজ, কখন, কোথা থেকে।
• বেশিরভাগ AWS service-এ আগে থেকেই বসানো। EBS, S3, RDS আর Aurora, DynamoDB, SSM Parameter Store, Secrets Manager, Lambda, SQS, SNS-সহ আরও অনেক service একটা box-এ টিক দিলেই KMS key দিয়ে encrypt করে। প্রশ্নে কোনো AWS service-এর “encryption” শুনলে, প্রায় নিশ্চিত KMS জড়িত।
• সরাসরিও ব্যবহার করা যায়। তোমার নিজের code আর CLI, SDK দিয়ে Encrypt, Decrypt আর GenerateDataKey ডাকতে পারে। এতে secret কখনো plaintext-এ রাখতে হয় না: code-এ বা environment variable-এ database password বা API token থাকলে সেটা encrypt করে রাখো, চালানোর সময় decrypt করো, খোলা অবস্থায় কখনো লিখে রেখো না (লেসন ২১.৩-এ এর managed উপায়গুলো আছে)।

#একটা KMS key আসলে কীভাবে ব্যবহার হয়

#সরাসরি encrypt আর 4 KB-এর সীমা

সবচেয়ে সহজ call হলো Encrypt: তুমি plaintext আর একটা key ID পাঠাও, KMS ফেরত দেয় একটা ciphertext blob। Decrypt সেই blob ফেরত নেয়; key-এর নামও বলতে হয় না, কারণ কোন key দিয়ে encrypt হয়েছিল তা blob-এর ভেতরেই লেখা। ReEncrypt ciphertext-কে KMS-এর ভেতরেই এক key থেকে আরেক key-তে সরিয়ে নেয়, plaintext তোমার সামনে একবারও না এনে।

Encrypt সর্বোচ্চ 4 KB plaintext নেয়। KMS বানানো হয়েছে key, password আর ছোট token-এর জন্য, file-এর জন্য না। এর চেয়ে বড় কিছু হলে KMS ব্যবহার করে envelope encryption, যেটা লেসন ২১.১-এ পুরোটা বোঝানো আছে: GenerateDataKey একটা নতুন data key দেয়, plaintext-এও আর KMS key দিয়ে encrypt করা অবস্থাতেও; ডেটা নিজের কাছেই plaintext data key দিয়ে encrypt হয়, encrypt করা data key ডেটার পাশে রাখা হয়, আর plaintext key ফেলে দেওয়া হয়। S3 (SSE-KMS), EBS আর RDS পর্দার আড়ালে ঠিক এটাই করে।

#দ্বিতীয় তালা

KMS encryption থাকলে ডেটা পড়তে দুটো permission লাগে: একটা resource-এ (যেমন s3:GetObject), আরেকটা key-তে (kms:Decrypt)। Hospital-এর billing team S3 permission দিয়ে bucket-এর সব object পড়তে পারে, তবুও রোগীর report-এ পায় AccessDenied, কারণ key policy-তে তাদের নাম নেই। এই দ্বিতীয় তালা, সাথে audit trail, আর এক click-এ key disable করার ক্ষমতা, এই তিন কারণে সংবেদনশীল ডেটা রাখা হয় customer managed key-এর নিচে (S3-এর দিকটা বিস্তারিত আছে লেসন ১০.৮-এ)।

Call-এর সাথে একটা encryption context-ও যেতে পারে: কিছু key-value জোড়া (S3 দেয় object বা bucket-এর ARN), যেটা ciphertext-এর সাথে বাঁধা থাকে, decrypt করার সময় আবার দিতে হয়, CloudTrail-এ দেখা যায়, আর key policy-র condition-এ বাধ্যতামূলক করা যায়।

#Key-এর ধরন: symmetric, asymmetric, HMAC

#Symmetric key

Symmetric KMS key হলো একটাই AES-256 key, যেটা encrypt-ও করে, decrypt-ও করে। Key বানানোর সময় এটাই default, আর AWS service-গুলো তোমার জমা ডেটা encrypt করতে শুধু এই ধরনটাই ব্যবহার করে (S3, EBS, RDS, DynamoDB আর বাকিরা)। Key নিজে তুমি কখনো পাও না: symmetric KMS key খোলা অবস্থায় বের করার কোনো API নেই, তাই প্রতিটা ব্যবহার একটা KMS call, যার অনুমতি যাচাই হয় আর log হয়।

#Asymmetric key

Asymmetric KMS key হলো একটা key pair: একটা public key আর একটা private key, RSA বা elliptic-curve (ECC) algorithm দিয়ে (China Region-এ চীনের নিজস্ব একটা algorithm আর নতুন post-quantum signature key-ও আছে)। প্রতিটা asymmetric key একটা কাজের জন্য বানানো হয়:

• Encrypt আর decrypt (RSA): public key যার কাছে আছে সে-ই encrypt করতে পারে; decrypt করতে পারে শুধু private key, যেটা কখনো KMS ছাড়ে না।
• Sign আর verify (RSA বা ECC): KMS private key দিয়ে sign করে; public key যার কাছে আছে সে-ই signature verify করতে পারে। Signature ঠিক থাকা মানে প্রমাণ, কে sign করেছে আর message বদলায়নি: এটাই digital signature।

Public key download করা যায় (GetPublicKey) আর যে কাউকে দেওয়া যায়। আসল সুবিধা এটাই: AWS-এর বাইরের যেসব ব্যবহারকারী KMS API ডাকতে পারে না, তারাও সাধারণ tool দিয়ে তোমার জন্য ডেটা encrypt করতে পারে, বা তোমার signature যাচাই করতে পারে। Private key খোলা অবস্থায় বের করা যায় না।

#HMAC key

HMAC key আরেকটা ছোট পরিবার: symmetric key, যেটা GenerateMac আর VerifyMac দিয়ে message authentication code বানায় আর যাচাই করে, যেমন এমন একটা token বানাতে যেটা কেউ বদলালে ধরা পড়ে। Symmetric key-এর মতো এটাও কখনো KMS ছাড়ে না। পরীক্ষার জন্য শুধু একটা পাশের কথা।

#Key-এর মালিক কে: তিন রকম KMS key

Notes AWS owned key থেকে সরাসরি customer managed key-তে চলে যায়। মাঝখানে আরেকটা স্তর আছে, আর পরীক্ষায় তিনটা নিয়েই প্রশ্ন আসে।

#AWS owned key

AWS owned key AWS service-এর নিজের, থাকে AWS-এর নিজের account-এ। একসাথে অনেক account-এর ডেটা রক্ষা করে, তুমি কখনো দেখতে পাও না, আর বিনা পয়সায়: মাসিক fee নেই, request-এর টাকাও নেই। S3-এর default encryption SSE-S3, SQS-এর SSE-SQS আর DynamoDB-র default encryption এগুলো ব্যবহার করে। এগুলো দেখা, audit করা, rotate করা, disable করা বা share করা, কোনোটাই তুমি পারো না।

#AWS managed key

AWS managed key তোমার account-এ বানায় কোনো service, প্রথম যেদিন তুমি নিজের key না দিয়ে “KMS encryption” বেছে নাও। এদের alias শুরু হয় aws/ দিয়ে: aws/s3, aws/ebs, aws/rds, aws/lambda। মাসিক fee নেই, তবে প্রতিটা request-এর টাকা লাগে। AWS এগুলো প্রতি বছর rotate করে (মে ২০২২ থেকে; তার আগে তিন বছরে একবার)। এদের key policy পড়তে পারো আর ব্যবহার CloudTrail-এ দেখতে পারো, কিন্তু policy বদলাতে পারো না, নিজের সময়সূচিতে rotate করতে পারো না, disable বা delete করতে পারো না, আর পরীক্ষার জন্য সবচেয়ে জরুরি কথা, অন্য কোনো account এগুলো কখনো ব্যবহার করতে পারে না।

#Customer managed key

Customer managed key হলো যেগুলো তুমি নিজে বানাও। Key policy তুমি লেখো, কে key সামলাবে আর কে শুধু ব্যবহার করবে ঠিক করো, rotation চালু করো, বিপদে key disable করো, delete-এর schedule করো, tag দাও, আর অন্য account-কে access দাও। প্রতিটার খরচ মাসে ১ USD, সাথে request-এর টাকা। যখনই প্রশ্নে নিয়ন্ত্রণের দরকার দেখবে, এটাই নাও: নিজের key policy, অন্য account-এর সাথে শেয়ার, নিজের মতো rotation period, disable করার ক্ষমতা, বা কাজের ভাগাভাগি।

#Imported key material

সাধারণত key material বানায় KMS নিজে (origin AWS_KMS)। চাইলে material ছাড়া একটা key বানাতে পারো (origin EXTERNAL) আর নিজের HSM-এ বানানো 256-bit material import করতে পারো, যেমন “key আমাদের নিজেদেরই বানাতে হবে” ধরনের নিয়ম মানতে, বা AWS-এর বাইরে একটা কপি রাখতে। দাম একই, মাসে ১ USD। পার্থক্যগুলো:

• নিজে নিজে rotation নেই। Slide আর পরীক্ষা বলে “imported key শুধু হাতে rotate করা যায়”: নতুন key বানাও, alias সেদিকে ঘুরিয়ে দাও। ২০২৫ থেকে KMS একই key-তে নতুন material import করে on-demand rotate করতেও দেয়, কিন্তু automatic rotation এখনো নেই।
• Material-এর দায়িত্ব তোমার। এতে expiration দিতে পারো, মুছে ফেলতে পারো (DeleteImportedKeyMaterial), আবার import করতে পারো। Material না থাকলে key ব্যবহারই করা যায় না।
• টিকে থাকার দায়ও তোমার। নিজের কপি হারিয়ে গেলে আর material মুছে গেলে বা মেয়াদ ফুরালে, ডেটাও শেষ।

নিজের HSM-এ (CloudHSM cluster) বা পুরোপুরি AWS-এর বাইরে (external key store) রাখা key-এর কথা আছে লেসন ২১.৫-এ।

#KMS-এর খরচ কত

• প্রতিটা customer managed key-এর জন্য মাসে ১ USD, KMS-এর বানানো হোক বা import করা, single-Region হোক বা multi-Region-এর প্রতিটা key। Rotation-এ প্রথমবার মাসে ১ USD বাড়ে, দ্বিতীয়বার আরও ১ USD; এরপরের rotation-এ আর বাড়ে না।
• Request: বেশিরভাগ Region-এ প্রতি ১০,০০০ symmetric request-এ প্রায় ০.০৩ USD; asymmetric কাজের দাম বেশি (RSA signing-এ প্রতি ১০,০০০-এ প্রায় ০.১৫ USD)।
• Free tier: সব Region মিলিয়ে মাসে ২০,০০০ request (asymmetric কাজ বাদে)।
• AWS managed key: মাসিক fee নেই, request-এর টাকা আছে। AWS owned key: বিনা পয়সায়। Pending deletion অবস্থার key-এর bill হয় না।

হিসাব করে দেখো। Hospital-এর তিনটা customer managed key (report, scan, database), rotation চালু, এর মধ্যে দুবার rotate হয়েছে, আর S3 মাসে ৪০ লাখ KMS request করে: key-এর জন্য ৩ × (১ + ২) = ৯ USD, request-এর জন্য ৪০০ × ০.০৩ = ১২ USD, মাসে মোট প্রায় ২১ USD। S3 Bucket Key চালু করলে request-এর অংশ প্রায় শূন্যে নেমে আসে (লেসন ১০.৮)।

#Rotation

KMS key rotate করলে নতুন key material তৈরি হয়, কিন্তু key ID, ARN, alias, policy আর grant একই থাকে। KMS পুরোনো সব material রেখে দেয়, আর পুরোনো ciphertext decrypt করতে ঠিকটা নিজেই বেছে নেয়, তাই application বা AWS service-এ কিছুই বদলাতে হয় না। Rotation আগের ডেটা re-encrypt করে না, আর এর মধ্যে ব্যবহার হওয়া data key-ও বদলায় না: এটা এখন থেকে যা encrypt হবে সেটাকে রক্ষা করে।

• Customer managed key-এ automatic rotation নিজে চালু করতে হয়; period ঠিক হয় --rotation-period-in-days দিয়ে।
• On-demand rotation (rotate-key-on-demand) এখনই rotate করে, যেমন leak-এর সন্দেহ হলে বা runbook কাজ করে কি না প্রমাণ করতে, automatic সময়সূচিতে হাত না দিয়ে।
• হাতে rotation মানে একটা নতুন key বানিয়ে alias সেটার দিকে ঘুরিয়ে দেওয়া। Alias ব্যবহার করা application নতুন key-তে চলে যায়; পুরোনো key দিয়ে বানানো ciphertext-এ এখনো পুরোনো key-এর নাম লেখা, তাই decrypt-এর জন্য পুরোনো key রেখে দাও (delete কোরো না)।
• প্রতিটা rotation CloudTrail-এ একটা RotateKey event আর EventBridge-এ একটা event লেখে, auditor-এর কাছে এটাই তোমার প্রমাণ।

#Alias, delete আর grant

• Alias হলো সহজ নাম, যেমন alias/reports-key। একটা key-এর কয়েকটা alias থাকতে পারে, প্রতিটা alias এক Region-এ একটা key-কেই দেখায়, আর alias অন্য key-এর দিকে ঘোরানো যায় (এটাই হাতে rotation)। alias/aws/ দিয়ে শুরু নামগুলো AWS managed key-এর জন্য সংরক্ষিত।
• Key-এর অবস্থা: একটা key হতে পারে Enabled, Disabled (কোনো cryptographic ব্যবহার নেই; যেকোনো সময় আবার enable করা যায়), বা Pending deletion। বিপদে নিরাপদ বোতাম হলো disable।
• Delete কখনো সাথে সাথে হয় না। ৭ থেকে ৩০ দিনের অপেক্ষা (default ৩০) দিয়ে schedule করতে হয়। অপেক্ষার সময় key ব্যবহার করা যায় না, আর delete বাতিল করা যায়। সময় পেরোলে key আর তার material শেষ, আর তার নিচে encrypt করা সবকিছু চিরতরে উদ্ধারের বাইরে। Pending deletion অবস্থার key ব্যবহারের চেষ্টা CloudTrail-এ (বা একটা CloudWatch alarm দিয়ে) নজরে রাখো: সেগুলো বলে দেয় key এখনো দরকার। Delete করা যায় শুধু customer managed key।
• Grant কোনো principal-কে key policy না বদলেই key ব্যবহারের অস্থায়ী, সরু অনুমতি দেয়। AWS service নিজেরাই এগুলো বানায়: EC2 যখন encrypt করা EBS volume attach করে, তখন একটা grant বানায় যাতে host volume-এর data key decrypt করতে পারে। এই কারণেই অন্য account-এ encrypt করা volume বা AMI launch করা role-এর kms:CreateGrant লাগে।

#Key policy

#প্রতিটা key-এর ঠিক একটা

Key policy হলো একটা KMS key-এর গায়ে লাগানো resource-based policy, IAM policy-র মতো একই JSON-এ লেখা (principal, action, resource, condition)। S3 bucket policy-র মতোই কাজ করে, শুধু একটা বড় পার্থক্য: key policy ছাড়া KMS key-এর access নিয়ন্ত্রণই করা যায় না। S3-এ শুধু IAM দিয়েই access দেওয়া যায়; KMS-এ IAM policy তখনই কাজ করে, যখন key policy account-কে ওই key-এর জন্য IAM ব্যবহারের অনুমতি দেয়।

#Default key policy

নিজের policy না দিয়ে key বানালে KMS default key policy লাগিয়ে দেয়। এর মূল statement account-এর root principal-কে পুরো access দেয়:

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

এর মানে এই না যে শুধু root user key ব্যবহার করতে পারবে। মানে হলো পুরো account-কে বিশ্বাস করা হলো, তাই key কে ব্যবহার করবে আর কে সামলাবে, ঠিক করবে ওই account-এর IAM policy। Console থেকে বানালে সাথে তোমার বেছে নেওয়া key administrator আর key user-দের জন্য আলাদা statement-ও যোগ হয়।

#Custom key policy

Custom key policy নির্দিষ্ট user আর role-এর নাম বলে দেয়: কে key administer করবে (policy বদলানো, rotate, disable, delete-এর schedule) আর কে শুধু ব্যবহার করবে (encrypt, decrypt, data key বানানো)। Auditor ঠিক এই কাজের ভাগাভাগিটাই খোঁজেন: key যারা সামলায় তারা ডেটা পড়তে পারবে না, আর যে app ডেটা পড়ে সে key delete করতে পারবে না। আর অন্য account-এর জন্য key খোলার উপায়ও এই custom policy।

#অন্য account-এর জন্য দুই জায়গায় অনুমতি

Account A-এর একটা key account B-কে ব্যবহার করতে দিতে:

1. Account A-তে key policy account B-কে অনুমতি দেবে (তার root principal-কে, বা সেখানকার নির্দিষ্ট একটা role-কে)।
2. Account B-তে IAM policy সেই user বা role-কে key-এর পুরো ARN-এ KMS action-গুলোর অনুমতি দেবে (অন্য account-এর alias এখানে চলে না)।

দুটোই লাগবে। Account B-কে বিশ্বাস করা key policy শুধু B-এর administrator-দের অনুমতি ভাগ করে দেওয়ার সুযোগ দেয়; আবার B-এর কোনো role-এর IAM policy থাকলেও key policy-তে মিল না থাকলে সে আটকে যায়। Policy মূল্যায়নের নিয়ম লেসন ২.২-এর মতোই; ওপরে লেসন ২০.১-এর SCP আর organization-এর অন্য guard rail তবুও deny করতে পারে।

{
  "Sid": "Allow the client account to use the key",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
  "Action": ["kms:Decrypt", "kms:DescribeKey", "kms:CreateGrant", "kms:ReEncrypt*", "kms:GenerateDataKey*"],
  "Resource": "*"
}

#KMS key নিজের Region ছাড়ে না

একটা KMS key থাকে ঠিক একটা Region-এ। Tokyo-র key Virginia-র কিছুই decrypt করতে পারে না, আর Singapore-এর key ARN Mumbai-তে অর্থহীন। তাই encrypt করা ডেটা অন্য Region-এ গেলে সেটা destination Region-এর একটা key দিয়ে re-encrypt করতে হয়।

#Encrypt করা snapshot অন্য Region-এ কপি

Encrypt করা EBS বা RDS snapshot অন্য Region-এ কপি করলে সেটা source key দিয়ে decrypt হয়ে destination key দিয়ে re-encrypt হয়। কাজটা AWS কপির ভেতরেই করে (KMS ReEncrypt); তুমি শুধু destination key-এর নাম দাও, আর দুটো key-তেই তোমার permission লাগে।

• RDS: encrypt করা snapshot কপিতে destination Region-এর KMS key দেওয়া বাধ্যতামূলক।
• EBS: key না দিলে কপি ব্যবহার করে destination Region-এর default EBS key (সাধারণত aws/ebs)। এতে কাজ চলে, কিন্তু aws/ebs-এর নিচের কপি পরে আর কোনো account-এর সাথে share করা যাবে না, তাই share-এর পরিকল্পনা থাকলে customer managed key দাও।
• Encrypt না করা snapshot কপির সময় encrypt করা যায়; encrypt করা snapshot-কে unencrypted কপি করা যায় না।

#Encrypt করা snapshot অন্য account-এর সাথে share

ধাপগুলো, notes আর slide-এর সাথে মিলিয়ে:

1. ১. Customer managed key দিয়ে encrypt

   Snapshot-টা তোমার account-এর একটা customer managed key দিয়ে encrypt করা থাকতে হবে। AWS managed key (aws/ebs, aws/rds) দিয়ে encrypt করা থাকলে share করা যায় না: ওই key-এর policy শুধু তোমার account-কে বিশ্বাস করে, আর বদলানো যায় না। আগে snapshot কপি করে customer managed key দিয়ে re-encrypt করো, তারপর কপিটা share করো।

2. ২. Target account-এর জন্য key policy খোলো

   Key policy-তে এমন একটা statement যোগ করো, যেটা target account-কে অনুমতি দেয় (kms:DescribeKey, kms:CreateGrant, kms:Decrypt, kms:ReEncrypt*, kms:GenerateDataKey*)।

3. ৩. Snapshot share করো

   EBS: target account ID দিয়ে modify-snapshot-attribute। RDS: restore attribute দিয়ে modify-db-snapshot-attribute। Encrypt করা snapshot account-এর সাথে share করা যায়, কখনো public করা যায় না।

4. ৪. Target-এ: কপি করে re-encrypt

   Target account, যার IAM policy-ও source key-এর অনুমতি দেয়, shared snapshot-টা কপি করে, আর কপিটা নিজের customer managed key দিয়ে encrypt করে। তার কপি আর তোমার key-এর ওপর নির্ভর করে না।

5. ৫. Target-এ: volume বানানো বা restore

   Target নিজের কপি থেকে EBS volume বানায়, বা RDS instance restore করে।

EBS আর RDS-এর দিকটা আছে লেসন ৫.২ আর লেসন ৭.৪-এ; এখানে নজর key-এর ওপর।

#Encrypt করা AMI share করা

Encrypt করা EBS snapshot সহ একটা AMI একই যুক্তি মানে (AMI share করার সাধারণ কথা আছে লেসন ৪.৩-এ):

1. AMI-এর snapshot-গুলো source account-এর একটা customer managed key দিয়ে encrypt করা (aws/ebs না; দরকার হলে আগে customer managed key দিয়ে AMI কপি করো)।
2. Image attribute বদলে target account-এর জন্য একটা launch permission যোগ করো।
3. AMI-এর snapshot যে KMS key দিয়ে encrypt, সেটা target account-এর সাথে share করো (key policy)।
4. Target account-এর IAM role বা user-এর ওই key-তে kms:DescribeKey, kms:ReEncrypt*, kms:CreateGrant আর kms:Decrypt লাগবে।
5. Launch করার সময় target চাইলে volume re-encrypt করতে নিজের account-এর একটা নতুন KMS key দিতে পারে, অথবা আগে নিজের key দিয়ে AMI কপি করে নিতে পারে, যাতে source key-এর ওপর আর নির্ভর না থাকে।

এবার নিজে ধাপগুলো মিলিয়ে দেখো: কী share হচ্ছে, কোন key, কোন setting বেছে নাও, আর দেখো কোন ধাপে আটকায়।

#Multi-Region key

Multi-Region key (AWS-এর diagram-এ MRK) হলো বিভিন্ন Region-এ থাকা কয়েকটা KMS key-এর একটা সেট, যারা একে অন্যের জায়গায় চলে: একটা primary key আর তার replica key-দের key ID একই (শুরু হয় mrk- দিয়ে), key material একই, key spec আর rotation-ও একই। এক Region-এ encrypt করা ডেটা আরেক Region-এ re-encrypt ছাড়াই আর Region পেরিয়ে KMS না ডেকেই decrypt করা যায়।

arn:aws:kms:ap-southeast-1:111122223333:key/mrk-1234abcd12ab34cd56ef1234567890ab   primary
arn:aws:kms:ap-south-1:111122223333:key/mrk-1234abcd12ab34cd56ef1234567890ab       replica
arn:aws:kms:eu-west-1:111122223333:key/mrk-1234abcd12ab34cd56ef1234567890ab        replica

যা মনে রাখবে:

• Global না। Multi-Region key থাকে শুধু সেই Region-গুলোতে যেখানে তুমি replicate করেছ (primary আর replica), সব জায়গায় না।
• প্রতিটা key আলাদাভাবে সামলানো হয়। প্রতিটা replica নিজেই একটা KMS resource, নিজের key policy, grant, alias, tag আর enabled অবস্থা সহ, আর প্রতিটার bill মাসে ১ USD। ভাগ করা শুধু material, key ID, key spec আর rotation; rotation চালু করা আর on-demand rotation শুরু করা হয় primary-তে।
• বানানোর সময়ই ঠিক করো। আগের একটা single-Region key-কে multi-Region বানানো যায় না। Primary-র Region অনেকক্ষণ হারিয়ে গেলে একটা replica-কে primary বানানো যায়।
• দরকার হলে তবেই। AWS default হিসেবে single-Region key-এর পরামর্শ দেয়: একটা key অনেক Region-এ থাকলে একটা ভুলের প্রভাবও বড় হয়। Multi-Region key-এর জায়গা হলো এমন client-side encryption, যেটা কয়েকটা Region-এ decrypt করতে হবে, অনেক Region-এ sign বা verify করা global application, আর এমন disaster recovery যেখানে primary Region ছাড়াই decrypt করতে হবে।

#Client-side encryption সহ DynamoDB global table

DynamoDB global table নিজেই multi-Region, আর DynamoDB server-এর দিকে জমা ডেটা আগে থেকেই encrypt করে (লেসন ১৫.৫)। কিন্তু কিছু field, যেমন NID নম্বর, card নম্বর বা চিকিৎসার code, এমন মানুষ আর tool থেকেও লুকাতে হয় যারা table পড়তে পারে। তাই app লেখার আগেই AWS Database Encryption SDK (আগের নাম DynamoDB Encryption Client) দিয়ে ওই attribute-গুলো client-side encrypt করে। Global table ciphertext replicate করে। এবার অন্য Region-এর app-কে decrypt করতে হবে:

• Single-Region key হলে Mumbai-র app-কে প্রতিটা read-এ Singapore-এর KMS ডাকতে হয়: বাড়তি latency, Region পেরোনো traffic, আর Singapore বন্ধ থাকলে decrypt একেবারেই হয় না।
• প্রতিটা table Region-এ replicate করা multi-Region key হলে প্রতিটা app decrypt করে নিজের Region-এর replica key দিয়ে: latency কম, আর অন্য Region পড়ে গেলেও কাজ চলে।

#Aurora Global Database

একই যুক্তি খাটে Aurora Global Database-এ (লেসন ৭.৩)। সংবেদনশীল column database-এ পৌঁছানোর আগেই AWS Encryption SDK দিয়ে encrypt করলে, secondary Region-এর application-গুলোর নিজের কাছে key লাগবে: একটা multi-Region key। Client-side column encryption-এর বাড়তি লাভ: database administrator-রাও শুধু ciphertext দেখেন।

#Encrypt করা object-এর S3 replication

Replication (লেসন ১০.৪) encrypt করা object key-এর ধরন দেখে আলাদাভাবে সামলায়:

SSE-KMS object replicate করতে:

1. Replication rule-এ KMS key দিয়ে encrypt করা object replicate করার option চালু করো।
2. Destination Region-এ replica encrypt করার KMS key-এর নাম দাও (source key ওখানে চলে না), আর দেখো সেই key-এর key policy replication role-কে অনুমতি দেয় কি না।
3. Replication IAM role-কে source key-এ kms:Decrypt আর destination key-এ kms:Encrypt দাও।
4. KMS-এর চাপ মাথায় রাখো: প্রতিটা object মানে source Region-এ একটা decrypt আর destination Region-এ একটা encrypt। বেশি হারে KMS throttle করতে পারে; S3 Bucket Key চালু করো, আর দরকার হলে Service Quotas-এ বাড়ানোর আবেদন করো।

Source আর destination-এ multi-Region key ব্যবহার করা যায়, কিন্তু S3 এখনো সেগুলোকে আলাদা key ধরে: object তবুও decrypt হয়ে re-encrypt হয়।

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

• S3-এ পড়ার অনুমতি আছে, তবু object-এ AccessDenied: caller-এর object-এর key-তে kms:Decrypt নেই (key policy বা IAM-এ)। Multipart upload-এও kms:Decrypt লাগে।
• Key policy account-কে অনুমতি দিলেও অন্য account-এর call আটকে যায়: ওই account-এর role-এর key-এর পুরো ARN-এ IAM permission নেই, বা সে alias ব্যবহার করেছে।
• Snapshot বা AMI share হচ্ছে না: সেটা aws/ebs বা aws/rds দিয়ে encrypt করা। আগে customer managed key দিয়ে কপি করো।
• অন্য Region-এ snapshot কপি ব্যর্থ: দেওয়া key source Region-এর, অথবা caller-এর source key-এ kms:Decrypt বা destination key-এ kms:Encrypt/kms:CreateGrant নেই।
• Shared AMI থেকে EC2 launch ব্যর্থ, বা instance সাথে সাথে বন্ধ: target role-এর AMI-এর key-তে kms:CreateGrant বা kms:Decrypt নেই।
• নতুন SSE-KMS object replicate হয় না: opt-in বন্ধ, বা role-এর KMS permission নেই।
• একটা key-এর নিচের সবকিছু হঠাৎ পড়া যাচ্ছে না: key disable হয়েছে, বা delete-এর schedule হয়েছে। আবার enable করো, বা অপেক্ষার সময়ের মধ্যে delete বাতিল করো।
• ডেটা চিরতরে হারানো: অপেক্ষার সময় পেরিয়ে key delete হয়ে গেছে, বা কোনো কপি না রেখে imported key material মুছে ফেলা হয়েছে।
• ভিড়ের সময় throttling error: ভাগ করা KMS request quota শেষ। Bucket Key, data key caching, quota বাড়ানো।
• দ্বিতীয় Region-এর app client-side encrypt করা ডেটা decrypt করতে পারে না: ডেটা single-Region key দিয়ে encrypt। Multi-Region key ব্যবহার করো।
• নতুন key বানিয়ে “rotate” করার পর পুরোনো ডেটা decrypt হয় না: পুরোনো key delete করা হয়েছে। হাতে rotation করলে পুরোনো key enable রেখে দাও।

#System design-এ KMS

• প্রতিটা ডেটা-এলাকা আর environment-এর জন্য একটা করে customer managed key (যেমন prod-patient-records, prod-payments, dev-shared), সবকিছুর জন্য একটা key না: সরু key policy ঠিক করে কে কী পড়বে, আর বিপদে একটা key disable করলে পুরো কোম্পানি থেমে যায় না।
• কাজের ভাগাভাগি: key administrator (security team) আর key user (application) আলাদা; application পায় শুধু যে key-গুলো দরকার সেগুলোতে kms:Decrypt আর kms:GenerateDataKey।
• Multi-account setup: একটা কেন্দ্রীয় security account shared key-গুলোর মালিক, আর key policy দিয়ে workload account-গুলোকে access দেয়; backup আর DR account পায় নিজেদের key দিয়ে re-encrypt করা কপি, তাই একটা account ফাঁস হলেও backup ফাঁস হয় না।
• Region পেরিয়ে DR: destination Region-এর key দিয়ে snapshot কপি; multi-Region key শুধু সেখানে, যেখানে client-side encrypt করা ডেটা কয়েকটা Region-এ পড়তে হয়।
• খরচ আর scale: S3 Bucket Key চালু রাখো, SDK যেখানে দেয় সেখানে data key cache করো, আর যে ডেটায় key-এর নিয়ন্ত্রণ লাগে না সেখানে বিনা পয়সার AWS owned key রাখো।
• Audit: সব Region-এ CloudTrail, DisableKey আর ScheduleKeyDeletion-এর ওপর alarm, আর customer managed key-এ rotation চালু আছে কি না দেখতে AWS Config rule (লেসন ১৯.৭)।

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

এই command-গুলো AWS CLI v2-এর। Customer managed key-এর খরচ মাসে ১ USD, তাই শেষে test key-গুলোর delete schedule করে দিয়ো।

# 1. Create a symmetric customer managed key and an alias
aws kms create-key --description "Hospital reports key" --region ap-southeast-1
# { "KeyMetadata": { "KeyId": "1234abcd-12ab-34cd-56ef-1234567890ab",
#   "KeySpec": "SYMMETRIC_DEFAULT", "KeyUsage": "ENCRYPT_DECRYPT", "Origin": "AWS_KMS",
#   "KeyManager": "CUSTOMER", "KeyState": "Enabled", "MultiRegion": false } }
aws kms create-alias --alias-name alias/reports-key --target-key-id 1234abcd-12ab-34cd-56ef-1234567890ab

# 2. Encrypt and decrypt a small secret (at most 4 KB)
aws kms encrypt --key-id alias/reports-key --plaintext fileb://lab-token.txt \
  --query CiphertextBlob --output text | base64 --decode > lab-token.enc
aws kms decrypt --ciphertext-blob fileb://lab-token.enc --query Plaintext --output text | base64 --decode

# 3. Envelope encryption: a data key for a big file
aws kms generate-data-key --key-id alias/reports-key --key-spec AES_256
# { "CiphertextBlob": "AQIDAHh...", "Plaintext": "kJ8x...", "KeyId": "arn:aws:kms:ap-southeast-1:111122223333:key/1234abcd-..." }

# 4. Rotation: every 180 days, plus one rotation now
aws kms enable-key-rotation --key-id 1234abcd-12ab-34cd-56ef-1234567890ab --rotation-period-in-days 180
aws kms rotate-key-on-demand --key-id 1234abcd-12ab-34cd-56ef-1234567890ab
aws kms get-key-rotation-status --key-id 1234abcd-12ab-34cd-56ef-1234567890ab
# { "KeyRotationEnabled": true, "RotationPeriodInDays": 180, "NextRotationDate": "2027-04-30T..." }

# 5. Open the key to another account (edit key-policy.json first) and give an app a grant
aws kms put-key-policy --key-id 1234abcd-12ab-34cd-56ef-1234567890ab --policy-name default --policy file://key-policy.json
aws kms create-grant --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
  --grantee-principal arn:aws:iam::111122223333:role/report-app --operations Decrypt GenerateDataKey

# 6. Copy an encrypted EBS snapshot to Mumbai with a Mumbai key
aws ec2 copy-snapshot --region ap-south-1 --source-region ap-southeast-1 \
  --source-snapshot-id snap-0123456789abcdef0 --encrypted \
  --kms-key-id arn:aws:kms:ap-south-1:111122223333:key/0987dcba-09fe-87dc-65ba-ab0987654321

# 7. Share a snapshot and an AMI with the client account
aws ec2 modify-snapshot-attribute --snapshot-id snap-0123456789abcdef0 \
  --attribute createVolumePermission --operation-type add --user-ids 444455556666
aws ec2 modify-image-attribute --image-id ami-0abcdef1234567890 \
  --launch-permission "Add=[{UserId=444455556666}]"

# 8. A multi-Region key and its replica in Mumbai
aws kms create-key --multi-region --description "Wallet NID key" --region ap-southeast-1
# "KeyId": "mrk-1234abcd12ab34cd56ef1234567890ab", "MultiRegion": true
aws kms replicate-key --key-id mrk-1234abcd12ab34cd56ef1234567890ab --replica-region ap-south-1

# 9. Clean up: schedule deletion with the shortest wait (and cancel if it is still needed)
aws kms schedule-key-deletion --key-id 1234abcd-12ab-34cd-56ef-1234567890ab --pending-window-in-days 7
# { "KeyState": "PendingDeletion", "DeletionDate": "2026-11-08T...", "PendingWindowInDays": 7 }
aws kms cancel-key-deletion --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

তারপর CloudTrail-এর event history খোলো, event source kms.amazonaws.com দিয়ে filter করো, আর নিজের role-কে caller হিসেবে রেখে তোমার Encrypt, Decrypt, GenerateDataKey আর RotateKey event-গুলো খুঁজে বের করো।

#সারসংক্ষেপ

মূল কথাগুলো

• KMS তোমার হয়ে key বানায়, রাখে আর ব্যবহার করে; key কখনো খোলা অবস্থায় বের হয় না; প্রতিটা ব্যবহারের অনুমতি দেয় key policy + IAM, আর log হয় CloudTrail-এ। পরীক্ষার শব্দ: “auditable”, “centralized key management”। CMK হলো KMS key-এর পুরোনো নাম।
• Encrypt নেয় সর্বোচ্চ 4 KB; বড় ডেটার জন্য data key (envelope encryption)। KMS দিয়ে encrypt করা ডেটা পড়তে resource-এ আর key-তে, দুই জায়গাতেই permission লাগে।
• Symmetric (AES-256): প্রতিটা AWS service যা ব্যবহার করে। Asymmetric (RSA, ECC): encrypt/decrypt বা sign/verify, AWS-এর বাইরের KMS ডাকতে না পারা ব্যবহারকারীর জন্য public key download করা যায়, digital signature। Message authentication code-এর জন্য HMAC key।
• AWS owned (বিনা পয়সায়, অদৃশ্য: SSE-S3, SSE-SQS, DynamoDB default) → AWS managed (aws/s3, aws/ebs, aws/rds: মাসিক fee নেই, request-এর টাকা আছে, প্রতি বছর rotate, policy বদলানো যায় না, share করা যায় না) → customer managed (মাসে ১ USD + request, policy তোমার, ইচ্ছামতো rotation ৯০–২,৫৬০ দিন, default ৩৬৫, on-demand সর্বোচ্চ ২৫ বার, share আর delete করা যায়)। Imported material: automatic rotation নেই, alias দিয়ে হাতে rotation।
• Delete-এর আগে ৭–৩০ দিন অপেক্ষা (default ৩০); disable হলো ফেরানো যায় এমন বিপদের বোতাম। Alias key-এর নাম দেয়, grant service-কে অস্থায়ী ব্যবহারের অনুমতি দেয়।
• Default key policy account-কে বিশ্বাস করে, তাই সিদ্ধান্ত IAM-এর। অন্য account = key policy আর সেই account-এর IAM policy।
• Key Region-এর ভেতরে থাকে: অন্য Region-এ snapshot কপি destination key দিয়ে re-encrypt হয়। অন্য account-এর সাথে snapshot বা AMI share করতে লাগে customer managed key, key policy-তে access, share বা launch permission, target-এ IAM অনুমতি, আর ভালো হয় target-এ re-encrypt করা কপি।
• Multi-Region key: বেছে নেওয়া Region-গুলোতে একই key ID আর material, global না, প্রতিটা আলাদাভাবে সামলানো; client-side encryption সহ DynamoDB global table / Aurora Global Database-এর জন্য।
• S3 replication: SSE-S3 আর SSE-C default-এ replicate হয়; SSE-KMS-এ লাগে opt-in, destination key, আর role-এ kms:Decrypt + kms:Encrypt; KMS quota খেয়াল রাখো, Bucket Key ব্যবহার করো।

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