رفتن به محتوای اصلی
MedaDesk

چرا مدادسک؟

داستان شکل‌گیری MedaDesk

وقتی مسئله فقط «ریموت شدن» نیست

مدانت یک MSP است؛ یعنی بخش مهمی از کار ما ارائه خدمات پشتیبانی و مدیریت فناوری اطلاعات برای سازمان‌های مختلف است. این مدل کاری یک چالش قدیمی و آشنا برای تقریباً همه MSPها دارد: تعدد ابزارهای دسترسی از راه دور.

هر سازمان سیاست امنیتی، مسیر اتصال و ابزارهای خاص خودش را دارد. در نتیجه، کارشناس پشتیبانی پیش از آن‌که به حل مسئله کاربر برسد باید ابتدا راه رسیدن به سیستم او را پیدا کند.

واقعیت روزمره یک MSP

ده‌ها ابزار برای یک کار ساده: رسیدن به کاربر

AnyDesk / TeamViewer

ابزارهای عمومی ریموت که هر مشتری ممکن است یکی از آن‌ها را بپذیرد یا مسدود کند.

VNC / UltraVNC / RustDesk

راهکارهایی که بسته به شبکه و سیاست سازمان در سناریوهای مختلف استفاده می‌شوند.

Rakard / DorsanDesk

ابزارهای محلی یا اختصاصی که به فهرست نرم‌افزارهای موردنیاز کارشناسان اضافه می‌شوند.

PAM / PAM360

در محیط‌های حساس، دسترسی باید از لایه‌های کنترل دسترسی ممتاز عبور کند.

Cisco AnyConnect / FortiClient

هر مشتری ممکن است کلاینت، پروفایل، گواهی و تنظیمات VPN متفاوتی داشته باشد.

Windows VPN / OpenVPN / Kihan

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

مسئله واقعی

برای ما «ریموت» مشکل اصلی نبود

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

یعنی به‌جای اینکه کارشناس روی درخواست کاربر تمرکز کند، بخشی از زمان و انرژی او صرف رسیدن به کاربر می‌شد.

آیا واقعاً باید برای پشتیبانی از صد سازمان، صد روش متفاوت برای اتصال داشته باشیم؟

پاسخ ما

MedaDesk از همین سؤال شروع شد

یک نقطه واحد دسترسی

کارشناس سازمان، کاربر یا دستگاه موردنظر را پیدا می‌کند و عملیات پشتیبانی را از یک مسیر مشخص آغاز می‌کند.

کاهش وابستگی به ابزارهای پراکنده

هدف، اضافه کردن ابزار شماره ۱۰۱ نیست؛ هدف کم کردن پراکندگی ابزارها و مسیرهای اتصال است.

کنترل و ردگیری دسترسی

دسترسی باید مشخص، قابل کنترل و قابل ردیابی باشد؛ نه مجموعه‌ای از رمزها و پروفایل‌های پراکنده روی سیستم کارشناسان.

اتصال پشتیبانی به Service Management

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

یک نکته مهم

حذف VPN و PAM از همه‌جا هدف نیست

MedaDesk قرار نیست سیاست امنیتی سازمان‌ها را دور بزند یا VPN، PAM و کنترل‌های امنیتی را بی‌معنا کند. برعکس، هدف این است که نیاز به نصب و مدیریت ده‌ها ابزار دسترسی روی سیستم کارشناسان کاهش پیدا کند و ارتباطات در یک ساختار مشخص، کنترل‌شده و قابل ردیابی انجام شوند.

سازمانی که نیاز به تأیید مدیر، محدودیت دسترسی یا کنترل‌های امنیتی دارد باید بتواند این سیاست‌ها را حفظ کند؛ بدون اینکه هر کارشناس مجبور باشد یک محیط پیچیده از VPN، رمز عبور و نرم‌افزارهای مختلف را مدیریت کند.

فراتر از اشتراک‌گذاری صفحه

وقتی ریموت بخشی از Service Management می‌شود

چه کسی به سیستم متصل شد؟
به کدام دستگاه متصل شد؟
این اتصال برای کدام درخواست بود؟
نشست چه زمانی آغاز و پایان یافت؟
کارشناس چه مجوزی برای اتصال داشت؟
نتیجه عملیات چگونه در فرآیند پشتیبانی ثبت شد؟

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

چیزی که از MedaDesk می‌خواهیم

یک معماری منسجم برای پشتیبانی از راه دور

MedaDesk برای ما از دل یک نیاز واقعی متولد شد: یک کنسول، یک مسیر مشخص، یک سیاست دسترسی و یک نقطه برای مدیریت ارتباط با سیستم‌های مشتریان.

نه برای اینکه بگوییم ابزارهای موجود بد هستند؛ بسیاری از آن‌ها در جای خود بسیار قدرتمندند. اما یک MSP بیش از آنکه به «یک ابزار ریموت خوب» نیاز داشته باشد، به یک معماری منسجم برای پشتیبانی از راه دور نیاز دارد.

سخن پایانی

«برای این مشتری با چی وصل می‌شیم؟»

اگر MedaDesk به هدفی که برایش تعریف کرده‌ایم برسد، پاسخ این سؤال باید بسیار ساده باشد: با MedaDesk.

88