Что ИТ-отдел может извлечь из отключения Facebook

«Интернет не работает, не могли бы вы помочь мне это исправить?»

Электронное сообщение тети Мэйбл смотрело на меня из моего почтового ящика. Посмеиваясь, я ответил ей по электронной почте, сказав: «Если Интернет не работает, то почему вы можете написать мне по электронной почте?»

«Gmail все еще работает, — ответила она, — и Google тоже. Это Интернет, в который я не могу попасть».

Она имела в виду Facebook, конечно. Для миллионов и миллионов людей Интернет является почти синонимом Facebook, Instagram, Messenger и WhatsApp, четырех крупных активов гиганта социальной сети. Поэтому, когда 4 октября Facebook внезапно отключился по всему миру, пользователи повсюду запаниковали.

Что случилось? Может ли это повториться? Можно ли предотвратить это в будущем? И — для тех из нас, кто управляет большими и малыми ИТ-сетями — может ли с нами произойти то же самое?

Версия в двух словах

Я прочитал и попытался переварить несколько длинных статей о сбое в работе Facebook, включая собственное объяснение Facebook, этот пост от Cloudflare и эту статью Брайана Кребса. И из разговоров с коллегами, которые управляют гораздо более крупными и сложными средами, чем та, которой управляю я, я пришел к выводу, что, хотя их настройка DNS не была основной причиной катастрофы, она, вероятно, в значительной степени повлияла на масштабы того, что произошло. произошел. Когда было выпущено плохо продуманное обновление маршрутизации, из-за которого их центры обработки данных отключились друг от друга, результатом стало истечение срока действия всех их данных DNS. Это помешало инженерам Facebook получить доступ к инструментам, необходимым им для выхода из ситуации, и даже не позволило некоторым сотрудникам Facebook войти в свои здания, когда их значки безопасности перестали работать. В конце концов, однако, Facebook нашел способ передать свои инструменты восстановления в руки нужных людей, и постепенно все стало нормально. А вскоре моя тетя Мейбл тоже была счастлива.

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

Источник объяснил, что ошибочное обновление не позволило сотрудникам Facebook, большинство из которых работают удаленно, отменить изменения. Между тем, те, у кого был физический доступ к зданиям Facebook, не могли получить доступ к внутренним инструментам Facebook, потому что все они были привязаны к застрявшим доменам компании.

Угу, подумал я. Разве у них не настроен внеполосный (OOB) доступ к ключевым элементам их инфраструктуры на случай возникновения именно такой ситуации?

Важность ООБ

Совсем недавно я писал здесь, на TechGenix, о том, почему решения для внеполосного управления (OOB) жизненно важны для вашей сети. Я подчеркнул, что внештатные системы управления предоставляют вам альтернативный, выделенный и безопасный метод доступа к вашей сетевой ИТ-инфраструктуре, чтобы вы могли удаленно администрировать свои серверы, приложения и другие ИТ-активы в ситуациях, когда обычный доступ невозможен. Это может означать что-то такое же простое, как наличие маршрутизатора 4G или 5G с подключением виртуальной частной сети (VPN) к терминальному серверу. Таким образом, вы всегда можете использовать сеть своего оператора сотовой связи для настройки сетевого оборудования с помощью порта монитора, даже если сама конфигурация по какой-либо причине была удалена. Другими словами, вы используете вторичную сеть — обычно чью-то еще сеть — в качестве лазейки в свою собственную сеть в случае чрезвычайной ситуации. Конечно, это также означает внедрение различных элементов управления и политик безопасности для предотвращения нарушений и обеспечения безопасности вашей сетевой инфраструктуры.

Я также уверен, конечно, что специализированная команда высококвалифицированных сетевых инженеров Facebook знает об этом и имеет такие внештатные системы для ситуаций аварийного восстановления и аварийного восстановления, хотя настройка внеполосного доступа для каждого устройства в такой большой сети должна быть практически невозможно — они должны использовать какую-то распределенную систему каталогов для масштабирования, что, вероятно, означает, что она использует DNS. Что делает его недавний массовый сбой и отчеты о трудностях, с которыми Facebook столкнулся при его устранении, еще более тревожными — мне кажется, что им, возможно, придется переосмыслить некоторые аспекты своей настройки DNS, которая, вероятно, ежедневно обслуживает миллиарды пользовательских запросов, помимо предоставления доступа к сети для всем, кто работает в своей компании по всему миру. Но такие вещи выходят за рамки моего ограниченного опыта управления DNS. И в статье их инженерной группы не обсуждается (по очевидным причинам), как настроено управление их сетью OOB, поэтому я также не могу больше рассуждать на эту тему.

Что мы можем узнать из отключения Facebook

Итак, что мы можем извлечь из этой катастрофы, связанной с отключением Facebook, помимо использования OOB-управления для обеспечения безопасных бэкдоров для доступа к ключевым компонентам сетевой инфраструктуры в сценариях аварийного восстановления или аварийного восстановления? Вернемся к основам.

Остерегайтесь самодовольства. То, что ваши инструменты управления сетью работают сегодня, не означает, что они будут работать и завтра. Подумайте, что может привести к тому, что они перестанут работать, а затем соответствующим образом перестройте свою сеть, чтобы предотвратить катастрофу. Обновляйте свой плейбук DR/BC соответствующим образом и часто тестируйте его.

Убедитесь, что у вас есть альтернативное решение для совместной работы на случай, если ваше основное решение выйдет из строя. Ваша компания использует Microsoft Teams? Обязательно настройте Slack, Webex или даже Zoom в качестве резервной копии и убедитесь, что все знают, как им пользоваться.

Не забывайте, что ваш ИТ-персонал также должен быть включен в ваш план обеспечения непрерывности бизнеса. Аварийное восстановление — это не только наличие инструментов и умение ими пользоваться. Это также касается тех, кому необходимо использовать эти инструменты в чрезвычайной ситуации. Знают ли они, кому звонить, если кто-то в отпуске, болен или в больнице? Знают ли они, кто живет ближе всего к зданию, на случай, если для разрешения ситуации потребуется локальный доступ? Есть ли у них контактная информация ключевых сотрудников на их мобильных телефонах? Есть ли распечатанный лист со списком экстренных контактов, прикрепленный к стене их офиса на работе или дома на случай, если их мобильный телефон разрядится, и им нужно будет одолжить телефон своего супруга?

Убедитесь, что на одного или двух человек из высшего руководства возложена ответственность за аварийное восстановление, включая одобрение непредвиденных расходов, необходимых для восстановления. Работа этого человека должна быть двоякой: обеспечить неуклонное продвижение процесса восстановления и твердо запретить другим высшим руководителям вмешиваться в процесс восстановления. Последнее, что нужно вашей переутомленной команде аварийного восстановления, — это требовать от CxO обновлений статуса каждые 10 минут, пока они усердно работают над восстановлением услуг. В связи с этим, если вы настраиваете конференц-залы, физические или виртуальные, для управления процессом восстановления, обязательно отделите свою конференц-комнату для руководителей от комнаты, отвечающей за управление инцидентом.

Наконец, крупные организации, особенно работающие в области социальных сетей, также должны помнить о том, что сбои, влияющие на их услуги, могут вызвать проблемы с другими компаниями, расположенными между ними и их конечными пользователями в том, что касается сети Интернет. Например, интернет-провайдеры с большим количеством клиентов из числа бытовых пользователей внезапно обнаружили, что их службы поддержки переполнены разгневанными пользователями, которые, не имея доступа к своим любимым Facebook, Instagram или WhatsApp, неоднократно нажимали кнопку сброса на своих домашних маршрутизаторах, пытаясь восстановить подключение к социальной сети. «Мой роутер не работает!» — эхом отозвалось в ушах измученных технических специалистов первого уровня, которым приходилось снова и снова терпеливо объяснять им, что «Facebook не равен Интернету».