Что было технически под капотом в проекте системы доступа
Что проверяют
Строили вы систему доступа сами или видели её со стороны. Ждут не список технологий, а решения: где хранятся права, в какой точке они проверяются, что происходит в момент отзыва доступа и как это не превращается в тормоза на каждом запросе.
Как отвечать
Разложить рассказ слоями и на каждом называть конкретный выбор и его причину.
- Аутентификация: чем подтверждается личность, как выдаются и проверяются токены, срок жизни доступа и обновления, где живёт сессия.
- Модель прав: роли, списки доступа на конкретный объект или атрибутные правила. Стоит сказать, почему выбрали эту модель: роли просты, пока не появляется «доступ только к своему отделу».
- Точка проверки: зависимость на роут в FastAPI или класс разрешений в DRF, плюс обязательная фильтрация на уровне запроса к базе. Проверка прав в цикле по списку объектов даёт лишние запросы, поэтому ограничение вкладывают в сам запрос.
- Хранение и кэш: таблицы пользователей, ролей и связей, кэш прав и, главное, его инвалидация при отзыве роли.
- Аудит: журнал действий и отказов, по нему потом разбирают инциденты.
Где спотыкаются
Говорят «пароли шифруем». Пароли хэшируют, и именно необратимость тут главное свойство: bcrypt и argon2 это медленные хэши с солью, расшифровать их нельзя ни с каким ключом. Оговорка мелкая на слух, но для собеседования по безопасности она заметная.
Второе: называют OAuth2 способом аутентификации. OAuth2 это протокол делегирования доступа, личность пользователя поверх него описывает OIDC. Рядом обычно всплывает JWT без ответа на вопрос про отзыв: подписанный токен нельзя отменить до истечения срока, нужен короткий срок жизни плюс список отозванных или проверка версии сессии.
Третье: считают, что ORM сам защищает от инъекций, и тут же собирают фрагмент запроса из строки. Защищает параметризация, а не ORM, и любой сырой кусок с подстановкой значения возвращает проблему на место.