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

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

Контроль доступа, шифрование, DLP/CAB, маскирование, анонимизация или псевдонимизация — все это может помочь защитить конфиденциальные данные в облаке. Но как эти кусочки головоломки сочетаются друг с другом? И как публичные облака, такие как AWS, помогают инженерам и специалистам по безопасности, реализующим такую ​​архитектуру? Давайте копаться.

Контроль доступа

Первая часть головоломки защиты данных настолько очевидна, что инженеры могут даже забыть упомянуть о ней: контроль доступа (рис. 1, А). Следуя принципу служебной необходимости, доступ к данным должны иметь только сотрудники или технические учетные записи, которым действительно необходима информация. Таким образом, доступ к данным должен быть возможен только после того, как кто-то явно предоставил доступ. Контроль доступа имеет два нюанса: управление идентификацией и доступом (например, RBAC и LDAP) и подключение на сетевом уровне (например, межсетевые экраны).

Шифрование

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

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

Крупные поставщики облачных услуг, такие как Microsoft Azure , Google GCP и Amazon AWS , отказались от концепций шифрования и контроля доступа в своих сервисах. Они шифруют (почти) все данные, которые хранят, будь то данные в GCP Bigtable, Azure CosmosDB или объектном хранилище AWS S3. Трудно найти облачный сервис без шифрования по умолчанию, позволяющего защитить конфиденциальные данные.

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

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

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

Маскирование, анонимизация и псевдонимизация

Маскирование, анонимизация и псевдонимизация скрывают конфиденциальные данные в базах данных, включая личную информацию (PII), такую ​​как номера социального страхования, номера счетов IBAN или частные медицинские данные. Однако сокрытие работает по-другому:

• Маскировка нулей или «исчезаний» конфиденциальных данных. Например, каждый IBAN становится «XXXXXXXXXX».
• Анонимизация заменяет конфиденциальные данные псевдоданными. Анонимизация по определению необратима, но сохраняет такие отношения, как отношения первичного-внешнего ключа между таблицами базы данных. Типичными вариантами реализации являются перетасовка данных (например, присвоение номеров IBAN разным, «неправильным» клиентам), замена данных сгенерированными новыми элементами данных или хеширование. Два момента имеют решающее значение. Во-первых, согласованность замен, независимо от того, где находятся данные. Если «старый» IBAN — CH249028899406, вхождения во всех таблицах и файлах становятся новым «анонимным» IBAN CH32903375, где бы он ни находился. Во-вторых, не должно быть сопоставления старого с новым. Если такая таблица необходима во время анонимизации, ее необходимо удалить впоследствии для обеспечения необратимости.
• Псевдонимизация заменяет конфиденциальные данные в конкретных системах и базах данных токенами. Системы, инженеры и пользователи, видя токены, не могут восстановить исходные данные; только специальный компонент может псевдонимизировать и депсевдонимизировать данные.

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

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

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

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

Брокер безопасности доступа к облаку и предотвращению потери данных

Последними частями головоломки по защите облачных данных являются предотвращение потери данных (DLP), брокеры безопасности доступа к облаку (CASB) и прокси (рис. 1, E). В отличие от контроля доступа, в этой группе инструментов и методологий основное внимание уделяется не тому, кто может получить доступ к данным. Вместо этого они помогают предотвратить неправомерное использование и кражу данных пользователями, у которых есть законная потребность просматривать данные и работать с ними.

Прокси-серверы обеспечивают безопасность в стиле кувалды: полностью блокируют URL-адреса, чтобы предотвратить передачу данных в облачные сервисы, такие как DropBox. CASB — это вариант в стиле скальпеля. Они включают контекстную информацию при принятии решения о разрешении или блокировании трафика (например, принимая во внимание конкретного пользователя). Network DLP анализирует трафик с ноутбуков или серверов в облако. На рабочем месте система DLP электронной почты проверяет исходящую почту.

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

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