Как устроена система доступа в компании

Что проверяют

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

Как отвечать

Рассказывайте про свою компанию по уровням и без секретов:

• идентификация: единый провайдер учётных записей (Keycloak, корпоративный SSO по OIDC или SAML, за ним LDAP или Active Directory). Сервисы паролей не хранят, пользователь приходит с токеном;
• проверка в сервисе: HTTP-middleware или grpc.UnaryServerInterceptor проверяет подпись JWT по ключам из JWKS, срок exp и аудиторию aud, затем кладёт данные пользователя в context.Context, откуда их берут обработчики. Токены часто разбирают библиотекой github.com/golang-jwt/jwt/v5;
• права: роли (RBAC) или атрибуты (ABAC). Правила либо в коде, либо в движке политик: Casbin как библиотека или OPA отдельным сервисом;
• сервис к сервису: mTLS в сервис-меше или сервисные токены с минимальными правами, секреты в Vault;
• процесс: как сотрудник получает доступ (заявка, согласование), как доступ отзывают при увольнении, где хранится аудит.

Лучше всего работает конкретный эпизод: как вы добавляли роль, чинили баг с правами или переводили сервис с самописной проверки на общий провайдер. Детали и цифры нужны свои. Если систему проектировали не вы, честно скажите, что были её потребителем, и опишите, что видели изнутри и что сделали бы иначе.

Где спотыкаются

Пересказывают учебник про OAuth вместо своей системы. Вопрос про опыт, и абстрактный ответ читается как его отсутствие.

Смешивают аутентификацию и авторизацию: «у нас JWT, значит, доступ разграничен». Токен говорит, кто пришёл, а что ему можно, решает отдельная проверка.

Раскрывают лишнее: адреса внутренних систем, роли с правами администратора, известные обходы защиты. Интервьюер делает вывод, что так же вы расскажете и про его компанию.