تأمین امنیت فناوری اطلاعات در گرو همکاری تیم‌ امنیت با مدیریت دارایی فناوری اطلاعات

دبلیو راس اشبی در کتاب خود، درآمدی بر سایبرنتیک، که در سال ۱۹۵۶ منتشر شد، چارچوبی برای مدیریت سیستم‌های ارتباطی ارائه کرد. امروزه، مفاهیم ارائه‌شده در این کتاب که بیش از شصت سال پیش منتشر شده، همچنان کارآمد هستند. یکی از مفاهیم پایه‌ای این کتاب اصل تاریکی (Darkness) است؛ جایی که غیرممکن است هر فرد خاصی بتواند هر سیستم بسیار پیچیده‌ای را مشاهده و درک کند.

برای مدیریت خدمات فناوری اطلاعات (ITSM)، مدیریت دارایی فناوری اطلاعات (ITAM) و تیم‌های امنیتی، اصل تاریکی بیانگر مشکل بزرگ‌تری است: وقتی همه‌ی دارایی‌هایمان را نمی‌شناسیم، چگونه می‌توانیم خدماتمان را به‌شکل مؤثری ارائه دهیم؟ چگونه می‌توانیم آن خدمات و دستگاه‌ها را ایمن بداریم و از آنها محافظت کنیم؟ چگونه می‌توانیم آن دستگاه‌ها را ردیابی کرده و عناصر تشکیل‌دهنده‌‌شان را بشناسیم؟

امروزه، در کنار افزایش تهدیدات امنیتی و ریسک‌های مربوط به دستگاه‌ها و سیستم‌ها، این سیستم‌ها هم مدام پیچیده‌تر می‌شوند. مسئله اینجاست که به‌دست آوردن همه‌ داده‌های لازم و استفاده از آن‌ها در موارد گوناگون، نیازمند همکاری است.

آیا شناخت دارایی‌ها کار سختی است؟

بزرگ‌ترین مشکل در این زمینه، شفاف نبودن حوزه دارایی‌های فناوری اطلاعات است. موضوع همیشگی متخصصانِ باسابقه‌ مدیریت دارایی فناوری اطلاعات، وجود خلأ میان دارایی‌های سخت‌افزاری موجود و سوابق موجود در پایگاه داده مدیریت پیکربندی (CMDB) است. در حال حاضر، هم‌زمان با ساده‌شدن درک استفاده از ابزارهای ارتباطات شبکه‌ای، ردیابی لپ‌تاپ‌ها و نرم‌افزارهای نصب‌شده روی آن‌ها، با فراگیر شدن استفاده از موبایل، دشوارتر شده است. دریافت فهرست دقیق دارایی‌ها ضروری است، اما اطمینان از به‌روز بودن و صحت نسخه‌های سخت‌افزاری، تأسیسات نرم‌افزاری، و نسخه‌ها همچنان چالشی جدی به‌شمار می‌آید.

یکی از مسائل مرتبط با این مشکل وجود تعدد دستگاه‌های متصل به شبکه است؛ دستگاه‌هایی که لپ‌تاپ‌ و کامپیوترهای رومیزی قدیمی نیستند. افزایش کار با کامپیوتر، با وجود دستگاه‌های کوچک‌تری مانند رَزبری پای (Raspberry Pi) یا کامپیوتر تَک‌بُرد (کامپیوترهای بسیار کوچکی به اندازه کَف دست) و دستگاه‌های مرتبطی که بخشی از اینترنت اشیا (IoT) هستند، شناخت موارد موجود در شبکه را دشوارتر کرده است. این مسئله برای تمام شرکت‌های کوچک و بزرگ یک مشکل واقعی است. برای مثال، شرکت ناسا در سال ۲۰۱۹ گزارشی منتشر کرد که توضیح می‌داد چطور منشأ نشتِ کلان‌داده‌های بخش آزمایشگاهیِ پیشرانشِ جتِ ناسا، نصب یک رَزبری غیرمجاز بوده که کشف نشده است.

در کنار این مشکل، شاهد افزایش دارایی‌های فناوری اطلاعات هستیم که در فضای ابری (Cloud) میزبانی می‌شوند و این مسئله کار مدیریت دارایی فناوری اطلاعات را سخت‌تر کرده است. آگاهی از همه این برنامه‌های کاربردیِ (application) مورد استفاده -چه برنامه‌های معطوف به سرویس‌های وب آمازون (AWS)، چه پلت‌فرم ابری گوگل، چه آزور (Azure) و چه نرم‌افزارهایی که به مثابه‌ یک خدمت (SaaS) ارائه می‌شوند- وضعیت چالش‌برانگیز دیگری برای مدیریت دارایی ایجاد کرده است.

امروزه، یک روند دیگر را هم  باید در نظر داشت. برنامه‌های کاربردی جدیدی در حال توسعه‌اند و در بسترهای نرم‌افزاری اجرا می‌شوند. نمونه‌های کوچک و کم‌اهمیتی که فقط شامل مبادی و اصول ابتدایی مورد نیاز برای اجرای یک برنامه‌ی کاربردی هستند. آنها معمولاً فقط تا زمانی که لازم باشد روی سرویس‌های ابری اجرا و استفاده می‌شوند و تعداد بسترهای اجرایی‌شان، براساس درخواستی که مشتریان یا کاربران از یک سرویس دارند، می‌تواند کم یا زیاد بشود.

از دیدگاه مدیریت دارایی فناوری اطلاعات، چیزی که این بسترهای اجرایی (container) را چالش‌برانگیزتر می‌کند، بی‌دوام بودن آنهاست. شرکت‌ها در مواردی، به جای خرید نرم‌افزار اصلی، بستری محدود از نرم‌افزار اصلی را درخواست می‌کنند، آن را در فضای ابری اجرا می‌کنند و این بسترها وقتی دیگر قابل استفاده نباشند، خاموش می‌شوند. یعنی نصب و راه‌اندازی آنها به نحوی نیست که بتوان تا سال‌ها از آنها استفاده کرد. در حالی که آنها تمایل دارند روی نرم‌افزارِ متن باز (Open Source) ساخته شوند تا فشار خرید مجوز نرم‌افزار از روی آنها برداشته شود، هر بار می‌توانند برای چند ساعت یا حتی چند دقیقه وجود داشته باشند. از دیدگاه مدیریت دارایی، این امر مدیریت فهرست دقیق دارایی‌ها را بسیار دشوار می‌کند.

همه این روندها -رشد اینترنت اشیا، ظهور رایانش ابری و معرفی این بسترها- را باید در کنار این مشکل در نظر داشت؛ مشکل دائمی حفظ یک فهرست دقیق از دارایی‌ها که باید روشن بشود. برای حل این مشکل چه کاری می‌توان انجام داد؟

همکاری میان دارایی‌ها، امنیت و خدمات

یک رویکرد این است که ببینیم چه فرد دیگری در این کسب‌وکار به فهرست دقیق و به‌روز دارایی‎ها نیاز دارد و چرا؟ برای مثال، تیم‌های امنیت فناوری اطلاعات باید بتوانند ایمنی دارایی‌های شرکت را -از داده‌ها و مالکیت معنوی گرفته تا دارایی‌های فناوری اطلاعات- در برابر تهدیدات بیرونی حفظ کنند. همچنین، این تیم‌ها باید فهرست دقیقی از نرم‌افزارها و آسیب‌پذیری‌های حوزه فناوری اطلاعات داشته باشند، و بررسی کنند که آیا آنها ریسکی برای سازمان محسوب می‌شوند یا نه؟ پس از آن، چگونگی نصب یا تعمیر آنها در طی زمان را در اولویت قرار دهند.

این داده‌ها به یک اندازه برای تیم‌های مدیریت دارایی فناوری اطلاعات و تیم‌های امنیت حیاتی هستند، اما اغلب می‌توانند در سیلوها تولید شوند. درعوض، این تیم‌ها باید با هم همکاری داشته باشند تا مطمئن شوند که از همه دارایی‌های مورد نیازشان مطلع هستند. با این حال، تیم‌های امنیت فناوری اطلاعات برای اینکه بتوانند تهدیدات امنیتی را، در هنگام اجرای کار، مدیریت کنند باید بلادرنگ از وضعیت دستگاه و آسیب‌پذیری‌های نرم‌افزار آگاه باشند.

از طرف دیگر، تیم‌های مدیریت امنیت فناوری اطلاعات و مدیریت دارایی امنیت اطلاعات تمایل دارند که تجربه بیشتری در ساخت CMDBها و استفاده از این داده‌ها برای مدیریت مستمر نرم‌افزار، مجوزها و خدمات داشته باشند.

این در عمل بدان معنی است که این تیم‌ها باید در ایجاد فهرست دقیقی از دارایی‌های فناوری اطلاعات و بلادرنگ به‌روز نگه داشتن آنها، با هم همکاری کنند. برای تیم امنیت، عامل «بلادرنگ بودن» برای محافظت از دارایی‌ها در گذر زمان ضروری است. از نظر منطقی، تیم امنیت باید حافظ و مسئول مدیریت این داده‌ها باشد. دسترسی تیم‌های مدیریت دارایی فناوری اطلاعات و مدیریت امنیت فناوری اطلاعات به این داده‌ها می‌تواند به تغییر در اولویت‌های آنها و شاخص‌های کلیدی عملکرد (KPI) بینجامد. به جای اینکه هدفتان تدارک فهرستی از دارایی‌ها و درست نگه داشتن آن‌ها باشد، تمرکزتان را بیشتر بر نحوه استفاده از این داده‌ها برای انطباق با مجوز، کاهش هزینه و تخصیص مجدد دارایی‌ها در صورت لزوم، قرار بدهید.

تأکید بر چگونگی استفاده مؤثر از داده‌ها بستگی دارد که این داده‌ها چقدر استفاده همه تیم‌ها مناسب و به‌روز هستند. به‌جای اینکه یک تیم مسئول باشد و سایر افراد برای تهیه اطلاعات از آنها استفاده کنند، باید رویکردی دو سویه وجود داشته باشد. این بدان معناست که هر سیستم امنیتی یا CMDB اجراشده باید بتواند هر سیستم‌ دیگری را که تیم‌های دیگر با داده‌های جدید از آن استفاده می‌کنند، به‌روز کند. اگر تغییری در سیستم‌های دیگر رخ دهد، باید به واسطه APIها به عقب برگردانده شوند تا تنها همان منبع حقیقی باقی بماند. این کار باید داده‌های مربوط به دارایی‌های خاص را توسعه بدهد تا همه تیم‌های درگیر بتوانند از این «شناخت بهتر داده‌ها» بهره‌مند شوند.

واریانس: یکی از بزرگ‌ترین مشکلات موجود در ITAM

در میانگین فهرست دارایی‌ها، نام فروشنده‌ها می‌تواند به هشت روش مختلف کدگذاری شود، این در حالی است که ممکن است محصولات این فروشنده‌ها با بیست حالت مختلف کدگذاری شوند. این امر سبب می‌شود که به موازات پیشرفت شرکت‌های فناوری و خرید کالا و کدگذاری‌های بیشتر، شاهد پیچیدگی‌هایی در کدگذاری کالاهای مختلف باشید. این واریانس، مدیریت پیگیری بین تیم‌ها را دشوارتر می‌کند؛ این مسئله روند مدیریت دارایی و انطباق مجوز را برای مدیریت دارایی فناوری اطلاعات پیچیده می‌کند. برای آسان‌تر شدن مدیریت واریانس، داده‌های فهرست دارایی‌ها باید به عنوان بخشی از توسعه‌ داده‌های مربوط به دارایی‌ها، به حالت عادی دربیایند.

از آنجاکه شرکت‌ها برای پیگیری اهداف و مقاصدشان خدمات جدیدی درخواست می‌کنند، توسعه رویکردهای جدید برای پاسخگویی به این درخواست‌ها روزبه‌روز پیچیده‌تر خواهد شد. طراحی و پیکربندی این خدمات، ایمن نگه داشتن آنها و مدیریت نحوه تحویل آنها یک چالش خواهد بود. با این حال، همچنان «اصل تاریکی» در فناوری اطلاعات و طراحی خدمات (service design) اهمیت خود را از دست نداده و دستیابی به یک منبع واحد حقیقت در حوزه فناوری اطلاعات امکان‌پذیر است. در حالی که تمرکز داده‌ها بر دارایی‌ها و نحوه استفاده از آنها می‌تواند نیل به این امر را میسر کند، همکاری بین فرآیندهاست که به تیم‌های متعدد کمک می‌کند تا به اهداف متفاوتشان دست یابند. مادامی که سیستم‌ها پیچیده هستند، آن داده‌هایی که اکنون می‌توانیم جمع‌آوری کنیم می‌توانند همچون نوری در این تاریکی باشند و در گذر زمان، به ما کمک کنند که درک بهتری از این سیستم‌ها داشته و از آن‌ها درست استفاده کنیم.

این یادداشت در رسانه اینترنتی راه پرداخت نیز منتشر شده است.

برای مطالعه سایر یادداشت های گروه فناوری پرند در رسانه اینترنتی راه پرداخت، اینجا کلیک کنید.