لاگ سیستم Okta

Okta System Log را به رویدادهای امنیتی Status200 وارد کنید: ورودها، چالش‌های MFA، تغییرات حساب و گروه، و تشخیص‌های تهدید خود Okta. آنجا آن‌ها را کنار لاگ‌ها، ترِیس‌ها و متریک‌هایتان جستجو می‌کنید، با هر منبع دیگری هم‌بسته می‌کنید، و برای آن‌هایی که مهم‌اند آنکال را فرا می‌خوانید. Status200 آن‌ها را با یک توکن API که خودتان می‌سازید می‌خواند، و هیچ چیزی را در Okta تغییر نمی‌دهد.

چگونه کار می‌کند#

Status200 هر دقیقه از هر اتصال فعالی که بازهٔ نظرسنجی‌اش گذشته باشد نظرسنجی می‌کند. یک نظرسنجی رویدادهای System Log منتشرشده از نظرسنجی پیش را از Okta می‌خواهد، و هر کدام را به‌صورت یک رویداد OCSF ذخیره می‌کند: یک ورود به‌صورت رویداد Authentication، یک ویرایش حساب به‌صورت Account Change، و یک تشخیص Okta به‌صورت Detection Finding. از آن پس قاعده‌های تشخیص، مانیتورها و داشبوردها با آن مانند یک رویداد امنیتی از هر منبع دیگری رفتار می‌کنند. با هر سلول Okta، یعنی okta.com، oktapreview.com و okta-emea.com، و با سازمانی روی دامنهٔ سفارشی کار می‌کند.

پیش از شروع#

• در Status200، نقش Project Owner، Project Admin یا Security Admin. Security Member و Security Viewer می‌توانند اتصال‌ها و تاریخچهٔ اجرایشان را ببینند، اما نمی‌توانند آن‌ها را تغییر دهند.
• یک مدیر Okta که بتواند System Log را ببیند، برای ساختن توکن. یک توکن هر کاری را که مدیرش می‌تواند انجام می‌دهد، پس از یک Read-only Administrator استفاده کنید: System Log را می‌خواند و هیچ چیزی را تغییر نمی‌دهد. یک مدیر فقط‌خواندنی کاربران، گروه‌ها، برنامه‌ها و تنظیمات را هم می‌بیند، پس توکن را به اندازهٔ یک رمز عبور امن نگه دارید.
• در حالت ایده‌آل، یک حساب سرویس برای آن مدیر. Okta توکنی را وقتی غیرفعال می‌کند که مدیرش غیرفعال شود، و وقتی ۳۰ روز بی‌استفاده بماند. نظرسنجی هر چند دقیقه از آن استفاده می‌کند، پس تا وقتی اتصال فعال است در استفاده می‌ماند.
• اگر سازمان شما فقط از یک ناحیهٔ شبکه فراخوانی API می‌پذیرد، ناحیه‌ای که نشانی‌هایی را که Status200 از آن‌ها فرا می‌خواند در بر دارد: در Status200 Cloud، نشانی‌های خروجی آن، و در یک نصب خودمیزبان، نشانی عمومی میزبان‌های برنامه و کارگر شما.

راه‌اندازی اتصال#

1. ساختن یک توکن API#

   1. به‌عنوان مدیر فقط‌خواندنی به Admin Console در Okta وارد شوید.
   2. Security → API را باز کنید، سپس زبانهٔ Tokens را، و Create token را برگزینید.
   3. نامی به آن بدهید، برای نمونه Status200 security events. زیر محل‌هایی که فراخوانی‌هایش می‌توانند از آن‌ها بیایند، Any IP را نگه دارید، مگر اینکه سازمان شما به یک ناحیه نیاز داشته باشد.
   4. Create token را برگزینید، و Token Value را کپی کنید. Okta آن را یک بار نشان می‌دهد.

   هر توکن می‌تواند سهمی از محدودیت نرخ API سازمان را به کار ببرد، که ردیف آن در زبانهٔ Tokens نشان می‌دهد. یک نظرسنجی حداکثر ۲۰ درخواست می‌فرستد، پس سهم پیش‌فرض کافی است، مگر اینکه ابزارهای دیگر از همان توکن استفاده کنند.

2. افزودن اتصال در Status200#

   محصولات > رویدادهای امنیتی > Connections (/dashboard/{projectId}/security-events/connections) را باز کنید، روی افزودن اتصال کلیک کنید، Okta System Log را برگزینید، و روی بعدی کلیک کنید. تنظیمات جدول زیر را پر کنید، روی بعدی کلیک کنید، و توکن را در API token بچسبانید.

3. آزمایش پیش از ذخیره#

   روی Test these settings زیر آزمایش پیش از ذخیره کلیک کنید. آزمایش با مقدارهای فرم وارد می‌شود و رویدادها را می‌خواند، و چیزی ذخیره نمی‌کند، پس نشانی نادرست یا یک پالایهٔ بد پیش از ساخته شدن اتصال آشکار می‌شود. سپس روی بعدی کلیک کنید، به اتصال یک نام بدهید، و آن را بسازید.

گام Polling همچنین یک توضیحات اختیاری دارد، Poll Interval (Minutes)، یک عدد صحیح از 1 تا 1440 که با 5 شروع می‌شود، و فعال، که از آغاز روشن است.

چه چیزی وارد می‌شود#

بدون Event filter، Status200 خانواده‌های رویدادی را که یک تیم امنیتی زیر نظر دارد، بر پایهٔ پیشوند eventType، وارد می‌کند. پالایهٔ خودتان این فهرست را جایگزین می‌کند، نه اینکه به آن بیفزاید:

هر رویداد به یک رویداد OCSF تبدیل می‌شود، با فروشندهٔ Okta و محصول Okta System Log، از کلاسی که eventType آن می‌طلبد:

رویدادی که در هیچ‌کدام از این کلاس‌ها نمی‌گنجد باز هم هر فیلد را نگه می‌دارد، و بر پایهٔ هر کدام از آن‌ها جستجوپذیر می‌ماند. هر رویداد این ستون‌ها را پر می‌کند:

ورود ناموفق یا ردشده در INFO به Low بالا برده می‌شود، تا از یک ورود موفق متمایز شود. System Log هیچ ارجاع MITRE ATT&CK ندارد، پس آن ستون‌ها خالی می‌مانند.

نظرسنجی چگونه کار می‌کند#

هر نظرسنجی رویدادهای منتشرشده در پنجره‌اش را، قدیمی‌ترین‌ها اول، ۱٬۰۰۰ تا در هر صفحه، فهرست می‌کند، و پیوند next را که Okta می‌فرستد تا آخرین صفحه دنبال می‌کند:

GET {Okta organization URL}/api/v1/logs?since={window start}&until={window end}&sortOrder=ASCENDING&limit=1000&filter={Event filter}

• زمان انتشار، نشانگر است. یک رویداد System Log خودِ فعالیت است، پس published هم زمان رخ دادن آن است و هم چیزی که نظرسنجی می‌خواند.
• نخستین نظرسنجی ۲۴ ساعت به عقب نگاه می‌کند، پس یک اتصال تازه بی‌درنگ رویدادهای اخیرش را نشان می‌دهد.
• هر نظرسنجی بعدی ۱۵ دقیقه پیش از نشانگر ذخیره‌شده شروع می‌شود. Okta هشدار می‌دهد که درخواستی با زمان پایان ممکن است رویدادهای دیرکرده را جا بیندازد، که آن را نادر می‌خواند. هم‌پوشانی آن‌ها را در نظرسنجی بعدی می‌خواند. رویدادی که بیش از ۱۵ دقیقه دیر کند ممکن است پشت نشانگر بیفتد: بازهٔ زمانی آن را وارد کنید تا بازیابی شود.
• یک نظرسنجی حداکثر ۲۴ ساعت پس از نشانگر را می‌خواند. اتصالی که نشانگرش عقب افتاده، در رشته‌ای از پنجره‌های ۲۴ ساعته جبران می‌کند، و Health آن Catching up را نشان می‌دهد.
• تکراری‌ها بر پایهٔ uuid کنار گذاشته می‌شوند، درون پروژه، پس هم‌پوشانی، پنجره‌ای که دوباره امتحان شده و یک وارد کردن هرگز یک رویداد را دو بار ذخیره نمی‌کنند.

پیوند next که به جایی جز Okta organization URL شما اشاره کند هرگز دنبال نمی‌شود، چون توکن با هر درخواست می‌رود.

وقتی یک پنجره بیش از توان یک نظرسنجی دارد#

یک نظرسنجی حداکثر ۱۰٬۰۰۰ رویداد را، در حداکثر ۲۰ درخواست، می‌خواند. وقتی پنجره‌ای بیشتر از این داشته باشد، اجرا Partial است، با هشداری مانند:

Stopped after collecting 10000 events; the window holds more. The last event read was published at 2026-09-14T08:12:44.000Z.

رویدادها قدیمی‌ترین‌ها اول خوانده می‌شوند، پس Status200 نشانگر را به زمان انتشار آخرین رویدادی که خوانده می‌برد، و نظرسنجی بعدی از آنجا، بدون هم‌پوشانی ۱۵ دقیقه‌ای، با همان طول پنجره شروع می‌شود. یک سازمان پرکار در هر نظرسنجی ۱۰٬۰۰۰ رویداد جبران می‌کند، به جای اینکه همان رویدادها را دوباره بخواند. هم‌پوشانی وقتی برمی‌گردد که نشانگر ۱۵ دقیقه از آن نقطه جلوتر رفته باشد.

وقتی یک اجرا اصلاً نتواند از نشانگر ذخیره‌شده جلوتر برود، برای نمونه چون فقط ۱۵ دقیقهٔ هم‌پوشانی بیش از ۱۰٬۰۰۰ رویداد دارد، Status200 به جای آن پنجره را کوتاه می‌کند:

1. باریک کردن. نظرسنجی بعدی پنجره‌ای به نصف طول را از همان نقطهٔ شروع می‌خواند، و تا وقتی پنجره‌ای کامل خوانده شود دوباره نصف می‌کند، تا حداقل یک دقیقه. هشدار اجرا همین را می‌گوید: This window holds more records than one poll can read; the next poll reads a {n} minute window from the same starting point.
2. دوباره بزرگ کردن. پس از اینکه پنجره‌ای کامل خوانده شد، پنجرهٔ بعدی دوباره دو برابر می‌شود، تا ۲۴ ساعت.
3. گذشتن از یک دقیقهٔ تنها. اگر حتی یک دقیقه بیش از توان یک نظرسنجی داشته باشد، نظرسنجی از آن می‌گذرد، تا رویدادهای تازه‌تر همچنان برسند، و هم‌پوشانی نظرسنجی‌های بعدی دیگر به آن نمی‌رسد. اجرا Partial می‌ماند، و آخرین خطا این را نشان می‌دهد: More records were created in the one minute from {cursor} to {end} than one poll can read. Polling moved past this minute so newer records keep arriving; use Import this time range in Diagnostics on this minute to recover what one run can read. آن دقیقه را با Import this time range وارد کنید تا آنچه یک اجرا می‌تواند بخواند بازیابی شود، یا Event filter را باریک‌تر کنید.

اجرایی که با خطایی از Okta یکسره شکست بخورد، نشانگر و طول پنجره را نگه می‌دارد، و نظرسنجی بعدی همان پنجره را دوباره می‌خواند. تنها استثنا درخواستی است که زمانش سر رسیده: نشانگر می‌ماند، اما پنجرهٔ بعدی نصف طول می‌شود، چون پنجره‌ای که برای پاسخ به‌موقع بیش از حد سنگین است در هر تلاش به پایان زمان می‌خورد. تغییر Poll Interval (Minutes) هیچ‌کدام از این‌ها را تغییر نمی‌دهد: این تنظیم تعیین می‌کند یک نظرسنجی هر چند وقت شروع شود، نه اینکه پنجره‌اش از کجا شروع شود.

اجرا، پیش‌نمایش و وارد کردن در صورت نیاز#

روی Diagnostics یک اتصال کلیک کنید تا اجراهای اخیرش را ببینید و دستی با آن کار کنید. هر کسی که بتواند اتصال را تغییر دهد می‌تواند این‌ها را شروع کند؛ هر کسی که بتواند آن را ببیند می‌تواند تاریخچه را بخواند.

• Run now بی‌درنگ یک نظرسنجی با نشانگر معمول شروع می‌کند، حتی وقتی اتصال فعال نیست.
• Preview log events یک بازهٔ زمانی تا ۷ روز را می‌خواند و چیزی وارد نمی‌کند.
• Import this time range پس از تأیید شما بازه‌ای تا ۷ روز را وارد می‌کند، بی‌آنکه نشانگر را جابه‌جا کند. رویدادهایی که پیش‌تر وارد شده‌اند رد می‌شوند. Okta لاگ سیستم را ۹۰ روز نگه می‌دارد.
• Copy diagnostics روی یک اجرا، گزارش آن را برای پشتیبانی کپی می‌کند. هرگز اعتبارنامه‌ها را در بر ندارد.

آزمایش اتصال#

آزمایش اتصال در ردیف یک اتصال، و Test these settings در فرم، در فرایند API اجرا می‌شوند، نه در یک کارگر پس‌زمینه، پس یک آزمایش حتی وقتی مشکل از کارگرهاست هم پاسخ می‌دهد. این بررسی‌ها را به ترتیب انجام می‌دهد:

هر درخواست در یک آزمایش مهلتی ۲۰ ثانیه‌ای دارد. یک آزمایش هرگز چیزی وارد نمی‌کند یا نشانگر را جابه‌جا نمی‌کند، و هر بررسی شکست‌خورده می‌گوید چه چیزی را تغییر دهید.

عیب‌یابی#

آخرین خطا اتصال پیام خطای کامل را، با اعتبارنامه‌های پوشانده‌شده، پشت پیشوندی نگه می‌دارد که گام شکست‌خورده را نام می‌برد. وقتی اتصالی خطا دارد، برای خواندنش مشاهده خطا را در ستون اقدام‌ها آن برگزینید، و برای کپی کردنش کپی خطا را در کادر گفتگو. هر پیام با Okta System Log events request شروع می‌شود، و کد خطای خود Okta را پس از وضعیت نقل می‌کند؛ آنچه پس از آن می‌آید را بخوانید.

چه به دست می‌آورید#

• جستجو. ورودها، نتیجه‌های MFA، تغییرات حساب و تشخیص‌های Okta را در کاوشگر رویدادهای امنیتی، کنار هر منبع دیگری، بر پایهٔ شدت، وضعیت، کاربر، IP یا هر observable پالایش کنید.
• هم‌بسته‌سازی. کاربران، برنامه‌ها و IPهای هر رویداد به‌صورت observable نمایه می‌شوند، پس یک جستجو هر کاری را که یک کاربر کرده، کنار لاگ‌های خود برنامهٔ او، پیدا می‌کند.
• قاعده‌های تشخیص. قاعده‌های Sigma که بر اساس زمان‌بندی روی رویدادهای امنیتی شما اجرا می‌شوند، مانند ورودهای ناموفق برای هر IP یا ردهای MFA برای هر کاربر، و هشدارهایی باز می‌کنند که آنکال را فرا می‌خوانند.
• مانیتورها. مانیتورهای رویدادهای امنیتی رویدادهای جور را می‌شمارند و پس از گذشتن از یک آستانه حادثه یا هشدار باز می‌کنند.

رویدادهای امنیتی مانند بقیهٔ تله‌متری شما، بر اساس هر گیگابایت دریافت‌شده صورت‌حساب می‌شوند. قیمت‌گذاری را ببینید.

گام‌های بعدی#