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

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

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

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

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

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

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

Вернемся к проекту MusicCorp, объединив ряд концепций, чтобы посмотреть, где и в какой степени следует применить ряд технологий обеспечения безопасности. Основное внимание мы уделим обеспечению безопасности передаваемых и просто хранящихся данных. На рис. 9.4 показан поднабор всей системы, подлежащий анализу и страдающий от нашего вопиющего невнимания к вопросам его безопасной работы. Все данные здесь отправляются с использованием простого старого протокола HTTP.

Рис. 9.4. Поднабор проекта MusicCorp, который, к сожалению, не обладает безопасной архитектурой

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