Библиотеки Go для RBAC и прав доступа в B2B-продуктах

Почему права доступа быстро превращаются в хаос

Логика прав редко ломается сразу. Она расползается понемногу. Одна проверка появляется в HTTP-обработчике, другая — в фоновой задаче, а третья оказывается в интерфейсе, чтобы скрыть кнопку.

Сначала это кажется нормальным. B2B-продукт может начинаться с двух простых правил: админы могут всё, участники — меньше. Потом первый крупный клиент просит менеджера по продажам, который может видеть все сделки, но редактировать только сделки в одном регионе. Финансовому руководителю нужно одобрять возвраты, но не менять настройки биллинга. Владелец аккаунта может приглашать пользователей, но не видеть журналы аудита.

Теперь старой проверки if user.IsAdmin() уже недостаточно.

Хаос растет потому, что каждая часть продукта отвечает на один и тот же вопрос по-своему. API проверяет одно правило. Интерфейс предполагает другое. Плановая задача запускается с широким доступом, потому что никто не хочет, чтобы она упала в два часа ночи. Вскоре в системе появляется несколько версий одной и той же правды.

Это дорого обходится, пусть и по-скучному болезненно:

• пользователи видят кнопки, которыми не могут воспользоваться
• в поддержку приходят тикеты про «пропавший» доступ
• инженеры чинят крайние случаи в случайных файлах
• одно поспешное исключение создает дыру в безопасности

Жестко зашитые проверки ролей тоже быстро устаревают в B2B SaaS. Корпоративным клиентам почти всегда нужны исключения. Им нужны кастомные роли, области доступа команд, временный доступ и правила, зависящие от аккаунта, проекта, региона или тарифа. Если правила живут внутри обработчиков, каждая новая сделка превращается в изменение кода.

Обычно именно в этот момент команды начинают искать библиотеки Go для RBAC и прав доступа. Библиотека важна, но большая проблема — это дрейф. Если у команды нет одной понятной модели, одно и то же правило снова и снова появляется в новых местах, но уже с небольшими отличиями.

Хорошая настройка дает всем одну и ту же карту. Продукт может называть роли понятно. Инженеры могут проверять права одинаково в API, задачах и сервисах. Поддержка может объяснять доступ без догадок. Такая согласованность предотвращает множество мелких ошибок еще до того, как они станут проблемами для клиентов.

Начните с модели доступа

Большинство проблем с правами начинается еще до выбора библиотеки. Они начинаются тогда, когда продуктовая команда говорит: «admin, member, viewer» — и считает вопрос закрытым. Это работает какое-то время, а потом кто-то просит маленькое исключение, и правила начинают протекать в обработчики, фоновые задачи и скрипты поддержки.

Чистые роли хорошо подходят, когда люди с одной ролью могут делать почти одно и то же везде. Небольшой B2B-продукт с тремя ролями и одним общим рабочим пространством вполне может жить с таким подходом. Его легко объяснить клиентам и просто анализировать поддержке.

Разрешения, привязанные к действиям, лучше подходят, когда в продукте больше нескольких чувствительных операций. Думайте о действиях вроде просмотра счетов, одобрения выплат, экспорта данных, управления API-ключами или приглашения пользователей. В такой модели роли по-прежнему существуют, но роли — это просто наборы разрешений. Настроек нужно чуть больше, зато по мере роста продукта все обычно остается чище.

Область доступа важна не меньше самой роли. Во многих схемах прав для B2B SaaS одному и тому же человеку нужен разный доступ на разных уровнях:

• область аккаунта — для биллинга, SSO и общих настроек компании
• область рабочего пространства — для проектов, данных и приглашения участников
• область команды — для ежедневной работы внутри небольшой группы

Если пропустить область доступа, правила быстро начинают вести себя странно. Пользователю может понадобиться редактировать записи в одном рабочем пространстве, просматривать другое и управлять биллингом всего аккаунта. Одна плоская роль не умеет выразить это нормально.

Временный доступ — это место, где простой RBAC начинает трещать. Финансовому руководителю может понадобиться право экспорта на одну неделю. Подрядчику — доступ только к одному клиентскому рабочему пространству и ни к чему больше. Инженеру поддержки — ограниченный по времени доступ, чтобы разобраться с проблемой. Если такие случаи важны, лучше добавлять выдачи прав с областью и сроком действия, а не создавать еще одну постоянную роль.

Простое правило работает хорошо: выбирайте минимальную модель, которая покрывает текущий продукт и несколько очевидных исключений на ближайшее время. Если трех ролей и одной области хватает почти для всех случаев — оставьте всё простым. Если вы уже говорите «кроме этой команды» или «кроме периода онбординга», переходите на права плюс область доступа, пока правила не расползлись.

Чем обычно отличаются Go-библиотеки

Большинство библиотек прав доступа для Go решают одну и ту же задачу тремя очень разными способами. Они либо используют фиксированные роли, либо именованные разрешения, либо policy-правила, которые приложение оценивает во время выполнения.

Первая группа — самая простая для чтения. Вы определяете роли вроде admin, manager или viewer как enum'ы или константы, а затем проверяете их в коде. Это хорошо работает, когда у каждой роли есть ясный смысл и у продукта всего несколько планов, команд или типов аккаунтов.

Карты разрешений находятся посередине. Вместо вопроса «это админ?» код спрашивает: «может ли этот пользователь редактировать счета?» или «может ли он приглашать коллег?» Это дает больше контроля и обычно лучше переживает рост, когда продажи, поддержка и корпоративные клиенты начинают просить исключения.

Policy-движки идут дальше. Они оценивают правила вроде роли пользователя, команды, владельца ресурса, статуса аккаунта или настроек тенанта в одном месте. Они могут избавить от жестко зашитых проверок, но при этом добавляют больше движущихся частей, больше настройки и больше шансов, что правило будет выглядеть правильным, а работать неправильно.

Грубое сравнение такое:

• Enum-ролям быстро начать и легко следовать, но они быстро становятся жесткими.
• Карты разрешений дают более чистые проверки на уровне обработчика или сервиса, но кому-то все равно нужно поддерживать соответствие.
• Policy-движки лучше справляются со сложными правами в B2B SaaS, особенно с правилами на уровне клиента, но требуют более строгой дисциплины в тестировании.

Где живут правила

Некоторые библиотеки хранят правила в Go-коде. Это самый удобный вариант для контроля версий, ревью кода и рефакторинга. Минус в том, что любое изменение правила требует выката.

Другие варианты хранят правила в конфигурационных файлах или в базе данных. Это полезно, когда операциям или поддержке нужно менять доступ, не дожидаясь релиза. Но появляется новая проблема: теперь нужны история изменений, безопасные значения по умолчанию и понятный способ откатить плохое правило.

Смешанная модель в B2B-продуктах встречается часто. Базовые правила остаются в коде, а клиентские исключения живут в данных. Такой раздел полезен, но только если команда договорилась, какой слой за что отвечает.

Тестирование и отладка

Тестирование сильно меняется в зависимости от подхода. Роли-энумы легко проверять несколькими table-driven-кейсами. Карты разрешений требуют более широкого покрытия, потому что одно новое право может повлиять на несколько страниц, фоновых задач и API-маршрутов.

Policy-движки требуют больше всего внимания. Нужны тесты на приоритет правил, на поведение allow и deny, а также на крайние случаи вроде заблокированных пользователей или доступа между разными тенантами. Отладка тоже усложняется. Когда пользователя блокируют, команде нужно видеть, какое правило сработало, какие входные данные совпали и почему deny победил allow.

Если команда не может объяснить неудачную проверку прав за минуту-другую, библиотека, скорее всего, слишком умная для текущего этапа продукта.

Простой пример для B2B

Представьте B2B-приложение с множеством клиентских рабочих пространств. У одной компании есть команды продаж, финансов и поддержки, и каждая работает в своем пространстве. Такая схема выглядит простой, пока кто-то не спросит, кто может приглашать пользователей, кто может экспортировать данные и кто может видеть счета.

Хорошая отправная точка — пять ролей:

• Owner управляет всем аккаунтом и может делать редкие вещи вроде передачи владения.
• Admin управляет людьми и настройками на уровне аккаунта.
• Manager руководит одной командой или одним рабочим пространством.
• Member выполняет повседневную работу в назначенных областях.
• Billing занимается тарифами, счетами и платежными данными.

Теперь свяжите действия с этими ролями. Owner может приглашать пользователей, экспортировать данные, менять настройки аккаунта и смотреть счета. Admin обычно тоже может приглашать пользователей и менять большинство настроек, но вы можете запретить ему передачу владения или обновление платежных методов. Manager может приглашать людей в свое рабочее пространство и экспортировать из него данные, но не должен трогать корпоративный биллинг. Member может работать с записями, которыми владеет он сам, или с записями, которые разделяет его команда, но не должен менять настройки аккаунта. Роль Billing может смотреть счета и обновлять платежные данные, но не должна читать данные клиентов.

Область доступа меняет ответ

Одно и то же действие может быть разрешено в одном месте и запрещено в другом. Менеджер может экспортировать лиды из sales workspace и провалить ту же проверку в finance workspace. Это значит, что ваше правило — это не просто роль плюс действие. Это роль, действие и область доступа.

В паттернах авторизации Go это часто превращается в проверки вроде: может ли пользователь менять настройки для этого рабочего пространства или для всего аккаунта? «Изменять настройки рабочего пространства» и «изменять настройки аккаунта» звучат похоже, но это должны быть разные разрешения. «Просмотр счетов» обычно относится к области аккаунта, а «приглашение пользователя» может относиться либо к аккаунту, либо к рабочему пространству — в зависимости от продукта.

Одно исключение — временный доступ для поддержки. Допустим, клиент открыл тикет, потому что отчеты выглядят неправильно. Вы можете выдать инженеру поддержки доступ только на чтение к одному рабочему пространству на два часа. Этот доступ должен завершиться сам, а также блокировать экспорт, биллинг и управление участниками.

Этот небольшой пример показывает, почему проверки прав в Go превращаются в хаос, когда команды пропускают этап модели. Если ваша библиотека умеет ответить на вопрос «кто может что сделать, где и как долго» без дополнительных if-ов в каждом обработчике, модель, скорее всего, удачная.

Выберите рабочий процесс команды, который выдержит рост

Большинство проблем с правами начинается как проблема названий. Если продукт говорит «workspace admin», API говорит «owner», а поддержка говорит «manager», люди будут принимать неверные решения. То же самое относится и к действиям. Выберите одно имя для каждого действия и используйте его везде — от текста в интерфейсе до кода policy.

В Go RBAC и библиотеках прав доступа сложность обычно не в самой проверке. Сложность в том, чтобы продукт, поддержка и инженерная команда использовали одни и те же слова. Скучная общая таблица прав убирает больше путаницы, чем еще одна helper-функция.

Сделайте правила читаемыми

Храните одну таблицу на простом языке, которую сможет прочитать любой член команды. Менеджеры продукта должны уметь проверять ее без открытия кода, а поддержка — отвечать по ней на вопросы клиентов.

Обычно в простой таблице хватает нескольких колонок:

• название роли
• название действия
• область, например, свои записи, команда или все аккаунты
• разрешено или запрещено
• примечания про ограничения тарифа или особые случаи

Эта таблица должна отвечать на реальные вопросы в одной строке. Например: «Billing admin может экспортировать счета своей команды, но не может менять подписку». Если PM хочет изменить это правило, он сначала правит таблицу. Потом инженеры обновляют тесты и policy-код, чтобы они совпадали.

Команде поддержки это помогает сразу. Когда клиент спрашивает: «Почему этот пользователь может приглашать коллег, но не может удалить проект?», поддержке не нужен разработчик, чтобы это объяснить. Нужно посмотреть на роль, действие и область доступа, а потом ответить понятной причиной.

Держите исключения на коротком поводке

Изменения ролей и разовые исключения должны иметь владельцев. Если править роли может кто угодно, логика доступа быстро расползается.

Задайте простой путь согласования:

• продукт определяет новые роли и действия
• инженерная команда переносит их в код и тесты
• ограниченная группа администраторов может утверждать исключения
• у каждого исключения есть владелец и дата окончания

Временный доступ должен оставаться временным. Если продажам или поддержке нужен особый случай, запишите, кто его утвердил и когда он истекает. Иначе «только для этого клиента» превращается в постоянное поведение, а потом в поддержку сыпятся тикеты.

Небольшие команды хорошо чувствуют себя с таким подходом, потому что он убирает гадание. Одно название роли, одно название действия, одна таблица, один путь согласования. Обычно этого хватает, чтобы правила доступа не расползались по случайным обработчикам и побочным проверкам.

Как добавлять проверки, не распыляя их по коду

Логика прав становится хаотичной, когда каждый обработчик сам принимает решение. Один маршрут проверяет название роли, другой — флаг аккаунта, а третий вообще забывает про правило. Если вы сравниваете библиотеки Go для RBAC и прав доступа, этот момент важнее, чем API самой библиотеки.

Сначала назовите объекты, с которыми работают люди. В B2B-продукте это обычно ресурсы вроде счетов, рабочих пространств, участников или отчетов. Затем назовите действия: просмотр, редактирование, экспорт или удаление. И в конце задайте область: собственная запись, команда, компания или все клиенты — для внутреннего персонала.

Соберите эти правила в одну матрицу прав до того, как писать код. Простая таблица часто рано ловит неверные предположения. Вы можете обнаружить, что «manager» может редактировать счета в одной команде, но не должен экспортировать все счета компании. Исправить это в матрице гораздо проще, чем после того, как правила расползутся по двадцати обработчикам.

Когда матрица понятна, добавьте один слой авторизации рядом с бизнес-логикой. Держите обработчики тонкими. Пусть они парсят запрос, загружают пользователя и вызывают что-то вроде auth-сервиса или policy-проверки. Этот слой должен отвечать на один вопрос: «Может ли этот пользователь выполнить это действие над этим ресурсом в этой области?» Когда каждый endpoint спрашивает один и тот же слой, правила остаются в одном месте.

Тесты должны покрывать и разрешенные, и запрещенные случаи для каждой роли. Команды часто проверяют счастливый путь и пропускают отказы, а потом именно поддержка первой находит дыры. Небольшой набор table tests приносит большую пользу, потому что ошибки в правах обычно скучные и предсказуемые.

Когда вы запрещаете действие, логируйте достаточно деталей, чтобы потом это можно было объяснить. Добавьте:

• ID пользователя или аккаунта
• использованную роль или policy
• ресурс и действие
• область или контекст тенанта
• причину отказа

Этот лог реально экономит время, когда клиент спрашивает, почему один менеджер может архивировать проект, а другой — нет. Он также делает изменения в policy безопаснее, потому что видно, какие правила люди реально затрагивают.

Ошибки, из-за которых появляются тикеты в поддержку

Многие команды обвиняют свои библиотеки Go для RBAC и прав доступа, когда поддержка начинает задыхаться от тикетов, но библиотека редко бывает настоящей причиной. Проблемы начинаются, когда бизнес-правила смешиваются с правилами авторизации. «Можно редактировать счета» — это правило доступа. «Можно редактировать счета только до их блокировки и только для своего региона» — это уже смесь доступа и продуктовой логики, и обычно она прячется в одном обработчике.

Названия ролей тоже доставляют много боли. Команды часто создают роли вроде «sales», «finance» или «ops», потому что эти названия кажутся знакомыми. Через год у каждой команды уже по шесть разных задач, и роль перестает что-либо значить. Роли лучше работают, когда они отражают действия, которые нужны людям, например просмотр отчетов, одобрение возвратов или управление биллингом.

Особые случаи часто прячутся в странных местах. Веб-обработчик блокирует действие, но импорт-скрипт все равно запускает его. Cron-задача отправляет отчеты пользователям, которые потеряли доступ на прошлой неделе. Админ-инструмент пропускает ту же проверку, потому что «им пользуется только staff». Пользователям не важно, какой путь создал ошибку. Они просто видят данные, которых не должны видеть, или не могут сделать работу, которую им разрешено делать.

Фоновые процессы должны использовать ту же модель прав, что и основное приложение. Импорт, экспорт, sync-задачи, консоли поддержки и внутренние скрипты часто находятся вне обычного потока запросов. Именно там появляются одни из самых неприятных тикетов, потому что баг выглядит случайным. Один клиент может обновить аккаунт через дашборд, но не через CSV-импорт. Другой теряет доступ в интерфейсе, но продолжает получать запланированные письма с ограниченными данными.

Журналы аудита не менее важны. Рано или поздно кто-то спросит: «Кто изменил эту роль?» Если вы не логируете изменения ролей, поддержке остается только гадать. Безопасности — тоже. Записывайте, кто изменил доступ, что именно изменилось, когда это произошло и к какому аккаунту это относилось.

Лучшее решение — держать проверки прав в одном месте и вызывать этот код из обработчиков, задач, импортов и админ-инструментов. Звучит скучно, и это как раз хорошо. Oleg Sotnikov часто направляет команды к такой схеме в работе Fractional CTO, потому что она убирает странные баги с правами еще до того, как на них наткнутся клиенты.

Как выглядит реальная система прав

Большинство прав в B2B SaaS ломаются, когда команды полагаются только на широкие роли. Роль помогает пройти часть пути, но настоящим продуктам нужны еще действие, ресурс, область и иногда срок действия.

Какие бы паттерны авторизации Go вы ни выбрали, каждое правило должно отвечать на один и тот же вопрос: кто может что сделать, с какой записью, в каком аккаунте и как долго.

Практическая модель

Многие команды держат каждое право простым и явным:

• subject: пользователь или команда
• action: view, edit, invite, download
• resource: сделка, счет, billing, HR-заметка
• scope: workspace, account, project, record
• expires_at: необязательное время окончания

Такая модель хорошо выдерживает рост продукта.

Представьте одно клиентское рабочее пространство с четырьмя людьми. Менеджер по продажам может редактировать сделки, потому что это часть его работы. Он может менять стадию, сумму, владельца или заметки по сделке. Но он все равно не может открыть настройки биллинга или обновить способы оплаты, потому что денежные настройки должны жить в другом месте.

Пользователю из финансов нужен другой набор прав. Он может смотреть и скачивать счета, но только по одному аккаунту. Если у той же компании пять аккаунтов, этот пользователь не должен по умолчанию перемещаться между ними всеми. Область доступа важна не меньше действия.

Workspace admin часто управляет доступом, а не приватными данными. Он может приглашать пользователей, удалять пользователей и менять места или роли в команде. Но это не значит, что он может читать HR-заметки, комментарии о зарплате или внутренние записи о сотрудниках. Если в приложении есть чувствительные поля, относитесь к ним как к отдельному ресурсу с отдельными правилами.

Доступ для поддержки должен оставаться временным. Во время инцидента сотруднику поддержки может понадобиться доступ на чтение к одному аккаунту, нескольким настройкам и журналам аудита на два часа. После этого доступ должен закончиться сам. Ручная очистка кажется нормальной, пока кто-то не забудет.

Именно здесь проверки прав в Go остаются читаемыми. Вместо набора собственных if-ов по всем обработчикам приложение перед каждым чувствительным действием задает один и тот же вопрос. Команды быстрее отлаживают, аудит становится понятнее, а тикетов в поддержку меньше, потому что пользователи видят одно и то же правило везде.

Быстрая проверка перед релизом

Ошибки в правах редко выглядят драматично. Чаще один клиент не может открыть страницу, один менеджер редактирует не ту запись, или у поддержки нет ясного ответа, когда доступ не проходит.

Если вы используете библиотеки Go для RBAC и прав доступа, делайте короткую проверку перед каждым релизом. Это экономит много времени на чистке позже.

• Новый разработчик должен найти весь набор правил в одном месте. Если правила доступа живут в обработчиках, middleware, шаблонах и случайных методах сервисов, результату никто не доверяет.
• Поддержка должна видеть, почему проверка провалилась. Одного слова «Denied» недостаточно. Нужна понятная причина, например отсутствие роли в workspace, неверный аккаунт или несоответствие владельца объекта.
• Вы должны добавлять новую роль, не трогая десять обработчиков. Если каждая новая роль означает копипасту по всему коду, модель уже слишком разъехалась.
• Тесты должны покрывать каждую область доступа, которую вы продаете клиентам. В B2B SaaS permissions это обычно означает область аккаунта, рабочего пространства и объекта.
• В логах должно быть видно, кто изменил роли, что изменилось и когда. Без этого следа ошибки в ролях превращаются в длинные Slack-треды и догадки.

Один небольшой тест многое показывает: попросите коллегу, который не строил систему прав, ответить на простой вопрос поддержки. Например: «Почему Dana видит список счетов, но не может экспортировать один счет из Workspace B?» Если он не может проследить ответ за несколько минут, в системе все еще есть слепые зоны.

Здесь же многие команды понимают, что policy-проверки и журналы аудита должны быть вместе. Чистый rule engine помогает разработчикам принимать решения о доступе. Чистый audit trail помогает людям объяснять их задним числом. Нужны оба, прежде чем клиенты начнут тестировать систему за вас.

Что делать дальше

Выберите одну модель доступа уже сейчас, даже если она кажется немного простой. Простая модель с несколькими шероховатостями лучше, чем смесь ролей, флагов и разовых исключений. Именно из-за этого многие библиотеки Go для RBAC и прав доступа начинают казаться сложнее, чем должны.

Опишите модель простыми словами. Сделайте ее короткой. Объясните, кто что может делать, где живет каждое правило и кто может утвердить изменение. Если поддержка не может объяснить право клиенту за минуту, модель уже слишком сложная.

Затем проведите короткий разбор с теми, кто будет жить с этой системой каждый день:

• инженерная команда проверяет, где срабатывает правило и как сохранить一致ность
• продуктовая команда проверяет, соответствует ли правило тому плану, который реально покупают клиенты
• поддержка проверяет странные случаи, которые обычно превращаются в тикеты

Этой встречи не нужны слайды или длинное ТЗ. Общего документа и нескольких реальных примеров клиентов вполне достаточно. Например, задайте один простой вопрос: может ли менеджер редактировать биллинг, приглашать пользователей и видеть данные другой команды, или только часть этого? Если в комнате звучат три разных ответа, сначала поправьте формулировку, а уже потом трогайте код.

Не мигрируйте все проверки прав сразу. Начните с самых шумных: блокировки онбординга, операции с биллингом, админский доступ и данные, которые пересекают границы команд. Перенесите эти проверки в один понятный путь. После этого остальное пойдет легче, потому что у команды появится шаблон, который можно копировать.

Если в вашем продукте уже есть проверки, размазанные по обработчикам, middleware и SQL-фильтрам, сторонний взгляд может сэкономить недели чистки позже. Oleg Sotnikov разбирает роли, границы сервисов и рабочий процесс команды для стартапов и малого бизнеса до того, как модель затвердеет. Обычно полезный результат довольно простой: меньше неожиданных правил, меньше тикетов в поддержку и модель доступа, которую вся команда объясняет одинаково.