Независимо от того, что вас беспокоит: конфиденциальность, безопасность, конкурентное преимущество, интеллектуальная собственность или предотвращение рисков, ваше предприятие должно делиться — буквально — как можно меньшим количеством данных с сотрудниками, подрядчиками и третьими сторонами. Каким бы очевидным ни было это утверждение, просто поразительно, сколько данных без необходимости передается облачным провайдерам и другим организациям.
Этому есть две причины. Во-первых, время и усилия, необходимые для удаления данных, которые на самом деле не нужны третьей стороне, из данных, которые необходимы, могут сделать рентабельность инвестиций непривлекательной. Это особенно верно, когда руководители преуменьшают риск возникновения чего-то плохого.
Например, «я, наверное, могу доверять Google/Microsoft/Amazon/Rackspace и т. д.». Действительно? Даже если вы решите предположить, что их безопасность является звездной — это не так — как насчет проблем с конкуренцией? Вы действительно готовы верить, что они будут обращаться с вашими данными, исходя из ваших интересов?
Вторая причина более практическая: технологические ограничения. То, как многие предприятия обрабатывают данные, особенно данные, созданные мобильными устройствами или управляемые ими, действительно затрудняет легкое отделение критического от второстепенного.
Ограниченный обмен данными и шифрование
Исследователи из Швейцарского федерального технологического института в Лозанне, официально именуемого Федеральной политехнической школой Лозанны (EPFL), возможно, придумали способ решения обеих проблем. Их подход ограничивает то, какие данные передаются, и использует подход к шифрованию, который позволяет обрабатывать данные, оставаясь при этом зашифрованными.
Подход, который они предлагают, предназначен для решения очень ограниченной проблемы: вопросов конфиденциальности и безопасности, связанных с услугами по совместному использованию поездок, такими как Uber и Lyft. Но его создатели видят тот же подход, применимый к широкому спектру облачных сервисов, больших данных и других сторонних сервисов, с которыми предприятия имеют дело каждый день, когда они обычно делятся гораздо большим объемом информации, чем им нужно и хочется.
Итало Дакоста, постдокторский исследователь EPFL, участвовавший в проекте, упомянул больницы, которые «в контексте персонализированной медицины хотят выполнять вычисления на основе последовательности ДНК» и ищут облачную фирму, чтобы помочь со сложной обработкой чисел. «Пациентам может быть неудобно делиться последовательностью ДНК, потому что она очень чувствительна», — сказал он в интервью по Skype.
«Пациенты с гомоморфным шифрованием вообще не должны будут раскрывать свою последовательность ДНК, даже частично», — сказал Дакоста. «Основной вариант использования гомоморфного шифрования для персонализированной медицины — позволить исследователям/врачам из других больниц/медицинских учреждений анализировать геномные данные без необходимости раскрывать им данные. Они видят только результаты своих запросов и анализа».
Третьи стороны «никогда не видят реальных данных, но вы получаете результаты вычислений. [Third parties] не нужно видеть данные [as they] может сжать данные, пока они зашифрованы».
Исследователи публикуют свой исходный код и полную информацию о реализации в надежде, что компании примут этот подход. По словам Дакосты, они намеренно избегают патентования подхода, предпочитая, чтобы компании использовали его бесплатно.
Несколько гомоморфное шифрование (SHE)
Подход, подробно описанный в этой статье, включает несколько гомоморфное шифрование (SHE). (Примечание: Стэнфордский университет опубликовал краткое описание SHE.)
Этот отрывок из этого документа дает обзор технического подхода:
«Криптосистемы SHE обеспечивают семантическую безопасность, т. е. невозможно (вычислительно) узнать, скрывают ли два разных шифрования один и тот же открытый текст. без получения какой-либо информации о значениях открытого текста. Кроме того, мы выбираем одну из самых последних и эффективных схем SHE, основанных на идеальных решетках, схему FV. Эта схема основана на сложности задачи кольцевого обучения с ошибками (RLWE). Обратите внимание, что Всякий раз, когда мы работаем с криптосистемами, основанными на конечных кольцах, мы обычно работаем с целыми числами, поэтому с этого момента мы будем предполагать, что все входные данные адекватно квантуются как целые числа.
«Когда гонщик хочет сделать запрос на поездку, он генерирует эфемерную пару открытого и закрытого ключей FV вместе с ключом релинеаризации. Он использует открытый ключ для шифрования своих планарных координат и получает их зашифрованные формы. [service provider] о зоне ее пикапа, открытых ключах и ключах релинеаризации и ее зашифрованных планарных координатах. Когда эта информация поступает в [service provider], [service provider] передает открытый ключ всем драйверам, доступным в этой зоне. Каждый водитель использует открытый ключ для шифрования своих планарных координат и отправляет их в SP. SP вычисляет на основе их зашифрованных координат зашифрованные расстояния между гонщиком и водителями и возвращает зашифрованные расстояния гонщику, из которых гонщик может расшифровать и выбрать наилучшее совпадение, например, водителя, который находится ближе всех. к месту ее посадки».
Этот подход был разработан с расчетом на мобильную сеть, хотя в реализации SHE нет ничего, что не работало бы в немобильной среде. Но в документе признается то, что ИТ известно уже много лет, а именно то, что мобильные устройства впечатляют своей утечкой данных с точки зрения данных.
Исследователи пытались обойти проблемы с утечкой мобильных данных.
«Мы предполагаем, что метаданные сети и нижних коммуникационных уровней нельзя использовать для идентификации пассажиров и водителей или для увязки их действий. Такое предположение разумно, поскольку в большинстве случаев смартфоны водителей и водителей не имеют фиксированного общедоступного IP-адреса. адреса [since] они выходят в Интернет через шлюз NAT, предлагаемый их оператором сотовой связи. При необходимости можно использовать VPN-прокси или Tor для сокрытия сетевых идентификаторов», — говорится в документе. «Кроме того, водители используют навигационное приложение, которое не раскрывает свое местоположение [service provider]. Это можно сделать с помощью стороннего навигационного/дорожного приложения, например, Google Maps, TomTom, Garmin, или предварительно загрузив карту их рабочих областей, например города, и используя навигационное приложение в автономном режиме. “
Некоторые недостатки системы
Тем не менее, даже для предполагаемого подхода к вызову такси у их системы есть свои недостатки, говорится в документе.
«Оценка [the service] Использование реальных наборов данных из такси Нью-Йорка показывает, что даже при сильной битовой безопасности более 112 бит ORide вводит приемлемые затраты на вычисления и пропускную способность для пассажиров, водителей и [service provider]. Например, для каждого запроса на поездку пассажиру необходимо загрузить только один зашифрованный текст размером 186 КБ с вычислительными затратами менее десяти миллисекунд. ORide также предоставляет большие наборы анонимности для пассажиров за счет приемлемых требований к пропускной способности для водителей: например, для поездок в районах Квинса и Бронкса поездка будет иметь набор анонимности около 26 000, а от водителей требуется только скорость передачи данных менее 2 Мбит/с. Более того, наши результаты показывают, что ORide является масштабируемым, поскольку мы рассмотрели нагрузку запросов, которая значительно выше, чем у текущих RHS, например, на долю Uber приходится только 15% запросов на получение поездки в Нью-Йорке», — написали исследователи.
Но «удобство использования PrivateRide снижается [compared with] Текущий [car services] поскольку поддерживаемый механизм оплаты менее удобен. [Their approach] требует оплаты электронными деньгами, купленными заранее перед поездкой. Кроме того, согласование поездок неоптимально, потому что расстояние между гонщиком и водителем оценивается с использованием центров скрытых областей, а не точных местоположений, что приводит к дополнительному времени ожидания для гонщиков».
Эти недостатки, однако, кажутся ограниченными услугой каршеринга. Скорее всего, это не окажет большого влияния на типичные усилия предприятий по аутсорсингу больших данных.
Недавно я разговаривал с топ-менеджером очень крупной облачной хостинговой компании, который рассказал, как государственное учреждение недавно обратилось за помощью в очень крупном проекте по анализу данных. На сколько огромен? Начальник первоначально подсчитал, что им потребуется 100 серверов для запуска аналитики, и в итоге они использовали почти 2000 серверов. Да, иногда большие данные становятся очень большими.
В этом-то и дело. Каждый раз, когда вы передаете данные на аутсорсинг, вы берете на себя огромный риск. Будут ли данные хорошо защищены? Кстати, кто на самом деле получает доступ? Вам нужно доверять не только сотрудникам этой третьей стороны, но и любому подрядчику третьей стороны, у которого есть доступ. Кто-то очищает резервные копии? Черт возьми, данные этой третьей стороны резервируются еще одной третьей стороной?
Как далеко в этой кроличьей норе вы хотите, чтобы ваши данные ушли? Хотите, чтобы однажды вам позвонил агент секретной службы и сообщил, что ваши данные были найдены в файлах компании, о которой вы никогда не слышали? Это может быть несанкционированный доступ, но вероятность того, что это может быть санкционированный доступ, невелика. Передавая свои данные на аутсорсинг, вы также передаете на аутсорсинг контроль. Насколько вы доверчивы?
Этот швейцарский подход не решит эту проблему. Но если это дает возможность снизить риск — а я говорил, что это предлагается компаниям бесплатно? — это может быть очень полезно изучить.
Авторское право © 2017 IDG Communications, Inc.