Наличие системной архитектуры, состоящей из узкоспециализированных сервисов, дает нам больше свободы в реализации системы безопасности. Для тех частей, которые работают с наиболее конфиденциальной информацией или предоставляют наиболее полезные возможности, можно избрать оснащение с наиболее жесткими мерами безопасности. Насчет же других частей системы степень своего беспокойства можно значительно снизить.
Вернемся к проекту MusicCorp, объединив ряд концепций, чтобы посмотреть, где и в какой степени следует применить ряд технологий обеспечения безопасности. Основное внимание мы уделим обеспечению безопасности передаваемых и просто хранящихся данных. На рис. 9.4 показан поднабор всей системы, подлежащий анализу и страдающий от нашего вопиющего невнимания к вопросам его безопасной работы. Все данные здесь отправляются с использованием простого старого протокола HTTP.
Рис. 9.4. Поднабор проекта MusicCorp, который, к сожалению, не обладает безопасной архитектурой
Здесь имеются стандартные браузеры, которые наши клиенты используют для осуществления покупок в магазине. Здесь также вводится концепция стороннего шлюза лицензионных отчислений: мы начали работать со сторонней компанией, которая будет заниматься лицензионными отчислениями для нашего нового потокового сервиса. Она выходит с нами на связь, чтобы забрать записи о том, какая музыка и когда была востребована потоковым сервисом, то есть получить информацию, которую мы старательно скрываем от конкурирующих компаний. И наконец, мы выставляем напоказ данные нашего каталога для других сторонних организаций, позволяя им, к примеру, вставлять в сайты музыкальных ревю метаданные об артистах и песнях. Внутри нашего сетевого периметра имеется несколько сотрудничающих сервисов исключительно для внутреннего потребления.
В браузере мы будем использовать сочетания стандартного HTTP-трафика для незащищенного содержания, чтобы ему было позволено находиться в кэше. Все надежно защищенное содержимое безопасных, прошедших регистрацию страниц будет отправляться по протоколу HTTPS, который обеспечит клиентам дополнительную защиту, если они будут пользоваться, к примеру, открытыми WiFi-сетями.
Что же касается сторонней системы лицензионных отчислений, то нас волнует не только характер выставляемых данных, но и легитимность получаемых запросов. Здесь мы настаиваем на том, чтобы сторонние партнеры пользовались клиентскими сертификатами. Все данные отправляются по надежному зашифрованному каналу, увеличивая возможность убедиться в том, что их запросил известный нам человек. Нам, конечно же, нужно подумать и о том, что произойдет, если данные выйдут из-под нашего контроля. Будет ли наш партнер заботиться о них так же тщательно, как и мы?
Что касается снабжения данными каталога, нам бы хотелось, чтобы эта информация распространялась как можно шире, облегчая людям покупку нашей музыки! Но нам не хочется, чтобы этой возможностью злоупотребляли, а также хочется знать, кто использует наши данные. В этом случае наиболее подходящими для нас будут API-ключи.
Внутри сетевого периметра все обстоит немного тоньше. Как противодействовать тем, кто пытается пробраться в нашу сеть? В идеале нам хотелось бы как минимум воспользоваться протоколом HTTPS, но управлять им довольно хлопотно. Вместо этого мы решили (хотя бы на первых порах) поместить всю работу в прочный сетевой периметр, имеющий настроенный соответствующим образом брандмауэр и выбирающий для отслеживания вредоносного трафика (например, сканирования портов или атак, вызывающих отказ от обслуживания) подходящее оборудование или программные приспособления для обеспечения безопасности.
При этом мы побеспокоились о некоторых наших данных и о тех местах, где они находятся. Нас не волнуют данные сервиса каталогов, ведь мы же сами захотели, чтобы они попали в общее пользование, и даже предоставили для этого соответствующий API-интерфейс! Но нас очень беспокоит безопасность клиентских данных. Поэтому мы решили зашифровать данные, хранящиеся в клиентском сервисе, и расшифровывать их при чтении. Если взломщики проберутся в нашу сеть, они смогут выдавать запросы к нашему API-интерфейсу клиентской службы, но текущая реализация не позволит извлекать клиентские данные в больших объемах. Если же реализация позволяет подобные действия, то лучше рассмотреть возможность использования для защиты информации клиентских сертификатов. Даже если взломщики проникнут в машину и в запущенную на ней базу данных и распорядятся скачать все ее содержимое, им понадобится доступ к ключу, чтобы расшифровать данные, которыми они собираются воспользоваться.
На рис. 9.5 показана окончательная картина происходящего. Как видите, наш технологический выбор основан на понимании характера защищаемой информации. Возможно, у вас будут совершенно иные взгляды на обеспечение безопасности используемой архитектуры, тогда вы сможете остановиться на решениях, не похожих на эти.
Рис. 9.5. Более безопасная система, используемая в проекте MusicCorp
По мере удешевления дискового пространства и роста возможностей баз данных получать и сохранять большие объемы информации становится все проще. Эти данные имеют ценность не только для бизнеса как такового, который все чаще рассматривает их в качестве ценного актива, но в равной степени и для пользователей, заботящихся о своей неприкосновенности. К данным, относящимся к индивидууму или позволяющим получить о нем информацию, нужно относиться с особым вниманием.
А что, если нам упростить ситуацию? Почему бы не стереть как можно больше личной информации и не сделать это как можно раньше? Нужно ли нам при регистрации запроса пользователя навечно сохранять весь IP-адрес или можно заменить последние несколько цифр символами «x»? Нужно ли сохранять чьи-то имя, возраст, пол и дату рождения, чтобы выложить предложения о покупке товара, или достаточно будет информации о примерном возрасте и почтового индекса?
Положительно ответив на эти вопросы, можно получить множество преимуществ. Во-первых, если не хранить эти данные, то никто их не сможет украсть. Во-вторых, если они у вас не хранятся, то никто (например, какое-нибудь правительственное агентство) не сможет их запросить!
Эту концепцию хорошо поясняет немецкий термин Datensparsamkeit (означающий минимизацию данных). Появившись в немецком законодательстве о конфиденциальности, он является воплощением концепции хранения только той информации, которая необходима для выполнения бизнес-операций или соответствия местным законам. Вполне очевидно, что это противоречит тенденции к хранению все более солидных объемов информации, но это толчок к пониманию того, что противоречие все же существует!
Основная часть того, о чем здесь говорилось, касается основ реализации технологических мер безопасности для защиты ваших систем и данных от внешних взломщиков-злоумышленников. Но вам также нужны процессы и политики, имеющие дело с человеческим фактором в вашей организации. Как аннулировать доступ к учетным данным, когда кто-нибудь уйдет из организации? Как защититься от социальной инженерии? В качестве неплохого умственного упражнения рассмотрим, какой ущерб может нанести раздосадованный бывший сотрудник вашей системе, если ему захочется это сделать. Для того чтобы придумать защитные меры, неплохо будет поставить себя на место потенциального вредителя, ведь никакие злоумышленники не знают вашу организацию изнутри так хорошо, как бывший сотрудник!
Если вам больше нечего почерпнуть из данной главы, возьмите хотя бы это: не создавайте собственную систему шифрования. Не изобретайте собственные протоколы системы защиты. Вы все равно не сможете изобрести ничего путного в шифровании или разработке криптографических средств защиты, если только вы не специалист по криптографии с многолетним стажем. Но, даже являясь специалистом в этой области, вы все равно можете сделать что-нибудь не так.
Многие из ранее упомянутых средств, подобных AES, представляют собой весьма зрелые промышленные технологии, в основу которых положены алгоритмы, прошедшие коллегиальное рецензирование, программная реализация которых тщательно тестировалась и исправлялась в течение многих лет. Эти средства вполне успешно справляются со своими задачами! Зачастую изобретение колеса превращается в пустую трату времени, но, когда дело касается безопасности, такая изобретательская деятельность может стать весьма рискованным занятием.
Как и в случае с автоматизированным функциональным тестированием, мы не хотим, чтобы вопросами безопасности занимались разные группы людей и делали это в последнюю очередь. Главное — помочь разработчикам в разъяснении проблем безопасности, поскольку подъем общего уровня информированности каждого разработчика о проблемах безопасности может в первую очередь сократить количество таких проблем. Для начала неплохо бы ознакомить людей с десятью самыми значимыми уязвимостями из открытого проекта обеспечения безопасности веб-приложений — списком OWASP Top Ten и средой тестирования безопасности — OWASP Security Testing Framework. Специалисты, конечно, народ занятой, но если у вас есть с ними деловой контакт, то попросите их помочь в данном вопросе.
Существует ряд автоматизированных инструментальных средств, способных испытать вашу систему на наличие уязвимостей, например на возможность атак с применением межсайтовых сценариев. Хорошим примером может послужить средство Zed Attack Proxy, известное также как ZAP. Будучи проинформированным о результатах работы, ZAP предпринимает попытки воссоздания вредоносных атак на ваш сайт. Существуют и другие средства, использующие статический анализ с целью поиска распространенных ошибок программирования, которые могут стать прорехами в системе безопасности, например Brakeman для Ruby. Если эти средства легко интегрировать в обычные CI-сборки, их следует включить в стандартные проверочные процедуры. Другие виды автоматизированного тестирования — более сложная процедура. Например, использование средств, подобных Nessus, для сканирования на предмет обнаружения уязвимостей происходит немного сложнее и может потребовать для интерпретации результатов человеческого вмешательства. Тем не менее эти тесты все же поддаются автоматизации, и, может быть, имеет смысл запускать их на том же этапе, что и нагрузочные тесты.