Многофакторная аутентификация и Zero Trust: как устроена безопасность доступа в корпоративной сети

Когда говорят о защите информации в компании, первым делом вспоминают брандмауэры и антивирусы. Но по факту — всё начинается с контроля доступа. Если пароль скомпрометирован, если кто-то перехватил код подтверждения, если чужой вошёл под вашим аккаунтом, никакой NGFW вас не спасает. Многофакторная аутентификация (MFA) и архитектура Zero Trust — это про тот момент, когда система не верит ни пароле, ни виду, и требует доказательств на каждый шаг. Разбираем, как это устроено, где сидят подводные камни и почему SMS-коды — худший выбор.

Коротко о главном

Многофакторная аутентификация — это система, которая требует от пользователя несколько независимых доказательств его личности. NIST и все мировые стандарты выделяют три класса факторов: фактор знания (что-то, что вы помните — пароль, PIN), фактор владения (что-то, что у вас есть — телефон, аппаратный ключ) и фактор неотъемлемости (что-то, что вы есть — отпечаток пальца, биометрия). Одна из этих категорий даёт слабую защиту, две — уже намного лучше, три — лучший вариант.

Zero Trust — это архитектурный принцип: компания не строит защитный периметр вокруг сети и не доверяет никому внутри. Вместо этого каждый запрос доступа аутентифицируется и авторизуется отдельно, независимо от того, откуда он пришёл и кто его отправил. Если у вас раньше была модель «мы доверяем всем, кто за брандмауэром», то Zero Trust — это её полная противоположность: «никогда не доверяй, всегда проверяй».

MFA в контексте Zero Trust — это не просто двухфакторная аутентификация в приложение, это встроенная в архитектуру доступа система, которая на каждом шаге (AD, VPN, RDP, веб-приложения) проверяет и пользователя, и устройство, и контекст входа. Иначе весь Zero Trust развалится на первой же фишинговой ссылке.

В этой статье

Три фактора многофакторной аутентификации: знание, владение, неотъемлемость
Отличие многофакторной аутентификации от двухфакторной (MFA vs 2FA)
Что такое Zero Trust и как MFA в неё встраивается
MFA в корпоративной архитектуре доступа: AD, VPN, RDP
Беспарольная аутентификация: FIDO2, WebAuthn и passkeys
Почему SMS — слабый выбор для фактора аутентификации
Типичные ошибки при внедрении MFA
Как правильно спланировать внедрение MFA

Три фактора многофакторной аутентификации

Многофакторная аутентификация построена на идее, что один фактор легко скомпрометировать. Пароль украдут фишингом. Телефон потеряют. Отпечаток пальца можно снять и подделать (хотя это уже очень дорого). Но чтобы атакующему удалось подделать всё сразу — пароль И физический токен И биометрию — это уже совсем другая история.

NIST и все международные стандарты ИБ делят факторы аутентификации на три класса:

1. Фактор знания (Something you know) — информация, которая живёт только в голове пользователя. Это пароль, PIN, ответы на секретные вопросы, паспортные данные. Главное свойство: фактор знания легко передать (и легко скомпрометировать по незнанию — записал на стикер на монитор). Одного фактора знания для безопасности недостаточно: пароли взламывают перебором, фишингом, утечками из баз данных.

2. Фактор владения (Something you have) — физический или виртуальный объект, который есть у пользователя. Это мобильный телефон с приложением аутентификатора, аппаратный ключ (YubiKey, Titan Key), смарт-карта, генератор кодов. Фактор владения взять сложнее — нужен доступ к самому устройству или перехват сигнала. Но телефон можно потерять, ключ — тоже, а SMS-коды перехватывают социальной инженерией.

3. Фактор неотъемлемости (Something you are) — биометрические данные, которые не может быть скомпрометированы в традиционном смысле (потому что они не передаются и не хранятся отдельно). Это отпечаток пальца, сканирование лица, сетчатки глаза, голос. Биометрия отличается от двух предыдущих факторов тем, что её нельзя просто «дать кому-то» — она всегда при вас. Но биометрия требует специального оборудования и хранится в защищённом виде на устройстве.

Предупреждение от бывалого: часто путают «фактор» и «метод доставки». SMS-код — это не фактор неотъемлемости, это метод доставки фактора владения (телефон). TOTP-приложение (Google Authenticator) — это тоже не сам фактор, это способ генерировать коды. А вот аппаратный ключ — это уже настоящий фактор владения. Разница критична: SMS может быть перехвачена, а ключ в руках — нет.

На практике лучшая комбинация — пароль (знание) плюс биометрия (неотъемлемость) плюс аппаратный ключ (владение). Но если компания только начинает, реального выигрыша уже даёт пароль плюс TOTP-приложение: это разные каналы компрометации, и если один скомпрометирован, другой остаётся в силе. SMS не считаю достаточным фактором, потому что SS7-атаки и SIM-swap давно вышли за пределы лаборатории.

Многофакторная аутентификация vs двухфакторная: в чём разница

Часто эти термины путают, хотя разница есть — и она важна для архитектуры доступа.

Двухфакторная аутентификация (2FA) — это когда вы используете ровно два фактора из трёх классов. Классический пример: пароль (знание) плюс SMS-код на телефон (владение). Или пароль плюс отпечаток пальца. Это лучше, чем один пароль, но 2FA уязвима к атакам на конкретные факторы (если SMS перехватить, или если пароль слит в даркнет).

Многофакторная аутентификация (MFA) — это система, которая может требовать два, три или даже четыре фактора в зависимости от контекста входа. MFA — это не фиксированное количество, а архитектурный подход, когда количество и тип факторов адаптируются к рискам. Приложение часто ограничивает себя двумя факторами просто потому, что больше неудобно пользователю. А вот корпоративная архитектура доступа может требовать разное количество факторов для разных сценариев: простой вход в email — два фактора, доступ к финансовым системам — три.

Главное отличие: 2FA — это конкретное решение (два фактора), MFA — это стратегия (адаптивное количество факторов в зависимости от риска и контекста).

На практике это означает, что компания, которая внедрила 2FA, скорее всего уже решила: всегда два фактора. Компания, которая внедрила MFA, может сказать: для этого пользователя, для этого устройства, при этом местоположении — два фактора достаточно, а при входе с неизвестного IP требуем три. Это гораздо более гибко и безопасно.

Zero Trust: архитектура «никогда не доверяй, всегда проверяй»

Традиционный подход к безопасности сети строился на идее периметра: есть «свои» внутри брандмауэра, которым мы доверяем, и есть «чужие» снаружи, которых не доверяем. Когда ты за корпоративным брандмауэром, ты уже считаешься честным. Но в 2026 году этот подход развалился: работники сидят дома, устройства — смешанные (личные и корпоративные), данные — в облаке. Границы периметра размыты.

Zero Trust отвергает эту модель. Его принцип: никогда не доверяй никому, даже если они за брандмауэром, даже если они корпоративные сотрудники. Вместо периметра Zero Trust строит микросегментацию: сеть делится на небольшие части, доступ между ними ограничен и требует отдельной аутентификации. Это как серия шлюзов, каждый из которых проверяет, кто ты, откуда ты, на каком устройстве ты, и только потом пускает дальше.

Ключевые компоненты Zero Trust:

Микросегментация. Вместо одной большой доверенной сети — множество малых, изолированных друг от друга. Даже если атакующий прошёл в один сегмент, он не может просто перейти в другой.
Контекстная авторизация. Система смотрит не только на пароль, но и на то, с какого устройства вы входите, откуда (IP-адрес, геолокация), во сколько, ваше обычное поведение. Если всё совпадает — быстро. Если что-то странное (вы обычно входите из Москвы, а вот сейчас вход из Сингапура в 3 часа ночи) — требуем дополнительных факторов.
Identity Provider (IdP). Центральная система управления учётными записями и правами доступа. Она знает, кто вы, какие права у вас есть, и проверяет каждый запрос доступа к любому ресурсу.
Least Privilege (принцип минимальных привилегий). Каждому пользователю и приложению даётся ровно столько прав, сколько нужно для работы, и не больше.

MFA — это не просто часть Zero Trust, это её фундамент. Если система не может надёжно определить, кто вы, все остальные компоненты Zero Trust развалятся. Поэтому в Zero Trust MFA — это не опция, это обязательность на каждом шаге: вход в AD, подключение к VPN, доступ к облаку, работа с приложениями.

Лайфхак: многие компании говорят, что внедрили Zero Trust, но на деле просто добавили 2FA в RDP. Это не Zero Trust, это 2FA в RDP. Настоящий Zero Trust требует полной переборки архитектуры: отката от VPN к бесперимётрному доступу (например, через Identity-Aware Proxy), включения MFA на каждый ресурс, микросегментации сети, мониторинга поведения. Это не разовая настройка, это перестройка, которая идёт месяцы.

MFA в корпоративной архитектуре доступа: AD, VPN, RDP

На практике корпоративные системы доступа построены слоями: сначала входишь в Active Directory (или LDAP), потом по этим же учётным данным входишь в VPN, потом в RDP-сессию, потом в конкретное приложение. Если MFA нет, то скомпрометированный пароль даёт доступ во все эти слои сразу.

Active Directory + MFA. AD — это центральный репозиторий учётных записей и прав доступа. Если на уровне AD включить MFA, то это защитит вход в каждый ресурс, который привязан к AD (большинство корпоративных приложений так и устроены). MFA на AD может быть реализована через приложение аутентификатора, аппаратный ключ, push-уведомление на телефон. SMS тоже возможна, но это самый слабый вариант.

VPN + MFA. VPN — это первая линия защиты при удалённой работе. Удалённый сотрудник подключается к VPN, получает доступ к корпоративной сети как будто сидит в офисе. Если MFA нет на VPN, то скомпрометированный пароль сотрудника даёт атакующему полный доступ к сети. На VPN MFA обычно реализуется через OTP-приложение (TOTP) или push-уведомление.

RDP + MFA. RDP (Remote Desktop Protocol) — это протокол удалённого доступа к компьютерам и серверам. Если администратор подключается в RDP со слабым паролем, атакующий может получить полный контроль над сервером. MFA на RDP обычно реализуется через сторонние решения (типа Multifactor, аппаратных ключей через FIDO2 или OTP-кодов). Встроенная поддержка MFA в Windows RDP ограничена, поэтому часто ставят промежуточный шлюз с MFA.

Веб-приложения + MFA. Если у вас есть корпоративные сервисы (Sharepoint, OneDrive, внутренние приложения), MFA на них — это обязательность. Современные облачные сервисы (Microsoft 365, Google Workspace) поддерживают MFA из коробки и требуют её на критичные ресурсы.

По факту: правильная архитектура выглядит так. Пользователь входит в VPN с пароля и кода из OTP-приложения (MFA). Попадает в сеть. Потом входит в AD с тем же пароля и кода (вторично — но если смена IP или отсутствие активности, требуем заново). Потом открывает RDP-сессию на сервер (и если это критичный сервер, требуем дополнительный фактор). Потом входит в конкретное приложение. На каждом этапе система проверяет контекст (откуда вход, с какого устройства, обычное ли поведение) и требует нужное количество факторов.

Беспарольная аутентификация: FIDO2, WebAuthn и passkeys

Проблема пароля очевидна: его легко украсть, легко переиспользовать, легко забыть. Мир постепенно переходит на беспарольную аутентификацию. FIDO2 и WebAuthn — это стандарты, которые позволяют это сделать.

Как работают passkeys и FIDO2. Вместо пароля система генерирует пару криптографических ключей: открытый ключ хранится на сервисе, закрытый ключ живёт на устройстве пользователя и никогда его не покидает. Когда вы входите, устройство подписывает запрос своим закрытым ключом, сервер проверяет подпись с открытым ключом. Никакого секрета по сети не передаётся.

Passkey (или passkeys) — это удобная реализация FIDO2 для пользователя. Вместо физического ключа (YubiKey) passkey хранится в защищённом хранилище устройства (на iPhone это Secure Enclave, на Android — Strongbox, на компьютере — TPM). Вход защищен биометрией (отпечаток пальца) или PIN-кодом устройства. С точки зрения пользователя — это просто отпечаток пальца вместо пароля. С точки зрения безопасности — это криптографический фундамент, который не могут украсть ни фишинг, ни брутфорс.

Преимущества перед паролем:

Не уязвима к фишингу. Passkey привязана к домену сервиса, поддельный сайт не сможет получить валидную подпись.
Не уязвима к перехвату. Закрытый ключ никогда не передаётся по сети.
Не уязвима к перелению баз данных. На сервере хранится только открытый ключ, закрытый — только на устройстве.
Удобна для пользователя. Отпечаток пальца быстрее, чем вводить пароль.

Где уже используется. Microsoft, Google, Apple уже внедрили passkeys в свои сервисы. GitHub, Dropbox, Notion и другие сервисы тоже поддерживают passkeys. На корпоративном уровне решения (Okta, Auth0, Teleport) поддерживают FIDO2-ключи (физические YubiKeys) и постепенно переходят на passkeys.

Лайфхак: если вы планируете внедрение MFA в компании, начните не с SMS-кодов, начните с FIDO2-ключей (они дешевле, чем кажется — под $20 за ключ) или с passkeys через облачный Identity Provider. Это даст вам лучшую безопасность, чем SMS, и не будет требовать держать на балансе телефоны для каждого сотрудника.

Защита персональных данных в организации начинается с контроля доступа — это основа, на которой стоит всё остальное. MFA и Zero Trust обеспечивают, чтобы доступ получал только авторизованный пользователь на авторизованном устройстве.

Почему SMS — слабый фактор для аутентификации

SMS давно считается скомпрометированным каналом для доставки кодов аутентификации. И вот почему.

SS7-атаки. SS7 (Signaling System No. 7) — это протокол, на котором работает мобильная связь. У него древняя архитектура, рассчитанная на доверие между операторами. На практике эту архитектуру можно обойти: если у вас есть доступ к SS7-шлюзу, можно перехватить SMS, идущую на чужой номер. Эти шлюзы продаются в свободном доступе, и нередко ими пользуются киберпреступники.

SIM-swapping. Это атака, когда злоумышленник социальной инженерией убеждает сотрудника оператора связи переввести номер жертвы на SIM-карту под его контролем. Потом все SMS-коды начинают поступать атакующему. Это проще, чем кажется: звонок оператору, история про потерянный телефон, и готово — номер перенесён на новую SIM.

Перехват на уровне приложения оператора. Если на телефоне жертвы установлено вредоносное ПО, оно может перехватить SMS ещё до того, как её увидит пользователь. Корпоративные устройства в большинстве случаев защищены хорошо, но если сотрудник использует личный телефон — это реальная уязвимость.

На практике компании до сих пор используют SMS для 2FA потому, что это просто (не нужно просить сотрудников ставить приложение) и дёшево (SMS из коробки). Но если у вас есть возможность требовать TOTP-приложение (Google Authenticator, Microsoft Authenticator), push-уведомление или FIDO2-ключ — SMS лучше избегать.

По факту: для критичных систем (финансы, AD, доступ администраторов) SMS не должна быть вариантом вообще. Для менее критичных (доступ в email, документы) — SMS можно использовать как резервный вариант, но не как основной.

Если компания говорит, что у них есть MFA на основе SMS, я сразу знаю, что настоящей защиты нет. SMS — это театр безопасности. Реальная защита — это TOTP, push-уведомление на контролируемое устройство, или FIDO2-ключ. SMS имеет смысл только как опция восстановления доступа, когда человек потерял телефон.

Типичные ошибки при внедрении MFA

Когда компании внедряют MFA, они часто делают одни и те же ошибки. Вот самые распространённые.

Ошибка 1: недифференцированное внедрение. Включили MFA на всех — и на уборщика, и на финансового директора, и на администратора. Все требуют одинаковое количество факторов одинаково часто. Результат: все раздражены, админы начинают её отключать, а защиты на самом деле нет.

Правильный подход: риск-ориентированный. Для рядовых сотрудников, входящих в облачный email с офиса — достаточно пароля плюс знакомое устройство. Для входа в финансовые системы — три фактора, независимо от контекста. Для администраторов, подключающихся в RDP на серверы — всегда MFA, при смене IP — дополнительная проверка.

Ошибка 2: выбор слабых факторов. SMS, вот они и выбрали, потому что просто. Или односекундные TOTP-коды, которые сотрудник не успевает перепечатать, пока код уже истёк. Или push-уведомление только на личный телефон, который может оказаться в роуминге.

Правильный подход: составить матрицу рисков, определить, какие факторы для какого доступа, и использовать несколько каналов. Например: TOTP как основной, push-уведомление как резервный, SMS как последняя опция восстановления.

Ошибка 3: отсутствие интеграции с бизнес-процессами. Внедрили MFA, но забыли про сценарии, когда сотрудник теряет телефон, или когда система обслуживания требует доступ к приложению без сотрудника. Сломалась стандартная процедура, люди начинают обходить MFA, безопасность падает.

Правильный подход: спланировать резервные способы доступа до внедрения. Например: потеря телефона — есть резервные коды восстановления, или вызов в офис с документом, или backup-ключ в сейфе. Для систем-сервисов — отдельные учётные записи без MFA с ограниченными правами.

Ошибка 4: отсутствие резервных способов доступа в целом. Что если сервис аутентификации упал? Что если оператор связи потерял данные? Что если у 10 сотрудников одновременно пропали телефоны? Компания висит без доступа к системам.

Правильный подход: резервные коды восстановления, резервные факторы (если основной фактор TOTP, то резервный — физический ключ), план recovery на случай сбоя сервиса аутентификации.

Ошибка 5: отсутствие обучения и коммуникации. Внедрили MFA, сказали людям: вот, включили, пользуйтесь. Никто не знает, что делать, когда код не приходит, какой фактор безопаснее, как восстановить доступ. Люди раздражены, поддержка завалена тикетами.

Правильный подход: кампания коммуникации до внедрения (зачем это нужно, как это работает), рассылка инструкций, FAQ, программа поддержки. И главное — слушать feedback. Если много сотрудников жаловается, что TOTP-коды не успевают вводить — может, нужно увеличить окно (не 30 секунд, а 60).

Как правильно спланировать внедрение MFA

Если вы решили внедрять MFA, вот порядок действий, который работает на практике.

Шаг 1. Провести инвентаризацию систем и пользователей. Что такое в компании? Сколько пользователей? Какие системы критичные, какие — нет? Кто администраторы, кто — рядовые сотрудники? На каких устройствах люди работают (корпоративные ноутбуки или BYOD)? Какой уровень ИТ-грамотности?

Шаг 2. Выбрать стратегию факторов. Какой фактор для какого доступа? Основной вариант — 2-3 фактора для критичных систем, 2 фактора для остального. Резервные варианты — коды восстановления, резервный ключ, физический ключ в сейфе. Никогда SMS как основной, максимум как резервный.

Шаг 3. Выбрать решение. Облачное (Microsoft Entra, Okta, Google Identity) или on-premise (Keycloak, FortiAuthenticator)? С какими системами оно интегрируется? Сколько стоит на одного пользователя? Есть ли поддержка наших специфичных каналов (например, SMS через определённого оператора)?

Шаг 4. Спланировать rollout. Не все сразу. Начните с администраторов (они разберутся быстро), потом с ранних адептов, потом волна за волной. На каждой волне собирайте feedback и подстраивайте процесс.

Шаг 5. Подготовить support и резервные процессы. Обучить поддержку, как помочь сотруднику, если он потерял доступ. Написать процедуру восстановления. Убедиться, что есть способ разблокировать критичные системы, если сервис аутентификации упал.

Шаг 6. Коммуникация и обучение. За месяц до внедрения начните рассказывать, зачем это нужно. Как только внедрили — выпустите инструкции, FAQ, видео. И главное — слушайте feedback. Если люди жалуются — не игнорируйте, это сигнал.

Часто задаваемые вопросы

Многофакторная аутентификация одна и та же для всех систем?

Нет. MFA может быть разной для разных систем. Например: для входа в email достаточно пароля плюс push-уведомление, для доступа в финансовые системы требуем три фактора (пароль, TOTP, аппаратный ключ). Это называется адаптивной аутентификацией — количество и тип факторов зависит от риска доступа и контекста.

Что делать, если сотрудник потерял телефон с приложением аутентификатора?

Вот для этого нужны резервные коды восстановления. При настройке TOTP-приложения (Google Authenticator, Microsoft Authenticator) система выдаёт 8-10 резервных кодов. Сотрудник должен их распечатать и хранить в безопасном месте (например, в сейфе). Если потеря — используем резервные коды для входа и переустанавливаем приложение на новый телефон. Если резервные коды не были созданы — обращаемся в поддержку с документом, и поддержка вводит временный код восстановления.

MFA замедляет работу? Все будут входить в систему 10 минут?

Нет. При правильной настройке MFA замедляет вход максимум на 5-10 секунд (ввод кода или отпечаток пальца). Кроме того, если система «запомнила» устройство, то в следующий раз может не требовать MFA вообще (в течение дня). Главное — выбрать удобный способ. Push-уведомление быстрее, чем вводить TOTP-код. TOTP быстрее, чем ждать SMS. Отпечаток пальца (passkey) — самый быстрый вариант.

Чем отличается TOTP от OTP? Это одно и то же?

Похожи, но не совсем. OTP (One-Time Password) — это общее название для одноразовых кодов. TOTP (Time-based OTP) — конкретный вид OTP, который генерирует коды на основе времени. Есть ещё HOTP (HMAC-based OTP), который генерирует коды на основе счётчика. На практике TOTP — это то, что реализовано в Google Authenticator и большинстве приложений аутентификатора.

Безопасна ли биометрия? Отпечаток пальца можно же украсть?

Технически отпечаток можно скопировать (это возможно, но требует специального оборудования и времени), но он не передаётся по сети как пароль. Когда вы разблокируете телефон отпечатком, вы не отправляете отпечаток на сервер. На сервер отправляется результат криптографической операции, которую телефон выполнил. Поэтому биометрия намного безопаснее пароля. Плюс, биометрия не может быть потеряна или забыта — она всегда при вас.

Как Zero Trust защищает от инсайдера? Ведь инсайдер — это сотрудник компании, он уже в системе?

Инсайдер в Zero Trust остаётся под контролем. Да, он в компании, но за каждый его запрос к данным система проверяет: а нужны ли ему эти данные? Есть ли у него права? Обычное ли это поведение для этого пользователя? Если финансист вдруг пытается скопировать базу персональных данных — это странно, и система либо заблокирует, либо потребует дополнительную проверку. Zero Trust работает на комбинации контроля доступа (RBAC, ABAC), логирования и мониторинга поведения. Полностью от инсайдера не спасает, но сильно усложняет.

Какое количество факторов — золотой стандарт? 2, 3, или 4?

Зависит от критичности доступа и риска. Два фактора (пароль + TOTP или push) — это хороший уровень для большинства сотрудников. Три фактора (пароль + TOTP + аппаратный ключ) — для администраторов и финансистов. Четыре фактора — редко, потому что человек не потянет (слишком долго и раздражающе). На практике лучше сфокусироваться на качестве факторов, чем на количестве. Три слабых фактора (пароль + SMS + знакомое устройство) хуже, чем два сильных (пароль + FIDO2-ключ).

Контроль доступа — это основа защиты доступа в организации. MFA и Zero Trust не заменяют другие меры безопасности (шифрование, логирование, обновления), но без них остальное просто теряет смысл. Если злоумышленник прошёл аутентификацию, дальше по сети ему уже нечего не преградит.

Что запомнить

Многофакторная аутентификация — это архитектурный подход, который требует от пользователя несколько независимых доказательств личности. NIST выделяет три класса факторов: знание, владение, неотъемлемость. Один фактор слаб, два — уже хорошо, три — лучше. Два фактора могут быть из одного класса, но тогда это не совсем MFA, это просто два слоя одной защиты.

Zero Trust — это не технология, это архитектурный принцип: никогда не доверяй, всегда проверяй. Он требует микросегментации сети, контекстной авторизации и MFA на каждом шаге доступа. Компания, которая говорит, что внедрила Zero Trust, но не переделала архитектуру доступа — эта компания просто добавила 2FA.

На практике MFA в корпоративной среде интегрируется с AD (Active Directory), VPN и RDP. Каждый из этих слоёв может требовать свой набор факторов в зависимости от контекста и риска.

Беспарольная аутентификация (FIDO2, WebAuthn, passkeys) — это будущее. Она защищена от фишинга, перехвата и перелива баз данных. Если у вас есть возможность внедрить passkeys вместо паролей — это сильнее, чем любая MFA на основе пароля.

SMS для аутентификации — это театр безопасности. SS7-атаки и SIM-swapping давно вышли из лабораторий. Используйте TOTP, push-уведомления, FIDO2-ключи. SMS — только как резервный вариант восстановления.

При внедрении MFA избегайте типичных ошибок: недифференцированное включение для всех, выбор слабых факторов, отсутствие интеграции с бизнес-процессами, отсутствие резервных способов. Спланируйте внедрение, начните с администраторов, собирайте feedback, подстраивайте процесс.