Бессерверные приложения

Бессерверное программное обеспечение – это программное обеспечение, которое размещается или работает на сервере не на постоянной основе. Оно доступно только при непосредственной ссылке на него. Вызываемое бессерверное приложение открывает контейнер, выполняет свой код, затем самоуничтожается, отдавая все ресурсы обратно экосистеме для использования другим процессом. Эфемерность (недолговечность) означает, что бессерверное программное обеспечение создает меньшую поверхность атаки, поскольку оно редко находится в запущенном состоянии (что часто требуется для атаки), следовательно, сервер для атаки также отсутствует. Главное преимущество бессерверных приложений заключается в том, что плата за них производится только по факту использования, то есть они стоят намного меньше, чем обычные приложения. Оплата только девяти минут времени работы в месяц может значительно сократить выставленные за облако счета. Однако в отношении безопасности здесь действуют те же принципы, что и для любых других приложений. Кроме того, нужно обратить внимание на еще несколько пунктов. Взглянем на них поближе.

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

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

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

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

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

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

Хотя это касается каждого приложения, крайне важно, чтобы секреты из бессерверных приложений хранились в тайнике, а не в библиотеке кода или базе данных.

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

При использовании конвейера CI/CD следует подумать о добавлении сканирования безопасности для проверки конфигурации бессерверных приложений.

Наконец (это также относится ко всем приложениям), необходимо убедиться, что все компоненты, от которых зависит бессерверное приложение, проверены на отсутствие угроз безопасности, а все найденные в нем уязвимости устранены.

Инфраструктура как код (IaC)

Инфраструктура как код (IaC), иногда называемая «конфигурация как код», – это создание сценариев или файлов конфигурации в виде кода для автоматизации развертывания. Использование IaC является частью DevOps, которая обеспечивает возможность выпуска инфраструктуры через конвейер CI/CD. Можно также добавить в инфраструктуру средства усиления безопасности в закодированном формате и тем самым повысить ее защиту с момента создания. Не лишним будет сканирование безопасности для проверки инфраструктуры как кода по мере ее продвижения по релизному конвейеру. IaC позволяет быстрее не только выпускать исправления и изменения инфраструктуры, но и внедрять исправления безопасности и изменения в укреплении инфраструктуры в эксплуатационные системы. Рабочий процесс показан на рис. 8.3.

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

Рис. 8.3. Рабочий процесс инфраструктуры как кода

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

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

ОСТОРОЖНО ПРЕДОСТАВЛЯЙТЕ РАЗРЕШЕНИЯ

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

При работе с инфраструктурой как кодом необходимо убедиться, что все изменения проводятся по соответствующей процедуре. Нельзя войти в рабочую машину и что-то поменять в конфигурации вручную, потому что тогда нарушится весь процесс. Вероятность случайного внесения ошибок, уязвимостей или слабых мест в инфраструктуру в таком случае значительно повышается, поскольку не проводятся все тесты безопасности и другие необходимые проверки, являющиеся частью CI/CD-конвейера.

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

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