Санкт-Петербург
«БХВ-Петербург»
2024

УДК 004.738.5
ББК 32.973.26-018.2
Б11
Б11

Бхаджария Н.
Конфиденциальность данных: Пер. с англ. — СПб.: БХВ-Петербург,
2024. — 432 с.: ил.
ISBN 978-5-9775-1888-8
Во всех деталях рассматривается обеспечение конфиденциальности данных в
масштабах большой и/или растущей компании. Уделено внимание защите конкурентных преимуществ, корпоративной репутации, а также пользовательских личных данных. Затронуты вопросы классификации данных по степени важности их
защиты, вопросы масштабирования и репликации хранилищ данных без ущерба
конфиденциальности, соответствие юридическим нормам, различные инструменты, обеспечивающие отслеживание и защиту данных. Также рассказано, как с нуля
выстроить защиту конфиденциальных данных в крупной компании, в том числе
активно использующей облачные хранилища данных.
Для сетевых инженеров, специалистов по безопасности,
системных администраторов и руководителей ИТ-компаний

УДК 004.738.5
ББК 32.973.26-018.2
Группа подготовки издания:
Руководитель проекта
Зав. редакцией
Перевод с английского
Редактор
Компьютерная верстка
Оформление обложки

Олег Сивченко
Людмила Гауль
Михаила Райтмана
Зоя Корниенко
Натальи Смирновой
Зои Канторович

© 2023 BHV
Authorized translation of the English edition © 2022 Manning Publications. This translation is published and sold
by permission of Manning Publications, the owner of all rights to publish and sell the same.
Авторизованный перевод с английского языка на русский издания © 2022 Manning Publications. Перевод
опубликован и продается с разрешения компании-правообладателя Manning Publications. Все права защищены.

"БХВ-Петербург", 191036, Санкт-Петербург, Гончарная ул., 20.

ISBN 978-1-61729-899-8 (англ.)
ISBN 978-5-9775-1888-8 (рус.)

© Manning Publications, 2022
© Перевод на русский язык, оформление.
ООО "БХВ-Петербург", ООО "БХВ", 2023

Оглавление

Вступительное слово........................................................................................................... 13
Предисловие ......................................................................................................................... 17
Благодарности...................................................................................................................... 19
О книге .................................................................................................................................. 20
Кому следует прочитать эту книгу ...................................................................................... 20
Структура книги .................................................................................................................... 20
О коде ..................................................................................................................................... 22
Об авторе............................................................................................................................... 23

Об иллюстрации на обложке .......................................................................................... 24
ЧАСТЬ I. КОНФИДЕНЦИАЛЬНОСТЬ, ДАННЫЕ И ВАШ БИЗНЕС........................................... 25
Глава 1. Инженерия конфиденциальности: зачем нужна
и как ее масштабировать ................................................................................................... 27
1.1. Что такое конфиденциальность..................................................................................... 28
1.2. Как данные поступают в компанию и перемещаются внутри нее............................. 32
1.3. Почему конфиденциальность имеет значение............................................................. 34
1.3.1. Штрафы реальны.................................................................................................. 34
1.3.2. Погоня за эффективностью в начале пути может вызвать проблемы
конфиденциальности в будущем.................................................................................. 36
Gamesbuster: анализ конкретного примера ......................................................... 36
1.3.3. Расследования нарушений конфиденциальности — не просто преграда
на пути к успеху ............................................................................................................. 39
Еврокомиссия оштрафовала компанию WhatsApp на 110 млн евро
за искажение данных ........................................................................................... 40
Антимонопольный регулятор Италии оштрафовал WhatsApp
на 3 млн евро ........................................................................................................ 41
Пять органов ЕС по надзору за соблюдением законодательства
по защите данных подают иски к корпорации Facebook
за изменения политики в 2014-м и другие действия с данными ..................... 42
1.3.4. Защита конфиденциальности как возможность для бизнеса:
реальный пример............................................................................................................ 44
1.4. Конфиденциальность: ментальная модель................................................................... 46

6

Оглавление

1.5. Как конфиденциальность влияет на бизнес на макроуровне ..................................... 49
1.5.1. Конфиденциальность и безопасность: период ковида ..................................... 49
1.5.2. Конфиденциальность и правила: циклический процесс .................................. 51
1.6. Инструменты и техники защиты конфиденциальности: возможности
и варианты.............................................................................................................................. 53
1.6.1. Дилемма: разрабатывать или покупать.............................................................. 54
1.6.2. Инструменты защиты конфиденциальности от сторонних
разработчиков: они действительно работают и масштабируются?........................... 56
Платформенные решения для обеспечения конфиденциальности:
BigID и OneTrust .................................................................................................. 56
Специализированные решения для защиты конфиденциальности:
Privicera, Collibra, DataGrail, Informatica, SailPoint ........................................... 59
1.6.3. Риски при покупке сторонних инструментов защиты
конфиденциальности ..................................................................................................... 60
1.7. В чем эта книга не поможет .......................................................................................... 61
1.8. Как изменение роли инженеров повлияло на защиту конфиденциальности............ 61
Резюме............................................................................................................................. 64
Глава 2. Представление о данных и конфиденциальности ......................................... 65
2.1. Что следует из понятия конфиденциальности ............................................................. 65
2.1.1. Почему обеспечить конфиденциальность трудно ............................................ 66
2.1.2. Инженерия конфиденциальности на местах: чего необходимо добиться ...... 67
2.1.3. Конфиденциальность, системы данных и соблюдение политики ................... 70
2.2. Это могла бы быть ваша компания............................................................................... 72
2.3. Данные, стратегия развития бизнеса и конфиденциальность .................................... 76
2.4. Примеры нарушения конфиденциальности данных ................................................... 78
2.4.1. Equifax................................................................................................................... 78
2.4.2. Нарушение в работе Службы управления персоналом .................................... 80
2.4.3. Компании LabCorp и Quest Diagnostics.............................................................. 82
2.5. Конфиденциальность и нормативно-правовая база .................................................... 83
2.5.1. Как нормативные акты влияют на ваш продукт и его пользователей ............ 83
2.5.2. Как ваша программа должна помочь подготовиться к изменению
законодательства о защите конфиденциальности данных......................................... 85
2.6. Конфиденциальность и пользователь........................................................................... 86
2.6.1. Превращение в полноправного американца и конфиденциальность.............. 86
2.6.2. Опасения современных пользователей по поводу конфиденциальности....... 87
2.7. После создания инструментов наступает самое сложное: разработка
программы.............................................................................................................................. 88
2.8. Разрабатывая программу, сначала сформируйте корпоративную культуру,
ориентированную на конфиденциальность данных........................................................... 92
Резюме............................................................................................................................. 95
ЧАСТЬ II. УПРЕЖДАЮЩАЯ ПРОГРАММА ЗАЩИТЫ КОНФИДЕНЦИАЛЬНОСТИ:
УПРАВЛЕНИЕ ДАННЫМИ ....................................................................................................... 97
Глава 3. Классификация данных ..................................................................................... 99
3.1. Классификация данных в контексте клиента............................................................. 100

Оглавление

7

3.2. Зачем нужна классификация данных.......................................................................... 101
3.2.1. Классификация как часть управления данными ............................................. 102
3.2.2. Классификация данных: как она помогает выстраивать приоритеты........... 103
Как определяются приоритеты защиты данных ............................................. 103
Сегментация данных ......................................................................................... 106
Упражнение по защите данных: линза определения приоритетов ............... 108
3.2.3. Сопоставление примеров по классификации данных в отрасли
технологий .................................................................................................................... 110
3.2.4. Неструктурированные данные и управление .................................................. 111
3.2.5. Классификация данных как этап на пути к зрелости...................................... 112
Что такое зрелость организации....................................................................... 113
Классификация данных и зрелость организации............................................ 114
3.3. Как применить классификацию данных для повышения
конфиденциальности........................................................................................................... 116
3.3.1. Классификация данных и варианты доступа к ним........................................ 116
3.3.2. Классификация данных, управление доступом и конфиденциальность:
пример 1........................................................................................................................ 118
3.3.3. Классификация данных, управление доступом и конфиденциальность:
пример 2........................................................................................................................ 120
3.4. Классификация данных согласно законам о конфиденциальности......................... 121
3.4.1. Классификация данных как выделение главного в законах
о конфиденциальности ................................................................................................ 121
3.4.2. Классификация данных для разрешения противоречий
в интерпретациях законов о конфиденциальности................................................... 122
3.5. Процесс классификации данных................................................................................. 124
3.5.1. Работа над классификацией данных с участниками из разных отделов....... 124
3.5.2. Оформление и переработка классификации данных ...................................... 127
3.5.3. Процесс классификации данных: шаблон Microsoft....................................... 128
3.6. Классификация данных: пример ................................................................................. 129
Резюме .................................................................................................................................. 133
Глава 4. Учет данных ....................................................................................................... 134
4.1. Учет данных: что это такое и зачем это нужно ......................................................... 135
4.2. Машиночитаемые метки .............................................................................................. 138
4.2.1. Что такое метки для учета данных ................................................................... 138
4.2.2. Метки для учета данных: конкретный пример................................................ 139
4.3. Разработка базовой версии .......................................................................................... 143
4.4. Техническая архитектура............................................................................................. 145
4.4.1. Структурированные и неструктурированные данные .................................... 145
4.4.2. Архитектурные возможности учета данных ................................................... 148
4.4.3. Рабочий процесс учета данных......................................................................... 150
4.5. Представление о данных.............................................................................................. 153
4.5.1. Процесс определения метаданных ................................................................... 154
4.5.2. Процесс обнаружения метаданных .................................................................. 156
4.6. Когда следует приступать к учету данных................................................................. 157
4.6.1. Почему процесс учета данных так сложен? .................................................... 157
4.6.2. Учет данных: лучше раньше, чем позже.......................................................... 158

8

Оглавление

4.7. Учет данных — небинарный процесс......................................................................... 161
4.7.1. Первый уровень учета данных.......................................................................... 161
4.7.2. Второй уровень учета данных .......................................................................... 163
4.7.3. Третий уровень учета данных........................................................................... 164
Поддержка функций загрузки личных данных и запросы субъекта
на доступ к персональным данным.................................................................. 165
Поддержка функции удаления данных............................................................ 165
Получение информации о бизнесе ................................................................... 166
4.8. Как выглядит успешный процесс учета данных........................................................ 167
4.8.1. Объективные показатели успешности учета данных ..................................... 167
4.8.2. Субъективные показатели успешности учета данных.................................... 168
Резюме .................................................................................................................................. 169
Глава 5. Совместное использование данных ............................................................... 171
5.1. Совместное использование данных: зачем компаниям ими делиться..................... 172
5.1.1. Совместное использование данных: службы такси ........................................ 173
5.1.2. Совместное использование данных: интернет-реклама ................................. 174
5.1.3. Конфиденциальность в рекламе ....................................................................... 178
5.2. Как безопасно обмениваться данными: безопасность — союзник
конфиденциальности........................................................................................................... 180
5.2.1. Отслеживание президента Трампа ................................................................... 180
5.2.2. Защита передаваемых данных .......................................................................... 182
5.2.3. Защита данных в состоянии покоя ................................................................... 183
Контроль доступа как инструмент защиты конфиденциальности................ 184
Шифрование как инструмент защиты конфиденциальности ........................ 185
5.3. Методы обфускации для безопасного обмена данными........................................... 187
5.3.1. Обмен данными и национальная безопасность США .................................... 188
5.3.2. Анонимизация данных: связь между точностью и сроком хранения ........... 189
5.3.3. Анонимизация данных: взаимосвязь между точностью и доступом ............ 191
5.3.4. Анонимизация данных: сопоставление универсальных
идентификаторов с внутренними ............................................................................... 194
5.4. Передача внутренних идентификаторов третьим лицам .......................................... 196
5.4.1. Сценарий использования № 1: минимальная сессия
(без связи видов деятельности пользователя) ........................................................... 197
Предлагаемые методы псевдонимизации ......................................................... 198
5.4.2. Сценарий использования № 2: одна сессия на каждый набор данных
(связывание действий одного пользователя в рамках набора данных) .................. 198
Предлагаемые методы псевдонимизации ......................................................... 198
5.4.3. Сценарий использования № 3: наборы данных, охватывающие
всю сессию (связывание между наборами данных).................................................. 199
Предлагаемые методы псевдонимизации ......................................................... 199
5.4.4. Восстановление псевдонимизированных значений........................................ 200
Таблица сопоставления ..................................................................................... 200
Двусторонняя криптографическая функция ................................................... 200
5.5. Измерение воздействия на конфиденциальность ...................................................... 201
5.5.1. K-анонимность ................................................................................................... 201
K-анонимность с неточными данными ............................................................ 202

Оглавление

9

K-анонимность с точными данными................................................................ 203
K-анонимность и лучшая практика в отрасли................................................. 204
5.5.2. L-разнообразие ................................................................................................... 205
5.6. Ущерб конфиденциальности: это не учения.............................................................. 206
5.6.1. Facebook и Cambridge Analytica........................................................................ 207
5.6.2. Совместное использование данных и слабые места ....................................... 208
Резюме .................................................................................................................................. 209
ЧАСТЬ III. ИНСТРУМЕНТЫ И ПРОЦЕССЫ ......................................................................... 211
Глава 6. Техническая проверка защиты конфиденциальности............................... 213
6.1. Что такое проверка защиты конфиденциальности.................................................... 214
6.1.1. Оценка воздействия на конфиденциальность ................................................. 216
6.1.2. Оценка воздействия на защиту данных ........................................................... 217
Определите необходимость оценки воздействия на защиту данных............ 219
Опишите процесс обработки данных............................................................... 220
Опишите отношения с пользователем ............................................................. 221
Консультация ..................................................................................................... 222
Проведите оценку риска.................................................................................... 222
Определите меры по смягчению риска............................................................ 223
6.2. Внедрение процесса юридической проверки защиты конфиденциальности.......... 223
6.3. Обоснование необходимости технической проверки защиты
конфиденциальности........................................................................................................... 226
6.3.1. Сроки и объем .................................................................................................... 226
6.3.2. Что входит в техническую проверку, но не входит в юридическую ............ 228
6.4. Интеграция технических проверок защиты конфиденциальности в процесс
внедрения инноваций.......................................................................................................... 231
6.4.1. Когда проводится техническая проверка защиты конфиденциальности...... 232
6.4.2. Как реализовать техническую защиту конфиденциальности ........................ 234
6.5. Масштабирование процесса технической проверки защиты
конфиденциальности........................................................................................................... 240
6.5.1. Совместное использование данных.................................................................. 240
6.5.2. Модели машинного обучения........................................................................... 241
Машинное обучение и данные ......................................................................... 241
Машинное обучение, данные и конфиденциальность ................................... 243
6.6. Примеры технических проверок защиты конфиденциальности .............................. 244
6.6.1. Приложения-мессенджеры и приложения для взаимодействия:
связаны ли они?............................................................................................................ 244
6.6.2. Маски и отслеживание контактов .................................................................... 247
Резюме .................................................................................................................................. 249
Глава 7. Удаление данных ............................................................................................... 250
7.1. Почему компания должна удалять данные ................................................................ 251
7.2. Как выглядит современная архитектура сбора данных ............................................ 253
7.2.1. Распределенная архитектура и микросервисы: как компании
собирают данные.......................................................................................................... 253

10

Оглавление

7.2.2. Как хранятся получаемые в реальном времени данные
и как организуется к ним доступ ................................................................................ 255
7.2.3. Хранение архивных данных.............................................................................. 255
7.2.4. Другие места хранения данных ........................................................................ 257
7.2.5. Как хранилище данных превращается из коллекции в архив........................ 258
7.3. Как работает архитектура сбора данных.................................................................... 260
7.4. Удаление данных на уровне учетной записи: отправная точка ............................... 262
7.4.1. Удаление учетной записи: разработка инструментария и процесса ............. 262
7.4.2. Масштабирование удаления учетной записи .................................................. 263
7.5. Удаление данных на уровне учетной записи: автоматизация
и масштабирование для распределенных услуг ............................................................... 265
7.5.1. Регистрация сервисов и полей данных для удаления ..................................... 267
7.5.2. Планирование удаления данных....................................................................... 269
7.6. Удаление конфиденциальных данных........................................................................ 270
7.7. Кто должен управлять удалением данных ................................................................. 274
Резюме .................................................................................................................................. 276
Глава 8. Экспорт пользовательских данных:
запрос субъекта на доступ к персональным данным ................................................. 277
8.1. Что такое DSAR............................................................................................................ 278
8.1.1. Какие права предоставляют пользователям нормативные положения
о DSAR.......................................................................................................................... 281
8.1.2. Обзор процесса выполнения DSAR ................................................................. 283
8.2. Настройка процесса работы с DSAR .......................................................................... 285
8.2.1. Ключевые этапы создания системы выполнения DSAR ................................ 286
8.2.2. Создание панели мониторинга состояния DSAR............................................ 288
8.3. Автоматизация DSAR, структуры и потоки данных................................................. 290
8.3.1. Компоненты DSAR ............................................................................................ 290
8.3.2. Модели в форме параллелепипеда: подмножество данных
запроса DSAR............................................................................................................... 292
8.3.3. Шаблоны DSAR ................................................................................................. 295
8.3.4. Источники данных для шаблонов DSAR......................................................... 297
8.4. Интерфейсы и информационные панели для сотрудников ...................................... 299
Резюме .................................................................................................................................. 307
ЧАСТЬ IV. БЕЗОПАСНОСТЬ, МАСШТАБИРОВАНИЕ И КАДРОВОЕ ОБЕСПЕЧЕНИЕ.......... 311
Глава 9. Разработка платформы управления согласием........................................... 311
9.1. В чем важность управления согласием ...................................................................... 312
9.1.1. Управление согласием и нормативные документы в области защиты
конфиденциальности........................................................................................................... 313
9.1.2. Управление согласием и изменения в технологической отрасли.................. 315
9.1.3. Управление согласием и ваш бизнес................................................................ 317
9.2. Платформа управления согласием.............................................................................. 318
9.3. Модель схемы данных для управления согласием.................................................... 320
9.3.1. Отношения элементов, помогающие структурировать CMP......................... 321

Оглавление

11

9.3.2. Схемы отношений элементов: база данных CMP ........................................... 322
Таблица Feature .................................................................................................. 323
Таблица Disclosure_Version .............................................................................. 325
Таблица «Согласие пользователя»................................................................... 326
Таблица Locale_Copy......................................................................................... 328
Таблица LocaleTerritory..................................................................................... 329
9.4. Код согласия: объекты ................................................................................................. 330
9.4.1. API для проверки статуса согласия .................................................................. 331
9.4.2. API для получения документа о разглашении данных................................... 333
9.4.3. API для обновления статуса согласия на документ о разглашении
данных........................................................................................................................... 336
9.4.4. API для обработки нескольких документов о разглашении данных............. 339
9.4.5. API для регистрации в сервисе получения согласия ...................................... 342
9.4.6. Полезные определения для сервиса получения согласия............................... 343
9.5. Другие полезные возможности CMP .......................................................................... 345
9.6. Интеграция управления согласием в рабочий процесс продукта ............................ 347
Резюме .................................................................................................................................. 351
Глава 10. Закрытие уязвимостей системы безопасности........................................... 352
10.1. Защита конфиденциальности путем уменьшения поверхности атаки .................. 354
10.1.1. Управление поверхностью атаки.................................................................... 354
10.1.2. Как тестирование может вызвать риски нарушения безопасности
и конфиденциальности ................................................................................................ 356
Использование производственных данных в тестировании ........................ 356
Гибкое тестирование, но с расширенной поверхностью атаки.................... 358
Потенциальные способы смягчения последствий изучены
и отвергнуты ..................................................................................................... 358
Выводы для инженеров и технических специалистов.................................. 359
10.1.3. Модель риска предприятия для обеспечения безопасности и
конфиденциальности ................................................................................................... 360
Автоматизированное обнаружение для управления поверхностью
атаки .................................................................................................................. 360
Внедрение управления рисками безопасности.............................................. 362
Сегментация сервисов ..................................................................................... 364
Глубокая защита............................................................................................... 365
Обеспечение поддержки.................................................................................. 366
10.2. Защита конфиденциальности путем управления доступом к периметру.............. 367
10.2.1. Взлом компании Target.................................................................................... 368
Разведка с целью обнаружения сетевых уязвимостей .................................. 370
Получение несанкционированного доступа к стороннему
поставщику ....................................................................................................... 370
Использование уязвимости веб-приложения ................................................ 371
Поиск данных о клиентах................................................................................ 372
Получение и поддержание доступа к данным клиентов .............................. 372
Расширение доступа к данным клиента......................................................... 373
Кража личных данных клиентов и данных кредитных карт ........................ 373
Отправка украденных данных за пределы сети компании........................... 374
10.2.2. Слабые места безопасности системы MongoDB ........................................... 376

12

Оглавление

10.2.3. Лучшие практики в сфере авторизации ......................................................... 379
Принудительное разделение политики авторизации и кода ........................ 379
Как сделать авторизацию безопасной, ориентированной на сервисы
и легко интегрируемой .................................................................................... 380
Проверка надежности каналов передачи данных и подтверждение
подлинности личности..................................................................................... 384
10.2.4. Почему важен непрерывный мониторинг учетных записей
и учетных данных ........................................................................................................ 387
10.2.5. Удаленная работа и риск для конфиденциальности ..................................... 389
10.3. Защита конфиденциальности путем устранения пробелов в управлении
доступом............................................................................................................................... 391
10.3.1. Как работает уязвимость IDOR ...................................................................... 392
10.3.2. Тестирование на уязвимость IDOR и смягчение последствий .................... 394
Резюме .................................................................................................................................. 396
Глава 11. Масштабирование, найм и рассмотрение правил..................................... 397
11.1. Модель зрелости для инженерии конфиденциальности ......................................... 399
11.1.1. Идентификация ................................................................................................ 401
Управление активами ...................................................................................... 402
Управление конфиденциальностью ............................................................... 403
Управление рисками ........................................................................................ 404
11.1.2. Защита ............................................................................................................... 406
Управление идентификацией и доступом...................................................... 406
Управление уязвимостями .............................................................................. 408
Безопасность и конфиденциальность разработки программного
обеспечения ...................................................................................................... 409
Защита данных в облаке .................................................................................. 411
Защита данных на основе инфраструктуры................................................... 412
11.1.3. Обнаружение .................................................................................................... 415
Разведка угроз безопасности........................................................................... 415
Непрерывный мониторинг .............................................................................. 416
Инсайдерская угроза ........................................................................................ 417
11.1.4. Смягчение последствий................................................................................... 419
Управление реагированием на инциденты .................................................... 419
11.2. Область инженерии конфиденциальности: необходимые навыки ........................ 420
Разработчики программного обеспечения для защиты
конфиденциальности ....................................................................................... 421
Специалисты по соблюдению нормативно-правовых требований ............. 421
Аналитики по вопросам конфиденциальности ............................................. 422
Менеджеры по продуктам для защиты конфиденциальности ..................... 422
Аналитики данных ........................................................................................... 422
Специалисты по инфраструктуре конфиденциальности.............................. 423
UX-дизайнеры в области защиты конфиденциальности .............................. 423
Архитекторы конфиденциальности................................................................ 423
11.3. Защита конфиденциальности и нормативно-правовой климат.............................. 424
Резюме .................................................................................................................................. 428
Предметный указатель..................................................................................................... 429

Вступительное слово

Я познакомился с Нишантом, когда возглавлял команду разработчиков продукта и
инженеров в компании Netflix, где работал с момента ее появления. В команде было около 500 человек, и нам с самого начала приходилось решать проблемы безопасности. Но мы не уделяли достаточно внимания защите конфиденциальности,
пока не столкнулись с неожиданным результатом проведения премии Netflix Prize,
а затем почти сразу — с выходом Общего положения о защите данных (англ.:
GDPR — General Data Protection Regulation) и Закона штата Калифорния о защите
персональных данных потребителей (англ.: CCPA — California Consumer Privacy
Act). Мы одновременно создавали команду, разрабатывали философию и итоговый
продукт, а Нишант был у нас ключевой фигурой — человеком, разбирающимся и в
инженерии, и в защите конфиденциальности. Он понимал практические аспекты и
потребности бизнеса, границы возможностей технических специалистов, обязательства, которые мы брали (и должны были взять) на себя перед клиентами, и то,
как их выполнить.
Для премии Netflix Prize в 2006–2009 годах мы хотели опубликовать большой набор данных, включающий в себя 100 миллионов оценок от 500 тысяч пользователей (например, пользователь N оценил фильм T на 4 звезды), и предложить приз в
1 миллион долларов команде, которая сумеет создать лучший механизм предсказания для прогнозирования оценок в тестовом наборе, не известном их конкурентам.
Очевидно, что набор данных нужно было сделать обезличенным.
Джеймс Беннетт, который руководил составлением конкурсных заданий, вдобавок
применил сложный подход рандомизации процента оценок, чтобы их нельзя было
сопоставить с другими открытыми источниками. Однако Арвинд Нараянан и Виталий Шматиков из Техасского университета в Остине написали работу, где показали, что статистические методы повторной идентификации позволяют сопоставить
оценки с интернет-базой кинофильмов и раскрыть личности отдельных пользователей, — возможность, о которой мы не задумывались. Это стало для меня тревожным сигналом.
Примерно в это же время в других компаниях произошла серия утечек данных,
раскрывающих личную информацию, в том числе имена, адреса, номера социального страхования, кредитных карт и т. д. Было бы легко списать это на проблемы с
безопасностью, но нередко утечки возникали не вследствие взлома системы защиты, а в результате действий инсайдера или случайно. Выясняя, как избежать взлома, мы все яснее начали осознавать: несмотря на необходимость строгих мер безопасности, нужно также разрабатывать собственные ИТ-системы, позволяющие ог-

14

Вступительное слово

раничивать и разделять персональные данные. Это позволило бы снизить вероятность случайностей, уменьшить шансы инсайдеров допустить утечку и повысить
их мотивацию ее избежать. А хакерам пришлось бы всерьез потрудиться, чтобы
собрать все фрагменты данных.
Затем появился GDPR, ставший предвестником множества новых нормативных
актов в области конфиденциальности, которые все еще разрабатывались в
2021 году, когда я писал эти строки. GDPR (а затем и CCPA) добавили новый
фактор — право пользователей знать, какие данные были собраны, иметь возможность видеть эти данные, исправлять их, если они неверны, и удалять по своему желанию. Это лишь подчеркнуло необходимость разработки систем с учетом
защиты конфиденциальности.
Для Netflix это означало разделение идентифицирующей пользователя информации
по хранилищам данных с расставленными токенами, обеспечение того, чтобы все
ссылки были косвенными, а также добавление политик, средств контроля и аудита
в процесс получения доступа к хранилищам. Достичь этой цели в системе, работающей в большом масштабе, без ущерба для ее производительности было очень
непросто, и в решении этой задачи Нишант сыграл важнейшую роль. Я жалею, что
мы не запланировали меры в этой области с самого начала, и что нам пришлось
действовать по факту, поэтому я стал задумываться о принципах проектирования
защиты конфиденциальности и обсуждать их с командой.
В этой книге данные размышления получили еще более глубокое развитие. Она
написана для профессионалов из высокотехнологических компаний, которые сталкиваются с теми же проблемами, что и мы тогда, но в еще более жесткой требовательной среде, где выше значение конфиденциальности для людей, а, значит, и для
регулирующих органов, где хранится все больше данных и постоянно происходит
все больше нарушений и утечек. Где технологические платформы становятся все
менее монолитными, а все чаще состоят из нескольких партнерских организаций и
сервисов, где общество все хуже относится к технологическим компаниям потому,
что те используют персональные данные и часто злоупотребляют ими.
Ваш цифровой след может оказаться невероятно ценным и окупить для компании
услуги и продукты, предлагаемые бесплатно (или увеличить доход от продаваемых
продуктов). Наличие бесплатных товаров (или снижение их стоимости) всегда было привлекательной моделью для потребителей, но сейчас люди становятся более
грамотными и требовательными к тому, как следует использовать их персональные
данные. Компании же ведут себя все агрессивнее, стремясь извлечь максимальную
выгоду из этих данных, чтобы окупались более дорогие и интересные продукты.
Однако персональная информация, касающаяся вашего поведения, все чаще используется в сервисах или системах, без которых не обойтись: от инфраструктуры
государственных служб, здравоохранения, банков, транспортных сервисов до инфраструктуры сторонних организаций вроде рейтинговых агентств. Эти системы,
поскольку регистрация в них обязательна, несут еще большую ответственность за
безопасное использование персональной информации клиентов, ведь клиенты не

Вступительное слово

15

могут «проголосовать ногами» и не обращаться в компании, злоупотребившие вашим доверием.
В связи с этим компании должны четко представлять, что они будут делать с данными, понятно и открыто сообщать об этом пользователям, и работать с данными
безопасным способом, что позволит частично восстановить утраченное доверие.
Выполнение этих требований начинается с людей, с привития им чувствительности
к конфиденциальности — мышления, при котором защита конфиденциальности
становится главной темой во всей организации.
Затем необходимо продумать проекты продуктов и услуг, решить, какие из них
нужны, на какой срок и что с ними делать потом, а также суметь четко донести эту
информацию до пользователей.
А далее потребуется разработать и внедрить технологии, которые позволят выполнить данные обещания и соблюдать правила так, чтобы они не мешали организации, не снижали ее производительность, гибкость и способность приносить прибыль. Проект должен предвосхищать как будущие потребности в защите конфиденциальности, которые возникнут в связи с эволюцией ожиданий общества, так и
будущие нормы этой защиты, которые неизбежно будут возникать по мере роста
озабоченности общества.
Эта книга позволит вам лучше понять, что такое конфиденциальность и почему она
важна. Примеры нарушений безопасности данных и утечек информации на ее
страницах заставят задуматься: какие шаги по снижению риска можно было бы
предпринять, если бы речь шла о вашей организации?
Нишант описывает методики классификации и обсуждения данных, обладающих
различной степенью чувствительности к конфиденциальности, рассказывает, куда
передаются данные и для чего они используются, а также побуждает вас задаться
вопросами: «Необходимо ли это для моей цели? Хотел бы я этого на месте клиента? Этично ли это? Соответствует ли это нашей политике и нормативным требованиям?» Затем он рассматривает возможность обмена данными с другими подразделениями организации, а также (что обретает все большее значение) — с партнерами, поставщиками и продавцами. Он объясняет, какие вопросы следует задать
другим организациям, прежде чем доверить им данные своих пользователей.
Значительная часть книги посвящена техническим решениям, облегчающим сохранение личной информации в тайне. К таким методам относятся шифрование, хэширование, токенизация и варианты разделения данных для защиты личной информации. Еще один аспект — избегание небезопасных способов неформального сбора
персональных данных, таких как протоколирование или потоки отладки. Для этого
требуется инструментарий, позволяющий собирать полезные данные без персональных, а также обучающие программы, гарантирующие, что технические специалисты будут осторожнее.
Конфиденциальность во многом зависит от того, какие данные собираются. Поэтому важной частью проектирования ее защиты является обоснованность сбора и
хранения данных. Важно гарантировать, что данные не будут собираться без необ-

16

Вступительное слово

ходимости и будут удалены, как только необходимость в них исчезнет. Не менее
важно определить, что подразумевается под необходимостью. Может оказаться,
что какие-то данные понадобятся в будущем, и вы пожалеете, что не собрали их,
когда могли. Или же какие-то данные казались нужными в прошлом, но не принесли особой пользы и, возможно, были не нужны изначально.
Новые законы о защите конфиденциальности дают пользователю право знать, какие данные он предоставляет, просматривать их, исправлять и удалять. Это может
вскоре стать для компании невыполнимым, если только сразу не организовать сбор
данных так, чтобы можно было находить всю информацию о человеке и выборочно
удалять отдельные записи, не оставляя несоответствий в данных (например, записей в контрольных журналах для транзакций, указывающих на удаленные данные
клиентов).
Конфиденциальность неразрывно связана с безопасностью. Без надежной идентификации/аутентификации и (достаточно мелкомодульной) авторизации становится
невозможно сохранить контроль над персональными данными или доступом к ним.
А отсутствие контроля доступа облегчает злоумышленникам задачу.
Книга завершается размышлениями о масштабировании — то есть о соответствии
ресурсов и команды, отвечающей за конфиденциальность, размеру и целям организации. Легко недооценить объем работы и не достичь поставленных целей. Так же
легко переоценить усилия, потратить ресурсы впустую, замедлить работу и лишить
организацию прибыли, которую она стремится получить.
Правильно рассчитать усилия — сложная задача!
Хотелось бы мне иметь этот текст под рукой в 2015 или 2016 году в Netflix, когда
мы начали работать над соблюдением нормативно-правовых требований, содержащихся в GDPR. Он был бы полезен в 2008–2012 годах, в период значительной архитектурной эволюции наших технологий. С ним некоторые идеи было бы реализовать гораздо проще. Он бы мне пригодился и в 2006-м, когда мы думали о премии Netflix Prize, или даже раньше, в конце 1990-х, когда закладывались основы
компании Netflix. Книга полезна мне и сейчас, в работе над созданием ИИ в области здравоохранения. Возможности медицины, основанной на больших данных, огромны, но пристальное внимание к ней регуляторов и общества особенно заметно,
хотя и кажется запоздалым и не совсем понятным в современную эпоху конфиденциальности в технологиях.
Я часто сталкиваюсь с командами, которые игнорируют вопросы конфиденциальности или пренебрегают этим, откладывая на потом. Пожалуй, эта книга станет одновременно и хорошей прививкой от такого типа мышления, и замечательным
учебником, рассказывающим, как добиться прогресса там, где нужно действовать
сбалансированно, экономически эффективно и при этом способствовать росту прибыли.
Приятного чтения!
Нил Хант
Директор отдела контроля производства компании Netflix, 1999–2017

Предисловие

«Есть общеизвестные вещи.
Это вещи, о которых мы знаем, что нам они известны.
Есть известные неизвестные.
То есть вещи, о которых мы знаем, что они нам не известны.
Но есть и неизвестные неизвестные — вещи,
о которых мы не догадываемся, что они нам не известны».
Дональд Рамсфелд, бывший министр обороны США

Приведенная выше цитата Дональда Рамсфелда часто приходила мне на ум в первые годы работы инженером по безопасности и защите конфиденциальности. На
первый взгляд тривиальные проблемы — определение местонахождения данных,
проверка одобрения пользователем и удаление данных — часто оказывались невообразимо более сложными, чем должны были. Навыки сбора и передачи данных,
верно служившие мне на предыдущей работе в должности инженера, а потом и менеджера по продукту, обернулись против меня, когда я стал руководителем по защите конфиденциальности.
Я помню, как искал информацию в Интернете и ничего не нашел. Больше всего меня расстраивали моменты, когда тех из нас, кто работал над защитой конфиденциальности, компании воспринимали как помеху. Из-за несоблюдения инженерами
гигиены данных мне было трудно дать четкие и объективные ответы адвокатам,
представлявшим нас в суде.
С началом процесса регулирования и контроля защиты конфиденциальности в
компаниях, использующих данные клиентов, наметились улучшения. И все же существующие законы в этой области слишком фрагментарны и чересчур запутаны.
Неудивительно, что от этой двусмысленности страдают предприятия, не обладающие теми ресурсами, которые есть у более крупных компаний. Взаимоотношения
компаний с регуляторами здесь варьируются от недоверия до отвращения, а страдают от этого потребители.
Мой любимый пример со времен работы в компании Netflix: Закон о защите конфиденциальности пользователей видеоматериалов (англ.: VPPA — Video Privacy
Protection Act) был принят Конгрессом США в 1988 году. Он стал результатом вызвавшего споры назначения в Верховный Суд судьи Роберта Борка. Судья Борк
заявил, что «Американцы пользуются только такими средствами защиты персональных данных, теми защитами частной жизни, которые предоставлены законодательством». В ответ на это Майкл Долан, внештатный писатель газеты Washington

18

Предисловие

City Paper, уговорил продавца из видеомагазина предоставить ему перечень всех
фильмов, которые Борк брал напрокат.
VPPA, позволяющий регулировать использование данных об истории просмотра
видеофильмов пользователями, Конгресс принял за десятилетия до появления
Netflix и Amazon Prime. Однако положения VPPA распространяются и на эти платформы. Последующие законы о защите конфиденциальности также не лишены
изъянов, поскольку они часто не учитывают сложность разработки технических
решений для обеспечения конфиденциальности.
Кроме того, группы инженеров все чаще работают изолированно над конкретными
процессами. Это еще сильнее затрудняет осуществление контроля конфиденциальности таким образом, чтобы он был масштабируемым и измеримым. Слишком долго компании и правительства получали данные с избытком и недостаточно сдерживали свои аппетиты.
В 2019-м я решил помочь техническим специалистам и руководителям, пытающимся решить проблемы, схожие с теми, над которыми я бился годами. Я начал
вести курсы на платформе LinkedIn Learning, их хорошо приняли. Вскоре оказалось, что мои знания и опыт нужны основателям стартапов, зрелым компаниям,
инвесторам и представителям сферы кибербезопасности в целом. Я понял, что мой
уникальный набор навыков из области инженерии, защиты данных и политики
нормативно-правового регулирования позволяет запускать масштабные и эффективные программы по защите конфиденциальности. Если бы можно было собрать
все мои знания, победы и ошибки в виде справочника для компаний, они могли бы
начать внедрять конфиденциальность в свои продукты с самого начала, а не добавлять в конце.
Рынку и правительству нужна система, которая сочетала бы в себе деловой и политический контекст с практическими техническими навыками. Я решил написать
книгу, чтобы предложить именно такую систему.
В течение года, когда данные распространялись по всему миру, а большинство из
нас, тем временем, были заперты дома, я писал эту книгу, чтобы увеличить число
«известных известных» и сократить количество «известных неизвестных» и «неизвестных неизвестных».

Благодарности

Эту книгу не удалось бы написать без растущего сообщества кибербезопасности,
ключевым фактором которого является защита конфиденциальности и данных.
Инженеры, постоянно стремящиеся защитить данные клиентов, стали для меня
вдохновляющей целевой аудиторией и моей путеводной звездой. Экспертов в данной области, предложивших свои решения и комментарии, слишком много, чтобы
перечислить всех, но это не умаляет их вклада.
Я выражаю сердечную благодарность Майклу Дженсену за техническую экспертизу, благодаря которой книга оказалась нацелена на помощь своей основной аудитории — инженерам.
Также от души благодарю наставников и экспертов, которые помогли моему профессиональному росту и чей вклад обогатил эту книгу: Энтони Дюпре, Ларри Дребеса, Анн Брэдли, Джейсона Чана, Бенджамина Малли, Патрика Мюллера, Нила
Ханта, Нареш Гопалани, Рассела Льюиса, Чарльза Смита, Викрама Кхаре, Виная
Гоэл, Джона «Четверку» Флинна, Юн Цяо, Руби Зефо, Дерека Кэра, Уттару Сиварам, Мишель Деннеди, Мелани Энсин, Саймона Ханию, Мохаммада Ислама, Кэтрин Нельсон, Питера Дикмана, Ким Люси, Брайана Каспера, Бена Файнштейна,
Энджина Боздага, Кельвина Сето, Мэтта Ольсена, Аяну Миллер, Ахмеда Ибрагима,
Авни Верму, Латху Марипури, Николаса Лидзборски, Чжэнцюнь Луо и других.
Благодарю всех рецензентов: Бенджамина Ламперта, Брайана Личеагу, Деса Хорсли, Диего Каселлу, Дониора Ульмасова, Флорис Бушо, Ховарда Уолла, ЖанаФрансуа Бошефа, Йенса Гирардина, Джо Иванса, Джона Тайлера, Йона Риддла,
Джонатана Бурбонну, Марка Рулло, Марсина Сека, Мэтью Тодда, Майтхама Фахми, Майкла Лэнгдона, Надю Нури, Усаму Хана, Пола Лава, Питера Уайта, Пьетро
Альберто Росси, Тима Вулдриджа и Виллема ван Кетвича. Ваши предложения помогли сделать книгу лучше.

О книге

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

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

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

О книге

21

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

проходящих через технологический стек и хранилище, и как компания может
разработать соответствующие программные средства управления;
 в главе 2 объясняется, каким образом данные могут стать причиной риска нару-

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

партнерами с позиций риска нарушения конфиденциальности;
 глава 4 подробно рассматривает учет данных, подразумевающий категоризацию
данных с использованием сочетания приемов классификации, выполняемых
вручную и с помощью компьютера;
 в главе 5 описываются методы анонимизации наборов данных и измерения степени их влияния на конфиденциальность, а также в качестве примера приводится обмен данными.
Часть 3 поможет инженерам разработать критически важные инструменты защиты
конфиденциальности, направленные на соблюдение нормативно-правовых требований в области, а также укрепление доверия клиентов:
 глава 6 поможет инженерам организовать технический обзор и консультирование по вопросам конфиденциальности, чтобы заранее подготовить руководство
по защите конфиденциальности и снизить нагрузку на юридический отдел;
 в главе 7 будет рассмотрен пример архитектуры по удалению данных — основного требования для минимизации рисков, связанных с данными, а также для
нескольких режимов соответствия нормативно-правовым актам по защите конфиденциальности;
 с помощью главы 8 читатели смогут разработать возможность экспорта данных,
чтобы помочь выполнить «Запрос субъекта на доступ к персональным данным»
(англ.: DSAR — Data Subject Access Requests);
 глава 9 предлагает примерный проект платформы управления согласием, позволяющей компаниям выполнить новые требования регулирующих органов и корпораций.
Часть 4 развивает идеи, затронутые в предыдущих частях книги, и помогает инженерам масштабировать программы обеспечения конфиденциальности:
 в главе 10 риски конфиденциальности соотносятся с рисками безопасности, и
предлагаются лучшие практики по их снижению;

22

О книге

 глава 11 поможет инженерам спланировать модели зрелости для своих предло-

жений по защите конфиденциальности и модели подбора персонала.
Если вы — практикующий инженер, то части 2 и 3 в большей степени отвечают
вашим насущным потребностям. Ведущим инженерам полезно прочитать книгу
целиком, поскольку их обязанности часто охватывают всю сферу деятельности организации. Руководителям, представителям СМИ и регулирующих органов я бы
рекомендовал подробно изучить части 1 и 4, а средние части, имеющие более техническую направленность, читать по желанию.

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

Об авторе

Нишант Бхаджария имеет степени бакалавра и магистра в области компьютерных
наук. Он работает в сфере кибербезопасности и конфиденциальности с 2010 года и
руководил командами разной величины в компаниях Nike, Netflix, Google и Uber.
В последней он в настоящее время возглавляет отдел инженерии конфиденциальности и подчиняется начальнику управления информационной безопасности. В команды, которые он возглавлял, входили инженеры и архитекторы, аналитики данных и консультанты по защите конфиденциальности, а также менеджеры по продуктам и специалисты по реагированию на инциденты.
Начав свою карьеру с создания команд и программ, он перешел к созданию более
стратегических программ, направленных на обеспечение зрелости конфиденциальности, партнерских отношений с группами инженеров и сотрудниками платформ
данных, а также на более тесное взаимодействие с юридическими отделами и отделами по связям с общественностью. Он отвечает за многое — от помощи совету
директоров в принятии решений, основанных на данных, до обучения менеджеров
продуктов работать с учетом принципов справедливости и доверия.
Кроме того, Нишант активно занимается проблемами кибербезопасности, публикует технические материалы по защите конфиденциальности и выступает с докладами в организациях, занимающихся этими вопросами. Он консультирует стартапы
по стратегии защиты данных и ведет курсы на платформе LinkedIn Learning
(https://www.linkedin.com/learning/instructors/nishant-bhajaria) по этой и другим
темам, в том числе карьерному росту и инклюзивности при подборе технических
кадров. Помимо этого, в начале пандемии COVID-19 Нишант совместно с исследователями из Массачусетского технологического института разработал первые в истории принципы конфиденциальности при отслеживании контактов заболевших
(https://law.mit.edu/pub/commentaryoncovid19contacttracingprivacyprinciples/
release/1).
Еще в колледже он проявил себя как разносторонний человек: учась на инженера,
Нишант писал статьи в газету, был членом команды по дебатам и подрабатывал у
профессоров политологии.
Вне работы у него есть несколько любимых занятий, связанных с дикой природой.
Из нравственных соображений он помогает спасать собак из приютов, борется с
контрабандой диких животных, защищает слонов от браконьерства и жестокого
обращения.

Об иллюстрации на обложке

Рисунок на обложке книги «Конфиденциальность данных» озаглавлен «Paysanne
des Environs de Berne» — «Крестьянка из окрестностей Берна, Швейцария». Он взят
из коллекции парадных костюмов разных стран Жака Грассе де Сен-Совера (1757–
1810), которая называется «Costumes civils actuels de tous les peuples connus» и была
впервые опубликована во Франции в 1788 году. Каждая иллюстрация тщательно
прорисована и раскрашена вручную, а разнообразие рисунков в коллекции напоминает о том, насколько разными в культурном отношении были регионы мира всего
двести лет назад.
Изолированные друг от друга, люди говорили на разных диалектах и языках. На
улицах или в сельской местности по одежде можно было легко определить, где живет человек, какова его профессия и социальное положение. С тех пор дресс-коды
изменились, и региональные различия, столь значительные в те времена, почти исчезли. Сейчас бывает трудно отличить жителей разных континентов, не говоря уже
о городах или регионах. Возможно, мы променяли культурное многообразие на более разнообразную личную жизнь — и уж точно на более разнообразную и стремительную технологическую.

- ЧАСТЬ I -

Конфиденциальность,
данные и ваш бизнес
Целевая аудитория этой книги — инженеры, но она будет не менее полезна руководителям компаний, сотрудникам СМИ и правительства. Однако крайне важно,
чтобы все читатели могли рассматривать конфиденциальность и защиту данных в
контексте. Они должны понимать, как изменилась программная инженерия на
практике и какие возникли соответствующие изменения бизнес-рисков. Это поможет им избежать ошибок, которые трудно исправить.
Глава 1 поможет разобраться в вопросах потока данных, чтобы технические руководители поняли, как их архитектура и данные работают в связке. Мы также рассмотрим риски изменения нормативной базы и подробно обсудим новых технологических игроков в области защиты конфиденциальности. Данный контекст поможет
читателям подойти к решению проблем конфиденциальности с четким пониманием, основанным на знаниях.
В главе 2 мы поговорим о том, что у различных заинтересованных сторон бизнеса — разные интересы в вопросах обработки данных. Мы также рассмотрим громкие дела, связанные с конфиденциальностью, чтобы читатели получили представление об уязвимостях, на которые следует обратить внимание. Наконец, расскажем
о том, как контролировать инвестиции и создать программу, способную масштабироваться в соответствии с изменениями в бизнесе.

- ГЛАВА 1 -

Инженерия конфиденциальности:
зачем нужна и как ее масштабировать

В этой главе мы рассмотрим:
 что такое конфиденциальность;
 как на нее влияет поток данных, проходящий через технологический стек и хра-

нилище;
 каково значение конфиденциальности и ее воздействие на ваш бизнес;
 какова ситуация в отношении инструментов обеспечения конфиденциальности,

особенно в вопросе «разрабатывать или покупать»;
 с чем эта книга не поможет;
 как меняется роль инженеров в последние годы.

Сейчас о защите конфиденциальности то и дело говорят в новостях. Обсуждаются
новые законы, направленные на защиту клиентов, сообщается об утечках данных и
штрафах, налагаемых на компании.
Люди на всех уровнях бизнеса беспокоятся по этому поводу, что вполне понятно.
Многие основатели компаний по профессии — инженеры или технические специалисты. Им трудно оценить риски, связанные с продуктами, которые зависят от сбора данных. Есть и другие — инженеры среднего звена в компаниях, которые пишут
код и создают средства автоматизации. Они принимают множество менее значимых решений, но результаты их технической работы, помноженные на масштаб,
способны стать источником риска для акционеров и инвесторов. Руководителям,
работающим в ИТ-сфере, стоит задуматься: «Какие из моих решений могут повлиять на защиту конфиденциальности в будущем, как раз тогда, когда стратегия начнет приносить плоды?»
Любому специалисту, чья должность прямо или косвенно будет влиять на защиту
конфиденциальности пользователей, важно быть компетентным в вопросах конфиденциальности как концепции и как вектора угроз. Таким людям необходимы четкие практические навыки контроля конфиденциальности. Эти навыки помогут им
внедрить разработку и инструментарий для обеспечения конфиденциальности в

28

Часть I. Конфиденциальность, данные и ваш бизнес

технические предложения компании, а также создать средства контроля конфиденциальности, прорывающиеся сквозь замкнутые структуры, характерные для ИТкомпаний.
Слишком часто компании попадают в ловушку противопоставления инноваций и
защиты конфиденциальности. Они создают цифровые продукты на основе данных
пользователей, а через несколько циклов пытаются наверстать конфиденциальность. К тому времени ущерб конфиденциальности и репутации зачастую уже нанесен. Ущерб конфиденциальности — это универсальный термин, означающий последствия утечки данных, эксфильтрации или несанкционированного доступа, в
результате которых нарушается неприкосновенность частной жизни пользователя.
Потеря защиты конфиденциальности подразумевает, что пользователю был нанесен ущерб; отсюда и этот распространенный термин. Затем руководителям необходимо найти ресурсы и пропускную способность, чтобы укомплектовать штат для
создания программы по защите конфиденциальности, определить приоритеты ее
реализации, а также изменить ритм ведения бизнеса, адаптировав его к требованиям данной задачи.
Эта книга поможет избежать многих ошибок и позволит читателям, будь то руководители технических отделов или специалисты-практики, осмыслить конфиденциальность и рассуждать о ней с пониманием как общей картины, так и мелких деталей. Освоив инструменты, методы и уроки, изложенные здесь, руководители
смогут адаптироваться к миру, ориентированному на конфиденциальность. Кроме
того, они смогут согласовать работу компании, превратив свою позицию в отношении защиты конфиденциальности в конкурентное преимущество.
В этой главе мы начнем с основ: самого понятия «конфиденциальность», возможных последствий для конфиденциальности потока данных, передаваемых внутри
компании, и пояснения, почему конфиденциальность важна. Во второй части главы
мы кратко рассмотрим инструменты обеспечения конфиденциальности, обсудим,
какие аспекты книга не охватывает, и рассмотрим изменения роли инженеров в последние годы, влияющие на конфиденциальность. Начнем с простого: что такое
конфиденциальность?

1.1. Что такое конфиденциальность
Чтобы понять, что такое конфиденциальность, сначала необходимо изучить, что
такое безопасность. Большинство компаний и руководителей применяют определенную систему безопасности, а также имеют хотя бы поверхностное понимание
этой концепции.
Для читателей данной книги, многим из которых, возможно, придется выполнять
двойную работу — специалиста по конфиденциальности и специалиста по безопасности — это очень важно. Если вы столкнулись с проблемой безопасности, она,
скорее всего, включает в себя что-то из перечисленного:
 сотрудник или иное лицо в компании получает доступ к конфиденциальным

данным бизнеса или клиентов, которого не должен иметь;

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

29

 деловой партнер получает коммерческие сведения или данные клиентов в такое

время или в таком объеме, которые негативно влияют на защиту конфиденциальности клиентов или конкурентные преимущества компании;
 данные, которые были собраны с разумной, оправданной целью, используются

для иных задач. Например, данные, собранные для выявления мошенничества
путем проверки, является ли пользователь реальным человеком, а не ботом, затем используются для маркетинга, потому что системы контроля доступа были
скомпрометированы.
Каждый из этих примеров начался с нарушения безопасности, которое привело к
нарушению конфиденциальности пользователя. И это не считая иного ущерба, нанесенного компании и ее конкурентному преимуществу.
При возникновении проблем с безопасностью всегда велика вероятность, что будет
нанесен ущерб и конфиденциальности. Руководителям очень важно это понимать и
избегать изолированного подхода, когда эти понятия рассматриваются отдельно
друг от друга. Изучаемые в следующих главах методы будут направлены на повышение уровня и конфиденциальности, и безопасности, что поможет компаниям защитить свою интеллектуальную собственность, а также данные пользователей.
ИТ-безопасность подразумевает реализацию набора стратегий кибербезопасности,
направленных на предотвращение несанкционированного доступа к активам организации. Эти активы включают в себя компьютеры, сети и данные. Целостность и
конфиденциальность чувствительной информации поддерживается путем подтверждения личности пользователей, желающих получить доступ к данным, и блокирования тех, кто не имеет на это прав. Подробнее об этом можно узнать из ресурсов,
посвященных безопасности, таких как Cisco Systems. Компания Cisco определяет
ИТ-безопасность как «набор стратегий кибербезопасности, предотвращающий несанкционированный доступ к активам организации, таким как компьютеры, сети и
данные. Она поддерживает целостность и конфиденциальность чувствительной
информации, блокируя доступ опытным хакерам» (http://mng.bz/Koag).
Обратите внимание, что это определение охватывает доступ к компьютерам (или, в
более широком смысле, к любому месту, где могут находиться данные), сетям (по
которым данные перемещаются от компьютера к компьютеру) и самим данным.
Цель здесь — избежать утечки, изменения или эксфильтрации данных внешними
злоумышленниками, то есть хакерами. В данном определении также вводится понятие чувствительной (конфиденциальной) информации, которое имеет разные
значения в зависимости от того, идет ли речь о данных, принадлежащих человеку
или же корпорации.
Как ведущий специалист в этой области, я всегда разрабатывал программы защиты
конфиденциальности, адаптируя и перепрофилируя инструменты безопасности.
Это означает, что я мысленно уравниваю внешнего злоумышленника (например,
хакера) и сотрудника компании, который может сознательно или случайно использовать данные ненадлежащим образом. В итоге целью становится защита данных
путем управления их сбором, доступом, хранением и использованием. В этом
смысле для защиты конфиденциальности не стоит создавать заново инструменты и

30

Часть I. Конфиденциальность, данные и ваш бизнес

процессы. Можно начать с адаптации структур, направленных на обеспечение
безопасности данных и их корректировки для защиты конфиденциальности.
Например, обнаружив несанкционированный доступ извне, вы, возможно, временно ограничите доступ к учетной записи, чтобы выяснить, исходит ли опасность от
владельца учетной записи или же сама запись была взломана. Вы также можете
приостановить действие других учетных записей, связанных с тем же адресом
электронной почты, IP-адресом и т. д. В случае с внутренним пользователем можно
приостановить доступ только из конкретной учетной записи к конкретной базе
данных — если выяснится, что это было не злонамеренное действие, а неправильное использование прав доступа. Что вы сделаете? Внедрите инструменты безопасности с явной целью повышения конфиденциальности и отслеживания влияния
доступа к данным на конфиденциальность. Это создает ощущение преемственности
и позволяет эффективно использовать существующие инструменты и отношения, а
не создавать лишние инструменты и процессы, которые могут мешать работе.
Давайте рассмотрим первое из моих любимых определений конфиденциальности.
По мнению авторов книги «The Privacy Engineer’s Manifesto» (Michelle Dennedy,
Jonathan Fox, Tom Finneran, Apress, 2014), «конфиденциальность данных можно
определить как санкционированную, справедливую и законную обработку личной
информации». Конфиденциальность тесно связана с безопасностью. Без безопасности нет конфиденциальности, поскольку любой доступ, нарушающий защиту безопасности, будет по определению несанкционированным, неоправданным и незаконным.
Понятие «конфиденциальность» шире, чем «безопасность»: безопасность, в первую очередь, защищает от внешних злоумышленников, а для конфиденциальности
требуются процессы и системы, защищающие данные и от злоупотреблений внутри
компании. В этом смысле конфиденциальность начинается после того, как обеспечена оптимальная безопасность. Как сказал мне один кандидат, с которым я недавно беседовал, безопасность — необходимое, но не достаточное условие для конфиденциальности.
Реализация такой программы требует определенного уровня творческого мышления, ведь ваша стратегия будет все время влиять на работу команды. Вместо того,
чтобы пытаться подавить внешние угрозы, задачей контроля конфиденциальности
будет влиять на то, как ваши команды взаимодействуют с пользователями и используют их данные. Это касается, например, того, какие данные вы можете собрать, как связываете риск с различными типами данных и как эти вопросы решаются в масштабе, когда через системы проходят петабайты данных.
Переходим ко второму определению конфиденциальности, которое мне нравится,
поскольку дарит пользователям чувство собственной значимости, даже когда вы
используете их данные в их отсутствие. По мнению Международной ассоциации
профессионалов в области конфиденциальности (англ.: IAPP — International Association of Privacy Professionals), «конфиденциальность информации — это право
управлять тем, как собираются и используются ваши персональные данные»
(https://iapp.org/about/what-is-privacy). Мы поговорим об этом подробнее в других

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

31

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

связанных с различными типами данных;
 учет данных — маркировка данных в системах хранения для отражения их

классификации;
 удаление данных — удаление данных после окончания заранее оговоренного

использования;
 обфускация данных — применение различных методов анонимизации для сни-

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

32

Часть I. Конфиденциальность, данные и ваш бизнес

1.2. Как данные поступают в компанию
и перемещаются внутри нее
Понимание того, как данные циркулируют по организации, принципиально важно,
поскольку во многих фирмах инженеров побуждают использовать преимущественно собственные инструменты и продукты компании, а также собственные технологические стеки, репозитории кода и процессы системной инженерии. В результате
они часто не осознают в полной мере, как действует поток данных и как он распределяется в системах хранения данных организации.
На рис. 1.1 показано, как данные попадают в компанию от «производителей» —
другими словами, как интерфейсы программирования приложений (англ.: API —
Application Programming Interface) и другие сервисы вводят данные в систему. С
точки зрения остальной части компании и практических служб, данные могут поступать от клиентов, третьих лиц, поставщиков данных, правительств и т. д. Как
правило, это происходит через API-шлюз, который служит единой точкой первоначального сбора данных. Однако за API-шлюзом находится множество микросервисов (подробно обсудим в следующих главах), которые обрабатывают данные и анализируют их, поэтому я называю этот уровень сбора данных «производителями».

Рис. 1.1. Поток данных в системах хранения данных компании:
поступление, хранение и загрузка

С первого уровня «производителей» поток данных распределяется по нескольким
другим уровням:
 оперативные базы данных, такие как Cassandra, где данные могут храниться, и к

ним может быть обеспечен быстрый доступ другим приложениям;
 хранилища в режиме реального времени, такие как Kafka, Pinot и другие распре-

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

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

33

для высокопроизводительных конвейеров данных, потоковой аналитики, интеграции данных и других критически важных приложений;
 аналитические хранилища, такие как Hadoop, Vertica и другие, куда аналитики

данных и специалисты по обработке данных отправляют запросы для целей бизнес-аналитики;
 облачные хранилища, такие как Amazon Web Services (AWS), Google Cloud

Platform (GCP) и другие, где данные могут храниться и архивироваться.
Однако, как показано на диаграмме, данные попадают и в другие системы, которые
плохо поддаются управлению и аудиту, — это ноутбуки сотрудников, программное
обеспечение (ПО) для повышения производительности типа Google Docs и
Microsoft Word, электронная почта и каналы чата. Проще говоря, в современном
бизнесе очень важно осознать, что тенденции и передовые практики, ускоряющие
инновации, — децентрализованная разработка, распределенное и избыточное хранение данных — затрудняют создание для крупных масштабов инструментов защиты конфиденциальности, о которых я говорил в предыдущем разделе, будь то
удаление данных, контроль доступа или снижение рисков и тому подобное.
Распространение данных также неизбежно становится причиной увеличения объема данных в организации. На рис. 1.2 показано, что большой объем вводимых и
распространяемых данных приводит к появлению большого количества хранилищ
данных, таблиц и файлов, и даже к экзабайтам данных.

Рис. 1.2. Системы хранения компании, содержащие распределенные данные

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

34

Часть I. Конфиденциальность, данные и ваш бизнес

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

1.3. Почему конфиденциальность имеет значение
Полагаю, среди читателей книги есть как исполнители, так и мечтатели. К исполнителям относятся руководители технических программ, инженеры, архитекторы
данных, специалисты по облачным технологиям и системным операциям, а также
руководители, которые выполняют различные задачи, но с одной целью —
сохранить непрерывность и предсказуемость бизнес-операций.
К мечтателям относятся основатели стартапов с техническим образованием, научно-технические сотрудники-новаторы, а также инвесторы, готовые вложиться в
идеи будущего.
Мечтатели оптимизируют свою работу с целью получения результата и ускорения
процесса, а исполнители — ради качества выполнения и согласованности. Все эти
цели не будут достигнуты, если (или когда) из-за проблем защиты конфиденциальности работа компании встанет. Однако, как уже говорилось, слишком многие руководители, на волне достижений в других областях, считают себя неуязвимыми
для рисков, связанных с конфиденциальностью. Они также уверены, что рычаги
государственного принуждения ослабли из-за нежелания политиков препятствовать
предпринимателям, которые создают несметные богатства и работают на благо
США и других стран по всему миру. Эта уверенность может быть необоснованной.

1.3.1. Штрафы реальны
Принятие нормативных документов — таких, как «Общий регламент по защите
данных» (GDPR), которые мы рассмотрим в последующих главах, позволило регулирующим органам штрафовать компании, уличенные в несоблюдении конфиденциальности.
На рис. 1.3 показан один из способов влияния проблем конфиденциальности на бизнес.
Штрафы, налагаемые на компании, — реальны и значительны (http://mng.bz/9aZq).
Крупные предприятия с проверенными моделями получения прибыли способны
выдержать это финансовое бремя, но мелкие компании оно может истощить. Может оказаться, что стартапам придется отдавать на оплату штрафов ресурсы, предназначенные для финансирования новых инициатив и найма ключевого персонала.

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

35

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

Рис. 1.3. Самые высокие штрафы в делах о защите конфиденциальности

Ни одна компания не застрахована от риска нарушить конфиденциальность или
привлечь к себе внимание регулирующих органов. Штрафы могут обрушиться на
голову любого предприятия, именно поэтому важно брать их в расчет. Иногда
штрафы пересматриваются в сторону уменьшения. Так, штраф авиакомпании British
Airways снизили до 20 миллионов долларов (http://mng.bz/WBWl), но глупо надеяться на удачу или милосердие, особенно если у вашей фирмы нет больших связей.
Один из моих профессиональных наставников сказал, что компанию Equifax следовало
оштрафовать жестче после знаменитого взлома в 2017 году (http://mng.bz/80A5).
Ведь кредитное агентство имеет возможность собирать личные финансовые данные
пользователей без их согласия и принимать решения, касающиеся их кредитоспособности. К тому же Equifax допустила утечку огромного количества этих данных в
результате процессов настолько небрежных и неадекватных, что даже младший
инженер по защите конфиденциальности или безопасности понял бы, что они рискованные. Особенно обидно, что обычные потребители должны были платить около 120 долларов в год за защиту кредитных отчетов, не говоря уже об издержках,
которые несут предприятия, вынужденные покрывать такие расходы.
Почему инженеры должны переживать о штрафах? Разве их работа не заключается
в том, чтобы создавать продукты и проверять их на практике, а бизнес-рисками
разве не управляют юристы и специалисты по соблюдению нормативных требований? Помимо очевидного ответа, что ни одна компания не сможет бесконечно платить штрафы, важно, чтобы инженеры понимали — их работа теперь включает в
себя не только создание функций, стимулирование вовлеченности и монетизацию

36

Часть I. Конфиденциальность, данные и ваш бизнес

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

1.3.2. Погоня за эффективностью в начале пути
может вызвать проблемы конфиденциальности в будущем
На ранней стадии инновационного процесса и даже когда компании пытаются стимулировать внедрение продукта, инженеры принимают ряд решений, чтобы привлечь внимание инвесторов (И), а также клиентов из секторов «бизнес-длябизнеса» (В2В) и «бизнес-для-потребителя» (В2С).
В этом есть смысл, поскольку финансирование и раннее внедрение — необходимые, хотя и недостаточные условия для коренных изменений, к которым стремятся
руководители инженерных отделов.
Рассмотрим сценарий, в котором отсутствие долгосрочной стратегии стало причиной серьезных трудностей у компании.

Gamesbuster: анализ конкретного примера
Жила-была компания, назовем ее Gamesbuster, которая создавала приложения для
видеоигр для «умных» телевизоров. Она стремилась завлечь пользователя сразу же
после включения им «умного» телевизора. Для достижения этой цели было очень
важно, чтобы приложение запускалось сразу после включения телевизора, ведь
иначе пользователь мог выбрать другие приложения.
Чтобы гарантировать как можно более быстрый запуск приложения, инженеры
Gamesbuster разработали логику автоматизации под названием «загрузка в режим
ожидания». При загрузке устройства приложение запускалось в фоновом режиме
и находилось в нем постоянно, регулярно связываясь с серверами компании
Gamesbuster для получения обновлений и поддержания режима «готовности».
Чтобы загрузка в режим ожидания работала, серверы Gamesbuster должны были
получать информацию от устройств, включая IP-адреса, которая автоматически отправлялась по стандартным протоколам интернет-связи. По мнению инженеров,
сбор IP-адресов был очень нужен, ведь информация о местоположении, полученная
на его основе, позволила бы персонализировать приложение для пользователя.
Эта функция являлась детищем двух инженеров, которые хотели быть уверенными,
что целевая аудитория — нетерпеливая молодежь — не выйдет из приложения до
загрузки игры. Они не понимали природу данных, передаваемых на серверы компании Gamesbuster. Это хрестоматийный пример подхода «fail fast and make
things» — «быстро провалиться и действовать дальше».
По мере того, как загрузка в режим ожидания приживалась, она превратилась из
чисто инженерной идеи в возможность роста для бизнеса. Отделы продаж увидели

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

37

возможность убедиться, что партнеры, поставляющие приложения Gamesbuster,
знают об этой опции и поддерживают ее. Согласно контракту, партнерам, которые
предустанавливали приложение Gamesbuster на свои устройства, настоятельно рекомендовалось применить данную функцию. Через некоторое время количество
устройств, поддерживающих ее, число пользователей и, в свою очередь, объем
данных, поступающих на серверы компании, существенно увеличились. Значит, и
доходы основателей Gamesbuster, а также ее технических специалистов, вносящих
инновации, значительно выросли. Инвесторы заметили этот успех и влили в компанию еще больше денег.
Однако не только инвесторы заметили изменения. Регуляторы, задача которых —
защищать права пользователей на конфиденциальность, встревожились, что
Gamesbuster собирает информацию о местоположении клиентов. Вероятно, эти
данные были собраны инженерами без злого умысла, но их собирали, пока приложение работало в фоновом режиме (по сути, это и есть загрузка в режим ожидания). Получалось, что данные собирались еще до того, как пользователь регистрировался и принимал политику конфиденциальности и другие положения, которые
обычно позволяют компаниям собирать такие данные.
Регулирующие органы потребовали от Gamesbuster прекратить сбор IP-адресов без
согласия пользователей, а если таковой абсолютно необходим, то инженеры компании должны хранить их в отдельных базах данных с очень ограниченным доступом, откуда адреса должны автоматически удаляться после запуска приложения и
использования данных в целях персонализации.
Чтобы гарантировать, что они смогут определить, какие именно данные собирают,
инженеры, разработавшие приложение загрузки в режим ожидания, создали фильтры, определяющие поля под названием «IP-адрес». Однако через несколько месяцев, когда регулирующие органы провели аудит хранилища данных в системах
компании Gamesbuster, там обнаружили миллионы IP-адресов, хранившихся по несколько месяцев. Это было явным нарушением обязательств, которые компания
Gamesbuster взяла на себя перед государством.
Как такое случилось? Основных причин две:
1. Фильтры, созданные инженерами, могли обнаружить IP-адреса, если они были в
формате структурированных данных, где каждая передаваемая единица определялась как пара ключ/значение. Как оказалось, все большее количество устройств партнеров, которые предварительно загрузили приложение Gamesbuster,
передавали данные на сервера в виде JSON-блобов. В нашем примере JSONблоб — это одно поле, где хранится текст в формате JSON. Следовательно, база
данных понятия не имела о ключах в блобе или их значениях, а фильтры компании Gamesbuster не могли обнаружить IP-адреса. Вместо того чтобы хранить их
в специальных таблицах с ограниченным доступом, системы Gamesbuster позволили этим IP-адресам смешиваться и храниться вместе с данными, разрешенными к свободному использованию.
2. Когда IP-адреса удавалось успешно перехватить, они заносились в одну разрешенную таблицу, где хранились в течение 30 дней. Однако инженеры предоста-

38

Часть I. Конфиденциальность, данные и ваш бизнес

вили доступ к этой таблице службе безопасности для решения критически важных задач по безопасности — например, для анализа и предотвращения DDOSатак и других подобных инцидентов. Однако выяснилось, что различные автоматизированные скрипты запрашивали эту таблицу в качестве источника, а данные IP-адресов копировались и хранились в других таблицах более 30 дней.
Другими словами, ни жесткий контроль доступа, ни сроки хранения данных не
обеспечивались, как было обещано регулирующим органам.
Аудиторское расследование поставило под угрозу существование самой бизнесмодели компании, поскольку фирме, находящейся под следствием за неправомерное
использование данных о местоположении, трудно найти партнеров, готовых устанавливать ее приложения. Это привело бы к замедлению роста и снижению степени
вовлечения клиентов, что, в свою очередь, привело бы к сокращению доходов от
рекламы. В итоге компании пришлось принять меры по исправлению ситуации:
1. Во-первых, пришлось массово удалить IP-адреса. Это означало, что в некоторых
случаях было необходимо перестраховаться и удалить даже IP-адреса, собранные на законных основаниях. Невозможно было точно определить, какие именно данные были собраны при загрузке в режиме ожидания, а из-за отсутствия
учета данных не представлялось возможным выполнить целенаправленное удаление. В следующих главах я расскажу о пользе программы управления, внедренной на начальном этапе.
2. Во-вторых, эти действия привели к срыву разработки новых функций, поскольку
компания не могла полагаться на существующие данные и поток доходов до завершения расследования. В результате изменения коснулись дорожных карт нескольких продуктов, а амбициозные инженеры, чье продвижение по службе зависело от создания новых функций, ушли в молодые компании, подвергавшиеся
менее пристальному вниманию со стороны регулирующих органов.
3. В-третьих, компании пришлось ввести ограничительный режим соблюдения
нормативных требований, что негативно сказалось на скорости внедрения и разработки продуктов. На смену модели «торопись и делай» пришла модель «заполняй формы и проверяй».
Урок для инженеров очевиден: внедрение новых функций, связанных с обработкой
данных, без учета вопросов конфиденциальности таит в себе значительные риски.
Инженерам и техническим руководителям стоит создавать инструменты и процессы обеспечения конфиденциальности в процессе разработки основных продуктов и
функций. Далее в этой книге мы подробно рассмотрим тщательный технический
процесс проверки конфиденциальности, который поможет защитить конфиденциальность и одновременно позволит инженерам эффективно и продуктивно вводить
инновации.
Не только штрафы могут подкосить компанию финансово, но и сами расследования. Крайне важно, чтобы инженеры и технические руководители (основатели
компаний и те, кто их финансирует) понимали, насколько серьезной может быть
атака регулирующих органов на их дорожные карты. Мы обсудим это в следующем
подразделе.

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

39

1.3.3. Расследования нарушений конфиденциальности —
не просто преграда на пути к успеху
Нормативно-правовая база в области конфиденциальности и безопасности появилась относительно недавно, и, учитывая новизну концепций, регулирующие органы
могут быть очень слабо осведомлены о технологиях защиты конфиденциальности.
Кроме того, миллионы людей во всем мире только впервые подключаются к Интернету, а компании получают информацию о пользователях, объединяя сведения
из множества баз данных и идентификаторов, которые еще десять лет назад были
им недоступны.
Потенциал технологий вроде искусственного интеллекта и машинного обучения
растет с каждым днем, а с ним растут возможности для злоупотреблений и расследований. Трудно предсказать, какое влияние подобные проверки окажут на качественные инновации, но я хочу привести пример масштабного правительственного
расследования, разрушившего планы одной из самых успешных компаний Америки
и изменившего траекторию развития технологий.
Антимонопольное законодательство гарантирует, что ни одна компания не будет
контролировать рынок, ограничивать выбор потребителей и завышать цены. В конце 1990-х Министерство юстиции США обвинило корпорацию Microsoft в том, что
она, предоставляя свое программное обеспечение для браузера бесплатно, пыталась
создать монополию и стала причиной краха конкурирующей компании Netscape. В
1998 году против компании были выдвинуты обвинения, и Министерство юстиции
подало на нее в суд. До этого момента казалось, что корпорацию Microsoft не остановить.
Расследование нарушило бизнес-модель компании Microsoft, а также ее текущую
деятельность. В одном интервью основатель и икона бизнеса Билл Гейтс заявил,
что Windows могла бы стать доминирующей мобильной операционной системой в
мире, если бы не то антимонопольное дело (http://mng.bz/EDvX).
«Несомненно, антимонопольный иск плохо сказался на работе Microsoft. Если бы
не он, мы могли бы активнее сосредоточиться на создании операционной системы
для телефонов, и тогда вместо Android вы бы пользовались Windows Mobile», —
сказал Гейтс на конференции DealBook газеты New York Times в Нью-Йорке.
Microsoft остается лидером с операционной системой Windows для настольных ПК
и в других категориях, таких как коммерческие пакеты офисного ПО, но больше не
работает над Windows для телефонов. Сегодня самой популярной мобильной операционной системой является Google от Alphabet, а на втором месте — iPhone от
Apple.
«О, мы были так близки, — выразился Гейтс о неудаче компании в области мобильных операционных систем. — Я просто слишком отвлекся. Я все испортил потому, что отвлекся». Он сказал, что компания опоздала на три месяца с выпуском
операционной системы, которую можно было бы использовать на телефонах компании Motorola. «Сегодня никто из присутствующих и не слышал о Windows
Mobile» (http://mng.bz/N4pv).

40

Часть I. Конфиденциальность, данные и ваш бизнес

На момент написания этой книги самым серьезным нормативным документам по
защите конфиденциальности еще не исполнилось и пяти лет, но у комментариев
Гейтса есть четкий подтекст: крупные дела против современных технологических
компаний могут иметь негативные последствия для рынка. Если опыт Microsoft кажется вам случайностью, подумайте вот о чем: за долгое время антимонопольное
законодательство развилось от теории до нормативных актов, непосредственно
влияющих на рынок. Законодательство в области защиты конфиденциальности может пойти по аналогичной траектории в сегодняшнем политическом климате.
Давайте рассмотрим другие недавние штрафы и санкции. В 2017 году, до проблем
с компанией Cambridge Analytica, Facebook (ныне Meta Platforms Inc., признана
экстремистской организацией на территории РФ) за 24 часа получил несколько
штрафов.
 Итальянский антимонопольный регулятор оштрафовал компанию WhatsApp на

3 млн евро за «принуждение» пользователей мессенджера делиться данными с
Facebook (то есть они или делятся данными, или теряют доступ к приложению).
 На следующий день Европейская комиссия оштрафовала Facebook на 110 млн

евро в рамках антимонопольного дела за предоставление недостоверной информации об имеющейся возможности автоматически сопоставлять учетные записи
пользователей Facebook и WhatsApp. В 2014-м Facebook заявила, что не может
этого делать, но затем в 2016-м неожиданно смогла, используя общие для обоих
аккаунтов номера телефонов.
 В тот же день Франция, Бельгия и Нидерланды заявили, что компания Facebook

нарушила их законы о конфиденциальности данных, поскольку после обновления своих пользовательских соглашений в 2014 году применяла не удовлетворяющие требованиям закона практики сбора и использования данных. Франция
наложила штраф в размере 150 тысяч евро; Бельгия и Нидерланды могут тоже
наложить штрафы. Испания и Германия объявили о проведении расследований
по данному вопросу.
Полезно разобраться подробнее, как такие расследования размывают границы между антимонопольным законодательством и неприкосновенностью частной жизни.

Еврокомиссия оштрафовала компанию WhatsApp
на 110 млн евро за искажение данных
Во время рассмотрения антимонопольным регулятором в 2014 году сделки по приобретению компании WhatsApp за 19 млрд долларов корпорация Facebook дважды
заявляла, что не может «установить надежное автоматизированное соответствие»
между аккаунтами Facebook и WhatsApp. Затем, в 2016-м, сервис WhatsApp объявил про обновление пользовательских соглашений и политики конфиденциальности, включающее привязку аккаунтов WhatsApp к аккаунтам Facebook через номера
телефонов. Комиссия обвинила компанию в обмане и наложила крупный штраф, но
согласилась не пересматривать решение об одобрении слияния. Штраф мог составлять до 1 % от общей выручки (примерно 270 млн долларов США по данным
Facebook за 2016 год) (http://mng.bz/DKnA, http://mng.bz/l9md).

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

41

Ключевой вывод — антимонопольные органы ЕС считают, что права и обязательства по использованию данных пользователей имеют большое значение при анализе слияний и обеспечении соблюдения антимонопольного законодательства.
Кроме того, в ЕС, похоже, готовы налагать крупные штрафы на американские технологические компании. Время покажет, воспользуются ли органы ЕС по защите
данных своей возможностью делать это в соответствии с GDPR (позволяющим выписывать штрафы до 4 % от глобального дохода).
Что нужно знать инженерам и техническим руководителям — доподлинно неизвестно, в каком виде инженеры компании Facebook хранили телефонные номера
в своих базах данных, какие меры контроля применялись (если вообще имелись)
для предотвращения связывания аккаунтов на основе телефонных номеров, и как
эти средства контроля впоследствии обошли, чтобы связать аккаунты.
Однако европейские власти посчитали, что обязательство хранить две базы данных
отдельно друг от друга будет выполняться неукоснительно. На самом деле все оказалось вовсе не так. Инженерам часто удобно объединять два набора данных об
одном и том же пользователе потому, что это обеспечивает лучшую видимость для
персонализации и монетизации. Или же они могли более эффективно защитить
данные, объединив их в один набор на основе уникального значения, такого как
номер телефона.
В любом случае, инженерное решение соединить два набора данных, которое, в
свою очередь, привело к нарушению прав пользователей на конфиденциальность,
затем рассматривалось через призму обязательств, взятых на себя корпорацией
Facebook во время сделки по слиянию/поглощению.
Основатели технических компаний и другие руководители в данной сфере должны
спросить себя: «Каковы возможные последствия нашей практики работы с данными для конфиденциальности пользователей и могут ли они повлиять на долгосрочные стратегические возможности роста компании?» Сколько решений, которые могут привести к большим негативным результатам, инженеры принимают каждый
день, имея весьма ограниченное представление о защите конфиденциальности? Наличие проверяемой системы каталогизации данных может смягчить некоторые из
этих проблем, и в главе 4 вы узнаете, как это сделать.
Главный технический вывод для инженеров: решения, продиктованные лучшими
соображениями и принятые с целью оптимизации рабочего процесса, могут идти
вразрез с юридическими обязательствами, а также интересами клиентов. Вот почему крайне важно надежное управление данными, а также более тесная связь между
инженерными и юридическими службами.

Антимонопольный регулятор Италии оштрафовал WhatsApp
на 3 млн евро
По крайней мере, одна страна, являющаяся членом ЕС (Италия), решила наложить
собственный антимонопольный штраф за связывание аккаунтов Facebook и WhatsApp.
Обоснованием послужило такое положение защиты данных, как получение согла-

42

Часть I. Конфиденциальность, данные и ваш бизнес

сия пользователей WhatsApp на объединение их аккаунтов с аккаунтами Facebook.
Регулятор пришел к выводу, что WhatsApp и Facebook «излишне подчеркивали»
необходимость принятия нового пользовательского соглашения и политики конфиденциальности в рамках обновления приложения.
Ключевой вывод — некоторые антимонопольные органы ЕС, похоже, готовы
применять принципы защиты данных и принципы обеспечения конфиденциальности при установлении факта нарушения свободной конкуренции.
Что нужно знать инженерам и техническим руководителям — в этом конкретном
случае основное внимание следователи и регулирующие органы уделяли тому, давали ли пользователи разрешение использовать их данные определенным образом. Регулирующие органы, похоже, также хотели, чтобы на пользователей не оказывалось
давления при получении этого согласия, и чтобы оно было информированным.
Инженеры часто считают, что реорганизация кода делает его более эффективным и
масштабируемым. Они применяют аналогичный подход к разрозненным наборам
данных, описывающим одних и тех же пользователей.
Урок для инженеров и технических руководителей таков: вы можете считать, что
объединенный набор данных позволит расширить ваше представление о пользователе, но регулирующим органам, которые занимаются вопросами конфиденциальности, нужно гарантировать, что права пользователей не нарушены.
Инженерам крайне важно сотрудничать с коллегами-юристами, чтобы убедиться,
что пользователи дали согласие на такое объединение данных.

Пять органов ЕС по надзору за соблюдением законодательства
по защите данных подают иски к корпорации Facebook
за изменения политики в 2014-м и другие действия с данными
Колеса правосудия вращаются медленно. И хотя большинство пользователей уже
давно забыли об изменениях в политике конфиденциальности Facebook 2014 года,
пять органов ЕС по надзору за соблюдением законодательства по защите данных
начали расследование. В мае 2017-го три из них объявили о своих выводах, а еще
один вынес решение чуть раньше (Гамбург, Германия). Последний (Испания) расследование еще не завершил (http://mng.bz/B16w). Вот результаты.
 Франция — орган по надзору за соблюдением законодательства по защите дан-

ных (англ.: DPA — data protection authority) обнаружил следующие нарушения:
(1) отсутствие правовой основы для объединения информации пользователей с
целью подбора и показа онлайн-рекламы на основе их поведения, (2) незаконное
отслеживание файлов datr-cookie и (3) отсутствие должного уведомления и согласия пользователей на присутствие кнопки «Нравится» на сторонних сайтах.
Был наложен штраф в размере 150 тысяч евро.
 Бельгия — DPA пришел к выводу, что корпорация Facebook нарушила и про-

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

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

43

являющихся пользователями. DPA добивается судебного постановления для
введения в действие изменений, которые он хочет наложить на практики
Facebook.
 Нидерланды — среди наиболее значимых выводов по данному делу можно на-

звать следующие определения DPA: (1) полномочия в отношении корпорации
Facebook имеет нидерландский, а не ирландский регулятор, (2) практика сбора и
использования данных о нажатии кнопки «Нравится» незаконна (общий вывод
всех надзорных органов), поскольку компания не обеспечила адекватное уведомление о сборе данных, и (3) раскрываемые компанией Facebook данные о
конфиденциальности слишком многослойны, и потому недостаточны (голландский регулятор поднимал эту проблему ранее, в отдельном расследовании 2015
года). DPA выясняет, изменили ли в Facebook свою практику в соответствии с
голландским законодательством о защите данных, и если нет, может наложить
штраф.
 Германия — DPA Гамбурга ранее предписал корпорации Facebook прекратить

объединение данных пользователей WhatsApp без их предварительного согласия
и удалить уже переданные данные.
Так чему же учат нас эти результаты по конкретным странам?
Ключевой вывод — несмотря на заявления корпорации Facebook, что она находится в юрисдикции только ирландского DPA, и что к ней применимо только ирландское законодательство о защите данных, все надзорные органы пришли к выводу, что их местные законы также применимы (в зоне юрисдикции обычно оказывался местный, находящийся в стране офис Facebook).
Что нужно знать инженерам и техническим руководителям — зачастую между
принятием инженерных решений, затрагивающих конфиденциальность, и последствиями юридического плана бывает значительная задержка. В случае расследования в Бельгии власти утверждали, что корпорация Facebook собирала «избыточные
персональные данные». Инженеры часто стараются собирать данные с прицелом на
будущее и хранить их как можно дольше, полагая, что те могут пригодиться позже.
В настоящее время власти ограничивают сбор и хранение данных без обоснованных коммерческих целей.
В случае с расследованием в Нидерландах под пристальным вниманием оказался
уровень прозрачности и наглядности, предоставляемый пользователям. Чтобы избежать подобных неприятностей, инженерам важно действовать обдуманно и взаимодействовать с юридическим отделом компании, а также разработчиками средств
представления информации пользователям. Это позволит надлежащим образом
информировать пользователей о сборе данных.
Наконец, в примере с Германией инженерам пришлось удалить ранее собранные
сведения, которые они объединили с другими данными. Пример компании
Gamesbuster показывает, что подобные удаления могут оказаться непомерно дорогими и технически сложными. Во избежание ошибок и неэффективных решений
инженерам стоит обзавестись для этого инструментами, о которых мы подробно
поговорим в следующих главах.

44

Часть I. Конфиденциальность, данные и ваш бизнес

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

1.3.4. Защита конфиденциальности как возможность
для бизнеса: реальный пример
В 2012 году меня нанял небольшой стартап, занимавшийся инновациями в сфере
цифровой идентификации. В числе наших продуктов была система глобальной
идентификации openID, позволявшая пользователям проходить аутентификацию на
разных сайтах, не вводя логин и пароль, а также одновременно работать с несколькими электронными ресурсами. Она же собирала серверные данные для облегчения
изучения клиентов.
Как и большинство стартапов, мы фонтанировали идеями, но не уделяли должного
внимания процессам. Инженеры старались обходиться без строгих предписаний по
документированию кода, проверке сбора данных и обеспечению согласованности
между публичным раскрытием информации и практикой конфиденциальности. Однако со временем для привлечения инвестиций раунда B нам стало крайне важно
заполучить в клиенты компании, которые сами находились под строгим контролем
и часто работали в юрисдикциях, чувствительных к конфиденциальности, — например, в Европейском союзе.
В то время законов о конфиденциальности вроде Общего регламента по защите
данных (GDPR), чреватых серьезными последствиями, еще не существовало, поэтому продемонстрировать нашу зрелость как организации, заботящейся о конфиденциальности, было непросто. Старший вице-президент компании по инженерным
вопросам попросил меня пройти сертификацию на соответствие стандарту ISO
27001: «ISO/IEC 27001 формально определяет систему управления информационной безопасностью (англ.: ISMS — Information Security Management System). Это
механизм управления, включающий в себя структурированный набор действий, с
помощью которых можно управлять информационными рисками (в стандарте они

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

45

называются "риски информационной безопасности")» (www.iso27001security.com/
html/27001.html).
Система ISMS должна была доказать нашим потенциальным клиентам, что у нас
есть технические процессы для управления защитой данных. Это было очень важно, поскольку наши инструменты должны были позволить нашим клиентам работать с данными, собранными у их клиентов. Без надежной технической базы ни одна крупная корпорация не доверила бы огромные объемы данных маленькому американскому стартапу. Я был молодым инженером, стремился отработать новые
технические навыки, а заодно выделиться на фоне коллег, и потому занялся подробным изучением ISO.
Стандарт ISO/IEC 27001 преследует две четкие цели:
1. Описывает структуру ISMS, излагая важные аспекты на достаточно высоком
уровне.
2. Аккредитованные аудиторы-сертификаторы могут (при желании) использовать
его как основу для формальной оценки соответствия организации нормативноправовым требованиям.
Для сертификации требуются следующие обязательные документы:
1. Область применения ISMS (в соответствии с пунктом 4.3).
2. Политика информационной безопасности (п. 5.2).
3. Процесс оценки информационных рисков (п. 6.1.2).
4. Процесс регулирования информационных рисков (п. 6.1.3).
5. Цели информационной безопасности (п. 6.2).
6. Доказательства компетентности людей, работающих в сфере информационной
безопасности (п. 7.2).
7. Другие документы, связанные с ISMS, которые организация считает необходимыми (п. 7.5.1b).
8. Документы оперативного планирования и контроля (п. 8.1).
9. Результаты оценок (информационных) рисков (п. 8.2).
10. Решения относительно регулирования (информационных) рисков (п. 8.3).
11. Свидетельства мониторинга и измерения информационной безопасности
(п. 9.1).
12. Программа внутреннего аудита ISMS и результаты проведенных аудитов (п. 9.2).
13. Свидетельства проведения высшим руководством проверок ISMS (п. 9.3).
14. Свидетельства выявленных несоответствий и предпринятых действий по их исправлению (п. 10.1).
Когда мы занялись созданием необходимых инструментов и процессов, я заметил
следующие изменения:
 сам факт того, что мы проходили сертификацию, очень заинтересовал венчур-

ных инвесторов, готовых финансировать и поддерживать нас;

46

Часть I. Конфиденциальность, данные и ваш бизнес

 консервативные и избегающие риска компании в США и Европе начали исполь-

зовать наши инструменты, поскольку теперь они были уверены, что мы можем
работать с их данными безопасно;
 отдельные инструменты и процессы способствовали повышению эффективности

работы инженеров и улучшили качество данных. А мне помогли привести в порядок некоторые элементы моей работы, что, в свою очередь, позволило создать
долгожданную структуру в нашей фирме, которая очень в этом нуждалась.
Со временем сертификация сделала нас более зрелой компанией, обеспечила прочную клиентскую базу и помогла пройти через трудные времена. Благодаря усилиям, потраченным на то, чтобы разобраться с массивными серверными системами,
конвейерами данных и технологиями вроде платформ Apache Hadoop и Kafka, повысилась и моя компетентность как инженера. Это позволило мне занимать очень
высокие должности технического руководителя в таких компаниях, как Netflix,
Google и Uber, вести курсы в социальной сети LinkedIn, а затем написать эту книгу
о технической защите конфиденциальности.
Урок для инженеров заключается в следующем: конфиденциальность — это не
только возможность избежать штрафов и переделок. При правильном подходе она
может выделить ваше техническое предложение на фоне других, возвысить компанию, а заодно и вашу карьеру.
До сих пор мы рассматривали влияние вопросов конфиденциальности на компании
с точки зрения штрафов, накладываемых органами, и неэффективности, вызванной
недальновидными техническими решениями. Мы также отметили благотворное
влияние качественной практики защиты конфиденциальности. Инженерам очень
важно понять, что их работа в этом направлении влияет на доверие общества к
компании, безопасность и взаимоотношения с клиентами. Следующий раздел будет
посвящен более конкретным аспектам. Мы посмотрим, как выглядит рабочий процесс в компании, которая не придерживается надлежащей практики защиты конфиденциальности, а затем — в той, что придерживается.

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

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

47

личных системах, а классифицируют или инвентаризируют их только на поздних
этапах рабочего процесса.
Может оказаться, что к тому моменту инженеры и их инструменты эти данные уже
использовали, что вызовет проблемы с обеспечением конфиденциальности. У компании возникнет множество трудностей в процессе организации и обработки разросшегося объема данных. Мы поговорим об этом подробнее в главе 4, а пока рассмотрим, каковы последствия сбора такого количества данных при незнании того,
какие их фрагменты являются источником рисков конфиденциальности, и неспособности защитить их должным образом. Вполне возможно, что многие утечки
данных, штрафы и нарушения происходят именно из-за подобных небрежных проектных решений!
Цель данной книги — заставить вас считать эффективные меры по защите конфиденциальности основополагающим компонентом своего бизнеса. Эти меры должны
применяться к данным с момента попадания их в компанию. Это обеспечит гораздо
более эффективное управление данными, больший контроль доступа, а вероятность
нарушения конфиденциальности значительно снизится.

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

На рис. 1.5 показана компания, проводящая эффективную политику защиты конфиденциальности. Главы 3–9 позволят вам взглянуть на конфиденциальность с позиции этой компании. Вы научитесь создавать архитектуру рационального управления данными, которая поможет выявлять риски конфиденциальности на этапе
ввода данных. Также вы научитесь создавать правильные инструменты, процессы и
настраивать автоматизацию для внедрения защиты конфиденциальности.
Такой порядок действий — сначала управление, потом инструменты — очень важен и помогает инженерам повысить уровень защиты конфиденциальности, а вместе с ним — качество данных и производительность.

48

Часть I. Конфиденциальность, данные и ваш бизнес

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

Рис. 1.6. Маркировка данных на этапе получения и сопоставление
их с элементами контроля защиты конфиденциальности —
инженерия конфиденциальности в действии!

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

49

Рассмотрим подробнее компанию на рис. 1.5 и выясним, какие процессы происходят на всех этапах защиты конфиденциальности. Рис. 1.6 демонстрирует, как маркировка и каталогизация должны работать в этом смелом новом мире. Мы подробно обсудим описанные методы далее, но из схемы видно, как значения отдельных
полей данных изменяются сразу после попадания в нашу экосистему. Поля попадают в систему с основными значениями, а затем мы добавляем тег, указывающий
на риск конфиденциальности. Поле с надписью «Служба маркировки данных» —
это упрощенное обозначение всей инфраструктуры учета данных, о которой мы
расскажем подробнее.
А пока главное заключается в том, что на ранней стадии маркировка позволяет
применить к данным принудительные политики обработки (удаления, хранения
и т. д.). Это создает архитектуру проектирования защиты конфиденциальности, в
которой средства контроля конфиденциальности закладываются на ранних этапах,
в сами данные. Рисунок призван донести простую мысль: нет никакого секретного
ингредиента для защиты конфиденциальности — только своевременное выявление
и автоматизированный механизм управления.
Мы рассмотрели процесс защиты конфиденциальности на высоком уровне, и я вернусь к этой теме позже. На данный момент я надеюсь, что вы получили более четкое представление об этом процессе и последствиях как плохого, так и хорошего
управления им.
Изучив конкретные последствия инженерии конфиденциальности, давайте рассмотрим вопрос с более абстрактной точки зрения. Следующий раздел — для инженеров, чувствующих, что им приходится выбирать между отправкой функции и
завоеванием доверия.

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

1.5.1. Конфиденциальность и безопасность: период ковида
Инженеров и технических руководителей больших и малых компаний волнуют одни и те же вопросы:
 Зачем вообще при ограниченных ресурсах и трудновыполнимых перспективных

планах уделять так много внимания защите конфиденциальности?

50

Часть I. Конфиденциальность, данные и ваш бизнес

 Данные собирают все, и мы знаем компании, где плохо соблюдают конфиденци-

альность, но цена их акций взлетает. Зачем заботиться о защите конфиденциальности?
Ответы могут показаться нелогичными, но если задуматься, они очевидны. Бизнес
работает на основе предсказуемости, и его процветание зависит от доверия. Если
предсказуемость нарушена, а доверие подорвано, как правило, это плохо сказывается на рентабельности бизнеса.
Можно провести интересную параллель с коронавирусом. Пандемия изменила наш
образ жизни. Шумные улицы, множество посетителей в спортивных центрах, переполненные конференц-залы, сияющие банкетные залы — все они затихли. Связь
между людьми исторически была символом комфорта и стремлений. Во времена
коронавируса она стала угрозой, точкой проникновения инфекции.
Физическая мобильность людей и вытекающая из нее коммерция строятся на фундаменте доверия и безопасности. Когда эти компоненты исчезают, двигатели экономики перестают работать, атрофируются и потихоньку исчезают. Точно так же и
наша жизнь онлайн строится на доверии и безопасности.
Переехав в США еще подростком в 2000 году, я звонил родителям, используя дорогие телефонные карты. Не только цена, но и сам процесс был кошмарным: набрать бесплатный телефонный номер, затем ввести длинный PIN-код и только потом получить соединение, потенциально ненадежное. Пополнить карту и купить
новую также было непросто.
Спустя два десятилетия связаться с родителями в Мумбае стало проще и дешевле.
Мессенджеры WhatsApp, Skype и Google Meet обеспечивают надежную, быструю и
недорогую связь на основе данных. Она вездесуща и персональна. Я могу видеть
родных, отправлять им информацию во время разговора и подключать к разговору
другие устройства. Легкость и доверительность общения основаны на фундаменте
безопасности, как и все остальные мои действия в Интернете: заказ продуктов, доставка еды, поиск попутчика, бронирование билетов. Онлайн-торговля опирается на
доверие и безопасность.
Если вы — инженер, чьи инструменты процветают благодаря обмену товарами,
идеями, деньгами и информацией в Интернете, значит, вы пользуетесь этим доверием и несете ответственность за его безопасное поддержание. Подобно тому, как
привычный образ жизни был поставлен на паузу вирусом, онлайн-коммерция также
уязвима к дефициту доверия, а защита конфиденциальности является одним из
компонентов доверия. Если ваши клиенты почувствуют, что их данные и личность
не находятся в безопасности под вашей опекой, они уйдут в другое место. Вот почему инженерам необходимо заботиться об обеспечении конфиденциальности.
Кроме того, существует вопрос вашей репутации и соблюдения правовых норм.
Недавно принятые законы предлагают регулирующим органам инструменты, позволяющие как никогда раньше анализировать ваши практики обеспечения конфиденциальности. Проверка может выявить прошлые решения, принятые на основе
совсем другого набора данных, но приводящие в нынешних обстоятельствах к неоптимальным результатам в этом плане.

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

51

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

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

Рис 1.7. Правительство начало издавать законы
и нормативные документы о защите конфиденциальности

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

Однако на рис. 1.7 упускается из виду тот факт, что, в отличие от налогового законодательства США, где действует сначала закон штата, а затем еще федеральный, у
разных правительств законы о конфиденциальности отличаются. Поэтому на
рис. 1.8 показаны две различные влиятельные юрисдикции в этой сфере. Например,
ЕС принял Общий регламент по защите данных (GDPR), который вступил в силу в

52

Часть I. Конфиденциальность, данные и ваш бизнес

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

Рис. 1.9. Цепочка событий, возникающая из-за того, что несколько правительств
издают собственные законы и нормативные акты

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

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

53

ходят с определенной регулярностью в течение последних нескольких лет. После
ряда подобных инцидентов СМИ и активисты по защите частной жизни начинают
обращать пристальное внимание на компании, слывущие нечестными игроками в
этом смысле. Такое внимание приводит к критическим статьям в прессе, что, в свою
очередь, становится причиной формирования негативного общественного мнения.
Для небольших компаний это может вылиться в испорченные отношения и потерю
бизнеса. Крупные компании получат пятно на репутации, которое не исчезнет даже
после кризиса. В любом случае, ожесточение общественного мнения и активность
прессы приводят к принятию подобных законов. Вот почему, независимо от размера вашей компании, очень важно заблаговременно предпринять шаги по устранению пробелов в защите конфиденциальности, чтобы они не превратились в пропасти.
Любой опытный эксперт по связям с общественностью скажет вам, что лучший
способ контролировать ущерб — управлять степенью причиненного вами ущерба.
Как технический руководитель со множеством различных обязанностей, спросите
себя: «Когда лучше оптимизировать работу по защите конфиденциальности и
управлению данными?» Лучше ли сделать это на начальных этапах работы компании, пока разрабатывается стратегия, будет ли это реакцией на первые проблемы с
обеспечением конфиденциальности, или это произойдет, когда компания окажется
в кризисе, а ее рост затормозится из-за недобросовестной практики защиты конфиденциальности?
Преимущество современных технических специалистов заключается в том, что они
начинают работу заранее. За прошедшие годы о конфиденциальности было получено множество данных, начиная от инцидентов, касающихся компаний и правительств, и заканчивая инструментами, которые разработаны поставщиками, занимающимися ее защитой. При таком изобилии ресурсов у сегодняшних руководителей есть возможность разработать свою стратегию защиты конфиденциальности,
позволяющую избежать неудач, от которых страдают компании.
Цель данной книги — помочь вам правильно выбрать время для создания инструментария защиты конфиденциальности. Я часто повторяю фразу одного из моих
наставников в Netflix: «Лучший момент для умного поступка — вчера; хороший
момент — сегодня».
Мы подробно обсудили, как конфиденциальность может повлиять на ваш бизнес.
Теперь давайте рассмотрим несколько вариантов решения проблем в этой области
и перейдем к автоматизации процессов и инструментов обеспечения конфиденциальности.

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

54

Часть I. Конфиденциальность, данные и ваш бизнес

больше денег в эту критически важную область. Я уже со счета сбился, сколько
инвесторов обращались ко мне за советом по поводу «липкости» продуктов (возможности привлекать и удерживать клиентов — прим. ред.), в которые они потенциально готовы инвестировать. Не меньшее число стартапов и начинающих
технологических компаний из сферы защиты конфиденциальности, которые находятся в поиске статусных соразработчиков, регулярно приходят ко мне за подтверждением работоспособности концепций и пилотных проектов.
Инженеры должны уметь рассматривать инструменты защиты конфиденциальности в трех аспектах:
 знать — знать, где обнаруживаются и размещаются конфиденциальные данные;
 сокращать — минимизировать контактную зону с помощью обфускации и уда-

ления;
 защищать — защита достигается путем введения контроля доступа.

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

Рис. 1.10. Схема принятия решения, разрабатывать средства защиты
конфиденциальности или покупать

1.6.1. Дилемма: разрабатывать или покупать
Дилемма «разрабатывать или покупать» — одна из важнейших для инженеров.
Ведь именно специалистам в итоге придется реализовывать любое выбранное решение, поэтому логично, что им нужно разбираться в вопросе. Инженеры и руко-

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

55

водители технических программ предпочитают сначала разрабатывать сами по нескольким причинам:
1. Собственные программные решения будут обладать преимуществом, поскольку
контекстуально и технически будут согласовываться с существующим технологическим стеком компании, и потенциально их будет легче интегрировать в распределенную архитектуру.
2. Инженеры, которым приходится самим сталкиваться с пробелами в защите конфиденциальности и неэффективностью инструментов, могут разрабатывать технические решения, более соответствующие их насущным потребностям.
3. Инженерам компании, возможно, будет легче строить модели машинного обучения на основе клиентской базы и данных, имеющих значение для бизнеса
компании, ведь они уже вникли в детали.
4. Инженеры часто встречают сопротивление со стороны финансовых руководителей, когда хотят купить инструменты сторонних производителей. Компании боятся, что инженеры запросят слишком много инструментов с дорогостоящими
лицензиями.
Я согласен с этими аргументами лишь отчасти. У собственных решений также есть
ограничения:
1. Как уже говорилось, инженеры часто работают изолированно, и редко (а то и
никогда) рассматривают технологический стек как единое целое или сквозную
линию данных. Скорее они склонны фокусироваться на фрагментах, значимых
для их продуктов. Именно этот приоритет глубины над широтой охвата не дает
им увидеть последствия для конфиденциальности и безопасности. Вот почему
рискованно поручать создание инструментария для защиты конфиденциальности с комплексным охватом одним и тем же специалистам. По моим наблюдениям, использованию таких инструментов мешает предвзятое отношение ко времени. То есть продукты направлены на решение самых актуальных недавних
проблем, но в них не применяется предиктивный анализ для предотвращения
будущих. Решение «разрабатывать самим» — это часто оптимизация с целью
«остановить кровотечение», а не «нарастить мышцы».
2. Инженеры часто меняют работу и команды, что может привести к проблемам с
обслуживанием. Средства для защиты конфиденциальности обычно должны
тщательно исследовать хранилища данных, конвейеры данных и API, и поддерживать высокие уровни масштабирования и доступности. Отсутствие постоянного «хозяина» может негативно сказаться на способности компании создавать
собственные инструменты защиты конфиденциальности и институциональную
память, необходимую для реализации ориентированного на данные подхода,
способного предотвратить и устранить проблемы защиты конфиденциальности.
3. Современные сервисы системы «бизнес-для-потребителя» (B2C) часто оптимизируют, повышая доступность в ущерб согласованности (у сервисов вроде
Twitter или TikTok нередко бывают ошибки на стороне сервера, которые пользователь, учитывая объем доступного контента, может никогда не заметить). Од-

56

Часть I. Конфиденциальность, данные и ваш бизнес

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

1.6.2. Инструменты защиты конфиденциальности от сторонних
разработчиков: они действительно работают и масштабируются?
Я уже долго работаю в сфере защиты конфиденциальности и хорошо знаю популярные и перспективные инструменты для ее обеспечения. Некоторые я применял
на разных этапах их разработки, а другие — оценивал. Хочу поделиться собственным непредвзятым впечатлением о том, какова их задача, ведь обилие средств для
защиты конфиденциальности привело к тому, что их стало трудно различать. Словосочетание «технология конфиденциальности» инженеры воспринимают почти
так же, как покупатели слово «органический» при описании продуктов питания.
Из-за слишком частого и неоправданного употребления оно потеряло свое значение.
Процесс выбора часто затруднен тем, что инженеры не обладают достаточно глубокими знаниями о конфиденциальности. Кроме того, эти инструменты должны
быть интегрированы с несколькими контактными точками — API, хранилищами
данных, конечными точками, системами управления ключами и т. д. А это процесс
дорогостоящий. Не менее дорогостоящи их извлечение и замена, поэтому важно
понимать возможности широко обсуждаемых решений сторонних производителей.

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

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

57

Компания BigID (https://bigid.com) имеет значительное преимущество, ведь они
одними из первых в мире занялись разработками в данной области, и поэтому их
продукция уже опробована и испытана в крупных облачных корпорациях. (Открою
секрет: я был частью команды, которая оценивала BigID в компании Nike в
2015 году.)
Компания BigID предлагает несколько ключевых возможностей:
1. Учет и каталогизация данных — как и в случае с IP-адресами в компании
Gamesbuster, инженерам нужны инструменты для обнаружения и индексирования данных в больших масштабах. BigID может помочь составить карту конфиденциальных и персональных данных, метаданных и документов с использованием шаблонов машинного обучения и информации о происхождении данных.
2. Кластерный анализ — на основе своего каталога данных BigID может наглядно
показать, в каких хранилищах находятся конфиденциальные данные, чтобы инструменты удаления можно было применить целенаправленно. Этот анализ также позволяет компании BigID соотнести данные с владельцами (для сокращения
следов «осиротевших» наборов данных), тем самым уменьшая общий риск.
3. Обработка данных — создав индексированный каталог ваших данных, BigID
попытается предложить возможность централизованного просмотра индекса
данных субъекта и доступ к нему через API. Это позволяет компании удалять
данные и экспортировать их по запросам пользователей, основанным на законах
наподобие CCPA.
4. Соотнесение с правовыми нормами — для таких видов деятельности, как передача данных через партнерские платформы и другие конечные точки, BigID
стремится соотнести ваши процессы защиты конфиденциальности опять же с
требованиями законов, например, GDPR, тем самым ускоряя выполнение требований аудита.
BigID — привлекательный продукт для компаний, которым требуется комплексное
решение по автоматизации защиты конфиденциальности, однако в нем отсутствуют критические возможности, которые есть у быстро развивающихся компаний:
 BigID работает в конце конвейера данных, после того как данные уже получены

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

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

граммы, позволяющие проверить удаление данных, совершенное третьими ли-

58

Часть I. Конфиденциальность, данные и ваш бизнес

цами, ограничены. Это критически важное ограничение, поскольку сомнительный обмен данными с третьими сторонами стал причиной множества проблем у
самых разных компаний. Проверка удаления данных третьими лицами имеет
решающее значение.
Я выяснил, что инженерам приходилось разрабатывать собственные инструменты
для обнаружения метаданных и управления удалением в хранилищах данных, таких как Hadoop, чтобы восполнить пробелы, образовавшиеся из-за недостатков
BigID и большого объема данных, собранных до начала использования. Также я
заметил, что штатные инженеры способны разработать инструменты обнаружения, работающие эффективнее, чем BigID, поскольку они лучше осведомлены о
том, как их коллеги собирали и использовали данные. По этой причине инструменты штатных инженеров применяются чаще, чем BigID. Я не критикую продукты компании BigID, но инженерам следует знать эти аспекты до того, как они
выберут инструмент.
OneTrust (www.onetrust.com) — это аналогичная комплексная платформа для защиты конфиденциальности данных, которая предлагает широкий спектр возможностей, начиная от шаблонов для автоматизации проверки конфиденциальности
(мы подробно поговорим об них далее), проведения оценки рисков поставщиков и
заканчивая средствами реагирования на инциденты, связанные со взломом данных
и запросы о соблюдении прав субъектов. Для выполнения других серьезных обязательств по защите конфиденциальности — таких, как запрос субъекта на доступ к
персональным данным (англ.: DSAR — Data Subject Access Request), о которых мы
также поговорим далее, — компания OneTrust предоставляет шаблоны для сбора
запросов, отслеживания хода выполнения и распределения их по внутренним ресурсам.
Платформа OneTrust очень полезна, если ваши операции с конфиденциальной информацией выполняет юридический отдел и/или группа по контролю соответствия
нормативно-правовым требованиям, состоящая из подрядчиков и инженеров, которые проводят операции вручную. Другими словами, OneTrust предоставляет интерфейс контрольного списка, чтобы вы не создавали индивидуальные процессы
или не пропустили шаги в рамках стандартного алгоритма.
Проще говоря, OneTrust — это автоматизация рабочего процесса, которую можно
использовать для создания повторяемой автоматизации, чтобы перепоручить работу по проверке конфиденциальности сотрудникам, не занятым разработкой критически важных для прибыли продуктов. Если ваша цель как инженера — не волноваться о конфиденциальности и переложить эту проблему на других, то OneTrust —
отличный инструмент.
На самом деле инженерам нужна комплексная ментальная модель для обеспечения
конфиденциальности и управления, в которой автоматизация внедрялась бы в данные, а не формировала процессы для решения вопросов конфиденциальности. Надеяться, что OneTrust сама по себе решит ваши проблемы с конфиденциальностью, — это как ждать, что пластырь вылечит опухоль мозга.

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

59

Специализированные решения для защиты конфиденциальности:
Privicera, Collibra, DataGrail, Informatica, SailPoint
Многие компании используют значительный объем данных для анализа потребителей и проведения рекламы, но при этом у них может быть своя культурная специфика и специфические риски конфиденциальности. Тогда, возможно, им нет смысла обзаводиться такими инструментами, как BigID.
Например, у инженеров или руководителей технических программ в медицинском
учреждении, скорее всего, больше ограничений в отношении сбора данных, чем у
сотрудников социальных сетей, ведь само назначение социальных медиа-платформ,
как правило, требует сбора огромного количества данных для построения поведенческих моделей. Для инженеров компаний в сфере здравоохранения обнаружение
данных не всегда является насущной проблемой, поскольку существуют защитные
механизмы, определяющие, кому и какие данные (и сколько) разрешено собирать.
Однако важнейшей задачей может быть управление доступом к конфиденциальной
медицинской информации о пациентах.
В этом случае более уместным будет специализированное решение, предоставляющее управление политикой контроля доступа и шифрование данных на уровне полей/столбцов. Это могут обеспечить инструменты вроде Privicera
(https://privacera.com/products/enterprise-grade-encryption), хотя у меня нет достаточного опыта работы с этим продуктом, чтобы поручиться, что он способен работать с большими объемами или множеством разновидностей данных.
Другой инструмент, ориентированный на управление доступом, — SailPoint
(www.sailpoint.com). Он оптимизирован для управления гранулированным доступом, идентификацией пользователей, сроком предоставления доступа, а также обеспечения соответствия нормативно-правовым требованиям. С помощью SailPoint можно не только управлять доступом, но и применять эти политики к данным в облаке
и к данным в целом на всем протяжении их жизненного цикла. Потенциал инструмента заключается в том, что он применяет к данным управление доступом на основе идентификации, а затем использует эту информацию для интеллектуальной
обработки данных. Это может охватывать использование сотрудниками компании
несанкционированных сервисов, качество данных и т. д., обеспечивая помимо защиты конфиденциальности коммерческие выгоды и преимущества в плане безопасности. Может ли SailPoint интегрироваться в экосистему и обеспечить эти преимущества в больших масштабах — еще не проверено.
Достоинство специализированных решений заключается в том, что вместо полного
набора средств для защиты конфиденциальности они предлагают инженерам и техническим руководителям компании оптимизировать эти решения, подогнав под
насущные потребности, и даже использовать их для понимания масштаба работы.
Получив достаточный опыт, ваши инженеры смогут создать внутренние инструменты и быстрее добиться нужного результата, а не тратить циклы впустую.
Кроме того, существуют решения, ориентированные исключительно на обнаружение данных. Платформа Collibra (www.collibra.com) предлагает возможность видеть все значимые данные в их бизнес-контексте путем отслеживания их. Анало-

60

Часть I. Конфиденциальность, данные и ваш бизнес

гичным образом инструменты вроде DataGrail (www.datagrail.io/platform) и
Informatica (www.informatica.com/products/data-catalog.html) предлагают возможность каталогизации данных, рассматривая при больших объемах данные в обратном потоке (англ.: upstream), а не в хранилищах.
Причина, по которой я подробно рассказал про готовые инструменты, заключается
в том, что инженерам и техническим руководителям мелких и крупных компаний
часто приходится принимать решения о закупках под давлением и с ограниченным
бюджетом. Им была бы полезна схема, как соотнести свои потребности с инструментами. Нужно не просто выбрать, «разрабатывать или покупать», но и суметь
объяснить ответственному за финансы начальнику, почему выбранный курс логичен.
Каждое решение — своего рода компромисс, и компании жизненно важно избегать
необратимых решений, когда при дорогостоящих вложениях не удается снизить
риск нарушения конфиденциальности.
Кроме того, инженеры и их коллеги в бухгалтерии (те, с кем должен быть согласован каждый запрос на покупку инструментов) часто по-разному понимают, в чем
отличия между этими инструментами. Причем, по моему опыту, графа расходов на
подобные цели обычно появляется в условиях кризиса, когда трудно трезво проанализировать, что именно решит проблему в данный момент. В итоге компании
приобретают неподходящие инструменты, а затем добавляют взломанные дополнения для своих отдельных команд. Нехватка дисциплины приводит к низким показателям и уроку, что защита конфиденциальности обходится слишком дорого, если
проблему не решать.
Инструменты — основополагающий аспект проектирования защиты конфиденциальности, и теперь, когда вы познакомились с предложениями в данной области,
можно обсуждать риски покупки готовых решений.

1.6.3. Риски при покупке сторонних инструментов
защиты конфиденциальности
Малым, средним и даже крупным компаниям конфиденциальность часто кажется
досадным обременением, работу с которым можно просто передать авторитетному
стороннему инструменту. Похожим образом мы рассуждаем, когда рассчитываем
налоги. Большинство предпочитает пользоваться программным обеспечением, а не
рассчитывать их вручную. У такого подхода есть два риска.
Сначала рассмотрим случай в июне 2021 года. В статье Алекса Херна в издании
The Guardian говорится, что массовое отключение Интернета, затронувшее, в том
числе, сайты «The Guardian», Amazon и Reddit, было вызвано сбоем в работе сети
доставки контента (англ.: CDN — Content Delivery Network), управляемой компанией под названием Fastly. В результате посетители множества сайтов получили
сообщения об ошибках. Отключение полностью вывело из строя некоторые вебстраницы, а также привело к сбою в работе отдельных разделов других сервисов,
например, серверов компании Twitter, на которых размещены эмодзи социальной
сети.

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

61

Компания Fastly, поставщик услуг облачных вычислений, управляет граничным
облаком, предназначенным для сокращения времени загрузки веб-сайтов, защиты
их от DDoS-атак и поддержки при всплесках трафика. Fastly является посредником
между большинством своих клиентов и их пользователями. Если на сервисе Fastly
произойдет катастрофический сбой, клиенты, возможно, совсем не смогут совершать какие-либо действия.
Если критически важное звено вашего технологического стека зависит от третьей
стороны, это означает, что отдельные точки отказа могут привести к перебоям в
работе.
Другой пример: в 2017 году из-за сбоя в компании Amazon Web Services некоторые
из крупнейших веб-сайтов мира несколько часов не работали по всему восточному
побережью США. Учитывая, какое пристальное внимание уделяется вопросам
обеспечения конфиденциальности, вы действительно считаете целесообразным передавать критически важные функции защиты данных компании стороннему инструменту?
Кроме того, технологические стеки и дорожные карты компаний разнообразны, и
маловероятно, что один готовый инструмент подойдет большинству из них.
Я подчеркиваю все это не для того, чтобы списать инструменты со счетов, а чтобы
доказать, что современные потребности в области защиты конфиденциальности
требуют участия инженеров компании — даже после обеспечения безопасной работы инструментов.

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

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

62

Часть I. Конфиденциальность, данные и ваш бизнес

Результатом становились рабочий продукт и усилия, затраченные для его создания.
Помню, для описания процесса мы использовали фразу «водопадная модель». Команда А что-нибудь создавала, передавала команде Б, которая спустя оговоренное
время передавала продукт команде С и так далее.
Во взаимоотношениях с клиентами также не было ничего захватывающего —
сплошная определенность. Запросы клиентов определяли мою техническую реализацию; поток идей был однонаправленным. Компании, работавшие лучше всех,
стали лидерами. Возникнув в начале рецессии интернет-компаний (так называемого
кризиса доткомов), они основное внимание уделяли эффективности, а не фантазиям.
А затем, после Великой рецессии 2008 года, казалось, что произошел сбой в иерархической структуре управления и институциональном доверии. Он затронул все
общество. Люди всех мастей почувствовали, что эксперты, которым они доверяли,
оказались притворщиками. С исчезновением рабочих мест и доходов исчезла также
идея, что у эксперта, находящегося на вершине пищевой цепочки, есть все ответы.
Из этой неустойчивой динамики возник новый тип технического специалиста. Инженеры, независимо от занимаемой должности, стали предпринимателями, сформировавшими понимание руководства «снизу вверх». В этом понимании разрозненные команды работали над созданием атмосферы, в которой три «Д» формировали бы новый взаимосвязанный процесс инноваций.
Первым «Д» были данные, которые должны побуждать к изменениям, измерять
результаты, а их анализ позволил бы сформировать продукты и опыт, которые приведут клиентов в восторг. А последующее привлечение клиентов будет способствовать росту доходов компаний.
Вторым «Д» была децентрализация, когда разные инженеры создавали продукты
на основе собственных идей, с помощью собственных инструментов и понимания.
С каждой итерацией инноваций они создавали быструю обратную связь и расширяли сферу деятельности. Процесс стал не нужен, а нужен прогресс. И отправка продукта, заслужившего доверие покупателей. В этом дарвиновском мире выжили
только сильнейшие.
Третье «Д» — демократизация, когда младшие инженеры и специалисты по анализу данных порой имеют большее влияние на процессы и лучше знакомы со спектром продуктов, чем высшее руководство. Раньше отдельные сотрудники должны
были повиноваться авторитету, теперь менеджерам приходится доказывать, что
они имеют право вмешаться.
Эти три «Д» позволили инженерам и менеджерам технических программ действовать более автономно и самостоятельно, чем когда-либо, чем даже во время расцвета высоких технологий в конце 1990-х годов. Однако это привело к ослаблению
полномочий, позволяющих контролировать, как инженеры принимают решения,
которыми обычно наделены централизованные команды, такие как ИТ. Поэтому
отделам кибербезопасности и защиты конфиденциальности стало гораздо труднее
добиваться согласованности и единообразия в работе компании. Как правило, ошибочно считается, что они скорее мешают бизнесу, чем помогают. Рис. 1.11 обобщает перечисленные проблемы. Я часто показывал эту диаграмму на встречах с руко-

Глава 1. Инженерия конфиденциальности: зачем нужна и как ее масштабировать

63

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

Рис. 1.11. Как техническое проектирование создает трудности
для проектирования защиты конфиденциальности

Изменение отношения к технологическому сектору, когда из героев-обогатителей
технические специалисты превращаются в собирателей данных, которых ругают
все, кому не лень — от Берни Сандерса до Стива Бэннона, вытекает из этих функциональных трансформаций их роли. Точнее, эта трансформация посеяла сомнения
в отношении того, как организации собирают и используют данные о клиентах. Я
вижу эти сомнения, когда друзья и родственники, не работающие в сфере технологий, задают мне вопросы типа: «На чем зарабатывает компания XYZ?» или «Откуда мне знать, что компанию ABC не взломают так же, как Equifax?», или даже «Неужели у всех сотрудников этих корпораций есть доступ к интимным подробностям
моей жизни и они могут на мне зарабатывать?». Часто обсуждаемый «техлэш» (негативная реакция на растущее влияние крупных технологических компаний) — это
выражение подобных вопросов.
В крупных компаниях руководители и управляющие, которые часто являются выходцами из отдела разработки продукции или финансового отдела компании, не
обладают техническими знаниями и лишены инстинкта защиты конфиденциальности. Небольшие компании, где бюджеты скуднее, маржа меньше, а сотрудников
совсем мало, сталкиваются с еще более сложной задачей в этой области. Руководителям технических отделов и архитекторам приходится выполнять одновременно
несколько функций, и потому им часто не хватает возможностей и полномочий для
проведения нужных кросс-функциональных изменений,. Дело в том, что большинство команд, создающих продукты компании, работают изолированно, сосредоточены на своих квартальных целях, а защита конфиденциальности для них — малозначимая проблема.
В большинстве компаний вопросы, связанные с обеспечением конфиденциальности, возникают после периода роста и часто после того, как вступили в силу необратимые решения. Именно для таких ситуаций написана данная книга.
Эта глава закладывает основу для размышлений о конфиденциальности и сопутствующих вопросах. Кроме того, теперь вы, наверное, лучше представляете себе, как
функционируют команды разработки продуктов в вашей компании с точки зрения
иерархии, как их разрозненные действия на основе дорожных карт помогают бизнесу расти, часто создавая при этом проблемы для защиты конфиденциальности.

64

Часть I. Конфиденциальность, данные и ваш бизнес

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

Резюме
 Конфиденциальность носит личный и контекстуальный характер, поэтому ин-

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

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

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

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

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

- ГЛАВА 2 -

Представление о данных
и конфиденциальности

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

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

66

Часть I. Конфиденциальность, данные и ваш бизнес

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

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

Рис. 2.1. Традиционная разработка программного обеспечения;
линейный путь

Как показано на рис. 2.1, миссия компании определяла дорожную карту ее продукции. Дорожная карта содержала конкретные требования к продуктам и функциям, а
команды инженеров выполняли это задание. Затем продукт выпускали в продажу.
Преимуществами этой модели были предсказуемость и повторяемость. К недостаткам относилось то, что, вложив много ресурсов и времени в создание продукта, затем приходилось ждать обратной связи в виде принятия или отклонения его рынком.
Позже в моей карьере инженера процесс разработки стал более инновационным,
нерегулируемым и непредсказуемым. На рис. 2.2 показана общая картина.
К началу 2010-х годов, с развитием таких тенденций, как разработка в методологиях Agile и Scrum, инновации в области технического проектирования также эволюционировали. Компании по-прежнему могли придерживаться модели «сверху
вниз», но наряду с этим команды и инженеры имели возможность экспериментировать с идеями и понемногу внедрять инновации.

Глава 2. Представление о данных и конфиденциальности

67

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

Рис 2.2. Современный динамический инновационный процесс;
непрерывный цикл обратной связи и новых итераций

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

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

68

Часть I. Конфиденциальность, данные и ваш бизнес

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

дете защищать данные клиентов.
 Право знать — компании должны предоставлять копии данных о клиентах по

запросу. Мы подробно разберем эту тему в главе 8, посвященной DSAR.
 Право на забвение — позволяет пользователям добиваться удаления своих дан-

ных. Мы подробно поговорим об этом в главе 7.
 Судебные расследования — компании должны контролировать, какие данные

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

пользователей, сотрудников и клиентов;
 авторизация, которая соотносит тех, кто запрашивает доступ к системе или дан-

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

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

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

Глава 2. Представление о данных и конфиденциальности

69

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

Рис. 2.4. Призмы, через которые различные заинтересованные стороны
рассматривают данные: аналитика, безопасность/конфиденциальность,
ИТ-системы и экономическая эффективность

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

70

Часть I. Конфиденциальность, данные и ваш бизнес

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

2.1.3. Конфиденциальность, системы данных
и соблюдение политики
Даже заручившись поддержкой всех заинтересованных сторон в компании, инженерам по защите конфиденциальности придется применять свои инструменты в
различных системах организации. На рис. 2.5 показано, какие они могут быть.
В предыдущей главе вы видели, как данные после получения могут распространиться по всей компании. На рис. 2.5 показан пример систем, в которых они могут
находиться. Эти системы различны:
 хранилища данных автономной аналитики, такие как Hadoop и Hive;
 оперативные данные, которые обслуживают транзакции в реальном времени и

находятся в структурированных и неструктурированных хранилищах данных;
 облачные хранилища данных, такие как S3 и GCP.

Рис. 2.5. Конфиденциальность и распространение данных

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

Глава 2. Представление о данных и конфиденциальности

71

 сохранение — сохранение данных только для конкретного использования —

например, шифрование данных по истечении срока с целью ограничения доступа к ним, когда он остается только у сотрудников юридического отдела;
 архивирование — перемещение данных в архивную систему на определенный

период или до конкретного события в будущем.
Инженерам по защите конфиденциальности, возможно, также придется управлять
доступом к данным — например, с помощью шифрования. Выполнение этой задачи состоит из нескольких ключевых этапов:
1. Определение необходимого уровня шифрования (на уровне приложения, «at
rest», то есть в состоянии покоя, или «in transit» — в пути). Это потребует согласования работы отделов аналитики, безопасности, хранения и платформы обработки.
2. Создание систем управления ключами (англ.: KMS — Key Management System)
для работы с ключами дешифровки, так чтобы доступ можно было предоставлять или отзывать автоматически в масштабе компании.
3. Настройка систем хранения, данных и рабочих нагрузок для получения ключей
из KMS и доступа к данным. Таким образом, инженеры по защите конфиденциальности информации смогут гарантировать, что технические средства контроля
соотносятся с системами и данными, а не с отдельными инженерами, и не вызваны их капризами.
4. Настройка бизнес-событий и событий жизненного цикла данных для выполнения алгоритмов шифрования и расшифровки соответствующих данных.
5. Создание закрытого журнала доступа с указанием действующего лица, цели и
возвращенных данных. В целях обнаружения нарушений безопасности и для
предоставления в случае аудита вам могут понадобиться журналы, показывающие, кто к каким данным обращался, соответствующий ключ расшифровки,
действия, совершенные с данными после получения доступа.
Идет ли речь об удалении или шифровании данных, технические средства контроля
должны быть интегрированы как алгоритмы в рабочий процесс компании. Это
очень важно, поскольку внедрение в больших масштабах возможно только при автоматизации и настройке алгоритмов. Следующие шаги показывают, как может
выглядеть рабочий процесс:
1. Настройка алгоритмов для идентификации применимых наборов данных, после
чего данные во всей компании можно будет идентифицировать на основе их
риска конфиденциальности.
2. Расширение инструментария платформы данных для подключения к событиям
жизненного цикла данных. Тогда алгоритмы можно будет применять к данным
по мере их движения по инфраструктуре.
3. Внедрение интеграции с хранилищами, данными, а также инструментами извлечения, преобразования и загрузки данных (англ.: ETL — Extract, Transform,
Load), для генерации событий жизненного цикла, так что в результате действие

72

Часть I. Конфиденциальность, данные и ваш бизнес

политик реализуется путем запуска и выполнения алгоритмов. Это очень важно,
поскольку по мере изменения состояний данных применяемые алгоритмы надо
будет адаптировать. Так, если в конечном итоге вы объедините данные, собранные у клиентов, с данными третьей стороны, возрастает риск того, что конкретных клиентов можно будет повторно идентифицировать и они могут пострадать
от нарушения конфиденциальности. Это, в свою очередь, может потребовать
введения более строгой политики защиты конфиденциальности. Для изменения
данных потребуется сгенерировать событие жизненного цикла, которое позволит применить соответствующие изменения в алгоритме.
4. Запуск выполнения алгоритмов для архивирования, удаления и/или шифрования
применимых данных. Это последний шаг для обеспечения возможности вовремя
применить к данным инструментарий защиты конфиденциальности.
Эти шаги будут зависеть от систем, в которых данные идентифицируются, классифицируются по степени риска (конфиденциальные данные шифруются) и маркируются (чтобы можно было применять алгоритм шифрования). Мы подробно рассмотрим вопросы классификации и маркировки данных в главах 3 и 4.
Учитывая, что большинство компаний начинают свою работу с ограниченным набором средств защиты конфиденциальности и неограниченным, на первый взгляд,
объемом данных, описанные шаги часто трудновыполнимы. Именно поэтому обеспечивать конфиденциальность информации нелегко, и мы порой получаем сценарий, в котором нововведения и скорость развития компании находятся в обратной
зависимости от нашей способности обеспечить конфиденциальность и безопасность клиентов. Поэтому крайне важно, чтобы инженеры по защите конфиденциальности информации автоматизировали как можно большее число процессов.
Данная книга поможет вам это сделать.
Однако в любом случае вам будут полезны примеры трудностей, с которыми сталкивались другие компании. Более структурированный подход, как уже подчеркивалось, поможет добиться одобрения руководства на создание инструментов защиты
конфиденциальности, а также их внедрение в процессы.
Чтобы понять, как эти общие стратегические направления соотносятся с операционными решениями и техническими деталями, давайте рассмотрим, как данные и
связанные с ними решения способны помочь, а затем навредить, компании, ее росту
и отношениям с клиентами.

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

Глава 2. Представление о данных и конфиденциальности

73

Доска. Заметки-стикеры. Диаграммы пользовательского потока. Концептуальные
путешествия. Все творческие силы были направлены на то, чтобы сделать вашу
платформу привлекательной. Она стала идеальным сочетанием великолепного дизайна, отвечающего интересам пользователей, и масштабирования с помощью облачных технологий. Предложение отвечало спросу благодаря повсеместному доступу к Интернету на рынках, которые никогда раньше не видели такого сочетания
клиентов и продуктов.
Всего 18 месяцев назад вы с коллегами-инженерами объединили усилия и разработали платформу взаимодействия, где единомышленники могли бы собираться вместе и играть в видеоигры. Вы предоставите первые видеоигры, а они привлекут
верных и воодушевленных поклонников. Социальные сети позволят вашим участникам хвастаться своими рекордами, особыми хитростями и техниками игры.
Через три месяца платформа была готова. У вас была вся классика видеоигр: Super
Mario, Double Dragon и многие другие. Игроки по всему миру могли входить в систему, используя свои учетные данные в социальных сетях, приглашать друзей (которые затем могли приглашать своих друзей), соревноваться с ними, делиться
своими результатами в Интернете и организовывать команды, которые могли бы
бросать друг другу вызов по круговой системе.
Это были бы концентрические круги социальной активности, в которых участвовали бы люди со всех уголков мира, играющие в любимые игры своей молодости. А
центром этих кругов стала бы ваша платформа.
Данные о ваших пользователях — что им понравилось, сколько игр они сыграли,
кого пригласили и другие сведения о вашей онлайн-аркаде — стали бы основой для
маркетинга и даже создания новых игр. Вы могли бы даже продать платформу
крупному производителю компьютерных игр или владельцу социальной сети.
Ваша модель роста выглядела бы как на графике на рис. 2.6: после первоначального
спада роста и доходов оба показателя резко возросли. Спад произошел в период,
когда вы создавали платформу, запускали первые игры и укрепляли безопасность
первой системы хранения данных. Как только появились пользователи, за ними последовали данные, и это позволило вам установить больше игр и привлечь больше
пользователей. С экономической и эстетической точек зрения все было в порядке.
В это же время ваши инженеры, аналитики данных и менеджеры по продуктам начали изучать возможности данных. Модели машинного обучения, построенные ими
с использованием собранных данных клиентов, предоставили им полезную информацию, позволившую привлечь еще больше клиентов. Ваши гении задумались: а
почему бы не собрать как можно больше данных, даже сверх необходимого? Их
всегда можно использовать позже, а если не понадобятся, то удалить.
Оказалось, что неиспользуемые данные сродни коробкам, с которыми после переезда никогда не удается разобраться до конца. Так и данные никогда не удалялись
полностью. Инженеры-новички видели, что более опытные коллеги бесцеремонно
собирают данные, и следовали их примеру. У каждого был доступ к любым данным, которые они хотели получить, потому что инновационная культура компании,

74

Часть I. Конфиденциальность, данные и ваш бизнес

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

Рис. 2.6. Модель роста в форме галочки

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

Глава 2. Представление о данных и конфиденциальности

75

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

Рис. 2.7. Как проблемы с конфиденциальностью приводят
к остановке роста и падению

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

внедрению инноваций.
 Эти инновации могут привести к ускорению процесса создания продукта и рос-

ту вовлеченности.

76

Часть I. Конфиденциальность, данные и ваш бизнес

 В децентрализованной и восходящей культуре эта тенденция нередко приводит

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

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

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

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

2.3. Данные, стратегия развития бизнеса
и конфиденциальность
Данные способны помогать компании и решать реальные проблемы. Этот раздел
покажет, что рассмотренные выше воображаемые сценарии и модели являются
предвестниками ущерба конфиденциальности данных и в реальном мире.
Пусть данные и не фигурируют в балансовом отчете в количественном выражении,
но они позволяют раскрывать суть и закономерности поведения и ожиданий существующих и потенциальных клиентов. Это может помочь вам развить бизнес и совершать инвестиции, вероятность успешности которых будет выше.
Платформы, отслеживающие перемещения мыши пользователя долгое время, могут первыми заметить симптомы болезни Паркинсона (http://mng.bz/drRg). Искусственный интеллект на основе данных может улучшить работу торговых площадок
и социальных сетей, обеспечить производство экологически чистой энергии, а также более эффективное управление поставками продовольствия и транспортными
системами. Данные могут помочь компаниям управлять доходами для увеличения
экономического благополучия и уменьшения количества увольнений, вызванных
нестабильностью.
Эти возможности требуют сбора значительных объемов данных в течение определенного времени для изучения закономерностей и построения моделей. Данные,
собираемые техническими специалистами вашей компании в реальном времени и
по частям, помогают моделировать человеческое поведение, а модели задают тон
для разработки проектов и дорожных карт продуктов. В этом заключается суть работы, выполняемой специалистами по обработке данных и аналитиками.

Глава 2. Представление о данных и конфиденциальности

77

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

Стратегия роста вашей онлайн-компании будет основана на нескольких точках
данных (Si Quan Ong, www.referralcandy.com/blog/ecommerce-metrics):
 трафике веб-сайта, указывающем, какой поток клиентов генерирует ваше при-

сутствие в Интернете;
 коэффициенте конверсии трафика, обозначающем, какая часть трафика конвер-

тируется в клиентов, продажи, возвраты и т. д.;
 коэффициенте конверсии при подписке на рассылку по электронной почте, со-

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

гие расходы, связанные с привлечением и удержанием клиентов;
 средней стоимости заказа, что не требует пояснений;
 так называемой «пожизненной ценности» клиента, указывающей, сколько дохо-

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

яльности клиентов или «липкости» продукта;
 коэффициенте отказа от покупок, указывающем процент клиентов, которые на-

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

78

Часть I. Конфиденциальность, данные и ваш бизнес

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

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

2.4.1. Equifax
Equifax — одно из трех крупнейших агентств по предоставлению информации о
потребительских кредитах в США — в сентябре 2017 года объявило, что его системы были взломаны, а конфиденциальные данные 148 миллионов американцев
скомпрометированы.
Украденные данные содержали имена, домашние адреса, номера телефонов, даты
рождения, номера карточек социального страхования и водительских прав. Кроме

Глава 2. Представление о данных и конфиденциальности

79

того, в результате взлома были похищены номера кредитных карт примерно
209 000 клиентов.
Важно понять, как произошло это нарушение (http://mng.bz/VBjN):
1. Сначала компанию взломали через веб-портал, посвященный жалобам потребителей. Злоумышленники воспользовались широко известной уязвимостью, которая должна была быть исправлена, но из-за сбоев во внутренних процессах компании Equifax ее не заметили.
2. Злоумышленники смогли перейти с веб-портала на другие серверы, потому что
системы не были адекватно сегментированы друг от друга. Они сумели найти
имена пользователей и пароли, хранящиеся в открытом тексте, что позволило
получить доступ к еще большему числу систем.
3. Злоумышленники месяцами извлекали данные из сети в зашифрованном виде,
оставаясь незамеченными, потому что компания Equifax не обновила сертификат шифрования на одном из своих внутренних инструментов безопасности.
В первом квартале 2019 года утечка информации стоила компании Equifax
690 миллионов долларов, потраченных на урегулирование выдвинутых групповых
исков, а также на потенциальные штрафы федеральных и государственных регулирующих органов.
Рейтинговое агентство Moody’s ухудшило прогноз по рейтингу Equifax, сославшись в качестве причины на кибербезопасность (и, как следствие, проблемы обеспечения конфиденциальности) (http://mng.bz/xXp7). Как объяснил представитель
Moody’s, это понижение рейтинга было значимо тем, что «в качестве фактора изменения прогноза впервые была названа кибербезопасность». Агентство Moody’s
также заявило, что затраты на наверстывание упущенного снизят прибыль компании Equifax.
Урок прост:
 если вы думаете, что программы обеспечения конфиденциальности и безопасно-

сти стоят дорого, то их игнорирование обойдется еще дороже;
 в вопросах защиты данных и доступа к ним важно правильно определить все

детали;
 подобно тому, как невозможно остановить звонящий колокол, отменить слу-

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

80

Часть I. Конфиденциальность, данные и ваш бизнес

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

2.4.2. Нарушение в работе Службы управления персоналом
В апреле 2015 года сотрудники из ИТ-отдела Службы управления персоналом
США (англ.: OPM — Office of Personnel Management), агентства, управляющего
гражданским персоналом правительства, обнаружили, что некоторые личные дела
сотрудников компании были взломаны. Среди украденных конфиденциальных
данных были миллионы форм SF-86, содержащих очень личные сведения, собранные в ходе проверок биографических данных сотрудников для предоставления им
доступа к секретной государственной информации, а также отпечатки пальцев
миллионов людей (http://mng.bz/ZxNN). После взлома OPM было начато расследование в Конгрессе, несколько руководителей OPM лишились своих должностей, но
в полной мере его последствия — для национальной безопасности и частной жизни
тех, чьи записи были опубликованы, — возможно, так и не будут осмыслены.
Следователи смогли составить приблизительную хронологию того, когда начались
утечки и как злоумышленники постепенно выполняли свой план (http://mng.bz/RqzR).
Считается, что первая утечка произошла в ноябре 2013 года, когда злоумышленники впервые взломали систему OPM. Этому злоумышленнику или группе в отчете
Конгресса о взломе в OPM присвоено имя X1. В тот раз X1 не удалось получить
доступ к документам персонала, но им удалось украсть технические инструкции, а
также информацию об архитектуре ИТ-систем. Через месяц, в декабре 2013 года,
злоумышленники попытались взломать системы двух подрядчиков — компаний
USIS и KeyPoint, проводивших проверку биографических данных госслужащих и
имевших доступ к серверам OPM (хотя USIS, возможно, взломали еще несколькими месяцами ранее).
В марте 2014 года в OPM поняли, что их взломали. Однако они не обнародовали
информацию о нарушении, и, посчитав, что злоумышленники имели доступ только
к части сети, в которой не было никаких данных о персонале, сотрудники решили
позволить преступникам продолжать взломы, чтобы иметь возможность следить за
ними и получить контрразведывательную информацию.
7 мая 2014-го злоумышленник или группа, получившие в отчете Конгресса о взломе в OPM название X2, использовали учетные данные, украденные у компании
KeyPoint, для создания еще одного входа в сеть OPM и установки там вредоносного
программного обеспечения (ПО), позволявшего создать лазейку (http://mng.bz/20Oo).

Глава 2. Представление о данных и конфиденциальности

81

Эту лазейку можно было использовать для незаконного проникновения в системы
без аутентификации. Брешь не обнаружили, и усилия OPM по лишению злоумышленников доступа или устранению лазейки были безрезультатны. В июле и августе
2014-го злоумышленники украли из систем OPM данные проверок биографии сотрудников.
К октябрю 2014-го злоумышленники с помощью среды OPM взломали сервер Министерства природных ресурсов и по делам коренных народов, где хранились личные дела сотрудников, а в декабре того же года украли еще 4,2 миллиона записей с
личными данными. Записи с отпечатками пальцев были украдены в конце марта
2015-го. Наконец, 15 апреля 2015 года сотрудники службы безопасности заметили
необычную активность в сетях OPM и быстро поняли, что злоумышленники все
еще находятся в их системах.
Уроки, которые можно извлечь из этого конкретного взлома:
 чем конфиденциальнее данные и чем больше их объем, тем больше поверхность

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

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

теме безопасности и сети. Как уже говорилось ранее, безопасность является необходимым условием для защиты конфиденциальности, и далее в этой главе я
расскажу, как методы обеспечения безопасности и персонал смогут сформировать ключевые элементы программы защиты.
Взлом в компании Equifax раскрыл данные о личности и финансовом положении
пользователей. Взлом в OPM раскрыл личные данные отдельных людей, а также их
должности в правительстве. Совместив данные из этих двух хранилищ, можно
идентифицировать людей, которые занимают руководящие должности в США и
при этом находятся в затруднительном финансовом положении (см. рис. 2.8). Попав не в те руки, эти сведения могут стать поводом для шантажа или подкупа, ставя
национальную безопасность США под угрозу.
Риски нарушения конфиденциальности и безопасности часто оказываются комплексными. Инженеры склонны считать, что конфиденциальность собираемых ими
данных не стоит особо защищать, ведь они не планируют совершать ничего неэтичного. Приведенный мной пример показывает, что накопленные риски конфиденциальности часто проявляются позднее, после серии инцидентов, связанных с
безопасностью.

82

Часть I. Конфиденциальность, данные и ваш бизнес

Рис. 2.8. Каким образом взломы агентства OPM и компании Equifax
наносят вред конфиденциальности и национальной безопасности

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

2.4.3. Компании LabCorp и Quest Diagnostics
Компания LabCorp, которая занимается проведением медицинских анализов, заявила, что в результате взлома были раскрыты персональные и финансовые данные
7,7 миллионов клиентов. Компания Quest Diagnostics пострадала от взлома, затронувшего 11,9 миллионов пациентов. Тот взлом позволил «неавторизованному пользователю» получить доступ к финансовой информации, номерам социального страхования и медицинским данным. Их связывает то, что взлом произошел в сторонней компании, занимавшейся обработкой платежей, которая обслуживала как
LabCorp, так и Quest.
Важные уроки, которые компания может вынести из этих взломов, таковы:
 даже если ваша компания все делает правильно, она все равно будет уязвима,

если один из ваших партнеров пострадает от утечки данных (http://mng.bz/10eQ);
 в будущем важность защиты данных из области здравоохранения будет только

расти;
 компания LabCorp утверждает, что хакеры не получили «результаты лаборатор-

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

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

Глава 2. Представление о данных и конфиденциальности

83

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

2.5. Конфиденциальность и нормативно-правовая база
В последние годы возрос интерес регулирующих органов к вопросам защиты конфиденциальности. Когда я начинал свою карьеру в этой области, большинству
компаний не нужно было переживать из-за многочисленных законов о конфиденциальности или иметь дело с полномочными регулирующими органами. В последние годы ситуация изменилась, а в недавно принятых постановлениях различных
юрисдикций прописаны обязательства для компаний, которые собирают данные
своих пользователей.
Я не адвокат, поэтому по вопросам применимости данных законов советую проконсультироваться со штатными юристами или с внешними специалистами. Однако я вкратце расскажу, как нормативные акты вроде «Общего регламента по защите
данных» (GDPR) изменили процесс взаимодействия компаний с клиентами. GDPR
предоставляет клиентам больше возможностей и средств контроля над своими данными и более подробно прописывает ответственность компаний за то, как они получают доступ, обрабатывают и хранят данные клиентов.
Приведу пример из личного опыта: как GDPR повлиял на работу компании, постоянным клиентом которой я был, и на услуги, которые она мне могла предложить.

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

84

Часть I. Конфиденциальность, данные и ваш бизнес

достаточно было только нажать на свое имя, и не нужно было помнить имя пользователя и пароль.
После приведения работы компании в соответствие с положениями GDPR на беговых дорожках перестало автоматически отображаться мое имя. Его вместе с паролем нужно было вводить. Мне сказали, что это сделано с целью защиты конфиденциальности. Многие мои друзья столкнулись с тем же.
Я так и не выяснил, почему отключили связь между беговой дорожкой и устройством регистрации пропусков. Возможно, юристы посчитали, что есть угроза нарушения конфиденциальности, или инженеры, подчищавшие данные в соответствии с
GDPR, внесли это изменение по техническим причинам. А может, виновато сразу
несколько причин. К тому же перед принятием GDPR царила такая неразбериха и
спешка, что защита конфиденциальности не всегда оказывалась главной причиной
вносимых компаниями изменений, с которыми столкнулись пользователи.
Как бы там ни было, но, чтобы не вводить каждый раз имя и пароль, некоторые посетители тренажерного зала стали пользоваться гостевым режимом. В результате
они не могли заниматься по персонализированным планам тренировок, созданным
специально для них и соответствующим их потребностям в снижении веса и развитии мышц. В гостевом режиме также нельзя было получить доступ к истории своих
тренировок — критически важному параметру оценки удовлетворенности занимающихся. Подобное изменение поведения тренирующихся означало, что фитнескомпания также не могла собрать о них никакие данные.
Теперь поставьте себя на место владельца тренажерного зала или производителя
оборудования для кардиотренировок. Вы предоставляете продукт, который помогает людям привести себя в форму. Кроме того, вы надеетесь стимулировать их вовлеченность и дальнейшее участие путем сбора данных, которые помогут вам эффективнее обучить своих клиентов, как им лучше работать над своей физической
формой. А затем сложный законодательный акт о защите конфиденциальности
данных воздвигает между вами и клиентами стену. В данном случае ни тренажерный зал, ни занимающиеся не потворствовали нарушениям конфиденциальности,
однако беспокойства по поводу защиты своих личных данных хватило, чтобы
GDPR стал реальностью и, в свою очередь, привел к результатам, выходящим за
рамки наказания виновных в нарушении конфиденциальности.
Здесь есть несколько ключевых уроков:
 несложно привести примеры компаний, которым сходят с рук нарушения в об-

ласти конфиденциальности;
 если компании, собирающие данные, не активизируют работу в области обеспе-

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

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

Глава 2. Представление о данных и конфиденциальности

85

 недобросовестные практики обеспечения конфиденциальности — проигрышная

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

2.5.2. Как ваша программа должна помочь подготовиться
к изменению законодательства о защите
конфиденциальности данных
Ниже показано, как можно создать процессы и инструменты для защиты конфиденциальности данных и повысить степень соответствия нормативным требованиям:
1. Организуйте режим управления доступом к данным без ненужной и контрпродуктивной бюрократии. Такая система свяжет доступ к данным с логичными потребностями и позволит установить контроль для предотвращения злоупотреблений.
2. Приведите процессы хранения и удаления данных в соответствие с оправданными потребностями бизнеса и обязательствами по защите конфиденциальности
частной жизни. То есть способы хранения данных в вашей компании должны
быть такими, чтобы не злоупотреблять доверием клиентов и не делать данные
уязвимыми для взлома или похищения.
3. Делитесь данными с внешними организациями только теми способами, которые
обеспечивают защиту конфиденциальности. Передавайте данные с помощью
защищенных инструментов — таких, как шифрование, а также агрегирование
и/или анонимизация, чтобы исключить возможность идентификации конкретных пользователей.
В следующих главах мы обсудим эти понятия гораздо более подробно.
Данная книга поможет вам разработать программу защиты конфиденциальности,
способствующую построению доверительных отношений с клиентами, в которых
правовые нормы станут основой, а не целью. Вы сможете с пониманием отнестись

86

Часть I. Конфиденциальность, данные и ваш бизнес

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

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

2.6.1. Превращение в полноправного американца
и конфиденциальность
6 мая 2013 года я принял присягу как гражданин США. Это была прекрасная церемония. Прожив в Америке почти тринадцать лет, я официально стал американцем.
Однако перед этим трогательным и знаменательным днем мне пришлось пройти
через процесс доскональной проверки, называемый натурализацией. Он требует
заполнения нескольких форм, предоставления множества данных обо мне, моей
семье и друзьях, сдачи отпечатков пальцев и прохождения собеседования под присягой, где задают самые разные вопросы. Во время этого процесса мне пришлось
предоставить очень личные сведения — финансовые, биографические, семейные. И
отказаться было нельзя.
Я был не в том положении, чтобы выяснять, почему для определения, имею ли я
право на получение гражданства, нужно так много информации. Например, моя
бабушка по материнской линии родилась в маленькой деревне в Индии и умерла
еще до того, как мои родители познакомились. Правительство потребовало ее свидетельство о рождении. Получить этот документ было непросто, поскольку в те
времена в деревне, где она родилась, свидетельства о рождении даже не выдавали.
На протяжении всего этого процесса я не имел ни малейшего представления о том,
каким образом будет использоваться вся информация обо мне, кто будет иметь к
ней доступ и на какой срок, кому она будет передана и как защищена. С тех пор
прошло много лет, а я до сих пор не знаю. Было бы хорошо, если бы правительство
объяснило мне, зачем им нужны все эти документы, часть из которых не имела ни
малейшего отношения к моему заявлению.
Я понимаю, что власти несут ответственность за защиту родины и не могут раскрывать слишком много подробностей, но все это действо напоминало изъятие
данных и подчеркивание власти... у правительства было то, что я хотел получить, а
мне нечего было ему противопоставить.

Глава 2. Представление о данных и конфиденциальности

87

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

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

Исследование, проведенное компанией SalesForce, показывает, насколько важно
укреплять это доверие. В нем представлены объяснения поведения клиентов, которое поначалу может показаться контринтуитивным (http://mng.bz/PXV8): клиенты
ценят персонализизацию, для которой вам необходимо собирать данные, но при
этом хотят, чтобы вы уважали их частную жизнь. Если клиенты вам доверяют, то
вероятность, что они будут лояльны к вашей компании, покупая у вас и рекомендуя
другим, возрастает. Особенно важным в исследовании является фрагмент об обмене информацией. Клиенты, начиная от бэби-бумеров и заканчивая миллениалами и
более юными поколениями, с большей вероятностью будут делиться положительными отзывами о вас, если они вам доверяют.
В исследовании также говорится, что способность и готовность клиентов доверять
компании зависят от того, насколько хорошо она защищает тайну их данных. Чувства клиентов понятны. Они хотят, чтобы вы предоставили им контроль, действовали прозрачно, не воспринимали их согласие как должное и относились к их данным с уважением.
Развивая деятельность по защите конфиденциальности, вы заметите, что многие
ожидания клиентов отражены в законах. Как и в случае с другими социальными
изменениями, такими как равенство супругов в браке или сотрудников в оплате
труда, это пример того, как законы отвечают на социальные ожидания. Вот почему,
когда речь заходит о технической реализации обеспечения конфиденциальности, я
считаю главной задачей сохранение доверия клиентов и ставлю ее даже выше соблюдения правовых норм.

88

Часть I. Конфиденциальность, данные и ваш бизнес

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

2.7. После создания инструментов наступает
самое сложное: разработка программы
Конфиденциальность для отдельных людей может быть очень личной и в то же
время очень контекстуальной. Следовательно, нередко ее трудно планировать, измерять и определять в общепринятой терминологии. Даже в тех случаях, когда обе
стороны (компании и клиенты) проявляют добрую волю и пытаются согласовать
свои действия, разработать стратегию бывает непросто. Книга поможет разобраться
в этой сложной области и разработать план игры, который можно будет корректировать, исходя из ваших потребностей и ситуации в организации.
По опыту скажу, что путь создания инструментов конфиденциальности и получения инвестиций включает в себя три поворотных момента:
1. Как только возникает необходимость в защите конфиденциальности, сразу же
происходит наплыв идей и ресурсов. На рис. 2.9 показан всплеск инвестиций в
защиту конфиденциальности. Это первый поворотный момент.
2. Как только угроза нарушения конфиденциальности отступает, начинается нехватка ресурсов. Инвестиции в обеспечение конфиденциальности теперь перенаправляются на разработку функций. На рис. 2.9 это показано как понижение
кривой. В итоге расходы на защиту конфиденциальности могут оказаться даже
ниже, чем вначале.
3. Затем в итоге оказывается, что вы топчетесь на месте, принимая ряд решений по
защите конфиденциальности, чтобы у компании не возникли неприятности с регулирующими органами. Расходы на защиту конфиденциальности возрастают,
но даже после восстановления они все равно не достигают пика. Это третий поворотный момент, когда компания принимает такой статус-кво как фактический
уровень рискоустойчивости.
При подобном сценарии программа защиты конфиденциальности находится в
центре внимания только в ситуациях неминуемого кризиса. В состоянии реактив-

Глава 2. Представление о данных и конфиденциальности

89

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

Рис. 2.9. Инвестиции в защиту конфиденциальности:
всплеск, спад и восстановление

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

90

Часть I. Конфиденциальность, данные и ваш бизнес

навыки по внедрению защиты конфиденциальности в работу с данными и процессы
функционирования компании, которые гарантируют, что конфиденциальность станет стратегическим сопровождением ваших деловых начинаний, а не сигналом пожарной тревоги, отвлекающим от создания дохода.
Клиенты были в таком же замешательстве. Многие из нас помнят, как получали
электронные письма практически от всех компаний, с которыми взаимодействовали, об изменениях, внесенных в соответствии с GDPR. Одни мои друзья не понимали, из-за чего столько шума, а другие были обеспокоены — как этот закон повлияет на их жизнь?
Учитывая огромный объем работы и перераспределение приоритетов, трудно оценить, было ли тогда больше согласованности и доверия между компаниями и их
клиентами. Далее мы рассмотрим более эффективные способы информирования
клиентов об инструментах и решениях в области защиты конфиденциальности,
чтобы им было понятнее, какую работу проводят компании в данном направлении.
Это, в свою очередь, способствует укреплению доверия, улучшению имиджа компании и, быть может, даже снижению давления регуляторов. Такое превентивное
информирование очень важно, поскольку компании должны принимать регулирование за основу, а не за потолок возможностей. Компании должны действовать
добросовестно, потому что это хорошо для их клиентов, и не вести себя так, будто
их вынудили к этому нормативные акты.
За время, прошедшее после вступления в силу GDPR, многие компании столкнулись и с другими проблемами защиты конфиденциальности данных. Для многих
начинаний в этом русле требуется перераспределение ресурсов, и другим видам
деятельности при этом уделяется меньше внимания. После того как кризис минует,
обычно устанавливается статус-кво, а ресурсы, выделяемые на конфиденциальность, резко сокращаются. В компании формируется стиль работы, при котором
программы по защите информации буксуют, а ресурсы заимствуются отдельно для
каждого случая — вместо того чтобы стратегически инвестировать в разработку
адаптирующейся программы. Такой подход сродни тому, чтобы ходить в продуктовый магазин, каждый раз беря с собой денег ровно на один обед или ужин.
Для достижения долгосрочного успеха компании и построения доверительных отношений с клиентами техническим руководителям следует создать базу сведений о
конфиденциальности, которая поможет им управлять событиями, и не позволять
событиям управлять собой. Хорошая новость в том, что другие сферы деятельности — например, обеспечение безопасности — прошли тот же процесс эволюции к
зрелости. Следовательно, уже есть прецедент, как можно улучшить практику защиты конфиденциальности.
Основная обязанность технических руководителей, совмещающих разные функции, — привести компанию к успеху. Данная книга поможет вам встроить защиту
конфиденциальности в стратегию успеха. Для этого необходимо:
 сформировать четкое понимание таких терминов, как конфиденциальность,

безопасность и соответствие нормативно-правовым требованиям;

Глава 2. Представление о данных и конфиденциальности

91

 осознать, насколько изменился процесс инженерных инноваций и какое проти-

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

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

Рис. 2.10. Опыт работы в сфере защиты конфиденциальности
и временны́е затраты обратно пропорциональны

92

Часть I. Конфиденциальность, данные и ваш бизнес

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

2.8. Разрабатывая программу,
сначала сформируйте корпоративную культуру,
ориентированную на конфиденциальность данных
Изначально эта книга рассчитана на две категории читателей: технических руководителей, с одной стороны, инженеров и руководителей кросс-функциональных программ — с другой. И в реальности руководители могут перемещаться из одной
группы в другую. Вот почему у книги большая аудитория и широкая сфера применения.
Технические руководители крупных компаний, использующих большие данные,
могут сами не писать код, но они должны осознавать, чем ради чего жертвуется и
каковы долгосрочные последствия технических решений.
Они должны взвешивать свои решения и учитывать их влияние на измеряемые цели дохода/роста в сравнении с менее осязаемыми целями укрепления доверия/бренда. Эти технические руководители — которые иногда могут занимать
должности директоров — как правило, работают на высоком уровне со стратегическим долгосрочным планированием. Принимая решения, они основываются на
опыте, интуиции и данных.
Для них защита конфиденциальности — это сбой и риск, поскольку она влияет на
способность поддерживать связь с клиентами, продавать им товары и удерживать
их. Конфиденциальность лежит в основе их работы с данными, обеспечения сохранности информации и интерпретации сложных нормативных актов.
Без концептуального и технического понимания рисков и средств контроля обеспечения конфиденциальности они подобны архитекторам, которые строят высокие
здания и, сами того не ведая, рискуют, работая без чертежей.
Моя книга поможет таким руководителям:
 создать культуру «обучения, тренировки и доверия», в рамках которой они смо-

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

Глава 2. Представление о данных и конфиденциальности

93

 осознать сложность внедрения инструментов защиты конфиденциальности в

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

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

пании;
 разработать элементы управления защитой конфиденциальности, такие как уда-

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

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

копий конфиденциальных данных в системах;
 ввести для данных, которыми необходимо поделиться, встроенные средства за-

щиты конфиденциальности, чтобы не навредить своим пользователям;

94

Часть I. Конфиденциальность, данные и ваш бизнес

 научиться измерять степень влияния на защиту конфиденциальности таких ме-

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

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

Компоненты

Начальный этап

 Реагирование на инциденты
 Технические недоработки и обнаружение данных
 Понимание риска несоблюдения правовых норм

Этап планирования

 Перечисление видов собираемых данных
 Классификация данных на основе риска
для конфиденциальности

 Согласование классификации данных с юридическим
и техническим отделами
Этап исполнения

 Каталогизация данных
 Обзор защиты конфиденциальности (перед выпуском)
 Удаление данных вручную

Этап зрелости

 Классификация и учет новых данных
 Автоматическое удаление
 Возможность экспорта и обмена данными
в соответствии с требованиями законодательства

 Возможность получения согласия пользователя
 Минимизация сбора данных путем создания общих
хранилищ данных

 Построение системы управления доступом
Этап готовности к аудиту

 Соотнесение средств контроля защиты конфиденциальности с такими законами, как GDPR и CCPA

 Соотнесение средств контроля защиты конфиденциальности с договорными обязательствами

Глава 2. Представление о данных и конфиденциальности

95

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

Резюме
 Современные инженерные процессы, стимулирующие нововведения, как прави-

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

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

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

регулирующими органами во многом пересекаются.
 Нормативно-правовая база в этой области постоянно расширяется, поэтому

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

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

- ЧАСТЬ II -

Упреждающая программа защиты
конфиденциальности:
управление данными
Эта часть поможет инженерам посмотреть на проектирование защиты конфиденциальности не как на серию инструментов и точечных решений, а как на платформу
для разумного управления. Учитывая взаимосвязи в экосистеме технологий, инженерам придется обеспечивать конфиденциальность данных во всем стеке. В этом
разделе они получат практические навыки встраивания средств защиты конфиденциальности в массив данных.
Глава 3 посвящена задаче классификации данных с участием сотрудников разных
отделов с целью определения степени риска конфиденциальности. Без классификации данных невозможно ни количественно оценить риск, ни начать применять автоматизированные средства контроля. Также предлагаются примеры, которые помогут инженерам развить необходимые для работы навыки и профессиональные
привычки.
В главе 4 мы углубимся в изучение учета данных, чтобы инженеры могли применить классификацию к данным, находящимся в их системах. Мы разработаем архитектуру системы, которая будет проводить учет и индексацию данных при помощи
сочетания ручных методов и машинного интеллекта.
Глава 5 позволит инженерам применять встроенные средства защиты конфиденциальности к данным, которыми они делятся с кем-либо. В ней читатели узнают о
методах анонимизации наборов данных и измерениях влияния на конфиденциальность. Так они смогут адаптировать обмен данными к уровню готовности компании
к риску, нормативным обязательствам и фактору доверия клиентов.

- ГЛАВА 3 -

Классификация данных

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

тивно-правовых требований;
 как классификация данных может работать кросс-функционально;
 сквозной процесс классификации данных.

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

универсально принятым идентификаторам (ID), таким как Google, Facebook
(Facebook принадлежит Meta Platforms Inc., признана экстремистской организацией на территории РФ) и другим идентификаторам устройств;
 способны влиять на поведение с помощью машинного обучения и искусствен-

ного интеллекта;
 обладают потенциалом для причинения часто непоправимого вреда при непра-

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

100

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

3.1. Классификация данных в контексте клиента
Нельзя содержательно обсуждать защиту конфиденциальности и не учитывать
техслэш — негативную реакцию на растущие силу и влияние крупных технологических компаний. Постепенно и неотвратимо за последние пару десятилетий технологический сектор превратился из жемчужины экономики в наглого родственника, которой приходит на обед с пустыми руками, но успевает съесть три блюда и
десерт еще до того, как все остальные попробуют первое.
Как я писал на LinkedIn в 2015 году, технологии изначально отличаются от традиционных секторов, таких как сельское хозяйство, инфраструктура и здравоохранение, в плане взаимоотношений между объемом производства и трудом. В тех секторах для последовательного превращения планов в продукты требуется много рабочих. Иначе обстоит дело с техническими профессиями, ведь одним из главных
достоинств технологии является использование автоматизации, позволяющей делать больше с меньшими затратами труда и меньшим количеством итераций
(http://mng.bz/v4j1).
Например, когда корпорация Facebook (ныне корпорация Meta Platforms Inc., признана экстремистской организацией на территории РФ) приобрела компанию
WhatsApp за 19 млрд. долларов, в WhatsApp работало всего 55 сотрудников
(http://mng.bz/4K0D). Эта покупка была выгодна для сотрудников WhatsApp, но
она не приносила прибыли или дохода никому, кроме этих 55 человек
(http://mng.bz/QqAR). Аналогичным образом, когда компания Yahoo купила
Tumblr, примерно 40 сотрудников заработали миллионы и около 178 сотрудников
заработали приблизительно по 300 тысяч долларов (http://mng.bz/voNm). Подобные примеры есть по всему миру.
Что касается мнения о технологическом секторе как генераторе рабочих мест, то
репутация не всегда соответствует действительности. Рекламируется, что технологии приносят огромное богатство; однако это богатство распределяется среди небольшой части общества. Есть жирная разделительная черта между теми, кто зарабатывает миллионы, и остальными «миньонами». Проще говоря, технологический
сектор может создавать богатство, не создавая большого количества рабочих мест,
и в результате среднестатистический сотрудник может не иметь никаких экономических выгод от технологического бума. Как мы увидели на примере недавней неудачной сделки компании WeWork: основатели покинули компанию со щедрыми
пакетами, а рядовые сотрудники не получили почти ничего.

Глава 3. Классификация данных

101

Источником этого богатства является способность технологического сектора оптимизировать повседневную жизнь с помощью данных. Титаны технологий позиционируют себя как новаторы, но это новаторство также часто вызывает социальные и
общественные сдвиги. Контекстуальный и культурный разрыв между экономикой
услуг и остальной экономикой, который мы наблюдали последние несколько лет,
отчасти объясняется этим явлением. То, что некоторые игроки в отрасли собирали
больше данных, чем им требовалось, обрабатывали их бесцеремоннее, чем следовало бы, и делились данными расточительнее, чем было уместно, лишь усугубляет
ситуацию.
Когда пользователи жалуются, что компании собирают слишком много информации, речь идет именно об этом неравновесии: они понимают, что для компании выгода от сбора пользовательских данных непропорционально больше, чем для пользователя. Компания может приводить аргументы, часто убедительные, что сбор
данных помогает создавать более качественные продукты для пользователей. Но
пользователи мало что получают взамен, даже если предоставляют компании дополнительные сведения. Персонаж Лео МакГарри из сериала «Западное крыло»
выразил мнение многих, когда высказывал свое разочарование в современном технологическом секторе, спрашивая, где лунные колонии, которые ему обещали.
Классификация данных — важный шаг, направленный на упорядочивание отношений между технологическим сектором и пользователями, которых в конечном итоге идентифицируют по их данным. Процесс и результат помогут компаниям взглянуть на набор данных с точки зрения пользователей, чьи данные они собирают.
Классификация данных может помочь компании избежать потенциальных проблем
с защитой конфиденциальности и продемонстрировать внешним заинтересованным
лицам, что компания не относится к пользователям как к товару. Также она позволит более эффективно работать с данными (или быстрее их удалять) в зависимости
от того, что предписывает их класс. Классификация не может решить глобальную
проблему экономического неравенства, однако она позволит компаниям, использующим большие данные, сформировать более человечное отношение к данным и
представленным через них пользователям.
В следующих разделах мы поговорим подробнее о том, зачем и каким образом
классифицировать данные, но главным инженерам следует рассматривать эту работу как элемент общих инвестиций в уважительное отношение к своим пользователям и укрепление доверия.

3.2. Зачем нужна классификация данных
По сути, классификация данных позволяет ответить на следующие вопросы по каждому типу собираемых или сохраняемых данных:
 Что это за данные с точки зрения объема и определения?
 Зачем нам их собирать?
 Что они сообщают нам о клиентах и нашем бизнесе?
 Что произойдет, если эти данные неправильно обработать?

102

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

рамках своей свободы действий;
 постоянное согласование использования данных в организации и требований к

ним в соответствии с законами о защите данных;
 способность адаптировать методы и инструменты защиты данных и предостав-

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

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

рования в США, ЕС и странах с развивающейся рыночной экономикой.
К этому следует добавить еще одну проблему: у большинства компаний отсутствует процесс управления сбором данных и определения степени риска, который представляют данные для безопасности и конфиденциальности. Автор книги «The
Privacy Engineer’s Manifesto» Мишель Финнеран Деннеди недавно заявил, что в балансовых отчетах современных компаний, ориентированных на потребителя, данные указываются и как актив, и как пассив.
Без надежного управления данными невозможно принимать обоснованные решения о том, какие из них хранить и как лучше защитить их от внешних атак и внутреннего нецелевого использования. Эксперты в данной области сходятся в том, что
классификация данных — это первый шаг на пути к зрелости компании в отношении защиты конфиденциальности.
В знаковом техническом документе корпорации Microsoft «Data classification for
cloud readiness» говорится, что классификация предоставляет организациям один из
самых простых способов определения относительных значений и присваивания их
имеющимся у компаний данным. Этот процесс позволяет организациям классифицировать хранящиеся данные по степени конфиденциальности и влияния на бизнес,
чтобы определить связанные с ними риски. В результате организации смогут
управлять своими данными в зависимости от их ценности, а не относиться ко всем
данным одинаково. Классификация данных — это осознанный, продуманный подход, позволяющий провести оптимизацию, которая была бы невозможна, если бы
всем данным присваивалось одинаковое значение (http://mng.bz/Xrv1).
Из документа следует, что высшему руководству крайне важно хорошо разбираться
в вопросах классификации данных. Это касается «консультантов, специалистов по

Глава 3. Классификация данных

103

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

(англ.: BDM — business decision makers), перед которыми поставлены критически важные бизнес-цели и заданы условия, требующие ИТ-поддержки»;
 «архитекторы и планировщики, отвечающие за управление архитектурой в сво-

их организациях»;
 «консультанты и партнерские организации, которым необходимы инструменты

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

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

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

104

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

Рис. 3.1. Пирамида потребностей Маслоу

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

Глава 3. Классификация данных

105

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

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

доступа к информации);
 объединения с данными, доступными в других местах, внутри компании или за

ее пределами;
 обмена данными с другим партнером.

Рис. 3.2. Образец классификации данных

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

106

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

альности, на рис. 3.2 это категория «Ограниченный доступ». Логично предположить, что это данные, которые могут идентифицировать ваших клиентов и их поведение, но они также могут включать и критически важные для бизнеса сведения.
Следующий уровень данных, который необходимо защитить, может содержать
сведения чуть менее секретные. В соответствии с этим следует корректировать и
стратегию по их использованию.
Используя рис. 3.2 как ориентир, важно понять, что организации не могут объявить
данные «Конфиденциальными» только потому, что меры по защите информации,
необходимые для уровня «Ограниченный доступ», слишком трудны.
Данные категории «Ограниченный доступ» обычно отвечают хотя бы нескольким
из следующих критериев:
 они однозначно идентифицируют конкретного человека. Это субъективный кри-

терий. Например, имя «Джон Смит» не может однозначно идентифицировать
человека, если не подкреплено другими данными, скажем, домашним адресом,
но «Нишант Бхаджария» предлагает гораздо более высокий уровень идентифицируемости;
 эти данные можно объединить с другими, легкодоступными, чтобы определить

конкретного человека, его деятельность или предпочтения;
 информация о человеке, доступная в этих данных, делает их уникальными. На-

пример, предположим, что компания 12080 Inc. управляет онлайн-аптекой и
хранит таблицу с данными о людях, принимающих лекарства для нормализации
артериального давления. Чтобы не указывать имена пользователей, в таблице
пользователям присвоены случайные ID. Такая таблица может быть безопасной
в плане конфиденциальности, если она содержит данные для всего Нью-Йорка,
учитывая большое количество жителей. Но если в такой таблице будут содержаться сведения о людях, проживающих в городке Битти, штат Орегон, она может представлять риск для конфиденциальности, поскольку население Битти
значительно меньше.
Проще говоря, данные категории «Ограниченный доступ», как правило, более персонализированы, в то время как данные категории «Конфиденциальные» могут
быть более обобщенными. Из-за сопутствующих последствий для конфиденциальности контроль получения доступа к данным категории «Ограниченный доступ»
должен быть более жестким, а сроки их хранения меньше. Данные категории
«Конфиденциальные» могут иметь более мягкие требования к доступу и более длительные сроки хранения.

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

Глава 3. Классификация данных

107

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

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

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

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

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

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

108

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

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

ется чем-то неизменным. При агрегировании данных и их сокрытии риск может
заметно снизиться, как вы увидите в главе 5.
 Так, пользовательские записи, в которых нет конкретных идентификаторов

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

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

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

Глава 3. Классификация данных

109

спроса, вы сможете планировать будущие заказы от производителей лекарств, чтобы быть уверенными, что будущие рецепты будут оперативно обслужены.
Информация, идентифицирующая личность пациентов и принимаемые ими лекарства, попадает в категорию «Ограниченный доступ». Согласно большинству законов, эта информация крайне чувствительная, и даже если не учитывать нормативный аспект — люди чрезвычайно бережно относятся к сведениям, касающимся их
здоровья. Логично, что данные в этой категории будут подчинены строгим правилам контроля доступа и ограниченного периода хранения.
Однако в данном случае у вас нет причин фокусироваться на отдельных пользователях, их здоровье или медицинской обстановке. Для вас актуальнее совокупность
данных о рецептах за период времени, чтобы можно было планировать будущее.
Значит, можно изменить схемы хранения данных. В двух таблицах ниже объясняется, как это сделать.
Табл. 3.1 представляет собой базу данных, в которой перечислены имена людей и
лекарства, которые они заказали в аптеке. Эта информация может однозначно
идентифицировать людей и, следовательно, попадает в категорию «Ограниченный
доступ».
Таблица 3.1. Список индивидуальных рецептов
Имя

Препарат

Дата

Джош Смит

Риталин

12/1/2019

Карен Джонс

Риталин

12/7/2019

Уна Блэр

Лозартан

12/8/2019

Викрам Кханна

Риталин

12/15/2019

Тони Браун

Лозартан

12/18/2019

Тереза Джонсон

Лозартан

12/22/2019

Для ваших целей может потребоваться хранить эти данные дольше, чем обычно
разрешено, или предоставить доступ к ним большему количеству людей. В
табл. 3.2 показана база данных, из которой убраны имена пациентов, но сохранены
действительно важные сведения — сколько раз в аптеке были куплены определенные лекарства. Можно обоснованно сделать вывод, что отсутствие персональной
информации в таблице позволяет классифицировать ее как «Конфиденциальную», а
значит, хранить дольше — например, для сравнения декабря 2019 года с декабрем
2018-го.
Таблица 3.2. Обобщенный список рецептов
Название препарата

Количество рецептов

Диапазон дат

Риталин

3

12/1/2019-12/31/2019

Лозартан

3

12/1/2019-12/31/2019

110

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

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

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

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

Глава 3. Классификация данных

111

Исследование компании Gartner (под названием «Guidance for Addressing Risks with
Unstructured Data») подтверждает это.
 У 25 % респондентов нет официальной программы.
 У почти 38 % программа есть, но, можно сказать, «в стадии наброска».
 Только у 37 % респондентов есть программа, функционирующая на регулярной

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

3.2.4. Неструктурированные данные и управление
Неструктурированными считаются данные, которые трудно сохранить в традиционной базе данных, состоящей из столбцов и строк, или электронной таблице (например, JSON-блобе). Один инженер как-то уверял меня, что в их базе данных
Cassandra нет конфиденциальных данных, а затем мы обнаружили, что во вложенных объектах JSON находились IP-адреса, по которым можно было идентифицировать некоторых пользователей. И хотя неструктурированным данным часто не уделяют должного внимания, их могут использовать не по назначению, поэтому ими
следует управлять так же аккуратно, как и структурированными (хранящимися в
традиционной базе данных, состоящей из столбцов и строк).
Структурированными, напротив, считаются данные, которые соответствуют заранее
определенной модели данных и нужны для прямого анализа (http://mng.bz/yJlo).
Структурированные данные представлены в формате таблицы с определенными
взаимосвязями между различными строками и столбцами — например, в базе данных SQL.
По данным журнала Forbes, объем неструктурированных данных, которые собирают и хранят компании, ежегодно увеличивается на 5565 % (http://mng.bz/yJlo).
Журнал TechRepublic пишет, что 80 % данных, обрабатываемых компаниями, —
неструктурированные (http://mng.bz/aZW9).
Из-за своей природы неструктурированные данные труднее поддаются анализу,
чем структурированные, также их сложно находить. Вот почему компании не считали их полезными до недавнего времени. Однако сегодня у нас есть инструменты
для анализа неструктурированных данных, работающие на основе технологии искусственного интеллекта (ИИ), созданные специально для доступа к имеющимся
сведениям из неструктурированных данных.
Компании должны знать, какие типы неструктурированных данных они накапливают и какие способы обработки и хранения таких данных самые эффективные.
Это особенно актуально потому, что неструктурированные данные затрудняют выполнение требований ряда законов о защите конфиденциальности.

112

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

В докладе компании Gartner также объясняется, почему в организациях, которые
испытывают трудности в управлении данными, неструктурированные данные становятся отдельной проблемой.
 Для 75 % респондентов представляло собой профессиональную трудность выяв-

ление мест, где хранятся неструктурированные данные.
 63 % респондентов испытывали трудности при удалении неструктурированных

данных по истечении срока хранения.
 У 37,5 % респондентов возникали трудности с получением поддержки со сторо-

ны руководства компании.
Немалая часть неструктурированных данных в итоге оказывается в журналах или
во вложенных JSON-блобах, где часто остаются похоронены. Несмотря на то, что
такие конфиденциальные данные, как IP, легко обнаружить с помощью инструментов вроде регулярных выражений, вы можете никогда не найти IP-адрес и, следовательно, не удалить его вовремя, если он запрятан глубоко в недрах неструктурированных данных. И хотя шаблоны регулярных выражений способны сопоставлять
неструктурированные данные, огромный объем собираемой информации может
привести к превышению времени работы алгоритмов еще до того, как эти данные
будут обнаружены и идентифицированы как чувствительные.
Помните: все эти проблемы реальны, но компании продолжают собирать все больше и больше данных, включая неструктурированные. Такие компании могут оказаться не в состоянии извлечь из них выгоду. Они хранят больше неструктурированных данных, чем необходимо, тем самым увеличивая расходы на центры обработки данных и повышая риски нарушения конфиденциальности и безопасности.
П РИМЕЧАНИЕ
Неструктурированные данные — пример того, как методы, способствующие инновациям, — высокая скорость и доступность — могут создавать риски для конфиденциальности. Природа данных расширяет возможности инженеров и аналитиков данных, но
усложняет жизнь специалистам по защите конфиденциальности.

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

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

Глава 3. Классификация данных

113

Что такое зрелость организации
Инженеры и технические руководители надеются, что их усилия помогут повысить
качество продукта, выпускаемого организацией, а затем — масштабировать организацию для более эффективного предоставления продукта, т.е. перейти на более
высокий уровень зрелости.
Организационная зрелость особенно важна для технических инициатив. Именно в
этой сфере полезны модель измерения зрелости компании и руководство по выведению ее на более высокий уровень этого параметра.
Согласно журналу TechTarget, «Модель технологической зрелости организации —
это методология, используемая для создания и совершенствования процессов разработки программного обеспечения в организации. Модель описывает пятиуровневый эволюционный путь процессов, становящихся все более организованными и
систематически более зрелыми».
В статье в TechTarget говорится, что «Модель технологической зрелости организации схожа со стандартом ISO 9001, одним из серии стандартов ISO 9000, установленных Международной организацией по стандартизации… Конкретно ISO 9001
касается разработки и сопровождения программного обеспечения».
Однако у этих двух систем есть и отличия: «Стандарт ISO 9001 устанавливает минимальный приемлемый уровень качества для процессов программного обеспечения, а модель технологической зрелости организации создает основу для постоянного совершенствования процессов и более четко, чем стандарт ISO, определяет
средства, которые необходимо использовать для достижения этой цели»
(https://searchsoftwarequality.techtarget.com/definition/Capability-Maturity-Model).
На рис. 3.4 показаны в общих чертах различные уровни технологического развития
и зрелости. Видно, что благодаря совершенствованию и доработке процессы разработки программного обеспечения меняются от непредсказуемых и плохо контролируемых до достаточно зрелых. На этапе формирования идеи разработки программного обеспечения, как правило, имеется очень мало средств контроля качества кода, документации, порядка разработки и т. д. Это помогает разработчикам быстро
выпускать первые версии с возможностью дальнейших итераций, а прогресс позволяет начинающим компаниям привлекать деньги. Однако по мере того как компании становятся зрелыми, жизненно важно разработать процессы, которые помогут
масштабировать техническую работу и повысить качество.
На ранних этапах разработки продукта также стоит собирать данные для составления дорожной карты и руководства ее выполнением. Однако при отсутствии контроля такой подход может привести к накоплению риска и возможному злоупотреблению доверием клиентов. В этом смысле классификация данных может помочь
компании достичь зрелости в способности защитить соответствующие данные, построить доверительные отношения с клиентами и, возможно, получить благосклонность инвесторов на рынках, где особенно ценится надежность организационных
процессов. Хорошая защита конфиденциальности — это хорошая политика.

114

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

Рис. 3.4. Модель технологической зрелости организации

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

док присвоения документам грифов «конфиденциально» или «секретно» уже де-

Глава 3. Классификация данных

115

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

классификацию, но компаниям, часто меняющим область деловой активности
(например, выходящим на новые рынки) и адаптирующимся к новым условиям
использования (например, поддержке новых пользовательских устройств),
нужна более детальная и гибкая классификация. Скажем, правительство может
определить, что в категорию «персональные сведения» относится все, что однозначно идентифицирует человека. Например, адрес электронной почты, а
также номер карты социального страхования. Однако компания, ориентированная на работу с большими данными, может создать две категории — например, «личные данные» и «социальные данные». В этом случае адрес электронной почты попадет в первую категорию, номер карты социального страхования — во вторую;
 чтобы процесс классификации данных не был разобщенным, как у многих ко-

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

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

116

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

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

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

Глава 3. Классификация данных

117

Модель разработки инструментов, обучения и доверия, как следует из названия,
включает в себя:
 инструменты (шифрование, многофакторную аутентификацию, интерфейс при-

кладного API для удаления данных и т. д.);
 обучение;
 формирование общей культуры доверия, в которой будет цениться конфиденци-

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

118

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

3.3.2. Классификация данных, управление доступом
и конфиденциальность: пример 1
В данном примере рассматривается проблема, с которой сталкивается большинство
компаний: как проверить, что пользователи, пытающиеся получить доступ к конфиденциальным данным, — те, за кого себя выдают? Решить ее помогают инструменты авторизации и аутентификации (также известные как authn и authz).
Для данных с невысоким уровнем конфиденциальности может быть достаточно
просто проверить личность пользователя — скажем, является ли он сотрудником
вашей компании. Это можно сделать с помощью аутентификации.
Авторизация — следующий шаг после аутентификации. По мере накопления конфиденциальных данных компаниям необходимо создавать мелкоструктурный режим управления доступом. Решение о предоставлении доступа к определенным
данным или их комбинациям, возможно, придется принимать в масштабе. Авторизация означает координацию управления доступом. Она может потребоваться при
автоматизированном взаимодействии между двумя или более сервисами, а также
при взаимодействии пользователя с сервисом. Например, инженер, поддерживающий работу конкретного сервиса, может быть авторизован для работы в промежуточной среде с синтетическими данными, но не в рабочей среде с реальными данными пользователей.
Суть авторизации — в определении политики доступа и обеспечении ее соблюдения в масштабе компании (http://mng.bz/g1Z8).
Рис. 3.5 объясняет, что аутентификация обеспечивает защиту конфиденциальности
в рамках всей системы, а авторизация обеспечивает ее на уровне отдельных слоев и
систем.
Из схемы видно, почему аутентификация и авторизация критически важны для
обеспечения конфиденциальности, ведь чем секретнее данные, тем сильнее желание не ограничиваться одной только аутентификацией. Однако инженерам, занимающимся вопросами защиты конфиденциальности, необходимо понимать, что с
помощью классификации данных эти инструменты можно будет применять стратегически.

Глава 3. Классификация данных

119

Рис. 3.5. Аутентификация и авторизация

Все больше компаний переходят на модель системных операций (DevOps), которая
существенно изменила цифровой бизнес. Термином DevOps теперь обозначают
компании, которые автоматизируют развертывание кода, а также энергично развивают свои возможности и хранят данные в облачных средах. В частности, наблюдается тенденция отказа от локальных ИТ-систем в пользу облачного будущего. Это
упрощает хранение данных, и, как следствие, компании собирают еще больше информации.
Кроме того, в модели DevOps инфраструктура обеспечивается кодом, а не только
аппаратными средствами. Это изменение позволяет операционным командам конфигурировать машины как код.
Этим машинам нужен доступ и привилегии, чтобы выполнять действия, на которые
они запрограммированы, а службам безопасности становится все труднее отслеживать, у кого или у чего есть доступ. Особенно в тех случаях, когда машин с доступом оказывается больше, чем людей. Посмотрим, как классификация данных способна помочь защитить данные в такой динамичной среде.
При наличии системы классификации данных можно развить гибридную стратегию, к примеру, такую:
 реализовать ролевое управление доступом (англ.: RBAC — Role-Based Access
Controls) для управления разрешениями уровней пользователь-система и система-система (http://mng.bz/5Z97);
 хранить ключи критического доступа вне кода, вне жестких дисков и хранилищ
кода вроде GitHub и GitLab;
 создавать аудиторские отчеты, чтобы показать, что процессы доступа и авторизации соответствуют нормативным требованиям;
 управлять простыми и/или секретными SSH-ключами в масштабе динамических
систем;
 добиться возможности обзора всего набора используемых облачных систем и
выяснить, кто имеет к ним доступ.
Все эти пункты чрезвычайно важны и подходят для чувствительных данных, но не
для всех данных и систем.
Разумный и практичный подход заключается в применении авторизации для данных с высоким уровнем конфиденциальности, в то время как для других данных

120

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

3.3.3. Классификация данных, управление доступом
и конфиденциальность: пример 2
Как вы, наверное, уже поняли, продуманная схема классификации данных позволяет защитить их путем управления доступом. В предыдущем примере рассматривалась стратегия, которая управляет доступом к данным, разделяя его уровни на основе аутентификации и авторизации. При таком подходе решения здесь принимаются на уровне системы. Система решает, кто может войти (аутентификация) и к
чему они могут получить доступ (авторизация).
Как вариант, с помощью классификации данных можно связать принятие решения
о контроле доступа с данными. Например, если данные классифицируются как
имеющие высший уровень конфиденциальности, можно установить жесткие требования к способам их передачи между системами или хранения в системах, принадлежащих компании. Предположим, что в списке от класса 1 к классу n уровень
конфиденциальности данных снижается (класс 1 содержит наиболее засекреченные
данные с, пожалуй, самыми строгими требованиями защиты). Требования могут
выглядеть следующим образом:
 элементы управления доступом сверх традиционной комбинации «имя пользо-

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

передаче;
 сквозное транзитное шифрование на уровне служб с взаимным протоколом TLS

там, где это технически возможно. В тех случаях, когда взаимный протокол TLS
нецелесообразен, можно обязать инженеров использовать обычный протокол
SSL/TLS, поскольку использование незашифрованного протокола HTTP недопустимо;
 если информация хранится в общедоступном облаке, то данные класса 1 должны

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

Глава 3. Классификация данных

121

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

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

3.4.1. Классификация данных как выделение главного
в законах о конфиденциальности
Я уже говорил, что я не адвокат, и потому моя интерпретация законов о защите
конфиденциальности в своей основе — результат общения с экспертами в области
права, и ее не стоит воспринимать как юридический совет. За разъяснением применимых законов и определением средств правовой защиты вам стоит обратиться к
штатным и внешним юристам.
Ранее мы уже рассмотрели быстро меняющийся правовой ландшафт, связанный с
защитой конфиденциальности, и выяснили, почему инженерам крайне важны базовые знания в этой области. Однако всякий раз, когда в разных уголках мира одновременно издаются несколько нормативных актов, могут возникнуть непредвиденные сложности в том, как они применяются в отношении способности компании
обрабатывать данные пользователя и ее обязательств по закону.
В контексте обеспечения конфиденциальности ключевым понятием являются персональные данные или информация, идентифицирующая личность (англ.: PII —
Personally Identifiable Information), но определения варьируются и могут быть нечеткими. Тем, кто пытается управлять данными пользователей, бывает непросто

122

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

правильно понять текст определения. В США или в юрисдикциях за рубежом, принявших всеобъемлющее законодательство в области защиты конфиденциальности
данных, не выработан универсальный подход к персональным данным. Национальный институт стандартов и технологии определяет PII как «информацию, которая
может быть использована для распознавания или отслеживания личности человека» (https://csrc.nist.gov/glossary/term/PII). Это определение требует в каждом
конкретном случае индивидуальной оценки риска идентификации конкретного лица.
Закон Калифорнии о защите персональных данных потребителей дает гораздо более широкое определение «личной информации». К ней относятся:
 IP-адреса;
 коммерческая информация, например, учет личного имущества, учитываемая

продукция и т. д.;
 биометрическая информация;
 история просмотра в сети Интернет и поиска;
 данные геолокации;
 аудио-, электронная, визуальная, тепловая и обонятельная информация.

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

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

Глава 3. Классификация данных

123

затруднить обеспечение безопасности. Это становится все заметнее по мере расширения свода законов о конфиденциальности.
Например, протокол WHOIS размещает идентификационную и контактную информацию конечных пользователей в открытом доступе, а данные протокола WHOIS —
нужный инструмент для обеспечения безопасности, предотвращения мошенничества, а также отслеживания злоумышленников в Интернете. Широкая сфера применения GDPR может затруднить администрирование этого очень важного инструмента.
Переносимость данных, обеспечения которой требует ряд законов о конфиденциальности, создает дополнительные проблемы. Расширенные индивидуальные права,
предоставляемые физическим лицам в предложениях о защите конфиденциальности, включают возможность доступа, исправления, передачи или удаления информации о них. Калифорнийский CCPA требует, чтобы предприятия предоставляли
информацию в удобном для использования формате, позволяющем клиентам передать данные другой организации. А европейский GDPR устанавливает право физических лиц на удаление персональных данных. Право на удаление также известно
как «право быть забытым».
Другой вопрос, связанный с правами доступа и переносимости, — как безопасно
передать данные клиентам. Как объясняют защитники конфиденциальности, например, некоммерческая правозащитная организация Electronic Frontier Foundation,
«переносимые данные могут содержать чрезвычайно конфиденциальную информацию… и компаниям необходимо четко представлять потенциальные риски до того,
как пользователи перенесут свои данные в другой сервис» (http://mng.bz/6mWR).
Риски включают кражу или раскрытие данных, объединенных для совместного использования, или передачу их не тому человеку.
Помимо описанных проблем существуют и другие затруднения, которые следует
учитывать:
 удаление данных также может повлиять на качество и широту базовых наборов

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

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

124

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

Дальновидные компании поступят правильно, если классифицируют данные на
ранней стадии, ориентируясь на существующие правовые рамки как минимальную
цель и на доверие клиентов как максимальную.

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

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

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

Глава 3. Классификация данных

125

строить маршрут между ними. На стороне сервера у вас будет база данных — возможно, похожая на табл. 3.3.
Таблица 3.3. База данных на стороне сервера для приложения Directions
Имя

Адрес электронной
почты

Адрес начала
поездки (шир/долг)

Адрес окончания
поездки (шир/долг)

Джош Смит

jsmith@gmail.com

Карен Джонс

kjones@live.com

5 знаков после
запятой

5 знаков после
запятой

Уна Блэр

oblair@msn.com

Викрам Кханна

vik@yahoo.com

Тони Браун

tony@tonybrown.co

Тереза Джонсон

tjo@yahoo.com

Юристы будут утверждать, что каждая строка этой таблицы однозначно идентифицирует человека, и приведут две причины:
1. Адреса электронной почты пользователей приложения уникальным образом связаны с конкретными людьми. Электронную почту можно связать с другими данными о пользователях в Интернете и получить подробный профиль пользователя. Учитывая потенциал таких данных, это значительно усугубляет последствия
нарушения конфиденциальности данных или неправомерного использования.
2. Адреса начала и окончания поездки — очень точные. Чем больше знаков в адресе после запятой при определении местоположения по GPS, тем точнее местоположение.
Юристы посчитают, что каждую запись (каждую строку в таблице) нужно отнести
к категории «Ограниченный доступ» и жестко контролировать, кто может получить
к ним доступ, а также потребовать, чтобы срок их хранения был коротким.
Специалисты по обработке и анализу данных могут возразить, поскольку их возможность анализировать поездки, собирать данные для рекламы, обновлять карты
на основе того, по каким улицам ездят пользователи и т. д., — в значительной степени зависит от сбора данных в течение определенного времени и отслеживания
возникающих закономерностей. Они могут привести доводы, что базу данных и
содержащиеся в ней данные нужно классифицировать таким образом, чтобы их
можно было хранить дольше и с меньшими ограничениями.
Я бывал на многих совещаниях, где юристы считали, что инженеры и специалисты
по обработке данных слишком небрежно относятся к защите конфиденциальности.
При этом инженеры и аналитики обвиняли юристов в непримиримости и непонимании того, как в этой сфере деятельности обычно получают доступ к данным. Я
называю это аргументом «конкуренты уже так делают».
Инженеры могут предложить решение, похожее на представленное в табл. 3.4, где
поля, которые позволяют однозначно идентифицировать человека — его имя и
электронная почта, — будут скрыты с помощью техники хеширования. Стоит от-

126

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

Адрес
электронной почты

Адрес начала поездки
(шир/долг)

Адрес окончания
поездки (шир/долг)

(хешировано)

(хеширован)

3 знака после запятой

3 знака после запятой

Чтобы обозначить местоположение с меньшей точностью, команда инженеров может уменьшить количество знаков после запятой в координатах GPS, сохраненных
для анализа. Ограничение точности, вероятно, приведет к тому, что начальный и
конечный адреса будут охватывать гораздо большую географическую территорию.
Так снизится вероятность, что конкретный адрес будет однозначно указывать на
местоположение определенного дома или офиса.
В сумме изменения могут способствовать тому, что данные в целом станут менее
чувствительными, а записи базы данных, показанные в табл. 3.4, попадут в категорию «Конфиденциальных», а не «Ограниченного доступа»
Остается открытым вопрос: а если в каких-то случаях потребуются точные адреса и
личные данные? Например,
 службе безопасности может понадобиться доступ к подробной информации о

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

плату будет доступна вся история поездок пользователя.
Тогда можно сохранить обе версии данных, хотя и с оговорками:
 табл. 3.3 будет доступна узкому кругу инженеров и иметь контроль доступа так,

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

доступа и сроков хранения информации.
П РИМЕЧАНИЕ
В предыдущем примере инженеры показаны менее консервативными в вопросах защиты конфиденциальности, но в стартапах с действительно восходящей культурой
инженеры могут взять на себя роль «сознания потребителя» в обеспечении конфиденциальности, в то время как адвокаты могут довольствоваться подходом «соблюдение требований — прежде всего». Надежная стратегия управления данными обеспечит гибкость, позволяющую учитывать человеческий фактор, неизменно присущий
такому контекстуальному и личностному понятию, как конфиденциальность.

Глава 3. Классификация данных

127

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

3.5.2. Оформление и переработка классификации данных
На этапе 2 я бы разработал первоначальную систему классификации, основанную
на мнении юристов относительно нормативных документов и на консультациях с
другими заинтересованными сторонами.
Именно здесь инженеры, как опытные, так и начинающие, должны взять на себя
руководство в вопросах защиты конфиденциальности, чтобы гарантировать принятие осознанного решения о том, как определить уровни риска и сопоставить с ними
различные компоненты данных. На этом этапе у многих компаний получается либо
недоработанная схема классификации данных, пригодная лишь для экстренных ситуаций, либо несколько различных версий классификации данных, разработанных
специально для разных отделов, географических регионов и т. д.
Любой из этих вариантов может отлично работать в краткосрочной перспективе,
однако в быстро развивающихся компаниях часто выясняется, что выигрывает подход «срочное приоритетней важного». В этом случае компания решает использовать недоработанную классификацию, обязуясь доработать ее, но так никогда и не
заканчивает. В то же время многочисленные команды инженеров и специалистов
по обработке данных в конечном итоге иногда принимают необратимые решения,
тем самым закрепляя имещуюся классификацию данных.
Чтобы этого избежать, я как руководитель отдела защиты конфиденциальности работаю с коллегами по техническим и юридическим вопросам над созданием классификации данных с полугодовым интервалом. Мы публикуем нашу классификацию, V1, например, как официальный документ, и одновременно открываем копию
того же документа в черновике для сбора комментариев. Это, по сути, третий этап.
На этапе 3 цели заключаются в следующем:
 определить заинтересованные стороны, которые могли не участвовать в этапах 1

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

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

128

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

3.5.3. Процесс классификации данных: шаблон Microsoft
Описанный выше процесс из трех этапов — наиболее эффективное и итеративное
воплощение классификации данных из внедренных мной в компаниях разной величины. Однако справедливо будет показать и альтернативные варианты, особенно
применяемые компаниями, которые я считаю заслуживающими доверия.
Microsoft разработала модель, которую, на мой взгляд, можно эффективно воспроизводить в крупных и разветвленных компаниях. А также в небольших, где может
не быть должности, связанной с обеспечением конфиденциальности данных.
В своем техническом документе «Data classification for cloud readiness»
(http://mng.bz/o8XD) компания Microsoft представила модель «Планируй, делай,
проверяй, действуй» (см. рис. 3.6):
1. Планируй — определите ключевого сотрудника главной команды по защите конфиденциальности, роль которого будет заключаться в идентификации систем
данных, точек сбора данных, систем, по которым движутся данные (например,
Kafka Pipelines), систем, в которых данные хранятся (неструктурированные базы
данных, такие как Cassandra, и структурированные, например, MySQL), различных команд, использующих данные, и т. д. Этот сотрудник, взаимодействуя с
коллегами из других отделов, которых я перечислил выше, создаст профиль
данных, которые помогают компании работать.
2. Делай — после согласования политики классификации данных этот сотрудник
будет руководить развертыванием классификации данных, которая может включать документы по управлению, средства управления системой и т. д.
3. Проверяй — просто классифицировать данные недостаточно; необходимо убедиться, что средства контроля конфиденциальности в компании, а также продукты, к которым эти средства применяются, отражают классификацию данных.

Глава 3. Классификация данных

129

Это очень важно, поскольку цель классификации данных — гарантировать, что
данные будут обрабатываться по-разному, особенно с точки зрения конфиденциальности.
4. Действуй — классификацию данных не делают «раз и навсегда». Компании разрастаются и сокращаются, законы постоянно меняются, активисты и СМИ задают вопросы, а инженерный отдел и отдел производства творчески подходят к
стратегиям сбора данных. По сути, команде, занимающейся защитой конфиденциальности, постоянно придется классифицировать и переклассифицировать
данные, адаптируя соответствующим образом методы управления доступом.
На рис. 3.6 объясняется итеративный характер классификации данных, который
отражает типичное течение данного процесса.

Рис. 3.6. Модель классификации данных

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

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

130

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

Примеры

Идентификационные
данные

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

Конфиденциальные
данные

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

Платежные данные

Номер кредитной карты (со сроком действия или без него),
банковский счет и код, информация сторонних платежных
сервисов (например, Venmo, PayPal)

Демографические
данные

Раса, этническая принадлежность, религия, сексуальная
ориентация/идентичность, политические взгляды или членство
в профсоюзе

История транзакций

Запрошенные услуги, оказанные услуги, дата и время оказания
услуг, сумма оплаты и валюта

Данные для аутентификации и авторизации

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

Посмотрим, как может выглядеть первый этап в описанном выше процессе классификации данных для этой компании (фаза «Планируй» по терминологии компании
Microsoft).
Если смотреть с чисто юридической точки зрения с учетом рисков, то можно привести аргументы в поддержку модели блокировки. Данные конкретного заказа клиента будут храниться:
 только до тех пор, пока заказ находится в процессе выполнения;
 и доступ к этим данным смогут получить только отделы, отвечающие за выпол-

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

Глава 3. Классификация данных

131

Отделу маркетинга, наоборот, может понадобиться провести анализ покупок:
 Каковы модели покупательского поведения в зависимости от демографических

характеристик и местоположения?
 Какие товары покупают регулярно, а какие — сезонно?
 Каково соотношение покупок, совершенных в приложении, по сравнению с со-

вершенными через сайт?
 Как определить модели поведения покупателей на основе разных уровней дохода?
 Как изучить данные по отдельности и в совокупности с целью повышения каче-

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

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

дами хранения и более свободным доступом, но содержащую обобщенные данные большого числа пользователей.
Большинство опытных руководителей согласятся, что для стратегических инвестиций в бизнес вовсе не обязательно изучать потребительские привычки конкретных
клиентов. Помимо того, что это ненормально с точки зрения защиты конфиденциальности, вы, скорее всего, примете неверные бизнес-решения.
Разделяя и обобщая данные, можно хранить персонализированные данные отдельно от обобщенных и использовать каждый вид должным образом. Хороший бизнес
и хорошая конфиденциальность идут рука об руку. Помните об этом, когда в следующий раз кто-то скажет вам, что конфиденциальность — это помеха.
Как же выглядит классификация данных в этом новом смелом мире?
К разделу «Ограниченный доступ» можно перечислить персонализированные данные, позволяющие идентифицировать конкретного пользователя:
 имя;
 дату рождения;
 адрес;
 электронную почту;
 номер телефона;

132

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

 IP-адрес и информацию об устройстве;
 платежную информацию.

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

Таким образом, описанный выше анализ можно будет провести, не привязывая ни
одну из покупок к конкретному пользователю. Данные можно хранить в течение
более длительного периода времени и разрешить к ним доступ к целому ряду заинтересованных сотрудников — от команды, занимающейся учетом, до отдела обеспечения безопасности, защищающего компанию от мошенничества. Так процесс
классификации данных будет развиваться, обеспечивая равновесие между потребностью в защите конфиденциальности и целями бизнеса.
На данном этапе можно применить любой из описанных мною процессов для итерационной классификации данных на основе новых сценариев использования или
последовать процессу компании Microsoft. В действительности описанный мной
второй этап объединяет шаги «Делай» и «Проверяй» из компании модели Microsoft.
Однако я настоятельно рекомендую вам разработать процесс, подходящий именно
вашей команде.
В любом случае вам нужно будет достичь одновременно двух целей:
 собрать отзывы о самой последней версии классификации данных, чтобы начать

работать над ее следующей версией;
 создать применимые и проверяемые средства контроля для внедрения инструк-

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

рованию);
 шифрование при передаче (должно быть подтверждено экспертом по шифро-

ванию);
 ограниченный и одобренный доступ ваших собственных и сторонних сотрудников;
 соблюдение политики сохранения и удаления данных пользователей.

Глава 3. Классификация данных

133

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

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

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

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

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

продуманного процесса классификации данных и обучения на его почве.
 Классификация данных — это стратегическая инвестиция в построение действи-

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

собственный процесс классификации данных.

- ГЛАВА 4 -

Учет данных

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

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

Глава 4. Учет данных

135

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

4.1. Учет данных:
что это такое и зачем это нужно
Процесс учета данных — это процесс добавления меток, полученных в результате
классификации данных, в системы данных. В ходе учета индексируется содержимое массивов данных и ускоряется процесс поиска отдельных компонентов. Создание реестра данных подобно созданию серверной части поисковой системы для
ваших данных или тому, как команда умных инженеров создает серверную часть
таких инструментов, как Google.
Это объяснение содержит интуитивно понятное определение учета данных, но
крайне важно, чтобы технические руководители понимали, как снижать риски и
создавать условия для бизнеса с помощью данного процесса.
Незадолго до введения Общего регламента по защите данных Международная ассоциация специалистов по защите частной жизни предоставила план в виде перечня пунктов, чтобы компании могли начать работу по обеспечению соответствия
нормативно-правовым требованиям (http://mng.bz/AxDx). Это должен был быть
контрольный список, чтобы компании знали, с чего начать и какие структуры и
процессы создавать, готовясь к работе с Общим регламентом по защите данных, в
том мире, где защита конфиденциальности актуальна, как никогда ранее. Этот список остается весьма полезным, несмотря на то, что отдельные его компоненты ста-

136

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

новится все сложнее реализовать, и появляются новые его варианты в зависимости
от использования данных компанией.
Ниже я привожу этот план, дополненный моими размышлениями:
1. «Провести учет и картирование данных». Предполагается, что отправной точкой
надежной программы защиты данных является способность классифицировать,
каталогизировать и обнаруживать данные, так, чтобы риск нарушения конфиденциальности был понятен в момент сбора данных и доступа к ним. Эта книга
содержит подробное описание управления данными, созданное на основе проверенных временем советов от экспертов в данной отрасли.
2. «Создать правомерную основу для обработки данных и трансграничной передачи». Юридический отдел должен проконсультировать вас в этом вопросе. Однако относительно допустимых способов обработки данных и регионов, куда их
можно пересылать, могут возникнуть дополнительные сложности, если речь
идет о географических границах. Для такой оценки нужно уметь делать выводы
и разбираться в данных, что становится возможным благодаря классификации и
учету данных.
3. «Разработать и поддерживать систему управления данными, включая установление руководства (при необходимости это может быть старший специалист по
защите данных, который будет устанавливать политику и проводить обучение
персонала)». Это поможет гарантировать, что вместо распределения обязанностей по защите конфиденциальности между инженерами будет выбран вариант,
когда обеспечением конфиденциальности руководит отдельный специалист. Такая независимость повысит отслеживаемость и прозрачность.
4. «Осуществить оценку воздействия защиты данных, а также проектируемой защиты данных и применяемой по умолчанию». Обычно это относится к оценкам
рисков конфиденциальности и обзорам конфиденциальности, проводимым вашими сотрудниками для продуктов и функций. Мы рассмотрим вопросы оценки
рисков конфиденциальности в главе 6.
5. «Подготовить и внедрить политику хранения и учета данных», так, чтобы у вас
была полная прозрачность в вопросах того, какие данные собираются и хранятся. Эти обязательства могут стать частью ваших аудиторских проверок, для которых необходимо разумное ведение бухгалтерского учета. В противном случае
аудиторские проверки могут стать громоздкими и дорогостоящими.
6. «Настроить системы и внедрить процессы, учитывающие права субъектов данных, включая право на доступ, исправление, удаление, перенос, возражение
против автоматизированной обработки и отзыв согласия на обработку данных».
Как уже упоминалось ранее, права субъектов данных (DSAR) — основное обязательство для многих компаний благодаря таким нормативным документам,
как GDPR и CCPA. Учет данных — это ключ к точному выполнению этих обязательств в масштабах компании.

Глава 4. Учет данных

137

7. «Приготовиться реагировать на нарушение безопасности и уведомить о нем».
Юридическому отделу вашей компании и/или внешнему юристу стоит взвесить
все «за» и «против», но в некоторых штатах в США и других странах действуют
законы об уведомлении о нарушениях. Эти законы предполагают, что компании,
пострадавшие от утечки данных, должны уведомить об этом пострадавших определенным образом и в определенные сроки.
8. «Иметь надежный протокол управления поставщиками». Этот шаг очень важен,
поскольку поставщики, получающие доступ к вашим системам и данным, могут
принимать решения, рискованные для конфиденциальности. Крайне важно оценить способность поставщиков следовать вашим рекомендациям по защите данных и их послужной список. Как уже отмечалось, компания может заявить, что
проблемы с обеспечением конфиденциальности данных возникли у третьей стороны, но заинтересованные лица в сообществе по защите конфиденциальности
все равно могут возложить ответственность на нее саму.
9. «Создать системы и каналы для связи с органом по надзору за соблюдением законодательства о защите персональных данных». Быть может, вам придется
предоставить регулирующим органам подробную информацию о данных, решениях по работе с ними и записи с временны́ми метками. Учет данных позволит
осуществить и ускорить процесс раскрытия информации, а также поможет построить прочные доверительные отношения.
Руководителей инженерных компаний, успокаивающих себя тем, что в новостях о
нарушениях конфиденциальности упоминаются только технологические гиганты, я
хочу предупредить: для этих корпораций момент истины наступил после быстрого
роста. По крайней мере, у них были деньги, чтобы сформировать группы по защите
конфиденциальности и нанять юристов для представления их интересов в суде. А
вдруг регулирующие органы или граждане-активисты придут в стартап прежде,
чем его акции появятся на бирже, и инвесторы не могут получить даже базовый
доход со своих инвестиций?
Кроме того, чем меньше размер компании и чем ограниченнее ресурсы, тем труднее будет адаптироваться к внезапным изменениям в законодательстве. Я знаю несколько небольших компаний, дорожные карты которых сильно пострадали. Если
вам кажется, что защита конфиденциальности обходится дорого, то издержки в
случае проблем в этой области наверняка будут еще выше. Вот грубый пример:
Билл Гейтс недавно заявил, что расследование антимонопольной службы, в котором фигурировала корпорация Microsoft в конце 1990-х годов, повлияло на способность компании эффективно осмыслить угрозу, исходящую от модели SaaS Google
и мобильной вычислительной модели Apple. Из-за этого корпорация Microsoft потеряла целых десять лет. Зачем сознательно подвергать свою компанию такой неопределенности, если верные действия по защите конфиденциальности помогут
вашему бизнесу укрепить доверие клиентов и поспособствуют его росту?
Процесс учета данных — ключевой элемент программы их защиты. Выяснив, что
такое учет данных и почему он важен, перейдем к его основным элементам. В следующем разделе мы рассмотрим метки данных.

138

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

П РИМЕЧАНИЕ
Учет данных — это действия, цель которых — убедиться, что ваша классификация
данных, основанная на риске конфиденциальности, отражена в физических данных,
хранящихся в массивах и хранилищах данных.

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

4.2.1. Что такое метки для учета данных
Учет данных — это процесс применения классификации данных к физическому
хранилищу данных. Как вы уже убедились, процесс классификации является кроссфункциональным, и потому отделам приходится придумывать обозначения, описывающие природу данных и связанный с ней риск нарушения конфиденциальности.
Но чтобы система учета данных функционировала и выполняла свою задачу, необходимо предпринять дополнительные шаги — проиндексировать данные, облегчив
их поиск и защиту.
Первый шаг в этом процессе, который многие компании нередко упускают из виду
себе же во вред, заключается в придумывании меток или ярлыков. Метки представляют собой машиночитаемое воплощение классификации данных. Вполне возможно, что с ними компания впервые разработает общие определения, относящиеся к
данным, ранее собранным несколькими отделами. Доработать систему меток порой
бывает непросто, ведь отделы уже привыкли к собственным способам именования.
Для простоты я приведу несколько критериев использования меток данных, которые помогут провести учет данных и улучшить его результаты:
 метки данных должны легко восприниматься точками внедрения, такими как

шлюзы для предотвращения потерь данных или средства управления правами
доступа к данным для интеллектуальной системы;
 метки должны быть совместимы с внешними нормативными документами и со-

ответствовать им (например, с GDPR и CCPA). Нередко бывают случаи, когда
нужно применить средства управления, соответствующие конкретному законодательству, поэтому рекомендуется помечать данные надлежащим образом. (К
примеру, в почтовом сервисе Gmail можно прикрепить к письму метки «семейный отдых, декабрь 2019» и «Мама». Тогда при поиске по любой из этих фраз
будет появляться помеченное письмо);

Глава 4. Учет данных

139

 метки необходимо применять ко всем данным в следующих состояниях: в мес-

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

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

4.2.2. Метки для учета данных: конкретный пример
Теперь, когда у вас есть общее понимание меток для учета данных, изучение конкретных образцов и примеров поможет выработать собственную стратегию маркировки. Это упражнение позволит получить информативное представление о детальности и разнообразии данных, а также понимание критической значимости работы по маркировке данных.
Поскольку учет данных расширяет их существующую классификацию, мы сосредоточимся на конкретном уровне конфиденциальности. В табл. 4.1 показано, как
можно создавать различные виды меток для самых чувствительных данных (которые я называю данными первого уровня).
Во-первых, формат конкретной метки должен быть следующим:
(business|personal):[a-z]+(-[a-z]+)*

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

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

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

140

Часть II. Упреждающая программа защиты конфиденциальности: управление данными
Таблица 4.1. Шаблон метки для учета данных (данные уровня 1)

Уровень

Деловые/
личные

Уровень 1

деловые

Описание

Собрание
совета директоров

Значение метки
(business|
personal):
[a-z]+(-[a-z]+)*

Максимальный период
хранения

Условия
хранения

Вариативное
значение (например,
ярлык GCP)
(business|
personal)_
[a-z]+(-[a-z]+)*

нет

нет

business:
board-material

или
business_
board-material

Уровень 1

деловые

Закрытые
финансовые
данные

нет

нет

business:
non-public-financial

или
business_
non-public-financial

Уровень 1

деловые

Деловые дан- нет
ные в области
безопасности

нет

Уровень 1

личные

Данные
о местоположении

7 лет

Удалить (незаре- personal:
level1-location
гистрированных
пользователей);
хранить до истечения периода
хранения (зарегистрированных
пользователей)

Уровень 1

личные

Идентифицирующие документы

Жизненный
цикл приложения

Уровень 1

личные

Уровень 1,
Жизненный
демографиче- цикл прилоские данные
жения

Удалить

personal:
level1-demographic

Уровень 1

личные

Биометрические данные

Удалить

personal:biometric

Жизненный
цикл приложения

business:security

personal:
government-id

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

Глава 4. Учет данных

141

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

сотрудников и поддержка всех форм удостоверений личности;
 поиск сотрудников на основе определенного критерия формы удостоверения

личности: например, найти всех сотрудников, которые находятся на двухдневном испытательном сроке после первого рабочего дня, поскольку они не предоставили удостоверение личности.
В табл. 4.2 формат метки(business|personal):[a-z]+(-[a-z]+)*) позволяет указывать
двоичное значение (True/False). С помощью этого значения можно определить, какие сотрудники предоставили действительное удостоверение личности (Джон Смит
и Джейн Доу), а какие — нет (Эйб Линк). После первых трех дней работы можно
выполнить запрос поиска сотрудников с тегом «False» и выявить, кто из них еще не
предоставил удостоверение личности. Для этого значение «government-id» должно
быть логическим (булевым). Также можно настроить его, чтобы появлялось число,
соответствующее количеству цифр в номере документа, удостоверяющего личность (водительских прав, паспорта и т. д.), или последовательность нулей, указывающая, что нужного документа предоставлено не было.
Важно, что даже если ваши данные не структурированы в определенном формате,
все равно можно использовать метки, чтобы сделать их доступными для поиска и
идентификации.
Таблица 4.2. Основные метки для учета данных с двоичными значениями

Уровень

Компания/
пользователь

Уровень 1

Пользователь

Значение метки
(business|personal):[a-z]+
(-[a-z]+)*
Описание

Вариативное значение
(например, ярлык GCP)
(business|personal)_[a-z]+
(-[a-z]+)*

Удостоверение
личности

personal:government-id

Пример
метки

John
Smith:True

142

Часть II. Упреждающая программа защиты конфиденциальности: управление данными
Таблица 4.2 (окончание)

Уровень

Компания/
пользователь

Уровень 1
Уровень 1

Значение метки
(business|personal):[a-z]+
(-[a-z]+)*

Пример
метки

Описание

Вариативное значение
(например, ярлык GCP)
(business|personal)_[a-z]+
(-[a-z]+)*

Пользователь

Удостоверение
личности

personal:government-id

Jane
Doe:True

Пользователь

Удостоверение
личности

personal:government-id

Abe
Linc:False

Теперь предположим, что вам нужно идентифицировать сотрудников, имеющих
разрешение на работу, а значит, они должны предоставить свои паспорта для подтверждения права на работу в Соединенных Штатах. В табл. 4.3 показано, как может помочь учет данных. Во второй (personal:government-id-passport) и третьей
(personal:government-id-driverlicense) строках указаны форматы меток, позволяющие использовать различные виды идентификаторов. Вместо двоичного значения,
как в табл. 4.2, здесь можно использовать регулярные выражения. Так метки подскажут, какой документ предоставил пользователь: водительские права или паспорт.
Таблица 4.3. Метки для учета данных
Значение метки
(business|personal):
[a-z]+(-[a-z]+):L|F
*Изменяющееся значение
(например, ярлык GCP)
(business|personal)_
[a-z]+(-[a-z]+):L/F

Уровень

Компания/
пользователь

Уровень 1

Пользователь

Удостоверение личности

personal:government-id-passport

Jerry Seinfeld:^d{10}

Уровень 1

Пользователь

Удостоверение личности

personal:government-iddriverlicence

Jerry
Maguire:^d{9}

Уровень 1

Пользователь

Удостоверение личности

personal:government-id-passport

Jerry Tom:^d{10}

Описание

Пример метки

В табл. 4.3 первый и третий пользователи будут соответствовать запросу на идентификацию сотрудников с действительными паспортами (исходя из предположения, что в номере паспорта 10 цифр). Однако Джерри Магвайер (Jerry Maguire) —
пользователь, который еще должен предоставить паспорт (он предоставил только
водительские права, в которых 9 цифр).

Глава 4. Учет данных

143

Таким образом, с помощью учета данных можно:
 придумывать метки, которые сделают данные доступными для поиска, и сопос-

тавлять данные по уровню конфиденциальности;
 расширять метки для различных вариантов использования в бизнесе.

Пример выше — упрощенный. Учет данных и реальные сценарии будут становиться все сложнее и разнообразнее. Главный вывод заключается в том, что гораздо
удобнее иметь возможности искать, обрабатывать и удалять данные благодаря проведенному заранее учету, чем разыскивать конфиденциальные данные в JSONблобах или других форматах данных. В последнем случае можно упустить важную
информацию или потратить значительные ресурсы на ее поиск.
Учет данных связывает ориентированное на конфиденциальность представление о
данных (классификацию данных) с самими данными. Это означает, что если вам
потребуется передать данные из локальной среды в облако или из базы данных
MongoDB в Cassandra, нужно будет убедиться, что данные несут в себе ту идентификационную информацию и те значения риска, которые вы им присвоили. Это
существенно облегчит управление риском конфиденциальности в крайне децентрализованной, организованной по принципу «снизу вверх» компании, которая работает с большими данными.
Теперь, когда у вас появились метки, применимые к данным, можно создать базовую
версию (отправную точку) для учета данных перед применением автоматизации.

4.3. Разработка базовой версии
В любой компании работа с данными требует не только автоматизации, но и усилий сотрудников. В следующем разделе вы увидите, что процесс применения меток
предполагает как раз такое сочетание — отчасти из-за объема данных, а отчасти изза его сложности.
Однако сначала необходимо разработать процесс обнаружения данных. Он очень
важен, потому что, как вы скоро увидите, большинство фирм начинают процесс
учета после того, как наберут значительный объем данных. И хотя разработка процесса зачастую приводит к непредвиденным серьезным расходам, она также позволяет компаниям разработать базовую версию для имеющихся данных.
Сначала придется потрудиться, собирая информацию, которая легко доступна, но
разбросана по разным отделам или находится в головах инженеров и не задокументирована. Такую информацию образно называют «коллективным знанием», а превращение коллективного знания в общедоступное — как раз и есть разработка базовой версии.
Чтобы создать базовую версию учета данных, инженерам, специалистам по анализу
данных и другим сотрудникам следует разработать модели и способы оценки того,
какие данные были собраны и где они находятся. Несмотря на то, что первоначальные результаты могут оказаться неполными или неверными, или и теми, и другими
сразу, с помощью этого процесса можно собрать сведения об известных случаях

144

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

Перед тем как сотрудники начнут производить учет данных по системам хранения,
необходимо предоставить им шаблон, куда можно будет записать, какие данные
были найдены при первичном учете вверенных им систем. Для каждой системы
хранения данных (например, Hive, Vertica, Kafka, база данных SQL, хранилища S3
и т. д.) данные должны быть учтены с указанием следующих атрибутов:
 общий размер (объем хранилища);
 структурированные/неструктурированные данные (в процентном соотношении);
 уровень классификации данных (если в хранилище имеются данные с несколь-

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

Однако учета данных по системам хранения недостаточно. Системы хранения данных часто принадлежат нескольким отделам. Или может оказаться, что за некоторые из них никто не отвечает, но многие инженеры их используют. Чтобы получить
точное представление о системах в своей компании, необходимо провести также
учет данных по их владельцам. Тогда у осиротевших хранилищ данных появятся
владельцы, а вы сможете ввести определенную ответственность, касающуюся
обеспечения конфиденциальности.
Контрольный список атрибутов для второго этапа похож на список для первого
этапа и может быть таким:
 общий размер (объем хранилища);
 количество единиц (количество сервисов, пользователей, учетных записей или

наборов данных);
 структурированные или неструктурированные;
 уровень классификации данных (если в хранилище имеются данные с несколь-

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

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

Глава 4. Учет данных

145

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

4.4. Техническая архитектура
Многим руководителям компаний нравится выражение «Чтобы заработать, надо
потратиться». Его обычно употребляют, говоря о маркетинге, исследованиях и других инвестициях, необходимых для развития бизнеса. Например, новые продукты
на новых рынках на ранних стадиях часто требуют больше расходов, пока не начнут приносить доход и прибыль.
Аналогичная проблема и при учете данных. Добавленная стоимость учета данных
для бизнеса заключается в том, что он связывает с данными критически важную
информацию, подчеркивая риски конфиденциальности, а также индексирует данные для удобства поиска.
Затраты инженеров при учете данных являются разовыми и связаны с поиском
данных для индексации и маркировки. Другими словами, чтобы сделать данные
доступными для поиска, их сначала нужно найти. Обратите внимание, что это
предполагает наличие у вас накопленного объема данных, уже собранных до начала учета. В следующих главах мы выясним, как подгадать с моментом учета данных таким образом, чтобы этих данных было как можно меньше.
Далее мы сосредоточимся на обнаружении данных и ориентированной на машинное обучение категоризации данных как ключевых компонентах, необходимых для
их учета. Подразумевается, что обычных инструментов для обнаружения таких
данных недостаточно.

4.4.1. Структурированные и неструктурированные данные
Многие руководители предприятий задавали мне вопрос: «Базу данных А обработали быстро, так почему обработка базы данных B занимает гораздо больше времени, хотя в ней меньше данных?» Именно в этом случае ключевую роль играет коренное отличие структурированных данных от неструктурированных.
Согласно определению сайта обзоров G2.com:
Структурированные данные чаще всего относятся к категории количественных данных, [и, как правило] это данные, которые четко вписываются в
фиксированные поля и столбцы реляционных баз данных и электронных таблиц. Структурированные данные высокоорганизованы и легко понятны для
машинного языка. Те, кто работает с реляционными базами данных, могут
относительно быстро вводить, искать структурированные данные и манипулировать ими... Это самая привлекательная особенность структурированных данных (https://learn.g2.com/structured-vs-unstructured-data).

146

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

Рис. 4.1. Структурированные данные

На основе рис. 4.1 построим базу данных, которая позволит нам отслеживать заказы для розничного бизнеса:
1. Создадим таблицу «Пользователь» для пользователей/клиентов.
2. Чтобы отправлять клиенту товар и, возможно, рекламу, нужно будет создать
таблицу, в которой будет храниться информация о каждом пользователе — например, его имя и контактные данные.

Глава 4. Учет данных

147

Следует отметить два момента:
 в строке каждого пользователя содержится идентифицирующая личность информация, например, его адрес, электронная почта и т. д..;
 каждая строка также содержит уникальный идентификатор, который можно
использовать, чтобы связать данные пользователя в одной таблице с другими
данными о нем в другой таблице.
3. Создадим таблицу «Заказ», содержащую заказы, размещенные пользователем.
4. Поскольку один пользователь может размещать много заказов, в этой таблице
может быть несколько записей для каждого пользователя. Обратите внимание,
что вместо имени пользователя или его электронной почты мы используем
идентификатор, чтобы связать эту таблицу с основной таблицей «Пользователь». На это есть две причины:
 сокращение числа дублирований чувствительных данных в компьютерных
системах компании;
 идентификатор может быть числовым, и это облегчит сопоставление при ответе на запросы, запускаемые для устранения неполадок и анализа.
5. Обратите внимание, что у каждого заказа также есть идентификатор. Это поможет нам дальше развить базу данных для ознакомления с содержанием заказа.
6. Мы создадим таблицу «Позиция заказа», содержащую подробную информацию
о заказах, чтобы знать, какие товары содержатся в заказе.
7. Подобно тому, как каждому заказу присваивается идентификатор, снабдим
идентификаторами и товары, содержащиеся в заказе. В таблице «Позиция заказа» товары и заказы соотносятся как «много к одному», поскольку в каждом заказе может быть ноль или более товаров. Наличие ID товара позволяет связать
таблицу «Позиция заказа» с другой таблицей, содержащей подробную информацию о товарах.
8. Создадим таблицу «Товар» с подробной информацией о самих товарах.
9. Она связана с таблицей «Позиция заказа» с помощью ID товара.
Изучив рис. 4.1 сверху вниз, увидим, что идентификатор пользователя 1 относится
к клиенту Alice, у которой было два ID заказов — 1234 и 5678. Далее, у Alice было
два ID товаров — 765 и 987. Наконец, мы видим, что Alice купила два пакета картофеля и одну пачку спагетти.
Эти данные организованы очень аккуратно и логично, но в современных системах
данные нечасто распределены по четким полям, столбцам и имеют логические корреляции.
Для более точного анализа эффективности бизнеса вам необходимо вести учет данных, которые не соответствуют структурированному формату. Так мы подходим к
неструктурированным данным.

148

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

Неструктурированные данные часто качественные и не поддаются обработке или
анализу с помощью традиционных инструментов. Компания NetApp, занимающаяся управлением данными, приводит несколько примеров (http://mng.bz/ZzwA):
 мультимедиа — данные СМИ и развлекательных ресурсов, данные наблюдения,

геопространственные данные, аудио и т. д..;
 коллекции документов — счета-фактуры, записи, электронные письма и прило-

жения для повышения производительности труда;
 интернет вещей — данные датчиков и тикеров;
 журналы приложений — машинное обучение, искусственный интеллект.

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

4.4.2. Архитектурные возможности учета данных
Теперь рассмотрим техническую реализацию учета данных. Вам понадобится архитектура учета данных, способная выполнять следующие действия:
1. Просмотреть известные хранилища данных.
2. Обнаружить другие наборы данных (особенно неструктурированных).

Глава 4. Учет данных

149

3. Сделать эти наборы данных и соответствующие метаданные доступными для
маркировки.
4. Обеспечить расширяемость для добавления новых метаданных.
5. Поддерживать возможности категоризации персональных данных (сценарий использования для обеспечения конфиденциальности).
Первые три пункта в списке относятся к обнаружению и маркировке данных. Эта
ключевая способность лежит в основе учета данных. Жизненно важно, чтобы ваша
инфраструктура могла обнаруживать данные, распределенные по системам хранения.
Как говорилось выше, значительная часть собираемых нами данных — неструктурированные. Например, их фрагменты могут поступать в системы в виде JSONблобов, поэтому понадобятся инструменты, такие как поисковые боты, для просмотра различных хранилищ данных и обнаружения наборов данных, а затем применения тегов к данным на нужном уровне детализации информации. С помощью
инструментов вроде регулярных выражений и истории данных поисковые боты будут искать данные и обеспечивать возможность их маркировки. Далее вы увидите,
что по мере обнаружения новых данных арсенал инструментов будет расширяться.
В этом смысле учет данных — это процесс, который приносит результаты и совершенствуется на основе этих результатов.
Четвертый пункт списка, в котором инфраструктура позволяет инженерам вводить
дополнительные метаданные, также очень важен. Руководители и инженеры, их
подчиненные, могут поинтересоваться: «Зачем инвестировать в такую большую
инфраструктуру, если в нее придется добавлять ручной процесс — ввод инженерами ценной информации о запасах?» Как вы уже знаете, на самом деле учет данных — эволюционный процесс, который совершенствуется по мере того, как вы
упорядочиваете большее количество систем и строите взаимосвязи между различными данными.
Пока вы не достигнете стадии зрелости учета данных, о которой мы поговорим
чуть позже, жизненно важно, чтобы этот процесс был как можно более комплексным. Нельзя рассчитывать на то, что инженеры проведут учет всех данных, но следует дать им возможность вводить соответствующую информацию через интерфейс прикладного программирования (API) или другой пользовательский интерфейс (UI). Однажды, когда я развивал программы учета данных до стадии зрелости,
меня приятно удивили инженеры и специалисты по обработке данных, вызвавшиеся ввести информацию о данных, которые они собрали и о которых знали, но которые наши скрипты и инструменты не смогли обнаружить.
Далее вы сами решите, стоит ли проверять их работу с помощью инструментов или
перенаправить автоматизированные процессы на другие хранилища данных.
Наконец, как указано в пятом пункте, ваша инфраструктура должна обеспечивать
возможность категоризации персональных данных. Именно теперь, обнаружив
данные, следует применить метки. Как я объясню позднее, для этого процесса нужны инфраструктура, автоматизация, человеческие суждения и искусственный интеллект.

150

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

Инфраструктура для всей этой работы обойдется недешево, а результаты появятся
не сразу. В условиях ограниченного бюджета многие технические руководители
задумаются, оправданы ли расходы. Как эксперт по конфиденциальности, устанавливающий высокую планку в вопросе защиты доверия пользователей, и как человек, которому приходилось работать с регулирующими органами, я считаю, что
учет данных — выгодное вложение, если принять во внимание штрафы и репутационный ущерб, которым опасны проблемы с конфиденциальностью.
И все же стоит рассмотреть приведенный выше список комплексно. В частности,
первые четыре пункта в любом случае необходимы отделам обработки данных для
улучшения процесса обнаружения данных, а также их качества. Отделам, принимающим решения об инвестициях, требуются высококачественные и правильно
размеченные данные. Обычно они получают такие данные в обобщенном виде из
хранилища данных. Если данные будут размечены и сопоставлены, а незначимая
информация — удалена, то это улучшит результаты анализа и сократит время,
нужное для выполнения запросов о поиске данных.
Аналогичным образом, если вы слишком поздно обнаружите, что сохранили данные, которые не нужно было хранить, вы создадите лишнюю работу отделам, занимающимся платформой и хранилищем данных. Однажды я работал в компании,
где мы по незнанию собирали IP-адреса пользователей без их согласия. Данные попали в хранилища в JSON-блобах и не были обнаружены во время получения и начального хранения. Для их удаления пришлось выводить базы данных в автономный режим, переформатировать таблицы (по сути, удалить их и переписать заново
с меньшим объемом информации) и повторно запускать все запросы для получения
данных анализа. Весь отдел анализа данных был вынужден три дня сидеть без дела,
пока все доступное оборудование было брошено на решение проблемы чистки данных на стороне сервера. Помимо затрат на удаление IP-адресов, мы понесли издержки упущенных возможностей от того, что не могли проводить анализ данных в
течение трех дней и потеряли данные, которые могли бы законно собрать.
Я рекомендую компаниям не взваливать учет данных на отдел защиты конфиденциальности. Учет данных — это требование бизнеса, а не конфиденциальности.
Фактически, отделы, которые занимаются обеспечением конфиденциальности,
платформой данных и обработкой данных, должны быть способны распределить
обязанности между собой, объединить силы и провести более качественный учет
данных.

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

Глава 4. Учет данных

151

всегда идут в таком порядке. Вам придется скорректировать их в соответствии со
своими потребностями.
Учет происходит в службе учета данных (англ.: DIS — data inventory service), которая показана на схеме в ячейке 6. Этот блок соответствует пятому пункту списка из
предыдущего раздела, в котором к данным добавляются метки в соответствии с
классификацией.

Рис. 4.2. Схема процесса учета данных

Рассмотрим все это подробнее.
Процесс классификации данных на рис. 4.2. представлен в поле 1. В ходе него сотрудники из разных отделов классифицируют данные на основе правил, использования и т. д. Их задача — разработать метки данных. В жизни этот процесс не сводится к одному элементу схемы, а многократно повторяется и возобновляется, но
на схеме он представлен упрощенно.
Поле 2 отражает создание машиночитаемых меток, примеры которых приводились
ранее.
Данные, поступающие в систему, представлены в поле 3 в левом нижнем углу.
Схема предполагает, что у вас есть один основной API, с помощью которого можно
вводить всю информацию. Однако в реальности ваша инфраструктура, скорее всего, более сложная.
DIS может получить все данные и связанные с ними метаданные с помощью поисковых ботов, слушателей событий и других средств. Инструментарий представлен
полем 4 в средней части. Чуть позже я расскажу об инструментах подробнее.
Поток данных на рис. 4.2 логичен, поскольку здесь визуализированы шаги, начиная
от совместной и ручной работы (классификация данных, планирование меток) и
заканчивая автоматизированными процессами (обнаружение данных, наложение
меток). Однако в этом процессе есть нюансы, которые необходимо изучить отдельно.

152

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

Рис. 4.3. Система учета данных; объедините данные
перед началом процесса маркировки

На рис. 4.3 показано, как можно объединить данные и метаданные в одном месте
(шаг 1 на рисунке). Это можно сделать с помощью поисковых ботов, слушателей
событий и т. д. Указанные инструменты будут использовать регулярные выражения
и методы, основанные на машинном обучении для просмотра хранилищ данных,
выборки конкретных базы данных и просмотра истории данных. На основе этого
будет сделан вывод о наличии данных и риске для них.
Например, для обнаружения столбцов или строк с номерами социального страхования ваши поисковые боты будут искать фрагменты данных, соответствующие
^\d{3}-\d{2}-\d{4}$. То есть вам нужно найти шаблон, состоящий из трех цифр, дефиса, двух цифр, еще одного дефиса, а затем еще четырех цифр.
С каждой новой итерацией процесса учета данных инструменты будут становиться
более комплексными и точными. Возможно, вам стоит также разработать портал
пользовательского интерфейса для инженеров, чтобы они могли вручную вводить
свои схемы данных, как мы обсуждали выше.
В средней части диаграммы (шаг 2) подчеркивается, что:
 инженеры и специалисты по обработке данных, знающие свои данные, могут

распределить их по категориям вручную;

Глава 4. Учет данных

153

 эту созданную вручную классификацию можно использовать для тренировки

моделей на основе машинного обучения, которые будут присваивать данным
метки классификации.
Подобное сочетание методов учета данных — учет вручную и с помощью машинного обучения — поможет снизить зависимость от выполнения действий.
В правой части рисунка (шаг 3) представлен этап завершения маркировки данных
после проведения классификации вручную и с помощью моделей машинного обучения. В отношении использования процесса учета данных DIS на схеме показана
как многомерная система. DIS — одновременно сервис и база данных.
 Как сервис она передает данные классификаторам, проводящим классификацию
вручную или с помощью автоматизированных программ. Классификаторы —
это эксперты-люди, а также инструменты машинного обучения, которые оценивают данные, а затем присваивают им уровень конфиденциальности и метку.
 Как база данных DIS предоставляет классификаторам следующую информацию:
имя столбца, тип столбца, выполненную вручную категоризацию персональных
данных и т. д. Классификаторы используют эту информацию, чтобы автоматически сделать вывод о категории персональных данных. Классификация вручную
также происходит с использованием этой функции DIS. Таким образом, DIS объединяет данные и бизнес-логику, обеспечивая фактическую маркировку данных.
Все маркированные данные затем хранятся в отдельной временной базе данных.
Обратите внимание, что DIS также представлена в виде чистой базы данных в
крайнем правом углу схемы. В этом случае она хранит данные, маркированные и
обработанные с помощью «блока выбора решения», чтобы можно было удостовериться, что первоначальная маркировка выполнена правильно. Блок выбора решения может содержать инструментарий для выборки данных или предоставлять возможность верификации экспертом-человеком для проверки работоспособности.
Это и есть «суждение», о котором я упоминал ранее, — позволяющее убедиться,
что вы не слишком консервативно или беспечно подходите к процессу маркировки.
Когда все будет сделано, можно применить политики для защиты данных. Помните, на этом этапе можно программно применять политики аутентификации, авторизации и т. д.
Теперь данные готовы к использованию и обладают соответствующей встроенной
защитой. Возможно, вы слышали выражение «проектируемая конфиденциальность».
Мы пошли дальше, разработав «конфиденциальность, обеспеченную данными».
Поскольку встраивание соответствующих элементов управления в данные имеет
решающее значение для защиты конфиденциальности, уделим больше внимания
формированию представления о данных.

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

154

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

4.5.1. Процесс определения метаданных
Для правильной классификации данных необходимо найти способ собрать как
можно больше метаданных. Также необходимо, чтобы определения метаданных
были единообразными для всех источников данных. На рис. 4.4 показан комплексный характер сбора метаданных, которые вам понадобятся. DIS должна охватывать
не только наборы данных, но и все объекты данных. Это означает, что недостаточно просто определить местоположение данных. Необходимо понять, какая служба
предоставила доступ к этим данным, где они находились в последний раз и, возможно даже, каков источник их первоначального ввода. Вся эта информация, упрощенно говоря, представляет собой метаданные.

Рис. 4.4. Система обнаружения метаданных

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

Глава 4. Учет данных

155

Поскольку DIS необходимо понимать данные, собранные из многих источников,
вам придется сначала создать определение метаданных, указав, какие сведения метаданные сообщают о самих данных. Формулирование такого определения поможет выделить желаемую информацию среди множества схожих данных, найденных
в разных источниках. Отсутствие определения метаданных может привести к двусмысленности в обработке информации. Например, вам понадобятся метаданные,
чтобы отличить информацию по действующим кредитным картам, которую необходимо защитить, от записи о просроченных подарочных картах, которая представляет меньший риск, и потому меры по защите ее конфиденциальности могут быть
гораздо менее жесткими.
Отсутствие определения метаданных также может привести к неправильному выявлению (и классификации) неструктурированных данных, так как определения
при поиске в разных случаях будут различаться. Например, номера кредитных и
подарочных карт в идеале должны содержать метаданные, которые помогут инженерам их отличить. Логично, что кредитные карты с высоким лимитом требуют более
строгой защиты конфиденциальности, чем подарочные карты, ценность которых
предположительно меньше. На рис. 4.5 показано, как можно решить эту проблему.
Я рекомендую использовать для определения метаданных структуру, близкую к
таксономии, — с типами сущностей и значений. На рис. 4.5 таблицы MySQL и
RelationalDB определены как типы сущностей со свойствами, объясняющими их
значение. Подобно тому, как у человека есть характеристики роста и веса, в MySQL
есть свойства «Имя» и «Структура».

Рис. 4.5. Определение и регистрация метаданных

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

156

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

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

Рис. 4.6. Получение данных системой учета с помощью моделей извлечения и передачи.

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

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

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

Глава 4. Учет данных

157

Что касается модели передачи, с ней все должно быть немного проще:
 можно использовать существующие API разработчиков и другие инженерные

инструменты для обмена данными с целью поиска;
 также можно обратиться к услугам краудсорсинга для получения проверенной

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

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

4.6.1. Почему процесс учета данных так сложен?
Помимо технических деталей, которые мы уже рассмотрели, важно понять, почему
процесс учета данных настолько сложно реализовать.
Во-первых, речь о конфиденциальности — неважно, рассматривают ее как задачу
бизнеса или гонку за ресурсами, — заходит после роста компании. В большинстве
компаний специалистов по конфиденциальности/безопасности никогда не нанимают заблаговременно. Если представить, что инженеры и специалисты по данным —
слоны в цирке, то специалисты по конфиденциальности и безопасности — уборщики, ходящие следом за ними с лопатами. А если серьезно, обычно крупные компании нанимали меня после того, как им выписывался штраф или выносилось определение об утверждении мирового соглашения. Уже было собрано много данных,
сформировались вредные привычки, и требовалось многое сделать, чтобы наверстать упущенное. Вместе с тем, если доходы и количество пользователей компании
не будут увеличиваться, она не сможет позволить себе нанять специалистов по
конфиденциальности. Рост финансирует конфиденциальность, и специалистам по
конфиденциальности следует помнить, что бизнес им не враг.

158

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

Во-вторых, как мы уже видели, современные компании оптимизируют деятельность для ускорения роста и создают децентрализованные команды, которые работают каждая в своем направлении. Конфиденциальность, с другой стороны, требует
делать упор на централизованность.
Клиент во Франции, пользующийся английской версией вашего онлайн-сервиса,
должен иметь такую же защиту конфиденциальности, как и клиент во Франции,
использующий французскую версию. Это сложно гарантировать, когда разные отделы работают обособленно, и их решения по сопоставлению артефактов с сервисами не являются единообразными. В этом случае, если в результате действий одного отдела возникнут проблемы с защитой конфиденциальности, пострадает вся
компания, а не только отдел, занимающийся платежами или выставлением счетов.
Вам понадобится сложная программа защиты конфиденциальности, поскольку
конфиденциальность не просто отстает от темпов роста компании — для ее обеспечения требуется иной тип мышления, отличный от того, который дал компании
возможность расти.
Наконец, есть прокрастинация. Слишком часто компании тянут до тех пор, пока не
случится крупное нарушение конфиденциальности или не придут с проверкой регулирующие органы, и только потом начинают работу в этом плане. К тому моменту данные и риски уже накоплены, и требуется принять меры прежде, чем риск
станет финансовым или повлечет за собой серьезные последствия. Инженеры привыкли жить по принципу «мы всегда так делали». Тут даже зрелые и престижные
компании, похоже, страдают зависимостью от данных. У них появляется непреодолимая тяга продолжать работу, повторять шаблон снова и снова, потому что продолжать легче, чем остановиться. Если они остановятся, придется проводить жесткую проверку, выявляя уже нанесенный вред, растраченные финансы и разрушенное доверие. Момент расплаты может оказаться болезненным, но, как и лечение
зубов, его нельзя откладывать надолго. Продолжая действовать как ни в чем не бывало при угрозе такого риска, они удваивают вероятность финансовых потерь.
Учитывая, как дорого обходится чрезмерное затягивание внедрения учета данных,
давайте рассмотрим, каким образом можно встроить этот важный шаг в жизненный
цикл данных.

4.6.2. Учет данных: лучше раньше, чем позже
У моего коллеги со времен работы в Netflix (где я внедрял программу защиты конфиденциальности) была меткая поговорка: «Что касается защиты данных, лучше
всего было начать ее вчера; или хотя бы сегодня».
Чтобы понять, что представляет собой процесс учета данных на ранней стадии,
представьте, что данные, поступающие в вашу компанию, — это опрокинутая воронка (рис. 4.7). Как только данные поступят в систему, пользователи скопируют
их, логически выведут из них другие данные и так далее. По мере перемещения
глубже в систему (слева направо) объем данных увеличивается. Такая воронка наоборот. Многие руководители слишком далеки от непосредственной работы с данными, чтобы в полной мере оценить эту динамику.

Глава 4. Учет данных

159

Рис. 4.7. Учет данных через призму воронки данных; по мере прохождения
через системы компании данные увеличиваются в объеме за счет копий,
извлечения сведений, объединения и т. д.

Инженеры и специалисты по обработке данных собирают все больше данных, ведь
теперь облачные вычисления упрощают получение места для их хранения по сравнению с былыми временами, когда ИТ-специалистам приходилось физически приобретать дополнительное оборудование. Точно так же, как только инженеры и специалисты по данным получают доступ к ресурсам хранилища и вычислительным
мощностям, они находят им творческое применение — проводят эксперименты с
еще не обработанными данными. Система спроектирована для роста: увеличения
объема собираемых данных и роста инфраструктурных возможностей их обработки. Мой коллега по работе в Google называл это парадоксом «высокой доступности
и низкой видимости». Вот так воронка растет слева направо.
В исследовании компании Gartner («Guidance for Addressing Risks with Unstructured
Data») объясняется, что наша ИТ-инфраструктура стала более плотной и взаимосвязанной. Это, в свою очередь, повлияло на данные. По мере роста компаний инженеры получают больше возможностей для управления собственными сервисами,
а возможности центральных ИТ-отделов по управлению данными и услугами неуклонно сокращаются. Отдельные инженеры могут предоставлять услуги по автоматизации существующих возможностей, оптимизации устаревших, рекламировать
новые услуги, чтобы ускорить их принятие пользователями, и т. д. Такое положение дел затрудняет создание стандарта по управлению данными. В довершение всего обмен информацией, сгенерированной этими сервисами, с третьими лицами усложняет задачу ведения каталога данных.
Инновации «снизу вверх» предоставляют всем отделам компании большую свободу, но это имеет свою цену. Необходимо учитывать соотношение затрат и выгод.
Основная цель ИТ-отдела в организации — упростить процесс снабжения про-

160

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

граммным обеспечением и оборудованием. Дополнительным преимуществом такого порядка обслуживания является помощь для компании в управлении данными.
Однако по мере децентрализации бизнеса способность ИТ-отдела обеспечивать
этот порядок снижается.
Нет сомнений, что все сервисы фирмы, не связанные с ИТ, помогают повысить качество обслуживания клиентов и работы сотрудников. В конце концов, кто-то же
оплачивает корпоративные учетные записи. Эти сервисы также могут помочь генерировать огромные объемы данных в помощь маркетингу и разработке продуктов.
Однако они же затрудняют любое управление этими данными. Это, в свою очередь,
затрудняет измерение рисков и защиту данных. Создание технической инфраструктуры, находящей нужный баланс между этими двумя системами, — вызов, с которым сталкиваются все технические руководители. Вот только, учитывая присущие
данным риски, процесс учета данных нельзя откладывать.
Продолжая аналогию с воронкой, самый подходящий момент для учета данных —
как можно ближе к узкому концу воронки. Лучше, если учет данных будет происходить как можно дальше слева на рис. 4.7. Так вы сможете применить оптимальные методы защиты данных до того, как инженеры начнут использовать эти данные.
Техническим руководителям нередко сложно установить сроки учета данных потому, что они сталкиваются с противодействием со стороны заинтересованных лиц
по всей компании. Несмотря на то, что раннее начало процесса видится логичным,
оно требует дополнительных расходов (поскольку у большинства фирм нет возможности пометить данные в точке приема) и может даже замедлить поток данных
к другим отделам, пусть и на время.
По мере того как инженеры изучают категоризированные данные, проверяя их точность методом выборки, учет данных становится все более и более аккуратным.
Целью является создание моделей, которые можно использовать автоматически для
маркировки больших объемов данных. До тех пор, пока процесс учета данных не
накопит достаточно моделей для типов данных и метаданных, время выполнения
запросов микросервисами может быть увеличено. И только спустя определенный
период они смогут выполнять запросы с такой же скоростью, как раньше.
Рис. 4.8 объясняет, как запуск учета данных на ранней стадии работы компании
очевидно способствует управлению бизнес-рисками, а также их снижению. Это
способствует прогрессу и дальнейшему развитию.
Как видите, если учет данных не проводился, применить к ним какие-либо значимые средства контроля невозможно. Суть схемы заключается в том, что в момент
сбора данных (крайний слева фрагмент) в идеале уже следует начинать их учет
(второй этап слева). Так вы сможете разработать логику обеспечения разной степени защиты данных с помощью элементов управления безопасностью и конфиденциальностью (третий фрагмент слева). Как только средства защиты конфиденциальности окажутся привязаны к данным, можно переходить к использованию данных, обмену ими и возможному удалению. Все это описано в следующих фрагментах.

Глава 4. Учет данных

161

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

Стрелка над тремя крайними правыми фрагментами на рис. 4.8 охватывает наиболее знакомые нам действия: инженеры выполняют запросы данных; модифицируют
их; объединяют; обмениваются данными с поставщиками с помощью пикселей отслеживания, API или передачи файлов; и, наконец, удаляют данные. Крайне важно
выполнить управление данными, в том числе классификацию и физический учет,
до того, как данные попадут в эту область. На этом этапе у данных либо уже есть
встроенные элементы управления конфиденциальностью, либо нет. Единственный
способ оказаться на правильной стороне — наличие управления.
Сценариев использования данных станет больше по мере роста инноваций, поэтому
крайне важно, чтобы ваши данные были классифицированы, помечены и защищены в соответствии с вашими метриками риска конфиденциальности и доверия. Это
имеет особое значение потому, что использование данных необратимо. Нельзя забрать обратно данные, которыми вы поделились с третьей стороной, поэтому учет
данных должен быть приоритетной задачей, чтобы вы могли принимать обоснованные решения в этой связи.

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

4.7.1. Первый уровень учета данных
Уровень 1 — самый базовый. Здесь метки классификации данных применяются на
уровне базы данных/хранилища. Результаты и ключевые показатели эффективности (КПЭ) (англ.: KPI — key performance indicators) уровня 1 учета данных опреде-

162

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

Результаты, которые должны
быть получены

KPI для измерения
прогресса

Базы данных (структурированные данные) в датацентрах

1. Общий объем данных (Тбайт/
Пбайт) для каждого экземпляра
базы данных.
2. Метки категорий классификации
данных для каждого экземпляра
базы данных (т. е. какие метки
представлены в этом конкретном
экземпляре базы данных?)

1. Процент от общего объема производственных данных в производственных
центрах данных, прошедший учет первого уровня.
2. Процент экземпляров
производственных баз данных в производственных
центрах данных, прошедший учет первого уровня.

3. Состав уровня производственных
данных в производственных датацентрах:
 процент от общего объема
производственных данных,
содержащий наиболее конфиденциальные данные;
 процент от объема производственных данных за вычетом
конфиденциальных данных;
 процент от общего объема производственных данных, содержащий общедоступные данные.
Хранилища в общедоступном облаке (неструктурированные данные;
в настоящее время вебсервисы Amazon / Облачная платформа Google)

1. Общий объем данных (Тбайт/
Пбайт) для каждого хранилища.
2. Метки категорий классификации
данных для каждого хранилища
(т. е. какие метки представлены
в этом конкретном хранилище?).
3. Состав уровня данных в производственных общедоступных
облачных хранилищах:
 процент от общего объема производственных данных, содержащий наиболее конфиденциальные данные;
 процент от объема производственных данных за вычетом
конфиденциальных данных;
 процент от общего объема производственных данных, содержащий общедоступные данные.

1. Процент от общего объема производственных данных в производственных
общедоступных облачных
хранилищах, прошедший
учет первого уровня.
2. Процент хранилищ в производственных общедоступных облачных хранилищах, прошедший учет первого уровня.

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

Глава 4. Учет данных

163

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

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

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

4.7.2. Второй уровень учета данных
На втором уровне маркировка гораздо более детализированная — на уровне столбца для структурированных данных (таких как база данных Hive) или на уровне объектов для неструктурированных данных (таких как хранилище S3 веб-сервисов
Amazon). Результатом учета на втором уровне будет маркировка всех столбцов в
хранилищах структурированных данных и всех объектов в хранилищах неструктурированных данных. Результаты и KPI учета данных второго уровня отражены в
табл. 4.5.
Таблица 4.5. Второй уровень учета данных
Источник данных

Результаты, которые должны
быть получены

KPI для измерения
прогресса

Базы данных (структурированные данные) в
дата-центрах

1. Общий объем данных (Тбайт/Пбайт)
для каждого экземпляра базы данных.

1. Процент от общего объема производственных данных в экземплярах баз данных, прошедший учет второго уровня.
2. Процент производственных столбцов и объектов,
прошедший учет первого
уровня.

2. Метки категорий классификации
данных по столбцам данных для каждого столбца.
3. Состав уровня производственных
данных в основных производственных
дата-центрах:
 процент от общего объема производственных данных, содержащий
наиболее конфиденциальные
данные;
 процент от объема производственных данных за вычетом конфиденциальных данных;
 процент от общего объема производственных данных, содержащий
общедоступные данные.

164

Часть II. Упреждающая программа защиты конфиденциальности: управление данными
Таблица 4.5 (окончание)

Источник данных

Результаты, которые должны
быть получены

KPI для измерения
прогресса

Хранилища в общедоступном облаке (неструктурированные
данные; в настоящее
время веб-сервисы
Amazon / Облачная
платформа Google)

1. Общий объем данных (Тбайт/Пбайт)
для каждого хранилища.

1. Процент от общего объема производственных данных в производственных
общедоступных облачных
хранилищах, прошедший
учет второго уровня.

2. Метки категорий классификации
данных для каждого объекта данных
(например, файла).
3. Состав уровня данных в рабочей
среде общедоступного облака:
 процент от общего объема производственных данных, содержащий
наиболее конфиденциальные
данные;
 процент от объема производственных данных за вычетом конфиденциальных данных;
 процент от общего объема производственных данных, содержащий
общедоступные данные.

2. Процент хранилищ в производственных общедоступных облачных хранилищах,
прошедший учет второго
уровня.

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

4.7.3. Третий уровень учета данных
Результат учета данных на третьем уровне следующий: при наличии некоторых
идентификаторов (UUID, имени, номера телефона, адреса электронной почты и
т. д.) пользователя базовая система должна возвращать указатели или ссылки на все
строки в каждом хранилище структурированных данных или на объекты в каждом
неструктурированном хранилище данных, содержащие данные пользователя.
Результаты и KPI учета данных третьего уровня очень похожи на представленные в
табл. 4.4 и 4.5, причем добавление индексированной базы данных тоже является
результатом учета, а не простой маркировкой.
Этот дополнительный шаг займет много времени, поэтому стоит разобраться, каковы стимулы для бизнеса, чтобы расставить приоритеты в учете данных.

Глава 4. Учет данных

165

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

доступ к персональным данным;
 поддержка таких функций, как удаление данных;
 получение информации о бизнесе.

Давайте рассмотрим их по очереди.

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

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

закции этого же пользователя могут не содержать UUID;
 он ищет в определенных таблицах Hive;
 он может идти очень медленно.

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

166

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

Кроме того, как показано на рис. 4.9, даже когда количество нарушений снижается,
злоумышленники по-прежнему могут увеличивать объемы похищаемых данных
(http://mng.bz/REev). С информацией, полученной в результате учета данных, вы
сможете нацелить инструменты конечного удаления на данные с наивысшей степенью конфиденциальности и место их хранения. Это позволит снизить вероятность,
что такие данные пострадают в результате взлома, и уменьшить влияние подобных
взломов, если они произойдут.

Рис. 4.9. Ежегодное количество утечек данных и выложенных
в открытый доступ записей в США с 2005 г. по первое полугодие 2020 г.

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

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

Глава 4. Учет данных

167

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

данных по мере роста компании?
 Насколько быстро растет объем конфиденциальных данных по сравнению с

данными в целом?
Кроме того, можно проанализировать источники данных и выяснить, какие отделы
ответственны за рост объемов данных и рисков.
Цифры могут указывать на решения:
 если цель состоит в снижении затрат и рисков, можно активизировать удаление

данных;
 если цель заключается только в управлении рисками, можно поделить данные на

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

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

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

168

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

Так вы сможете в динамическом режиме классифицировать облачные ресурсы и
использовать их собственную инфраструктуру меток для ускорения сопоставления
и анализа дублирований. Вместо того чтобы создавать поисковые боты и прочие
инструменты, вы сможете использовать возможности, которые продают эти облачные провайдеры, и получать больше за те деньги, что платите за хранение данных в
облаке.
Одна компания, которую я недавно консультировал, разработала внутренние процессы, чтобы понять структуру своих локальных и облачных хранилищ данных, а
также цель использования данных. Эти процессы помогли проанализировать данные и найти закономерности, а затем разметить информацию. Последующий учет
данных привел к созданию центральной защищенной платформы вместо электронной почты или электронных таблиц, которыми пользовались прежде.
Как я уже упоминал, усилия по защите конфиденциальности также помогают
удовлетворить другие требования бизнеса, особенно если они связаны с улучшением понимания и качества данных. Учет данных позволяет автоматически извлекать и сопоставлять истории данных из различных исходных систем и легко
поддерживать их в актуальном состоянии. Это поможет отслеживать данные, когда они проходят через системы, и применять к ним разные степени защиты конфиденциальности.
Кроме того, вы сможете просматривать косвенные отношения, влияющие на перемещение данных (условные операторы и соединения). Все это поможет скорректировать процесс защиты конфиденциальности данных. Например, если вы разрешите третьей стороне доступ к данным через API с целью их анализа, а затем поймете,
что эта третья сторона получает доступ к бо́льшим объемам данных, чем разрешено, либо использует их для рекламы, либо составления профиля, можно сразу же
урезать возможности, регулируя и ограничивая скорость API. Это даст вам единую
точку входа данных, и не придется закрывать несколько дверей. Победа с точки
зрения обеспечения конфиденциальности данных, а также вашей способности защитить корпоративные IP-адреса от утечки.
Подробная техническая история данных, отследить которую станет возможно благодаря их учету, позволит вам добраться до конкретной таблицы, столбца и запроса
в истории, просматривать преобразования и перемещаться по конвейерам данных.
Это поможет понять, каким образом различные изменения функций и работы отрасли в целом повлияли на данные — как с точки зрения их ценности для бизнеса,
так и с точки зрения защиты конфиденциальности.

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

Глава 4. Учет данных

169

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

вится непомерно дорого?
 Что вы делаете, когда возможности по удалению данных в требуемом масштабе

оказываются ничтожны по сравнению с объемом данных?
 Когда наступит переломный момент, и вы перестанете искать данные, припря-

танные хитроумными инженерами?
 Как защита конфиденциальности способствует повышению качества данных —

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

Резюме
 Учет данных — важный элемент управления данными и дополнение к процессу

их классификации.
 Учет данных помогает применить к данным классификацию и таким образом

обеспечивает проектируемую конфиденциальность.

170

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

 Учет данных включает в себя автоматизацию на уровне данных и инфраструк-

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

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

щих измерить эффективность учета данных.

- ГЛАВА 5 -

Совместное использование данных

В этой главе мы рассмотрим:
 зачем компаниям делиться данными;
 как совместное использование данных может создать риски для конфиденци-

альности;
 какие есть методы снижения рисков конфиденциальности при совместном ис-

пользовании данных;
 как измерить риски конфиденциальности до и после применения методов ее за-

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

172

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

5.1. Совместное использование данных:
зачем компаниям ими делиться
Прежде чем приступить к обсуждению совместного использования данных с точки
зрения компании, вспомните, когда вы в последний раз обращались в какую-либо
организацию за услугой как клиент. Допустим, вам нужно было проверить свой
банковский счет, и вы решили не идти в отделение банка и не звонить представителю службы поддержки клиентов, а проверить счет онлайн. Чтобы получить к нему
доступ, вам потребуется следующая информация:
 номер вашего банковского счета (предполагается, что у вас уже есть счет в банке);
 адрес электронной почты, который будет служить онлайн-логином;
 информация, позволяющая установить личность (номер карточки социального

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

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

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

Глава 5. Совместное использование данных

173

5.1.1. Совместное использование данных: службы такси
Если вы вызываете машину с помощью приложения такси или сервиса поиска попутчиков, возможно, даже вероятно, что приложение обменивается какими-то данными с городом, где вы находитесь. Такой обмен данными также может происходить со службами такси или другими поставщиками транспортных услуг:
 городским планировщикам и регулирующим органам необходим доступ к данным

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

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

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

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

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

вать использование данных и ограничить его этим сценарием;

174

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

 защищайте данные на этапе передачи (когда они перемещаются из системы

службы такси к получателю);
 обеспечьте проверяемый контроль доступа даже после того, как данные покинут

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

5.1.2. Совместное использование данных:
интернет-реклама
Онлайн-реклама — самый распространенный и самый сложный пример совместного использования данных в Интернете. Многие из нас привыкли видеть в Интернете рекламу, которая словно угадывает, какие товары мы в последний раз покупали
или просматривали; то есть объявления, ориентированные на нас на основе нашего
поведения. Руководители компаний должны довольно хорошо понимать, кто является ключевыми игроками в экосистеме онлайн-рекламы и как между ними передаются данные. Это понимание поможет инженерам принимать разумные решения
в отношении обмена данными, а также гарантирует, что многообещающий поток
доходов не станет причиной неправомерных действий в отношении конфиденциальности.
Как и в случае со службой такси, я специально выбрал пример с рекламой. Далее
вы более подробно узнаете, как работает рекламная экосистема, а я демистифицирую некоторые понятия. Позже мы вернемся к теме рекламы и изучим элементы
управления защитой конфиденциальности, которые делают обмен данными в этой
сфере более безопасным с точки зрения конфиденциальности.
Рис. 5.1, заимствованный из материалов исследования, проведенного Фондом борьбы
с нарушением конфиденциальности и гражданских свобод с помощью электронных
технологий (англ.: EFF — Electronic Frontier Foundation), показывает, как выглядит
экосистема онлайн-рекламы (www.eff.org/wp/behind-the-oneway-mirror#Part3).
Чтобы понять рис. 5.1, необходимо уточнить некоторые определения:
 Издатель — веб-сайт, который может посетить пользователь и на котором мо-

жет быть показана реклама. Например, веб-сайт газеты New York Times является
издателем.
 Платформа на стороне предложения (англ.: SSP — supply-side platform) — рек-

ламная сеть, которая помогает решить, какой именно рекламодатель может разместить объявление на веб-сайте, чтобы пользователь его увидел.
 Платформа на стороне спроса (англ.: DSP — demand-side platform) — компа-

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

Глава 5. Совместное использование данных

175

Для данного примера предположим, что у вас есть веб-сайт, на котором будут отображаться рекламные объявления, то есть вы — издатель. Мы рассмотрим поток
данных с точки зрения пользователя, который просматривает Интернет.
1. Пользователь заходит на сайт www.website.com (см. рис. 5.1). Данные передаются от браузера пользователя в рекламные сети, также известные как платформы
на стороне предложения (SSP). Процесс рекламирования начнется, когда рекламные сети соберут данные с браузера и устройства. Эти данные неизбежно
попадают в рекламные сети, которые представляют сторону предложения рекламной экосистемы. Этот поток нужен, чтобы облегчить показ персонализированной рекламы пользователю.

Рис. 5.1. Экосистема интернет-рекламы (по Cyphers and Gennie Gebhart,
«Behind the One-Way Mirror»; диаграмма распространяется под лицензией
Creative Commons, https://creativecommons.org/licenses/by/3.0)

2. SSP должна персонализировать взаимодействие пользователя с рекламой, и это
достигается с помощью cookie-файлов, которые содержат идентифицирующую

176

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

информацию. Тут обмен данными начинается всерьез, но пользователь может
этого даже не заметить. Руководители обязательно должны это понять, ведь
многие инженеры часто полагают, что обмен данными означает только сознательное размещение данных. В действительности значительный объем обмена
данными инициируется программным обеспечением, которое работает в фоновом режиме.
3. SSP должна привлечь рекламные объявления, настроенные по информации
пользователя, и для этого она генерирует запрос о предложении. Этот запрос
сродни призыву, обращенному к рекомендуемым объявлениям, которые предназначены для привлечения пользователя на основе его прошлого поведения. Благодаря этому «запросу» SSP сообщает рекламодателям, что существует пользователь с определенными характеристиками (на основе информации, содержащейся в cookie-файле) на сайте www.website.com, и ему можно показать рекламу.
4. SSP отправляет этот запрос о предложении рекламодателям, у которых есть объявления для показа, тем самым завершая сторону предложения этого обмена
данными. Если возникает совпадение, и на веб-странице отображается реклама,
издатель получает доход, выплачиваемый ему рекламодателем. За показ пользователю рекламы конкурируют несколько рекламодателей, поэтому SSP проводит аукцион, и победитель этого аукциона получает право показывать пользователю свою рекламу.
Объявление, которое показывается пользователю, и сам факт показа зависят от содержания запроса о предложении. Он позволяет потенциальным рекламодателям
оценить, стоит ли показывать рекламу конкретному пользователю. Запрос о предложении содержит некоторые конфиденциальные данные — такие как сведения о
местоположении, интересах, данные устройства, а также уникальный ID, который
может идентифицировать пользователя в целом (см. рис. 5.2, диаграмма распространяется под лицензией https://creativecommons.org/licenses/by/3.0).
Эта информация позволяет рекламодателям решить, стоят ли запрос о предложении
и содержащиеся в нем данные тех денег, которые они потратят на показ рекламы
пользователю. Однако, в связи с растущим вниманием к защите конфиденциальности, мне нравится напоминать людям, что запрос о предложении — не абстрактная
программная единица. За этими данными стоит реальный человек, и этот человек
заслуживает конфиденциальности и прозрачности, ведь передаются именно его
данные.
Это подводит нас к концу процесса, когда реклама показывается пользователю. У
рекламодателей теперь есть выбор: размещать рекламу или нет. Проще говоря, рекламодатель, который потенциально мог бы показать объявление, обычно сначала
изучает данные пользователя и сопоставляет их с объявлением. В большинстве
случаев он решает проверить релевантность объявления и протестировать его —
возможно, опираясь на прошлые показатели или оценку на основе машинного обучения. Затем, если он решит показать рекламу, то сообщит свою ставку на SSP. На
следующем этапе SSP выберет победившую ставку, которая в большинстве случаев
будет содержать самую высокую цену, и отобразит объявление.

Глава 5. Совместное использование данных

177

Рис. 5.2. Атрибуты запроса о предложении (по Cyphers and Gennie Gebhart,
«Behind the One-Way Mirror»; диаграмма распространяется под лицензией Creative Commons,
https://creativecommons.org/licenses/by/3.0)

В упрощенной форме данный процесс показан на рис. 5.3.

Рис. 5.3. Таким образом реклама в итоге демонстрируется пользователю
(по Cyphers and Gennie Gebhart, «Behind the One-Way Mirror»; диаграмма распространяется
под лицензией Creative Commons, https://creativecommons.org/licenses/by/3.0)

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

178

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

передается до перевода оплаты. Рекламодатели, не выигравшие аукцион, все равно
получают личную информацию пользователей. Некоторые компании могут притворяться, что хотят показать объявление, но намеренно делают низкие ставки и
проигрывают во всех аукционах, чтобы собрать как можно больше данных, заплатив как можно меньше.
Адресный показ рекламы крайне важен для онлайн-бизнеса, поскольку помогает
показывать объявления людям с подходящими предпочтениями и личными данными. Однако с точки зрения пользователя он несет в себе определенные риски защиты конфиденциальности. Если пользователю адресно показывается объявление, то,
вероятно, есть брокеры данных и другие организации, у которых в хранилищах
имеются данные об этом человеке. Эти данные оказываются доступны игрокам в
рекламной экосистеме и помогают скорректировать запрос о предложении. Большинство действий происходят без прямого одобрения владельца данных. Подобное
отсутствие свободы выбора — первый удар по защите конфиденциальности.
Второй удар связан с сохранением данных о пользователе и ростом их объема. Независимо от того, чье объявление покажут пользователю (если вообще покажут),
данные, которые собирают компании через запрос о предложении ставки, остаются
у них, а также их можно в будущем дополнить данными из других источников. Подобные рост и распространение данных затрудняют их удаление и извлечение.
Способность пользователей защитить свою конфиденциальность снижается, потому что их данные находятся в слишком большом количестве мест.

5.1.3. Конфиденциальность в рекламе
В предыдущем разделе обсуждался ряд рисков конфиденциальности, присущих
интернет-рекламе. Здесь я хочу дать несколько советов по управлению конфиденциальностью, которые могли бы помочь компаниям использовать данные о поведении пользователей для предоставления значимой рекламы.
Для многих компаний способность адресно обращаться к своим актуальным или
потенциальным клиентам с помощью рекламы зависит от данных. Эти данные
представляют собой комбинацию сведений о поведении, выведенных в результате
отслеживания активности пользователей на сайте компании, а также информации о
похожих пользователях. В последнем случае логика очень схожа с той, которой
придерживается компания Netflix, предлагая на своей веб-странице раздел «Люди,
которые посмотрели этот фильм, также смотрели…».
Компании, размещающие рекламу, обычно строят граф персоналий, представляющий собой список отличительных черт, характерных для клиентов или пользователей, которым они хотят показывать рекламу. Рассмотрим такого гипотетического
пользователя:
 пользователь А имеет идентификатор Google AAA@gmail.com и использует его

для входа на сайт газеты New York Times;
 пользователь

A также использует другой адрес электронной почты,
AAAA@yahoo.com, для входа в свою учетную запись в социальной сети Face-

Глава 5. Совместное использование данных

179

book (продукт корпорации Meta Platforms Inc., которая признана экстремистской организацией на территории РФ);
 у пользователя А есть учетная запись на сайте сервиса потоковой передачи, где

он использует адрес электронной почты ААА@email.com.
Предположим, сервис потоковой передачи хочет настроить адресный показ пользователю А рекламы новых фильмов своего каталога так, чтобы он видел объявления,
когда просматривает веб-сайты. Как видно из примера выше, у пользователя может
быть несколько адресов электронной почты, которые он использует в качестве логинов. На этот случай сервис потоковой передачи будет поддерживать граф персоналий, содержащий все адреса электронной почты пользователя А.
Это важно, ведь когда сервис потоковой передачи захочет показать рекламу пользователю А, он может использовать график для доступа ко всем онлайнидентификациям А и связанным с ними данным о поведении. Тогда, если пользователь А зайдет в приложение или на сайт New York Times, либо в приложение или
на сайт социальной сети, компания потоковой передачи сможет адресно показать
ему рекламу. Этот процесс сбора идентификационных данных пользователя для
построения графа и последующего таргетинга рекламы требует обмена данными в
огромных объемах.
Предположим, вы отвечаете за повышение защиты конфиденциальности в компании, занимающейся потоковой передачей. Вы можете предпринять следующие действия:
 создать хешированную версию идентификатора на своем веб-сайте и сопоста-

вить ее с оригинальным идентификатором. В предыдущем примере это будет
сопоставление адресов AAA@gmail.com и hash(AAA@gmail.com);
 можно отнести пользователя к более крупным категориям зрителей (например,

пользователей, которые ищут триллеры; пользователей, которые просматривают
DVD со Спенсером Трейси и т. д.), чтобы показывать им объявления, которые
будут не слишком индивидуальны, но при этом актуальны. Например, если мне
чуть больше 30 лет, и я время от времени ищу в Интернете беговые кроссовки,
то совершенно нормально прислать мне адресно рекламу кроссовок перед Новым годом (когда люди принимают решения вести здоровый образ жизни), если
я являюсь частью группы похожих пользователей, на которых нацелена реклама.
Если же рекламная кампания идентифицирует меня лично — это одновременно
жутко и потенциально незаконно. Таргетинг должен быть ориентирован на
группу — например, пользователей, интересующихся беговыми кроссовками, а
не на профиль, скажем, конкретного пользователя, который купил кроссовки
полгода назад, и теперь ему пора приобретать новые;
 в графе персоналий можно установить флажок отказа. Когда пользователь, вой-

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

180

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

Хеширование идентификаторов
В Интернете можно найти немало информации о хешировании, но в рамках данной темы хеширование позволяет создать версию исходного контента (адрес электронной
почты в нашем случае), которая передается только в одну сторону. То есть при правильном алгоритме можно вывести хешированное значение из исходного адреса электронной почты, но нельзя получить исходный адрес электронной почты из хешированного значения.
Например, предположим, что вы хешируете адрес nishant@hotmail.com и в итоге получаете 22344. С этого момента каждый раз, сталкиваясь с адресом nishant@hotmail.com,
вы сможете сопоставить его с 22344. Это означает, что вы можете сопоставить версию
логина пользователя, используемого для его действий на вашем веб-сайте, с более
безопасной для конфиденциальности хешированной версией. Последнюю можно использовать для передачи данных. Как видите, с помощью идентификатора вроде
nishant@hotmail.com можно получить другие данные о пользователе или даже связаться с ним, тогда как преобразованная (хешированная) версия 22344 обеспечивает более
надежную защиту конфиденциальности.
Такой подход позволяет разделить личность пользователя и его действия на вашем
сайте, знание о которых поможет подобрать для него рекламные объявления.

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

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

5.2.1. Отслеживание президента Трампа
Издание New York Times первым занялось этим в рамках своего проекта защиты
конфиденциальности (http://mng.bz/2joa). Мы же сосредоточимся на последствиях
передачи приложениями на вашем устройстве данных о вашем местонахождении.

Глава 5. Совместное использование данных

181

Исследование, проведенное New York Times, показало, что с приложениями на вашем телефоне, которые делятся данными в режиме реального времени, можно отследить кого угодно. Хоть президента Соединенных Штатов. В рамках проекта защиты конфиденциальности издание New York Times получило набор данных с более чем 50 миллиардами местоположений с телефонов более 12 миллионов
жителей США (http://mng.bz/1j6q). Согласно New York Times, это была случайная
выборка за 2016 и 2017 годы.
Большинство онлайн-пользователей осознают, что отчасти приложения определяют
местоположение в сети с целью персонализации. Однако часто бывает трудно понять общую картину, поэтому пример будет кстати.
В рамках того проекта New York Times смогли использовать общедоступную информацию для деанонимизации и последующего отслеживания местонахождения и
перемещений президента Трампа.
Если вам любопытно самим увидеть передвижения президента, которые отследили
журналисты, карта доступна по адресу http://mng.bz/2joa.
Сотрудники смогли проследить передвижения президента, потому что при нем был
мобильный телефон, и на этом телефоне, вероятно, работало приложение, которое
передавало координаты телефона.
На карте начало трека обозначало местонахождение президента в клубе «Мар-аЛаго» во Флориде. С этого момента местонахождение президента можно было легко зафиксировать. Следующей остановкой был президентский гольф-клуб, и здесь
сила отслеживания местоположения выходит на первый план. В открытом графике
президента обычно указаны встречи, и в данном случае он встречался с премьерминистром Абэ из Японии. Объединение данных о местоположении президента с
его открытым расписанием позволило изданию отслеживать не только президента,
но и премьер-министра Японии.
Затем они смогли отследить президента, когда он обедал в ресторане Международного гольф-клуба Трампа и, наконец, когда он вернулся на рабочий ужин с премьер-министром Абэ.
Само по себе это уже весьма интересно (или неприятно, как посмотреть), но отслеживание также позволило идентифицировать устройство, передававшее координаты.
Устройство (точнее, установленное на нем приложение) также транслировало данные о местоположении в ближайший полевой офис Секретной службы.
Это позволило журналистам идентифицировать владельца устройства и точно определить его место работы и домашний адрес. Полученная информация в сочетании с общедоступными сведениями помогла узнать подробности о семье владельца
устройства.
Данный случай невольной передачи данных о местоположении, идентификации
себя с дальнейшим раскрытием биографической информации не уникален и не
единичен. Такое может случиться с каждым, кто использует мобильное устройство,
передающее данные на сервер. Вот почему для защиты данных от нарушения конфиденциальности необходимы элементы управления безопасностью.

182

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

5.2.2. Защита передаваемых данных
Как отмечалось выше, компании используют все больше и больше данных, и процесс становится неструктурированным. Это затрудняет возможность идентификации, обнаружения и защиты данных, а также негативно сказывается на защите конфиденциальности. Вот почему крайне важно иметь эффективные средства защиты
конфиденциальности для передаваемых данных (после того, как они покинут системы вашей компании и до того, как попадут в руки получателей).
Здесь наблюдается интересное пересечение сфер обеспечения безопасности и конфиденциальности. Если кто-то перехватит данные, пока они находятся в динамике
между двумя системами, нарушение безопасности почти неизбежно приведет к
ущербу для конфиденциальности. Мы обсудим, как уменьшить эффект от ущерба
конфиденциальности с помощью методов обфускации данных перед передачей.
Кроме того, рекомендуется снизить вероятность того, что данные окажутся перехвачены. Для этого применяются определенные элементы управления.
Стратегии обеспечения безопасности следует разрабатывать в сотрудничестве со
службой безопасности, но для начала мы рассмотрим базовый перечень. Он является отправной точкой, а эксперты по безопасности могут порекомендовать более
новые или удобные инструменты.
Для данных с наивысшим уровнем конфиденциальности, пересылаемых с помощью электронной передачи, рекомендуется следующее:
 данные в идеале должны подвергаться сквозному шифрованию при передаче на

уровне служб с взаимным протоколом TLS, если это технически возможно. Если
взаимный протокол TLS невозможен, следует попытаться использовать обычный протокол SSL/TLS, так как незашифрованный протокол HTTP может представлять угрозу безопасности;
 не позволяйте передавать данные по электронной почте, поскольку электронная

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

Глава 5. Совместное использование данных

183

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

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

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

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

воров и законодательства, касающиеся передачи данных, особенно если эта передача — транснациональная;
 убедиться, что вы понимаете влияние копирования данных на передачу, ведь

каждая копия данных может повысить степень риска;
 убедиться, что в работе участвуют все команды разработчиков продукта и ин-

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

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

184

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

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

Контроль доступа как инструмент защиты конфиденциальности
Управлять доступом к конфиденциальным данным помогают следующие инструменты аутентификации и авторизации:
 требование использования уникального идентификатора, предоставляемого работодателем (например, адреса электронной почты или ID пользователя), и пароля для аутентификации всей связанной с работодателем информации, ресурсов,
сетей и данных. Один и тот же пароль можно использовать только для одной
учетной записи (например, пароль для управления идентификацией и доступом
должен отличаться от пароля GitHub, если у вас нет системы единого входа);
 любые пароли рабочих учетных записей пользователей, секретные данные,
криптографические ключи, токены, ключи API и другие конфиденциальные материалы не должны регистрироваться или храниться в открытом виде в исходном коде или любом другом неутвержденном инструменте, в том числе на редактируемых страницах, в Документах Google, электронных таблицах, аналитических событиях, локальных рабочих станциях для разработчиков и т. д.;
 пароли и механизмы аутентификации должны удовлетворять следующим требованиям (если иное не оговорено требованиями о соответствии нормативным актам, законам или иным юридическим документам):
 не содержать имя учетной записи пользователя;
 быть не менее восьми символов;
 содержать символы как минимум трех из перечисленных ниже категорий: заглавные буквы латинского алфавита (от A до Z), строчные буквы латинского
алфавита (от a до z), основные числа (от 0 до 9), неалфавитные символы
(!@#$%^&*()_+|~=\{}[]:";'<>?,./) или любой символ кодировки Unicode, который классифицируется как буквенный, но не является ни прописным, ни
строчным;
 пароли не должны содержать слова, похожие на имена пользователей, словарные слова, сочетания клавиш или замены символов на числа;
 нужно блокировать пользователей не менее чем на 30 минут после шести неудачных попыток входа в систему;
 для среды взаимосвязи периферийных компонентов или при отсутствии многофакторной аутентификации пароли должны меняться не реже одного раза в
90 дней;

Глава 5. Совместное использование данных

185

 экстренный доступ (например, с полномочиями администратора или rootдоступ) к рабочим компьютерам должен требовать многофакторной аутентификации и быть ограничен по времени (не более 20 часов);
 следует настроить тайм-ауты простоя для информационных ресурсов так,
чтобы они не превышали 30 минут и требовали повторной аутентификации
для активации сеанса связи после бездействия;
 в паролях и секретных ключах на управляемых информационных ресурсах
нельзя использовать установленные поставщиком значения по умолчанию, и
они должны соответствовать вышеупомянутым требованиям.
Как уже говорилось, при демократизированном и разрозненном процессе разработки инженеры часто могут собирать и хранить данные как пожелают. Такие хранилища данных — как бомба замедленного действия, а наличие нескольких копий
конфиденциальных данных означает, что у вас несколько таких. Конечно, разумнее
не допускать этого вообще, но если они уже есть, крайне важно управлять доступом к этим данным, чтобы кто-то случайно не «поджег фитиль». Управление доступом в определенной степени помогает достичь этой цели, а представленный выше список является основой, которую можно развивать в зависимости от степени
подверженности ваших данных внешнему воздействию и риску.

Шифрование как инструмент защиты конфиденциальности
Подобно тому, как доступом к данным управляют, используя механизмы контроля
доступа, данные можно изменять таким образом, чтобы злоумышленник, если
вдруг получит к ним доступ, не смог бы нанести большого ущерба. Один из инструментов для этого — шифрование. Хотя данная книга посвящена защите конфиденциальности и ее задачей не является углубление ваших знаний в области шифрования, в этом разделе рассказывается, как использовать данный способ для предотвращения ущерба конфиденциальности.
Предположим, что конкретная угроза конфиденциальности, которую вы хотите
устранить, связана с тем, что кто-то, помимо предполагаемого получателя конфиденциальных данных, может расшифровать и использовать эти данные в открытом
виде. Чтобы защититься от угрозы, необходимо убедиться, что любая компрометация служебной учетной записи с правами доступа для чтения или записи сегмента
(где «сегмент» относится к единице хранения в системе облачных вычислений —
например, Amazon Web Services) или служб учетной записи (у третьей стороны,
например, провайдера общедоступного облачного хранилища) с доступом для чтения сегмента, не поставит под угрозу данные.
Для этого необходимо убедиться, что данные защищены с помощью шифрования
на стороне клиента. Шифрования на стороне сервера недостаточно, так как к учетной записи на самом сервере может быть получен несанкционированный доступ.
Следует убедиться, что данные защищены криптографически, до того, как они попадут на сервер.

186

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

П РИМЕЧАНИЕ
Ваши специалисты по безопасности могут предоставить более подробную информацию, но шифрование на стороне клиента — это действие по шифрованию данных перед их передачей с пользовательского устройства на сервер.

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

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

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

ваны, помните:
 ошибки в архитектуре, политике или кодировании могут раскрыть ваши секреты;
 партнеры могут быть ненадежными (из-за недобросовестных сотрудников,
подрядчиков или ошибок конфигурации сети — преднамеренных или случайных);
 добейтесь согласованности действий всех заинтересованных участников компа-

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

Глава 5. Совместное использование данных

187

 управление ключами защиты играет важнейшую роль, когда речь идет о шифро-

вании:
 ключи шифрования необходимо регулярно менять, поскольку криптографические алгоритмы постоянно анализируются, и в них могут быть обнаружены
уязвимости;
 симметричные и закрытые ключи необходимо хорошо защищать;
 открытый ключ, при его наличии, необходимо хранить в виде сертификата
для предотвращения атак с целью его перехвата;
 как уже упоминалось, шифрование необходимо настроить с учетом состояния
данных:
 данные в состоянии покоя в идеале требуют шифрования конвертов — устанавливается иерархия ключей. Никогда не шифруйте все данные в базе данных одним и тем же ключом;
 для данных в динамике может потребоваться протокол HTTPS/TLS. Данные с
высоким уровнем конфиденциальности должны быть всегда зашифрованы,
даже если они передаются через зашифрованное соединение. Можно рассмотреть альтернативные способы защиты данных, такие как протоколы
SFTP, IPSEC и т. п.
Далее мы выясним, как сделать сами данные менее заметными на случай, если инструменты безопасности, такие как шифрование, не сработают во время обмена
данными.

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

188

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

Я был бы, мягко говоря, неприятно удивлен, если бы при оценке приложения для
подбора попутчиков выяснил бы, что оно предоставляет для совместного использования следующие данные:
 отслеживание поездки в режиме реального времени от начала до конца;
 точные координаты начала и конца поездки (далее в этой главе вы увидите, как
фитнес-приложение идентифицировало военнослужащих даже с неточными
данными о местоположении);
 отсутствие правил защиты конфиденциальности со стороны лица, получающего
эти данные.
Произошедший обмен данными невозможно отменить. А что касается служб такси,
вашего имени и местонахождения может быть достаточно, чтобы идентифицировать и найти вас. Когда служба такси передает данные о местонахождении и другие
чувствительные сведения третьему лицу, невозможно узнать, что будет делать с
ними получатель или насколько качественно они будут защищены.
Однако речь не только о компаниях и о том, как они бьются над этими проблемами.
Давайте рассмотрим пример, когда конфиденциальность отошла на второй план,
как только дело коснулось вооруженных сил Соединенных Штатов.

5.3.1. Обмен данными и национальная безопасность США
Strava, приложение для отслеживания физической активности, использует спутники для записи пробежек своих пользователей, поездок на велосипеде и других тренировок (http://mng.bz/PWmR). Оно также открывает доступ ко многим из этих
маршрутов в сервисе Global Heatmap, показывающем, где бегают и ездят на велосипедах люди во всем мире (https://labs.strava.com/heatmap).
Эта интересная функция в конечном итоге стала причиной неприятностей для компании Strava и американских военных. Военнослужащие записывали свои пробежки по территории военных баз. Эта информация попала на тепловую карту Strava, и
местоположение баз было нечаянно раскрыто.
Пользователи Твиттера сообразили, что могут идентифицировать контуры и шаблоны активности на военных базах США в Сирии, Афганистане и Сомали. Самый
большой потенциальной угрозой было не местонахождение самих баз, которое и
так известно, а раскрытие происходящего на их территории и вокруг. Карта показывала характер активности внутри и вокруг базы, выдавая маршруты снабжения и
патрулирования, а также точное расположение объектов, таких как столовые и жилые помещения. Кроме того, пользователи могли получать данные о местоположении, что позволило связать активность карты с определенными профилями. В результате можно было бы узнать, кто из военнослужащих находился в том или ином
месте в конкретный момент.
Strava ответила, что все пользователи могут скрыть свои действия, и они не будут
отображаться на тепловой карте. Технически это объяснение верно, но когда дело
доходит до обеспечения безопасности и конфиденциальности, за результат ответственны компании, создающие продукты, а не пользователи.

Глава 5. Совместное использование данных

189

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

Strava?
 Можно ли изменить данные, чтобы сделать их менее идентифицируемыми, ко-

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

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

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

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

190

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

Рис. 5.4. Чем выше точность данных, тем короче срок хранения

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

Глава 5. Совместное использование данных

191

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

минимум 5-анонимными или ε (эпсилон) = 1,6 дифференциально-частными;
 данные в массиве общих данных должны быть, по крайней мере, 100-анонимны-

ми или ε = 4,6 дифференциально-частными.
Как видите, в первых двух пунктах сроки хранения можно настроить на основе
точности данных. Третий и четвертый пункты связаны с концепциями, которые мы
обсудим далее. В двух словах, при огрублении данных с целью сделать их менее
идентифицируемыми, можно измерить влияние этих изменений на защиту конфиденциальности. Здесь применяются значения k-анонимность и l-разнообразие. Это
объективные концепции, основанные на данных и помогающие обеспечить конфиденциальность.

5.3.3. Анонимизация данных:
взаимосвязь между точностью и доступом
Если существует обратная зависимость между точностью данных и сроком их хранения, должно быть аналогичное обратное отношение между точностью и доступностью.
Делясь данными с партнером, нужно настоять, чтобы он анонимизировал данные в
памяти, особенно если вы делитесь детализированными данными. Можно применить следующие техники:
 не сохранять данные, используемые исключительно для обобщения;
 хранить данные отдельных пользователей в памяти, а на диск сохранять только

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

ными;

192

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

чом (например, HMAC-SHA256).
В контексте работы служб такси мы обсуждали потенциал данных, идентифицирующих личность клиента и его местонахождение. Подобно тому, как мы удаляем
идентификаторы, раскрывающие личность клиентов, и заменяем их внутренними
идентификаторами, существуют методы, позволяющие скрыть данные о местоположении:
 округлить время до ближайшего 30-минутного приращения (например, 12:25

округлим до 12:30);
 преобразовать координаты GPS в отрезок улицы начало/центр/конец;
 сократить GPS-координаты до трех знаков после запятой — это критично, так

как меньшее количество чисел после запятой в десятичной дроби в местоположении GPS снижает точность определения местоположения.
Читателям, не имевшим дело ранее с точностью данных о местоположении, процесс может показаться трудоемким, особенно учитывая объем данных, генерируемых приложениями и потребляемых компаниями. Будет полезно разобраться, каким образом огрубление может изменить данные и сделать их более безопасными с
точки зрения конфиденциальности.
Предположим, у вас есть таблица с двумя записями:
 поездка A: началась в 12:22 и закончилась в 13:09;
 поездка B: началась в 12:24 и закончилась в 13:11.

Ключевой пример ущерба для конфиденциальности — возможность однозначно
идентифицировать человека и/или его деятельность. Если вам нужно поделиться
этими данными для анализа, они будут нести в себе риск нарушения конфиденциальности, так как позволяют определить, кто совершил каждую из поездок на основе времени их начала, окончания и других общедоступных данных. Цель огрубления данных состоит в том, чтобы сделать любые два уникальных действия более
похожими, чтобы снизить вероятность того, что инженер или автоматизированный
процесс идентифицируют их как уникальные.
Если округлить время в предыдущем примере до ближайшего получаса, записи будут выглядеть так:
 поездка A: началась в 12:30 и закончилась в 13:00;
 поездка B: началась в 12:30 и закончилась в 13:00.

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

Глава 5. Совместное использование данных

193

пы, сформированные на основе определенных параметров. Если вам не нужно точно знать время начала каждой поездки, можно создать группы с интервалом в час
(14:00, 15:00 и 16:00). Точные данные не нужны, если мы знаем, к какой группе относится поездка. Кроме того, при указании точного времени начала поездки еще
сохраняется риск, что пассажиров можно будет идентифицировать, особенно с помощью внешних данных.
Таким образом, если речь идет об анализе, то вместо левого столбца с отдельными
поездками, идентифицированными по времени их начала, можно использовать
данные правого столбца, где поездки сгруппированы по часу начала. Левый столбец представляет собой оперативную версию данных, а правый — архивный учет
данных. Первый можно использовать, когда требуется более детальная информация
(например, чтобы узнать конкретное время начала поездки, если это необходимо
для службы поддержки клиентов, возмещения и т. д.); в других случаях можно использовать данные из правого столбца.

Рис. 5.5. Обобщайте данные для защиты конфиденциальности

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

194

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

оценку протоколов совместного использования данных, я требую контроль доступа, чтобы убедиться, что как только партнер получает данные, он контролирует,
кому на его стороне они доступны. На практике я добиваюсь этого следующим образом: прошу партнера ограничить в пользовании его API людей, желающих получить доступ к данным.
Мои команды внедрили инструменты для проверки того, действительно ли инженерам и специалистам по обработке данных все еще необходимы конфиденциальные зашифрованные данные, к которым они имеют доступ. Мы регулярно делали
выборку данных и проверяли, когда их расшифровывали в последний раз. Часто мы
обнаруживали, что команды запрашивали ключи, но очень редко пользовались ими
или не пользовались совсем.
В таких случаях мы меняли ключи, чтобы проверить, начнут ли инженеры жаловаться. В семидесяти пяти процентах случаев никакой реакции не поступало. То
есть люди часто думают, что им понадобится больше данных, чем оказывается на
самом деле. И даже если данные не используются, возможность доступа к ним несет в себе риск для конфиденциальности. Подобные методы рекомендуется применять как внутри компании, так и при совместном использовании данных.
Как можно было заметить, в предыдущих главах и разделах речь шла об управлении
доступом при помощи инструментов, но когда дело доходит до обмена данными, мы
применяем более комплексный подход. Мы внедрили политики и изменили данные,
чтобы уменьшить объем данных, к которым имеют доступ поставщики и партнеры, а
также снизить их точность. Такое изменение является критически важным.
Говоря о сотрудниках компании, можно быть более уверенным в том, что средства
контроля доступа вкупе с аудиторскими проверками смогут смягчить ущерб, наносимый конфиденциальности. Внешние партнеры могут иметь доступ к другим данным, позволяющим однозначно идентифицировать пользователя, а их возможности
проверки того, кто получает доступ к данным и как их используют, могут быть неоптимальными. Следовательно, не стоит надеяться лишь на средства управления
доступом. Рекомендуется огрубить данные так, чтобы даже если кто-то получит к
ним доступ и объединит их с другими данными, ущерб конфиденциальности можно было бы локализовать.

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

Глава 5. Совместное использование данных

195

не управлять доступом к таблице, внутренние и внешние исполнители с ее помощью запросто свяжут внешние данные с внутренними.
Рассмотрим пример. В табл. 5.1 приведены данные службы такси, которая сохраняет сведения о поездке, связанные с паспортными данными клиентов. Я понимаю,
что компании такси обычно не собирают номера паспортов, но предположим, что в
нашем примере так делают.
Таблица 5.1. Данные о поездке, сопоставленные с номерами паспортов
Номер паспорта

Время начала поездки

Время окончания поездки

5037678987

13:00

14:00

3239892821

14:00

16:00

2398753116

12:00

16:00

3873736111

11:00

11:00

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

Внутренний идентификатор

5037678987

ghsvfydvbdv

3239892821

hgavdchgdfe

2398753116

dhbchchvhge

3873736111

wdjhpdjdiehf

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

Время начала поездки

Время окончания поездки

ghsvfydvbdv

13:00

14:00

hgavdchgdfe

14:00

16:00

dhbchchvhge

12:00

16:00

wdjhpdjdiehf

11:00

11:00

196

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

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

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

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

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

Глава 5. Совместное использование данных

197

Внешнее раскрытие внутренних идентификаторов пользователей может создать риски идентификации, даже если эти идентификаторы не связаны с данными, идентифицирующими личности пользователей. Поскольку некоторые из этих идентификаторов долговечны и не меняются в течение срока существования, раскрытие их сторонним организациям может позволить отследить одних и тех же пользователей в
нескольких наборах данных спустя продолжительное время (причем это может быть
доступно как одной организации, так и, — что еще хуже, — нескольким, если наборы данных были в них общими или оказались раскрыты в результате утечки).
Как правило, внутренние идентификаторы никогда нельзя раскрывать в наборе
данных при обмене со сторонними организациями. Их следует псевдонимизировать
таким образом, чтобы исходный идентификатор невозможно было восстановить из
псевдонима, но при этом сохранялась согласованность между значениями набора
данных. Кроме того, если хешированные внутренние идентификаторы будут раскрыты извне и, следовательно, взломаны, хеширование перед обменом данными
может позволить вам определить, какой поставщик причастен к нарушению.
П РИМЕЧАНИЕ
Псевдонимизация — это метод деидентификации, при котором данные системно заменяются суррогатами (также известными как токены). Она отличается от других методов деидентификации, таких как редактирование входных данных или обобщение
тем, что суррогаты сохраняют свойства ссылок в деидентифицированном наборе данных. Кроме того, зная преобразование, используемое для производства суррогатов,
авторизированный пользователь может превратить их обратно в исходные конфиденциальные значения. Примерами псевдонимизации являются шифрование и безопасное хеширование.

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

5.4.1. Сценарий использования № 1:
минимальная сессия (без связи видов деятельности пользователя)
Как пользователь данных о клиентах, вы будете применять этот подход, чтобы поделиться наименьшими элементами данных в наборе. Например, допустим, вы
управляете сайтом интернет-магазина и обмениваетесь информацией с компанией,

198

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

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

5.4.2. Сценарий использования № 2:
одна сессия на каждый набор данных
(связывание действий одного пользователя в рамках набора данных)
В отличие от первого случая, где мы обменивались данными об отдельных действиях, этот сценарий предполагает совместное использование сессии, которая может
содержать несколько действий. Например, вы запускаете веб-сайт розничной торговли онлайн. Пользователь купил несколько товаров на вашей платформе, а еще
часть сохранил в список желаний. Затем вы делитесь этими данными с аналитической платформой, консультирующей вас по вопросам совершенствования пользовательского интерфейса для улучшения взаимодействия пользователя с сайтом.
В этом случае каждый набор данных рассматривается как отдельная независимая
сессия. Все элементы данных, связанные с одним и тем же внутренним идентификатором, должны иметь определенное и единообразное псевдонимизированное значение в наборе данных. Как правило, этого можно добиться, используя криптографическую или безопасную функцию хеширования, а также справочную таблицу, с
помощью которой поддерживается согласованность псевдонимизированных значений внутренних идентификаторов в наборе данных.

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

Глава 5. Совместное использование данных

199

хеш-функции затем можно использовать в качестве псевдонимизированного идентификатора. Если длину внутреннего идентификатора необходимо оставить 128битной, хеш можно сократить до 128 бит. Ключ HMAC (кода аутентификации сообщения на основе хеш-функции) следует использовать только один раз и сразу же
утилизировать.
Как вариант, можно применить к внутреннему идентификатору функцию безопасного хеширования SHA-256 с уникальной 256-битной случайно сгенерированной
солью для набора данных. На выходе здесь также выдается 256-битное значение
хеш-функции, которое при необходимости может быть усечено до 128 бит.
Другой способ — генерировать случайное псевдонимизированное значение для каждого внутреннего идентификатора, как в сценарии № 1, но хранить все внутренние идентификаторы и их псевдонимизированные значения в справочной таблице
для соблюдения единообразия. К этому варианту следует прибегать, если нет возможности применить криптографическую или хеш-функцию. Справочную таблицу
необходимо безопасно хранить и удалить после использования. Эта опция требует
дополнительных затрат, выражающихся в потреблении памяти или зависимости от
внешних служб.
Поскольку разные наборы данных рассматриваются как отдельные сессии, криптографический ключ, соль или справочную таблицу нельзя использовать для нескольких наборов данных одновременно.

5.4.3. Сценарий использования № 3:
наборы данных, охватывающие всю сессию
(связывание между наборами данных)
Продолжая пример с интернет-магазином, допустим, что вам нужно поделиться с
аналитической компанией некоторыми примерами покупок и отказов (когда пользователи добавляют товары в корзину, но не покупают), чтобы она помогла вам
спрогнозировать доход. В таком случае обфускацию идентификаторов следует хорошо продумать. Если необходимо, чтобы псевдонимизация личности последовательно поддерживалась в нескольких наборах данных для одной и той же сторонней компании, придется расширить сценарий № 2.

Предлагаемые методы псевдонимизации
Для псевдонимизации наборов данных необходимо применять один и тот же криптографический ключ (для функции HMAC-SHA256) или соль (для функции SHA256). Следует позаботиться о надлежащей защите ключей и соли внутри компании
и использовать каждый ключ или соль только для одной сторонней компании.
Функция HMAC-SHA256 выполняет два раунда хеширования, поэтому затраты на
ее вычисление примерно в два раза выше по сравнению с SHA256. Ее преимущество — в использовании стандартных криптографических примитивов, которые
обеспечивают нужную длину ключа и не требуют объединения внутреннего идентификатора и соли.

200

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

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

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

Двусторонняя криптографическая функция
Вместо односторонней хеш-функции для создания псевдонимизированного идентификатора с аналогичными свойствами можно применить подходящее двустороннее шифрование/дешифрование.
В частности, вместо того, чтобы применить к внутренним идентификаторам функцию HMAC-SHA256 для создания псевдонимизированных значений, можете зашифровать внутренние идентификаторы с помощью усовершенствованного стандарта шифрования (англ.: AES — Advanced Encryption Standard) с 256-битным
ключом (в режиме цепочно-блочного шифрования с нулевой синхропосылкой). Затем можно восстановить исходные внутренние идентификаторы, просто расшифро-

Глава 5. Совместное использование данных

201

вав псевдонимизированные значения тем же ключом. В отличие от одностороннего
хеширования, сгенерированное значение нельзя обрезать. Если нужно значение
меньшей длины, лучше использовать 128-битный ключ для получения 128-битного
выходного значения. Этот метод не требует дополнительных затрат на хранение,
однако при каждом использовании придется выполнять расшифровку.
П РИМЕЧАНИЕ
Функция двустороннего шифрования/дешифрования предназначена исключительно
для создания псевдонимизированных значений, а не для общего шифрования данных.
По сути, тут опускаются некоторые более надежные режимы шифрования, такие как
AES-GCM, потому что от них либо нет дополнительной пользы (например, режим обратной связи не дает никаких преимуществ, так как длина ключа в нем больше или
равна длине внутреннего идентификатора в битах), либо они значительно увеличивают длину вывода без очевидного преимущества (например, добавление одноразового
номера и тега аутентификации).

5.5. Измерение воздействия
на конфиденциальность
Мы рассмотрели несколько методов снижения идентифицируемости и, следовательно, ущерба конфиденциальности при совместном использовании данных. Однако затрачиваемые усилия не совсем соответствуют возможным последствиям.
Вот почему руководителям жизненно важно применять основанный на данных
процесс для определения степени воздействия этих приемов обфускации. Использование методов защиты конфиденциальности позволит вам количественно оценить это воздействие.
Существуют два метода, позволяющие измерить воздействие на конфиденциальность: k-анонимность и l-разнообразие. Их можно использовать одновременно или
по отдельности, в зависимости от ситуации с конфиденциальностью.

5.5.1. K-анонимность
Самая исчерпывающая работа на тему k-анонимности, которую я читал, принадлежит профессору Латанье Суини (http://mng.bz/J1mZ), но для этой книги обратимся
к простому объяснению, сформулированному в Университете Карнеги-Меллона
(www.cs.cmu.edu/~jblocki/Slides/K-Anonymity.pdf): при k-анонимности атрибуты
подавляются до тех пор, пока каждая строка не будет идентична не менее чем k-1
другим строкам. В этот момент говорят, что база данных является k-анонимной. Канонимность таким образом предотвращает определенные связи с базой данных. В
худшем случае опубликованные данные сужают поиск отдельной записи до группы
из k лиц.
K-анонимность интуитивно понятна в реализации, ее использует корпорация
Google в рекламном API, обеспечивая минимальную гарантию того, что вы являетесь частью минимальной группы и вас нельзя однозначно идентифицировать.

202

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

K-анонимность с неточными данными
В табл. 5.4 показано, как работает k-анонимность при разных уровнях точности
данных о местоположении. В таблице по оси Y отложено количество десятичных
знаков в данных о местоположении, а ось Х представляет значение k-анонимности.
Чтобы понять, что обозначает значение k-анонимности, рассмотрим пример: возьмем ячейку в последней строке третьего столбца. Если после запятой в местоположении по GPS указано пять знаков, то только в 35,5 % записях о местоположении
будут 5 других похожих значений поездки. Значит, остальные 64,5 % записей содержат менее 5 одинаковых значений, что позволяет их идентифицировать.
Удалив одно значение после запятой в GPS-координатах и оставив только четыре,
получим выборку, в которой 93,2 % наборов данных будут содержать схожие значения, тем самым уменьшая вероятность идентификации по сравнению с использованием пяти знаков после запятой. Следовательно, чем точнее данные, тем меньше
вероятность найти другие схожие наборы данных, и это делает каждый из них более узнаваемым. Соответственно, чем выше значение k-анонимности, тем более
защищены данные.
У двух поездок с одинаковой стоимостью должны быть одинаковые точки посадки
и высадки.
В верхней строке табл. 5.4 на основе данных о местоположении GPS без знаков после запятой вы увидите, что для всех пользователей (100 %) можно найти как минимум одну другую поездку (что дает значение k-анонимности, равное 2), четыре
другие поездки (что дает значение k-анонимности, равное 5). И так до 999 других
поездок (что дает значение k-анонимности, равное 1 000) пользователей с той же
ценностью поездки.
Таблица 5.4. K-анонимность при GPS-координатах без знаков после запятой
Значение k-анонимности
Количество знаков
после запятой
в данных
о местоположении

2

5

10

50

100

1 000

0

100 %

100 %

100 %

100 %

100 %

100 %

1

100 %

100 %

100 %

100 %

100 %

100 %

Глава 5. Совместное использование данных

203
Таблица 5.4 (окончание)

Значение k-анонимности
Количество знаков
после запятой
в данных
о местоположении

2

5

10

50

100

1 000

2

100 %

100 %

100 %

99,9 %

99,9 %

99,1 %

3

99,9 %

99,8 %

99,5 %

97,6 %

95,3 %

87,9 %

4

97,4 %

93,2 %

89,3 %

73,1 %

59,3 %

17,3 %

5

68,4 %

35,5 %

18,3 %

2,5 %

1,5 %

0,9 %

Предоставляя для совместного использования данные о местоположении по GPS
без знаков после запятой, с высокой k-анонимностью вы делаете пользователей менее идентифицируемыми. Так происходит потому, что множество разных мест посадки и высадки были уравнены из-за округления значений GPS-координат. Подобным образом при округлении время посадки 11:21 и 11:22 превращаются в
11:30.
Цель k -анонимности достигнута, но вы пожертвовали качеством данных.

K-анонимность с точными данными
В табл. 5.5 показано, как работает k-анонимность при наличии очень точных данных о местоположении. Чем больше знаков после запятой указано в GPSкоординатах, тем точнее местоположение пользователя и тем более идентифицируемым он является.
Таблица 5.5. K-анонимность при GPS-координатах с 4 и 5 знаками после запятой
Значение k-анонимности

Количество знаков
после запятой в
данных о местоположении

2

5

10

50

100

1 000

0

100 %

100 %

100 %

100 %

100 %

100 %

1

100 %

100 %

100 %

100 %

100 %

100 %

2

100 %

100 %

100 %

99,9 %

99,9 %

99,1 %

3

99,9 %

99,8 %

99,5 %

97,6 %

95,3 %

87,9 %

4

97,4 %

93,2 %

89,3 %

73,1 %

59,3 %

17,3 %

5

68,4 %

35,5 %

18,3 %

2,5 %

1,5 %

0,9 %

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

204

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

при движении слева направо. Например, при отображении 5 знаков после запятой
для 68,4 % пользователей значение k-анонимности равно 2, а значит, для 68,4 %
пользователей можно найти еще одного пользователя с такими же значениями поездки.
Убрав один знак и предложив координату GPS с четырьмя знаками после запятой,
мы увидим, что для 97,4 % пользователей можно найти схожую поездку, поэтому
для них значение k-анонимности равно 2. Как и раньше, чем менее точны данные,
тем большую анонимность можно обеспечить пользователям.
В крайнем правом углу, если мы укажем 5 знаков после запятой и захотим обеспечить значение k-анонимности, равное 1 000, то есть найти 999 других подобных
поездок, это удастся сделать только для 0,9 % пассажиров.
Таким образом, из-за точности данных о местоположении анонимность очень низкая. Показатели немного улучшатся, если мы удалим один знак после запятой и
округлим до 4. Однако обеспечить значение k-анонимности, равное 1 000, удастся
только для 17,4%, то есть примерно для одной из шести поездок.
Если нужно, чтобы определенное значение k-анонимности было у большего процента пользователей, придется сокращать количество знаков после запятой в данных о местоположении.

K-анонимность и лучшая практика в отрасли
Для окончательного представления этих данных, как показано в табл. 5.6, я сосредоточусь на значении k-анонимности, равном 5, так как оно считается лучшей
практикой в отрасли. В этом случае ваши данные сокрыты настолько, что для каждой записи имеются как минимум четыре других, почти неотличимых от нее. Благодаря этому запись лучше защищена с точки зрения конфиденциальности и ее
труднее индивидуально идентифицировать.
Таблица 5.6. Значение k-анонимности, равное 5
Значение k-анонимности

Количество знаков
после запятой в
данных о местоположении

2

5

10

50

100

1 000

0

100 %

100 %

100 %

100 %

100 %

100 %

1

100 %

100 %

100 %

100 %

100 %

100 %

2

100 %

100 %

100 %

99,9 %

99,9 %

99,1 %

3

99,9 %

99,8 %

99,5 %

97,6 %

95,3 %

87,9 %

4

97,4 %

93,2 %

89,3 %

73,1 %

59,3 %

17,3 %

5

68,4 %

35,5 %

18,3 %

2,5 %

1,5 %

0,9 %

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

Глава 5. Совместное использование данных

205

можно увидеть, что происходит со значением k-анонимности, по мере того, как мы
добавляем больше знаков после запятой к данным о местоположении. Как мы уже
выяснили, чем больше десятичных знаков добавляется, тем точнее становятся данные и тем легче идентифицировать пользователя, на чьи GPS-координаты мы смотрим. Таким образом, количество пользователей со значением k-анонимности, равным 5, будет уменьшаться.
Когда знаки после запятой не указываются (более грубое местоположение), для
всех пользователей можно найти еще четыре других поездки с такими же значениями (т. е. 100 % пользователей имеют k-анонимность, равную 5). То же самое
верно для одного и двух знаков после запятой — можно иметь GPS-координаты с
точностью до двух знаков после запятой, а k-анонимность по-прежнему будет 5.
При добавлении третьего знака после запятой наступает переломный момент. Начиная с него, уже не у всех пользователей значение k-анонимности будет равно 5.
Для части пользователей не найдется как минимум четыре других с такими же, как
у них, значениями поездок. Однако оказывается, что, даже добавив третий знак после запятой, мы по-прежнему получим значение k-анонимности, равное 5 для
99,8 % пользователей.
Таким образом, если цель — получить значение k-анонимности, равное 5, нам нужно подавить только 0,2 % данных.

5.5.2. L-разнообразие
Лучшая в отрасли практика — значение k-анонимности, равное 5, — обеспечивает
значимый баланс между конфиденциальностью и удобством использования. Однако k-анонимность имеет свои ограничения, поэтому есть еще один инструмент, помогающий анонимизировать данные перед обменом ими: l-разнообразие. Рассмотрим сценарий использования, который показывает ограничения k-анонимности и
то, как l-разнообразие может помочь.
Предположим, вы получили значение k-анонимности, равное 5, но существует хотя
бы одна точка посадки, из которой все поездки отправлялись в один и тот же пункт
назначения. Тогда, используя внешние данные, можно узнать, куда направляется
любой пассажир из этой точки. Здесь может помочь l-разнообразие. L-разнообразие
позволяет обеспечить множество потенциальных точек посадки или пунктов назначения. Таким образом, для каждой поездки в указанном временном окне должно
быть как минимум l различных потенциальных точек высадки, а для каждой высадки должно быть l потенциальных точек посадки.
В некоторых ситуациях k-анонимность может отфильтровать слишком много данных, и тогда l-разнообразие окажется гораздо более эффективным инструментом.
Рис. 5.6 это иллюстрирует. Точки слева на рисунке обозначают места посадки, а
точки справа — места высадки. Применив значение k-анонимности, равное 2, вы
отфильтруете все поездки, поскольку среди них нет двух с одинаковыми местами
посадки и высадки. С другой стороны, если разделить места посадки и высадки и
применить l-разнообразие, равное 2, можно сохранить весь набор данных, обеспечив при этом конфиденциальность.

206

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

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

Рис. 5.6. L-разнообразие в действии

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

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

Глава 5. Совместное использование данных

207

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

5.6.1. Facebook и Cambridge Analytica
Сегодня почти все уже слышали о проблеме компании Cambridge Analytica
(http://mng.bz/q21x). Эта фирма по обработке политических данных, нанятая предвыборной кампанией президента Трампа в 2016 году, получила доступ к личной
информации более чем 50 миллионов пользователей Facebook (ныне корпорация
Meta Platforms Inc. признана экстремистской организацией на территории РФ). У
компании, по их словам, имелись инструменты с возможностями прогнозирования,
способные влиять на поведение пользователей. Желание получить данные от Facebook теоретически могло сподвигнуть Cambridge Analytica усовершенствовать свои
инструменты прогнозирования и применить их к самим пользователям. Это сделало бы их целевые сообщения более эффективными и, возможно, повлияло на модели голосования и итоги выборов.
Данные включали сведения о личности пользователей, друзьях, других связях и
поведении пользователей на основе постов, которые они отметили как понравившиеся. Главная идея компании Cambridge Analytica заключалась в том, чтобы на
основе активности пользователя в Facebook определить черты его личности, а затем
таргетировать цифровую рекламу для этого пользователя, исходя из его личностных особенностей.
В рамках данной главы и книги для нас важнее не то, каким образом использовались
данные, а то, как компания Cambridge Analytica их получила. Пользователям было
предложено пройти личностный опрос и скачать приложение. Затем приложение извлекало личную информацию из их профилей и профилей их друзей. Компания
Facebook на тот момент не блокировала и не ограничивала этот режим извлечения
данных, но теперь закрыла тот уровень доступа. Извлечение и возможности анализа
были разработаны в Центре психометрии Кембриджского университета.
Центр отказался сотрудничать с компанией Cambridge Analytica, но нашелся желающий — Александр Коган, профессор психологии в университете. Используя
способность извлекать большие объемы данных у пользователей и их контактов,
Коган создал собственное приложение и в июне 2014 года начал собирать данные

208

Часть II. Упреждающая программа защиты конфиденциальности: управление данными

для компании Cambridge Analytica. Всего он предоставил фирме более 50 миллионов необработанных профилей.
Ущерб конфиденциальности здесь затронул пользователей и их контакты. Лишь
около 270 000 пользователей — те, кто участвовал в опросе, — давали согласие на
сбор их данных, при условии, что данные будут использованы для исследований, —
и не ожидали, что их согласие будет использовано для сбора данных их друзей.
Из этого эпизода можно извлечь несколько уроков, но я хочу подчеркнуть следующие моменты:
 как только данные покинут вашу компанию, вы, скорее всего, уже не сможете
контролировать, что с ним происходит;
 организации, с которыми вы делитесь данными, могут быть не такими прозрачными и честными, как вы;
 тот, с кем вы делитесь данными, может обладать более совершенными возможностями их обработки, чем вы;
 нередко требуется время, чтобы в полной мере осознать все последствия обмена
данными, поэтому в данном случае отсутствие новостей вовсе не обязательно
является хорошей новостью.
Вспомните эти уроки, прежде чем сбрасывать со счетов риск, связанный с совместным использованием данных.

5.6.2. Совместное использование данных и слабые места
На случай, если описанные векторы атак при обмене данными покажутся недостаточной угрозой, есть еще программы-вымогатели.
Программа-вымогатель — это вредоносное программное обеспечение, которое быстро распространяется по компьютерным сетям и шифрует их, удерживая конфиденциальные документы «в заложниках», пока жертва не заплатит хакерам
(http://mng.bz/7WYQ).
Программа-вымогатель — значительная угроза:
 в 2019 году программы-вымогатели поразили 103 федеральных, государственных и муниципальных учреждения, 759 провайдеров учреждений здравоохранения, а также 86 школ и университетов (http://mng.bz/mxE8);
 только в декабре 2017-го четыре города США были атакованы программамивымогателями;
 увидев, что Атланта тратит 2,6 млн. долларов на восстановление своих систем
вместо того, чтобы заплатить выкуп в размере 52 000 долларов, многие чиновники решили, что дешевле заплатить хакерам;
 атака программы-вымогателя обошлась Балтимору в 18 млн. долларов.
Эти атаки только учащаются по мере того, как злоумышленники осознают, насколько слабы оборонительные возможности кибербезопасности и какие огромные
объемы данных хранят компании и правительства.

Глава 5. Совместное использование данных

209

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

Резюме
 В современных компаниях совместное использование данных является ключе-

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

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

фиденциальностью.
 Некоторые из этих методов характерны для стандартных требований безопасно-

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

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

(k-анонимность, l-разнообразие и т. д.), которые позволяют измерить воздействие ваших методов защиты конфиденциальности для оценки возможности безопасно обмениваться данными.
 Обмен данными — одно из самых необратимых решений, которое может при-

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

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

- ЧАСТЬ III -

Инструменты и процессы
Эта часть поможет инженерам создать точечные решения с применением описанных выше возможностей управления данными. Инженерия конфиденциальности
направлена на предоставление клиентам важных, поддающихся проверке возможностей. Многие из этих возможностей являются техническими воплощениями ожиданий и регулируются нормативными документами. В данной части описаны практические навыки, призванные помочь инженерам оправдать эти ожидания.
Глава 6 поможет инженерам настроить процесс технической проверки защиты
конфиденциальности, чтобы внедрить конфиденциальность в качестве технической
функции в продукты и услуги компании.
В главе 7 будет рассмотрена подробная архитектура удаления данных для обеспечения стирания данных на основе сервисов. В ней описывается удаление информации, начиная с данных учетной записи и заканчивая данными потокового события.
Глава 8 поможет читателям спроектировать возможности экспорта данных, чтобы
обеспечить требующие высокой степени видимости запросы DSAR.
В главе 9 предлагается пример проекта платформы управления согласием, позволяющей компаниям выполнить новое требование регуляторов и корпораций.

- ГЛАВА 6 -

Техническая проверка защиты
конфиденциальности

В этой главе мы рассмотрим:
 что подразумевается под «проверками защиты конфиденциальности»;
 как компании могут разделить проверки защиты конфиденциальности между

сотрудниками юридического и инженерного отделов;
 как интегрировать техническую проверку защиты конфиденциальности в рабо-

чий процесс компании;
 как сделать техническую проверку защиты конфиденциальности более автома-

тизированной и эффективной;
 какие бывают примеры обоих видов проверок (юридической и технической).

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

214

Часть III. Инструменты и процессы

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

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

ности для двух разных видов среды разработки;
 в третьей читатели узнают, как обосновать необходимость технической провер-

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

помощью автоматизации;
 в пятой в центре внимания будут масштаб и эффективность для обеспечения

широкого внедрения технической проверки защиты конфиденциальности;
 в шестой мы рассмотрим практические примеры, которые помогут нашим чита-

телям потренироваться на изучении реальных технических проверок защиты
конфиденциальности.
Начнем с основ: что мы подразумеваем под «проверками защиты конфиденциальности»?

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

Глава 6. Техническая проверка защиты конфиденциальности

215

обеспечения конфиденциальности также занимались специалисты — специалисты
по защите конфиденциальности.
Поскольку канонического определения проверки защиты конфиденциальности не
существует, я его сформулирую для данной книги. Проверка защиты конфиденциальности — это процесс, с помощью которого специалисты по защите конфиденциальности оценивают технический продукт (или функцию) с целью обеспечения
соблюдения отраслевых стандартов и ожиданий клиентов.
Полный процесс проверки защиты конфиденциальности включает в себя два основных шага, которые не всегда выполняются в определенном порядке.
Сначала юридический отдел компании, занимающийся вопросами защиты конфиденциальности (который часто состоит из одного сотрудника со множеством других
обязанностей), должен критически оценить продукт. Проверка направлена на определение того, соответствует ли продукт требованиям таких нормативных документов, как GDPR, CCPA, Общий закон о защите персональных данных Бразилии (порт.:
LGPD — Lei Geral de Proteção de Dados Pessoais) и т. д., а также на то, чтобы обеспечить соответствие продукта требованиям действующего законодательства.
Затем инженеры по защите конфиденциальности, у которых, повторюсь, в небольших компаниях часто есть и другие обязанности — например, обеспечение безопасности и информационно-техническое обеспечение рабочего процесса, должны
провести более углубленный анализ, уделяя особое внимание различным аспектам
обработки данных. Такая проверка защиты конфиденциальности проблематична
тем, что, в отличие от юристов, инженеры по защите конфиденциальности не могут
указать на конкретные законы, положения которых, возможно, были нарушены. А
поскольку техническая проверка часто происходит после того, как юристы одобрят
проект, влияние инженеров по защите конфиденциальности порой ограничено. Их
обвиняют в задержке выпуска продукта, в том, что из-за них процесс становится
врагом прогресса и прочей ереси.
В этой главе объясняется, как небольшим и гибким компаниям с ограниченным
бюджетом, а также сотрудникам корпораций вроде Google и Apple разработать
проверку защиты конфиденциальности. Им придется полагаться на автоматизацию,
чтобы помочь своим стремящимся к инновациям инженерам выполнить эту задачу.
В этой главе также приводятся примеры продуктов и функций, которые можно
подвергнуть проверке защиты конфиденциальности. Ни одна книга не способна
научить компании, как придумать надежную проверку защиты конфиденциальности, поскольку инновации часто развиваются быстрее, чем пишутся учебники. Эта
глава может лишь дать основу для разработки процесса и несколько ориентиров,
которые помогут создать проверку, позволяющую предотвращать и выявлять проблемы конфиденциальности. Это способствует снижению риска нарушения конфиденциальности, а также со временем превратит компанию в более эффективного
хранителя данных о клиентах.
Прежде чем углубиться в изучение процесса и примеров, важно определить некоторые понятия. В книге процесс проверки защиты конфиденциальности рассматри-

216

Часть III. Инструменты и процессы

вается целостно и охватывает как юридическую, так и техническую проверку. По
этой причине мы сначала проанализируем юридическую проверку защиты конфиденциальности — часть процесса проверки, которую проводит юридический отдел
компании или сторонние консультанты. Проверки делятся на две категории: оценка
воздействия на конфиденциальность (англ.: Privacy Impact Assessment — PIA) и
оценка воздействия на защиту данных (англ.: Data Protection Impact Assessment —
DPIA). Далее мы рассмотрим их подробно, а также выясним, как они вписываются
в общий процесс проверки защиты конфиденциальности компании.

6.1.1. Оценка воздействия на конфиденциальность
Большинство компаний проводит только юридическую проверку защиты конфиденциальности. Для этого нередко привлекают юристов с опытом работы в области
защиты конфиденциальности и безопасности, однако чаще возлагают проверку на
юристов, имеющих и другие обязанности, такие как судебные разбирательства,
трудовое законодательство и т. д. Таким образом, объем и глубина подобной проверки, называемой оценкой воздействия на конфиденциальность, она же PIA, могут
быть ограничены. Тем не менее, важно сформулировать определение и критерии
этого типа оценки.
Оценку воздействия на конфиденциальность можно рассматривать как инструмент
принятия решений для выявления и смягчения рисков конфиденциальности по следующим направлениям (http://mng.bz/8l7D):
 какую идентифицирующую личность информацию может собирать у клиентов и

пользователей компания и ее сотрудники;
 для чего собираются данные с четко определенными и перечисленными вариан-

тами использования;
 каковы сбор, использование, совместное использование, безопасность и хране-

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

Глава 6. Техническая проверка защиты конфиденциальности

217

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

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

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

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

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

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

218

Часть III. Инструменты и процессы

По данным Управления Комиссара по информации Соединенного Королевства,
«Оценка воздействия на защиту данных — это процесс, призванный помочь вам
систематически анализировать, выявлять и минимизировать риски защиты данных
проекта или плана. Это ваша ключевая обязанность в соответствии с GDPR, и при
правильном выполнении она помогает оценить и продемонстрировать, как вы соблюдаете все свои обязательства по защите данных» (http://mng.bz/jyoe).
Согласно GDPR, неспособность в случае необходимости выполнить DPIA может
повлечь для вашей компании меры принуждения, в том числе штраф до 10 млн.
евро или 2 % от годового оборота, а то и больше.
Компании часто воспринимают оценку воздействия на защиту данных как помощь
по соблюдению правовых норм в отношении конкретного продукта. Однако если
применять эту оценку стратегически, а потом использовать ее результаты для
улучшения планирования и проектирования следующего набора технических продуктов, это может способствовать развитию зрелости организации. Как подчеркивает Управление Комиссара по информации, эта зрелость может помочь организации в целом придерживаться более глобального стандарта, задаваемого для области
в целом, и избежать необходимости исправлять нарушения по отдельности.
При выполнении DPIA организация должна ответить на четыре основных вопроса
(http://mng.bz/doNw):
1. Каким образом и с какой целью обрабатываются персональные данные? Здесь
нужно не заявление, сделанное руководством. Вместо этого компания должна
отследить, какие данные собраны, каким образом их использование позволяет
достичь конкретных результатов, как эти результаты соотносятся с изначально
заявленными целями и т. д.
2. Зачем были собраны определенные данные? Могла ли компания получить те же
преимущества и идеи благодаря другому набору данных или меньшему количеству наборов данных? Цель состоит в том, чтобы обосновать соответствие сбора
данных цели и не собирать без четко определенной цели огромные объемы данных.
3. Каково конкретное воздействие на пользователя в плане прав, свобод, уязвимостей и безопасности? Это заставит компанию взглянуть на данные с позиции
пользователя, а не смотреть на пользователя через призму данных.
4. Как компания будет защищать своих пользователей от нарушения конфиденциальности? Компании придется найти способ сделать данные доступными и
удобными для использования, но таким образом, чтобы не нанести вреда конфиденциальности. Идеально будет определить элементы управления, операционные детали, описания на основе метрик, объясняющие, каким образом данные элементы управления будут устранять наносимый конфиденциальности
ущерб, и т. д.
Указанные четыре элемента помогут вам сосредоточиться на типе данных, которые
вы собираете и обрабатываете, на рисках, связанных с обработкой данных, а также
вероятности их возникновения и силы воздействия. Оценка воздействия на защиту
данных поможет вам определить наихудшие сценарии и обеспечить их смягчение.

Глава 6. Техническая проверка защиты конфиденциальности

219

П РИМЕЧАНИЕ
Оценка воздействия на защиту данных — это оценка рисков, которая требуется в соответствии с GDPR в зависимости от характера, масштаба, контекста и цели обработки данных, и особенно для деятельности с высоким риском и новых технологий, влияние которых неизвестно. Она может потребоваться только для деятельности, которая
будет нацелена на жителей ЕС. Следует проконсультироваться у юриста относительно применимости DPIA для вашего бизнеса.

Международная ассоциация профессионалов в области конфиденциальности (англ.:
IAPP — International Association of Privacy Professionals) предложила пошаговый
процесс оценки воздействия на защиту данных, который может помочь небольшим
компаниям провести ее в ускоренном порядке. Эти шаги обозначены на рис. 6.1.
Давайте рассмотрим каждый из них по очереди.

Рис. 6.1. Процесс оценки воздействия на защиту данных

Определите необходимость оценки воздействия на защиту данных
Согласно директиве властей ЕС, «GDPR не требует проводить оценку воздействия на
защиту данных для каждой операции обработки, которая может привести к рискам
нарушения прав и свобод физических лиц. Проведение оценки воздействия на защиту данных обязательно только в случаях, когда обработка данных "может стать причиной высокого риска нарушения прав и свобод физических лиц" (статья 35(1), проиллюстрированная статьей 35(3) и дополненная статьей 35(4)). Это особенно актуально при введении новой технологии обработки данных» (http://mng.bz/9K7r).

220

Часть III. Инструменты и процессы

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

цели должен достичь проект;
 поручить техническим руководителям (или инженерам по защите конфиденци-

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

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

 Как вы будете собирать, использовать, хранить и удалять данные?
 Каков источник данных? Будете ли вы делиться данными с кем-либо? Для
описания потоков данных, возможно, будет полезно представить их в виде
диаграммы технологической схемы процесса или отобразить графически както иначе.
 Какие типы обработки, классифицированные как имеющие высокий риск, задействованы? Здесь очень пригодятся уроки, почерпнутые из главы 5.
 Объем обработки данных

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

Глава 6. Техническая проверка защиты конфиденциальности

221

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

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

с клиентами, незарегистрированными пользователями и т. д.
 Какой степенью контроля они будут обладать?
 Знают ли они, что вы будете использовать их данные таким образом?
 Есть ли среди них дети или другие уязвимые группы?
 Есть ли опасения по поводу этого типа обработки или недостатков обеспечения

безопасности? Учитывая, что вокруг вопросов защиты конфиденциальности существует постоянный водоворот проблем, стоит провести параллели. Эта информация может помочь смягчить последствия.
 Вводится ли что-то новое? Другими словами, отличается ли изменение от теку-

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

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

мы сертификации?
 Чего вы хотите достичь? Рекомендуется перечислить и количественно оценить

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

для компании, а также в более широком смысле?

222

Часть III. Инструменты и процессы

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

этого делать не следует. Другими словами, новаторы должны будут объяснить,
каким образом они уведомили пользователей, на которых повлияло изменение
технологии. Мы поговорим об этом подробнее в главе 9.
 Кого еще необходимо привлечь в рамках компании? Собираетесь ли вы кон-

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

соразмерности ответственности характеру нарушения, в частности:
 Какова законодательная основа для обработки данных?
 Действительно ли обработка достигает цели?
 Есть ли другой способ добиться того же результата?
 Как предотвратить «ползучесть» функций?
 Как обеспечить качество и минимизацию данных? Какую информацию вы пре-

доставите людям?
 Как защищены международные передачи данных?

Проведите оценку риска
Если будете соблюдать перечисленные выше шаги по управлению данными, процесс оценки рисков должен пройти относительно легко, поскольку он основан на
абстрактном понимании данных. А риск конфиденциальности воспринимается как
вызванный конкретным изменением. IAPP предоставляет удобный шаблон, модифицированная версия которого предложена в табл. 6.1 (http://mng.bz/Nxdd).
Таблица 6.1. Шаблон оценки риска конфиденциальности
Опишите риск конфиденциальности и его влияние на пользователей

Вероятность

Серьезность

Количественная оценка
риска по шкале от 1
до 100

Глава 6. Техническая проверка защиты конфиденциальности

223

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

Определите меры по смягчению риска
После перечисления рисков понадобится еще один шаблон для описания мер, которые будут предприняты по управлению ими и устранению. Такой шаблон, любезно
составленный IAPP, показан в табл. 6.2.
Таблица 6.2. Шаблон управления рисками конфиденциальности
Риск

Варианты
смягчения

Статус риска после
смягчения

Остаточный риск

Результат

Устранен/уменьшен/
без изменений

Низкий/средний/
высокий

Изменение одобрено
или отклонено

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

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

224

Часть III. Инструменты и процессы

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

Рис. 6.2. Юридическая проверка защиты конфиденциальности
в традиционном процессе разработки программного обеспечения

Как показано на рисунке, процесс вполне линейный и предсказуемый. Четкая согласованность между клиентом, стратегическими целями компании и инженерной
разработкой может упростить управление проверками защиты конфиденциальности и их масштабирование. Сотрудники смогут использовать некоторые процессы и
согласования как для отслеживания проверок конфиденциальности, так и для тестирования программного обеспечения, управления выпусками и тому подобного.
Итог в том, что юридические проверки защиты конфиденциальности происходят в
конце процесса разработки.
Однако с натиском революции Agile и Scrum-методологий процесс разработки стал
более подвержен сбоям. На рис. 6.3 показано, как может выглядеть современная
мастерская инновационных разработок.

Глава 6. Техническая проверка защиты конфиденциальности

225

Рис. 6.3. Юридическая проверка защиты конфиденциальности
в современном адаптивном процессе разработки программного обеспечения

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

226

Часть III. Инструменты и процессы

 адвокатам не хватает контекста, поскольку не все продукты создавались по тех-

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

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

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

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

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

Глава 6. Техническая проверка защиты конфиденциальности

227

выпуска. Это также означает, что, учитывая ограниченную пропускную способность, некоторые продукты не будут рассмотрены. У такого подхода есть существенный недостаток: юристы могут принимать решения о том, какой продукт
проверять, не зная всех технических деталей, поскольку они не участвуют в этапах разработки с приращением. О риске для конфиденциальности часто невозможно судить, не зная контекста эволюции продукта.
Юридическая проверка защиты конфиденциальности тормозится не потому, что
юристы или целые отделы не заботятся об обеспечении конфиденциальности. Сроки проведения таких проверок обусловлены соотношением инженеров и юристов.
В результате последним приходится выбирать, что и когда проверять. Таким образом, качество процесса оказывается недостаточно высоким, учитывая сложность
современного проектирования и последствия внедрения основанных на данных инноваций.
Помимо сроков юридической проверки защиты конфиденциальности существует
также проблема ее ограниченности. На рис. 6.4 показано, что юридическая оценка
воздействия на конфиденциальность и на защиту данных — это часть общей работы, необходимой для проверки защиты конфиденциальности.

Рис. 6.4. Юридические проверки защиты конфиденциальности и их ограничения

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

228

Часть III. Инструменты и процессы

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

низкой производительности отдела или недостаточной технической глубины?
 Если юрист обнаружит проблему с функцией в последний момент, он может

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

6.3.2. Что входит в техническую проверку,
но не входит в юридическую
Как уже говорилось, рекомендуемый процесс обеспечения конфиденциальности
для современных компаний требует проведения также и технической оценки. В то
время как юридические проверки защиты конфиденциальности сосредоточены на
соблюдении нормативных требований, технические проверки концентрируют внимание на деталях технической реализации, потоках данных и других аспектах создания и проектирования технических продуктов. Цель таких проверок — оценить
последующее воздействие на пользователя, обнаружить потенциальный вред и внести исправления.
Таким образом, юридическая проверка защиты конфиденциальности — оценки
воздействия на конфиденциальность и защиту данных — полезный ресурс, если
говорить о комплексной экспертизе. Однако, чтобы добиться доверия клиентов и
обеспечить страховку от рисков нарушения конфиденциальности с технической
стороны, очень важно включить специалистов по защите конфиденциальности,
имеющих техническое образование, в производственный процесс до начала разработки.
Рис. 6.5 в общих чертах объясняет разницу между проверками защиты конфиденциальности, проводимыми юристами в ходе PIA или DPIA, и техническими проверками обеспечения конфиденциальности, которые проводят специалисты по
конфиденциальности.
Разница между двумя типами проверок заключается в структуре и глубине. Юристы обратятся к нормативной базе для обеспечения соответствия ей. Например, во
время проверки юристы могут задать такие вопросы:
 Будут ли данные, которые необходимо собрать, использоваться только для оп-

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

Глава 6. Техническая проверка защиты конфиденциальности

229

Рис. 6.5. Сравнение юридических
и технических проверок защиты конфиденциальности

Эти вопросы призваны гарантировать наличие неразрывной связи между требованиями законов — например, GDPR, раскрытием компанией конфиденциальной информации, а также проектами и техническими характеристиками, заявленными инженерами. Однако юристы не могут «заглянуть внутрь» и убедиться, что какойнибудь пройдоха-инженер не сделает несколько копий данных. И что одну из копий не запросит другой отдел, а к еще одной не получит доступ через API сторонняя компания с непроверенными практиками защиты конфиденциальности.
Часто инженеры не считают нужным указывать эти детали в документации, спешно
подготовленной к юридической проверке. Также они нередко забывают установить
средства контроля для проверки нарушений конфиденциальности после выпуска
продукта. Таким образом, проверки защиты конфиденциальности, проводимые
группой юристов, — необходимый, но недостаточный ресурс для встраивания проектируемой конфиденциальности в процессы разработки и инноваций.
Технические проверки защиты конфиденциальности помогают восполнить этот
пробел. В технических программах обеспечения конфиденциальности, которые мне
доводилось составлять, технические специалисты по защите конфиденциальности
сотрудничали с инженерами и менеджерами по продукту на этапе «белой доски» —
когда идет разработка продукта или функции. Специалисты по защите конфиденциальности следят за тем, чтобы все планы, технические характеристики продукта
и инженерно-технические проекты выполнялись с учетом защиты конфиденциальности. Так, например, техническая проверка защиты конфиденциальности может
вызвать следующие вопросы:
 Какие данные собираются?

 Каково соотношение структурированных и неструктурированных данных
(JSON-блобы, XML и т. д.)?
 Где их обнаруживают? На граничном уровне? В базах данных вроде REDIS?
В базах данных с малой задержкой, таких как Cassandra? Или в хвостовой
части конвейера в хранилище данных?

230

Часть III. Инструменты и процессы

 Как осуществляется контроль доступа к каждой из этих баз данных?

 Применяете ли вы шифрование? Если да, то какое? Двухточечное? Или шифрование данных выполняется в состоянии покоя, а передаются они в открытом виде незашифрованными?
 Как выглядит система управления ключами? Используются ли ключи, позволяющие получить доступ к данным только алгоритмам машинного обучения
и алгоритмам анализа мошенничества, а другим — нет?
 Имеется ли многофакторная аутентификация? Если да, то используются ли
инструменты вроде Okta, OneLogin или Ping? Возможно, применяется собственное решение?
 Как происходит аудит доступа к данным?

 Журналы аудита записываются в режиме реального времени или с помощью
пакетных процессов? Может ли это иметь решающее значение для своевременного определения неправомерного доступа и блокирования инсайдерского риска и риска третьего лица?
 Защищены ли журналы аудита от несанкционированного доступа?
 Каков срок хранения журналов аудита? Каким образом осуществляется его со-

гласованное соблюдение?
При технической проверке защиты конфиденциальности гораздо более подробно
рассматриваются сам проект и характеристики продукта. Так получают информацию, которую инженеры часто забывают указать в документации. Эта углубленная
проверка является связующим звеном между императивами соответствия нормативным требованиям и оправдания доверия клиентов, а также инженерной реализацией.
Мой коллега-адвокат недавно заметил, что адвокаты могут предложить «конфиденциальность в защите», в то время как инженеры по конфиденциальности могут
предложить «проектируемую конфиденциальность». Адвокаты могут защитить от
заметного и явного ущерба конфиденциальности, в то время как инженеры могут
встраивать элементы управления конфиденциальностью в проект. В итоге для защиты компании и пользователей нам нужны оба вида проверок.
П РИМЕЧАНИЕ
Юридическая проверка защиты конфиденциальности предлагает конфиденциальность в защите, а техническая проверка конфиденциальности предлагает проектируемую конфиденциальность. Обе незаменимы в деле предотвращения ущерба конфиденциальности и смягчения проблем нарушения конфиденциальности, связанных с
продуктами и функциями.

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

Глава 6. Техническая проверка защиты конфиденциальности

231

Рис. 6.6. Сравнение юридической
и технической проверок защиты конфиденциальности

Как видно из рис. 6.6, степень тщательности проверки защиты конфиденциальности для одного и того же инженерного продукта может быть разной в зависимости
от того, кто ее проводит.
Ч ЕМ

ПОЛЕЗНА ТЕХНИЧЕСКАЯ ПРОВЕРКА ЗАЩИТЫ КОНФИДЕНЦИАЛЬНОСТИ

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

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

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

232

Часть III. Инструменты и процессы

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

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

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

Рис. 6.7. Технические проверки защиты конфиденциальности
в традиционном процессе инженерной разработки

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

Глава 6. Техническая проверка защиты конфиденциальности

233

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

Рис. 6.8. Место технических проверок защиты конфиденциальности
в гибком процессе разработки

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

234

Часть III. Инструменты и процессы

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

Рис. 6.9. Образец анкеты для технической проверки защиты конфиденциальности

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

Глава 6. Техническая проверка защиты конфиденциальности

235

 любых продавцов, работающих с данными;
 применения/неприменения машинного обучения;
 регионов, в которых будут собираться или храниться данные.

Рассмотрим некоторые пункты подробнее, чтобы понять, почему процесс проверки
защиты конфиденциальности является частью общей стратегии управления данными.
Попросив инженеров перечислить данные, которые они намереваются собрать и
использовать, вы заставляете их разобраться в потоках данных и API. Это поможет
избежать сюрпризов, которых рецензенты-юристы часто не замечают. Эффективность этого шага зависит от того, правильно ли компания классифицировала и каталогизировала данные, о чем говорилось выше.
На стороне сервера записи инженеров можно использовать для вынесения решения
о том, какой уровень проверки обеспечения конфиденциальности необходим.
Подобным образом, если собираемые данные будут использоваться для моделирования машинного обучения и анализа, возможно, их потребуется хранить в течение
длительного времени.
Наконец, если данные собирают из регионов, особенно заботящихся о защите конфиденциальности, — например, из Западной Европы, это может увеличить риск
нарушения конфиденциальности и потребовать более подробной технической проверки.
После того как инженеры введут свои значения в форму и нажмут кнопку «Создать», результат может выглядеть примерно так, как показано на рис. 6.10.
На рис. 6.10 представлены два примера заполнения анкеты инженером. В первом
собирается большой объем конфиденциальных данных на уровне отдельных пользователей с потенциалом использования для машинного обучения. Следовательно,
соответствующий запрос JIRA показывает высокую степень конфиденциальности.
Я организовал процесс так, чтобы специалист по защите конфиденциальности был
соавтором руководящих технических документов вместе с инженером. Таким образом, определенная степень защиты конфиденциальности обеспечивается в проекте
с самого начала. Это очень важно, поскольку после поступления данных в систему
их необходимо классифицировать, каталогизировать и защитить, что требует больших финансовых затрат. Техническая проверка защиты конфиденциальности направлена на снижение этих расходов путем ограничения сбора данных действительно нужными. Это эффективно как с точки зрения соответствия закону, так и
для завоевания доверия пользователей.
Данный процесс также можно скорректировать и добавить в инженерно-технические
требования раздел защиты конфиденциальности, информацию в котором инженеры
и сотрудники, ответственные за проверку защиты конфиденциальности, смогут регулярно обновлять по мере обнаружения и смягчения рисков. На рис. 6.11 показано, как процесс технической проверки может работать на стороне сервера.

236

Часть III. Инструменты и процессы

Рис. 6.10. Пример результата заполнения анкеты
для технической проверки защиты конфиденциальности

Первый вопрос об использовании данных: «Занимаетесь ли вы сбором, использованием, обновлением, передачей личных данных?» — может инициировать проверку
защиты конфиденциальности, а дополнительные сведения пригодятся для заполнения раздела защиты конфиденциальности в инженерно-технических требованиях.
Разумеется, ответ «да» станет поводом для технической проверки защиты конфиденциальности, поэтому я часто советую инженерам использовать для выполнения
задач, не требующих данных о покупателях продукта, синтетические или вымышленные данные.
Так они смогут выполнить еще несколько действий без дополнительного риска,
возникающего из-за сбора, обмена и хранения данных пользователей, а также предоставления к ним доступа. Подобная мера поможет снизить общий риск нарушения конфиденциальности — в конце концов, трудно некорректно использовать
данные, которые вы не собрали. Это также поможет снизить риск нарушения безопасности — в случае взлома нельзя потерять данные, которых у вас нет. К тому же

Глава 6. Техническая проверка защиты конфиденциальности

237

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

Рис. 6.11. Рабочий процесс технической проверки конфиденциальности на стороне сервера

238

Часть III. Инструменты и процессы

Сама формулировка вопросов, лежащих в основе технической проверки защиты
конфиденциальности, позволяет тактично послать сигналы инженерам и ненавязчиво их обучить. Это еще одна возможность внедрить проектируемую защиту конфиденциальности в деятельность компании.
Второй набор вопросов на рис. 6.11 в разделе «Установление очередности и создание запроса JIRA» поможет определить уровень технической проверки защиты
конфиденциальности, которой подвергнется продукт или функция. На рис. 6.10 показано, что индивидуализированные данные требуют гораздо более глубокой проверки, чем обобщенные. Ответы на вопросы этого раздела и помогут специалистам
по защите конфиденциальности определить необходимый уровень проверки. Как и
первый вопрос, они содержат ненавязчивую подсказку инженерам, которые могут
не использовать конфиденциальные данные или сократить объем их хранения и
совместного использования. Тогда техническую проверку защиты конфиденциальности можно проводить не так тщательно.
Третий раздел на рис. 6.11 показывает документ с техническими требованиями,
данные в котором были введены в шагах 1 и 2. В этом разделе указаны аспекты
продукта, которые должны быть более пристально изучены техническими специалистами по защите конфиденциальности. Объединение сведений о конфиденциальности в документ с требованиями преследует несколько целей:
 инженеры и специалисты по защите конфиденциальности смогут легко на него

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

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

проекте, юристы смогут в качестве основы использовать этот раздел вместе с
контекстом, собранным специалистами по защите конфиденциальности. Это
значительно ускорит процесс оценки воздействия на конфиденциальность и на
защиту данных, а также укрепит связь между юридическим и техническим аспектами конфиденциальности.
Из личного опыта предложу техническим руководителям, решившимся осваивать
проверки защиты конфиденциальности, два совета. Читатели могут не согласиться
с ними или попытаться импровизировать, но предлагаю все же их рассмотреть:
1. Крайне важно, чтобы инженеры заранее не знали, каким образом их ответы связаны с проверками защиты конфиденциальности. Если они узнают, что ответ
«Нет» на вопрос о сборе данных может помочь избежать технической проверки
защиты конфиденциальности, есть вероятность, что они попытаются обмануть
систему, чтобы ускорить выпуск.

Глава 6. Техническая проверка защиты конфиденциальности

239

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

Рис. 6.12. Рабочий процесс технической проверки защиты конфиденциальности

Процесс на рис. 6.12 содержит основные этапы:
 создание запроса;
 первоначальные вопросы проверяющего;
 цикл вопросов-ответов;
 вердикт проверяющего с предлагаемыми средствами управления защитой кон-

фиденциальности.

240

Часть III. Инструменты и процессы

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

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

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

 API/Box — наиболее предпочтительный способ обмена.
 Не следует использовать сервисы Google Диск/Таблицы/Документы для обмена данными, за исключением случаев, когда это утверждено в индивидуальном порядке.

Глава 6. Техническая проверка защиты конфиденциальности

241

 Если приходится обмениваться данными через хранилище S3 (например, этого требует регулятор), то зашифруйте их и ограничьте сроки хранения.
 Никогда не используйте электронную почту для передачи персональных данных, например номеров карточек социального страхования.
 Для сервиса Box:

 файл не должен быть общедоступным. Его следует защитить паролем;
 если не обеспечивается шифрование на стороне клиента, срок хранения устанавливается равным одной неделе;
 для обмена файлами следует использовать корпоративную учетную запись
работодателя, а не личный кабинет сервиса.
 Для API:

 для авторизации используются безопасные токены;
 встроенная аутентификация и авторизация с использованием протокола
oAuth 2.0.;
 необходимо настроить ограничение скорости и времени ожидания.
 Для протокола SFTP:

 зашифруйте личные данные с помощью синтаксиса криптографических сообщений CMS (RFC 6032) с открытым ключом шифрования для получателя.
Принимающая сторона может сгенерировать 2048-битную пару RSA открытый/закрытый ключ и поделиться ими, используя сертификат X509;
 создание закрытых ключей и управление ими должны быть безопасными.
Ориентируйтесь на стандарты шифрования при создании ключей. Ключи необходимо менять каждые три месяца.

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

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

242

Часть III. Инструменты и процессы

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

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

цию, может повторно звонить или писать на электронную почту, если не получит ответа;
 справедливость — если вероятность, что два человека повторят (или не повто-

рят) правонарушение, одинакова, результат их апелляций тоже должен быть
одинаковым.
Система должна работать в большом масштабе и давать результаты для огромного
количества данных. Помните, это большой город, в котором ежедневно люди подают тысячи апелляций. В этом контексте собираемые городом данные будут использоваться как основа для оценки обоснованности будущих апелляций.
Существующие штрафы и апелляции можно сгруппировать по следующим категориям:
 люди, превысившие скорость на 5 миль в час и повторившие нарушение;
 люди, которые превысили скорость на 10 миль в час и повторили нарушение;
 люди, превысившие скорость на 15 миль в час и повторившие нарушение.

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

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

Глава 6. Техническая проверка защиты конфиденциальности

243

Машинное обучение, данные и конфиденциальность
Чтобы собрать данные для машинного обучения в среде, ориентированной на конфиденциальность, эти данные необходимо анонимизировать. Это позволит избежать идентификации или определения профиля отдельных пользователей. В приведенном ниже контрольном списке есть несколько полезных рекомендаций.
 Удалить атрибуты — не следует собирать и читать любые атрибуты, не требующиеся для данной цели, а также делиться ими. Например, если для вашей
службы не нужна дата рождения, не собирайте и не копируйте эти данные.
 Гранулярность — любой атрибут, который не нужен в подробном виде, следует
обобщить. Для данных о местоположении:
 IP-адрес — обнуление последнего октета IP-адресов везде, где это возможно.
IP-адрес мог быть получен из системы безопасности автомобиля;
 широта/долгота по GPS — по возможности вместо этого используйте идентификатор соты или ориентир. Если необходимо знать точное местоположение, минимизируйте число знаков после запятой (максимум 3 знака). Если
знаков будет 2 или меньше, GPS-координаты не будут указывать точное местоположение (тем самым снижая чувствительность данных GPS). Три знака
после запятой дают точность около 100 метров, а 5 знаков дают точность в
1 метр. Чем меньше точность, тем лучше;
 отметка времени — обобщите до 24 часов; если это невозможно, обобщите
до 1 часа. Если и это невозможно (в худшем случае), обобщите до 15минутного интервала;
 предварительное обобщение — предварительно обобщите данные и используйте группы из 18 или хотя бы 11–20 элементов при объединении поездок,
чтобы снизить риск повторной идентификации. Это означает, что имеется как
минимум 11–20 отдельных поездок, которые неотличимы друг от друга по
сочетанию даты, времени и местоположения.
 Объем — по возможности используйте меньше данных. Например, если можно
отрабатывать моделирование данных (для машинного обучения, например),
имея 50 000 записей, не собирайте миллион.
Пользы от контрольных списков можно добиться, написав ботов или другие программы, которые будут вводить данный контент в запросы JIRA, с инженернотехническими требованиями, чтобы инженеры могли с ними свериться перед отправкой документов на проверку защиты конфиденциальности. Это поможет обеспечить согласованность процесса и сэкономить время как инженерам, так и техническим специалистам, занимающимся проверкой защиты конфиденциальности.
Кроме того, предоставив инженерам эту информацию, вы избавите их от необходимости искать ее в больших базах данных и сформируете более гибкий подход к
обучению конфиденциальности. Для мелких компаний, которые работают с небольшой маржей и не располагают средствами на обучение, подобная экономия
крайне важна и со временем поможет встроить защиту конфиденциальности не
только в проекты продуктов, но и в корпоративную культуру.

244

Часть III. Инструменты и процессы

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

6.6.1. Приложения-мессенджеры и приложения для взаимодействия:
связаны ли они?
Давайте представим, что ваша компания занимается созданием приложений, позволяющих пользователям общаться и взаимодействовать друг с другом. По мере роста:
1. Компания выпускает платформу обмена сообщениями, которая позволяет пользователям создавать страницы профиля для себя или своего бизнеса.
2. Затем платформа расширяется, позволяя пользователям создавать группы и сообщества для общения с единомышленниками. Платформа взаимодействия
предназначена для пользователей с высокоскоростным Интернетом, разделяющих культуру, в которой поощряется обмен информацией.
3. Далее компания приобретает другую фирму поменьше, которая позволяет пользователям отправлять друг другу сообщения в виде СМС с той только разницей,
что они отправляются через Интернет. Приложение для обмена сообщениями
предназначено для регионов и стран, где подключение к Интернету может быть
ограничено, и для его работы достаточно низкой пропускной способности.
П РИМЕЧАНИЕ
Анализ, приведенный в данном примере, основан на моем понимании нормативных
документов, и его не следует воспринимать как юридический совет. Анализ приводится исключительно в учебных целях.

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

Глава 6. Техническая проверка защиты конфиденциальности

245

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

Рис. 6.13. Базы идентификационных данных из приложения
для взаимодействия и мессенджера

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

из одного приложения для индивидуальной настройки другого приложения под
пользователя;
 конкретный пользователь может общаться с одними и теми же друзьями в обоих

приложениях и решить, с кем он хочет взаимодействовать активнее, а с кем —
просто обмениваться сообщениями время от времени;
 если пользователь окажется заблокирован в одном приложении, компания мо-

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

246

Часть III. Инструменты и процессы

гистрированы на одну и ту же личность. Из рис. 6.13 понятно, что с помощью
номера телефона 232-333-9092 можно разблокировать одного и того же пользователя в обоих приложениях.
Указанные преимущества, начиная от удобства пользователя и заканчивая безопасностью, зависят от обмена данными между приложениями и личных данных пользователей. Исходя из моего опыта, большинство компаний считают, что идентификаторы пользователей хранятся у них по отдельности в двух разных базах данных,
как на рис. 6.13. Однако по мере роста компании возможность расширить вовлеченность пользователей, халатность или отсутствие этики приводят к «присоединению» или «связыванию» между собой двух баз данных. И как только две базы
данных объединятся, их невозможно будет отключить, ведь многие последующие
процессы рассчитаны на наличие доступа к этому объему данных. Часто присоединение выполняется с помощью автоматизированных сценариев и API, написанных для извлечения специальных сведений из данных.
Принимая во внимание большое количество слияний и поглощений, происходящих
в наши дни, а также тот факт, что огромные объемы данных передаются между
странами, антимонопольные регуляторы ЕС считают, что при анализе слияний и
соблюдения законодательства о конкуренции важно принимать во внимание права
на использование данных потребителей и данные им обещания. Недостаточная
прозрачность в области данных может негативно повлиять на перспективы компании. Инженеры должны понимать, что простой запрос, выполняющийся всего за
несколько секунд, может иметь далеко идущие последствия — в зависимости от
того, насколько его результаты совпадают с ожиданиями пользователей.
С учетом ситуации выводы оценки воздействия на защиту данных были следующими:
 компании необходимо изменить правила, перечислив в них сценарии использова-

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

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

Глава 6. Техническая проверка защиты конфиденциальности

247

6.6.2. Маски и отслеживание контактов
В данном примере мы представим более современную ситуацию, когда дом престарелых позволяет членам семьи навещать своих постояльцев только в медицинских
масках. С целью минимизации личных контактов снаружи здания установлены камеры, которые фотографируют посетителей. Если на лице человека маска, он может войти. Если маски нет, посетителю вход запрещен.
Учитывая последствия, вызванные COVID-19, нетрудно представить использование подобных инструментов в домах престарелых, школах, офисах и других организациях во избежание риска заражения и обеспечения безопасности. Однако на
стороне сервера информацию, собранную в рамках этого процесса, следует обрабатывать с осторожностью.
 Например, где будут храниться фотографии?
 Как долго будут храниться фотографии?
 Кто будет иметь к ним доступ?
 Будет ли программа собирать другие данные о пользователе? Например, хранить

отметку о времени, когда пользователь посетил объект?
 Какие имеются средства защиты и контроля, позволяющие убедиться, что фото-

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

Cassandra, обеспечивая возможность быстрой проверки, а не в хранилище данных вроде Hive, где данные обычно хранятся в течение длительного времени;
 после использования изображения для определения наличия или отсутствия

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

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

248

Часть III. Инструменты и процессы

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

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

Рис. 6.14. Программа для проверки ношения маски

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

Глава 6. Техническая проверка защиты конфиденциальности

249

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

Резюме
 Современные компании быстро внедряют инновации и опираются на сбор данных.
 В рамках общего управления данными и для формирования доверия компаниям

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

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

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

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

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

- ГЛАВА 7 -

Удаление данных

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

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

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

Глава 7. Удаление данных

251

такой сложной, но необходимой работы. Вы узнаете, как обращаться с оперативными и архивными данными с учетом защиты конфиденциальности.
Однако сначала дадим определение удалению данных. В этой книге удаление данных означает физическое или логическое уничтожение идентифицируемых пользовательских данных так, чтобы их нельзя было восстановить, или анонимизацию
данных таким образом, чтобы никто в вашей компании или вне ее, если данные будут раскрыты, не мог повторно их идентифицировать с помощью логических умозаключений.
Акт удаления охватывает системы — начиная от баз данных реального времени и
заканчивая базами данных с архивными данными для систем резервного копирования, в которых компания хранит данные. Крайне важно, чтобы масштаб технических работ по удалению данных — с точки зрения того, какие данные удаляются,
как они изменяются и какие системы затронуты, — согласовывался с заявлениями
(обязательствами перед обществом) компании в отношении удаления и хранения
данных.
П РИМЕЧАНИЕ
Существует множество других юридических определений и интерпретаций удаления,
но, поскольку тематика книги не юридическая, я сосредоточусь на конечном результате удаления, определение которого дано выше.

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

7.1. Почему компания должна удалять данные
Компаниям необходимо удалять данные, чтобы не нарушить нормативные требования вроде тех, что прописаны в GDPR и CCPA.
В статье 17 GDPR изложены конкретные обстоятельства, при которых применяется
право на забвение (https://gdpr-info.eu/art-17-gdpr). Физическое лицо имеет право
на удаление своих личных данных, если:
 персональные данные больше не нужны для тех целей, с которыми организация

первоначально их собирала или обрабатывала;
 организация опирается на согласие пользователя как законное основание для

обработки данных, а пользователь отзывает свое согласие;
 организация полагается на законное право в качестве основания для обработки

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

но пользователь возражает против обработки;
 организация незаконно обработала персональные данные физического лица;

252

Часть III. Инструменты и процессы

 организация должна стереть личные данные, чтобы выполнить судебное реше-

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

информационного общества (https://gdpr-info.eu/art-8-gdpr).
Интерпретация этого списка не входит в обязанности инженеров, но я привел его в
книге, чтобы дать инженерам определенный контекст на случай обращения за юридической консультацией по вопросам защиты конфиденциальности и тонкостям
удаления информации.
В любой компании юристы обычно следят за действием политики удаления и хранения, описывающей, как сотрудники должны обеспечивать защиту данных, хранение и поиск, а также методы удаления/отделения в соответствии с существующими
и ожидаемыми нормами. Политика существует для того, чтобы компания придерживалась известных нормативных указаний и соблюдала права на удаление, изложенные в ее собственной общедоступной политике защиты конфиденциальности.
Это очень важно, поскольку компании часто указывают в своей политике защиты
конфиденциальности, что удаляют данные клиентов, как только они становятся не
нужны.
Однако удаление данных только потому, что это — требование закона, как правило, недальновидный подход. Умные технические руководители будут опираться на
законодательство в области защиты конфиденциальности как на основу и не станут
воспринимать его как потолок, ограничивающий их инструменты защиты конфиденциальности. Помимо обязательных действий по удалению, компаниям следует
предоставить пользователям контроль над их личными данными. Компании должны хранить личные данные только до тех пор, пока они служат бизнес-целям, а
подход к защите конфиденциальности пользователей, сосредоточенный на минимизации данных, в конечном итоге может стать конкурентным преимуществом.
Кроме того, поскольку компании стремятся повысить эффективность хранения
данных и их качество, очень важно идентифицировать, автоматизировать и масштабировать процессы и инструменты удаления данных. В этой главе мы рассмотрим передовые методы удаления, которые я изучил за последние годы, — они варьируются от методов сбора данных компаниями до способов построения логики и
инструментов удаления.
С ОВЕТ
Не следует разрабатывать стратегию удаления только для того, чтобы соответствовать нормативно-правовым требованиям. Удаление дает возможность использовать
дополнительные средства управления защитой конфиденциальности — например,
минимизацию данных за счет устранения запасных или избыточных копий данных.
Удаление — это пример того, как можно использовать вероятность риска нарушения
конфиденциальности для совершенствования организации данных.

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

Глава 7. Удаление данных

253

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

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

7.2.1. Распределенная архитектура и микросервисы:
как компании собирают данные
У каждой организации — собственная уникальная архитектура и возможности хранения данных, но большинство современных компаний используют архитектуру на
базе микросервисов. Чтобы понять, каким образом компании необходимо производить удаление, очень важно знать, как работают современные процессы приема и
хранения данных.
Как видно из рис. 7.1, большинство компаний строят свои возможности не в виде
единого фрагмента кода, а в виде сочетания различных сервисов. В крайнем левом
углу рисунка находится балансировщик нагрузки (англ.: ELB — elastic load
balancer), который решает, как обрабатывать входящие запросы. Они включают в

254

Часть III. Инструменты и процессы

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

Рис. 7.1. Современная инфраструктура микросервисов

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

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

Глава 7. Удаление данных

255

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

7.2.2. Как хранятся получаемые в реальном времени данные
и как организуется к ним доступ
Данные учетной записи клиента (такие как данные для входа в систему, последние
действия, текущие транзакции и т. д.) попадают в базы данных вроде Cassandra,
характеризующиеся малой задержкой отклика и высокой доступностью. Такой
подход в случае необходимости обеспечивает быстрый доступ к данным для обслуживания клиентов. Данные, хранящиеся в таких базах данных, не структурированы. Мы это подробно обсуждали в предыдущих главах.
Рассмотрим, как осуществляется хранение в базе данных Cassandra. Данные хранятся во множестве узлов (местах хранения). Это помогает обеспечить избыточность. Если получить доступ к одному узлу или месту хранения не удается, клиенту, делающему запрос (ищущему товары или совершающему платеж), все равно
может быть оказана помощь.
Положительным аспектом этого подхода является то, что если инженеру придется
разрабатывать новую функцию, для которой потребуются данные о клиентах (например, рекомендации новых товаров клиенту на основе нескольких последних
приобретенных товаров), такая функция сможет получать доступ к данным из нескольких возможных мест хранения. Это важный момент, ведь может оказаться,
что для новой функции потребуется выделенный источник данных, потому что ей
нужно постоянно обновлять данные. Функция может задействовать существующую
мощность источника данных полностью, а избыточность позволит предотвратить
подобные сбои. Кроме того, даже если конкретный узел выйдет из строя или будет
поврежден, новая функция все равно сможет получить доступ к данным клиентов.
Не менее важно, чем понимание процесса хранения и сбора данных в реальном
времени, осмысление процесса хранения агрегированных данных на уровне хранилища данных, где работают инженеры, занимающиеся обработкой данных и машинным обучением. Они используют хранилище для получения информации, которая может помочь в принятии будущих бизнес-решений. Вот почему данные, как
правило, архивируются в хранилищах в течение длительного времени, и именно
здесь часто кроются риски для конфиденциальности. В следующем разделе мы поговорим о таком хранилище.

7.2.3. Хранение архивных данных
Компаниям нередко приходится анализировать собираемые данные, чтобы лучше
разобраться в своем бизнесе. Информация часто накапливается в базах данных, которые могут быть либо хранилищами, либо озерами данных, как показано на
рис. 7.2.

256

Часть III. Инструменты и процессы

Рис. 7.2. Хранилища данных и озера данных

Из рис. 7.2 видно, что хранилища данных и озера данных — это крупные места
хранения данных, предоставляющие аналитикам данных и специалистам по обработке данных компании исторические агрегированные данные, необходимые для
принятия бизнес-решений. И озера, и хранилища данных широко используются для
хранения, но не взаимозаменяемы (www.talend.com/resources/what-is-datawarehouse). Озеро данных — это огромный пул необработанных данных, назначение которых еще не определено. В хранилище данных, с другой стороны, находятся
структурированные, отфильтрованные данные, уже обработанные с конкретной
целью.
Эти два типа хранения данных часто путают, но между ними гораздо больше различий, чем сходства. На самом деле, единственное реальное сходство между ними — это высокоуровневая цель хранения данных.
Отличия важны потому, что эти типы мест хранения данных служат разным целям,
и для их надлежащей оптимизации требуются разные специалисты.
Для одной компании может хорошо работать озеро данных, а для другой лучше
подойдет хранилище.
Для целей этой книги различие между хранилищем данных и озером данных озеро
не так значимо, как сама идея, что оба они — репозитории, где агрегируются данные, собранные микросервисами из систем, работающих в режиме реального времени, таких как Cassandra и MongoDB. Эти места хранения архивных данных —
неважно, хранилища или озера, — консолидируют и централизуют данные, собираемые в потоке от абонента к серверу. Они — место встречи различных трибутарных потоков данных.
Это важно с точки зрения обеспечения конфиденциальности потому, что даже если
хранящиеся в этих архивах данные агрегируются и анонимизируются, объединенные данные из нескольких отдельных источников могут представлять риск повтор-

Глава 7. Удаление данных

257

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

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

Рис. 7.3. Кеширование и распространение данных

258

Часть III. Инструменты и процессы

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

7.2.5. Как хранилище данных превращается
из коллекции в архив
Репликация данных, описанная в предыдущих разделах, затрудняет обеспечение
конфиденциальности. Ранее мы уже обсуждали проблему управления защитой
конфиденциальности, связанную с противоречием между сокращением объема
данных компании во избежание ущерба конфиденциальности и одновременном
открытии доступа к данным для целей бизнеса:
 операций — предоставления клиентам, инженерам и т. д. возможности быстро

находить данные по запросу;
 анализа — предоставления ученым и аналитикам данных возможности исполь-

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

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

Глава 7. Удаление данных

259

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

Рис. 7.4. Как растет объем данных

На рис. 7.4, который вы впервые видели в главе 4, показано, как растет объем данных после их поступления в компанию. Это одна из многих причин, по которым я
рекомендую техническим руководителям классифицировать, каталогизировать
данные и вести их учет ближе к левому концу воронки. Так можно будет быстрее
удалять данные, когда они станут не нужны. Это очень важно потому, что компании, возможно, придется удалить данные по истечении срока хранения (для определенных типов данных) или по запросу клиента/пользователя.
П РИМЕЧАНИЕ
Чтобы иметь возможность удалять данные осмысленно, четко и масштабируемо, компаниям крайне важно классифицировать данные и провести их учет в начале конвейера. Удаление — это не отдельное действие, а часть общей стратегии управления
данными.

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

тах, такие как регистрация и другие операции?
 Как вы будете удалять данные из хранилища? Речь может идти об удалении

личных данных из необработанных таблиц Kafka в Hive после запроса пользователя на удаление учетной записи.

260

Часть III. Инструменты и процессы

 Как вы будете удалять чрезвычайно чувствительные данные, например данные

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

7.3. Как работает архитектура сбора данных
Мы выяснили, как данные передаются из коллекции в клиентской части во внутренние хранилища на уровне сервера.
На рис. 7.5 в упрощенном виде представлен типичный микросервис (прямоугольник слева). Этот сервис принимает запросы пользователей и записывает данные
пользователей в некую базу данных, из которой потом их считывает (цилиндр в
середине). Это может быть одна из множества поддерживаемых баз данных, таких
как MySQL или Cassandra. После записи в базу данных информация попадает в
хранилище данных, откуда ее можно использовать для анализа бизнеса или машинного обучения. С хранилищем данных тоже немало сложностей, но эти детали
выходят за рамки книги.

Рис. 7.5. Поток данных от микросервисов к базе данных и хранилищу данных

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

Глава 7. Удаление данных

261

данных Cassandra, содержащей информацию о добропорядочных пользователях,
или в другой базе данных, где хранится информация о пользователях-мошенниках.
В будущем попытка входа, выполненная данным пользователем, заставит микросервис обратиться к обеим базам данных. В зависимости от того, с какой базой будет совпадение, пользователю будет либо разрешено продолжить работу, либо нет.
Чтобы компания могла осмысленно анализировать модели использования и мошенничества, необходимо провести агрегированный анализ тысяч или миллионов
таких пользователей. Для этого значительную часть данных придется перенести из
баз данных в хранилище.
Это точное, но неполное объяснение. Технические и старшие руководители должны понимать, какой масштаб данных поступает в хранилище, чтобы соотнести свои
ожидания с реальностью и сделать соответствующие инвестиции в инфраструктуру
удаления данных. Рис. 7.6 дает более полное представление о масштабе. В реальном сценарии данные стекаются из нескольких источников, затем преобразуются с
помощью процессов извлечения, преобразования и загрузки (англ.: ETL — extract,
transform, load) и направляются в хранилище данных. Поскольку одни компании
покупают другие, заключают сделки с поставщиками и предоставляют инженерам
возможность создавать больше источников данных (микросервисы, API и т. д.), поток данных в хранилище будет только расти.

Рис. 7.6. Поток данных в хранилище современной компании

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

262

Часть III. Инструменты и процессы

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

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

7.4.1. Удаление учетной записи:
разработка инструментария и процесса
В современных компаниях частой причиной для удаления учетной записи является
звонок (либо электронное письмо, сообщение в социальных сетях) клиента с
просьбой об удалении его учетной записи.
Многие компании изо всех сил пытаются внедрить базовый процесс удаления
учетной записи клиента. Обычный процесс удаления на ранней стадии, при котором следует удалять данные как можно раньше после завершения их использования, может включать следующие действия:
1. При получении запроса на удаление пользовательская запись клиента маркируется (отмечается флажком). Это указывает, что запись данного клиента подлежит
удалению. Можно разработать машиночитаемый тег, например «to_be_deleted».
2. Баланс на счету клиента (возвраты средств) обнуляется.
3. Номер мобильного телефона клиента помечается как доступный для использования новыми клиентами.
4. Фотографии профиля клиента и другие биометрические артефакты удаляются из
хранилища S3.
5. Клиент «удален». На этом этапе могут быть произведены следующие действия:
 Основная информация, позволяющая установить личность клиента (имя, номер мобильного телефона и т. д.), перезаписывается фиктивными или пустыми значениями.
 Все «заметки» удаляются. Это очень важно, поскольку заметки, сделанные
инженерами и специалистами службы поддержки, могут содержать личные
данные. Я часто видел, как инженеры писали в комментариях информацию,
которая идентифицирует клиентов, а потом забывали ее удалить. Многие ин-

Глава 7. Удаление данных

263

циденты, связанные с нарушением конфиденциальности, — результат подобной небрежности, а не злонамеренных действий.
 Все сторонние идентификаторы (социальных сетей, Google+ и т. д.) и соответствующие графы персоналий удаляются, равно как и данные, связанные с
cookie-файлами для таких идентификаторов. Это очень важно, поскольку
часто нарушения конфиденциальности происходят из-за неполного удаления,
когда идентификационные данные впоследствии оказываются связаны с данными о деятельности. Совершенно необходимо обеспечить удаление идентификационных данных во избежание неприятных сюрпризов.
 Все альтернативные адреса электронной почты (если они есть) удаляются.
 Все данные о поведении и логические выводы удаляются.
 Все теги данных удаляются. Эти теги могут указывать на тип данных или
любые детали, обеспечивающие контекст относительно данных.
6. Все платежные профили удаляются. (Мы рассмотрим пример удаления платежных данных в разделе 7.6).
7. Пользователя отписывают от всех типов рассылок, чтобы избежать любого контакта с ним, раз он попросил удалить свои данные.

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

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

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

данных, использующих Kafka (например, Elasticsearch), личные данные могут
сохраниться в записях, которые были отправлены до удаления профиля клиента.
Здесь, возможно, придется разработать специальные меры.
 Удаление может быть запрещено в ряде случаев.

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

264

Часть III. Инструменты и процессы

 Клиент был забанен — тогда может оказаться, что компании необходимо сохранить его данные даже после того, как он отправил запрос на удаление.
 Клиент имеет непогашенный кредитный баланс в случае, если услуга не была
ему оказана после получения оплаты (например, отмена услуги после того,
как будущий месяц уже был оплачен заранее).
 Клиент имеет непогашенный кредит (возврат).
 У клиента имеется задолженность по оплате.
Значительная часть этой информации нередко находится в базах данных, предназначенных только для добавления, т.е. «неизменяемых». Значит, в базе данных хранится история всех совершенных сделок. Это полезно для данных журнала и рекомендуется для Kappa-архитектуры.
Программная архитектура Kappa используется для обработки потоковых данных.
Основная идея заключается в том, что она позволяет выполнять обработку как в
режиме реального времени, так и пакетную, особенно для аналитики, с единым
технологическим стеком. В ее основе лежит потоковая архитектура, в которой входящий ряд данных сначала сохраняется в механизме обмена сообщениями, таком
как Apache Kafka. Оттуда механизм потоковой обработки будет считывать данные
и преобразовывать в анализируемый формат, а затем сохранит их в базе данных
аналитики для запросов конечных пользователей. Этот тип архитектуры получил
широкое распространение. В частности, распределенная файловая система Hadoop,
основа проекта Apache Hadoop, была разработана в данном стиле.
Кроме того, при проектировании инфраструктуры удаления следует учитывать
возможные юридические требования:
 для удаления записей, связанных с внутренними идентификаторами, такими как

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

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

чтобы убедиться, что данные удалены. Если они не сработают, это станет причиной для беспокойства.

Глава 7. Удаление данных

265

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

7.5. Удаление данных на уровне учетной записи:
автоматизация и масштабирование
для распределенных услуг
В данном разделе мы создадим проект высокоуровневой системы для центрального
сервиса удаления, который назовем Destroyer. Вы можете перепрофилировать этот
проект для своих сценариев использования, если решите его применять.
В самом простом понимании Destroyer должен поддерживать удаление личных или
конфиденциальных данных из первичных хранилищ данных компании по запросу
клиента. Для этого задействуются сервисы, которые управляют личными данными
и отвечают на запросы об удалении. Запросы об удалении будет отправлять сервис
планирования, представляющий собой часть сервиса Destroyer.
Чуть позже мы рассмотрим архитектуру сервиса планирования, однако перед тем,
как запланировать удаление данных учетной записи пользователя, необходимо
провести проверку, чтобы убедиться, что данные не подлежат хранению по юридическим причинам. Прежде чем инициировать удаление каких-либо данных клиента,
сервис Destroyer должен проверить необходимость хранения документации по
юридическим причинам. Это следует сделать с помощью модели извлечения. Destroyer отправит запрос в базу данных (или службу), чтобы проверить наличие ограничений на данных, предназначенных для удаления.

266

Часть III. Инструменты и процессы

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

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

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

электронной почты или UUID на удержании по юридическим причинам?
 Каков список сотрудников, подрядчиков или клиентов, на которых распростра-

няется удержание?
 Какова политика хранения в отношении сотрудника, подрядчика или покупателя?

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

Глава 7. Удаление данных

267

менять ко всем API, конкретному API или категории API. Вы можете измерить следующие показатели:
 точность — какова максимально допустимая частота ошибок для ложнополо-

жительных и ложноотрицательных результатов? Сюда могут входить пользовательские записи, возвращенные (чтобы их можно было удалить) при том, что
они подлежат юридическому удержанию, или не возвращенные, даже если на
них нет юридического удержания. Поясню: данные пользователя должны возвращаться для удаления, только если на это нет юридического запрета;
 обрабатывающая способность — какова минимальная требуемая производи-

тельность (запросов в секунду)?
 задержка — каково среднее время отклика и каков 99-й процентиль времени

отклика?
 доступность — каково гарантированное время безотказной работы? Пожалуй-

ста, добавьте обоснование, если значение меньше, чем 99,999 %.
Как только подтвердится, что данные, направленные на удаление, не подлежат
юридическому удержанию, вам потребуется механизм планирования удаления.

7.5.1. Регистрация сервисов и полей данных для удаления
Чтобы управлять запросами на удаление, владельцы сервисов, управляющих персональными данными, должны зарегистрировать свои сервисы и поля персональных данных, которые они обрабатывают, в нашем сервисе удаления Destroyer
(см. выше). Он будет отвечать за инициирование удаления этих полей при выполнении запланированного запроса на удаление.
Как уже говорилось, сбор данных происходит децентрализованно несколькими отделами, разрабатывающими инструменты и возможности для клиентов. Вот почему
крайне важно зарегистрировать эти сервисы в центральном сервисе удаления. Если
не выполнить этот шаг, может получиться, что в одних сервисах данные будут удаляться, а в других — нет. Поверьте, вам не захочется оказаться в ситуации, когда
вы заявили, что данные удалены, а затем узнали, что некоторые поля были пропущены.
П РИМЕЧАНИЕ
В этом проекте мы оптимизируем удаление данных на уровне полей. Следовательно,
можно настроить сервис на удаления полей данных клиентов по отдельности и при
необходимости удалять некоторые учетные записи частично. Например, предположим, что вы управляете веб-сайтом розничной торговли и хотите удалить имена и адреса клиентов в транзакциях, которым больше года, но при этом сохранить историю
покупок для последующего анализа. Для завершения такого удаления можно использовать сервис Destroyer.

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

268

Часть III. Инструменты и процессы

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

ется F, выбирается из заданного списка типов и определяет, какая политика хранения данных применяется к F. Например, название ИМЯ указывает на тип поля, которое необходимо удалить, и на политику хранения, которую нужно к нему применять. Можно составить список типов, один из которых будет
отображаться в этом поле. Например, типы могут быть такими: «имя», «электронная почта», «местоположение» и т. д. Указание поля и типа также может
определять вид удаления, применяемого к самому полю.
 Описание — текст, описывающий, какие данные из поля удаляются, например,

«Удаление имени из MySQL».
 Имя сервиса — название сервиса, который «владеет» полем F (то есть сервиса, в

котором содержится поле данных F), выбранное из списка доступных сервисов.
Владельцев этого сервиса необходимо уведомить в случае таких проблем, как
ошибка удаления или сбой теста.
 Тип API — тип API, который будет предоставляться и вызываться для удаления

сервисом Destroyer.
 Удаление и тестирование шаблонов API — далее я подробно расскажу об уда-

лении API и сопутствующих конечных точках. Предполагается, что для поиска
удаляемого пользователя имеется уникальный идентификатор.
Есть три конечных точки, которые могут быть предоставлены через HTTP или
Thrift API.
В любом из URL-адресов своего шаблона или заголовках конечные точки могут
использовать следующие параметры:
 {user_id} — это внутренний идентификатор удаляемого пользователя;
 {field_type} — мы сопоставим это поле во время выполнения с зарегистриро-

ванным типом поля, выбранного для удаления, например, «ИМЯ». Подход полезен, когда нужно использовать одну и ту же конечную точку для удаления нескольких полей одного и того же UUID;
 {requestor_uuid} — во время выполнения будет соответствовать идентификатору

сервиса, отправившего запрос на удаление.
Учитывая, что удаление, как правило, необратимо, важно тщательно проверять и
сопоставлять поля и сервисы.
Вот три рекомендуемые конечные точки:
1. DELETE — основная конечная точка для поддержки удаления поля для определенного идентификатора.
 Поле должно разрешать передачу трех рассмотренных выше параметров.

Глава 7. Удаление данных

269

 Реализация удаления может варьироваться от полного стирания до замены
целевых полей синтезированными данными для анонимизации. Действие
должны финализировать сотрудники, поддерживающие работу сервиса Destroyer, а также инженеры, использующие Destroyer для удаления данных.
2. GET_TEST_USER — данная конечная точка будет возвращать параметр user_id, который затем будет использоваться для тестирования с целью проверки конечной
точки удаления.
 user_id должен быть действительным пользователем с достаточным количеством данных для адекватной проверки первой части потока удаления, в которой предоставляется учетная запись для удаления.
 При обращении к этой конечной точке сервис будет пытаться настроить
учетную запись пользователя на «обновление» или «восстановление» полей
данных. Учетная запись будет рассматриваться как неудаленная, и поэтому
конечная точка при каждом обращении будет возвращать ее user_id. Таким
образом, в рамках теста можно получить доступ к новой записи для удаления.
 Альтернативой может быть создание нового тестового пользователя при каждом обращении и возвращении user_id. В любом случае, цель состоит в
том, чтобы получить неудаленного пользователя, которого можно будет
удалить.
3. IS_DELETED — это конечная точка, подтверждающая удаление данных конкретного user_id. Конечная точка поможет протестировать вторую часть потока,
выполняющего процесс удаления.
4. Данная конечная точка должна возвращать информацию о том, считается ли пользователь удаленным в соответствии с логикой, указанной в политике удаления.
Остальные детали реализации должны быть хорошо знакомы инженерам, однако
это проектное решение предлагает надежную основу для дальнейшей разработки.
Ключевым элементом удаления является создание очереди, гарантирующей упорядоченное удаление учетных записей. Для этого вам понадобится сервис или функция, которые будут организовывать процесс удаления среди тысяч микросервисов,
инженеров и хранилищ данных, имеющихся в компании. В следующем разделе я
дам несколько советов.

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

270

Часть III. Инструменты и процессы

вам придется изучить несколько политик хранения, чтобы определить подходящую). Политика будет состоять из определений двух периодов: во-первых, срока
хранения данных после отправки запроса на удаление, а во-вторых, увеличенного
срока хранения, применяемого в случае, если на учетную запись наложено активное удержание по юридическим причинам, по истечении которого может быть
предпринята новая попытка удаления.
С точки зрения реализации, получение запроса на удаление равносильно истечению
срока хранения данных этого клиента. Логика действий будет аналогичной, если
срок хранения истечет, а запрос от пользователя не поступит.
Процесс, которому вы будете следовать при разработке логики планирования удаления, может быть таким:
1. Проверить наличие удержания по юридическим причинам — необходимо отправить запрос ответственным за контроль над удержаниями по юридическим
причинам, чтобы узнать, применяется ли удержание к конкретному user_id.
При наличии такого удержания необходимо приостановить удаление, перенести
его срок в соответствии с политикой удержания по юридическим причинам и
повторить попытку позже.
2. Подтвердить возможность удаления пользователя — после истечения срока
удержания по юридическим причинам (если таковой был) необходимо убедиться, что состояние учетной записи пользователя не изменилось за период, прошедший с момента планирования удаления до его выполнения. Например, пользователь, запросивший удаление своей учетной записи, мог продлить подписку.
В этом случае неясно, актуален ли запрос на удаление.
3. Инициировать удаление — на этом шаге выполняется удаление (путем стирания
данных, обфускации и др.).
Планированием удаления учетной записи пользователя или проверкой статуса запроса на удаление необходимо управлять централизованно, чтобы вести реестр успешных и неудачных удалений. Таким образом, если юридическому отделу необходимо будет проверить удаления в нескольких сервисах, им достаточно будет
проверить один центральный источник, а не выискивать владельцев каждого сервиса.
В этом разделе представлена архитектура системы удаления данных учетной записи в оперативных базах данных. Далее мы рассмотрим способы удаления особо
конфиденциальных данных, таких как финансовая информация, которые обычно
хранятся в очень надежной базе данных.

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

Глава 7. Удаление данных

271

У нас также есть вторая база данных (SecureDB), где содержатся данные о платежах, защищенные с помощью инструментов безопасности для предотвращения
кражи и неправомерного использования.
Кроме того, предположим следующие понятия, где «mop» означает «способ оплаты» (англ.: method of payment):
 mop_token_id — это токенизированная версия 16-значной кредитной карты,

хранящаяся в базах данных PaymentsDB и SecureDB, причем последняя является
источником истины. По сути, это случайно сгенерированный идентификатор,
присвоенный реальному значению кредитной карты. Применительно к безопасности данных токенизация — это процесс замены конфиденциального элемента
данных его неконфиденциальным эквивалентом, называемым токеном, который
не имеет внешнего или эксплуатируемого смысла или значения. Токен — это
ссылка, сопоставляемая с конфиденциальными данными через систему токенизации;
 mop_id — этот идентификатор может принадлежать отделу разработчиков сис-

темы платежей. Каждый раз, когда клиент обновляет или вводит номер кредитной карты (даже если он совпадает с предыдущим), будет создаваться новый
mop_id (с помощью генератора последовательности, только выдающего не последовательные, а случайные числа).
Платежная система обычно использует приложение, которое мы в данном примере
назовем Cloud Online Pay (COP). Оно нужно для обработки номеров кредитных
карт клиентов в сочетании с базами данных SecureDB и PaymentsDB.
 Приложение COP получает запрос от другого микросервиса на добавление пла-

тежа. Когда приходит запрос, COP отправляет платежную информацию в базу
данных SecureDB и получает из нее токен (mop_token_id), который COP хранит
в базе данных PaymentsDB (cass_seg_pay). В базе данных Payments хранилища
Cassandra содержится следующая информация:
 объект платежа (mop_id, mop_token_id, имя, фамилия, почтовый индекс) и
статус (основной/неактивный/деактивированный);
 журнал транзакций (активности) со сроком жизни 10 месяцев;
 сопоставление mop_id с mop_token_id. В первом из двух приведенных ниже
примеров этот действие описано более подробно.
 Этот токен (mop_token_id) сохраняется в базе данных PaymentsDB независимо

от того, прошел платеж или нет.
 В базе данных SecureDB хранятся:

 сопоставление токена с зашифрованным платежом (возможная схема: токен,
хешированный идентификатор платежа, зашифрованный идентификатор платежа). Таким образом, мы предоставляем и хешированную, и зашифрованную
версии платежной информации. Так база данных SecureDB возвращает токен
для платежа;

272

Часть III. Инструменты и процессы

 если ранее отправленная кредитная карта используется повторно, приложение пытается найти хешированную и зашифрованную запись и вернуть существующий токен, но может в итоге присвоить и новый токен;
 в случае обратимого удаления в базе данных SecureDB для mop_token_id и
хешированной оплаты может быть установлен более длительный срок хранения — 3 года. При этом API для базы данных, в которой хранятся записи о
подписчиках, информирует службу приема платежей об аннулировании
учетной записи на 10 месяцев. Предполагается, что учетная запись аннулируется на определенный срок — в данном случае 10 месяцев — перед тем, как
будет инициировано формальное удаление. Это позволяет клиенту, чья учетная запись была аннулирована, при желании вернуться и возобновить пользование ею с исходными данными.
На рис. 7.7 показано, как такая система будет обрабатывать удаления. Вот несколько важных моментов:
 система предназначена для пакетного удаления платежных данных клиентов, и
во многих ситуациях в реальной жизни так и происходит, поскольку компании
редко могут удалить данные немедленно. Вот почему компании постоянно заявляют, что системе может потребоваться время, чтобы выполнить запрос на удаление, а изменения учетной записи счета 401k занимают больше одного платежного цикла;
 платежные системы проверяют, была ли в последнее время активность на счете.
В этом случае процесс удаления платежей может быть остановлен;
 удаление происходит поэтапно. При этом данные аккаунта отделяются от платежных данных, после чего сервис Destroyer удалит данные аккаунта, а потом и
данные о платежах.
Стандартный процесс удаления записей о кредитной карте может работать следующим образом:
1. Восходящий микросервис обращается к отделу платежей для инициации очистки.
2. Отдел платежей входит в базу данных PaymentsDB и скрывает все личные данные, заменяя их значения на «PII_WIPE».
3. По истечении указанного срока данные клиента должны быть удалены, платежная система подвергается так называемой очистке личной информации —
«PII_WIPE». Будут удалены:
 журналы действий, содержащие информацию о кредитных картах;
 в таблице, содержащей сведения о соответствии mop_id и mop_token_id, токен заменяется на «PII_WIPE». Как следствие, микросервис платежей не может запросить данные кредитной карты в базе SecureDB, и клиенту не может
быть выставлен счет.
4. Когда микросервис платежей отправляет запрос «PII_WIPE» в базу данных SecureDB, из базы удаляются зашифрованные данные кредитной карты, но сохраняется односторонний хеш карты и ее сопоставление с mop_token_id, а также
определяется срок действия токена — три года.

Глава 7. Удаление данных

273

Рис. 7.7. Удаление данных о платежах

5. При обратимом удалении зашифрованные данные кредитной карты удаляются
из базы данных SecureDB, но хеш и токен кредитной карты сохраняются в течение трех лет, однако они помечены как удаленные с возможностью восстановления. В этом случае кредитной картой нельзя воспользоваться для совершения
платежей.
6. При окончательном удалении удаляется также и mop_token_id. Это происходит,
когда клиент запрашивает полное удаление данных своей кредитной карты.

274

Часть III. Инструменты и процессы

В случае, если одной кредитной картой пользуются несколько покупателей, а вам
нужно удалить данные карты только у одного из них, отдел платежей может выполнить так называемое отсоединение. Это позволит учесть ситуацию, когда клиенты C1 и C2 (а может, и другие) пользуются одной кредиткой. База данных PaymentsDB будет выглядеть как на рис. 7.8.

Рис. 7.8. Общие кредитные карты

Кроме того, база данных содержит строку со списком всех клиентов, на которых
ссылается mop_token_id. Например, [(mop_token_id), (C1, C2)]. Сопоставление
mop_token_id с C1 и C2 показывает, что оба клиента используют один и тот же платежный инструмент.
Если C1 отправит запрос на удаление данных кредитной карты, вышеупомянутая
строка сообщит платежной системе, что кредитная карта является общей. Затем
платежная система выполнит следующие действия:
 установит для mop_id значение «PII_WIPE»;
 отсоединит элемент C1 на рис. 7.8 от mop_token_id;
 элемент C2 на рис. 7.8 по-прежнему будет связан с элементом mop_token_id;
 в

примере
[(mop_token_id),(C1,
[(mop_token_id),(C2)].

C2)]

запись

поменяется

на

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

7.7. Кто должен управлять удалением данных
Вы, наверное, уже поняли, что процесс удаления данных может быть очень непростым и трудоемким. В итоге компаниям нередко бывает трудно определить, кто
именно из сотрудников ответственен за логику и инфраструктуру удаления.
По моему опыту, наиболее масштабируемым и эффективным вариантом удаления
данных клиента является такой, при котором сервис Destroyer принадлежит центральному отделу по защите конфиденциальности, а другие отделы управляют API
удаления.
Удаление данных из хранилища — задача посложнее. Важно, чтобы за ее выполнение отвечал конкретный человек. В противном случае существует риск несоответствия нормативно-правовым требованиям, а также эксфильтрации данных в результате нарушений безопасности. В табл. 7.1 представлены различные варианты и
компромиссы, возможные при распределении обязанностей по удалению.

Глава 7. Удаление данных

275

Я не рекомендую назначать специальную команду сотрудников. Вместо этого организуйте группу Хранения Данных из сотрудников разных отделов. Она будет отвечать за удаление информации из хранилищ данных. В группу могут входить инженеры из разных отделов, а разработкой и обслуживанием службы удаления
Hadoop может заниматься группа, уже осуществляющая техническую поддержку
работы Hadoop в компании.
В табл. 7.1 показаны три возможных варианта распределения ответственности за
удаление и сопутствующие им компромиссы.
Таблица 7.1. Варианты управления удалением
Управляющий
Преимущества
API удаления
и Хранители Данных

Недостатки

Все группы инженеров

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

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

Центральная группа по Одна группа отвечает за внедрение
защите конфиденции сопровождение сервиса.
альности
Библиотеке удаления Hadoop нужно будет поддерживать минимальное количество клиентов.

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

Сборщик данных
Hadoop и хранитель

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

*Предпочтительно*

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

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

дами, работающими с системой Hadoop;

276

Часть III. Инструменты и процессы

 проверка кода, с которым работают отделы, пользующиеся хранилищами дан-

ных, и настройка мониторинга для своевременного удаления;
 настройка фильтров для обнаружения данных, которые необходимо удалить до

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

Резюме
 Удаление данных — важная обязанность компании и ключевой компонент ее

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

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

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

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

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

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

- ГЛАВА 8 -

Экспорт пользовательских данных:
запрос субъекта на доступ
к персональным данным

В этой главе мы рассмотрим:
 понятие запросов субъекта на доступ к персональным данным (DSAR);
 как DSAR вписывается в обязательства компании по защите конфиденциальности;
 формирование процесса выполнения DSAR;
 автоматизацию DSAR;
 настройку данных в DSAR;
 как администраторы могут создавать DSAR.

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

278

Часть III. Инструменты и процессы

В-третьих, мы рассмотрим создание внутреннего инструмента для управления процессом DSAR и сопоставим то, что отображается на экране пользователя, с решениями о данных на уровне сервера. У многих компаний не получается создать подобный инструмент, и это приводит к снижению эффективности при создании
DSAR и управлении взаимодействием с пользователем.
В целом, здесь представлены передовые методы разработки собственной платформы DSAR, ее компонентов на уровне пользовательского интерфейса и сервера, а
также приводится достаточно информации, чтобы выбрать продукт стороннего
разработчика, соответствующий вашим потребностям.
Обязательство по выполнению DSAR требует от компании способности собирать,
обрабатывать, сохранять и архивировать данные клиента таким образом, чтобы их
можно было предоставить по его запросу. Крайне важно, чтобы компания могла
сделать это в срок, установленный законодательством в той юрисдикции, где проживает клиент, и способом, отвечающим общественным настроениям.
Эту задачу было гораздо проще выполнить несколько лет назад, когда структура
компаний была нисходящей и позволяла регулировать, какие данные собираются.
Во многих компаниях собираемые в то время данные были более структурированными и определенными, поскольку хранить их было очень дорого, а взаимодействие с пользователем не было так ориентировано на его вовлечение и сбор конфиденциальных данных. Хранение данных также происходило в конечном числе баз
данных, четко контролируемых ИТ-администраторами компании.
Современная инновационная экосистема разительно отличается от мира, существовавшего всего пять лет назад. Сегодня компании, как правило, больше ориентированы на целесообразность, инновации и разрыв связей, а в их способности соответствовать требованиям прозрачности данных клиентов главную роль играют единообразие, обобщение и объяснение. Форсирующие функции, стимулирующие рост и
вовлеченность, идут вразрез с теми, которые стимулируют проверку конфиденциальности и нормативные проверки.
Вот почему в этой книге управление данными рассматривается как непрерывная
работа, а основное внимание в главе уделяется разработке системы и процесса экспорта пользовательских данных. Чем скорее компании создадут интерфейсные и
серверные возможности для DSAR, тем лучше. Искать данные станет проще после
того, как вы превратите их сбор, учет и экспорт в единый комплексный процесс.
Однако прежде, чем углубиться в тему, начнем с основ: что такое DSAR?

8.1. Что такое DSAR
Прежде чем подробно объяснять, что такое DSAR, стоит определить их роль в общей среде защиты конфиденциальности и управления, а также поместить DSAR в
контекст повествования данной книги. Этот контекст полезен, поскольку DSAR —
относительно новое явление, а компаниям необходимо правильно их выполнять с
акцентом на конфиденциальность.

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 279

Ранее я объяснял, как встроить защиту конфиденциальных данных и управление
ими, начиная с точки сбора данных. Техническим руководителям и их начальству
крайне важно осознать понятие распределенной архитектуры (т. е. разрозненных
сервисов, обрабатывающих данные, а также различных хранилищ, существующих
для сохранения данных). Это поможет им понять, почему защиту конфиденциальности трудно встроить в системы компании. Подобные вложения в технологический стек компании жизненно необходимы, чтобы дать ей возможность осмысленно и масштабируемо классифицировать и каталогизировать свои данные, делиться
данными, имеющими элементы управления защитой конфиденциальности, удалять
данные и проводить технические проверки новых продуктов и функций защиты
конфиденциальности.
Однако обязательства компании в отношении конфиденциальности не ограничиваются управлением данными в замкнутых системах или обменом информацией с
партнерами. Вызванные отчасти общественными настроениями, а отчасти требованиями законодательства и регулирующих органов, в обществе существуют ожидания, что компании смогут предоставить клиентам копию тех данных, которые о них
собрали. Вот тут-то и появляются DSAR.
Запрос субъекта на доступ к персональным данным (DSAR) — это средство, с помощью которого люди просят компанию раскрыть для них хранящиеся у нее личные данные пользователя и то, как она их использует или намерена использовать.
Отправка DSAR — право субъекта данных, гарантируемое потребителям в соответствии с законами о конфиденциальности данных, такими как Закон Калифорнии о
защите персональных данных потребителей (CCPA) и Общий регламент по защите
данных (GDPR). Эти законы не только рассказывают потребителям об их правах в
отношении собственных персональных данных, но и предоставляют необходимые
инструменты, чтобы этими правами воспользоваться (http://mng.bz/Bx52).
Если обязательства компании по удалению данных являются результатом нормативного «права на забвение», то обязательства по DSAR — это результат стремления регулирующих органов обеспечить больше прозрачности для клиентов относительно того, что компании делают с данными своих клиентов и пользователей
(https://gdpr.eu/right-to-be-forgotten). На рис. 8.1 показано, как эволюционируют
запросы DSAR под влиянием развития законодательства в области защиты конфиденциальности по всему миру.
И хотя техническим специалистам и руководителям часто не требуется вникать в
юридические тонкости, изучить подробнее тему DSAR крайне важно по следующим причинам:
 инфраструктура DSAR является продолжением работы, которую следовало про-

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

адекватным ответом на DSAR;
 данные, которые вы предоставляете клиентам в ответ на DSAR, выходят за пре-

делы вашей компании, оказываются в открытом доступе и могут подвергнуться

280

Часть III. Инструменты и процессы

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

Рис. 8.1. Как законы о защите конфиденциальности
предоставляют клиентам права DSAR

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

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 281

Своевременные и четкие ответы на запросы DSAR могут повысить доверие ключевых заинтересованных сторон к компаниям, а также обеспечить соблюдение нормативных требований. Однако стоимость выполнения каждого DSAR для некоторых компаний может оказаться чрезмерной, поскольку для этого нужно извлечь
данные из нескольких систем и собрать их вместе, просмотреть записи данных и
обобщить результаты в один понятный отчет.
Руководителям, считающим, что выполнение DSAR можно отодвинуть на задний
план, стоит спросить себя: что произойдет, если клиенты или кто-нибудь еще запустят массовую отправку DSAR и завалят вашу компанию запросами? Развивать
эту функцию крайне важно.
П РЕДУПРЕЖДЕНИЕ
Директора и технические руководители должны учитывать, что DSAR могут поступать
не только от клиентов, но и от других лиц, стремящихся с их помощью подорвать бизнес компании. В любом случае удобно, когда для выполнения запросов применяются
отлаженное управление данными и автоматизация.

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

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

нарушений конфиденциальности и безопасности данных.
Приведенный ниже контрольный список, хоть и не является исчерпывающим, но
содержит детали, которые необходимо включить в ответ на DSAR (https://securiti.ai/
blog/dsar-rights-and-compliance):
1. Подтверждение того, что компания обрабатывает персональные данные пользователя (под «обработкой» может подразумеваться «использование», однако этот
аспект следует уточнить у юристов).
2. Запись или файл, содержащий личные данные пользователя.
3. Объяснение законного основания, на котором компания обрабатывает данные клиентов. Эта информация должна быть согласована с отделами защиты конфиденциальности, юридическим, инженерным и другими, которые собирают данные.

282

Часть III. Инструменты и процессы

4. Период, в течение которого будут храниться данные. Это требование задает тон
в новом мире, где компании больше не могут собирать и хранить данные сколько им угодно. Вместо этого они должны указывать конкретные обоснованные
периоды сбора и хранения данных.
5. Подробности о происхождении данных — как были получены данные, из каких
источников и т. д.
6. Любые доступные сведения о том, каким образом данные клиента использовались для автоматизированного принятия решений и профилирования.
7. Названия сторонних компаний и иных партнеров, с которыми вы делились информацией о пользователе.
Учитывая быстро меняющийся нормативный ландшафт в сфере защиты конфиденциальности и безопасности, полезно сравнить права, предоставляемые некоторыми уже действующими общими законами. На рис. 8.2 показано, что отличия
таких нормативных актов, как GDPR и CCPA, варьируются от незначительных до
существенных (рисунок основан на одной из иллюстраций Эрика Эндрюса,
https://securiti.ai/blog/dsar-rights-and-compliance).

Рис. 8.2. Права клиентов, предоставляемые CCPA и GDPR

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

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 283

8.1.2. Обзор процесса выполнения DSAR
Компании, которые выросли и преуспели благодаря облегченным процессам, скудной документации и демократизированному подходу к развитию, часто выступают
против применения процессов, необходимых, чтобы масштабировать обязательства
относительно DSAR. Приведенный ниже контрольный список будет полезен им, а
также и более зрелым компаниям, плохо знакомым с областью защиты конфиденциальности.
Процесс выполнения DSAR включает в себя следующие основные этапы (источники: Andrews, «DSARs: What You Need to Know»; Kokkengada, «6 Keys to Automating
the DSAR Process Under CCPA»):
1. Записать и проверить запросы DSAR. Очень важно, чтобы компании вели учет
запросов DSAR — когда получены и от кого. Соответственно, необходимо:
 документировать полученные DSAR;
 убедиться, что записи DSAR нельзя изменять. Они должны оставаться достоверным источником;
 аутентифицировать пользователя, чтобы иметь подтверждение его личности,
прежде чем начинать процесс сбора данных о клиентах. Учитывая, с какой
частотой во многие компании поступают DSAR, возможно, стоит автоматизировать аутентификацию, чтобы масштабировать весь процесс.
2. У клиентов есть несколько способов подать DSAR: по электронной почте, телефону или другим каналам, однако компании также должны предоставить форму
для DSAR, которая будет обладать следующими характеристиками:
 быть встроенной в веб-сайт компании, что облегчит ее поиск для подавляющего большинства клиентов;
 быть персонализированной, особенно у компаний, которые обслуживают несколько регионов, где закреплены права пользователей на DSAR. Возможно,
для этого компании придется управлять несколькими формами, разработанными для потребителей из разных регионов;
 возможно, содержать функции, которые позволят клиентам выбирать из ряда
предопределенных вариантов, хоть это и удлинит процесс согласования с
юридическими партнерами. Такие варианты послужат шаблоном, из которого
внутренние процессы автоматизации будут извлекать различные версии данных. Предоставить клиентам выбор с помощью шаблонов — разумное решение, однако вам придется удостовериться, что все шаблоны соответствуют
правилам применения;
 предлагать способ четко изложить запрос клиента. Клиент может хотеть просто запросить копию своих данных (с помощью DSAR) или полностью закрыть свою учетную запись (попросив компанию удалить личную информацию). Очень важно, чтобы компания понимала характер запроса прежде, чем
примет необратимые решения в отношении данных пользователя.

284

Часть III. Инструменты и процессы

3. Идентифицировать пользователя — злоумышленники могут использовать
DSAR для захвата чужой учетной записи, поэтому вам необходимо собрать достаточно пользовательских данных для проверки, что пользователь, запрашивающий DSAR, является тем, за кого себя выдает. С этой целью применяются
стандартные меры проверки личности, такие как многофакторная аутентификация и другие. Эти меры имеют решающее значение для защиты входящих запросов, предотвращения мошенничества (например, сценариев захвата учетной
записи или кражи финансовых данных) и устранения запросов от ботов.
4. Собрать из внутренних баз данных и других хранилищ данных личную информацию клиента, необходимую для DSAR — чтобы реагировать на DSAR, компаниям необходимо находить и классифицировать данные, которые они обрабатывают и хранят. Как упоминалось в предыдущих главах, эти данные часто хранятся в нескольких структурированных и неструктурированных базах данных, а
также базах данных в оперативной памяти и в других местах как внутри компании, так и вне ее. Составление каталога таких данных и его регулярное обновление имеет решающее значение для DSAR. Отправной точкой для создания такого каталога являются методы учета данных, рассмотренные в главе 4.
5. Сопоставить идентификаторы пользователя для точного сбора данных —
возможно, у пользователя, отправившего DSAR на вашем сайте, есть несколько
идентификаторов. Например, он мог использовать идентификаторы Google и
Facebook (ныне продукт корпорации Meta Platforms Inc., признана экстремистской организацией на территории РФ). Чтобы собрать все необходимые данные
для создания DSAR, вам потребуется построить граф персоналий, который свяжет все эти личности и их данные. Учитывая объемы и природу собираемых
компаниями данных, процесс связывания нельзя выполнить в больших масштабах в короткие сроки. Я рекомендую начинать эту работу на ранней стадии, еще
до получения DSAR.
6. Просмотреть и утвердить информацию — после сбора необходимой информации компаниям (в частности, их юридическим отделам и отделам по защите
конфиденциальности) необходимо просмотреть данные и убедиться, что они соответствуют требованиям DSAR в той юрисдикции, в которой находится компания, а также не раскрывают служебную информацию или личные данные других
пользователей. Крайне важно сохранить эти документы на случай, если возникнут сомнения в точности или полноте ответа на DSAR, и его решат проверить.
7. Безопасно доставить информацию о клиенте — ответ на DSAR должен быть
доставлен пользователю с применением достаточных методов защиты. Компанию могут привлечь к ответственности, наложить штрафы и пени, если данные,
собранные для DSAR, окажутся взломаны или украдены. В связи с этим жизненно важно классифицировать данные по степени риска и применять соответствующие меры безопасности во время экспорта ответа на DSAR так же, как и
во время хранения и обработки данных внутри компании.

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 285

8. Учитывать исключения при выполнении DSAR — помимо запроса о доступе к
своим данным, клиент может также подать запрос на удаление этих данных.
Правила DSAR предусматривают ряд исключений и освобождений от обязательств, о которых компаниям необходимо знать и проконсультироваться со
своими юристами насчет их применимости. Это помогает сбалансировать
стремление человека к конфиденциальности и требование бизнеса сохранить
данные.
9. К исключениям для выполнения запроса на удаление данных, согласно Закону
Калифорнии о защите персональных данных, относятся:
 информация, необходимая для совершения транзакции;
 данные, связанные с безопасностью, которые необходимо сохранить для обнаружения мошенничества и привлечения виновных к ответственности;
 личная информация, которую может потребоваться сохранить для идентификации и исправления ошибок программы;
 соблюдение требований Закона Калифорнии о защите электронных систем
связи. Организациям нельзя удалять определенную информацию, если личные данные были запрошены правоохранительными органами штата. Возможно, компании придется создать еще одну копию данных клиента и хранить ее в защищенной базе данных, к которой будут иметь доступ только избранные сотрудники так, чтобы до момента удаления данных хранились под
строгим контролем доступа;
 личная информация, собранная с целью изучения интересов общества;
 соблюдение правовых норм. Любая личная информация, которую компания
должна хранить для выполнения юридического обязательства, не подлежит
удалению по запросу клиента.
В этом списке приводятся основные аспекты выполнения DSAR. Учитывая новизну
области защиты конфиденциальности данных и самих запросов DSAR, многим
компаниям стоит выработать развертываемый и настраиваемый рабочий процесс,
помогающий получать запросы DSAR, отслеживать их и выполнять. Следующий
раздел поможет сформировать такой рабочий процесс.

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

286

Часть III. Инструменты и процессы

8.2.1. Ключевые этапы создания системы выполнения DSAR
Прежде всего, рассмотрим создание рабочего процесса для выполнения DSAR. В
предыдущем разделе мы говорили о рабочем процессе, а здесь обсудим ключевые
этапы взаимодействия администратора с системой DSAR.
1. Получение доступа к инструментам DSAR. Специалисты по защите конфиденциальности компании могут извлекать данные пользователей для выполнения
DSAR с помощью запросов к базам данных. Однако чтобы масштабировать возможности DSAR, рекомендуется разработать пользовательский интерфейс, предоставляющий заинтересованным сторонам возможность извлекать внутренние
данные для DSAR.
2. Учитывая характер данных, которые можно получить для DSAR, доступом к такому инструменту рекомендуется управлять. Управление доступом в пользовательском интерфейсе для DSAR будет выглядеть так:
 внутренние пользователи, ответственные за сбор данных для DSAR, должны
иметь возможность получить доступ к инструменту выполнения DSAR, войдя в систему с данными своей рабочей учетной записи;
 внутренние пользователи должны будут пройти двухфакторную аутентификацию, чтобы получить доступ к инструменту.
3. Будет разумно установить более строгие меры контроля, если ваша компания
работает в строго регулируемой среде или содержит данные с высокой степенью
чувствительности.
4. Разработка контроля доступа к инструменту выполнения DSAR — чтобы не
позволить злоумышленникам внутри компании нарушать правила использования системы выполнения DSAR, могут потребоваться специальные средства
контроля доступа:
 настройка элементов управления таким образом, чтобы DSAR могла выполнить только ограниченная группа людей в «белом списке» для этого запроса;
 настройка элементов управления таким образом, чтобы внутренние пользователи были авторизованы только в течение определенного периода времени,
например, 30 дней. Тогда пользователям придется, получив доступ к данным
для выполнения DSAR, экспортировать данные клиенту, который их запросил, или же повторно запрашивать эти данные;
 принятие дополнительных мер безопасности — таких, как ограничение скорости API, которые отображают данные DSAR и ведут журналы, показывающие, кто имел доступ к этим данным.
5. Запрос пользовательских данных для DSAR — инженер, извлекающий данные
для выполнения запроса DSAR, должен будет предоставить внутренние идентификаторы, идентифицирующие клиента, который запросил данные, в базах дан-

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 287

ных компании, или глобальный идентификатор (email, номер карточки социального страхования и т. д.) одним из следующих способов:
 Вручную введя идентификатор в соответствующее поле для одного пользователя и заполнив запрос на получение данных отдельного пользователя.
 Сгенерировав DSAR для нескольких пользователей и создав «пакетный запрос». Это можно реализовать, если позволить сотрудникам загружать таблицы CSV/Google, содержащие идентификаторы (внутренние идентификаторы, адреса электронной почты и т. д.) для группы пользователей. Таким образом можно масштабировать работу, а не извлекать данные пользователей по
одному набору за раз.
6. Определение диапазона дат для запроса DSAR. К тому времени, когда компании
начнут получать запросы DSAR, у них, скорее всего, уже будут накоплены данные за несколько лет. Несмотря на то, что во многих запросах требуется предоставить все собранные данные пользователя, рекомендуется также разработать
возможности для извлечения данных за выбранный период. Тогда системы будут
реагировать на уточненные запросы и не будут перегружать базы данных сервера.
7. В таком сценарии внутренний пользователь, создающий DSAR, сможет выбрать
один из двух вариантов:
 Стандартный DSAR за весь период. Преимущество данного варианта: можно
быть уверенным, что у вас есть все данные пользователя, при условии, что вы
правильно пометили данные.
 Сгруппированные и ограниченные по времени DSAR. В этом случае у вас получится заполненный DSAR, в котором в некоторых полях данных сведения
не будут охватывать весь период взаимодействия пользователя с вашей компанией. Можно создавать группы полей данных, где каждая группа будет
иметь регулируемые временные рамки (30 дней, 3 месяца, 1 год, все время).
Например, клиенту веб-сайта розничной торговли может потребоваться копия всей истории его покупок, но только для определенных товаров.
 Наличие фильтров по времени или конкретным товарам поможет управлять
DSAR пользователей. В противном случае вам придется запускать трудоемкие запросы, получать больше данных, чем запросил клиент, а затем выбирать из них конкретные сведения, которые ему нужны. Это не только неэффективно, но и плохо масштабируется, учитывая число конкурирующих запросов к одним и тем же базам данных (например, от специалистов по
обработке данных, проводящим анализ) и количество DSAR, которые компания может обслужить.
 Проблема возникает также из-за того, что инженерам приходится разбираться
не только с данными в истории, но и с недавно полученными данными. Руководители компании часто не понимают, что постепенное накопление данных
в конечном итоге приводит к проблемам, поэтому возможность извлечения
подмножества данных — это продуманное инженерное решение и стратегически грамотная инвестиция.

288

Часть III. Инструменты и процессы

8. Проверка частоты запросов DSAR. Рекомендуется также настроить инструмент
выполнения DSAR или пользовательский интерфейс таким образом, чтобы помечать пользователей (с помощью методов, применяемых для учета данных в
главе 4), отправлявших DSAR в течение последних 12 месяцев. Цель данной
конфигурации или маркировки в том, чтобы помочь распознать пользователя
как уже отправлявшего DSAR и получившего ответ, если он снова отправит
DSAR. В данном случае его стоит пометить, чтобы юридический отдел компании мог выяснить, не пытаются ли определенные пользователи перегрузить систему с помощью DSAR (например, путем создания частых запросов).
Представленный выше список не является исчерпывающим. Его задача — служить
руководством для проектирования и применения системы во всех типах компаний.
Процесс может казаться простым, но когда DSAR появляются в условиях напряженного графика и перерасхода ресурсов, полезно иметь предсказуемый и повторяемый процесс, позволяющий удовлетворить ожидания клиентов, не отвлекая дополнительные внутренние ресурсы, чтобы компенсировать недочеты процессов.
Далее мы рассмотрим, как можно усовершенствовать ответ на DSAR с помощью
информационной панели, которая будет информировать и консультировать персонал, работающий над DSAR, руководителей, юристов и аудиторов.

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

Триггер

Нет

Заявка DSAR была открыта, но работа по ней еще не проводилась..

Подтвержден

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

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 289
Таблица 8.1 (окончание)
Состояние

Триггер

В обработке

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

Подготовлен
к юридической
проверке

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

На рассмотрении

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

Юридическая проверка завершена

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

Экспортирован
субъекту данных

Специалист по защите конфиденциальности отправляет файл пользователю и обновляет статус заявки на «закрыта» с пометкой «файл
отправлен пользователю».

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

Рис. 8.3. Процесс изменения состояния запроса DSAR

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

290

Часть III. Инструменты и процессы

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

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

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

Значение

Шаблон DSAR

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

Параллелепипед
DSAR

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

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 291

Теперь, когда мы разобрались с определениями, разобьем работу системы доставки
DSAR на отдельные модули. Каждый модуль будет предоставлять определенный
функционал сотрудникам компании, извлекающим данные для DSAR. Разработка и
объединение модулей поможет автоматизировать процесс выполнения DSAR.
Комплексная служба автоматизации выполнения DSAR состоит из пяти элементов:
1. Модуль шаблона DSAR. Этот сервис позволяет создавать стандартные DSAR и
предоставляется пользователям, которые запрашивают копию своих данных. Он
обеспечивает две ключевые возможности:
 перечислить шаблоны DSAR, заданные по умолчанию, — возможно, компаниям придется определить конечное число шаблонов DSAR для поддержки определенных контекстов и географических регионов. В данном модуле нужно
будет перечислить все такие шаблоны, чтобы администратор мог поддерживать шаблон, наиболее подходящий для конкретного запроса пользователя;
 обновить или вставить шаблон DSAR — UPSERT — это функция системы
управления базой данных, позволяющая автору команды на языке манипулирования данными DML вставить отдельную строку, либо, если строка уже
существует, безопасно обновить ее, не задумываясь о происходящей параллельно обработке данных. Этот модуль должен позволять администратору
исправлять шаблоны DSAR в соответствии с нормативными изменениями.
2. Модуль пакетных запросов DSAR. Выбрав шаблон для конкретного DSAR, администратор должен запустить выполнение этого шаблона. Этот модуль будет
заниматься его выполнением и обладать следующими ключевыми возможностями:
 выполнение DSAR для одного пользователя;
 выполнение пакетных DSAR, где каждый пакет включает несколько DSAR;
 возобновление выполнения DSAR в случае проблем с данными или их зависимостями, на устранение которых может потребоваться некоторое время.
Эта возможность позволит администратору возобновлять попытки и продолжать их на основе предыдущих неудачных запусков, используя промежуточные результаты. И не нужно будет начинать заново;
 получение статуса запроса DSAR, который затем будет использоваться для
обновления заявок, описанных выше.
3. Комбинирование/сборка — этот модуль позволит администратору запроса DSAR
комбинировать и собирать данные из HDFS (распределенной файловой системы
Hadoop), группировать данные по пользователям и таблицам, а также загружать
их на сервер для хранения или передачи пользователю, отправившему DSAR.
Логику разработки обсудим чуть позже.
4. Конвейер данных — модуль комбинирования/сборки будет извлекать данные, но
вам также нужен способ направить данные обратно в систему HDFS, чтобы предоставить их пользователю, отправившему запрос. Эту функцию выполняет модуль конвейера данных. Зная имя таблицы, набор выбранных столбцов таблицы,

292

Часть III. Инструменты и процессы

список идентификаторов пользователей и временны́е интервалы, конвейер будет
извлекать данные пользователя и помещать результаты в HDFS. В некотором
смысле полученные данные для запроса DSAR являются трехмерными (таблица/столбцы * пользователь * период времени).
5. Журнал контроля. Компании, получающие и выполняющие DSAR, должны вести журналы контроля для последующих проверок — с целью подтвердить правильность самих запросов DSAR или гарантировать, что они были созданы и
доступны законными путями. Для этой цели понадобится служба, которая будет
создавать метаданные для каждого DSAR. Эта служба также будет публиковать
журналы в Kafka, и они будут использоваться системой управления базами данных HIVE через Hadoop. В случае аудита эта библиотека (сочетание журналов
контроля и журналов регистрации) предоставит основные SQL-запросы, помогающие запрашивать соответствующие таблицы и собирать информацию.
Рассмотрев элементы автоматизированного процесса выполнения DSAR, перейдем
к их практической реализации, начиная с моделей в форме параллелепипеда и заканчивая шаблонами.

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

сы на разработку шаблонов, которые потом не используют;
 кроме того, для понимания характера структуры данных перед тем, как вклады-

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

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

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 293

тов до зоотоваров и товаров для дома. Сайт собирает данные клиентов, чтобы рекомендовать товары на основе их прошлых покупок. Затем, по мере роста бизнеса,
вы решаете приобрести дополнительно данные от сторонних компаний для анализа
поведения.
Расширение данных позволит предлагать товары не только на основе истории покупок, но и прогноза поведения (например, если кто-то покупает диетический корм
для собаки, сайт может порекомендовать им другие продукты для собак, которым
нужно похудеть, — пищевые добавки, средства по уходу за зубами для пожилых
собак и т. д.). Можно купить данные с веб-сайтов, полученные в ходе исследований, участники которых обладают схожими характеристиками с вашими клиентами.
Теперь предположим, что путь клиента как пользователя был следующий:
 он добавляет в корзину беззерновые продукты, совершает покупку и больше ни-

чего не смотрит;
 на основе доступных с вашего сайта данных о клиенте можно сделать вывод, что

он принадлежит к определенной возрастной группе;
 у вас также есть информация об адресе клиента, исходя из того, куда отправля-

ется более 90 % его покупок;
 анализ данных показывает, что такие клиенты (в этой возрастной группе, зака-

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

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

данных Hive;
 данные, купленные у сторонней компании, хранятся в 30 совершенно разных

таблицах в хранилище данных;
 данные, приобретенные у сторонней компании, охватывают определенный пе-

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

294

Часть III. Инструменты и процессы

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

вующих таблиц.
Выполняя DSAR конкретного пользователя, вместо обращения ко всему набору
данных можно запустить запросы для меньших параллелепипедов.
Предположим, мы хотим выполнить запросы DSAR для 1 000 пользователей (используя одинаковый шаблон во всех случаях), в котором будет содержаться 10 таблиц для каждого пользователя за период, равный 1 000 дней. Чтобы запустить запросы на более фрагментированной основе, одна конфигурация параллелепипеда
будет получать данные по 100 пользователям одновременно, по 1 таблице на пользователя и за период в 100 дней.

Рис. 8.4. Модель в форме параллелепипеда
для выполнения запроса DSAR

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

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 295

рата вертикальными линиями обозначено количество таблиц, включенных в DSAR,
а горизонтальными — период времени, охватываемый запросом.
Различные комбинации темных блоков дают некоторое представление о компромиссах, связанных с обработкой отдельных DSAR как части более крупного пакета.
Например, для некоторых пользователей нужно обработать большее количество
таблиц, но охватывающих меньший промежуток времени, а для других — меньшее
количество таблиц, но за более продолжительное время.
Выяснив, как можно разбивать запросы DSAR, теперь рассмотрим разработку шаблона для DSAR.
П РИМЕЧАНИЕ
Компаниям придется идти на компромиссы при обработке DSAR. Применение шаблонов обеспечит повторение и воспроизводимость, но может связать вам руки с точки
зрения предоставления пользователю всех данных. Модель в форме параллелепипеда предлагает бо́льшую гибкость и может обеспечить целенаправленное обнаружение, позволяя выбрать объем данных (в зависимости от количества таблиц и временного периода), который будет отправлен тому или другому пользователю.

8.3.3. Шаблоны DSAR
Шаблоны DSAR служат двум основным целям. Во-первых, администратор внутри
компании может использовать шаблон для получения полных данных (или подмножества данных с помощью модели в форме параллелепипеда), а во-вторых, они
позволяют записывать данные DSAR в шаблон, который отправляется пользователю.
В табл. 8.3 представлен простой в использовании практический шаблон для создания DSAR.
Таблица 8.3. Шаблон DSAR
Первичный ключ: id; Секционный ключ: Type
Поле

Тип

Описание

id

Идентификатор
пользователя

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

datasources

Массив таблиц

Список таблиц, столбцов и интервал времени.

created_by

Идентификатор
пользователя

Это уникальный идентификатор запрашивающей стороны, создавшей DSAR от имени пользователя.

created_at

Дата/время

Указывает время, когда запрашивающая сторона создала DSAR от имени пользователя(ей). Для сохранения согласованности должны быть указаны в кодировке ISO-8601.

updated_by

Идентификатор
пользователя

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

296

Часть III. Инструменты и процессы
Таблица 8.3 (окончание)

Поле

Тип

Описание

updated_at

Дата/время

Время, когда инициатор запроса обновил DSAR от
имени пользователя(ей). Кодировка ISO-8601. Если
запись не была обновлена, значение такое же, как в
поле created_at.

is_active

Логический

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

В листинге 8.1 показан пример запроса, который можно использовать для создания
шаблона DSAR. Вам придется обновить поля, чтобы они соответствовали вашей
схеме данных.
Листинг 8.1. Запрос для шаблона DSAR
CREATE TYPEDEF type_struct (
type int32;
);
CREATE TABLE DSARtemplate
(
id
userID;
data_attribute_name STRING(100);
category STRING(100);
datasources STRING(1000); **
created_by
userID;
created_at DATETIME;
updated_by
userID;
updated_at DATETIME;
type
type_struct;
is_active BOOL;
) PRIMARY KEY ((type), userID);

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

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 297

8.3.4. Источники данных для шаблонов DSAR
Из листинга 8.1 видно, что в каждом шаблоне DSAR обозначены определенные
таблицы для извлечения данных. Для каждой таблицы, поддерживаемой шаблоном
DSAR, необходимо указать поля, из которых будут браться данные.
Каждый запрос DSAR содержит список таблиц вместе с данными столбца, столбцом UUID или индекса и охватываемым периодом.
Как уже говорилось, не нужно извлекать всю информацию из заданной таблицы,
так как трехмерный подход позволяет предоставить частичный набор данных.
В табл. 8.4 показано, как можно задать таблицы источников данных для шаблона
DSAR.
Таблица 8.4. Предоставление источников данных для шаблона DSAR
Источник данных
Поле

Тип

Описание

table_name

string

Название таблицы (таблиц), включенной в запрос
DSAR.

lookbackInDays

integer

Количество дней в заданном периоде, начиная со дня
создания запроса о доступе к данным.
Например: значение 365 означает, что вы запрашиваете данные за 1 год из определенного источника данных.

columns

array<string>

Список столбцов, которые нужно экспортировать из
таблицы или источника данных в DSAR.

userID

string

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

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

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

298

Часть III. Инструменты и процессы

 по мере внедрения компанией новых таблиц для DSAR длина каждого запроса

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

источников данных;
 индивидуальный источник данных — это определяемая пользователем структу-

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

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

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

правляться ко всем записям в таблицах и столбцах в поле DataSource.

Рис. 8.5. Определение источников данных в перечисляемых форматах

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

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 299

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

жества инструментов;
 при сохранении DSAR в таблицах хранилища Hive выходные данные можно тут

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

формации не будет серьезной проблемой.
Также стоит изучить недостатки Hive как места хранения данных DSAR:
 вставки и обновления могут происходить медленно. Хранилище Hive изначаль-

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

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

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

300

Часть III. Инструменты и процессы

Кроме того, они помогут логически соединить архитектуру на стороне сервера и решения, касающиеся данных, из разделов 8.2 и 8.3, с действиями пользователя. Если
бы вы покупали готовое стороннее решение, то платили бы как раз за соответствие
серверного и пользовательского интерфейсов. Вот почему необходимо понять, как
эти две части работают вместе, чтобы принять обоснованное решение о том, стоит ли
создавать собственное проектное решение для DSAR или лучше купить готовое.
Первый проект, который мы рассмотрим, — это информационная панель для отслеживания хода выполнения текущих DSAR. Рис. 8.6 сообщает администраторам
DSAR, специалистам по защите конфиденциальности и юридическому отделу
фрагменты важной информации:
 линии DSAR объединяются в один идентификатор запроса (Request ID), что по-

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

выполнения;
 указывается статус для каждой группы DSAR.

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

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

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 301

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

Рис. 8.7. Два варианта извлечения данных DSAR

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

302

Часть III. Инструменты и процессы

Рис. 8.8. Функция добавления пользователей в запрос DSAR по одному

Рис. 8.9. Добавление пользователей к DSAR по одному — процесс выбора

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

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 303

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

Рис. 8.10. Экран проверки перед извлечением данных DSAR

На рис. 8.12 показано, что результат может быть таким же (рис. 8.11), как при добавлении пользователей по одному. Для выполнения окончательной проверки перед запуском ресурсозатратных запросов DSAR к внутренним базам данных компании можно сделать кнопку «Добавить» или функцию удаления (X), чтобы отменить выбор.
После того как были указаны пользователи, для которых отправляется DSAR, можно выбрать:
 таблицы, из которых нужно перенести данные пользователя для заполнения

DSAR;
 период, за который вам нужны данные для DSAR.

304

Часть III. Инструменты и процессы

Рис. 8.11. Добавление пользователей для выполнения DSAR через электронную таблицу

Рис. 8.12. Добавление пользователей к DSAR
с помощью электронной таблицы и функции выбора

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 305

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

Рис. 8.13. Выбор таблиц для запроса DSAR

306

Часть III. Инструменты и процессы

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

Рис. 8.14. Создание запроса для всех таблиц за все время

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

Глава 8. Экспорт пользовательских данных: запрос субъекта на доступ к персональным… 307

Рис. 8.15. Создание DSAR, адаптированного для разных периодов для каждой таблицы

Резюме
 DSAR — ключевое требование для бизнеса, поскольку нормативные акты в об-









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

- ЧАСТЬ IV -

Безопасность, масштабирование
и кадровое обеспечение
Учитывая тесную связь конфиденциальности и безопасности, крайне важно устранить пробелы в безопасности, которые могут нанести ущерб конфиденциальности.
Также полезно определить ориентиры, позволяющие измерить зрелость предложения компании в сфере конфиденциальности. Посвященная управлению и соответствующим инструментам, данная часть поможет разработать профессиональное и
зрелое инженерное предложение по обеспечению конфиденциальности.
В главе 10 мы подробно рассмотрим инциденты, связанные с нарушением безопасности, их воздействие на защиту конфиденциальности и способы исправления ситуации. Здесь вопросы обеспечения конфиденциальности и безопасности объединены в рубрику защиты данных, почти как в GDPR.
Глава 11 поможет инженерам спланировать модели зрелости для программы защиты конфиденциальности.
Поскольку инженерия конфиденциальности превращается в самостоятельную отрасль знания по аналогии с разработкой программного обеспечения, крайне важно
перечислить основные возможности и степень их реализованности. В данной главе
дается основа, которую инженеры в силу чрезмерной занятости обычно не могут
разработать самостоятельно.

- ГЛАВА 9 -

Разработка платформы
управления согласием

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

ния согласием;
 какие ключевые возможности позволяют оптимизировать платформу управле-

ния согласием;
 как интегрируется платформа управления согласием в бизнес-процесс.

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

312

Часть IV. Безопасность, масштабирование и кадровое обеспечение

вятся очень важны для организаций, которые собирают данные о клиентах. В то же
время характер современного бизнеса и инженерной разработки усложняет эти задачи. Для простоты я буду называть все действия такого рода в совокупности
управлением согласием, а процесс автоматизации в этом ключе — платформой
управления согласием (англ.: CMP — consent management platform).
Управление согласием — относительно новая область деятельности для многих
компаний. Как и для инженеров, работающих в этих компаниях и создающих инструменты, которые собирают данные клиентов. Эта область в новинку и клиентам.
На протяжении многих лет обмен данными и услугами (клиенты предоставляют
данные в обмен на онлайн-инструменты) казался интуитивно понятным. Все изменилось с появлением таких законов, как GDPR и CCPA, а также изменением настроений в обществе и повышением интереса к защите конфиденциальности.
Чтобы предоставить контекст компаниям, работа которых зависит от законных и
прозрачных сбора и обработки данных клиентов, в этой главе мы сначала раскроем
значение управления согласием для компаний с точки зрения регулирования. Затем
подробно разберем реализацию CMP. Для этого придется изучить базу данных на
стороне сервера и связи с ней, а также несколько примеров кода, которые при всестороннем анализе помогут вам понять, как разработать свою платформу управления согласием.
Мы также рассмотрим другие аспекты, связанные с созданием CMP. Многие компании сталкиваются в этой области с двумя проблемами. Во-первых, в маленьких,
растущих, а иногда и в крупных компаниях может не быть больших отделов по защите конфиденциальности, разработке или юридического, но эти фирмы все равно
обязаны соблюдать общие правила, касающиеся согласия. Во-вторых, необходимо
гарантировать, что клиенты, пользующиеся услугами компании, массово дадут это
согласие. Отсутствие согласия мешает компании использовать собираемые данные.
Вот почему управление согласием на сегодняшний день — одна из крупнейших
проблем в области защиты конфиденциальности и соответствия требованиям законодательства.
Специалисты по защите конфиденциальности должны убедиться, что инструменты
для получения согласия внедряются таким образом, чтобы не сбивать с толку клиентов. Иначе это может привести к неоптимальным результатам в удержании клиентов.
В первом разделе данной главы будет приведен контекст, поясняющий, зачем компаниям нужно получать согласие.

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

Глава 9. Разработка платформы управления согласием

313

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

9.1.1. Управление согласием и нормативные документы
в области защиты конфиденциальности
В тексте Общего регламента по защите данных (GDPR) говорится, что «Общему
регламенту по защите данных необходимы правовые основы для обработки данных». Ниже приведен список таких оснований (https://gdpr.eu/gdpr-consentrequirements):
1. Обработка необходима для выполнения договора, стороной которого является
субъект данных.
2. Данные необходимо обработать, чтобы выполнить юридическое обязательство.
3. Данные необходимо обработать, чтобы спасти чью-то жизнь.
4. Обработка необходима для выполнения задачи в общественных интересах или
для осуществления какой-либо официальной функции.
5. Наличие согласие пользователя.
6. Наличие законного права на обработку чьих-либо персональных данных. (Это
самая гибкая правовая основа, хотя «основные права и свободы субъекта данных» всегда важнее ваших деловых интересов, особенно если это данные ребенка).
Простой способ избежать крупных штрафов за нарушение GDPR — всегда получать разрешение клиентов до использования их персональных данных (https://gdpr.eu/
fines). Но, вопреки распространенному мнению, GDPR не требует, чтобы компании
получали согласие клиентов прежде, чем обрабатывать их личную информацию
для деловых целей. Скорее согласие является одним из шести правовых оснований,
изложенных в статье 6 GDPR (http://mng.bz/oaVD). Компании должны указать
правовую основу для обработки этих данных.
П РИМЕЧАНИЕ
Хочу напомнить, что в этой книге нет юридических рекомендаций. Для определения
степени применимости согласия в вашем бизнесе, а также полноты любого реализуемого решения, следует обратиться к юрисконсульту.

Идея заключается в том, что если у компании, собирающей данные, есть законное
основание (наличие согласия является одним из правовых оснований), ей разрешено собирать и обрабатывать данные.
Определение согласия в Общем регламенте по защите данных гласит, что «Согласие субъекта данных означает любое свободно данное, конкретное, информированное и недвусмысленное указание пожеланий субъекта данных…» (статья 4(11)). В
определении содержится больше подробностей, однако инженерам и техническим

314

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

дали субъекта данных соглашаться на использование его (ее) данных. Вопервых, это значит, что вы не можете потребовать согласия на обработку данных в качестве условия использования сервиса. У пользователя должна быть
возможность сказать «нет». Единственное исключение — если вам нужен фрагмент данных пользователя для предоставления услуги. Например, вам могут понадобиться данные его кредитной карты для обработки транзакции или почтовый адрес для отправки товара;
 конкретное — когда вы собираете пользовательские данные, должно быть ясно,

какие действия по их обработке вы намереваетесь выполнять. Пользователь
должен иметь возможность выразить согласие на каждое действие. Итак, если
вам нужен адрес электронной почты пользователя в маркетинговых целях и его
IP-адрес для веб-аналитики, следует объяснить каждый случай использования
данных отдельно, предоставляя субъектам данных возможность дать согласие на
каждое действие по отдельности. Это требование подразумевает очень детальный набор элементов в инфраструктуре согласия, чтобы точно отслеживать и
поддерживать статусы согласия;
 информированное — клиент, чьи данные вы собираете, должен знать, кто вы,

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

ных согласие. Недвусмысленное согласие «может включать пометку в соответствующем поле при посещении веб-сайта, выборе технических настроек и т. д.».
(Декларация GDPR, 32);
 с возможностью отзыва — пользователь, давший согласие, имеет право ото-

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

Глава 9. Разработка платформы управления согласием

315

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

9.1.2. Управление согласием и изменения
в технологической отрасли
Не только правительства, но и некоторые технологические компании, предоставляющие платформы и шлюзы для сбора данных, тоже начали требовать согласия
пользователей, прежде чем позволить бизнесу собирать их данные. Например, корпорация Apple объявила, что для выпуска новых приложений и обновлений к приложениям разработчики должны на странице своего продукта предоставить информацию о применяемых в их приложениях методах сбора данных
(http://mng.bz/nYxd). И начиная с iOS 14.5, iPadOS 14.5 и tvOS 14.5, разработчики
приложений должны будут спрашивать у пользователей разрешения отслеживать
их в приложениях и на веб-сайтах, принадлежащих другим компаниям.
Эта новость важна по нескольким причинам:
 сервис App Store корпорации Apple — это ключевой посредник, с помощью ко-

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

зации и поведенческой аналитики, и зависящая от отслеживания пользователей
в Интернете;
 даже действия, не нацеленные на получение прибыли, типа выявления случаев

мошенничества, требуют сбора данных.
В настоящее время корпорация Apple позволяет владельцам iPhone с помощью настроек отключить данный тип отслеживания. Теперь вместо того, чтобы заставлять
пользователей самих отключать эту функцию, корпорация Apple потребует, чтобы
разработчики сначала запросили у пользователей разрешение. При несоблюдении
или попытке обхода правил их приложение может быть приостановлено или удалено из App Store.
Большинству из нас уже знакома ситуация, когда находишь товар онлайн, откладываешь в корзину, но так и не покупаешь. Затем, перейдя на следующий веб-сайт,
вдруг видишь рекламу того самого не купленного товара. Даже люди, не разбирающиеся в технологиях, понимают, что связь между онлайн-активностью и рекламой не случайна. Это результат нескольких автоматизированных действий.

316

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Во-первых, исходный веб-сайт (или приложение) собирает уникальный идентификатор для рекламодателей Apple (англ.: IDFA — identifier for advertisers). Далее
первое приложение связывает действия пользователя с IDFA, а затем отправляет
IDFA следующим приложениям, которые посещает пользователь. У одного из этих
приложений окажется собственное экранное пространство, где оно будет показывать рекламу в обмен на деньги от рекламодателей. Идентификатор IDFA и связанный с ним пользовательский контекст позволяют этим приложениям показывать
пользователям персонализированную рекламу. IDFA также помогает приложениям
отслеживать эффективность рекламы, предоставляя сведения о том, как долго объявление оставалось на экране, нажал ли на него пользователь и т. д. Таким образом,
сочетание идентификатора, данных о действиях пользователя, связанных с этим
идентификатором, и возможности коллективно делиться идентификатором обеспечивает работу Интернета, финансируемого за счет рекламы (http://mng.bz/voOa).
Новое требование корпорации Apple заставит владельцев приложений (они же разработчики приложений) получать четкое согласие от пользователей, прежде чем
собирать их данные, прикреплять к IDFA и делиться ими с кем-либо. Следовательно, владельцу приложения необходимо будет иметь согласие пользователя на все
действия: от сбора данных до использования и отслеживания. Это новая проблема
для компаний, ведь раньше они осуществляли все эти действия, а согласие пользователя подразумевалось. Функция включалась у пользователя по умолчанию, а он
должен был отказаться, если хотел. Такое соглашение означало для пользователей
более высокий уровень взаимодействия, а для издателей и владельцев приложений — более эффективную рекламу. Новая договоренность (когда пользователи
исходно не подключены и должны согласиться на подключение) приведет к снижению показателей участия и уменьшению доходов.
Непонятно, какие штрафы и действия по ремедиации будут наложены на разработчиков приложений, если они пойдут наперекор требованиям корпорации Apple относительно отслеживания и надлежащего учета. Для малого бизнеса удаление из
App Store и потеря доступа к клиентской базе пользователей iOS — нежелательный
результат с финансовой точки зрения.
Таким образом, знание контекста поможет вам разобраться в требованиях корпорации Apple, прежде чем разрабатывать серверную часть процесса управления согласием. Это позволит инженерам оценить детализацию согласия и сложность его получения.
Как уже говорилось, начиная с iOS 14.5, iPadOS 14.5 и tvOS 14.5 разработчикам приложений, чтобы отслеживать пользователей или получать доступ к идентификатору
для рекламодателей на их устройствах, необходимо получить разрешение пользователя через фреймворк AppTrackingTransparency. Корпорация Apple определяет понятие отслеживания в документации разработчика App Store (http://mng.bz/nYxd).
Отслеживание — это акт связывания данных о пользователе или устройстве, собранных из приложения, с данными о пользователе или устройстве, собранными из
приложений, веб-сайтов или офлайн-ресурсов других компаний для целевой рекламы или измерений с целью рекламы. Отслеживанием также является передача
данных о пользователе или устройстве брокерам данных.

Глава 9. Разработка платформы управления согласием

317

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

ранных из приложений и веб-сайтов, принадлежащих другим компаниям;
 передачу данных о местоположении устройства или списков адресов электрон-

ной почты брокеру данных;
 передачу списка адресов электронной почты, рекламных идентификаторов или

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

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

9.1.3. Управление согласием и ваш бизнес
Слишком часто инженеры считают, что управление согласием сводится к крохотному, обычно предустановленному флажку. Такой подход можно охарактеризовать
как «режим отказа», при котором пользователь считается предварительно согласившимся и должен вовремя отказаться, сняв флажок.
До того как новости о нарушениях конфиденциальности стали популярны в СМИ и
до принятия законов о защите конфиденциальности, эта модель продолжала распространяться. Впрочем, возможно, это изменится.
Во-первых, многие клиенты теперь способны заметить предварительно установленный флажок и снять его, если не доверяют компании или не уверены в том, как
это повлияет на их конфиденциальность. Во-вторых, из-за разросшейся взаимосвязанной экосистемы данных и регулирования со стороны правительства предустановленный флажок теперь не выход. Это означает, что репутация вашей компании
по части сбора, обработки и защиты данных, может влиять на скорость, с которой
пользователи будут давать согласие. В связи с этим все технические инструменты,
описанные в книге, имеют большое значение, однако не менее важно иметь надежную платформу управления согласием.
Хорошо спроектированная серверная часть жизненно необходима для управления
согласием, поскольку позволяет точно отслеживать, какое раскрытие информации
относится к какому региону и согласился ли на это пользователь или нет. Учитывая, что клиенты теперь могут проверить с помощью DSAR, какие данные о них вы
собираете, важно, чтобы управление согласием было четко сформулировано.

318

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Непонятный, многословный текст или вводящий в заблуждение внешний интерфейс также может привести к снижению коэффициента получения согласия. В этом
сценарии на вашей платформе может быть высокий уровень использования услуг и
вовлеченности, но не будет подтверждающих это данных. Вы не сможете монетизировать сервис и добавлять возможности, финансируемые пользователями.
Инженерам, которые все еще могут быть настроены скептически, полезно прочитать результаты опроса, посвященного вышеупомянутому изменению корпорации
Apple. Согласно новому анализу, проведенному платформой Flurry Analytics, по
состоянию на конец лета 2021 года только 5 % ежедневных пользователей iOS 14.5
в США дали свое согласие (http://mng.bz/4jvQ, http://mng.bz/g4YG).
Платформа Flurry Analytics, принадлежащая компании Verizon Media, используется
более чем в 1 млн мобильных приложений на 2 млрд устройств. Она ежедневно собирает и обновляет данные в приложении, отслеживая долю согласий, просматривая ежедневно миллионы активных мобильных пользователей, уже установивших
новую операционную систему.
Согласно результатам исследования, опубликованного порталом Mashable, показатель согласия по миру в целом немного выше (http://mng.bz/XWAE). На момент
написания этой книги он составлял 13 %. У платформы Flurry есть данные о
5,3 миллионах пользователей iOS 14.5 по всему миру.
Изменения в процессе получения согласия почти наверняка будут иметь измеримые побочные эффекты для бизнеса. Однако компании могут решить хотя бы часть
этой проблемы, создав надежную платформу управления согласием. Следующий
раздел поможет вам построить такую платформу и ее критические компоненты
снизу вверх.

9.2. Платформа управления согласием
Платформа управления согласием (CMP) представляет собой совокупность возможностей, позволяющих веб-сайту или приложению:
 информировать посетителей о типах данных, которые у них будут собирать;
 запрашивать у пользователей согласие на обработку данных с определенными

целями.
Как указывалось ранее, CMP включает в себя множество возможностей, связанных
с предоставлением пользователю управления согласием на обработку этой информации на сервере. По сути, они представляют собой высшую точку функций защиты конфиденциальности, которые способствуют соблюдению нормативноправовых требований, а также функций защиты конфиденциальности, помогающих
завоевать доверие пользователей. В частности, с точки зрения функций, CMP позволяют (https://piwik.pro/blog/consent-management-platforms-comparison):
 предоставить пользователям возможность дать согласие, а затем управлять дан-

ными этих пользователей на основе полученного согласия;

Глава 9. Разработка платформы управления согласием

319

 предложить пользовательский интерфейс, позволяющий пользователю дать со-

гласие (например, баннеры, всплывающие окна и т. д.);
 прежде чем активировать рекламные теги, убедиться, что получено соответст-

вующее согласие, чтобы гарантировать, что любой показ персонализированной
рекламы осуществляется после получения согласия (http://mng.bz/y42e);
 связать собранные данные с будущими DSAR. Возможно, полученные данные

пользователей придется экспортировать как ответ на DSAR. Будет разумно связать их с помощью CMP на раннем этапе.
Взаимодействуя с пользователем, CMP служит следующим целям компании:
 уведомляет клиентов о сборе и обработке персональных данных;
 предоставляет клиентам возможность применить детализированные настройки

конфиденциальности, связанные с согласием;
 собирает предпочтения клиентов в cookie-файл согласия, удовлетворяющий требованиям Бюро интерактивной рекламы (англ.: IAB — Interactive Advertising Bureau), которым можно будет поделиться с проверенными партнерами. Этот контекст жизненно важен для компаний, которые получают доход из экосистемы
онлайн-рекламы или являются ее частью. IAB — глобальная бизнес-организация, объединяющая онлайн-рекламодателей и маркетологов. Их «Стандарт прозрачности и согласия» помогает издателям, рекламодателям и поставщикам технологий соответствовать требованиям прозрачности и согласия, прописанным в
GDPR. Ваша CMP должна соответствовать требованиям стандарта IAB;
 позволяет компании получить доступ к журналу аудита, который отслеживает
согласие пользователя.
CMP состоит из двух важных компонентов: внешнего и внутреннего интерфейсов.
Внешний интерфейс CMP напрямую влияет на пользователей и клиентов. Пользуясь им, они могут выбрать, на сбор и использование каких данных дать согласие.
Дизайн и пользовательский интерфейс такой CMP будет зависеть от вашего бизнеса и данных, которые вы хотите собрать. Пример пользовательского интерфейса
CMP приводится на рис. 9.1.
Внешний интерфейс CMP на рис. 9.1 объясняет различные сценарии использования
для сбора данных, начиная от аналитики и заканчивая тестированием, отслеживанием конверсий, маркетингом и обратной связью. В соответствии с рекомендациями
GDPR, все это отдельные варианты, устанавливаемые с помощью переключателей.
С инженерной точки зрения, разработать внешний интерфейс CMP относительно
просто. Однако когда разрешения привязаны к нескольким местоположениям, устройствам и языкам, управлять данными на стороне сервера может быть очень
сложно. Вот почему инженерам необходимо сначала построить ментальную модель
управления согласием и лишь потом начинать работу над внутренним кодом.
Как уже говорилось, различные источники принуждения компаний к получению
согласия — от правил до игроков отрасли и самих клиентов — подталкивают к
дисциплинированному учету. Остальная часть главы поможет инженерам и руководителям технических программ спроектировать серверную часть.

320

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Рис. 9.1. Внешний интерфейс CMP

При разработке серверной части CMP необходимо учитывать модель данных и код
конечных точек. Сначала рассмотрим отношения между различными элементами
архитектуры, а затем подробно изучим код, который также поможет определить
конечные точки, их общедоступные API, объекты запроса и объекты ответа.
В следующем разделе определены такие компоненты и схемы.

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

Глава 9. Разработка платформы управления согласием

321

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

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

322

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Рис. 9.2. Отношения между различными элементами
хранения сведений о согласии

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

9.3.2. Схемы отношений элементов: база данных CMP
Теперь, когда определены отношения между различными элементами, набросаем
схему базы данных. На рис. 9.3 показано, как можно определить эти элементы и
отношения.

Глава 9. Разработка платформы управления согласием

323

В качестве примера при рассмотрении отношений схемы мы используем иерархию,
также показанную на рис. 9.3.

Рис. 9.3. Пример схемы получения согласия

Таблица Feature
Теперь рассмотрим таблицы одну за другой, чтобы получить представление об их
расположении в базе данных. Сначала изучим схему таблицы Feature, показанную
на рис. 9.4.
С ОВЕТ
Пример в этой главе является иллюстративным, но допускает перестановки. В нем вы
увидите ситуации, когда возможности и поля значительно повышают целостность. Однако для продукта с минимально необходимым функционалом (англ: MVP — minimum
viable product) не обязательно реализовывать все возможности, особенно в ситуации,
когда компании приходится создавать платформу для получения согласия под давлением обстоятельств. В таких случаях инженеры могут использовать следующий шаблон и выбрать поля, наиболее подходящие для их ситуации.

324

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

Рис. 9.4. Схема таблицы Feature

Преимущество этого поля в том, что оно свяжет функцию с контролирующим ее
отделом, позволяя проверить использование данных, соответствующих функции.
Это упрощает задачи удаления данных, шифрования и т. д. В будущем вы только
порадуетесь, что предусмотрительно сопоставили функции с сотрудниками, которые их контролируют. И все же, если цель — получить согласие на использование
функции, чтобы выйти на рынок или выполнить нормативные требования, это поле
можно убрать из версии CMP с минимально необходимым функционалом.
Учитывая, что названия отделов (обычно) нечисловые (строковые), значением атрибута owning_team будет строка. Как и значение атрибута feature_name, описывающего имя функции. Однако для каждой функции также потребуются нестроковые поля, которые будут использоваться для однозначной идентификации функции
и служить первичным ключом. В схеме для функции также используется атрибут
disclosure_uuid, однозначно идентифицирующий документы о разглашении данных. Кроме того, в большинстве сценариев у каждой функции будет несколько документов о разглашении данных (политики конфиденциальности, условия использования, документы о раскрытии маркетинговой информации и т. д.). Поле disclosure_uuid будет содержать много значений, поэтому реальное представление базы
данных функции может выглядеть как в табл. 9.1.
Таблица 9.1. Образцы значений таблицы Feature
Feature ABCD
feature_uuid ef42c910-981e-11eb-a8b3-0242ac130003
disclosure_uuid 0b712ee2-981f-11eb-a8b3-0242ac130003 16de1fe2-981f-11eba8b30242ac130003 1f1f0644-981f-11eb-a8b3-0242ac130003
owning_team "Marketing"
feature_name "communication opt-in"

Глава 9. Разработка платформы управления согласием

325

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

Таблица Disclosure_Version
Вторая таблица, на которую мы обратим внимание, — Disclosure_Version, показанная на рис. 9.5.

Рис. 9.5. Схема таблицы Disclosure_Version

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

глашении данных у вас может быть несколько версий политики конфиденциальности, но версией 1 из них будет только одна. Следовательно, UUID версии
служит первичным ключом;
 disclosure_uuid — служит в качестве UUID документов о разглашении дан-

ных. Для нескольких версий может быть один и тот же атрибут disclosure_uuid. Ниже мы рассмотрим пример, чтобы объяснить этот аспект.
Вышеупомянутые поля имеют решающее значение, поскольку у любых документов
о разглашении данных должен быть уникальный идентификатор как для них самих,
так и для всех версий. Однако, как только у вас появится стабильный MVP, можно
рассмотреть другие поля, например:
 business_purpose_names — строки для хранения описательной информации;
 required_feature_update — позволяет определить, действительно ли пользова-

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

326

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

сия документа о разглашении данных обязательной для каждого устройства. Это
очень важно, так как разные устройства могут иметь разные версии или варианты документов о разглашении данных;
 Territory_granularity — географический охват для версии документа о раз-

глашении данных, например, страна, штат и т. д.;
 updated_at — временна́я метка, указывающая, когда в последний раз была об-

новлена версия документа о разглашении данных.
В табл. 9.2 приведен пример того, как может выглядеть запись таблицы Disclosure_Version.
Таблица 9.2. Примеры значений таблицы Disclosure_Version
Disclosure_Version ABCD
disclosure_version_uuid ef42u910-981e-11eb-a8b3-0242ac130003
disclosure_uuid 0b712ee2-981f-11eb-a8b3-0242ac130003
data_types "This disclosure covers "
business_purpose_name "communication opt-in"
mandatory_feature_update true
is_per_device true
Territory_granularity country
updated_at 2020/09/09

Таблица «Согласие пользователя»
Третья таблица — это таблица User_Consent, которая содержит историю согласия
пользователя. Схема таблицы показана на рис. 9.6.
В идеале таблица User_Consent должна включать в себя следующие поля как часть
MVP:
 user_uuid — служит первичным ключом. Поскольку в таблице будет содер-

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

Глава 9. Разработка платформы управления согласием

327

Рис. 9.6. Схема таблицы User_Consent

 disclosure_uuid — содержит UUID всех документов о разглашении данных,

которые пользователь согласился или отказался предоставить. Это решение
можно реализовать разными способами, но мне представляется удобным сопоставление пользователей с документами о разглашении данных по принципу
«один-ко-многим», так как один пользователь столкнется в веб-интерфейсе и
приложениях с несколькими видами документов о разглашении данных;
 locale_copy_uuid — содержит идентификаторы копий документов о разглаше-

нии данных, специфичных для конкретных локалей. Как и в случае с полем disclosure_uuid,
здесь будут сопоставляться поля disclosure_uuid и
locale_copy_uuid. Другими словами, для UUID одного вида документов о разглашении данных может быть несколько UUID конкретных локалей. У вас также будет внутреннее сопоставление, где у каждого пользователя будет несколько документов о разглашении данных, а у каждого вида документов о разглашении данных — несколько копий для конкретных локалей. Создание такого
сопоставления данных будет иметь последствия с точки зрения вашей способности хранить согласия на раскрытие информации, обновлять их и представлять
доказательства функциональности согласия во время аудитов. Следовательно,
необходимо разрабатывать схемы аккуратно.
Для обеспечения работоспособности CMP жизненно важно суметь сопоставить поле user_uuid с соответствующим документом о разглашении данных и его локальной копией. Вот почему настоятельно рекомендуется включить в MVP перечисленные выше поля. По мере развития системы также рекомендуется добавить
следующие:
 device_id — идентификатор, связанный с устройством и позволяющий его

идентифицировать. Он будет сопоставляться с полем locale_copy_uuid, поскольку устройство принимает не документ о разглашении данных, а его версию
для конкретной локали;
 compliance — это может быть двоичное значение true/false (истина/ложь) или 1/0,

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

328

Часть IV. Безопасность, масштабирование и кадровое обеспечение

документа о разглашении данных для конкретной локали на своем iPhone, но не
примет на устройстве с операционной системой Android. Так у вас может оказаться несколько строк с сопоставлением полей device_id и compliance;
 ip_address — будет записан IP-адрес, с которого было получено предоставлен-

ное пользователем согласие, чтобы в случае аудита можно было указать, где находился пользователь, когда давал согласие;
 time.Time — здесь будет храниться время, чтобы гарантировать, что наряду с

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

Таблица Locale_Copy
Следующая таблица — Locale_Copy, которая будет содержать информацию о документах о разглашении данных для конкретной локали (см. рис. 9.7).

Рис. 9.7. Схема таблицы Locale_Copy

У таблицы Locale_Copy относительно простая схема, и в ней MVP будет включать
в себя следующие поля:
 locale_copy_uuid — UUID версии конкретных документов о разглашении дан-

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

персональных данных. Атрибут обеспечивает дополнительную детализацию документа о раскрытии персональных данных, поскольку для каждого документа,
специфичного для конкретного региона, у вас может быть несколько версий;
 locale_uuid — UUID для каждой локали. Пусть это и не самое важное сопос-

тавление, но оно гарантирует наличие четкого соответствия между конкретным

Глава 9. Разработка платформы управления согласием

329

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

Таблица LocaleTerritory
Последняя таблица, схему которой мы рассмотрим, — LocaleTerritory на рис. 9.8.

Рис. 9.8. Схема таблицы LocaleTerritory

Данная таблица содержит три поля, детализирующие местоположение, чтобы документ о разглашении данных для определенной локали можно было с ней сопоставить. У самой локали есть UUID, служащий в качестве первичного ключа записи.
Он сопоставляется с таким же ключом в таблице Locale_Copy.
Два других поля — не обязательные для MVP, но впоследствии их можно вести,
чтобы предоставить дополнительную информацию о местоположении. Инженеры,
внедряющие решение, могут задать для поля territoryID числовой идентификатор, а не строку. Это снизит количество ошибок. Подобным образом можно задать
коды для поля territoryGranularity, чтобы очертить область, которую охватывает документ о разглашении данных. Если сделать эти два поля необязательными, то
логично добавить еще поле имени, чтобы лучше понимать отдельные записи.
Столь подробное описание этого проекта отчасти обусловлено личным опытом.
Однажды я консультировал компанию, которая обратилась ко мне после того, как
предоставила клиенту неправильные документы о разглашении данных. Речь шла
не о злом умысле, а просто о небрежности инженеров. Они неверно соотнесли политику конфиденциальности для Франции на французском языке с пользователями
из Канады, установившими на своих iPhone французский язык в качестве выбранного по умолчанию. Пользователь, получивший неправильную политику конфиденциальности, пожаловался в местные органы по защите конфиденциальности,
что обернулось серьезным расследованием методов защиты конфиденциальности и

330

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

9.4. Код согласия: объекты
В этом разделе мы поговорим о коде на языке программирования Thrift, помогающем определить ключевые возможности управления согласием, о которых говорилось выше. Далее показано, как соотнести ключевые структуры данных, а также
объекты-запросы и объекты-ответы с функциональными возможностями, необходимыми для получения и сохранения согласия пользователей. Обратите внимание,
что хоть я и определил в прошлом разделе критически важные для MVP поля, ниже
приводится код для более полной системы. Его можно скорректировать в зависимости от ваших желаний и потребностей.
П РИМЕЧАНИЕ
Если вы хотите узнать больше о языке программирования Thrift и коде, изучите учебник на сайте: http://mng.bz/M2W8. Приведенный ниже код должен быть интуитивно
понятен большинству инженеров, но учебник поможет ускорить обучение. Поэтому,
если вы не знакомы с языком Thrift, я рекомендую заглянуть в учебник.

Давайте рассмотрим сценарий, в котором мы получаем до трех обращений (взаимодействия запрос/ответ в течение нескольких секунд во время одного и того же посещения) от пользователя, который подключается к нашему сервису. При каждом обращении будет задан определенный вопрос, и ответ на обращение запустит следующий набор действий. В соответствии с обращениями существуют три конечных
точки, предоставляющие надлежащие ответы. В нашем сценарии предположим, что
пользователь подключается к веб-сайту (или приложению) розничной торговли и,
исходя из особенностей работы сети Интернет, сбор данных начнется с момента получения согласия пользователя. В этом смысле процесс будет выглядеть так:
1. Принял ли пользователь текущий набор документов о разглашении данных,
применимых в текущем местоположении пользователя?
2. Обращение 1:
 если да, позвольте пользователю продолжить и соберите соответствующие
данные.
3. Обращение 2:
 если нет, покажите актуальную, соответствующую языку и местоположению
версию (версии) документов о разглашении данных, которую пользователю
необходимо принять.

Глава 9. Разработка платформы управления согласием

331

4. Обращение 3:
 обновите статус согласия пользователя для соответствующей текущей версии(й) документов о разглашении данных.
В данном контексте определим конечные точки и общедоступные API. В следующем разделе мы подробно рассмотрим API, помогающие получить статус согласия
пользователя.

9.4.1. API для проверки статуса согласия
Первый API, который мы определим, поможет проверить, принял ли пользователь
конкретный документ о разглашении данных. Данный API может казаться пустяковым — и с инженерной точки зрения его легче реализовать, чем другие, описанные
далее, — но инженеры и технические руководители должны понимать его важность
для бизнеса.
С точки зрения защиты конфиденциальности вам необходимо получить согласие,
прежде чем разрешать пользователю доступ к функции или начинать собирать данные. Однако другие заинтересованные стороны в компании захотят убедиться, что
проверки конфиденциальности не замедляют без необходимости путь пользователя.
С точки зрения бизнеса проверки защиты конфиденциальности должны быть практически целесообразными, ведь пользователи легко отвлекаются, Интернетсоединение обрывается и т. д. По этой причине вам, вероятно, придется искать баланс между ролью защиты конфиденциальности в обеспечении доверия пользователей и зависимостью ее существования от бизнеса. Помните, если ваш бизнес потерпит неудачу из-за того, что уйдут клиенты, даже самая лучшая программа защиты конфиденциальности будет не нужна.
Приведенный ниже API следует рассматривать как важнейшую часть рабочего
процесса получения согласия пользователя.
/** getCompliance возвращает статус соответствия пользователя
*/
Compliance getCompliance(
1: GetComplianceStatusRequest getComplianceStatusRequest
) throws (
1: ValidationError validationError,
2: InternalServerError internalServerError
3: NotFoundError notFoundError
)

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

332

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Объект-запрос для этого API можно определить следующим образом:
struct GetComplianceStatusRequest {
1: optional UUID userUuid,
сервисом
2: optional UUID disclosureVersionUuid,
или featureUuid
3: optional string territoryId,
сервисом
5: optional string deviceId,
сервисом
6: optional string language,
сервисом, код языка IETF
7: optional UUID featureUuid,
или featureUuid
}

// Необходимость принудительно задается
// Требуется атрибут disclosureVersionUuid
// Необходимость принудительно задается
// Необходимость принудительно задается
// Необходимость принудительно задается
// Требуется атрибут disclosureVersionUuid

Обратите внимание, что в предыдущем объекте-запросе требуются:
 уникальный идентификатор пользователя (userUUID) — это будет внутренний

идентификатор, а не внешний вроде адреса электронной почты или государственного идентификатора;
 уникальный идентификатор конкретной версии документа о разглашении дан-

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

зависят от местоположения, поэтому необходимость поля territoryID очевидна. Однако здесь есть дополнительные нюансы:
 пользователь может попытаться получить доступ к функции из места, где эта
функция должна быть недоступна (например, музыкальные клипы, лицензированные для определенной страны, нельзя показывать в другой стране), поэтому проверка наличия согласия относительно данной функции на основе
местоположения перед предоставлением доступа к функции — это способ гарантировать добросовестность при определении функции и местоположения.
Таким образом, если пользователь с territoryID X попытается дать согласие
на функцию, предназначенную для territoryID Z, можно заблокировать доступ, оставив при этом возможность сохранить факт согласия, если эта функция станет доступной для territoryID X;
 обратите внимание: я предполагаю, что запрос и, следовательно, обновление
согласия пользователя является предварительным условием для доступа к
определенной функции. Так можно управлять трафиком к функции или гарантировать, что статус согласия никогда не помешает доступу к функциям в

Глава 9. Разработка платформы управления согласием

333

случае ограничений по возрасту, местоположению и т. д. Чтобы свести к минимуму замедление работы, обращение к этой конечной точке можно запустить в фоновом режиме и не заставлять пользователя каждый раз принимать
документ о разглашении данных. «Устанавливая данный флажок, вы принимаете условия...» — подход, часто применяемый компаниями для получения
согласия, является визуальным представлением таких проектных решений;
 поле deviceID — может иметь решающее значение для компаний, которым не-

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

языке, или вам потребуется представить документ о разглашении данных на определенном языке в зависимости от местоположения пользователя.
Следующий код определяет объект-ответ:
struct Compliance {
1: optional bool compliant
}

// Наличие согласия пользователя

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

9.4.2. API для получения документа о разглашении данных
Далее мы рассмотрим API для получения обновленного документа о разглашении
данных для конкретной локали в случае, если статус согласия пользователя возвращается отрицательным. Тогда пользователю предъявляется для принятия указанный документ о разглашении данных.
В коде ниже показан общедоступный API для конечной точки, предоставляющей
копию конкретного документа о разглашении данных.
/** getLocaleCopy вызывает копию, извлекаемую с помощью LocaleCopyUUID,
➯ DisclosureVersionUUID или FeatureUUID */
LocaleCopy getLocaleCopy(
1: GetLocaleCopyRequest getLocaleCopyRequest
) throws (
1: ValidationError validationError,
2: InternalServerError internalServerError
3: NotFoundError notFoundError
)

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

334

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Объект-запрос для этого API можно определить следующим образом:
struct GetLocaleCopyRequest {
1: optional UUID localeCopyUuid,
// Требуется localeCopyUuid,
➯ disclosureVersionUuid или featureUuid
2: optional UUID disclosureVersionUuid, // Требуется localeCopyUuid,
➯ disclosureVersionUuid или featureUuid
3: optional string territoryId,
// Требуется, если
➯ disclosureVersion territoryGranularity не имеет значения GLOBAL
4: optional string language = "en"
// Необходимость принудительно
➯ задается службой, код языка IETF
5: optional UUID featureUuid,
// Требуется localeCopyUuid,
➯ disclosureVersionUuid или featureUuid
}

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

глашении данных с одним из трех полей: localeCopyUuid, disclosureVersionUuid или featureUuid. Это означает, что можно получить документ о разглашении данных, выбранный на основе конкретной версии, конкретного местоположения, функции или определенного сочетания трех элементов.
Предоставляю вам возможность самостоятельно выбрать вариант реализации;
 логика запроса области местоположения и языка пользователя остается преж-

ней, однако есть нюанс, согласно которому показываемый пользователю документ о разглашении данных может быть выбран на основе местоположения или
языка в настройках учетной записи пользователя или устройства. Вы можете
сделать так, чтобы выбор зависел от бизнес-факторов и нормативных документов.
Теперь рассмотрим объект-ответ для API на запрос о получении копии документа о
разглашении данных.
struct LocaleCopy {
1:
2:
3:
4:
5:
6:
7:
8:
}

optional
optional
optional
optional
optional
optional
optional
optional

UUID localeCopyUuid,
UUID disclosureVersionUuid,
string territoryId,
string copy,
string richText,
DateTime createdAt,
map<string, string> richTextMappingV2,
list<DocumentDetails> documents

Глава 9. Разработка платформы управления согласием

335

Данный объект-ответ для API поиска документа о разглашении данных довольно
стандартный, но его все же полезно изучить в качестве примера. Тело запроса может выглядеть так:
{
"getLocaleCopyRequest": {
"disclosureVersionUuid": "2b2b33a7-1426-4a88-acc5-8bbebf50f265",
"territoryId": "24",
"language": "en"
}
}

Соответствующий ответ может выглядеть следующим образом:
{
"ok": true,
"head": {
"$rpc$-service": "consents-staging"
},
"body": {
"localeCopyUuid": "18873e56-a28c-4a79-87e7-1d0b55c42212",
"disclosureVersionUuid": "2b2b33a7-1426-4a88-acc5-8bbebf50f265",
"territoryId": "24",
"copy": null,
"richText": "This is the privacy policy.",
"createdAt": "2019-09-12 20:51:44.706 +0000 UTC",
"richTextMappingV2": {
"BODY": "This is the privacy policy.",
},
"documents": null
},
"headers": {
"as": "thrift"
}
}

Как видите, в соответствии с объектом-ответом мы добавляем отдельные поля для
копии и форматированной текстовой версии, но это нюансы реализации. Главное — сопоставление поля disclosureVersionUuid, являвшегося частью запроса, с
полем localeCopyUuid в ответе. Крайне важно правильно сопоставить их в модели
данных. Вот почему мы рассмотрели модели данных, прежде чем перейти к коду.
Это может казаться само собой разумеющимся в контексте данной книги, однако в
жизни я сталкивался с ситуациями, когда неправильные или плохо отмасштабированные сопоставления становились причиной судебных постановлений в отношении контента лишь из-за того, что пользователю был предоставлен не тот документ
о разглашении данных. Если вы не предложите пользователю применимый в его

336

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

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

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

9.4.3. API для обновления статуса согласия
на документ о разглашении данных
Далее мы рассмотрим код для обновления статуса согласия пользователя при представлении ему нового или обновленного документа о раскрытии персональных
данных. Код API приведен ниже:
UserConsent updateCompliance(
1: UpdateComplianceRequest userConsentRequest
) throws (
1: ValidationError validationError,
2: InternalServerError internalServerError
3: NotFoundError notFoundError
)

Как и в предыдущих API, мы допускаем наличие ошибок.
Теперь рассмотрим объект-запрос для API.
struct UpdateComplianceRequest {
1: optional UUID userUuid,

// Необходимость принудительно

➯ задается сервисом
2: optional UUID disclosureVersionUuid,

// Требуется localeCopyUuid или

➯ disclosureVersionUuid
3: optional string territoryId,

// Требуется, если

➯ disclosureVersion territoryGranularity не имеет значения GLOBAL

Глава 9. Разработка платформы управления согласием
4: optional string deviceId,

337

// Необходимость принудительно

➯ задается сервисом
5: optional i32 compliance,

// Необходимость принудительно

➯ задается сервисом
6: optional UUID localeCopyUuid,

// Требуется localeCopyUuid или

➯ disclosureVersionUuid
7: optional string language,

// Необходимость принудительно

➯ задается сервисом, язык кода IETF, значение по умолчанию "en"
8. optional string ipAddress
}

Как и в предыдущих примерах кода, поля подтверждают выполнение определенных требований:
 запрашивается параметр userUuid. Необходимо обновить статус согласия кон-

кретного пользователя, поэтому первичный ключ — это не подлежащее обсуждению предварительное условие;
 запрашивается disclosureVersionUuid или localeCopyUuid, так как нам нужно

зафиксировать принятие для конкретного однозначного сопоставления. Согласие конкретного пользователя сопоставляется с конкретным документом о разглашении данных;
 запрашивается TerritoryId, так как версия документа о разглашении данных

или его локальная копия сопоставляется с конкретным местоположением, которое мы получаем из TerritoryId;
 атрибут deviceId очень важен, поскольку нам может потребоваться вести жур-

нал аудита с указанием, с какого устройства пользователь дал согласие. Компаниям часто приходится получать согласия с каждого устройства или вести учет
того, с какого устройства пользователь дал согласие;
 compliance — двоичное значение согласия пользователя (1, если пользователь

согласен, и 0, если в согласии отказано).
Соответствующий объект-ответ для обновления согласия может выглядеть так:
struct UserConsent {
/* Ниже мы вызываем поля, соответствующие согласию пользователя.
➯ Каждое согласие будет иметь следующие поля для обновления */
1: optional UUID userUuid,
2: optional string deviceId,
3: optional string ipAddress,
4: optional DateTime timestamp,
5: optional string language,
// Код языка IETF
6: optional string territoryId,
7: optional UUID disclosureUuid,
8: optional UUID localeCopyUuid,
}

338

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Для объяснения объекта-ответа рассмотрим пример конкретного запроса и соответствующее тело ответа:
{
"userConsentRequest": {
"userUuid": "UserUUID",
"disclosureVersionUuid": "",
"territoryId": "1",
"deviceId": null,
"compliance": 0,
"ipAddress": "203.0.113.1",
"localeCopyUuid": "LocaleUUID",
"language": "en"
}
}

Предыдущий запрос, указывающий, что согласие не было предоставлено, приведет
к такому ответу:
{
"ok": true,
"head": {
"$rpc$-service": "consents"
},
"body": {
"userUuid": "UserUUID",
"deviceId": "",
"compliance": 0,
"ipAddress": "203.0.113.1",
"timestamp": "2021-04-22 03:21:43.218029116 +0000 UTC",
"language": "en",
"territoryId": null,
"disclosureUuid": "DisclosureUUID",
"localeCopyUuid": "LocaleUUID"
},
"headers": {
"as": "thrift"
}
}

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

Глава 9. Разработка платформы управления согласием

339

9.4.4. API для обработки нескольких документов
о разглашении данных
В реальной жизни инженеры должны учитывать тот факт, что им придется получать
документы о разглашении данных сразу по несколько штук, а не по одному. Кроме
того, потребуется одновременно проверять или обновлять несколько подтверждений
согласия. И здесь нужно будет искать баланс между правом на конфиденциальность,
дизайном пользовательского интерфейса клиента и вопросами бизнеса.
Если вы потребуете от клиента принять подряд четыре соглашения, это не просто
будет признаком некачественной реализации, но и, вероятно, утомит пользователя,
который прекратит процесс и, скажем, не завершит покупку. И вы добьетесь полной конфиденциальности ценой коммерческого успеха.
В связи с этим рассмотрим, как получить согласие на несколько документов о разглашении данных за один шаг. Тогда в упоминавшемся выше примере можно будет
показать только документы, требующие принятия.
Вызов API для этой функции может быть следующим:
GetComplianceAndCopyForFeaturesResponse getComplianceAndCopyForFeatures (
1: GetComplianceAndCopyForFeaturesRequest
getComplianceAndCopyForFeaturesRequest
) throws (
1: ValidationError validationError
2: InternalServerError internalServerError
3: NotFoundError notFoundError
)

В следующем объекте-запросе присутствует сопоставление пользователя и документов о разглашении данных по принципу «один ко многим». Этот вызов напоминает множественные вызовы функции getCompliance в разделе 9.4.1:
struct GetComplianceAndCopyForFeaturesRequest {
1:
2:
3:
4:
5:
6:
7:
}

optional
optional
optional
optional
optional
optional
optional

UUID userUuid,
list<UUID> featureUuids,
string territoryId,
string language,
string deviceId,
map<UUID, UserConsent> userConsentsToSync,
string ipAddress

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

340

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Соответствующий объект-ответ выглядит так:
struct GetComplianceAndCopyForFeaturesResponse {
1: optional map<UUID, UserConsent> userConsents // Последний атрибут
➯ userConsent для запрашиваемых функций, с ключом featureUUID
2: optional map<UUID, LocaleCopy> localeCopies // Атрибут localeCopy для любых
➯ запрашиваемых функций БЕЗ записанного UserConsent
}

Чтобы понять, как код будет функционировать на практике, рассмотрим пример. В
следующем вызове мы проверяем наличие согласия пользователя с UUID UserUUID
для идентификаторов функций d6063933-161d-4134-abce-ff786db70193 и
13eaf184-b855-4a8d-8b84-7ded597f62a9. Этот подход позволяет проверить наличие у пользователя согласия на несколько документов о разглашении данных, которые соответствуют нескольким функциям.
{
"getComplianceAndCopyForFeaturesRequest": {
"userUuid": "UserUUID",
"featureUuids": [
"d6063933-161d-4134-abce-ff786db70193",
"13eaf184-b855-4a8d-8b84-7ded597f62a9"
],
"territoryId": "1",
"language": "en",
"deviceId": null,
"userConsentsToSync": {
"13eaf184-b855-4a8d-8b84-7ded597f62a9": {
"userUuid": "UserUUID",
"deviceId": "hailstorm",
"ipAddress": "203.0.113.1",
"language": "en",
"territoryId": null,
"disclosureUuid": "DisclosureUUID",
"localeCopyUuid": "LocaleUUID"
}
}
}
}

В нашем сценарии использования ответ на предыдущий вызов может быть таким:
{
"ok": true,
"head": {
"$rpc$-service": "consents"
},

Глава 9. Разработка платформы управления согласием
"body": {
"userConsents": {
"13eaf184-b855-4a8d-8b84-7ded597f62a9": {
"userUuid": "UserUUID",
"deviceId": "hailstorm",
"compliance": 1,
"ipAddress": "203.0.113.1",
"language": "en",
"territoryId": null,
"disclosureUuid": "DisclosureUUID",
"localeCopyUuid": "LocaleUUID"
}
},
"localeCopies": {
"d6063933-161d-4134-abce-ff786db70193": {
"localeCopyUuid": "769b6726-dcf8-41a1-a268-8b48f81cac89",
"disclosureVersionUuid": "331b724f-a72d-4d47-9490-e034e6e3c442",
"territoryId": "1",
"copy": null,
"richText": "test",
"createdAt": "2018-12-27 00:30:15.78 +0000 UTC",
"richTextMapping": {
"BODY": "This is the first disclosure"
},
"documents": null
},
"13eaf184-b855-4a8d-8b84-7ded597f62a9": {
"localeCopyUuid": "a878d99a-d817-43f1-9800-2879c652f1c4",
"disclosureVersionUuid": "c0e80149-d3e2-440c-8cc3-ed401061122b",
"territoryId": "1",
"copy": null,
"richText": "testing one two three",
"createdAt": "2018-12-26 23:48:13.383 +0000 UTC",
"richTextMapping": {
"BODY": "This is the second disclosure"
},
"documents": null
}
},
},
"headers": {
"as": "thrift"
}
}

341

342

Часть IV. Безопасность, масштабирование и кадровое обеспечение

В предыдущем фрагменте ответа выделяются несколько моментов:
 наша проверка принятия документов о разглашении данных для функций, пред-

ставленных

идентификаторами

d6063933-161d-4134-abce-ff786db70193 и
13eaf184-b855-4a8d-8b84-7ded597f62a9, выявила, что согласие пользователя
есть только для одной из них — "13eaf184-b855-4a8d-8b84-7ded597f62a9". Это

показано с помощью значения соответствия 1. Так как для другого идентификатора функции нет принятого документа о разглашении данных, никакое значение не возвращается;
 независимо от принятия пользователем документов о разглашении данных,

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

9.4.5. API для регистрации в сервисе получения согласия
В этом разделе я буду использовать термин «внедрение» для обозначения микросервиса или иной возможности применения сервиса получения согласия. Мы определим параметры, которые должны будут поддерживаться сервисом для реализации возможности получения согласия.
Цель создания сервиса — позволить нескольким отделам компании им пользоваться. Например, если вы управляете интернет-магазином, вам нужно, чтобы сотрудники, работающие с iOS, Android, а также с сетью Интернет, пользовались одним и
тем же сервисом. Посмотрим, как можно составить код, позволяющий другим сервисам подключаться к сервису получения согласия.

Глава 9. Разработка платформы управления согласием

343

Код запроса такой:
struct OnboardingRequest {
1:
2:
3:
4:
5:
6:
7:

optional
optional
optional
optional
optional
optional
optional

list<string> territoryIDs,
TerritoryGranularity territoryGranularity,
string owningTeam,
string featureName,
string businessPurposeName,
bool mandatoryFeatureUpdate,
bool isPerDevice,

}

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

и т. д.;
 идентификаторы для отделов и функций, соотносимых с документом о разгла-

шении данных;
 коммерческую цель документа о разглашении данных;
 будет ли принятие документа о разглашении данных обязательным при каждом

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

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

9.4.6. Полезные определения для сервиса получения согласия
Значительная часть представленного выше кода предполагает использование общепринятых определений. Например, значение 1 показывает, что пользователь
принял конкретный документ о разглашении данных. В этом разделе я предоставлю шаблон для некоторых определений.
Приведенный ниже фрагмент кода создает определение видов действий, которые
может предпринять пользователь, получив возможность принять документ о разглашении данных:
enum UserConsentStatus
{
ACCEPTED = 1

344

Часть IV. Безопасность, масштабирование и кадровое обеспечение

DEFERRED = 2
INVALIDATED = 3
DECLINED = 0
}

Этот код говорит сам за себя. Он присваивает интуитивно понятные значения
предоставлению согласия и другим действиям, которые может предпринять пользователь.
Мы также упоминали детализацию территории для региона, к которому привязан
документ о разглашении данных. В коде ниже показан пример шаблона определения степени детализации.
enum TerritoryGranularity {
CITY = 1001,
STATE = 1002,
COUNTRY = 1003,
GLOBAL = 1004,
}

Помимо определения основополагающих значений, крайне важно допускать возможность значимых ошибок в случае, если данные в вызове окажутся недействительны, если возникнет ошибка на стороне сервера, проблема с поиском данных
для статуса согласия или документа о разглашении данных. Представленные ниже
три фрагмента кода содержат идеи, которые можно взять за основу.
/** Ошибка проверки, возникающая при проблемах с предоставленными данными */
exception ValidationError {
1: required string code,
2: required string message
}
/** Внутренняя ошибка сервера — возникает при неожиданных ошибках во время
➯ выполнения обработки событий */
exception InternalServerError {
1: required string code,
2: required string message
}
/** Ошибка поиска — возникает, когда элемент не найден в базе данных */
exception NotFoundError {
1: required string code,
2: required string message
}

Глава 9. Разработка платформы управления согласием

345

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

9.5. Другие полезные возможности CMP
В этом разделе будут указаны функции, которые можно внедрить в CMP, чтобы
гарантировать отсутствие явных перекосов между собираемыми данными и имеющимися согласиями пользователей. Перечисленные ниже возможности, строго говоря, не относятся ни к стороне сервера, ни к стороне клиента, однако их может
быть полезно реализовать.
Во-первых, почти каждый веб-сайт использует третьи стороны, например, рекламные пиксели или платформы социальных сетей, однако во многих регионах нельзя
загружать эти скрипты, пока пользователь не даст свое согласие. Нужно, чтобы ваша CMP автоматически блокировала и разблокировала сторонние скрипты, не позволяя третьим лицам собирать данные пользователей без их согласия.
Законы о согласии посетителей действуют в нескольких странах, но в каждой стране есть свои нюансы понимания того, что представляет собой согласие. Для автоматического отображения и предоставления надлежащей просьбы о согласии на
основе геолокации каждого посетителя веб-сайта вам понадобятся четкие инструкции, как расшифровать местоположение пользователя. Можно было бы использовать информацию из настроек его учетной записи, но при этом не будут учитываться незарегистрированные пользователи, которые тоже используют ваш веб-сайт
или приложение. В данном случае можно опереться на IP-адрес пользователя, но
тогда в зоне риска окажутся пользователи, подключающиеся через VPN. Независимо от того, как вы расшифруете местонахождение пользователя, наличие четких
стандартов поможет гарантировать, что полученное согласие действительно.
Быстрорастущие компании часто удивляются, когда какая-то часть их онлайнинфраструктуры оказывается не отражена в CMP, но все равно собирает данные
пользователей. Сложнее всего, когда данные собираются со страницы, которая не
доступна для поиска. Важно, чтобы CMP всегда знала о скрытых страницах и держала вас в курсе того, какая информация и где загружается на вашем сайте.
Учитывая, что в небольших, да и в некоторых крупных компаниях не всегда присутствует кроссплатформенная прозрачность, рекомендуется оснастить CMP A / Bтестированием и инструментами отчетности для отслеживания согласий потребителей, управления ими и оптимизации.
Кроме того, CMP будет просто бесценна, если сумеет перечислить все запускаемые
cookie-файлы, трекеры, и технологий, применив для этого захват всего контента,
предоставляемого с помощью рекламных пикселей, cookie-файлов, JavaScript и вызовов API, а также сможет использовать эмуляцию сценария, отражающую действия пользователя (настройки конфиденциальности, авторизации).

346

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Одно из возражений, которые слышат специалисты по защите конфиденциальности, особенно в компаниях, работающих с минимальными затратами и обладающих
скудными познаниями в области защиты конфиденциальности, — что инструменты
получения согласия замедлят поток клиентов. Необходимость устанавливать эти
флажки будет раздражать клиентов и приведет к проблемам с пропущенной конверсией и отказами от отложенных в корзину покупок. Таких скептиков можно
воспитать, рассказав о цене неполучения согласия, но полезнее применить благоприятное для бизнеса решение получения согласия.
Для этого надо интегрировать решения по идентификации, чтобы создать удобный
пользовательский интерфейс на разных устройствах и отслеживать согласия пользователей на настольных компьютерах и в мобильном Интернете. Это позволит избежать создания ненужных препятствий на пути навигации пользователя. Постоянная проверка статуса согласия пользователя и наличие графа согласия, аналогичного хорошо известному графу персоналий, уравновесит защиту конфиденциальности
с императивами бизнеса. Наконец, сопоставление вашего внутреннего идентификатора с собственными или партнерскими идентификаторами поможет гарантировать, что настройки конфиденциальности легко записать и при необходимости поделиться ими с партнерами.
Еще одна область управления согласием — сторонние поставщики. Рост бизнеса
часто приводит к установлению отношений с поставщиками, иногда даже требует
этого. Однако, как выяснила корпорация Facebook (ныне Meta Platforms Inc., признана экстремистской организацией на территории РФ) в ходе дела компании
Cambridge Analytica, обмен данными с третьими лицами чреват рисками, если это
касается согласия. Поэтому необходимо, чтобы ваша CMP помечала уязвимости
конфиденциальности, которые могут привести к утечке данных, несоблюдению
нормативных требований и репутационному риску, а также предоставляла практически полезную информацию для обеспечения нормативного соответствия. Стоит
рассмотреть следующие возможности:
 функцию сканирования страниц для мониторинга страниц и автоматического

добавления поставщиков в ваш список;
 создание комплексного представления о неавторизованных поставщиках, обра-

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

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

Глава 9. Разработка платформы управления согласием

347

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

9.6. Интеграция управления согласием
в рабочий процесс продукта
Итак, вы увидели, как можно выстроить логику управления согласием для управления документами о разглашении данных, сбором согласий и получением статуса. В
этом разделе мы рассмотрим, как использовать функциональную CMP на практике
в рабочем процессе продукта.
Я хочу показать конкретный пример использования, чтобы вы поняли, как рассмотренные ранее модель данных и фрагменты кода соотносятся с реальным рабочим процессом. Защита конфиденциальности — это не абстрактная благотворительность. При правильной реализации она может сыграть важнейшую роль в развитии бизнеса. Я покажу, каким образом отношения между различными объектами
и возможности CMP обеспечивают конкретную потребность бизнеса. Понимание
потребностей бизнеса поможет вам разработать решение, которое будет стимулировать внедрение защиты конфиденциальности в бизнес, что, в свою очередь, приведет к защите конфиденциальности данных конечного пользователя.
Предположим, что наша компания должна провести онлайн-мероприятие. Также
предположим, что для сбора данных о посетителях мероприятий потребуется их
согласие. В предыдущих примерах кода согласие и документы о разглашении данных были соотнесены с местоположениями. Аналогичным образом в этом примере
документы о разглашении данных сопоставляются с конкретными событиями.
Юристам или организаторам, ответственным за мероприятие, придется составить
документы о разглашении данных.
Для этой системы у нас будет два ключевых микросервиса: первый, названный
NET, будет управлять созданием событий; второй, названный NULL, будет управлять созданием документов о разглашении данных и записью согласия пользователя на эти документы.
Чтобы упростить работу этих функций, у нас будет три API:
 первый API позволит микросервису NET отправлять в NULL параметры, отно-

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

348

Часть IV. Безопасность, масштабирование и кадровое обеспечение

 второй API будет периодически разрешать NET отправлять в NULL протокол

резервирования сетевых ресурсов для события (список участников) и их соответствующие документы о разглашении данных с указанием статуса согласия;
 третий API будет периодически включать NULL для отправки обновленных

PDF-файлов документов о разглашении данных в облачное хранилище и отправки соответствующих URL-адресов в NET с сопоставлением с событиями,
которых касаются эти обновления документов о разглашении данных.
Таким образом, первые два API позволят микросервису NET сообщать NULL о событиях и
 получить документы о разглашении данных, которые нужно принять,

или
 отправить принятые документы о разглашении данных.

Третий API позволит микросервису NULL держать наготове документы о разглашении данных, чтобы, когда кто-то использует NET для создания события, это событие можно было создать гораздо быстрее.
Давайте кратко рассмотрим каждый шаг (я считаю самим собой разумеющимся шаг
составления юристами документов о разглашении данных; наш рабочий процесс
начнется с создания события):
1. Создатель события входит в микросервис NET, чтобы, собственно, создать событие. Он должен знать основные сведения о событии, в том числе:
 название события,
 место проведения,
 время начала и окончания.
2. Создатель использует микросервис NET для создания события. Предположим,
что событие не считается созданным до тех пор, пока не будет соответствующих
документов о разглашении данных. События без документов отмечены как «незавершенные».
3. При сохранении создателем события в микросервисе NET внутренняя логика
распознает его как проводящееся с возможными участниками и ищет документ о
разглашении данных, который участники смогут принять.
 Чтобы получить документы о разглашении данных, микросервис NET отправляет в NULL предоставленные создателем параметры (название события,
место и время начала/окончания).
 Любые значения по умолчанию, которые создает микросервис NET, например, идентификатор события, также передаются в NULL. Таким образом
микросервис NULL сможет сопоставить с событием конкретную версию документа о разглашении данных.
 Микросервис NET также может предоставлять микросервису NULL дополнительный контекст о том, какой документ о разглашении данных требуется:
стандартный или специально разработанный.

Глава 9. Разработка платформы управления согласием

349

4. Перед предоставлением документа о разглашении данных в микросервис NET
система микросервиса NULL запустит рабочий процесс для стандартных или
специально разработанных документов о разглашении данных.
 В случае стандартного документа о разглашении данных NULL заполняет
сведения о событии в специально созданной для события версии документа и
отправляет ее в хранилище, в данном случае — S3. Генерируется URL-адрес
документа о разглашении данных, а событие помечается как «завершенное».
 Если стандартного документа о разглашении данных не существует (например, для определенного места) или возникла какая-то другая системная
ошибка, сервис NULL может отправить электронное письмо специалистам
юридического или технического отделов.

5.

6.

7.

8.

9.

 Если для события требуется специально разработанный документ о разглашении данных (который юристу необходимо будет создать специально для
данного), NULL продолжит сохранять событие, но не пометит его как завершенное. Микросервис NULL также отправит электронное письмо специалистам юридического отдела с просьбой предоставить специально разработанный документ.
У системы, используемой юристами компании для документов о разглашении
данных, теперь есть шаблон документа с подробной информацией о событии.
После того как юристы внесут свои коррективы, специально разработанный документ можно считать готовым.
После подготовки специально разработанного документа о разглашении данных
система управления контентом, поддерживаемая юридическим отделом, должна
будет уведомить микросервис NULL о том, что теперь существует специально
разработанный документ о разглашении данных для конкретного события. (В
большинстве компаний, где я работал, у юридического отдела имелась определенная система управления контентом, но вам, может быть, придется внедрить
дополнительные возможности, позволяющие системе управления контентом работать с API, как в данном примере).
Микросервис NULL передает новый специально разработанный документ о разглашении данных в хранилище (в нашем примере это опять же S3), чтобы сгенерировать URL-адрес для данной версии. Это крайне важно, поскольку каждый
документ о разглашении данных — стандартный или специально разработанный — может относиться к более чем одному событию. Наличие URL-адреса
позволяет связать его с соответствующими событиями.
URL-адрес вновь созданного документа о разглашении данных отправляется из
микросервиса NULL в NET с информацией о событии, для которого он создан.
Это позволяет микросервису NET извлечь событие, которое было помечено как
«незавершенное» из-за отсутствия документа о разглашении данных.
Микросервис NULL отправляет создателю события уведомление о том, что надлежащий документ о разглашении данных создан и связан с его событием. В реальной жизни этот вызов также может выполняться микросервисом NET. В любом случае, создателя события необходимо уведомить о том, что теперь он может продолжить работу.

350

Часть IV. Безопасность, масштабирование и кадровое обеспечение

10. Получив уведомление о завершении документа о разглашении данных, создатель публикует событие. На практике это означает, что посетители могут начать регистрацию на событие и принять документ о разглашении данных.
11. Когда участник нажмет на ссылку для просмотра документа о разглашении данных, включится логика сопоставления (подобная рассмотренной в примерах
кода ранее в этой главе), и микросервис NET вызовет уровень хранения для получения документа о разглашении данных.
12. Микросервис NET регистрирует принятие участником документа о разглашении данных и сохраняет в таблице (используя логику, аналогичную той, что вы
видели ранее).
13. Для ведения проверяемого учета принятий документов о разглашении данных
микросервис NET может отправить пакетные обновления микросервису
NULL, чтобы там присутствовал работающий список, показывающий, кто из
пользователей какие документы о разглашении данных принял. Постоянный
учет позволит компаниям продемонстрировать, что у них есть способ проверки соответствия.
14. Этот необязательный шаг позволяет юристам вносить изменения в документ о
разглашении данных через свою систему управления контентом и уведомлять
сервис NULL, что отслеживаемые документы о разглашении данных были обновлены. Сопоставление документа о разглашении данных с местоположением,
например, имеет решающее значение для выполнения этих вызовов. Такой вариант использования показывает, как модель данных и примеры кода обеспечивают логическое развитие и являются незаменимой частью системы управления контентом, которой приходится приспосабливаться к перестановкам и комбинациям, которые могут идти в количестве и одновременно.
15. Получив уведомление об обновлении документа о разглашении данных, микросервис NULL публикует обновление документа на уровне хранения, генерируя
новый номер версии и новый URL-адрес, если это требуется.
Как показывает данный сценарий использования, критически важно, чтобы система
управления контентом стремилась к согласованности (схемы данных и код должны
гармонично сочетаться), а также беспроблемно работала с другими сервисами (например, сервисом событий), платформами (например, системой управления контентом, где юридический отдел физически хранит документы о разглашении данных) и уровнем хранения (база данных S3).
Специалистам по защите конфиденциальности важно понимать это, поскольку
многие из них уделяют больше внимания самой защите, чем тому, чтобы разбираться с проблемами, и создают решения, несовместимые с существующей технической инфраструктурой и целями бизнеса. В этом случае вы получаете решения,
которые избавляют от насущных проблем (например, получение и загрузка нового
документа о разглашении данных для запуска важного продукта), но не предоставляют проверяемые возможности (обеспечение записи согласия для автоматического поиска).

Глава 9. Разработка платформы управления согласием

351

Резюме
 Сбор и поддержание согласия пользователей играют важную роль для компаний

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

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

рованного и детального согласия и поддержания его в проверяемом формате.
 Помимо защиты конфиденциальности, CMP могут предоставлять еще несколько

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

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

- ГЛАВА 10 -

Закрытие уязвимостей
системы безопасности

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

нения рисков защиты конфиденциальности;
 как накапливаются основные риски защиты конфиденциальности и безопасно-

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

Многим компаниям сложно внедрить средства управления защитой конфиденциальности, особенно если бюджет компании ограничен, а она сама относится к малому или среднему бизнесу. Такие компании часто задаются важным вопросом: «С
чего начать встраивание защиты конфиденциальности в техническую инфраструктуру?» И хотя вопросы расстановки приоритетов извечны, решить, что делать в
первую очередь, очень трудно.
По моему опыту, объем работы, необходимый, чтобы приступить к защите конфиденциальности данных, пугает компании, которые только начинают работать в
этом плане. Практики вроде минимизации данных и управления ими требуют значительных изменений, которые часто затрагивают все уровни компании. Для минимизации данных, например, инженерам придется собирать меньше данных.
Масштабное внедрение потребует изменений в культуре, процессах и автоматизации, на которые может потребоваться время. При этом другие уязвимости (например, связанные с управлением разрешениями, влияющими на уже имеющиеся данные) могут остаться незамеченными. Управление данными может оказаться для
компаний еще более сложным делом, поскольку оно требует понимания, какие
данные собираются, с какой целью и кем, а затем внедрения инструментов для защиты конфиденциальности информации.

Глава 10. Закрытие уязвимостей системы безопасности

353

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

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

354

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

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

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

Глава 10. Закрытие уязвимостей системы безопасности

355

инфраструктуру безопасности в контексте защиты конфиденциальности, надо обратить внимание на следующие аспекты:
 уязвимые веб-компоненты, не исправленные соответствующими программными

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

данным;
 серверы или сети, которые злоумышленник может залить трафиком в попытке

нарушить работу и перегрузить сервер, лишив его работоспособности;
 вредоносное ПО и попытки фишинга, нацеленные на нанесение максимального

ущерба;
 попытки программ-вымогателей, включающие в себя блокировку и захват вашей

сети;
 отсутствие фильтрации контента, из-за чего сотрудники могут посещать неза-

щищенные веб-сайты, что, в свою очередь, может привести к потере данных;
 отсутствие защиты веб-серверов, что серьезно, поскольку эти серверы часто на-

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

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

356

Часть IV. Безопасность, масштабирование и кадровое обеспечение

дежное интеграционное тестирование — случайно привела к расширению поверхности атаки компании.

10.1.2. Как тестирование может вызвать риски нарушения
безопасности и конфиденциальности
Компании, создающие клиентоориентированные продукты и сервисы, должны
тщательно их тестировать на протяжении всего процесса проектирования, разработки и развертывания. Цель тестирования — убедиться, что функциональность
соответствует проекту. Это сложный процесс, ведь такие продукты состоят из нескольких более мелких микросервисов. Например, приложение для розничной торговли может состоять из отдельных сервисов — скажем, взаимодействия с пользователем, рекомендаций, платежей, выставления счетов, доставки и обнаружения
мошенничества. Все их нужно протестировать по отдельности или модульно, а
также провести интеграционное тестирование. Так инженеры смогут гарантировать, что отдельные элементы работают должным образом и в целом продукт
функционирует так, как ожидалось.
Учитывая, что разные команды работают с разной скоростью, а нередко и с разными технологическими стеками, во многих небольших компаниях для тестирования
принято использовать данные реальных клиентов. В некоторых случаях компании
копируют производственные данные на отдельный сервер, который используется
для тестирования. Такая практика понятна: экономится время разработки, код подвергается более строгой проверке, а затраты снижаются. У подобного подхода следующие преимущества:
 можно исправить проблему, которая только появилась в рабочей среде;
 можно протестировать соответствующее исправление, прежде чем применять

его в рабочей среде;
 сотрудники (например, служба поддержки клиентов) могут обучаться работе с

ИТ-системами без риска воздействия на работающую систему;
 можно разрешить доступ к данным для удобного сквозного тестирования.

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

Глава 10. Закрытие уязвимостей системы безопасности

357

граммная система Jenkins запускала обновление. Еженедельное обновление включало в себя копирование файлов данных из хранилища S3 в рабочей среде в локальный экземпляр на соответствующих тестовых серверах. Бизнес-цель состояла в
том, чтобы предоставить всем группам инженеров доступ к производственным
данным — без ограничений доступа, необходимых в эксплуатационной среде.
После завершения обновления на всех узлах высокоскоростное свойство, определяющее имя кластера для приложения, передавалось обновленному кластеру, чтобы отделы, работавшие с приложением, могли начать его использовать. На
рис. 10.1 показан рабочий процесс еженедельного обновления. Аббревиатура
«CID» здесь означает «идентификатор клиента» (англ.: customer identifier), но на
самом деле это заменитель для любого внутреннего идентификатора, обозначающего клиента или пользователя.

Рис. 10.1. Рабочий процесс еженедельного обновления

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

сей на тестовый сервер, а затем запустила инструмент TestTool для идентифика-

358

Часть IV. Безопасность, масштабирование и кадровое обеспечение

ции учетных записей, которые можно использовать для тестирования. Таким образом, компания могла еженедельно корректировать, какие производственные
учетные записи использовать для тестирования.
 На шагах 2–5 инструмент TestTool играл роль посредника между учетными за-

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

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

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

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

Глава 10. Закрытие уязвимостей системы безопасности

359

циалисты по инфраструктуре, уже работавшие на пределе возможностей, отказались и от этого плана.
Была еще одна попытка зашифровать и скрыть конфиденциальные данные на производственных серверах до передачи копии на тестовый сервер. При реализации
этого плана тоже столкнулись с трудностями.
Найти простой способ изменить файлы напрямую не удалось. Единственным вариантом модификации или изменения данных было переписывание изменений для
всего набора данных, что замедлило бы обновление и повлияло на расписание тестов. Изменение терабайтов информации в базе данных Cassandra обычно занимает
недели и не вписывается в еженедельные расписания обновлений. Еженедельное
обновление начиналось в четверг и завершалось в воскресенье, чтобы в понедельник данные были доступны для тестирования.
При выборе между безопасностью и производительностью в очередной раз победила последняя.
В результате реальные производственные данные компании оказались на тестовом
сервере, куда обращались приложения-прототипы. У этих приложений были даже
более широкие права доступа, чем у их готовых к выпуску версий на производственном сервере. Кроме того, тестовые приложения имели и другие уязвимости, характерные для быстроразвивающихся компаний: повторно используемые или ненадежные учетные данные, присутствие учетных данных в самом коде, слишком подробное ведение журнала, где могли оказаться конфиденциальные данные,
ограниченное тестирование безопасности и урезанные оповещения.
Приходивших в компанию новых инженеров недостаточно обучали работе с тестовой и производственной учетными записями и предоставляли ограниченную документацию касательно их отличий, несмотря на то, что использование производственных данных на тестовом сервере росло. Тестовый сервер оставался незащищенным, а объемы поступающих в него конфиденциальных данных росли, и
сопутствующие риски конфиденциальности повышались.
Эта практика сохранялась, хотя даже сами применяющие ее инженеры считали ее
неоптимальной. Например, инженерам, пользовавшимся тестовым сервером, часто
приходилось по несколько раз отправлять запрос прежде, чем получить нужные
данные. Значит, они часто тратили впустую ресурсы компании, а также открывали
и регистрировали конфиденциальные данные, которые оказывались бесполезными.
Как видно из рис. 10.1, данные на тестовом сервере постоянно менялись даже во
время его использования, потому что несколько отделов одновременно пользовались единственной копией производственных данных, хранившейся там. Это приводило к неудачным тестам и повторным попыткам.

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

360

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

10.1.3. Модель риска предприятия для обеспечения безопасности
и конфиденциальности
Учитывая распространение данных между компаниями, недостаточно полагаться
только на безопасность периметра и возможности обнаружения. В отрасли все
большую популярность обретает модель нулевого доверия, ориентированная на
постоянную проверку личности пользователей, устройств и приложений в сети, с
одновременным соблюдением принципа минимальных привилегий. Широко открытый доступ к производственным данным — один из способов, как злоумышленники со стороны могут взломать сеть и данные компании.
Процесс сопоставления идентификаторов пользователей с привилегиями доступа
сложен. Оценка этого требования часто охватывает все уровни платформы компании, включая инструменты администрирования, хосты, контейнеры, хранилища
данных и даже API.
Учитывая это, я рекомендую компаниям выстраивать двустороннюю стратегию,
которая начинается с автоматизированного обнаружения, а заканчивается развивающейся матрицей управления рисками. Рассмотрим сначала подход автоматизированного обнаружения.

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

Глава 10. Закрытие уязвимостей системы безопасности

361

нять проблемы в этой области, что, в свою очередь, способствует устранению пробелов в конфиденциальности.
Менеджеры технических программ, например, сотрудничая со специалистами по
обеспечению безопасности приложений и безопасности операций, могли бы создать ряд механизмов для поиска репозиториев кода, в которых могут храниться
конфиденциальные материалы вроде учетных данных или закрытых ключей. Затем
эти механизмы будут обеспечивать рабочий процесс, который позволит руководителям программ привлекать владельцев репозиториев и не только устранять проблемы, но и одновременно обучать инженеров безопасным и одобряемым методам
обработки чувствительных данных. Для компаний, использующих корпоративные
облачные сервисы, эти механизмы можно дополнительно автоматизировать, чтобы
они обнаруживали неправильные конфигурации и аномальные случаи доступа к
ресурсам облачного хранилища и реагировали соответственно.
Вместо создания для конфиденциальных данных нескольких местоположений, которые, как вы уже знаете, становятся причиной проявлений неэффективности и
рисков, компания может применить другой подход. Инженеры создадут сервис для
выполнения ряда функций по обеспечению безопасности, включая безопасное хранение секретов, ключей и данных. Этот сервис можно использовать не только для
хранения данных конфиденциального характера, но также и бизнес-IP, а доступ
будет ограничен и контролируем. Такой подход поможет заручиться поддержкой
бизнеса и финансированием, поскольку он будет рассматриваться как фактор содействия бизнесу, а не навязывания защиты конфиденциальности.
Одна из причин, по которой компания из примера выше настаивала на еженедельном обновлении, заключалась в управлении учетными данными. Они не могли сгенерировать персонализированные учетные данные для производственного доступа,
и им казалось, что необходимо дублировать данные, предоставив к ним более свободный доступ. Я помог запустить программу, реализующую возможности вебсервисов Amazon (англ.: AWS — Amazon web services), называемые ролями управления идентификацией и доступом для облака эластичных вычислений (EC2). Это
позволило компании получать доступ к ресурсам AWS из своих экземпляров EC2.
Сервис предоставляет динамические и эфемерные учетные данные, которые помогают избежать многих проблем безопасности, связанных со статическими и долгоживущими учетными данными. Таким образом, компания смогла предоставить
производственный доступ ко многим тестам с использованием учетных данных,
которые были сопоставлены со сценариями использования и сроками.
Пример с еженедельным обновлением также показывает, что накопление рисков
происходило постепенно. Вполне вероятно, что никто в компании не мог количественно оценить вероятность и воздействие этих рисков. И хотя далее мы создадим
основу для такого управления рисками, инженерам и техническим руководителям
во всех типах компаний будет полезно получать оценку со стороны, это не даст
расслабиться.
Ваши специалисты по безопасности приложений и ИТ должны инициировать программу «Награда за уязвимости», которая позволит сторонним аналитикам в облас-

362

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

Внедрение управления рисками безопасности
Устранив в упомянутой выше компании наиболее серьезные проблемы безопасности,
связанные с еженедельным обновлением, я занялся для них разработкой аппарата по
обеспечению безопасности и конфиденциальности. Прежде чем перейти к защите
конфиденциальности данных, я помог сменить облачную инфраструктуру и инфраструктуру безопасности на более продуманные для масштабирования их сервисов.
Первым делом мы соотнесли сервисы и приложения, использующие данные, с
учетными записями AWS, на которых хранились эти данные. Когда я пришел, у
компании было несколько десятков отдельных учетных записей AWS для запуска
собственных сервисов и бизнеса. Рост компании и развитие архитектуры сначала
происходили органично, однако на них влияли жесткие сроки, нехватка ресурсов,
факторы соответствия и различные потребности бизнеса. В результате архитектура
оказалась в значительной степени лишена организационных принципов и создавала
операционные отклонения, которые не позволяли работать продуктивно и эффективно.
Например, два разных сервиса, не имеющие общей цели, — сервис платежей и сервис персонализации пользовательского интерфейса — использовали одни и те же
учетные записи и, следовательно, одни и те же тестовые данные. Это сделало невозможным обеспечение безопасности с привязкой к конкретному сервису или осмысленную коррекцию данных для тестирования. Цель моей инициативы состояла
в том, чтобы привести инфраструктуру AWS компании в соответствие с передовыми методами обеспечения безопасности. Для этого мы занялись разделением учетных записей, чтобы добиться более точного сопоставления учетной записи хранения и сервиса.
Здесь имеет большое значение концепция местоположения сервиса (в какой учетной записи должно находиться конкретное приложение). Конфигурация учетной
записи влияет на надежность самого сервиса.
Если (или когда) ваша компания попытается разработать подобную архитектуру,
вы заметите, что решения о местоположении сервиса редко бывают однозначными.

Глава 10. Закрытие уязвимостей системы безопасности

363

Тем не менее я рекомендую придерживаться следующих принципов при определении целевой учетной записи для конкретного сервиса или ресурса:
 Бизнес-цель — какова бизнес-цель системы или ресурса? Этот вопрос поможет
провести своего рода привязку к сервису с помощью нескольких дополнительных вопросов:
 Являются ли система/ресурс частью основного сервиса?
 Являются ли они частью критически важной вспомогательной функции типа
обработки платежей либо других приложений поддержки — таких, как мониторинг безопасности, инфраструктура платформы или обработка больших
данных?
 Являются ли они частью сервисов, ориентированных на работу внутри компании для ее сотрудников, — например, ИТ-систем или управления расходами?
 Бизнес-цель стоит воспринимать как первичный ориентир для определения местонахождения сервиса.
 Привязка к сервису и к риску. Должна соотноситься с бизнес-целью. Системы с
одинаковыми бизнес-целями (например, поддержка студии), скорее всего, взаимосвязаны, а также имеют схожие профили рисков и контингент пользователей.
Эта привязка помогает выбрать местоположение сервиса.
 Требования соответствия — попадает ли сервис в сферу действия нормативных требований, таких как Стандарт безопасности данных индустрии платежных карт или закон Сарбэйнса-Оксли 2002 года? К системам, работающим в соответствии с нормативным регулированием, могут предъявляться требования
ограниченного доступа, которые проще выполнить с помощью отдельной и изолированной среды учетных записей.
 Право собственности — каждая учетная запись будет принадлежать одному
отделу, даже если учетная запись многопользовательская, а данные и приложения поступают из нескольких источников. Этот отдел будет отвечать за определение принципов организации приложений и систем в своей учетной записи.
Таким образом, отдел, владеющий учетной записью, должен согласиться с тем,
что сервис или данные будут размещены в их учетной записи.
 Отсутствие сегментов общего назначения — компаниям следует отказаться от
широких сегментов общего назначения и вместо этого по возможности создавать сегменты для приложений и конкретных отделов. Это позволит определить
хранилище и право собственности на данные для отделов, пользующихся хранилищами S3.
До сих пор мы рассматривали процессы автоматизации, запускаемые для обнаружения внутренних уязвимостей и учетных записей, как средство повышения безопасности. Теперь мы рассмотрим реализацию параллельных путей для повышения
безопасности по всем направлениям с целью получения преимуществ в области
защиты конфиденциальности. Для каждого пути перечислим:
 принцип — влияние конкретного пути на бизнес и безопасность;
 суть и выгоду — бизнес-обоснование для определения объема и аргументации;

364

Часть IV. Безопасность, масштабирование и кадровое обеспечение

 в какой ситуации особенно подходит;
 потенциальные уязвимости;
 желаемое (конечное) состояние;
 возможности.

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

Сегментация сервисов
Детали реализации сегментации сервисов таковы.
 Принцип — ограничьте радиус поражения и применяйте модель доступа «с наи-

меньшими привилегиями».
 Суть — суть в том, чтобы ограничить влияние критических событий, таких как

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

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

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

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

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

Глава 10. Закрытие уязвимостей системы безопасности

365

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

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

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

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

ры безопасности или кто-то воспользуется уязвимостью.
 В какой ситуации особенно подходит: специалисты по безопасности разрешают

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

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

пасности по всему стеку. Например, иметь несколько способов защиты от атак на
передаваемые данные, на конечные точки или экземпляры. Элементы управления
более высокого уровня (такие как протоколы TLS, аутентификация сервиса и ав-

366

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

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

Обеспечение поддержки
Здесь речь идет об инструментальных средствах для полной прозрачности системы,
идентификации владельца и управления отношениями. Так специалисты по конфиденциальности и безопасности могут предотвратить нападения и смягчить их воздействие.
 Принцип — прозрачность, владение и управление зависимостями.
 Суть — специалисты по разработке инфраструктуры должны знать, что нахо-

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

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

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

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

ти защиты данных все зависимости и потоки данных необходимо изучить и со-

Глава 10. Закрытие уязвимостей системы безопасности

367

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

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

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

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

368

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

10.2.1. Взлом компании Target
В декабре 2013 года компания Target опубликовала заявление о взломе, в котором
говорилось, что в период с 27 ноября по 15 декабря 2013 г., возможно, пострадали
40 миллионов счетов кредитных и дебетовых карт (http://mng.bz/aD4X). Тип украденных данных также известен как трек данных, и он позволяет мошенникам создавать поддельные карты, кодируя информацию на любую карту с магнитной полосой. Если воры также сумели перехватить PIN-данные для дебетовых транзакций, то они теоретически могли бы воспроизвести украденные дебетовые карты и
воспользоваться ими для снятия наличных в банкоматах (http://mng.bz/5KY8). Не
найти более серьезного примера нарушения безопасности, приводящего к нарушению конфиденциальности.
В кругах специалистов по кибербезопасности и защите конфиденциальности эта
история имела эффект разорвавшейся бомбы, когда блогер Брайан Кребс сообщил,
что хакеры взломали сеть ритейлера, используя для входа учетные данные, украденные у фирмы, занимавшейся отоплением, вентиляцией и кондиционированием
воздуха, которая обслуживала несколько зданий компании Target (http://mng.bz/
6ZGp). После того как информация получила огласку, компания Target привела
такие же аргументы, как и многие другие до и после нее. Руководство компании
сделало два заявления: их программы защиты данных и защиты от угроз были надежными и работали без сбоев, а нарушение произошло потому, что атака была
беспрецедентной, и ее сложно было предотвратить.
Последующий анализ показал другую картину. Один из контраргументов высказал
Джоди Бразил, основатель и технический директор компании-поставщика систем
безопасности FireMon. Бразил предположил, что во взломе не было ничего изощренного. Проблема — это расплата компании Target за отсутствие сегментации
сети, из-за которого у них действовал подход «все или ничего». Предоставив компании Fazio доступ для выполнения работ, Target невольно открыла им гораздо более широкий доступ, чем требовалось, — например, к платежным системам компании. Кропотливая работа по сегментации системы обеспечивает более узконаправ-

Глава 10. Закрытие уязвимостей системы безопасности

369

ленный доступ и более специализированную защиту. Очень часто компании бездействуют до тех пор, пока не становится слишком поздно (http://mng.bz/6ZGp).
Инженерам и техническим специалистам компаний, работающих с большими объемами чувствительных данных клиентов, бывает непросто выявить основные уязвимости безопасности, ставшие причиной конкретного нарушения. Это особенно
актуально потому, что резко возросшее количество комментариев и анализов безопасности и конфиденциальности часто вредит читателям, которые к концу обсуждения еще сильнее запутываются в фактах и в том, какие шаги необходимо предпринять.
Рассмотрим процесс взлома компании Target, чтобы вы могли учесть эти уязвимости при настройке собственной ИТ-безопасности (http://mng.bz/oaVy). На рис. 10.2
показано, что взлом происходил постепенно, методично и, в конце концов, последовательно.
Как видно из рис. 10.2, злоумышленники действовали целенаправленно, изучая
системы Target и проникая в них, получая несанкционированный доступ к приложениям внутри систем, а затем воруя данные. Сначала они получали доступ к данным, а потом расширяли свои привилегии. В следующих разделах мы рассмотрим
ситуацию подробнее, но инженерам в небольших и динамично развивающихся
компаниях следует усвоить главное: игнорирование или недооценка незначительных рисков может оказаться фатальной ошибкой. По мере погружения в детали вы
поймете, что случай компании Target — это история об упущенных возможностях
и катастрофических последствиях.

Рис. 10.2. Как взломали компанию Target

370

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Разведка с целью обнаружения сетевых уязвимостей
Как уже упоминалось, данные о вас, доступные где-либо, могут стать причиной
уязвимостей безопасности и конфиденциальности. То же самое относится и к сетевой инфраструктуре. В случае компании Target исследования показывают, что злоумышленники, готовясь к взлому, вероятно, сначала получили информацию об инфраструктуре Target. Так, по словам исследователя Тери Радичела, на веб-сайте
корпорации Microsoft представлено подробное тематическое исследование, описывающее, каким образом компания Target использовала ключевые возможности Microsoft: программное обеспечение для виртуализации и централизованное разрешение имен. В документации Microsoft также говорится, что Target использовала
средство управления Microsoft System Center Configuration Manager для применения
«заплаток» системы безопасности и системных обновлений. Кроме того, в тематическом исследовании Microsoft представлена техническая инфраструктура, а описание системы торговых точек тоже могло иметь значение для злоумышленников
(https://www.sans.org/white-papers/35412).
Таким образом, еще до взаимодействия с инфраструктурой компании хакеры получили план поверхности атаки. Инженеры, настраивающие доступ к сети вашей
компании, должны принимать во внимание существование подобной информации в
свободном доступе.
Как это часто бывает с современными распределенными системами с разными владельцами, обнаружить связи между инфраструктурой Target и ее поставщиками
оказалось не так уж сложно. Кребс отметил, что портал поставщиков компании находился в свободном доступе в сети Интернет. Его целью было обучение новых и
существующих поставщиков и партнеров тому, как обмениваться информацией и
проводить транзакции с Target. На портале также была страница со списком подрядчиков, занимающихся отоплением, вентиляцией и кондиционированием воздуха
(ОВКВ), а также холодильным оборудованием (http://mng.bz/nYxV).
Урок здесь в том, что инженеры, заботящиеся о защите конфиденциальности и
безопасности, должны, помимо прочего, рассматривать поставщиков как потенциальный вектор риска.

Получение несанкционированного доступа
к стороннему поставщику
Злоумышленники начали с кражи учетных данных поставщика систем ОВКВ —
фирмы Fazio Mechanical Services. По данным портала KrebsOnSecurity, который
первым обнародовал историю со взломом, преступники заразили компанию Fazio
универсальным вредоносным ПО, известным как Citadel, через электронную почту
с помощью фишинга (http://mng.bz/voOm). Запустив Citadel, злоумышленники
ждали, пока вредоносное ПО сообщит учетные данные для входа в систему Fazio
Mechanical (http://mng.bz/nYxV). Затем они использовали украденные учетные

Глава 10. Закрытие уязвимостей системы безопасности

371

данные для доступа к предназначенным для поставщиков веб-сервисам на серверах
компании Target.
Организации с ограниченным бюджетом или не имеющие специфического опыта
часто склоняются к тому, чтобы привлекать сторонние компании для решения узкоспециализированных задач, и такая позиция в данном случае оказалась фатальной. Многие сторонние компании сами стеснены в средствах и, следовательно, пессимистично настроены в отношении инвестиций в безопасность. Пытаясь сэкономить, они выполняют лишь необходимый минимум.
Руководство компании Fazio заявило, что они не осуществляли ни удаленный мониторинг, ни управление системами отопления, охлаждения или холодильными
установками для Target. По их словам, передача данных между Fazio и Target ограничивалась исключительно выставлением электронных счетов, контрактной документацией и управлением проектом.
Злоумышленники получили доступ к внутреннему веб-приложению, размещенному
во внутренней сети компании Target, но приложение не позволяло выполнять произвольные команды, необходимые для получения несанкционированного доступа к
технике (http://mng.bz/4jv5). Из-за таких конструктивных решений часто считается, что доступ к одному приложению ограничивает уязвимость в отношении конфиденциальности и безопасности. Компания Target на личном опыте прочувствовала обратное. Урок для инженеров и руководителей программ: нужно проверять
сторонние компании, имеющие доступ к вашей сети.

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

372

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Поиск данных о клиентах
На этом этапе уязвимость безопасности стала влиять на конфиденциальность. Злоумышленникам, проникнувшим на сетевую периферию, необходимо было узнать,
где находятся данные клиентов, до того, как их присутствие обнаружат.
В статье Тора Олавсруда для портала CIO Online говорится, что ключевой вектор
атаки был направлен на сервис каталога Active Directory компании Target. Каталог
служил хранилищем данных для пользователей, участников и сервисов. Используя
стандартный протокол LDAP, злоумышленники могли запрашивать Active Directory — и, возможно, им не требовалось знать, какой сервис какую функцию выполнял и для кого он это делал. Вероятно, они искали сервисы, соответствующие значению «MSSQLSvc», а имена сервисов помогли идентифицировать те службы, которые планировалось использовать, — например, занимавшиеся выставлением
счетов. После получения имен и расшифровки функций целевых сервисов, вероятно, хватило простого запроса на DNS-сервер для получения их IP-адресов
(http://mng.bz/4jv5).
Здесь может помочь поведенческая аналитика: тем, кто пытается получить доступ к
вашим сервисам для законных целей, обычно нет нужды извлекать все сервисы.
Наличие мониторинга безопасности также помогает защитить конфиденциальность; инженеры должны вкладываться в алгоритмы, обнаруживающие мошенническое и аномальное поведение при попытках посторонних лиц и сотрудников
компании получить доступ к конфиденциальным данным.

Получение и поддержание доступа к данным клиентов
Определив местонахождение конфиденциальных данных, злоумышленники применили технику под названием Pass-the-Hash (PtH), чтобы получить доступ к хештокену, позволяющему им выдавать себя за администратора каталога Active Directory. С PtH им не нужно было расшифровывать хеш, чтобы получить пароль в виде
простого текста. Атаки PtH используют протокол аутентификации, так как хеш пароля остается статичным для каждого сеанса до ротации пароля (пока администратор его не сменит). Злоумышленники обычно добывают хеши, извлекая их из активной памяти, а также другими способами (http://mng.bz/QWg1).
Мошеннический метод получения доступа администратора неэффективен, если администратор меняет свой пароль. Предвидя такую возможность, злоумышленники
использовали украденные привилегии для создания новой учетной записи и добавления ее в группу администраторов домена. Это дало вновь созданной учетной записи необходимые права, сведя на нет вероятность того, что кто-то другой изменит
пароль (http://mng.bz/4jv5).
Урок для инженеров очевиден: нужно иметь больше многоуровневых и непрерывных средств контроля доступа и аутентификации для тех, кто стремится попасть в
вашу сеть. Стоит добавить дополнительные препятствия на входе, учитывая, какие
риски для конфиденциальности клиентов возникнут, если злоумышленник попадет
внутрь и найдет, где хранятся ваши ценности.

Глава 10. Закрытие уязвимостей системы безопасности

373

Расширение доступа к данным клиента
На этом этапе злоумышленникам необходимо было обойти брандмауэры и другие
средства сетевой безопасности, преграждавшие прямой доступ к их целям, а затем
запустить удаленные процессы на различных машинах, ведущих по цепочке к
этим целям. Они использовали свои учетные данные совместно с утилитой Microsoft PSExec. (замена протокола telnet для выполнения процессов в других системах) и внутренним клиентом удаленного рабочего стола Windows. Оба инструмента используют каталог Active Directory для аутентификации и авторизации
пользователя, а значит, Active Directory узнает об этом действии, если кто-то пытается его выполнить.
Получив доступ к нужным системам, злоумышленники использовали приложение
администрирования Microsoft Orchestrator для получения постоянного доступа. Это
позволило им удаленно вводить какой угодно код на взломанных серверах
(http://mng.bz/4jv5).
Рискую повториться, но эта дополнительная уязвимость еще раз показывает, насколько важно следить, чтобы возможности мониторинга были непрерывными и
распространялись на сторонние компании, особенно с учетом узкого понимания
компанией Fazio своих обязательств по защите данных. Как уже говорилось, руководство Fazio заявляло, что компания не осуществляла удаленный мониторинг систем отопления, охлаждения или заморозки или управление ими для Target. По их
словам, Fazio передача данных между ними и Target ограничивалась исключительно выставлением электронных счетов, представлением контрактов и управлением
проектами.

Кража личных данных клиентов и данных кредитных карт
Раздел 3.2 стандарта PCI-DSS гласит: «Не храните конфиденциальные данные аутентификации после авторизации (даже в зашифрованном виде). При получении конфиденциальных данных для аутентификации после завершения процесса авторизации
они должны быть уничтожены без возможности восстановления» (http://mng.bz/
4jv5). Поскольку на момент взлома компания Target соблюдала требования стандарта PCI, в базах данных не хранились данные кредитных карт. Таким образом,
хотя злоумышленникам и удалось получить доступ к персональным данным
70 миллионов клиентов компании, у них не было доступа к их кредитным картам.
Однако, как обсуждалось выше в разделах в разделах «Поиск данных о клиентах» и
«Получение и поддержание доступа к данным клиентов», злоумышленники получили доступ к торговым автоматам компании Target и возможность запускать программы автоматов удаленно. Они воспользовались этим для установки вредоносного ПО, с помощью которого затем просканировали память зараженных машин и
сохранили все данные кредитных карт, найденные в локальных файлах.
Урок для инженеров: незначительные уязвимости безопасности, на которые не обращают внимания, часто накапливаются, вырастая в серьезную угрозу конфиденциальности, и могут привести к эксфильтрации конфиденциальных данных клиентов.

374

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Исследователь Таль Беери, чью работу я цитировал на протяжении всего обсуждения, утверждает, что «начальная точка проникновения — не самое важное, ведь вы
должны предполагать, что в конечном итоге вас взломают... Вы не можете предположить иное. Нужно быть готовым и иметь план реагирования для ситуации, если
вас взломают. Настоящей проблемой станет, когда вредоносное ПО позволит злоумышленнику проникнуть глубже в сеть» (http://mng.bz/4jv5).

Отправка украденных данных за пределы сети компании
Как только вредоносная программа получила данные кредитных карт, то с помощью команды Windows и учетных данных администратора домена она создала удаленный файлообменник на компьютере с FTP-сервером. И периодически отправляла
копии локальных файлов на удаленный ресурс общего доступа. Оба эти инструмента проходят авторизацию через Activity Directory и могли бы быть замеченными, если бы кто-то обратил на это внимание. Если бы в Target хоть как-то мониторили данные, покидающие их сеть, то, несмотря на предыдущие ошибки, компания
и ее партнеры, возможно, смогли бы предотвратить потерю этих данных. Тор Олавсруд, чей анализ, опубликованный на порталах CIO и CSO, цитируется в этом разделе, предлагает инженерам несколько практических методов для защиты конфиденциальности и безопасности компании. Я их доработал, но вы можете прочитать
и саму статью Олавсруда (http://mng.bz/4jv5).
 Создайте более надежный режим контроля доступа. Здесь потребуются совме-

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

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

тям тоже следует сделать многоуровневым. Тогда способ подключения пользователя к услугам и хранилищам данных будет определять права доступа к ним.
Предоставлять всем свободный доступ к данным неразумно, а широкий доступ к
сетям также может принести проблем. Исследователь Тери Радичел утверждает,
что ограниченные права администратора могли бы предотвратить внедрение
ПО, позволяющего вмешиваться в процесс развертывания, используемый для
заражения POS-системы вредоносными программами (https://www.sans.org/
white-papers/35412). Это требует скорее смены мировоззрения, а не технического решения, ведь инженерам придется урезать свои амбиции и отказаться от повсеместного и постоянного доступа к конфиденциальным данным.
 Учитывая преобладание теневых ИТ-ресурсов и распределенное владение сер-

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

Глава 10. Закрытие уязвимостей системы безопасности

375

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

вимости безопасности) и лишь потом атакуют конфиденциальные данные, необходимо отслеживать любые запросы, которые кажутся оптимизированными для
сбора информации. Если вы видите, что пользователь делает такие запросы к
сервисам или в поисках данных, — это может быть признаком, что происходит
что-то нехорошее.
 Для серверов, выделенных конкретным сервисам или пользователям, а также

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

злоумышленник использует собственные инструменты, но самые опытные преступники, как правило, обманывают антивирусные программы с помощью готовых корпоративных инструментов. Вам необходимо соответственно разнообразить свой защитный арсенал.
 Программа Active Directory может служить как шлюзом, так и средством для

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

Дополнительные практические рекомендации от Тери Радичела включают в себя
техническое обслуживание, мониторинг и анализ контрольных журналов
(https://www.sans.org/white-papers/35412). Журналы могут помочь отслеживать
аномалии — такие, как искаженные пакеты и пакеты с неожиданными размерами
или данными. Хоть они и длинные, журналы содержат метки о выводе крупных

376

Часть IV. Безопасность, масштабирование и кадровое обеспечение

объемов данных. Кроме того, в них могут записываться случаи неожиданного трафика в критические системы и из них. Примером аномалии будет сброс платежной
системой данных вне своего нормального цикла.
Аномалии часто являются признаком того, что непрошенный гость совершает нежелательные действия с конфиденциальными данными.
Радичел также предлагает компаниям «составлять профили учетных записей, отмечая нормальную деятельность и периоды использования, для выявления аномалий».
Права учетной записи должны быть ограничены принципом необходимого знания.
Специалисты компании по ИТ и безопасности должны «разделить доступ к учетным записям в сети по уровням. Отключить и удалить ненужные учетные записи»
(https://www.sans.org/white-papers/35412). Случаи с компаниями Target и Colonial
Pipeline подчеркивают риски широкого доступа и отсутствия контроля над неиспользуемыми учетными записями. Это еще один слом мировоззрения, когда компаниям необходимо оптимизировать качество взаимодействия с пользователем, а
не только объем.
Что касается порталов поставщиков, Тери Радичел рекомендует применять «Тесты
на проникновение и тренировки по отражению внешней угрозы, поскольку эта система находится по периметру на первом уровне обороны...» (https://www.sans.org/
white-papers/35412). Предотвратить проникновение злоумышленников крайне
важно, но не менее важно гарантировать, что данные, хранящиеся в определенных
местах, не покинут периметр сети.
Фильтрация URL-адресов, на которые отправляются данные, сама по себе может
способствовать ограничению исходящего доступа. Ответная реакция компании
Target на взлом включала реализацию многих из этих идей (http://mng.bz/XWAl).
Описанные уязвимости поставщиков имеют большое значение, но маловероятно,
что они характерны только для низкотехнологичных узкоспециализированных поставщиков. В следующем подразделе я объясню, почему.

10.2.2. Слабые места безопасности системы MongoDB
Система управления базами данных MongoDB была популярна у разработчиков,
переходящих на облачные серверы, например, размещенные на AWS. В период работы в компании Nike, когда я руководил отделом управления идентификацией,
мне пришлось освоить MongoDB за одну ночь. В те годы технология MongoDB
внедрялась очень активно.
MongoDB особенно полезна для хранения неструктурированных данных. Ее модель
данных хранит все связанные данные вместе в одном документе. Благодаря этому
ее структура становится гораздо более удобной, чем у модели реляционной базы
данных (https://www.mongodb.com/scale/unstructured-data-types). Однако система
MongoDB подверглась более мощным атакам, чем любая другая платформа.
Ранние версии MongoDB позволяли устанавливать сервер базы данных без включенного механизма аутентификации. Проще говоря, установка MongoDB по умол-

Глава 10. Закрытие уязвимостей системы безопасности

377

чанию была небезопасной. То есть любой, кто имел доступ к порту базы данных,
мог подключиться к базе данных с неограниченными полномочиями. Возможно, к
появлению этой уязвимости привела главная цель MongoDB — доступ с малой задержкой к огромным объемам данных. Однако, учитывая распространение конфиденциальных данных среди компаний, это не столько риск безопасности, сколько
нарушения конфиденциальности. И он исходит не изнутри периметра, а от поставщика.
Период с 2014 по 2017 год очень важен: именно тогда происходило расширение
пространства онлайн-идентичности, а также объемов неструктурированных данных, к которым обращались компании. От этих перемен выиграли базы данных
вроде Cassandra и MongoDB. Они же становились и объектами атак. Базы данных
системы MongoDB регулярно подвергались атакам, и в результате нескольких были
украдены данные. В 2017 году на облачные базы данных MongoDB было произведено несколько атак программ-вымогателей. В силу специфики подобных атак, во
многих случаях данные восстановить не удалось (http://mng.bz/y427).
Поскольку законы о защите данных ужесточались, а нарушения стали обычным
явлением, в базы данных MongoDB были внесены изменения (http://mng.bz/y427).
 В версии MongoDB 3.6 (2017) был по умолчанию закрыт внешний доступ, что

снизило ее обнаруживаемость потенциальными злоумышленниками. Это не устранило все уязвимости, но уменьшило вероятность атаки на базы с установкой
по умолчанию.
 В MongoDB 3.6 также появился список разрешенных IP-адресов. Теперь доступ

не предоставлялся автоматически, а по умолчанию был задан запрет доступа с
IP-адресов, не входящих в список.
 В версии 4.0 облачный сервер Atlas добавил поддержку аутентификации с по-

мощью протокола LDAP, что означало более высокие требования при первичном входе. Со стороны хранилища диск хранилища зашифровывался, а управление ключами передавалось клиенту. Это помогло снизить вероятность, что потеря хранилища будет равносильна потере данных.
 Версия 4.2 развивала шифрование, добавив шифрование на стороне клиента, а

также на уровне поля. Все эти вместе взятые изменения затрудняли атаку и извлечение данных.
 В MongoDB 4.4 добавлена аутентификация x509 и интеграция с системой управ-

ления идентификацией и доступом веб-сервисов Amazon. Тем самым совмещаются шифрование и режим контроля доступа к AWS.
Несмотря на эти улучшения, по состоянию на 24 июля 2020 года тысячи баз данных MongoDB были уничтожены атакой «Мяу».
Увидев, насколько единообразно происходят взломы баз данных, исследователи
установили приманки, чтобы выяснить, как происходят атаки, откуда исходят угрозы и как быстро они начинаются. Приманка — это «компьютер или компьютерная
система, предназначенные для имитации вероятных целей кибератак»
(http://mng.bz/M2WE). В Интернете были разбросаны десятки незащищенных баз-

378

Часть IV. Безопасность, масштабирование и кадровое обеспечение

приманок MongoDB, заполненных фальшивыми данными. Сетевой трафик отслеживался на предмет вредоносной активности. Если было замечено, что хеши паролей извлечены и покинули базу данных, это являлось признаком ее взлома
(http://mng.bz/aD4x).
Исследование показало непрерывные атаки на онлайн-базы данных MongoDB. Казалось, что атаки автоматически настраивались на новые онлайн-базы данных и
были высокой интенсивности, чтобы использовать уязвимости. В одном примере
незащищенные базы данных были взломаны в среднем менее чем за 24 часа
(http://mng.bz/aD4x).
В ходе исследования как минимум одна из приманок была успешно атакована и
захвачена для получения выкупа менее чем через минуту после появления в сети.
Действуя по печально известной схеме, злоумышленник стер базу данных и оставил записку о выкупе, попросив платеж в биткойнах за возврат данных. Обратите
внимание: в таких ситуациях нет гарантии, что злоумышленник все еще владеет
данными или готов вернуть их после получения оплаты.
Исследователи установили еще приманки, и в этот раз незащищенная база данных
Mongo оказалась взломана меньше, чем за 13 часов после подключения к Интернету. Одно проникновение, которое исследователи считают самым быстрым из зарегистрированных, произошло через девять минут после завершения настройки базы
данных (http://mng.bz/g4YZ).
Исследователь Крис Уоллис утверждает, что трудно отреагировать на такие атаки
меньше, чем за девять минут, в особенности если ваша компания небольшая. Уоллис выделяет две проблемы, с которыми сталкиваются компании: во-первых, обнаружение незащищенной базы данных и оценка уровня риска; и во-вторых, устранение проблемы и закрытие бреши в безопасности. По словам Уоллиса, решить обе
эти задачи и за 13 часов непросто, не говоря уже о девяти минутах
(http://mng.bz/aD4x).
Как утверждает эксперт по безопасности Гай Харрисон, «база данных Atlas, принадлежащая MongoDB, как платформа полностью защищена и невосприимчива к
таким атакам. Подобные уязвимости проявляются только у систем, настроенных
вручную на облачных виртуальных машинах» (http://mng.bz/y427). Имеется в виду, что только те системы, которые были настроены вручную на облачных виртуальных машинах, демонстрируют эти уязвимости. И для достижения высокого
уровня безопасности облачных баз данных компании достаточно лишь использовать базу данных Atlas системы MongoDB.
В этом заключается риск для малого бизнеса с ограниченным бюджетом. У них
может не быть средств на закупку первоклассной БД Atlas, а их настройки вручную
могут соответствовать заданным по умолчанию значениям в MongoDB, тем самым
наследуя уязвимости конфиденциальности и безопасности.
Также возможно, что самыми незащищенными базами данных MongoDB являются
те, которые находятся в стадии разработки или тестирования и используют устаревшие версии кода MongoDB. Однако, как вы видели, тестовые и находящиеся в
разработке экземпляры могут содержать производственные данные с ограничен-

Глава 10. Закрытие уязвимостей системы безопасности

379

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

10.2.3. Лучшие практики в сфере авторизации
Многие фирмы настраивают систему авторизации на начальной стадии развития.
Ошибки, допущенные на этой стадии, как правило, настигают компании в самый неподходящий момент. В этом разделе я дам несколько рекомендаций, которые послужат для таких компаний контрольным списком по развитию системы авторизации.
Настоящая проблема, с которой сталкиваются организации, — разработка детальной авторизации. Об аутентификации говорят уже достаточно долго, у нее есть
стандарты, в основе которых лежат протокол авторизации OAuth 2, язык SAML и
протокол проверки подлинности OpenID Connect. Для авторизации же нет подобных аналогов, позволяющих единообразно реализовать ее в различных сервисах. В
результате каждый владелец сервиса может сам настраивать разрешения, привилегии и роли. Вместо мелкозернистой архитектуры авторизации, которую можно соотнести с уровнями риска и использования, мы получаем контроль доступа в индивидуальном режиме (http://mng.bz/endw).
По словам аналитика безопасности Омри Газитта, подход к авторизации должен
придерживаться определенных передовых практик (http://mng.bz/p2gE). Мы изучим некоторые из них подробно в следующих разделах.

Принудительное разделение политики авторизации и кода
У инженеров может возникнуть соблазн децентрализовать политику авторизации и
адаптировать ее под свой сервис так же, как они поступают с другими функциями.
Однако это создаст проблемы по мере расширения использования сервиса и угрозы. Например (http://mng.bz/OG22):
 даже при наличии у разных сервисов собственных политик авторизации может

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

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

380

Часть IV. Безопасность, масштабирование и кадровое обеспечение

 по мере роста компаний в результате слияний у них могут появиться «по на-

следству» сервисы, написанные на разных языках. Это затрудняет задачу модификации не только политики авторизации, но и всего сервиса в целом.
Основываясь на выводах Омри Газитта, приведу несколько лучших практик по разграничению политики и кода (http://mng.bz/p2gE).
 Объединение приложений и политики авторизации несет в себе риск появления

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

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

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

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

Глава 10. Закрытие уязвимостей системы безопасности

381

жения. Большинство инженеров, если им предоставить правильный инструментарий и контекст, будут делать правильные вещи для конфиденциальности и безопасности. Те же инженеры часто из-за нехватки времени и бестолковых инструкций
могут совершить ошибки по неаккуратности.
Чтобы показать, как это может произойти, изучим, каким образом ошибки в кодовой базе компании John Deere привели к появлению уязвимости. Инженерам часто
кажется, что ошибки в коде не связаны с защитой данных. В этом случае ошибки
стали открытой дверью к данным клиентов, владевших оборудованием и техникой
компании (http://mng.bz/YgPe).
Уязвимости, если бы их использовали, раскрыли бы личные данные клиентов John
Deere, в том числе их адреса. По словам исследователя, «для новой сельскохозяйственной техники он смог увидеть имя владельца техники или оборудования, его адрес, уникальный идентификатор оборудования и идентификационный номер
транспортного средства или VIN, идентификационный код конкретного автомобиля» (http://mng.bz/YgPe).
Исследователь рассказал, что «первая уязвимость позволяла кому угодно составить
список всех логинов веб-портала John Deere». Это все равно что зайти на сайт интернет-магазина и получить возможность видеть логины всех покупателей. Если бы
эта уязвимость осталась незамеченной, злоумышленники смогли бы легко узнать,
сколько пользователей подписалось на онлайн-портал. Этого можно было бы избежать, если бы веб-сайт или мобильное приложение обнаруживали подобные запросы. Однако именно здесь вторая уязвимость стала еще более критической.
Неавторизованный злоумышленник с удаленным доступом, то есть человек, который даже не вошел в систему, мог просто удалить cookie-файл из исходного запроса. И тогда каждый последующий запрос казался бы новым. Злоумышленник мог
отправлять один и тот же запрос много раз. Помимо слабого протокола аутентификации, отсутствие ограничения скорости позволило бы атаке продолжаться, не ослабевая. Способность неограниченно долго находить имена пользователей в сочетании с возможностью получить личные данные из информации о новом оборудовании представляла собой мощный вектор атаки.
Злоумышленники могли бы использовать эти пробелы для поиска и публикации
личной информации всех владельцев техники John Deere. По мнению исследователя, доступ к уязвимости осуществлялся через мобильное приложение операционного центра John Deere для Android и iOS и соответствующую веб-версию.
Злоумышленники могли получить необходимый cookie-файл для API, просто зарегистрировавшись в приложении и не покупая технику компании John Deere. Затем
они могли «раскрыть имя владельца любой единицы техники или оборудования,
его адрес, глобальный уникальный идентификатор оборудования (постоянный
идентификатор оборудования) и статус удаленного доступа к терминалу через протокол RDA с помощью API идентификационного номера автомобиля (VIN)», —
говорится в отчете об уязвимости.

382

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Подобные случаи можно исправить с помощью методов, рекомендованных исследователем Омри Газиттом (http://mng.bz/p2gE):
 Политики должны быть безопасными по умолчанию — опасность использова-

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

учетная запись президента Джо Байдена в сервисе мобильных платеженй
Venmo. Исследователям из медиа-компании Buzzfeed потребовалось менее
10 минут, чтобы его найти. Они смогли обнаружить не только учетную запись
президента, но и сеть его личных социальных связей.
 Урок для разработчиков приложений таков: если приложение создано неакку-

ратно, степени вовлеченности и конфиденциальности могут быть обратно пропорциональны друг другу. Функции, стимулирующие вовлеченность, — возможность легко оплачивать подключения и приглашать друзей подписаться в
обмен на поощрения — создают график, показывающий, что негативный эффект
от утечки данных усиливается. В случае с президентом Байденом это могло
стать вопросом национальной безопасности. Для обычных пользователей это
представляло серьезную проблему конфиденциальности, поскольку не было
возможности предсказать, как на них может повлиять данный пробел в защите.
«У клиентов всегда есть опция сделать свои транзакции конфиденциальными и
задать собственные настройки конфиденциальности в приложении», — заявила
компания Venmo в ответ. В итоге авторитетные лица в области защиты конфиденциальности потребовали сделать транзакции и друзей закрытыми по умолчанию. Так что «конфиденциальность по умолчанию» — это идея, время которой
пришло.
 Авторизация должна поставляться как сервис, а не как библиотека: предос-

тавление решения разработчика в виде библиотеки, а не сервиса, — идея, которая работает в теории, но не на практике. Однако, если вы предоставляете сервис разработчика, это может помочь обеспечить центральную точку управления
и выполнять работу, необходимую для масштабирования решения. Газитт считает это важной причиной, по которой разработчики доверяют таким сервисам
платежей, как Stripe, или аутентификации, как Auth0.
 Сервисы авторизации должны легко интегрироваться — во многих (если не в

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

Глава 10. Закрытие уязвимостей системы безопасности

383

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

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

должна интегрироваться со стандартными системами аутентификации, чтобы
переход из «AuthN» в «AuthZ» был плавным. Реализация потребует, чтобы система авторизации принимала идентификационную информацию в криптографическом токене, таком как JavaScript Web Token (JWT). Системы авторизации
должны обеспечивать широкий охват от поставщиков удостоверений платформы — таких как Google и Azure — до поставщиков федеративных удостоверений, таких как Okta и корпоративных каталогов вроде Active Directory.
 Чтобы стать комплексной, система должна сопоставить различные виды иден-

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

комбинации приложения и идентифицирующих данных. Если обнаружение и
применение политики занимает слишком много времени, возникает опасность,
что по умолчанию будут применены далеко не оптимальные настройки. Измерение и тестирование играют здесь ключевую роль.
 Наконец, Газитт отмечает, что система должна поддерживать «API REST и

gRPC для авторизации, комплект средств разработки и привязку к языку для популярных языков и инструментария, [а также] простые соглашения для организации и разработки политик для ресурсов, доступ к которым осуществляется с
использованием стандартных архитектурных шаблонов (например, REST,
GraphQL)» (http://mng.bz/zQMr).
 Это важнее, чем могут себе представить многие новички в сфере защиты конфи-

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

384

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Проверка надежности каналов передачи данных
и подтверждение подлинности личности
Мы уже обсудили, как лучше защитить периметр, организовать слои защиты внутри периметра и упростить внедрение описанных средств защиты. Но как повысить
эффективность этой защиты, чтобы достичь нашей главной цели — защиты данных
клиента и конфиденциальности?
Эксперт по идентификации Роберт Маккей указывает на риски ограниченных процессов проверки, применяемых компаниями (http://mng.bz/0wWm). Это в особенности касается динамично развивающихся компаний, которым отчаянно нужно добиться вовлеченности клиентов. Компании часто проверяют личность пользователей с помощью подтверждающей информации, которую теоретически может знать
только реальный пользователь, — например, имя питомца или девичью фамилию
матери. Традиционно проверка личности представляет собой линейный процесс, в
ходе которого человек, пытающийся аутентифицироваться, предоставляет проверяемые данные в качестве доказательства. В зависимости от рабочего процесса
компании и склонности к риску, объем запрошенных данных может быть большим
или маленьким. Самое наглядное — когда мы предоставляем номер карточки социального страхования или идентификационный номер налогоплательщика, чтобы
воспользоваться финансовыми услугами. Есть много способов проверки принадлежности номера карточки социального страхования лицу, его предоставившему.
Далее у пользователя могут запросить счет за коммунальные услуги в качестве
подтверждения места проживания.
Однако у этих подходов появляются ограничения по мере того, как злоумышленники становятся все изощреннее. По мнению Маккея, «вместо того, чтобы выполнять аутентификацию с помощью ряда проверок точек данных, необходимо целостно исследовать связи между всеми маркерами идентичности во времени»
(http://mng.bz/0wWm). Необходимость нового подхода обуславливается тем, что
злоумышленникам становится все проще получать последовательные фрагменты
данных, управляющие процессом проверки.
Маккей описывает атаку, известную как атака с применением технологии «незаконный посредник». Ее можно смягчить, если с обеих сторон надлежащим образом
применяются протоколы TLS, но такая атака может быть весьма вредоносной, учитывая эффективность попыток фишинга, недостаточное применение многофакторной аутентификации и изобилие учетных данных в Даркнете. На рис. 10.3 показана
концепция действия атаки.
Мошенники действуют по алгоритму:
1. Злоумышленник настраивает два параллельных диалога между компанией и
клиентом.
2. Компания считает, что связывается с клиентом, а клиент думает, что разговаривает с компанией. На самом деле с обеими сторонами взаимодействует злоумышленник.
3. Мошенник может инициировать схему, запросив выдачу одноразового пароля
через сеанс на веб-сайте компании. Это стало сделать проще потому, что адреса

Глава 10. Закрытие уязвимостей системы безопасности

385

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

Рис. 10.3. Атака «Незаконный посредник»

Злоумышленники также могут создавать поддельные удостоверения, используя
комбинацию подлинных данных, принадлежащих клиенту, и фальшивых правдоподобных данных, которые могли бы принадлежать этому клиенту.
Чтобы получить представление о социальной инженерии, лежащей в основе атак с
подменой участника, подумайте вот о чем: если вы или я обнаружим, что кто-то
использует наш номер карточки социального страхования, скорее всего, мы немедленно примем меры. Вот почему некоторые злоумышленники могут использовать
личные данные детей, пожилых людей и бездомных. Не меняющаяся или даже
средняя кредитная история в сочетании с простой проверкой личности (использование информации, имеющейся в свободном доступе в Интернете) удовлетворяют
требованиям порога проверки многих учреждений (http://mng.bz/0wWm).
Отчасти так происходит из-за количества задействованных транзакций и объема
данных и динамики, в которой главной валютой являются вовлеченность и низкая
задержка. Подобное положение дел неоптимально во всех отношениях — как для
человека, чью личность незаконно используют, так и для обманутого учреждения.
В случаях инцидентов, наносящих ущерб безопасности и конфиденциальности,
жертв почти всегда несколько.
Маккей верно подчеркивает, что даже более динамичные методы, такие как проверка местоположения, имеют ограничения. Компании поступают умно, внедряя

386

Часть IV. Безопасность, масштабирование и кадровое обеспечение

использование данных о местоположении для подтверждения личности. Одним из
примеров является добавление банком дополнительных уровней проверки, если вы
воспользовались приложением, находясь в совершенно новом месте. В таких случаях приложение может отправить одноразовый код на подтвержденный адрес
электронной почты или номер телефона. Однако у этого подхода есть лазейки, которыми могут воспользоваться мошенники. Злоумышленник может физически находиться вблизи адреса клиента, тогда его положение по GPS будет достаточно похожим, чтобы обмануть проверку.
Именно здесь средства защиты конфиденциальности часто вступают в противоречие. Я уже писал, что компании могут сокращать количество знаков после запятой
в GPS-координатах, хранящихся для указания данных о местоположении. Это защищает конфиденциальность данных, затрудняя идентификацию пользователей по
принадлежности к конкретной группе. С другой стороны, ограниченная точность
таких данных снижает точность указания местоположения и оставляет открытой
лазейку для злоумышленников.
Учитывая эти риски, что должны делать инженеры и руководители технических
программ при проверке личности пользователя? Маккей рекомендует применять
целостный подход к идентификации на основе онлайн- и офлайн-данных, а также
сведений об используемых устройствах и поведении за период времени. Такой
процесс подразумевает выполнение следующих видов оценки почти в режиме реального времени:
 Не рассматривайте точки данных по отдельности, а соотносите их друг с другом,

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

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

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

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

Глава 10. Закрытие уязвимостей системы безопасности

387

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

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

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

388

Часть IV. Безопасность, масштабирование и кадровое обеспечение

В начале 2021 года один из крупнейших в стране нефтепроводов, по которому
транспортируются очищенный бензин и топливо для реактивных двигателей из Техаса в Нью-Йорк через Восточное побережье, был вынужден прекратить работу
после того, как подвергся атаке программ-вымогателей. Это самый недавний пример того, насколько уязвимой может быть американская энергетическая инфраструктура к кибератакам. Оператор системы, компания Colonial Pipeline заявила,
что перекрыла трубопровод протяженностью 5 500 миль, по которому, по их словам, проходило 45 процентов запасов топлива для Восточного побережья, чтобы
локализовать взлом (http://mng.bz/KB14).
Логично было бы предположить, что взлом такого масштаба возник в результате
нарушения функционирования системы безопасности сопоставимого размаха. Это
кажется особенно реалистичным, если учесть серьезность последствий: нехватка
топлива и длинные очереди за ним. Однако взлом, по данным эксперта по кибербезопасности, изначально стал результатом одного скомпрометированного пароля.
Согласно отчету агентства Bloomberg (http://mng.bz/9KOa), хакерам удалось получить доступ к сети компании Colonial Pipeline из-за уязвимости. Однако эта уязвимость не должна была существовать, учитывая уроки, которые следовало извлечь
из взломов компаний Target и Equifax.
Хакеры использовали учетную запись виртуальной частной сети (VPN), которая
была настроена таким образом, чтобы предоставлять сотрудникам удаленный доступ к компьютерной сети компании. Особенно должен насторожить тот факт, что
учетная запись была бездействующей, но с нее сохранялась возможность доступа к
сети компании.
На протяжении этой книги уже несколько раз говорилось, что комбинация точек
данных может значительно увеличить уязвимости. В этом случае оказалось достаточно вышеупомянутой учетной записи в сочетании с обнаружением ее пароля в
пакете паролей, просочившихся в Даркнет.
Невозможно узнать наверняка, как эти учетные данные оказались в Даркнете. Чарльз
Кармакал, эксперт по безопасности, в интервью для статьи агентству Bloomberg
предположил, что сотрудник компании Colonial Pipelines мог использовать другую
учетную запись с такими же учетными данными, а затем ее взломали. Данные о
количестве удостоверений и их сопоставлений с правами доступа трудно обновлять
и защищать, и одной неудачи достаточно, чтобы злоумышленники смогли напасть.
Кроме того, для учетной записи VPN не использовалась многофакторная аутентификация. Вообще учетная запись, разрешающая удаленный доступ и не аутентифицированная в течение какого-то времени, должна была стать главным кандидатом
на многофакторную аутентификацию (МФА). Отсутствие этого препятствия облегчило работу злоумышленникам. Выявление возможных попыток фишинга, направленных на сотрудника, чей аккаунт был взломан, не дало результатов.
Это означает, что взлом мог быть результатом:
 неиспользования учетной записи VPN в течение какого-то времени;
 отсутствия мониторинга бездействия учетной записи и повторного использования пароля;

Глава 10. Закрытие уязвимостей системы безопасности

389

 повторного использования учетных данных, при котором кто-то еще раз исполь-

зовал в Интернете тот же пароль, что и для VPN;
 отсутствия МФА, из-за чего сбой базового уровня аутентификации привел к

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

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

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

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

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

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

390

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Потенциальный риск, связанный со слабой защитой данных, стал реальным
15 января 2021 г. Целью была водоочистная станция, обслуживающая Область залива Сан-Франциско. Злоумышленники не только несанкционированно проникли
внутрь, но и попытались отравить воду, продемонстрировав прямую связь уязвимости со здоровьем населения. Они вошли через открытую дверь, использовав логин и
пароль учетной записи бывшего сотрудника для программы, позволявшей удаленный доступ. Как мы уже видели в этой главе, комбинация легкого доступа и привилегий может привести к нежелательным последствиям. И, конечно же, войдя в систему, хакер попытался удалить программы очистки воды (https://www.nbcnews.com/
news/amp/rcna1206).
Этот инцидент — пример, показывающий, что кибератаки теперь направлены и на
водную инфраструктуру. Всего через несколько недель после атаки в Области залива Сан-Франциско нечто подобное произошло в Олдсмаре, штат Флорида. Вторая атака была похожа на первую тем, что для доступа использовалась учетная запись программы TeamViewer. Злоумышленник использовал ее права доступа, чтобы повысить уровень щелочи в питьевой воде до ядовитого. Обнаружили его не с
помощью элементов управления или автоматического мониторинга, а благодаря
бдительному сотруднику, который заметил, что курсор компьютерной мыши двигается сам по себе. К счастью, этот сотрудник смог отменить внесенные хакером
изменения (http://mng.bz/jyOy).
В новостях NBC об инциденте в Области залива верно указано, что децентрализованный характер водоснабжения спасает от централизованных отключений. В
США и выборы проводятся локально, и большинство источников водоснабжения
тоже локализованные. Благодаря этому злоумышленники не могут использовать
центральную точку отказа.
Это одновременно благословение и проблема. Отсутствие центральной власти в
инфраструктуре также приводит к отсутствию единого закона о кибербезопасности
и конфиденциальности.
«Очень трудно применить какую-то единую оценку кибергигиены, учитывая несопоставимые размеры, мощности и технические возможности всех водоканалов», —
говорит Майк Киган (Mike Keegan), аналитик Национальной ассоциации сельского
водоснабжения, отраслевого объединения данного сектора (https://www.nbcnews.com/
news/amp/rcna1206).
Электросистема в США в основном состоит из коммерческих корпораций, деятельность которых следовало бы контролировать жестче. С другой стороны, большая
часть объектов питьевой воды в Соединенных Штатах — некоммерческие. Их уровень кибербезопасности зависит от величины клиентской базы, что, в свою очередь, определяет финансирование, выделяемое на кибербезопасность. Когда местные органы власти сокращают финансирование, вероятно, эти функции страдают,
что приводит к задержке обновлений и сокращению штатов.
Это отголоски инцидента с поставщиком услуг ОВКВ, уязвимости которого создали ключевую цепочку для взлома компании Target почти десять лет назад.

Глава 10. Закрытие уязвимостей системы безопасности

391

В репортаже NBC News приводится случай, который меня особенно беспокоит.
По словам Дарина Мартина, технического помощника в Канзасской ассоциации
сельского водоснабжения, отраслевой организации, объединяющей около 800 водоочистных сооружений Канзаса, включая Пост-Рок, небольшие сельские объекты
водоснабжения обычно неохотно рассказывают о своих уязвимостях.
«Как правило, они не отчитываются перед федеральным правительством. Знаете, в маленьких городках на Среднем Западе США чувствуется некое недоверие», — сказал он…
«Удаленный доступ избавляет вас от необходимости дежурить на объекте
24 часа в сутки, — добавил Мартин. — У нас много отдаленных водных районов,
разбросанных на сотни миль. Платить парню за то, что он проедет 30 миль, чтобы включить насос? А затем ему, возможно, придется выключать его через
3 часа, когда бак наполнится? Все это он может делать удаленно. Это экономит
деньги» (https://www.nbcnews.com/news/amp/rcna1206).
Если заменить недоверие правительству на организационную разобщенность, у вас
получится пример крупного бизнеса с данными о здравоохранении, путешествиях и
финансах, уязвимого для кибератак и ущерба конфиденциальности.
Удаленная работа и сегментация сервисов, конечно, будут и дальше применяться,
но негативные последствия для защиты данных становятся все серьезнее. Если злоумышленники могут испортить водопроводную воду, просто изменив программы и
настройки, то ущерб, который они смогут нанести персональным данным, невообразим и не поддается измерению. По этой причине программы-вымогатели и кибербезопасность считаются ключевыми факторами национальной безопасности.
«Черные» хакеры проникают в многочисленные сети правительства и иногда месяцами остаются незамеченными. Преступники взламывают все предприятия и шантажируют любые компании, какие хотят, в том числе занимающие важное место в
цепочках поставок.
И хотя не существует гарантированно успешного плана, компании и организации
могут предпринять шаги по сдерживанию риска, о которых мы поговорим далее.

10.3. Защита конфиденциальности путем устранения
пробелов в управлении доступом
Ни одно обсуждение управления доступом не может быть полным без обсуждения
небезопасных прямых ссылок на объекты (англ.: IDOR — insecure direct object
references). IDOR — это тип уязвимости управления доступом, который возникает,
когда приложение использует обеспеченный пользователем ввод для прямого доступа к объектам.
Давайте сначала выясним, как работает уязвимость IDOR, а затем рассмотрим варианты ее устранения.

392

Часть IV. Безопасность, масштабирование и кадровое обеспечение

10.3.1. Как работает уязвимость IDOR
Прежде чем говорить об уязвимости IDOR, способах ее выявления и устранения,
необходимо определить основные концепции, которые могут быть полезны.
 Если речь идет об IDOR, то под объектом подразумевают данные и/или функ-

ции. Например, как у покупателя в интернет-магазине у меня есть доступ к таким объектам, как моя корзина, но нет доступа к хранящимся на сервере данным
каталога сайта, который продает товары.
 «Вертикальный контроль доступа направлен на контроль ограничений функ-

ций доступа в соответствии с ролями пользователей» (http://mng.bz/W7ax). В
нашем примере с электронной коммерцией я как покупатель могу менять элементы в моей корзине. Изменять элементы в каталоге сайта на сервере, который
доступен всем покупателям, может только администратор.
 «Горизонтальный контроль доступа направлен на контроль ограничений дос-

тупа к ресурсам пользователей с таким же уровнем возможностей» (http://mng.bz/
W7ax). Например, я должен иметь возможность удалять товары из своей корзины, но не из корзины другого пользователя с другой учетной записью.
Проще говоря, уязвимость IDOR «возникает, когда злоумышленник получает прямой доступ, используя предоставленный пользователем ввод в объект, для доступа
к которому не нужна авторизация» (http://mng.bz/W7ax). Это происходит, когда
аутентификация (механизм, позволяющий пользователю войти в систему) недостаточно хорошо связана с авторизацией (механизмом, позволяющим пользователю
получить доступ к объектам системы). Другими словами, в контексте уязвимости
IDOR мой доступ к объектам как пользователя не привязан к моей личности.
Также возможно, что недочеты в реализации авторизации достаточно серьезны,
чтобы злоумышленники могли обойти механизм авторизации и получить доступ к
ресурсам в системе.
В большинстве веб-приложений объект представлен идентификатором (ID). Например, в приложении или на веб-сайте интернет-магазина у меня и у продукта,
который я покупаю, есть идентификаторы. И если их легко угадать или злоумышленник может получить к ним доступ в обход средств контроля — это явные признаки уязвимости IDOR.
Рассмотрим пример, чтобы понять, как работает подобная атака, а затем изучим
стратегии смягчения. На рис. 10.4 показана схема объекта для стороны сервера сайта электронной коммерции. Как видите, объект пользователя имеет атрибуты: ID,
имя и дату создания. Точно так же у объекта заказов будут атрибуты: ID, дата создания, ID пользователя и ID товара. У обоих объектов есть первичные ключи — их
собственные ID, но они также указывают на другие ID. Например, заказ сопоставляется с конкретным идентификатором пользователя, ведь обычно один заказ соответствует одному покупателю. Однако в одном заказе бывает и несколько продуктов, поэтому возможно, что один ID заказа будет соответствовать нескольким ID
товара. Предположим, что два пользователя делают покупки на веб-сайте, и их заказы показаны в таблице 10.1.

Глава 10. Закрытие уязвимостей системы безопасности

393
Таблица 10.1. Два примера заказов

ID пользователя

ID заказа

Товары

1234

A1

Пищевые продукты

5678

B1

Мебель для дома

Рис. 10.4. Взаимоотношения между пользователями, заказами и товарами

Предположим также, что внутренний запрос для отображения заказов выглядит
следующим образом:
http://www.buyproducts.com/order_details?order_id=A1
http://www.buyproducts.com/order_details?order_id=B1

Если внутренняя функция не подтвердит, что пользователь, вошедший в систему,
является тем же пользователем, чей заказ отображается в данный момент, это считается уязвимостью IDOR.
В данном примере ID заказа используется непосредственно как индекс записи в запросах, направляемых к серверной базе данных. При отсутствии других средств контроля злоумышленнику достаточно просто изменить значение ID заказа, минуя средства контроля доступа, чтобы просмотреть записи других клиентов. Это пример уязвимости IDOR, приводящей к повышению горизонтальных привилегий. Если
пользователь может изменить ID заказа и получить информацию об истории покупок
другого пользователя, или если страница со сведениями о заказе содержит имя и адрес пользователя — налицо серьезное нарушение конфиденциальности, из-за которого происходит утечка данных одного пользователя к другому (http://mng.bz/W7ax).

394

Часть IV. Безопасность, масштабирование и кадровое обеспечение

Как написано в блоге PortSwigger, «злоумышленник также может выполнять горизонтальное и вертикальное повышение привилегий, сменив пользователя на другого с дополнительными привилегиями в обход контроля доступа. Также злоумышленник может воспользоваться утечкой паролей или изменить параметры после того, как попадет на страницу учетной записи пользователя» (http://mng.bz/8lJ2).
Уязвимости IDOR могут проявляться и другими способами. Например, они часто
возникают, когда конфиденциальные ресурсы находятся в статических файлах в
файловой системе на стороне сервера. Веб-сайт может сохранять квитанции о покупках пользователей на диск, используя имя файла «с приращением на 1», и разрешить пользователям извлекать их, перейдя по ссылке, скажем:
https://www.buyproducts.com/static/12144.txt

В этой ситуации злоумышленник может просто изменить имя файла, чтобы извлечь
квитанцию другого пользователя и потенциально получить его учетные данные и
другие конфиденциальные сведения.
Чтобы суть данного риска стала понятнее, представьте, что если злоумышленнику
не понравятся публикации в таких газетах, как New York Times или Wall Street
Journal, он может написать скрипт, позволяющий увидеть ID подписчиков, если
эти ID общедоступны или их можно угадать. Затем он может получить учетные
данные подписчиков через Даркнет и приостановить их подписки или, что еще
хуже, отменить.
Учитывая сегодняшнюю гиперполяризованную атмосферу, злоумышленники могут
с помощью приемов кибервойны донести свою позицию. Справедливости ради,
взлом общенациональной газеты, при котором злоумышленники будут обновлять
информацию, чтобы расширить привилегии, а затем вызвать геополитические проблемы, маловероятен. Однако такая опасность может грозить провинциальному
СМИ.

10.3.2. Тестирование на уязвимость IDOR
и смягчение последствий
Не существует простых способов предусмотреть все возможные методы атаки с
помощью уязвимости IDOR, однако есть несколько эффективных методов, рекомендуемых исследователями (http://mng.bz/8lJ2):
 проверьте, что вы способны обнаруживать ситуации, когда пользователь может

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

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

Глава 10. Закрытие уязвимостей системы безопасности

395

 возможно, вы помните, как интуитивно понятные названия сервисов помогли

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

тестирование каждый раз при создании/регистрации новой роли. Будете ли вы
делать это вручную для каждой роли или массово, зависит от зрелости и охвата
вашего инструментария.
Существуют также лучшие практики кодирования, которые можно применить,
прежде всего, во избежание пробелов, создающих уязвимость IDOR
(http://mng.bz/8lJ2, http://mng.bz/NxA2, http://mng.bz/ DxV9):
1. Учитывая, что уязвимость IDOR возникает благодаря комбинациям, модульного
тестирования недостаточно. Обязательны интеграционные тесты, охватывающие
варианты использования IDOR.
2. Тестирование на уязвимость IDOR не ограничивается ролями; на этапе системной инженерии вам понадобятся дополнительные интеграционные тесты для повторной проверки перед развертыванием сервисов.
3. Разработчики не должны отображать ссылки на частные объекты. Цель — свести к минимуму доступность ключей или имен файлов.
4. При любом виде доступа должна подтверждаться подлинность всех параметров
и объектов, на которые даются ссылки.
5. Между пользователями и токенами должна быть тесная связь, и ни токены, ни
сопоставления не должны быть общедоступными.
6. Во время сессии значения данных должны храниться в ней, а не в базе данных,
к которой возможен доступ позже. Учитывая, сколько раз мы видели, что к конфиденциальным данным могут получить доступ злоумышленники, следует предотвратить сохранение, и это, в свою очередь, снизит риск последующих утечек.
7. Когда пользователь отправляет данные, необходимо проверить их подлинность,
но не допускать задержки. Например, если пользователь отправляет номер карточки социального страхования, можно соединить таблицу, в которой хранятся
финансовые данные, с таблицей, хранящей данные учетной записи пользователя. Вы получите средство контроля доступа, обеспечиваемое самими данными,
если только сами данные на сервере не окажутся повреждены.
Эта глава позволит инженерам и другим специалистам в данной области разобраться, как неэффективные средства управления безопасностью могут нанести ущерб
конфиденциальности. Важно понимать, что не существует полного списка слабых
мест в системе безопасности, устранение которых может снизить риски. Комбинации данных могут привести к риску конфиденциальности, но пробелы в системе
безопасности в совокупности тоже на это способны.
Для начала следует ориентироваться на руководство Центра интернет-безопасности
в качестве контрольного списка ресурсов для организаций (http://mng.bz/lapM).

396

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

Резюме
 Компании слишком часто оптимизируют свою работу с целью защиты конфи-

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

пом представляют собой реальные риски для компании, ее данных и доверия
клиентов.
 Модель управления рисками и проактивное управление доступом имеют ре-

шающее значение для компании и ее поставщиков.
 Многие угрозы безопасности (и, следовательно, конфиденциальности) являются

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

- ГЛАВА 11 -

Масштабирование, найм
и рассмотрение правил

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

лирование защиты конфиденциальности.
К этому моменту вы уже знаете, как встроить защиту конфиденциальности в данные, инструменты и процессы бизнес-анализа. В главах 3 и 4 подробно рассматривалось управление данными — с момента их попадания в компанию — путем классификации и каталогизации с помощью автоматизации и метаданных. В главе 5
предлагались масштабируемые методы защиты конфиденциальности при обмене
данными, с учетом того, сколько онлайн-вычислений и транзакций связано с передачей данных.
Кроме того, вы узнали, как масштабировать эти архитектуры и процессы по мере
роста компании. И как практически применить инструменты и процессы защиты
конфиденциальности, ведь компании не могут позволить себе постоянно выкидывать оборудование, программное обеспечение и персонал на решение этих вопросов. Глава 6 направлена на перепрофилирование традиционного процесса проверки
конфиденциальности и смещение акцентов на начальных этапах на совещательный
и консультационный потенциал. При помощи автоматизации компании могут
встроить защиту конфиденциальности в свои функции вместо того, чтобы добавлять ее постфактум.
Учитывая шумиху вокруг соблюдения правовых норм при взаимодействии с клиентами, в главах 7–9 подробно рассматриваются вопросы удаления, экспорта данных
и получения согласия пользователя.
В силу значимости как безопасности, так и конфиденциальности при защите данных, мы также потратили достаточно времени на устранение пробелов в сфере
безопасности, которые могут нанести ущерб защите конфиденциальности. В гла-

398

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

ном топтаться на месте? В этом случае действия по обеспечению конфиденциальности и защите данных останутся реактивными и тактическими.
 Или выбрать иной курс и составить план проектирования защиты конфиденци-

альности, которое не только будет практически применимо, но и оптимизируемо?
Эта глава поможет вам осуществить второе.
Наличие такой зрелой программы имеет несколько преимуществ. Вы сможете грамотно подобрать персонал, расставить приоритеты с учетом данных, а также избежать накопления технического долга. Я рекомендую этот вариант, основываясь на
личном опыте консультирования множества стартапов и венчурных компаний.
Фирмы, не сумевшие разработать собственную программу, часто обнаруживают,
что их планы стремительного взлета заканчиваются резким падением. Дорожные
карты их продуктов замирают и деградируют, а запускать функции становится все
труднее из-за аудитов защиты конфиденциальности и утечек данных. Из единорога
компания превращается в верблюда.
В компаниях, попавших в эту ловушку, специалистам по защите конфиденциальности и менеджерам программ постоянно приходится просить у руководителей финансирование, но у них нет набора инструментов или показателей, чтобы подкрепить свои просьбы. Это обрекает компанию на провал — как в стратегии защиты
конфиденциальности, так и в производительности. В этой главе мы рассмотрим,
как избежать такого финала.
Во-первых, я помогу вам создать модель зрелости возможностей для программы
обеспечения конфиденциальности. Я предложу вам шаблон, который поможет не
только масштабировать ваше предложение, но и:
 сегментировать возможности защиты данных на такие категории, как идентификация, защита, обнаружение и устранение;
 провести анализ пробелов для выявления ключевых аспектов ваших возможностей защиты данных;
 определить уровни возможностей, чтобы отслеживать их эволюцию от базовых
до зрелых и продвинутых.
Такой подход поможет вам количественно оценить свою программу в сопоставлении с моделью угрозы, обязательствами по соблюдению нормативных требований,
обязательствами по отношению к клиентам и дорожными картами развития функций. Без такой модели, основанной на данных, специалисты по конфиденциальности и безопасности всегда будут, в конечном итоге, искать хоть какое-то финансирование и возможности вместо того, чтобы полноценно сотрудничать с компанией
и помогать ей.

Глава 11. Масштабирование, найм и рассмотрение правил

399

Во-вторых, я помогу вам построить кадровую модель, которая обретет важность,
если ваша программа разрастется. Даже если компания не станет увеличивать штат,
вам стоит найти специалистов с соответствующими навыками внутри компании
или привлечь сторонние организации. По аналогии с разработкой программного
обеспечения, для которой нужен опыт работы с интерфейсом, серверной частью,
платформой и инфраструктурой, инженерия конфиденциальности имеет свои собственные области знаний. Мы рассмотрим различные навыки, необходимые для
разработки инструментов и показателей, обсуждавшихся на протяжении всей книги.
В-третьих, мы рассмотрим более крупную экосистему правового регулирования,
влияющую на компании и технический персонал. Инженерам недостаточно в общих чертах разбираться в таких законах, как GDPR. Они должны иметь возможность взаимодействовать с регулирующими органами и другими авторитетными
лицами. Это позволит даже влиять на новые и существующие законы.
Будучи техническим специалистом, я всегда считал, что относиться к инженерам
как к простым исполнителям — неправильно и вредно для бизнеса. Отстранять
технических специалистов по конфиденциальности и безопасности от процесса
нормативно-правового регулирования контрпродуктивно, как и не вовлекать их в
обсуждения продаж. В последнем случае вы получите отток клиентов и неудовлетворенные ожидания, а в первом может оказаться, что законы о защите конфиденциальности не обеспечат клиентам значимые средства защиты и станут ненужным
бременем для бизнеса.
Прежде чем углубиться в подробности, хочу предостеречь вас: эта глава, как и вся
книга, — лишь начало пути. Я предлагаю основы и архитектуры, которые можно
корректировать по своему вкусу. Учитывая масштабы современных технологий и
данных, ни одна книга не сможет предложить простые пошаговые инструкции для
обеспечения зрелости инженерии конфиденциальности на уровне предприятия.
Сначала мы построим модель зрелости для отслеживания эффективности вашей
инженерии конфиденциальности. Чтобы сохранить последовательность и создать
четкую отправную точку, для работы в этой главе я использовал NIST Cybersecurity
Framework (www.nist.gov/cyberframework) и пользовался результатами аудитов/оценок, проведенных крупными фирмами.

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

400

Часть IV. Безопасность, масштабирование и кадровое обеспечение

точки зрения конфиденциальности. Сначала в компании боятся этих сотрудников, а
затем оттесняют в сторону, считая несговорчивыми. Такой подход нежизнеспособен.
Начав внедрять практику защиты данных в компании, вы столкнетесь с препятствиями: недостаточно проработанными процессами, сопротивлением, недостатком
внимания и зачастую с тем, что люди просто ставят прибыль выше защиты конфиденциальности. Чтобы отстоять свои позиции и завоевать союзников, вам нужно
сопротивляться желанию сказать «нет» и найти способ помочь бизнесу сделать так,
чтобы было «Да, но без нарушения доверия пользователей».
Этот подход отлично применим в начале, но он не долговечен. Со временем вам
нужно будет защищать и ограждать ресурсы, а также создавать объективные критерии успеха.
Данный раздел поможет вам построить основу, которая послужит в качестве модели зрелости для вашей работы по защите конфиденциальности.
В процессе построения модели зрелости для защиты конфиденциальности мы рассмотрим четыре ключевых аспекта. Для каждого из них изучим оценки и действия,
которые помогут измерить эффективность. Далее мы рассмотрим каждый аспект
подробнее.
 Идентификация — здесь вы оцениваете риски конфиденциальности, связанные

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

стей защиты данных благодаря проверке указанных ниже аспектов:
 Можете ли вы защитить данные в динамике между конечными точками и в
состоянии покоя в нескольких местах хранения?
 Проводите ли вы сканирование уязвимостей и динамическое тестирование,
чтобы устранить пробелы?
 Построен ли ваш метод управления доступом к активам, данным и системам
таким образом, чтобы учитывать риски и обеспечивать готовность к проверке?
 Обнаружение — поскольку не каждый риск можно заблаговременно идентифи-

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

Глава 11. Масштабирование, найм и рассмотрение правил

401

 Смягчение последствий — даже самая зрелая инженерная программа защиты

конфиденциальности может быть не в состоянии предотвратить все риски и
ущерб. Поэтому крайне важно проверять способности вашей программы в следующих областях:
 Предлагает ли ваша программа возможности отказоустойчивости и непрерывности работы бизнеса при устранении ущерба конфиденциальности?
 Заключают ли ваши специалисты по реагированию на инциденты соглашения
о гарантированном уровне обслуживания?
 Имеется ли информационная панель, которая отслеживает входящие инциденты, статус соглашения о гарантированном уровне обслуживания и шаблоны?
Этот список — всего лишь контур, вокруг которого может строить свою основу
растущая и развивающаяся организация.
Теперь мы подробно рассмотрим каждый аспект и оценим готовность вашей программы. Однако сначала стоит задать уровни готовности: например, от базового к
зрелому, а затем к продвинутому. Тогда при проведении анализа недочетов в компании вы сможете использовать эти уровни как ступеньки и цели.
У этих уровней нет общепринятого определения, поэтому мы дадим его сами:
 базовый — программа обладает основными возможностями, но их еще требует-

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

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

практикам, но и совершенствуется, демонстрируя другим компаниям, как можно
развиваться и расти.

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

402

Часть IV. Безопасность, масштабирование и кадровое обеспечение

лости и спланировать эволюцию компании в соответствии с ними. Теперь изучим
эти процессы по очереди.

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

Зрелый уровень

Продвинутый уровень

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

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

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

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

Глава 11. Масштабирование, найм и рассмотрение правил

403
Таблица 11.1 (окончание)

Базовый уровень

Зрелый уровень

Продвинутый уровень

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

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

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

KPI отслеживаются путем
объединения связанных отделов или относящихся к одному и тому же направлению
деятельности.

KPI отслеживаются и проверяются снизу вверх по всей
организации.

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

К табл. 11.1 и далее применимы следующие два пункта:
 каждое предложение становится более зрелым по мере продвижения слева на-

право. Например, область действия (строка 1) в столбце «Зрелый уровень» требует расставлять приоритеты при каталогизации активов, а не просто отслеживать их время от времени, как компании, скорее всего, поступают на «Базовом
уровне» при относительной незрелости;
 кроме того, каждая запись предполагает, что работа в поле слева от нее уже вы-

полнена.

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

404

Часть IV. Безопасность, масштабирование и кадровое обеспечение
Таблица 11.2. Эволюция зрелости системы управления

Базовый уровень

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 11. Масштабирование, найм и рассмотрение правил

405

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

Зрелый уровень

Продвинутый уровень

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

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

Руководители компании качественно и количественно оценивают риск и варианты восстановления (на основе KPI и
сопоставления с допустимым
уровнем риска) как элементы
разработки стратегии конфиденциальности.

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

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

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

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

406

Часть IV. Безопасность, масштабирование и кадровое обеспечение
Таблица 11.3 (окончание)

Базовый уровень

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

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

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

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

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

Глава 11. Масштабирование, найм и рассмотрение правил

407

Таблица 11.4. Эволюция зрелости системы управления идентификацией и доступом
Базовый уровень

Зрелый уровень

Продвинутый уровень

В соответствии с установкой
на развитие ИТадминистраторы могут предоставить учетные данные
для доступа сотрудникам,
партнерам и пр. Потенциальный охват их аудиторским
проверками является частью
элементарной системы контроля доступа.

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

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

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

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

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

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

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

408

Часть IV. Безопасность, масштабирование и кадровое обеспечение
Таблица 11.4 (окончание)

Базовый уровень

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

Зрелый уровень

Продвинутый уровень

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

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

С течением времени и с усилением контроля соглашения
об уровне обслуживания для
устранения уязвимостей становятся более жесткими.

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

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

Глава 11. Масштабирование, найм и рассмотрение правил

409
Таблица 11.5 (окончание)

Базовый уровень

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

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

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

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

Векторы риска постоянно
обновляются автоматически
в соответствии с внутренними
и внешними изменениями
в бизнесе. Это понимание
затем применяется в реализации сканирования на уязвимости.

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

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

410

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

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

Глава 11. Масштабирование, найм и рассмотрение правил

411
Таблица 11.6 (окончание)

Базовый уровень

Зрелый уровень

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

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

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

Зрелый уровень

Продвинутый уровень

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

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

Данные разного уровня конфиденциальности часто обрабатываются в облаке, и эти
данные нередко неструктурированные.

412

Часть IV. Безопасность, масштабирование и кадровое обеспечение
Таблица 11.7 (окончание)

Базовый уровень

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

Глава 11. Масштабирование, найм и рассмотрение правил

413

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

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

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

414

Часть IV. Безопасность, масштабирование и кадровое обеспечение
Таблица 11.8 (окончание)

Базовый уровень

Зрелый уровень

Продвинутый уровень

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

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

Глава 11. Масштабирование, найм и рассмотрение правил

415

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

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

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

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

416

Часть IV. Безопасность, масштабирование и кадровое обеспечение
Таблица 11.9 (окончание)

Базовый уровень

Зрелый уровень

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

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

Продвинутый уровень

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

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

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

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

Глава 11. Масштабирование, найм и рассмотрение правил

417
Таблица 11.10 (окончание)

Базовый уровень

Зрелый уровень

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

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

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

Продвинутый уровень

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

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

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

Зрелый уровень

Продвинутый уровень

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

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

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

418

Часть IV. Безопасность, масштабирование и кадровое обеспечение
Таблица 11.11 (окончание)

Базовый уровень

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

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

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

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

Глава 11. Масштабирование, найм и рассмотрение правил

419

11.1.4. Смягчение последствий
Даже если компании сделают все возможное и невозможное, нарушения конфиденциальности все равно будут происходить. Они могут варьироваться от непреднамеренного занесения в журнал или доступа к конфиденциальным данным до неполного удаления и эксфильтрации. Для них потребуется функция управления реагированием на инциденты, которую невозможно разработать «на ходу». Такой ресурс
(или команда) должен действовать кроссфункционально и быстро. Это сложная
задача для небольших и растущих компаний, ведь для повышения скорости работы
их структура сильно сегментирована. В табл. 11.12 представлен определенный контекст, показывающий, каким образом масштабировать этот аспект для завершения
процесса защиты данных.

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

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

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

420

Часть IV. Безопасность, масштабирование и кадровое обеспечение
Таблица 11.12 (окончание)

Базовый уровень

Приоритетность инцидентов
определяется степенью их
«громкости».

Зрелый уровень

Продвинутый уровень

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

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

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

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

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

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

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

Глава 11. Масштабирование, найм и рассмотрение правил

421

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

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

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

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

422

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

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

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

Аналитики данных
Аналитики данных имеют глубокие знания в области математики и осуществления
запросов данных. Они помогают составить руководство, основанное на данных;

Глава 11. Масштабирование, найм и рассмотрение правил

423

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

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

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

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

424

Часть IV. Безопасность, масштабирование и кадровое обеспечение

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

11.3. Защита конфиденциальности
и нормативно-правовой климат
Я давно убежден, что нормативно-правовое регулирование зависит от настроений
населения. Не случайно законы вроде GDPR и CCPA появились в тот момент, когда
возросло недовольство технологическим сектором. И так же не случайно институциональное недоверие правительствам и бизнесу привело к появлению популистских движений во всем мире.
Какое отношение это имеет к инженерам, чье главное стремление — создавать
продукты и решать проблемы? Инженеры слишком долго были вынуждены подчиняться тем, кто принимает решения. Во времена нисходящей иерархии они находились в подчинении у тех, кто управлял продуктами и продажами, и часто являлись
лишь «почетными» исполнителями заказов. Сегодня, на этапе более гибкого и восходящего развития, они оказываются в стороне от регулирования защиты конфиденциальности, которое пересматривает решения, принятые в существенно отличавшихся условиях.
Эта книга призвана частично решить эту проблему. Она поможет инженерам внедрить модель «встроенной» защиты конфиденциальности вместо «наспех прикрученной». В первом случае защита конфиденциальности встраивается в проект, процесс и архитектуру компании. Во втором, напротив, ею пытаются закрыть пробелы
по мере их появления, а потолком является сдерживание распространения проблемы. Однако инженерам необходимо искать союзников за пределами компании в
лице влиятельных игроков в отрасли, обозревателей в области защиты конфиденциальности, СМИ и прочих, чтобы убедиться, что нормативно-правовые основы
защиты конфиденциальности принимаются всерьез.

Глава 11. Масштабирование, найм и рассмотрение правил

425

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

использование данных;
 предоставление клиентам и пользователям значимой защиты;
 создание количественно измеримых ожиданий, которые компании могут удов-

летворить.
Хочу привести два макрополитических примера, чтобы пояснить, почему и без того
трудная работа инженера в области защиты конфиденциальности станет еще труднее. В 2006 году тогдашний председатель комитета по торговле Сената США, сенатор Тед Стивенс высказал свои мысли по поводу сетевого нейтралитета. Вот фрагмент его речи:
Сейчас существует одна компания, в которой можно зарегистрироваться и получать фильмы с доставкой на дом. Каждый день. Через службу доставки [...] Теперь эта услуга будет осуществляться через Интернет. И теперь вы идете, заказываете фильм, и знаете что? Можно заказать доставку сразу десяти, и доставка будет бесплатной, верно?
Десять фильмов транслируются через Интернет. А что будет с вашим личным
Интернетом? Буквально на днях мои сотрудники отправили мне [письмо по сети]
Интернет в 10 часов утра в пятницу, а я получил его вчера. Почему? Потому что
оно запуталось во всей этой коммерческой ерунде, наводнившей Интернет.
И здесь у нас ситуация, когда огромные организации хотят использовать Интернет для своих нужд, чтобы сэкономить деньги, занимаясь тем же, что они делают сейчас. Они используют FedEx, они используют службу доставки, они используют почту. Они осуществляют доставку другими способами, но они хотят доставлять огромные объемы информации через Интернет.
И опять же, Интернет — это не место, куда можно просто вывалить что угодно. Это не большой грузовик. Это куча трубок. И неужели вам непонятно, эти
трубки могут заполниться, и если они заполнены, когда вы отправляете свое сообщение, оно попадает в очередь, его задерживают те, кто выгружает в эти
трубки огромное количество материала (http://mng.bz/BxDg).
Сенатор Стивенс, по всей вероятности, говорил про будущую бизнес-модель
Netflix. Высказывания сенатора уже много лет высмеивают в Интернете из-за содержащихся в них ошибок. Например:
 понятия «письмо» и «Интернет» у него используются как взаимозаменяемые;
 не было доказательств того, что потоковое видео привело к задержке электрон-

ной почты в данном конкретном случае.
Тем не менее в отчете канадской компании Sandvine, специализирующейся на сетевом оборудовании, говорится, что компания Netflix в одиночку генерирует в часы
пик более трети всего трафика североамериканского Интернета (http://mng.bz/doPX).
Заявление сенатора и результаты исследования компании Sandvine разделяет почти

426

Часть IV. Безопасность, масштабирование и кадровое обеспечение

целое десятилетие, но были и другие примеры, свидетельствующие о том, что даже
хотя технологическая индустрия оказывает влияние на мир на невиданном ранее
уровне, политические лидеры не стали мыслить мудрее и прогрессивнее.
Это создает серьезную проблему для инженеров и технологической отрасли. Сторонники навязываемого нормативно-правового регулирования, многие из которых
находятся в правительстве, не обладают глубоким знанием технических деталей в
подкрепление к своему пониманию онлайн-торговли.
От инженеров постоянно ожидают, что они будут писать код, поставлять продукты
и не нарушат эти сложные законы. Отсутствие связи между регулирующим аппаратом в правительстве и производящим аппаратом в промышленности вредит тем самым потребителям, которых законы призваны защищать.
Наверное, вам интересно, изменилась ли ситуация за 15 лет, прошедших после речи
Стивенса. В начале 2018 года, когда в Сенате США проходили слушания по делу
компании Cambridge Analytica, генеральный директор корпорации Facebook (ныне
Meta Platforms Inc., признана экстремистской организацией на территории РФ)
Марк Цукерберг вступил в перепалку с тогдашним сенатором Оррином Хэтчем.
Сенатор Хэтч спросил Цукерберга, по-прежнему ли Facebook привержена идее
предоставления своих услуг бесплатно. Ниже приводится стенограмма их диалога
(http://mng.bz/raBZ):
ЦУКЕРБЕРГ: Сенатор, да. Всегда будет существовать бесплатная версия
Facebook. Это наша миссия — попытаться помочь соединить всех людей во всем
мире и сделать мир ближе.
Для этого, мы считаем, следует предлагать услугу, которую может позволить
себе каждый, и мы стремимся к этому.
ХЭТЧ: Ну, если так, то как вы поддерживаете бизнес-модель, в которой пользователи не платят за ваши сервисы?
ЦУКЕРБЕРГ: Сенатор, мы запускаем рекламу.
ХЭТЧ: Понятно. Замечательно.
Тот факт, что один из самых опытных действующих сенаторов не изучил информацию о бизнес-модели Facebook до начала телевизионного слушания, вызвало замешательство. Видео этого диалога повеселило многих инженеров из-за отсутствия у
политиков технических знаний (http://mng.bz/VlqO). Часто на интернет-форумах
технические специалисты используют это видео как пример своего превосходства
над теми, кто гораздо менее подкован в технических вопросах.
Моя реакция прямо противоположная. Если кто-то, обладающий большей властью,
чем вы, знает меньше вас о критически важной области, эту проблему придется
решать вам. Больше нельзя считать функциональную точность, вовлеченность и
принятие единственными показателями успеха.
И если данные — топливо для информационной супермагистрали, то регулирующие органы — указатели ограничения скорости и объезда. Незнание регуляторами
технической стороны может привести к принятию бесполезных законов, подавляющих инновации, вредящих конкуренции и не защищающих потребителей.

Глава 11. Масштабирование, найм и рассмотрение правил

427

Я не могу закончить, не рассказав еще один случай из личного опыта. Однажды я
принимал участие в дискуссии. Нас было четверо: двое экспертов в области кибербезопасности (я и мой коллега) и два консультанта правительства по вопросам законодательства о конфиденциальности. Обсуждение было в основном закрытым,
но в его части, открытой для общественности, произошел следующий диалог:
ГОСУДАРСТВЕННЫЙ ЭКСПЕРТ: Нам нужно больше законов о защите конфиденциальности, потому что технологическая индустрия вышла из-под контроля.
БХАДЖАРИЯ: Ну, у нас уже есть два широко применяемых закона, которые
можно развивать дальше. Не лучше ли изучить их эффективность и использовать
в качестве основы? Так мы будем уверены, что законы обеспечивают надежную
защиту пользователей.
ГОСУДАРСТВЕННЫЙ ЭКСПЕРТ: В промышленности не так много добросовестных компаний, с которыми можно сотрудничать, и, кроме того, почему бы не ввести 50 законов о конфиденциальности в 50 штатах? Сливки собирают сверху. Так
мы получим суперкомплект защит.
Я вспоминаю этот диалог каждый раз, когда выступаю за расстановку приоритетов
в бюджетах и проектах по защите конфиденциальности. Хуже низкой технической
компетентности государственных регуляторов в области защиты конфиденциальности может быть только их желание регулировать компании, монетизирующие
данные пользователей.
Эта книга поможет техническим специалистам и компаниям сделать проектирование конфиденциальности частью бизнеса. Это очень важно, поскольку у развивающихся и растущих компаний есть всего два варианта. Первый — они могут продолжать работать как обычно и отдать свое будущее в руки тем, кто постепенно
задавит их нормами и требованиями. В отличие от крупных технологических гигантов, новым компаниям не хватит ресурсов, чтобы справиться с карательными
законами.
Однако они могут выбрать второй вариант. В этой книге описаны инженерные инструменты, которые компании смогут создать для обеспечения конфиденциальности, но не менее важно активнее вовлекать инженеров в процесс обучения и влияния. Будущее защиты данных будет зависеть от здорового соперничества и сотрудничества между инновациями и регулированием. Они должны дополнять, а не
отменять друг друга. Это станет темой моих будущих начинаний и книг.
В заключение хочу дать совет. Я надеюсь, что инженеры и другие технические
специалисты, являющиеся основной аудиторией этой книги, будут активно использовать ее в качестве отправной точки. Воспользуйтесь ею как основой для внедрения технологии защиты конфиденциальности в продукты, инструменты и процессы. Теперь у вас есть базовый уровень, который можно адаптировать под ваши технические внедрения.
Мне также хотелось бы обратиться к руководителям компаний, которые часто оторваны от рабочего процесса и удивляются неоптимальным результатам защиты
конфиденциальности. Вы можете не понимать всех деталей, однако эта книга при-

428

Часть IV. Безопасность, масштабирование и кадровое обеспечение

звана показать не только риски и масштабы, связанные с защитой конфиденциальности, но также эффективность и преимущества. Ее цель — помочь вам как руководителю и человеку, принимающему решения, определить приоритеты и обеспечить зрелость бизнеса.
Наконец, представители СМИ и регулирующих органов в последнее время уделяют
все больше внимания вопросам защиты конфиденциальности.
Эта книга должна помочь вам понять сложности и взаимозависимости в сфере инженерии конфиденциальности. СМИ часто выступают в роли термометров, поскольку их освещение подсказывает, насколько хорошо или плохо идут дела. Регуляторы действуют как термостаты, повышая или понижая температуру в зависимости от воздействия и настроения людей. Часто события разворачиваются быстро
среди шквала новостей без соответствующего контекста, и эта книга предназначена
исправить ситуацию. Она также будет полезна техническим журналистам, законодателям и регуляторам, и поможет им более грамотно выполнять свои обязанности.
Какими бы ни были ваш опыт и взгляды относительно данной книги, спасибо, что
прошли со мной этот путь. Надеюсь, мы увидим будущее, в котором защита конфиденциальности будет все больше и больше встраиваться во все, что мы делаем
(проектироваться!), на благо пользователей и, в свою очередь, предприятий, которые докажут, что для них важны интересы пользователей. Удачи!

Резюме
 Компаниям нужно постепенно и постоянно совершенствовать свои системы и

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

ний есть несколько аспектов и вариантов выбора для отслеживания зрелости
программы.
 Компании также должны ориентироваться в многообразии навыков в области

разработки защиты конфиденциальности, все они имеют разный уровень значимости.
 Разрыв и дисбаланс знаний в технологической индустрии и регулирующих ор-

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

Предметный указатель

A
API, 32
AWS, 361

B
B2C, 55
BigID, 57

C
Cambridge Analytica, 207
CCPA, 52
CDN, 60
CMP, 312, 318

D
DevOps, 119
DPIA, 217
DSAR, 58, 277, 279
 автоматизация, 291
 выполнение, 283
 журнал контроля, 292
 информационная панель, 300
 настройка, 285
 параллелепипед, 290
 состояния, 288
 требования, 281
 шаблон, 290, 295
DSP, 174

E
EC2, 361
ETL, 71, 261

I
IAPP, 30, 219
IDFA, 316
IDOR, 391
ISO 27001, 44

K
Kappa-архитектура, 264
KMS, 71
K-анонимность, 201

L
LGPD, 215
L-разнообразие, 205

M
MongoDB, 376
MVP, 323

O
OneTrust, 58
OpenID Connect, 379
OPM, 80

P
Pass-the-Hash, 372
PIA, 216

S, T, U
G, H
GDPR, 34, 83
HDFS, 291

SSP, 174
Thrift, 330
UUID, 155

430

А
Авторизация, 118
Анонимизация, 191
Архивирование, 71
Архитектура сбора данных, 253
Аутентификация, 118

Предметный указатель

Коллективное знание, 143
Конвейер данных, 291
Контекстный доступ, 368
Конфиденциальность данных, 30, 31

Л
Локаль, 321

Б
Балансировщик нагрузки, 253

В
Вертикальный контроль доступа, 392

Г
Горизонтальный контроль доступа, 392
Граф персоналий, 178

Д
Данные
 архивные, 190
 оперативные, 190
Документы о разглашении данных, 321

З
Задачи защиты конфиденциальности, 68
Закон Калифорнии о защите персональных
данных потребителей, см. CCPA
Запрос о предложении, 176
Запрос субъекта на доступ к персональным
данным, см. DSAR
Защита инфраструктуры, 412

И
Избыточность, 255
Инженерно-технические требования, 234
Инсайдерская угроза, 417
Информация, идентифицирующая
личность, 121
ИТ-безопасность, 29

К
Классификация данных, 31, 101, 102, 104
Ключевые показатели эффективности, 161

М
Маскировка данных, 70
Машинное обучение, 241
Международная ассоциация профессионалов
в области конфиденциальности, см. IAPP
Местоположение сервиса, 362
Метаданные, 154
Метка, 138
Модель зрелости, 400
Модель нулевого доверия, 360
Модель обнаружения, 415
Модель технологической зрелости
организации, 113

Н
Незаконный посредник, 384
Неструктурированные данные, 111

О
Обфускация данных, 31
Общий закон по защите данных Бразилии,
см. LGPD
Общий регламент по защите данных, см.
GDPR
Озеро данных, 256
Отслеживание, 316
Оценка воздействия на защиту данных, см.
DPIA
Оценка воздействия на конфиденциальность,
см. PIA

П
Поверхность атаки, 354, 355
Политика удаления и хранения, 252
Проверка защиты конфиденциальности, 214,
215
 техническая, 226
 юридическая, 223

Предметный указатель

Программа защиты конфиденциальности, 94
Продукт с минимально необходимым
функционалом, см. MVP
Проектируемая конфиденциальность, 230
Псевдонимизация, 197

Р
Распределенная архитектура, 279
Ролевое управление доступом, 119

С
Сегментация данных, 107
Сегментация сервисов, 364
Система управления ключами, см. KMS
Совместное использование данных, 172
Согласие, 313
 внедрение управления согласием, 342
 платформа управления согласием, 312
 управление согласием, 312
Соответствие нормативно-правовым
требованиям, 421
Стандарт ISO 9001, 113
Структурированные данные, 111, 145

Т
Таблица сопоставления, 200
Техслэш, 100

431

«Термометр и термостат», 360
Токенизация, 271

У
Удаление данных, 31, 251
 немедленное удаление, 70
 планировщик удаления данных, 269
 cервис удаления, 267
 удаление неактивного пользователя, 70
 удаление учетной записи, 262
Универсальный уникальный идентификатор,
см. UUID
Уникальный идентификатор для
рекламодателей, см. IDFA
Управление активами, 402
Управление рисками, 405
Учет данных, 31, 135, 138
 служба учета данных, 151
Ущерб конфиденциальности, 28

Х
Хеширование, 180
Хранилище данных, 256

Ш
Шифрование, 185
 Двустороннее шифрование, 200
 Шифрование на стороне клиента, 186