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