চলার পথে, রাখা অবস্থায় আর Client-side Encryption

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

• Encryption আসলে কী (plaintext, ciphertext, algorithm, key), বুঝিয়ে বলতে, আর পরীক্ষার কোন কথাগুলো দেখলে বুঝবে encryption লাগবেই, চিনতে।
• Symmetric আর asymmetric encryption আলাদা করতে, আর কোনটা কী কাজে লাগে বলতে, digital signature সহ।
• TLS দিয়ে চলার পথের encryption ব্যাখ্যা করতে: কী থেকে বাঁচায়, certificate কীভাবে man-in-the-middle আটকায়, AWS-এ TLS কোথায় শেষ হয়, আর পরীক্ষা এখনো কেন “SSL” বলে।
• Server-side encryption at rest আর client-side encryption বুঝিয়ে বলতে: কে encrypt করে, key কোথায় থাকে, plaintext কে কখনো দেখতে পারে, আর প্রতিটার পরীক্ষার keyword।
• Data key দিয়ে envelope encryption ব্যাখ্যা করতে, KMS কেন এভাবে কাজ করে (4 KB-র সীমা, গতি, খরচ), আর KMS key disable হলে কী হয়।
• একটা design-এ তিনটা পদ্ধতি একসাথে বসাতে, আর scenario পড়ে ঠিকটা বাছতে।

#Encryption লাগে কেন?

অধ্যায় ২১-এর বিষয় AWS-এ data আর application সুরক্ষিত রাখা: encryption আর key (এই লেসন, ২১.২-এ KMS, ২১.৫-এ CloudHSM), secret (২১.৩), certificate (২১.৪), আর যেসব service হামলা আটকায় ও ধরে (২১.৬, ২১.৭)। এই অধ্যায়ের প্রায় প্রতিটা প্রশ্ন একই ছাঁচে আসে: keyword খোঁজো (key কার নিয়ন্ত্রণে, ফ্রি না টাকা লাগে, এক Region না অনেক Region, network layer না application layer), তারপর যে একটা service বা option খাপ খায়, সেটা বাছো। প্রথম এই লেসন সেই শব্দভান্ডার দেয়, যার ওপর বাকি সব লেসন দাঁড়িয়ে।

#Plaintext, ciphertext আর key

Encryption একটা algorithm আর একটা key দিয়ে plaintext-কে (যে data সবাই পড়তে পারে) ciphertext-এ (যা দেখতে এলোমেলো byte-এর মতো) বদলে দেয়। Decryption আবার আগের অবস্থায় ফেরায়। Algorithm সবার জানা, বহু পরীক্ষিত (AES, RSA…); গোপন শুধু key। যার কাছে ঠিক key আছে সে data পড়ে; বাকিরা, এমনকি যে প্রতিটা byte কপি করে নিয়েছে, কাজের কিছুই পায় না।

মূল উদ্দেশ্য হলো অননুমোদিত access থেকে data রক্ষা করা: যার পাওয়ার কথা না, অথচ কোনোভাবে byte-গুলো হাতে পেয়ে গেছে, তার থেকে। Permission ঠিক করে কে data চাইতে পারবে; encryption ঠিক করে না চেয়েই কেউ byte পেয়ে গেলে কী পড়তে পারবে। দুটোই লাগে।

#Symmetric আর asymmetric encryption

Algorithm-এর দুটো পরিবার। এদের KMS-রূপ দেখবে লেসন ২১.২-এ; এখানে শুধু ধারণাটা।

বাস্তবে দুটো একসাথে কাজ করে। TLS asymmetric cryptography দিয়ে একটা নতুন symmetric session key ঠিক করে নেয়, তারপর traffic encrypt করে সেই symmetric key দিয়ে। AWS service তোমার জমা data encrypt করে symmetric AES-256 দিয়ে। Asymmetric key আসে তখন, যখন AWS-এর বাইরের কাউকে public key দিয়ে encrypt করতে হয়, বা কিছু একটায় সই করতে হয় (document, software release, token), যাতে অন্যরা যাচাই করতে পারে কে বানিয়েছে আর মাঝপথে কিছু বদলায়নি।

#Data রক্ষার তিন পথ

Data থাকে দুই অবস্থার একটায়, আর জমা অবস্থায় encrypt করার জায়গা দুটো; তাই মিলিয়ে তিনটা পদ্ধতি, যেগুলো নিয়ে পরীক্ষা প্রশ্ন করে:

এগুলো একটার বদলে আরেকটা না: ভালো design সব জায়গায় in flight আর at rest দুটোই রাখে, আর সবচেয়ে সংবেদনশীল data-র জন্য বাড়তি client-side encryption যোগ করে।

#চলার পথে encryption: TLS

#TLS কী করে

In flight (বা in transit) data মানে এক জায়গা থেকে আরেক জায়গায় যাচ্ছে এমন data: গ্রাহকের phone থেকে তোমার load balancer, app server থেকে database, তোমার data centre থেকে S3। পথে সে পার হয় Wi-Fi router, ISP, switch, যেগুলোর কোনোটাই তোমার নিয়ন্ত্রণে না। ওই পথে যে কেউ data পড়তে পারে, বদলেও দিতে পারে। একেই বলে man-in-the-middle (MITM) হামলা।

TLS (Transport Layer Security) connection-টাকে রক্ষা করে:

• গোপনীয়তা: পাঠানোর আগে data encrypt হয়, পাওয়ার পরে decrypt হয়, এমন session key দিয়ে যা শুধু দুই প্রান্তই জানে।
• অখণ্ডতা (integrity): প্রতিটা record-এর সাথে একটা যাচাই থাকে, তাই একটা byte বদলালেও ধরা পড়ে আর connection কেটে যায়।
• Server-এর পরিচয় প্রমাণ: server একটা certificate দেখিয়ে প্রমাণ করে সে কে; certificate-টা এমন এক certificate authority (CA)-র সই করা, যাকে client বিশ্বাস করে। CA আর certificate-এর এই পুরো জালটার নাম public key infrastructure (PKI)। MITM তোমার domain-এর জন্য বৈধ certificate দেখাতে পারে না, কারণ তার কাছে তোমার private key নেই, আর কোনো CA তাকে সেটা সই করে দেবেও না।

HTTPS মানে TLS-এর ভেতরে HTTP, এর বেশি কিছু না। একই TLS database connection, mail, IoT যন্ত্রের MQTT, এমনকি AWS API-কেও মুড়ে রাখে।

#AWS-এ TLS কোথায় শেষ হয়

TLS একটা connection-কে এক প্রান্ত থেকে আরেক প্রান্ত পর্যন্ত রক্ষা করে। AWS-এ সেই প্রান্তটা কোথায় হবে, ঠিক করো তুমি:

• সদর দরজায়। Application Load Balancer বা Network Load Balancer (TLS listener), API Gateway, CloudFront বা App Runner certificate রাখে আর TLS terminate করে। Certificate ফ্রিতে পাও AWS Certificate Manager (ACM) থেকে, সে-ই renew-ও করে: লেসন ২১.৪।
• Instance পর্যন্ত পুরো পথ। নিয়ম যদি হয় “end to end encrypted”, ALB আবার encrypt করে HTTPS target group-এ পাঠায়, অথবা NLB TCP যেমন আছে তেমনই পার করে দেয়, যাতে instance নিজেই TLS terminate করে। Termination, re-encryption আর passthrough আছে লেসন ৬.৪-এ।

AWS-এর ভেতরেও চলার পথে একই ধারণা, service ধরে ধরে। প্রতিটা তুমি আগেই দেখেছ; এখানে পাশাপাশি রাখা হলো:

#Server-side encryption at rest

#Server-side encryption কীভাবে কাজ করে

At rest data মানে storage-এ বসে থাকা data: S3 object, EBS volume, RDS database, DynamoDB table, EFS file system, snapshot, backup। Server-side encryption (SSE)-এ:

1. Service তোমার data পায় (TLS দিয়ে)।
2. Disk-এ লেখার আগে একটা key দিয়ে, সাধারণত একটা data key দিয়ে, সেটা encrypt করে।
3. অনুমতি আছে এমন কেউ data চাইলে service decrypt করে ফেরত পাঠায় (TLS দিয়ে)।

Application আলাদা কিছুই করে না। আগের মতোই লেখে আর পড়ে; তার code-এ কোনো key নেই, কোনো encryption library ডাকতে হয় না। পরীক্ষার “transparent to the application” কথাটার মানে এটাই।

ফাঁকটা আছে slide-এর শেষ লাইনে: key কোথাও না কোথাও সামলাতে হয়, আর server-কে সেই key ব্যবহার করতে পারতে হয়। Server-side encryption বাঁচায় storage ভুল হাতে পড়লে (নষ্ট disk, ফাঁস হওয়া backup, raw storage-এর কপি); কিন্তু request সামলানোর সময় service নিজে plaintext ছোঁয়, আর service যাকে ঢুকতে দেয় সে plaintext-ই পায়।

#Key কার হাতে

AWS-এ server-side encryption-এর পেছনের key হয় তিন রকম KMS key-এর একটা, নয়তো service-এর নিজের key। প্রতিটা নিয়ে বিস্তারিত লেসন ২১.২-এ; আপাতত আসল প্রশ্ন হলো, নিয়ন্ত্রণ আর audit কতটা পাচ্ছ:

• Service-এর নিজের key (যেমন SSE-S3, বা DynamoDB-র default): ফ্রি, কিছু সামলাতে হয় না, কিন্তু key-এর আলাদা কোনো permission নেই, ব্যবহারের কোনো হিসাবও নেই। Data পড়ার অনুমতি যার আছে, সে-ই plaintext পায়।
• KMS key: প্রতিটা ব্যবহার key policy আর IAM দিয়ে যাচাই হয়, আর CloudTrail-এ log হয়। পাঠকের লাগে data-র permission আর key-এর permission, তাই key হয়ে ওঠে দ্বিতীয় দরজা। Customer managed key হলে কে ব্যবহার, rotate, disable বা share করতে পারবে, সেটাও তুমিই ঠিক করো।

S3-এর চারটা server-side option হলো SSE-S3, SSE-KMS, DSSE-KMS আর SSE-C (যেখানে প্রতিটা request-এর সাথে key তুমি পাঠাও); পুরোটা পড়ানো হয়েছে লেসন ১০.৮-এ। EBS আর RDS encryption, আর তাদের “তৈরির সময়ই ঠিক করো” নিয়ম আছে লেসন ৫.২ আর ৭.৪-এ।

#Client-side encryption

#Client-side encryption কীভাবে কাজ করে

Client-side encryption-এ তোমার application data তোমার পরিবেশ ছাড়ার আগেই encrypt করে, আর ফেরত আসার পরে decrypt করে। Storage service ciphertext পায়, ciphertext রাখে, ciphertext ফেরত দেয়। সে কখনো plaintext বা key দেখে না, চাইলেও decrypt করতে পারবে না। Storage-এর ভাষায় এটাই end-to-end encryption (E2EE): key থাকে শুধু দুই প্রান্তে।

• Decrypt করে গ্রহণকারী client (তোমার নিজের app, বা এমন partner যাকে key দেওয়া হয়েছে)।
• যেকোনো storage-এ চলে: S3, DynamoDB, একটা FTP server, এমনকি email attachment।
• নিজে নিজে cryptography বানাতে না হয়, সেজন্য AWS library দেয়: AWS Encryption SDK (যেকোনো data), Amazon S3 Encryption Client, আর DynamoDB item-এর জন্য AWS Database Encryption SDK। সবগুলোই envelope encryption ব্যবহার করে (পরের অংশ)।
• Key আসতে পারে তোমার নিজের key store থেকে, একটা HSM থেকে, বা KMS থেকে। KMS হলেও library encrypt করে তোমার process-এর ভেতরেই: KMS শুধু অনুমতি থাকা caller-কে একটা data key দেয়, আর S3 তখনো শুধু ciphertext দেখে।

দামটা কিন্তু সত্যিকারের:

• পুরো চক্র চালাও তুমি: key রাখা, rotation, access, আর যে যে program data পড়ে তার প্রতিটায় decryption।
• AWS service ভেতরে তাকাতে পারে না: Athena query নেই, ব্যক্তিগত data খুঁজতে Macie scan নেই, Lambda দিয়ে thumbnail নেই, full-text search নেই, যদি না সেই code-এর হাতে key থাকে।
• Key হারালে data-ও শেষ। AWS-এর কেউ সাহায্য করতে পারবে না।

#কে পড়তে পারে?

মনে রাখার মতো একটাই table: প্রতিটা পদ্ধতিতে plaintext কে কখনো দেখতে পারে।

প্রতিটা ঘর নিজে চেষ্টা করে দেখো:

#Envelope encryption: AWS আসলে যেভাবে encrypt করে

#KMS-এ data পাঠানোর সমস্যা

KMS তার key রাখে hardware security module-এর ভেতরে, আর KMS key কখনো খোলা অবস্থায় KMS ছাড়ে না। তাহলে S3 এটা দিয়ে 5 GB-র একটা object encrypt করে কীভাবে? 5 GB KMS-এ পাঠিয়ে নিশ্চয়ই না:

• KMS-এর Encrypt operation সর্বোচ্চ 4 KB (৪,০৯৬ byte) plaintext নেয়। এটা বানানো password-এর মতো ছোট গোপন জিনিসের জন্য, file-এর জন্য না।
• ছোট জিনিস হলেও প্রতিটা record-এর জন্য network দিয়ে KMS ডাকা মানে ধীর গতি, প্রতিবার request-এর খরচ, আর KMS request quota খেয়ে ফেলা, যে quota account আর Region-এর সব service ভাগ করে নেয়।

#Data key আর key-encryption key

সমাধান হলো envelope encryption: data encrypt হয় একটা data key দিয়ে, আর data key encrypt হয় KMS key দিয়ে। এখানে KMS key-টা একটা key-encryption key (KEK)।

1. একটা data key চাও

   Client (S3, EBS, বা Encryption SDK-এর মাধ্যমে তোমার নিজের code) একটা KMS key-এর ওপর GenerateDataKey ডাকে। KMS permission দেখে একই data key দুবার ফেরত দেয়: plaintext রূপে, আর KMS key দিয়ে encrypted রূপে।

2. নিজের কাছেই encrypt করো

   Client plaintext data key দিয়ে data encrypt করে (AES-256), নিজের কাছে, দ্রুত, কোনো সাইজের সীমা ছাড়া।

3. খোলা key ফেলে দাও

   Plaintext data key যত দ্রুত সম্ভব memory থেকে মুছে ফেলা হয়।

4. Encrypted key data-র সাথে রাখো

   Encrypted data key রাখা হয় ciphertext-এর ঠিক পাশে, একই “খামে” (object-এর metadata, volume-এর metadata, Encryption SDK-এর message header)।

5. Decrypt করতে শুধু key খোলাও

   Client KMS-এর Decrypt-এ পাঠায় শুধু encrypted data key। KMS permission দেখে, call-টা CloudTrail-এ লেখে, আর plaintext data key ফেরত দেয়। Client নিজের কাছে data decrypt করে আবার key মুছে ফেলে।

এই নকশা কেন জেতে:

• গতি আর মাপ: বড় data যেখানে আছে সেখানেই encrypt হয়, কখনো KMS-এ যায় না। পথে যায় শুধু ৩২ byte-এর key।
• খরচ আর quota: প্রতি record-এ না, প্রতি data key-এ একবার KMS call। Library কয়েকটা message-এর জন্য একটা data key cache-ও করতে পারে, আর S3 Bucket Key অনেক object-এর জন্য একটাই ব্যবহার করে (লেসন ১০.৮)।
• নিয়ন্ত্রণ এক জায়গায় থাকে: প্রতিটা decrypt-এ তবুও KMS লাগে, তাই প্রতিটা পড়ায় key policy, IAM আর CloudTrail খাটে। KMS key disable করো, প্রতিটা খাম সিল হয়ে যায়।
• Rotation সস্তা: KMS key rotate করা মানে terabyte-এর পর terabyte নতুন করে encrypt করা না। পুরনো data key খুলতে KMS পুরনো key material রেখে দেয়, আর নতুন data key মোড়ানো হয় নতুন material দিয়ে।
• ক্ষতির পরিধি ছোট: প্রতিটা object বা volume-এর আলাদা data key, তাই একটা data key ফাঁস হলে ফাঁস হয় একটা object, সবকিছু না।

এর একটা রূপ GenerateDataKeyWithoutPlaintext, যা শুধু encrypted data key ফেরত দেয়; এমন component-এর জন্য, যে এখন key জমা রাখবে আর পরে KMS-কে decrypt করতে বলবে (volume বানানোর সময় EBS এটাই করে, লেসন ৫.২)।

#কোথায় ভুল হয়

• HTTPS-এর পাশে HTTP খোলা থেকে গেছে। Port 80-এর একটা load balancer listener redirect না করে app-ই দেখাচ্ছে, বা bucket-এ SecureTransport-এর Deny নেই: পুরনো client থেকে data খোলা অবস্থায় যায়। HTTP-কে HTTPS-এ redirect করো, TLS ছাড়া request deny করো।
• Certificate যাচাই বন্ধ। একটা error চাপা দিতে app বা script-এ “verify = false”, তাই যেকোনো certificate মেনে নেয়, আর MITM আবার সফল। বরং trust store ঠিক করো।
• “Encrypted তো, তাই নিরাপদ।” Server-side encryption-এ পড়ার permission যার আছে, সে plaintext পায়। Encryption at rest least-privilege permission-এর বিকল্প না; KMS key দ্বিতীয় দরজা হয় তখনই, যখন তার key policy সত্যিই সরু।
• S3 অনুমতি দিলেও AccessDenied। Object-টা SSE-KMS, আর caller-এর kms:Decrypt নেই (বা key policy তার account-কে বিশ্বাস করে না)। Key-এর permission দাও, S3-এর বাড়তি permission না।
• Key বদলানোর পর data পড়া যাচ্ছে না। KMS key disable বা delete-এর জন্য schedule করা, import করা key-এর material-এর মেয়াদ শেষ, বা client-side key কারও laptop-এ হারিয়ে গেছে। Key-কে data-র চেয়েও দামি ভাবো।
• নিয়ম end to end চায়, অথচ TLS শেষ load balancer-এ। Instance পর্যন্ত শেষ ধাপটা খোলা HTTP। HTTPS target group বা NLB passthrough নাও।
• Client-side encryption অন্য service ভেঙে দেয়। Ciphertext-এর ওপর Athena, Macie, search বা ছবি process করা অর্থহীন ফল দেয়। ঠিক কোন field-এর সত্যিই দরকার, সেটা ভেবে বাছো (যেমন শুধু NID scan, পুরো order history না)।
• সংবেদনশীল data encrypted অংশের বাইরে। S3-এর server-side encryption object-এর নাম, tag বা metadata encrypt করে না, তাই nid/rina-akter-1990.jpg-এর মতো key-তে নাম ফাঁস হয়ে যায়। অর্থহীন ID ব্যবহার করো।

#System design-এ encryption

বাংলাদেশের একটা fintech-এর জন্য স্তরে স্তরে সাজানো চেনা একটা design:

• Edge: ACM certificate সহ CloudFront বা ALB, শুধু TLS 1.2+, HTTP গেলে HTTPS-এ redirect।
• ভেতরে: নিয়ম যেখানে চায় সেখানে ALB থেকে service পর্যন্ত TLS, parameter দিয়ে RDS আর ElastiCache-এ TLS বাধ্যতামূলক, EFS mount হয় tls দিয়ে।
• জমা data, সব জায়গায়: EBS আর RDS default-এ encrypted, S3-এ SSE-KMS আর Bucket Key, সবই customer managed key দিয়ে, যাদের key policy টিমের সীমানা মেনে লেখা, আর প্রতিটা ব্যবহারে CloudTrail-এর নজর।
• সবচেয়ে সংবেদনশীল field: NID scan আর card data-র জন্য client-side encryption, এমন KMS key-এর key দিয়ে যা শুধু একটা service role ব্যবহার করতে পারে।
• Secret আর certificate সামলায় Secrets Manager আর ACM, server-এ পড়ে থাকা file না (লেসন ২১.৩ আর ২১.৪)।

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

এই command-গুলো AWS CLI v2 আর OpenSSL ব্যবহার করে। একটা KMS key-এর দাম মাসে প্রায় ১ USD, তাই শেষে key-টা delete-এর জন্য schedule করে দিয়ো।

# 1. Look at a real TLS handshake: protocol, cipher and the certificate chain
openssl s_client -connect aws.amazon.com:443 -servername aws.amazon.com -brief </dev/null
# CONNECTION ESTABLISHED
# Protocol version: TLSv1.3
# Ciphersuite: TLS_AES_128_GCM_SHA256
# Peer certificate: CN = aws.amazon.com
# Verification: OK

# 2. Plain HTTP versus HTTPS: the request line is readable only in the first case on the wire
curl -sv http://example.com -o /dev/null 2>&1 | grep -E '^> (GET|Host)'
curl -sv https://example.com -o /dev/null 2>&1 | grep -E 'SSL connection|subject:'

# 3. A symmetric KMS key for the lab
KEY_ID=$(aws kms create-key --description "enc-basics lab" --query KeyMetadata.KeyId --output text)
aws kms create-alias --alias-name alias/enc-basics-lab --target-key-id "$KEY_ID"

# 4. Encrypt a small secret directly with KMS (under 4 KB: fine)
aws kms encrypt --key-id alias/enc-basics-lab --plaintext fileb://<(echo -n 'db-password-example') \
  --query CiphertextBlob --output text > secret.b64

# 5. Try a 5 MB file directly: KMS refuses
head -c 5242880 /dev/urandom > big.bin
aws kms encrypt --key-id alias/enc-basics-lab --plaintext fileb://big.bin
# An error occurred (ValidationException) ... Member must have length less than or equal to 4096

# 6. Envelope encryption by hand: get a data key in two forms
aws kms generate-data-key --key-id alias/enc-basics-lab --key-spec AES_256 > dk.json
jq -r .Plaintext dk.json | base64 -d > dk.plain          # 32 bytes, use and destroy
jq -r .CiphertextBlob dk.json | base64 -d > dk.enc       # keep this next to the data

# 7. Encrypt the big file locally with the plaintext data key, then wipe the key
openssl enc -aes-256-cbc -pbkdf2 -in big.bin -out big.bin.enc -pass file:dk.plain
shred -u dk.plain

# 8. Later: ask KMS to unwrap only the small encrypted key, then decrypt locally
aws kms decrypt --ciphertext-blob fileb://dk.enc --query Plaintext --output text | base64 -d > dk.plain
openssl enc -d -aes-256-cbc -pbkdf2 -in big.bin.enc -out big.check -pass file:dk.plain
cmp big.bin big.check && echo "same file"
shred -u dk.plain

# 9. Server-side encryption needs no code: upload with SSE-KMS and look at the result
aws s3 cp big.bin s3://enc-lab-example/big.bin --sse aws:kms --sse-kms-key-id alias/enc-basics-lab
aws s3api head-object --bucket enc-lab-example --key big.bin \
  --query '[ServerSideEncryption,SSEKMSKeyId]'
# [ "aws:kms", "arn:aws:kms:ap-southeast-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" ]

# 10. Clean up (the key waits 7 days before it is really deleted)
aws s3 rm s3://enc-lab-example/big.bin
aws kms schedule-key-deletion --key-id "$KEY_ID" --pending-window-in-days 7

৭ নম্বর ধাপে openssl enc শুধু ধারণাটা দেখানোর জন্য; আসল application ব্যবহার করে AWS Encryption SDK, যা authenticated encryption দিয়ে একই ধাপগুলো করে, আর encrypted data key নিজেই message header-এ রেখে দেয়। এরপর CloudTrail-এর event history খোলো, event source kms.amazonaws.com দিয়ে filter করো: তোমার GenerateDataKey আর Decrypt call দেখবে, কিন্তু plaintext key দিয়ে নিজের কাছে যা করেছ তার কোনো রেকর্ড নেই।

#সারসংক্ষেপ

মূল কথা

• Encryption = সবার জানা algorithm আর গোপন key দিয়ে plaintext → ciphertext। উদ্দেশ্য: অননুমোদিত access থেকে data রক্ষা। পরীক্ষা: “regulatory compliance”, “unauthorised access” → encryption রাখো।
• Symmetric (একটাই key, AES-256, দ্রুত, data-র জন্য) বনাম asymmetric (public + private key জোড়া, RSA/ECC, ধীর, key বিনিময় আর digital signature-এর জন্য: private সই করে, public যাচাই করে)।
• চলার পথে: TLS (পরীক্ষার “SSL”) পাঠানোর আগে encrypt আর পাওয়ার পরে decrypt করে, integrity যাচাই করে, আর CA-র সই করা certificate দিয়ে server-এর পরিচয় প্রমাণ করে, যা MITM আটকায়। Keyword: HTTPS, “in transit”। AWS-এ: ALB, NLB, API Gateway, CloudFront-এ ACM certificate; দরকার হলে target পর্যন্ত end-to-end TLS; খোলা HTTP deny করতে aws:SecureTransport।
• Server-side at rest: service পাওয়ার পরে encrypt আর পাঠানোর আগে decrypt করে; transparent to the application, “minimal code changes”। Key ব্যবহার করতে পারতে হয় server-কে। KMS key যোগ করে দ্বিতীয় দরজা (kms:Decrypt) আর CloudTrail audit trail; service-এর নিজের key (SSE-S3) তা করে না।
• Client-side: পাঠানোর আগেই তুমি encrypt করো; AWS রাখে ciphertext, plaintext বা key কখনো দেখে না। Keyword: “full control before data leaves the network”, “AWS must never see plaintext”। Tool: AWS Encryption SDK, S3 Encryption Client, Database Encryption SDK। দাম: key তোমাকে সামলাতে হয়; AWS service content process করতে পারে না।
• Envelope encryption: GenerateDataKey একটা data key দেয় plaintext রূপে আর KMS key (KEK) দিয়ে encrypted রূপে; নিজের কাছে encrypt করো, plaintext key মুছে ফেলো, encrypted key data-র সাথে রাখো; পড়তে শুধু encrypted key পাঠাও Decrypt-এ। লাগে কারণ Encrypt সর্বোচ্চ 4 KB নেয়, আর এটা দ্রুত, সস্তা, KMS quota-র ওপরও চাপ কম।
• KMS key হারালে বা delete হলে data-ও শেষ: deletion ৭–৩০ দিন অপেক্ষা করে (লেসন ২১.২)।

নিজেকে যাচাই করো: encryption-এর গোড়ার কথা৩০টি প্রশ্ন