ব্লগে ফিরে যানAI নিরাপত্তা

অভ্যন্তরীণ উইকিতে PII: Confluence-এ গ্রাহকের তথ্য

সাপোর্ট টিম গ্রাহকের অ্যাকাউন্টের স্ক্রিনশট দিয়ে প্রক্রিয়া ডকুমেন্ট করে। তিন বছরে এটি আপনার নলেজ বেসে হাজার হাজার GDPR ডেটা মিনিমাইজেশন লঙ্ঘনে পরিণত হয়।

March 6, 20266 মিনিট পড়া
Confluence GDPRinternal wiki PIIcustomer datadocumentation privacydata minimization

অভ্যন্তরীণ নলেজ বেসে স্ক্রিনশট PII

অভ্যন্তরীণ নলেজ বেস — Confluence, Notion, SharePoint, GitBook — একটি নির্দিষ্ট ধরনের PII সমস্যা বহন করে যা স্ট্যান্ডার্ড কমপ্লায়েন্স টুল মিস করে: প্রক্রিয়া ডকুমেন্টেশনের জন্য ব্যবহৃত স্ক্রিনশটে এমবেড করা গ্রাহকের ব্যক্তিগত তথ্য।

হাজার হাজার সাপোর্ট ও অপারেশন টিমে এই প্যাটার্নটি বারবার দেখা যায়।

একজন সাপোর্ট এজেন্ট একটি অস্বাভাবিক অ্যাকাউন্ট সেটআপ খুঁজে পান। সমস্যাটি ডকুমেন্ট করতে তিনি গ্রাহকের অ্যাকাউন্ট পেজের একটি স্ক্রিনশট নেন। স্ক্রিনশটে UI হেডারে গ্রাহকের নাম, অ্যাকাউন্ট সেটিংসে তাদের ইমেইল এবং প্ল্যানের বিবরণ দেখা যায়।

আর্টিকেলটি অভ্যন্তরীণ নলেজ বেসে প্রকাশিত হয়। এখন ১৫০ জন সাপোর্ট এজেন্ট এটি দেখতে পারেন। বাইরের হেল্পডেস্কের ১২ জন ঠিকাদারও দেখতে পারেন। আর্টিকেলটি কার্যকর। এটি সেই এজ কেস সামলানোর পদ্ধতি দেখায়। ভবিষ্যতে সেই সেটআপে যে কোনো এজেন্ট পড়বেন।

তিন বছর পরে, নলেজ বেসে এমন ৮৪৭টি আর্টিকেল রয়েছে। প্রতিটিতে গ্রাহকের অ্যাকাউন্টের স্ক্রিনশট আছে। দেখানো গ্রাহকরা তাদের রেকর্ডের এই গৌণ ব্যবহারে সম্মতি দেননি। বেশিরভাগ জানেনও না যে তাদের তথ্য সেখানে সংরক্ষিত আছে।

এটি ছোট কোনো সমস্যা নয়। প্রতিটি নতুন আর্টিকেলের সাথে এটি বাড়তে থাকে।

GDPR এক্সপোজার: এটি কেন গুরুত্বপূর্ণ

নলেজ বেস স্ক্রিনশটের জন্য GDPR বিশ্লেষণ সরাসরি।

ডেটা মিনিমাইজেশন (Article 5(1)(c)): ব্যক্তিগত তথ্য অবশ্যই "পর্যাপ্ত, প্রাসঙ্গিক এবং প্রয়োজনীয়তার মধ্যে সীমাবদ্ধ" হতে হবে। অ্যাকাউন্ট সেটআপ সংক্রান্ত নলেজ বেস আর্টিকেলে আসল গ্রাহকের নাম ও ইমেইলের প্রয়োজন নেই। একটি ব্লার করা স্ক্রিনশট একই উদ্দেশ্য পূরণ করে। লাইভ গ্রাহক ডেটা অন্তর্ভুক্ত করা অপ্রয়োজনীয়।

উদ্দেশ্য সীমাবদ্ধতা (Article 5(1)(b)): এক উদ্দেশ্যে সংগৃহীত তথ্য — গ্রাহক সেবা — বৈধ ভিত্তি ছাড়া অন্য উদ্দেশ্যে — অভ্যন্তরীণ প্রক্রিয়া ডকস — পুনরায় ব্যবহার করা যাবে না। অ্যাকাউন্ট রেকর্ড সেবা প্রদানের জন্য সংগ্রহ করা হয়েছিল, অভ্যন্তরীণ ডকুমেন্টেশনের জন্য নয়। এই দুটি স্বতন্ত্র প্রক্রিয়াকরণের উদ্দেশ্য। একই রেকর্ড উভয় উদ্দেশ্যে ব্যবহার করতে বৈধ আইনি ভিত্তি প্রয়োজন যা বেশিরভাগ টিম স্থাপন করেনি।

অ্যাক্সেস নিয়ন্ত্রণ (Article 5(1)(f) এবং Article 32): ব্যক্তিগত তথ্য রক্ষায় উপযুক্ত প্রযুক্তিগত ব্যবস্থা থাকতে হবে। সমস্ত ১৫০ এজেন্ট ও ঠিকাদারদের জন্য খোলা একটি টুলে গ্রাহকের অ্যাকাউন্ট স্ক্রিনশট — অন্তর্নিহিত অ্যাকাউন্ট সিস্টেমে অ্যাক্সেস নেই এমন ব্যক্তিসহ — অতিরিক্ত বিস্তৃত অ্যাক্সেস তৈরি করে।

মুছে ফেলার অধিকার (Article 17): মুছে ফেলার অনুরোধকারী একজন ডেটা সাবজেক্টের অধিকার আছে "অযথা বিলম্ব ছাড়াই" তাদের রেকর্ড সরানোর। যদি তাদের তথ্য এমবেড করা স্ক্রিনশট হিসেবে ২৩টি নলেজ বেস আর্টিকেলে থাকে, তাহলে অনুরোধটি সমস্ত ২৩টি আর্টিকেল খুঁজে বের করে আপডেট করার দাবি রাখে। একটি সিস্টেম ছাড়া এটি কঠিন। আমাদের GDPR right-to-erasure গাইড বিস্তারিত পদক্ষেপ কভার করে।

এগুলোর কোনোটিই প্রান্তিক ব্যাখ্যা নয়। এগুলো একটি সাধারণ অনুশীলনে বিধিমালার পাঠ্যের সরাসরি প্রয়োগ।

অ্যাক্সেস কন্ট্রোল বাইপাস

Confluence স্ক্রিনশটের সবচেয়ে গুরুতর কমপ্লায়েন্স সমস্যা হলো তারা যে অ্যাক্সেস কন্ট্রোল বাইপাস তৈরি করে।

সাপোর্ট টিম গ্রাহকের অ্যাকাউন্ট সিস্টেম কে দেখতে পারবে তা সীমিত করতে রোল-বেসড অ্যাক্সেস কন্ট্রোল (RBAC) ব্যবহার করে। টায়ার ১ এজেন্টরা মৌলিক অ্যাকাউন্টের বিবরণ দেখেন। টায়ার ২ এজেন্টরা বিলিং ও প্রযুক্তিগত রেকর্ড দেখেন। ম্যানেজাররা সম্পূর্ণ অ্যাকাউন্ট প্রোফাইল দেখেন।

যখন একজন টায়ার ২ এজেন্ট সম্পূর্ণ গ্রাহক অ্যাকাউন্টের স্ক্রিনশট সহ একটি নলেজ বেস আর্টিকেল তৈরি করেন, সেই স্ক্রিনশট টুলের প্রতিটি ব্যবহারকারীর কাছে দৃশ্যমান হয়ে যায়। টায়ার ১ এজেন্ট যাদের বিলিং রেকর্ড দেখার কথা নয় তারা এখন দেখতে পারেন। সিস্টেম অ্যাক্সেস নেই এমন ঠিকাদাররা দেখতে পারেন। অনবোর্ডিং-এ নতুন কর্মীরাও দেখতে পারেন।

স্ক্রিনশট গ্রাহকের অ্যাকাউন্ট সিস্টেমের RBAC নিয়ন্ত্রণ বাইপাস করে। RBAC যে ব্যক্তিগত তথ্য রক্ষার জন্য তৈরি হয়েছিল তা এখন নলেজ বেসে অ্যাক্সেস সহ সবার কাছে খোলা।

এটি তাত্ত্বিক ঝুঁকি নয়। এটি ডকস ওয়ার্কফ্লোর স্বাভাবিক ফলাফল। স্ক্রিনশটটি সেখানে বসে থাকে কোনো মেয়াদ, অ্যাক্সেস লগ বা অডিট ট্রেইল ছাড়াই।

ব্যবহারিক প্রতিকারের পদক্ষেপ

যেসব টিম GDPR অডিটের সময় এই সমস্যা খুঁজে পায়:

পূর্ববর্তী প্রতিকার:

  1. ইমেজ অ্যাটাচমেন্ট সহ সমস্ত নলেজ বেস পেজ চিহ্নিত করুন
  2. প্রতিটি অ্যাটাচমেন্টে ইমেজ PII ডিটেকশন চালান
  3. ফ্ল্যাগ করা ইমেজ পর্যালোচনা করুন: হাই-কনফিডেন্স হিট রিভিউ কিউতে যায়
  4. প্রতিটি ফ্ল্যাগ করা ইমেজের জন্য: স্যানিটাইজড সংস্করণ দিয়ে প্রতিস্থাপন করুন বা পেজ অ্যাক্সেস সীমিত করুন
  5. GDPR রেকর্ডের জন্য প্রতিকারের পদক্ষেপ লগ করুন

পূর্ববর্তী কাজের পরিমাণ নলেজ বেসের আকারের উপর নির্ভর করে। ৫০ জন সাপোর্ট টিমের তিন বছরের পুরনো নলেজ বেসে ইমেজের সংখ্যা হাজারে পৌঁছাতে পারে। ব্যাচ ইমেজ প্রক্রিয়াকরণ এটি সম্ভব করে। ফ্ল্যাগ করা ইমেজের মানব পর্যালোচনা মূল বাধা।

ভবিষ্যৎ নিয়ন্ত্রণ:

  1. নলেজ বেসে প্রকাশের আগে স্ক্রিনশট স্যানিটাইজ করতে সমস্ত সাপোর্ট কর্মীদের প্রশিক্ষণ দিন
  2. টুলিং প্রদান করুন: পেস্ট করার আগে গ্রাহকের নাম ব্লার করার স্ক্রিনশট অ্যানোটেশন টুল
  3. একটি রিভিউ ধাপ যোগ করুন: একজন মনোনীত রিভিউয়ার প্রকাশের আগে আর্টিকেল চেক করেন, বিশেষভাবে ইমেজে গ্রাহকের PII খোঁজেন
  4. সমস্ত Confluence অ্যাটাচমেন্টে ত্রৈমাসিক ব্যাচ ইমেজ স্ক্যান চালান

ন্যূনতম কার্যকর নিয়ন্ত্রণ: একটি প্রকাশ চেকলিস্ট: "প্রকাশ করার আগে স্ক্রিনশট থেকে সমস্ত গ্রাহকের নাম, ইমেইল এবং অ্যাকাউন্ট আইডি সরান বা ব্লার করুন।" লো-টেক, অটোমেটেড নয়, কিন্তু এটি একটি ডকুমেন্টেড নিয়ন্ত্রণ তৈরি করে। ছোট টিমের জন্য, এটি শুরুর বিন্দু।

বিস্তৃত আইনি কাঠামোর জন্য আমাদের GDPR কমপ্লায়েন্স ওভারভিউ দেখুন, এবং চেকলিস্ট-মাত্র পদ্ধতি কীভাবে স্কেলে ভেঙে পড়ে তার জন্য কারিগরি নিয়ন্ত্রণ ছাড়া নীতি কেন ব্যর্থ হয় পড়ুন।

সময়ের সাথে সমস্যা কেন বাড়ে

সিস্টেমেটিক নিয়ন্ত্রণ ছাড়া, নলেজ বেস PII এক্সপোজার যৌগিকভাবে বাড়তে থাকে।

পরিমাণ: গ্রাহকের স্ক্রিনশট সহ প্রতিটি নতুন আর্টিকেল মোট এক্সপোজার বাড়ায়। সাপোর্ট টিম বাড়লে এবং নলেজ বেস প্রসারিত হলে সঞ্চিত PII-ও বাড়ে। এই টুলগুলোকে যা কার্যকর করে — প্রকাশের সহজতা, স্থায়িত্ব, ব্যাপক অ্যাক্সেস — তাই PII সমস্যা আরও খারাপ করে।

ভুলে যাওয়া আর্টিকেল: পুরনো এজ কেস সম্পর্কে আর্টিকেল যা আর আসে না তা অ্যাক্সেসযোগ্য থাকে। এগুলোতে এমন গ্রাহকদের PII আছে যারা তখন থেকে মুছে ফেলার অনুরোধ করেছেন। ২০২২ সালে শেষ আপডেট হওয়া কোনো আর্টিকেল কেউ চেক করে না।

ক্রস-টিম বিস্তার: নলেজ বেস প্রায়ই ক্রস-ফাংশনাল হয়ে যায়। গ্রাহকের স্ক্রিনশট সহ একটি সাপোর্ট আর্টিকেল প্রোডাক্ট টিম, ইঞ্জিনিয়ারিং টিম বা বাইরের ঠিকাদারদের সাথে একটি ফিচার রিকোয়েস্ট বা বাগ রিপোর্টের প্রসঙ্গ হিসেবে শেয়ার হতে পারে। প্রতিটি শেয়ার ব্যক্তিগত তথ্যের দর্শক বিস্তৃত করে।

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

নলেজ বেস PII ঠিক করার চেয়ে প্রতিরোধ করা সহজ। এখন যে নিয়ন্ত্রণ স্থাপন করা হবে তা যৌগিক প্রতিকার সমস্যা এড়ায়। ব্লার করা স্ক্রিনশট ছাড়া প্রকাশিত প্রতিটি আর্টিকেল ভবিষ্যতে পুনরুদ্ধারের একটি কাজ।

সূত্র

সম্পর্কিত নিবন্ধ

AI নিরাপত্তা

রিয়েল-টাইম PII প্রতিরোধে $২.২M সাশ্রয়

IBM একটি $২.২M খরচের পার্থক্য পেয়েছে প্রতিরোধ এবং ডিটেকশনের মধ্যে। এখানে গণিত যা রিয়েল-টাইম PII আটকানো নিরাপত্তা দলগুলোর জন্য বাধ্যতামূলক করে তোলে।

AI নিরাপত্তা

GDPR আর্ট. ৩২: AI সরঞ্জাম PII পর্যবেক্ষণ

এন্টারপ্রাইজ কমপ্লায়েন্স দলগুলোর AI সরঞ্জাম PII নিয়ন্ত্রণের পরিমাণগত প্রমাণ দরকার। নেটওয়ার্ক DLP ব্রাউজার AI ইন্টারঅ্যাকশন মিস করে।

AI নিরাপত্তা

AI ডেটা লিকের জন্য রিয়েল-টাইম PII প্রতিরোধ

যখন একজন কর্মী ChatGPT-তে কোনো গ্রাহকের নাম টাইপ করেন, তখন সেই ডেটা তাৎক্ষণিকভাবে প্রতিষ্ঠানের নিয়ন্ত্রণের বাইরে চলে যায়। পরবর্তীকালীন DLP এই ঘণ্টা আর ফিরিয়ে আনতে পারে না।

আপনার তথ্য সুরক্ষিত করতে প্রস্তুত?

48 ভাষায় 273 সত্তা প্রকারের সাথে PII অ্যানোনিমাইজ করা শুরু করুন।