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

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


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

Современные крупные 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
    • fmlnuser
      Автор fmlnuser
      Добрый день, не работают системные переменные в контроле приложений. Как то можно включить поддержку?
      Переменные на подобии этих:
      %system32%
      %osdrive% 
      и тд
    • Acteon_927
      Автор Acteon_927
      Можно ли использовать резервное хранилище Kaspersky Password Manager для восстановления днных в новом хранилище KPM, если утерян мастер-пароль к нему? Сколько резервных хранилищ может быть и где их можно хранить? Можно ли использовать проводник для создания резервных копий?
       
    • shidogbc
      Автор shidogbc
      Добрый вечер, позавчера столкнулся с проблемой, что использование gpu в играх очень сильно увеличилось. Если раньше в Valorant оно было около 5%, то резко стало 50-60%. При заходе в Counter Strike 2 игра вообще не запускалась (отображался экран загрузки и зависал на нем), а использование gpu было 100% в момент входа. Увеличение использования GPU  произошло во всех играх (Apex Legends, в League of legends работал лаунчер, но сама игра не работала).
      Хотелось бы узнать, с чем это может быть связано.
      Изначально подумал, что поймал вирус или майнер (который работает при заходе в игры). На компе был обнаружен chromium:page.malware.url и процесс лечения можно посмотреть в этой теме -> 
      До начала лечения вируса почитал о возможных проблемах, кто-то писал, что недавно драйвера амд начали конфликтовать с кастомными разрешениями экрана. Решил удалить папку в стиме, в которой хранится информация о персональных настройках, чтобы убрать кастомные разрешения. После этого Counter Strike 2 начала запускаться, но использование GPU всё равно осталось высоким (не думаю, что у меня какая-либо проблема с драйверами так как изначально, в момент повышения использования gpu, у меня стояли прошлогодние драйвера; подумал, что проблема с ними - обновил до актуальных, но ничего не изменилось; чуть позже поставил драйвер августа 2024 года).
      Итак, подходя к сегодняшнему состоянию, после удаления вируса, описанного в вышеуказанной теме, использование GPU в играх снизилось, но оно всё равно в разы выше, чем было ранее (3 дня назад всё было в порядке, сейчас 40-50% в зависимости от игры). За этот период как таковых обновлений игр не было.
    • sammi
      Автор sammi
      Здравствуйте!
      Коллеги, помогите разобраться плз. 
      Есть в KSC политика на одну группу компьютеров, в которой включен контроль устройств. Там есть ряд разрешенных устройств и мне нужно добавить в разрешённые виртуальный сидиром винды. Чтобы можно было с  iso работать. 
      Пробовал через "Добавить->Сформировать правила на основе данных системы" и он как-бы добавляет  Virtual_DVD-ROM, но всё равно не работает. Судя по всему, мой предшественник также делал и у него тоже не взлетело.
      Единственное, что я заметил, что DeviceID которое в правиле и в событие, которое генерится при срабатывании защиты отличаются.  
      В правиле "SCSI\CDROM&VEN_MSFT&PROD_VIRTUAL_DVD-ROM\000001", а в событии перед 000001 ещё символы есть. 
       
      Я выгрузил правила в .xml, там добавил дополнительные символы в DeviceId и оставил только одно моё правило в этой xml. Делаю "Импорт из файла XML->Добавить правила к существующим" и получаю ошибку чтения правил из файла. Синтаксис внутри вроде корректный. 
       
      Может я сильно усложняю и как-то можно проще сделать?  С KSC только знакомлюсь)
       
       
×
×
  • Создать...