Создание микросервисов

Система обнаружения вторжений (IDS) может вести мониторинг сетей или хо­стов с целью обнаружения подозрительного поведения и оповещения о проблемах по мере их возникновения. Система предотвращения вторжений (IPS) вдобавок к мониторингу подозрительных действий способна вмешиваться в них, не давая им совершиться. В отличие от брандмауэра, который в первую очередь анализирует окружающую обстановку, препятствуя проникновению вредоносного кода, IDS и IPS активно выискивают подозрительное поведение внутри периметра. Когда все начинается с нуля, благоразумнее устанавливать IDS. Эти системы основаны на эвристическом анализе, как и многие приложения-брандмауэры, и вполне возможно, что универсальный стартовый набор правил будет либо слишком мягким, либо недостаточно мягким по отношению к поведению вашего сервиса.

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

Обособление сетей

При использовании монолитной системы возможности структурирования сетей для предоставления дополнительной защиты ограничены. Но, применяя микросервисы, вы можете поместить их в разных сегментах сети, чтобы получить дополнительный контроль над тем, как сервисы общаются друг с другом. К примеру, AWS дает возможность автоматического предоставления виртуального закрытого облака (VPC), позволяющего хостам находиться в отдельных подсетях. Затем можно указать, какие VPC-облака могут видеть друг друга, установив правила пиринга, и даже направлять трафик через шлюзы для доступа к прокси-серверу, очерчивая фактически несколько периметров, на которых могут быть предприняты дополнительные меры безопасности.

Это дает вам возможность сегментировать сети на основе командной принадлежности или, возможно, степени риска.

Операционная система

Работа систем зависит от большого количества программных средств, создава­емых не нами, и может иметь уязвимости с точки зрения безопасности, которые способны отразиться на нашем приложении (имеются в виду операционные си­стемы и другие вспомогательные средства, под управлением которых оно работает). Здесь вам может пригодиться ряд рекомендаций общего плана. Начните с запуска сервисов исключительно в качестве пользователей операционной системы, имеющих как можно меньше прав доступа, чтобы при компрометации их учетной записи мог быть нанесен минимальный вред.

Затем вносите исправления в свои программные средства. И делайте это регулярно. Этот процесс должен быть автоматизирован, и вы должны быть осведомлены о том, что ваши машины не синхронизированы с самыми последними пакетами исправлений. Здесь могут пригодиться такие средства, как SCCM от компании Microsoft или Spacewalk от RedHat, которые могут оповестить вас о том, что на машине не установлены самые последние исправления, и, если требуется, иници­ировать обновление программных средств. Если используются такие средства, как Ansible, Puppet или Chef, то проблем с автоматизированным получением изменений у вас, скорее всего, нет, поскольку эти средства могут успешно решать эту задачу, но абсолютно все за вас они делать не будут.

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

Если вы используете Linux, то нужно обратить внимание также на наличие модулей безопасности для самой операционной системы. К примеру, AppArmour позволяет определить ожидаемое поведение вашего приложения и в нем имеется ядро, которое будет постоянно следить за приложением. Как только оно начнет делать что-нибудь, чем не должно заниматься, ядро вмешается в его работу. Кроме AppArmour, имеется также SeLinux. Хотя с технической точки зрения оба модуля могут работать на любой современной Linux-системе, на практике некоторые дистрибутивы поддерживают один из них лучше, чем другой. К примеру, AppArmour используется по умолчанию в Ubuntu и SuSE, а SELinux традиционно хорошо поддерживается дистрибутивом RedHat. Самым последним вариантом таких модулей является GrSSecurity, разработанный с прицелом на то, чтобы стать проще в использовании, чем AppArmour или GrSecurity, и с попыткой расширения до их возможностей, но ему для работы требуется собственное ядро. Я бы советовал присмотреться ко всем трем модулям, чтобы понять, который из них вам больше подойдет, но мне нравится идея использования в работе еще одного уровня защиты и профилактики.

Рабочий пример