Безопасность, управление изменениями и хранение данных в \"облаках\"

Для несведущих: управление изменениями, это когда программу разрабатывают, тестируют и устанавливают в среде промышленной эксплуатации (АКА "продуктиве") разные люди. Вернее, это даже следствие контроля за изменениями. Но все по порядку.

Когда-то очень давно один мудрый генеральный директор решил, что хватит уже относиться к ИТ, как к шаманам и чернокнижникам, ютящимся в подвалах бизнес-центров и выполняющих одним только им известные манипуляции над многомиллионным аппаратным и программным обеспечением. Пора уже вывести этот орден рыцарей плаща и обжимки на свет божий и призвать к ответу за ИТ-бюджеты: куда, мол, и сколько было потрачено. А главное, с какой эффективностью, то есть, что компания приобрела за вложенные деньги. Последовавшие за этим попытки айтишников  невнятно оправдаться за разбазаренное народноекорпоративное добро были названы процессом обоснования или возврата инвестиций (Return on Investment, ROI). А установка жесткого бизнес-контроля над вложениями в ИТ и измерением их "выхлопа" было названо громким словом IT Governance. В основу этой новой дисциплины был заложен принцип четкого соответствия функций ИТ и целей бизнеса

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

Непредвиденные обстоятельства - это универсальное объяснение факапов (от англ. to fuck up), которых не удалось избежать при помощи денег и прочих нечеловеческих ресурсов. Иными словами, это когда и сервер новый, быстрый и места много, и сеть к нему подключена быстрая-прибыстрая, и (а чем черт не шутит?) резервирование ему сделано для высокой доступности. А бекапы на него все равно не ложатся, потому что администратор в конфигурации программы резервного копирования допустил ма-а-аленькую синтаксическую ошибку. Или другой пример, когда в новую мега-круто-распупыристую бизнес-систему в конце рабочего дня в пятницу молодой системный администратор вносит незначительное изменение, в результате чего все выходные (т.е. два, а иногда и три дня) система работает неправильно. Например, неправильно считает траффик, потребленный абонентами мобильного Интернета. В результате чего компания поставщик этого самого мобильного Интернета попадает на баблов убытки.

Перечислять примеры факапов особого смысла не имеет, так как любой читатель, имеющий отношение к ИТ, может с легкостью поделиться экземпляром, очевидцем или участником которого был он сам. Для того, чтобы избежать таких ситуаций, или свести частоту их возникновения к минимуму, умные люди придумали управления изменениями (Change Management). Основной принцип прост: перед применением в продуктиве все изменения должны быть аккуратно разработаны, испытаны и утверждены руководством. Причем очень важно, чтобы разработка, испытание и применение изменений выполнялись разными сотрудниками и с использованием разных копий программы. То есть, разработчики разрабатывают ПО в среде разработки, после чего тестировщики копируют готовый код в среду тестирования и проводят испытания, вслед за чем администраторы приложения копируют испытанный код в среду промышленной эксплуатации - так называемый продуктив. Естественно, вся эта возня большинству айтишников видится совершенно бессмысленной, поэтому факапам в ближайшем будущем конца не видно.

Так причем здесь безопасность? На самом деле, безопасность по большому счету мало отличается от эффективного управления изменениями. Главное, чтобы в этом процессе учитывались риски ИБ. Один из ярчайших примеров, иллюстрирующих влияние контроля над изменениями на безопасность, произошел в это воскресенье. На протяжении четырех часов доступ к любому аккаунту в Dropbox можно было получить без пароля , то есть введя вместо пароля что угодно. Причиной послужило изменение в коде программы-сервера, очевидно, протестированное не очень внимательно, если протестированное вообще.

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