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

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

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

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

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

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

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

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

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

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

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

Рис. 9.5. Более безопасная система, используемая в проекте MusicCorp