> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Службові облікові записи

> Створюйте службові облікові записи інтеграцій, яким належать API-ключі та OAuth-клієнти вашої організації, і керуйте ними.

Службовий обліковий запис — це іменована ідентичність для інтеграції. Йому належать API-ключі або
OAuth-клієнти, і він визначає дозволи, які можуть використовувати ці облікові дані, тому
перегляд доступу виконується на рівні облікового запису: що саме може робити інтеграція, видно
в одному місці, незалежно від того, скільки
облікових даних вона має. Сам обліковий запис не є обліковими даними: його ID
не можна використати для автентифікації запиту. Щоб вибрати метод, див. [Authentication](/uk/developers/v1/authentication);
інтеграції з API-ключем OAuth не потрібен.

Керуйте службовими обліковими записами на вкладці **Service accounts** у
[Developer Hub](/uk/developers/developer-hub/overview).

## Проєктуйте облікові записи відповідно до робочих навантажень

Створюйте один службовий обліковий запис на кожну інтеграцію або робоче навантаження — наприклад,
`reporting-pipeline`, `scim-sync` або `soc-enrichment` — замість одного
універсального облікового запису для всього. Облікові записи для окремих навантажень забезпечують
мінімальні дозволи, дають змогу зіставляти [журнали запитів](/uk/developers/developer-hub/request-logs)
з конкретною інтеграцією та дозволяють вимкнути одну інтеграцію, не зачіпаючи
інші.

## Створення службового облікового запису

<Steps>
  <Step title="Назвіть обліковий запис">
    Вкажіть назву облікового запису, що визначає робоче навантаження, яке він обслуговує, та опис
    його призначення. Обидва значення відображаються в списках і журналах, тому майбутні
    адміністратори зможуть розрізняти облікові записи.
  </Step>

  <Step title="Надайте дозволи">
    Виберіть дозволи, які обліковий запис може надавати своїм обліковим даним, — наприклад,
    `entity:read`, `simulation:read` або `reporting:read`. Цей набір є
    верхньою межею для всіх облікових даних, створених у межах облікового запису: облікові дані можуть мати підмножину
    цих дозволів, але не більше.

    <Tip>
      Надавайте мінімум, потрібний робочому навантаженню сьогодні. Дозволи облікового запису можна додати
      пізніше; наявні облікові дані зберігають надані їм області доступу.
    </Tip>
  </Step>

  <Step title="Перевірте та створіть">
    Підтвердьте назву та набір дозволів. Після створення на сторінці відомостей облікового запису можна [створити його API-ключі](/uk/developers/developer-hub/api-keys).
  </Step>
</Steps>

## Керування життєвим циклом

* **Редагуйте дозволи в будь-який час.** Вилучення дозволу з облікового запису
  вилучає його з тих можливостей, які можуть використовувати його API-ключі та маркери доступу OAuth.
* **Вимкніть обліковий запис**, щоб зупинити доступ до API через усі його облікові дані, — це корисно під час
  виведення інтеграції з експлуатації або під час стримування підозрюваного витоку облікових даних, доки
  триває розслідування. Повторне ввімкнення дозволяє знову автентифікуватися обліковим даним, які ще активні та
  не втратили чинності.
* **Видаліть обліковий запис**, коли інтеграцію виведено з експлуатації. Спершу зупиніть
  інтеграцію та відкличте її облікові дані. Видалення є безповоротним.

На сторінці відомостей кожного облікового запису показано, хто його створив, коли, і коли востаннє
використовувався один з його ключів, — це швидкий спосіб виявити занедбані інтеграції, які слід
вимкнути.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.