S3 Encryption

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

• জমা থাকা অবস্থার encryption (at rest) আর পথে চলার সময়ের encryption (in transit) আলাদা করতে, আর কোনটা কোন বিপদ থেকে বাঁচায় সেটা বলতে।
• S3 object encrypt করার পাঁচটা উপায় (SSE-S3, SSE-KMS, DSSE-KMS, SSE-C আর client-side encryption) বোঝাতে: কে encrypt করে, key কোথায় থাকে, কোন header দিয়ে চাইতে হয়, আর খরচ কত।
• প্রতিটা upload আর download-এ S3 কীভাবে KMS ব্যবহার করে, পড়তে হলে কেন bucket-এর পাশাপাশি key-তেও permission লাগে, আর অন্য account-কে দিতে হলে কেন customer managed key লাগে, সেটা ব্যাখ্যা করতে।
• SSE-KMS-এর traffic কখন KMS request quota ছুঁয়ে ফেলে সেটা হিসাব করতে, আর S3 Bucket Key বা quota বাড়িয়ে সমস্যাটা মেটাতে।
• aws:SecureTransport দিয়ে HTTPS বাধ্য করতে, bucket policy দিয়ে নির্দিষ্ট encryption বাধ্য করতে, আর কেন default encryption-এর আগেই bucket policy যাচাই হয় সেটা বোঝাতে।
• পরীক্ষার প্রশ্ন যেভাবে লেখা থাকে, সেভাবে পড়ে ঠিক option বেছে নিতে।

#তালাবন্ধ data আবার encrypt কেন?

#Data দুই জায়গা দিয়ে ফাঁস হতে পারে

লেসন ১০.২-এ দেখেছ, bucket policy আর IAM ঠিক করে S3-এর কাছে একটা object কে চাইতে পারবে। Encryption অন্য একটা প্রশ্নের উত্তর দেয়: না চেয়েই কেউ যদি bytes-গুলো হাতে পেয়ে যায়, সে কী পড়তে পারবে? Bytes ফাঁস হতে পারে দুই জায়গায়, তাই S3 দুই অবস্থাতেই এদের পাহারা দেয়:

• In transit (in flight-ও বলে): request যখন তোমার client আর S3-এর মাঝখানের পথে। পথের কেউ, ধরো হোটেলের Wi-Fi বা দখল হয়ে যাওয়া কোনো router, request পড়তে বা বদলে দিতে পারত। এর পাহারা TLS, মানে HTTPS।
• At rest: object যখন S3-এর disk-এ বসে আছে। বদলে ফেলা কোনো disk ঠিকমতো মোছা না হলে, কোনো backup কপি, বা এমন কোনো bug যা কাঁচা storage দেখিয়ে দেয়, তাহলে খোলা data বেরিয়ে পড়ত। এর পাহারা server-side encryption (disk-এ লেখার আগে S3 encrypt করে) বা client-side encryption (পাঠানোর আগে তুমি নিজে encrypt করো)।

Encryption কিন্তু permission-এর বদলি না। SSE-S3 দিয়ে encrypt করা object-ও bucket policy যাকে ঢুকতে দেয়, তার হাতে decrypt হয়েই পৌঁছায়। শক্তিশালী option-গুলো (SSE-KMS, আর যেগুলোতে key AWS-এর বাইরে থাকে) একটা দ্বিতীয় দরজা বসায়: key নিজেই।

#Object encrypt করার পাঁচ উপায়

S3 চার ধরনের server-side encryption (SSE) দেয়, যেখানে encrypt আর decrypt দুটোই S3 করে; আর client-side encryption তো তুমি সবসময় নিজেই করতে পারো। পরীক্ষায় দেখা হয় কোন পরিস্থিতিতে কোনটা মানায়, সেটা তুমি জানো কিনা।

সবগুলোই AES-256 ব্যবহার করে। তফাত হলো key কার কাছে, কে সেটা ব্যবহার করতে পারে, আর কে দেখতে পায় যে ব্যবহার হয়েছে।

#SSE-S3: যে তালা সবসময় লাগানো

SSE-S3-এ (Amazon S3-এর সামলানো key দিয়ে server-side encryption) সব কাজ S3 নিজেই করে:

• প্রতিটা object-এর জন্য আলাদা একটা data key বানায়, disk-এ লেখার আগে AES-256 দিয়ে object encrypt করে, আর প্রতিটা data key রক্ষা করে এমন এক root key দিয়ে যেটা S3-এর নিজের, S3-ই নিয়মিত বদলায়। এই key-গুলোর কোনোটাই তুমি দেখো না, সামলাও না, টাকাও দাও না।
• নিজে থেকে চাইতে হলে request-এ header পাঠাও x-amz-server-side-encryption: AES256।
• সব bucket-এ এটা চালু। ৫ জানুয়ারি ২০২৩ থেকে S3 সব bucket-এর প্রতিটা নতুন upload-এ encryption-এর ন্যূনতম স্তর হিসেবে SSE-S3 লাগায়, কোনো খরচ ছাড়া, performance-এ কোনো প্রভাব ছাড়া। যে bucket-এ আগে default encryption ছিল না, সেগুলো SSE-S3-এ চলে গেছে; যেগুলোতে আগে থেকেই SSE-KMS ছিল, সেগুলো তা-ই রেখেছে।
• KMS call নেই: তাই KMS-এর খরচ নেই, KMS quota নেই, CloudTrail-এ key-এর কোনো event-ও নেই।

SSE-S3 যা দেয় না: key-এর ওপর নিয়ন্ত্রণ, key-এর জন্য আলাদা permission, বা key কে কখন ব্যবহার করল তার হিসাব। যার s3:GetObject আছে, সে খোলা object-ই পড়ে। একটা news site-এর public ছবি বা পণ্যের catalogue-এর জন্য এটাই ঠিক। কিন্তু hospital-এর scan-এর বেলায় নিয়ন্ত্রক সংস্থার প্রশ্নের (“key কে ব্যবহার করতে পারে? কে ব্যবহার করেছে দেখাও”) কোনো উত্তর এখানে নেই।

#SSE-KMS: key তোমার, সাথে audit trail

#প্রতিটা request-এ S3 কীভাবে KMS ব্যবহার করে

SSE-KMS-এ যে key তোমার data রক্ষা করে, সেটা থাকে AWS KMS-এ (Key Management Service, chapter ২১-এ খুঁটিয়ে পড়বে)। KMS key কখনো KMS-এর hardware security module (HSM) ছেড়ে বের হয় না; S3 ব্যবহার করে সেই envelope encryption, যেটা EBS-এর সাথে দেখেছিলে লেসন ৫.২-এ:

1. Upload। Request-এ থাকে x-amz-server-side-encryption: aws:kms, চাইলে সাথে x-amz-server-side-encryption-aws-kms-key-id দিয়ে কোন key সেটা বলা (অথবা bucket-এর default encryption-এ নাম বসানো থাকে)। তোমার হয়ে S3 KMS-এর GenerateDataKey ডাকে।
2. KMS ফেরত দেয় একটা খোলা data key, আর তোমার KMS key দিয়ে encrypt করা সেই একই data key।
3. S3 খোলা data key দিয়ে object encrypt করে, encrypt করা data key-টা object-এর পাশে রেখে দেয়, আর খোলা key memory থেকে মুছে ফেলে।
4. Download। S3 encrypt করা data key-টা Decrypt call-এ KMS-এ পাঠায়, খোলা data key ফেরত পায়, object decrypt করে দিয়ে দেয়।
5. প্রতিটা GenerateDataKey আর Decrypt call CloudTrail-এ (লেসন ১৯.৬) লেখা থাকে: কে ডাকল, কোন key, আর encryption context, যেটা default-এ object-এর ARN। এটাই audit trail: “গত মঙ্গলবার scan-0412 কে decrypt করেছিল?” প্রশ্নের উত্তর তুমি দিতে পারো।

দুটো নিয়মে মানুষ প্রায়ই হোঁচট খায়: SSE-KMS object-এর GET বা HEAD-এ encryption header পাঠানো যাবে না (পাঠালে 400 Bad Request), আর KMS দিয়ে encrypt করা object-এর প্রতিটা request HTTPS আর Signature Version 4 দিয়ে করতে হবে।

#AWS managed key নাকি customer managed key

দুটোতেই প্রতিটা KMS request-এর খরচ আছে (বেশিরভাগ Region-এ প্রতি ১০,০০০ request-এ মোটামুটি $0.03)। Key হতে হবে symmetric KMS key, আর থাকতে হবে bucket-এর একই Region-এ।

#দুটো তালা: bucket-এ একটা, key-তে একটা

SSE-KMS-এ একটা object পড়তে দুটো permission লাগে:

• object-এ s3:GetObject, IAM বা bucket policy থেকে (লেসন ১০.২), আর
• KMS key-তে kms:Decrypt, key policy আর/অথবা caller-এর IAM policy থেকে।

লিখতে লাগে s3:PutObject আর kms:GenerateDataKey। আর multipart upload-এ (লেসন ১০.১২) লাগে kms:GenerateDataKey আর kms:Decrypt দুটোই, কারণ প্রতিটা part-এর জন্য S3 data key আবার খোলে; “একবারের PUT চলে, বড় upload ব্যর্থ” হলো kms:Decrypt না থাকার চেনা লক্ষণ।

Hospital ঠিক এই দ্বিতীয় তালাটাই চাইছিল। Billing team invoice-এর জন্য s3:GetObject রাখে, কিন্তু scans-key-এর key policy-তে আছে শুধু radiology আর ডাক্তারদের role, তাই প্রতিটা scan-এ billing role পায় AccessDenied, আর চেষ্টাটাও log হয়ে থাকে। কোনো বিপদের সময় security team key disable করে দিলেই সব scan একসাথে অপাঠ্য হয়ে যায়, একটা bucket policy-তেও হাত না দিয়ে।

#অন্য account-কে দিতে হলে customer managed key

AWS managed key দিয়ে encrypt করা object অন্য account-এর সাথে ভাগ করা যায় না: এর key policy শুধু নিজের account-কে বিশ্বাস করে, আর সেটা বদলানোও যায় না। কোনো partner account-কে object পড়তে বা upload করতে দিতে হলে customer managed key নাও, যার key policy সেই account-কে KMS-এর কাজগুলোর অনুমতি দেয়, সাথে partner account-এর ভেতরে IAM permission।

Upload-এ আরেকটা আরও বাজে ফাঁদ আছে। অন্য account-এর কোনো role যদি aws:kms দিয়ে, key ID ছাড়া, upload করে, আর bucket-এর default-এও কোনো KMS key-এর নাম না থাকে, তাহলে S3 নেয় upload করা account-এর AWS managed key। Upload সফল হয়, কিন্তু bucket owner-এর account-এর কেউ ওই object কোনোদিন decrypt করতে পারবে না। Cross-account write-এর জন্য AWS-এর পরামর্শ: customer managed key-এর পুরো key ARN দাও, alias না (alias খোঁজা হয় requester-এর account-এ)।

#যখন KMS-ই আটকে দেয়

#KMS request quota

প্রতিটা SSE-KMS upload মানে একটা GenerateDataKey call, প্রতিটা download মানে একটা Decrypt call। KMS ঠিক করে দেয় একটা account একটা Region-এ সেকেন্ডে কতগুলো cryptographic operation করতে পারবে, আর সবাই একটাই quota ভাগ করে নেয়: S3-এর call, EBS, RDS, Lambda, Secrets Manager, তোমার নিজের code। Symmetric key-এর জন্য এখনকার default:

Quota-র ওপরে KMS বাড়তি call-গুলো throttle করে, আর S3 সেই ব্যর্থতা তোমার client-কে একটা throttling error হিসেবে ফেরত দেয়, যেটা SDK backoff দিয়ে আবার চেষ্টা করে। Quota-টা account আর Region-প্রতি, আর Service Quotas console থেকে বাড়ানো যায়।

হাতে-কলমে হিসাব। ১০,০০০ quota-র এক Region-এ একটা news site নির্বাচনের রাতে সেকেন্ডে ১১,০০০ ছবি download আর ১,০০০ upload সামলাচ্ছে, সবই SSE-KMS: ১১,০০০ Decrypt + ১,০০০ GenerateDataKey = সেকেন্ডে ১২,০০০ KMS call, quota-র চেয়ে ২,০০০ বেশি। S3 নিজে এই ভার নিতে পারত (তার সীমা প্রতি prefix-এ সেকেন্ডে ৩,৫০০ write আর ৫,৫০০ read, লেসন ১০.৬), কিন্তু KMS পারে না।

#S3 Bucket Key

ঠিক এই সমস্যার জন্যই AWS বানিয়েছে S3 Bucket Key:

1. S3 KMS-এর কাছে চায় অল্প সময়ের একটা bucket-level key (encryption context: bucket-এর ARN)।
2. একটা নির্দিষ্ট সময় ধরে S3 ওই key দিয়ে S3-এর ভেতরেই প্রতিটা নতুন object-এর আলাদা data key বানায়। তখন বেশিরভাগ upload আর download-এ KMS call-ই লাগে না।
3. তবু প্রতিটা requester-এর জন্য (আলাদা role বা account) S3 অন্তত একবার bucket key আনে, তাই প্রত্যেক requester-এর key ব্যবহার log হয়েই থাকে।

ফল: KMS request ৯৯% পর্যন্ত কম, মানে KMS-এর খরচ অনেক কম, quota-র ওপর চাপও অনেক কম। Bucket-এ চালু করো (default encryption → Bucket Key), বা প্রতি request-এ x-amz-server-side-encryption-bucket-key-enabled: true দিয়ে; application-এ কিছু বদলাতে হয় না। যা বদলায়:

• CloudTrail-এ প্রতিটা object-এর ARN-এর বদলে দেখা যায় bucket-এর ARN, আর KMS event অনেক কম। যে auditor object ধরে খুঁজত, তাকে অন্যভাবে খুঁজতে হবে।
• যে key policy বা IAM condition encryption context হিসেবে object-এর ARN ব্যবহার করত, তাকে bucket-এর ARN-এ যেতে হবে।
• আগে থেকে থাকা object আগের setting-এই থাকে, যতক্ষণ না তুমি সেগুলো copy করো (CopyObject, বা লাখ লাখ object-এর জন্য Batch Operations, লেসন ১০.৭)।
• DSSE-KMS-এ চলে না।

খরচের হিসাব। একটা bucket মাসে ২০ কোটি SSE-KMS request সামলায়। Bucket Key ছাড়া: ২০,০০,০০,০০০ ÷ ১০,০০০ × $0.03 = KMS request-এ $600। Bucket Key থাকলে আর requester কম হলে, AWS-এর “৯৯% পর্যন্ত” হিসাবে খরচ নামে প্রায় $6-এ।

Notes আর slide যে সমাধান দেয় সেটাও আছে: Service Quotas দিয়ে (Service Quotas যেখানে নেই সেখানে AWS Support দিয়ে) quota বাড়ানোর আবেদন। Traffic খুব বেশি হলে দুটোই করো; আগে Bucket Key চেষ্টা করো, কারণ এতে বিলও কমে।

#DSSE-KMS: কড়া নিয়মের জন্য দুই স্তর

DSSE-KMS (KMS key দিয়ে dual-layer server-side encryption) প্রতিটা object দুবার encrypt করে, AES-256-এর দুটো স্বাধীন স্তরে:

1. প্রথম স্তর: AWS KMS থেকে আনা একটা আলাদা data key দিয়ে, ঠিক SSE-KMS-এর মতো।
2. দ্বিতীয় স্তর: আগে থেকে encrypt হওয়া data আবার encrypt হয় S3-এর সামলানো আলাদা একটা AES-256 key দিয়ে।

কোনোদিন এক স্তর ভেঙে গেলেও অন্যটা data রক্ষা করবে। চাইতে হয় x-amz-server-side-encryption: aws:kms:dsse দিয়ে। Key-এর নিয়ন্ত্রণ, permission আর CloudTrail-এর audit trail সব SSE-KMS-এর মতোই।

দাম: বেশি processing আর একটু বেশি latency, SSE-KMS-এর চেয়ে বেশি খরচ, আর S3 Bucket Key চলে না, তাই প্রতিটা request KMS ডাকে আর quota-তে গোনা হয়। এটা নাও শুধু তখন, যখন কোনো compliance standard স্পষ্ট করে একাধিক স্তরের encryption চায়, যেমন গোপন data রক্ষার জন্য মার্কিন সরকারের নিয়ম, যেখানে দুই স্তরের encryption লাগে (notes-এ US Department of Defense-এর কথা আছে)।

#SSE-C: প্রতিটা request-এ নিজের key নিয়ে এসো

#SSE-C কীভাবে কাজ করে

SSE-C-তে (customer-এর দেওয়া key দিয়ে server-side encryption) key তুমি রাখো AWS-এর বাইরে, কিন্তু encryption-এর কাজটা S3-ই করে:

• Object-এর ওপর প্রতিটা request (PUT, GET, HEAD, copy) তিনটা header-এ key বয়ে আনে: x-amz-server-side-encryption-customer-algorithm: AES256, x-amz-server-side-encryption-customer-key (256-bit key, base64-এ), আর x-amz-server-side-encryption-customer-key-MD5 (key-এর একটা checksum, যাতে S3 নষ্ট key ধরতে পারে)।
• S3 ওই key দিয়ে encrypt বা decrypt করে, তারপর key ফেলে দেয়। রেখে দেয় শুধু key-এর একটা এলোমেলো salt মেশানো HMAC, যাতে পরে ভুল key এলে ফিরিয়ে দিতে পারে; এটা থেকে key আবার বানানো যায় না।
• HTTPS বাধ্যতামূলক। খোলা HTTP-তে আসা যেকোনো SSE-C request S3 ফিরিয়ে দেয়। ভুল করে কখনো HTTP দিয়ে key পাঠিয়ে ফেললে, AWS বলে সেটাকে ফাঁস হওয়া ধরে নিয়ে বদলে ফেলতে।
• কোন key দিয়ে কোন object encrypt হলো, সেই হিসাব তোমার (versioning চালু থাকলে কোন version, সেটাও)। Key হারালে object-ও শেষ; AWS কিছু করতে পারে না, কারণ key তার কাছে কখনো ছিলই না।
• S3 console দিয়ে SSE-C object upload করা বা বদলানো যায় না। বাড়তি কোনো খরচ নেই।
• যেসব AWS service-কে তোমার data পড়তে হয় (analytics, replication-এর tool, Lambda), তারা নিজে থেকে SSE-C object decrypt করতে পারে না; এজন্যই AWS এখন বেশিরভাগ কাজ SSE-KMS-এর দিকে ঠেলে।

Notes-এর exam trick ঠিকই আছে: “company নিজের key নিজে সামলাতে চায়, কিন্তু encryption-টা AWS করুক” → SSE-C।

#এপ্রিল ২০২৬ থেকে নতুন bucket-এ default-এ বন্ধ

৬ এপ্রিল ২০২৬ থেকে AWS একটা নতুন default চালু করেছে: সব নতুন general purpose bucket-এ SSE-C বন্ধ (Bahrain আর United Arab Emirates-এর দুটো Middle East Region ছাড়া সব Region-এ), আর যেসব account-এ কোনো SSE-C object ছিল না, তাদের পুরনো bucket-গুলোতেও। বন্ধ থাকা অবস্থায় SSE-C চাওয়া যেকোনো PutObject, CopyObject, POST, multipart upload বা replication request ব্যর্থ হয় 403 AccessDenied দিয়ে; আগের SSE-C object অবশ্য পড়া যায়। SSE-C ব্যবহার করতে হলে bucket owner-কে PutBucketEncryption দিয়ে default encryption configuration-এ BlockedEncryptionTypes-কে NONE করে block তুলে দিতে হবে। একইভাবে পুরনো bucket-এও SSE-C বন্ধ করা যায়।

#Client-side encryption: S3 কখনো খোলা data দেখে না

Client-side encryption-এ data তোমার system ছাড়ার আগেই তুমি encrypt করো, আর download করার পরে decrypt করো। S3 জমা রাখে ciphertext, ভেতরে কী আছে তার কোনো ধারণাই তার নেই।

• একটা client library ব্যবহার করো: Amazon S3 Encryption Client (যেটা S3 SDK-কে মুড়ে রাখে) বা AWS Encryption SDK। Key আসতে পারে তোমার নিজের key store থেকে, বা KMS থেকে: তখন library KMS থেকে data key আনে, কিন্তু encrypt করে তোমার নিজের process-এর ভেতরেই।
• পুরো encryption চক্র তোমার: algorithm, key রাখা, rotation, আর যে application data পড়বে তার প্রত্যেকটায় decryption।
• ওপর দিয়ে S3 তবুও তার default SSE-S3 লাগায়, ফলে object দুবার encrypt হয়, কিন্তু ভেতরের স্তর খুলতে পারো শুধু তুমি।
• AWS service ভেতরে উঁকি দিতে পারে না: Athena query নেই, ব্যক্তিগত data খুঁজতে Macie scan নেই, Lambda-তে ছবি ছোট করা নেই, যদি না সেই code-এর হাতে key থাকে।

“Key তোমার হাতে” এমন দুটো option, SSE-C আর client-side encryption, স্বাভাবিক আর ব্যর্থতার দুই অবস্থাতেই মিলিয়ে দেখো:

#পথে চলার সময়ের encryption

#HTTP আর HTTPS endpoint

S3-এর API endpoint HTTP (encrypt করা না) আর HTTPS (TLS দিয়ে পথে encrypt করা) দুটোতেই সাড়া দেয়। HTTPS-ই পরামর্শ দেওয়া হয়, এখনকার AWS SDK আর AWS CLI default-এ এটাই ব্যবহার করে, আর SSE-C ও KMS-encrypted object-এর request-এ এটা বাধ্যতামূলক। ২৭ ফেব্রুয়ারি ২০২৪ থেকে S3 সহ AWS-এর প্রতিটা API endpoint TLS 1.2 বা নতুন চায়, তাই যে client শুধু TLS 1.0 বা 1.1 জানে, সে connect-ই করতে পারে না।

(লেসন ১০.৩-এর static website endpoint আলাদা: সে শুধু HTTP বোঝে, HTTPS-এর জন্য সামনে CloudFront বসাতে হয়।)

#aws:SecureTransport দিয়ে HTTPS বাধ্য করা

S3 নিজে থেকে HTTP ফিরিয়ে দেয় না। কোনো bucket-এ HTTPS বাধ্যতামূলক করতে, bucket policy-তে একটা Deny যোগ করো সেই সব request-এর জন্য যেখানে global condition key aws:SecureTransport হলো false (লেসন ২.১-এ এর সাথে পরিচয় হয়েছিল):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::scans-example",
        "arn:aws:s3:::scans-example/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

"true" দিয়ে Allow না দিয়ে Deny কেন? Allow শুধু অনুমতি যোগ করে। যার IAM policy আগে থেকেই S3-এ অনুমতি দেয়, সে HTTP দিয়েও ঢুকে যাবে। Explicit Deny সব Allow-কে হারায় (লেসন ২.২), account-এর নিজের administrator-কেও। Bucket-এর ARN আর /* দুটোই দেওয়া আছে, যাতে bucket-স্তরের আর object-স্তরের দুই ধরনের কাজই ঢাকা পড়ে।

আরও কড়া নিয়মের জন্য, যেমন “শুধু TLS 1.3”, condition key s3:TlsVersion-এর ওপর NumericLessThan 1.3 দিয়ে দ্বিতীয় একটা Deny যোগ করো।

#Default encryption আর bucket policy

#Default encryption

প্রতিটা bucket-এর একটা default encryption configuration থাকে: upload-এ কোনো encryption header না থাকলে S3 যে encryption লাগায়। তুমি না বদলালে এটা SSE-S3; বদলে করতে পারো SSE-KMS (AWS managed key বা customer managed key দিয়ে, চাইলে Bucket Key সহ) বা DSSE-KMS। Header থাকলে upload সেই header যা চায় তা-ই পায়।

Notes-এর exam trick খাটে: “bucket-এর সব নতুন object encrypt হবে, কীভাবে নিশ্চিত করবে?” → default encryption। ২০২৩ থেকে SSE-S3 দিয়ে এটা নিজে থেকেই হয়, তাই এখনকার প্রশ্ন সাধারণত নির্দিষ্ট একটা ধরন চায়, যেমন “সব object আমাদের key দিয়ে SSE-KMS-এ encrypt হতে হবে” → default encryption ওই key সহ SSE-KMS করো, আর অন্য header-এর upload ফিরিয়ে দিতে হলে একটা bucket policy যোগ করো।

Default encryption যা করে না:

• আগে থেকে থাকা object-এ হাত দেয় না। Default SSE-S3 থেকে SSE-KMS করলে পুরনো object যেমন ছিল তেমনই থাকে; জায়গায় বসেই CopyObject দিয়ে copy করে আবার encrypt করো, লাখ লাখ object হলে S3 Batch Operations-এর Copy দিয়ে (লেসন ১০.৭)।
• Header-কে টপকায় না। Default SSE-KMS হলেও কোনো client AES256 পাঠালে সে SSE-S3-ই পায়, যদি না কোনো bucket policy সেটা ফিরিয়ে দেয়।

#Bucket policy দিয়ে একটাই encryption বাধ্য করা

SSE-KMS ছাড়া অন্য কিছুর upload ফিরিয়ে দিতে, encryption header aws:kms ছাড়া অন্য কিছু হলে s3:PutObject deny করো:

{
  "Sid": "DenyNonKmsUploads",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::scans-example/*",
  "Condition": {
    "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
  }
}

একটা নির্দিষ্ট key বাধ্য করতে, key-এর পুরো ARN দিয়ে s3:x-amz-server-side-encryption-aws-kms-key-id-এর ওপর একটা Deny যোগ করো। পুরনো, চেনা রূপটা header না থাকলে upload deny করে ("Null": { "s3:x-amz-server-side-encryption": "true" })।

Bucket policy যাচাই হয় default encryption-এর আগে। ওপরের policy থাকলে, header ছাড়া একটা request-এ s3:x-amz-server-side-encryption-এর কোনো মানই নেই, StringNotEquals সত্য, আর upload deny হয়ে যায়, যদিও bucket-এর default encryption SSE-KMS, আর সেটা ঠিকঠাকই encrypt করে দিত। তাই এমন policy দিলে প্রতিটা client-কে header পাঠাতেই হবে। যদি তোমার চাওয়া শুধু “সব SSE-KMS-এ encrypt হোক”, তাহলে শুধু default encryption-ই যথেষ্ট, আর client-দের জন্যও সহজ।

সব রকম মিশিয়ে চেষ্টা করো: default encryption, Bucket Key, SSE-C block, policy-র দুটো statement, HTTP বা HTTPS, প্রতিটা header, KMS permission না থাকা, আর অন্য account-এর caller।

#ঠিক option বাছা

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

• “S3 দিল, KMS দিল না।” একটা role-এর s3:GetObject আছে, তবু শুধু SSE-KMS object-এ AccessDenied: key policy বা তার IAM policy-তে kms:Decrypt নেই। ছোট upload চলে কিন্তু বড়গুলো ব্যর্থ: multipart-এর জন্য kms:Decrypt নেই।
• Cross-account object যা কেউ পড়তে পারে না। Partner aws:kms দিয়ে, key ID ছাড়া upload করেছে, তাই object-গুলো partner-এর aws/s3 key-এর তালায়। আগে পদ্ধতি ঠিক করো (customer managed key, request-এ বা default-এ পুরো ARN), তারপর partner account থেকে object-গুলো আবার copy করো।
• ভিড়ের সময় KMS throttling, আর quota ভাগের বলে একই সময়ে অন্য service-ও ব্যর্থ। Bucket Key চালু করো, Service Quotas আর CloudWatch-এ quota-র তুলনায় KMS-এর ব্যবহার দেখো, quota বাড়াতে বলো।
• ভুল Region-এর key। us-east-1-এর KMS key দিয়ে eu-west-1-এর bucket-এর object encrypt করা যায় না; bucket-এর Region-এ key বানাও (বা key-এর multi-Region replica)।
• Disable বা মুছে ফেলা key। Key disable করলে যত SSE-KMS object সে রক্ষা করে, সব আবার enable না করা পর্যন্ত অপাঠ্য; মুছে ফেললে data চিরতরে শেষ। ঠিক এই কারণেই KMS মুছে ফেলার আগে ৭ থেকে ৩০ দিন অপেক্ষা করায়।
• SSE-C key হারানো: data চিরতরে হারানো। HTTP দিয়ে SSE-C: ফিরিয়ে দেয়, আর key বদলাতে হয়। নতুন bucket-এ SSE-C: block না তোলা পর্যন্ত 403।
• Header ছাড়া upload deny, “aws:kms লাগবে” policy-র কারণে, যদিও default encryption SSE-KMS: policy আগে যাচাই হয়।
• পড়া যায় না এমন server access log। S3 server access log যে bucket-এ যায় (লেসন ১০.৯), সেটায় SSE-S3 লাগবে; default SSE-KMS হলে log object এমন key-এ encrypt হতে পারে যেটা তুমি ব্যবহারই করতে পারো না।
• Replication-এর চমক। SSE-KMS object replicate হয় তখনই, যখন replication rule-এ সেটা চালু করো আর replication role-কে KMS permission দাও (লেসন ১০.৪)। Unencrypted source object গন্তব্যের default encryption পায়, তাই তাদের ETag আলাদা হয়ে যায়।
• নামে বা metadata-য় ব্যক্তিগত data: SSE সেগুলো encrypt করে না।

#System design-এ encryption

• Default থেকে শুরু করো, কোনো চাহিদা চাইলে তবেই বাড়াও। SSE-S3 বিনা পয়সার আর চোখেই পড়ে না। কারও key নিয়ন্ত্রণ বা audit করার দরকার হলে SSE-KMS-এ যাও; দুই স্তরের নিয়ম থাকলে তবেই DSSE-KMS; key AWS-এর বাইরে রাখতেই হলে তবেই SSE-C বা client-side।
• Key policy দিয়ে দায়িত্ব ভাগ করো। যারা bucket সামলায় আর যারা data পড়তে পারে, তাদের আলাদা permission দাও। SSE-KMS থাকলে একজন storage administrator lifecycle rule আর replication সামলাতে পারে, অথচ একটা scan-ও পড়তে পারে না।
• প্রতিটা data-র এলাকার জন্য একটা key। রোগীর scan-এর জন্য একটা key, invoice-এর জন্য আরেকটা: প্রত্যেকটার নিজস্ব key policy, নিজস্ব CloudTrail-এর গল্প, আর একটাকে না ছুঁয়ে অন্যটা disable করার সুযোগ।
• Request-এর পরিমাণ মাথায় রেখে পরিকল্পনা করো। ভারী traffic-এর SSE-KMS bucket-এ প্রথম দিন থেকেই Bucket Key চালু করো; শুধু S3 না, Region-এর সব KMS ব্যবহারকারীকে মিলিয়ে account-এর KMS quota দেখো।
• HTTPS নিয়ে কোনো আপস নয়: প্রতিটা bucket-এ SecureTransport-এর Deny, আর কোনো standard নতুন TLS version চাইলে s3:TlsVersion।
• Encryption S3-এর বাকি সবকিছুর সাথে চলে। Versioning, replication, lifecycle rule, Object Lock আর access point (লেসন ১০.৪, ১০.৫, ১০.৯) সবই encrypt করা object-এ কাজ করে; SSE-KMS object-এর pre-signed URL Signature Version 4 দিয়ে sign করতে হয় (লেসন ১০.১২)।

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

# 1. Bucket-এর default encryption দেখো (কেউ না বদলালে SSE-S3)
aws s3api get-bucket-encryption --bucket scans-example

# 2. নির্দিষ্ট encryption দিয়ে upload করো, তারপর কী জমা হলো দেখো
aws s3 cp scan-0412.jpg s3://scans-example/scans/0412.jpg --sse AES256
aws s3api head-object --bucket scans-example --key scans/0412.jpg \
  --query '{sse:ServerSideEncryption,key:SSEKMSKeyId,bucketKey:BucketKeyEnabled}'

# 3. একটা customer managed key, তারপর তা দিয়ে SSE-KMS
aws kms create-key --description "Patient scans" --query KeyMetadata.Arn --output text
aws s3 cp scan-0413.jpg s3://scans-example/scans/0413.jpg --sse aws:kms \
  --sse-kms-key-id arn:aws:kms:ap-south-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

# 4. Default encryption = ওই key সহ SSE-KMS, সাথে S3 Bucket Key
aws s3api put-bucket-encryption --bucket scans-example --server-side-encryption-configuration '{
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:ap-south-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
    },
    "BucketKeyEnabled": true
  }]
}'

# 5. একটা object-এ DSSE-KMS
aws s3 cp ledger-2026.csv s3://archive-example/ledger-2026.csv --sse aws:kms:dsse

# 6. SSE-C: আগে এই bucket-এ block তোলো (নতুন bucket-এ বন্ধ থাকে), তারপর local 256-bit key
aws s3api put-bucket-encryption --bucket legal-example --server-side-encryption-configuration '{
  "Rules": [{ "BlockedEncryptionTypes": { "EncryptionType": ["NONE"] } }]
}'
openssl rand -out sse-c.key 32
aws s3 cp contract.pdf s3://legal-example/contract.pdf --sse-c AES256 --sse-c-key fileb://sse-c.key
aws s3 cp s3://legal-example/contract.pdf ./copy.pdf --sse-c AES256 --sse-c-key fileb://sse-c.key

# 7. HTTPS বাধ্য করো: ওপরের DenyInsecureTransport policy tls-only.json নামে রাখো
aws s3api put-bucket-policy --bucket scans-example --policy file://tls-only.json
curl -I http://scans-example.s3.ap-south-1.amazonaws.com/scans/0412.jpg   # 403: খোলা HTTP deny

# 8. পুরনো একটা object নতুন key-এ আবার encrypt করো (নিজের ওপরেই copy)
aws s3 cp s3://scans-example/scans/old-0001.jpg s3://scans-example/scans/old-0001.jpg \
  --sse aws:kms --sse-kms-key-id arn:aws:kms:ap-south-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

# 9. Key কে ব্যবহার করল? CloudTrail-এ KMS event
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=Decrypt \
  --max-results 5 --query 'Events[].{time:EventTime,user:Username}'

# 10. এই Region-এ symmetric cryptographic operation-এর KMS quota
aws service-quotas list-service-quotas --service-code kms \
  --query "Quotas[?contains(QuotaName,'symmetric')].[QuotaName,Value]"

#সারসংক্ষেপ

মূল কথাগুলো

• In transit = TLS/HTTPS; at rest = server-side বা client-side encryption। Encryption permission-এর পরিপূরক, বদলি না।
• SSE-S3: S3-এর নিজের key, AES-256, header AES256, জানুয়ারি ২০২৩ থেকে প্রতিটা নতুন upload-এ default, বিনা পয়সায়, KMS নেই, key-এর audit নেই।
• SSE-KMS: header aws:kms; upload-এ S3 ডাকে GenerateDataKey, download-এ Decrypt; CloudTrail-এ audit trail; পড়তে s3:GetObject-এর পাশাপাশি kms:Decrypt লাগে; multipart-এ দুটো KMS permission-ই লাগে; key একই Region-এ; cross-account-এ লাগে customer managed key (aws/s3 না)।
• KMS quota (Region-প্রতি সেকেন্ডে ১০,০০০ / ২০,০০০ / ১,০০,০০০ cryptographic operation, সব service মিলে ভাগ) ব্যস্ত SSE-KMS bucket-কে throttle করতে পারে। S3 Bucket Key KMS call ৯৯% পর্যন্ত কমায় (তখন CloudTrail-এ bucket-এর ARN; পুরনো object-এর জন্য copy লাগে); অথবা Service Quotas-এ বাড়াতে বলো।
• DSSE-KMS: header aws:kms:dsse, AES-256-এর দুটো স্বাধীন স্তর, একাধিক স্তরের compliance-এর জন্য; খরচ বেশি, Bucket Key নেই।
• SSE-C: প্রতিটা request-এ তিনটা header-এ তোমার key, শুধু HTTPS, S3 রাখে শুধু salt মেশানো HMAC, console-এ চলে না, key হারালে data হারায়; এপ্রিল ২০২৬ থেকে নতুন bucket-এ default-এ বন্ধ (BlockedEncryptionTypes = NONE দিয়ে খোলো)।
• Client-side: upload-এর আগে encrypt (S3 Encryption Client, AWS Encryption SDK); S3 দেখে শুধু ciphertext।
• শুধু HTTPS → aws:SecureTransport false হলে bucket policy-তে Deny; ২০২৪ থেকে AWS-এর সব endpoint-এ TLS 1.2 সর্বনিম্ন; আরও কড়া নিয়মের জন্য s3:TlsVersion।
• Default encryption header ছাড়া upload ঢাকে, আগে থেকে থাকা object কখনো না (Batch Operations দিয়ে আবার encrypt করো)। Default encryption-এর আগে bucket policy যাচাই হয়, তাই “header লাগবে” policy header ছাড়া upload ফিরিয়ে দেয়।

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