1. “অধ্যায় 91: Privacy Engineering & Data Minimization” scenario-তে মূল control কোনটি?
প্রয়োজনীয় minimum data, short retention ও explicit purpose—এটাই অধ্যায় 91: Privacy Engineering & Data Minimization-এর প্রধান defensive control.
Data lifecycle, purpose limitation and retention.
অগ্রগতি এই browser-এ স্থানীয়ভাবে সংরক্ষিত হবে।
গাছের reminder app জন্মতারিখ, ঠিকানা ও location চাইছিল—যদিও কাজের জন্য দরকার ছিল না। শাওন data inventory করে অপ্রয়োজনীয় field বাদ দিল, retention সীমা ও deletion owner নির্ধারণ করল। বৃষ্টি ম্যাম বললেন, “সৌরভ সোনা, আগে সমস্যাটাকে ছোট করে বুঝি—কোন সম্পদ, কার অনুমতি, আর কোন সীমার মধ্যে কাজ?” সৌরভ বোর্ডে একটি data-flow এঁকে সম্ভাব্য ভুলের জায়গা চিহ্নিত করল। তারা বাস্তব কোনো account বা website-এ হাত না দিয়ে synthetic উদাহরণে hypothesis যাচাই করল।
বৃষ্টি ম্যাম জিজ্ঞেস করলেন, “সৌরভ, গল্পের চরিত্রটি কোন সীমা পেরোতে দিচ্ছিল?” তারা বোর্ডে asset, actor, trust boundary আর expected outcome লিখল। ভুলটি শুধু একটি tool-এর সমস্যা নয়; server কী অনুমতি দিচ্ছে, আর সেই সিদ্ধান্ত যাচাই করা যায় কি না—সেটিই মূল প্রশ্ন।
তারপর তারা বাস্তব service ছুঁয়ে না দেখে synthetic record-এ একই decision অনুশীলন করল। প্রথমে স্বাভাবিক অনুমোদিত flow, তারপর ভুল পরিচয়/invalid state, শেষে fix-এর পর retest। বৃষ্টি ম্যাম বললেন, “সোনা, নিরাপদ শেখা মানে কেবল সমস্যা দেখানো নয়—সীমা মেনে প্রতিরক্ষা প্রমাণ করাও।”
সমস্যা: অপ্রয়োজনীয় personal data breach impact ও legal/privacy burden বাড়ায়।
মূল নিয়ম: প্রয়োজনীয় minimum data, short retention ও explicit purpose। এই নিয়মটি Data lifecycle, purpose limitation and retention.-এর সঙ্গে মিলিয়ে threat boundary-তে enforce করো; শুধু UI, client-side check বা model instruction-এ ভরসা কোরো না। প্রত্যাখ্যানের কারণ user-কে নিরাপদভাবে জানাও, আর diagnosis-এর জন্য সীমিত redacted event রাখো।
নিচের snippet-টি illustrative pseudocode। এটি কোনো বাইরের target-এ পরীক্ষা চালায় না; control কীভাবে server-side-এ বসে তা দেখায়।
stored = minimize(input, required_fields)
expire_after(policy.retention)Review checklist: explicit scope, least privilege, malformed/unauthorized negative case, privacy-safe logging এবং post-fix retest।
feature-এ analytics-এর জন্য পূর্ণ birth date দরকার নেই। privacy by design? কেবল isolated mock বা লিখিত অনুমতিপ্রাপ্ত lab-এ চেষ্টা করো। expected result এবং deny case লিখে রাখো।
প্রয়োজনীয় minimum data, short retention ও explicit purpose Minimize collection, retention limits, access controls, deletion. remediation-এর owner ও retest ফলাফলও নথিভুক্ত করো।
Review: owner, telemetry, failure behavior ও retest ফলাফল নথিভুক্ত করো।
Scope, synthetic setup, পর্যবেক্ষণ, ঝুঁকি, remediation ও retest লিখে রাখো। secret বা ব্যক্তিগত তথ্য যোগ কোরো না।
Mock feature-এর data inventory থেকে unnecessary fields বাদ দাও.
Scenario: feature-এ analytics-এর জন্য পূর্ণ birth date দরকার নেই। privacy by design?
একটি defensive সিদ্ধান্ত বেছে নিয়ে ল্যাব চালু করো চাপো। এটি synthetic scenario; কোনো network request করা হয় না।
অপ্রয়োজনীয় personal data breach impact ও legal/privacy burden বাড়ায়।—সফল সমাধানে scope, control এবং retest—তিনটিই উল্লেখ করো।
প্রতিটি প্রশ্নে একটি উত্তর বেছে নাও। ব্যাখ্যাসহ স্কোর নিচে দেখা যাবে।
প্রয়োজনীয় minimum data, short retention ও explicit purpose—এটাই অধ্যায় 91: Privacy Engineering & Data Minimization-এর প্রধান defensive control.
অপ্রয়োজনীয় personal data breach impact ও legal/privacy burden বাড়ায়। হওয়ায় access, data বা service impact হতে পারে.
Synthetic isolated environment production data বা অন্যের service-কে ঝুঁকিতে ফেলে না.
Negative case control bypass বা fail-open আচরণ ধরতে সাহায্য করে.
এতে তদন্তযোগ্য প্রমাণ থাকে, কিন্তু secret বা customer payload লগ হয় না.
আগে scope স্থির করলে পরীক্ষা অনুমোদিত ও সীমাবদ্ধ থাকে.
validation ব্যর্থতায় fail-closed আচরণ নিরাপদ.
Code/config ও synthetic test control বাস্তবে কার্যকর কি না দেখায়.
Retest fix ও regression দুটোই যাচাই করে.
এই তথ্য remediation-কে actionable করে, sensitive data প্রকাশ না করে.
স্কোর: ০ / ১০
আরও পড়ার জন্য প্রতিষ্ঠিত security standards ও guidance দেখো; প্রতিটি lab অনুমোদিত বা synthetic environment-এ করো।