Skip to main content

Кожна вправа проіндексована за назвою та посиланнями на CWE, OWASP, MITRE ATT&CK, CIS, NIST CSF, GDPR і Закон ЄС про ШІ.

Спробуйте

PagerDuty Integrations

Підключення PagerDuty до RansomLeak

Коли інцидент безпеки спрямовується до відповідального, RansomLeak призначає йому короткий модуль безпеки й записує проходження назад в інцидент нотаткою. Момент інциденту стає моментом навчання, а доказ лежить на стрічці. Підключіть один раз через OAuth 2.0, без налаштування для кожного інциденту.

Переглянути в каталозі інтеграцій PagerDuty

Оновлено вересень 2026

Огляд

RansomLeak для PagerDuty перетворює інцидент безпеки на навчальний момент. Коли інцидент спрямовується до відповідального, RansomLeak призначає цій людині короткий модуль на пʼять–десять хвилин і публікує проходження назад в інцидент нотаткою, тож навчання та його доказ живуть там, де вже відбувається реакція.

Адміністратор підключає його один раз, і далі він працює сам:

  • Інцидент спрямовується до відповідального
  • Призначається модуль на пʼять–десять хвилин
  • Проходження публікується нотаткою в інциденті
  • Ідемпотентно, тож ніколи не призначає двічі

Це застосунок RansomLeak для PagerDuty, побудований на PagerDuty App Registration з OAuth 2.0 та Webhooks v3. Немає жодного налаштування для кожного інциденту й жодного скрипта, який треба хостити. Окремий no-code рецепт Incident Workflow доступний для команд, які хочуть побудувати цикл вручну.

Вимоги

  • Акаунт PagerDuty на будь-якому плані з Webhooks v3, у регіоні обслуговування US або EU.
  • Той, хто підключає, має бути Admin або Account Owner у PagerDuty. Підписка на вебхуки охоплює весь акаунт, і PagerDuty дозволяє створювати її лише цим ролям.
  • Тенант RansomLeak і адміністратор у ньому, який може відкрити Settings → Integrations.
  • Відповідальні існують у RansomLeak з тією самою робочою поштою, що й у PagerDuty. Відповідальний без відповідного користувача RansomLeak пропускається.

Встановлення в один клік

Адміністратор підключає з RansomLeak. Жодного API-ключа копіювати чи вставляти не треба: PagerDuty видає токен OAuth, а RansomLeak створює підписку на вебхуки за вас, тож на кожному інциденті нічого налаштовувати не треба.

  1. У RansomLeak відкрийте Settings → Integrations → PagerDuty і виберіть Connect.

  2. Вас перенаправить до PagerDuty. Увійдіть як Admin або Account Owner, оберіть акаунт і підтвердьте доступ write, який запитує застосунок.

  3. Ви повертаєтеся в RansomLeak, де підключення показано як активне. Він зберіг токени OAuth зашифрованими й створив підписку Webhooks v3, спрямовану на свій приймач.

  4. Оберіть, який модуль RansomLeak призначається, коли інцидент спрямовується до відповідального, і збережіть.

  5. У розділі Security services оберіть сервіси PagerDuty, які створюють інциденти безпеки, або залиште всі сервіси, і збережіть. Це все налаштування.

Який доступ запитується й навіщо

Застосунок запитує дозвіл OAuth PagerDuty write — саме цей дозвіл доступний застосункам із каталогу PagerDuty App Directory. Доступ до ваших даних також обмежений роллю того, хто авторизує. Застосунок використовує цей доступ лише для таких викликів:

Виклик Читання чи запис Навіщо він робиться
POST /webhook_subscriptionsЗаписСтворити підписку на події під час підключення.
PUT /webhook_subscriptions/{id}ЗаписОновлювати список подій підписки, коли ви зберігаєте налаштування.
GET /servicesЧитанняПоказати ваші сервіси для вибору сервісів безпеки.
GET /users/{id}ЧитанняВизначити робочу пошту відповідального.
POST /incidents/{id}/notesЗаписОпублікувати нотатку про проходження.
DELETE /webhook_subscriptions/{id}ЗаписВидалити підписку під час відключення.

RansomLeak ніколи не створює, не редагує, не підтверджує, не перепризначає й не закриває інциденти і ніколи не змінює користувачів, розклади чи сервіси.

Які події обробляє

RansomLeak підписується на чотири інцидентні події Webhooks v3. Коли одна з них надходить із сервісу, який ви позначили як сервіс безпеки (або з будь-якого, якщо ви залишили всі), він визначає робочу пошту відповідального, призначає налаштований модуль і надсилає йому пряме посилання, щоб почати.

  • incident.triggered
  • incident.responder.added
  • incident.reassigned
  • incident.escalated

Призначення ідемпотентне для пари «інцидент і відповідальний», тож повторна чи відредагована подія ніколи не призначає ту саму людину двічі, а тому, хто пройшов модуль за останні 30 днів, він не призначається повторно, тож зайнятого чергового інженера не перенавчають на кожному виклику. Доставки вебхуків перевіряються за HMAC-SHA256 над сирим тілом запиту проти секрету кожної підписки, тож підроблені дані відхиляються.

Запис проходження назад

Коли призначений модуль завершено, RansomLeak публікує нотатку в первинному інциденті, тож доказ лежить на стрічці поруч із рештою реакції:

RansomLeak: "<module title>" completed by <user email> on <date>.

Якщо модуль має тест, нотатка завершується його результатом, наприклад Quiz passed (100%). або Quiz not passed (83%)., тож невдала спроба ніколи не подається як чисте проходження.

Запис назад використовує те саме підключення OAuth, тож немає другого облікового запису, яким треба керувати. Кожне проходження публікується щонайбільше один раз, тож повторне чи дубльоване проходження ніколи не дублює нотатку.

Дозволи та обробка даних

Інтеграція зчитує якомога менше. Вона використовує лише ті конкретні поля інциденту, які потрібні, щоб ідентифікувати причетного співробітника, і ніколи не зберігає тіло інциденту.

Дані Як вони обробляються
Id інциденту й робоча пошта відповідального чи призначеногоЗчитуються, щоб визначити людину й призначити модуль.
Призначення й одна нотатка про проходженняНадсилаються до assignment API RansomLeak і назад в інцидент, через TLS.
Тіло інциденту, заголовок та інші поляНіколи не зберігаються поза межами відправлення.
  • Токени й секрет вебхуків зашифровані (AES-256-GCM)
  • Доставки перевіряються за HMAC-SHA256
  • Відключення видаляє підписку й токени

Жодні дані не передаються третім сторонам, і жодні дані користувача, окрім робочої пошти, не залишають ваш тенант. Резидентність даних відповідає регіону PagerDuty для підключення, US або EU, і регіону API RansomLeak. Про те, як RansomLeak обробляє дані, читайте в політиці конфіденційності та на сторінці безпеки й відповідності.

Видалення

  1. У RansomLeak відкрийте Settings → Integrations → PagerDuty і виберіть Disconnect.

  2. RansomLeak видаляє підписку Webhooks v3 на боці PagerDuty, а також збережені токени й секрет підпису.

Якщо ви відкликаєте застосунок у самому PagerDuty, RansomLeak виявляє це під час наступного оновлення токена й автоматично очищає локальне підключення. Уже призначене навчання залишається в RansomLeak.

Підтримка

Цю інтеграцію підтримує RansomLeak. Щоб отримати допомогу з підключенням, поставити запитання чи повідомити про проблему, напишіть на support@ransomleak.com. Вкажіть адресу свого тенанта RansomLeak і, якщо потрібно, номер інциденту PagerDuty.

Поширені запитання

Чи інтегрується RansomLeak із PagerDuty?

Так. Адміністратор один раз підключає застосунок RansomLeak до PagerDuty через OAuth 2.0, і відтоді, коли інцидент безпеки спрямовується до відповідального, RansomLeak призначає цій людині короткий модуль безпеки на пʼять–десять хвилин і записує проходження назад в інцидент нотаткою. Немає жодного налаштування для кожного інциденту й жодного скрипта, який треба хостити.

Як інцидент призначає навчання?

Під час встановлення RansomLeak створює підписку Webhooks v3 на вашому акаунті, і ви обираєте, який модуль призначається. Також можна обмежити це сервісами PagerDuty, які створюють інциденти безпеки. Коли PagerDuty надсилає incident.triggered, incident.responder.added, incident.reassigned або incident.escalated з одного з цих сервісів, RansomLeak визначає робочу пошту відповідального, призначає налаштований модуль і надсилає йому пряме посилання, щоб почати. Призначення ідемпотентне для пари «інцидент і відповідальний», а тому, хто пройшов модуль за останні 30 днів, він не призначається повторно.

Які дані інтеграція зчитує й зберігає?

Вона зчитує лише id інциденту, на який посилається подія, і робочу пошту відповідального чи призначеного. Тіло інциденту, заголовок і будь-яке інше поле ніколи не зберігаються поза межами відправлення. Єдині вихідні виклики — до assignment API RansomLeak і до PagerDuty REST API, обидва через TLS, і жодні дані користувача, окрім робочої пошти, не залишають ваш тенант.

Чи потрібен доступ лише на читання, чи на читання й запис, і чому?

На читання й запис. Застосунок використовує OAuth PagerDuty з єдиним дозволом write — саме його може запитувати застосунок із каталогу App Directory. Запис потрібен рівно для двох викликів: створити підписку Webhooks v3 під час підключення й опублікувати нотатку про проходження в інциденті. Єдине читання — робоча пошта відповідального, бо id інциденту приходить у самому підписаному вебхуку. Доступ також обмежений роллю в PagerDuty того, хто авторизує, тож підключайтеся як Admin або Account Owner. RansomLeak ніколи не створює, не редагує, не підтверджує й не закриває інциденти.

Чи записується проходження назад в інцидент?

Так. Коли призначений модуль завершено, RansomLeak публікує нотатку в первинному інциденті, називаючи модуль, користувача й дату, тож доказ лежить на стрічці інциденту. Нотатка використовує те саме підключення OAuth, і кожне проходження публікується щонайбільше один раз, тож повторна спроба ніколи не дублює нотатку.

Як видалити інтеграцію?

Відключення в RansomLeak видаляє підписку Webhooks v3 на боці PagerDuty й забуває збережені токени. Якщо ви відкликаєте застосунок у самому PagerDuty, RansomLeak виявляє це під час наступного оновлення токена й очищає локальне підключення автоматично.

Наступний посібник Перетворіть виявлення Datadog на навчання Та сама ідея для вашого моніторингу: виявлення стає призначеним уроком для причетних людей.

Потрібна допомога?

Напишіть нам на support@ransomleak.com — і ми допоможемо підключити PagerDuty до вашого тенанта.

Подивіться RansomLeak у дії

Спробуйте безкоштовні вправи або замовте демо, щоб побачити аналітику, експорт SCORM, SSO та індивідуальний контент у вашому середовищі.