доступ к коду и данным в с жестко контролируется
Управление доступом для кода и ADO.NET
Разрешения для доступа к коду
При выполнении кода он предоставляет свидетельство, которое проверяется системой безопасности CLR. Обычно это свидетельство состоит из источника кода, включая URL-адрес, узел и зону, а также цифровые сигнатуры, которые подтверждают происхождение сборки.
Среда CLR позволяет коду выполнять только те операции, на которые у него есть права. Код может запросить права доступа, и эти запросы удовлетворяются, исходя из политики безопасности, заданной администратором.
Код, выполняющийся в среде CLR, не может предоставлять права доступа самому себе. Например, код может запросить и предоставить меньшие права доступа, чем позволено политикой безопасности, при этом он никогда не получить больше прав доступа. При предоставлении прав доступа следует начинать с нуля и добавлять минимальные необходимые права для каждой выполняемой задачи. Если начать с предоставления всех прав, а затем удалять отдельные их них, то приложение окажется небезопасным. В нем могут возникать неожиданные бреши в системе безопасности из-за предоставления больших прав доступа, чем необходимо. Дополнительные сведения см. в разделе Настройка политики безопасности и Управление политиками безопасности.
Существует три типа прав доступа для кода.
Code access permissions получаются из класса CodeAccessPermission. Права доступа требуются для использования защищенных ресурсов, например файлов и переменных среды, а также для выполнения защищенных операций, например для доступа к неуправляемому коду.
Identity permissions представляют собой характеристики, определяющие сборку. Права доступа предоставляются сборке, исходя из свидетельства, которое может содержать такие элементы, как цифровая сигнатура или сведения об источнике кода. Права доступа для удостоверения также являются производными от базового класса CodeAccessPermission.
Role-based security permissions основаны на том, имеет ли участник указанное свидетельство или является ли членом указанной роли. Класс PrincipalPermission позволяет проводить декларативные и императивные проверки прав доступа по активному участнику.
Система безопасности среды выполнения просматривает стек вызова, сравнивая разрешения, предоставленные каждому вызывающему, с запрашиваемым разрешением, чтобы определить, разрешено ли коду иметь доступ к ресурсу. Если какой-либо вызывающий объект в стеке вызова не имеет запрашиваемого разрешения, формируется исключение SecurityException и ему отказывается в доступе.
Запрос прав доступа
Цель запроса прав доступа состоит в том, чтобы проинформировать среду выполнения о том, какие права доступа требуются данному приложению для работы, а также чтобы обеспечить получение им только тех прав доступа, которые ему действительно нужны. Например, если приложению требуется записать данные на локальный диск, ему необходимо право доступа FileIOPermission. Если это право доступа не было предоставлено, при попытке приложения записать данные на диск произойдет сбой. Однако если приложение запрашивает право доступа FileIOPermission и не получает его, то в результате оно формирует исключение и не загружается.
В том случае, когда приложению требуется только считать данные с диска, можно потребовать, чтобы ему никогда не предоставлялись права доступа для записи. При возникновении ошибки или атаки злоумышленника код не сможет повредить данные, с которыми он работает. Дополнительные сведения см. в разделе запрос разрешений.
Безопасность на основе ролей и CAS
Реализация безопасности на основе ролей и управления доступом для кода (CAS) повышает общую безопасность приложения. Безопасность на основе ролей может основываться на учетных записях Windows или пользовательских удостоверениях, которые предоставляют сведения об участнике безопасности текущему потоку. Кроме того, часто требуется, чтобы приложения предоставляли доступ к данным или ресурсам, исходя из учетных данных, переданных пользователем. Такие приложения обычно проверяют роль пользователя и предоставляют доступ к ресурсам на основании этих ролей.
Безопасность на основе ролей позволяет компоненту идентифицировать текущих пользователей и их роли во время выполнения. Затем эти сведения сопоставляются при помощи политики CAS, чтобы определить набор прав доступа, предоставляемых во время выполнения. Ведущее приложение может изменить политику безопасности на основе ролей по умолчанию и задать участника безопасности по умолчанию, который представляет пользователя и роли, связанные с этим пользователем, для указанного домена приложения.
В среде CLR для реализации своего механизма применения ограничений для управляемого кода используются права доступа. Права доступа на основе ролей предоставляют механизм для определения, имеет ли пользователь (или агент, действующий от имени пользователя) конкретное удостоверение или является ли он членом указанной роли. Дополнительные сведения см. в разделе разрешения безопасности.
В зависимости от типа создаваемого приложения также следует рассмотреть возможность реализации в базе данных прав доступа на основе ролей. Дополнительные сведения о безопасности на основе ролей в SQL Server см. в разделе SQL Server Security.
Сборки
Назначение строгих имен сборкам
Строгое имя или цифровая сигнатура состоит из идентификатора сборки, в который входит ее простое текстовое имя, номер версии и сведения о языке и региональных настройках (если указано) плюс открытый ключ и цифровая сигнатура. Цифровая сигнатура формируется из файла сборки при помощи соответствующего закрытого ключа. В файле сборки содержится манифест сборки, в котором указаны имена и хэши всех файлов, составляющих эту сборку.
Строгое имя сборки дает приложению или компоненту уникальный идентификатор, который может использоваться другими программами явной ссылки на сборку. Строгие имена предотвращают имитацию сборок со стороны сборок, содержащих вредоносный код. Строгие имена также обеспечивают согласованность разных версий компонента. Сборки, которые будут установлены в глобальный кэш сборок, должны получать строгие имена. Дополнительные сведения см. в разделе Создание и использование сборок со строгими именами.
Частичный уровень доверия в ADO.NET 2.0
У частично доверенного приложения, использующего поставщик the SQL Server, как минимум, должно быть право доступа для выполнения и право доступа SqlClientPermission.
Свойства атрибута разрешения для частичного уровня доверия
В следующей таблице содержится список имеющихся свойств SqlClientPermissionAttribute и их описания.
Наследуется от DBDataPermissionAttribute.
Синтаксис ConnectionString
Синтаксис KeyRestrictions
В следующем примере включается одна и та же строка подключения, что позволяет Encrypt использовать Packet Size Параметры строки соединения и, однако, обеспечивает использование любых других параметров строки подключения.
Синтаксис KeyRestrictionBehavior с PreventUsage
Синтаксис KeyRestrictionBehavior с AllowOnly
Разрешение частичного уровня доверия при помощи пользовательских наборов прав доступа
Образец набора прав доступа
Проверка доступа к коду ADO.NET при помощи прав доступа Security Permissions
В сценариях с частичным доверием для некоторых методов в коде можно затребовать права доступа CAS, указав SqlClientPermissionAttribute. Если предоставление этого права доступа запрещено действующей политикой безопасности, перед выполнением кода формируется исключение. Дополнительные сведения о политике безопасности см. в разделе рекомендации по управлению политиками безопасности и политикам безопасности.
Пример
В следующем примере демонстрируется, как написать код, в котором требуется определенная строка соединения. В нем имитируется запрет на неограниченные права доступа для System.Data.SqlClient, который в реальной среде реализуется системным администратором при помощи политики CAS.
При разработке прав доступа CAS для ADO.NET рекомендуется начинать с наиболее жестких ограничений (полное отсутствие прав доступа), а затем добавлять определенные права доступа, необходимые конкретной задаче, которую требуется выполнить коду. Противоположный подход, когда начинают с предоставления всех прав доступа, а затем удаляют определенные права, не является безопасным, поскольку существует много способов выражения одинаковой строки соединения. Например, если начать с предоставления всех прав доступа, а затем попытаться запретить использование строки соединения «server=someserver», то строка «server=someserver.mycompany.com» останется допустимой. Начиная с отсутствия предоставленных прав, можно сократить вероятность появления уязвимостей, связанных с набором прав доступа.
В следующем коде демонстрируется, как SqlClient выполняет запрос на право доступа, который формирует исключение SecurityException при отсутствии соответствующих прав доступа CAS. Исключение SecurityException отображается в консольном окне.
Вот что должно отобразиться в консольном окне:
Совместимость с неуправляемым кодом
Код, который выполняется вне среды CLR, называется неуправляемым. Поэтому применять к неуправляемому коду такие механизмы безопасности, как CAS, нельзя. Примерами неуправляемого кода являются компоненты COM, интерфейсы ActiveX и функции Windows API. При выполнении неуправляемого кода возникают особые вопросы безопасности, с тем чтобы не подвергать риску общую безопасность приложения. Дополнительные сведения см. в разделе Взаимодействие с неуправляемым кодом.
Использование ограничений доступа к данным для различных объектов 1С:Предприятия 8
Этот раздел содержит информацию об особенностях использования ограничений доступа к данным, определяемых поведением различных объектов 1С:Предприятия.
О принципах функционирования ограничений доступа к данным
Основные принципы функционирования и использования ограничений доступа к данным описаны в документации 1С:Предприятия 8 и в разделе «Ограничения доступа к данным. Сведения о принципах функционирования».
Для лучшего понимания механизма проверки ограничений доступа полезно иметь в виду следующие правила:
Приведем несколько примеров.
Например, в случае простейшего ограничения вида:
ГДЕ Реквизит = &ПравильноеЗначениеРеквизита
можно считать, что для каждой записи, для которой проверяется ограничение(проверяемой записи), выполняется запрос следующего вида:
ВЫБРАТЬ 1
ИЗ ТаблицаИзОднойПроверяемойЗаписи
ГДЕ Реквизит = &ПравильноеЗначениеРеквизита
В данной таблице доступ к записи, в которой значение реквизита «Реквизит» совпадает со значением параметра сеанса «ПравильноеЗначениеРеквизита», разрешен. К другим записям этой таблицы доступ запрещен.
Другой пример. Усложним ограничение. Допустим нужно разрешить доступ к записи таблицы «Справочник.Контрагенты» не только если ее «Реквизит» имеет «правильное значение», но и в том случае, если «правильное значение» имеет «Реквизит» родителя этой записи (1-го или 2-го уровня). В этом случае ограничение может иметь следующий вид:
Контрагенты
ИЗ Справочник.Контрагенты КАК Контрагенты
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты1
ПО Контрагенты.Родитель = Контрагенты1.Ссылка
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты2
ПО Контрагенты1.Родитель = Контрагенты2.Ссылка
ГДЕ Контрагенты.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты1.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты2.Реквизит = &ПравильноеЗначениеРеквизита
Тогда запрос, который будет выполнятся в процессе проверки этого ограничения для конкретной записи справочника «Контрагенты», будет иметь вид:
ВЫБРАТЬ 1
ИЗ ТаблицаИзОднойПроверяемойЗаписи КАК Контрагенты
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты1
ПО Контрагенты.Родитель = Контрагенты1.Ссылка
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты2
ПО Контрагенты1.Родитель = Контрагенты2.Ссылка
ГДЕ Контрагенты.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты1.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты2.Реквизит = &ПравильноеЗначениеРеквизита
Обращения по ссылкам в запросах и ограничения доступа к данным
Пусть на справочник «Контрагенты» установлено следующее ограничение доступа:
ГДЕ Ответственный = &ТекущийПользователь
а сам справочник содержит такие записи:
Ответственный
(ссылка на Справочник.Пользователи)
Пусть регистр сведений «КонтактнаяИнформация» содержит следующие записи:
КонтактноеЛицо
(ссылка на Справочник.ФизЛица)
Организация
(ссылка на Справочник.Контрагенты)
Тогда если текущим пользователем является пользователь «Иванов», то результатом запроса:
ВЫБРАТЬ РАЗРЕШЕННЫЕ Имя, Ответственный
ИЗ Справочник.Контрагенты
Ответственный
(ссылка на Справочник.Пользователи)
Однако, результатом следующего запроса:
ВЫБРАТЬ РАЗРЕШЕННЫЕ КонтактноеЛицо, Организация
ИЗ РегистрСведений.КонтактнаяИнформация
Ответственный
(ссылка на Справочник.Пользователи)
ВЫБРАТЬ РАЗРЕШЕННЫЕ КонтактноеЛицо, Организация.Имя КАК Имя, Организация.Ответственный КАК Ответственный
ИЗ РегистрСведений.КонтактнаяИнформация
поскольку противоречащие ограничению записи справочника «Контрагенты» считаются отсутствующими, а значениями полей «Имя» и «Ответственный» по ссылкам, указывающим на несуществующие записи, является значение NULL.
Если же необходимо по тому же признаку ограничить доступ к записям регистра сведений «КонтактнаяИнформация», то на этот регистр можно наложить ограничение вида:
ГДЕ Организация.Ответственный = &ТекущийПользователь
В этом случае результатом выполнения последнего запроса будет таблица:
Ограничения и табличные части
Ограничения доступа к данным действуют только на записи таблиц верхнего уровня и не могут ограничивать доступность записей табличных частей. С другой стороны, в тексте ограничения поля табличных частей использоваться могут. В этом случае в процессе проверки ограничения для некоторой записи будет исполнен запрос, в котором табличная часть будет соединена с таблицей из одной проверяемой записи левым внешнем соединением. Таким образом запись будет удовлетворять ограничению, если в ее табличной части найдется хотя бы одна запись, для которой условие в ограничении принимает значение «Истина».
Из соображений эффективности в ограничениях доступа к данным нельзя использовать агрегатные функции. Поэтому возможности участия в ограничениях доступа к данным каких-нибудь условий на совокупности записей табличных частей не предусмотрено. Подобная цель может быть достигнута посредством запросов, вложенных в ограничения, однако пользоваться этим необходимо с осторожностью из-за возможного снижения производительности.
Например, если документ «Накладная» содержит табличную часть «Состав», то ограничения доступа к этому документу проверяются при обращении к каждой накладной, как к единому целому и не могут разрешить доступ к какой-нибудь одной записи его табличной части «Состав», а к какой-нибудь другой запретить.
Пусть таблица «Документ.Накладная» содержит следующие записи:
Контрагент
(ссылка на Справочник.Контрагенты)
Состав (табличная часть)
В этом случае запрос, исполняемый для каждой накладной в процессе проверки следующего ограничения:
ГДЕ Состав.Количество > 50
ВЫБРАТЬ 1
ИЗ ТаблицаИзОднойПроверяемойЗаписи КАК Накладная
ЛЕВОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ Документ.Накладная.Состав КАК Состав
ПО Накладная.Ссылка = Состав.Ссылка
ГДЕ Состав.Количество > 50
Следовательно доступ будет разрешен только для записи «Трикотажная фабрика». Поэтому запрос:
ВЫБРАТЬ РАЗРЕШЕННЫЕ Контрагент, Состав.(Номенклатура, Количество)
ИЗ Документ.Накладная
а запрос к вложенной таблице:
ВЫБРАТЬ РАЗРЕШЕННЫЕ Контрагент, Номенклатура, Количество
ИЗ Документ.Накладная.Состав
поскольку ограничение накладывается только на записи верхнего уровня, но не на записи табличных частей.
Если нужно разрешить доступ еще и к тем накладным, у которых состав пустой, то ограничение может быть модифицировано так:
ГДЕ Состав.Количество > 50 ИЛИ Состав.Количество ЕСТЬ NULL
Если же необходимо разрешить доступ только к тем накладным, у которых в табличной части «Состав» нет записей с «Количеством», превышающем 50, то в ограничении необходимо использовать вложенный запрос:
Все операции над объектами встроенного языка 1С:Предприятия выполняются в режиме «ВСЕ» (без использования режима «РАЗРЕШЕННЫЕ»). Для успешного получения разрешенных объектов в соответствующих методах объектов необходимо указывать отборы, не противоречащие ограничениям. Например, если на чтение из регистра сведений «КонтактнаяИнформация» установлено ограничение вида:
ГДЕ Тип = &ТипКонтактнойИнформации»
то для успешного выполнения метода
необходимо установить отбор:
Если ограничение доступа сложное и не может быть сформулировано в терминах отборов, то использование выборки (метод Выбрать() ) и аналогичных оказывается невозможным. В этом случае следует использовать запросы. Проектирование разграничения доступа к данным таким образом, чтобы ограничения могли быть сформулированы в терминах отборов, позволит использовать объекты встроенного языка с максимальной гибкостью.
Виртуальные таблицы запросов
При использовании в запросах без ключевого слова РАЗРЕШЕННЫЕ виртуальных таблиц в условиях установленных ограничений доступа к данным необходимо указывать отборы, не противоречащие ограничениям не только для запроса в целом, но и для виртуальных таблиц. Например:
ВЫБРАТЬ
КонтактнаяИнформацияСрезПервых.Представление
ИЗ
РегистрСведений.КонтактнаяИнформация.СрезПоследних(, Тип = &Тип ) КАК КонтактнаяИнформацияСрезПервых
ГДЕ
КонтактнаяИнформацияСрезПервых.Тип = &Тип
Выделенный отбор по виртуальной таблице «СрезПоследних» может содержать произвольное логическое выражение, допустимое для раздела ГДЕ, использующее поля, которые присутствуют в виртуальной таблице.
Анализ безопасности исходного кода как ключевой элемент DevSecOps
Процесс безопасной разработки невозможен без обеспечения безопасности исходного кода. Для поиска уязвимостей в создаваемых приложениях существует отдельный класс инструментов, который сейчас активно развивается, в том числе и под давлением регуляторов. Вместе с ведущими экспертами отрасли мы попытались разобраться в том, какие бывают средства тестирования исходного кода, какие задачи можно решать при помощи таких сканеров и каковы перспективы развития этого рынка.
Введение
Мы продолжаем обсуждать различные аспекты методологии DevSecOps в рамках цикла онлайн-конференций AM Live. В феврале ведущие эксперты рынка рассказали зрителям об основах безопасной разработки, а очередная встреча, прошедшая в конце марта, была посвящена обеспечению безопасности исходного кода. Мы собрали группу экспертов, чтобы обсудить, какие сканеры безопасности исходного кода представлены на рынке, чем отличаются решения классов SAST, DAST и IAST и что такое RASP-инструменты, а также порассуждать о перспективах отрасли.
В студии Anti-Malware.ru собрались:
Модерировал беседу Андрей Бешков — руководитель направления развития бизнеса компании Softline.
Зачем проверять код на безопасность
В начале дискуссии модератор предложил обсудить базовые вопросы и попросил экспертов рассказать о том, для чего вообще существуют различные сканеры безопасности и какую пользу они могут принести компании.
Первой слово взяла Дарья Орешкина, которая отметила, что организации важно понимать, где и какие фрагменты кода используются и кто их автор. При обнаружении ошибок в отдельном фрагменте необходимо оценить то, какие системы затрагивает эта проблема, и оперативно их исправить, желательно силами автора. Валерий Куваев согласился с коллегой и добавил, что следует исходить из задачи, которую организация ставит перед собой. Это могут быть требования регуляторов или желание снизить риски от кибератак.
Алексей Жуков поделился мнением, что компании уже научились управлять уязвимостями в периметре безопасности, устанавливая патчи на типовые, массовые программы — операционные системы и базы данных. Однако наряду с ними в организации могут использоваться уникальные приложения, написанные специально под определённые задачи — например, веб-сайты. Чтобы такие программы не стали точкой входа для злоумышленников, необходимо найти и устранить в них уязвимости.
По мнению Анны Архиповой, защита должна быть встроена на всех уровнях, поскольку каждый из них зависит от другого и влияет на общую безопасность организации. Сергей Деев отметил, что используемые компаниями приложения могут иметь разные задачи, однако статический анализ кода — это универсальный инструмент, который подходит абсолютно для всех типов программ. Подводя итог высказываниям коллег, Артём Синицын сказал, что в общем случае основная задача анализа кода — это обеспечение безопасности приложений или сервисов в процессе их эксплуатации. Если говорить конкретнее, то сканеры кода позволяют уменьшить издержки разработчика на устранение уязвимостей обнаруженных после релиза системы.
Чем раньше наступит стадия, когда компания начинает думать о безопасности кода, тем меньше времени, денег и других ресурсов потребуется на патчинг. Как отметили наши эксперты, чем раньше начнёшь анализ кода, тем меньше заплатишь в итоге. Существуют сервисы и приложения, которые напрямую связаны с выручкой компании — например, финансовые и торговые программы. Цена компрометации таких систем несёт не только репутационные, но и прямые денежные убытки для компании. Статический анализ позволяет решить задачу обеспечения безопасности кода на самых ранних этапах. Безусловно, это — не единственный инструмент безопасной разработки, но первый и необходимый шаг.
Сканирование кода на безопасность позволяет разработчику лучше контролировать процесс, после выпуска патча такой возможности практически не существует и создатель обновления не может управлять его использованием. Идеология Shift Left (смещение вопросов связанных с безопасностью как можно ближе к началу разработки) позволяет снизить потенциальные издержки от проблем и для разработчика, и для заказчика.
Использовать ли сканеры с открытым исходным кодом
Ещё один вопрос, который обсудили спикеры онлайн-конференции AM Live, — насколько допустимо использовать бесплатные (open-source) продукты для анализа кода. Как отметили эксперты, такие разработки могут обеспечить некоторый базовый уровень безопасности, однако для поиска уязвимостей второго порядка чаще всего необходимы специализированные ИБ-продукты. Платные инструменты часто обладают расширенной рекомендательной функциональностью. Это важно, поскольку в ряде случаев мало сообщить о проблеме, надо ещё и объяснить, что необходимо сделать, вплоть до автоматического исправления проблемного кода. Детальное описание уязвимостей и разработка рекомендаций по их исправлению требуют очень больших усилий и затрат от разработчиков сканеров, а опенсорс-команды часто ими не обладают.
Как отметил Артём Синицын, не бывает полностью бесплатного ПО и тем более не бывает дешёвой безопасности. В то же время нельзя говорить, что лучше — коммерческий сканер или бесплатный; можно говорить о том, какой инструмент лучше подходит для решения определённой задачи. Можно комбинировать различные ядра для анализа кода на разных стадиях проекта, а также применять разные сканеры для разных разработок.
Мы поинтересовались у зрителей прямого эфира, анализируют ли они исходный код своих проектов на предмет безопасности. Как оказалось, в организациях 30 % респондентов действует специальный регламент по проверке кода. Ещё 20 % опрошенных сообщили, что код анализируется, но этот процесс не поставлен на регулярную основу. Не анализируют код 17 % наших зрителей, а 18 % из них уверены в чистоте используемого в их проектах кода. Отдали процесс обеспечения безопасности кода на аутсорсинг 15 % опрошенных.
Рисунок 1. Анализируете ли вы исходный код своих проектов на безопасность?
Что такое SAST, DAST, IAST и с чего нужно начинать внедрение анализа безопасности исходного кода
Вместе с нашими экспертами мы попытались разобраться в терминологии, существующей на рынке анализа безопасности исходного кода, и попросили рассказать, чем же отличаются друг от друга и для чего предназначены технологии динамической, статической и интерактивной проверки.
Анна Архипова:
— Каждый инструмент используется на своём этапе DevSecOps. Статический анализатор поможет при написании кода и определении архитектуры приложения, динамическая проверка и, возможно, IAST будут полезны при сборке и тестировании программы. Ни один из инструментов не обеспечивает полной безопасности кода, но в комплексе они дают хороший результат.
Валерий Куваев:
— Выбор средства анализа кода зависит от возможностей и прав «заказчиков» — имеют ли они доступ к коду или могут оперировать только на уровне приложения. Безусловно, в идеале стоит начать со статического тестирования, но и другие инструменты не стоит сбрасывать со счетов.
Сергей Деев:
— Компании по-разному подходят к разработке, но если стоит цель сделать этот процесс безопасным, то SAST — это один из базовых инструментов. Однако стоит не противопоставлять статический и динамический анализ, а использовать все доступные инструменты, чтобы сделать код безопасным. Некоторые типы уязвимостей можно определить только в статике, некоторые — только в динамике, а целый ряд проблем находится на стыке возможностей этих двух инструментов.
Дарья Орешкина:
— Не стоит забывать о рисках юридического характера. Компании необходимо понимать, какая часть кода ей принадлежит, кто будет обладать правами на код в случае разделения бизнеса, а также [каковы] лицензионные требования сторонних компонентов. Анализ кода в этом случае может стать средством автоматизации работы юристов.
Артем Синицын:
— Чтобы понять текущую классификацию решений для сканирования кода, достаточно запомнить пять аббревиатур. Исторически существуют статический (SAST) и динамический (DAST) анализ, а также гибридный подход (IAST). Кроме того, существует FAST, или фаззинг — подраздел динамического тестирования на основе обратной связи. Наконец, нельзя забывать и о RASP (Runtime Application Self-Protection), технологии, которая скорее является внутренним файрволом приложения и используется для анализа и блокировки атак в реальном времени.
Алексей Жуков:
— В контексте безопасности приложений необходимо помнить об ещё одной технологии: WAF (Web Application Firewall). Это — накладное средство безопасности, которое позволяет заблокировать определённые известные уязвимости и выпустить программу дав разработчику время для исправления проблемы.
Эксперты упомянули также о продуктах класса SCA, предназначенных для анализа сторонних компонентов, используемых в системе. Базовые варианты таких решений способны формировать список сторонних библиотек, включённых в разработку, и уязвимостей в них. Более совершенные SCA-продукты способны оценить методы работы проприетарного кода и понять, возможно ли эксплуатировать найденные уязвимости в конкретной системе.
Зрители онлайн-конференции AM Live считают, что в первую очередь необходимо уделять внимание статическому анализу кода. За это в ходе проведённого нами опроса высказались 69 % респондентов. Ещё 21 % опрошенных отдают предпочтение динамическому анализу. За анализ сторонних компонентов и интерактивный анализ (IAST) отдали свои голоса 7 % и 3 % соответственно.
Рисунок 2. На какие способы анализа безопасности приложений вы обращаете внимание в первую очередь?
Что мешает внедрять средства анализа безопасности кода
Эксперты обсудили организационные проблемы, возникающие при внедрении средств анализа исходного кода. Как выяснилось, одним из существенных препятствий в этом процессе является сложность взаимодействия специалистов по информационной безопасности и разработчиков. Нередко у программистов бывает свой взгляд на степень критической важности уязвимости и приоритет её исправления. Как отметили спикеры, в ряде случаев прийти к общему знаменателю могут помочь базы данных уязвимостей, однако даже самый большой реестр не всегда применим к конкретной разработке. К тому же у каждого приложения — своя модель угроз. Поэтому оценку значимости найденных проблем необходимо выполнять в контексте конкретной разработки. Помочь в приоритизации может интерактивный анализ.
По мнению экспертов в студии, закладывать требования к безопасности программы необходимо ещё на этапе создания её архитектуры, наравне с функциональными возможностями. Важно также понимать, что ошибка не всегда является уязвимостью. Чтобы правильно построить диалог с разработчиками, следует предоставить как можно больше структурированной информации об обнаруженной проблеме со ссылками на международную практику и другие источники — в привязке к коду и в понятных терминах.
На вопрос «Что ограничивает вас во внедрении анализа безопасности исходного кода?» 28 % зрителей онлайн-трансляции ответили, что им мешает сопротивление внутри компании. Столько же голосов набрал вариант «Дефицит внутренних ресурсов». Высокая стоимость технологий анализа исходного кода на безопасность ограничивает 20 % опрошенных, а увеличение срока выхода релизов — 8 % респондентов. Наконец, 16 % наших зрителей сообщили, что в их компании этот процесс находится на стороне подрядчика.
Рисунок 3. Что ограничивает вас во внедрении анализа безопасности исходного кода?
Перспективы рынка: уйдёт ли анализ кода на безопасность в облако
В завершение беседы ведущий конференции AM Live предложил гостям в студии порассуждать о перспективах рынка и, в частности, обсудить то, будут ли анализаторы кода мигрировать в облако. Эксперты отметили, что на западном рынке этот процесс уже идёт и вендоры получают до 50 % своей прибыли от облачных систем безопасности кода. В России этот тренд также заметен, хотя и не так значим. Некоторое недоверие к облачным технологиям в нашей стране обусловлено в том числе и слабой нормативной базой, которая, впрочем, сейчас активно развивается.
Мы спросили у зрителей конференции, готовы ли они отдать анализ исходного кода в облако. Большинство участников опроса — 62 % — отрицательно отнеслись к такой возможности. Готовы использовать облачные технологии в том случае, если серверы находятся на территории России, 19 % респондентов; столько же доверяют анализу кода в облаке без дополнительных условий.
Рисунок 4. Готовы ли вы производить анализ безопасности исходного кода в облаке?
Ещё одна тенденция, которую отметили наши эксперты, — усиление требований регулирующих органов в части безопасности кода. Если ранее разработчики в первую очередь заботились о соответствии функциональным требованиям, то сейчас для поставки решений в критически важные отрасли необходимо думать не только о безопасности используемой инфраструктуры, но и о безопасности кода.
Важным вектором на ближайшие несколько лет эксперты назвали более активное использование опенсорс-компонентов, в том числе и в проприетарных разработках, а также увеличение сложности кода создаваемых программ. Всё это будет стимулировать спрос на решения способные анализировать большее количество уровней вложенности и зависимостей.
По итогам конференции мы поинтересовались у зрителей тем, как изменилось их мнение относительно технологий анализа кода после просмотра прямого эфира. Почти четверть опрошенных — 24 % — заинтересовались анализаторами и выразили готовность начать их тестирование. Чуть больше — 28 % респондентов — считают, что такое решение будет избыточно для их компании. Почти треть участников опроса уже используют сканеры исходного кода — за этот вариант отдали свои голоса 32 % зрителей. Ещё 4 % опрошенных выразили мнение, что спикеры онлайн-конференции не смогли доказать необходимость таких инструментов, а 12 % вообще не поняли, о чём шла речь.
Рисунок 5. Каково ваше мнение относительно анализаторов безопасности исходного кода?
Выводы
Мы планируем продолжить обсуждение различных аспектов DevSecOps с экспертами в этой сфере. Кроме того, зрителей ждут новые выпуски конференции AM Live, посвящённые и другим актуальным для отечественного рынка информационной безопасности вопросам. Чтобы оставаться в курсе ключевых тенденций, иметь возможность в прямом эфире наблюдать дискуссии лидеров мнений и общаться с ними в процессе онлайн-трансляции, подписывайтесь на наш YouTube-канал и включайте уведомления о новых материалах. До встречи на конференции AM Live!