Почему компании бегут из зарубежных облачных IdP на свои сервера

Ещё три-четыре года назад на профильных конференциях считалось признаком хорошего тона рассказывать, как компания «избавилась от серверов и перенесла всю аутентификацию в модное зарубежное облако».

Архитекторы радостно подключали Okta, Auth0, OneLogin или Microsoft Entra ID (бывший Azure AD): *«Красота! Никаких бэкапов, никаких обновлений баз данных, отказоустойчивость 99.99%, вендор обо всём позаботится»*.

А потом наступила суровая геополитическая и экономическая реальность.

В одно прекрасное утро сотни российских компаний открыли корпоративную почту и увидели лаконичное уведомление: *«Ваш тенант заблокирован в связи с соблюдением требований комплаенса. Доступ к панели управления прекращён. Экспорт базы данных не предусмотрен»*.

В эту секунду работа бизнеса встала колом: сотрудники не могут войти в почту, разработчики отрезаны от репозиториев, бухгалтерия заблокирована.

Сегодня бегство из зарубежных облачных Identity Provider (IdP) обратно на собственное железо — это не прихоть параноиков, а базовое условие выживания компании. Вот четыре главные причины этого исхода.

---

1. Риск отключения в один клик без права апелляции

Когда ваша система единого входа (SSO) хостится в облаке зарубежного вендора, кнопка включения и выключения вашего бизнеса находится в чужих руках.

Любое изменение санкционных пакетов, смена политики вендора или банальный сбой платёжного шлюза при оплате зарубежной картой означает мгновенный шатдаун.

Вы не можете позвонить в техподдержку, не можете прийти в офис вендора и не можете развернуть бэкап, потому что проприетарное облако не отдаёт вам внутренние базы сессий и хэшей паролей. Доверив IdP чужому дяде, вы отдали ему ключи от всех дверей своей компании.

---

2. Задержки сети и деградация трансграничных каналов

Аутентификация — это синхронный процесс с высокой чувствительностью к задержкам (Latency).

Каждый раз, когда пользователь заходит в локально развернутый GitLab, корпоративную Wiki или Grafana:

• Браузер редиректит пользователя на сервер авторизации;
• Запрос летит через трансграничные магистральные каналы в Франкфурт, Амстердам или Дублин;
• Там крутится логика облачного провайдера;
• Ответ возвращается обратно в Россию.

В идеальных условиях это даёт задержку в 150–200 миллисекунд. Но в условиях регулярных сбоев внешних магистралей, DPI-фильтрации и замедлений задержки подскакивают до 3–8 секунд, а запросы начинают отваливаться по Connection Timeout.

Пользователи жалуются на «тормозящий GitLab», хотя сам сервер Git стоит в соседней комнате в серверной стойке!

---

3. 152-ФЗ и утечки данных

Имя, фамилия, должность, рабочий email, IP-адрес рабочего места, хэши паролей и состав проектных групп — всё это в совокупности является персональными данными сотрудников.

Хранить эти сведения в калифорнийском дата-центре:

• Прямое нарушение требований Федерального закона № 152-ФЗ «О персональных данных» (требование локализации баз данных на территории РФ);
• Риск попасть под внеплановую проверку регуляторов с блокировкой доменов и оборотными штрафами;
• Постоянный риск утечки через баги в мульти-тенантной архитектуре облачного провайдера (вспомните знаменитые инциденты со взломом серверов поддержки Okta).

---

4. Долларовая кабала: экономика безумия

Зарубежные облачные IdP работают по подписной модели с тарификацией за каждого активного пользователя (Per-User Pricing):

• Базовый тариф Okta или Entra ID с поддержкой SSO и MFA обходится в $6–$15 на пользователя в месяц.
• Для компании на 150 человек это $900–$2 250 ежемесячно.
• В пересчёте на рубли с учётом комиссий посредников за трансграничную оплату это превращается в 1.5–3 миллиона рублей в год!

Платить миллионы рублей ежегодно просто за то, чтобы сервер генерировал текстовые токены — это финансовое преступление против ИТ-бюджета.

---

Возвращение домой: суверенный On-Premise шлюз OwnGate

Единственный способ спать спокойно — вернуть систему авторизации внутрь собственного защищённого периметра.

Шлюз доступа OwnGate спроектирован с упором на 100% автономность и On-Premise:

1. Полная изоляция (Air-gap Ready). Шлюз устанавливается на ваши физические сервера или во внутренний контур виртуализации (KVM, Proxmox, VMware). Он не делает ни единого запроса во внешние облака.

2. Работа без интернета. Если внешний интернет полностью отключается, сотрудники в офисе и на удалёнке продолжают бесперебойно работать со всеми внутренними системами компании.

3. Мгновенный отклик. Пинг до шлюза авторизации составляет 1–2 миллисекунды, а вход происходит со скоростью щелчка пальцев.

4. Фиксированная прозрачная стоимость. Никаких долларов, зарубежных карт и растущих с каждым новым сотрудником счетов.

Хватит арендовать безопасность у тех, кто может захлопнуть дверь перед вашим носом. Собственный шлюз авторизации внутри компании — это надёжный фундамент независимой инфраструктуры.