Шифрование часто является вопросом безопасности, но оно также важно и для конфиденциальности. Цель шифрования — не дать другим прочитать зашифрованную информацию… но запретить другим читать вашу информацию — это один из способов сохранить ее конфиденциальность. Пользователь часто ограничен в том, насколько он может сделать это самостоятельно, но с вашей помощью как поставщика услуги, которую он использует, шифрование может помочь сохранить его данные.
Существует три подходящих способа применения шифрования для обеспечения конфиденциальности пользователей: шифрование при передаче, шифрование при хранении и сквозное шифрование:
- Шифрование при передаче сохраняет данные между пользователем и вашим сайтом в зашифрованном виде: то есть HTTPS. Вероятно, на ваших сайтах уже настроен HTTPS, но уверены ли вы, что все данные, передаваемые на ваши сайты, зашифрованы? Для этого нужны перенаправление и HSTS, они описаны ниже и должны быть частью вашей настройки HTTPS.
- Шифрование неактивных данных — это шифрование данных, хранящихся на ваших серверах. Это защищает от утечки данных и является важной частью вашей политики безопасности.
- Сквозное шифрование — это шифрование данных на клиенте еще до того, как они достигнут вашего сервера. Это защищает пользовательские данные даже от вас: вы можете хранить данные своих пользователей, но не можете их прочитать. Это сложно реализовать, и оно подходит не для всех типов приложений, но это сильно помогает обеспечить конфиденциальность пользователей, поскольку никто, кроме них самих, не может видеть их данные.
HTTPS
Первый шаг — обслуживание вашего веб-сервиса через HTTPS. Весьма вероятно, что вы уже это сделали, но если нет, то это важный шаг. HTTPS — это HTTP, протокол, который браузер использует для запроса веб-страниц с сервера, но зашифрованный с помощью SSL. Это означает, что внешний злоумышленник не может прочитать или вмешаться в HTTPS-запрос между отправителем (вашим пользователем) и получателем (вами), поскольку он зашифрован, и поэтому он не может его прочитать или изменить. Это шифрование при передаче: когда данные передаются от пользователя к вам или от вас к пользователю. Шифрование HTTPS при передаче также не позволяет интернет-провайдеру пользователя или поставщику Wi-Fi, который он использует, прочитать данные, которые они отправляют вам в рамках своих отношений с вашим сервисом. Это также может повлиять на функции вашего сервиса: многие варианты использования существующих API-интерфейсов JavaScript требуют, чтобы веб-сайт обслуживался через HTTPS. MDN имеет более полный список, но API, защищенные безопасным контекстом, включают сервис-воркеры, push-уведомления, общий доступ к веб-страницам и веб-шифрование, а также API некоторых устройств.
Для обслуживания вашего сайта через HTTPS вам понадобится сертификат SSL. Их можно создать бесплатно с помощью Let's Encrypt или зачастую предоставить вам ваш хостинг, если вы его используете. Также можно использовать стороннюю службу, которая «проксирует» вашу веб-службу и может предоставлять HTTPS, а также услуги кэширования и CDN. Существует множество примеров таких сервисов, таких как Cloudflare и Fastly — какой именно использовать зависит от вашей текущей инфраструктуры. В прошлом внедрение HTTPS могло быть обременительным или дорогостоящим, поэтому его обычно использовали только на платежных страницах или в особо безопасных источниках; но свободно доступные сертификаты, улучшения стандартов и большее распространение браузеров устранили все эти препятствия.
Делать
- Включите HTTPS на ваших серверах для всего (какой бы метод вы ни выбрали).
- Рассмотрите возможность использования прокси-сервера перед вашими серверами, например Cloudflare ( httpsiseasy.com/ объясняет этот процесс).
- Let's Encrypt проведет вас через процесс создания собственного SSL-сертификата Let's Encrypt.
- Или используйте OpenSSL напрямую, чтобы создать свой собственный сертификат и подписать его выбранным центром сертификации (CA) ( Включить HTTPS подробно объясняется, как это сделать).
Какой подход вы выберете, зависит от деловых компромиссов. Использование сторонней организации для управления SSL-соединением проще всего настроить и дает другие преимущества, такие как балансировка нагрузки, кэширование и аналитика. Но это также сопровождается очевидной передачей некоторого контроля этой третьей стороне и неизбежной зависимостью от их услуг (и возможной оплаты, в зависимости от используемых вами услуг и уровня вашего трафика).
Генерация сертификатов и их подписание центром сертификации — это то, как раньше выполнялся процесс SSL, но использование Let's Encrypt может быть проще, если оно поддерживается вашим провайдером или если ваша серверная команда достаточно технически подкована для этого, и это бесплатно. Ваш провайдер также часто предлагает SSL как услугу, если вы используете что-то более высокого уровня, чем облачный хостинг, поэтому стоит проверить.
Почему
Безопасность — это часть вашей истории конфиденциальности: возможность продемонстрировать, что вы защищаете пользовательские данные от вмешательства, помогает укрепить доверие. Если вы не используете HTTPS, ваши сайты также помечаются браузерами как «небезопасные» (и так было в течение некоторого времени). Существующие API-интерфейсы JavaScript часто доступны только для страниц HTTPS («безопасное происхождение») . Это также защищает ваших пользователей от того, что их использование Интернета будет замечено их интернет-провайдером . Это, безусловно, лучшая практика; сейчас практически нет причин не использовать HTTPS для веб-сайтов.
Как браузеры представляют HTTP-страницу (незащищенную)
Перенаправление на HTTPS
Если ваш сайт доступен как по URL-адресам http:, так и по https:, вам следует перенаправить все обращения к URL-адресам http на https. Это происходит по вышеуказанным причинам, а также гарантирует, что ваш сайт не появится наWhynohttps.com , если он станет популярным. Как это сделать, во многом зависит от вашей инфраструктуры. Если вы размещены на AWS, вы можете использовать балансировщик нагрузки Classic или Application . Google Cloud аналогичен. В Azure вы можете создать Front Door ; в узле с экспресс- проверкой request.secure ; в Nginx перехватить весь порт 80 и вернуть 301 ; а в Apache используйте RewriteRule . Если вы используете службу хостинга, вполне вероятно, что они автоматически выполнят для вас перенаправление на URL-адреса HTTPS: Netlify, Firebase и GitHub Pages, среди многих других, это делают.
HSTS
HSTS — это сокращение от «HTTP Strict-Transport-Security» и это способ навсегда заблокировать браузер для использования HTTPS для вашего сервиса. Если вы довольны переходом на HTTPS или если вы уже это сделали, вы можете добавить заголовок ответа HTTP Strict-Transport-Security к своим исходящим ответам. Браузер, который ранее обращался к вашему сайту, зафиксирует, что видел этот заголовок, и с этого момента будет автоматически получать доступ к этому сайту по протоколу HTTPS, даже если вы запрашиваете HTTP. Это позволяет избежать перенаправления, как указано выше: браузер молча «обновляет» все запросы к вашей службе для использования HTTPS.
Аналогичным образом вы можете разместить заголовок Upgrade-Insecure-Requests вместе со своими страницами. Это действие отличается от Strict-Transport-Security но связано с ним. Если вы добавите Upgrade-Insecure-Requests: 1 , то запросы с этой страницы к другим ресурсам (изображениям, скриптам) будут запрашиваться как https, даже если ссылка http. Однако браузер не будет повторно запрашивать саму страницу как https и не запомнит ее в следующий раз. На практике Upgrade-Insecure-Requests полезен, если вы конвертируете существующий сайт с большим количеством ссылок на HTTPS и преобразовать URL-адреса ссылок в контенте сложно, но лучше изменить контент, где это возможно.
HSTS — это, прежде всего, функция безопасности: он «привязывает» ваш сайт к HTTPS для пользователей, которые были там раньше. Однако, как указано выше, HTTPS хорош для конфиденциальности, а HSTS — для HTTPS. Точно так же Upgrade-Insecure-Requests на самом деле не нужен, если вы обновляете весь свой контент, но это полезный подход «пояса и скобок», позволяющий добавить глубокую защиту и гарантировать, что ваш сайт всегда будет использовать HTTPS.
Делать
Добавьте заголовок HSTS в исходящие ответы:
Strict-Transport-Security: max-age=300; includeSubDomains
Параметр max-age определяет, как долго (в секундах) браузер должен помнить и обеспечивать обновление HTTPS. (Здесь мы установили его равным 300 секундам, то есть пяти минутам.) В конечном итоге вы захотите, чтобы это значение составило 6 3072 000, что составляет два года, и это цифра, которую рекомендует hstspreload.org , но восстановить ее довольно сложно. если есть проблемы. Поэтому рекомендуется сначала установить небольшое значение (300), проверить, чтобы убедиться, что ничего не сломалось, а затем поэтапно увеличивать число.
Добавьте заголовки Upgrade-Insecure-Requests в исходящие ответы:
Upgrade-Insecure-Requests: 1 Content-Security-Policy: upgrade-insecure-requests
Сквозное шифрование
Хороший способ сохранить конфиденциальность пользовательских данных — не показывать их никому, кроме пользователя, включая вас. Это очень помогает с вашей позицией доверия: если у вас нет данных вашего пользователя, то ясно, что вы не можете сделать с ними ничего такого, чего они не захотят. Один из способов сделать это — вообще не позволять пользовательским данным покидать их устройство, сохраняя все на стороне клиента. Этот подход работает, но для чистого клиентского приложения существуют ограничения: размер хранилища данных браузера может быть ограничен, а в некоторых браузерах может быть очищен практически без предупреждения. Также сложно или невозможно получить доступ к вашим данным на двух устройствах, таких как ноутбук и мобильный телефон. По этой причине может быть полезно отправлять данные на сервер как обычно, но зашифровывать их ключом, известным только пользователю, чтобы сервер не мог получить к ним доступ (поскольку он не может их расшифровать), но мог их сохранить.
Как это работает?
Этот подход часто используется приложениями для обмена сообщениями, где он называется «сквозным шифрованием» или «e2e». Таким образом, два человека, знающие ключи друг друга, могут шифровать и расшифровывать свои сообщения взад и вперед и отправлять эти сообщения через провайдера обмена сообщениями, но провайдер обмена сообщениями (у которого нет этих ключей) не может прочитать сообщения. Большинство приложений не являются приложениями для обмена сообщениями, но можно объединить два подхода — хранилище данных исключительно на стороне клиента и шифрование данных с помощью ключа, известного клиенту, — чтобы хранить данные локально, но также отправлять их в зашифрованном виде на сервер. Важно понимать, что у этого подхода есть ограничения: это возможно не для всех сервисов, и, в частности, его нельзя использовать, если вам, как поставщику услуг, необходим доступ к тому, что хранит пользователь. Как описано в части 2 этой серии статей, лучше всего соблюдать принцип минимизации данных; по возможности вообще избегайте сбора данных. Если пользователю необходимо хранилище данных, но вам не нужен доступ к этим данным для предоставления услуги, то сквозное шифрование является полезной альтернативой. Если вы предоставляете услуги, которые требуют возможности видеть, что хранит пользователь для предоставления услуги, то сквозное шифрование не подходит. Но если вы этого не сделаете, то клиентский JavaScript вашего веб-сервиса может шифровать любые данные, которые он отправляет на сервер, и расшифровывать любые данные, которые он получает.
Пример: Экскалидро
Excalidraw делает это и объясняет, как это сделать, в своем блоге. Это приложение для векторного рисования, которое хранит рисунки на сервере, зашифрованные случайно выбранным ключом. Одной из причин того, что Excalidraw может реализовать это сквозное шифрование с использованием относительно небольшого количества кода, является то, что криптографические библиотеки теперь встроены в браузер с помощью window.crypto , который представляет собой набор API-интерфейсов JavaScript , поддерживаемых во всех современных браузерах . Криптография сложна, и реализация алгоритмов сопряжена со многими крайними случаями. Браузер делает тяжелую работу здесь, что делает шифрование более доступным для веб-разработчиков и, следовательно, упрощает реализацию конфиденциальности с помощью зашифрованных данных. Как описывает Excalidraw в своей статье, ключ шифрования остается на стороне клиента, поскольку он является частью фрагмента URL-адреса: когда браузер посещает URL-адрес https://example.com/path?param=1#fraghere , путь URL-адрес ( /path ) и параметры ( param=1 ) передаются на сервер ( example.com ), а фрагмент ( fraghere ) — нет, поэтому сервер его никогда не видит. Это означает, что даже если зашифрованные данные проходят через сервер, ключ шифрования не проходит, и, таким образом, конфиденциальность сохраняется, поскольку данные полностью зашифрованы.
Ограничения
Этот подход к шифрованию пользовательских данных не является надежным. Это способствует повышению доверия к пользователям, но не может полностью заменить его. Вашим пользователям по-прежнему придется доверять вашему сервису, потому что вы можете в любой момент заменить клиентский JavaScript на какой-то немного похожий JavaScript, который не обеспечивает непроницаемого шифрования данных; и хотя пользователь может определить, сделал ли это веб-сайт, который вы используете, сделать это чрезвычайно сложно. На практике вашим пользователям все равно придется верить, что вы не будете намеренно читать и злоупотреблять их данными, хотя и обещаете не делать этого. Однако демонстрация того, что данные зашифрованы и недоступны для чтения вами как (не злонамеренным) поставщиком услуг, может во многом помочь доказать, почему вам можно доверять.
Также важно помнить, что одна из целей сквозного шифрования — лишить вас, владельца сайта, возможности прочитать данные. Это хорошо для конфиденциальности, но также означает, что если возникнут проблемы, вы не сможете помочь. По сути, служба, использующая сквозное шифрование, возлагает на пользователя ответственность за ключи шифрования. (Это может быть неочевидно или явно, но у кого-то должен быть ключ, и если данные хранятся в тайне от вас, то это не вы.) Если эти ключи утеряны, вы ничем не сможете помочь, и вероятно, любые данные, зашифрованные с помощью этих ключей, также могут быть потеряны. Здесь существует тонкий баланс между конфиденциальностью и удобством использования: сохраняйте конфиденциальность данных от всех, используя шифрование, но также не вынуждайте пользователей быть экспертами в криптологии, которые безопасно управляют своими собственными ключами.
Шифрование в состоянии покоя
Помимо шифрования данных ваших пользователей при передаче, важно также рассмотреть возможность шифрования данных, которые вы храните на сервере. Это помогает защититься от утечки данных, поскольку любой, кто получит несанкционированный доступ к вашим сохраненным данным, будет иметь зашифрованные данные, и, будем надеяться, у него не будет ключей для расшифровки. Существует два разных и взаимодополняющих подхода к шифрованию хранящихся данных: шифрование, которое добавляете вы, и шифрование, которое добавляет ваш поставщик облачного хранилища (если вы используете поставщик облачного хранилища). Шифрование поставщика хранилища не обеспечивает значительной защиты от утечки данных через ваше программное обеспечение (поскольку шифрование поставщика хранилища обычно прозрачно для вас как пользователя его службы), но оно помогает против взломов, которые происходят в инфраструктуре поставщика. Часто его просто включить, и поэтому стоит подумать. Это поле быстро меняется, и ваша команда безопасности (или опытные инженеры в вашей команде) могут дать вам совет по этому поводу, но все поставщики облачных хранилищ предлагают шифрование в состоянии покоя для блочного хранилища Amazon S3 по настройке, Azure Storage и Google Cloud Storage. по умолчанию, а также для хранения данных базы данных AWS RDS , Azure SQL , Google Cloud SQL и других. Уточните это у своего поставщика облачного хранилища, если вы его используете. Самостоятельно выполнять шифрование хранящихся данных, чтобы защитить пользовательские данные от утечек данных, сложнее, поскольку логистика безопасного управления ключами шифрования и предоставления их коду, не делая их доступными для злоумышленников, является сложной задачей. Это не лучшее место для консультирования по вопросам безопасности на этом уровне; поговорите об этом со своими опытными в области безопасности инженерами или специальной командой или внешними агентствами безопасности.