Що таке ABAC і як доступ за атрибутами відрізняється від простого списку дозволів

Зачіпка

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

ABAC розшифровується як attribute-based access control, тобто контроль доступу на основі атрибутів.

Простий приклад

Уявімо внутрішню панель, де доступ до продакшн-налаштувань дозволено лише тоді, коли:

• користувач належить до команди platform;
• ресурс має мітку environment=production;
• запит іде з корпоративної мережі;
• дія відбувається в робочий час або після додаткового підтвердження.

Це і є ABAC: рішення формується не одним списком дозволених користувачів, а набором умов.

Чим ABAC відрізняється від allow-list

Allow-list відповідає на питання “кого ми впускаємо”. Це простий список дозволених людей, сервісів або IP-адрес.

ABAC відповідає на питання “за яких умов ми впускаємо”. Один і той самий користувач може отримати доступ у одному сценарії та бути заблокованим в іншому.

Це важливо, коли доступ має змінюватися залежно від контексту. Наприклад:

• один і той самий токен може бути допустимий для staging, але не для production;
• один і той самий співробітник може редагувати свій проєкт, але не чужий;
• один і той самий сервіс може читати дані лише для певного tenant.

Де це видно на практиці

ABAC часто з’являється там, де є:

• OIDC claims, які передають атрибути користувача або сесії;
• API authorization, де рішення залежить від ролі, tenant, scope або власника ресурсу;
• CI/CD, де доступ до секретів або деплой-операцій обмежують за середовищем і контекстом;
• внутрішні адмін-панелі, де правила враховують підрозділ, регіон або тип ресурсу.

Де тут RBAC

RBAC, тобто role-based access control, теж важливий. Але це інша модель.

• RBAC групує права в ролі.
• ABAC оцінює атрибути та умови.

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

Типові помилки

• Намагаються описати всі правила лише через allow-list.
• Додають забагато атрибутів, які ніхто не може підтримувати.
• Не перевіряють, що атрибути дійсно приходять із надійного джерела.
• Роблять політику такою складною, що її ніхто не ревʼює.
• Забувають про явний deny для критичних випадків.

Короткий чекліст

• Переконайтеся, що ви знаєте, які атрибути бере policy engine.
• Перевірте, чи рішення враховує користувача, ресурс і контекст.
• Подивіться, чи потрібен вам ABAC, а не простий allow-list або RBAC.
• Переконайтеся, що джерела атрибутів надійні та передбачувані.
• Зробіть кілька тестових сценаріїв для дозволу та відмови.

Підсумок

ABAC — це модель доступу, де рішення залежить від атрибутів, а не лише від списку дозволених імен. Вона корисна там, де доступ має змінюватися залежно від контексту, ресурсу та умов запиту.

Якщо коротко: allow-list питає “хто в списку?”, а ABAC питає “чи підходить цей запит зараз і за цих умов?”.