AWS Shared Responsibility Model (যৌথ দায়িত্ব মডেল)-এর আওতায়, যদিও AWS দায়িত্ব পালন করে "Security OF the Cloud" (শারীরিক ডেটা সেন্টার, হোস্ট হার্ডওয়্যার, হাইপারভাইজার)-এর জন্য, গ্রাহক কিন্তু অবিভক্তভাবে দায়বদ্ধ থাকে "Security IN the Cloud"—বিশেষ করে পরিচিতি নিয়ন্ত্রণ (identity governance), ক্রেডেনশিয়াল স্বাস্থ্যবিধি এবং অ্যাক্সেস নিয়ন্ত্রণের জন্য। একটি অরক্ষিত AWS Root অ্যাকাউন্ট বা সুবিধাভোগী IAM ক্রেডেনশিয়াল হাতছাড়া হলে হামলাকারীরা হাজার হাজার ডলারের অবৈধ GPU ক্রিপ্টো-মাইনিং ইনস্ট্যান্স চালু করতে পারে, সংবেদনশীল S3 ডেটা লেক হাতিয়ে নিতে পারে অথবা ক্ষতিকর র্যানসমওয়্যার দিয়ে সবকিছু ধ্বংস করে ফেলতে পারে।
সমস্ত প্রশাসনিক কনসোল ব্যবহারকারীর জন্য MFA বাধ্যতামূলক এবং AWS Root অ্যাকাউন্টের ক্ষেত্রে এটি কোনোভাবেই আপসযোগ্য নয়।
AWS প্রতি অ্যাকাউন্টে সর্বোচ্চ ৮টি পৃথক FIDO2 এবং ভার্চুয়াল TOTP টোকেন নিবন্ধনের সুবিধা দেয়, যা একক ব্যর্থতার ঝুঁকি নির্মূল করে।
গ্লোবাল IAM কন্ডিশনাল ডিনাই পলিসি সক্রিয় MFA প্রমাণীকরণ সম্পন্ন না হওয়া পর্যন্ত সমস্ত অননুমোদিত API কল ব্লক করে দেয়।
ক্লাউড কমপ্লায়েন্স বেসলাইন: CIS বেঞ্চমার্ক ও নিয়ন্ত্রক ফ্রেমওয়ার্ক
আপনার ইঞ্জিনিয়ারিং প্রতিষ্ঠান SOC 2 Type II প্রত্যয়ন, ISO 27001 সার্টিফিকেশন, PCI DSS 4.0 মানদণ্ড অর্জন করতে চাক অথবা AWS Well-Architected Security Pillar অনুসরণ করুক না কেন, IAM পরিচিতিগুলোর জন্য MFA বাস্তবায়ন একটি মৌলিক ও বাধ্যতামূলক শর্ত:
| স্ট্যান্ডার্ড / কমপ্লায়েন্স মানদণ্ড | কন্ট্রোল স্পেসিফিকেশন | তীব্রতা / বাধ্যবাধকতা | অডিট ভ্যালিডেশন মেকানিজম |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | লেভেল ১ (বাধ্যতামূলক) | AWS Security Hub / Prowler স্বয়ংক্রিয় মূল্যায়ন |
| PCI DSS 4.0 | Requirement 8.4.2 | বাধ্যতামূলক | কার্ডহোল্ডার ডেটা এনভায়রনমেন্ট (CDE) কনসোল ও API অডিট |
| SOC 2 Type II (ট্রাস্ট ক্রাইটেরিয়া) | CC6.1 / CC6.2 | মূল নিয়ন্ত্রণ (Key Control) | IAM ক্রেডেনশিয়াল রিপোর্টের স্বাধীন CPA নিরীক্ষা |
| AWS বাধ্যতামূলক MFA রোলআউট | AWS 2024–2026 Policy | প্ল্যাটফর্ম বাধ্যবাধকতা | MFA নিবন্ধন সম্পন্ন না হওয়া পর্যন্ত Root লগইন গেটওয়ে ব্লক |
AWS Root অ্যাকাউন্ট সুরক্ষিত করার চূড়ান্ত আবশ্যকতা
একটি AWS অ্যাকাউন্টের সীমানার মধ্যে Root অ্যাকাউন্ট হলো অ্যাকাউন্ট তৈরির সময় সৃষ্ট সর্বময় ক্ষমতার অধিকারী সত্ত্বা। সাধারণ IAM রোল বা ব্যবহারকারীর মতো, Root অ্যাকাউন্টের কার্যাবলীকে IAM আইডেন্টিটি-ভিত্তিক পলিসি অথবা স্ট্যান্ডঅ্যালোন অ্যাকাউন্টের Service Control Policies দ্বারা সীমাবদ্ধ করা যায় না।
একটি আপসকৃত Root অ্যাকাউন্টের ক্ষয়ক্ষতির মারাত্মক পরিধি:
- অপরিবর্তনীয় অ্যাকাউন্ট বন্ধকরণ: আক্রমণকারীরা "Close Account" বাটনে ক্লিক করে স্থায়ী অবকাঠামো ধ্বংসের সময়সূচী নির্ধারণ করতে পারে।
- বিলিং ও আর্থিক ছিনতাই: ইনভয়েস রি-রুট করা, করপোরেট বিলিং পেমেন্ট কার্ড পরিবর্তন করা এবং অবৈধ ক্রিপ্টোকারেন্সি মাইনিংয়ের জন্য ৩০টিরও বেশি AWS অঞ্চলে শত শত GPU স্পট ইনস্ট্যান্স স্থাপন করা।
- AWS Organizations কাঠামো ছিন্ন করা: প্রাতিষ্ঠানিক কমপ্লায়েন্স মনিটরিং ভেঙে দিতে ম্যানেজমেন্ট ট্রি থেকে সদস্য অ্যাকাউন্টগুলোকে বিচ্ছিন্ন করে দেওয়া।
- প্রাথমিক নিরাপত্তা যোগাযোগ পরিবর্তন: Root ইমেইল এবং টেলিফোন নম্বর পরিবর্তন করে ফেলা, যা প্রাতিষ্ঠানিক AWS সাপোর্ট হস্তক্ষেপের পথ চিরতরে রুদ্ধ করে দেয়।
- জিরো Root অ্যাক্সেস কী: Root অ্যাকাউন্টের জন্য কোনো অ্যাক্সেস কী বিদ্যমান নেই তা নিশ্চিত করতে IAM Credential Reports অডিট করুন। যদি থাকে, অবিলম্বে তা মুছে ফেলুন।
- ডুয়াল-কাস্টডি পাসওয়ার্ড ভল্টিং: ৩২+ অক্ষরের একটি জটিল ও এলোমেলো পাসওয়ার্ড তৈরি করুন, পাসফ্রেজটি CISO এবং জেনারেল কাউন্সেল (আইনি কর্মকর্তা)-এর মধ্যে ভাগ করুন এবং টুকরোগুলো শারীরিক অগ্নিনির্বাপক ভল্টে সুরক্ষিত রাখুন।
- মাল্টি-ডিভাইস রিডান্ড্যান্সি (৮টি ডিভাইস পর্যন্ত): অন্তত দুটি ফিজিক্যাল FIDO2 হার্ডওয়্যার কী (YubiKey) এবং একটি অফলাইন, কোল্ড-স্টোর করা ভার্চুয়াল TOTP ফলব্যাক ডিভাইস নিবন্ধন করুন।
MFA নির্বাচনের ম্যাট্রিক্স: ভার্চুয়াল TOTP বনাম হার্ডওয়্যার FIDO2 (YubiKey)
AWS প্রধান তিনটি MFA ডিভাইস ক্লাস সমর্থন করে। ক্লাউড আর্কিটেক্টদের উচিত সম্ভাব্য হুমকি মডেল এবং প্রশাসনিক সুবিধার স্তরের ওপর ভিত্তি করে ডিভাইস নির্বাচন করা:
ভার্চুয়াল TOTP অ্যাপ্লিকেশন
স্ট্যান্ডার্ড RFC 6238 টোকেন (Google Authenticator, 1Password, 2FA-Tool)। দ্রুত অনবোর্ডিং, সংগ্রহের কোনো জটিলতা নেই। সাধারণ ডেভেলপারদের জন্য আদর্শ।
YubiKey 5 সিরিজ
ফিশিং-প্রতিরোধী ক্রিপ্টোগ্রাফি। অরিজিন-বাউন্ড পাবলিক-কী অ্যাসারশন রিভার্স-প্রক্সি ফিশিং কিট প্রতিহত করে। Root এবং অ্যাডমিনিস্ট্রেটরদের জন্য বাধ্যতামূলক।
Gemalto / Thales কার্ড
স্ব-চালিত, LCD স্ক্রিনযুক্ত এয়ার-গ্যাপড TOTP কার্ড। উচ্চ নিরাপত্তাবিশিষ্ট সুরক্ষিত সুবিধা (SCIFs)-র জন্য অপরিহার্য, যেখানে স্মার্টফোন এবং USB ড্রাইভ সম্পূর্ণ নিষিদ্ধ।
এন্টারপ্রাইজ হার্ডওয়্যার MFA FIPS 140-2 Level 3 ও ডুয়াল-কাস্টডি সেফ প্রোটোকল:
Fortune 500 কোম্পানি এবং প্রতিরক্ষা চুক্তিভিত্তিক সংস্থাগুলোর জন্য Root অ্যাকাউন্ট সুরক্ষার অংশ হিসেবে FIPS 140-2 Level 3 সার্টিফাইড ডেডিকেটেড হার্ডওয়্যার কি ফোব (যেমন SafeNet/Gemalto IDPrime fobs) ব্যবহার বাধ্যতামূলক। স্মার্টফোন অ্যাপের বিপরীতে, এই ফিজিক্যাল ফোবগুলোতে কোনো ওয়্যারলেস ইন্টারফেস বা ব্লুটুথ থাকে না এবং কোনো মোবাইল স্পাইওয়্যারের মাধ্যমেও এগুলো দখল করা যায় না।
ফিজিক্যাল ডুয়াল-কাস্টডি গভর্ন্যান্স: এন্টারপ্রাইজ ডেটা সেন্টার প্রোটোকল অনুযায়ী, Root অ্যাক্সেসের জন্য দুজন ভিন্ন ব্যক্তির উপস্থিতি প্রয়োজন: একজন হেফাজতকারীর কাছে থাকে মাস্টার ইমেইল ক্রেডেনশিয়াল, আর একজন স্বাধীন নিরাপত্তা কর্মকর্তার কাছে থাকে এমন এক সুরক্ষিত লকারের চাবি যাতে Root হার্ডওয়্যার টোকেনটি সংরক্ষিত। কেউই একতরফাভাবে AWS Root অ্যাকাউন্ট অ্যাক্সেস করতে পারেন না।
IAM পলিসির মাধ্যমে MFA প্রয়োগ (JSON বাস্তবায়ন)
নিরাপত্তা বেসলাইন কর্মীদের স্বেচ্ছাধীন আচরণের ওপর ছেড়ে দেওয়া যায় না। ক্লাউড প্রশাসনে পলিসি-স্তরের প্রয়োগ প্রয়োজন: সক্রিয় MFA প্রমাণীকরণ ছাড়া ব্যবহারকারীদের নিজস্ব MFA ডিভাইস স্ব-নিবন্ধন করার ক্ষমতা ছাড়া সমস্ত AWS API এবং কনসোল অ্যাক্সেস পদ্ধতিগতভাবে নিষিদ্ধ করতে হবে।
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/${aws:username}"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "BlockAllAccessUnlessMFAAuthenticated",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"iam:GetUser"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
Statement 4 গ্লোবাল কন্ডিশন কী "aws:MultiFactorAuthPresent": "false" একটি স্পষ্ট Deny-এর মাধ্যমে মূল্যায়ন করে। যেহেতু স্পষ্ট Deny যেকোনো Allow স্টেটমেন্টের ওপর প্রাধান্য পায়, তাই নন-MFA সেশনগুলো সমস্ত AWS API-তে সাথে সাথে ব্লক হয়ে যায় এবং ব্যবহারকারী সরাসরি স্ব-নিবন্ধন স্ক্রিনে পৌঁছাতে বাধ্য হন।
AWS CLI ও SDK MFA প্রমাণীকরণ: STS অস্থায়ী সেশন টোকেন
যখন IAM পলিসিতে MFA বাধ্যতামূলক করা হয়, তখন যেসব প্রকৌশলী aws s3 ls চালান বা Terraform কোড এক্সিকিউট করেন তারা AccessDenied ত্রুটির সম্মুখীন হবেন। দীর্ঘমেয়াদী অ্যাক্সেস কীগুলো ইন্টারঅ্যাক্টিভভাবে OTP চাইতে পারে না।
ইঞ্জিনিয়ারদের অবশ্যই AWS STS (Security Token Service) ব্যবহার করে দীর্ঘমেয়াদী কী + একটি ৬-সংখ্যার TOTP বিনিময়ে ক্ষণস্থায়ী ক্রেডেনশিয়াল সংগ্রহ করতে হবে:
অটোমেশন স্ক্রিপ্ট (aws-mfa-session.sh):
টোকেন সংগ্রহ স্বয়ংক্রিয় করতে আপনার স্থানীয় পরিবেশে (~/.aws/aws-mfa-session.sh) এই সহায়ক স্ক্রিপ্টটি রাখুন:
# Exchange AWS Long-Term Keys + MFA Code for STS Session Token
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Enter 6-digit 2FA OTP Code: "
read -r TOKEN_CODE
SESSION_JSON=$(aws sts get-session-token \
--serial-number "$MFA_ARN" \
--token-code "$TOKEN_CODE" \
--duration-seconds 43200 \
--output json)
if [ $? -eq 0 ]; then
export AWS_ACCESS_KEY_ID=$(echo "$SESSION_JSON" | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo "$SESSION_JSON" | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo "$SESSION_JSON" | jq -r '.Credentials.SessionToken')
echo "✅ Authenticated! Temporary session exported (Valid for 12 hours)."
else
echo "❌ Authentication failed. Check token code or device time drift."
fi
MFA শর্তে ক্রস-অ্যাকাউন্ট AssumeRole
এন্টারপ্রাইজ মাল্টি-অ্যাকাউন্ট আর্কিটেকচারে, বিশেষ সুবিধাপ্রাপ্ত প্রকৌশলীরা সাধারণত একটি কেন্দ্রীভূত Identity অ্যাকাউন্টে প্রমাণীকরণ করেন এবং sts:AssumeRole-এর মাধ্যমে লক্ষ্য অ্যাকাউন্টে (Production, Staging) প্রবেশ করেন। কোনো ফাঁস হওয়া ক্রেডেনশিয়ালের মাধ্যমে যেন প্রোডাকশন অ্যাকাউন্টের অ্যাক্সেস হাইজ্যাক না হয়, সেজন্য টার্গেট রোলের ট্রাস্ট রিলেশনশিপে অবশ্যই MFA শর্ত প্রয়োগ করতে হবে:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
এই আর্কিটেকচারাল প্যাটার্ন নিশ্চিত করে যে আক্রমণকারী যদি কেন্দ্রীয় আইডেন্টিটি অ্যাকাউন্টের ক্রেডেনশিয়াল হাতিয়েও নেয়, তবুও MFA সন্তুষ্ট না করে টার্গেট রোল গ্রহণ করার চেষ্টা করলে সিকিউরিটি টোকেন বাউন্ডারিতে সাথে সাথে AccessDenied ত্রুটি ঘটবে।
CloudTrail অডিটিং ও EventBridge রিয়েল-টাইম অ্যালার্ট
স্বয়ংক্রিয় কমপ্লায়েন্স যাচাইকরণের জন্য কোনো ব্যবহারকারী মাল্টি-ফ্যাক্টর প্রমাণীকরণ ছাড়া AWS ম্যানেজমেন্ট কনসোলে প্রবেশ করলেই তা তাৎক্ষণিকভাবে সনাক্ত করা প্রয়োজন। AWS CloudTrail ইভেন্টগুলো সংগ্রহ করে Amazon EventBridge-এর মাধ্যমে রাউট করার মাধ্যমে SecOps টিমগুলো রিয়েল-টাইম অ্যালার্ট পেতে পারে:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
ইভেন্ট প্রাপ্তির সাথে সাথে EventBridge সিকিউরিটি অপারেশনস সেন্টারের (SOC) অন-কল পেজারে Amazon SNS নোটিফিকেশন পাঠায় অথবা একটি AWS Lambda ফাংশন চালু করে যা সক্রিয় IAM ব্যবহারকারী সেশনটি তাৎক্ষণিকভাবে প্রত্যাহার করে দেয়।
মাল্টি-অ্যাকাউন্ট গভর্ন্যান্স: AWS Organizations ও IAM Identity Center
ল্যান্ডিং জোনের আওতায় ডজন ডজন বা শত শত AWS অ্যাকাউন্ট পরিচালনাকারী এন্টারপ্রাইজ পরিবেশে প্রতিটি অ্যাকাউন্টে আলাদা IAM ব্যবহারকারী তৈরি করা একটি অ্যান্টি-প্যাটার্ন (ত্রুটিপূর্ণ নকশা)।
কেন্দ্রীভূত পরিচিতি ফেডারেশন:
আপনার নির্ধারিত Management অ্যাকাউন্টে AWS IAM Identity Center (পূর্বে AWS SSO) স্থাপন করুন। করপোরেট IdP (Okta, Microsoft Entra ID, PingFederate)-এর সাথে পরিচিতি ফেডারেট করুন। IdP স্তরে করপোরেট MFA প্রয়োগ করুন এবং সদস্য অ্যাকাউন্টগুলোতে Root অ্যাকশন প্রতিরোধ করতে অর্গানাইজেশন রূটে Service Control Policies (SCPs) সংযুক্ত করুন:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
প্রোডাকশন-গ্রেড SCP: সমস্ত সদস্য অ্যাকাউন্টে MFA শর্ত কার্যকর করা
বৃহৎ সংস্থায় কোনো একক অ্যাকাউন্টের অ্যাডমিনিস্ট্রেটর অনিচ্ছাকৃতভাবে অতিরিক্ত সুবিধা প্রদান করে ফেলতে পারেন। Organization Root অথবা Organizational Unit (OU) স্তরে একটি Service Control Policy (SCP) সংযুক্ত করে ক্লাউড গভর্ন্যান্স টিম একটি অপরিবর্তনীয় সুরক্ষা প্রাচীর গড়ে তুলতে পারে: সক্রিয় MFA সেশন ছাড়া উচ্চ-ঝুঁকিপূর্ণ API কলগুলো নিঃশর্তভাবে বাতিল হয়ে যাবে:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCriticalActionsWithoutMFA",
"Effect": "Deny",
"Action": [
"iam:CreateAccessKey",
"iam:CreateLoginProfile",
"s3:DeleteBucket",
"kms:ScheduleKeyDeletion",
"ec2:TerminateInstances"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
রোল চেইনিং ও STS টোকেনের জীবনকাল সংক্রান্ত সীমাবদ্ধতা:
যখন IAM পরিচয়গুলো কোনো মধ্যবর্তী রোল গ্রহণ করে এবং পরবর্তীতে দ্বিতীয় কোনো রোল গ্রহণ করে ("role chaining"), তখন AWS STS ডাউনস্ট্রিম সেশন টোকেন থেকে মূল aws:MultiFactorAuthPresent প্রসঙ্গটি সরিয়ে ফেলে! তাই ক্রস-অ্যাকাউন্ট পাইপলাইনে কঠোর কমপ্লায়েন্স বজায় রাখতে একাধিক মধ্যবর্তী IAM রোল চেইনিং না করে সরাসরি প্রমাণীকৃত IAM Identity Center সেশন থেকে রোল-অ্যাসাম্পশন গ্রাফ ডিজাইন করুন।
দুর্যোগ পরবর্তী পুনরুদ্ধার: Root MFA ডিভাইস হারানোর প্রোটোকল
কোনো দুর্ঘটনায় যদি সমস্ত নিবন্ধিত Root MFA হার্ডওয়্যার টোকেন এবং ভার্চুয়াল ডিভাইস ধ্বংস হয়ে যায় তবে কী হবে?
অফিসিয়াল আউট-অফ-ব্যান্ড রিকভারি ধাপ:
- Root সাইন-ইন শুরু করুন: AWS কনসোলে Root অ্যাকাউন্টের ইমেইল এবং মাস্টার পাসওয়ার্ড দিন।
- Troubleshoot MFA নির্বাচন করুন: MFA প্রম্পটে "Troubleshoot MFA" ক্লিক করুন।
- প্রাথমিক ইমেইল যাচাইকরণ: AWS প্রাথমিক Root ইমেইল ঠিকানায় একটি সময়-সীমিত যাচাইকরণ লিঙ্ক পাঠাবে। ইমেইল চ্যালেঞ্জটি যাচাই করুন।
- স্বয়ংক্রিয় ভয়েস কল যাচাই: "Call me now" ক্লিক করুন। AWS-এর স্বয়ংক্রিয় যাচাইকরণ সিস্টেম নিবন্ধিত প্রাথমিক ফোন নম্বরে কল করবে এবং একটি ৬-সংখ্যার পিন (PIN) বলবে।
আপনার প্রতিষ্ঠান যদি ফোন নম্বর পরিবর্তন করে থাকে বা সংশ্লিষ্ট ব্যক্তি AWS অ্যাকাউন্ট সেটিংস আপডেট না করেই প্রতিষ্ঠান ত্যাগ করেন, তবে এই স্বয়ংক্রিয় পুনরুদ্ধার ব্যর্থ হবে। তখন ম্যানুয়ালি সমাধান করতে AWS Trust & Safety-এর কাছে প্রতিষ্ঠানের নোটারি করা আইনি নিবন্ধন নথি জমা দিতে হবে, যার পর্যালোচনা সম্পন্ন হতে ৩ থেকে ৭ কার্যদিবস পর্যন্ত সময় লেগে যেতে পারে।
এন্টারপ্রাইজ ক্লাউড আর্কিটেক্ট FAQ
AWS Root MFA টোকেন কি DevOps টিমের সদস্যদের মাঝে ভাগাভাগি করা যায়? ▼
সম্পূর্ণ নিষিদ্ধ। Root MFA ক্রেডেনশিয়াল শেয়ার করলে তা সমস্ত কমপ্লায়েন্স অডিটে (SOC 2, ISO 27001) ব্যর্থ হবে। রুটিনমাফিক প্রশাসনিক কাজ অবশ্যই ব্যক্তিগত জবাবদিহিতাসহ IAM Identity Center রোলের মাধ্যমে সম্পন্ন করতে হবে। Root ক্রেডেনশিয়াল কেবল ভয়াবহ জরুরি পরিস্থিতিতে "ব্রেক-গ্লাস" হিসেবে ব্যবহারের জন্য ফিজিক্যাল ডুয়াল-কাস্টডি লকারে তালাবদ্ধ রাখতে হবে।
aws:MultiFactorAuthAge কন্ডিশন কী কীভাবে নিরাপত্তা বৃদ্ধি করে? ▼
এই কী-টি সেশনের সতেজতা (freshness) নিশ্চিত করে। "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} কনফিগার করলে পূর্ববর্তী ৩,৬০০ সেকেন্ডের (১ ঘণ্টা) মধ্যে MFA টোকেন উপস্থাপন করা বাধ্যতামূলক হয়। সেশনটি যদি এর চেয়ে পুরানো হয়, তবে উচ্চ-ঝুঁকিপূর্ণ কাজ (যেমন RDS ক্লাস্টার ডিলিট করা) ব্লক হয়ে যাবে, যা দীর্ঘস্থায়ী সেশন হাইজ্যাকিং থেকে রক্ষা করে।
আমি কি AWS Virtual MFA সেটআপ করতে 2FA-Tool অনলাইন প্রমাণীকরণকারী ব্যবহার করতে পারি? ▼
হ্যাঁ। AWS Virtual MFA সম্পূর্ণভাবে RFC 6238 TOTP স্পেসিফিকেশন মেনে চলে (HMAC-SHA1, ৩০-সেকেন্ডের ব্যবধান, ৬-সংখ্যা)। নিবন্ধনের জন্য প্রয়োজনীয় পরপর দুটি প্রমাণীকরণ কোড তৈরি করতে আপনি Base32 সিক্রেট স্ট্রিংটি 2FA-Tool.com-এ ইনপুট করতে পারেন, যা আপনার ব্রাউজারে শতভাগ স্থানীয়ভাবে জেনারেট হয়।
নিরাপদে এন্টারপ্রাইজ TOTP টোকেন পরীক্ষা করুন
W3C Web Crypto API দিয়ে তাৎক্ষণিকভাবে স্ট্যান্ডার্ড RFC 6238 TOTP যাচাইকরণ কোড তৈরি করুন। কোনো সার্ভার কল নেই, সম্পূর্ণ মেমরি সুরক্ষা এবং শূন্য ডেটা ফাঁসের নিশ্চয়তা।