Журнал "Системы Безопасности" № 5‘2021

S E C U R I T Y A N D I T M A N A G E M E N T 43 дит в облачной инфраструктуре. Как правило, провайдер предоставляет специализированные сервисы, позволяющие реализовать такой мониторинг (например, Cloudtrail или Audit Trails). все события из этих сервисов можно экс- портировать в SIEM и настроить там необходи- мые алерты. 6. Обязательно использовать многофакторную аутентификацию для доступа к облаку Данная мера является обязательной при использовании облака, так как при компроме- тации привилегированной учетной записи можно полностью потерять контроль над обла- ком и, следовательно, всеми бизнес-процесса- ми, реализованными с помощью облачных сер- висов. 7. Контролировать целостность контейнеров и используемого программного обеспечения использование принципов безопасной разра- ботки – важнейший фактор обеспечения необходимого уровня безопасности совре- менных веб-сервисов. Так как внедрить вре- доносный код можно на всех этапах жизнен- ного цикла ПО, крайне важно обеспечить без- опасность кода, начиная с этапа проектирова- ния и разработки и до ввода приложения в эксплуатацию. Риск№2. Доступность сервиса вторым по важности риском является наруше- ние доступности сервиса по вине провайдера. это обусловлено тем, что любые технологиче- ские сбои в инфраструктуре провайдера или политические ограничения могут оказать пря- мое влияние на работу зависимого сервиса. Чаще всего данный риск является следствием реализации таких угроз, как: l ограничение доступа из-за санкционных ограничений; l любой иной отказ в предоставлении услуги со стороны провайдера; l технический сбой на оборудовании провай- дера. Кроме того, необходимо учесть, что несанкцио- нированный доступ к консоли управления со стороны внешнего нарушителя с большой долей вероятности приведет к нарушению работы сервиса. Для снижения вероятности возникновения этого риска необходимы следующие меры. 1. Обязательное резервирование данных, исходного кода приложений и описания инфраструктуры в месте, не зависящем от текущего провайдера облачных сервисов Если возникнет ситуация, кода доступ к облаку станет невозможен, то это означает утрату всего, что находится в облаке. При этом для восстановления работы сервиса на других ресурсах обязательно необходимо иметь резервную копию данных и исходного кода боевых сервисов. Если эти данные отсутствуют, то работу сервиса будет практически невозмож- но восстановить. Резервные копии необходимо хранить в не зависящем от используемого обла- ка месте, например в другом облачном сервисе или собственном физическом сервере. Для ускорения процесса восстановления работы сервиса на других ресурсах рекомендуется использовать подход "инфраструктура как код" с обязательным резервированием описания используемой инфраструктуры. 2. Запрет на использование рутового аккаунта для целей администрирования Рутовый аккаунт – это аккаунт, который исполь- зовался для регистрации в облачном сервисе. Он обладает наиболее широкими правами, и если его потерять, то будет крайне сложно вос- становить контроль над облаком. Поэтому реко- мендуется максимально снизить риск компро- метации такого аккаунта, возникающий при использовании его для администрирования или выполнения иных задач. 3. Мониторинг сообщений от провайдера о техническом обслуживании или деградации оборудования Провайдер достаточно часто осуществляет тех- ническое обслуживание оборудования, иногда это бывает связано, например, с реградацией жестких дисков. Бывает, что для проведения работ провайдеру необходимо выключить ваш сервис. Как правило, он предупреждает об этом, чтобы можно было оперативно переклю- читься на резервное оборудование. но если игнорировать сообщения провайдера, то воз- можна ситуация, когда сервис перестанет рабо- тать из-за того, что ключевой сервер вдруг выключился. 4. Отдельные OU для администраторов, безопасников, тестировщиков, разработчиков и основной инфраструктуры Разделять функционал важно как минимум по двум причинам. Прежде всего, инфраструктура, используемая для разработки или тестирова- ния, очень часто меняется, а более низкие тре- бования безопасности повышают вероятность компрометации сервисов или учетных записей. в таком случае отделение этих сегментов от производственного позволит минимизировать влияние данных сегментов на работу боевого сервиса. Что касается отделения функций без- опасности в отдельный сегмент, то это прежде всего необходимо для обеспечения безопасно- сти журналов аудита. Риск№3. Избыточная стоимость Простота и скорость выделения ресурсов в облаке – неоспоримое преимущество такого подхода. это позволяет быстро масштабиро- вать сервисы при увеличении количества запросов от клиентов. С другой стороны, важно помнить, что если не ограничивать выделение ресурсов, то в итоге стоимость использования этих ресурсов существенно превысит возможную прибыль. Особенно остро проблема неограниченного масштаби- рования проявляется во время DDoS-атак. Если сервис будет пытаться обработать все посту- пающие запросы, то это в итоге приведет к тому, что стоимость ресурсов превысит воз- можные пределы, а базы данных будут забиты бесполезной информацией. важно обратить внимание на эффективность использования ресурсов. Если, например, были арендованы мощные серверы, которые загру- жены менее чем на 10%, это также приведет к перерасходу и снижению прибыли. Для минимизации возможных последствий необходимы такие шаги. 1. Лимитирование масштабируемых сервисов Как правило, все облачные сервисы выделяют ресурсы в рамках квот. Поэтому достаточно ука- зать такие значения квот на ресурсы, стоимость которых будет приемлемой. 2. Использование средств защиты от атак на прикладном уровне это требование является обязательным как минимум по двум причинам. во-первых, запро- сы от злоумышленников не приносят никакого дохода, а значит, нет смысла тратить ресурсы на их обработку. во-вторых, отсутствие защиты на прикладном уровне существенно повышает риск успешной атаки на сервис. При этом воз- можны различные варианты реализации защи- ты на прикладном уровне, начиная от опенсорс- ного или промышленного межсетевого экрана уровня приложения и заканчивая сервисами очистки трафика. 3. Контроль загрузки виртуальных серверов При аренде виртуального сервера оплачивается его полная стоимость. Следовательно, чем меньше загружен сервер, тем дороже в итоге обходится его эксплуатация. Данные по исполь- зованию ресурсов можно получить из логов операционной системы сервера. Риск№4. Несанкционированное изменение ПО Программное обеспечение отвечает за все аспекты работы интернет-сервисов. в условиях использования облачных сервисов крайне важно обеспечить целостность приложения, от написания исходного кода до запуска этого кода на боевом сервисе. При использовании внешних сервисов появляются такие дополни- тельные угрозы, как внесение несанкциониро- ванных изменений в собранные контейнеры и внедрение вредоносного кода в процессе компиляции. Для минимизации данного риска следует обес- печить полный контроль за репозиторием исходного кода и регистром контейнеров, а также за целостностью программного обес- печения на всем протяжении его жизненного цикла. n www.secuteck.ru октябрь – ноябрь 2021 СПЕЦПРОЕКТ БЕзОПаСнОСТь БанКОв в эПОху ЦифРОвизаЦии Ваше мнение и вопросы по статье направляйте на ss @groteck.ru П ервоочередным риском при использовании облачных сервисов является несанкционированный доступ к конфиденциальной информа- ции со стороны провайдера услуг. Затем идет нарушение доступности сервиса по вине провайдера