Защита ресурсов

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

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

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

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

Примечание

Защита ресурсов, как правило, реализуется командами по ИТ-операциям, которые обслуживают эти ресурсы, с помощью экспертов из команды безопасности. Дополнительные сведения см. в разделе Командная разработка элементов управления.

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

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

Просмотрите следующее видео, чтобы узнать об истории защиты ресурсов и о том, как защитить старые и новые ресурсы.

Обеспечение безопасности

Инициатива "Обеспечение безопасности" направлена на присоединение ресурсов в соответствии со стандартами, политиками и архитектурой безопасности вашей организации. Существует два вида действий:

  • Этап "Браунфилд": модификация стандартов безопасности и элементов управления с учетом существующих ресурсов. Организации могут разрабатывать ИТ-среды и оперировать ими, рассматривая безопасность как низкоприоритетную задачу. Такой подход создает так называемый "технический долг": слабые конфигурации безопасности, необновляющееся и устаревшее программное обеспечение, незашифрованные каналы связи и хранилища, устаревшие протоколы и т. п. Используйте современный подход к развертыванию элементов управления. Это критически важно в плане уменьшения рисков, поскольку злоумышленники постоянно улучшают методы и средства эксплуатации слабых мест.
  • Этап "Гринфилд": настройка новых ресурсов и типов ресурсов в соответствии со стандартами. Этот процесс очень важен, поскольку позволяет избежать постоянного создания устаревших или браунфилд-систем, которые не соответствуют текущим стандартам. Технический долг придется устранять позже и при больших затратах, что повышает риски взлома системы.

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

Поддержание безопасности

Со временем все приходит в упадок. Физические компоненты изнашиваются. Среда меняется в зависимости от виртуальных элементов (программного обеспечения, элементов управления безопасностью и средств обеспечения безопасность). Эти элементы могут больше не соответствовать меняющимся требованиям. Сегодня эти перемены происходят стремительнее, чем когда-либо. Это обусловлено быстрым изменением следующих аспектов.

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

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

Поддержание безопасности подразумевает множество аспектов. Уделите особое внимание двум специфическим областям защиты ресурсов.

  • Непрерывное улучшение облака. Возможности обеспечения безопасности, которые предоставляет облако, непрерывно совершенствуются. Используйте это. Например, во многие службы Azure, такие как служба хранилища Azure и База данных SQL Microsoft Azure, постепенно добавляются новые функции, обеспечивающие защиту от действий злоумышленников.
  • Окончание жизненного цикла программного обеспечения. Жизненный цикл любого программного обеспечения, включая операционные системы, рано или поздно заканчивается, и обновления для системы безопасности этого ПО больше не предоставляются. В таких ситуациях критически важные для бизнеса данные и приложения становятся легкой мишенью для атак злоумышленников. Хотя поставщики облачных служб поддерживают программное обеспечение как услугу, облачные инфраструктуры и платформы, у предприятий часто имеется собственное программное обеспечение, которое им необходимо устанавливать и обслуживать.

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

Вопросы исправления

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

  • Операционный риск: изменение программного обеспечения, при которых запуск систем, может нарушить работу бизнес-процессов. Такие изменения влияют на предположения, которые делаются при настройке системы для организации. Этот факт подразумевает, что лучше избегать изменения системы.
  • Угроза безопасности: атака, которая может привести простою. Злоумышленники анализируют все основные обновления систем, когда они появляются на рынке. Рабочий эксплойт можно разработать в течение 24–48 часов и с его помощью атаковать организации, которые не успели установить обновление системы безопасности.

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

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

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

Сетевая изоляция

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

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

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

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

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

Начало работы

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

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

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

    • Базовые показатели безопасности из Тестирования безопасности Azure. Корпорация Майкрософт предоставляет руководство по настройке системы безопасности для отдельных служб Azure. Базовые показатели безопасности Azure применяются к уникальным атрибутам каждой службы. Этот подход позволяет командам по безопасности обеспечивать защиту каждой службы и уточнять конфигурации по мере необходимости. Дополнительные сведения см. в разделе о базовых показателях безопасности в Azure.
    • Базовые показатели безопасности Майкрософт. Корпорация Майкрософт предоставляет руководство по настройке безопасности для часто используемых технологий, в том числе Windows, Microsoft Office и Microsoft Edge. Дополнительные сведения см. в разделе о базовых показателях безопасности Майкрософт.
    • Тесты производительности CIS. Центр интернет-безопасности (CIS) предоставляет конкретные рекомендации по настройке для многих продуктов и поставщиков. Дополнительные сведения см. в разделе Тесты производительности CIS.

Основные сведения

Эти основные элементы помогут вам защитить ресурсы.

Подотчетные и ответственные команды

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

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

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

Дополнительные сведения об общей модели ответственности см. в разделе Общая ответственность в облаке.

Эластичность облака

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

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

Управление исключениями

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

Проблема измерения ценности

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

Автоматизированные политики

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

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

Командная разработка элементов управления

Разработка всех элементов управления должна совместно вестись всеми основными заинтересованными лицами.

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

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

Следующая тема: управление безопасностью