অথেন্টিকেশন ও অ্যাক্সেস কন্ট্রোল বেসিকস
এই পাঠে যা শিখবেন
- অথেন্টিকেশন ঠিক কোথায় ঘটে এবং কেন এটি লগইনের সময়ের একটি এককালীন যাচাই, প্রতিটি সিস্টেম কলে নয়
- DAC ও MAC — এই দুই অ্যাক্সেস-কন্ট্রোল পলিসি মডেলের পার্থক্য এবং কোথায় কোনটি ব্যবহৃত হয়
- Unix-এর owner/group/other পারমিশন-বিট মডেল বাস্তবে কীভাবে কাজ করে
- Python দিয়ে একটি প্রকৃত পারমিশন-চেকার — বিভিন্ন ইউজার পরিস্থিতিতে অ্যাক্সেস অনুমোদিত হয় নাকি প্রত্যাখ্যাত হয় তা কোড নিজেই যাচাই করবে
১ · অথেন্টিকেশন — লগইনের মুহূর্তে পরিচয় যাচাই
অথেন্টিকেশনAuthenticationএকজন ব্যবহারকারী আসলেই তিনি যা দাবি করছেন তা-ই কি না, তা যাচাই করার প্রক্রিয়া — সাধারণত লগইনের সময় ঘটে। হলো লগইনের সময় একজন ব্যবহারকারীর পরিচয় যাচাই করার প্রক্রিয়া — কোনো প্রসেস চালু হওয়ার আগেই এটি ঘটে। পাসওয়ার্ড সবচেয়ে পরিচিত পদ্ধতি; আধুনিক OS-গুলো ক্রমবর্ধমানভাবে মাল্টি-ফ্যাক্টর অথেন্টিকেশনMulti-Factor Authentication (MFA)পাসওয়ার্ডের পাশাপাশি আরও একটি স্বাধীন প্রমাণ (যেমন ফোনে পাঠানো কোড, ফিঙ্গারপ্রিন্ট) দাবি করে পরিচয় যাচাইকে শক্তিশালী করা। সমর্থন করে (এখানে শুধু নাম উল্লেখ করছি — এর গভীর প্রোটোকল-স্তরের বিস্তারিত এই কোর্সের বিষয় নয়)।
একবার অথেন্টিকেট হয়ে গেলে, সেই ইউজারের হয়ে চালু হওয়া প্রতিটি প্রসেস সেই ইউজারের পরিচয়/পারমিশন বহন করে চলে — এটিই সরাসরি L46-এর প্রোটেকশন ডোমেইনের ভিত্তি তৈরি করে দেয়: ইউজারের পরিচয়ই কার্যত ঠিক করে দেয় তার প্রসেসগুলো কোন প্রোটেকশন ডোমেইনে থাকবে, অর্থাৎ কোন অবজেক্টে কোন অপারেশন করতে পারবে।
২ · অ্যাক্সেস কন্ট্রোল পলিসি — DAC বনাম MAC
L46-এ আমরা দেখেছি অ্যাক্সেস ম্যাট্রিক্স কীভাবে সংরক্ষিত হয় (ACL বনাম Capability list)। এই পাঠে প্রশ্নটা ভিন্ন — কে সিদ্ধান্ত নেয় কোন পারমিশন থাকবে? এটিই অ্যাক্সেস কন্ট্রোল পলিসি-র প্রশ্ন, এবং এখানে দুটি প্রধান মডেল আছে।
রিসোর্সের মালিক ঠিক করে অন্য কে অ্যাক্সেস পাবে। চিরাচরিত Unix ফাইল-পারমিশন মডেল (owner/group/other × read/write/execute) এর ক্লাসিক উদাহরণ — একজন ফাইলের মালিক নিজের ইচ্ছামতো অন্যকে অ্যাক্সেস দিতে বা কেড়ে নিতে পারেন।
রিসোর্সের মালিক নয়, সিস্টেম নিজেই কেন্দ্রীয়ভাবে সিকিউরিটি লেবেল/শ্রেণিবিন্যাসের ভিত্তিতে নিয়ম বলবৎ করে। উচ্চ-নিরাপত্তা পরিবেশে ব্যবহৃত হয় (যেমন সরকারি/সামরিক সিস্টেম) — এমনকি মালিকও এই নিয়ম ওভাররাইড করতে পারেন না।
DAC-এ ক্ষমতা ব্যবহারকারীর হাতে (আমার ফাইল, আমি ঠিক করব কে দেখতে পারবে); MAC-এ ক্ষমতা সিস্টেমের নিয়মের হাতে (সিকিউরিটি লেবেল যা বলে তাই হবে, ব্যবহারকারীর ইচ্ছার উপর নির্ভর করে না)।
৩ · Unix পারমিশন-বিট মডেল — একটি বাস্তব DAC উদাহরণ
Unix-পরিবারের ফাইল সিস্টেমে প্রতিটি ফাইলের সাথে তিন সেট পারমিশন যুক্ত থাকে — owner (ফাইলের মালিক), group (মালিকের গ্রুপের সদস্যরা), এবং other (বাকি সবাই)। প্রতিটি সেটে তিনটি বিট — read (r), write (w), execute (x)। কোনো নির্দিষ্ট অনুরোধকারী ইউজার কোন সেটের আওতায় পড়বে তা ঠিক হয় এভাবে —
- অনুরোধকারী যদি ফাইলের মালিক হন → owner পারমিশন প্রযোজ্য।
- না হলে, তিনি যদি ফাইলের গ্রুপের সদস্য হন → group পারমিশন প্রযোজ্য।
- উপরের কোনোটিই না হলে → other পারমিশন প্রযোজ্য।
নিচের কোড সেলে এই যুক্তিটি একটি সত্যিকারের পারমিশন-চেকার ফাংশন হিসেবে লেখা হলো।
# Unix-স্টাইল ৯-বিট পারমিশন চেকার -- বাস্তব ফাইল সিস্টেম নয়, শুধুই সিমুলেটেড ডেটা স্ট্রাকচার
def check_access(requesting_user, file_owner, file_group, requesting_user_group,
permissions, requested_op):
"""
permissions: {"owner": (r, w, x), "group": (r, w, x), "other": (r, w, x)}
requested_op: "read" | "write" | "execute"
"""
op_index = {"read": 0, "write": 1, "execute": 2}[requested_op]
if requesting_user == file_owner:
applicable_set = "owner"
elif requesting_user_group == file_group:
applicable_set = "group"
else:
applicable_set = "other"
allowed = permissions[applicable_set][op_index]
return applicable_set, allowed
# একটি ফাইলের পারমিশন: rw- র-- --- (owner: rw-, group: r--, other: ---)
file_permissions = {
"owner": (True, True, False),
"group": (True, False, False),
"other": (False, False, False),
}
file_owner = "arif"
file_group = "developers"
scenarios = [
("arif", "developers", "write"), # মালিক নিজেই, write চাইছে
("nasrin","developers", "read"), # একই গ্রুপের সদস্য, read চাইছে
("nasrin","developers", "write"), # একই গ্রুপের সদস্য, কিন্তু write নেই group-এ
("rahim", "guests", "read"), # সম্পূর্ণ অপরিচিত, other হিসেবে গণ্য
]
for user, user_group, op in scenarios:
which_set, allowed = check_access(user, file_owner, file_group, user_group,
file_permissions, op)
verdict = "অনুমোদিত" if allowed else "প্রত্যাখ্যাত"
print(f"{user} ({which_set} সেট প্রযোজ্য) -> {op}: {verdict}")
nasrin ও rahim কেউই ফাইলের মালিক নন, কিন্তু nasrin
developers গ্রুপের সদস্য হওয়ায় group পারমিশন (r--) পান, আর rahim সম্পূর্ণ অপরিচিত হওয়ায় other
পারমিশন (---) পান — একই ব্যক্তি না হয়েও দুজনের ফলাফল ভিন্ন, কারণ প্রযোজ্য পারমিশন-সেটই ভিন্ন।
অথেন্টিকেশন ঠিক করে "আপনি কে," আর অ্যাক্সেস কন্ট্রোল পলিসি (DAC/MAC) ঠিক করে "আপনার পরিচয়ের ভিত্তিতে কী করার অনুমতি আছে।" Unix-এর পারমিশন বিট হলো DAC-এর একটি বাস্তব, সর্বব্যাপী বাস্তবায়ন — এবং এটিই L46-এর অ্যাক্সেস ম্যাট্রিক্সের একটি হাতে-কলমে, সরলীকৃত ACL-স্টাইল প্রয়োগ।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ একজন ব্যবহারকারী একবার লগইন করার পর, তার প্রতিটি প্রসেসের প্রতিটি অ্যাকশনে কি আবার নতুন করে অথেন্টিকেশন হয়?
না। অথেন্টিকেশন লগইনের সময় একবারই ঘটে (এককালীন পরিচয় যাচাই)। এরপর সেই ইউজারের হয়ে চালু হওয়া প্রতিটি প্রসেস সেই পরিচয়/পারমিশন সেট বহন করে চলতে থাকে — প্রতিটি ফাইল অ্যাক্সেস বা সিস্টেম কলে আবার পাসওয়ার্ড চাওয়া হয় না। পরবর্তী প্রতিটি অ্যাকশনে যা যাচাই হয় তা হলো অ্যাক্সেস কন্ট্রোল (এই পরিচয়ের কি এই নির্দিষ্ট অপারেশনের অনুমতি আছে) — এটি অথেন্টিকেশনের চেয়ে ভিন্ন, দ্রুততর একটি চেক।
প্র ০২ DAC মডেলে একজন ফাইল-মালিক ভুল করে (বা প্রতারিত হয়ে) খুবই সংবেদনশীল একটি ফাইল সবার জন্য উন্মুক্ত করে দিলে কী হয়? MAC কীভাবে এটি প্রতিরোধ করত?
DAC-এ যেহেতু ক্ষমতা সম্পূর্ণ মালিকের হাতে, তার ভুল সিদ্ধান্তই চূড়ান্ত — কোনো কেন্দ্রীয় নিয়ম তাকে থামায় না, তাই ফাইলটি সত্যিই উন্মুক্ত হয়ে যাবে। MAC-এ এই ফাইলের একটি নির্দিষ্ট সিকিউরিটি লেবেল (যেমন "গোপনীয়") থাকত, এবং সিস্টেম কেন্দ্রীয়ভাবে বলবৎ করত যে সেই লেবেলের নিচে থাকা ইউজাররাই এটি দেখতে পারবে — মালিক নিজে চাইলেও এই নিয়ম পরিবর্তন/ওভাররাইড করতে পারতেন না, তাই একটি একক ভুল সিদ্ধান্ত পুরো সুরক্ষা ভেঙে দিতে পারত না।
প্র ০৩
উপরের কোড সেলে যদি rahim-এর জন্য requesting_user_group ভুলবশত "developers" দেওয়া হতো, ফলাফল কী পাল্টাত এবং কেন?
তাহলে check_access ফাংশনে requesting_user_group == file_group শর্তটি সত্য হয়ে
যেত (যেহেতু উভয়ই "developers"), আর rahim ভুলভাবে group পারমিশন সেট (r--)
পেয়ে যেতেন — যদিও বাস্তবে তিনি সেই গ্রুপের সদস্যই নন। এটি দেখায় Unix পারমিশন মডেলের নিরাপত্তা সম্পূর্ণভাবে
নির্ভর করে ইউজারের গ্রুপ-সদস্যতা তথ্য সঠিকভাবে ব্যবস্থাপনা করার উপর — এই তথ্যই যদি ভুল/জালিয়াতিপূর্ণ হয়,
পারমিশন-চেক নিজে যতই যুক্তিসঙ্গত হোক, ফল ভুল হবে।
অনুশীলন
-
পরীক্ষা করুন: উপরের কোড সেলে
file_permissions["other"]-কে(True, False, False)করে (অর্থাৎ other-দের জন্য read অনুমতি দিয়ে) Run চাপুন —rahim-এর read অনুরোধের ফলাফল কী হয়?rahim এখনও "other" সেটের আওতায় পড়বেন (তিনি মালিকও নন, group সদস্যও নন), কিন্তু এবার other-এর read বিট True হওয়ায় তার read অনুরোধ "অনুমোদিত" দেখাবে। এটি নিশ্চিত করে যে ফাংশনটি সঠিকভাবে "কোন সেট প্রযোজ্য" ও "সেই সেটে কী অনুমতি আছে" — এই দুটি স্বতন্ত্র সিদ্ধান্ত আলাদাভাবে নিচ্ছে।
-
চিন্তা করুন: আপনার নিজের কম্পিউটারে (Linux/macOS হলে টার্মিনালে
ls -l) একটি ফাইলের পারমিশন দেখুন — সেটিকে owner/group/other × rwx হিসেবে ভেঙে বুঝার চেষ্টা করুন এই পাঠের মডেলের সাথে মিলিয়ে।ls -l-এর আউটপুটে যেমন-rw-r--r--দেখা যায়, প্রথম অক্ষরের পর প্রতি তিনটি অক্ষর যথাক্রমে owner (rw-), group (r--), other (r--) নির্দেশ করে — ঠিক এই পাঠের কোড সেলে ব্যবহৃত(True, True, False)-স্টাইল ট্রিপলের সরাসরি বাস্তব প্রতিনিধিত্ব।chmodকমান্ড দিয়ে এই বিটগুলোই পরিবর্তন করা হয়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- L46 · প্রোটেকশন ডোমেইন ও অ্যাক্সেস ম্যাট্রিক্স আগের পাঠ ACL ও Capability list — অ্যাক্সেস ম্যাট্রিক্স সংরক্ষণের দুটি বাস্তব উপায়, এই পাঠের DAC/MAC আলোচনার ভিত্তি।
- L48 · প্রিভিলেজ লেভেল ও রিং প্রোটেকশন পরের পাঠ অ্যাক্সেস কন্ট্রোল সফটওয়্যার-স্তরে হলেও, এর পেছনের হার্ডওয়্যার প্রয়োগ — রিং প্রোটেকশন — কীভাবে কাজ করে তা দেখুন।
- Cybersecurity কোর্স গভীর বিস্তারিত পাসওয়ার্ড হ্যাশিং, MFA প্রোটোকল, এবং অথেন্টিকেশন/অথোরাইজেশনের সম্পূর্ণ নিরাপত্তা-প্রকৌশল দিক এখানে গভীরভাবে আলোচিত।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৬টি পাঠ M12 (ভার্চুয়ালাইজেশন) ও M13 (কেস স্টাডি) সহ বাকি পাঠগুলো দেখুন।