Раскрытие информации облачным системам или этими системами
Многие люди думают об облаке как об «инфраструктуре как услуге» (IaaS) или «программном обеспечении как услуге» (SaaS). Не вполне в рамках этого определения, но также необходимо обсудить различные и многообразные наборы веб-инструментов, например внешние аналитические сервисы, которые, по своей сути, являются раскрытием информации аналитической системе. Они часто собирают большое количество деталей, включая полные URL-адреса, которые могут содержать секреты. В целом проектирование позволяет раскрывать информацию гораздо шире, чем библиотеки аналитики: она доступна для всего используемого вами кода. На самом деле, это еще не все, что доступно, но раскрытие информации может быть очень тонкой атакой. Если библиотека подделывает ваши данные, веб-сайт или приложение, вы, скорее всего, заметите это.
Эти атаки с использованием включенного кода, конечно, не ограничиваются средой Web. Большая часть современных разработок включает в себя использование произвольных библиотек, каждая из которых может украсть ваши данные.
Также в мире современной разработки существуют облачные инструменты разработки. Многие из них, намеренно или случайно, получают информацию, которую вы хотите сохранить в тайне. GitHub поддерживает частные репозитории, и кажется разумным предположить, что по крайней мере некоторые из них случайно оказались более открытыми, чем планировали их владельцы.
URL-адреса
Существует две угрозы раскрытия информации, связанные с URL-адресами. Во-первых, это прямое раскрытие информации, когда кто-то делится ссылкой или когда ссылка обрабатывается прокси-сервером, кэшем или аналитическим программным обеспечением. Информация, содержащаяся в такой ссылке (&username=darth&password=youweremyfriend), раскрывается напрямую (текст ссылки: «Ты был моим другом!»). Любой, у кого есть URL-адрес, может просто нажать на него. Если пароль не будет заменен, пользователь может попытаться войти в систему как darth на любом сайте. Замена всех потенциально конфиденциальных данных токенами снижает оба риска.
Вторая угроза заключается в том, что URL-адрес используется как своего рода «способность» (capability), заменяя проверки контроля доступа предположением, что любой, у кого есть URL-адрес, авторизован для доступа к данным, на которые он ссылается.
Возможно, вы захотите сохранить в тайне один или несколько наборов обучающих данных, источники данных, модели или их анализ.
Злоумышленник, который может прочитать ваши обучающие данные, может воспроизвести ваш ИИ или найти недостатки, о которых вы не знаете. Обученная модель намного меньше по размеру и может быть гораздо более ценной. Она также подвержена раскрытию злоумышленниками.
Все глубокие нейронные сети неизбежно запоминают информацию, и чем лучше они оптимизированы, тем больше им нужно запоминать. Поэтому, к сожалению, если вы помещаете свою систему машинного обучения в убежище с очень конфиденциальными данными, а затем выносите модель из него, вы забираете часть этих конфиденциальных данных вместе с моделью [Feldman, 2021].
В 2019 году институт OpenAI создал очень грамотный инструмент генерации текста – GPT-3. Правда, были опасения, что раздача полной модели может привести к злоупотреблениям ею, и выпускали ее поэтапно. Они следовали той же схеме для своего генератора изображений, DALL-E.
Информация в блокчейне является публичной по своей природе, как и метаданные о транзакциях. Выставление хэша непубличной информации позволяет использовать свойства невозможности отказа, не раскрывая информацию, которая была хэширована. Если система не была специально разработана для предотвращения этого, транзакции можно связать: вы можете сказать, что один и тот же кошелек выполнял транзакции 1234 и 2345 благодаря метаданным о кошельке. Поскольку транзакции можно связать, если какая-либо из них отслеживается (а именно, кто-то может связать их с человеком), то все эти транзакции отслеживаемы. Таким образом, Оби-Ван Кеноби, вероятно, должен получить новый кошелек, когда он поселится на Татуине и исчезнет.
Отслеживание и использование раскрытой информации лежит в основе многих вопросов приватности. Информация может быть раскрыта субъектом или другими лицами. Она может быть получена в виде выводов. Многие люди чувствуют себя некомфортно, будучи объектом пристального внимания или осуждения; некоторые ученые, занимающиеся вопросами неприкосновенности частной жизни, утверждают, что государственная политика должна быть сосредоточена на снижении вреда. Многие крупные нарушения безопасности раскрываются из-за законов, требующих, чтобы хранитель данных перестал отслеживать собранные им персональные данные. Полное рассмотрение вопроса о неприкосновенности частной жизни выходит за рамки этой книги.
Защита
Защита от разглашения информации зависит от того, можете ли вы рассчитывать на помощь операционной системы, разрабатываете ли вы собственную программу или взаимодействуете по сети. Если вы можете использовать операционную систему для защиты данных в состоянии покоя, разрешения – это полезная отправная точка. Даже если у вас есть такая возможность, вы можете захотеть использовать криптографию, и вам нужно будет делать это во время коммуникации. При написании программного обеспечения необходимо учитывать метаданные и утечку данных через них.
Новички в сфере безопасности часто хотят использовать неясность в качестве защиты, и это нормально, если то, что остается неясным, тоже защищено. Например, основные поисковые системы будут уважать файл /robots.txt веб-сайта, сообщающий им, что именно не следует индексировать. Любопытные злоумышленники также уважают этот файл, но как отличную дорожную карту к хорошему материалу. Предсказуемость тоже играет свою роль. Было, по крайней мере, одно судебное преследование того, кто спрогнозировал URL-адрес отчета о доходах компании и смог получить к нему ранний доступ. Детали судебного дела не имеют значения для наших целей – важно то, что защита полагалась на неясность, и это не сработало. Гораздо лучше полагаться на что-то более сильное, к этой теме мы вернемся в главе 7.
В оставшейся части этого раздела исследуются средства защиты, связанные с операционными системами, процессами и криптографией.
Одна из ключевых задач операционной системы – быть посредником между процессами и управлять тем, кто и к какому ресурсу может получить доступ. Разрешения являются основным инструментом для этого. Операционная система также создает, отслеживает и управляет метаданными, и вам может потребоваться изменить свое поведение или код, чтобы контролировать, какие метаданные и кому доступны. Современные операционные системы также включают в себя функции поиска, которые вам, возможно, придется учитывать, если вы создаете такой сервис или, что более вероятно, если метаданные являются проблемой.
Разрешения (и ACL)
Как обращаться с разрешениями, зависит от того, с чем вы работаете. Unix и Windows имеют две совершенно разные модели управления доступом. Одна из них очень простая, другая довольно сложная, и, как стало ясно со временем, можно сказать, что ни одна из них не является «правильной».
Механизм Unix заключается в том, что файлы имеют набор независимых разрешений (чтение, запись и выполнение), которые могут быть установлены для пользователя, группы или «другого», то есть для всех пользователей этой системы. Разрешения хранятся в четырех октетах, причем четвертый используется для специальных разрешений: setuid, setgid и sticky bit (бит закрепления в памяти). Когда закрепленный бит установлен в каталоге, удаление ограничено; так, общие каталоги могут быть в некоторой степени защищены от удаления пользователем чужих файлов (и, возможно, их подмены).
Механизм Windows представляет собой список управления доступом (ACL). В списке есть несколько записей, и они оцениваются последовательно. Дарт Вейдер получает доступ на чтение и выполнение ко всем объектам. Принцесса Лея отказывает в доступе на чтение всем членам имперской группы. Какое правило имеет приоритет? Честно говоря, я не помню, и, если даже мне придется проконсультироваться с экспертом, чтобы это понять, большинство разработчиков и пользователей сделают все правильно, только если им повезет [Microsoft, 2021].
Настройка разрешений или списков ACL быстро усложняется. Назначение прав некоторым группам Unix не особенно выразительно, а более эффектная модель Windows настолько запутанна, что мой коллега защитил докторскую диссертацию, исследуя то, как она ломается [Reeder, 2008]. Уважаемый эксперт по безопасности Дэн Гир (Dan Geer) убедительно доказал, что открытость, в том числе признание сбоев, обходится дешевле, чем тщательная настройка разрешений [Udell, 2004]. Наконец, при устранении неполадок легко установить слишком либеральные разрешения, а чтобы заметить, что разрешения установлены широко открытыми, требуется усердие. Как только «у меня заработало», кто полезет узнавать, кто еще может получить доступ к данным?
Проектирование систем контроля доступа является особой дочерней дисциплиной компьютерной безопасности. Она очень быстро усложняется, когда вы имеете дело с расстановкой приоритетов для правил и тем, как работать с группами. Например, что делать, если какой-то аккаунт принадлежит группам с противоречивыми правилами? Эта сложность при проектировании выходит далеко за рамки того, что нужно знать каждому инженеру – просто знайте, что это не то, к чему можно отнестись легкомысленно.
При получении разрешений для онлайн-сервиса возникают две дополнительные проблемы: совместимость и удобство использования. Если сегодня я установлю разрешения на чтение группе «редакторы», что произойдет с этими разрешениями, когда сервис заменит группы командами или выделит «комментарии» как конкретную вещь, которая может быть разрешена или запрещена? Должны ли редакторы иметь эту новую возможность комментирования? Аналогичным образом такой сервис, как Facebook, который регулярно добавляет разрешения, в итоге придет к сложному разрастанию. Они неизбежно столкнутся с такого рода проблемами при рефакторинге, что приведет либо к повышению удобства использования, либо к разочарованию людей, либо к тому и другому. (У Google есть рекомендуемый поиск «почему мои настройки конфиденциальности на Facebook* постоянно меняются» [Cassidy, 2022; Coldewey, 2021].) Вы, вероятно, не захотите в этом подражать Facebook*.