📣 پیامک تمدید دریافت کردید؟ برای تمدید آنلاین گواهی توکن، بدون مراجعه حضوری اینجا کلیک کنید.
کنترل لایسنس نرم‌افزار با دانگل سخت‌افزاری؛ پاسخ تازه به یک دغدغه قدیمی
دانگل سخت‌افزاری این روزها دوباره موضوع جدی میزهای فنی سازمان‌ها شده است و این بازگشت بی‌دلیل نیست. تیم‌های توسعه نرم‌افزار سازمانی سال‌ها برای جلوگیری از کپی‌شدن محصول خود به شماره سریال، آدرس MAC یا شناسه UUID ماشین مجازی تکیه کرده‌اند، اما هر مدیر دواپس با تجربه می‌داند که این شناسه‌ها به‌راحتی قابل تغییر و بازتولید هستند. کافی است یک ماشین مجازی کلون شود یا چند پارامتر در تنظیمات سیستم دستکاری شود تا یک کپی غیرمجاز از نرم‌افزار، انگار نسخه اصلی است، روی سرور دیگری جان بگیرد. در چنین وضعیتی تنها راه مطمئن برای اثبات اصالت یک استقرار، گره زدن مجوز اجرا به یک ریشه اعتماد فیزیکی است؛ ریشه‌ای که قابل کلون‌شدن نیست و خارج از کیس سرور وجود ندارد.
این مقاله بر پایه یک بررسی فنی دقیق روی سه محصول شناخته‌شده بازار نوشته شده است: توکن رمزنگاری ePass3003 Auto، دانگل حفاظت نرم‌افزار ROCKEY4 SMART و دانگل شبکه‌ای NetROCKEY4ND. هر سه محصول از یک سازنده معتبر بین‌المللی می‌آیند، هر سه روی لینوکس کار میکنند و هر سه می‌توانند مجوز اجرای نرم‌افزار را به یک عامل سخت‌افزاری وابسته کنند؛ اما ماهیت آن‌ها یکسان نیست و همین تفاوت است که انتخاب را دشوار می‌کند. یکی با امضای دیجیتال مبتنی بر استاندارد PKCS#11 حرف می‌زند، دیگری با ماژول، تایمر و شمارنده لایسنس و سومی با سرویس شبکه‌ای و مدیریت نشست‌های هم‌زمان.
اگر محصول شما روی Ubuntu Server اجرا میشود، در قالب سرویس‌های Docker Swarm استقرار می‌یابد و مشتریانتان گاهی در شبکه‌های کاملاً آفلاین کار میکنند، این راهنما دقیقاً برای شماست. در ادامه نخست ضعف روش‌های نرم‌افزاری را روشن می‌کنیم، سپس معماری پیشنهادی اعتبارسنجی را می‌کیم و در پایان هر سه راهکار را با جزئیات فنی، الگوی استفاده و ملاحظات پیاده‌سازی مقایسه می‌کنیم تا انتخاب بر اساس نیاز واقعی محصول انجام شود، نه بر اساس تبلیغات.
فهرست مطالب
چرا شناسه‌های نرم‌افزاری برای محافظت از مجوز کافی نیستند؟
روش سنتی کنترل مجوز اجرای نرم‌افزار ساده است: برنامه هنگام راه‌اندازی، آدرس MAC کارت شبکه، UUID ماشین یا شماره سریال سخت‌افزار میزبان را می‌خواند و با مقدار ثبت‌شده مقایسه می‌کند. این روش در محیط‌های کوچک جواب می‌دهد، اما در استقرارهای سازمانی چند ایراد بنیادی دارد. اول اینکه تمام این شناسه‌ها اطلاعات قابل مشاهده محیط اجرا هستند؛ در ماشین مجازی، hypervisor اجازه می‌دهد مقادیر MAC و UUID و سریال به دلخواه تنظیم شود و یک کلون ساده از دیسک مجازی، همراه با چند خط تغییر پیکربندی، یک استقرار تقلبی کاملاً معتبر می‌سازد. دوم اینکه هیچ عملیات رمزنگاری واقعی در این روش انجام نمی‌شود؛ برنامه فقط یک رشته متن را می‌خواند و مقایسه می‌کند، پس مهاجم نیازی به شکستن الگوریتمی ندارد و کافی است نقطه مقایسه را در باینری خنثی کند.
نگاه دقیق‌تر نشان می‌دهد مسئله فقط فنی نیست و یک بعد تجاری هم دارد. وقتی مجوز بر پایه شناسه‌های قابل جعل گره می‌خورد، توان فروشنده برای مدل‌های لایسنس پیشرفته مثل اشتراک زمانی، فعال‌سازی ماژول‌به‌ماژول یا شمارش دفعات استفاده عملاً صفر است؛ چون هیچ مخزن امنی وجود ندارد که وضعیت مجوز را دور از دسترس مشتری نگه دارد. نتیجه، فرسایش درآمد از راه کپی‌های غیرمجاز و هزینه پشتیبانی برای رفع اختلاف‌های نسخه‌های دستکاری‌شده است.
راهکار جایگزین باید سه ویژگی داشته باشد: اول، انجام یک عملیات واقعی توسط سخت‌افزار که بدون حضور فیزیکی دستگاه تکرارشدنی نباشد؛ دوم، کارکرد کامل در شبکه داخلی و بدون اینترنت، چون بسیاری از استقرارهای سازمانی به دلایل امنیتی کاملاً آفلاین‌اند؛ سوم، سازگاری با معماری‌های مدرن مثل Docker Swarm که در آن یک سرویس چندین Replica دارد و اتصال یک دانگل USB به تک‌تک کانتینرها معنا ندارد. در ادامه می‌بینیم که هر سه محصول بررسی‌شده، هر یک به شیوه خود، این سه شرط را پوشش می‌دهند و تفاوت آن‌ها در عمق و نوع امکانات لایسنس‌دهی است.
معماری پیشنهادی برای کنترل مجوز اجرای نرم‌افزار در Docker Swarm
پیش از مقایسه محصولات، باید تصویر درستی از معماری داشت؛ چون در هیچ‌کدام از این سه گزینه، صرف اتصال دانگل به سرور، سرویس‌ها را متوقف یا فعال نمی‌کند. جریان اعتبارسنجی همیشه از سمت Application آغاز میشود: نرم‌افزار در زمان راه‌اندازی یا پیش از اجرای یک عملیات حفاظتشده، درخواست بررسی مجوز صادر می‌کند. این درخواست به یک سرویس واسط می‌رسد که ما آن را Token Agent یا سرویس اعتبارسنج می‌نامیم. این سرویس با کتابخانه و SDK سازنده ارتباط برقرار می‌کند، عملیات موردنظر را به دانگل متصل به میزبان ارسال می‌دارد و پاسخ را دریافت می‌کند. سپس پاسخ با اطلاعات مجوز و قواعد محصول تطبیق داده میشود و نتیجه به برنامه برمی‌گردد. پس توکن هیچ‌گاه آغازگر ارتباط یا تصمیم‌گیر مستقل نیست؛ نقش آن فقط انجام یک عملیات اثبات‌پذیر است.
برای اینکه پاسخ توکن قابل استفاده مجدد نباشد، اعتبارسنجی باید بر الگوی Challenge–Response بنا شود. برنامه یک مقدار تصادفی و غیرتکراری به‌همراه شناسه مجوز تولید می‌کند و پاسخ سخت‌افزار به همین چالش تازه بررسی میشود؛ به این ترتیب ضبط و بازپخش پاسخ یک درخواست قدیمی، فایده‌ای برای مهاجم ندارد. در مدل‌های مبتنی بر کلید نامتقارن، اصالت پاسخ با کلید عمومی ثبت‌شده سنجیده میشود و در مدل‌های دارای توابع اختصاصی، تطبیق مطابق الگوریتم SDK انجام میگیرد.
در محیط Docker Swarm نکته کلیدی این است که اتصال فیزیکی توکن به هر کانتینر لازم نیست و عملاً هم منطقی نیست. توکن روی یک میزبان مشخص یا سرور مجوز مرکزی قرار میگیرد و یک رابط داخلی، نتیجه اعتبارسنجی را در اختیار Replicaهای مجاز می‌گذارد. اگر سرور داخل ماشین مجازی باشد، انتقال دستگاه USB با قابلیت USB Passthrough زیرساخت مجازی‌سازی انجام میشود. ارتباط سرویس‌ها با Agent باید با احراز هویت سرویس و کانال امن محافظت شود تا کسی خارج از کلاستر نتواند از API اعتبارسنجی سوءاستفاده کند.
خروجی این فرایند می‌تواند اجازه اجرای مستقیم یک عملیات باشد یا به شکل مجوز کوتاهمدت به نام License Lease صادر شود؛ مجوزی که شناسه محصول، استقرار، ماژول‌های مجاز و زمان انقضا را در خود دارد. کنترل هنگام راه‌اندازی کافی نیست: در سرویس‌های طولانی‌مدت، اعتبار مجوز باید در فواصل تعریف‌شده یا پیش از عملیات حساس دوباره بررسی شود تا جدا شدن دانگل یا انقضای لایسنس، طبق سیاست محصول، اجرای عملیات حفاظتشده را محدود کند. مدیریت وضعیت مجوز، صدور Lease، سیاست توقف سرویس و ارتباط میان Nodeها بخشی از منطق نرم‌افزار است و هیچ توکنی این‌ها را به‌تنهایی ارائه نمی‌دهد.
دانگل سخت‌افزاری امنیتی و توکن امضای دیجیتال؛ اشتراک و تفاوت
در بازار ایران، کلمه توکن بیش از هر چیز به یاد توکن امضای دیجیتال میافتد؛ همان دستگاه کوچکی که مدیران اداری برای امضای اسناد در سامانه‌های ثبت من، ستاد ایران، جامع تجارت و سامانه‌های مالیاتی به گردن می‌آویزند. نمونه پرکاربرد این خانواده، توکن epass3003 Auto است که کلید خصوصی کاربر را داخل تراشه امن نگه می‌دارد و عملیات امضا را روی همان چیپ انجام می‌دهد. این توکن با استاندارد PKI کار می‌کند، تا هشت گواهی امضا را نگه می‌دارد و روی ویندوز، لینوکس و مک اجرا میشود. اما باید دقت کرد که کاربرد اداری آن با سناریوی کنترل لایسنس نرم‌افزار تفاوت ماهوی دارد: در امضای دیجیتال، هدف اثبات هویت یک شخص یا سازمان در برابر سامانه دولتی است و در حفاظت از نرم‌افزار، هدف اثبات اصالت یک استقرار در برابر منطق مجوزدهی خود محصول است.
دانگل سخت‌افزاری حفاظت از نرم‌افزار، در واقع پسر عموی فنی همین توکن است. هر دو یک چیپ امن دارند، هر دو از درگاه USB کار میکنند و هر دو تکیه‌گاهشان انجام عملیات رمزنگاری داخل دستگاه است؛ اما خانواده دانگل‌ها علاوه بر رمزنگاری، مخزن مجوز هم دارند: ماژول‌های فعال، تایمر اعتبار و شمارنده مصرف را داخل خود نگه می‌دارند و توابعی در اختیار برنامه می‌گذارند که این مقادیر را بخواند و بر اساس آن تصمیم بگیرد. این همان نقطه‌ای است که خانواده ROCKEY از ePass جدا میشود.
درک این تفکیک برای انتخاب محصول حیاتی است، چون سه گزینه این مقاله دقیقاً روی این طیف قرار می‌گیرند: ePass3003 Auto نزدیک‌ترین عضو به دنیای PKI و امضای استاندارد است، ROCKEY4 SMART محصولی برای کنترل مجوز داخل خود دانگل است و NetROCKEY4ND همین قابلیت را به شبکه می‌کشاند. انتخاب درست به این بستگی دارد که در محصول شما، کدام نوع اثبات اصالت و کدام مدل تجاری لایسنس اولویت دارد؛ موضوعی که در بخش مقایسه به‌تفصیل برمی‌گردیم.
اکوسیستم سخت‌افزاری امنیت سازمانی؛ از کنترل لایسنس تا احراز هویت چندعاملی
دانگل و توکن، دو عضو از خانواده بزرگ‌تری هستند که زیرساخت اعتماد دیجیتال را می‌سازند و شناخت بقیه اعضا به تصمیم‌گیری بهتر کمک می‌کند. در سمت احراز هویت کاربران، دستگاه‌های رمزیاب رهسا شامل مدل‌های C100 و C200 و درسا ۳۰۰ رمز یکبار مصرف مبتنی بر استانداردهای TOTP و HOTP و سازوکار Challenge–Response تولید میکنند و در استقرارهایی که اینترنت یا شبکه باز وجود ندارد، گزینه‌ای مطمئن برای ورود امن به سامانه‌های سازمانی هستند. این دستگاه‌ها از نظر فنی با دانگل‌های این مقاله هم‌خانواده‌اند: هر دو بر اصل «اثبات از راه عملیات سخت‌افزاری» بنا شده‌اند.
در لایه سامانه‌های احراز هویت چندعاملی، سامانه نشانه رهسا بر استاندارد جهانی FIDO2 و WebAuthn کار می‌کند؛ سامانه‌ای بدون گذرواژه که با بیومتریک و کلید USB، ورود به سرویس‌های سازمانی را از حملات فیشینگ و سرقت گذرواژه مصون می‌کند و برای احراز هویت کارمندان و مشتریان سازمان‌ها و بانک‌ها طراحی شده است. مشابه این سامانه با نام فوآس نیز برای ارسال رمز یکبار مصرف و مدیریت ورود امن کاربران تحت وب به کار می‌رود.
پیوند این اکوسیستم با موضوع مقاله روشن است: هر جا امنیت بر رمزنگاری سخت‌افزاری تکیه کند، سطح حمله به‌شدت کوچک میشود. در کنترل لایسنس، کلید یا مقادیر مجوز داخل دانگل زندگی می‌کند و بیرون کشیدن آن عملاً ناممکن است؛ در احراز هویت، کلید خصوصی هرگز دستگاه کاربر را ترک نمی‌کند. همین فلسفه مشترک است که باعث میشود سازمانی که برای ورود امن از توکن و رمزیاب استفاده می‌کند، برای محافظت از محصولات نرم‌افزاری خود نیز سراغ راهکار سخت‌افزاری برود و برعکس. تجربه نشان داده سازمان‌هایی که این دو لایه را با هم پیاده میکنند، هزینه پشتیبانی کمتری برای حوادث امنیتی می‌پردازند و فرایند ممیزی نرم‌تر پیش می‌رود.
راهکار مبتنی بر epass3003 Auto؛ اثبات اصالت با امضای دیجیتال
epass3003 Auto در اصل یک توکن رمزنگاری از خانواده PKI است، نه یک سامانه آماده مدیریت لایسنس. قوت آن در نگهداری امن کلید خصوصی و انجام عملیات مبتنی بر کلید از طریق رابط استاندارد PKCS#11 است؛ استانداردی که در دنیای لینوکس پشتیبانی گسترده‌ای دارد و همین موضوع، یکپارچه‌سازی آن با برنامه‌های سمت سرور را ساده می‌کند. بر اساس مشخصات محصول، عملیات RSA تا ۲۰۴۸ بیت و سازوکار امضای RSA همراه با SHA-256 در این رابط پشتیبانی میشود و SDK لینوکسی شامل کتابخانه ۶۴ بیتی و نمونه‌کدهای C/C++ است.
در این رابط، توابع C_GetSlotList و C_GetTokenInfo توکن را شناسایی میکنند، C_OpenSession و C_Login نشست و احراز هویت را می‌سازند، C_GenerateKeyPair جفت‌کلید تولید می‌کند و C_SignInit و C_Sign امضای داده را انجام می‌دهند. سناریوی استفاده برای کنترل مجوز چنین است: هنگام صدور لایسنس، روی دانگل مشتری یک جفت‌کلید RSA ساخته میشود و کلید عمومی آن همراه شناسه محصول، مشتری و استقرار در سامانه فروشنده ثبت میگردد. هنگام اجرای نرم‌افزار، سرویس اعتبارسنج یک Challenge تازه با Nonce غیرتکراری می‌سازد، توکن آن را با کلید خصوصی امضا می‌کند و برنامه با کلید عمومی ثبت‌شده، امضا را راستی‌آزمایی می‌کند. اگر امضا معتبر باشد، حضور دانگل اصلی اثبات شده است؛ روشی که از خواندن ساده شماره سریال USB جهش بنیادی دارد.
این توکن در شبکه‌های آفلاین بی‌نقص کار می‌کند چون هیچ‌کدام از مراحل امضا و بررسی به اینترنت نیاز ندارد و عملیات PKCS#11 در یک سرویس لینوکسی بدون رابط گرافیکی انجام میشود. در Docker Swarm نیز دانگل به یک میزبان ثابت یا سرور مجوز مرکزی متصل میشود و نتیجه اعتبارسنجی از راه API داخلی به Replicaها می‌رسد.
اما مرزهای این گزینه را باید صادقانه دید: epass3003 Auto هیچ سرویس شبکه‌ای آماده، License Server، قابلیت توقف خودکار سرویس یا مدیریت تعداد کاربران ارائه نمی‌دهد؛ همه این‌ها را تیم توسعه باید بسازد. همچنین چند نکته فنی حیاتی وجود دارد. در نمونه‌کد آموزشی SDK مقدار CKA_EXTRACTABLE روی TRUE تنظیم شده، در حالی که برای جلوگیری از کپی باید کلید خصوصی با CKA_SENSITIVE=TRUE و CKA_EXTRACTABLE=FALSE ساخته شود. نمونه امضای SDK از سازوکار قدیمی SHA-1 استفاده می‌کند، اما راهنمای محصول SHA-256 را نیز پشتیبانی می‌کند و برای طراحی جدید انتخاب بهتری است. مدیریت PIN نیز نباید فراموش شود: PIN توکن نباید داخل Image کانتینر یا مخزن کد ذخیره شود و سرویس باید روش امنی برای تأمین آن و بازیابی نشست پس از ری‌استارت داشته باشد. در مجموع، این گزینه زمانی انتخاب اول است که اثبات رمزنگاری‌شده اصالت دانگل با رابط استاندارد، اولویت نخست محصول باشد.
راهکار مبتنی بر ROCKEY4 SMART؛ مدیریت ماژول، زمان و شمارنده
ROCKEY4 SMART دانگلی تخصصی برای حفاظت از نرم‌افزار است و برخلاف epass3003، از بدو تولد برای سناریوی لایسنس طراحی شده است. این محصول به‌جای تکیه صرف بر استاندارد PKCS#11، از API اختصاصی سازنده استفاده می‌کند که علاوه بر محاسبات وابسته به سخت‌افزار، مخزنی از اطلاعات مجوز را هم داخل خود دانگل نگه می‌دارد. SDK لینوکسی آن شامل کتابخانه‌های ۳۲ و ۶۴ بیتی، فایل‌های Header و نمونه‌کدهای C و جاوا است و یکپارچه‌سازی با سرویس‌های سرور را ممکن می‌کند.
در API این محصول، توابع RY_FIND و RY_OPEN دانگل را پیدا و باز میکنند و RY_CLOSE نشست را می‌بندد. تابع RY_SEED در برابر ورودی، پاسخی محاسباتی وابسته به رمزهای داخلی دانگل تولید می‌کند و توابع RY_CALCULATE1/2/3 الگوریتم‌های اختصاصی ذخیره‌شده در دستگاه را اجرا میکنند. اما نکته تمایزآمیز، ظرفیت لایسنس‌دهی داخلی است: هر دانگل ۶۴ ماژول، ۶۴ تایمر و ۶۴ شمارنده دارد. فعال بودن یک قابلیت نرم‌افزاری را می‌توان به وضعیت یک ماژول گره زد، تاریخ انقضا یا ساعات استفاده را با تایمر کنترل کرد و دفعات اجرا را با شمارنده محدود نمود؛ توابعی مانند RY_CHECK_MODULE و RY_GET_TIMER_EX و RY_GET_COUNTER_EX این مقادیر را در اختیار برنامه می‌گذارند.
قابلیت برجسته دیگر، بهروزرسانی آفلاین مجوز است. در گردش کار Parent/Child، تولیدکننده بسته بهروزرسانی مخصوص دانگل مقصد را صادر می‌کند و مشتری آن را بدون هیچ اتصال اینترنتی روی دانگل خود اعمال می‌نماید؛ توابعی مثل RY_UPDATE_GEN_EX و RY_UPDATE_EX در SDK برای ساخت و اعمال این بسته‌ها موجودند. این ویژگی برای محصولاتی که مشتریانشان در شبکه‌های بسته کار میکنند، یک مزیت عملیاتی واقعی است: تمدید اعتبار، فعال‌سازی ماژول جدید یا افزایش سقف مصرف، همه با یک فایل و بدون اینترنت انجام میشود.
دو نکته فنی را نباید نادیده گرفت. اول اینکه در روش RY_SEED، دانگل‌هایی با رمزهای داخلی یکسان به چالش یکسان پاسخ یکسان می‌دهند؛ پس استفاده از یک Seed ثابت یا رمزهای مشترک برای همه مشتریان، مبنای درستی برای تفکیک استقرارها نیست و تخصیص رمزها باید به‌صورت کنترل‌شده و یکتا انجام شود. دوم اینکه پایان مقدار تایمر به معنای توقف خودکار برنامه نیست؛ نرم‌افزار باید مقادیر را بخواند و خودش تصمیم بگیرد. ROCKEY4 SMART سرویس شبکه‌ای آماده برای Docker Swarm ندارد و ساخت Token Agent و API داخلی همچنان کار تیم توسعه است؛ اما اگر مدل تجاری محصول شما به زمان، ماژول و شمارنده وابسته است، این گزینه امکانات آماده‌تر و متناسب‌تری نسبت به رقبای خود ارائه می‌دهد.
راهکار مبتنی بر NetROCKEY4ND؛ دانگل شبکه‌ای برای چند سرویس
NetROCKEY4ND همان DNA خانواده ROCKEY را دارد با یک تفاوت بنیادی: دانگل مرکزی آن به‌همراه یک License Server شبکه‌ای عرضه میشود. یعنی به‌جای اینکه هر سرور دانگل خودش را داشته باشد، یک دستگاه روی سرور مرکزی قرار میگیرد و همه سرویس‌های مجاز از راه شبکه به آن دسترسی پیدا میکنند. این معماری برای استقرارهای Docker Swarm که چند Replica روی چند Node دارند، از ابتدا با کانال ارتباطی آماده به دنیا آمده است و تیم نرم‌افزار را از نوشتن سرویس واسط برای دسترسی به USB بی‌نیاز می‌کند.
از نظر فنی، سرویس سرور به‌نام ryserv اجرا میشود و کلاینت‌ها با کتابخانه libNetRockey4ND.so و فایل سرآیند NetRockey.h به آن وصل می‌شوند. پیکربندی سمت سرور و کلاینت در فایل‌های SvrCfg.ini و CliCfg.ini انجام میگیرد و پورت پیش‌فرض ارتباط TCP/UDP، عدد 3152 است. مقادیر نمونه شامل Timeout پاسخ دو ثانیه و IdleTime سه دقیقه است؛ یعنی نشست کلاینت‌های بدون فعالیت پس از سه دقیقه آزاد میشود و ظرفیت دانگل به مشتریان جدید برمی‌گردد. مدیریت ظرفیت در دو حالت Private و Share انجام میشود: در حالت خصوصی، ماژول برای یک فرایند انحصاری باز میشود و در حالت اشتراکی، چند فرایند مجاز به استفاده هم‌زمان هستند. هر ماژول در هر فرایند فقط یکبار باز میشود و Handle آن میان Threadهای همان فرایند قابل استفاده است.
چرخه کاری هر کلاینت شبیه دانگل محلی است: با RY_FIND دانگل مجاز در شبکه پیدا میشود، با RY_OPEN ماژول موردنظر باز میشود و License Server بر اساس ظرفیت و حالت ماژول، درخواست را می‌پذیرد یا رد می‌کند. برای اتصال به Docker Swarm دو مسیر وجود دارد: هر Replica مستقیماً کتابخانه کلاینت را فراخوانی کند، یا یک Adapter مرکزی ارتباط با سرور لایسنس را بر عهده بگیرد و نتیجه را از راه API داخلی توزیع کند. انتخاب میان این دو به مدل شمارش نشست و معماری محصول بستگی دارد؛ یادمان باشد که شمارش نشست‌های License Server لزوماً معادل تعداد کاربران نهایی یا Replicaها نیست و باید با واحد شمارش قرارداد لایسنس هماهنگ شود.
از نظر امنیت، License Server باید فقط در شبکه‌های مجاز در دسترس باشد، قواعد فایروال محدود تعریف شود و در صورت نیاز، احراز هویت سرویس‌ها در لایه Adapter اعمال گردد؛ SDK این محصول رابط اختصاصی خودش را دارد و نباید آن را بدون مستندات مشخص معادل mTLS دانست. رمزهای نمونه در فایل clienttest.c صرفاً آموزشی‌اند و نباید بدون تغییر در محصول استفاده شوند. در مجموع، اگر دسترسی چند سیستم به یک دانگل مرکزی و مدیریت سهمیه‌های هم‌زمان، نیاز واقعی شماست، این مدل تنها گزینه‌ای است که این زیرساخت را آماده تحویل می‌دهد.
مقایسه کاربردی سه راهکار و راهنمای انتخاب
وقتی سه گزینه کنار هم قرار می‌گیرند، معیار انتخاب دیگر «کدام بهتر است» نیست و «کدام به نیاز واقعی محصول نزدیک‌تر است» میشود. ePass3003 Auto بر عملیات رمزنگاری استاندارد تمرکز دارد، ROCKEY4 SMART بر کنترل ویژگی‌های مجوز داخل خود دانگل و NetROCKEY4ND بر دسترسی شبکه‌ای و مدیریت نشست‌های هم‌زمان. اگر اولویت شما این است که نرم‌افزار با یک امضای قابل راستی‌آزمایی، حضور کلید خصوصی مرتبط با دانگل را اثبات کند، epass3003 مناسب‌ترین گزینه است؛ در این مسیر عملیات امضا با PKCS#11 انجام میشود اما اطلاعات مجوز، ارتباط با Replicaها و سیاست توقف Backend باید در نرم‌افزار تعریف شوند.
اگر مدل تجاری محصول به تاریخ انقضا، ماژول‌های فعال، شمارنده مصرف یا تمدید آفلاین وابسته است، ROCKEY4 SMART امکانات آماده‌تری فراهم می‌کند: تایمر، شمارنده، ماژول و گردش کار بهروزرسانی Parent/Child در همین دانگل زندگی میکنند؛ فقط به یاد داشته باشید که برنامه باید وضعیت آن‌ها را بخواند و خودش تصمیم بگیرد، چون دانگل به‌تنهایی هیچ برنامه‌ای را متوقف نمی‌کند.
اگر مسئله اصلی، دسترسی چند سیستم به یک دانگل مرکزی بدون توسعه سرویس USB است، NetROCKEY4ND مزیت مستقیم دارد؛ چون License Server و کتابخانه کلاینت شبکه‌ای همراه محصول ارائه میشود و سهمیه نشست‌های هم‌زمان را هم مدیریت می‌کند. تنها یادآوری مهم این است که شمارش نشست در این سرور لزوماً معادل تعداد کاربران نهایی یا کانتینرها نیست و باید با مدل لایسنس محصول هماهنگ شود.
نکته سرنوشت‌ساز در هر سه گزینه، مرز میان قابلیت آماده توکن و منطقی است که تیم توسعه باید بنویسد. epass3003 عملیات PKCS#11 را می‌دهد، ROCKEY4 SMART توابع اختصاصی و داده‌های مجوز را و NetROCKEY4ND به این‌ها سرویس شبکه‌ای و مدیریت ظرفیت را می‌افزاید. اما صدور مجوز تجاری، اتصال نتیجه اعتبارسنجی به Backend، صدور و تمدید مجوز کوتاهمدت، ارتباط امن با Docker Swarm و توقف عملیات پس از نامعتبر شدن مجوز، قابلیت آماده هیچ‌کدام نیست. در دو مدل محلی، ساخت API شبکه‌ای مرکزی هم بر عهده شماست و در NetROCKEY4ND فقط لایه ارتباط با خود دانگل آماده است، نه لایه کسب‌وکار. معیارهای هزینه، پیچیدگی توسعه و شیوه پشتیبانی را هم به این تحلیل اضافه کنید تا تصمیم نهایی سنجیده باشد.
جدول زیر تصویری شفاف و تطبیقی از امکانات و ابعاد فنی این سه محصول امنیتی ارائه می‌دهد:
شاخص ارزیابی فنی و تجاری | توکن ePass3003 Auto | دانگل ROCKEY4 SMART | دانگل NetROCKEY4ND |
استاندارد نرم‌افزاری و API | استاندارد رمزنگاری PKCS#11 | توابع محاسباتی اختصاصی FEITIAN | کتابخانه اختصاصی شبکه FEITIAN |
هسته اثبات اصالت | امضای دیجیتال RSA 2048 / SHA-256 | الگوریتم محاسباتی داخلی Seed/Cal | نشست‌های شبکه‌ای متصل به لایسنس |
سرویس سرور شبکه‌ای پیش‌فرض | ندارد (نیاز به توسعه Token Agent) | ندارد (ارتباط محلی با درگاه USB) | دارد (سرویس آماده به کار ryserv) |
انقضای تاریخی و شمارنده داخلی | وابسته به منطق نرم‌افزار و سرور | ۶۴ ماژول، ۶۴ تایمر و ۶۴ شمارنده | بدون تایمر داخلی پیشرفته |
بهروزرسانی محتویات به شکل آفلاین | نیاز به ابزارهای بازتولید گواهی | سیستم اختصاصی کد والد و فرزند | امکان‌پذیر با ابزارهای نرم‌افزاری |
کنترل مصرف نشست‌های هم‌زمان | پیاده‌سازی دستی در لایه نرم‌افزار | پیاده‌سازی دستی در لایه نرم‌افزار | مدیریت داخلی با حالات Share و Private |
نیاز به پیاده‌سازی نرم‌افزاری | سطح متوسط به بالا | سطح متوسط | سطح کم در بخش زیرساخت شبکه |
بررسی این مشخصات نشان می‌دهد که اگر اولویت سازمان اثبات اصالت بدون ابهام با کلیدهای نامتقارن و سازگاری با معماری‌های امنیتی کلان باشد، توکن ePass3003 انتخابی بی‌رقیب است. در مقابل، شرکت‌هایی که نیاز به مدل‌های درآمدی اشتراکی، ماژول‌های جداگانه با قیمت‌های مختلف و شمارش حجم پردازش دارند، از دانگل ROCKEY4 SMART بیشترین بهره را می‌برند. شرکت‌هایی که با چالش توزیع کلید بین ده کانتینر هم‌زمان مواجهند و نمی‌خواهند درگیر برنامه‌نویسی سرویس شبکه لایسنس شوند، با انتخاب NetROCKEY4ND در کمترین زمان به پاسخ مطلوب می‌رسند.
چرا بهروزرسانی درایور و پیش‌نیازها هنگام تمدید گواهی حیاتی است؟
شاید تا کنون برای شما هم پیش آمده که توکن امضای دیجیتال را به رایانه وصل می‌کنید اما سامانه مقصد آن را شناسایی نمی‌کند یا پیام خطای مربوط به کتابخانه PKCS#11 می‌بینید. تجربه پشتیبانی نشان می‌دهد بخش بزرگی از این خطاها از خود توکن نیست؛ ریشه آن در قدیمی بودن میان‌افزارها و پیش‌نیازهای سامانه است. برای برقراری ارتباط توکن با سامانه‌هایی مثل ثبت من، ستاد ایران، جامع تجارت و سامانه‌های مالیاتی، معمولاً نرم‌افزارهایی مثل جاوا و دستینه باید نصب باشند و وقتی نسخه این اجزا با نسخه میان‌افزار توکن یا نسخه مرورگر هم‌خوانی ندارد، ارتباط برقرار نمی‌شود. این ناسازگاری به‌خصوص پس از بهروزرسانی مرورگر یا تغییر نسخه جاوا، ظاهر میشود و کاربر معمولاً مشکلی را می‌جست که جای دیگری است.
حساس‌ترین لحظه، تمدید گواهی امضاست. وقتی گواهی روی توکن تمدید میشود، حتماً باید درایور توکن epass3003 به آخرین نسخه بهروزرسانی شود؛ تجربه نشان داده در بسیاری از موارد، گواهی تازه‌روی میان‌افزار قدیمی یا بالعکس به‌درستی کار نمی‌کند و کاربر گمان می‌کند توکن خراب شده است. توصیه عملی ما این است که پیش از هر تمدید گواهی، نسخه فعلی درایور را حذف و آخرین نسخه را نصب کنید و سپس عملکرد توکن را در برنامه مدیریت توکن تست نمایید.
برای تهیه این فایلها لازم نیست در وب سرگردان شوید: در بخش پشتیبانی سایت ره‌آورد سامانه‌های امن، قسمت دانلود پیش‌نیازهای سامانه، آخرین نسخه درایور توکن برای ویندوز، مک و لینوکس، نسخه ادمین برای رفع قفل توکن، نرم‌افزار جاوا و دستینه و حتی SDK برنامه‌نویسی برای ویندوز، لینوکس و مک در دسترس است. توصیه می‌کنیم نشانی این صفحه را در سازمان خود به همه کاربرانی که با توکن کار میکنند اطلاع دهید؛ چون مراجعه به منابع ناشناس برای دانلود درایور، علاوه بر نسخه نامناسب، خطر بدافزار را هم به همراه دارد. یک توصیه تکمیلی: پیش از هر تمدید گواهی، نسخه پشتیبان از تنظیمات سامانه‌های کاری خود بگیرید و بروزرسانی را در یک روز غیرکاری تست کنید تا در صورت بروز مشکل، زمان اداری از دست نرود.
امنیت چرخه مجوز؛ از صدور تا ابطال
انتخاب دانگل فقط نیمی از مسیر است؛ نیم دیگر، طراحی امن چرخه حیات مجوز است. این چرخه از صدور آغاز میشود: هنگام تحویل محصول به مشتری، کلید یا رمزهای داخلی دانگل باید به‌صورت کنترل‌شده و یکتا تخصیص یابد و اطلاعات مجوز شامل شناسه محصول، مشتری، استقرار، ماژول‌های مجاز و تاریخ اعتبار، به‌صورت امن ثبت گردد. در گزینه epass3003 این ثبت با گره زدن کلید عمومی دانگل به اطلاعات تجاری انجام میشود و در خانواده ROCKEY، با پیکربندی ماژول‌ها و تایمرها و رمزهای اختصاصی هر دستگاه.
در ادامه چرخه، اعتبارسنجی دوره‌ای نقش نگهبان را بازی می‌کند. کنترل هنگام راه‌اندازی سرویس کافی نیست؛ یک مهاجم می‌تواند سرویس را با توکن متصل شروع کند و سپس دانگل را جدا سازد. راهکار درست، بررسی مجدد اعتبار در فواصل تعریف‌شده یا پیش از عملیات حساس است، همراه با صدور مجوز کوتاهمدت به‌نام License Lease که پایان اعتبار آن، اجرای عملیات حفاظتشده را محدود می‌کند. مدت اعتبار این مجوز، معامله‌ای میان امنیت و تداوم سرویس است: بازه کوتاه، امنیت بالاتر اما حساسیت بیشتر به قطعی‌های موقت می‌دهد و بازه بلند برعکس عمل می‌کند؛ مقدار بهینه باید بر اساس حساسیت محصول و توافق سطح سرویس با مشتری تعیین شود.
روی لایه ارتباطی هم نباید تعلل ورزید. ارتباط سرویس‌ها با Agent اعتبارسنج باید با احراز هویت سرویس و کانال امن محافظت شود؛ استفاده از mTLS، محدود کردن درخواست امضا به قالب مشخص و جلوگیری از پذیرش پاسخ تکراری، از تکنیک‌های استاندارد این حوزه‌اند. مدیریت PIN و کلیدها نیز اهمیت ویژه دارد: PIN توکن هرگز نباید در Image کانتینر یا مخزن کد ذخیره شود و کلید خصوصی باید با ویژگی‌های غیرقابل استخراج تولید گردد.
و سرانجام، سناریوی ابطال. وقتی قرارداد به پایان می‌رسد یا دانگلی گم میشود، باید بتوان مجوز آن را به‌سرعت غیرفعال کرد: در خانواده ROCKEY این کار با عدم تمدید تایمر و ماژول‌ها و در epass3003 با حذف کلید عمومی از فهرست مورد اعتماد سامانه انجام میشود. طراحی این مسیر از روز اول، شما را از نوشتن کدهای اضطراری در لحظه بحران نجات می‌دهد.
اشتباه‌های رایج در پیاده‌سازی کنترل لایسنس سخت‌افزاری
بخش بزرگی از مشکلاتی که پروژه‌ها با دانگل تجربه میکنند، از خود سخت‌افزار نمی‌آید؛ از تصمیم‌های اشتباه در طراحی می‌آید. رایج‌ترین اشتباه، اتکای صرف به شناسه‌های ظاهری است: تیمی که دانگل را خریده اما همچنان اعتبارسنجی را بر شماره سریال USB یا Hardware ID قابل خواندن بنا کرده، در واقع چیزی جز تغییر شکل همان روش قدیمی MAC و UUID ساخته است. اصل درست این است که اعتبارسنجی بر پایه عملیاتی باشد که فقط خود دانگل می‌تواند انجام دهد؛ امضای یک چالش تازه در مدل PKI یا پاسخ به Seed در مدل اختصاصی.
اشتباه دوم، استفاده از رمزها و Seedهای مشترک میان همه مشتریان است. همان‌طور که اشاره شد، دانگل‌هایی با رمزهای داخلی یکسان به چالش یکسان پاسخ یکسان می‌دهند و این یعنی یک پاسخ ضبط‌شده می‌تواند در چند استقرار بازپخش شود. تخصیص یکتا و کنترل‌شده رمزها، هزینه اندکی دارد اما کل امنیت طرح را بالا می‌برد.
اشتباه سوم، فراموش کردن کنترل دوره‌ای مجوز است. بسیاری از تیم‌ها فقط هنگام StartUp توکن را چک میکنند و پس از آن، سرویس بدون هیچ‌گونه راستی‌آزمایی به کار ادامه می‌دهد؛ در این حالت جدا کردن دانگل پس از راه‌اندازی، عملاً هیچ مانعی ندارد. مجوز کوتاهمدت و بازبینی دوره‌ای، پادزهر این حفره است.
اشتباه چهارم، ذخیره PIN در تصویر کانتینر یا مخزن کد است؛ این کار کل مفهوم اعتماد سخت‌افزاری را بی‌اثر می‌کند، چون هر کس به Image دسترسی داشته باشد، به اعتبار توکن هم دسترسی خواهد داشت. راه درست، تأمین امن PIN در زمان اجرا و محدود کردن دسترسی به Agent است. اشتباه پنجم، خلط کردن دو مفهوم مستقل: امکانات SDK و منطق لایسنس. تیم‌هایی که تصور میکنند دانگل به‌خودی‌خود سرویس‌های Docker را متوقف می‌کند یا نشست‌های سرور لایسنس را معادل کاربران نهایی می‌شمارند، در طراحی دچار برآورد غلط می‌شوند و در میانه پروژه به بازطراحی برمی‌گردند. شفاف‌سازی این مرز از روز اول، هم هزینه را کنترل می‌کند و هم انتظارات ذی‌نفعان را واقعی نگه می‌دارد.
پرسش‌های متداول درباره کنترل لایسنس نرم‌افزار با دانگل سخت‌افزاری
پیش از پایان، به پرتکرارترین پرسش‌هایی پاسخ می‌دهیم که کارشناسان ما در گفت‌وگو با تیم‌های نرم‌افزاری و مدیران سازمانی می‌شنوند؛ همین پرسش‌ها در قالب کد اسکیمای پرسش‌های متداول در انتهای مقاله نیز آماده درج شده است.
آیا دانگل سخت‌افزاری در شبکه بدون اینترنت هم کار می‌کند؟
بله؛ این دقیقاً یکی از مهم‌ترین مزیت‌های این راهکارهاست. تمام عملیات اعتبارسنجی میان سرویس‌های داخلی و دانگل متصل به زیرساخت انجام میشود و هیچ وابستگی به سرویس بیرونی وجود ندارد. در خانواده ROCKEY حتی تمدید مجوز نیز به‌صورت آفلاین با بسته بهروزرسانی Parent/Child انجام میشود و مشتری نیازی به اتصال اینترنتی ندارد.
آیا توکن امضای دیجیتال epass3003 برای کنترل لایسنس هم به کار می‌آید؟
بله، اما با یک تفکیک مهم: کاربرد اصلی این توکن، امضای الکترونیک در سامانه‌هایی مثل ثبت من، ستاد ایران و جامع تجارت است؛ بااین‌حال قابلیت امضای مبتنی بر کلید خصوصی آن با رابط PKCS#11، برای اثبات اصالت استقرار نرم‌افزار نیز مناسب است. تنها باید در نظر داشته باشید که سرویس لایسنس و منطق کنترل مجوز را باید در نرم‌افزار خود پیاده‌سازی کنید.
آیا برای هر کانتینر Docker به یک دانگل جداگانه نیاز داریم؟
خیر؛ این تصور رایج اما نادرست است. دانگل به یک میزبان مشخص یا سرور مجوز مرکزی متصل میشود و نتیجه اعتبارسنجی از راه یک API داخلی در اختیار Replicaهای مجاز قرار میگیرد. در NetROCKEY4ND حتی این لایه ارتباطی نیز به‌صورت License Server شبکه‌ای آماده ارائه شده است.
دانگل از سرور جدا شود چه اتفاقی برای سرویس میافتد؟
هیچ‌چیز به‌صورت خودکار متوقف نمی‌شود؛ این رفتار را نرم‌افزار شما تعیین می‌کند. با طراحی درست، برنامه پس از عدم دریافت پاسخ معتبر، صدور و تمدید مجوز را متوقف می‌کند و پس از انقضای مجوزهای کوتاهمدت قبلی، اجرای عملیات حفاظتشده را محدود می‌سازد.
برای رفع خطای شناسایی نشدن توکن امضای دیجیتال چه کنیم؟
ابتدا درایور توکن epass3003 را به آخرین نسخه بهروزرسانی کنید و سپس نرم‌افزارهای پیش‌نیاز مانند جاوا و دستینه را نیز تازه‌سازی نمایید؛ به‌خصوص پس از تمدید گواهی، بهروزرسانی درایور ضروری است. آخرین نسخه همه این فایلها در بخش پشتیبانی سایت رهسا در قسمت دانلود پیش‌نیازهای سامانه موجود است.
اگر توکن قفل شود راه‌حل چیست؟
با نسخه Admin برنامه مدیریت توکن و استفاده از گزینه Unblock می‌توان قفل را باز کرد؛ البته دقت کنید که ورود اشتباه رمز مدیر بیش از پنج بار، توکن را به‌طور کامل مسدود می‌کند و در آن صورت باید به مرکز صدور گواهی مراجعه کنید تا دستگاه پاکسازی و گواهی جدید صادر شود.
جمع‌بندی: کدام دانگل سخت‌افزاری به محصول شما می‌خورد؟
آنچه در این مقاله دیدیم را می‌توان در یک جمله فشرده کرد: دانگل سخت‌افزاری زمانی ارزش واقعی خود را نشان می‌دهد که به‌عنوان ریشه اعتماد در یک معماری کامل لایسنس‌دهی به کار رود، نه به‌عنوان یک قفل جادویی که همه چیز را خودکار حل کند. هر سه محصول بررسی‌شده امکان وابسته کردن مجوز اجرای نرم‌افزار به یک عامل سخت‌افزاری مستقل از ماشین مجازی را فراهم میکنند، اما انتخاب درست باید بر اساس نوع کنترلی که قرار است در نرم‌افزار اعمال شود انجام گیرد، نه صرف وجود پشتیبانی لینوکس یا درگاه USB.
اگر اولویت شما اثبات رمزنگاری‌شده حضور یک کلید سخت‌افزاری با رابط استاندارد است، توکن epass3003 Auto متناسب‌ترین انتخاب است؛ سازوکار امضا با PKCS#11، پشتیبانی از RSA تا ۲۰۴۸ بیت و SHA-256 و کارکرد کامل در شبکه‌های آفلاین، آن را برای سناریوهای اثبات اصالت استقرار مناسب می‌کند. اگر مدل تجاری محصول به تاریخ انقضا، ماژول‌های فعال، شمارنده مصرف یا تمدید آفلاین وابسته است، ROCKEY4 SMART با ۶۴ ماژول و تایمر و شمارنده، ابزارهای آماده‌تری در اختیار شما می‌گذارد. و اگر استفاده شبکه‌ای چند سرویس از یک دانگل مرکزی یا کنترل نشست‌های هم‌زمان نیاز واقعی شماست، NetROCKEY4ND با License Server آماده، کوتاه‌ترین مسیر رسیدن به هدف است.
در همه حالت‌ها، تفکیک میان امکانات دانگل و SDK با منطق کنترل مجوز در نرم‌افزار را از یاد نبرید: دانگل عملیات و اطلاعات لازم را فراهم می‌کند و تبدیل نتیجه به مجوز اجرای Backend، اعتبارسنجی دوره‌ای، سیاست واکنش به قطع توکن و ارتباط با Replicaها در نرم‌افزار شما پیاده‌سازی میشود. تجربه ما نشان می‌دهد پروژه‌هایی که این مرز را از روز اول می‌شناسند، هم سریع‌تر به بهره‌برداری می‌رسند و هم در نگهداری درازمدت مشکلات کمتری دارند. پیشنهاد نهایی ما این است که پیش از خرید، سناریوی دقیق استفاده و مدل تجاری لایسنس خود را مکتوب کنید و بر مبنای آن، محصولی را برگزینید که کمترین فاصله را با نیاز واقعی دارد؛ باقی مسیر، طراحی هوشمندانه نرم‌افزار است.