White paper: Zanzibar: Google's Consistent, Global Authorization System

Разговор начинается с признания, которое участники повторяют несколько раз: пока приложение одно, авторизация проста, а сложность растёт вместе с числом команд и распределённостью системы. Илья проводит по эволюции моделей — от списков доступа и матрицы субъектов и объектов, которую неэффективно хранить целиком, к ролям и затем к атрибутам. Сергей Клименко, десять лет в Т-Банке и пять из них во главе направления аутентификации и авторизации, рассказывает, где ролевая модель сломалась в продукте для малого и среднего бизнеса: роли нужно было выдавать временно, например бухгалтеру на ограниченный срок, а типов ресурсов — организаций, заявок, групп компаний — оказалось слишком много для аккуратных ролей. Александр добавляет, что RBAC понятен менеджменту ровно до момента, когда нужна гранулярность, и тогда команда начинает дорисовывать к ролям списки доступа.

Атрибутная модель снимает связку «пользователь — роль», но приносит свою цену: политики пишут отдельные люди, когнитивная сложность растёт, аудит становится обязательным, потому что ошибка в политике роняет всю систему, а вычисление сложных политик замедляется. Дальше обсуждается архитектурный узел, из-за которого и появляются такие системы: как только монолит превращается в распределённую систему с фронтами и межсервисными вызовами, встаёт выбор между децентрализацией и централизацией. Децентрализация на токенах упирается в их размер и в невозможность быстро отозвать право; централизация в общей базе — плохой, но встречающийся паттерн. В итоге нужна единая точка, отвечающая на вопрос «могу ли я выполнить это действие», — и на этом рубеже возникает Zanzibar.

Модель Google описывается через кортежи «объект — отношение — субъект», где субъектом может быть и пользователь, и множество пользователей другого объекта. Из кортежей складывается граф, а проверка доступа превращается в поиск пути в нём. Участникам нравится компактность: грамматика отношений задана явно, кортежи читаются как текст, и вся статья умещается примерно в пятнадцать страниц. Илья показывает схему из SpiceDB — реализации от выходцев из Google: документ связан с организацией, право просмотра наследуется владельцами, читателями и администраторами организации, а схема и отношения хранятся отдельно, так что модель доступа меняется правкой схемы без перезаписи отношений — с оговоркой, что миграции при смене схемы всё равно придётся продумывать. Отдельно проговариваются пять целей статьи — корректность, гибкость, низкая задержка, высокая доступность и масштабируемость — и результат: медиана около трёх миллисекунд и двадцать на девяносто девятом перцентиле при нагрузке в миллионы проверок в секунду.

Самая спорная часть — проблема «нового врага»: если Алиса убрала Боба из папки, а затем в папку положили новый документ, Боб не должен его увидеть, но увидит, если проверка игнорирует порядок изменений. Google решает это снимками с меткой времени и zookie — токеном, который клиент получает при записи отношения и обязан присылать с последующими проверками. Даниил объясняет механику: сервер с протухшим кешем не ответит старыми данными, а пойдёт искать более свежий снимок на других узлах и в крайнем случае в хранилище — обращение к хранилищу увеличивает задержку по сравнению с чтением из кеша. Это осознанный выбор корректности в ущерб времени ответа, и Zanzibar позволяет применять его не ко всем пространствам, а только там, где цена ошибки высока. Александр напоминает критику: zookie приходится хранить на стороне клиента и обновлять согласованно с записью, поэтому говорят, что не Zanzibar встраивается в приложения, а приложения выстраиваются вокруг Zanzibar, отгружая в него данные об объектах и группах.

Дальше участники разбирают оптимизации. Индекс Leopard разворачивает глубокие вложенные группы в плоское представление, чтобы не обходить граф на каждый запрос; обновления в него приходят через Watch server, следящий за изменениями схем и отношений. Против длинного хвоста применяется хеджирование: запрос сначала уходит на один узел, и только если ответ не пришёл за порог вроде ста миллисекунд, дублируется на другие, а сам порог подстраивается по наблюдаемым хвостам. Стоимость каждого вызова измеряется в процессорных секундах, у клиентов есть глобальные лимиты и ограничения на число ожидающих запросов и одновременных чтений на объект, а таблица блокировок использует разные ключи для разных клиентов — Александр называет это встроенной мультитенантностью без эффекта шумного соседа, которого так не хватает системам, написанным в предположении, что все клиенты хорошие. Кеш есть на обеих сторонах, а таблица блокировок не даёт параллельно считать один и тот же тяжёлый запрос; Илья вспоминает похожую прослойку, о которой рассказывал Twitter.

Открытым остаётся вопрос списков: когда нужно показать сто объектов с пятью правами каждый, наивная схема даёт пятьсот проверок, а на сотнях тысяч объектов поиск с учётом прав становится отдельной задачей — участники упоминают пакетные проверки в планах SpiceDB и индекс, который сообщество называет Tiger. Финал — про собственные планы Т-Банка. Сергей объясняет, почему команда ушла от Open Policy Agent: свой язык политик требует времени на освоение, а данные в сайдкаре не помещаются, когда клиентов миллионы; и почему не осталась на ролях — гранулярность требований только растёт. Новую систему авторизации решено строить на SpiceDB, написанной на Go, с пониманием, что дорабатывать напильником и тюнить пространства придётся. Александр подводит итог: белые книги Google задают концепции, вокруг которых потом вырастает открытый инструментарий, и следить за этим — способ не собирать все грабли самостоятельно.