[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-multi-factor-authentication::ru":3,"gloss-cluster-multi-factor-authentication::ru":26,"gloss-next-multi-factor-authentication::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"multi-factor-authentication","security","Многофакторная аутентификация (MFA)","Многофакторная аутентификация требует более одного вида доказательства перед выдачей доступа: то, что вы знаете (пароль), то, что у вас есть (устройство или аппаратный ключ), или то, чем вы являетесь (биометрия). Смысл в том, что второй фактор должен отказывать независимо от первого, поэтому одного украденного пароля недостаточно. Это по-прежнему самая ценная отдельная мера, которую SaaS-продукт может предложить, потому что повторное использование паролей и фишинг дают большую долю захватов аккаунтов. Не все вторые факторы равны, и различия практические, а не теоретические. SMS-коды — самый слабый из распространённых вариантов: их перехватывают подменой SIM, и они по-прежнему фишингуемы, потому что пользователя можно уговорить продиктовать код злоумышленнику в реальном времени. Одноразовые коды из приложения-аутентификатора убирают оператора связи из схемы, но фишингуются так же. Push-подтверждения добавляют атаки на утомление, когда пользователь в конце концов принимает одно из множества уведомлений; сопоставление цифр это смягчает. Аппаратные ключи и passkey — качественно другой уровень, потому что учётные данные привязаны к origin сайта и не воспроизводятся на похожем домене. Для продуктовых команд вопросы такие: какие действия запрашивают подтверждение повторно (вход, добавление реквизитов выплаты, смена данных восстановления), может ли администратор включить требование для всей организации и, что упускают чаще всего, каков путь восстановления — слабый сброс возвращает всю схему к уровню того почтового ящика, куда он приходит.","MFA требует второй независимый фактор помимо пароля: чем различаются SMS, коды приложения, push и аппаратные ключи и почему слабое звено это восстановление.",null,[11,14,17,20,23],{"slug":12,"name":13},"least-privilege","Принцип наименьших привилегий (Least Privilege)",{"slug":15,"name":16},"oauth","OAuth",{"slug":18,"name":19},"passkey","Passkey (ключ доступа)",{"slug":21,"name":22},"sso","Единый вход (SSO)",{"slug":24,"name":25},"zero-trust","Архитектура нулевого доверия (Zero-Trust)",[27,31,35,39,42,45,48,51,54,57,60,63],{"slug":28,"category":5,"name":29,"updated_at":30},"audit-log","Журнал аудита (Audit Log)","2026-08-24T02:46:37+00:00",{"slug":32,"category":5,"name":33,"updated_at":34},"blast-radius","Радиус поражения","2026-08-24T03:30:02+00:00",{"slug":36,"category":5,"name":37,"updated_at":38},"break-glass-access","Аварийный доступ (break-glass)","2026-08-24T02:46:38+00:00",{"slug":40,"category":5,"name":41,"updated_at":38},"bridge-letter","Бридж-письмо (bridge letter)",{"slug":43,"category":5,"name":44,"updated_at":38},"business-associate-agreement","Соглашение с бизнес-партнёром (BAA)",{"slug":46,"category":5,"name":47,"updated_at":30},"byok","Собственный ключ шифрования (BYOK)",{"slug":49,"category":5,"name":50,"updated_at":38},"cve","CVE (идентификатор уязвимости)",{"slug":52,"category":5,"name":53,"updated_at":34},"data-classification","Классификация данных",{"slug":55,"category":5,"name":56,"updated_at":38},"data-loss-prevention","Предотвращение утечек данных (DLP)",{"slug":58,"category":5,"name":59,"updated_at":38},"data-minimization","Минимизация данных",{"slug":61,"category":5,"name":62,"updated_at":38},"data-poisoning","Отравление данных (Data Poisoning)",{"slug":64,"category":5,"name":65,"updated_at":38},"data-processing-agreement","Соглашение об обработке данных (DPA)"]