Парадокс доверия: как реестр .bank.in подставил тех, кого должен был защищать

В 2014 году Резервный банк Индии запустил домен .bank.in с простой целью — создать проверенное цифровое пространство, где граждане могли бы безопасно работать с настоящими банками. Более десяти лет эта система защиты выглядела надёжной. До тех пор, пока исследователи не обнаружили, что реестр тринадцать месяцев подряд сливал конфиденциальные данные.

Что произошло

Специалисты по безопасности нашли API-интерфейсы реестра, которые не требовали никакой авторизации. Через них кто угодно мог получить доступ к базе с контактными данными администраторов. Целый год любой человек с базовыми техническими навыками мог запросить:

• Полные имена администраторов доменов
• Рабочие email-адреса
• Номера телефонов
• Информацию об организациях банков и финансовых учреждений

В общей сложности 5576 записей. Данные людей, управляющих финансовым присутствием Индии в интернете, лежали открытыми, как вещи на вокзале.

Философия фишинга

Самая болезненная деталь этой истории — .bank.in создавался именно для борьбы с фишингом. Идея RBI была прямолинейной: заходишь на .bank.in — значит имеешь дело с настоящим банком. Проверено.

Но теперь этот же реестр снабдил злоумышленников точными данными для фишинговых атак. Вместо массовых рассылок с «уважаемый клиент» мошенники получают конкретные имена, номера телефонов и email конкретных IT-администраторов банков. Это не просто информация — это навигатор для социальной инженерии.

Почему это случилось: технический разбор

Для тех, кто работает в разработке, этот случай — классический набор ошибок, которые, к сожалению, встречаются слишком часто.

Отсутствие авторизации на API. Интерфейсы реестра были по сути публичными. API-ключи, OAuth-токены или ограничение по IP-адресам — это базовые требования для любой системы с чувствительными данными.

Никакого rate limiting. Открытый endpoint без ограничения частоты запросов — приглашение к злоупотреблениям. Нужно точно знать, кто и как часто обращается к вашим системам.

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

Слабый контроль доступа. Даже публичный API не должен возвращать все данные подряд. Принцип минимальных привилегий никто не отменял. Зачем отдавать наружу полные контакты, если для большинства сценариев хватит названия организации?

Уроки для каждого бизнеса

Эта история не уникальна для Индии или банковской сферы. Любая компания, работающая с персональными данными — стартап с клиентской базой или корпорация с доменной инфраструктурой — должна сделать выводы.

Доверяй, но проверяй постоянно

Команда .bank.in не халатничала при создании системы. Она была продумана. Но безопасность — это не разовый проект, а непрерывный процесс. Как только прекратился активный мониторинг, уязвимости не заставили себя ждать.

Защищайте своих защитников

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

API-безопасность — не опция

Современный мир построен на API. Воспринимать их как простые каналы данных опасно. Каждый endpoint — потенциальная точка входа для атаки. Авторизация, шифрование, ограничение запросов, логирование — для всех интерфейсов, включая внутренние.

Считайте, что утечка уже произошла

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

Что дальше

Реестр .bank.in утверждает, что уязвимость устранена. Но инцидент ставит вопросы о безопасности всей финансовой цифровой инфраструктуры Индии. Если флагманская антифишинговая инициатива допускает подобную утечку, что скрывается в менее заметных системах?

Для организаций, управляющих доменами .bank.in или похожей инфраструктурой доверия, это должно стать сигналом к действию. Проведите немедленный аудит API-интерфейсов. Внедрите жёсткие ограничения доступа. Настройте непрерывный мониторинг. И тестируйте системы так, будто их атакует кто-то с плохими намерениями.

Большая картина

Мы живём в эпоху, когда цифровое доверие критичнее, чем когда-либо, и при этом хрупче, чем когда-либо. Реестры, удостоверяющие центры, инфраструктура доверия — это фундамент безопасных интернет-взаимодействий. Когда эти системы дают сбой, последствия расходятся кругами.

Утечка .bank.in — это предостережение о разрыве между намерениями и реальностью в сфере безопасности. Завоевать доверие сложно. Удержать его можно только постоянной бдительностью, инвестициями и готовностью признать собственные уязвимости.

Для разработчиков и технических лидеров: проверьте свои системы. Не в следующем квартале. Не когда освободитесь. Сейчас. Потому что где-то эти уроки уже изучают те самые люди, которым не стоило бы их изучать.

Безопасность интернета зависит от инфраструктуры, которую мы часто принимаем как должное. Будем лучше, чем тринадцать месяцев открытого доступа.