Приложения и службы

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

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

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

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

Diagram of Application Models

Современные облачные платформы, такие как Azure, могут размещать как устаревшие, так и современные приложения

  • Устаревшие приложения размещаются на виртуальных машинах «Инфраструктура как услуга» (IaaS), которые обычно включают все зависимости, включая ОС, промежуточное ПО и другие компоненты.

  • Современные приложения «Платформа как услуга» (PaaS) не требуют от владельца приложения управления и защиты базовых серверных операционных систем (ОС), и иногда они полностью «бессерверны» и построены в основном с использованием функций как услуги.

    Примечания: Популярные формы современных приложений - это код приложения, размещенный в службах приложений Azure и контейнерные приложения (хотя контейнеры также могут размещаться на виртуальных машинах IaaS или локально).

  • Гибридные – Хотя гибридные приложения могут принимать разные формы, наиболее распространенным является состояние «IaaS plus», когда унаследованные приложения переходят на современную архитектуру с современными службами, заменяющими унаследованные компоненты или добавляемыми унаследованными приложениями.

Для защиты приложения требуются гарантии безопасности для трех различных типов компонентов:

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

  • Службы приложений - это различные стандартизированные компоненты, которые использует приложение, например базы данных, поставщики удостоверений, концентраторы событий, управление устройствами IoT и т. д. Для облачных сервисов это общая ответственность:

    • Облачный провайдер - за безопасность базовой услуги отвечает облачный провайдер

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

  • Платформа хостинга приложений представляет собой вычислительную среду, в которой приложение фактически выполняется и запускается. На предприятии с приложениями, размещенными локально, в Azure и в сторонних облаках, таких как Amazon Web Services (AWS), это может принимать различные формы со значительными различиями в том, кто отвечает за безопасность:

    • Как правило, Устаревшие приложения требуют полной операционной системы (и любого промежуточного программного обеспечения), размещенной на физическом или виртуальном оборудовании. Виртуальное оборудование может быть размещено локально или на виртуальных машинах «Инфраструктура как услуга» (IaaS). Данная операционная система и установленное промежуточное программное обеспечение/другие компоненты управляются и защищаются владельцем приложения или его командой (группами) инфраструктуры.
      Ответственность за физическое оборудование и компоненты виртуализации ОС (хосты виртуализации, операционные системы и службы управления) варьируется:

      • Локально - владелец приложения или его организация несет ответственность за обслуживание и безопасность.

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

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

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

Выявление и классификация критически важных бизнес-приложений

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

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

Определите приложения, которые имеют высокий потенциал воздействия и/или высокий потенциальный риск.

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

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

    • Регулируемые данные – приложения для работы с денежными инструментами и конфиденциальной личной информацией, регулируемые стандартами. Например, индустрия платежных карт (PCI) и Закон о переносимости и подотчетности медицинской информации (HIPAA).

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

    • Значительный доступ - приложения, которые имеют доступ к системам с высоким потенциальным воздействием с помощью технических средств, таких как

      • Сохраненные учетные данные или ключи/сертификаты, предоставляющие доступ к данным/службе

      • Разрешения, предоставленные через списки управления доступом или другими способами

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

Принятие подхода DevOps

Организации должны перейти от «водопадного» цикла разработки к жизненному циклу DevOps с непрерывной интеграцией, непрерывной доставкой (CI/CD) для приложений настолько быстро, насколько это возможно. DevOps - это объединение людей, процессов и инструментов, которые обеспечивают непрерывное предоставление ценности конечным пользователям. Соединение "Dev" и "Ops" означает сочетание разработки и эксплуатации в многофункциональных командах, которые совместно работают с общими и эффективными методиками и инструментами.

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

Следуйте руководству по безопасности DevOps

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

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

Использование облачных сервисов вместо пользовательских реализаций

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

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

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

  • Идентификация – каталоги пользователей и другие функции аутентификации сложно разработать и критически важны для обеспечения безопасности. Избегайте использования собственных решений аутентификации и отдавайте предпочтение зрелым возможностям, таким как Azure Active Directory (Azure AD), Azure AD B2B, Azure AD B2C или решениям сторонних производителей для аутентифицировать и предоставлять разрешения пользователям, партнерам, клиентам, приложениям, службам и другим объектам.

  • Защита данных – разработчикам следует использовать установленные от поставщиков облачных услуг возможности, такие как собственное шифрование в облачных службах, для шифрования и защиты данных. Мир безопасности изобилует примерами неудачных попыток защитить данные или пароли, которые не выдержали реальных атак. Если требуется прямое использование криптографии, разработчики должны вызывать хорошо зарекомендовавшие себя криптографические алгоритмы, а не пытаться изобретать свои собственные.

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

  • Конфигурации приложений – Несогласованные конфигурации приложений могут создавать риски для безопасности. Конфигурация приложений Azure предоставляет службу для централизованного управления параметрами приложений и флагами функций, что помогает снизить данный риск.

Используйте возможности Native Security в службах приложений

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

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

  • Список служб Azure
    https://azure.microsoft.com/services/

  • Предпочтение идентификации процедуры проверки подлинности ключам
    </azure/security/common-security-attributes>

Предпочитать проверку подлинности с помощью ключей

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

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

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

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

image showing bottom-up approach to reduce security bug volume and impact

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

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

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

Нисходящий подход через моделирование угроз

image showing top-down approach through threat modeling

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

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

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

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

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

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

    1. Начните с метода простых вопросов (см. Метод простых вопросов), описанного ниже, чтобы быстро получить представление о рисках и наличии основных средств защиты

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

      1. Дизайн на уровне системы - включает приложения и то, как они взаимодействуют друг с другом

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

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

  3. Согласование с жизненным циклом разработки – оптимизируйте свои усилия, согласовывая действия по моделированию угроз с жизненными циклами разработки приложений.

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

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

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

Метод простых вопросов

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

Задайте эти вопросы для каждого приложения или компонента и ответьте на них

  • Вы проводите проверку подлинности соединений с помощью Azure AD, TLS (с взаимной проверкой подлинности) или другого современного протокола безопасности, одобренного вашей группой безопасности? Это защищает от несанкционированного доступа к приложению и данным

    • Между пользователями и приложением (если применимо)

    • Между различными компонентами приложения и службами (если применимо)

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

  • Регистрируется ли активность приложения и передается ли она в систему управления информацией и событиями безопасности (SIEM) через Azure Monitor или аналогичное решение? Это помогает группе безопасности обнаруживать атаки и быстро их расследовать.

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

  • Шифруется ли входящий и исходящий сетевой трафик с помощью TLS? Это помогает защитить от несанкционированного копирования данных во время передачи.

  • Защищено ли приложение от атак распределенного отказа в обслуживании (DDoS) с использованием таких служб, как защита от DDoS-атак Azure, Akamai или аналогичных? Это защищает от атак, направленных на перегрузку приложения, чтобы его нельзя было использовать

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

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

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

Расширенные методы моделирования угроз

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

  • Microsoft Security Development Lifecycle задокументировал процесс моделирования угроз и выпустил бесплатный инструмент для помощи в этом процессе

    • Данный метод оценивает компоненты приложения и соединения/отношения на предмет потенциальных рисков, которые отображаются в мнемонике STRIDE:

      • спуфинг;

      • незаконное изменение;

      • отказ;

      • Раскрытие информации

      • Отказ в обслуживании

      • Повышение привилегий

    • Данный метод может быть применен к любому уровню дизайна от высокоуровневых архитектурно-специфических прикладных компонентов.

  • OWASP – служба Open Web Application Security Project (OWASP) задокументировала подход к моделированию угроз для приложений, который относится к STRIDE и другим методам https://www.owasp.org/index.php/Application_Threat_Modeling

Используйте брандмауэры веб-приложений

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

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

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

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

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

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

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

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

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

Несмотря на то, что это новое пространство, которое быстро развивается, стали очевидны несколько извлеченных ключевых уроков и передовых методов:

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

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

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

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

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

  • Не запускайте контейнеры от имени пользователя root или администратора, если это явно не требуется
    Ранние версии контейнеров требовали привилегий root (что упрощало атаки), но в текущих версиях это больше не требуется.

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

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

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