Перейти к содержанию

Защита контейнеризации на всех этапах разработки и использования


Рекомендуемые сообщения

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

Чем выгодна контейнеризация в разработке и эксплуатации

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

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

Наиболее распространенным инструментом для создания и хранения образов контейнеров, безусловно, является Docker, а оркестрацию контейнерных нагрузок чаще всего реализуют при помощи Kubernetes, Docker Swarm или Red Hat OpenShift.

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

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

Если грамотно внедрить требования контейнерной безопасности в процесс разработки и сборки, то это существенно продвинет организацию на пути к полноценной реализации методологии DevSecOps.

 

Посмотреть статью полностью

Ссылка на комментарий
Поделиться на другие сайты

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • KL FC Bot
      От KL FC Bot
      Уже сегодня технологии на базе ИИ внедрены в каждой второй компании, а за ближайшие два года к ним присоединится еще 33% коммерческих организаций. ИИ в том или ином виде будет внедрен повсеместно. Экономический эффект, который получают компании от внедрения, варьируется от повышения удовлетворенности клиентов до прямого роста выручки. По мере того как понимание сильных и слабых сторон ИИ-систем бизнесом будет углубляться, эффективность только увеличится. Но уже сейчас очевидно, что о рисках, которые несет внедрение ИИ, нужно подумать заранее.
      Даже ранние примеры внедрения демонстрируют, что цена ошибки ИИ-системы может быть высока и может выражаться в том числе во влиянии на репутацию, отношения с клиентами, здоровье пациентов и многое другое. А если учесть еще и киберфизические системы вроде автономных автомобилей, то вопросы безопасности станут еще острее.
      Внедрять безопасность постфактум, как это было с предыдущими поколениями технологий, будет дорого и порой невозможно. Чтобы в этом убедиться, достаточно найти свежие оценки ущерба, который мировой экономике наносит киберпреступность: на 2023 год это $8 трлн. Неудивительно, что страны, претендующие на технологическое лидерство в XXI веке, торопятся внедрить регулирование ИИ (например, China’s AI Safety Governance Framework, EU AI Act, US Executive Order on AI). Но в законах редко указываются технические подробности и практические рекомендации — это не их задача. Поэтому для практического применения любых регуляторных требований формата «обеспечить надежность и этичность ИИ, а также контролируемость его решений» необходимы конкретные практические рекомендации, позволяющие достичь этого результата.
      Чтобы помочь практикам, внедряющим ИИ уже сегодня, а также сделать будущее нашего мира более безопасным, специалисты «Лаборатории Касперского» при участии Эллисон Вайлд, члена команды по функциональной совместимости Сети по вопросам политики в области искусственного интеллекта Форума ООН по управлению Интернетом; доктора Мелодены Стивенс, профессора управления инновациями и технологиями школы государственного управления имени Мохаммеда бин Рашида; и Серхио Майо Масиаса, менеджера инновационных программ из Технологического института Арагона, создали набор рекомендаций. Документ был представлен в ходе семинара «Кибербезопасность в сфере ИИ: баланс между инновациями и рисками» на 19-м ежегодном Форуме по управлению Интернетом (UN Internet Governance Forum, IGF) для обсуждения с международным сообществом формирующих политику работы с AI экспертов.
      Следование описанным в документе практикам поможет инженерам, специалистам DevOps и MLOps, которые разрабатывают и затем эксплуатируют ИИ-решения, достичь высокого уровня защищенности и безопасности ИИ-систем на всех этапах их жизненного цикла. Рекомендации документа нужно индивидуально оценивать для каждого внедрения ИИ, поскольку их применимость зависит от разновидности ИИ и модели внедрения.
      Какие риски нужно учесть
      Многообразие применений ИИ вынуждает организацию учитывать очень разнородные риски:
      Риск от неиспользования ИИ. Звучит на первый взгляд забавно, но только сравнив выигрыш и потери компании от внедрения ИИ, можно правильно оценивать все остальные риски. Риски несоответствия регулированию. Быстро развивающееся регулирование ИИ делает этот риск динамичным, его нужно часто оценивать заново. Кроме регулирования ИИ как такового, нужно учитывать сопутствующие риски, например нарушения законов по обработке персональных данных. ESG-риски, то есть социально-этические риски применения ИИ, риски раскрытия чувствительной информации и риски для экологии. Риск нецелевого использования ИИ-сервисов пользователями — от шуточных до злонамеренных сценариев. Угрозы ИИ-моделям и наборам данных, применявшимся в тренировке. Угрозы сервисам компании, возникающие при внедрении ИИ. Возникающие при этом угрозы данным, которые обрабатываются в рамках этих сервисов. При этом «под капотом» трех последних групп рисков находятся все угрозы и задачи, традиционные для ИБ в сложных облачных инфраструктурах: контроль доступа и сегментация, управление уязвимостями и обновлениями, создание систем мониторинга и реагирования, контроль цепочек поставок.
       
      View the full article
    • sammi
      От sammi
      Здравствуйте!
      Коллеги, помогите разобраться плз. 
      Есть в KSC политика на одну группу компьютеров, в которой включен контроль устройств. Там есть ряд разрешенных устройств и мне нужно добавить в разрешённые виртуальный сидиром винды. Чтобы можно было с  iso работать. 
      Пробовал через "Добавить->Сформировать правила на основе данных системы" и он как-бы добавляет  Virtual_DVD-ROM, но всё равно не работает. Судя по всему, мой предшественник также делал и у него тоже не взлетело.
      Единственное, что я заметил, что DeviceID которое в правиле и в событие, которое генерится при срабатывании защиты отличаются.  
      В правиле "SCSI\CDROM&VEN_MSFT&PROD_VIRTUAL_DVD-ROM\000001", а в событии перед 000001 ещё символы есть. 
       
      Я выгрузил правила в .xml, там добавил дополнительные символы в DeviceId и оставил только одно моё правило в этой xml. Делаю "Импорт из файла XML->Добавить правила к существующим" и получаю ошибку чтения правил из файла. Синтаксис внутри вроде корректный. 
       
      Может я сильно усложняю и как-то можно проще сделать?  С KSC только знакомлюсь)
       
       
    • Gillox
      От Gillox
      Добрый вечер. Сегодня сидел, смотрел видео и тут бац, вылетел синий экран с таким текстом внизу: "System_Thread_Exception_Not_Handled; что вызвало проблему: nvlddmkm.sys", после перезапуска, через 2 часа вылетел новый синий экран с ошибкой "kernel mode heap corruption". До синий экран с последней ошибкой тоже вылезал, но замечалось при играх в тяжелые игры. Как исправить эту ситуацию?
    • dexter
      От dexter
      Всем привет.
       
      Открыл меню Плюса и увидел сообщение (скрин). Ладно, залез в BIOS и включил виртуализацию и попутно (по совету в одной из профильных статей ЛК) параметр VT-d.
      Опять посетил Настройку защиты ввода данных и опять сообщение "... Обнаружено несовместимое устройство или программное обеспечение."
       
      Хорошо. По поводу устройства - ясен пень, имеется в виду модуль TPM . Но он у меня не установлен. Это я знаю точно, поскольку я его не покупал и не устанавливал ( как мне разъяснили в одном из магазинов,
      сие устройство запрещено к оф. продаже). Разъём на плате есть, а самого модуля - нету.
       
      Смотрим и читаем дальше много букв в одной из профильных статей от ЛК. И оказывается, что причин о несовместимости программного обеспечения может быть несколько - https://support.kaspersky.ru/common/safemoney/13713#block1
      то что вверху написано - не суть важно. Листаем список ниже. И что мы там видим ? А то, что под программным обеспечением имеется в виду в том числе Изоляция ядра и Smart App Control.
      У меня, на начальной стадии использования винды-11 Smart App Control отключен, т.к. находится в  режиме "Оценка".
       
      А теперь такой вопрос к разработчикам : нельзя как-то решить эту коллизию с Smart App Control , Изоляцией ядра и защитой ввода данных с использованием аппаратной виртуализации ?
      Или вы реально решили, что для функционирования Плюса в том виде, как Вы задумали , надо отключить несколько функций по обеспечению безопасности в самой системе ?


    • pacificae
      От pacificae
      Доброго времени. Исходные данные - на клиентском ПК отключил вручную защиту KES бессрочно. Вопрос - можно ли через KSC (в моем случае 13) включить защиту удалённо?
×
×
  • Создать...