Когда ваши микросервисы начинают тихо общаться: безопасность имеет значение

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

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

В чем проблема?

Пока не спешите проверять код. Зачастую корень проблемы заключается не в технической глубине, а в идее. Вы считаете, что «внутренняя связь» безопасна, поэтому можете выполнять аутентификацию как хотите и экономить на шифровании передачи, если можете. Или каждая команда использует разные стандарты безопасности. Служба А чрезвычайно строга, но дверь службы Б открыта.

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

Итак, как же выглядит надежный подход?

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

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

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

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

Легко сказать, но много ли хлопот будет сделать? Именно здесь многие команды и застревают.

Как сделать, чтобы было не «больно»?

Главное – не превращать безопасность в тяжкое бремя. Его должно быть легко вплетено в ваш процесс разработки. Например, политика безопасности должна автоматически генерироваться как базовая часть в момент создания службы, а не добавляться в последнюю очередь.

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

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

Автоматизация — ваш друг. Настройка правил безопасности вручную рано или поздно приведет к ошибкам. Попробуйте использовать декларативный подход для определения политик и позвольте инструменту автоматически выполнять и синхронизировать их. Это экономит массу времени и исключает человеческую халатность.

Кто-нибудь на самом деле это делает?

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

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

сделать первый шаг

Если вы чувствуете, что растерялись, лучше начать с тщательного «коммуникативного аудита». Достаньте свою архитектурную схему, нарисуйте все потоки данных между сервисами, а затем задайте себе несколько простых вопросов: зашифрованы ли данные в этой линии? Идентифицирован ли звонивший? Вы дали слишком много разрешений?

Ответ может вас удивить. Поиск слабых звеньев — это начало укрепления.

Безопасность микросервисов — это не «проект», который можно решить раз и навсегда. Это продолжающееся состояние. Как и для поддержания здоровья, это требует ежедневных привычек и нескольких инструментов. Если вы подумаете об этом слишком комплексно, вы не осмелитесь это сделать; если вы думаете об этом слишком просто, вы столкнетесь со скрытыми опасностями.

В конечном счете, разве это не просто позволить военнослужащим свободно общаться, не позволяя подслушивать частные разговоры? Найдите этот баланс, и ваша система станет по-настоящему гибкой, но при этом позволит людям спать спокойно. Кпове глубоко проложил этот путь. Мы знаем, где могут возникнуть ловушки, а также знаем, как идти более уверенно. Безопасность стоит вашего времени и усилий, чтобы обеспечить ее правильность.

Основанная в 2005 году,мощностьбыла посвящена профессиональному производителю компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в технологии модульных приводов,мощностьобъединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, обеспечивая эффективные и индивидуальные решения для интеллектуальных систем привода.мощностьпредоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.