Минимальные требования для приложения безопасного обмена информацией

Бизнес работает на доверии. Чтобы обеспечить надежное доверие к обмену информацией в бизнесе, должны быть реализованы соответствующие параметры безопасности.

Цель

Эта статья призвана помочь ответственному лицу в разработке и команде продукта лучше понять, что означает Безопасность, и применить полученные знания на этапе разработки.

Фон

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

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

Принцип безопасности

Основываясь на проекте Open Web Application Security Project (OWASPS), существуют 3 основных принципа информационной безопасности. Принцип — это сущность, которая самоочевидна, не требуя оправдания или мнения. Три принципа безопасности:

1. Конфиденциальность
2. Честность
3. Доступность

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

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

Значение доступности зависит от проекта или контекста обсуждения. В общем, это касается того, на каком носителе и когда можно использовать информацию.

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

• Насколько безопасно отправлять Вам эту информацию?
• Верна ли информация, которую я получил от Вас?
• Как отправить вам эту информацию?

Требования

(1/3) Шифрование с использованием асимметричного ключа

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

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

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

Реализация шифрования с использованием асимметричного ключа для приложения обмена информацией заключается в следующем:

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

Какая польза от этого требования?

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

(2/3) Используйте цифровую подпись

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

Информация, передаваемая в цифровом виде, также требует подписи в цифровой форме. Цифровая подпись должна не только идентифицировать владельца информации, но и доказывать, что подпись действительна. Значение: только один объект может создать эту подпись.

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

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

Реализация цифровой подписи с использованием асимметричного ключа для приложения обмена информацией заключается в следующем:

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

Какая польза от этого требования?

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

(3/3) Независимость от приложений

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

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

Обычно такая практика разрешена, чтобы не упустить возможности для бизнеса. Я видел эту ситуацию десятки раз. С точки зрения безопасности немногие; вместо того, чтобы отвергать эту идею, мы должны убедиться, что эта идея также безопасна. Вы только посмотрите, как работает связь в Вооруженных силах. Они могут использовать свой стандартный инструмент обмена сообщениями, SMS, радио, электронную почту, телефон и даже распечатать на бумаге. Потому что, когда возникает критическая ситуация, должно быть доступно общение на любом возможном носителе. Используя эту концепцию, вы можете опубликовать доступ к своему банковскому счету в Instagram Feed и быть уверены, что никто не сможет его прочитать, кроме тех, кто владеет закрытым ключом.

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

Реализация Agnostic Application for Information Exchange Application следующая:

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

Какая польза от этого требования?

Безопасность должна быть доступна во всех сценариях и на всех средах для поддержки бизнес-операций.

Учебный пример

Приложение для обмена сообщениями: сквозное безопасное сообщение

Фаза инициации

1. Пользователи могут зарегистрироваться в службе обмена сообщениями после установки приложения, при регистрации используется номер телефона и адрес электронной почты в качестве идентификатора пользователя. Недавно зарегистрированный пользователь — Генри и Эдвард.
2. После успешной регистрации приложение создаст закрытый ключ и сохранит его на телефоне. Закрытый ключ никогда не покидает их телефон.
3. После успешного сохранения закрытого ключа приложение сгенерирует открытый ключ и загрузит его на сервер службы обмена сообщениями.

Этап общения

1. Пользователи могут добавлять других пользователей в качестве контакта, используя номер телефона или электронную почту. Генри добавляет Эдварда в качестве контактного лица.
2. После добавления контакта приложение получит открытый ключ добавленного контакта с сервера службы обмена сообщениями. Генри теперь владеет открытым ключом Эдварда, а Эдварду — открытым ключом Генри.
3. Когда Генри отправляет сообщение Эдварду, приложение шифрует сообщение, используя открытый ключ Эдварда, и подписывает зашифрованный текст, используя закрытый ключ Генри. Сообщение отправляется на сервер, прежде чем, наконец, доходит до телефона Эдварда.
4. Приложение в телефоне Эдварда проверяет с помощью открытого ключа Генри и расшифровывает сообщение с помощью его закрытого ключа, который хранится на его телефоне. Теперь Эдвард может прочитать содержание сообщения.

Альтернативный сценарий общения

1. Генри хочет отправить Эдварду защищенное сообщение. К сожалению, информация о его текущем местонахождении отсутствует в службе передачи данных в Интернете. Он может использовать только СМС.
2. Его приложение для обмена сообщениями не может отправлять сообщения без Интернета. Но у него есть возможность зашифровать сообщение. Он использует эту функцию и теперь получил зашифрованный текст (зашифрованное сообщение).
3. Генри отправляет зашифрованный текст по SMS. SMS отправляется оператору связи и наконец доходит до телефона Эдварда.
4. Эдвардс, зная, что он получает нечитаемое SMS от Генри, думая, что это должно быть безопасное сообщение. Он использует эту функцию в своем приложении для обмена сообщениями, чтобы расшифровать зашифрованный текст, полученный в SMS.
5. Теперь Эдвард может прочитать содержание сообщения.

Резюме

После выполнения трех требований мы сможем ответить на вопросы, основываясь на принципах безопасности.

• Насколько безопасно отправлять Вам эту информацию?
  Ответ: Да, только я мог прочитать информацию, которую Вы отправляете, потому что я единственный, у кого есть закрытый ключ для расшифровки сообщения, которое Вы отправляете (Конфиденциальность)
• Верна ли информация, которую я получил от Вас?
  Ответ: Да, я отправляю Вам цену за яблоко 2 доллара вместе с моей подписью. Вы можете проверить мою подпись, используя Открытый ключ, которым я вам поделился. Если это подтвердится, вы можете быть уверены, что цена на яблоко правильная и действительно от меня. (Целостность)
• Как отправить Вам эту информацию?
  Ответ: Вы можете отправить мне любую информацию через API, вложение в электронное письмо, SMS и даже распечатанные документы. Просто убедитесь, что вы зашифровали его и создали цифровую подпись. (Доступность)

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

Хотя он уже защищен, мы можем улучшить это требование, чтобы предоставлять аудиторскую информацию. Безопасность — это укрепление доверия, а за доверием должна следовать подотчетность.

Как вы думаете, что мы должны добавить к нашему требованию для поддержки подотчетности в будущем?