جلوگیری از افشای دادههای سازمانی در چتباتها از لحظهای شروع میشود که کاربر تصمیم میگیرد چه چیزی را در کادر گفتوگو بنویسد. متن یک قرارداد، فایل حقوق و دستمزد، اطلاعات مشتری، کد منبع یا حتی یک اسکرینشات داخلی ممکن است حاوی جزئیاتی باشد که نباید خارج از محیط تأییدشده سازمان قرار بگیرد.
مسئله فقط «رایگان یا پولی بودن» چتبات نیست. باید مشخص باشد داده به کدام سرویس میرود، چه کسانی به آن دسترسی دارند، برای چه مدتی نگهداری میشود و آیا سازمان بر استفاده از آن نظارت دارد یا نه. یک پاسخ مفید، ارزش ریسک ارسال اطلاعات محرمانه را ندارد.
افشای دادههای سازمانی در چتباتها چگونه رخ میدهد؟
بسیاری از نشتها با یک حمله پیچیده آغاز نمیشوند؛ کاربر برای خلاصهکردن یک گزارش، اصلاح متن ایمیل یا پیدا کردن خطای کد، محتوای واقعی را بدون پاکسازی در چتبات عمومی قرار میدهد. همین محتوا ممکن است شامل نام مشتری، شماره پرونده، اطلاعات مالی، نشانی، رمز عبور یا جزئیات یک پروژه منتشرنشده باشد.
خطر دیگر، اتصال چتبات به ابزارهای سازمانی است. افزونه، ربات داخلی یا دستیار متصل به فضای ابری اگر بیش از نیاز خود دسترسی داشته باشد، میتواند دامنه اطلاعات قابل مشاهده را بزرگتر کند. در این حالت، مشکل فقط متن ورودی نیست؛ پاسخ تولیدشده نیز ممکن است بخشی از داده داخلی را به کاربر نامناسب نشان دهد.
کدام اطلاعات نباید در چتبات عمومی وارد شوند؟
بهجای تکیه بر حافظه کارکنان، سازمان بهتر است اطلاعات را در چند سطح طبقهبندی کند. هر دادهای که انتشار آن میتواند به فرد، مشتری، شرکت یا رابطه تجاری آسیب بزند، باید پیش از استفاده از ابزارهای هوش مصنوعی بررسی شود.
- اطلاعات هویتی: کد ملی، شماره گذرنامه، شماره تلفن، نشانی، اطلاعات بانکی و شماره پرونده.
- اسناد محرمانه: قراردادها، پیشنهادهای قیمت، گزارشهای مالی، صورتجلسههای داخلی و برنامههای محصول.
- دادههای دسترسی: رمز عبور، کلید API، توکن، عبارت بازیابی و فایل تنظیمات دارای اعتبارنامه.
- اطلاعات منابع انسانی و مشتریان: حقوق، ارزیابی عملکرد، سوابق درمانی، شکایتها و مکاتبات خصوصی.
- داراییهای فنی: کد منبع اختصاصی، معماری شبکه، آسیبپذیریهای کشفنشده و گزارشهای امنیتی.
اطلاعات عمومی، دادههای ساختگی و نمونههایی که بهدرستی ناشناسسازی شدهاند، معمولاً انتخاب امنتری هستند؛ بااینحال ناشناسسازی ناقص میتواند همچنان امکان شناسایی فرد یا شرکت را باقی بگذارد.
قبل از ارسال درخواست، داده را کمخطر کنید
بهترین راهکار این نیست که از چتبات برای هیچ کاری استفاده نشود؛ بلکه باید مسئله را از داده جدا کرد. کاربر اغلب برای دریافت راهنمایی، لازم نیست متن واقعی سند یا همه جزئیات پرونده را وارد کند.
- هدف درخواست را مشخص کنید و فقط بخش لازم از اطلاعات را نگه دارید.
- نام، شماره تماس، شناسه مشتری، مبلغ دقیق و هر شناسه مستقیم را با برچسبهایی مانند «مشتری الف» یا «مبلغ نمونه» جایگزین کنید.
- رمزها، کلیدهای دسترسی و توکنها را حتی برای آزمایش کوتاه نیز وارد نکنید.
- اگر تحلیل یک فایل ضروری است، نسخهای جداگانه و پاکسازیشده بسازید؛ اصل فایل را بارگذاری نکنید.
- پس از تولید پاسخ، بررسی کنید که چتبات بخشی از داده حساس را در خروجی بازتولید نکرده باشد.
برای مثال، بهجای ارسال فهرست واقعی مشتریان و درخواست دستهبندی، میتوان ساختاری مشابه با چند ردیف ساختگی ارائه کرد. برای رفع خطای کد نیز معمولاً حذف نام مخزن، نشانی سرویس، متغیرهای محیطی و دادههای واقعی کافی است تا مسئله فنی حفظ شود.
سیاست سازمانی برای استفاده امن از چتباتها
یک دستورالعمل کوتاه و قابل اجرا از ممنوعیتهای مبهم بهتر است. کارکنان باید بدانند کدام ابزارها مجازند، چه نوع دادهای در هر ابزار قابل استفاده است و برای موارد استثنایی از چه کسی اجازه بگیرند.
در این سیاست، دستکم این موارد را روشن کنید:
- فهرست چتباتها و حسابهای مورد تأیید سازمان؛
- سطحبندی دادهها از عمومی تا محرمانه و ممنوع برای ارسال؛
- مسئول تأیید استفاده از دادههای مشتری، کارکنان و پروژهها؛
- نحوه گزارش اشتباه، حذف نشست و پیگیری رخداد؛
- ممنوعیت واردکردن رمز عبور و اتصال حساب شخصی به فایلهای سازمانی.
آموزش هم باید با مثالهای واقعی محیط کار انجام شود: خلاصهکردن قرارداد، بازنویسی نامه به مشتری، تحلیل فایل فروش یا رفع خطای برنامه. این مثالها نشان میدهند که مرز میان «کمک گرفتن» و «انتقال سند محرمانه» دقیقاً کجاست.
کنترلهای فنی برای کاهش احتمال نشت
مسئولیت جلوگیری از افشا نباید فقط بر دوش کاربر باشد. سازمان میتواند با مدیریت دسترسی و نظارت، احتمال خطا و دامنه پیامد آن را کاهش دهد.
- برای ابزارهای مورد تأیید، حساب سازمانی و احراز هویت چندمرحلهای فعال کنید.
- دسترسی هر دستیار یا افزونه را به کمترین داده و عملیاتی که برای کار لازم است محدود کنید.
- ارسال دادههای حساس را با ابزارهای جلوگیری از نشت داده یا قواعد فیلتر، در صورت وجود زیرساخت مناسب، بررسی کنید.
- ثبت رخدادها و بازبینی دورهای دسترسیها را انجام دهید؛ لاگها نیز نباید حاوی متن کامل اطلاعات محرمانه باشند.
- تنظیمات نگهداری، استفاده از مکالمات برای بهبود سرویس و حذف داده را پیش از راهاندازی بررسی کنید.
نسخه سازمانی یک سرویس میتواند کنترل بیشتری فراهم کند، اما بهتنهایی تضمین امنیت نیست. پیکربندی نادرست، دسترسی بیش از حد و کپیکردن پاسخها در کانال عمومی همچنان میتواند داده را افشا کند.
اگر اطلاعات حساس اشتباه ارسال شد، چه کنیم؟
پنهانکردن اشتباه معمولاً ریسک را بیشتر میکند. کاربر باید ارسال داده را متوقف کند و موضوع را طبق مسیر داخلی، سریع به مسئول امنیت یا مدیر سامانه اطلاع دهد.
در بررسی اولیه، این موارد را ثبت کنید:
- چه دادهای و در چه زمانی ارسال شده است؛
- نام ابزار، حساب و دستگاه استفادهشده؛
- آیا داده در فایل، پاسخ تولیدشده یا مکالمه دیگری بازنشر شده است؛
- چه اقدامهایی برای حذف، لغو دسترسی یا تغییر اعتبارنامهها انجام شده است.
اگر رمز، کلید API یا توکن ارسال شده باشد، باید آن را افشاشده فرض و در سریعترین زمان ممکن باطل یا تعویض کرد. درباره اطلاعات شخصی یا قراردادی نیز تصمیم برای اطلاعرسانی به افراد و نهادهای مرتبط باید بر اساس قوانین، قراردادها و سیاست پاسخگویی سازمان انجام شود.
جمعبندی عملی برای جلوگیری از افشای دادههای سازمانی در چتباتها
جلوگیری از افشای دادههای سازمانی در چتباتها به یک ابزار خاص محدود نیست: داده را طبقهبندی کنید، فقط حداقل محتوای لازم را ارسال کنید، اطلاعات واقعی را با نمونه ساختگی جایگزین کنید و از ابزارهای تأییدنشده برای اسناد داخلی استفاده نکنید. در سطح سازمان نیز سیاست روشن، کنترل دسترسی، آموزش و مسیر گزارش رخداد لازم است. اگر کاربر نتواند بهطور مطمئن تشخیص دهد داده محرمانه است یا نه، بهترین تصمیم ارسالنکردن آن تا زمان بررسی مسئول مربوط خواهد بود.
