Не так давно пользователи по всему миру начали свой рабочий день не как обычно, а с «синего экрана смерти» – массово сообщая о проблемах с MS Windows, связанных, как выяснилось чуть позже, с некорректным обновлением решения CrowdStrike. Эта ситуация поставила на паузу аэропорты, банки, медицинские центры, супермаркеты – в общем, все то, что делает нашу жизнь удобнее и приятнее. Российский бизнес, к слову, почти не пострадал, и я снова задумался о том, как сильно текущий уровень цифровизации влияет на нашу жизнь.
Эта мысль, безусловно, не нова. И в ней есть важный момент: пока мы внутри ситуации, то обычно не думаем, как будем жить, если внезапно рухнет целый блок привычной системы и мы не сможем купить билеты, сделать банковский перевод подрядчику, да даже записаться к стоматологу не сможем – ведь повсеместная автоматизация с нами уже довольно давно и стала вполне привычной. И именно поэтому подобные массовые инциденты, напоминающие сцены из фильмов-ужастиков, заставляют смотреть на все эти моменты несколько по-другому.
Мы работаем с разными заказчиками, и регулярно сталкиваемся с мнением, мол, ну даже если у нас встанет какая-то наша информационная система, всегда можно отвезти платежку в банк, а документацию подписать на бумаге как в старые добрые времена.
Не исключаю, что компании, пострадавшие из-за сбоя Microsoft+CrowdStrike, рассуждали примерно так же, загружая обновления от вендора день в день без дополнительного тестирования, и контроля отзывов в общем информационном поле ИТ после очередного релиза. Считать ли такой подход беспечностью или же изначально заложенным риском – другой вопрос. Но при любом раскладе это принесло миллиарды долларов убытков и нарушило планы множества людей.
Важный момент: получилось так, что все пользователи (в первую очередь крупные корпорации) рухнувших сервисов Microsoft доверили вендору все риски, связанные со стабильностью и отказоустойчивостью – уход за облачными сервисами, тестирование новых релизов, обновлений и тому подобное. И делали это много лет.
Альтернатива «облакам» известна и она не зависит от страны или вендора –компании могли не полагаться на чужие сервисы, а потратить деньги, к примеру, на свои ЦОДы. Или, скажем, могли обновляться позже, после дополнительной внутренней проверки обновлений. При этом риски тоже хорошо известны – позже закрываются потенциальные дыры в информационной безопасности, выше риск подвергнуться хакерской атаке.
Как правильнее и при какой стратегии больше рисков – сложно сказать. По сути, есть два расхожих мнения, которые традиционно существуют в IT: централизация или децентрализация, унификация или разнообразие, складываем яйца в одну корзину или в несколько? У каждого варианта есть свои риски и выгоды. Но, по большому счету, все сводится к одному – доверяешь ли ты вендору, который выпускает очередной релиз, и ты ставишь обновления «как есть» либо не доверяешь и выстраиваешь процессы проверки где-то у себя в закрытом периметре.
Ситуация с CrowdStrike показала, что многие компании полностью доверились поставщику и это принесло им ряд проблем, хотя в остальные дни все было в порядке. Конечно, больше всего поражает массовый характер этой истории и тот факт, что огромное количество людей пострадало из-за халатности условно 2-3 человек, которые не проконтролировали процесс предрелизного тестирования, либо провели его халатно и выпустили некорректное обновление. По этому поводу вспомнился анекдот про серийного программиста, и думаю, его уместно будет тут привести.
Программист Геннадий сделал ошибку в коде, из-за которой каждый пользователь программы потратил в среднем 15 минут на поиск решения проблемы. Всего продуктом пользовались 10 миллионов человек, то есть впустую потрачено 150 миллионов минут = 2.5 миллиона часов. Если человек спит 8 часов в сутки, то на сознательную деятельность у него остается 16 часов. Таким образом, Геннадий уничтожил 156250 человеко-дней ≈ 427.8 человеко-лет. Средний мужчина живет 64 года, а значит Геннадий убил примерно 6 целых 68 сотых человека. И как тебе после этого спится, Геннадий – серийный программист?
В целом, на ситуацию продуктов и обновлений мы смотрим с обеих сторон – как вендора, так и заказчика. Будучи вендором, мы производим решения и стремимся к тому, чтобы они были стабильные, безопасные и приносили нашим заказчикам только пользу, а проблем не приносили вовсе. При этом в наших решениях кроме нашего кода и наших ноу-хау частично используются заимствованные библиотеки и инструменты. Безусловно, мы их предварительно сканируем и проверяем, но при этом всегда помним, что вот этот кусочек кода не является частью нашего продукта и что даже при компиляции он может внести в продукт что-то незапланированное. Например, какую-то оскорбительную фразу или текст политического характера. Как это отловить и в какой момент – понятно, но это требует дополнительных время- и трудозатрат.
Поэтому, когда мы готовим свои решения к сертификации, то вынуждены очень скрупулезно анализировать коды заимствованных библиотек. При этом понимая, что ни в один момент времени невозможно собрать проект, в котором нет уязвимости вообще. Скажем, в одной библиотеке вышло обновление, которое убрало старые уязвимости, но добавило новые. Во второй библиотеке другой подход к устранению уязвимостей. В третьей еще какие-то особенности. И между всем этим приходится постоянно лавировать и углубляться, выясняя, где что обновилось, добавилось, устранилось. И от этой совокупной зависимости невозможно избавиться, просто создав новую версию продукта.
Конечно, можно написать полностью все свои библиотеки, компиляторы и доверенные операционные системы, чтобы минимизировать риски. Но все это выльется в огромные расходы, а разработка затянется на годы, что не соответствует нашим задачам по импортозамещению и тем более импортоопережению.
Теперь что касается заказчика. Как правило, заказчик собирает свою информационную систему из продуктов разных подрядчиков и строит свои бизнес-процессы на базе этой «сборной солянки». Так как все риски в части бизнеса несет он сам, то и выбор подхода по части «верю-не верю» продуктам и обновлениям тоже лежит на заказчике. Это касается заказчиков, которые выбрали стратегию «все свое храню у себя, никаких облаков».
Если же добавляются облачные сервисы, приходится к рискам своей системы добавлять часто неизвестные окончательно риски поставщика этих сервисов. В большинстве своем заказчики, особенно в системах реального времени, придерживаются концепции нулевого доверия (Zero Trust), при которой никто никому не верит и пытается закрыть все, до чего можно дотянуться. В рамках этой концепции одни заказчики требуют гарантийные письма, что мы выполняем требования безопасной разработки, другие просят проведение дополнительных тестов и анализов. Третьим нужна сертификация ФСТЭК, а четвертые принимают риски как есть, потому что понимают, что все дополнительные телодвижения увеличат расходы.
И эти рассуждения касались в первую очередь точки зрения ИТ. Бизнес же дополнительно вынужден искать компромиссы, балансировать и оценивать риски с точки зрения затрат. И тут на сцену выходит понимание, к примеру, что лучше – в случае какого-то инцидента компания потеряет миллион, но не потратить заранее два миллиона, чтобы этого избежать.
Возвращаясь к недавнему инциденту с Microsoft+CrowdStrike можно утверждать, что пострадавший бизнес сделал ставку на возможную потерю от сбоя внешних сервисов в угоду отсутствия необходимости содержать у себя серьезную ИТ-инфраструктуру и штат квалифицированных специалистов. Что оказалось выгоднее – время покажет. Многие до сих пор судятся, а страховые напрягаются от выплат.
А с точки зрения нашей компании конечно же не стоит забывать и о конечных пользователях – людях, нас с вами, которые в этой ситуации не смогли улететь домой или получить медицинскую помощь.
Как вендор, мы стараемся выпускать продукты, облегчающие жизнь пользователям, а не усложняющие ее. С точки зрения пользователя – надеемся на сходное отношение от других поставщиков.
Всем хорошего дня и рабочих сервисов 24\7!
Самое актуальное и интересное – у нас в telegram-канале!