هیچ محصولی در سبد خرید نیست
دسته بندی ها
فروش نرمافزارهای اورجینال و لایسنسدار اداری و امنیتی، همراه با پشتیبانی فنی، اصالت کالا و خدمات پس از فروش
زمان مطالعه : 18 دقیقه
راهنمای استقرار Kaspersky XDR 2.1 / EDR 8.1
انتشار : 23 تیر , 1405
آخرین بروزرسانی : 23 تیر , 1405
راهنمای استقرار Kaspersky XDR 2.1 / EDR 8.1
راهنمای کامل آموزشی، امنیتی و عملیاتی برای سناریوی آزمایشگاهی و سازمانهای کوچک
معرفی
در این آموزش، فرآیند استقرار Kaspersky XDR 2.1 / EDR 8.1 روی Ubuntu بهصورت عملی نمایش داده شد.
این سناریو بر اساس شواهد موجود، در یک محیط demo/lab اجرا شده است؛ این راهنما را باید بهعنوان
یک نمونه آموزشی/آزمایشگاهی مناسب برای سازمانهای کوچک یا PoC داخلی در نظر گرفت، نه یک نسخه نهایی Enterprise.
برای محیطهای Enterprise، معمولاً معماری Multi-Node، سیاستهای سختگیرانهتر، طراحی HA، جداسازی سرویسها
و تنظیمات امنیتی پیشرفتهتر لازم است.
نسخههای استفادهشده در این آموزش
- Kaspersky Next XDR Expert 2.1
- Kaspersky EDR Expert 8.1
- Ubuntu Server (طبق نسخه پشتیبانیشده در مستندات رسمی محصول)
- PostgreSQL 16
- Docker
ممکن است جزئیات نصب، اسکریپتها یا پیشنیازها در نسخههای جدیدتر تغییر کنند؛ بنابراین پیش از استقرار عملی، همواره آخرین مستندات رسمی کسپرسکی بررسی شود.
| Component | Role | Description |
|---|---|---|
| Administrator | Management User | Security administrator access and system management |
| Open Single Management Platform (OSMP) | Central Management Layer | Provides centralized administration and integration |
| PostgreSQL | Database | Stores platform configuration and operational data |
| KUMA | SIEM / Event Management | Collects, processes and analyzes security events |
| Collector | Data Collection | Receives logs and events from endpoints |
| Storage | Event Storage | Stores collected security data for analysis |
| Endpoints | Protected Assets | User devices and servers monitored by XDR/EDR |
1) پیش از نصب: Hardening Guide و الزامات امنیتی
قبل از شروع نصب، در پنجره Hardening Guide مجموعهای از الزامات امنیتی نمایش داده شده است. این بخش از مهمترین
قسمتهای کل فرایند است، چون تأکید میکند استقرار این محصول نباید بدون توجه به سختسازی امنیتی انجام شود.
موارد کلیدی عبارتاند از:
- استفاده از TLS 1.2 یا بالاتر
- محدودسازی ارتباطات ناامن و رمزنگاری ضعیف
- محدودسازی دسترسی به دیتابیس راهکار
- الزام استفاده از Two-Factor Authentication
- توصیه به استفاده از RFC 6238 / TOTP
- عدم نصب برنامه احراز هویت روی همان دستگاه
- استفاده از MFA / Token / Smart Card در صورت امکان
- محدودسازی نقش Main Administrator
- بازبینی دورهای کاربران
- استفاده از حساب جداگانه برای نصب از راه دور
- تأیید رسمی مطالعه راهنمای Hardening
در معماری Production، OSMP، Database و KUMA معمولاً بر اساس ظرفیت، تعداد Endpointها و حجم Eventها میتوانند روی نودهای مجزا مستقر شوند. معماری All-in-One بیشتر برای Lab، Demo و PoC مناسب است.
نتیجه عملی برای تیم نصب:
- دسترسی مدیریتی را محدود کند.
- از 2FA استفاده کند.
- دیتابیس را بدون کنترل و دسترسی باز قرار ندهد.
- برای نصب، حساب مجزا داشته باشد.
- راهنمای Hardening را بهعنوان سند مرجع اجرا کند.
2) فعالسازی 2FA و ورود به Administration Console
در مرحله بعد، صفحه احراز هویت دو مرحلهای نمایش داده میشود:
- Two-factor authentication is required for enhanced security
- حساب کاربر با 2FA محافظت میشود
- برای ورود به Administration Console باید Authenticator تنظیم شود
- یک Secret Key نمایش داده شده است
- سپس کد امنیتی باید از اپلیکیشن Authenticator وارد شود
نمونه اطلاعات نمایشدادهشده:
Secret key: …….
آدرس/هاست: ……
دامنه: …….
مسیر ورود: ……
نکته امنیتی:
- در این سناریو، 2FA بخشی از فرآیند الزامی راهاندازی است.
- تیم نصب باید قبل از تحویل نهایی، فرآیند TOTP را کامل کند.
- Secret Key و کدهای موقت باید بهصورت امن مدیریت شوند.
- در سناریوی عملی، این Secret نباید در مستندات عمومی منتشر شود.
3) ورود به Open Single Management Platform
در تصویر بعدی، صفحه ورود Open Single Management Platform دیده میشود. فیلدهای ورود شامل موارد زیر است:
- User name
- Password
- دکمه Sign in
و نام کاربر admin نیز در تصویر مشخص است.
برداشت عملی:
- کنسول مدیریتی از طریق Single Management Platform در دسترس قرار میگیرد.
- مسیر دسترسی کنسول باید برای تیم نصب و بهرهبرداری مستندسازی شود.
- نحوه احراز هویت و دسترسی مدیریتی باید در مستند نهایی ثبت شود.
4) آمادهسازی سیستمعامل و اجرای اسکریپت نصب
مهمترین بخش فنی فرایند، اجرای اسکریپت آمادهسازی سیستمعامل است.
./os_preparation_xdr_psql_bind_3.sh
در همان مسیر، فایلهای مهم زیر دیده میشوند:
kdt*kuma.ymllicense.keyos_preparation_xdr_psql_bind_3.shsmp.yamlxdr-2.1.584-en.tar
نقش این فایلها:
xdr-2.1.584-en.tar: بسته اصلی نصب/انتقالkdt: ابزار استقرارsmp.yaml: فایل پیکربندی YAML مربوط به SMPkuma.yml: فایل پیکربندی مرتبطlicense.key: لایسنسos_preparation_xdr_psql_bind_3.sh: اسکریپت آمادهسازی سیستمعامل
5) انتخاب نقش نصب: kdt_smp_psql
در اجرای اسکریپت، فهرستی از نقشها نمایش داده میشود:
kdt_onlykdt_smp_psqlsmp_psqlkumabind_dnspsql
نقش انتخابشده:
2. kdt_smp_psql
معنی عملی این نقش:
- KDT
- SMP
- PostgreSQL
این نقش نشان میدهد که در این سناریو، نصب بهصورت ترکیبی و یکپارچه انجام میشود و صرفاً نصب یک سرویس منفرد نیست.
6) تنظیم hostname و /etc/hosts
در حین آمادهسازی، نام میزبان و رکوردهای /etc/hosts باید کاملاً یکسان و
سازگار تنظیم شوند تا از بروز خطا در Name Resolution و ارتباط بین سرویسها جلوگیری شود.
hostname: xdr-smp.demo.lab/etc/hostsبرایxdr-smp.demo.labبهروزرسانی شده است
توجه: هرگونه ناهماهنگی بین hostname و رکوردهای /etc/hosts
(برای مثال .la بهجای .lab) میتواند باعث بروز مشکل در
Resolve نام، ارتباط بین مؤلفهها، و حتی خطاهای SSL/TLS یا احراز هویت شود.
اهمیت این مرحله:
- جلوگیری از مشکل Resolve نامها
- هماهنگی بین اجزای نصب
- آمادهسازی سرویسها برای ارتباط داخلی
در این مرحله باید hostname و فایل
بتوانند با نامهای داخلی یکدیگر را پیدا کنند.
/etc/hosts مطابق الگوی نامگذاری محیط تنظیم شوند تا سرویسهابتوانند با نامهای داخلی یکدیگر را پیدا کنند.
7) بررسی پیشنیازهای سختافزاری و CPU
در همان تصویر نصب، چند بررسی سختافزاری و سیستمی انجام میشود:
- kernel version مناسب است
- IPv6 با موفقیت غیرفعال شده است
- AVX support detected
- BMI2 support detected
- SSE4 support not detected
- منابع سیستم کافی هستند:
- 24 vCPU
- 63GB memory
- 441GB فضای آزاد روی root
نکته مهم درباره SSE4:
پیش از نصب، بررسی CPU instruction set ضروری است. در این نمونه AVX و BMI2 شناسایی شدند، اما SSE4 شناسایی نشد.
این موضوع باید در سیستم مقصد با پیشنیازهای رسمی محصول تطبیق داده شود.
پیش از نصب، بررسی CPU instruction set ضروری است. در این نمونه AVX و BMI2 شناسایی شدند، اما SSE4 شناسایی نشد.
این موضوع باید در سیستم مقصد با پیشنیازهای رسمی محصول تطبیق داده شود.
نتیجه برای واحد نصب:
- معماری CPU
- پشتیبانی از AVX
- پشتیبانی از BMI2
- وضعیت SSE4
- مقدار RAM
- فضای دیسک
- نسخه کرنل
- وضعیت IPv6
- نام میزبان و DNS داخلی
8) خطای known_hosts و نکات عیبیابی
اگر در حین اجرا با پیام زیر مواجه شوید:
grep: /root/.ssh/known_hosts: No such file or directory
تفسیر:
- فایل
known_hostsدر مسیر root هنوز ایجاد نشده است - یا برای اولینبار SSH Trust Chain در حال ساختهشدن است
- یا اسکریپت انتظار داشته قبلاً ارتباط SSH برقرار شده باشد
توصیه:
- مسیر SSH و Trust of Hosts بررسی شود.
- در صورت نیاز، اتصال اولیه SSH یا hostname trust بهصورت دستی Verify شود.
9) راهاندازی SMP + PostgreSQL و تولید کلید SSH
پیامهای مهمی که نشان میدهد اسکریپت در حال ساختن زیرساخت لازم است:
Setting up SMP+PostgreSQL server...SSH key pair generated successfully
اهمیت این قسمت:
- سرویس دیتابیس
- سرویس مدیریتی
- تبادل کلید SSH
همگی در یک جریان نصب خودکار آماده میشوند.
10) پایان موفق نصب و تأیید PostgreSQL 16
در تصویر پایانی، خلاصه نصب بهصورت واضح نمایش داده میشود:
- نقش انتخابشده:
kdt_smp_psql PostgreSQL 16 installation and verificationNo existing PostgreSQL installation detected.Installing PostgreSQL 16...PostgreSQL 16 installed.PostgreSQL connection test passed.PostgreSQL configured successfully.PostgreSQL 16 is ready for use.Docker installed and configured: YesCopying SSH key to KUMA and SMP servers...SSH keys copied successfully.SSH key pair generated: YesSSH key pair copied to SMP and KUMA servers: YesAll packages were successfully installed.Setup completed successfully. Summary:XDR installation finished successfully- مسیر لاگ:
/var/log/setup_script.log
نتیجه:
- PostgreSQL 16 نصب شده است
- Docker نصب و تنظیم شده است
- SSH Keyها توزیع شدهاند
- نصب با موفقیت کامل شده است
11) Post Installation Checklist (اقدامات پس از نصب)
پس از پایان موفقیتآمیز نصب، پیش از تحویل سامانه به تیم بهرهبرداری،
موارد زیر باید بررسی و تکمیل شوند:
تغییر Credential اولیه و حذف حسابهای پیشفرض غیرضروری
بررسی وضعیت سرویسها:
systemctl status
journalctl
بررسی Certificate و اعتبار TLS
فعالسازی و تست Backup پایگاه داده PostgreSQL
بررسی Role-Based Access Control (RBAC)
و محدودسازی دسترسی Administratorها
بررسی وضعیت 2FA/MFA کاربران مدیریتی
انجام تست عملیاتی Alert و Event Detection
اتصال به SIEM در صورت وجود زیرساخت SOC
ثبت نسخهها، تنظیمات، IPها، Certificateها و تغییرات انجامشده
تهیه مستند Runbook برای تیم عملیات
12) این سناریو برای چه محیطی مناسب است؟
بر اساس شواهد موجود، این پیادهسازی را باید آزمایشگاهی / آموزشی / دمو دانست، نه استقرار نهایی Enterprise.
چرا؟
- دامنههایی مثل
demo.labدیده میشود - آموزش با عنوان Full Implementation Training ارائه شده است
- نصب بهصورت یک مسیر واحد و مرحلهبهمرحله نشان داده شده است
این سناریو برای موارد زیر مناسب است:
- آموزش تیم فنی
- آزمایش داخلی
- PoC
- راهاندازی اولیه در سازمانهای کوچک
- بررسی سازگاری سختافزار و فرآیند نصب
اما برای Enterprise باید چه چیزهایی تغییر کند؟
- معماری Multi-Node
- جداسازی سرویسها
- سیاستهای سختگیرانهتر دسترسی
- طراحی High Availability
- مانیتورینگ و بکاپ حرفهای
- Hardening عمیقتر
- مدیریت Certificate و Network Policy
- مستندسازی عملیاتی دقیقتر
13) جمعبندی نهایی
این آموزش، یک سناریوی کامل استقرار Kaspersky XDR 2.1 / EDR 8.1 روی Ubuntu را نشان میدهد که شامل موارد زیر است:
- بررسی Hardening Guide
- فعالسازی 2FA
- ورود به کنسول مدیریتی
- اجرای اسکریپت آمادهسازی
- انتخاب نقش
kdt_smp_psql - تنظیم hostname و hosts
- بررسی CPU، RAM و دیسک
- نصب PostgreSQL 16
- نصب Docker
- انتقال SSH Keyها
- ثبت لاگ نهایی
از نظر کاربرد، این سناریو آموزشی/آزمایشگاهی است و میتواند برای سازمانهای کوچک یا PoC داخلی بسیار مفید باشد.
اما برای Enterprise، باید معماری و تنظیمات متناسب با الزامات مقیاس، امنیت و دسترسپذیری بازطراحی شود.
سوالات تخصصی استقرار Kaspersky XDR 2.1 / EDR 8.1 روی Ubuntu
1. آیا این سناریو برای محیط Enterprise مناسب است؟
خیر. این سناریو برای محیطهای Lab و PoC است. مطابق با اسناد رسمی سرویسهای حرفهای کسپرسکی (KPS Essential)، حتی برای یک استقرار پایه و کوچک در محیط عملیاتی، حداقل ۲ سرور مجزا (یکی برای نقشهای OSMP و دیگری برای سرویسهای KUMA شامل Collector و Storage) الزامی است. استقرار All-in-One روی یک سرور، برای محیط Production توصیه نمیشود.
2. چرا قبل از نصب باید Hardening Guide مطالعه شود؟
راهنمای Hardening الزامات امنیتی پایه و کنترلهای ضروری برای استقرار امن را مشخص میکند، از جمله:
- استفاده از TLS 1.2 یا بالاتر
- استفاده از MFA/2FA
- محدودسازی دسترسی حسابهای مدیریتی
- محافظت از پایگاه داده
- کنترل دسترسی به سرویسها
- بازبینی دورهای حسابهای کاربری
- استفاده از حسابهای مجزا برای نصب و مدیریت
نادیده گرفتن این الزامات میتواند سطح ریسک امنیتی استقرار را افزایش دهد.
3. آیا فعالسازی 2FA الزامی است؟
در این سناریوی نصب، احراز هویت دومرحلهای برای ورود مدیر به کنسول مدیریتی فعال شده و بخشی از فرآیند راهاندازی است.
بهصورت عملی توصیه میشود:
- Secret Key فقط یکبار ثبت و در محل امن نگهداری شود
- برنامه Authenticator روی دستگاهی جدا از سرور نصب شود
- در صورت پشتیبانی سیاستهای سازمان، برای حسابهای حساس از روشهای MFA قویتر نیز استفاده شود
الزام نهایی این قابلیت باید با نسخه محصول و سیاست امنیتی سازمان تطبیق داده شود.
4. آیا میتوان از حساب Root برای تمام عملیات استفاده کرد؟
از نظر فنی ممکن است، اما از دیدگاه امنیتی توصیه نمیشود. بهتر است:
- نصب اولیه با حسابی دارای مجوزهای لازم و کنترلشده انجام شود
- مدیریت روزمره با حسابهای مدیریتی محدود انجام گیرد
- دسترسی Root فقط برای عملیات ضروری، ثبتشده و کنترلشده استفاده شود
5. نقش kdt_smp_psql دقیقاً چیست؟
این نقش مخفف ابزارهای اصلی پلتفرم است. طبق معماری XDR Expert، این نقش شامل Kaspersky Deployment Tool (KDT) برای مدیریت نصب، Open Single Management Platform (OSMP) به عنوان هسته مرکزی، و دیتابیس PostgreSQL است. این ترکیب، زیرساخت لازم برای مدیریت یکپارچه حوادث و تعامل بین کنسولهای KUMA و OSMP را فراهم میکند.
6. آیا امکان جداسازی PostgreSQL از SMP وجود دارد؟
بله. در معماریهای بزرگتر معمولاً پایگاه داده روی سروری مجزا قرار میگیرد تا:
- بار پردازشی بهتر توزیع شود
- سطح امنیت افزایش یابد
- مدیریت پشتیبانگیری و بازیابی سادهتر شود
- نگهداری و توسعهپذیری بهتر انجام شود
این تصمیم باید بر اساس معماری نهایی و مستندات پشتیبانیشده اتخاذ شود.
7. چرا تنظیم صحیح Hostname و فایل /etc/hosts اهمیت دارد؟
بسیاری از مؤلفههای داخلی برای برقراری ارتباط به نام میزبان متکی هستند. هرگونه ناهماهنگی بین Hostname، DNS و
/etc/hosts میتواند باعث بروز مشکلاتی مانند موارد زیر شود:
- اختلال در ارتباط بین سرویسها
- خطاهای SSL/TLS
- شکست بخشی از فرآیند استقرار
- مشکلات احراز هویت و Resolve نام
8. آیا استفاده از DNS داخلی الزامی است؟
در محیطهای کوچک و آزمایشگاهی، استفاده از /etc/hosts ممکن است کافی باشد. با این حال، در سازمانها
و محیطهای عملیاتی، استفاده از DNS داخلی توصیه میشود تا مدیریت نامها، مقیاسپذیری، عیبیابی و نگهداری
سادهتر و استانداردتر انجام شود.
9. چرا اسکریپت CPU و منابع سیستم را بررسی میکند؟
برخی مؤلفههای محصول به قابلیتهای سختافزاری و حداقل منابع سیستم وابسته هستند. به همین دلیل، اسکریپت پیش از نصب معمولاً موارد زیر را بررسی میکند:
- AVX
- BMI2
- SSE4
- نسخه Kernel
- میزان RAM
- فضای آزاد دیسک
هدف این بررسی، اطمینان از سازگاری اولیه سیستم با الزامات استقرار است.
10. اگر SSE4 شناسایی نشود، نصب ناموفق خواهد بود؟
نه لزوماً. این وضعیت به نیازمندیهای همان نسخه محصول، نوع پردازنده و اجزایی که قرار است اجرا شوند بستگی دارد.
در صورت مشاهده چنین پیامی، باید نتیجه با پیشنیازهای رسمی و ماتریس سازگاری همان نسخه از Kaspersky XDR/EDR
مقایسه شود.
11. چرا IPv6 در این سناریو غیرفعال شده است؟
در برخی محیطها برای کاهش پیچیدگی شبکه یا جلوگیری از مشکلات سازگاری، IPv6 غیرفعال میشود. با این حال،
این اقدام نباید بهصورت پیشفرض و بدون بررسی انجام شود. اگر سازمان از IPv6 استفاده میکند، پیش از هر تغییر
باید الزامات محصول، طراحی شبکه و سیاستهای امنیتی سازمان بررسی شوند.
12. پیام known_hosts: No such file or directory به چه معناست؟
این پیام معمولاً نشان میدهد فایل known_hosts هنوز ایجاد نشده یا ارتباط SSH قبلاً برقرار نشده است.
در بسیاری از موارد این پیام بهتنهایی بحرانی نیست، اما باید موارد زیر بررسی شوند:
- دسترسی SSH برقرار باشد
- کلید میزبان معتبر باشد
- اعتماد اولیه (Trust) بهدرستی ایجاد شده باشد
13. چرا اسکریپت کلید SSH تولید میکند؟
کلید SSH برای برقراری ارتباط امن میان مؤلفهها، اجرای عملیات مدیریتی، انتقال فایل و اجرای دستورات از راه دور
استفاده میشود. در استقرارهای خودکار، این کار بخشی از آمادهسازی زیرساخت ارتباطی بین نودها یا سرویسها است.
14. آیا Docker بخشی از نصب است؟
در این سناریو بله؛ اسکریپت Docker را نصب و پیکربندی میکند تا سرویسهای موردنیاز اجرا شوند. با این حال،
نسخه Docker باید همواره با الزامات و ماتریس سازگاری همان نسخه محصول تطبیق داده شود.
15. آیا PostgreSQL 16 تنها نسخه قابل استفاده است؟
خیر. نسخه قابل پشتیبانی PostgreSQL به نسخه Kaspersky XDR/EDR و مستندات همان Release بستگی دارد. در این سناریو
PostgreSQL 16 مشاهده شده، اما برای هر استقرار عملی باید نسخه نهایی با ماتریس سازگاری رسمی کنترل شود.
16. چگونه از موفقیت نصب اطمینان حاصل کنیم؟
نشانههای رایج موفقیت نصب عبارتاند از:
- تکمیل موفق نصب PostgreSQL
- برقراری ارتباط موفق با پایگاه داده
- نصب و راهاندازی Docker
- تولید و توزیع موفق کلیدهای SSH
- تکمیل اسکریپت بدون خطاهای بحرانی
- ثبت موفق گزارش نصب
همچنین توصیه میشود موارد زیر نیز بررسی شوند:
- وضعیت سرویسها با
systemctl - رویدادهای سیستمی با
journalctl - قابلیت ورود به کنسول مدیریتی
- سلامت سرویسهای وابسته و اتصالهای داخلی
17. مسیر فایل لاگ نصب کجاست؟
در این سناریو، گزارش نصب در مسیر زیر ثبت شده است:
/var/log/setup_script.log
این فایل یکی از مهمترین مراجع برای عیبیابی خطاهای نصب و بررسی جزئیات مراحل اجرا است.
18. مهمترین اقدامات پس از پایان نصب چیست؟
- تغییر گذرواژههای پیشفرض یا اولیه
- بررسی وضعیت سرویسها
- اعمال آخرین بهروزرسانیهای مجاز
- بررسی وضعیت گواهیهای TLS
- بازبینی نقشها و مجوزهای مدیریتی
- فعالسازی و آزمون Backup پایگاه داده
- ثبت مستندات نهایی استقرار
- اجرای تست عملیاتی اولیه
19. آیا این استقرار برای محیط Production کافی است؟
خیر. پیش از استفاده در محیط عملیاتی، باید موارد زیر متناسب با نیاز سازمان طراحی، بازبینی یا تکمیل شوند:
- معماری High Availability
- طراحی Disaster Recovery
- برنامه Backup و Restore
- مانیتورینگ متمرکز
- یکپارچهسازی با SIEM
- مدیریت گواهیهای دیجیتال
- تقسیم وظایف مدیریتی (RBAC)
- سختسازی سیستمعامل و سرویسها
- سیاستهای Patch Management و بهروزرسانی و برای تبدیل این استقرار به یک محیط Production پایدار، علاوه بر موارد ذکر شده، باید محدودیتهای عملیاتی استاندارد را نیز در نظر گرفت. طبق مستندات Next XDR Expert، یک استقرار پایه معمولاً برای پوشش حداکثر ۷ منبع رویداد استاندارد و ۵۰ کلاینت طراحی میشود. برای سازمانهایی با حجم داده بالاتر، حتماً باید معماری به سمت Multi-Node و استفاده از کلاستر دیتابیس و Storageهای مجزا حرکت کند.
20. رایجترین دلایل شکست نصب چیست؟
- تنظیم نبودن صحیح Hostname یا DNS
- ناسازگاری نسخه سیستمعامل
- کمبود منابع سختافزاری
- ناسازگاری نسخه PostgreSQL یا Docker
- خطاهای ارتباط شبکه
- مجوزهای ناکافی کاربر
- محدودیتهای فایروال یا سیاستهای امنیتی سیستمعامل
- تنظیمات نادرست فایلهای پیکربندی
بسته به تنظیمات سیستم، محدودیتهای SELinux یا AppArmor نیز ممکن است در برخی سناریوها نیازمند بررسی باشند.
21. چه اقداماتی پس از تحویل سامانه به واحد بهرهبرداری توصیه میشود؟
- تدوین Runbook عملیاتی برای مدیریت روزمره سامانه
- تعریف فرآیند Change Management برای ارتقا و بهروزرسانی
- زمانبندی منظم برای بررسی سلامت سرویسها و ظرفیت منابع
- آزمون دورهای بازیابی از نسخههای پشتیبان
- پایش لاگها و در صورت نیاز یکپارچهسازی با SIEM
- بازبینی دورهای حسابهای مدیریتی، کلیدهای SSH و تنظیمات امنیتی
- مستندسازی کامل نسخهها، تنظیمات و تغییرات اعمالشده
22. اگر خطا در مرحله PostgreSQL رخ دهد، اولین اقدامات عیبیابی چیست؟
- وضعیت سرویس PostgreSQL
- تنظیمات اتصال و دسترسی کاربر پایگاه داده
- باز بودن پورتهای لازم
- سازگاری نسخه PostgreSQL با نسخه محصول
- ثبت خطاها در لاگ نصب و لاگهای PostgreSQL
- کافی بودن فضای دیسک و منابع سیستم
23. اگر نصب در مرحله SSH یا Trust متوقف شود، چه باید کرد؟
- صحت نام میزبان و Resolve شدن آن
- دسترسی SSH بین سامانهها
- معتبر بودن Host Key مقصد
- وجود یا عدم وجود فایل
known_hosts - مجوزهای صحیح برای کلیدها و دایرکتوری
.ssh
در برخی موارد، برقراری اتصال اولیه SSH بهصورت دستی میتواند به تشخیص مشکل کمک کند.
نکته ارجاعی: محتوای این بخش با نگاهی به سرفصلهای اجرایی بر اساس اسناد زیر میباشد:
جهت مطالعه ی بیشتر سایر مقالات تخصصی را مطالعه نمایید :
1.راهنمای عملیاتی فنی OSMP (Operational Security Management Platform)
این راهنما با هدف مستندسازی تجربه استقرار و افزایش آمادگی تیمهای فنی تهیه شده است. برای طراحی معماری Production، Hardening و پیادهسازی سازمانی، نیازمندیهای محیط باید بهصورت جداگانه ارزیابی شود.برای اجرای امن و حرفهای راهکارهای سازمانی با آمادسافت در تماس باشید.
پشتیبانی آماد سافت 17 نوشته
محصولات
-
ایست هوم التیمیت سکیوریتی
8,500,000 تومان6,400,000 تومان -
گیفت کارت 100 دلاری پلی استیشن
9,600,000 تومان -
گیفت کارت75 دلاری پلی استیشن
7,250,000 تومان -
گیفت کارت 70 دلاری پلی استیشن
-
گیفت کارت 60 دلاری پلی استیشن
5,830,000 تومان
دیدگاه ها
