Мы часто сталкиваемся с ситуацией, когда RBAC трещит по швам. В одном проекте после внедрения RBAC мы получили 47 запросов на изменение ролей за месяц — каждое требовало согласования. ABAC сократил это до 2 запросов. Появляются правила вроде «пользователь может редактировать документ, если он его автор, документ находится в статусе draft, и пользователь работает в той же организации, что и документ». Роль тут не поможет — нужен контекст. ABAC (Attribute-Based Access Control) принимает решение на основе атрибутов субъекта (пользователя), объекта (ресурса) и среды (время, IP, контекст запроса). Наш опыт показывает, что гибрид RBAC+ABAC даёт оптимальный баланс производительности и гибкости. Мы гарантируем прозрачность решений с помощью детального аудита.
Как устроена модель
Четыре сущности в ABAC:
- Subject — пользователь и его атрибуты: role, department, clearance_level, org_id.
- Resource — объект и его атрибуты: owner_id, status, org_id, classification, region.
- Action — read, write, delete, approve.
- Environment — time_of_day, ip_address, request_method.
Политика — это предикат над этими атрибутами. Например:
ALLOW IF
subject.org_id == resource.org_id
AND (subject.role == 'editor' OR subject.id == resource.owner_id)
AND resource.status IN ('draft', 'review')
AND action == 'write'
Почему ABAC лучше RBAC?
RBAC прост и быстр, но не масштабируется для сложных правил. ABAC позволяет выразить практически любое бизнес-ограничение: «менеджер может одобрить заявку, если сумма < 10000 и заявка создана в его отделе». В RBAC пришлось бы вводить новую роль. ABAC решает это декларативно. Сравним ключевые параметры:
| Критерий | RBAC | ABAC |
|---|---|---|
| Гибкость | Низкая (роли фиксированы) | Высокая (атрибуты) |
| Поддержка контекста | Нет | Да |
| Производительность | Высокая | Средняя (при большом числе политик) |
| Сложность внедрения | Низкая | Средняя |
Схема хранения политик
Можно хранить политики в коде (подходит для небольшого числа правил) или в базе с DSL. Вот вариант с хранением в PostgreSQL в виде JSON-условий:
CREATE TABLE abac_policies (
id SERIAL PRIMARY KEY,
name VARCHAR(128) NOT NULL,
description TEXT,
effect VARCHAR(8) NOT NULL CHECK (effect IN ('allow', 'deny')),
priority INT NOT NULL DEFAULT 0,
conditions JSONB NOT NULL, -- дерево условий
actions TEXT[] NOT NULL,
resources TEXT[] NOT NULL -- glob: 'documents', 'documents/*'
);
-- Пример записи
INSERT INTO abac_policies (name, effect, priority, conditions, actions, resources)
VALUES (
'editors_can_write_own_draft',
'allow',
10,
'{
"operator": "AND",
"conditions": [
{"attribute": "subject.role", "op": "in", "value": ["editor", "senior_editor"]},
{"attribute": "subject.org_id", "op": "eq", "value": {"ref": "resource.org_id"}},
{"attribute": "resource.status", "op": "in", "value": ["draft", "review"]}
]
}',
ARRAY['write', 'delete'],
ARRAY['documents', 'documents/*']
);
Движок принятия решений
class ABACEngine {
constructor(policies) {
// Политики предзагружены и отсортированы по приоритету (deny > allow при конфликте)
this.policies = policies.sort((a, b) => {
if (a.effect === 'deny' && b.effect !== 'deny') return -1;
return b.priority - a.priority;
});
}
evaluate(subject, resource, action, environment = {}) {
const context = { subject, resource, action, environment };
for (const policy of this.policies) {
if (!policy.actions.includes(action)) continue;
if (!this.matchesResource(policy.resources, resource.type)) continue;
if (this.evaluateCondition(policy.conditions, context)) {
return policy.effect === 'allow';
}
}
return false; // default deny
}
evaluateCondition(condition, ctx) {
if (condition.operator === 'AND') {
return condition.conditions.every(c => this.evaluateCondition(c, ctx));
}
if (condition.operator === 'OR') {
return condition.conditions.some(c => this.evaluateCondition(c, ctx));
}
if (condition.operator === 'NOT') {
return !this.evaluateCondition(condition.condition, ctx);
}
// Листовой узел
const leftVal = this.resolveAttribute(condition.attribute, ctx);
const rightVal = condition.value?.ref
? this.resolveAttribute(condition.value.ref, ctx)
: condition.value;
switch (condition.op) {
case 'eq': return leftVal === rightVal;
case 'neq': return leftVal !== rightVal;
case 'in': return Array.isArray(rightVal) && rightVal.includes(leftVal);
case 'gte': return leftVal >= rightVal;
case 'lte': return leftVal <= rightVal;
case 'contains': return Array.isArray(leftVal) && leftVal.includes(rightVal);
default: return false;
}
}
resolveAttribute(path, ctx) {
// 'subject.org_id' → ctx.subject.org_id
return path.split('.').reduce((obj, key) => obj?.[key], ctx);
}
matchesResource(patterns, resourceType) {
return patterns.some(p =>
p === resourceType || (p.endsWith('/*') && resourceType.startsWith(p.slice(0, -2)))
);
}
}
Как интегрировать ABAC в Express?
const engine = new ABACEngine(await loadPoliciesFromDB());
// Перезагрузка политик при изменении (без рестарта сервера)
db.on('policy_changed', async () => {
engine.updatePolicies(await loadPoliciesFromDB());
});
function abac(action) {
return async (req, res, next) => {
const resource = await loadResource(req); // загружаем объект со всеми атрибутами
const allowed = engine.evaluate(
req.user, // subject
resource, // resource
action, // action
{ // environment
ip: req.ip,
timestamp: Date.now(),
userAgent: req.headers['user-agent'],
}
);
if (!allowed) {
return res.status(403).json({ error: 'Forbidden' });
}
req.resource = resource;
next();
};
}
router.put('/documents/:id', authenticate, abac('write'), updateDocument);
router.delete('/documents/:id', authenticate, abac('delete'), deleteDocument);
Audit log
ABAC без аудита — слепой инструмент. Каждое решение движка логируется:
CREATE TABLE abac_audit_log (
id BIGSERIAL PRIMARY KEY,
ts TIMESTAMPTZ NOT NULL DEFAULT now(),
subject_id INT NOT NULL,
resource_type VARCHAR(128),
resource_id VARCHAR(128),
action VARCHAR(64) NOT NULL,
decision BOOLEAN NOT NULL,
matched_policy_id INT REFERENCES abac_policies(id),
context_snapshot JSONB -- snapshot subject+resource attrs на момент решения
);
CREATE INDEX idx_abac_audit_subject ON abac_audit_log (subject_id, ts DESC);
CREATE INDEX idx_abac_audit_resource ON abac_audit_log (resource_type, resource_id, ts DESC);
Это даёт ответ на вопрос «почему пользователь X не смог сделать Y с объектом Z три дня назад» — без него расследование инцидентов превращается в гадание.
Комбинирование с RBAC
Чистый ABAC медленнее RBAC при большом числе политик — каждая проверка проходит через все правила. На практике используют гибрид: RBAC как первый слой (быстрая грубая проверка по роли), ABAC как второй (тонкие контекстуальные правила только там, где нужно).
async function authorize(user, resource, action) {
// Быстрый RBAC-check: есть ли у роли хоть какой-то доступ к этому типу ресурса?
if (!await rbac.canAccessResourceType(user.role, resource.type)) {
return false; // отсекаем без загрузки объекта и прохода по ABAC-политикам
}
// Тонкая проверка через ABAC
return engine.evaluate(user, resource, action);
}
Как оценить сложность проекта?
Сроки зависят от объёма политик и архитектуры. Мы выделяем три варианта:
| Вариант | Срок | Что входит |
|---|---|---|
| Базовый | 3–4 дня | Движок в коде, 5–10 политик, тесты |
| Расширенный | 7–10 дней | Политики в БД, REST API, UI для редактирования, аудит |
| Интеграция с OPA | 2–3 дня | Sidecar-развёртывание, написание политик на Rego, тестирование |
Что входит в работу по внедрению ABAC?
- Анализ модели доступа и атрибутов пользователей, ресурсов, окружения.
- Проектирование и документирование политик доступа.
- Разработка движка принятия решений (или интеграция с OPA/Casbin).
- Реализация REST API для управления политиками.
- Создание системы аудита с визуализацией логов.
- Покрытие тестами (unit + integration).
- Деплой и настройка мониторинга.
- Обучение команды: как писать и отлаживать политики.
- Гарантия на код и поддержка после внедрения.
Базовый движок с хранением политик в коде — 3–4 дня. Движок с хранением политик в базе и UI для их редактирования — 7–10 дней. Добавление audit log с UI — ещё 2–3 дня. Интеграция со сторонней PDP (Open Policy Agent, Casbin) вместо самописного движка — 2–3 дня на интеграцию плюс время на написание политик на Rego или PERM.
Open Policy Agent — зрелая альтернатива самописному движку. Политики пишутся на Rego, OPA запускается как sidecar или как отдельный сервис, приложение обращается к нему через HTTP или gRPC. Это добавляет операционную сложность, но даёт версионирование политик, горячую перезагрузку и встроенный аудит.
Если у вас сложные требования к доступу — обратитесь к нам за аудитом. Оценим ваш проект бесплатно. Свяжитесь с нами, чтобы обсудить детали. Закажите реализацию ABAC под ключ.