AWS Academy Cloud Foundations (Module 04)

অনেকের মধ্যেই একটি ভুল ধারণা কাজ করে—"আমরা তো AWS ক্লাউডে চলে এসেছি, এখন সিকিউরিটির সব দায়িত্ব নিশ্চয়ই AWS-এর!"

বাস্তবতা কিন্তু একেবারেই আলাদা। ক্লাউডে কাজ করার সময় সিকিউরিটি কখনোই একক কোনো পক্ষের দায়িত্ব নয়। আপনি যদি একটি ভুল কনফিগারেশন করে রাখেন কিংবা আপনার অ্যাপ্লিকেশনের সার্ভার অ্যাক্সেস কি (Access Key) অসাবধানতাবশত গিটহাবে পুশ করে দেন, তবে কয়েক ঘণ্টার মধ্যে আপনার পুরো অ্যাকাউন্ট হ্যাক হতে পারে, লাখ লাখ টাকার অপ্রত্যাশিত বিল চলে আসতে পারে কিংবা মূল্যবান ডেটা চিরতরে হারিয়ে যেতে পারে।

আজকের এই ব্লগে আমরা AWS Academy Cloud Foundations কোর্সের অন্যতম গুরুত্বপূর্ণ অধ্যায় Module 4: AWS Cloud Security-এর প্রতিটি খুঁটিনাটি বিষয় একদম সহজ ও সাবলীল ভাষায় আলোচনা করব। আপনি যদি সদ্য ক্লাউড নিয়ে পড়াশোনা শুরু করে থাকেন কিংবা AWS Certified Cloud Practitioner (CLF-C02) পরীক্ষার জন্য নিরেট প্রস্তুতি নিতে চান, তবে এই পোস্টটি হবে আপনার জন্য একটি স্বয়ংসম্পূর্ণ মাস্টারক্লাস গাইড।

---

১. AWS Shared Responsibility Model (যৌথ দায়িত্বের নীতি)

AWS ক্লাউড সিকিউরিটির একদম প্রথম ও প্রধান ভিত্তিপ্রস্তর হলো Shared Responsibility Model। এর সোজা অর্থ হলো—ক্লাউডের নিরাপত্তার ভার AWS এবং কাস্টমার (Customer) উভয়ের মধ্যেই সুনির্দিষ্টভাবে ভাগ করা থাকে।

সহজ একটি বাস্তব উপমা দেওয়া যাক: মনে করুন আপনি একটি বহুতল ভবনে ফ্ল্যাট ভাড়া নিয়েছেন। এখন পুরো বিল্ডিংয়ের মূল ফটকে দারোয়ান রাখা, সিসিটিভি ক্যামেরা লাগানো, লিফট ও সিঁড়ির নিরাপত্তা এবং ভবনের ছাদ ঠিক রাখার দায়িত্ব বাড়িওয়ালার (AWS)। কিন্তু আপনার ফ্ল্যাটের দরজায় তালা দেওয়া, আলমারি লক রাখা কিংবা আপনার ড্রয়িংরুমে আপনি কাকে ঢুকতে দেবেন আর কাকে দেবেন না—এই দায়িত্ব কিন্তু সম্পূর্ণ আপনার (Customer)।

┌────────────────────────────────────────────────────────────────────────┐
│               গ্রাহকের দায়িত্ব: SECURITY "IN" THE CLOUD               │
│  • গ্রাহকের নিজস্ব ডেটা ও ডেটা এনক্রিপশন (Data at Rest & in Transit)   │
│  • IAM পরিচালনা (ইউজার, পাসওয়ার্ড, MFA, রোল ও পারমিশন)                 │
│  • অপারেটিং সিস্টেম (Guest OS) প্যাচিং ও সফটওয়্যার আপডেট               │
│  • নেটওয়ার্ক ও ফায়ারওয়াল কনফিগারেশন (Security Groups & Network ACLs)   │
├────────────────────────────────────────────────────────────────────────┤
│           ═══════ যৌথ সুরক্ষার সীমারেখা (SHARED BORDER) ═══════        │
├────────────────────────────────────────────────────────────────────────┤
│                 AWS-এর দায়িত্ব: SECURITY "OF" THE CLOUD                │
│  • সফটওয়্যার লেয়ার (Compute, Storage, Database ও Networking সার্ভিস)   │
│  • হার্ডওয়্যার ও গ্লোবাল ইনফ্রাস্ট্রাকচার (Regions, AZs, Edge Locations) │
│  • ফিজিক্যাল ডেটা সেন্টার নিরাপত্তা (সিসিটিভি, সশস্ত্র গার্ড, বায়োমেট্রিক) │
│  • হাইপারভাইজর বা ভার্চুয়ালাইজেশন লেয়ার (এক গ্রাহক থেকে অন্যের আইসোলেশন)  │
└────────────────────────────────────────────────────────────────────────┘

AWS-এর দায়িত্ব: Security "OF" the Cloud (ক্লাউডের নিজস্ব নিরাপত্তা)

AWS মূলত সেই ভিত্তিগত অবকাঠামো (Underlying Infrastructure) পাহারা দেয় যার ওপর সব ক্লাউড সার্ভিস চলে:

• ফিজিক্যাল ডেটা সেন্টার: AWS ডেটা সেন্টারগুলো অত্যন্ত গোপনীয় ও বেনামী ভবনে (Nondescript facilities) অবস্থিত। এখানে সার্বক্ষণিক সশস্ত্র গার্ড, ২-ফ্যাক্টর বায়োমেট্রিক অ্যাক্সেস এবং ভিডিও নজরদারি থাকে। কোনো হার্ডডিস্ক নষ্ট হয়ে গেলে সেটিকে বিশেষ বৈজ্ঞানিক প্রক্রিয়ায় ডিম্যাগনেটাইজ (Degaussing) ও গুঁড়ো করে ধ্বংস করা হয় যাতে এক ফোঁটা ডেটাও রিকভার করা না যায়।

• হার্ডওয়্যার ও নেটওয়ার্ক: সার্ভার রেক, পাওয়ার ব্যাকআপ জেনারেটর, ফাইবার অপটিক ক্যাবলিং, রাউটার এবং সুইচ।

• ভার্চুয়ালাইজেশন ও হাইপারভাইজর: ফিজিক্যাল সার্ভারের ভেতরের হাইপারভাইজর সফটওয়্যার, যা নিশ্চিত করে যে একই ফিজিক্যাল সার্ভারে অন্য কোম্পানির ভার্চুয়াল মেশিন থাকলেও আপনার ডেটা অন্য কেউ দেখতে পারবে না।

কাস্টমারের দায়িত্ব: Security "IN" the Cloud (ক্লাউডের ভেতরের নিরাপত্তা)

AWS আপনাকে একটি সুরক্ষিত পরিবেশ উপহার দেয়, কিন্তু সেই পরিবেশের ভেতর আপনি কী করবেন তা আপনার দায়িত্ব:

• ডেটার মালিকানা ও সুরক্ষা: আপনার ডেটা এনক্রিপ্ট করবেন কি না, কাকে দেখতে দেবেন, ডেটার ব্যাকআপ রাখবেন কি না—তা পুরোপুরি আপনার হাতে।

• গেস্ট ওএস (Guest OS) প্যাচিং: আপনি যদি একটি EC2 সার্ভার (যেমন উবুন্টু বা উইন্ডোজ) চালু করেন, তবে সেটির ওএস আপডেট ও সিকিউরিটি প্যাচ দেওয়া আপনার দায়িত্ব।

• ফায়ারওয়াল কনফিগারেশন: আপনার সার্ভারের সিকিউরিটি গ্রুপে (Security Groups) কোন কোন পোর্ট খোলা রাখবেন (যেমন ওয়েবের জন্য পোর্ট ৮০/৪৪৩) আর কোনটি বন্ধ রাখবেন (যেমন ডেটাবেস পোর্ট)—তা ঠিক করা।

সার্ভিসের প্রকারভেদে দায়িত্বের বণ্টন (IaaS vs PaaS vs SaaS)

সার্ভিসের ধরন	ক্লাউড সার্ভিসসমূহ	কার দায়িত্ব কতটুকু?
IaaS (Infrastructure as a Service)	Amazon EC2, Amazon EBS, Amazon VPC	কাস্টমারের নিয়ন্ত্রণ সবচেয়ে বেশি, তাই দায়িত্বও সবচেয়ে বেশি। গেস্ট ওএস প্যাচিং, সফটওয়্যার ইনস্টল, নেটওয়ার্ক কনফিগারেশন—সব কাস্টমারকে করতে হয়।
PaaS / Managed (Platform as a Service)	Amazon RDS, AWS Lambda, AWS Elastic Beanstalk	AWS এখানে অবকাঠামো, অপারেটিং সিস্টেম এবং ডেটাবেস ইঞ্জিন প্যাচিং নিজের কাঁধে তুলে নেয়। কাস্টমার শুধু কোড ও ডেটা নিয়ে ভাবেন।
SaaS (Software as a Service)	AWS Trusted Advisor, AWS Shield, Amazon Chime	সম্পূর্ণ সফটওয়্যার এবং ইনফ্রাস্ট্রাকচার AWS পরিচালনা করে। কাস্টমার শুধু ব্রাউজার বা অ্যাপ দিয়ে সেবাটি ব্যবহার করেন।

বাস্তব কেস স্টাডি (পরীক্ষার কমন প্রশ্ন): একটি কোম্পানি Oracle ডেটাবেস ক্লাউডে চালাতে চায়। এই ডেটাবেসের সফটওয়্যার আপডেট ও সিকিউরিটি প্যাচ দেওয়ার দায়িত্ব কার?

• ডেটাবেসটি যদি Amazon EC2-তে নিজে ইনস্টল করে চালায় \(\rightarrow\) দায়িত্ব কাস্টমারের (কারণ EC2 হলো IaaS)।

• ডেটাবেসটি যদি Amazon RDS হিসেবে নেয় \(\rightarrow\) দায়িত্ব AWS-এর (কারণ RDS একটি Managed Service/PaaS, যেখানে ওএস ও ডিবি প্যাচিং AWS স্বয়ংক্রিয়ভাবে করে)।

---

২. AWS Identity and Access Management (IAM)

ক্লাউডের গেটে দারোয়ান হিসেবে কাজ করে IAM। এর মাধ্যমে ঠিক করা হয়—কে ক্লাউডে ঢুকতে পারবে (Authentication) এবং ঢোকার পর সে কী কাজ করার অনুমতি পাবে (Authorization)।

মনে রাখার মতো বিষয়: IAM হলো একটি Global Service। আপনি বিশ্বের যে রিজিয়োনেই কাজ করুন না কেন, IAM ইউজার, গ্রুপ বা পলিসি পুরো AWS অ্যাকাউন্টের জন্য একটাই গ্লোবাল কনসোল থেকে পরিচালিত হয়।

IAM-এর ৪টি মূল স্তম্ভ (The Four Pillars):

1. IAM User (ইউজার): নির্দিষ্ট একজন ব্যক্তি বা অ্যাপ্লিকেশনের ডিজিটাল পরিচয় (যেমন: abir বা karim)। প্রতিটি ইউজারের নিজস্ব আলাদা ইউজারনেম, পাসওয়ার্ড বা সিক্রেট অ্যাক্সেস কি থাকে।

2. IAM Group (গ্রুপ): অনেকগুলো ইউজারের একটি দল (যেমন: Developers, Admins, Auditors)।

   • গ্রুপে একটি পলিসি দিলে গ্রুপের সব ইউজার এক নিমেষে সেই পারমিশন পেয়ে যায়।

   • নিয়ম: গ্রুপের ভেতরে আরেকটি সাব-গ্রুপ (Nested Group) রাখা যায় না। কোনো ডিফল্ট গ্রুপ থাকে না। একজন ইউজার একাধিক গ্রুপের সদস্য হতে পারে।

3. IAM Policy (পলিসি): এটি পারমিশনের অফিসিয়াল দলিল! এটি মূলত একটি JSON ডকুমেন্ট যা নির্ধারণ করে কোন রিসোর্সে কী করা যাবে আর কী করা যাবে না।

4. IAM Role (রোল): এটি কোনো নির্দিষ্ট ব্যক্তির সাথে স্থায়ীভাবে যুক্ত থাকে না। এটি একটি অস্থায়ী পরিচয়। এটি গ্রহণ (Assume) করলে AWS থেকে Temporary Security Credentials দেওয়া হয়। এটি সাধারণত সার্ভিসের জন্য (যেমন EC2) বা অন্য অ্যাকাউন্টের ইউজারকে সাময়িক প্রবেশাধিকার দিতে ব্যবহৃত হয়।

Authentication: অ্যাকাউন্টে প্রবেশের উপায়

• Console Access: ব্রাউজারে লগইন করতে প্রয়োজন \(\rightarrow\) 12-সংখ্যার Account ID (বা Alias) + Username + Password।

• Programmatic Access: টার্মিনাল (AWS CLI), পাইথন স্ক্রিপ্ট (SDK) বা কোড দিয়ে অ্যাক্সেস করতে প্রয়োজন \(\rightarrow\) Access Key ID এবং Secret Access Key।

• MFA (Multi-Factor Authentication): নিরাপত্তার জন্য পাসওয়ার্ড ছাড়াও অতিরিক্ত ওটিপি কোড (যেমন: Google Authenticator, Authy বা YubiKey সিকিউরিটি কি)।

IAM Policy দেখতে কেমন হয়? (JSON কোড ও বিশ্লেষণ)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::my-company-photos/*"
    }
  ]
}

• Effect: কাজটি করার অনুমতি দেওয়া হচ্ছে (Allow) নাকি মানা করা হচ্ছে (Deny)।

• Action: নির্দিষ্ট অ্যাকশন বা কাজের নাম (যেমন: s3:GetObject মানে ফাইল ডাউনলোড করা)।

• Resource: কোন নির্দিষ্ট ফাইলের ওপর এই নিয়ম প্রযোজ্য হবে (ARN - Amazon Resource Name)।

• Condition (ঐচ্ছিক): বিশেষ কোনো শর্ত (যেমন: নির্দিষ্ট অফিসের আইপি অ্যাড্রেস ছাড়া কেউ লগইন করতে পারবে না)।

পারমিশন যাচাইয়ের স্বর্ণসূত্র (Evaluation Logic)

AWS-এ যখন কোনো ইউজার বা অ্যাপ্লিকেশন কোনো কাজের অনুরোধ করে, তখন ৩টি ধাপে কঠোর সিদ্ধান্ত নেওয়া হয়:

                  [ API রিকোয়েস্ট আসলো ]
                            │
                            ▼
              ┌───────────────────────────┐
              │ কোনো EXPLICIT DENY আছে কি? │
              └─────────────┬─────────────┘
                     হ্যাঁ  │   │ না
         ┌──────────────────┘   └──────────────────┐
         ▼                                         ▼
┌──────────────────┐                     ┌────────────────────────────┐
│ ❌ অ্যাক্সেস বাতিল  │                     │ কোনো EXPLICIT ALLOW আছে কি? │
│     (DENIED)     │                     └─────────────┬──────────────┘
└──────────────────┘                            হ্যাঁ  │   │ না
                                        ┌──────────────┘   └──────────────┐
                                        ▼                                 ▼
                               ┌──────────────────┐              ┌──────────────────┐
                               │ ✅ অ্যাক্সেস মঞ্জুর │              │ ❌ ডিফল্ট বাতিল   │
                               │    (ALLOWED)     │              │ (IMPLICIT DENY)  │
                               └──────────────────┘              └──────────────────┘

1. স্বভাবগতভাবে সব বন্ধ (Implicit Deny): নতুন তৈরি ইউজারের কোনো পারমিশন থাকে না।

2. Explicit Deny সর্বদা বিজয়ী: যদি ১০০টি পলিসিতে Allow থাকে এবং একটি পলিসিতেও Explicit Deny থাকে, তবে Deny জয়ী হবে এবং অ্যাক্সেস বন্ধ হয়ে যাবে।

3. Explicit Allow প্রয়োজন: কোনো Deny না থাকলে এবং অন্তত একটি পলিসিতে স্পষ্ট Allow থাকলেই কেবল কাজ করা যাবে।

Principle of Least Privilege (ন্যূনতম সুবিধার নীতি): কোনো ইউজার বা অ্যাপ্লিকেশনকে তার কাজ করার জন্য ঠিক যতটুকু ক্ষমতা দরকার, ঠিক ততটুকুই দিন; এক বিন্দুও বেশি পারমিশন দেওয়া যাবে না।

কেন হার্ডকোডেড কি বাদ দিয়ে IAM Role ব্যবহার করবেন?

মনে করুন আপনার EC2 সার্ভারের ভেতর চলা একটি ওয়েবসাইটকে S3 বাকেট থেকে ছবি পড়তে হবে।

• ❌ ভুল ও বিপজ্জনক পদ্ধতি: কোডের ফাইলের ভেতর আপনার নিজস্ব Access Key ID ও Secret Key লিখে রাখা। সার্ভার হ্যাক হলে বা কোড গিটহাবে পুশ হয়ে গেলে কি লিক হয়ে যাবে!

• ✅ সঠিক পদ্ধতি (IAM Role): একটি IAM Role তৈরি করুন যার S3 রিড পারমিশন আছে। এরপর রোলটি EC2 ইনস্ট্যান্সের সাথে যুক্ত (Attach) করে দিন। EC2 সার্ভার ব্যাকগ্রাউন্ডে নিজেই AWS STS (Security Token Service) থেকে সাময়িক ক্রেডেনশিয়াল পাবে। কোনো পাসওয়ার্ড বা কি কোডে লিখতে হয় না!

---

৩. নতুন AWS অ্যাকাউন্ট সুরক্ষিত করার ব্লুপ্রিন্ট (Securing a New Account)

আপনি যখন প্রথম ইমেইল ও পাসওয়ার্ড দিয়ে একটি AWS অ্যাকাউন্ট খোলেন, সেই অ্যাকাউন্টটির নাম হলো Account Root User।

রুট ইউজারের ক্ষমতা অসীম ও অবাধ। এর ওপর কোনো পলিসি দিয়ে লাগাম টানা যায় না। সে চাইলে এক ক্লিকে পুরো অ্যাকাউন্ট এবং সমস্ত রিসোর্স মুছে ফেলতে পারে। তাই রুট ইউজার নিয়ে কাজ করার সময় সর্বোচ্চ সাবধানতা অবলম্বন করতে হয়।

রুট ইউজার ছাড়া যেসব কাজ কখনোই করা যায় না: ১. অ্যাকাউন্টের নাম, ইমেইল বা রুট পাসওয়ার্ড পরিবর্তন করা।
২. AWS Support Plan পরিবর্তন করা (যেমন Basic থেকে Business/Enterprise)।
৩. অ্যাকাউন্ট স্থায়ীভাবে বন্ধ (Close Account) করা।
৪. কোনো কারণে লক হয়ে যাওয়া IAM অ্যাডমিনের পারমিশন রিকভার করা।

নতুন অ্যাকাউন্ট খোলার পর প্রথম ৪টি কাজ:

┌────────────────────────────────────────────────────────────────────────┐
│               নতুন AWS অ্যাকাউন্ট সুরক্ষার ৪টি প্রধান স্তম্ভ            │
├──────────────┬──────────────┬──────────────────────────┬───────────────┤
│    ধাপ ০১    │    ধাপ ০২    │          ধাপ ০৩          │    ধাপ ০৪     │
│  Root User   │     MFA      │      AWS CloudTrail      │    Billing    │
│  বন্ধ করা    │  চালু করা    │      অ্যাক্টিভিটি লগ     │  অ্যালার্ম সেট │
└──────────────┴──────────────┴──────────────────────────┴───────────────┘

1. রুট ইউজারের ব্যবহার দ্রুত বন্ধ করুন: রুট ইউজার হিসেবে লগইন করে নিজের জন্য একটি IAM User তৈরি করুন। তাকে AdministratorAccess পারমিশন দিন। এরপর রুট অ্যাকাউন্টের কোনো অ্যাক্সেস কি থাকলে তা মুছে দিন। একটি শক্তিশালী পাসওয়ার্ড পলিসি সেট করুন। এরপর রুট অ্যাকাউন্ট থেকে লগআউট করে পাসওয়ার্ড নিরাপদ ভল্টে তালাবন্ধ করে রাখুন। এখন থেকে সব কাজ হবে আপনার নতুন IAM Admin দিয়ে।

2. MFA বাধ্যতামূলক করুন: রুট অ্যাকাউন্ট এবং সমস্ত IAM ইউজারের লগইনে মাল্টি-ফ্যাক্টর অথেন্টিকেশন (যেমন Google Authenticator বা YubiKey) চালু করুন।

3. AWS CloudTrail সক্রিয় রাখুন:

   • CloudTrail কী? এটি হলো আপনার ক্লাউড অ্যাকাউন্টের ২৪ ঘণ্টার সিসিটিভি ক্যামেরা। কে, কখন, কোন আইপি থেকে, কোন সার্ভিসের API কল করেছে—তার সব তথ্য লগ আকারে জমা হয়।

   • সুসংবাদ: প্রতিটি AWS অ্যাকাউন্টে CloudTrail বাই-ডিফল্ট চালু থাকে এবং শেষ ৯০ দিনের ইভেন্ট হিস্ট্রি (Event History) সম্পূর্ণ বিনামূল্যে দেখা যায়।

   • লগ সংরক্ষণ: ৯০ দিনের বেশি রেকর্ড রাখতে হলে একটি Trail তৈরি করে লগগুলো Amazon S3 বাকেটে পাঠাতে হয়।

4. Billing Alert ও বাজেট সেট করুন: বাজেট অতিক্রম করার আগেই যাতে ইমেইলে নোটিফিকেশন চলে আসে, সেজন্য CloudWatch Billing Alarm এবং AWS Cost and Usage Report (CUR) সক্রিয় করুন।

---

৪. মাল্টি-অ্যাকাউন্ট ও গুরুত্বপূর্ণ সিকিউরিটি সার্ভিসসমূহ

প্রতিষ্ঠান যখন বড় হয়, তখন একটা মাত্র অ্যাকাউন্টে সবকিছু রাখা যায় না। তখন বিভিন্ন কাজের জন্য আলাদা আলাদা অ্যাকাউন্ট নিয়ে কাজ করতে হয়। এই পরিস্থিতিতে নিরাপত্তা নিশ্চিত করতে নিচের সার্ভিসগুলো অপরিহার্য:

১. AWS Organizations এবং Service Control Policies (SCPs)

একাধিক AWS অ্যাকাউন্টকে একটি ছাতার নিচে এনে কেন্দ্রীয়ভাবে পরিচালনা করার সার্ভিস হলো AWS Organizations। এর মাধ্যমে সব অ্যাকাউন্টের খরচ এক সাথে (Consolidated Billing) দেওয়া যায় এবং ভলিউম ডিসকাউন্ট পাওয়া যায়।

                  [ AWS Organization Root ]
                             │
            ┌────────────────┴────────────────┐
            ▼                                 ▼
   [ OU: Development ]               [ OU: Production ]
     ├── Dev Account 1                 ├── Prod Account (Live)
     └── Dev Account 2                 └── Prod Account (Database)
            │                                 │
     [ SCP Guardrail ]                 [ SCP Guardrail ]
     (বড় সার্ভার ব্লক)                (ডেটাবেস মোছা নিষিদ্ধ)

• Service Control Policy (SCP) কী?

  • এটি হলো কোনো অ্যাকাউন্ট বা Organizational Unit (OU)-এর ওপর বসানো একটি সর্বোচ্চ সুরক্ষা দেয়াল বা Guardrail।

  • পরীক্ষার অত্যন্ত গুরুত্বপূর্ণ রুল:

    SCP কখনো কোনো পারমিশন প্রদান (Grant) করে না! এটি কেবল সর্বোচ্চ সীমা ঠিক করে।
    সদস্য অ্যাকাউন্টের রুট ইউজার বা অ্যাডমিন চাইলেও SCP-তে ব্লক করা কোনো সার্ভিস চালাতে পারবে না।

  • কার্যকর অনুমতি: ইউজার কেবল সেটাই করতে পারবে যা তার অ্যাকাউন্টের IAM Policy এবং মূল Organizations-এর SCP—উভয় জায়গাতেই অনুমোদিত।

২. AWS Key Management Service (AWS KMS)

ডেটা এনক্রিপ্ট করার চাবি (Customer Master Keys - CMKs) তৈরি, পরিচালনা ও রোটেট করার সার্ভিস হলো KMS।

• এটি আমেরিকান সরকারের FIPS 140-2 অনুমোদিত হার্ডওয়্যার সিকিউরিটি মডিউল (HSM)-এর মাধ্যমে চাবিগুলো সুরক্ষিত রাখে।

• কে কখন কোন চাবি ব্যবহার করে ডেটা ডিক্রিপ্ট করেছে, তার প্রতিটি ঘটনার রেকর্ড সরাসরি CloudTrail-এ জমা হয়।

৩. Amazon Cognito (অ্যাপ ব্যবহারকারীদের লগইন সিস্টেম)

আপনার মোবাইল বা ওয়েব অ্যাপ্লিকেশনে লাখ লাখ ইউজারের সাইন-আপ ও লগইন সিস্টেম তৈরি করার রেডিমেড সমাধান হলো Cognito।

• এটি ব্যবহারকারীদের সরাসরি Google, Facebook, Apple বা Amazon অ্যাকাউন্ট দিয়ে লগইন করার সুবিধা দেয়।

• অফিসের কর্মচারীদের জন্য Microsoft Active Directory বা SAML 2.0 (SSO) দিয়ে সিঙ্গেল সাইন-ইন সমর্থন করে।

• এটি HIPAA এবং PCI-DSS সার্টিফাইড।

৪. AWS Shield (DDoS আক্রমণ থেকে সুরক্ষার ছাতা)

একসাথে লাখ লাখ ভুয়া ট্রাফিক পাঠিয়ে কোনো ওয়েবসাইট ক্র্যাশ করানোকে বলা হয় DDoS (Distributed Denial of Service) আক্রমণ।

• AWS Shield Standard: এটি সম্পূর্ণ ফ্রি। বিশ্বের প্রতিটি AWS কাস্টমারের জন্য এটি ব্যাকগ্রাউন্ডে সবসময় অন থাকে। এটি সাধারণ লেয়ার ৩ ও লেয়ার ৪ এর ট্রাফিক আক্রমণ (যেমন SYN/UDP Floods) স্বয়ংক্রিয়ভাবে প্রতিহত করে।

• AWS Shield Advanced: এটি একটি পেইড সাবস্ক্রিপশন সার্ভিস। জটিল ও বিশাল আক্রমণ ঠেকাতে এবং সরাসরি আমাজনের ডেডিকেটেড DDoS Response Team (DRT)-এর ২৪/৭ বিশেষজ্ঞ সাহায্য পেতে বড় বড় প্রতিষ্ঠান এটি ব্যবহার করে।

---

৫. ক্লাউডে ডেটা সুরক্ষা ও এনক্রিপশন (Securing Data)

ডেটা সুরক্ষার ক্ষেত্রে দুটি বিষয় সবসময় মাথায় রাখতে হয়:

1. Data at Rest (সংরক্ষিত ডেটা): যা কোনো হার্ডডিস্ক, টেপ বা এসএসডিতে সেভ করা অবস্থায় আছে।

2. Data in Transit (চলমান ডেটা): যা ইন্টারনেটের মাধ্যমে বা নেটওয়ার্ক কেবল দিয়ে এক জায়গা থেকে অন্য জায়গায় যাতায়াত করছে।

┌──────────────────────────────────┐      ┌──────────────────────────────────┐
│     DATA AT REST (সংরক্ষিত)     │      │     DATA IN TRANSIT (চলমান)      │
├──────────────────────────────────┤      ├──────────────────────────────────┤
│ • স্টোরেজে থাকা ডেটা             │      │ • নেটওয়ার্ক দিয়ে যাতায়াতকারী ডেটা│
│ • Amazon S3, EBS, RDS, EFS       │      │ • ব্রাউজার থেকে সার্ভার বা EC2-EFS│
│ • অ্যালগরিদম: AES-256 Bit        │      │ • প্রটোকল: TLS 1.2 / HTTPS       │
│ • চাবি পরিচালনা: AWS KMS         │      │ • সার্টিফিকেট: AWS ACM (ফ্রি SSL) │
└──────────────────────────────────┘      └──────────────────────────────────┘

Data at Rest-এর সুরক্ষা:

• AWS শিল্পমানের AES-256 (Advanced Encryption Standard) অ্যালগরিদম ব্যবহার করে।

• আপনি যখন S3 বাকেট, EBS ভলিউম কিংবা RDS ডেটাবেস তৈরি করবেন, এক ক্লিকে "Encrypt" চালু করে দিলে ব্যাকগ্রাউন্ডে KMS দিয়ে পুরো ডেটা এনক্রিপ্ট হয়ে যায়। অ্যাপ্লিকেশনের কোনো কোড পরিবর্তন করতে হয় না।

Data in Transit-এর সুরক্ষা:

• সাধারণ HTTP ট্রাফিকের বদলে HTTPS / TLS 1.2 ব্যবহার করলে প্রেরক ও প্রাপকের মাঝে একটি এনক্রিপ্টেড টানেল তৈরি হয়। এটি আড়িপাতা এবং Man-in-the-Middle (MITM) আক্রমণ রোধ করে।

• AWS Certificate Manager (ACM): এটি বিনামূল্যে আপনার ডোমেইনের জন্য SSL/TLS সার্টিফিকেট ইস্যু করে এবং প্রতি বছর স্বয়ংক্রিয়ভাবে রিনিউ করে।

Amazon S3 বাকেট কীভাবে সুরক্ষিত রাখবেন?

• বাই-ডিফল্ট ১০০% প্রাইভেট: আপনি নতুন একটি S3 বাকেট বানালে স্বয়ংক্রিয়ভাবে তা পৃথিবীর কারো কাছে দৃশ্যমান থাকে না।

• S3 Block Public Access: এটি বাকেটের ওপর একটি সেন্ট্রাল মাস্টার সুইচ। এটি অন থাকলে ভুলবশতও কোনো ফাইল ইন্টারনেটে পাবলিক হতে পারে না।

• Bucket Policies: বাকেটের গায়ে JSON পলিসি লিখে নির্দিষ্ট আইপি বা ইউজারকে অ্যাক্সেস দেওয়া যায়।

• AWS Trusted Advisor: এটি একটি ফ্রি অডিট টুল যা আপনার অ্যাকাউন্ট স্ক্যান করে তাৎক্ষণিকভাবে অ্যালার্ট দেয় যে আপনার কোনো বাকেট ইন্টারনেটে উন্মুক্ত (Public) হয়ে গেছে কি না।

---

৬. অডিট ও কমপ্লায়েন্স: প্রমাণ করবেন কীভাবে?

বড় বড় আন্তর্জাতিক ক্লায়েন্টদের কাছে শুধু মুখে বললেই চলে না যে "আমার সাইট নিরাপদ", তাদের আন্তর্জাতিক সার্টিফিকেটের প্রমাণ দেখাতে হয়। একে বলে কমপ্লায়েন্স (Compliance)।

                                [ অডিটর বা সিকিউরিটি টিম ]
                                             │
             ┌───────────────────────────────┼───────────────────────────────┐
             ▼                               ▼                               ▼
    [ AWS CloudTrail ]                [ AWS Config ]                 [ AWS Artifact ]
   🎥 কে, কখন, কী করেছে?         🔍 কনফিগারেশন নিয়ম মেনে          📁 অডিট রিপোর্ট ও চুক্তি
    (ইউজার অ্যাক্টিভিটি লগ)          হয়েছে কি না তা যাচাই               (ISO/SOC রিপোর্ট ডাউনলোড)

৩টি কনফিউজিং সার্ভিসের সহজ পার্থক্য (পরীক্ষার জন্য মাস্ট-রিড!):

সার্ভিস	মূল কাজ (Keyword)	সহজ উপমা
AWS CloudTrail	কে, কখন, কোন সার্ভিস বা API ব্যবহার করেছে তার লগ রাখা।	সিসিটিভি ক্যামেরা (অ্যাক্টিভিটি হিস্ট্রি)
AWS Config	রিসোর্সগুলোর কনফিগারেশন নিয়মানুযায়ী ঠিক আছে কি না তা সার্বক্ষণিক পর্যবেক্ষণ করা।	সারপ্রাইজ ইন্সপেকশন (রিসোর্স স্বাস্থ্য পরীক্ষা)
AWS Artifact	AWS-এর অফিসিয়াল সিকিউরিটি সার্টিফিকেট ও অডিট রিপোর্ট ডাউনলোড করার পোর্টাল।	রিপোর্ট ফাইলের ড্রয়ার

• AWS Config কেন ব্যবহার করবেন? মনে করুন আপনার কোম্পানির নিয়ম হলো—"কোনো ডেভেলপার আন-এনক্রিপ্টেড হার্ডডিস্ক বানাতে পারবে না"। AWS Config সারাক্ষণ পাহারা দেবে। কেউ নিয়ম ভেঙে আন-এনক্রিপ্টেড ডিস্ক বানালে এটি সাথে সাথে তাকে Non-compliant হিসেবে চিহ্নিত করবে এবং চাইলে নিজে থেকেই অটোমেটিক ডিস্কটি এনক্রিপ্ট করে ফেলতে পারে।

• AWS Artifact কেন ব্যবহার করবেন? আপনার বিদেশি ক্লায়েন্ট যদি জানতে চায়, "AWS কি ISO 27001 বা PCI-DSS সার্টিফাইড?" আপনি সোজা কনসোল থেকে AWS Artifact-এ গিয়ে অফিসিয়াল অডিট রিপোর্ট ডাউনলোড করে ক্লায়েন্টকে জমা দিতে পারবেন। এছাড়াও মেডিকেলের কাজের জন্য HIPAA BAA এগ্রিমেন্ট এখান থেকেই স্বাক্ষর করা যায়।

---

📝 সার্টিফিকেশন পরীক্ষার স্পেশাল প্রশ্ন (Sample Exam Question)

মডিউল ৪-এর ওপর ভিত্তি করে AWS Certified Cloud Practitioner পরীক্ষায় আসা একটি রিয়েল প্রশ্ন দেখে নেওয়া যাক:

প্রশ্ন:

Which of the following is AWS's responsibility under the AWS shared responsibility model?
(AWS শেয়ার্ড রেসপন্সিবিলিটি মডেল অনুযায়ী নিচের কোনটি AWS-এর দায়িত্ব?)

• A. Configuring third-party applications (থার্ড পার্টি অ্যাপ কনফিগার করা)

• B. Maintaining physical hardware (ফিজিক্যাল হার্ডওয়্যার মেইনটেইন করা)

• C. Securing application access and data (অ্যাপ্লিকেশন অ্যাক্সেস ও ডেটা সুরক্ষিত করা)

• D. Managing custom Amazon Machine Images (AMIs) (কাস্টম AMI পরিচালনা করা)

সঠিক উত্তর ও বিশ্লেষণ:

• সঠিক উত্তর: B (Maintaining physical hardware)

• ব্যাখ্যা: ডেটা সেন্টারের সার্ভার র্যাক, পাওয়ার ও ফিজিক্যাল হার্ডওয়্যার রক্ষণাবেক্ষণ করা AWS-এর দায়িত্ব (Security OF the Cloud)। অপরদিকে অপশন A, C এবং D—এগুলো ক্লাউডের ভেতরে গ্রাহক পরিচালনা করে, তাই এগুলো কাস্টমারের দায়িত্ব (Security IN the Cloud)।

---

এক নজরে মূল শিক্ষা (Key Takeaways):

1. শেয়ার্ড মডেল: হার্ডওয়্যার ও ডেটা সেন্টারের নিরাপত্তা AWS-এর, কিন্তু ওএস প্যাচিং, ডেটা এবং অ্যাক্সেস কন্ট্রোল আপনার।

2. রুট ইউজার লক রাখুন: দৈনন্দিন কাজে কখনোই রুট ইউজার ব্যবহার করবেন না; একটি IAM Admin বানিয়ে রুট অ্যাকাউন্টে MFA দিয়ে নিরাপদ ভল্টে লক করে রাখুন।

3. Least Privilege মানুন: কোনো ইউজার বা সার্ভিসকে প্রয়োজনের এক বিন্দু বেশি পারমিশন দেবেন না।

4. হার্ডকোডেড কি পরিহার করুন: EC2 বা অ্যাপ্লিকেশনের জন্য অ্যাক্সেস কি কোডে না লিখে IAM Role ব্যবহার করুন।

5. অডিট ও ট্র্যাকিং চালু রাখুন: সিসিটিভি লগিংয়ের জন্য CloudTrail, কনফিগারেশন চেকের জন্য Config এবং অডিট পেপারের জন্য Artifact ব্যবহার করুন।

---

ক্লাউড সিকিউরিটি কোনো একদিনের কাজ নয়, এটি একটি ধারাবাহিক সচেতনতা ও চর্চা। এই ব্লগের প্রতিটি কনসেপ্ট আত্মস্থ করতে পারলে আপনার ক্লাউড ইনফ্রাস্ট্রাকচার যেমন সম্পূর্ণ নিরাপদ থাকবে, তেমনি AWS সার্টিফিকেশন পরীক্ষায় ক্লাউড সিকিউরিটির যেকোনো প্রশ্ন আপনি সম্পূর্ণ আত্মবিশ্বাসের সাথে সমাধান করতে পারবেন!