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

Статья
09/29/2024

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

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

Обучение
Требования
Проект

Обучение

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

Используйте следующие ресурсы на этапе обучения, чтобы ознакомиться со службами Azure, доступными для разработчиков, и с рекомендациями по обеспечению безопасности в Azure:

Руководство для разработчиков в Azure показывает, как приступить к работе с Azure. В этом руководстве показано, какие службы можно использовать для запуска приложений, хранения данных, внедрения аналитики, создания приложений IoT и развертывания решений более эффективным и безопасным способом.
Руководство по началу работы для разработчиков Azure предоставляет необходимые сведения для разработчиков, желающих приступить к работе с платформой Azure в соответствии с потребностями разработки.
Пакеты SDK и инструменты содержит описание инструментов, доступных в Azure.
Azure DevOps Services предоставляет инструменты для совместной работы в среде разработки. В их число входят высокопроизводительные конвейеры, бесплатные частные репозитории Git, настраиваемые канбан-доски, а также автоматизированные и облачные инструменты для нагрузочного тестирования. Центр ресурсов DevOps объединяет наши ресурсы для изучения методик DevOps, управления версиями Git, гибких методов разработки, способов работы с DevOps в корпорации Майкрософт, а также для оценки вашего собственного процесса DevOps.
Первые пять элементов безопасности, которые следует учитывать перед отправкой в рабочую среду , показано, как защитить веб-приложения в Azure и защитить приложения от наиболее распространенных и опасных атак веб-приложений.
Secure DevOps Kit для Azure — это коллекция сценариев, инструментов, расширений и автоматизации, которые обеспечивают комплексную подписку Azure и потребности в безопасности ресурсов команд DevOps, использующих обширную автоматизацию. Безопасный набор средств DevOps для Azure содержит примеры, которые вы можете использовать для плавной интеграции безопасности в свои рабочие процессы DevOps. В набор входят такие средства, как тесты проверки безопасности (SVT), которые помогают разработчикам создавать безопасный код и тестировать безопасную конфигурацию своих облачных приложений в ходе проектирования кода и на ранних стадиях разработки.
Рекомендации по безопасности Azure и шаблоны . Коллекция рекомендаций по обеспечению безопасности, используемых при разработке, развертывании и управлении облачными решениями с помощью Azure. Руководство предназначено для ИТ-специалистов. К ним могут относиться проектировщики, архитекторы, разработчики и тестировщики, занимающиеся созданием и развертыванием безопасных решений в Azure.

Требования

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

Учет вопросов безопасности и конфиденциальности

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

понять риски, связанные с проблемами безопасности;
выявлять и устранять ошибки безопасности во время разработки;
применять установленные уровни безопасности и конфиденциальности в рамках всего проекта.

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

Контрольные вопросы

Задавайте контрольные вопросы, например такие.

Содержит ли мое приложение конфиденциальные данные?
Будет ли мое приложение собирать или хранить данные, которые должны соответствовать отраслевым стандартам и программам обеспечения соответствия, таким как требования Федерального совета по надзору за финансовыми учреждениями (FFIEC) или Стандарты безопасности данных в сфере платежных карт (PCI DSS)?
Будет ли мое приложение собирать или содержать конфиденциальные личные данные или данные клиентов, которые можно использовать отдельно или вместе с другой информацией, чтобы идентифицировать, установить связь или отыскать конкретного человека?
Будет ли мое приложение собирать или содержать данные, которые можно использовать для доступа к медицинской, образовательной, финансовой информации или информации о занятости конкретного человека? Определение конфиденциальности данных на этапе требований помогает классифицировать данные и определять метод защиты данных, используемый для приложения.
Где и как хранятся мои данные? Рассмотрим, как отслеживать службы хранилища, которые приложение использует для любых непредвиденных изменений (например, более медленное время отклика). Вы можете повлиять на ведение журнала для сбора более подробных данных и подробного анализа проблемы?
Доступно ли мое приложение для общественности (в Интернете) или только внутренне? Если ваше приложение общедоступно, как вы будете защищать данные, которые могут быть собраны в случае неправильного использования? Если приложение доступно только для внутреннего использования, определите, какие сотрудники вашей организации и в течение какого времени должны иметь доступ к нему.
Обдумали ли вы модель идентификации перед началом разработки приложения? Можете ли вы определить, что пользователи, которые говорят, что они есть, и что пользователь авторизован для выполнения?
Выполняет ли мое приложение конфиденциальные или важные задачи (например, передачу денег, разблокирование дверей или доставку медицинских препаратов)? Рассмотрим, как вы проверяете, что пользователь, выполняющий конфиденциальную задачу, авторизован для выполнения задачи и как вы проверяете подлинность того, кто он говорит, что они есть. Авторизация (AuthZ) — это акт предоставления разрешения на выполнение какого-либо действия субъекту безопасности, прошедшему аутентификацию. Аутентификация (AuthN) — это акт запроса законных учетных данных стороны.
Выполняет ли мое приложение какие-либо рискованные программные действия, например разрешает пользователям отправлять или загружать файлы или другие данные? Если приложение выполняет рискованные действия, рассмотрите способ защиты пользователей от обработки вредоносных файлов или данных.

Просмотр документа OWASP Top 10

Рассмотрите Угрозы безопасности приложений OWASP Top 10. В документе OWASP Top 10 представлены наиболее серьезные угрозы безопасности веб-приложений. Осведомленность об этих угрозах может помочь вам принять решения в отношении требований и разработки, которые снизят риски в вашем приложении.

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

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

Проект

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

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

На этапе проектирования также подумайте о том, как применить многоуровневую безопасность. Одного уровня защиты может оказаться недостаточно. Что произойдет, если злоумышленник проникнет за брандмауэр веб-приложения (WAF)? Для защиты от такой атаки нужен еще один элемент управления безопасностью.

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

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

использование библиотеки безопасного кода и программной платформы.

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

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

Корпорация Майкрософт предлагает различные языки, платформы и инструменты , которые можно использовать для разработки приложений в Azure. Например, Azure для разработчиков .NET и .NET Core. Для каждого языка и платформы, которую мы предлагаем, можно найти краткие руководства, руководства и ссылки на API, которые помогут вам быстро приступить к работе.

Azure предлагает различные службы, которые можно использовать для размещения веб-сайтов и веб-приложений. С помощью этих служб вы можете выполнять разработку на привычном языке: .NET, .NET Core, Java, Ruby, Node.js, PHP или Python. Одной из таких служб являются Веб-приложения службы приложений Azure (Веб-приложения).

Веб-приложения службы приложений дополняют ваше приложение возможностями Microsoft Azure. В их число входят безопасность, балансировка нагрузки, автоматическое масштабирование и автоматизированное управление. Вы также можете воспользоваться такими преимуществами DevOps в веб-приложениях службы приложений, как управление пакетами, использование промежуточных сред, личные домены, TLS/SSL-сертификаты и непрерывное развертывание, из Azure DevOps, GitHub, Docker Hub и других источников.

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

Применение обновлений к компонентам

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

Рекомендуемые инструменты см. на странице Open Web Application Security Project (OWASP), посвященной использованию компонентов с известными уязвимостями. Вы также можете подписываться на оповещения по электронной почте об уязвимостях системы безопасности, связанных с используемыми вами компонентами.

Использование моделирование угроз во время разработки приложения

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

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

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

Угроза	Свойство безопасности	Устранение потенциальных рисков платформы Azure
Спуфинг	Проверка подлинности	Требуйте подключение только по протоколу HTTPS.
Незаконное изменение	Целостность	Проверяйте SSL/TLS-сертификаты. Приложения, использующие протокол SSL и TLS, должны тщательно проверять сертификаты X.509 сущностей, к которым они подключаются. Используйте сертификаты Azure Key Vault для управления сертификатами x509.
Отказ	Неподдельность	Включите мониторинг и диагностику в Azure.
Раскрытие информации	Конфиденциальность	Выполняйте шифрование конфиденциальных неактивных и передаваемыхданных.
Отказ в обслуживании	Availability	Отслеживайте метрики производительности на наличие признаков атаки типа "отказ в обслуживании". Примените фильтры подключения. Служба Защита от атак DDoS Azure обеспечит защиту от атак DDoS, если соблюдаются рекомендации по проектированию приложений.
Несанкционированное получение привилегий	Авторизация	Используйте идентификатор Microsoft Entra ID управление привилегированными пользователями.

Сокращение возможных направлений атаки

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

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

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

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

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

Анализ возможных направлений атаки помогает выявить:

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

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

Мы рассмотрим проведение проверки возможных направлений атаки на этапе проверки в жизненном цикле разработки защищенных приложений (Майкрософт).

Примечание.

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

Применение политики удостоверения в качестве основного периметра безопасности

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

Что вы можете сделать для применения подхода, ориентированного на удостоверения, при разработке веб-приложений:

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

Принудительное применение многофакторной проверки подлинности для пользователей

Используйте двухфакторную аутентификацию. Двухфакторная аутентификация в настоящее время является стандартом аутентификации и авторизации, так как позволяет избежать уязвимостей системы безопасности, присущих разновидностям аутентификации по имени пользователя и паролю. Доступ к интерфейсам управления Azure (портал Azure/remote PowerShell) и к службам, подключенным к клиентам, должен быть разработан и настроен для использования многофакторной проверки подлинности Microsoft Entra.

Используйте надежные платформы аутентификации и авторизации

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

Платформа удостоверений Майкрософт — это набор компонентов, используемый разработчиками для создания приложений, обеспечивающих безопасный вход пользователей. Платформа помогает разработчикам создавать приложения с одним клиентом, бизнес-приложениями и разработчиками, которые хотят разрабатывать мультитенантные приложения. В дополнение к базовому входу приложения, созданные с помощью платформы удостоверений Майкрософт, могут вызывать API Майкрософт и настраиваемые API. Платформа удостоверений Майкрософт поддерживает стандартные отраслевые протоколы, такие как OAuth 2.0 и OpenID Connect.
Azure Active Directory B2C (Azure AD B2C ) — это служба управления удостоверениями, используемая для настройки и контроля регистрации, входа клиентов и управления профилями при использовании приложений. Среди прочего, сюда входят приложения, разработанные для iOS, Android и .NET. Azure AD B2C разрешает эти действия и в то же время защищает пользовательские удостоверения.

Применяйте принцип минимально необходимых привилегий

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

Требуются ли разработчику программного обеспечения права администратора домена? Нужен ли секретарю-референту доступ к административным элементам управления на своем персональном компьютере? Процесс оценки доступа к программному обеспечению один и тот же. Если вы используете управление доступом на основе ролей Azure (Azure RBAC) для предоставления пользователям различных возможностей и полномочий в вашем приложении, вам не нужно предоставлять полный доступ каждому пользователю. Ограничивая доступ только необходимыми функциями для каждой роли, вы снижаете риск возникновения проблем безопасности.

Убедитесь, что во всех шаблонах доступа вашего приложения применяется принцип наименьших привилегий.

Примечание.

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

Реализуйте JIT-доступ

Реализуйте JIT-доступ для дальнейшего сокращения времени доступности привилегий. Использование Microsoft Entra управление привилегированными пользователями для:

предоставлять пользователям только необходимые им разрешения с JIT-доступом;
назначать роли на короткий период с автоматическим отзывом привилегий.

Требовать повторную проверку подлинности для важных транзакций

Подделка межсайтовых запросов (также известная как XSRF или CSRF) — это атаки, применяемые против приложений, размещенных в сети, когда вредоносное веб-приложение может влиять на взаимодействие между клиентским браузером и веб-сайтом, которому доверяет браузер. Атаки путем подделки межсайтовых запросов возможны, поскольку веб-браузеры автоматически отправляют некоторые типы маркеров проверки подлинности при каждом запросе на веб-сайт. Такая форма использования уязвимостей называется также атакой одним щелчком или захватом сеанса, поскольку атака использует преимущества ранее проверенного сеанса пользователя.

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

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

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

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

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

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

Внимание

Решение Azure Key Vault предназначено для хранения секретов конфигурации серверных приложений. Оно не предназначено для хранения данных, принадлежащих пользователям приложений. Это отражается в его характеристиках производительности, API и модели затрат.

Пользовательские данные должны храниться в другом расположении, например в экземпляре базы данных SQL Azure, который имеет прозрачное шифрование данных (TDE), или в учетной записи хранения, использующей Шифрование службы хранилища Azure. Секреты, используемые вашим приложением для доступа к этим хранилищам данных, можно хранить в Azure Key Vault.

Защита конфиденциальных данных

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

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

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

Использовать шифрование

Защита данных должны быть важнейшей частью вашей стратегии безопасности. Если данные хранятся в базе данных или перемещаются между расположениями, используйте шифрование неактивных данных (в базе данных) и шифрование передаваемых данных (на пути к пользователю, базе данных, API или конечной точке службы). Мы рекомендуем использовать протоколы SSL/TLS для обмена данными. Используйте последнюю версию протокола TLS для шифрования (сейчас это версия 1.2).

Избегайте жесткого программирования

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

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

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

Ранее мы обсуждали Azure Key Vault. Вы можете использовать Key Vault для хранения секретов, таких как ключи и пароли, а не жестко программировать их. Key Vault в сочетании с управляемыми удостоверениями для ресурсов Azure позволяет веб-приложению Azure легко и безопасно получать доступ к секретным данным конфигурации без необходимости хранить секреты в системе управления версиями или в конфигурации. Дополнительные сведения см. в статье Управление секретами в серверных приложениях с помощью Azure Key Vault.

Реализуйте резервные меры

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

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

Используйте преимущества обработки ошибок и исключений

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

Убедитесь в следующем:

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

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

Используйте ведения журнала и оповещения

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

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

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

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

Следующие шаги

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

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