আমার Bucket কে পড়তে পারবে? IAM, Bucket Policy আর Block Public Access

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

• S3-এ access নিয়ন্ত্রণের হাতিয়ারগুলোর নাম বলতে, আর কোনটা access দেয় আর কোনটা শুধু সীমা টানে সেটা আলাদা করতে: IAM policy, bucket policy, ACL, Block Public Access আর Object Ownership।
• একটা bucket policy পড়তে আর লিখতে: Effect, Principal, Action, Resource, Condition, আর bucket ARN আর object ARN-এর তফাত।
• যেকোনো S3 request-এর সিদ্ধান্ত হাতে-কলমে বের করতে: একই account (একটা Allow-ই যথেষ্ট), অন্য account (দুই দিককেই allow করতে হবে), anonymous (শুধু bucket allow করতে পারে), আর তার ওপরে explicit Deny আর Block Public Access।
• চেনা পরিস্থিতিগুলোর জন্য ঠিক pattern বেছে নিতে: public website, EC2-র application, partner account, পুরো organization, শুধু HTTPS, শুধু নিজের VPC থেকে।
• Block Public Access-এর চারটা setting, কোন কোন level-এ বসে, আর কেউ হাত না দিলেও একটা public policy কেন হঠাৎ কাজ করা বন্ধ করতে পারে, সেটা বোঝাতে।
• Object Ownership কী, আর এপ্রিল ২০২৩ থেকে ACL কেন default-এ বন্ধ, সেটা বলতে; আর IAM Access Analyzer for S3 দিয়ে খোলা পড়ে থাকা bucket খুঁজে বের করতে।

#প্রতিটা bucket শুরু হয় private হয়ে

#প্রতিটা request-এ দুটো প্রশ্ন

S3-এ যে request-ই আসুক, তার উত্তর হয় দুই ধাপে, ঠিক AWS-এর অন্য সব request-এর মতো (লেসন ২.২):

1. কে চাইছে? S3 signature দেখে। Sign করা request আসে একজন principal-এর কাছ থেকে: IAM user, role session (EC2 instance, Lambda function, বা role assume করা কোনো মানুষ), root user, বা কোনো AWS service। Signature ছাড়া request হলো anonymous: browser-এ একটা link খোলা, বা credential ছাড়া curl।
2. এই principal কি এই resource-এ এই কাজটা করতে পারে? S3 প্রযোজ্য সব policy জড়ো করে সিদ্ধান্ত দেয়: Allow নাকি Deny।

নতুন একটা bucket দ্বিতীয় প্রশ্নের উত্তরে সবাইকে না বলে, শুধু নিজের account-এর সেই principal-রা ছাড়া যাদের IAM permission আছে। Account-এর বাইরের কেউ, বা কোনো anonymous visitor, কিছুই পড়তে পারে না যতক্ষণ না কেউ জেনে-বুঝে অনুমতি দেয়। তার ওপর এপ্রিল ২০২৩ থেকে প্রতিটা নতুন bucket আসে আরও দুটো তালা আগে থেকেই লাগানো অবস্থায়: Block Public Access চালু, আর ACL বন্ধ। দুটোই এই লেসনের পরের দিকে বুঝিয়ে বলা আছে।

#এক নজরে সব হাতিয়ার

Slide-এ পুরো ব্যাপারটা দুই ভাগে বলা: user-based (IAM policy: এই user কোন কোন API call করতে পারবে) আর resource-based (bucket policy, object ACL, bucket ACL)। এই লেসনে আমরা একটা একটা করে ধরব, তারপর সব একসঙ্গে জোড়া দেব।

#User-based access: IAM policy

IAM policy লাগানো থাকে একটা user, group বা role-এ, আর বলে সেই identity কোন resource-এ কোন action করতে পারবে। JSON-টা তুমি লেসন ২.১-এ দেখেছ। S3-এর বেলায় আসল খুঁটিনাটি হলো, কোন action-এর জন্য কোন ARN লাগে:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListTheInvoicesPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::shop-media-example",
      "Condition": { "StringLike": { "s3:prefix": "invoices/*" } }
    },
    {
      "Sid": "ReadAndWriteInvoices",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::shop-media-example/invoices/*"
    }
  ]
}

• Bucket-level action, যেমন s3:ListBucket, কাজ করে bucket-এর ARN-এ: arn:aws:s3:::shop-media-example, শেষে কোনো slash নেই।
• Object-level action, যেমন s3:GetObject, s3:PutObject আর s3:DeleteObject, কাজ করে object-এর ARN-এ: arn:aws:s3:::shop-media-example/invoices/*।
• দুটোই লাগলে policy-তে দুই রকম ARN-ই রাখো। শুধু …/* থাকলে যে file-এর নাম আগে থেকে জানো সেটা পড়তে পারবে, কিন্তু list করতে গেলে AccessDenied। শুধু bucket ARN থাকলে list হবে, কিন্তু পড়া যাবে না।
• S3-এর ARN-এ Region বা account ID থাকে না, কারণ bucket-এর নাম পুরো পৃথিবীতে একটাই (লেসন ১০.১)।

#Application পায় role, key কখনো না

User-based access-এর জন্য slide-এ দুটো ছবি আছে: IAM policy সহ একজন IAM user, আর instance role সহ একটা EC2 instance। মনে রাখার মতো pattern হলো দ্বিতীয়টা। EC2-র application-এর disk-এ কখনো access key কপি করে রাখা হয় না; সে instance profile-এর মাধ্যমে একটা IAM role পায়, আর SDK নিজে থেকেই অল্প সময়ের credential তুলে নেয় (লেসন ২.৪)। Lambda function, ECS task আর অন্য service-ও একইভাবে নিজেদের execution role বা task role দিয়ে কাজ করে।

#Resource-based access: bucket policy

#Bucket policy দেখতে কেমন

Bucket policy হলো bucket-এর গায়েই লাগানো একটা JSON policy। Resource-এর ওপর বসে বলে তাকে বলে দিতে হয় কার কথা হচ্ছে: তাই এতে থাকে Principal, যেটা IAM policy-তে থাকে না।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadForProductPhotos",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::shop-media-example/photos/*"
    }
  ]
}

কয়েকটা নিয়ম জেনে রাখো:

• একটা bucket-এর bucket policy একটাই, সর্বোচ্চ ২০ KB। অনেক team একটা bucket share করে বলে policy যখন খুব বড় হয়ে যায়, তখন সমাধান S3 Access Point (লেসন ১০.৯)।
• Bucket policy-র Resource হতে হবে এই bucket বা তার ভেতরের object।
• Principal: "*" মানে সত্যিই সবাই, sign করুক বা না করুক। এটা ব্যবহার করো শুধু সত্যিকারের public ডেটার জন্য, অথবা এমন একটা Condition-এর সঙ্গে যেটা পরিধি ছোট করে, যেমন organization ID।
• Policy বদলাতে পারে শুধু bucket মালিকের account (s3:PutBucketPolicy permission থাকলে)।

#Bucket policy দিয়ে কী কী কাজ হয়

Slide আর নোটে bucket policy-র কাজগুলোর তালিকা আছে। নিচে প্রত্যেকটার আলাদা অংশ আছে:

• public access দেওয়া, যেমন static website-এর জন্য শুধু পড়ার অনুমতি;
• অন্য account-কে access দেওয়া (cross-account);
• HTTPS বাধ্যতামূলক করা আর upload-এ encryption বাধ্যতামূলক করা;
• network দিয়ে সীমা টানা: শুধু নির্দিষ্ট IP range থেকে, বা শুধু নিজের VPC endpoint দিয়ে;
• পুরো organization-এর সঙ্গে share করা।

#ACL, পুরনো কায়দা

Bucket policy আসার আগে (২০০৬ সালে) S3-এ ছিল access control list। ACL হলো একটা bucket বা একটা object-এর ওপর দেওয়া অনুমতির তালিকা: “X account READ করতে পারবে”, “AllUsers group READ করতে পারবে”। ACL মোটা দাগের (READ, WRITE, READ_ACP, WRITE_ACP, FULL_CONTROL), এতে condition দেওয়া যায় না, Deny করা যায় না, সর্বোচ্চ ১০০টা grant রাখা যায়, আর প্রতিটা object-এ আলাদা আলাদা বসে থাকে, তাই audit করা ভীষণ কঠিন। Slide-এ object ACL-কে বলা হয়েছে “finer grain”, কারণ প্রতিটা object-এ আলাদা করে বসানো যায়; ঠিক এই কারণেই এদের হিসাব রাখা এত ঝামেলার।

দুটো আগে থেকে ঠিক করা group অনেক নামকরা ডেটা ফাঁসের কারণ: AllUsers (internet-এর যে কেউ) আর AuthenticatedUsers (পৃথিবীর যেকোনো AWS account-এর যে কেউ, শুধু তোমার user না)। এই দুটোর যেকোনোটাকে কিছু দিলে S3 সেটাকে public ধরে।

AWS এখন বলে ACL বন্ধ রাখো আর সব কাজ policy দিয়ে করো। নতুন bucket-এ ACL default-এই বন্ধ; তার মানে কী, সেটা Object Ownership অংশে আছে।

#S3 কীভাবে সিদ্ধান্ত নেয়

#লেসন ২.২-এর নিয়ম, S3-এর ওপর

S3 বাকি AWS-এর মতো একই evaluation logic মানে (লেসন ২.২), শুধু কয়েকটা বাড়তি input আছে। Slide পুরোটা এক বাক্যে বলে: একজন principal object পড়তে পারবে যদি IAM permission allow করে OR resource policy allow করে, AND কোথাও explicit Deny না থাকে। কথাটা সত্যি একই account-এর ভেতরে। পুরো ছবিটা এরকম:

1. সবার আগে Block Public Access যেসব public অনুমতি আটকানোর জন্য সেট করা, সেগুলো বন্ধ করে দেয় (খুঁটিনাটি পরে)। সে কখনো কিছু দেয় না।
2. কোথাও explicit Deny থাকলে সে-ই জেতে। Caller-এর IAM policy, bucket policy, SCP বা RCP, বা endpoint policy, যেখানেই Deny মিলুক, evaluation সেখানেই শেষ। কোনো Allow সেটা উল্টাতে পারে না, administrator-এর Allow-ও না।
3. তারপর S3-এর Allow লাগে, আর কয়টা লাগবে সেটা নির্ভর করে কে চাইছে তার ওপর:

এর ওপরে organization-এর SCP আর RCP, permissions boundary আর session policy শুধু সীমা টানতে পারে (লেসন ২.২), আর SSE-KMS দিয়ে encrypt করা object-এর বেলায় caller-এর KMS key-এর অনুমতিও লাগে (লেসন ১০.৮)।

#অন্য account হলে দুই দিক কেন লাগে

“দুই দিককেই allow করতে হবে” নিয়মটা দুই কোম্পানিকেই রক্ষা করে:

• Bucket-এর মালিককে রাজি হতে হয়, নাহলে যে কেউ অন্যের bucket-এর জন্য একটা IAM policy লিখে সেটা পড়ে ফেলত।
• Caller-এর account-কে রাজি হতে হয়, নাহলে অচেনা কারও bucket policy তোমার কর্মচারীদের এমন অনুমতি দিয়ে দিত যেটা তোমার security team কখনো অনুমোদন করেনি।

Bucket policy যখন পুরো একটা account-এর নাম লেখে (arn:aws:iam::444455556666:root), তার মানে “ওই account-কে বিশ্বাস করি, তার কোন user বা role এটা পাবে সেটা সে-ই ঠিক করুক”। এতে ওই account-এর প্রতিটা user আপনা থেকে access পেয়ে যায় না। তাদের administrator-কে IAM দিয়ে দিতে হয়।

#যে 403-এর পেছনে লুকিয়ে থাকে 404

কোনো principal-এর যদি bucket list করার অনুমতি না থাকে (s3:ListBucket নেই) আর সে এমন একটা key চায় যেটা আসলে নেই, S3 উত্তর দেয় 403 AccessDenied, 404 Not Found না। এটা ইচ্ছা করেই: নাহলে বাইরের কেউ খুঁচিয়ে খুঁচিয়ে বের করে ফেলত কোন কোন file-এর নাম আছে। GET-এ 403 পেলে troubleshoot করার সময় আগে দেখো key-টা সত্যিই আছে কি না। s3:ListBucket অনুমতি থাকলে না-থাকা key-তে আসে 404 NoSuchKey।

#চেনা access pattern-গুলো

#Website-এর জন্য public read

Slide-এর প্রথম উদাহরণ: web-এর একজন anonymous visitor একটা bucket থেকে file পড়ছে, অনুমতি দিয়েছে bucket policy। দোকান পণ্যের ছবির জন্য ঠিক এটাই করে, আগে দেখানো policy দিয়ে (Principal: "*", s3:GetObject, photos/*)। তিনটা জিনিস ঠিক থাকতে হবে:

1. Block Public Access আটকাবে না, bucket আর account দুই level-এই (আর organization level-এ কিছু বসানো থাকলে সেখানেও)।
2. Bucket policy ঠিক prefix-এ "*"-কে s3:GetObject দেয়। শুধু পড়ার অনুমতি দাও, লেখার কখনো না: public s3:PutObject মানে তোমার bucket হয়ে গেল যে কারও file রাখার ফ্রি জায়গা, আর bill আসবে তোমার নামে।
3. Resource একদম ঠিকঠাক। photos/* public; invoices/ private-ই থাকে। ভুল করে shop-media-example/* লিখে ফেলা, ডেটা ফাঁস এভাবেই হয়।

Website hosting নিজে (endpoint, index আর error document, 403-এর ফাঁদ) লেসন ১০.৩-এর বিষয়। আজকাল বেশিরভাগ website-এর জন্য ভালো design হলো private bucket আর সামনে CloudFront, Origin Access Control দিয়ে, যাতে bucket নিজে কখনো public না হয়; সেটা আসবে chapter ১১-এ।

#EC2-র একটা application

ওপরে বলা হয়েছে: instance-এ একটা IAM role, তাতে শুধু দরকারি prefix-এর জন্য IAM policy। একই account, তাই bucket policy লাগে না। পাহারার জন্য চাইলে bucket policy-তে একটা Deny যোগ করো (যেমন “শুধু আমাদের VPC endpoint দিয়ে”)।

#অন্য account: দুটো pattern

Slide-এ দেখানো আছে bucket policy দিয়ে cross-account access। বাস্তবে উপায় দুটো, আর পরীক্ষা দুটোই জানতে চায়:

দুই pattern-এই মালিক সবচেয়ে ছোট পরিসরটুকু দেবে: একটা prefix, শুধু পড়া, দরকার হলে একটা condition।

#পুরো একটা organization

Bucket policy-তে ৪০টা account ID লেখা, আর প্রতিবার নতুন account যোগ হলে policy বদলানো, এভাবে চলে না। Condition key aws:PrincipalOrgID ব্যবহার করো:

{
  "Sid": "AllAccountsInOurOrganization",
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::shop-shared-config-example/*",
  "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-a1b2c3d4e5" } }
}

একটা নির্দিষ্ট organization ID সহ Principal: "*" S3-এর চোখে public না, তাই Block Public Access এটা আটকায় না। Organization-এর প্রতিটা account, আগামী বছর যোগ হওয়া account-সহ, পড়তে পারবে, যদি তার নিজের IAM policy-ও allow করে।

#পাহারাদার: bucket policy-তে Deny statement

Bucket policy access দিতে যেমন পারে, কেড়েও নিতে পারে। Explicit Deny যেহেতু সব Allow-কে হারায়, কয়েকটা Deny statement bucket-টাকে নিজেই নিজের নিরাপত্তারক্ষী বানিয়ে দেয়, পরে কেউ যে IAM policy-ই লিখুক না কেন।

#শুধু HTTPS (encryption in transit)

নোটের প্রধান exam trick:

{
  "Sid": "DenyInsecureTransport",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::shop-media-example",
    "arn:aws:s3:::shop-media-example/*"
  ],
  "Condition": { "Bool": { "aws:SecureTransport": "false" } }
}

Request TLS (HTTPS) দিয়ে এলে aws:SecureTransport হয় true, সাধারণ HTTP হলে false। Deny-টা যে কারও কাছ থেকে আসা প্রতিটা সাধারণ HTTP request ধরে ফেলে। TLS আর S3-এর encryption নিয়ে বিস্তারিত লেসন ১০.৮-এ।

#শুধু নিজের network থেকে

• aws:SourceVpce: শুধু নির্দিষ্ট একটা VPC endpoint দিয়ে আসা request। “Invoice পড়া যাবে শুধু আমাদের VPC-র ভেতর থেকে”, এটা বলার স্বাভাবিক উপায় (gateway endpoint লেসন ১০.১০-এ)। একটা VPC-র যেকোনো endpoint-এর জন্য একই কাজ করে aws:SourceVpc।
• aws:SourceIp: শুধু নির্দিষ্ট public IP range থেকে আসা request, যেমন অফিসের 198.51.100.0/24। VPC endpoint দিয়ে আসা traffic-এ এটা কাজ করে না, কারণ ওই request-এ মেলানোর মতো কোনো public address থাকে না; সেখানে endpoint-এর key ব্যবহার করো।

এগুলো লেখো “Deny … যদি না” আকারে (StringNotEquals, NotIpAddress), “শুধু এই শর্তে Allow” আকারে না: যার IAM policy আগেই s3:* allow করে, তার বিরুদ্ধে condition-ওয়ালা Allow কিছুই করে না, কিন্তু Deny সবাইকে থামায়।

#নিজেকে তালাবন্ধ করে ফেলো না

Action: "s3:*" সহ একটা Deny s3:PutBucketPolicy আর s3:DeleteBucketPolicy-ও deny করে। Condition যদি bucket দেখাশোনার মানুষদেরও বাদ দিয়ে ফেলে, তাহলে policy ঠিক করার আর কেউ থাকে না। দুটো অভ্যাস এটা ঠেকায়:

• একটা admin role-এর জন্য ছাড় যোগ করো: অন্য condition-এর পাশে "Condition": {"ArnNotEquals": {"aws:PrincipalArn": "arn:aws:iam::111122223333:role/storage-admin"}}।
• তবুও ঘটে গেলে, account-এর root user সবসময় bucket policy মুছে দিতে পারে। AWS Organizations-এর এমন member account, যার root credential নেই, সেখানে management account কাজটা কেন্দ্রীয়ভাবে করতে পারে, privileged root task হিসেবে।

#Block Public Access

#কেন এটা এল

বছরের পর বছর S3-এর ডেটা ফাঁস খবরের শিরোনাম হয়েছে: ভোটার তালিকা, হাসপাতালের রেকর্ড, প্রতিরক্ষার ফাইল, সব এমন bucket-এ যেটা কেউ একটা ভুল policy বা একটা AllUsers ACL দিয়ে public করে ফেলেছিল। নভেম্বর ২০১৮-তে AWS আনল S3 Block Public Access: এমন setting যেটা policy আর ACL-কে ছাপিয়ে যায়, যাতে bucket যেভাবেই সাজানো থাকুক public access হতেই না পারে। Slide যেমন বলে: কোনো bucket কখনো public হবে না জানলে এগুলো চালু রেখে দাও।

#চারটা setting

দুই জোড়া: প্রতি জোড়ার একটা থামায় নতুন public অনুমতি, অন্যটা আগে থেকে থাকা অনুমতিকে অকেজো করে। Setting-গুলো একটা আরেকটার ওপর নির্ভর করে না, আর console-এ একটা checkbox আছে, “Block all public access”, যেটা চারটাই চালু করে দেয়।

#কোনটা public গোনা হয়

S3 শুরুতেই ধরে নেয় bucket policy public, তারপর খোঁজে কেন সেটা public না। একটা statement public না, যদি সে শুধু এগুলোর নির্দিষ্ট value-কে access দেয়:

• নির্দিষ্ট principal: একটা account, user, role, service principal;
• aws:PrincipalOrgID (তোমার organization);
• aws:SourceIp, তবে IPv4-এ /8-এর চেয়ে বড় range না (private RFC 1918 range চলবে);
• aws:SourceVpc, aws:SourceVpce, aws:SourceArn, aws:SourceAccount, aws:SourceOwner, aws:userid, s3:DataAccessPointArn, s3:DataAccessPointAccount।

তাই শুধু Principal: "*" হলো public; aws:SourceVpce = vpce-1a2b3c4d সহ Principal: "*" public না। একটা ACL public, যদি সেটা AllUsers বা AuthenticatedUsers-কে কিছু দেয়।

#Level আর কে কার ওপরে

Block Public Access চারটা level-এ বসানো যায়:

• Access point: access point বানানোর সময় সেট হয়; পরে আর বদলানো যায় না।
• Bucket: bucket আর তার access point-গুলোর ওপর খাটে।
• Account: account-এর এখনকার আর ভবিষ্যতের সব bucket আর access point-এ, সব Region-এ (প্রতিটা Region-এ পৌঁছাতে একটু সময় লাগতে পারে)।
• Organization (নতুন, নভেম্বর ২০২৫): AWS Organizations-এর একটা policy, যেটা বাছাই করা account বা OU-তে চারটা setting-ই চালু করে দেয়, হয় সব নয় কিছুই না, আর নতুন member account আপনা থেকেই সেটা পায়।

S3 সবসময় সবচেয়ে কড়া combination-টা মানে। Account যদি বলে “আটকাও” আর bucket বলে “public চলবে”, bucket আটকে যায়। একটা public website চালাতে হলে প্রযোজ্য প্রতিটা level-এই অনুমতি দিতে হবে। AWS-এর পরামর্শ: account level-এ চারটাই চালু রাখো, আর যে কয়েকটা bucket সত্যিই public হতে হবে, সেগুলো আলাদা একটা account-এ রাখো।

Default: এপ্রিল ২০২৩ থেকে প্রতিটা নতুন bucket-এ চারটা setting-ই চালু (console, CLI, SDK আর CloudFormation, সব জায়গায়)। পুরনো bucket বদলানো হয়নি। Account level-এর setting কেউ তোমার হয়ে চালু করে দেয় না; সেটা তোমার কাজ।

#Object Ownership আর ACL

#কোন সমস্যার সমাধান

ACL-এর নিয়মে যে account object upload করে, সে-ই তার মালিক, এমনকি তোমার bucket-এর ভেতরেও। আগের দিনে একজন partner তোমার bucket-এ file upload করলে file-টা হতো partner-এর, আর তার default ACL পুরো control দিত শুধু partner-কে। তুমি এমন একটা file রাখার টাকা দিতে যেটা তুমি পড়তেই পারতে না। ঘুরপথে সমাধান ছিল প্রতিটা uploader-কে bucket-owner-full-control ACL পাঠাতে বাধ্য করা।

S3 Object Ownership (২০২০ সালে, আর “ACL বন্ধ” option যোগ হলো নভেম্বর ২০২১-এ) একটা bucket setting দিয়েই এটা মিটিয়ে দেয়:

Bucket owner enforced হলে:

• access-এর সিদ্ধান্ত নেয় শুধু policy: IAM, bucket policy, access point policy, endpoint policy, SCP, RCP;
• ACL ছাড়া, বা bucket-owner-full-control সহ upload গ্রহণ করা হয়; অন্য যেকোনো ACL ব্যর্থ হয় 400 AccessControlListNotSupported দিয়ে;
• ACL পড়া এখনো যায় (দেখবে পুরো control শুধু মালিকের), আর পরে ACL আবার চালু করা যায়, তাতে পুরনো ACL-গুলো ফিরে আসে।

পুরনো একটা bucket-এ এটা চালুর আগে, ACL এখনো যে access দিচ্ছে (যেমন কিছু file-এ public-read ACL, বা bucket-এ log delivery), সেটা bucket policy-তে সরিয়ে নাও, নাহলে ওই access বন্ধ হয়ে যাবে। AWS-এর পরামর্শ: ACL বন্ধ রাখো, শুধু সেই বিরল ক্ষেত্র ছাড়া যেখানে প্রতিটা object আলাদা করে নিয়ন্ত্রণ করতেই হবে। কিছু পুরনো feature-এর জন্য এখনো target bucket-এ ACL লাগে, যেমন CloudFront-এর legacy standard logging; ওটা দেখবে chapter ১১-এ।

#খোলা bucket খুঁজে বের করা: IAM Access Analyzer for S3

Policy, ACL, access point আর setting একটা আরেকটার সঙ্গে জড়িয়ে থাকে, আর মানুষ ভুল করে। IAM Access Analyzer for S3 S3 console-এই দেখিয়ে দেয় কোন কোন general purpose bucket তোমার account-এর বাইরে থেকে পৌঁছানো যায়:

• Public access finding: internet-এর যে কেউ bucket-এ পৌঁছাতে পারে।
• Cross-account access finding: অন্য AWS account পারে, তোমার organization-এর বাইরের account-সহ।

প্রতিটা bucket-এর জন্য দেখায় কীভাবে share হয়েছে (bucket policy, bucket ACL, access point policy, Multi-Region Access Point policy) আর কতটা access (list, read, write, permissions, tagging)। সেখান থেকে তুমি পারো:

• এক click-এ একটা bucket-এর সব public access বন্ধ করতে;
• যে finding ইচ্ছাকৃত (public website, courier-এর share), সেটা archive করতে, যাতে লেখা থাকে কেউ দেখে নিয়েছে; archive করা bucket তালিকায় থেকেই যায়, তাই সবসময় জানো কোনগুলো share করা;
• auditor-এর জন্য CSV report download করতে।

বাড়তি কোনো খরচ নেই, তবে IAM Access Analyzer-এ যে যে Region-এ bucket আছে, প্রতিটায় একটা external access analyzer বানাতে হয় (zone of trust হিসেবে account)। নতুন বা বদলানো bucket policy আর ACL মোটামুটি ৩০ মিনিটের মধ্যে finding-এ দেখা যায়; account level-এর setting বদলালে ৬ ঘণ্টা পর্যন্ত লাগতে পারে।

#নিজে হাতে সিদ্ধান্ত নিয়ে দেখো

একটা scenario বেছে নাও, তারপর একবারে একটা করে switch বদলাও: caller, IAM policy, bucket policy, HTTPS, ACL আর Block Public Access-এর চারটা setting। দেখো কোন যাচাইয়ে সিদ্ধান্ত হয়।

#কোথায় গোলমাল হয়: 403-এর checklist

#System design-এ access control

• Default-এ private, ব্যতিক্রম হলে public। সব জায়গায় account level-এ Block Public Access চালু রাখো; যে কয়েকটা bucket সত্যিই public, সেগুলো আলাদা account-এ রাখো, বা আরও ভালো, private bucket থেকে CloudFront দিয়ে পরিবেশন করো।
• Prefix ধরে সবচেয়ে কম অনুমতি। কার কী লাগবে সেই হিসেবে key prefix সাজাও (photos/, invoices/, labels/), যাতে policy ঠিক একটা prefix দিতে পারে।
• Workload-এর জন্য role। EC2, Lambda আর container পায় IAM role; কোথাও কোনো দীর্ঘমেয়াদি key না।
• Bucket policy হলো পাহারাদার। Allow-গুলো বেশিরভাগ IAM-এ রাখো, আর bucket policy-তে রাখো সেই নিয়মগুলো যেগুলো IAM যা-ই বলুক খাটতেই হবে: শুধু HTTPS, শুধু VPC endpoint দিয়ে, শুধু নিজের organization।
• Cross-account হবে নাম ধরে। Partner-এর account বা role-এর নাম লেখো; একজন partner-এর সঙ্গে share করতে কখনো Principal: "*" ব্যবহার করো না।
• ACL বন্ধ। সব জায়গায় Bucket owner enforced; ACL-এ এখনো যে অনুমতি বাকি, সেগুলো policy-তে নিয়ে যাও।
• সারাক্ষণ নজর রাখো। IAM Access Analyzer-এর finding, আর Block Public Access যাচাই করা AWS Security Hub control, মানুষ যে ভুলগুলো করবেই সেগুলো ধরে ফেলে।
• Public object-এর বদলে অস্থায়ী link। “একজন customer-কে একটা invoice download করতে দাও”, এর জন্য pre-signed URL (লেসন ১০.৯ আর লেসন ১০.১২), public object না।

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

Command-গুলোতে দোকানের বানানো bucket shop-media-example, account 111122223333।

# ১. Block Public Access-এর চারটা setting দেখো: আগে bucket level, তারপর account level
aws s3api get-public-access-block --bucket shop-media-example
aws s3control get-public-access-block --account-id 111122223333

# ২. পুরো account-এর জন্য চারটাই চালু করো (পরামর্শ এটাই)
aws s3control put-public-access-block --account-id 111122223333 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# ৩. Object Ownership: দেখো, আর পুরনো bucket-এ ACL বন্ধ করো
aws s3api get-bucket-ownership-controls --bucket shop-media-example
aws s3api put-bucket-ownership-controls --bucket shop-media-example \
  --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerEnforced}]'

# ৪. File থেকে bucket policy save করো, আবার পড়ো, আর S3-কে জিজ্ঞেস করো এটা public কি না
aws s3api put-bucket-policy --bucket shop-media-example --policy file://policy.json
aws s3api get-bucket-policy --bucket shop-media-example --query Policy --output text
aws s3api get-bucket-policy-status --bucket shop-media-example
# -> "PolicyStatus": { "IsPublic": false }

# ৫. শুধু-HTTPS নিয়মটা পরীক্ষা করো: প্রথমটা 403 দিয়ে ব্যর্থ, দ্বিতীয়টা চলে
curl -s -o /dev/null -w "%{http_code}\n" http://shop-media-example.s3.ap-southeast-1.amazonaws.com/photos/saree-red.jpg
curl -s -o /dev/null -w "%{http_code}\n" https://shop-media-example.s3.ap-southeast-1.amazonaws.com/photos/saree-red.jpg

# ৬. কিছু বদলানোর আগে S3-এর ওপর একটা IAM principal simulate করো
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/shop-web-role \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::shop-media-example/invoices/2026/10/inv-1043.pdf

# ৭. IAM Access Analyzer: প্রতি Region-এ একবার analyzer বানাও, তারপর S3-এর finding দেখো
aws accessanalyzer create-analyzer --analyzer-name account-external --type ACCOUNT
aws accessanalyzer list-findings-v2 \
  --analyzer-arn arn:aws:access-analyzer:ap-southeast-1:111122223333:analyzer/account-external \
  --filter '{"resourceType": {"eq": ["AWS::S3::Bucket"]}}'

৪ নম্বর ধাপের policy.json হতে পারে এই লেসনের যেকোনো policy। BlockPublicPolicy চালু রেখে public-read policy-টা save করে দেখো: call ব্যর্থ হবে AccessDenied দিয়ে, আর সেটাই setting-এর কাজ।

#সারসংক্ষেপ

মূল কথা

• প্রতিটা bucket শুরু হয় private। এপ্রিল ২০২৩ থেকে নতুন bucket-এ Block Public Access চালু আর ACL বন্ধ (Bucket owner enforced)।
• User-based: user, group আর role-এর IAM policy; EC2-র application পায় IAM role, key কখনো না। Resource-based: bucket policy (Principal সহ JSON, bucket প্রতি একটা, ২০ KB), আর পুরনো ACL।
• Bucket-level action (s3:ListBucket) লাগে arn:aws:s3:::bucket-এ; object action (s3:GetObject) লাগে arn:aws:s3:::bucket/*-এ।
• Explicit Deny সব জায়গায় জেতে। একই account: IAM অথবা bucket policy। Cross-account: দুটোই, caller-এর IAM policy এবং bucket policy। Anonymous: শুধু bucket allow করতে পারে।
• Bucket policy-র কাজ: public read (Principal: "*", শুধু পড়া, ঠিক prefix), cross-account, organization (aws:PrincipalOrgID), শুধু HTTPS (aws:SecureTransport false হলে Deny: in transit), upload-এ নির্দিষ্ট encryption বাধ্যতামূলক (at rest, লেসন ১০.৮), network-এর সীমা (aws:SourceVpce, aws:SourceIp)।
• Block Public Access কখনো কিছু দেয় না: BlockPublicAcls আর BlockPublicPolicy নতুন public অনুমতি ফিরিয়ে দেয়; IgnorePublicAcls আর RestrictPublicBuckets পুরনোগুলো অকেজো করে (policy public হলে শেষেরটা অন্য account-কেও আটকায়)। Level: access point, bucket, account, organization (নভেম্বর ২০২৫ থেকে); সবচেয়ে কড়াটা জেতে।
• Object Ownership: Bucket owner enforced (default, ACL বন্ধ, সবকিছুর মালিক bucket-এর মালিক), Bucket owner preferred, Object writer। অন্য ACL সহ upload ব্যর্থ হয় AccessControlListNotSupported দিয়ে।
• IAM Access Analyzer for S3 public আর cross-account bucket-এর তালিকা দেয়, এক click-এ public access বন্ধ করে, ইচ্ছাকৃত finding archive করে; প্রতি Region-এ একটা analyzer লাগে।

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