Журнал "Information Security/ Информационная безопасность" #1, 2020

Интеграция процессов обеспечения безопасной разработки предполагает формализацию требований по сертификации для отде- лов DevOps. Так, в идеале требуется, чтобы релизы отдельных программных компонентов собирались и тестировались на защи- щенных дистрибутивах в эталонной среде. Серьезную проблему в сфере защиты интеллекту- альной собственности пред- ставляют так называемые copyleft-лицензии, требую- щие раскрытие исходных кодов на производные про- граммные модули. Для борь- бы с подобным явлением планируется ввести единый репозиторий доверенных сторонних пакетов. ра, в защищаемой системе остаются открытыми уязвимо- сти, связанные с получением несанкционированного доступа к объектам облачной инфра- структуры (065, 103, 135), затруд- няется поиск точки отказа в слу- чае недоступности услуг поль- зователям (043, 140, 162, 164). Противоположную проблему представляет общедоступность ресурсов (101), вызванная неза- щищенным администрировани- ем (055), неопределенностью ответственности (066) и несо- гласованностью политик без- опасности (096). Так, система с широким открытым периметром может быть изучена и атакована (046, 104, 098, 099, 100, 102, 187, 031, 176, 177, 015, 016, 028, 030). Так или иначе, недоста- точное внимание к защищаемой инфраструктуре может быть рас- ценено пользователями как зло- употребление доверием (021) и недобросовестное исполнение обязательств (054), а в конечном итоге привести к его потере (134). Широкое распространение мобильных устройств и возмож- ность широкополосного под- ключения к сети Интернет поз- воляет работать без привязки к рабочему месту, однако в дан- ном случае требования к без- опасности облачной инфра- структуры в связи с ростом числа угроз серьезно ужесто- чаются. Так, имеет место угроза злоупотребления возможностя- ми, предоставленными потре- бителям (020). В случае если пользователь подключается к облаку с помощью личного ноутбука или мобильного теле- фона (такая форма организации труда имеет собственное назва- ние – BYOD, Bring Your Own Device), администратор безопас- ности не может взять устройство под контроль. В результате ста- новятся актуальными угрозы, связанные с установкой про- граммного обеспечения (186), способного к негласному полу- чению пользовательских данных различными способами (062, 008, 041, 042, 201, 159). Стоит также отметить угрозу некорректной реализации поли- тики лицензирования в облаке (064), угрозу непрерывной модернизации облачной инфра- структуры (070), угрозу потери управления собственной инфра- структурой при переносе ее в облако, а также угрозу привязки к поставщику облачных услуг (141). К указанным проблемам эксплуатационного характера следует отнести также возмож- ный конфликт юрисдикций раз- личных стран (040) при внедре- нии территориально распреде- ленного облака. Опыт "Новых Облачных Технологий" Изначально разработка велась несколькими независи- мыми коллективами, результа- том труда которых являются про- граммные модули. Далее эти модули компонуются в конкрет- ные программные продукты, имеющие товарные названия. Очевидно, что различные про- дукты обладают различной функциональностью, поэтому для минимизации избыточности в релизах компоненты должны быть минимальными. С другой стороны, процесс компоновки из десятков и сотен модулей сопряжен с большими пробле- мами, поэтому был выделен ряд базовых составляющих, разра- батываемых и проверяемых по отдельности, которые затем собираются в релиз. Для каж- дого такого модуля целостно и логически связно ведется исто- рия изменений во времени (задачи в Jira, коммиты кода, билды). В настоящий момент разра- ботка защищенной версии про- дукта находится в стороне от базовой. Базовый продукт имеет определенный релизный цикл (несколько релизов в год). При этом процесс сертифика- ции проводится не для каждого релиза. Из-за временных затрат на разработку защищенной вер- сии она по функциональности отстает от актуальной. С целью гомогенизации процесса раз- работки, направленной на соот- ветствие требованиям разра- ботки от ФСТЭК, требуется значительная реорганизация механизма взаимодействия подразделений. Другими сло- вами, необходима интеграция процессов безопасности в про- изводство основной версии про- дукта, а также изменение поряд- ка взаимодействия между отде- лами разработки. Интеграция процессов обес- печения безопасной разработки предполагает формализацию требований по сертификации для отделов DevOps. Так, в идеале требуется, чтобы релизы отдельных программных компо- нентов собирались и тестиро- вались на защищенных дистри- бутивах в эталонной среде. В процессе интеграции и централизации ресурсов воз- никает необходимость в созда- нии единого репозитория собст- венных и сторонних программ- ных продуктов. Контроль сто- ронних продуктов (3-rd party) производится на наличие выявленных уязвимостей и про- верку лицензионной чистоты. Серьезную проблему в сфере защиты интеллектуальной собственности представляют так называемые copyleft-лицен- зии, требующие раскрытия исходных кодов на производные программные модули. Для борь- бы с подобным явлением пла- нируется ввести единый репо- зиторий доверенных сторонних пакетов. Чтобы пакет стал дове- ренным, необходима проверка его лицензии, корректности ука- занной в метаданных версии, а также выявление наиболее существенных уязвимостей. Существующая система тех- нической поддержки взаимо- действует непосредственно с разработчиками и группой, занимающейся обучением сотрудников и клиентов. В дан- ный механизм добавляется новое направление – взаимо- действие с отделом безопасно- сти информации в части при- менения СЗИ и работы в защи- щенной среде. Внесение изменений в усто- явшийся технологический про- цесс в большинстве случаев сопряжено со значительными затратами – финансы, время, труд. Перед проведением реор- ганизации всегда следует учи- тывать ее целесообразность, оценивая как затраты, так и воз- можные позитивные и негатив- ные последствия. В случае если потребность в изменениях дик- туется внешними факторами, такими как изменение законо- дательства, освоение новых сфер деятельности, равно как и новых рынков сбыта продук- ции, необходимо выстраивать процесс таким образом, чтобы внедрение новых процессов не останавливало деятельность предприятия. Выход закона о КИИ является серьезным шагом в области государственного регулирова- ния деятельности в сфере обес- печения общественной безопас- ности. l 38 • ТЕХНОЛОГИИ Ваше мнение и вопросы присылайте по адресу is@groteck.ru