Как может измениться структура всей сферы ИТ, если некоторые системы защиты авторских прав, контроля, подтверждения подлинности, мониторинга и криптографии дадут нам не только более совершенные инструменты, но и принципиально новые технологии работы с данными? Это может отразиться не только на ИТ-рынке, но и на рынке труда. Такая технологическая трансформация, как и любая другая, создаст потребность в новых кадрах, а иных оставит без работы.
Данной публикацией я планирую начать цикл статей, посвящённых тому, как новые технологии в области кибербезопасности могут трансформировать всю отрасль ИТ. Обычно борьбе с угрозами отведена вспомогательная функция и мало кто задумывается о том, что в ближайшем будущем технологии защиты могут существенно изменить нашу жизнь, сделав её не то чтобы более безопасной, а принципиально иной. В своих прогнозах я буду стараться ориентироваться на период 5—30 лет. Если брать больше 30 лет, то можно совсем уйти в абстракции, а если менее 5-ти, то прогноз будет слишком очевиден. В первой части мы поговорим о новом рынке интеллектуального труда, практически отсутствующем в настоящий момент, это — рынок алгоритмов.
Каждому программисту, кто занимался сложными задачами оптимизации, разрабатывал новые криптографические функции или получил по ML- / AI-разработке какой-то новый значимый результат, возникала мысль: можно ли продать алгоритмы, на которые затрачен столь большой объём интеллектуального труда, и что-то на них заработать? Как правило, ответ на этот вопрос — «нет». Иногда продать можно, но только один раз и только каким-нибудь спецслужбам с обязательством больше нигде не использовать. Когда я учился в аспирантуре на кафедре системного анализа, местные аспиранты писали много интересных и значимых работ по многокритериальной оптимизации, в которых удавалось усовершенствовать отдельные алгоритмы и получить результат, на несколько процентов более точный, чем существующий. Однако дальнейшей коммерциализации за этими разработками никогда не следовало, за исключением продажи самого R&D как услуги.
Разберём сложность такой операции на отдельном примере. Допустим, некий разработчик создал новую хеш-функцию, являющуюся доказуемо устойчивой к коллизиям (collision resistant). Столь полезный результат навёл его на мысль, что неплохо было бы продать доступ к хеш-функции. Есть два пути, позволяющих реализовать это:
1. In-cloud: разместить где-то в облаке и предоставлять сервис HASHaaS. На сегодняшний день это решение является насколько простым, настолько же и бессмысленным. Даже если представить, что скорости и качества канала связи хватает для обеспечения необходимого SLA вызовов функции, мы столкнёмся со сложностью отправки самих данных в облако. Информация, которую мы хотим хешировать, скорее всего представляет некую ценность для нас. Например, мы можем находить хеш-функцию документа для дальнейшего заверения электронной цифровой подписью или применять хеширование пользовательских паролей, чтобы не хранить их в базе. Отправлять пароли в открытом виде на какой-то чужой сервер, чтобы потом получить хеш — выглядит абсурдно. Если зашифровать их для передачи, удалённый сервер всё равно должен будет провести расшифровку для вычисления хешей. Таким образом, он получит все пароли, все документы и любые другие данные, которые мы хотим хешировать. Использование облачной модели оказывается нежизнеспособным, за исключением некоторых редких случаев, когда отправляемая на удалённый сервер информация не несёт для нас абсолютно никакой ценности. Но такие ситуации будут скорее исключением из правил.
2. On-premise. Второй путь подразумевает передачу алгоритма непосредственно на сторону клиента, где он запустит его сам. Здесь есть несколько сложностей. Если мы передаём программу на интерпретируемом (открытом) языке, типа Python, то клиент может делать с ним всё что хочет. Контролировать дальнейшее копирование и модификацию кода будет невозможно. Если мы передаём её в скомпилированном виде, то, во-первых, это не всегда удобно для клиента, а во-вторых, отследить логику работы алгоритма и размножить его не составит большого труда. Даже если мы заблаговременно запутаем код и удалим всю отладочную информацию, можно дизассемблировать и отследить логику работы алгоритма, так как, вероятнее всего, объём кода для анализа будет не слишком велик. Таким образом, обе траектории ведут программиста к неудаче. Мысль о том, чтобы генерировать интеллектуальную собственность в виде каких-то специализированных алгоритмов и жить на пассивный доход от неё всю жизнь — остаётся мечтой… Или нет?
Некоторые теоретические области криптографии за последний десяток лет прошли колоссальный путь от нереализуемых теоретических конструкций до прикладных решений. Одним из таких направлений является гомоморфная криптография (homomorphic encryption).
Гомоморфизм шифра заключается в том, что изменения шифрованного текста аналогичны изменениям, производимым над исходным текстом. Допустим, Enc() — функция шифрования, а Dec() — дешифрования; тогда гомоморфизм по сложению можно выразить как x + y = Dec(Enc(x) + Enc(y)). Аналогично — по умножению: x ∙ y = Dec(Enc(x) ∙ Enc(y)). Если шифр обладает гомоморфизмом одновременно по сложению и по умножению, то он называется полностью гомоморфным шифрованием (Fully Homomorphic Encryption — FHE). Почему этого достаточно? Потому, что на этих операциях можно построить любую логическую схему. В частности, NAND (A, B) = 1 + A∙ B, а NAND в свою очередь является универсальным логическим вентилем (universal gate), то есть через него можно выразить любые другие логические операторы и написать любую программу. Первые идеи о гомоморфных шифрах появились весьма давно — ещё в 1976 году. Однако первая реализация такого шифра была описана только в 2009-м (Craig Gentry. Fully Homomorphic Encryption Using Ideal Lattices. In the 41st ACM Symposium on Theory of Computing (STOC), 2009). Конструкция эта была столь ограниченна в практическом применении, что требовала около 30 минут вычислений на одну элементарную операцию при достаточной криптостойкости длины ключа. За последующую пару лет появилось множество различных схем FHE, более пригодных для таких практических реализаций. Одними из самых известных являются BGV и CKKS (Z. Brakerski, C. Gentry, and V. Vaikuntanathan. Fully Homomorphic Encryption without Bootstrapping, ITCS 2012 и Cheon, Jung Hee; Kim, Andrey; Kim, Miran; Song, Yongsoo. Homomorphic encryption for arithmetic of approximate numbers. Advances in Cryptology — ASIACRYPT 2017. Springer, Cham. pp. 409—437). Далее последовало появление множества open-source реализаций и библиотек, реализующих гомоморфные шифры. Одним из первых был IBM с его библиотекой HElib (2013), далее появился HEAAN от Сеульского национального университета (2016), PALISADE от DARPA (2017), расширенный SEAL от Microsoft (2018) и множество других имплементаций, в том числе — с ускорением на GPU, FPGA и пр.
На примере FHE видно, как за 10 лет был пройден путь от абстрактных теоретических идей до конкретных прикладных решений. Гомоморфная криптография открывает ряд новых перспектив: например, она делает возможной работу с данными без расшифровки. Раньше для того, чтобы извлечь и обработать информацию из большой шифрованной базы данных, необходимо было сначала скачать всю базу, расшифровать её, изменить в нужных местах и далее снова зашифровать и отправить. Сейчас это можно сделать через одну операцию. В шифрованной базе данных мы сразу находим нужную ячейку и изменяем её, не прибегая к дешифровке всей таблицы.
Теперь, возвращаясь к схеме «in-cloud», мы можем реализовать удалённую торговую площадку («маркетплейс») алгоритмов, куда можно будет отправлять не открытые, а шифрованные данные. Это делает схему бизнеса гораздо более реалистичной. Теперь любой доступ к сервису не обязывает клиента разглашать что-либо. Мы можем отправлять персональные сведения, накопленные большие данные и любую другую зашифрованную конфиденциальную информацию и получать результат обработки также в шифрованном виде, ключ от которого есть только у нас.
Другая траектория заключается в продаже доступа к алгоритму по принципу «on-premise». Здесь стоит обратить внимание на ещё одно открытие криптографии последних лет. Это — так называемая неразличимая обфускация (indistinguishability obfuscation). Впервые идея неразличимой обфускации была озвучена в 2001 году (B. Barak, O. Goldreich, R. Impagliazzo, S. Rudich, A. Sahai, S. P. Vadhan, and K. Yang. On the (im)possibility of obfuscating programs. CRYPTO, 2001, pp. 1—18) в связи с необходимостью переосмысления формализованной задачи обфускации, так как предыдущие подходы к ней с математической точки зрения были не совсем корректными и не давали измеримых показателей того, насколько хорошо или плохо обфусцирована программа. Практически тем же коллективом исследователей в 2013 году было предложено решение задачи, которую они сами себе поставили в 2001-м. Им удалось найти конструкцию, которая может быть кандидатом на роль такого обфускатора (Sanjam Garg; Craig Gentry; Shai Halevi; Mariana Raykova; Amit Sahai; Brent Waters. Candidate Indistinguishability Obfuscation and Functional Encryption for all Circuits. Focs 2013, 40—49). Суть неразличимой обфускации можно объяснить следующим образом. Допустим, у нас есть такая программа obf(), которая на вход получает некий программный код, а на выходе выдаёт его в обфусцированном (запутанном) виде. При этом, если у нас есть две программы равной функциональности A и B, то получив их обфусцированные варианты obf(A) и obf(B), мы с точностью до пренебрежимо малых величин не сможем понять, какая из двух была подана на вход обфускатора (аналогичный подход используется для формулировки неразличимости алгоритмов шифрования). Из этого следует несколько неочевидных выводов, одним из которых является способность программы на выходе обфускатора хранить «секрет» внутри себя. Это может быть, например, ключ шифрования — тогда он передаётся вместе с исполняемым кодом и при этом не может быть извлечён.
Возможные бонусы от применения неразличимой обфускации этим не ограничиваются. Другим важным следствием использования неразличимого кода можно считать отсутствие необходимости доверять аппаратной составляющей. Любую обработку данных можно выполнять на недоверенном «железе». В результате миллиарды, потраченные на разработку отечественных компьютеров, или противостояние между Huawei и США становятся бессмысленными, если аргументировать это требованиями доверия к «железу». Но это — уже предмет другой статьи.
В случае продажи алгоритмов становится возможным передать их обфусцированный код клиенту. При этом, даже если мы заложим в код некую индивидуализацию под определённого пользователя, клиенту не удастся «извлечь» из кода эту кастомизированную часть. В результате мы не только делаем невозможным анализ принципов работы алгоритма, но и получаем способ снабжать программы некой неотделимой от них меткой, которая всегда будет оставлять цифровой след при распространении в интернете. Однако стоит заметить, что текущая реализация неразличимой обфускации столь громоздка, что говорить о её практическом использовании пока рано. Скорее всего (в отличие от «in-cloud»), схему реализации «on-premise» мы увидим не ранее чем через 10 лет.
Таким образом, мы видим, что в ближайшие 5 и более лет рынок алгоритмов может появиться в виде облачных схем, а впоследствии возможно и исполнение «on-premise». Конечно, это не произойдёт в один день. Для формирования таких отношений должны ещё появиться:
Развитие рынка алгоритмов может оказать существенное влияние на множество отраслей экономики. Можно выделить несколько направлений, которые однозначно окажутся под влиянием этой трансформации.
Большие данные. Конфигурация современного рынка больших данных складывается не только из самих массивов информации, но и — даже в большей степени — из центров аналитики, которые способны извлекать знания и строить модели на основе этих сведений. Каждый накопитель больших данных вроде телеком-оператора, банка или ритейла имеет собственный штат аналитиков, которые разрабатывают модели по извлечению знаний и продают эти материалы другим потребителям. При наличии в свободном доступе насыщенного маркетплейса алгоритмов и моделей работы с данными эти подразделения потеряют свою значимость. Накопители «бигдаты» больше не смогут наращивать добавочную стоимость на извлекаемую из больших данных информацию и будут вынуждены продавать только «сырой» материал, стоимость которого со временем также начнёт девальвироваться наподобие того, как обесценивается сейчас классическое сырьё (нефть, газ, алюминий и пр.).
Три уровня разработки. Классическая дихотомия разработки сейчас — это «backend и frontend». Последний пишет пользовательский интерфейс, первый — всю серверную логику работы приложения. Здесь может быть сформирован новый слой, который можно обозначить как «algoend». На нём будут заложены ключевые, самые важные и сложные алгоритмы (NLP, ML / AI, Data Mining, Blockchain и пр.). Иными словами, algoend — это сущностное наполнение любой разработки, а frontend и backend — его индивидуализация под конкретный проект. Algoend потребует максимальной квалификации и будет уходить в область дополнительных сервисов, формирующих новый рынок услуг. В свою очередь, frontend и backend — это рынок труда, стоимость которого будет снижаться.
Рынок C2B. Уже из первых двух пунктов можно сделать вывод о трансформации, происходящей на рынке труда. Развитие новых технологий в области кибербезопасности позволит оживить практически отсутствующий сейчас сектор C2B. Иначе говоря, мы переходим от правовых схем контроля интеллектуальной собственности (за который сейчас могут бороться только крупные корпорации) к технологическим схемам, которыми может воспользоваться любой. Если произведённая интеллектуальная собственность неотделима от того сервиса, который её использует, то и нет потребности в правовых и организационных затратах на поддержание режима её использования.
Рынок юридических услуг. Общепризнанным является утверждение, что переход к информационной экономике порождает большую востребованность юристов, которые занимаются патентованием и правовыми спорами. До какого-то момента это действительно было так. Однако на 10 и более лет вперёд я бы спрогнозировал полную смерть этого рынка услуг (по крайней мере — в области ИТ). Уже сейчас патентование и регистрация алгоритмов выглядят как не очень практичная и реально что-то защищающая процедура, все разработчики более склонны оставлять важные наработки как некое ноу-хау, нежели раскрывать и патентовать результаты. Здесь добавляется ещё один важный факт — код на выходе неразличимого обфускатора не может быть объектом авторских прав. Это следует из самого определения неразличимой обфускации, так как невозможно определить и доказать, какая именно программная конструкция была подана ему на вход. Я бы спрогнозировал, что правовых споров в индустрии ИТ 10 лет спустя больше не будет, по крайней мере — в том виде, как мы это представляем сейчас.
Прогнозы, озвученные в этой статье, конечно, как и любые другие предсказания, могут не сбыться. Открытия и разработки в R&D — это самая неблагодарная область для прогнозов. Мы не можем сказать, например, что нынешние сложные конструкции неразличимой обфускации будут усовершенствованы и станут практико-пригодными через 5 лет. Этого может не произойти. Правильнее будет предположить, что сами прогнозы и выводы этой статьи с высокой вероятностью сбудутся, а вот временные отрезки, на которые они положены, несут значительно большую неопределённость.
Оригинал статьи опубликован здесь
Как кибербезопасность трансформирует рынок ИТ (Часть 2)
Данной публикацией я планирую начать цикл статей, посвящённых тому, как новые технологии в области кибербезопасности могут трансформировать всю отрасль ИТ. Обычно борьбе с угрозами отведена вспомогательная функция и мало кто задумывается о том, что в ближайшем будущем технологии защиты могут существенно изменить нашу жизнь, сделав её не то чтобы более безопасной, а принципиально иной. В своих прогнозах я буду стараться ориентироваться на период 5—30 лет. Если брать больше 30 лет, то можно совсем уйти в абстракции, а если менее 5-ти, то прогноз будет слишком очевиден. В первой части мы поговорим о новом рынке интеллектуального труда, практически отсутствующем в настоящий момент, это — рынок алгоритмов.
Каждому программисту, кто занимался сложными задачами оптимизации, разрабатывал новые криптографические функции или получил по ML- / AI-разработке какой-то новый значимый результат, возникала мысль: можно ли продать алгоритмы, на которые затрачен столь большой объём интеллектуального труда, и что-то на них заработать? Как правило, ответ на этот вопрос — «нет». Иногда продать можно, но только один раз и только каким-нибудь спецслужбам с обязательством больше нигде не использовать. Когда я учился в аспирантуре на кафедре системного анализа, местные аспиранты писали много интересных и значимых работ по многокритериальной оптимизации, в которых удавалось усовершенствовать отдельные алгоритмы и получить результат, на несколько процентов более точный, чем существующий. Однако дальнейшей коммерциализации за этими разработками никогда не следовало, за исключением продажи самого R&D как услуги.
Можно ли продавать алгоритмы?
Разберём сложность такой операции на отдельном примере. Допустим, некий разработчик создал новую хеш-функцию, являющуюся доказуемо устойчивой к коллизиям (collision resistant). Столь полезный результат навёл его на мысль, что неплохо было бы продать доступ к хеш-функции. Есть два пути, позволяющих реализовать это:
1. In-cloud: разместить где-то в облаке и предоставлять сервис HASHaaS. На сегодняшний день это решение является насколько простым, настолько же и бессмысленным. Даже если представить, что скорости и качества канала связи хватает для обеспечения необходимого SLA вызовов функции, мы столкнёмся со сложностью отправки самих данных в облако. Информация, которую мы хотим хешировать, скорее всего представляет некую ценность для нас. Например, мы можем находить хеш-функцию документа для дальнейшего заверения электронной цифровой подписью или применять хеширование пользовательских паролей, чтобы не хранить их в базе. Отправлять пароли в открытом виде на какой-то чужой сервер, чтобы потом получить хеш — выглядит абсурдно. Если зашифровать их для передачи, удалённый сервер всё равно должен будет провести расшифровку для вычисления хешей. Таким образом, он получит все пароли, все документы и любые другие данные, которые мы хотим хешировать. Использование облачной модели оказывается нежизнеспособным, за исключением некоторых редких случаев, когда отправляемая на удалённый сервер информация не несёт для нас абсолютно никакой ценности. Но такие ситуации будут скорее исключением из правил.
2. On-premise. Второй путь подразумевает передачу алгоритма непосредственно на сторону клиента, где он запустит его сам. Здесь есть несколько сложностей. Если мы передаём программу на интерпретируемом (открытом) языке, типа Python, то клиент может делать с ним всё что хочет. Контролировать дальнейшее копирование и модификацию кода будет невозможно. Если мы передаём её в скомпилированном виде, то, во-первых, это не всегда удобно для клиента, а во-вторых, отследить логику работы алгоритма и размножить его не составит большого труда. Даже если мы заблаговременно запутаем код и удалим всю отладочную информацию, можно дизассемблировать и отследить логику работы алгоритма, так как, вероятнее всего, объём кода для анализа будет не слишком велик. Таким образом, обе траектории ведут программиста к неудаче. Мысль о том, чтобы генерировать интеллектуальную собственность в виде каких-то специализированных алгоритмов и жить на пассивный доход от неё всю жизнь — остаётся мечтой… Или нет?
Революция последних лет
Некоторые теоретические области криптографии за последний десяток лет прошли колоссальный путь от нереализуемых теоретических конструкций до прикладных решений. Одним из таких направлений является гомоморфная криптография (homomorphic encryption).
Гомоморфизм шифра заключается в том, что изменения шифрованного текста аналогичны изменениям, производимым над исходным текстом. Допустим, Enc() — функция шифрования, а Dec() — дешифрования; тогда гомоморфизм по сложению можно выразить как x + y = Dec(Enc(x) + Enc(y)). Аналогично — по умножению: x ∙ y = Dec(Enc(x) ∙ Enc(y)). Если шифр обладает гомоморфизмом одновременно по сложению и по умножению, то он называется полностью гомоморфным шифрованием (Fully Homomorphic Encryption — FHE). Почему этого достаточно? Потому, что на этих операциях можно построить любую логическую схему. В частности, NAND (A, B) = 1 + A∙ B, а NAND в свою очередь является универсальным логическим вентилем (universal gate), то есть через него можно выразить любые другие логические операторы и написать любую программу. Первые идеи о гомоморфных шифрах появились весьма давно — ещё в 1976 году. Однако первая реализация такого шифра была описана только в 2009-м (Craig Gentry. Fully Homomorphic Encryption Using Ideal Lattices. In the 41st ACM Symposium on Theory of Computing (STOC), 2009). Конструкция эта была столь ограниченна в практическом применении, что требовала около 30 минут вычислений на одну элементарную операцию при достаточной криптостойкости длины ключа. За последующую пару лет появилось множество различных схем FHE, более пригодных для таких практических реализаций. Одними из самых известных являются BGV и CKKS (Z. Brakerski, C. Gentry, and V. Vaikuntanathan. Fully Homomorphic Encryption without Bootstrapping, ITCS 2012 и Cheon, Jung Hee; Kim, Andrey; Kim, Miran; Song, Yongsoo. Homomorphic encryption for arithmetic of approximate numbers. Advances in Cryptology — ASIACRYPT 2017. Springer, Cham. pp. 409—437). Далее последовало появление множества open-source реализаций и библиотек, реализующих гомоморфные шифры. Одним из первых был IBM с его библиотекой HElib (2013), далее появился HEAAN от Сеульского национального университета (2016), PALISADE от DARPA (2017), расширенный SEAL от Microsoft (2018) и множество других имплементаций, в том числе — с ускорением на GPU, FPGA и пр.
На примере FHE видно, как за 10 лет был пройден путь от абстрактных теоретических идей до конкретных прикладных решений. Гомоморфная криптография открывает ряд новых перспектив: например, она делает возможной работу с данными без расшифровки. Раньше для того, чтобы извлечь и обработать информацию из большой шифрованной базы данных, необходимо было сначала скачать всю базу, расшифровать её, изменить в нужных местах и далее снова зашифровать и отправить. Сейчас это можно сделать через одну операцию. В шифрованной базе данных мы сразу находим нужную ячейку и изменяем её, не прибегая к дешифровке всей таблицы.
Теперь, возвращаясь к схеме «in-cloud», мы можем реализовать удалённую торговую площадку («маркетплейс») алгоритмов, куда можно будет отправлять не открытые, а шифрованные данные. Это делает схему бизнеса гораздо более реалистичной. Теперь любой доступ к сервису не обязывает клиента разглашать что-либо. Мы можем отправлять персональные сведения, накопленные большие данные и любую другую зашифрованную конфиденциальную информацию и получать результат обработки также в шифрованном виде, ключ от которого есть только у нас.
Другая траектория заключается в продаже доступа к алгоритму по принципу «on-premise». Здесь стоит обратить внимание на ещё одно открытие криптографии последних лет. Это — так называемая неразличимая обфускация (indistinguishability obfuscation). Впервые идея неразличимой обфускации была озвучена в 2001 году (B. Barak, O. Goldreich, R. Impagliazzo, S. Rudich, A. Sahai, S. P. Vadhan, and K. Yang. On the (im)possibility of obfuscating programs. CRYPTO, 2001, pp. 1—18) в связи с необходимостью переосмысления формализованной задачи обфускации, так как предыдущие подходы к ней с математической точки зрения были не совсем корректными и не давали измеримых показателей того, насколько хорошо или плохо обфусцирована программа. Практически тем же коллективом исследователей в 2013 году было предложено решение задачи, которую они сами себе поставили в 2001-м. Им удалось найти конструкцию, которая может быть кандидатом на роль такого обфускатора (Sanjam Garg; Craig Gentry; Shai Halevi; Mariana Raykova; Amit Sahai; Brent Waters. Candidate Indistinguishability Obfuscation and Functional Encryption for all Circuits. Focs 2013, 40—49). Суть неразличимой обфускации можно объяснить следующим образом. Допустим, у нас есть такая программа obf(), которая на вход получает некий программный код, а на выходе выдаёт его в обфусцированном (запутанном) виде. При этом, если у нас есть две программы равной функциональности A и B, то получив их обфусцированные варианты obf(A) и obf(B), мы с точностью до пренебрежимо малых величин не сможем понять, какая из двух была подана на вход обфускатора (аналогичный подход используется для формулировки неразличимости алгоритмов шифрования). Из этого следует несколько неочевидных выводов, одним из которых является способность программы на выходе обфускатора хранить «секрет» внутри себя. Это может быть, например, ключ шифрования — тогда он передаётся вместе с исполняемым кодом и при этом не может быть извлечён.
Возможные бонусы от применения неразличимой обфускации этим не ограничиваются. Другим важным следствием использования неразличимого кода можно считать отсутствие необходимости доверять аппаратной составляющей. Любую обработку данных можно выполнять на недоверенном «железе». В результате миллиарды, потраченные на разработку отечественных компьютеров, или противостояние между Huawei и США становятся бессмысленными, если аргументировать это требованиями доверия к «железу». Но это — уже предмет другой статьи.
В случае продажи алгоритмов становится возможным передать их обфусцированный код клиенту. При этом, даже если мы заложим в код некую индивидуализацию под определённого пользователя, клиенту не удастся «извлечь» из кода эту кастомизированную часть. В результате мы не только делаем невозможным анализ принципов работы алгоритма, но и получаем способ снабжать программы некой неотделимой от них меткой, которая всегда будет оставлять цифровой след при распространении в интернете. Однако стоит заметить, что текущая реализация неразличимой обфускации столь громоздка, что говорить о её практическом использовании пока рано. Скорее всего (в отличие от «in-cloud»), схему реализации «on-premise» мы увидим не ранее чем через 10 лет.
Прогнозы и предостережения
Таким образом, мы видим, что в ближайшие 5 и более лет рынок алгоритмов может появиться в виде облачных схем, а впоследствии возможно и исполнение «on-premise». Конечно, это не произойдёт в один день. Для формирования таких отношений должны ещё появиться:
- Платформа (или платформы) обмена данными между поставщиками и потребителями алгоритмов. Они должны автоматизированно выполнять все функции FHE на уровне некоего транспортного слоя. Тогда сервис действительно станет удобным и, главное, понятным для всех участников рынка, ведь сейчас мало кто из ИТ-специалистов знает, что такое FHE и как его применять.
- Обмен большими данными всё ещё тормозится ограниченностью скорости каналов коммуникации. Поэтому здесь необходимо дождаться момента, когда пропускная способность каналов органическим путём вырастет до нужных значений, либо запускать дополнительные сервисы предварительной обработки данных на стороне клиента, которые могут быть частью платформ и фреймворков в п. 1.
Развитие рынка алгоритмов может оказать существенное влияние на множество отраслей экономики. Можно выделить несколько направлений, которые однозначно окажутся под влиянием этой трансформации.
Большие данные. Конфигурация современного рынка больших данных складывается не только из самих массивов информации, но и — даже в большей степени — из центров аналитики, которые способны извлекать знания и строить модели на основе этих сведений. Каждый накопитель больших данных вроде телеком-оператора, банка или ритейла имеет собственный штат аналитиков, которые разрабатывают модели по извлечению знаний и продают эти материалы другим потребителям. При наличии в свободном доступе насыщенного маркетплейса алгоритмов и моделей работы с данными эти подразделения потеряют свою значимость. Накопители «бигдаты» больше не смогут наращивать добавочную стоимость на извлекаемую из больших данных информацию и будут вынуждены продавать только «сырой» материал, стоимость которого со временем также начнёт девальвироваться наподобие того, как обесценивается сейчас классическое сырьё (нефть, газ, алюминий и пр.).
Три уровня разработки. Классическая дихотомия разработки сейчас — это «backend и frontend». Последний пишет пользовательский интерфейс, первый — всю серверную логику работы приложения. Здесь может быть сформирован новый слой, который можно обозначить как «algoend». На нём будут заложены ключевые, самые важные и сложные алгоритмы (NLP, ML / AI, Data Mining, Blockchain и пр.). Иными словами, algoend — это сущностное наполнение любой разработки, а frontend и backend — его индивидуализация под конкретный проект. Algoend потребует максимальной квалификации и будет уходить в область дополнительных сервисов, формирующих новый рынок услуг. В свою очередь, frontend и backend — это рынок труда, стоимость которого будет снижаться.
Рынок C2B. Уже из первых двух пунктов можно сделать вывод о трансформации, происходящей на рынке труда. Развитие новых технологий в области кибербезопасности позволит оживить практически отсутствующий сейчас сектор C2B. Иначе говоря, мы переходим от правовых схем контроля интеллектуальной собственности (за который сейчас могут бороться только крупные корпорации) к технологическим схемам, которыми может воспользоваться любой. Если произведённая интеллектуальная собственность неотделима от того сервиса, который её использует, то и нет потребности в правовых и организационных затратах на поддержание режима её использования.
Рынок юридических услуг. Общепризнанным является утверждение, что переход к информационной экономике порождает большую востребованность юристов, которые занимаются патентованием и правовыми спорами. До какого-то момента это действительно было так. Однако на 10 и более лет вперёд я бы спрогнозировал полную смерть этого рынка услуг (по крайней мере — в области ИТ). Уже сейчас патентование и регистрация алгоритмов выглядят как не очень практичная и реально что-то защищающая процедура, все разработчики более склонны оставлять важные наработки как некое ноу-хау, нежели раскрывать и патентовать результаты. Здесь добавляется ещё один важный факт — код на выходе неразличимого обфускатора не может быть объектом авторских прав. Это следует из самого определения неразличимой обфускации, так как невозможно определить и доказать, какая именно программная конструкция была подана ему на вход. Я бы спрогнозировал, что правовых споров в индустрии ИТ 10 лет спустя больше не будет, по крайней мере — в том виде, как мы это представляем сейчас.
Прогнозы, озвученные в этой статье, конечно, как и любые другие предсказания, могут не сбыться. Открытия и разработки в R&D — это самая неблагодарная область для прогнозов. Мы не можем сказать, например, что нынешние сложные конструкции неразличимой обфускации будут усовершенствованы и станут практико-пригодными через 5 лет. Этого может не произойти. Правильнее будет предположить, что сами прогнозы и выводы этой статьи с высокой вероятностью сбудутся, а вот временные отрезки, на которые они положены, несут значительно большую неопределённость.
Оригинал статьи опубликован здесь
Как кибербезопасность трансформирует рынок ИТ (Часть 2)
