Войти в систему
Войти с помощью соц. сетей:
В это трудно поверить, но многие системы до сих пор редактируются в режиме реального времени, непосредственно на сервере. Это очень опасно, так как любая ручная работа чревата ошибками, а резервная копия текущей версии кода отсутствует. Нельзя проверить код на наличие допущенных ошибок, так как он уже работает, а вместе с ним и все его ошибки. К тому же со временем приложение будет меняться, и, если по какой-то причине сервер перестанет работать или кто-то удалит файл либо отформатирует компьютер, оно исчезнет. Представьте, каково это – в одно мгновение потерять несколько лет работы.
Использование репозитория кода (иногда называемого библиотекой кода, контролем версий, контролем исходного кода) является передовой практикой в IТ-отрасли. В репозитории хранится код вместе со всеми внесенными в него изменениями. В нем записывается, когда, кто, что изменил, и в любое время можно произвести откат приложения к предыдущей версии. В качестве бонусной функции некоторые репозитории кода могут также вводить код в эксплуатацию, регистрировать ошибки и многое другое. Репозиторий кода – лучший друг разработчика, и инженеру по безопасности приложений нужно быть хорошо с ним знакомым.
ВНИМАНИЕ. В репозитории кода не должны храниться секреты: пароли, строки подключения, хеши и все остальное, что необходимо приложению для работы и при этом должно оставаться скрытым. Если же секрет случайно попал в репозиторий, следует немедленно извлечь его оттуда и проанализировать причины произошедшего для предотвращения повторения инцидента.
Если кто-то в организации по привычке редактирует код на сервере в реальном времени, он создает угрозу безопасности. Отсутствие резервной копии кода, наличие у этого человека доступа для записи к производственным серверам, молчание системы предупреждения о нарушении безопасности в ответ на эти действия и сам факт нарушения политики безопасности организации – все это достаточные причины, чтобы считать такое вмешательство инцидентом безопасности.
ВНИМАНИЕ. Ситуация, когда рабочий сервер может быть поврежден, отформатирован, затоплен или иным образом уничтожен, кажется маловероятной, но со мной такое случалось неоднократно. По мере продвижения к использованию публичного облака данная проблема появляется все реже, но лишь небольшой процент всех приложений в мире размещается в публичном облаке. Многие компании создают собственные центры обработки данных (по множеству причин). Независимо от того, где находится приложение, всегда нужно иметь самую последнюю копию в системе контроля версий.
Многие типы IDE позволяют разработчикам публиковать свои приложения в различных средах непосредственно с места написания кода. Данный процесс иногда ласково называют «ПКМ → Опубликовать», поскольку именно эти команды обычно используются для выполнения действия. Если разработчик уже выполнил свои модульные тесты, он выкладывает их в dev- или test-среду, и приложение становится частью большой системы. Данный процесс нередко является частью каскадной или гибкой модели разработки при исправлении ошибки или при переходе разработчика в среду разработки для выполнения тестирования до перемещения приложения в QA (среду обеспечения качества), UAT (среду для пользовательского приемочного тестирования), Preprod (копию эксплуатационной среды, которая часто используется для стресс-тестирования или тестирования производительности), а затем, наконец, prod. Сюда могут быть включены и другие среды.
По возможности следует убедиться, что разработчики выполняют модульные тесты перед отправкой кода куда-либо. Нет смысла в том, чтобы они отправили код в dev-отдел, провели там кучу тестов, а затем поняли, что половина модульных тестов не пройдена, и вернулись к проектированию. Если вы работаете в организации, которая продвигает код таким образом, нужно будет очень постараться, чтобы получить согласие на добавление модульных тестов, ориентированных на установленные цели обеспечения безопасности.
Также необходимо добавлять тестирование безопасности к другим средам и этапам тестирования, с учетом наличия времени и загруженности других команд.
И, конечно, следует максимально автоматизировать тесты.
Поскольку разработчики являются разработчиками, многие компании создают свои собственные системы развертывания, которые переносят изменения из среды в среду, обеспечивают получение различных разрешений и документируют все произведенные действия. Большой победой для всей команды будет добавление тестирования безопасности к любому из вышеперечисленных этапов. Например, пусть первая среда запускает сканирование состава программного обеспечения (SCA) и возвращает код разработчику при результатах «высокого» или «среднего» уровня важности. Если вам удастся заручиться поддержкой, вы сможете выполнить свою работу в рамках системы такого типа.
Однако пользовательская система развертывания обязательно должна проходить проверки безопасности. Если кто-то получит возможность манипулировать системой, он сможет опубликовать все, что пожелает, или добавить в базу кода лишнее. Необходимо рассматривать пользовательскую систему развертывания как критически важное приложение организации.
«Самодельные» системы развертывания должны быть созданы с учетом всех применяемых передовых практик в области разработки. Иногда разработчики забывают, что инструменты, которые они создают для своей работы, имеют значительную ценность для бизнеса. Как и любое другое ценное приложение в компании, системы развертывания должны иметь резервные копии, проходить тесты и отвечать требованиям безопасности жизненного цикла системы. Все действия с ними должны быть записаны в журнал, а код сохранен в репозитории.
Войти с помощью соц. сетей: