মোবাইল ডিভাইস ম্যানেজমেন্ট ও অ্যাপ পারমিশন মডেল
এই পাঠে যা শিখবেন
- MDM কী এবং এন্টারপ্রাইজ কেন ডিভাইস ম্যানেজমেন্ট নীতি প্রয়োগ করে
- BYOD নীতির নিরাপত্তা ট্রেড-অফ — ব্যক্তিগত সুবিধা বনাম কর্পোরেট ডেটা ঝুঁকি
- রানটাইম পারমিশন মডেল পুরনো ইনস্টল-টাইম মডেলের চেয়ে কেন নিরাপদ
- একটি সাধারণ পারমিশন-রিকোয়েস্ট ও অ্যাক্সেস-চেক ফ্লো বাস্তবায়ন
১ · MDM — এন্টারপ্রাইজ ডিভাইসে নীতি প্রয়োগের টুল
MDM (Mobile Device Management)MDMএন্টারপ্রাইজ IT টিমকে কর্মীদের মোবাইল ডিভাইসে দূর থেকে নিরাপত্তা নীতি প্রয়োগ, পর্যবেক্ষণ ও ব্যবস্থাপনার ক্ষমতা দেওয়া সফটওয়্যার সিস্টেম। হলো এন্টারপ্রাইজ পর্যায়ের টুলিং যা প্রতিষ্ঠানকে কর্মীদের ডিভাইসে নিরাপত্তা নীতি প্রয়োগ করতে দেয়। সাধারণ MDM ক্ষমতার মধ্যে থাকে —
ডিভাইস আনলক করার জন্য একটি ন্যূনতম নিরাপত্তা স্তর নিশ্চিত করে।
ডিভাইস স্টোরেজ এনক্রিপ্টেড আছে তা নিশ্চিত করে — চুরি হলেও ডেটা পড়া কঠিন।
হারানো/চুরি হওয়া ডিভাইস থেকে দূর থেকে কর্পোরেট ডেটা মুছে ফেলার ক্ষমতা।
শুধুমাত্র অনুমোদিত অ্যাপ ইনস্টল করার অনুমতি দেয় — অজানা উৎস থেকে ইনস্টল প্রতিরোধ করে।
২ · BYOD — সুবিধা বনাম ঝুঁকি
BYOD (Bring Your Own Device)BYODকর্মীদের নিজস্ব ব্যক্তিগত মোবাইল ডিভাইস অফিসের কাজে ব্যবহারের অনুমতি দেওয়ার নীতি — প্রতিষ্ঠানকে হার্ডওয়্যার কেনার খরচ বাঁচায়, কিন্তু ব্যক্তিগত ও কর্পোরেট ডেটা একই ডিভাইসে মিশে যায়। নীতিতে ব্যক্তিগত ও কর্পোরেট ডেটা একই ডিভাইসে সহাবস্থান করে। এটি সুবিধাজনক (কর্মীরা তাদের পরিচিত ডিভাইস ব্যবহার করে, প্রতিষ্ঠান হার্ডওয়্যার কেনার খরচ বাঁচায়) কিন্তু নিরাপত্তার দিক থেকে জটিল — একটি ব্যক্তিগত ডিভাইস হারালে বা চুরি হলে, সেটিতে থাকা কর্পোরেট ইমেইল, ফাইল, বা অভ্যন্তরীণ অ্যাপ ডেটাও একই ঝুঁকিতে পড়ে। এই কারণেই MDM এর রিমোট-ওয়াইপ ক্ষমতা BYOD প্রেক্ষাপটে বিশেষভাবে গুরুত্বপূর্ণ — যদিও বাস্তবে সম্পূর্ণ-ডিভাইস ওয়াইপ ব্যক্তিগত ডেটাও মুছে ফেলতে পারে, তাই অনেক MDM সমাধান শুধু "কর্পোরেট কন্টেইনার" আলাদাভাবে ওয়াইপ করার সুবিধা দেয়।
৩ · রানটাইম পারমিশন মডেল — least-privilege মোবাইলে প্রয়োগ
পুরনো মোবাইল OS মডেলে, একটি অ্যাপ ইনস্টল করার সময়ই তার সব চাওয়া পারমিশন একবারে গ্রহণ বা প্রত্যাখ্যান করতে হতো — ব্যবহারকারী চাইলেও শুধু একটি নির্দিষ্ট পারমিশন বাদ দিয়ে অ্যাপটি ইনস্টল করতে পারতেন না। আধুনিক Android ও iOS "রানটাইম পারমিশন মডেল" ব্যবহার করে — একটি অ্যাপ যখন প্রথমবার কোনো সংবেদনশীল ফিচার (ক্যামেরা, লোকেশন, কন্ট্যাক্টস) ব্যবহার করতে চায়, ঠিক তখনই ব্যবহারকারীর কাছে পারমিশন চাওয়া হয় — এবং ব্যবহারকারী প্রতিটি পারমিশন আলাদাভাবে গ্রান্ট বা পরে রিভোক করতে পারেন।
এটি L31-এ দেখা least-privilege নীতিরই সরাসরি প্রয়োগ — প্রতিটি অ্যাপ শুধুমাত্র তার আসলেই প্রয়োজনীয় অ্যাক্সেসই পায়, এবং ব্যবহারকারী যেকোনো সময় সেই অ্যাক্সেস প্রত্যাহার করতে পারেন। "সব-বা-কিছুই-না" ইনস্টল-টাইম মডেলে, একটি অ্যাপ ব্যবহার করতে হলে ব্যবহারকারীকে তার সব চাওয়া পারমিশন মেনে নিতে হতো — এমনকি অপ্রাসঙ্গিক পারমিশনও — যা একটি একক দুর্বলতা বা ক্ষতিকর আপডেটকে অনেক বেশি শক্তিশালী করে তুলত।
৪ · একটি রানটাইম পারমিশন ফ্লো সিমুলেশন
নিচের কোড সেলটি একটি সরলীকৃত রানটাইম-পারমিশন সিস্টেম সিমুলেট করে — একটি অ্যাপ পারমিশন চায়, ব্যবহারকারী সিদ্ধান্ত নেন, এবং ফিচার ব্যবহারের আগে অ্যাপ সবসময় বর্তমান অনুমতি যাচাই করে (পারমিশন কখনো "মনে রাখা" হয় না, প্রতিবার প্রকৃত অবস্থা যাচাই করা হয়)।
granted_permissions = {} # app_name -> set of granted permission names
def request_permission(app, permission, user_decision):
"""ব্যবহারকারীর সিদ্ধান্ত অনুযায়ী পারমিশন গ্রান্ট করে (শুধুমাত্র True হলে)।"""
if user_decision:
granted_permissions.setdefault(app, set()).add(permission)
return "granted"
return "denied"
def check_access(app, permission):
"""ফিচার ব্যবহারের আগে অ্যাপ যা কল করবে — বর্তমান অনুমতি সরাসরি যাচাই করে।"""
return permission in granted_permissions.get(app, set())
# --- সিমুলেশন ---
app = "WeatherNow"
print("ধাপ ১ — অ্যাপ প্রথমবার ক্যামেরা ব্যবহারের চেষ্টা করে, পারমিশন না চেয়েই:")
print(" অ্যাক্সেস অনুমোদিত?", check_access(app, "CAMERA"))
print()
print("ধাপ ২ — অ্যাপ লোকেশন পারমিশন চায়, ব্যবহারকারী অনুমতি দেন:")
result = request_permission(app, "LOCATION", user_decision=True)
print(f" request_permission ফলাফল: {result}")
print(" লোকেশন অ্যাক্সেস এখন?", check_access(app, "LOCATION"))
print()
print("ধাপ ৩ — অ্যাপ ক্যামেরা পারমিশন চায়, ব্যবহারকারী প্রত্যাখ্যান করেন:")
result = request_permission(app, "CAMERA", user_decision=False)
print(f" request_permission ফলাফল: {result}")
print(" ক্যামেরা অ্যাক্সেস এখন?", check_access(app, "CAMERA"))
check_access কখনোই ধরে নেয় না যে পারমিশন আছে; এটি প্রতিবার
granted_permissions-এর বর্তমান অবস্থা যাচাই করে। এই কারণেই ব্যবহারকারী Settings থেকে
যেকোনো সময় একটি পারমিশন রিভোক করলে, পরবর্তী check_access কলেই সেটি তাৎক্ষণিকভাবে প্রতিফলিত হবে —
অ্যাপকে পুনরায় চালু করার প্রয়োজন নেই।
MDM ও রানটাইম পারমিশন মডেল একই মূলনীতির দুটি ভিন্ন স্তরে প্রয়োগ — MDM প্রতিষ্ঠান-স্তরে ডিভাইসের উপর নিয়ন্ত্রণ দেয়, রানটাইম পারমিশন মডেল অ্যাপ-স্তরে ব্যক্তিগত রিসোর্সের উপর নিয়ন্ত্রণ দেয়। দুটোই একই লক্ষ্যে কাজ করে — ডিফল্টে সর্বনিম্ন অ্যাক্সেস, প্রয়োজনে স্পষ্ট অনুমোদন। M8 এখানেই শেষ — পরের মডিউল থেকে আমরা সোশ্যাল ইঞ্জিনিয়ারিং ও ফিশিং-এ প্রবেশ করব, যেখানে টেকনিক্যাল কন্ট্রোল নয়, মানুষই মূল লক্ষ্যবস্তু।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ BYOD পরিস্থিতিতে একটি সম্পূর্ণ-ডিভাইস রিমোট-ওয়াইপ কেন সবসময় সেরা সমাধান নয়?
কারণ BYOD ডিভাইসে ব্যবহারকারীর ব্যক্তিগত ছবি, বার্তা ও অ্যাপ ডেটাও থাকে — একটি সম্পূর্ণ-ডিভাইস ওয়াইপ সেই ব্যক্তিগত ডেটাও অপরিবর্তনীয়ভাবে মুছে ফেলবে, যা কর্মীর জন্য অন্যায্য হতে পারে (বিশেষত যদি ডিভাইসটি আসলে হারায়নি, শুধু চাকরি ছেড়ে দিয়েছেন)। এই কারণেই অনেক MDM সমাধান একটি পৃথক "কর্পোরেট কন্টেইনার" তৈরি করে যা স্বাধীনভাবে ওয়াইপ করা যায়, ব্যক্তিগত ডেটাকে অক্ষত রেখে।
প্র ০২ রানটাইম পারমিশন মডেলে ব্যবহারকারী একটি পারমিশন রিভোক করলে অ্যাপের আচরণ কী হওয়া উচিত?
অ্যাপকে অবশ্যই সেই মুহূর্ত থেকেই সংশ্লিষ্ট ফিচার নিষ্ক্রিয়/অনুপলব্ধ দেখাতে হবে এবং কখনোই পুরনো
(ক্যাশ করা) অনুমতির উপর নির্ভর করা উচিত নয় — প্রতিবার ব্যবহারের আগে বর্তমান অনুমতি সরাসরি যাচাই করতে হবে,
ঠিক যেমন উপরের কোডের check_access ফাংশনটি করে। ক্যাশ করা অনুমতির উপর নির্ভর করলে একজন
ব্যবহারকারী পারমিশন প্রত্যাহার করার পরও অ্যাপ ভুলভাবে অ্যাক্সেস চালিয়ে যেতে পারে।
প্র ০৩ MDM ও রানটাইম পারমিশন মডেল — এই দুটি নিয়ন্ত্রণ স্তর একে অপরের পরিপূরক কীভাবে?
MDM ডিভাইস-স্তরে নিয়ন্ত্রণ দেয় (কোন অ্যাপ ইনস্টল করা যাবে, এনক্রিপশন বাধ্যতামূলক করা, হারানো ডিভাইস ওয়াইপ করা) — এটি প্রতিষ্ঠানের দৃষ্টিকোণ থেকে "কোন সিস্টেম বিশ্বস্ত"। রানটাইম পারমিশন মডেল অ্যাপ-স্তরে নিয়ন্ত্রণ দেয় (একটি নির্দিষ্ট অ্যাপ কোন নির্দিষ্ট রিসোর্স অ্যাক্সেস করতে পারে) — এটি ব্যবহারকারীর দৃষ্টিকোণ থেকে "কোন অ্যাপ বিশ্বস্ত"। দুটো স্তর একসাথে একটি সম্পূর্ণ defense-in-depth কাঠামো তৈরি করে।
অনুশীলন
-
চিন্তা করুন: আপনার প্রতিষ্ঠান/স্কুল যদি BYOD নীতি চালু করে, আপনি ব্যক্তিগত ডিভাইসে কর্পোরেট
ইমেইল অ্যাক্সেস দেওয়ার আগে কী কী নিরাপত্তা শর্ত (যেমন PIN, এনক্রিপশন) দাবি করবেন?
একটি যুক্তিসঙ্গত সেট: বাধ্যতামূলক ডিভাইস PIN/বায়োমেট্রিক লক, ডিভাইস-স্টোরেজ এনক্রিপশন সক্রিয় থাকা, OS-এর একটি ন্যূনতম আপডেটেড ভার্সন (পুরনো, আনপ্যাচড OS এড়াতে — ties to L16), এবং হারানো/চুরি হলে অন্তত কর্পোরেট ডেটা রিমোট-ওয়াইপ করার অনুমতি।
-
পরীক্ষা করুন: উপরের কোডে ধাপ ৩-এর পর একটি নতুন লাইন যোগ করুন যা আবার
request_permission(app, "CAMERA", user_decision=True)কল করে, তারপর আবারcheck_access(app, "CAMERA")চেক করুন — ফলাফল কী হবে?এবার
check_access(app, "CAMERA")Trueরিটার্ন করবে — কারণ ব্যবহারকারী এবার অনুমতি দিয়েছেন, এবংgranted_permissions["WeatherNow"]-এ"CAMERA"যোগ হয়ে গেছে। এটি দেখায় রানটাইম মডেলে সিদ্ধান্ত স্থায়ী নয় — ব্যবহারকারী যেকোনো সময় মত পরিবর্তন করতে পারেন।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৬০টি পাঠ পরবর্তী পাঠ থেকে M9 শুরু — সোশ্যাল ইঞ্জিনিয়ারিং সাইকোলজি ও কৌশল।
- System Design & Software Architecture কোর্স সঙ্গী কোর্স এন্টারপ্রাইজ-স্কেলে অ্যাক্সেস কন্ট্রোল ও অথেন্টিকেশন আর্কিটেকচার কীভাবে ডিজাইন করা হয় দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design ও Cybersecurity — সব এক জায়গায়।