امنیت و سخت‌سازی

امنیت همزاد دیجیتال از چند لایه ساخته می‌شود: دروازهٔ وب با TLS، حساب کاربری با قفل خودکار، کلید پروژه با سطح دسترسی، تأیید دوبارهٔ رمز پیش از فرمان به تجهیز و تأیید صریح کاربر برای هر تغییر دستیار هوشمند. این درس هر لایه را معرفی می‌کند و یک فهرست سخت‌سازی عملی پس از نصب می‌دهد.

کنترل‌های موجود در محصول

گام‌به‌گام: فهرست سخت‌سازی پس از نصب

1. TLS در دروازه. HTTPS را با گواهی معتبر در دروازهٔ وب فعال کنید و همهٔ درخواست‌های http را به https هدایت کنید. سرور و پایگاه داده را مستقیم در معرض شبکهٔ بیرونی قرار ندهید.
2. کوکی نشست و مبدأ مجاز. روی سایت HTTPS مقدار server.servlet.session.cookie.secure را true نگه دارید و argbms.websocket.allowed-origins را دقیقاً برابر نشانی عمومی سایت بگذارید (مقدار «*» پذیرفته نمی‌شود).
3. شبکه. پایگاه داده و درگاه مستقیم سرور را فقط روی شبکهٔ داخلی در دسترس بگذارید؛ فقط دروازه بیرون باشد. درگاه‌های TCP قدیمی که به‌صورت پیش‌فرض خاموش‌اند را روشن نکنید مگر ناچار باشید.
4. سرآیندها و محدودیت‌ها در دروازه. سرآیندهای امنیتی مانند HSTS و Content-Security-Policy، و محدودیت نرخ درخواست را در دروازه اعمال کنید. صفحهٔ مستندات API را اگر لازم نیست از دسترس بیرونی ببندید و پیام‌های خطای تولید را بدون جزئیات فنی تنظیم کنید.
5. حساب‌ها. رمزهای اولیه را پس از نصب عوض کنید و رمز بلند و یکتا بخواهید. حساب‌های بی‌استفاده را قفل کردن کنید و افراد رفته را غیرفعال کنید. «دسترسی سیستمی» (ورود به کنسول) را فقط به مدیران مورد اعتماد بدهید.
6. نقش‌ها. برای هر گروه کاری نقش جدا بسازید و به هر کاربر فقط نقش لازم را بدهید. نام نقش‌های غیرمدیریتی را بدون «مدیر» یا admin انتخاب کنید.
7. کلیدها. برای هر دستگاه یا سامانهٔ بیرونی کلید جدا با کمترین سطح و تاریخ انقضا بسازید؛ فقط‌خواندنی واقعی User Level 3 است. کلید Master را بیرون ندهید و کلیدهای بی‌استفاده را Deactivate کنید. کلید مدیریتی سرور را در صورت نیاز از متغیر محیطی بخوانید، نه متن فایل.
8. فایل‌ها و پشتیبان. دسترسی نوشتن پوشهٔ نصب را فقط به حساب سرویس بدهید. پشتیبان‌های پایگاه داده اطلاعات حساب‌ها را دارند؛ آن‌ها را رمزگذاری‌شده و با دسترسی محدود نگه دارید (درس C6).
9. بازبینی دوره‌ای. ماهانه فهرست حساب‌ها، حساب‌های قفل‌شده، کلیدها و ستون «Last Used» آن‌ها را مرور کنید و آنچه استفاده نمی‌شود را ببندید.

در عمل: فرمان به تجهیز

وقتی کاربری از داشبورد فرمانی می‌فرستد، پنجرهٔ «تایید دستور» با پیام «برای ارسال دستور، رمز عبور خود را وارد کنید» باز می‌شود. پس از وارد کردن رمز عبور و زدن تایید و ارسال، تا ۶۰ ثانیه فرمان‌های بعدی بدون پرسش دوباره ارسال می‌شوند. اگر کلید پروژهٔ کاربر اجازهٔ کنترل نداشته باشد، سرور فرمان را رد می‌کند؛ یعنی اجبار نهایی همان سطح کلید است.

ردپای فرمان‌ها

هر فرمانی که به تجهیز می‌رود شناسهٔ یکتا می‌گیرد و مراحلش ثبت می‌شود: ارسال به لبه، پذیرش تجهیز، دریافت رسید و در صورت خطا وضعیت ناموفق. کلید یکتایی فرمان باعث می‌شود یک فرمان دو بار اجرا نشود؛ مثلاً اگر کاربر از سر بی‌حوصلگی دو بار روی کلید بزند یا شبکه پاسخ را دیر برساند. هنگام بررسی یک حادثه، این زنجیره به شما می‌گوید فرمان اصلاً ارسال شده، به تجهیز رسیده یا تجهیز آن را رد کرده است. در ترکیب با تأیید رمز ۶۰ ثانیه‌ای، هر تغییر دستی روی تجهیز هم نیازمند حضور آگاهانهٔ کاربر است و هم ردپای فنی دارد.

نکته‌ها و اشتباه‌های رایج

• رمز اشتباه در پنجرهٔ «تایید دستور» هم جزو تلاش‌های ناموفق حساب می‌شود؛ پنج بار اشتباه، حساب را قفل می‌کند و فقط مدیر با باز کردن قفل آن را باز می‌کند.
• پیام «توکن نامعتبر یا منقضی» پس از راه‌اندازی مجدد سرور طبیعی است؛ کاربران دوباره وارد شوند.
• برچسب «User Level 2 (Read Only)» را به معنای فقط‌خواندنی نگیرید؛ User Level 3 بدهید.
• احراز هویت دو مرحله‌ای و دسترسی API در «تنظیمات امنیتی» برچسب «به زودی» دارند و در این نسخه فعال نیستند.
• صفحهٔ «دسترسی‌ها» فعلاً ذخیره نمی‌کند؛ کنترل دسترسی را با حساب، نقش و سطح کلید انجام دهید.

خلاصه

• TLS و سرآیندها و محدودیت نرخ در دروازه؛ پایگاه داده و سرور فقط در شبکهٔ داخلی.
• اجبار سمت سرور با سطح کلید؛ کمترین سطح لازم برای هر مصرف‌کننده.
• قفل خودکار پس از ۵ تلاش ناموفق؛ تأیید رمز پیش از فرمان با اعتبار ۶۰ ثانیه.
• هر تغییر دستیار فقط با تأیید همان کاربر، و پیشنهاد پس از ۳۰ دقیقه منقضی می‌شود.