ADOM در FortiAnalyzer چیست؟ راهنمای جامع طراحی، ساخت و مدیریت در نسخه 8.0

این مقاله بر اساسFortiAnalyzer 8.0.0نوشته شده است که در زمان تهیه مقاله آخرین شاخه اصلی مستندات رسمی FortiAnalyzer است. در FortiAnalyzer 7.6 مفهوم ADOM و بیشتر مسیرهای اصلی مشابه‌اند، اما ظاهر GUI، نام بعضی منوها، Alert Handlerها و گزینه‌های Device Type یا Storage تفاوت دارند. هنگام ارتقا از 7.6 یا 7.4، ابتدا Upgrade Guide، Compatibility Tool، Device Firmware و ADOM Disk Quota را بررسی کنید. Shell Access که در شاخه 7.6 حذف شده بود، در FortiAnalyzer 8.0 نیز در دسترس نیست.

مروری بر این مقاله

1. ADOM چیست و چه چیزی را جدا می‌کند؟
2. موارد Global و موارد ADOM-specific
3. تفاوت ADOM، VDOM و Security Fabric
4. Root ADOM و ADOMهای Device Type
5. Normal Mode و Advanced Mode
6. چه زمانی ADOM جدا بسازیم؟
7. Naming Convention و مستندسازی
8. سناریوی جامع Multi-Tenant
9. Pre-check قبل از فعال‌کردن ADOM
10. فعال‌کردن ADOM در GUI
11. فعال‌کردن ADOM در CLI
12. ساخت ADOM در GUI و توضیح فیلدها
13. محدودیت رسمی CLI برای ساخت ADOM
14. Administrator Access و RBAC
15. تخصیص Administrator در GUI
16. تخصیص Administrator در CLI
17. Device و VDOM Assignment
18. انتقال Device یا VDOM بین ADOMها
19. ADOM Version و Device Compatibility
20. Storage، Quota و Retention در ADOM
21. Log View، FortiView، Report و Dataset
22. Alert Handler و Incident در ADOM
23. Security Fabric و Non-FortiGate Devices
24. Clone، Disable و Delete کردن ADOM
25. Upgrade FortiAnalyzer و ADOM Lifecycle
26. روش تست دسترسی و جداسازی داده
27. Troubleshooting
28. Best Practice و چک‌لیست اجرایی

1. ADOM چیست و چه چیزی را جدا می‌کند؟

ADOM به Super User اجازه می‌دهد سایر Administratorها را به زیرمجموعه‌ای از Device List و داده‌های مربوط به همان Deviceها محدود کند. هر Administrator بر اساس ADOM Access خود فقط Contextهایی را می‌بیند که به او Assign شده‌اند.

2. موارد Global و موارد ADOM-specific

همه تنظیمات داخل ADOM نیستند. بعضی تنظیمات کل FortiAnalyzer را تحت تأثیر قرار می‌دهند و فقط Super User باید به آن‌ها دسترسی داشته باشد.

چرا این تفکیک مهم است؟

Administrator یک ADOM نباید انتظار داشته باشد Network Interface یا HA خود FortiAnalyzer را تغییر دهد. همچنین تغییر Global Setting می‌تواند تمام Tenantها را تحت تأثیر قرار دهد و باید به تعداد بسیار محدودی Super User محدود شود.

3. تفاوت ADOM، VDOM و Security Fabric

مثال

یک FortiGate دارای دو VDOM به نام‌هایCustomer-AوCustomer-Bاست. در Advanced ADOM Mode می‌توان Log هر VDOM را به ADOM جدا اختصاص داد تا هر مشتری فقط داده خودش را ببیند. در Normal Mode معمولاً Device و VDOMهای آن به‌صورت یک مجموعه مدیریت می‌شوند.

4. Root ADOM و ADOMهای Device Type

پس از فعال‌کردن ADOM، Root ADOM Context اصلی برای Deviceهای FortiGate است. برای محصولات دیگر مانند FortiWeb، FortiMail یا FortiSandbox می‌توان ADOM مناسب Device Type ایجاد کرد یا از ADOMهای پیش‌فرض مربوط به آن Device Type استفاده کرد.

نکات مهم

• Device Type باید با Product واقعی سازگار باشد.
• مخلوط‌کردن Device Typeهای نامرتبط طراحی مناسبی نیست.
• Security Fabric ADOM می‌تواند داده چند محصول Fabric را برای Visibility یکپارچه جمع کند.
• Root ADOM را به‌عنوان محل دائمی همه Deviceها استفاده نکنید، مگر طراحی شما ساده و تک‌سازمانی باشد.
• حساب‌های موجود غیر از Admin ممکن است هنگام فعال‌شدن ADOM به Root Assign شوند و باید بازبینی شوند.

5. Normal Mode و Advanced Mode

چه زمانی Advanced Mode لازم است؟

• یک FortiGate مشترک برای چند مشتری استفاده می‌شود.
• هر VDOM Owner و تیم SOC جدا دارد.
• Retention یا Report هر VDOM باید مستقل باشد.
• قرارداد یا Compliance اجازه مشاهده Cross-Tenant را نمی‌دهد.

6. چه زمانی ADOM جدا بسازیم؟

دلایل مناسب

• مشتری یا Tenant متفاوت
• Administrator Owner متفاوت
• نیاز Retention یا Quota متفاوت
• محیط Production و Lab با حساسیت متفاوت
• Device Type متفاوت
• Major Firmware Version متفاوت
• Report و Alert Workflow مستقل
• الزام قانونی برای جداسازی داده

دلایل نامناسب

• هر شعبه کوچک بدون تفاوت Access یا Retention
• هر Device به‌صورت ADOM جدا بدون نیاز
• جبران Naming ضعیف Deviceها
• تفکیک موقت چندروزه بدون برنامه Cleanup
• عبور از مشکل Version به‌صورت تصادفی

7. Naming Convention و مستندسازی

نام ADOM باید کوتاه، پایدار، یکتا و مستقل از نام افراد باشد. نام را طوری انتخاب کنید که Tenant، Environment، Device Type و Major Version از آن قابل تشخیص باشد.

CUST-A-PROD-FGT74 CUST-A-DR-FGT74 CUST-B-PROD-FGT76 INTERNAL-LAB-FGT76 SECURITY-FABRIC-PROD

مواردی که در Description ثبت شوند

• Owner و تیم مسئول
• Device Type
• Firmware یا ADOM Version
• Retention Requirement
• Administrator Group
• Ticket یا قرارداد ایجاد
• تاریخ Review بعدی

8. سناریوی جامع Multi-Tenant

یک FortiAnalyzer مرکزی برای دو مشتری، یک محیط داخلی و یک FortiWeb استفاده می‌شود

تصمیم‌های طراحی

• هر مشتری ADOM و Administrator جدا دارد.
• Super User فقط تیم Platform است.
• FortiWeb در ADOM Device Type مناسب قرار می‌گیرد.
• Lab Quota کم‌تری دارد تا Storage Production را مصرف نکند.
• Report و Alert Handler داخل همان ADOM ساخته می‌شوند.

9. Pre-check قبل از فعال‌کردن ADOM

• Backup کامل FortiAnalyzer گرفته شده است.
• تعداد Device، VDOM و Tenant مشخص است.
• ADOM Limit مدل یا License بررسی شده است.
• Normal یا Advanced Mode انتخاب شده است.
• Administratorهای فعلی و Scope آن‌ها مستند شده است.
• Device Type و Firmware Versionها فهرست شده‌اند.
• Storage Quota و Retention هر ADOM محاسبه شده است.
• Report و Alertهای فعلی بررسی شده‌اند.
• زمان Logout و تغییر GUI به کاربران اعلام شده است.
• حساب Super User و MFA آن تست شده است.

دستورات Read-only

get system status show system global show system admin user show system admin profile diagnose log device diagnose fortilogd logvol-adom

10. فعال‌کردن ADOM در GUI

1. با حساب Super User وارد شوید.
2. از FortiAnalyzer Backup بگیرید.
3. در Widget مربوط به System Information، Administrative Domain را Edit کنید.
4. ADOM را Enable کنید.
5. Normal یا Advanced Mode را انتخاب کنید.
6. در صورت نمایش ADOM Selector، آن را فعال نگه دارید.
7. تغییر را Apply کنید.
8. پس از Logout، دوباره Login کنید.
9. Root ADOM و ADOM Selector را بررسی کنید.
10. حساب‌های Administrator موجود را بازبینی کنید.

11. فعال‌کردن ADOM در CLI

Normal Mode

config system global set adom-status enable set adom-mode normal set adom-select enable end

Advanced Mode

config system global set adom-status enable set adom-mode advanced set adom-select enable end

بررسی

show system global get system status

12. ساخت ADOM در GUI و توضیح فیلدها

ترتیب ساخت پیشنهادی

1. Name، Description، Device Type و Version را تنظیم کنید.
2. Storage Policy و Quota را قبل از ورود Log سنگین مشخص کنید.
3. Deviceها را Assign کنید.
4. Administrator و Access Profile را تنظیم کنید.
5. Report و Alert Handler را داخل ADOM بسازید.
6. جداسازی داده را با حساب Tenant تست کنید.

13. محدودیت رسمی CLI برای ساخت ADOM

در FortiAnalyzer 8.0، Workflow رسمی و مستند برای ساخت و ویرایش خود ADOM از GUI انجام می‌شود. CLI Reference به‌طور رسمی فعال‌کردن ADOM Mode، انتخاب Context و تخصیص ADOM به Administrator را پوشش می‌دهد، اما نباید یک Command Tree حدسی برای ساخت ADOM ارائه کرد.

CLIهای رسمی مرتبط

• config system globalبرای ADOM Status و Mode
• config system admin userبرای ADOM Access
• config system admin profileبرای Permission
• diagnose fortilogd logvol-adomبرای حجم Log
• execute log adom disk-quotaدر Workflowهای پشتیبانی‌شده برای Quota

14. Administrator Access و RBAC

دسترسی Administrator ترکیبی از Access Profile و ADOM Scope است. Access Profile مشخص می‌کند فرد چه کاری انجام دهد و ADOM Scope مشخص می‌کند روی کدام داده‌ها و Deviceها آن کار را انجام دهد.

اصل Least Privilege

• Super User فقط برای تیم Platform
• Customer Admin فقط ADOM خودش
• Read-only برای Auditor
• Report Permission بدون Device Management برای Business User
• Alert Management فقط برای SOC
• Trusted Host و MFA برای تمام حساب‌های حساس

15. تخصیص Administrator در GUI

1. Username یاRemoteAuthentication را انتخاب کنید.
2. Access Profile مناسب را انتخاب کنید.
3. Administrative Domain را روی Specify یا Exclude قرار دهید.
4. ADOMهای موردنظر را انتخاب کنید.
5. Trusted Host را محدود کنید.
6. MFA یا Authentication Server را تنظیم کنید.
7. Account را Save کنید.
8. با همان حساب Login و Scope را تست کنید.

مواردی که با حساب Tenant باید تست شوند

• ADOMهای دیگر در Selector دیده نشوند.
• Deviceهای Tenant دیگر در Device Manager دیده نشوند.
• Log Search به ADOM خودش محدود باشد.
• Report و Alert Handlerهای دیگر قابل مشاهده نباشند.
• System Settingهای Global قابل تغییر نباشند.

16. تخصیص Administrator در CLI

فقط یک ADOM

config system admin user edit "soc-operator-a" set user_type local set profileid "Standard_User" set adom-access specify set adom "CUST-A-PROD-FGT74" set trusthost1 10.20.30..0 next end

چند ADOM

config system admin user edit "soc-senior" set user_type local set profileid "Standard_User" set adom-access specify set adom "CUST-A-PROD-FGT74" "CUST-B-PROD-FGT76" next end

همه به‌جز Lab

config system admin user edit "regional-admin" set user_type local set profileid "Standard_User" set adom-access exclude set adom "INTERNAL-LAB-FGT76" next end

بررسی

show system admin user show system admin profile

17. Device و VDOM Assignment

Device Assignment تعیین می‌کند Log و داده Device در کدام ADOM دیده شود. در Normal Mode معمولاً Device به‌صورت کامل Assign می‌شود؛ در Advanced Mode امکان تفکیک VDOMها وجود دارد.

Workflow GUI

1. Device یا VDOM موردنظر را انتخاب کنید.
2. Firmware و Device Type را بررسی کنید.
3. ADOM مقصد را انتخاب کنید.
4. تغییر را Save کنید.
5. Log جدید را در ADOM مقصد تأیید کنید.
6. Report و Alert Handler مقصد را آزمایش کنید.

قبل از Assignment

• Device در ADOM دیگری نباشد یا Move Plan مشخص باشد.
• Quota مقصد ظرفیت Log ورودی را داشته باشد.
• Administrator مقصد Assign شده باشد.
• Firmware Version با ADOM Version سازگار باشد.
• Security Fabric Relationship شکسته نشود.

18. انتقال Device یا VDOM بین ADOMها

Move کردن Device فقط یک تغییر نمایش نیست. Logهای تاریخی، Report Schedule، Alert Handler، Device Scope و Administrator Access می‌توانند تحت تأثیر قرار گیرند.

Change Plan پیشنهادی

1. مبدأ، مقصد و دلیل Move را ثبت کنید.
2. Device Type و ADOM Version را مقایسه کنید.
3. Quota و Retention مقصد را بررسی کنید.
4. Report، Alert Handler و Administrator مقصد را آماده کنید.
5. در بازه کم‌ریسک Device را Move کنید.
6. دریافت Log جدید را بررسی کنید.
7. Logهای تاریخی را در مبدأ و مقصد جستجو کنید.
8. Report و Alert را با Event تستی اجرا کنید.
9. دسترسی حساب Tenant را بازبینی کنید.

19. ADOM Version و Device Compatibility

ADOM Version باید با نسل Firmware Deviceهای داخل ADOM سازگار باشد. در FortiAnalyzer، این انتخاب بر Device Compatibility، Log Interpretation و Featureهایی که در Context ADOM قابل استفاده‌اند اثر می‌گذارد.

قواعد عملیاتی

• Deviceهای دارای Major Version متفاوت را بدون بررسی Compatibility در یک ADOM قرار ندهید.
• قبل از Upgrade ADOM، Deviceها و FortiAnalyzer را طبق Upgrade Guide بررسی کنید.
• Compatibility Tool رسمی را ملاک قرار دهید.
• ADOM Version را فقط برای حل یک Warning بدون Root Cause تغییر ندهید.
• پس از Upgrade، Log Parsing، Dataset و Report را تست کنید.

سناریوی Migration

1. FortiAnalyzer را طبق Upgrade Path ارتقا دهید.
2. Deviceهای FortiGate را طبق Change Plan ارتقا دهید.
3. دریافت Log و Parsing را بررسی کنید.
4. ADOM Version را طبق Compatibility ارتقا دهید.
5. Report، FortiView و Alert Handler را Regression Test کنید.

20. Storage، Quota و Retention در ADOM

ADOM یک مرز Storage Policy نیز هست. اگر Quota زودتر از Retention Day پر شود، Logهای قدیمی پیش از رسیدن به تعداد روز هدف حذف می‌شوند.

CLI مرتبط با Quota و حجم

diagnose fortilogd logvol-adom diagnose fortilogd lograte diagnose log device # نمونه تخصیص Quota در Workflow پشتیبانی‌شده: execute log adom disk-quota "CUST-A-PROD-FGT74" 1024000

21. Log View، FortiView، Report و Dataset

وقتی ADOM فعال است، بیشتر ابزارهای تحلیل در Context ADOM کار می‌کنند. انتخاب ADOM اشتباه یکی از رایج‌ترین دلایل «نبودن Log» یا «خالی بودن Report» است.

Log View

• فقط Deviceهای ADOM در Filter دیده می‌شوند.
• Time Range و Log Type باید صحیح باشد.
• Analytics و Archive Status را بررسی کنید.

FortiView

• Widgetها بر اساس Device Scope ADOM ساخته می‌شوند.
• Drill-down به Logهای همان ADOM می‌رود.
• عدم وجود Analytics Log باعث خالی بودن Widget می‌شود.

Report

• Report Template ممکن است Global یا ADOM-specific باشد.
• Schedule و Output Profile باید داخل Context صحیح تنظیم شوند.
• Dataset Fieldها باید با Log Deviceهای ADOM سازگار باشند.
• قبل از Schedule، Report را On-demand اجرا کنید.

22. Alert Handler و Incident در ADOM

در FortiAnalyzer 8.0، نام رسمی قابلیت از Event Handler به Alert Handler تغییر کرده است. Handlerها و Alertها در Context ADOM قرار دارند و فقط Analytics Logهای همان Scope را پردازش می‌کنند.

نکات طراحی

• Handler داخل ADOM Tenant ساخته شود.
• Data Selector فقط Deviceهای همان ADOM را ببیند.
• Notification Profile Recipient درست داشته باشد.
• Threshold با Log Volume Tenant Tune شود.
• Handler مشترک را با Export/Import رسمی توزیع کنید.
• بعد از Move Device، Handler مقصد را تست کنید.

مشکل رایج

اگر Handler Event تولید نمی‌کند، ابتدا ADOM Selector، Analytics Retention، Device Scope و Fieldهای Log را بررسی کنید؛ وجود Log در Archive به‌تنهایی کافی نیست.

23. Security Fabric و Non-FortiGate Devices

FortiAnalyzer می‌تواند Log محصولات مختلف Fortinet را دریافت کند. برای Deviceهای غیرFortiGate باید Device Type ADOM و Security Fabric Design بررسی شود.

FortiWeb

• در ADOM Device Type مناسب FortiWeb قرار گیرد.
• Report و Dataset با Fieldهای WAF سازگار باشند.
• Administrator AppSec فقط ADOM FortiWeb را ببیند.

Security Fabric ADOM

• برای Visibility یکپارچه چند Product مفید است.
• ممکن است Scope Tenant را گسترده‌تر کند؛ Access را دقیق تست کنید.
• همه Log Typeها و Reportها الزاماً یکسان نیستند.

24. Clone، Disable و Delete کردن ADOM

Clone

برای ساخت ADOM با تنظیمات مشابه مفید است، اما Deviceها و Logها الزاماً Clone نمی‌شوند. بعد از Clone، Name، Version، Quota، Administrator و Report Schedule را بازبینی کنید.

Disable

ADOM غیرفعال ممکن است از انتخاب روزمره خارج شود، اما قبل از Disable مشخص کنید Log Collection، Report Schedule و Administrator Access چه رفتاری خواهند داشت.

Delete

Checklist حذف

• ADOM Owner تأیید کرده است.
• Deviceها Move یا Deauthorize شده‌اند.
• Logهای لازم Export یا Archive شده‌اند.
• Report و Handlerها Export شده‌اند.
• Administrator Assignment اصلاح شده است.
• Change Ticket و Rollback Plan وجود دارد.

25. Upgrade FortiAnalyzer و ADOM Lifecycle

Upgrade FortiAnalyzer باید شامل بررسی ADOM نیز باشد. Fortinet توصیه می‌کند قبل از Upgrade، Release Notes، Upgrade Path، Model Support، Device Compatibility و ADOM Disk Quota بررسی شوند.

قبل از Upgrade

• Backup Configuration و در صورت نیاز Log
• بررسی Quota هر ADOM
• بررسی Unsupported ADOM Version
• ثبت Report و Alert Handlerهای سفارشی
• بررسی HA در صورت وجود
• بررسی License و Disk Space

بعد از Upgrade

• ADOM Selector و Device Assignment
• Log Receiving و Parsing
• FortiView Widgetها
• Report On-demand
• Alert Handler Test
• Administrator Scope
• Quota و Retention

26. روش تست دسترسی و جداسازی داده

Test Matrix

آزمون‌های لازم

1. Login با هر Role
2. بررسی ADOM Selector
3. بررسی Device Manager
4. Search یک Log مشخص
5. اجرای Report On-demand
6. مشاهده Alert Handler
7. تلاش برای ورود به System Setting Global
8. تلاش برای مشاهده Tenant دیگر
9. ثبت نتیجه و Screenshot در Change Record

27. Troubleshooting

دستورات بررسی

get system status show system global show system admin user show system admin profile diagnose log device diagnose fortilogd lograte diagnose fortilogd logvol-adom

28. Best Practice و چک‌لیست اجرایی

• دلیل ایجاد هر ADOM مستند است.
• تعداد ADOMها بی‌دلیل زیاد نشده است.
• Limit مدل یا License بررسی شده است.
• Naming Convention یکتا استفاده می‌شود.
• Normal Mode مگر با نیاز واقعی انتخاب شده است.
• Advanced Mode فقط برای VDOM Multi-Tenancy استفاده می‌شود.
• Device Type هر ADOM صحیح است.
• ADOM Version با Deviceها سازگار است.
• Root ADOM محل دائمی Deviceهای نامرتبط نیست.
• Administratorها فقط ADOM لازم را می‌بینند.
• Super Userها محدود، MFAدار و دارای Trusted Host هستند.
• Access Profileها Least Privilege دارند.
• Quota و Retention هر ADOM محاسبه شده است.
• Analytics Retention نیاز Alert و Report را پوشش می‌دهد.
• Report و Alert Handler در Context صحیح ساخته می‌شوند.
• Move Device دارای Change Plan و Test است.
• اثر Move بر Log تاریخی بررسی شده است.
• Delete ADOM بدون Export و Backup انجام نمی‌شود.
• قبل از Upgrade، ADOM Disk Quota بررسی می‌شود.
• بعد از Upgrade، Access و Data Isolation تست می‌شوند.
• Shell یا Command غیرمستند برای ساخت ADOM استفاده نمی‌شود.

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