Безопасность и контроль доступа
Безопасность, которую аналитик обязан описать — гранты OAuth2, структура JWT и отзыв, mTLS, TLS/HTTPS, симметричное и асимметричное шифрование, хеширование, цифровая подпись и токен-авторизация между микросервисами.
14 вопросов
JuniorТеорияОчень частоЧто такое хеширование, чем оно отличается от шифрования и зачем паролю соль?
Что такое хеширование, чем оно отличается от шифрования и зачем паролю соль?
Хеширование одностороннее — обратно дайджест не развернуть. Шифрование двустороннее — ключ восстанавливает открытый текст. Пароли хешируют, а не шифруют, поэтому утечка бесполезна. Соль уникальна на пароль, чтобы равные пароли давали разный хеш и били rainbow-таблицы.
Типичные ошибки
- ✗Называть хеширование обратимой операцией со скрытым ключом
- ✗Хранить пароли зашифрованными, а не с солью и хешем
- ✗Брать одну общую соль вместо уникальной на каждый пароль
Уточняющие вопросы
- →Почему быстрый универсальный хеш плох именно для паролей?
- →Что добавляет pepper поверх соли на каждый пароль?
JuniorТеорияОчень частоВ чём разница между HTTP и HTTPS и что гарантирует TLS?
В чём разница между HTTP и HTTPS и что гарантирует TLS?
HTTP шлёт запросы открытым текстом, который любой прочитает или изменит. HTTPS — тот же HTTP внутри TLS, он добавляет конфиденциальность, целостность и подлинность сервера: сертификат доказывает, что вы дошли до настоящего хоста. TLS не скрывает сам факт соединения.
Типичные ошибки
- ✗Думать, что HTTPS скрывает сам факт и адрес соединения
- ✗Считать, что TLS только про шифрование, забывая целостность
- ✗Верить, что сертификат подтверждает пользователя, а не сервер
Уточняющие вопросы
- →За что именно ручается удостоверяющий центр в сертификате?
- →Почему одного шифрования мало без проверки целостности?
JuniorТеорияЧастоЧем различаются идентификация, аутентификация и авторизация?
Чем различаются идентификация, аутентификация и авторизация?
Идентификация — заявление, кто вы. Аутентификация доказывает это заявление паролем, токеном или сертификатом. Авторизация решает, что доказанная личность вправе делать — к каким действиям и данным допущена. Каждый шаг — отдельная проверка в этом порядке.
Типичные ошибки
- ✗Считать аутентификацию и авторизацию одним и тем же шагом
- ✗Менять порядок и авторизовать до того, как личность доказана
- ✗Называть сам логин доказательством личности, а не просто заявлением
Уточняющие вопросы
- →Куда в эти три шага встраивается многофакторная аутентификация?
- →Может ли запрос пройти аутентификацию, но не пройти авторизацию?
MiddleТеорияЧастоЧто такое цифровая подпись и чем она отличается от шифрования?
Что такое цифровая подпись и чем она отличается от шифрования?
Цифровая подпись — хеш сообщения, подписанный закрытым ключом отправителя и проверяемый открытым ключом. Она доказывает целостность и подлинность, но ничего не скрывает; шифрование, наоборот, прячет содержимое. Подписывают закрытым ключом, а шифруют открытым ключом получателя.
Типичные ошибки
- ✗Думать, что подпись шифрует или скрывает содержимое сообщения
- ✗Подписывать открытым ключом вместо закрытого
- ✗Верить, что подпись даёт конфиденциальность, а не целостность
Уточняющие вопросы
- →Как удостоверяющий центр подписью ручается за ключ?
- →Можно ли и подписать, и зашифровать сообщение, и в каком порядке?
MiddleТеорияЧастоЧто такое JWT, из каких трёх частей он состоит и что нельзя класть в payload?
Что такое JWT, из каких трёх частей он состоит и что нельзя класть в payload?
JWT — подписанный токен из трёх частей: header, payload и signature. Подпись доказывает целостность и происхождение, но не шифрует — payload читается кем угодно. Поэтому не кладите в него секреты, пароли или персональные данные и держите его короткоживущим.
Типичные ошибки
- ✗Верить, что payload зашифрован, а не просто подписан
- ✗Класть секреты или персональные данные в читаемый payload
- ✗Доверять полю alg в header и допускать alg none
Уточняющие вопросы
- →Как сервер проверяет JWT, который он нигде не хранил?
- →Зачем держать короткий expiry, если JWT трудно отозвать?
MiddleТеорияЧастоЧто такое mTLS и когда вы требуете его между микросервисами?
Что такое mTLS и когда вы требуете его между микросервисами?
mTLS — взаимный TLS: обе стороны предъявляют сертификаты, поэтому каждая аутентифицирует другую, а не только сервер, как в обычном TLS. Требуйте его между сервисами в zero-trust-сети, где каждый сервис обязан доказать личность, а сети доверять нельзя.
Типичные ошибки
- ✗Думать, что при mTLS сертификат предъявляет только сервер
- ✗Называть mTLS двойным слоем TLS, а не взаимной аутентификацией
- ✗Требовать mTLS для браузерного трафика, а не между сервисами
Уточняющие вопросы
- →Кто выпускает и ротирует сертификаты сервисов в mTLS-меше?
- →Как mTLS связан с моделью zero-trust-сети?
MiddleТеорияЧастоЧто такое OAuth 2.0, какие роли он определяет и как выглядит authorization-code flow?
Что такое OAuth 2.0, какие роли он определяет и как выглядит authorization-code flow?
OAuth 2.0 позволяет пользователю делегировать доступ клиенту, не отдавая пароль. Его четыре роли — resource owner, client, authorization server и resource server. Code flow логинит пользователя, возвращает authorization code, а клиент меняет его на server-side на access token.
Типичные ошибки
- ✗Называть OAuth 2.0 аутентификацией и делиться паролем пользователя
- ✗Думать, что access token приходит уже в первом redirect
- ✗Путать authorization code с самим access token
Уточняющие вопросы
- →Зачем к code flow добавляют расширение PKCE для публичных клиентов?
- →Чем access token отличается от refresh token?
MiddleТеорияЧастоЧто такое RBAC, что такое ABAC и когда RBAC перестаёт масштабироваться?
Что такое RBAC, что такое ABAC и когда RBAC перестаёт масштабироваться?
RBAC выдаёт права через роли, назначаемые пользователю. ABAC решает каждый запрос по атрибутам — пользователь, ресурс, действие, контекст. RBAC перестаёт масштабироваться, когда тонкие контекстные правила вызывают взрыв ролей; ABAC это решает, но сложнее в сопровождении.
Типичные ошибки
- ✗Менять местами определения RBAC и ABAC
- ✗Утверждать, что у RBAC не бывает взрыва ролей на масштабе
- ✗Думать, что ABAC не нужна политика и он всегда проще
Уточняющие вопросы
- →Как RBAC и ABAC сочетаются в реальной боевой системе?
- →Что такое взрыв ролей и что его вызывает?
MiddleТеорияЧастоЧем различаются симметричное и асимметричное шифрование и где каждое применяется в TLS?
Чем различаются симметричное и асимметричное шифрование и где каждое применяется в TLS?
Симметричное использует один общий ключ в обе стороны — быстро, но ключ нужно доставить безопасно. Асимметричное — пара ключей — медленнее, зато без общего секрета. TLS берёт асимметрию в handshake для согласования ключа, затем симметрию для основных данных ради скорости.
Типичные ошибки
- ✗Путать, кто из двух использует общий ключ, а кто пару
- ✗Думать, что TLS шифрует основные данные асимметрией
- ✗Считать, что симметричный ключ можно слать открытым текстом
Уточняющие вопросы
- →Почему бы не использовать асимметрию на всю сессию?
- →Как согласуют симметричный сессионный ключ, не раскрыв его?
MiddleТеорияЧастоОпишите TLS handshake на глубине, нужной аналитику — что обменивается и зачем сертификат?
Опишите TLS handshake на глубине, нужной аналитику — что обменивается и зачем сертификат?
Стороны выбирают cipher, сервер присылает сертификат, а клиент проверяет его по доверенному CA. Затем они согласуют симметричный сессионный ключ асимметричной криптографией. Сертификат связывает имя хоста с открытым ключом и доказывает подлинность сервера.
Типичные ошибки
- ✗Думать, что сессионный ключ шлётся открытым текстом в handshake
- ✗Верить, что сертификат подтверждает пользователя, а не сервер
- ✗Считать, что асимметрия шифрует всю сессию, а не только её начало
Уточняющие вопросы
- →Зачем переходить на симметричный ключ после асимметричной настройки?
- →Что ломается, если цепочка сертификата не доходит до доверенного CA?
MiddleТеорияЧастоЧем различаются API key, Basic auth, Bearer token и протокол авторизации OAuth, и что выбрать для партнёрской интеграции?
Чем различаются API key, Basic auth, Bearer token и протокол авторизации OAuth, и что выбрать для партнёрской интеграции?
API key — статический секрет, называющий вызывающего, но грубо. Basic auth шлёт логин и пароль на каждом вызове. Bearer token выдаётся и истекает. OAuth выдаёт scoped и отзывные токены через flow. Для партнёра берите OAuth или scoped API key вместо Basic.
Типичные ошибки
- ✗Называть Basic auth безопасным выбором для партнёрской интеграции
- ✗Считать API key, Bearer и OAuth взаимозаменяемыми
- ✗Думать, что Bearer token — это сырой пароль пользователя
Уточняющие вопросы
- →Почему scoped и отзывной креденшел безопаснее для третьей стороны?
- →Как ротировать API key партнёра без простоя?
MiddleТеорияЧастоКак токен проходит по цепочке микросервисов — пробрасывание, exchange или service-to-service-токен?
Как токен проходит по цепочке микросервисов — пробрасывание, exchange или service-to-service-токен?
Пробрасывание передаёт токен пользователя без изменений, и каждый хоп держит полный scope. Token exchange меняет его на каждом хопе на узкий токен. Service-to-service-токен аутентифицирует сам сервис, а не пользователя. На практике их сочетают.
Типичные ошибки
- ✗Думать, что проброшенный токен сам сужает свой scope
- ✗Путать service-to-service-токен с токеном пользователя
- ✗Верить, что token exchange расширяет, а не сужает scope
Уточняющие вопросы
- →Чем рискован проброс токена с полным scope пользователя по цепочке?
- →Когда нужна идентичность сервиса отдельно от пользователя?
SeniorТеорияИногдаJWT украден и остаётся действительным 30 минут. Что реально сделать и как спроектировать отзыв?
JWT украден и остаётся действительным 30 минут. Что реально сделать и как спроектировать отзыв?
JWT самопроверяем, поэтому его нельзя отозвать на сервере. Держите короткий expiry с refresh-токенами и добавьте проверку отзыва: денилист token id или версию токена, сверяемую на каждом вызове. Это меняет statelessness на lookup, зато гасит токен раньше.
Типичные ошибки
- ✗Считать, что stateless JWT можно удалить на сервере для отзыва
- ✗Думать, что нельзя сделать ничего, кроме ожидания истечения
- ✗Верить, что короткий expiry сам отзывает уже украденный токен
Уточняющие вопросы
- →Как refresh-токены ограничивают ущерб от утёкшего access token?
- →Чего стоит денилист по задержке и хранимому состоянию?
SeniorДизайнИногдаСпроектируйте аутентификацию и авторизацию для одного бэкенда, обслуживающего три клиента: нативное мобильное приложение, браузерный SPA и партнёрский server-to-server API. Их доверие и сессии различны — мобильное держит вход неделями, веб-приложение работает в браузере под угрозой XSS и CSRF, а партнёр — сервер чужой компании без человека. Опишите, как каждый клиент аутентифицируется, какой креденшел или токен получает, сколько живёт сессия и как её обновляют и отзывают, и какие проверки авторизации применяет бэкенд, чтобы один скомпрометированный клиент не вышел за свой scope. Отметьте главные компромиссы.
Спроектируйте аутентификацию и авторизацию для одного бэкенда, обслуживающего три клиента: нативное мобильное приложение, браузерный SPA и партнёрский server-to-server API. Их доверие и сессии различны — мобильное держит вход неделями, веб-приложение работает в браузере под угрозой XSS и CSRF, а партнёр — сервер чужой компании без человека. Опишите, как каждый клиент аутентифицируется, какой креденшел или токен получает, сколько живёт сессия и как её обновляют и отзывают, и какие проверки авторизации применяет бэкенд, чтобы один скомпрометированный клиент не вышел за свой scope. Отметьте главные компромиссы.
OAuth 2.0, свой grant на клиента. Mobile: PKCE code flow, короткий токен, refresh в защищённом хранилище. SPA: токен в памяти, refresh в httpOnly-cookie. Partner: client-credentials токен без человека. Бэкенд проверяет токены и применяет отзываемые scope на клиента.
Типичные ошибки
- ✗Давать браузерному SPA долгоживущий токен в localStorage
- ✗Переиспользовать один креденшел или scope на все три клиента
- ✗Позволять машинному партнёру ходить под личностью человека
Уточняющие вопросы
- →Почему PKCE важен для публичных клиентов mobile и SPA?
- →Как отозвать доступ только партнёра, не трогая пользователей?
