Шифрование данных: разработчики критической терминологии должны знать

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

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

Безопасность данных как махинации

Что делает безопасность сложнее, так это то, что она имеет несколько уровней и становится делом «ответственность всех - это ответственность никого». В современной облачной команде несколько групп напрямую контролируют вход / выход данных: разработчики, администраторы баз данных, системные администраторы (ребята из DevOps, если хотите), привилегированные пользователи бэк-офиса и т. Д. Эти роли / команды могут быстро закрыть глаза и думать о безопасности данных как о проблеме других. Тем не менее, реальность такова, что у них есть свои собственные миры, о которых нужно заботиться, поскольку администратор базы данных не может контролировать безопасность приложения, сотрудник DevOps абсолютно ничего не может сделать с доступом к бэк-офису и так далее.

Разработчики и безопасность данных

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

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

Давайте начнем!

Хеширование

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

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

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

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

Всплывающее окно предлагает вам запустить команду, которая по сути будет хешировать весь файл, который вы только что загрузили, и сравнить результат с хеш-строкой, которую вы видите на странице загрузки: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5 . Это преобразование выполняется с использованием алгоритма SHA256, упоминание о котором вы можете увидеть в заключительных частях команды: shasum -a 256 --check .

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

Некоторые знакомые имена, которые вы услышите в области хеширования паролей, - это MD5 (небезопасный и ныне несуществующий), SHA-1 и SHA-2 (семейства алгоритмов, членом которых является SHA-256, как и SHA-512), SCRYPT, BCRYPT и т. Д.

Соление

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

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

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

Ключи

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

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

Вращающиеся клавиши

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

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

Например, в AWS есть специальный сервис под названием AWS Key Management Service (KMS). Автоматизированная служба избавляет вас от хлопот по смене и распределению ключей между всеми серверами, и в наши дни это не проблема, когда дело доходит до крупных развертываний.

Криптография с открытым ключом

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

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

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

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

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

Безопасность транспортного уровня (TLS)

Теперь вы знаете, как работает криптография с открытым ключом. Этот механизм (знание открытого ключа получателя и отправка им данных, зашифрованных с его помощью) - вот что стоит за всей популярностью HTTPS и заставляет Chrome говорить: «Этот сайт безопасен». Что происходит, так это то, что сервер и браузер шифруют HTTP-трафик (помните, что веб-страницы - это очень длинные строки текста, которые могут интерпретировать браузеры) с помощью открытых ключей друг друга, что приводит к защищенному HTTP (HTTPS).

Изображение предоставлено Mozilla. Интересно отметить, что шифрование не происходит на транспортном уровне как таковом; модель OSI ничего не говорит о шифровании данных. Просто данные зашифровываются приложением (в данном случае браузером) перед тем, как передать их на транспортный уровень, который позже отправляет их в место назначения, где они расшифровываются. Однако в этом процессе задействован транспортный уровень, и, в конце концов, все это приводит к безопасной транспортировке данных, поэтому нечеткий термин «безопасность транспортного» уровня сохранился.

В некоторых случаях вы можете даже встретить термин Secure Socket Layer (SSL). Это та же концепция, что и TLS, за исключением того, что SSL возник намного раньше и теперь заменен TLS.

Полное шифрование диска

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

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

Сквозное шифрование

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

Ранее мы видели, как Full Disk Encryption обеспечивает максимальную пуленепробиваемую стратегию, но для обычного пользователя это неудобно. Я имею в виду, представьте, что Facebook хочет, чтобы данные телефона, которые он генерирует и хранит в вашем телефоне, были безопасными, но у него не может быть доступа к шифрованию всего вашего телефона и блокировке всего остального в процессе.

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

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

Вывод

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