Разработка защищенных приложений в Azure

  • Статья

В этой статье представлены действия по обеспечению безопасности и элементы управления безопасностью, которые следует учитывать при разработке приложений для облака. В статье рассматриваются вопросы и концепции безопасности, которые следует учитывать на этапах реализации и проверки жизненного цикла разработки защищенных приложений (Майкрософт) (SDL). Ее цель — помочь вам определить действия и службы Azure, которые можно использовать для разработки хорошо защищенного приложения.

В этой статье описаны следующие этапы SDL:

  • Реализация
  • Проверка

Реализация

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

Выполнение проверок кода

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

Статический анализ кода

Статический анализ кода (также известный как анализ исходного кода) выполняется в рамках проверки кода. Статический анализ кода обычно относится к запуску средств анализа статического кода для поиска потенциальных уязвимостей в неисполняемом коде. Статический анализ кода использует такие методы, как проверка запятнания и анализ потока данных.

Azure Marketplace предлагает инструменты разработчика, которые выполняют статический анализ кода и помогают с проверкой кода.

Проверка и очистка всех входных данных для приложения

Рассматривайте все входные данные как ненадежные, чтобы защитить приложение от наиболее распространенных уязвимостей веб-приложений. Ненадежные данные могут использовать злоумышленники для атак путем внедрения кода. Ко входным данным приложения относятся параметры в URL-адресе, ввод пользователя, данные из базы данных или из API, а также все передаваемые данные, на которые может повлиять пользователь. Приложение должно проверить синтаксическую и семантическую допустимость данных, прежде чем использовать их каким-либо способом (включая вывод обратно пользователю).

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

Создание списка блокировок и списка разрешений — это два общепринятых подхода к проверке синтаксиса входных данных:

  • В процессе проверки по списку блокировок введенные пользователем данные проверяются на отсутствие содержимого, которое внесено в список как вредоносное.

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

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

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

Выполняйте эту работу на сервере, а не на стороне клиента (или и на сервере, и на стороне клиента).

Проверка выходных данных приложения

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

Экранирование гарантирует, что все будет отображается как выходные данные. Экранирование также указывает интерпретатору, что данные не предназначены для выполнения, и это предотвращает срабатывание атак. Это еще один распространенный способ атаки, который называется межсайтовый скриптинг (XSS).

Если вы используете веб-платформу от стороннего производителя, вы можете проверить параметры кодирования выходных данных на веб-сайтах с помощью памятки по предотвращению OWASP XSS.

Использование параметризованных запросов при обращении к базе данных

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

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

Удаление стандартных заголовков сервера

Такие заголовки, как Server, X-Powered-By и X-AspNet-Version, раскрывают сведения о сервере и базовых технологиях. Рекомендуется подавлять эти заголовки, чтобы предотвратить возможность создания отпечатка приложения. См. запись блога об удалении стандартных заголовков серверов на веб-сайтах Azure.

Обособление производственных данных

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

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

Применение политики надежных паролей

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

Azure AD B2C помогает вам управлять паролями, предоставляя самостоятельный сброс пароля, принудительный сброс пароля и другие функции.

Чтобы обеспечить защиту от атак на учетные записи по умолчанию, все ключи и пароли должны быть заменяемыми. Кроме того, их нужно создавать или заменять после установки ресурсов.

Если приложению нужно создавать пароли автоматически, они должны создаваться случайным образом и иметь высокий уровень энтропии.

Проверка передаваемых файлов

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

Антивредоносные программы помогают обнаруживать и удалять вирусы, шпионские и другие вредоносные программы. Вы можете установить Microsoft Antimalware или решение для защиты конечных точек от партнера Майкрософт (Trend Micro, Broadcom, McAfee, Microsoft Defender антивирусная программа в Windows и Endpoint Protection).

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

Не кэшируйте конфиденциальное содержимое

Не кэшируйте конфиденциальное содержимое в браузере. Браузеры могут сохранять информацию для кэширования и ведения истории. Кэшированные файлы хранятся в папке, подобной папке временных файлов Интернета в Internet Explorer. При повторном обращении к страницам браузер отображает их из кэша. Если пользователю отображается конфиденциальная информация (адрес, кредит карта данные, номер социального страхования, имя пользователя), эти сведения могут храниться в кэше браузера и быть извлечены путем проверки кэша браузера или нажатия кнопки Назад в браузере.

Проверка

Этап проверки включает в себя комплекс мер по обеспечению соответствия кода принципам безопасности и конфиденциальности, которые были установлены на предыдущих этапах.

Поиск и устранение уязвимостей в зависимостях приложения

Вам нужно просканировать приложение и его зависимые библиотеки для обнаружения компонентов с известными уязвимостями. Для выполнения этой проверки можно использовать такие продукты, как OWASP Dependency Check,Snyk и Black Duck.

Тестирование приложения в рабочем состоянии

Динамическое тестирование безопасности приложений (DAST) — это процесс тестирования приложения в рабочем состоянии для поиска уязвимостей системы безопасности. Средства DAST анализируют программы во время выполнения, чтобы найти уязвимости системы безопасности, такие как повреждение памяти, небезопасная конфигурация сервера, межсейтовые скрипты, проблемы с привилегиями пользователей, внедрение КОДА SQL и другие критические проблемы безопасности.

DAST отличается от статического тестирования безопасности приложений (SAST). Средства SAST анализируют исходный код или скомпилированные версии кода, когда код не выполняется, чтобы найти недостатки системы безопасности.

DAST рекомендуется выполнять при участии специалиста по вопросам безопасности (пентестера или оценщика уязвимостей). Если это невозможно, вы можете самостоятельно выполнить DAST с помощью сканера веб-прокси, освоив некоторые приемы. Подключите сканер DAST на ранних этапах, чтобы не допустить возникновения очевидных проблем безопасности в коде. Список сканеров уязвимостей веб-приложений см. на веб-сайте OWASP.

Нечеткое тестирование

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

Security Risk Detection — это уникальная служба нечеткого тестирования Майкрософт, предназначенная для поиска критических с точки зрения безопасности ошибок в программном обеспечении.

Проверка поверхности атаки

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

Вы можете определить поверхность атаки путем сканирования приложения. Корпорация Майкрософт предлагает средство анализа поверхности атаки под названием Attack Surface Analyzer. Вы можете выбрать один из множества коммерческих средств или служб динамического тестирования и сканирования уязвимостей, включая OWASP Attack Surface Detector, Arachni и w3af. Эти средства сканируют приложение и определяют, какие его части доступны через Интернет. Вы также можете выполнить поиск аналогичных средств для разработчиков в Azure Marketplace.

Тесты на проникновение

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

Тесты проверки безопасности

Решение безопасности клиента Azure (AzTS) из комплекта Secure DevOps для Azure (AzSK) содержит SVT для нескольких служб платформы Azure. Запускайте эти тесты время от времени, чтобы гарантировать защиту подписки Azure и других ресурсов, обеспечивающих работу приложения. Эти тесты также можно автоматизировать с помощью расширений AzSK для непрерывной интеграции и непрерывного развертывания (CI/CD), что позволяет выполнять эти тесты с помощью расширения для Visual Studio.

Дальнейшие действия

В следующих статьях представлены элементы управления безопасностью и действия, которые рекомендуется использовать при проектировании и развертывании защищенных приложений.