ماه پیش نوشتم یک مقاله در مورد روشی که پلتفرم‌های کم‌کد/بدون کد اشتراک‌گذاری اعتبار را به‌عنوان یک سرویس ارائه می‌کنند، چرا این کار را انجام می‌دهند، و چگونه به نظر می‌رسد. دیدگاه یک مهاجم. در این مقاله، من بر پیامدهای آن مصالحه و تأثیر آن بر شرکت‌های امروزی تمرکز خواهم کرد.
در اینجا دلیل به اشتراک گذاشتن اعتبار سازمانی خود با شخص دیگری عمل بدی است. بگویید من می‌خواهم اعتبارم را به یکی از همکارانم بفرستم تا گزارش‌های تولید را برای تحلیل رفتار کاربر یکباره جستجو کنم. در یک شرکت معمولی، اعطای مجوز به کسی برای پرس و جو از یک منبع داده جدید می تواند به معنای یک فرآیند بررسی دسترسی طولانی باشد، به خصوص زمانی که صحبت از تولید یا داده های حساس باشد. همکار من به راحتی می تواند ناامید شود. "تمام چیزی که می خواستم این بود که این پرس و جو کوچک را انجام دهم، و من قبلاً یک ماه است که منتظر بودم!" می توانستند بگویند من فقط می‌توانم پرس و جو را برای آنها اجرا کنم، اما درگیر وظایف روزمره خودم هستم، و درخواست‌های یکباره پیچیده می‌شوند.
من با یک راه حل سریع مانده ام: فقط می توانم نام کاربری/رمز عبورم را با همکارم به اشتراک بگذارم. اگر چالش MFA دریافت کنند، با کمال میل تایید می کنم. من نیازی به صرف زمان برای اجرای پرس و جو ندارم و همکارم مسدود می شود. همه برنده اند! درست؟
خوب، شما در تحلیل خود درست می گویید، اما تصویر بزرگتر را از دست داده اید. در حالی که برای شرکت مهم است که همکار شما تجزیه و تحلیل رفتار کاربر خود را انجام دهد، به همان اندازه، اگر نه بیشتر، مهم است که شرکت شما با مجموعه ای از استانداردهای حریم خصوصی و امنیتی مطابقت داشته باشد و با حفظ تعهد شرکت به امنیت، اعتماد مشتری را حفظ کند. .
اگر اهداف سازمانی سطح بالا شما را متقاعد نمی کند، تیم های مدیریت مرکزی در حوزه فناوری اطلاعات یا امنیت را در نظر بگیرید. این تیم ها عملیات و استراتژی های امنیتی خود را بر این واقعیت استوار می کنند که هر کاربر هویت منحصر به فرد خود را دارد. تیم‌های فناوری اطلاعات در حال تنظیم خط‌مشی‌های شبکه و دسترسی هستند که فرض می‌کنند هر کاربر از یک IP شرکت یا لپ‌تاپ شرکتی به طور همزمان وارد سیستم می‌شود. تیم های امنیتی رویدادها را بر اساس شناسه کاربری مرتبط می کنند. تیم های مالی می توانند گزارش های هزینه را برای هر کاربر و محیط ابری شخصی خود جمع آوری کنند. اشتراک اعتبار تمامی این مفروضات را تضعیف می کند. معنای اصلی هویت آنلاین را از بین می برد.
یک مثال در دنیای واقعی
بیایید به دنیای low-code/no-code بپردازیم و یک سناریوی واقعی را بررسی کنیم. در یک شرکت بزرگ، جین، یک کارمند الهام گرفته از تیم مراقبت از مشتری، متوجه شد که وقتی کارکنان سراسر سازمان در یک پرونده مشتری شرکت می‌کنند، معمولاً اطلاعات کلیدی مشتری، مانند سابقه پرونده پشتیبانی و آخرین خریدها را از دست می‌دهند. این امر تجربه مشتری را کاهش می دهد، زیرا آنها باید بارها و بارها موضوع خود را توضیح دهند در حالی که پرونده به کارمند مناسبی که می تواند مشکل را رسیدگی کند هدایت می شود.
برای بهبود این امر، جین برنامه‌ای ایجاد کرد که به کارمندان شرکت اجازه می‌دهد این اطلاعات کلیدی در مورد مشتریان را هنگامی که آن کارمندان بخشی از تیم مسئول رسیدگی به پرونده پشتیبانی مشتری هستند، مشاهده کنند. ابتدا، اجازه دهید لحظه‌ای به قدرت کم‌کد/بدون کد اذعان کنیم، که به جین اجازه می‌دهد تا نیازی را شناسایی کرده و بدون درخواست بودجه یا انتظار برای تخصیص منابع فناوری اطلاعات، به تنهایی به آن رسیدگی کند.
در حین ساخت برنامه، جین مجبور شد چندین مشکل را حل کند که بزرگترین آنها مجوزها بود. کارمندان در سراسر سازمان دسترسی مستقیم به پرس و جو از پایگاه داده مشتریان برای دریافت اطلاعات مورد نیاز خود ندارند. اگر آنها این کار را انجام دادند، جین مجبور نبود این برنامه را بسازد. برای غلبه بر این مشکل، جین وارد پایگاه داده شد و جلسه تأیید شده خود را مستقیماً در برنامه جاسازی کرد. هنگامی که برنامه درخواستی از یک کاربر دریافت می کند، از هویت جین برای اجرای آن کوئری استفاده می کند و سپس نتایج را به کاربر برمی گرداند. این ویژگی جاسازی اعتبار، همانطور که ماه گذشته بررسی کردیم، یکی از ویژگی های کلیدی پلتفرم های کم کد/بدون کد است. جین مطمئن شد که کنترل دسترسی مبتنی بر نقش (RBAC) را در برنامه راه‌اندازی کرده است تا هر کاربر فقط بتواند به موارد مشتری که به آنها اختصاص داده شده دسترسی داشته باشد.
این برنامه یک مشکل مهم تجاری را حل کرد و بنابراین به سرعت مورد قبول کاربران در سراسر شرکت قرار گرفت. مردم خوشحال بودند که با داشتن زمینه مناسب برای گفتگو می توانند خدمات بهتری به مشتریان خود ارائه دهند. مشتریان نیز خوشحال بودند. یک ماه پس از ایجاد این برنامه توسط جین، صدها کاربر در سراسر سازمان از آن استفاده کردند و میزان رضایت مشتری افزایش یافت.
در همین حال، در SOC، یک هشدار با شدت بالا که فعالیت غیرعادی در اطراف پایگاه داده مشتریان تولیدی را نشان می‌داد، فعال شد و به Amy، یک تحلیلگر امنیتی با تجربه، اختصاص یافت. تحقیقات اولیه امی نشان داد که یک کاربر داخلی در تلاش بود تا کل پایگاه داده را خراش دهد و اطلاعاتی درباره چندین مشتری از چندین آدرس IP در سراسر سازمان جستجو کند. الگوی پرس و جو بسیار پیچیده بود. به جای یک الگوی شمارش ساده که انتظار دارید هنگام خراش دادن یک پایگاه داده مشاهده کنید، داده های یک مشتری چندین بار، گاهی از طریق آدرس های IP مختلف و در تاریخ های مختلف، مورد پرسش قرار گرفت. آیا این ممکن است مهاجمی باشد که می‌خواهد سیستم‌های نظارت امنیتی را گیج کند؟
پس از یک بررسی سریع، امی اطلاعات مهمی را کشف کرد: همه آن جستجوها در تمام آدرس‌های IP و تاریخ‌ها از یک هویت کاربر استفاده می‌کردند، شخصی به نام جین از تیم مراقبت مشتری.
امی به سراغ جین رفت تا از او بپرسد که چه خبر است. در ابتدا جین نمی دانست. آیا مدارک او به سرقت رفته است؟ آیا او روی پیوند اشتباهی کلیک کرده یا به ایمیل دریافتی اشتباه اعتماد کرده است؟ اما زمانی که جین به ایمی درباره اپلیکیشنی که اخیرا ساخته بود گفت، هر دو متوجه شدند که ممکن است ارتباطی وجود داشته باشد. امی، تحلیلگر SOC، با low-code/no-code آشنایی نداشت، بنابراین آنها با تیم AppSec تماس گرفتند. با کمک جین، تیم متوجه شد که برنامه جین دارای اعتبار جین است. از دیدگاه پایگاه داده، هیچ برنامه کاربردی وجود نداشت - فقط جین بود که تعداد زیادی پرس و جو را اجرا می کرد.
جین، امی و تیم AppSec تصمیم گرفتند تا زمانی که راه حلی پیدا شود، برنامه را خاموش کنند. کاربران برنامه در سراسر سازمان ناامید شده بودند، زیرا آنها به آن اعتماد کرده بودند و مشتریان نیز آن را احساس می کردند.
در حالی که امی این موضوع را بسته و یافته‌های خود را مستند کرد، معاون مراقبت از مشتری از کاهش نرخ رضایت مشتری خوشحال نشد، بنابراین از جین خواستند به دنبال راه‌حلی دائمی باشد. جین با کمک اسناد پلتفرم و تیم مرکز تعالی سازمان، هویت جاسازی شده خود را از برنامه حذف کرد، برنامه را طوری تغییر داد که از هویت هر کاربر برای جستجو در پایگاه داده استفاده کند و اطمینان حاصل کرد که کاربران فقط برای موارد مشتری که با آنها مرتبط هستند مجوز دریافت می کنند. . در نسخه جدید و بهبود یافته خود، این برنامه از هویت هر کاربر برای پرس و جو از پایگاه داده مشتری استفاده کرد. جین و کاربران برنامه خوشحال بودند که برنامه دوباره آنلاین شده است، امی و تیم AppSec خوشحال بودند که هویت جین دیگر به اشتراک گذاشته نمی شود، و شرکت شاهد شروع دوباره افزایش نرخ رضایت مشتری بود. همه چیز خوب بود
دو هفته بعد، SOC هشدار دیگری در مورد دسترسی غیرعادی به پایگاه داده مشتریان تولیدی دریافت کرد. به طور مشکوکی شبیه به هشدار قبلی در همان پایگاه داده بود. مجدداً، آدرس‌های IP از سراسر سازمان از هویت یک کاربر برای جستجو در پایگاه داده استفاده می‌کردند. باز هم آن کاربر جین بود. اما این بار تیم امنیتی و جین می دانستند که این اپلیکیشن از هویت کاربر خود استفاده می کند. چه خبر است؟
تحقیقات نشان داد که برنامه اصلی داشته است به طور ضمنی به اشتراک گذاشته شده است جلسه پایگاه داده تأیید شده جین با کاربران برنامه. با اشتراک گذاری برنامه با یک کاربر، آن کاربر به طور مستقیم به آن دسترسی پیدا کرد ارتباط، یک بسته بندی در اطراف یک جلسه پایگاه داده احراز هویت شده که توسط پلت فرم low-code/no-code ارائه شده است. با استفاده از این اتصال، کاربران می‌توانستند مستقیماً از جلسه تأیید شده استفاده کنند - دیگر مجبور نبودند از طریق برنامه استفاده کنند. به نظر می رسد که چندین کاربر متوجه این موضوع شده اند و با تصور اینکه این رفتار مورد نظر بوده است، از جلسه پایگاه داده تایید شده جین برای اجرای پرس و جوهای خود استفاده می کنند. آنها این راه حل را دوست داشتند، زیرا استفاده از اتصال مستقیماً به آنها دسترسی کامل به پایگاه داده را می داد، نه فقط برای موارد مشتری که به آنها اختصاص داده شده است.
اتصال حذف شد و حادثه تمام شد. تحلیلگر SOC با کاربرانی که از اتصال جین استفاده کرده‌اند تماس گرفت تا مطمئن شود که داده‌های مشتری را که ذخیره کرده‌اند دور ریخته‌اند.
پرداختن به چالش امنیتی کم کد/بدون کد
داستان بالا یک سناریوی واقعی از یک شرکت چندملیتی B2C است. برخی از جزئیات حذف شده یا برای محافظت از حریم خصوصی تنظیم شده است. ما دیده‌ایم که چگونه یک کارمند خوش‌نیت می‌تواند ناخواسته هویت خود را با سایر کاربران به اشتراک بگذارد و باعث ایجاد طیف وسیعی از مشکلات در حوزه فناوری اطلاعات، امنیت و تجارت شود. همانطور که ماه گذشته بررسی کردیم، اشتراک‌گذاری اعتبار یکی از ویژگی‌های کلیدی کم‌کد/بدون کد است. این یک هنجار است، نه استثنا.
As کم‌کد/بدون کد، آگاهانه یا ناآگاهانه به شکوفایی در شرکت ادامه می‌دهد، برای تیم های امنیتی و فناوری اطلاعات بسیار مهم است که به گفتگوی توسعه کسب و کار بپیوندند. برنامه‌های کم‌کد/بدون کد همراه با a مجموعه ای منحصر به فرد از چالش های امنیتیو ماهیت پربار آنها به این معنی است که این چالش ها سریعتر از همیشه حاد می شوند.
