Проблемы безопасности, связанные с микросервисами

Введение

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

Почему микросервисы меняют взгляды на безопасность

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

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

Испытания

Большая площадь для атаки

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

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

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

Нам нужно стремиться уменьшить эту зону атаки.

Слияние разработки и эксплуатации (DevOps)

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

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

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

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

Интегрированная безопасность по дизайну

При монолитном подходе безопасность в основном была второстепенной задачей. Только после завершения заявки безопасность рассматривалась. Такого подхода к безопасности недостаточно при использовании микросервисов.

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

Вы стремитесь достичь следующего путем интеграции безопасности с самого начала:

• Усиленная и комплексная безопасность
• Улучшенный интеллект
• Улучшенный мониторинг
• Более эффективное применение политики
• Способность решать вопросы управления и соблюдения требований по дизайну

Лучшие практики для защиты микросервисов

Выявление и мониторинг межсервисных взаимодействий и коммуникаций

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

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

Улучшенная видимость и контроль

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

Изолирующие услуги

Микросегментация — это средство изоляции приложений за счет применения политик безопасности. Это должно быть сделано не на уровне периметра, а скорее на уровне кластера, чтобы быть эффективным. Идея состоит в том, чтобы ограничить службы, вставив вокруг них элементы управления.

Безопасные данные

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

Автоматизация управления политиками

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

Масштабируемость и производительность

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

Аутентификация, авторизация и контроль доступа

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

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

Вывод

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

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