Поделиться через

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

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

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

  • Implementation
  • Verification

Implementation

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

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

Перед проверкой кода провести проверки кода, чтобы повысить общее качество кода и снизить риск создания ошибок. You can use Visual Studio to manage the code review process.

Выполнение анализа статического кода

Статический анализ кода (также известный как анализ исходного кода) выполняется в рамках проверки кода. Анализ статического кода обычно относится к запуску средств анализа статического кода для поиска потенциальных уязвимостей в нерабочном коде. Static code analysis uses techniques like taint checking and data flow analysis.

Azure Marketplace offers developer tools that perform static code analysis and assist with code reviews.

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

Обрабатывать все входные данные как ненадежные, чтобы защитить приложение от наиболее распространенных уязвимостей веб-приложения. Ненадежные данные — это средство для атак методом внедрения. Входные данные для вашего приложения включают параметры в URL-адресе, данные от пользователя, данные из базы данных или из API, а также все, что передается и может быть изменено пользователем. An application should validate that data is syntactically and semantically valid before the application uses the data in any way (including displaying it back to the user).

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

Блокировка и список разрешений являются двумя общими подходами к выполнению проверки синтаксиса ввода:

  • Создание черного списка проверяет, что введенные пользователем данные не содержат содержимое, известного как вредоносное.

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

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

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

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

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

Все выходные данные, которые вы представляете визуально или в документе, всегда должны быть закодированы и экранированы. Escaping, also known as output encoding, is used to help ensure that untrusted data isn't a vehicle for an injection attack. Применение экранирования вместе с проверкой данных создает многоуровневую защиту, повышающую безопасность всей системы.

Escaping makes sure that everything is displayed as output. Escaping also lets the interpreter know that the data isn't intended to be executed, and this prevents attacks from working. This is another common attack technique called cross-site scripting (XSS).

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

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

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

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

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

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

Разделение рабочих данных

Рабочие данные или реальные данные не должны использоваться для разработки, тестирования или какой-либо другой цели, отличной от того, что предназначено для бизнеса. A masked (anonymized) dataset should be used for all development and testing.

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

Реализация политики строгого пароля

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

Внешний идентификатор Microsoft Entra во внешних арендаторах помогает управлять паролями, предоставляя самостоятельный сброс пароля и многое другое.

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

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

Проверка отправки файлов

If your application allows file uploads, consider precautions that you can take for this risky activity. Первым шагом во многих атаках является получение вредоносного кода в систему, которая находится под атакой. Использование отправки файлов помогает злоумышленнику выполнить это. OWASP предлагает решения для проверки файла, чтобы убедиться, что загруженный файл является безопасным.

Защита от вредоносных программ помогает выявлять и удалять вирусы, шпионские программы и другое вредоносное программное обеспечение. You can install Microsoft Antimalware or a Microsoft partner's endpoint protection solution (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus in Windows, and Endpoint Protection).

Microsoft Antimalware includes features like real-time protection, scheduled scanning, malware remediation, signature updates, engine updates, samples reporting, and exclusion event collection. Для упрощения развертывания и использования встроенных обнаружений (оповещений и инцидентов) Microsoft Antimalware и партнерские решения можно интегрировать с Microsoft Defender для облака.

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

Не кэшируйте конфиденциальное содержимое в браузере. Браузеры могут хранить сведения для кэширования и истории. Кэшированные файлы хранятся в папке, например в папке временных файлов Интернета в случае Internet Explorer. При повторном обращении к этим страницам браузер отображает страницы из кэша. If sensitive information (address, credit card details, Social security number, username) is displayed to the user, the information might be stored in the browser's cache and be retrievable by examining the browser's cache or by pressing the browser's Back button.

Verification

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

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

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

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

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

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

Perform DAST, preferably with the assistance of a security professional (a penetration tester or vulnerability assessor). Если специалист по безопасности недоступен, вы можете самостоятельно выполнять DAST с помощью сканера веб-прокси и некоторых учебных занятий. Подключите сканер DAST на ранней стадии, чтобы убедиться, что в коде не возникают очевидные проблемы с безопасностью. See the OWASP site for a list of web application vulnerability scanners.

Выполнение нечёткого тестирования

In fuzz testing, you induce program failure by deliberately introducing malformed or random data to an application. Сбой программы помогает выявить потенциальные проблемы безопасности перед выпуском приложения.

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

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

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

Вы можете создать изображение области атаки, просканировав приложение. Корпорация Майкрософт предлагает средство анализа поверхностей атак под названием "Анализатор поверхности атаки". Вы можете выбрать множество средств или служб для проверки уязвимостей, включая детектор атак OWASP, Arachni и w3af. Эти средства сканирования обходят приложение и сопоставляют части приложения, доступные через Интернет. You can also search the Azure Marketplace for similar developer tools.

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

Убедитесь, что ваше приложение безопасно, так же важно, как тестирование любых других функций. Make penetration testing a standard part of the build and deployment process. Запланируйте регулярные тесты безопасности и сканирование уязвимостей в развернутых приложениях и отслеживайте открытые порты, конечные точки и атаки.

Запуск тестов проверки безопасности

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

Next steps

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

  • Last updated on