Конфиденциальность пользователей

Статья
02/02/2007

Мэри Киртланд

Microsoft Corporation

14 февраля 2001 г.

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

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

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

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

Конфиденциальность определена

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

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

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

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

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

Справедливая информационная практика

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

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

Практики и избранное справедливой информации

Все это звучало разумно в теории, но нам по-прежнему было не совсем ясно, как это относится к нашей веб-службе и как вы будете реализовывать все эти элементы для веб-служб в целом. Поэтому я провел несколько часов, обсуждая эти вопросы с членом группы корпоративной политики. Мы начали со списком сценариев, которые служба "Избранное" потенциально может включить (на основе нашей первоначальной концепции):

Пользователь устанавливает надстройку в интернет-Обозреватель, которая предоставляет набор параметров меню, таких как Интернет Обозреватель избранное, за исключением того, что избранное на самом деле хранится в coldrooster.com. (Если вы читаете последний столбец, вы знаете, что мы определили бизнес-сценарий вокруг консалтинговой фирмы. Теперь мы можем показать, что имя этой вымышленной консалтинговой фирмы — Cold Петух Консалтинг, в честь петуха, который висит вокруг нашего здания в кампусе Майкрософт. Поэтому coldrooster.com.)
Coldrooster.com предоставляет веб-приложение, которое позволяет пользователям управлять избранными.
Веб-сайт, скажем, msdn.microsoft.com, предоставляет кнопку на каждой из своих страниц, которую пользователь может щелкнуть, чтобы добавить страницу в избранное пользователя, хранящееся на coldrooster.com.
Msdn.microsoft.com предоставляет веб-страницу, на которой отображаются избранное пользователя, которые изначально хранились msdn.microsoft.com от имени пользователя.
Msdn.microsoft.com предоставляет веб-приложение, которое позволяет пользователю управлять избранными, которые изначально хранились msdn.microsoft.com от имени пользователя.
Cold Rooster Consulting периодически принимает все сохраненные избранное, лишает любой информации, которая связывает их с конкретным пользователем, и помещает их в отдельную базу данных для анализа.
Msdn.microsoft.com предоставляет веб-страницу, которая отображает все избранное, хранящиеся у пользователя, независимо от веб-сайта, на котором изначально хранилось избранное от имени пользователя.
Msdn.microsoft.com предоставляет веб-приложение, которое позволяет пользователям управлять всеми избранными.
Cold Rooster Consulting предоставляет отдельную веб-службу, которую msdn.microsoft.com может лицензировать. Эта служба позволяет пользователям получать такие сведения, как "избранное" или "люди, которые сохранили эту страницу, также сохранили эти страницы", но только для msdn.microsoft.com домена.
Cold Rooster Consulting предоставляет веб-службу, описанную в сценарии 9, за исключением того, что рекомендации, возвращаемые в msdn.microsoft.com, могут включать избранное из других доменов.

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

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

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

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

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

Наш эксперт по конфиденциальности не имеет никаких проблем с сценариями 1–5. Типичная политика конфиденциальности будет охватывать эти сценарии. Однако для сценария 2 необходимо рассмотреть вопрос о том, должна ли coldrooster.com иметь возможность управлять всеми избранными пользователями, независимо от того, какое приложение хранит избранное для пользователя, или только избранное, добавленное приложениями Cold Rooster Consulting. Мы, вероятно, сбой на стороне осторожности и скажем, что приложения Cold Rooster Consulting могут управлять только избранное пользователей, добавленных через эти приложения, если пользователь явно не указал, что приложения могут использоваться для просмотра или редактирования всех избранного, хранящихся от имени пользователя.

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

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

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

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

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

На основе этого анализа сценариев мы решили отступить и переосмыслить представление о первоначальной доставке службы избранного. Новое видение первого этапа фокусируется на сценариях 3–5 выше. По сути, каждое приложение имеет собственный частный магазин для избранного пользователей. Если я перейду к msdn.microsoft.com и сохраните ссылку на этот столбец, я могу просматривать или изменять эту ссылку только через пользовательский интерфейс, msdn.microsoft.com предоставляется.

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

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

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

Оставшиеся проблемы конфиденциальности

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

Мы решали эти проблемы с помощью сочетания политики и кода. На следующей схеме представлено общее представление нашей системной архитектуры:

Рис. 1. Архитектура службы избранного на первом этапе

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

Кластер данных недоступен с компьютеров за пределами Cold Rooster Consulting.
Службе избранного не требуется доступ к контактным данным лицензирований, поэтому она использует компонент входа для проверки подлинности лицензий. Компонент Logon извлекает только необходимые сведения.
С другой стороны, веб-сайту управления лицензиями требуется доступ к контактным данным лицензирований. Как еще он может позволить лицензированию изменять данные? Веб-сайт выполняет весь доступ к данным через компонент лицензирования. Элементы управления доступом в компоненте лицензирования не позволяют вызывать компонент, кроме веб-сайта управления лицензиями.
Элементы управления доступом к базе данных лицензирующих не позволяют получить доступ к базе данных, кроме компонента Входа в систему и Компонента лицензирования.
Письма с подтверждением отправляются на адреса, указанные в контактных данных, при каждом изменении контактных данных.

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

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

Заключение

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

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

Поделиться через