MFA, Password Policy আর Root-কে সুরক্ষিত রাখা

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

• Root user আসলে কী, কেন কোনো policy তাকে আটকাতে পারে না, আর কোন কাজগুলো শুধু root-ই পারে, তা বলতে।
• Root-কে ঠিকমতো তালাবন্ধ রাখতে: শক্ত password, একাধিক MFA device, কোনো access key নয়, প্রতিটা লগইনে alert, আর অনেক account থাকলে centralized root access।
• MFA কীভাবে কাজ করে বুঝিয়ে বলতে, আর passkey ও security key, virtual authenticator app, hardware TOTP token-এর মধ্যে কোনটা নেবে ঠিক করতে।
• MFA device হারিয়ে গেলে কী করতে হয় জানতে, IAM user-এর বেলায় আর root-এর বেলায়।
• Account-এর password policy সেট করতে, আর এটা ঠিক কী করে আর কী করে না, পরিষ্কার জানতে।
• বিপজ্জনক কাজের জন্য MFA বাধ্যতামূলক করে policy লিখতে, Bool false-এর ফাঁদ এড়াতে, আর CLI থেকে MFA ব্যবহার করতে।

#দুটো প্রশ্ন: তুমি কে, আর সেটা প্রমাণ করতে পারবে?

লেসন ২.১-এ আমরা account-এর identity-গুলো চিনেছি: root user, IAM user আর group। লেসন ২.২-এ দেখেছি একটা request allow হবে কি না, AWS কীভাবে ঠিক করে। দুটো লেসনই একটা জিনিস ধরে নিয়েছে: request-টা কে পাঠাচ্ছে, AWS তা জানে। এই লেসনের কাজ হলো সেই ধরে নেওয়াটা সত্যি করা।

লগইনের মুহূর্তেই AWS ঠিক করে তুমি কে। হামলাকারী যদি তোমার নামে লগইন করতে পারে, তাহলে তোমার সব permission তার হয়ে গেল, দুনিয়ার সেরা policy-ও তখন কিছু করতে পারবে না। তাই এখানে তিনটা বিষয়, তিনটাই লগইন ঘিরে:

1. Root user, account-এর সবচেয়ে ক্ষমতাধর identity, আর তাকে কীভাবে নাগালের বাইরে রাখতে হয়।
2. MFA, যেটা থাকলে চুরি করা password কোনো কাজে আসে না।
3. Password policy, যেটা IAM user-দের password ন্যূনতম কতটা শক্ত হবে ঠিক করে দেয়।

তারপর আরও এক ধাপ: policy-র ভেতরেই MFA চাওয়া, যাতে লগইনের পরেও সবচেয়ে বিপজ্জনক কাজগুলোর আগে নতুন করে MFA যাচাই লাগে।

#Root user

AWS account খোলার সময় তুমি একটা email address আর একটা password দাও। এই জোড়াটাই হয়ে যায় root user: account-এর প্রথম identity, যার প্রতিটা service আর resource-এ পুরো ক্ষমতা আছে, billing আর account-টার ওপরও।

দুটো জিনিস root-কে বাকি সব identity থেকে আলাদা করে:

• কোনো IAM policy তাকে আটকাতে পারে না। Root-এর গায়ে policy লাগানোই যায় না, আর IAM policy-র deny তার ওপর খাটে না। (AWS Organizations-এ service control policy দিয়ে member account-এর root-কে আটকানো যায়, কিন্তু management account-এর root-কে কখনো না। সেটা অধ্যায় ২০-এর বিষয়।)
• সে তোমাকেই বের করে দিতে পারে। Root account-এর email আর password বদলাতে পারে, account বন্ধও করে দিতে পারে। Root যার হাতে, account-ও তার হাতে।

#যে কাজগুলো শুধু root পারে

AWS ইচ্ছা করেই এই তালিকা ছোট রেখেছে। একটা একা account-এ (কোনো organization-এ নেই এমন), শুধু root user পারে:

যা এই তালিকায় নেই: IAM user বানানো, AdministratorAccess লাগানো, কিছু launch করা, CloudTrail পড়া, account-এর নাম বা যোগাযোগের তথ্য বদলানো, কোন Region চালু থাকবে ঠিক করা। এগুলো সব একজন admin identity-ই করে।

#Root user-এর নিয়মগুলো

প্রতিটা নিয়মের পেছনে একটাই চিন্তা: root লাগে খুব কম, তাই root ব্যবহার করা খুব কঠিন করে রাখো।

• শক্ত আর অন্য কোথাও ব্যবহার না করা password, password manager থেকে বানানো। AWS অন্তত ৮ অক্ষর আর চার রকমের মধ্যে তিন রকম অক্ষর চায়, কিন্তু লম্বা একটা passphrase অনেক ভালো।
• MFA, সবসময়। AWS এখন সব রকম account-এর (একা, management আর member) root user-এ MFA বাধ্যতামূলক করেছে। সেট করা না থাকলে লগইনের সময়ই register করতে হয়, বড়জোর ১৪ দিনের ছাড় পাওয়া যায়।
• একটার বেশি MFA device। Root-এর ৮টা পর্যন্ত থাকতে পারে। একটা থাকবে দায়িত্বে থাকা মানুষের হাতের কাছে, আরেকটা সিন্দুকে।
• কোনো access key নয়। Access key হলো program-এর জন্য, আর কোনো program-এর root লাগে না। Root-এর key থাকলে মুছে ফেলো। (কখনো root দিয়ে CLI চালাতেই হলে aws login command স্থায়ী key-এর বদলে অল্প সময়ের credential দেয়।)
• কোম্পানির একটা group email, যেমন aws-root@example.com, কোনো একজনের নিজের inbox না। মানুষ ছুটিতে যায়, চাকরি ছাড়ে।
• গোপন জিনিস ভাগ করে রাখো। কিছু কোম্পানি password রাখে এক team-এর কাছে আর MFA device আরেক team-এর কাছে, যাতে root দিয়ে ঢুকতে দুজনকে একমত হতে হয়।
• প্রতিটা root লগইনে alert। CloudTrail root-এর সব কাজ লিখে রাখে; একটা EventBridge rule root লগইন করলেই security team-কে email পাঠাতে পারে। AWS Config, Security Hub আর Trusted Advisor, তিনটাতেই “root-এর MFA নেই” আর “root-এর access key আছে” যাচাইয়ের ব্যবস্থা আছে।

#অনেক account: centralized root access

যে কোম্পানির ৫০টা AWS account, তার root user-ও ৫০টা, প্রত্যেকটার password, MFA device আর recovery-র পথ আলাদা করে পাহারা দিতে হয়। ২০২৪-এর নভেম্বর থেকে AWS Organizations-এ root access এক জায়গা থেকে চালানো যায়:

• Management account (বা IAM-এর delegated admin) member account-গুলোর root credential মুছে দেয়: password, access key, signing certificate আর MFA। Organization-এ নতুন যে account বানানো হয়, সেগুলোতে শুরু থেকেই root credential থাকে না।
• কোনো member account-এ root-এর কোনো কাজ দরকার হলে admin sts:AssumeRoot দিয়ে একটা privileged root session চালু করে। এটা টেকে সর্বোচ্চ ১৫ মিনিট, আর শুধু একটা কাজের জন্য, যেমন সবাইকে আটকে দেওয়া bucket policy মোছা, বা password recovery চালু করা।
• Credential না থাকলে কেউ ওই member-এর root দিয়ে লগইন করতে পারে না, আর “forgot password”-ও কাজ করে না, কেউ root-এর email inbox দখল করে নিলেও না।

#Multi-factor authentication

Password হলো এমন কিছু যা তুমি জানো। যা জানা যায়, তা কপিও করা যায়: আন্দাজে, phishing-এ, hack হওয়া কোনো site-এ একই password দিয়ে থাকলে, বা কাঁধের ওপর দিয়ে উঁকি মেরে। MFA তার সাথে আরেকটা, ভিন্ন রকমের প্রমাণ যোগ করে:

• যা তুমি জানো: password বা PIN;
• যা তোমার কাছে আছে: authenticator app সহ ফোন, security key;
• যা তুমি নিজে: আঙুলের ছাপ বা মুখ, সাধারণত key রাখা device-টা খুলতে ব্যবহার হয়।

দুটো password মানে এখনো একটাই factor। আসল কথা হলো factor-গুলো ভিন্ন রকমের, তাই একটা চুরি হলেই কাজ হয় না। এক লাইনে মূল লাভ: password চুরি হয়ে গেলেও তোমার account নিরাপদ থাকে।

#৬ অঙ্কের code কীভাবে কাজ করে

Virtual authenticator app আর hardware token ব্যবহার করে TOTP, মানে সময়-ভিত্তিক one-time password:

1. সেটআপ: একবার একটা secret ভাগ করা

   Virtual MFA device লাগানোর সময় AWS একটা random secret বানিয়ে সেটা QR code হিসেবে দেখায়। App সেটা scan করে নেয়। এখন app আর IAM দুজনের কাছেই একই secret, আর এটা আর কখনো কোথাও যায় না। সেটআপ শেষ করতে তুমি পরপর দুটো code টাইপ করো, তাতে প্রমাণ হয় app ঠিকমতো কাজ করছে আর তার ঘড়িও ঠিক আছে।

2. প্রতি ৩০ সেকেন্ডে: একই secret + একই সময় = একই code

   App secret-টার সাথে এখনকার সময় (৩০ সেকেন্ডের ধাপে ভাগ করা) একটা hash function-এ (HMAC) মিশিয়ে শেষের ছয়টা অঙ্ক দেখায়। IAM-ও একই হিসাব করে। দুজনের মধ্যে কিছুই আদানপ্রদান হয় না, তাই ফোন offline থাকলেও চলে।

3. লগইন: মিলিয়ে দেখা

   তুমি code টাইপ করো, IAM নিজেরটা হিসাব করে মিলিয়ে দেখে। ঘড়ি সামান্য এদিক-ওদিক হলে যেন সমস্যা না হয়, তাই এখনকার সময়ের আশেপাশের ছোট একটা window মেনে নেয়। কিন্তু ফোনের ঘড়ি কয়েক মিনিট ভুল হলে code বাতিল হয়; সমাধান হলো automatic network time চালু করা, বা IAM-এ পরপর দুটো code দিয়ে device-টা resync করা।

#MFA device-এর রকমফের

SMS আর কোনো উপায় না। AWS-এ SMS text message দিয়ে নতুন করে MFA চালু করার সুবিধা বন্ধ হয়ে গেছে; text message মাঝপথে ধরা যায়, আর ফোন নম্বরও দখল করা যায়।

#Code-এর চেয়ে passkey কেন ভালো: phishing

৬ অঙ্কের code প্রমাণ করে যে ফোনটা তোমার কাছে আছে, কিন্তু code জানে না তুমি সেটা কোন website-এ টাইপ করছ। একটা নকল লগইন page তোমার password আর code দুটোই চেয়ে নিয়ে কয়েক সেকেন্ডের মধ্যে আসল AWS-এ বসিয়ে দিতে পারে। Passkey বা security key যে challenge-এ sign করে, সেটা আসল website-এর ঠিকানার সাথে বাঁধা। নকল site-এ browser নকল ঠিকানাটাই জানিয়ে দেয়, key-এর তখন sign করার কিছু থাকে না, হামলা ব্যর্থ হয়। Phishing-resistant মানে এটাই, আর এজন্যই AWS সবার আগে passkey আর security key ব্যবহার করতে বলে।

#একাধিক device, আর একটা হারিয়ে গেলে

• প্রতিটা root user আর IAM user ৮টা পর্যন্ত MFA device register করতে পারে, যেকোনো রকম মিলিয়ে। লগইনের জন্য এর যেকোনো একটাই যথেষ্ট।
• IAM user-কে নতুন device যোগ করতে বা সরাতে আগে একটা পুরনো device দিয়ে লগইন করতে হয়।
• IAM user-এর device হারালে: register করা আরেকটা device দিয়ে লগইন করে হারানোটা সরিয়ে দাও। একটাই device থাকলে admin সেটা বন্ধ করে নতুন একটা লাগিয়ে দেয়।
• Root-এর device হারালে: root-এর আরেকটা MFA device ব্যবহার করো। সবগুলো হারালে recovery-র জন্য লাগবে account-এর email inbox আর তার contact phone number, দুটোই। দুটোই হালনাগাদ রাখো, আর দুটো যেন একজন মানুষের হাতে না থাকে।
• যা-ই হোক, হারানো বা চুরি যাওয়া device সাথে সাথে identity থেকে সরিয়ে দাও।

#Account-এর password policy

একটা AWS account-এ password policy একটাই, আর সেটা খাটে IAM user-দের console password-এর ওপর। নিজে কোনো policy না দিলে default policy চলে: ৮ থেকে ১২৮ অক্ষর, বড় হাতের অক্ষর, ছোট হাতের অক্ষর, সংখ্যা আর চিহ্ন, এই চার রকমের অন্তত তিন রকম, account-এর নাম বা email-এর সাথে হুবহু এক হবে না, আর মেয়াদ কখনো শেষ হবে না।

নিজের policy-তে যা ঠিক করা যায়:

যা এটা করে না, আর পরীক্ষায় এগুলোই বেশি আসে:

• এটা root user-এর ওপর খাটে না, access key-এর ওপরও না। কোনো IAM user-এর password-এর মেয়াদ শেষ হলেও তার access key চলতে থাকে।
• Lockout-এর কোনো option নেই: কয়েকবার ভুল password দিলে user-কে আটকে দেওয়া যায় না। আন্দাজ করে ঢোকা ঠেকানোর উপায় হলো লম্বা password আর MFA।
• কমপক্ষে অক্ষরের সংখ্যা বাড়ালেও আজই কাউকে password বদলাতে বাধ্য করা হয় না; নিয়মটা খাটে পরের বার বদলানোর সময়।

#Policy-র ভেতরে MFA চাওয়া

MFA দিয়ে লগইন মানে দরজাটা সুরক্ষিত। কিন্তু কিছু কাজ এত বিপজ্জনক যে ঠিক ওই কাজের আগেই নতুন করে MFA যাচাই চাও: production-এর instance terminate করা, bucket মুছে ফেলা, IAM বদলানো। এর জন্য policy-তে MFA নিয়ে condition key আছে (policy-র Condition অংশটা লেসন ২.১-এ বোঝানো হয়েছে)।

#aws:MultiFactorAuthPresent

পরীক্ষার পরিচিত প্রশ্ন: “কীভাবে নিশ্চিত করবে যে MFA ছাড়া কেউ S3 bucket মুছতে পারবে না?” উত্তর: এমন একটা policy, যার Condition-এ aws:MultiFactorAuthPresent-এর মান "true"।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DeleteOnlyWithMfa",
      "Effect": "Allow",
      "Action": ["s3:DeleteBucket", "ec2:TerminateInstances"],
      "Resource": "*",
      "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
    }
  ]
}

ঠিকভাবে ব্যবহার করতে একটা খুঁটিনাটি জানতে হবে: key-টা request-এ আদৌ কখন থাকে?

• Console লগইন: console আড়ালে অস্থায়ী credential দিয়ে কাজ করে। Key থাকে: MFA দিয়ে লগইন করলে true, না করলে false।
• STS থেকে নেওয়া অস্থায়ী credential (MFA serial আর code দিয়ে GetSessionToken বা AssumeRole call করা): key থাকে, মান true।
• দীর্ঘমেয়াদি access key (সাধারণ access key দিয়ে CLI বা SDK): key-টা থাকেই না। false না, একদম অনুপস্থিত।

এই একটা পার্থক্যই ঠিক করে দেয় condition লেখার প্রতিটা ধরন কেমন আচরণ করবে:

Bool false দিয়ে লেখা Deny দেখতে ঠিকই লাগে, কিন্তু সব দীর্ঘমেয়াদি access key সোজা ঢুকে যায়, কারণ যে key নেই তার condition মেলে না। নিয়মটা যদি হয় “MFA ছাড়া কিছুই না”, তাহলে AWS বলে Deny আর BoolIfExists false লেখো। Console-এর visual editor-এ “MFA required” বেছে নিলে লেখা হয় BoolIfExists true দিয়ে Allow, যেটা console-এ MFA চায় কিন্তু access key-এর বেলায় চায় না।

#MFA policy থাকা অবস্থায় CLI চালানো

শুধু access key আছে এমন user condition পূরণ করতে পারে না। তাই আগে key আর MFA code দিয়ে অস্থায়ী credential নিতে হয়:

aws sts get-session-token \
  --serial-number arn:aws:iam::111122223333:mfa/sofia-phone \
  --token-code 482913

STS ফেরত দেয় একটা access key, secret key আর session token, যেগুলোতে লেখা থাকে MFA যাচাই হয়েছে। Default মেয়াদ ১২ ঘণ্টা (IAM user-এর জন্য ১৫ মিনিট থেকে ৩৬ ঘণ্টা)। এগুলো CLI profile বা environment variable-এ বসালেই policy সন্তুষ্ট। খেয়াল রেখো: এটা চলে virtual আর hardware TOTP device দিয়ে; passkey বা security key দিয়ে এভাবে STS-এ MFA দেওয়া যায় না, ওগুলোর জন্য আছে নতুন aws login command।

#aws:MultiFactorAuthAge

শুধু “MFA হয়েছিল” যথেষ্ট না-ও হতে পারে; হয়তো চাও “MFA হয়েছে একটু আগেই”। aws:MultiFactorAuthAge-এ থাকে MFA যাচাইয়ের পর কত সেকেন্ড পার হয়েছে:

"Condition": { "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" } }

এটা থাকলে পাঁচ ঘণ্টা আগে MFA দেওয়া session দিয়ে instance terminate করা যায় না; user নতুন code দিয়ে নতুন session নেয়। Present key-এর মতোই, দীর্ঘমেয়াদি key-তে এটাও থাকে না।

#Cross-account role-এ MFA

এক account-এর user যখন আরেক account-এর role assume করে (পুরো গল্প লেসন ২.৪-এ), তখন যে account-এর role, সে role-এর trust policy-তে MFA চাইতে পারে:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
  "Action": "sts:AssumeRole",
  "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
}

User তার MFA serial আর code AssumeRole call-এর সাথেই পাঠায়। MFA যাচাই হয় একবারই, role assume করার সময়; role-এর permission policy-তে আলাদা MFA condition লাগে না। (এখানে arn:aws:iam::444455556666:root মানে “অন্য account-টা”, তার root user লগইন করছে এমন না।)

#একটু আগাম দেখা: S3 MFA Delete

S3-এর নিজস্ব, আলাদা একটা MFA ব্যবস্থা আছে। Versioning চালু আছে এমন bucket-এ MFA Delete চালু থাকলে, কোনো object version চিরতরে মুছতে বা versioning-এর অবস্থা বদলাতে request-এর সাথে MFA code দিতে হয়। এটা চালু করতে পারে শুধু bucket-এর মালিক account-এর root user, আর শুধু CLI বা API দিয়ে। Versioning-এর সাথে এটা অধ্যায় ১০-এ পড়বে।

#System design-এ কীভাবে কাজে লাগে

• মানুষ লগইন করে MFA সহ IAM Identity Center দিয়ে, দীর্ঘমেয়াদি key সহ IAM user দিয়ে না (অধ্যায় ২০)। যেখানে এখনো IAM user আছে, সবার MFA চালু, আর password policy সেট করা।
• Root হলো জরুরি অবস্থার identity। শক্ত password, আলাদা দুজনের হাতে দুটো MFA device, কোনো access key নেই, group email, প্রতিটা লগইনে alert, আর কখন root ব্যবহার করা যাবে তার লিখিত নিয়ম।
• অনেক account থাকলে root access এক জায়গা থেকে চালাও আর member-দের root credential মুছে দাও।
• ধ্বংসাত্মক কাজে MFA লাগবে: মানুষের role-গুলোতে TerminateInstances, DeleteBucket আর IAM বদলের ওপর Deny + BoolIfExists পাহারা। কিন্তু application যে role ব্যবহার করে সেখানে এটা দিও না; ওদের MFA নেই, সব ভেঙে পড়বে।
• আগে phishing-resistant: admin আর root-এর জন্য passkey আর security key; virtual app সাময়িক ব্যবস্থা হিসেবে।
• নিয়মিত যাচাই করো: root-এর MFA, root-এর access key আর MFA ছাড়া IAM user খুঁজতে AWS Config rule আর Security Hub control, আর পুরো account একনজরে দেখতে credentials report (লেসন ২.৪)।

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

তোমার account-এর password policy পড়ো (error এলে বুঝবে default policy চলছে):

aws iam get-account-password-policy

আরও শক্ত একটা policy সেট করো:

aws iam update-account-password-policy \
  --minimum-password-length 14 \
  --require-uppercase-characters --require-lowercase-characters \
  --require-numbers --require-symbols \
  --max-password-age 90 --password-reuse-prevention 5 \
  --allow-users-to-change-password

দেখো root-এর MFA আছে (AccountMFAEnabled: 1) আর কোনো access key নেই (AccountAccessKeysPresent: 0):

aws iam get-account-summary \
  --query 'SummaryMap.{RootMfa: AccountMFAEnabled, RootKeys: AccountAccessKeysPresent}'

নিজের MFA device-এর তালিকা দেখো, তারপর CLI-এর জন্য MFA-চিহ্নিত অস্থায়ী credential নাও:

aws iam list-mfa-devices
aws sts get-session-token --serial-number <your device ARN> --token-code <6 digits>

Console-এ যাও IAM → Users → তোমার user → Security credentials → Assign MFA device, আর একটা দ্বিতীয় device যোগ করো, যাতে ফোন হারালেও কখনো আটকে না যাও।

#সারসংক্ষেপ

মূল কথাগুলো

• Root user (account খোলার email + password) সব পারে, আর IAM policy তাকে আটকায় না। ব্যবহার করবে শুধু root-এর কাজে: root-এর email বা password বদলানো, account বন্ধ করা, আটকে যাওয়া admin-কে ফেরানো, billing-এর কিছু কাজ, RI Marketplace-এ seller হওয়া, S3 MFA Delete, আর সবাইকে deny করা bucket বা queue policy খোলা।
• Root-এর নিয়ম: শক্ত password, MFA (এখন সব রকম account-এ বাধ্যতামূলক), একাধিক MFA device, কোনো access key নয়, group email, লগইনে alert। অনেক account থাকলে centralized root access চালু করে member-দের root credential মুছে দাও; sts:AssumeRoot দেয় ১৫ মিনিটের, একটা কাজে সীমাবদ্ধ session।
• MFA = যা তুমি জানো + যা তোমার কাছে আছে (বা যা তুমি নিজে)। শুধু চুরি করা password দিয়ে আর account খোলে না।
• Device-এর ধরন: passkey আর security key (FIDO2, phishing-resistant, এক key-এ অনেক user), virtual authenticator app (TOTP), hardware TOTP token। SMS আর চলে না। প্রতি user-এ ৮টা পর্যন্ত device; যেকোনো একটা দিয়েই লগইন।
• Device হারালে: IAM user → আরেকটা device বা admin; root → আরেকটা device, নইলে email আর ফোন দিয়ে recovery।
• Password policy: দৈর্ঘ্য ৬–১২৮, অক্ষরের রকম, মেয়াদ ১–১০৯৫ দিন (সাথে সাথে খাটে), পুনর্ব্যবহার ১–২৪, admin reset, নিজে বদলানোর অনুমতি। Root-এর জন্য না, access key-এর জন্য না, lockout নেই।
• aws:MultiFactorAuthPresent: অস্থায়ী credential-এ থাকে, দীর্ঘমেয়াদি key-তে থাকেই না। Allow + Bool true মানে MFA লাগবে; Deny + BoolIfExists false MFA ছাড়া সব আটকায়; Deny + Bool false access key ঢুকতে দেয়।
• MFA সহ CLI: device serial আর code দিয়ে aws sts get-session-token। aws:MultiFactorAuthAge দিয়ে সাম্প্রতিক MFA চাওয়া যায়। Cross-account role-এ MFA চাইতে হয় trust policy-তে।

নিজেকে যাচাই করো: MFA, Password Policy আর Root-কে সুরক্ষিত রাখা৩৩টি প্রশ্ন