পাঠ ৫১ · ৬০-এর মধ্যে · মডিউল ১১
Home / Courses / Cybersecurity & Ethical Hacking / শেয়ার্ড রেসপন্সিবিলিটি

ক্লাউড সিকিউরিটি — শেয়ার্ড রেসপন্সিবিলিটি মডেল

Cloud security — shared responsibility model
৮ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • Shared Responsibility Model কী এবং কেন এটি ক্লাউড সিকিউরিটির ভিত্তি
  • "Security OF the cloud" vs "Security IN the cloud" — পার্থক্যটা ঠিক কোথায়
  • IaaS, PaaS ও SaaS জুড়ে দায়িত্বের বিভাজন কীভাবে পরিবর্তিত হয়
  • কেন এই মডেল ভুল বোঝাই বাস্তব ক্লাউড ব্রিচের একটি সাধারণ মূল কারণ

১ · Shared Responsibility Model — ক্লাউড সিকিউরিটির ভিত্তি

যখন একটি প্রতিষ্ঠান নিজস্ব সার্ভার রুমের বদলে ক্লাউড (AWS, Azure, Google Cloud-স্টাইল প্রোভাইডার) ব্যবহার করে, একটি গুরুত্বপূর্ণ প্রশ্ন ওঠে — সিকিউরিটির দায়িত্ব ঠিক কার? উত্তরটি হলো Shared Responsibility ModelShared Responsibility Modelক্লাউড কম্পিউটিং-এর একটি মৌলিক নীতি, যেখানে সিকিউরিটির দায়িত্ব প্রোভাইডার ও গ্রাহকের মধ্যে ভাগ হয়ে যায় — কেউ একা সম্পূর্ণ দায়িত্ব নেয় না। — দায়িত্ব ভাগ হয়ে যায়, একা কারও উপরই সম্পূর্ণ বর্তায় না।

Security OF the cloud (প্রোভাইডারের দায়িত্ব)
শারীরিক ডেটা সেন্টার, হোস্ট অবকাঠামো, নেটওয়ার্কিং হার্ডওয়্যার, হাইপারভাইজার — অর্থাৎ ক্লাউড নিজে যেভাবে চলে তার নিরাপত্তা।
Security IN the cloud (গ্রাহকের দায়িত্ব)
নিজের ডেটা, IAM কনফিগারেশন, নেটওয়ার্ক সেটিংস (ফায়ারওয়াল রুল, ভিপিসি), অ্যাপ্লিকেশন কোড, এবং সার্ভিস মডেল অনুযায়ী OS প্যাচিং।

২ · সার্ভিস মডেল অনুযায়ী বিভাজন পরিবর্তিত হয়

এই দায়িত্বের সঠিক বিভাজন রেখা স্থির নয় — এটি ব্যবহৃত সার্ভিস মডেলের উপর নির্ভর করে পরিবর্তিত হয়:

  • IaaS (Infrastructure as a Service) — গ্রাহক সবচেয়ে বেশি দায়িত্ব নেয়: OS প্যাচিং, নেটওয়ার্ক কনফিগারেশন, অ্যাপ্লিকেশন — সবই গ্রাহকের হাতে (উদাহরণ: একটি ভার্চুয়াল মেশিন ভাড়া নেওয়া)।
  • PaaS (Platform as a Service) — প্রোভাইডার আরও বেশি সামলায় (OS, রানটাইম প্যাচিং), গ্রাহক মূলত অ্যাপ্লিকেশন কোড ও ডেটার দায়িত্বে থাকে।
  • SaaS (Software as a Service) — প্রোভাইডার প্রায় সবকিছু সামলায়; গ্রাহক মূলত নিজের অ্যাক্সেস ও ডেটা ম্যানেজমেন্টের দায়িত্বে থাকে (উদাহরণ: একটি রেডি-মেড ইমেইল সার্ভিস ব্যবহার করা)।
গুরুত্বপূর্ণ সতর্কতা · সবচেয়ে সাধারণ ভুল

বাস্তব-জগতের বেশিরভাগ ক্লাউড ব্রিচের মূল কারণ এক্সোটিক টেকনিক্যাল এক্সপ্লয়েট নয় — এটি এই মডেল ভুল বোঝা। গ্রাহক ধরে নেয় প্রোভাইডার হয়তো তার ডেটা এনক্রিপশন, অ্যাক্সেস কন্ট্রোল, বা নেটওয়ার্ক কনফিগারেশন "এমনিতেই" সামলে নিচ্ছে — কিন্তু সার্ভিস মডেল অনুযায়ী এগুলো প্রায়ই সম্পূর্ণভাবে গ্রাহকের নিজের দায়িত্ব। ব্যবহার শুরুর আগেই স্পষ্টভাবে জেনে নেওয়া উচিত ঠিক কোন অংশটুকু আপনার নিজের সিকিউরিটি টিমের দায়িত্ব।

৩ · কোড দিয়ে দায়িত্বের ম্যাট্রিক্স

নিচের কোড সেলটি সম্পূর্ণ নিরাপদ ও ইন-মেমরি — কয়েকটি সাধারণ দায়িত্বের ক্ষেত্রকে তিনটি সার্ভিস মডেল (IaaS/PaaS/SaaS) জুড়ে কে (Customer/Provider/Shared) সামলায় তা একটি রেফারেন্স টেবিল হিসেবে প্রিন্ট করে।

Python
responsibility_matrix = {
    "শারীরিক ডেটা সেন্টার নিরাপত্তা":       {"IaaS": "Provider", "PaaS": "Provider", "SaaS": "Provider"},
    "হাইপারভাইজার / হোস্ট অবকাঠামো":       {"IaaS": "Provider", "PaaS": "Provider", "SaaS": "Provider"},
    "নেটওয়ার্ক কন্ট্রোল (Firewall/VPC)":  {"IaaS": "Customer", "PaaS": "Shared",   "SaaS": "Provider"},
    "অপারেটিং সিস্টেম প্যাচিং":            {"IaaS": "Customer", "PaaS": "Provider", "SaaS": "Provider"},
    "অ্যাপ্লিকেশন কোড ও কনফিগারেশন":       {"IaaS": "Customer", "PaaS": "Customer", "SaaS": "Provider"},
    "IAM (অ্যাক্সেস ম্যানেজমেন্ট)":         {"IaaS": "Customer", "PaaS": "Customer", "SaaS": "Customer"},
    "ডেটা ও এনক্রিপশন":                    {"IaaS": "Customer", "PaaS": "Customer", "SaaS": "Customer"},
}

print("=== ক্লাউড শেয়ার্ড রেসপন্সিবিলিটি ম্যাট্রিক্স ===")
for area, models in responsibility_matrix.items():
    print(f"\n{area}")
    print(f"  IaaS : {models['IaaS']}")
    print(f"  PaaS : {models['PaaS']}")
    print(f"  SaaS : {models['SaaS']}")

    
লক্ষ্য করুন — IAM ও ডেটা/এনক্রিপশন সবসময় "Customer" থাকে, তিনটি মডেলের কোনোটিতেই এটি প্রোভাইডারের দায়িত্বে যায় না। এই দুটি ক্ষেত্র — কে অ্যাক্সেস পাবে ও ডেটা কীভাবে সুরক্ষিত থাকবে — সবসময়ই গ্রাহকের হাতে থাকে, যত সহজলভ্য বা "ম্যানেজড" সার্ভিসই ব্যবহার করা হোক না কেন। L52-এ আমরা ঠিক এই IAM অংশটিই বিস্তারিত কভার করব।
মূল কথা · Key takeaway

ক্লাউড ব্যবহার করা মানে সিকিউরিটির দায়িত্ব "আউটসোর্স" করা নয় — এটি দায়িত্ব পুনর্বিন্যাস করা। প্রোভাইডার যত বেশি সামলায় (IaaS → PaaS → SaaS), গ্রাহকের প্রযুক্তিগত বোঝা তত কমে, কিন্তু IAM ও ডেটা সিকিউরিটির দায়িত্ব কখনোই সম্পূর্ণভাবে চলে যায় না। এই সীমারেখা স্পষ্টভাবে না জানা মানেই একটি অরক্ষিত ফাঁক তৈরি হওয়া।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি কোম্পানি তাদের ক্লাউড স্টোরেজ বাকেট ভুলবশত পাবলিকলি এক্সেসযোগ্য রেখে দিয়েছে, ফলে সংবেদনশীল ডেটা ফাঁস হয়ে গেছে। Shared Responsibility Model অনুযায়ী এর জন্য কে দায়ী?

গ্রাহক (কোম্পানি) দায়ী। ক্লাউড প্রোভাইডার স্টোরেজ সার্ভিসের অবকাঠামো (হার্ডওয়্যার, বেস সিকিউরিটি) সুরক্ষিত রাখার দায়িত্বে থাকে, কিন্তু সেই স্টোরেজের অ্যাক্সেস কনফিগারেশন — কে দেখতে পারবে, পাবলিক নাকি প্রাইভেট — সবসময় গ্রাহকের ("Security IN the cloud") দায়িত্ব। এই ধরনের ভুল কনফিগারেশনই সবচেয়ে সাধারণ বাস্তব ক্লাউড ব্রিচের কারণ।

প্র ০২ একজন ডেভেলপার বলছেন, "আমরা একটি ম্যানেজড SaaS টুল ব্যবহার করছি, তাই IAM নিয়ে চিন্তা করার দরকার নেই — প্রোভাইডারই তো সব সামলাচ্ছে।" এই ধারণা কেন ভুল?

SaaS-এও IAM (কে কোন অ্যাকাউন্টে অ্যাক্সেস পাবে, কার কী পারমিশন থাকবে) সবসময় গ্রাহকের দায়িত্ব — কোনো সার্ভিস মডেলেই এটি প্রোভাইডারের কাছে যায় না। SaaS প্রোভাইডার অবকাঠামো ও অ্যাপ্লিকেশন কোড সামলায়, কিন্তু কে লগইন করতে পারবে এবং তাদের কী অ্যাক্সেস আছে তা কনফিগার করা সবসময় গ্রাহকের নিজের কাজ — এই ভুল ধারণাই দুর্বল অ্যাক্সেস কনফিগারেশনের একটি সাধারণ কারণ।

প্র ০৩ IaaS ব্যবহারকারী একটি কোম্পানি OS প্যাচ আপডেট না করে বহুদিন ফেলে রেখেছে, ফলে একটি পুরনো CVE-এর মাধ্যমে আক্রান্ত হয়েছে। প্রোভাইডারকে দোষারোপ করা কেন ভুল হবে?

IaaS মডেলে OS প্যাচিং সম্পূর্ণভাবে গ্রাহকের দায়িত্ব (উপরের ম্যাট্রিক্সে দেখানো হয়েছে) — প্রোভাইডার শুধু অন্তর্নিহিত হার্ডওয়্যার ও হাইপারভাইজার সুরক্ষিত রাখে, ভার্চুয়াল মেশিনের ভেতরে কী ইনস্টল বা প্যাচ করা হলো তা নয়। এটি সরাসরি L16-এর প্যাচ ম্যানেজমেন্ট নীতির প্রয়োগ — IaaS ব্যবহার করলেও নিয়মিত প্যাচিং সাইকেল বজায় রাখার দায়িত্ব গ্রাহকেরই থেকে যায়।

অনুশীলন

  1. চিন্তা করুন: আপনার প্রতিষ্ঠান একটি রেডি-মেড ইমেইল সার্ভিস (SaaS) ব্যবহার করে। কোন কোন সিকিউরিটি সিদ্ধান্ত তখনও আপনার নিজের সিকিউরিটি টিমের হাতে থেকে যায়?

    অন্তত এই ক্ষেত্রগুলো আপনার দায়িত্বে থেকে যায়: কোন কর্মীর অ্যাকাউন্ট থাকবে ও তাদের পারমিশন কী হবে (IAM), MFA বাধ্যতামূলক করা হবে কি না, কোন থার্ড-পার্টি অ্যাপকে ইমেইল অ্যাক্সেস দেওয়া হবে, এবং কর্মীরা ফিশিং শনাক্ত করতে প্রশিক্ষিত কি না (ties to M9)। প্রোভাইডার অবকাঠামো সুরক্ষিত রাখলেও এই মানবিক ও কনফিগারেশন সিদ্ধান্তগুলো সবসময় গ্রাহকেরই থেকে যায়।

  2. পরীক্ষা করুন: উপরের কোড সেলে responsibility_matrix-এ একটি নতুন এন্ট্রি যোগ করুন — "ব্যাকআপ ও ডিজাস্টার রিকভারি প্ল্যানিং": {"IaaS": "Customer", "PaaS": "Shared", "SaaS": "Shared"} — এবং কোড আবার চালিয়ে দেখুন এটি কীভাবে প্রিন্ট হয়।

    নতুন এন্ট্রিটি লুপে অন্যগুলোর মতোই একই ফরম্যাটে প্রিন্ট হবে, এবং এটি একটি বাস্তবসম্মত উদাহরণ দেখায় — ব্যাকআপ ও ডিজাস্টার রিকভারি প্রায়ই একটি "Shared" দায়িত্ব, কারণ প্রোভাইডার অবকাঠামো-স্তরের রিডানডেন্সি দিতে পারে, কিন্তু আপনার নিজের ডেটার ব্যাকআপ পলিসি ও পুনরুদ্ধার পরীক্ষা (recovery testing) নিশ্চিত করা এখনও গ্রাহকেরই দায়িত্ব।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
মেমরি ও ডিস্ক ফরেনসিক্স পরিচিতি