Безопасность как код (англ. Security as Code, SaC) – это вплетение безопасности в DevOps, в частности с использованием кода. Хотя некоторые утверждают, что SaC – это то же самое, что и DevSecOps, большинство сходятся во мнении, что это разные вещи: DevSecOps воплощает все действия по обеспечению безопасности, которые выполняются в рамках жизненного цикла разработки системы по методологии DevOps, а безопасность как код – это только закодированные части.
Примеры SaC: добавление кода в инфраструктуру как код для улучшения политик безопасности, написание кода для реализации или автоматизации требований безопасности, создание негативных модульных тестов (модульные тесты, которые обеспечивают правильное экстренное завершение работы, также известные как регрессионное тестирование безопасности), а также добавление сценариев тестирования безопасности в конвейеры.
Еще один пункт, который следует отметить в данном разделе, – это «пользовательские истории безопасности». Если в вашей компании создаются пользовательские истории, в их число должны входить также истории, касающиеся инцидентов безопасности, таких как атака методом грубой силы, XSS или инъекционная атака. Создание пользовательских историй безопасности гарантирует, что все другие усилия по тестированию, основанные на пользовательских историях, будут включать в себя обеспечение безопасности.
Пользовательские истории безопасности должны быть основаны на обеспечении целостности триады CIA, предотвращении моделей угроз, применении любых стандартов или политик, связанных с обеспечением безопасности, и реализации требований безопасности проекта.
Вот примеры пользовательских историй.
Платформа как услуга (англ. Platform as a Service) – это инфраструктура, создаваемая и предоставляемая поставщиками публичных облаков для размещения приложений и API. Поставщик облака берет на себя ответственность за обеспечение безопасности платформы, включая установку патчей и настройку большинства параметров конфигурации. Клиент приобретает платформу как услугу, выбирает ее желаемый размер, операционную систему (ОС) и т. д., после чего размещает на ней свое приложение. На платформу как услугу можно поместить контейнер или код, и она его просто запустит. Она хороша тем, что обслуживание и большая часть обеспечения безопасности не являются проблемой пользователя. Тем не менее некоторые аспекты обеспечения безопасности все же входят в его обязанности. Необходимо узнать, на какие конфигурации безопасности PaaS нужно обращать внимание, и затем поработать над ними соответствующим образом.
Хотя это и не относится к PaaS, включение мониторинга и протоколирования при использовании облачных сервисов – целесообразное, хотя и не дешевое решение. Основные затраты, связанные с мониторингом, – место, занимаемое журналами: размер журналов огромен. Тем не менее без ведения журналов и мониторинга невозможно быть в курсе атак, совершенных на PaaS и другие веб-ресурсы.
Все публичные веб-активы должны быть доступны только по зашифрованным каналам, что означает необходимость использования TLS/HTTPS. Следует обеспечить наличие заголовков безопасности, включить и правильно настроить другие конфигурации безопасности, которые находятся под вашим контролем. Наконец, вы как потребитель PaaS несете полную ответственность за создание безопасного программного обеспечения, размещаемого на платформе. Не имеет значения, что PaaS и публичное облако используют модель разделяемой ответственности. Поставщик облака не отвечает ни за какой ущерб или потери, понесенные из-за размещения в облаке небезопасного приложения, – это сфера ответственности клиента.
СОВЕТ. Независимо от того, какого поставщика услуг публичного облака вы решите использовать, прежде всего необходимо ознакомиться и согласиться с политикой разделяемой ответственности, которая определяет, какие конфигурации и задачи по обеспечению безопасности входят в сферу ответственности клиента и поставщика. В обязанности поставщика входят исправления, ротация сертификатов TLS, управление ключами шифрования и многое другое. Обязанностями клиента являются: обеспечение безопасности приложений, размещенных на PaaS; решение о принудительном использовании HTTPS; решение о принятии старых версий TLS (все версии SSL будут блокироваться) и многое другое.
Инфраструктура как услуга (англ. Infrastructure as a Service) является еще одной услугой, предлагаемой поставщиками публичных облаков. По сути, клиент выбирает операционную систему, аппаратное обеспечение и любые другие спецификации, и на основе его запросов в облаке автоматически создается такая инфраструктура. Например, чтобы создать виртуальную машину Linux с 4 Гб места на жестком диске и 8 Гб памяти, нужно заполнить онлайн-форму, нажать кнопку покупки – и в мгновение ока появится виртуальная машина, соответствующая этому описанию.
Как и платформа как услуга (PaaS), инфраструктура как услуга (IaaS) следует модели разделяемой ответственности. Но, в отличие от PaaS, IaaS требует, чтобы конечный пользователь (то есть вы) устанавливал патчи и выполнял прочее обслуживание предоставленной инфраструктуры. Облачный провайдер будет защищать физический центр обработки данных и обеспечивать надлежащий уход за физическими машинами, но не будет осуществлять поддержку предоставленной виртуальной машины – это ответственность клиента. Очень важно понимать разницу между PaaS и IaaS.
Лучшие практики защиты IaaS аналогичны тем, что применяются для всех ресурсов инфраструктуры: следование принципу наименьших привилегий; использование надежной идентификации, аутентификации и авторизации; подключение их к своей сети с использованием схем нулевого доверия и предположения взлома; регулярный выпуск исправлений, следование руководству по усилению безопасности и остальные действия по защите инфраструктуры.