Рекомендации по классификации данных

Применяется к рекомендации по контрольным спискам безопасности Azure Well-Architected Framework:

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

Определения

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

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

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

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

Наряду с этими рекомендациями см. Create хорошо спроектированную платформу классификации данных.

Общие сведения о таксономии, определяемой организацией

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

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

Ниже приведены некоторые примеры меток классификации для уровней конфиденциальности, типа информации и область соответствия.

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

Определение область классификации

Большинство организаций имеют разнообразный набор меток.

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

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

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

Инвентаризация хранилищ данных

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

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

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

Проектирование в соответствии с метками классификации

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

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

Для неактивных данных уровни влияют на выбор шифрования. Вы можете защитить конфиденциальные данные с помощью двойного шифрования. Разные секреты приложений могут даже требовать контроля с различными уровнями защиты. Вы можете оправдать хранение секретов в хранилище аппаратного модуля безопасности (HSM), которое предлагает более высокие ограничения. Метки соответствия также определяют принятие решений о правильных стандартах защиты. Например, стандарт PCI-DSS предписывает использовать защиту FIPS 140-2 уровня 3, которая доступна только с модулями HSM. В других случаях может быть приемлемо, чтобы другие секреты хранились в обычном хранилище управления секретами.

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

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

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

Это также влияет на операции управления жизненным циклом данных, такие как хранение и списание данных.

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

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

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

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

Фактическая реализация зависит от типа ресурсов. Некоторые ресурсы Azure имеют встроенные системы классификации. Например, Azure SQL Server имеет подсистему классификации, поддерживает динамическое маскирование и может создавать отчеты на основе метаданных. Служебная шина Azure поддерживает включение схемы сообщения, которая может содержать вложенные метаданные. При проектировании реализации оцените поддерживаемые платформой функции и воспользуйтесь ими. Убедитесь, что метаданные, используемые для классификации, изолированы и хранятся отдельно от хранилищ данных.

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

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

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

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

Упрощение поддержки Azure

Microsoft Purview объединяет решения Azure Purview и Microsoft Purview для обеспечения видимости ресурсов данных в вашей организации. Дополнительные сведения см. в статье Что такое Microsoft Purview?

Azure SQL Базы данных, Управляемый экземпляр SQL Azure и Azure Synapse Analytics предлагают встроенные функции классификации. Используйте эти средства для обнаружения, классификации, маркировки и создания отчетов о конфиденциальных данных в базах данных. Дополнительные сведения см. в разделе Обнаружение и классификация данных.

Пример

В этом примере используется среда информационных технологий (ИТ), созданная в базовом плане безопасности (SE:01). На приведенной ниже схеме показаны хранилища данных, в которых классифицируются данные.

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

2. Приложения взаимодействуют с базами данных или данными, хранящимися на дисках, таких как хранилище объектов или файловые серверы.

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

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

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

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

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

8. Локальные серверы подключаются к важным данным, которые необходимо классифицировать и защищать, например к файловыми серверам, хранилищу объектов и различным типам баз данных, таким как реляционные базы данных, no-SQL и хранилище данных.

9. Microsoft Purview Compliance предоставляет решение для классификации файлов и сообщений электронной почты.

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

Связанные ссылки

• Классификация данных и классификация меток конфиденциальности — Microsoft Service Assurance
• Create хорошо спроектированную платформу классификации данных — Microsoft Service Assurance

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

См. полный набор рекомендаций.