[Перевод] У Google появился новый креативный способ убивать SaaS-стартапы
Клянусь, я прочитал FAQ!
Всё проходит по одному сценарию. Сначала бизнес сознательно использует сервисы Google таким образом, что его выживание полностью зависит от них. Затем автоматизированный бегемот Google делает своё дело: он слегка меняет положение своей задницы на кожаном кресле размером с планету и, сам того не замечая, крушит в процессе мириады (относительно) маленьких компаний размером с муравья. И, наконец, компании размером с муравья отчаянно пытаются сообщить Google, что они раздавлены, но могут пообщаться только с автоматизированной формой для предложений.
Иногда генеральный директор размером с муравья знает кого-то в Google, потому что они были приятелями по колледжу, или технический директор пишет пост, который каким-то образом попадает на первую страницу муравейника Hacker News. Тогда Google замечает проблему и иногда считает её достойной решения, обычно из-за страха регулятивных последствий, которые может повлечь за собой муравьиная революция.
По этой причине общепринятая муравьиная мудрость диктует, что нельзя чрезмерно полагаться на сервисы Google. И если вам удастся избежать этой зависимости, всё должно быть в порядке.
Такая плоская синяя поверхность с классной красной крышей! Так удобно!
В сегодняшней серии «Интернет уже не тот, что раньше» поговорим о новом способе, которым Google может непреднамеренно сокрушить ваш стартап. Он не требует от вас использования сервисов Google каким-либо (преднамеренным) способом.
Вы знали, что ваши домены могут попасть в чёрный список Google без каких-либо особых причин и что этот чёрный список использует не только Google Chrome, но и несколько других вендоров программного и аппаратного обеспечения? Вы знали, что эти другие вендоры синхронизируют список с дико изменяющимися таймингами и интерпретациями, так что решение любых проблем становится чрезвычайно напряжённым и непредсказуемым делом? При этом сроки рассмотрения жалоб на чёрный список в Google измеряются неделями?
Теперь так выглядит ваш сайт или SaaS-приложение
Эта «функция» чёрного списка называется Google Safe Browsing, и на изображении выше можете прочитать сообщение, которое видят посетители вашего сайта, если один из доменов попал в базу Safe Browsing. Тексты предупреждений варьируются от «Обманный сайт» до «Сайт содержит вредоносное ПО» (полный список здесь), но все они на одинаково страшном красном фоне, который пытается максимально помешать пользователю перейти на сайт.
В первый раз мы узнали о проблеме из-за всплеска жалоб от клиентов, которые натыкались на это красное предупреждение при попытке использовать наше SaaS-приложение. Во второй раз мы лучше подготовлены, поэтому у нас уже есть свободное время, чтобы написать этот пост.
Наша компания InvGate — это SaaS-платформа для IT-подразделений, работающая на AWS. Она обслуживает более 1000 корпоративных клиентов и миллионы конечных пользователей. Фирмы используют продукт для управления тикетами и запросами от своих пользователей. Можете представить реакцию IT-менеджеров, когда внезапно их система тикетов начинает показывать конечным пользователям такие зловещие предупреждения безопасности.
Когда мы впервые столкнулись с этой проблемой, то отчаянно пытались понять, что происходит, и разобраться, как работает Google Safe Browsing (GSB), в то время как техподдержка пыталась справиться с потоком запросов от клиентов. Мы быстро поняли, что в базу GSB попал URL на Amazon Cloudfront CDN, с которого мы раздавали статические ресурсы (CSS, Javascript и др.), и это привело к сбою всего приложения для клиентов, использующих именно данный CDN. Быстрый обзор помеченной системы показал, что всё выглядит нормально.
В то время как команда девопсов работала в авральном режиме, чтобы настроить новый CDN и подготовиться к перемещению клиентов на новый домен, я обнаружил в документации Google, что через Google Search Console (GSC) можно получить дополнительные объяснения о причинах, почему сайт помечен в базе. Не буду утомлять вас подробностями, но чтобы получить доступ к этой информации, вы должны доказать владение сайтом, для этого настроить кастомную запись DNS или загрузить некоторые файлы в корень домена. Мы сделали это — и через 20 минут получили отчёт о нашем сайте.
Отчёт выглядел примерно так:
Это… не особенно информативно
В отчёте также была кнопка «Запросить проверку» (Request Review), которую я быстро нажал, фактически не предпринимая никаких действий на сайте, поскольку там не было никакой информации о предполагаемой проблеме. Я подал заявку с пометкой, что у меня не указаны вредоносные URL, хотя в документации говорится, что Google всегда предоставляет примеры URL, чтобы помочь веб-мастерам в выявлении проблем.
Отлично! Запрос на проверку недействительного отчёта может привести к тому, что будущие проверки станут ещё медленнее
Примерно через час сайт был удалён из базы GSB, мы даже не закончили выводить клиентов с этого CDN. Примерно через два часа пришёл автоматический email с подтверждением, что проверка прошла успешно. Никаких разъяснений, что вызвало проблему.
В течение недели после инцидента мы продолжали периодически получать от клиентов сообщения о проблемах с доступом.
Google Safe Browsing предоставляет два различных API для использования в коммерческих и некоммерческих продуктах. В нашем случае проблема воспроизводилась по крайней мере у некоторых пользователей Firefox, а также в некоторых антивирусах и сетевых устройствах безопасности. Они помечали наш сайт и блокировали доступ к нему много дней спустя.
Мы продолжали переводить всех клиентов со старого CDN на новый, и поэтому в конце концов решили проблему навсегда. Мы никогда так толком и не узнали причину и списали всё на какой-то обкуренный ИИ в штаб-квартире Google.
Если вы управляете SaaS-бизнесом и обещаете клиентам гарантированную доступность, то внесение в базу Google Safe Browsing без какой-либо конкретной причины представляет собой очень реальный риск для бизнеса.
К сожалению, учитывая чисто гугловскую непрозрачность механизма пометки и просмотра сайтов, вряд ли этого можно гарантированно избежать. Но вы, безусловно, можете спроектировать своё приложение и процессы таким образом, чтобы свести к минимуму вероятность этого, снизить влияние фактического внесения в чёрный список и свести к минимуму время, необходимое для решения проблемы.
Вот шаги, которые предпринимаем мы сами и которые я могу рекомендовать:
- Не держите все яйца в одном домене. Видимо, GSB помечает целые домены или поддомены. Поэтому лучше распределить приложения по нескольким доменам, так как это уменьшит ущерб от потери любого из них. Например, company.сom для сайта, app.company.net для приложения, eucdn.company.nеt для клиентов в Европе, useastcdn.company.nеt для клиентов на восточном побережье США и т. д.
- Не размещайте данные клиентов на основных доменах. Домены часто попадают в чёрный список из-за того, что клиенты SaaS по неведению загрузили на сервер вредоносные файлы. Эти файлы безвредны для систем, но само их существование может привести к тому, что весь домен будет занесён в чёрный список. Всё, что ваши пользователи загружают в приложения, должно размещаться за пределами основных доменов. Например, используйте companyusercontent.cоm для хранения клиентских файлов.
- Активно заявляйте о своём праве собственности на домены в Google Search Console. Это не помешает сайту попасть в чёрный список, но вы получите электронное письмо, которое позволит быстро отреагировать на проблему. Реагирование на такие инциденты занимает некоторое время, и это драгоценное время, в течение которого страдают ваши клиенты.
- Будьте готовы сменить домен, если нужно. Это самое сложное, что можно сделать, но это единственный эффективный инструмент против попадания в чёрный список: спроектируйте системы так, чтобы доменные имена сервисов можно было легко изменить (через скрипты или инструменты оркестровки). Например, пусть у eucdn.company2.net будет CNAME-запись eucdn.company.net, и если первый заблокирован, обновите конфигурацию приложения, чтобы загрузить ресурсы с альтернативного домена.
Вот что я бы порекомендовал:
- Если можете легко и быстро переключить своё приложение на другой домен, это единственный способ надёжно, быстро и якобы окончательно решить инцидент. Если можете, сделайте так. На этом всё.
- В противном случае, как только вы идентифицируете заблокированный домен, просмотрите отчёты в Google Search Console. Если вы до сих пор не заявили о владении доменом, придётся сделать это прямо сейчас, что займёт некоторое время.
- Если сайт действительно взломан, устраните проблему (например, удалите оскорбительный контент или взломанные страницы), а затем запросите проверку безопасности. Если сайт не взломан или отчёт Safe Browsing бессмысленный, в любом случае запросите проверку безопасности и заявите, что отчёт является неполным.
- Затем, вместо того чтобы метаться в агонии, представляя суммы ущерба за время ожидания, всё равно приступайте к переходу на новый домен. Проверка может занять несколько недель.
Спустя несколько месяцев после первого инцидента, мы получили письмо от Search Console с сообщением, что один из наших доменов опять попал в чёрный список. Через несколько часов мне как администратору домена G Suite пришло ещё одно интересное письмо, которое вы можете прочитать ниже.
«sc» в sc-noreply@google.com расшифровывается как Search Console
Позвольте объяснить своими словами, что это такое, потому что это просто умопомрачительно. Речь идёт о письме с предупреждением от Search Console о включении в чёрный список. В этом втором письме говорится, что автоматический фишинговый фильтр электронной почты G Suite считает поддельным это письмо от Google Search Console. Безусловно, это не так, поскольку наш домен действительно был занесён в чёрный список. Таким образом, Google даже не может решить, являются ли фишингом её собственные оповещения о фишинге. (LOL?)
Любому, кто работает в сфере технологий, совершенно ясно, что крупные техногиганты в значительной степени являются хранителями Интернета. Но раньше я интерпретировал это в свободном, метафорическом смысле. Описанный здесь инцидент с Safe Browsing очень ясно показал, что Google буквально контролирует, кто может получить доступ к вашему сайту, независимо от того, где и как вы им управляете. Поскольку Chrome занимает около 70% рынка, а Firefox и Safari в какой-то степени используют базу данных GSB, то Google может одним движением пальца сделать любой сайт практически недоступным в интернете.
