В России снова обсуждают вход на сайты через Google, Apple ID, GitHub и другие иностранные аккаунты. Повод — подписанный закон № 199-ФЗ от 26.06.2026, который добавил в КоАП штрафы за нарушение правил авторизации пользователей.
Но сам запрет появился не сейчас. Базовая норма пришла ещё с 406-ФЗ от 31.07.2023 и с 1 декабря 2023 года живёт в ч. 10 ст. 8 закона № 149-ФЗ «Об информации». Новость 2026 года в том, что теперь за нарушение есть отдельная статья КоАП — 13.55: для граждан 10–20 тысяч рублей, для должностных лиц 30–50 тысяч, для юрлиц 500–700 тысяч.
Обычного пользователя за аккаунт Gmail или Apple ID штрафовать не собираются — возможно, надо бы добавить слово «пока», но пусть будет пока так. Штраф адресован владельцу сайта, приложения или информационной системы, если он даёт пользователю из России войти способом, который закон теперь не считает допустимым.
Снаружи всё выглядит как борьба с иностранными кнопками входа, на деле можно разглядеть спор о том, кто держит ключ от аккаунта пользователя.
Как это было раньше
Раньше у владельца сайта было два обычных пути авторизации:
Первый — заводить для юзеров «свой» аккаунт: логин, пароль, восстановление доступа, база пользователей, свои сессии, свои ошибки, свои утечки. Зато ни на кого не полагаясь, и делая что душа пожелает (и с чем пользователь согласится).
Второй — внешний вход, все вот эти «Войти через Google», «Войти через Apple», «Войти через GitHub», «Войти через Microsoft». Обычно это делается через OAuth 2.0 и OpenID Connect. (cтрого говоря, OAuth 2.0 сам по себе не про вход пользователя, а про выдачу доступа; для логина поверх него обычно используют OpenID Connect).
Для маленького проекта такая схема была удобной. Пользователь не заводит ещё один пароль. Сайт не хранит пароль. Большой провайдер уже умеет MFA, восстановление доступа, антифрод, подозрительные входы и всё то, что небольшой команде делать дорого и скучно.
В спокойной среде это выглядело разумно: зачем писать свою систему входа, если можно доверить проверку пользователя Google, Apple или GitHub? Минимум уже и потому, что гранды явно имеют выделенный штат людей следить за безопасностью.
Что изменилось после санкций и блокировок
После 2022 года (вдруг) стало заметно, что внешний провайдер входа — это не только удобство, но и зависимость.
Если у российского сервиса вход завязан на Google, Apple, Microsoft или GitHub, то часть работоспособности сервиса зависит от компании, которая находится в другой юрисдикции и живёт по своим правилам комплаенса. Она может изменить условия API, ограничить работу аккаунта, закрыть консоль разработчика, отключить платёжный профиль, перестать работать с отдельной компанией или с целым классом клиентов. Не говоря уже о случаях, когда таковая компания может быть оштрафована за то, и (говоря человеческим языком) окажется обиженной стороной.
Звучит дико (я знавал людей, которые говорили, что авторизацию ломать точно никто не станет, как бы компании не поссорились), однако, согласитесь, российский IT уже проходил похожее с облаками, CDN, магазинами приложений, сертификатами, доменами, репозиториями, корпоративными SaaS и платёжными системами. И нет, это я не про «кто первый начал», а про «в какой реальности мы в России живем»
С авторизацией проблема особенно неприятная. Если на неком нашем сайте сломался виджет комментариев, подтягивающий данные с другого сайта — плохо, но наш сайт ещё жив. Если же сломается вход — для пользователя сервис перестанет существовать.
Поэтому у государства была понятная претензия: российский сервис не должен полностью зависеть от иностранной компании в такой базовой операции, как вход пользователя в аккаунт.
С этим тезисом можно спорить политически, но технически он имеет смысл.
Что теперь требует закон
Часть 10 статьи 8 149-ФЗ говорит, что владелец сайта, страницы сайта, информационной системы или программы для ЭВМ, если это российское юрлицо или гражданин РФ и он работает в интернете на территории России, должен проводить авторизацию пользователей, находящихся в России, одним из четырёх способов.
Первый — через абонентский номер российского оператора мобильной связи.
Второй — через ЕСИА, то есть «Госуслуги».
Третий — через ЕБС, единую биометрическую систему.
Четвёртый — через иную информационную систему, которая обеспечивает авторизацию, соответствует требованиям ст. 16 149-ФЗ по защите информации и принадлежит гражданину РФ без второго гражданства или российскому юрлицу под российским контролем.
Последний пункт важнее всего. Закон, грубо говоря, не говорит: «все обязаны идти в VK ID». Он говорит: можно использовать любую российскую систему входа, если её владелец подходит под требования закона.
Сюда потенциально попадают VK ID, Яндекс ID, Сбер ID, T‑ID, МТС ID, региональные системы вроде mos.ru, корпоративные российские SSO, а также (даже) собственная система входа владельца сайта.
Но «потенциально» — ключевое слово. Закон написан широко, а правоприменение будет смотреть не на то, как разработчик у себя в голове классифицирует систему, а на то, как именно пользователь получает доступ к закрытой части сайта.
Что, вероятно, хотели получить авторы закона
Если читать закон не как злой умысел, а как попытку решить государственную задачу, логика примерно такая.
Первое: убрать зависимость российских ресурсов от иностранных компаний, которые могут выключить или ограничить вход не по техническим причинам, а из‑за санкций, комплаенса или политики платформы.
Второе: сократить передачу метаданных за рубеж. Внешний провайдер входа обычно не видит содержимое сайта, но видит сам факт входа: какой сервис запросил авторизацию, когда, с какого устройства, с какого IP, под каким аккаунтом. Это уже поведенческий граф.
Третье: вернуть ответственность в российскую юрисдикцию. Если вход обеспечивает российская система, её можно проверять, штрафовать, обязывать выполнять требования по персональным данным и защите информации.
Четвёртое (неофициальная): создать рынок для российских провайдеров входа. Это уже не только безопасность, но и промышленная политика. Когда иностранные кнопки входа запрещены, спрос на российские ID‑сервисы возникает не только из‑за удобства, но и из‑за страха штрафов.
Мотивация понятна. Но из понятной мотивации не следует, что выбранное решение хорошее.
Почему замена Google на VK или Яндекс не решает проблему
Если сайт убрал «Войти через Google» и поставил «Войти через VK», он не избавился от посредника — он его сменил.
Раньше информацию о входах мог видеть Google. Теперь её может видеть VK. Раньше пользователь зависел от иностранной экосистемы. Теперь он зависит от российской экосистемы. Раньше одна большая компания помогала собрать поведенческий профиль. Теперь это может делать другая большая компания. И даже не сказать, чтобы понятно было, кому в меньшей степени гадко отдать это делать.
Да, с точки зрения государства разница принципиальная: российская компания находится в российской юрисдикции (хотя бы формально), а вот с точки зрения приватности пользователя картина не становится автоматически лучше.
То же касается Яндекса: технически у него сильная инфраструктура, но это крупная рекламная и поведенческая экосистема, да ещё патологически не любящий за что-то отвечать. Делать связку VK ID с Яндекс ID универсальным ключом ко всему Рунету — значит усиливать концентрацию данных у игроков, которые и без того знают о пользователе очень много.
Поэтому правильный вывод не «Google плохой, ВК/Яша хорошие». Правильный вывод другой: чем меньше независимых способов входа остаётся у пользователя, тем выше риск, что весь Рунет постепенно сведут к нескольким крупным поставщикам аккаунтов.
Это может быть удобно государству и крупному бизнесу. Но это не обязательно хорошо для пользователя.
Почему телефон — плохой фундамент для доверия
Самый массовый разрешённый способ — номер телефона. Для чиновника он выглядит понятным: номер выдан оператором, оператор знает абонента, даже смотрел в его паспорт, значит — всё нормально. Особенно на бумаге нормально.
Но технически номер телефона — не сказать чтобы железобетонно качественная основа данных для проверки входа.
Номер не принадлежит человеку в том смысле, как ключ от квартиры, который лежит у него в кармане. Номер выдан человеку на время действия договора. Номер обслуживается оператором. SIM‑карту можно перевыпустить. Номер можно перенести. Договор можно переоформить. Номер могут отключить, отдать другому абоненту, заблокировать из‑за проблем с данными или ошибиться при обслуживании. Ах да, и за вот эти, вполне болезенные для клиента действия, оператору, по идее, не потребуется ни заплатить штраф, ни, даже, извиниться.
Есть отдельный класс атак — SIM swap, когда злоумышленник добивается перевыпуска SIM‑карты или переноса номера, и начинает получать звонки и SMS жертвы. Именно поэтому в современных рекомендациях SMS давно считается не лучшим вторым фактором. Например, NIST SP 800–63B относит проверку через телефонную сеть к restricted‑методам и рекомендует учитывать признаки вроде смены SIM, переноса номера и другого подозрительного поведения. Но — рекомендовать не значит жениться настаивать не выполнении, да и документ этот — американский.
То есть закон говорит: «можно входить через номер телефона». Инженерная практика говорит: «номер телефона — это терпимый запасной вариант, но плохой первичный ID аккаунта». Разработчики (в т.ч. и госсайтов) пилят свой код, встраивают телефон везде и всюду как уникальный ID, сдают поделку в работу — и, конечно, никто переделывать не станет.
Если сайт с рецептами или небольшой форум просит телефон только потому, что так проще выполнить закон, это ещё можно пережить. Если телефон становится главным способом восстановления доступа к важному аккаунту, получаем еще более лихозакрученный парадокс: государство запрещает Google (который, будем говорить, довольно параноидален насчет данных для входа) как недостаточно надёжного посредника и предлагает вместо него оператора связи, который сам является посредником, да еще и не особо старается быть безгрешным: ошибается, переоформляет номера и, на любые попытки что-то выяснить отвечает «вы сами это сделали, через отправку USSD, но когда и какого — у нас логов нет!»
Итог, или что делать владельцам сайтов
Первое: найти все способы входа. Смотреть надо не только на большую кнопку «Войти через Google», но и на менее заметные места.
Проверьте:
-
Telegram Login Widget, если считать его иностранной системой — см. оговорку про правоприменительную практику;
-
magic link на Gmail;
-
сброс пароля через иностранную почту;
-
корпоративный вход через Microsoft Entra ID, Okta или Google Workspace;
-
старые мобильные приложения, где кнопка входа осталась в UI;
-
API‑клиенты, где пользователь получает доступ через внешний OAuth.
Второе: отделить email как контакт от email как проверки доступа. Адрес Gmail в профиле сам по себе не обязан быть проблемой. Проблема появляется, когда владение этим ящиком становится способом входа или восстановления доступа: magic link, одноразовый код, сброс пароля.
Самый осторожный вариант: email оставить как контактный адрес, но не делать иностранную почту единственным способом доказать, что пользователь — это он.
Третье: вернуть нормальный локальный вход. Логин, пароль, MFA, passkeys/WebAuthn, нормальные сессии, rate limit, защита от перебора, аудит восстановления доступа. «В жизни всегда есть место подвигу», потому что сделать это нужно быстро.
Пароли не умерли. Просто их нельзя хранить (и обслуживать), как в 2008 году. Минимум — Argon2id, запрет слабых паролей по словарям, защита от credential stuffing, журналирование подозрительных входов, отзыв сессий и понятный recovery.
Четвёртое: не делать один российский ID единственным способом входа. Если вы подключаете VK ID, Яндекс ID, Сбер ID, T‑ID или МТС ID, оставьте пользователю независимый вариант: локальный аккаунт, passkey, TOTP, телефон как запасной способ. Чисто на всякий случай, потому что, мы знаем, шансы встретить динозавра увидеть отказ от ВК/Яндекса никогда не равны нулю.
Пятое: не использовать «Госуслуги» там, где они не нужны. ЕСИА хороша для юридически значимых действий: госуслуги, финансы, медицина, образование, подтверждение статуса. Для форума, медиа, небольшого SaaS или интернет‑магазина это слишком тяжёлый инструмент. Тем более не цепляйтесь за ЕСИА‑авторизацию через прокси‑посредников.
Чем «сильнее» идентификатор, тем выше цена ошибки. Не везде нужно знать, кто человек юридически. Часто сайту достаточно понимать, что это тот же пользователь, который вчера оставил настройки и заказ.
И, да, нужно критически пройтись по текстам на своём сайте (в т.ч. разделы помощи юридический), и поправить там фразы и формулировки насчет того, что и как сайт хранит и для чего использует.
Что делать пользователям
Пользователю надо понимать: Gmail, Apple ID и GitHub не становятся запрещёнными аккаунтами. Меняется то, какие кнопки входа российский сайт имеет право показывать, внимание, пользователю из России.
Практически стоит сделать несколько вещей.
Если важный российский аккаунт завязан только на Google, Apple или GitHub, добавьте другой способ входа заранее.
Используйте парольный менеджер. Локальных аккаунтов станет больше, а значит снова вырастет соблазн повторять пароли. Это плохая идея.
Включайте MFA. Лучше TOTP или passkey. Вариант с SMS будет лучше, чем использовать один пароль, но хуже, чем нормальный криптографический ключ или приложение‑аутентификатор.
Не несите всё в VK ID или Яндекс ID просто потому, что так быстрее. Если сайт даёт локальный аккаунт с passkey, это часто более приватный вариант.
Проверяйте восстановление доступа. Самая слабая часть аккаунта часто не вход, а способ вернуть доступ. Если аккаунт можно восстановить через старую иностранную почту или через номер, который легко перевыпустить, именно это и есть слабое место.
Через кого можно входить, кроме VK/Яндекс
Вариантов больше, чем кажется.
Самый нейтральный — собственный вход сайта: логин, пароль, MFA, passkey. Для многих проектов это лучший вариант, если он сделан нормально.
Телефон — привычный, массовый, но спорный способ. Его можно использовать как запасной канал, но лучше не делать единственной опорой аккаунта.
ЕСИА — для сервисов, где нужна юридически значимая личность.
ЕБС — для редких случаев, где биометрия действительно оправдана.
Сбер ID — для сервисов, где аудитория уже живёт в банковской или торговой экосистеме Сбера.
T‑ID — для части B2C/B2B‑сценариев.
МТС ID — вариант через операторскую экосистему.
Региональные системы вроде mos.ru — для региональных сценариев.
Корпоративный российский SSO — для внутренних систем и B2B, если владелец и инфраструктура укладываются в требования закона.
Собственный OIDC‑провайдер — для группы своих сайтов или закрытого сообщества, если есть кому его администрировать и отвечать за безопасность.
Можно ли запилить свой OAuth/OIDC‑сервер
Тут важно сначала уточнить термин. Если речь о входе пользователя, лучше говорить не просто «OAuth2-сервер», а OIDC‑провайдер. OAuth 2.0 отвечает за выдачу доступа, а OpenID Connect добавляет слой аутентификации пользователя.
Если у вас один сайт, отдельный OIDC‑провайдер обычно не нужен. Проще сделать нормальный локальный вход прямо в приложении.
Если у вас несколько своих сервисов — блог, форум, wiki, Git, Nextcloud, личный кабинет, админка, API‑панель, — свой OIDC‑провайдер уже имеет смысл. Его можно поднять на Keycloak, Authentik, Authelia, Ory или Zitadel.
Но есть юридическая часть.
По букве ч. 10 ст. 8 149-ФЗ «иная информационная система» подходит только если её владелец — гражданин РФ без гражданства другого государства или российское юрлицо под российским контролем. Система также должна соответствовать требованиям защиты информации из ст. 16 149-ФЗ.
Отсюда неприятные выводы.
Гражданин РФ без второго гражданства, который поднял свой OIDC для своих же проектов, имеет самый понятный аргумент: это его российская информационная система, она используется для авторизации, данные и администрирование под его контролем, требования защиты информации он выполняет.
Гражданин РФ с двойным гражданством — плохой случай. Закон прямо говорит «гражданин Российской Федерации, не имеющий гражданства другого государства». Значит, как владелец такой системы он под четвёртый способ не подходит. И, да, иностранец, живущий в России, например гражданин Уругвая или (ближе) Белоруссии, как владелец такой системы, тоже не подходит под четвёртый способ (он не гражданин РФ и не российское юрлицо). Если он создаст российское юрлицо, придётся смотреть на контроль: закон говорит о российском юрлице под контролем РФ, субъекта РФ, муниципалитета, гражданина РФ без второго гражданства или контролируемых ими лиц.
То есть «я живу в России и сам себе поднял сервер» не равно «моя система подходит под закон».
Для личного сервера «для себя и родственников» ситуация всё равно мутная. Если это вообще не публичный ресурс, не коммерческий сервис, не площадка с регистрацией пользователей и не деятельность в интернете на территории РФ, практический риск ниже. Но закон написан так широко, что там есть и сайт, и страница сайта, и информационная система, и программа для ЭВМ. Отдельного исключения для homelab, семейного Nextcloud или маленького сообщества в норме не видно.
Поэтому безопасная позиция такая: если это публичный российский ресурс с пользователями из РФ, не надо считать самодельный OIDC «обходом закона». Это не обход, а один из возможных способов, но только если владелец системы проходит по требованиям и может объяснить, как выполняет защиту информации. Объяснять, понятно, на бумаге.
А если хабра-сообщество поднимет общий независимый ID?
Идея понятная: не хочется отдавать всех в VK или Яндекс, значит, можно сделать независимый российский ID‑провайдер для сообществ, небольших сайтов и open source‑проектов. Через базу юзеров Хабра, например.
Технически — можно. Юридически и организационно — тяжело.
Такой сервис сразу становится важной точкой. Он видит, кто и куда входит. Он хранит связки аккаунтов. Он отвечает за сессии, токены, recovery, MFA, логи, персональные данные, запросы госорганов, утечки и компрометации.
Если делать это серьёзно, нужен не VPS у энтузиаста, а нормальная организация:
-
российское юрлицо с подходящим контролем;
-
понятная политика обработки персональных данных;
-
минимальный сбор данных;
-
короткое хранение логов;
-
публичная модель угроз;
-
независимый аудит;
-
bug bounty (хорошо бы);
-
passkeys и TOTP;
-
запрет входа только по SMS;
-
разделение клиентов;
-
прозрачные правила доступа к логам;
-
отчёты о запросах государственных органов;
-
возможность удалить аккаунт и экспортировать данные.
Как ни крути, «народный ID» быстро станет ещё одним местом, куда все понесли аккаунты и метаданные, только защищён он будет хуже, чем системы крупных игроков — а когда придут проверяющие «оттуда», отмазаться «мы делали как могли» может и не получиться.
Практичный вариант для большинства
Для большинства сайтов разумная схема выглядит так.
Базовый способ — собственный аккаунт сайта.
Пароль хранится нормально, с Argon2id или сопоставимым современным подходом.
Для MFA есть TOTP и passkeys/WebAuthn.
Телефон используется как запасной канал, но не как единственный корень аккаунта.
Иностранная почта остаётся контактным адресом, но не единственным способом входа и восстановления.
ЕСИА подключается только там, где действительно нужна юридически значимая личность.
Российский ID‑провайдер можно добавить для удобства, но не делать единственной дверью.
Для группы своих проектов можно поднять свой OIDC, если владелец подходит под закон и готов отвечать за безопасность.
Для сообщества общий ID имеет смысл только как серьёзный проект с юрлицом, аудитом и прозрачными правилами, а не как «давайте поднимем Keycloak на VPS».
Что будет дальше
Скорее всего, первым делом сайты начнут просто убирать иностранные кнопки входа. С утра тикет для фронтэндеров, в обед созвон по итогам, вечером созвон по жалобам и выловленным багам. Так быстрее и дешевле.
Потом вырастет вход по телефону. Это самый понятный для бизнеса способ, хотя с точки зрения безопасности он спорный.
Крупные российские ID‑провайдеры получат дополнительный рынок. VK, Яндекс, Сбер, Т‑Банк, МТС и региональные системы станут чаще появляться там, где раньше был Google.
Потом начнутся споры: можно ли использовать иностранный email как логин; можно ли magic link; что делать с корпоративным SSO; как определять, что пользователь находится в России; подпадают ли мобильные приложения; что делать с пользователями, зарегистрированными до запрета; считается ли семейный сервер «информационной системой».
И где‑то неизбежно появятся перегибы. Кто‑то начнёт требовать телефон там, где он не нужен. Кто‑то запретит Gmail даже как контактный адрес. Кто‑то решит, что безопаснее всего загнать пользователей в один крупный российский ID. Это будет не безопасность, а комплаенс по принципу «лишь бы не прилетело».
Вывод
У государства была понятная претензия: не надо строить вход на российские ресурсы так, чтобы ключ от аккаунта лежал у иностранной платформы, которая может изменить правила или отключить доступ.
Но правильный ответ на эту претензию — не массовый перевод всех в VK ID или Яндекс ID. Это просто смена одного большого посредника на другого.
Правильный ответ — сделать вход в аккаунт самостоятельным, понятным и не завязанным на одну внешнюю экосистему: локальный аккаунт, passkeys, TOTP, аккуратное восстановление доступа, минимум лишних данных и несколько независимых способов входа.
Закон заставляет убрать иностранные кнопки. Это уже случилось.
Теперь вопрос в другом: сайты воспользуются этим как поводом привести вход в порядок или просто заменят одну большую кнопку на другую.
ссылка на оригинал статьи https://habr.com/ru/articles/1053664/