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

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

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

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

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

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

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

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

Проявляйте сдержанность

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

А что, если нам упростить ситуацию? Почему бы не стереть как можно больше личной информации и не сделать это как можно раньше? Нужно ли нам при регистрации запроса пользователя навечно сохранять весь IP-адрес или можно заменить последние несколько цифр символами «x»? Нужно ли сохранять чьи-то имя, возраст, пол и дату рождения, чтобы выложить предложения о покупке товара, или достаточно будет информации о примерном возрасте и почтового индекса?

Положительно ответив на эти вопросы, можно получить множество преимуществ. Во-первых, если не хранить эти данные, то никто их не сможет украсть. Во-вторых, если они у вас не хранятся, то никто (например, какое-нибудь правительственное агентство) не сможет их запросить!

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

Человеческий фактор