MFA Delete, Log, Pre-signed URL, Object Lock আর Access Point

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

• MFA Delete কী রক্ষা করে, কে আর কীভাবে এটা চালু করে, আর কী সে আটকায় না, তা বুঝিয়ে বলতে।
• Server access logging ঠিকভাবে বসাতে, logging loop এড়াতে, আর access log নাকি CloudTrail, সেটা বাছতে।
• Pre-signed URL বানাতে, সেটা আসলে কখন মরবে আগে থেকে বলতে, আর সেটা কার অনুমতি নিয়ে চলে তা ব্যাখ্যা করতে।
• Glacier Vault Lock, Object Lock-এর governance mode, compliance mode আর legal hold আলাদা করে চিনতে, আর কে কী কখন মুছতে পারবে তা হিসাব করতে।
• Access point দিয়ে একটা bucket-এর security টিম ধরে ভাগ করতে, access point-কে একটা VPC-তে বেঁধে দিতে, আর Multi-Region Access Point দিয়ে কয়েক Region-এর ডেটা এক নামে সার্ভ করতে।
• S3 Object Lambda কী, ২০২৫-এ তার availability-তে কী বদল এসেছে, আর AWS এখন কী বিকল্প বলে, তা জানতে।
• এই অংশের পরীক্ষার প্রতিটা keyword ঠিক feature-এর সাথে মেলাতে।

#Bucket-এর জন্য আরো ছয়টা তালা

আগের লেসনগুলোতে bucket-এর মূল সুরক্ষা দেখেছ: কে কী করতে পারবে ঠিক করে IAM আর bucket policy (লেসন ১০.২), পুরনো কপি রেখে দেয় versioning (লেসন ১০.৪), আর byte-গুলো লুকিয়ে রাখে encryption (লেসন ১০.৮)। এই লেসনে আসছে সেই হাতিয়ারগুলো, যখন শুধু “একটা policy” দিয়ে আর কুলায় না:

#MFA Delete

#কোথায় code লাগে, কোথায় লাগে না

MFA Delete হলো একটা versioned bucket-এর বাড়তি switch। চালু থাকলে দুই রকম কাজে সাধারণ credential-এর পাশাপাশি request-এর সাথে একটা MFA code পাঠাতেই হয়:

• কোনো object version স্থায়ীভাবে মোছা (যে delete-এ version ID বলা থাকে);
• bucket-এর versioning-এর অবস্থা বদলানো (versioning suspend করা, বা MFA Delete বন্ধ করা)।

বাকি সব আগের মতোই চলে। Versioning চালু করতে, upload করতে, পড়তে, version-এর list দেখতে (মুছে যাওয়াগুলো সহ), বা version ID ছাড়া সাধারণ delete করতে code লাগে না। সাধারণ delete তো শুধু একটা delete marker বসায়, কিছুই ধ্বংস করে না।

Code যায় x-amz-mfa request header-এ: device-এর serial number (virtual device হলে তার ARN), একটা space, তারপর ৬ অঙ্কের code। এই request অবশ্যই HTTPS-এ হতে হবে।

#কে চালু করতে পারে, আর কীভাবে

• MFA Delete চালু বা বন্ধ করতে পারে শুধু bucket owner-এর account-এর root user, root user-এর MFA device দিয়ে। একজন IAM user বা role, AdministratorAccess থাকলেও, versioning চালু করতে পারে, MFA Delete না।
• Console থেকে হয় না। লাগবে AWS CLI, SDK বা REST API, আর versioning বসানোর একই call (put-bucket-versioning)। MFA Delete জমা থাকে bucket-এর versioning configuration-এর ভেতরেই।
• Versioning চালু থাকতে হবে (দুটো একই call-এ চালু করা যায়)।
• এরপর স্থায়ী delete-এ লাগে bucket owner-এর (root) MFA, তাই বাস্তবে শুধু root user, হাতে device নিয়ে, version স্থায়ীভাবে মুছতে পারে।

লেসন ২.৩-এ root-এর একার কাজের তালিকায় MFA Delete ছিল; পুরো গল্পটা এখানে। Root-এর কোনো access key থাকা উচিত না, তাই সাধারণ উপায় হলো root হিসেবে sign in করা, browser console-এ একটা shell খোলা, একটা command চালানো, তারপর sign out।

#MFA Delete যা করে না

• সাধারণ delete (delete marker) সে আটকায় না। ডেটা নিরাপদ থাকে, কিন্তু কেউ restore না করা পর্যন্ত application দেখে “file নেই”।
• Overwrite-ও আটকায় না: নতুন upload নতুন version হয়; পুরনোটা থেকে যায়।
• Lifecycle configuration-এর সাথে এটা চলে না। Lifecycle rule তো MFA code টাইপ করতে পারে না, তাই তোমাকে বাছতে হবে: পুরনো version নিজে নিজে মুছে যাওয়া, নাকি MFA Delete।
• এটা একজন মানুষ আর একটা device-এর ওপর নির্ভর করে। বড় পরিসরে নিয়মমাফিক সুরক্ষা চাইলে (সব ৭ বছর রাখো, তারপর মুছে দাও) আধুনিক উত্তর Object Lock, এই লেসনেই পরে আসছে।

#Server access log

#একটা log record-এ কী থাকে

Server access logging bucket-এ আসা প্রতিটা request-এর জন্য একটা করে লাইন লেখে: bucket owner, bucket, সময়, remote IP, কে চাইল (IAM identity, নাকি anonymous), request ID, কী operation (REST.GET.OBJECT, REST.PUT.OBJECT…), key, HTTP status, error code, কত byte গেল, মোট কত সময় লাগল, আরো কিছু। যেকোনো account থেকে আসা request, allow হোক বা deny, সবই log হয়। এই log কাজে লাগে security review-তে (কে বারবার 403 খাচ্ছে?), ব্যবহারের হিসাবে (কোন ছবি জনপ্রিয়?), আর কোন টিম কতটা ব্যবহার করল সেই অনুযায়ী খরচ ভাগ করতে।

#বসানোর নিয়ম: target bucket

Log আসে text file হিসেবে, তোমার বেছে দেওয়া একটা target bucket-এ, চাইলে logs/shop-images/-এর মতো একটা prefix-এর নিচে। Target-এর নিয়মগুলো:

• Source bucket যে Region-এ আর যে account-এ, target-কেও ঠিক সেখানেই থাকতে হবে।
• Target source bucket নিজে হওয়া উচিত না (নিচের loop দেখো)।
• তাতে Object Lock-এর default retention থাকা চলবে না।
• তার default encryption হতে হবে SSE-S3; log delivery-তে SSE-KMS চলে না।
• তার bucket policy-তে logging service principal logging.s3.amazonaws.com-কে লেখার অনুমতি দিতে হবে (console নিজেই এটা যোগ করে; ACL দিয়ে অনুমতি দেওয়াটা পুরনো পদ্ধতি)।

Delivery best effort: বেশিরভাগ record কয়েক ঘণ্টার মধ্যে আসে, তবে কোনোটা দেরিতে আসতে পারে, দুবার আসতে পারে, খুব কদাচিৎ একেবারে হারিয়েও যেতে পারে। Logging চালু করা বা target বদলানোরও কার্যকর হতে সময় লাগে। Delivery বিনা পয়সায়; টাকা লাগে file রাখার, তাই log bucket-এ পুরনো log মুছে ফেলার একটা lifecycle rule দাও (লেসন ১০.৫)। বিশ্লেষণ করতে চাইলে file-গুলো জায়গায় রেখেই Athena দিয়ে query করো (chapter ১৭)।

#Logging loop

যে bucket-এর log নিচ্ছ, target যদি সেই bucket-ই হয়, তাহলে প্রতিটা log file লেখাও ওই bucket-এর ওপর একটা request, তাতে নতুন log record হয়, সেটা আরেকটা log file হয়ে আসে, সেটাও আবার log হয়। Bucket নিজে নিজেই বাড়তে থাকে, রাতে একজনও visitor না থাকলেও, আর কাজের লাইনগুলো আবর্জনায় ডুবে যায়। AWS-এর সতর্কবাণী সোজাসাপ্টা: যে bucket পর্যবেক্ষণ করছ, তাকে কখনো তার নিজের log target বানিও না।

#Access log নাকি CloudTrail?

যে compliance audit-এ একটা event-ও বাদ পড়া চলবে না, সেখানে CloudTrail data event (chapter ১৯); সস্তায় মোটা দাগের traffic log চাইলে server access log।

#Pre-signed URL

#Pre-signed URL কীভাবে কাজ করে

Pre-signed URL দিয়ে AWS credential ছাড়া কেউ একটা নির্দিষ্ট object-এ একটা নির্দিষ্ট কাজ করতে পারে, সীমিত সময়ের জন্য: download (GET), upload (PUT) বা metadata পড়া (HEAD)। যার অনুমতি আছে, সে নিজের credential দিয়ে request-টা আগেভাগে sign করে রাখে (Signature Version 4)। Signature, access key ID, সময় আর মেয়াদ থাকে URL-এর query string-এ।

• Sign হয় নিজের যন্ত্রেই, SDK বা CLI-তে। S3-এর সাথে যোগাযোগই হয় না, তাই অনুমতি না থাকলেও URL বানানো কখনো ব্যর্থ হয় না।
• URL ব্যবহারের সময় S3 signature আর মেয়াদ যাচাই করে, তারপর request-টা বিচার করে যেন signer নিজেই পাঠিয়েছে। URL কখনো তার বানানেওয়ালার চেয়ে বেশি কিছু করতে পারে না।
• মেয়াদ শেষ না হওয়া পর্যন্ত URL বারবার ব্যবহার করা যায়: এটা একটা bearer token। যার হাতে আছে, সে-ই চালাতে পারে।
• Sign করা কোনো কিছু (method, key, sign করা header) বদলালে signature ভেঙে যায়: uploads/u7/avatar.png-এর PUT URL দিয়ে admin/config.json-এ লেখা যায় না।

বানানো যায় S3 console থেকে (Object actions → Share with a pre-signed URL), AWS CLI থেকে (aws s3 presign, download-এর জন্য), বা যেকোনো SDK থেকে (upload URL-এর জন্য এটাই লাগে)।

#কতক্ষণ বাঁচে

যে credential দিয়ে sign হলো, সেটাও একটা দ্বিতীয় সীমা টানে, আর URL মরে যেটা আগে আসে তখনই:

S3 মেয়াদ যাচাই করে request শুরুর মুহূর্তে: মেয়াদ শেষের এক সেকেন্ড আগে শুরু হওয়া ২ GB-র download পুরোটাই হবে, কিন্তু মেয়াদের পরে resume করতে গেলে ব্যর্থ হবে।

#URL কার হয়ে কাজ করে

URL বয়ে নিয়ে যায় signer-এর identity। Sign করা role যদি videos/* পড়তে পারে, তাহলে link যার হাতে সে-ও পারে, ওই একটা object-এর জন্য। Role-এর অনুমতি না থাকলে (বা bucket policy deny করলে) link দেখতে ঠিকঠাক হলেও ফেরত আসে 403 Access Denied। Bucket policy network ধরে সীমা টানলেও একই কথা: অনুমোদিত IP range বা VPC endpoint-এর বাইরে থেকে URL চালালে প্রত্যাখ্যাত।

#Pre-signed URL নিরাপদ রাখা

• মেয়াদ ছোট রাখো (download-এর জন্য কয়েক মিনিট), আর app user কে তা যাচাই করার পর দরকার মতো URL বানাও।
• Sign করো একটা আলাদা role দিয়ে, যে শুধু শেয়ার করার prefix-গুলোতেই পৌঁছাতে পারে।
• যেখানে মানায়, bucket policy-তে শর্ত দাও: network সীমার জন্য aws:SourceIp বা aws:SourceVpce, ধরো ১০ মিনিটের বেশি পুরনো signature ফিরিয়ে দিতে s3:signatureAge, আর সংবেদনশীল bucket-এ query-string authentication পুরোপুরি বন্ধ করতে s3:authType।
• মনে রেখো, signer-এর credential বাতিল করলে তার sign করা সব link একসাথে মরে যায়: কোনো incident-এ এটা কাজে লাগে।

ডেটা S3-এ ঢোকার ১৩টা পথের একটা হলো pre-signed URL; upload-এর দিকটা (browser থেকে upload, pre-signed part দিয়ে multipart) পড়ানো হয়েছে লেসন ১০.১২-এ। CDN-এর সামনে link দিতে হলে CloudFront-এর নিজস্ব signed URL আছে (chapter ১১)।

#WORM storage: Vault Lock আর Object Lock

কিছু record রাখতে হয় write once, read many (WORM) পদ্ধতিতে: একবার লেখা হলে নির্দিষ্ট সময় পর্যন্ত কেউ বদলাতে বা মুছতে পারবে না। আমেরিকার broker-dealer-দের trade record এভাবেই রাখতে হয় (SEC Rule 17a-4, FINRA-র নিয়ম), আর অন্য দেশেও অনেক ব্যাংক, হাসপাতাল আর নিয়ন্ত্রক সংস্থার এমন retention-এর নিয়ম আছে। AWS-এ WORM-এর দুটো হাতিয়ার।

#Glacier Vault Lock

Glacier Vault Lock কাজ করে আদি Amazon S3 Glacier service-এর পুরো একটা vault-এর ওপর (vault-ভিত্তিক API, S3-এর storage class না)। তুমি IAM policy-র ভাষায় একটা Vault Lock policy লেখো (যেমন “২,৫৫৫ দিনের কম বয়সী archive মোছা নিষেধ”), তারপর সেটা এমনভাবে lock করো যাতে আর কখনো বদলানো না যায়।

• ধাপ ১: Lock initiate করো: policy বসে যায়, lock যায় in-progress অবস্থায়, আর তুমি পাও একটা lock ID। Policy তখন থেকেই কার্যকর, তাই পরীক্ষা করে দেখতে পারো।
• ধাপ ২: ২৪ ঘণ্টার মধ্যে lock ID দিয়ে lock complete করো। তারপর থেকে policy আর কখনো বদলানো বা মোছা যায় না, কেউই পারে না।
• ধাপ ৩: পরীক্ষায় ভুল ধরা পড়লে abort করে আবার শুরু করো। কিছু না করলে ২৪ ঘণ্টা পর lock ID-র মেয়াদ ফুরায় আর policy মুছে যায়: vault নিজে থেকে lock হয় না।

একটা vault-এ প্রতিদিনের, বদলানো-যায় এমন অনুমতির জন্য সাধারণ একটা vault access policy-ও থাকতে পারে; জমে যায় শুধু Vault Lock policy।

#S3 Object Lock

S3 Object Lock সাধারণ bucket-এ WORM নিয়ে আসে, প্রতিটা object version ধরে:

• Versioning লাগবেই। Object Lock একবার চালু হলে আর বন্ধ করা যায় না, versioning-ও suspend করা যায় না।
• নতুন bucket-এ চালু করা যায়, আর ২০২৩-এর শেষ থেকে পুরনো bucket-এও (console, CLI বা API দিয়ে)।
• প্রতিটা object version-এ থাকতে পারে একটা retention period (একটা mode আর একটা retain-until date সহ), একটা legal hold, বা দুটোই।
• Bucket-এ একটা default retention (mode আর কত দিন বা বছর) বসানো যায়, তাহলে প্রতিটা নতুন version নিজে থেকেই lock হয়; upload-এর সময় আলাদা করে বলে দিলে সেটা default-কে ছাপিয়ে যায়।

Object Lock রক্ষা করে version, নাম না। সাধারণ delete তবুও একটা delete marker বসায় (নিচের পুরনো version lock অবস্থাতেই থাকে), আর একই key-তে upload করলে হয় নতুন version; lock করা version-এ হাত পড়ে না।

#Retention mode: governance আর compliance

তারিখের আগে compliance-mode-এর version সরানোর একমাত্র উপায় পুরো AWS account বন্ধ করে দেওয়া। এজন্যই আগে governance দিয়ে পরীক্ষা করে নাও।

#Legal hold

Legal hold হলো object version-এর ওপর একটা on/off flag, যার কোনো শেষ তারিখ নেই। চালু থাকলে retention যা-ই বলুক, version মোছা বা ওভাররাইট করা যায় না।

• এটা retention থেকে স্বাধীন: একটা version-এ hold আছে retention নেই, retention আছে hold নেই, বা দুটোই থাকতে পারে। Hold চালু অবস্থায় retention-এর মেয়াদ শেষ হলেও version সুরক্ষিত থাকে; retention চলাকালীন hold তুলে নিলে retention-ই তাকে রক্ষা করে।
• s3:PutObjectLegalHold যার আছে, সে ইচ্ছামতো hold বসাতে বা তুলতে পারে; কোনো বিশেষ mode লাগে না।
• কতদিন লাগবে জানা না থাকলে এটা ব্যবহার করো: মামলা, তদন্ত, চলমান কোনো audit।

#নিজে হাতে lock-গুলো চালিয়ে দেখো

একটা mode, একটা legal hold আর ঘড়ি ঠিক করো, একটা action বাছো, তারপর দেখো app user, compliance officer আর root user প্রত্যেকে কী উত্তর পায়।

#S3 Access Point

#এক bucket, অনেক দরজা

Finance, sales, analytics আর এক ডজন application যে data-lake bucket ভাগ করে ব্যবহার করে, শেষমেশ তার একটা বিশাল bucket policy দাঁড়ায়। প্রতিটা বদলে অন্য কোনো টিমের কাজ ভেঙে যাওয়ার ভয়, আর bucket policy-র সীমাই ২০ KB। Access point এই সমস্যার সমাধান:

• Access point হলো একটা bucket-এর সাথে জোড়া একটা নামওয়ালা network endpoint, যার নিজের hostname, নিজের ARN আর নিজের access point policy (bucket policy-র ভাষাতেই, এটাও ২০ KB পর্যন্ত)।
• প্রতিটা টিম বা application পায় নিজের access point, ছোট একটা policy সহ: finance finance/* পড়তে-লিখতে পারবে, analytics সব পড়তে পারবে, একজন partner পড়তে পারবে exports/*।
• প্রতিটা access point-এর নিজের Block Public Access setting আর একটা network origin: Internet বা VPC।
• Access point দিয়ে হয় object-এর কাজ (GET, PUT, list…), bucket পরিচালনার কাজ না, যেমন replication rule বানানো।
• প্রতি account-এ প্রতি Region-এ ১০,০০০টা পর্যন্ত access point (soft quota, বাড়ানো যায়)। প্রতিটা access point চিরকাল একটা bucket-এর সাথে বাঁধা; তৈরির পর তার network origin আর Block Public Access setting বদলানো যায় না।

#Access point policy আর bucket থেকে দায়িত্ব দেওয়া

Access point দিয়ে আসা request-কে access point policy আর bucket policy, দুটোকেই allow করতে হবে (আর caller-এর IAM policy, সবসময়ের মতো, লেসন ২.২)। প্রতিটা অনুমতি bucket policy-তে আবার না লিখে AWS পরামর্শ দেয় একটা statement দিয়ে access point-গুলোকে দায়িত্ব দিয়ে দিতে (delegate):

{
  "Effect": "Allow",
  "Principal": { "AWS": "*" },
  "Action": "*",
  "Resource": ["arn:aws:s3:::company-data-example", "arn:aws:s3:::company-data-example/*"],
  "Condition": { "StringEquals": { "s3:DataAccessPointAccount": "111122223333" } }
}

মানে: “account 111122223333-এর কোনো access point দিয়ে যা আসবে, সব allow”; তারপর সিদ্ধান্ত নেয় access point-এর policy। দুটো ফাঁদ:

• Access point bucket-এর নিজের আচরণ বদলায় না। যার IAM policy S3 allow করে, সে এখনো সরাসরি bucket-কে call করতে পারে। সবাইকে দরজা দিয়ে আসতে বাধ্য করতে, যেসব request access point দিয়ে আসে না তাদের জন্য একটা স্পষ্ট Deny দাও।
• Access point অনুমতি কমাতে পারে, bucket যতটুকু দেয় তার বাইরে বাড়াতে পারে না।

#শুধু VPC-র access point

Network origin VPC দেওয়া access point request নেয় শুধু একটা নির্দিষ্ট VPC থেকে। Internet থেকে আসা request ফিরিয়ে দেয়, credential যা-ই থাকুক।

• VPC থেকে traffic পৌঁছায় S3-এর একটা VPC endpoint দিয়ে: gateway endpoint বা interface endpoint, দুটোই চলে (এগুলো কীভাবে কাজ করে, আর S3-এ যাওয়ার বাকি সব private পথ, লেসন ১০.১০-এ; endpoint-এর পুরো লেসন ২২.২)।
• তিনটা policy-কেই allow করতে হবে: endpoint policy (bucket-এর সাথে access point-এর ARN-ও allow করতে হবে), access point policy আর bucket policy।
• পুরো bucket-কে internet থেকে দূরে রাখতে bucket policy-তে বলো, s3:AccessPointNetworkOrigin যদি VPC না হয় তাহলে object access deny; পুরো organization জুড়ে একটা SCP দিয়ে internet-origin access point বানানোই নিষেধ করা যায় (chapter ২০)।

#Multi-Region Access Point

Multi-Region Access Point (MRAP) কয়েকটা Region-এর bucket-এর সামনে দেয় একটা global endpoint:

• Request সবচেয়ে কাছের edge-এ AWS network-এ ঢোকে (MRAP চলে AWS Global Accelerator-এর ওপর, chapter ১১) আর যায় active routing status থাকা সবচেয়ে কাছের bucket-এ: latency কম, internet-এ লাফালাফিও কম।
• MRAP ডেটা কপি করে না। Bucket-গুলোর মধ্যে Cross-Region Replication তোমাকেই বসাতে হয় (লেসন ১০.৪), সাধারণত দুই দিকেই। এক Region-এ লেখার ঠিক পরে আরেক Region থেকে পড়লে, replication না পৌঁছানো পর্যন্ত না-ও পেতে পারো।
• Failover control দিয়ে চালাতে পারো active-active বা active-passive, আর সমস্যায় পড়া Region থেকে traffic কয়েক মিনিটে সরাতে পারো; disaster-recovery-র মহড়াতেও এটা কাজে লাগে।
• সীমা: একটা MRAP-এ ১৭টা Region পর্যন্ত, প্রতি account-এ ১০০টা MRAP; কোন কোন bucket থাকবে তা তৈরির সময়েই ঠিক হয়ে যায়; request sign হয় SigV4A দিয়ে (SDK নিজেই করে); VPC থেকে পৌঁছাতে লাগে interface endpoint (gateway endpoint না)।

#S3 Object Lambda

S3 Object Lambda GET request-এর পথে (HEAD আর list request-এর পথেও) তোমার নিজের একটা Lambda function বসিয়ে দেয়, যাতে প্রত্যেক caller object-এর একটা বদলানো রূপ পায়, অথচ জমা থাকা object একই থাকে।

• Bucket-এ বানাও একটা supporting access point, আর তার ওপরে একটা Object Lambda access point, যেটা function-এর নাম জানে।
• Caller Object Lambda access point-এ একটা সাধারণ GET পাঠায়। S3 আসল object-এর একটা pre-signed link দিয়ে function চালায়; function সেটা পড়ে, বদলায়, ফলাফল ফেরত দেয়, আর S3 সেটা caller-কে পাঠায়।
• এক bucket আর ডেটার এক কপিতেই আলাদা আলাদা দৃশ্য: analyst পায় আড়াল করা (redacted) রূপ, admin সাধারণ access point দিয়ে পড়ে আসলটা।

সাধারণ ব্যবহার:

• Analytics বা non-production পরিবেশের জন্য PII ঢেকে দেওয়া (জাতীয় পরিচয় নম্বর, যেমন NID বা আমেরিকার SSN, ফোন নম্বর, account নম্বর)।
• Format বদলানো, যেমন JSON চায় এমন application-এর জন্য XML থেকে JSON।
• চলতি অবস্থায় ছবি ছোট করা আর watermark বসানো, caller-এর তথ্য দিয়ে (যেমন user-এর নাম দিয়ে watermark)।

#ঠিক control বাছাই

#System design-এ S3-এর উন্নত সুরক্ষা

• সুরক্ষা স্তরে স্তরে সাজাও। একটা ব্যাংকের statement bucket: Block Public Access চালু, versioning চালু, default encryption, ৭ বছরের default retention সহ compliance mode-এ Object Lock, প্রমাণের জন্য CloudTrail data event, আলাদা log bucket-এ access log, আর প্রতি application-এর জন্য একটা access point।
• Ransomware ঠেকাতে MFA Delete-এর চেয়ে Object Lock ভালো। Compliance-mode retention দিয়ে লেখা backup root-এর password চুরি গেলেও টিকে থাকে। MFA Delete রাখো ছোট, হাতে সামলানো bucket-এর জন্য।
• Log এক জায়গায় জড়ো করো, কিন্তু delivery হোক স্থানীয়ভাবে। পুরনো পদ্ধতির access log যায় একই Region আর account-এর log bucket-এ; তারপর replicate করে বা পাঠিয়ে দাও (বা নতুন CloudWatch Logs delivery ব্যবহার করো) কেন্দ্রীয় security account-এ।
• File শেয়ার করতে কখনো bucket public কোরো না। User যাচাই করা app থেকে স্বল্পমেয়াদি pre-signed URL দাও, অনেক বড় দর্শকের জন্য signed URL সহ CloudFront।
• প্রতিটা application-কে নিজের দরজা দাও। সরু policy-র access point, দায়িত্ব দেওয়া bucket policy, আর সরাসরি access-এর জন্য স্পষ্ট deny; হাসপাতালের scan-এর মতো ভেতরের ডেটার জন্য VPC-origin access point।
• Multi-Region যাও ভেবেচিন্তে। Global, latency-সংবেদনশীল পড়া আর Region failover-এর জন্য MRAP সাথে দুই দিকের replication; মনে রেখো replication asynchronous।

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

Command-গুলোতে বানানো bucket নাম আর account 111122223333। কিছু command-এ root user লাগে (MFA Delete), কিছু setting আর ফেরানো যায় না (compliance mode): একটা sandbox account-এ চেষ্টা করো।

# 1. MFA Delete (root user হিসেবে চালাও, যেমন root হিসেবে sign in করা console shell থেকে)
aws s3api put-bucket-versioning --bucket payslips-example \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "arn:aws:iam::111122223333:mfa/root-account-mfa-device 123456"
aws s3api get-bucket-versioning --bucket payslips-example        # Status + MFADelete
# এখন স্থায়ী delete-এ code দিতেই হবে:
aws s3api delete-object --bucket payslips-example --key 2026/oct.pdf \
  --version-id <version-id> --mfa "arn:aws:iam::111122223333:mfa/root-account-mfa-device 654321"

# 2. একই Region-এর আলাদা bucket-এ server access log
cat > logging.json <<'EOF'
{ "LoggingEnabled": { "TargetBucket": "shop-logs-example", "TargetPrefix": "shop-images/" } }
EOF
aws s3api put-bucket-logging --bucket shop-images-example --bucket-logging-status file://logging.json
aws s3api get-bucket-logging --bucket shop-images-example

# 3. Pre-signed URL: default 1 ঘণ্টা, এখানে 15 মিনিট
aws s3 presign s3://videos-example/premium/42.mp4 --expires-in 900
curl -s -o /dev/null -w "%{http_code}\n" "<URL-টা এখানে বসাও>"   # এখন 200, 15 মিনিট পরে 403

# 4. নতুন bucket-এ Object Lock, default 30 দিনের governance
aws s3api create-bucket --bucket statements-example --object-lock-enabled-for-bucket
aws s3api put-object-lock-configuration --bucket statements-example \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":30}}}'
aws s3api put-object --bucket statements-example --key stmt-0412.pdf --body stmt-0412.pdf
aws s3api get-object-retention --bucket statements-example --key stmt-0412.pdf
aws s3api put-object-legal-hold --bucket statements-example --key stmt-0412.pdf --legal-hold Status=ON
# Governance-এ lock করা version মোছা (s3:BypassGovernanceRetention লাগবে):
aws s3api delete-object --bucket statements-example --key stmt-0412.pdf \
  --version-id <version-id> --bypass-governance-retention

# 5. Access point: একটা internet-origin, একটা শুধু VPC-র
aws s3control create-access-point --account-id 111122223333 --name finance-ap \
  --bucket company-data-example
aws s3control create-access-point --account-id 111122223333 --name scans-vpc-ap \
  --bucket scans-example --vpc-configuration VpcId=vpc-0abc1234example
aws s3api get-object --bucket arn:aws:s3:ap-south-1:111122223333:accesspoint/finance-ap \
  --key finance/q3.xlsx q3.xlsx

# 6. Glacier Vault Lock (শুধু পুরনো vault customer-দের জন্য)
aws glacier initiate-vault-lock --account-id - --vault-name trades-vault --policy file://lock.json
aws glacier complete-vault-lock --account-id - --vault-name trades-vault --lock-id <lock-id>

aws s3 cp s3://shop-logs-example/shop-images/<file> - দিয়ে delivered একটা log লাইন দেখো, আর খুঁজে বের করো কে চাইল, কী operation, আর HTTP status কত। তারপর --bypass-governance-retention ছাড়া lock করা version মোছার চেষ্টা করো, আর 403-টা পড়ে দেখো।

#সারাংশ

মূল কথাগুলো

• MFA Delete: version স্থায়ীভাবে মুছতে বা versioning বদলাতে MFA code লাগে; versioning চালু করতে, version-এর list দেখতে বা সাধারণ delete-এ লাগে না। Versioning লাগবে, শুধু root user, শুধু CLI/API, lifecycle rule-এর সাথে চলে না।
• Server access log: প্রতিটা request, allow বা deny, text file হিসেবে একই Region আর account-এর target bucket-এ; best effort, কয়েক ঘণ্টা দেরিতে; target-এ SSE-S3, Object Lock default retention না। কোনো bucket-এর log তার নিজের ভেতরে কখনো না (logging loop)। পুরো, identity সহ audit-এর জন্য CloudTrail data event। নতুন (জুন ২০২৬): CloudWatch Logs-এ delivery।
• Pre-signed URL: AWS credential ছাড়া একটা object-এ সাময়িক GET/PUT; চলে signer-এর অনুমতিতে; console ১ মিনিট–১২ ঘণ্টা, CLI default ১ ঘণ্টা, সর্বোচ্চ ৭ দিন; sign করা credential-এর মেয়াদ ফুরালে বা বাতিল হলে আগেই মরে; bearer token, তাই মেয়াদ ছোট রাখো।
• Glacier Vault Lock: পুরো vault-এ Vault Lock policy; initiate → পরীক্ষা → ২৪ ঘণ্টার মধ্যে complete, নইলে মেয়াদ ফুরায়; lock হলে চিরকাল অপরিবর্তনীয়। ডিসেম্বর ২০২৫ থেকে vault service নতুন customer নেয় না।
• Object Lock: প্রতি object version-এ WORM; versioning লাগবে, বন্ধ করা যায় না; পুরনো bucket-এও চলে; bucket ধরে default retention।
• Governance: s3:BypassGovernanceRetention + header থাকা বিশেষ user মুছতে বা মেয়াদ কমাতে পারে। Compliance: কেউ না, root-ও না; মেয়াদ বাড়ানো যায়, কমানো কখনো না।
• Legal hold: শেষ তারিখ নেই, retention থেকে স্বাধীন, s3:PutObjectLegalHold দিয়ে on/off। নতুন (সেপ্টেম্বর ২০২৬): variable retention-এর জন্য event hold।
• Access point: প্রতি টিমের একটা endpoint আর policy; access point আর bucket policy দুটোকেই allow করতে হবে (s3:DataAccessPointAccount দিয়ে delegate); network origin Internet বা VPC, তৈরির সময়েই ঠিক; প্রতি account-এ প্রতি Region-এ ১০,০০০টা।
• VPC access point: শুধু একটা VPC থেকে, gateway বা interface endpoint দিয়ে; endpoint, access point আর bucket policy তিনটাকেই allow করতে হবে।
• MRAP: Global Accelerator-এর ওপর একটা global endpoint, সবচেয়ে কাছের active bucket, failover control; replication তোমাকেই বসাতে হয়; ১৭টা Region পর্যন্ত; SigV4A।
• S3 Object Lambda: Object Lambda access point দিয়ে (supporting access point-এর ওপর) Lambda GET-এর ফলাফল বদলায় (PII আড়াল, XML → JSON, resize/watermark); নভেম্বর ২০২৫ থেকে নতুন customer-দের জন্য বন্ধ।

নিজেকে যাচাই করো: S3-এর উন্নত সুরক্ষা৩০টি প্রশ্ন