> Как устроена система доступа в компании (Go)

Короткий ответ

Система доступа строится на принципах least privilege и defense in depth. Обычно это комбинация RBAC или ABAC, централизованного identity provider, короткоживущих токенов и обязательного аудита. В Go-бэкенде доступ проверяется через middleware, а решения о правах кэшируются с учётом trade-off между latency и консистентностью. Секреты хранятся в vault, а не в коде или конфигах.

Пример по STAR

Ситуация: в предыдущей компании у нас был монолитный Go-сервис с доступом на основе ролей, прописанных в конфигурации. При росте команды и числа сервисов это стало узким местом, а аудит прав занимал дни. Задача: унифицировать систему доступа без остановки продукта.

Действие: я предложил вынести проверку прав в отдельный middleware и перейти на ABAC с политиками в централизованном сервисе авторизации. Мы ввели короткоживущие JWT, кэширование решений в Redis и обязательное логирование каждого отказа. Для миграции использовали feature flag и параллельную проверку старой и новой логики.

Результат: время добавления новой роли сократилось с недели до часа, аудит стал автоматическим, а количество инцидентов с избыточными правами упало до нуля. Это также упростило прохождение внешних security-аудитов.

Как отвечать на собеседовании

Сначала опишите архитектуру на высоком уровне: identity provider, сервис авторизации, middleware, хранилище политик. Затем объясните, как принимаются решения о доступе и где они кэшируются. Обязательно упомяните аудит, ротацию секретов и обработку отказов. Покажите, что понимаете trade-off между производительностью и строгостью проверок. Приведите конкретный пример из практики, где вы улучшили или спроектировали такую систему.

Что проверяет интервьюер

Интервьюер оценивает понимание принципов безопасности, умение проектировать распределённые системы и знание Go-специфики, например, работу с context и middleware. Также важно, как вы балансируете между безопасностью и удобством разработчиков. Проверяется навык объяснять сложные вещи простым языком и признавать ограничения выбранного подхода. Опыт миграции без даунтайма - сильный плюс.

Типичные ошибки

Перечисление только технологий без объяснения принципов. Игнорирование аудита и ротации секретов. Утверждение, что RBAC всегда достаточно. Отсутствие примеров из реальной практики. Неупоминание trade-off между latency и консистентностью при кэшировании прав. Слишком общие фразы без конкретики по Go и backend-архитектуре.