سوالی که مدیر امنیت اول می‌پرسد
وقتی یک سازمان به فکر دستیار هوش مصنوعی می‌افتد، مدیر امنیت اطلاعات معمولاً قبل از هر چیز یک سوال می‌پرسد: «اگر هر کارمند بتواند از همه‌ی اسناد سازمان سوال بپرسد، قرارداد محرمانه و حقوق همکاران و رمز سامانه‌ها چه میشود؟»
این سوال بی‌جاست؟ نه. یک دستیار هوشمند که به اسناد سازمان دسترسی دارد، در عمل جست‌وجوگری است که هر چیزی را که در دسترسش باشد پیدا و خلاصه می‌کند. اگر دسترسی درست کنترل نشود، همین توانایی که مفید است، به یک نشت اطلاعات سریع و مودبانه تبدیل میشود.
ماژول «حاکمیت داده» در دانابات برای جواب دادن به همین سوال طراحی شده است. هدف این مقاله این است که ببینید دقیقاً چه کار می‌کند، چه چیزی را کنترل نمی‌کند و پیش از فعال‌سازی چه چیزهایی باید در خود سازمان آماده باشد.
حاکمیت داده یعنی بیشتر از دادن و گرفتن دسترسی
دسترسی ساده، یعنی «کاربر الف سند ب را می‌بیند یا نمی‌بیند»، لازم است اما کافی نیست. سازمان‌ها چند سوال دیگر هم دارند. آیا پاسخی که به کاربر نشان داده میشود ممکن است اطلاعات شخصی دیگران را لو بدهد؟ آیا میشود سوال‌های خطرناک را قبل از رسیدن به مدل شناسایی کرد؟ اگر سامانه‌ی استعلام دسترسی از کار بیفتد، دستیار چه رفتاری داشته باشد؟ و در نهایت، اگر اتفاقی افتاد، چه ردپایی برای بررسی هست؟
ماژول حاکمیت داده به این چهار سوال جواب می‌دهد: ABAC روی چارت سازمانی، ماسک اطلاعات شخصی، واژگان حساس، و ردپای حسابرسی. در ادامه هر کدام را جداگانه می‌بینیم.
چرا کنترل باید بیرون از خود مدل باشد
یک راه‌حل رایج و ضعیف برای امنیت دستیارهای هوشمند این است که در دستور مدل بنویسند: «اطلاعات محرمانه را فاش نکن.» این روش به قضاوت خود مدل تکیه می‌کند، و مدل یک سامانه‌ی قطعی نیست. ممکن است ده بار درست رفتار کند و بار یازدهم، با یک بازنویسی هوشمندانه‌ی سوال، اشتباه کند.
طراحی دانابات این منطق را وارونه می‌کند: کنترل‌های مهم بیرون از مدل و با قواعد قطعی انجام می‌شوند. دسترسی پیش از جست‌وجو و پیش از نمایش چک میشود، یعنی سندی که کاربر مجاز نیست اصلاً در مسیر ساخت پاسخ نمی‌آید. واژگان حساس پیش از ارسال سوال به مدل بررسی می‌شوند. در نتیجه، مدل هیچ‌وقت در موقعیتی قرار نمی‌گیرد که باید «تصمیم بگیرد» آیا چیزی را بگوید یا نگوید.
این فرق مهمی است. در یک مورد، امنیت شما به رفتار احتمالی یک مدل بستگی دارد. در مورد دیگر، به قواعدی که می‌توانید بخوانید، آزمایش کنید و ردپایشان را بررسی کنید.
ABAC: دسترسی بر اساس ویژگی، نه فقط نقش
مدل‌های ساده‌ی دسترسی بر پایهی نقش‌اند: «مدیر مالی»، «کارشناس»، «ادمین». این مدل در سازمان‌های کوچک کار می‌کند، اما در سازمان‌های بزرگ کم می‌آورد. ABAC یا کنترل دسترسی مبتنی بر ویژگی، تصمیم را بر پایهی ویژگی‌ها میگیرد: واحد سازمانی کاربر، پست او، سطح طبقه‌بندی‌اش، و در طرف دیگر ویژگیهای خود سند.
در دانابات این ویژگی‌ها روی چارت سازمانی سوار می‌شوند. فرض کنید یک سند «محرمانه» برای واحد مالی تعریف شده است. کارشناس مالی با سطح مناسب آن را می‌بیند. همکار او در واحد فروش، حتی اگر نقش مشابهی داشته باشد، نمی‌بیند. و مدیر ارشد یک واحد دیگر با سطح طبقهبندی بالا، فقط اگر ویژگی‌هایش با ویژگیهای سند هم‌خوان باشد دسترسی میگیرد.
این روش انعطاف بیشتری دارد: به‌جای نوشتن صدها قاعده‌ی دستی برای هر سند و هر نقش، ویژگی‌ها یک بار تعریف می‌شوند و تصمیم‌ها از روی آن‌ها گرفته میشود.
دو مرحله‌ی کنترل: قبل از جست‌وجو و قبل از نمایش
دسترسی در دانابات فقط یک‌جا چک نمیشود. دو مرحله دارد. مرحله‌ی اول پیش از جست‌وجو است: بر اساس نقش، واحد و سطح طبقهبندی، فقط اسنادی که کاربر مجاز است در نتایج جست‌وجو وارد می‌شوند. مرحله‌ی دوم پیش از نمایش است: پیش از اینکه پاسخ به کاربر برسد، دسترسی از خود سامانه‌ی سازمان استعلام میشود.
نتیجه‌ی این طراحی دو لایه، یک رفتار مهم است: اگر کاربر مجاز به دیدن سندی نباشد، آن سند حتی در فهرست منابع پاسخ هم ظاهر نمیشود. این مهم است چون گاهی خود وجود یک سند اطلاعات است. اگر در فهرست منابع بنویسد «قرارداد شماره‌ی فلان با شرکت فلان»، حتی بدون محتوا، کسی که نباید بداند، می‌داند. این همان چیزی است که در مقاله‌ی SmartConnect؛ دستیار برای هر سامانه بدون بازنویسی هم بیان شد: دسترسی پیش از پاسخ، نه پنهان کردن بعد از پاسخ.
ماسک اطلاعات شخصی
بخش دیگری از حاکمیت داده، ماسک اطلاعات شخصی در پاسخ‌هاست. حتی وقتی کاربر مجاز به دیدن یک سند است، ممکن است لازم نباشد همه‌ی جزئیات شخصی داخل آن را ببیند. شماره‌ی تماس یک مشتری یا اطلاعات شخصی یک همکار، می‌توانند در پاسخ پوشانده شوند.
نکته‌ی عملی این است که ماسک یک لایه‌ی محافظ است، نه ضمانت حقوقی. اینکه چه چیزی اطلاعات شخصی حساب میشود و چه الزام قانونی دارد، تصمیمی است که سازمان با مشاور حقوقی خودش میگیرد؛ ابزار فقط آن تصمیم را اجرا می‌کند.
واژگان حساس: پیش از آنکه سوال به مدل برسد
یکی از ویژگیهای متمایز این ماژول، بررسی واژگان حساس است. سازمان فهرستی از واژه‌ها و عبارت‌های حساس تعریف می‌کند. هر سوالی که کاربر می‌پرسد، پیش از ارسال به مدل با این فهرست تطبیق داده میشود.
ترتیب اینجا مهم است. اگر کنترل بعد از مدل انجام شود، سوال حساس به مدل رسیده است، و اگر مدل ابری باشد، از شبکه‌ی سازمان خارج شده است. بررسی پیش از مدل یعنی در موارد جدی، سوال اصلاً از سازمان بیرون نمی‌رود.
اگر سوالی با فهرست مطابقت کند، گفتگو برای بازبینی علامت می‌خورد و به صف بررسی می‌رود. و در شدت «بالا»، پاسخ مسدود میشود. مثال کلاسیک: «رمز عبور سامانه‌ی فلان چیست؟» این سوال هم بالقوه خطرناک است و هم نشانه‌ی یک رفتار غیرعادی که سازمان باید از آن مطلع شود. مسدود شدن پاسخ فقط نیمی از ماجراست؛ نیمه‌ی دیگر این است که مسئول امنیت آن گفتگو را ببیند.
سه سیاست دسترسی و تصمیم برای زمان قطعی
دانابات سه سیاست دسترسی دارد که هر سازمان بسته به فرهنگ و حساسیتش انتخاب می‌کند: سخت‌گیرانه، نیمه‌باز و کاملاً باز. این یعنی سازمانی که اسناد بسیار حساس دارد می‌تواند سخت‌گیر باشد و سازمانی که فرهنگ شفاف‌تری دارد می‌تواند بازتر.
یک تصمیم مهم دیگر هم وجود دارد که اغلب نادیده گرفته میشود: وقتی سامانه‌ای که دسترسی را استعلام می‌کند از کار بیفتد، دستیار چه کار کند؟ اجازه بدهد (fail-open) یا ببندد (fail-closed)؟ هر دو گزینه بهایی دارند. اگر ببندد، کارمندان در زمان قطعی از دستیار محروم می‌شوند. اگر باز بگذارد، در همان بازه ممکن است دسترسی کنترل‌نشده رخ دهد. دانابات این تصمیم را به عهده‌ی سازمان می‌گذارد و آن را به‌صورت یک تنظیم صریح در اختیارش قرار می‌دهد، نه یک رفتار پنهان.
ردپای کامل حسابرسی
آخرین لایه، ردپای حسابرسی است. هر پرسش، هر پاسخ و هر تصمیم دسترسی ثبت میشود و می‌توان آن را به صورت Excel یا CSV خروجی گرفت. این همان چیزی است که در زمان بروز یک مشکل، یا حتی در یک بازرسی داخلی، به شما اجازه می‌دهد بگویید چه کسی چه چیزی را پرسید و چه جوابی گرفت.
بدون حسابرسی، همه‌ی کنترل‌های بالا فقط اعتماد به حسن‌نیت‌اند. با حسابرسی، قابل‌راستی‌آزمایی می‌شوند.