ايتنا - ۱۷ پرسش امنیتی هنگام خرید BPMS

آیا ابزار BPMS شما امن می‌باشد؟ آیا مطمئن هستید که تمامی کانال‌های ارتباطی به ابزار شما، امن است؟ اگر با شنیدن این سؤالات، احساس نگرانی کردید، حتماً برای انتخاب محصول‌تان با یک کارشناس امنیت مشورت کنید. نکات امنیتی زیر را مطالعه و محصول BPMS موردنظر را تست کنید.

۱. کنترل دسترسی - احراز هویت و مجوز دسترسی
شاید مهم‌ترین جنبه امنیتی BPM، کنترل دسترسی باشد. داشتن صرفاً نام کاربری و رمز عبور جهت فراهم کردن احراز هویت کافی نیست.
شما نیاز به روش‌های مجوز دسترسی مناسب نیز دارید.
بسیاری از سیستم‌ها مجوز دسترسی را از سرویس LDAP استفاده می‌کنند که دسترسی کاربران به اطلاعات و منابع را مشخص می‌کند.
اگر کاربری بتواند به چگونگی دسترسی به گروه LDAP پی ببرد، می‌تواند به همه چیز دسترسی داشته باشد، سرور BPM می‌بایست برخی راه‌های از پیش تعریف شده برای دسترسی کاربر مستر را داشته باشد.

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-چگونه کاربر مستر به منابع و اطلاعات دسترسی دارد؟
-آیا زمانی که به یک شخص دسترسی کاربر مستر داده می‌شود، ما با خبر می‌شویم؟
-آیا برای احراز هویت نیازمند سیستم third party هستیم؟
-آیا سیاست‌های امنیتی به قدر کافی کاربران متخلف را محدود می‌کند؟

۲. رمزگذاری کلمه عبور
کلمه عبور باید به صورت رمزگذاری شده ذخیره شود و شامل کلمه‌های عبور کاربران، کلمه عبور پایگاه‌داده و نیز سیستم‌های خارجی است. سیستم‌هایی که از hash کردن (مانند MD۵) برای رمزگذاری استفاده می‌کنند، بسیار بهتر و ایمن‌تر از سیستم‌هایی هستند که بدون رمزگذاری، کلمه‌عبور را ذخیره می‌کنند. مراقب باشید! برخی از توسعه‌دهندگان سایت به اشتباه کلمه عبور را در فایل متنی ذخیره و گاهی در کلاس (با استفاده از جاوا) ذخیره می‌کنند که با تجزیه و decompiling به راحتی می‌توان به کلمه عبور، دسترسی پیدا کرد.

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-چه کلمات عبوری را ذخیره می‌کنیم؟
-آیا کلمه عبور، رمز شده می‌باشد؟
-آیا در سیستم توزیع شده، دسترسی به فایل سیستم و پایگاه‌داده به آسانی امکان‌پذیر است؟
-آیا سیاستی مبنی بر بررسی کد هر خط از برنامه وجود دارد؟

۳. امنیت در سطح فیلد
فرآیندها اغلب شامل داده‌ها و فیلدها هستند. آیا مطمئن هستید که در سطح فیلد، امنیت وجود دارد؟ و یادآوری کنم که اغلب سیستم‌های BPM، شامل این دسترسی نیستند! شما امنیت را در سطح فرم فراهم می‌کنید، لیکن در سطح فیلد -به صورت مجزا- امنیت وجود ندارد و هکر به راحتی می‌تواند به فیلدهای اطلاعاتی دسترسی داشته و داده‌های حساس نظیر قیمت، نرخ و ... را تغییر دهد.

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-آیا امنیت در سطح فیلد وجود دارد؟
-از کجا می‌توان فهمید که چه کسی به چه فیلدی دسترسی دارد؟
-صرفاً توسعه‌دهندگان فیلد را در فرم پنهان کنند، کافی‌ست یا اینکه دسترسی به فیلد، در سرور هم باید در نظر گرفته شود؟
-چه فیلد و داده‌ای محرمانه است؟

۴.ارسال ایمیل
فرض کنید کاربر، ایمیلی را شامل لینک به فرم فرآیندی دریافت می‌کند. ایمیل را به سمت دیگری در سازمان ارسال می‌کند. گیرنده ایمیل بر روی لینک، کلیک و فرم را باز می‌کند! او می تواند رد یا تأیید کند. نقطه مرگ و خطر همین‌جاست! صادقانه فکر کنیم که چند نفر از شما این سناریو را تست کرده‌اید؟ بسیاری از شرکت‌هایی که خواهان این ویژگی هستند، تهدید امنیتی را شناسایی نکرده‌اند.

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-لینک به فرم‌های فرآیندی چگونه پیاده‌سازی شده است؟
-چه اطلاعاتی در لینک، در دسترس است؟ آیا اطلاعات رمز شده‌اند؟
-آیا سیستم پیش از باز کردن فرم، مجوز دسترسی را چک می‌کند؟
-آیا ارسال ایمیل، امنیت را به خطر می‌اندازد؟

۵. یکپارچگی سیستم
شما صرفاً سیستم بسیار یکپارچه در مورد ابزار BPM می‌سازید. آیا مطمئن هستید که ارتباط میان داده‌هایی که در جریان هستند نیز یکپارچه است؟ و امنیت در هر کنترلی پیاده‌سازی شده است؟ اگر سیستم‌ها، درخواست کلمه عبور داشتند، مطمئن هستید که رمز شده انتقال می‌یابد؟ بسیاری از ما فکر می‌کنیم که اینترانت، محیط ارتباطی امنی است، در صورتی‌که واقعاً اینطور نیست. با تکنولوژی wi-fi و مشابه آن، یک هکر باهوش می‌تواند در پارکینگ شما به شبکه‌تان دسترسی داشته باشد!

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-سیستم های ما در ارتباط با چه سیستم‌هایی هستند؟
-چگونه اعتبار تعیین می‌شود؟
-آیا این سیستم‌ها در مورد احراز هویت، چالش دارند؟
-آیا به جای IP از نام دامین استفاده می‌کنید؟ اگر پاسخ مثبت است، چه میزان از هک کردن DNS Server خود جلوگیری کرده‌اید؟

۶. دسترسی ریشه‌ای
تازه‌واردها این مشکل را دارند که دسترسی admin و ریشه‌ای به همه‌چیز و همه منابع را به‌کار می‌برند. سرور برنامه و پایگاه‌داده با امتیاز ریشه‌ای اجرا می‌شود. این جمله به چه معناست؟ اگر برنامه شما با دسترسی ریشه‌ای اجرا شود، برخی می‌توانند کدهایی را با دسترسی admin اجرا نموده و فایل‌های سیستمی را از بین ببرند. همیشه برنامه را با حداقل امتیاز برای اجرای برنامه، تنظیم کنید. همیشه حمله‌ها از درون شبکه رخ می‌دهند!

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-پلتفرم برنامه اجرایی چیست؟
-چه سرویس‌هایی اجرا می‌شوند؟
-چه تعداد از کاربران با سطح دسترسی admin هستند؟
-آیا در زمان استقرار برنامه، می‌توان کدهایی را اجرا نمود؟

۷. اطلاعات هم‌تیمی
این آیتم مربوط به کسب‌وکار است. آیا کاربران می‌توانند کار هم تیمی خود را ببینند؟ آیا تیم‌ها می‌توانند کارهای دیگر تیم‌ها را ببینند؟ اگر جواب مثبت است، جزئیات سطح دسترسی چیست؟

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-آیا دیگران به کارهای من دسترسی دارند؟
-چه سطحی از اطلاعات در دسترس است؟
-چه کارهایی در سطح افراد و چه سطحی، گروهی است؟

۸. امنیت سرور
بیشتر ابزارهای BPM از سرور برای محیط اجرایی خود استفاده می کنند. اگر ابزار BPM شما به خوبی امن باشد، سرور هم به اندازه کافی، امن است؟ سرور شما کاربر Adminای دارد که از طریق آن هر کسی می‌تواند به تمامی اطلاعات شما دسترسی داشته داشته و با استفاده از این امتیاز، هکر می‌تواند سرور را متوقف یا خاموش کند.

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-برای اجرای فرآیندها، از چه نوع سروری استفاده می‌کنید؟
-آیا شما نام و کلمه عبور پیش‌فرض را تغییر داده‌اید؟
-آیا پورت مدیریت سرور برنامه، مسدود شده است؟
-آیا دسترسی مستقیم یا از طریق API و Web service به سرور برنامه مسدود شده است؟

۹. ورود یکپارچه (SSO)
اغلب سازمان‌ها برای ورود به برنامه، از سیستم "ورود یکپارچه" استفاده می‌کنند. سازمان‌های بالغ، عمل احراز هویت ابزار BPM خود را با مکانیزم sso، یکپارچه نموده و کمتر از احراز هویت windows استفاده می‌کنند. گاهی کلمه عبور توسط ارائه دهنده sso به اشتراک گذاشته می‌شود. در نهایت شما می‌توانید درصورتی‌که sso درست پیاده‌سازی نشده باشد، بدون احراز هویت وارد سیستم شوید.

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-کدام استاندارد sso پیاده‌سازی شده است؟
-آیا سیستم به نام کاربری و کلمه عبور windows وابسته می‌باشد؟
-چه سیستم‌هایی از sso استفاده می‌کنند؟ آیا این سیستم‌ها به اندازه کافی، امن هستند؟
-آیا می‌توان token سیستم دیگر را در ابزار BPM استفاده نمود؟

۱۰. پورت‌ها و دسترسی خارج از سیستم
DMZ برای امن کردن دسترسی به منابع شبکه داخلی به‌کار برده می‌شود. اگر ابزار BPM توسط فروشنده و مشتری خارج از شبکه شما در دسترس است، در معرض خطر امنیتی بزرگی هستید. باید مطمئن باشید که پورت‌های مناسب مسدود شده و شبکه اختصاصی مجازی (VPN) و نیز شیوه‌های امنیتی مشابه در محل فراهم شده است. در غیر این‌صورت، مستعد حملات امنیتی هستید.

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-کدام پورت، در سرور شما باز است (و چرا)؟
-چه اطلاعات و منابعی خارج از سرور و سیستم در دسترس است؟
-کاربران خارجی، مستقیم به سیستم دسترسی دارند یا از طریق پروکسی؟
-آیا کاربر خارجی به API و یا Web Service دسترسی دارد؟
-آیا برای دسترسی خارجی، پروتکل HTTP پیاده‌سازی شده است؟

هم‌چنین استفاده از firewall مناسب هم پیشنهاد می‌شود. گاهی سیستم در معرض حمله «انکار سرویس» (Dos) برای فلج کردن سیستم خواهد بود.

۱۱. کنترل دسترسی به رابط برنامه‌نویسی نرم‌افزار
دسترسی به API بسیار اساسی و حائز اهمیت است. بسیاری از ابزارهای BPM، سرویس دسترسی به سرور از طریق API را ارائه داده و شما می‌توانید به آسانی به سرور دسترسی داشته باشید. احراز هویت و مجوز دسترسی هر دو پیش از فراخوانی API باید در نظر گرفته شوند و از این طریق، دسترسی به مهمان یا کاربر غیرمجاز، غیرفعال می‌باشد.

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-چه سرویس‌هایی در قالب API، ابزار BPM ارائه می‌دهد؟
-آیا فراخوانی API، لازم به احراز هویت دارد؟
-پس از احراز هویت، کاربر چه آسیب‌هایی می‌تواند به سیستم برساند؟
-آیا روش‌های کنترل دسترسی و احراز هویت در محل را داریم؟

۱۲. سرویس‌های تحت‌وب
همانند API، دسترسی به سرویس‌های تحت‌وب نیز از اهمیت ویژه‌ای برخوردار هستند. بزرگ‌ترین مشکل، اجرا شدن وب‌سرویس در پورت HTTP است. اگر کاربر از طریق مرورگر، به پرتال BPM دسترسی دارد، به وب‌سرویس هم دسترسی دارد و چنانچه این دسترسی را کنترل نکنید، با مشکل بزرگی روبه‌رو خواهید شد. مشکل دیگر وب‌سرویس، استاندارد بودن آن است؛ افراد می‌توانند وب‌سرویس شما را شناسایی نمایند.

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-آیا ابزار از وب‌سرویس، استفاده می‌کند؟
-تا چه عمقی، شخص می‌تواند سرویس را شناسایی نموده و به چگونگی منطق سرویس پی ببرد؟
-آیا وب‌سرویس شامل احراز هویت و مجوز دسترسی است؟
-آیا سرویس‌های خاص و حساس کاربر در دسترس هستند؟

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

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-آیا سیستم هر نوع اطلاعاتی را منتشر می‌کند؟
-تا چه اندازه دسترسی به اطلاعات منتشر شده امن است؟
-چه اطلاعاتی در پیام منتشر می‌شود؟
-چگونه می‌توان سرویس انتشار را غیرفعال نمود؟

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

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-چگونه دسترسی به داده‌ها کنترل می‌شود؟ آیا اشخاص به داده‌های درونی دسترسی دارند؟
-آیا سطح دسترسی به جدول‌ها، پیاده‌سازی شده است؟
-آیا حقوق دسترسی به گزارشات ابزار BPM برای افراد تعریف شده است؟
-آیا می‌توان از طریق API، داده‌های تاریخچه را واکشی کرد؟

۱۵. امنیت و سمت توسعه‌گر
شما نیاز دارید که امنیت را نظارت و کنترل کنید. اگر شما با منافع عمومی یا پول سروکار دارید، نیاز است که مطمئن شوید، دسترسی منطقی و درست است یا خیر. قانون ساربنز-آکسلی (Sarbanes Oxley) به توسعه‌دهندگان سیستم، اجازه دسترسی به سیستم تولید را نمی‌دهد و دسترسی به داده تولید، نیاز به مستند شدن و مجوز لحظه‎به‎لحظه دارد.

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

۱۶. امنیت فیزیکی
این امر، بدیهی بوده لیکن حتی برای BPM هم مهم است. آیا سرورها به حد کافی امن هستند؟ اگر سیستم در زیرساختارهای ابری اجرا می‌شود، این شانس وجود دارد که سرورهای شما در محل شما نباشد. چگونه مرکز داده‌ها را ایمن ساخته‌اید؟ آیا مخرب شبکه می‌تواند به کسب‌وکارتان آسیب برساند؟

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-آیا اطلاعات محرمانه در محل خودتان است؟
-چه سطحی از امنیت فیزیکی در مراکز داده و اتاق‌های سرور، پیاده‌سازی شده است؟
-آیا دسترسی فیزیکی، نظارت و کنترل می‌شود؟
-آیا داده‌های پشتیبان، در محل امنی ذخیره می‌شوند؟

۱۷. برنامه‌های پس از خسارت
و در نهایت موضوع پر اهمیت! آیا در مواجهه با Dos یا حمله انکار سرویس و مشابه آن، می‌توانید به کسب‌وکارتان ادامه دهید؟ برای ادامه کار، چه راهکاری را در نظر گرفته‌اید؟ باید طرحی برای بازگرداندن اطلاعات خسارت دیده، داشته باشید.

سؤال‌های زیر را از کارشناس امنیت بپرسید:
-آیا طرح و برنامه‌ای در زمینه بازگرداندن داده‌ها و غلبه بر خسارت داریم؟
-در چه بازه زمانی می‌توانیم کسب‌وکار خسارت دیده شده را به وضعیت مناسب و اجرایی بازگردانیم؟
-چه اقداماتی جهت بازگرداندن داده‌های گم شده، اطلاعات خسارت دیده و کلمات رمز عبور به سرقت رفته لازم است؟
-آیا افراد سازمان در این شرایط می‌توانند به راحتی کار خود را ادامه دهند؟
-آیا اشتباهات رخ داده در جایی ثبت می‌گردد؟

منبع: پایگاه دانش BPM رایورز