Определение стратегии безопасности

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

Модернизация стратегии безопасности

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

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

Мониторинг и защита в масштабе облака

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

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

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

Безопасность облака и посредством облака

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

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

Защита программно-определяемых центров обработки данных

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

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

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

Примечание

Центр безопасности Azure и Azure Defender теперь называются Microsoft Defender для облака. Кроме того, мы переименовали планы Azure Defender в планы Microsoft Defender. Например, Azure Defender для хранилища теперь называется Microsoft Defender для хранилища.

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

Правильный уровень разногласий по поводу безопасности

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

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

Отдельные и интегрированные обязанности

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

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

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

Трансформации, мировоззрение и ожидания

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

Процесс внутренней трансформации обычно включает в себя следующее:

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

Внутренний конфликт может обойтись очень дорого

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

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

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

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

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

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

Устойчивость кибербезопасности

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

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

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

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

Как облако меняет безопасность

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

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

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

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

  Обязанности команд по безопасности:

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

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

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

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

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

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

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

Внедрение модели общей ответственности

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

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

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

Создание инициатив по безопасности

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

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

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

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

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

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

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

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

Безопасность и доверие

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

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

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

Как облако меняет отношения и обязанности в сфере безопасности

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

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

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

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

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

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

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

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

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

  Эти тенденции бросают вызов традиционным нормам для ролей и взаимосвязей приложений и инфраструктуры:

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

  

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

  

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

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

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

    

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

    • Запуск кода вместо размещения приложений на виртуальных машинах и серверах.
    • Предоставление функций приложения вместо разработки собственных компонентов. Это привело к созданию бессерверной модели, в которой для обычных функций используются существующие облачные службы. Количество и разнообразие облачных служб (и скорость внедрения в них инноваций) также превышают возможности групп безопасности по оценке и утверждению использования таких служб. В результате у них остается выбор — позволить разработчикам использовать любую службу, попытаться препятствовать использованию неутвержденных служб командами разработчиков либо попытаться найти лучший способ.
    • Приложения без кода и Power Apps. Другой новой тенденцией является использование технологий, не требующих написания кода, таких как Microsoft Power Apps. Эта технология позволяет людям без навыков программирования создавать приложения для достижения бизнес-результатов. Из-за несущественных разногласий и высокого ценностного потенциала эта тенденция может быстро набрать популярность, поэтому специалистам по безопасности стоит побыстрее изучить возможные последствия. Усилия по обеспечению безопасности следует сосредоточить на тех областях, где человек может допустить ошибку в приложении, а именно на дизайне приложения и разрешениях ресурсов, применяя моделирование угроз для компонентов приложения, взаимодействий/отношений и разрешений ролей.

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

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

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

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

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

    Примечание

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

    Корпорация Майкрософт опубликовала свои принципы ответственного применения ИИ, которыми руководствуются как наши собственные команды, так и наши клиенты.

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

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

  • Ускорение инициатив по цифровой трансформации за счет сокращения времени выпуска новых возможностей.

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

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

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

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

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

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

    • Microsoft Defender for Cloud Apps позволяет обнаруживать использование более 16 000 облачных приложений, которые ранжируются и оцениваются по более чем 70 факторам риска, чтобы предоставить актуальные сведения об использовании облака, о теневых ИТ и связанных с ними рисках для вашей организации.
    • Microsoft Service Trust Portal предоставляет клиентам доступ к сертификациям соответствия нормативным требованиям, отчетам об аудите, тестам на проникновение и многому другому. Эти документы включают множество подробностей о внутренних методах обеспечения безопасности (в частности, отчет SOC 2 типа 2 и план обеспечения безопасности системы FedRAMP Moderate). Microsoft Defender для облака позволяет управлять политиками безопасности и может указывать уровень соответствия предопределенным отраслевым и нормативным стандартам.

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

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

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

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