Скажем, я хочу, чтобы некоторые части моего программного обеспечения были зашифрованы. Например, учетные данные для базы данных и т. Д. Мне нужно где-то хранить эти значения, но при этом в открытом тексте злоумышленнику будет легко получить несанкционированный доступ.
Однако если я зашифрую какой-нибудь открытый текст, то где мне хранить ключ? Ко всему, что имеет доступ к программному обеспечению, решительный злоумышленник будет иметь доступ, независимо от уровня запутанности:
- Скажем, ключ защищен моделью безопасности файловой системы; но как насчет (злонамеренных) суперпользователей или платформ, которые не обеспечивают такую точность?
- Или ключ жестко закодирован в двоичные файлы программного обеспечения, но его всегда можно декомпилировать, а как насчет программного обеспечения с открытым исходным кодом или интерпретируемого кода?
- Если ключ сгенерирован, такой алгоритм должен быть детерминированным (предположительно), и тогда та же самая проблема относится к семени.
- и т.п.
Криптография настолько сильна, насколько самое слабое звено в ее цепочке, и это кажется довольно слабым! Если предположить, что это правильный инструмент для работы (приколите меня), то как можно надежно защитить такую информацию?
Что касается правильного инструмента для работы: возможно, в случае, например, доступа к услугам (БД, серверы аутентификации и т. Д.), Вы бы ограничили доступ на этом уровне с помощью учетной записи службы, возможно, с некоторым уровнем обслуживания одитинг и т. д. и наличие учетных данных в открытом тексте - не такая проблема.
Мне, однако, это все еще кажется неадекватным: я не хочу, чтобы кто-то копался там, где его не должно быть!
источник
Ответы:
Прежде всего, я бы не назвал себя экспертом по безопасности, но я был в состоянии ответить на этот вопрос. То, что я обнаружил, меня немного удивило: не существует такого понятия, как полностью безопасная система . Ну, я думаю, что полностью безопасная система будет такой, где все серверы выключены :)
Кто-то, работавший со мной в то время, описал проектирование безопасной системы с точки зрения повышения планки для злоумышленников. Таким образом, каждый уровень защиты уменьшает возможность для атаки.
Например, даже если вы можете полностью защитить личный ключ, система не является полностью защищенной. Но правильное использование алгоритмов безопасности и наличие обновлений с исправлениями поднимает планку. Но, да, суперкомпьютер, достаточно мощный и достаточно времени, может сломать шифрование. Я уверен, что все это поняли, поэтому я вернусь к вопросу.
Вопрос ясен, поэтому я сначала попытаюсь рассмотреть каждый из ваших пунктов:
Да, если вы используете что-то вроде хранилища ключей Windows или секретный ключ TLS, зашифрованный паролем, вы можете получить доступ к пользователям, у которых есть пароль (или доступ) к закрытым ключам. Но, я думаю, вы согласитесь, что поднимает планку. ACL файловой системы (если реализованы должным образом) обеспечивают довольно хороший уровень защиты. И вы в состоянии лично проверить и узнать своих суперпользователей.
Да, я видел жестко закодированные ключи в двоичных файлах. Опять же, это немного поднимает планку. Кто-то, кто атакует эту систему (если это Java), должен понимать, что Java создает байт-код (и т. Д.) И должен понимать, как его декомпилировать, читая его. Если вы используете язык, который пишет непосредственно в машинный код, вы можете увидеть, что это поднимает планку немного выше. Это не идеальное решение для обеспечения безопасности, но может обеспечить некоторый уровень защиты.
Да, по существу, тогда алгоритм становится информацией о секретном ключе для создания секретного ключа. Так что теперь его нужно защищать.
Итак, я думаю, что вы определили основную проблему с любой политикой безопасности, управления ключами . Наличие ключевой политики управления имеет решающее значение для обеспечения безопасной системы. И это довольно широкая тема .
Итак, вопрос в том, насколько безопасной должна быть ваша система (и, следовательно, закрытый ключ)? Насколько высоко в вашей системе нужно поднимать планку?
Теперь, если вы готовы платить, есть некоторые люди, которые предлагают решения для этого. Мы закончили с использованием HSM (Hardware Security Module) . Это в основном защищенный от несанкционированного доступа сервер, содержащий аппаратный ключ. Этот ключ затем может быть использован для создания других ключей, используемых для шифрования. Идея здесь в том, что (если настроен правильно) ключ никогда не покидает HSM. HSM стоят дорого . Но в некоторых компаниях (скажем, защита данных кредитных карт) стоимость взлома намного выше. Итак, баланс существует.
Многие HSM используют карточки-ключи от обслуживания и администрирования функций. Кворум карточек-ключей (скажем, 5 из 9) необходимо физически поместить на сервер, чтобы сменить ключ. Таким образом, это поднимает планку довольно высоко, допуская нарушение только в случае сговора суперпользователей.
Там могут быть программные решения, которые предоставляют функции, аналогичные HSM, но я не знаю, что они собой представляют.
Я знаю, что это лишь ответит на вопрос, но я надеюсь, что это поможет.
источник
То, что вы хотите, не может быть сделано.
Вы в основном хотите защиту от людей, становящихся злыми. В вашей модели в какой-то момент кто-то получит доступ к ключу. Что если этот человек злой? Что делать, если вы злой? Видите, проблема, о которой вы говорите, неразрешима, за исключением отсутствия ключа вообще.
Поэтому не работайте с учетными данными базы данных, а другими механизмами аутентификации. Но несмотря ни на что, кому-то в какой-то момент необходим доступ к данным, и этот кто-то может быть злонамеренным.
источник
Это одна из тех проблем, которые не могут быть решены на том же уровне, на котором она была создана. Нам придется сделать шаг назад к нескольким фундаментальным философиям и следовать каскаду в надежде на решение.
Первая философия - «никогда не доверяй клиенту», а тесно связанная «если ты действительно хочешь сохранить секрет, никому не говори!»
Простой пример - учетные данные базы данных, как вы упомянули. Очевидно, что вы хотите, чтобы ваш клиент имел к нему доступ, но не какой-либо случайный Интернет-незнакомец, поэтому вам нужна какая-то система идентификации / проверки / входа в систему. Но основная предпосылка сокрытия этого - проблема: если сам пользователь должен обладать секретом, но вы не хотите, чтобы он знал, что это за секрет, все, что вы можете сделать, это спрятать его или затруднить его открытие ». секретный пакет ". Но они все еще могут узнать, так что вам лучше иметь план резервного копирования!
Самое простое решение - «не делай этого». Используйте учетные данные собственной учетной записи пользователя, чтобы разрешить клиентскому доступу к базе данных для программного обеспечения, и все. Если клиент становится злонамеренным, в худшем случае клиент может испортить свои собственные данные. Вот и все. Ваша база данных и система должны, самое большее, теперь содержать нежелательные записи от этого клиента, предназначенные исключительно для этого клиента, чтобы никто (включая вас) не страдал от беспорядков.
Существуют конкретные случаи использования, когда вы просто хотите, чтобы развернутое программное обеспечение что-то делало, но не все в мире могли подключаться и делать то же самое, но для этого вы просто скрывали секреты, и единственная веская причина сделать это - просто уменьшить головную боль или системную активность. Если ваша скрытая информация становится общеизвестной, лучше не ломать игру, а в худшем случае раздражать.
Если вы находитесь в одном из тех узких вариантов использования, это просто запутывание, которое все о становлении творческим. На самом деле это очень похоже на Code Golf - за исключением того, кто создает головоломку. Это все, что есть на самом деле - головоломка. И людям нравится решать головоломки, так что, опять же, будет лучше, если кто-то это поймет.
Но для большинства вещей в мире, это просто лучше работать , не заботясь о том , чтобы сохранить в тайне от пользователя. Вместо этого рекомендуется просто позволить пользователю раскрыть секрет, возложить на него ответственность за его защиту (например, на имя пользователя и пароль) и ограничить риск снижения вероятности того, что произойдет, если секрет будет раскрыт или подвергнут злоупотреблению.
В истинном «управлении ключами» в криптографическом контексте / контексте безопасности ответ «где хранить закрытый ключ» - «где-то еще!» Шифрование - это защита «точка-точка», а шифрование с использованием открытого и закрытого ключей предназначено для защиты информации, передаваемой во времени и пространстве. Закрытый ключ по своей природе уязвим, и его защита на самом деле не является вопросом перекрывающегося шифрования, а полностью защищает его от доступа. И если Система должна получить к ней доступ, то сама Система должна быть защищена - и вы не можете сделать это на компьютере клиента. Они всегда могут запустить виртуальную машину, сбросить оперативную память, перехватить сетевой трафик, установить прокси или виртуальный сетевой адаптер, декомпилировать исполняемые файлы ... добровольно не участвовать в этой проигрышной битве.
Теперь, если вам нужно сделать что-то вроде DRM, где ваша потребность хранить секрет на самом деле основана на контроле над использованием самого программного обеспечения, это совсем другая ситуация .
TLDR: Не храните секреты от пользователя, храните секреты с пользователем.
источник
Так работает одна из систем, которую я сейчас использую.
Конечно, защищенная служба работает где-то вне моей досягаемости. Он может работать на моей машине под другой учетной записью (и, возможно, в контейнере), но у меня есть привилегии суперпользователя, и тогда я могу попытаться обойти ограничения.
В основном, если у вас есть злонамеренный суперпользователь, все ставки отключены. И вы должны предполагать присутствие злоумышленника в вашей модели угроз.
Поэтому вам необходимо изолировать защищенный сервис от машины, доступной клиенту. Переместите защищенный сервис на машину, доступную только через сеть. Разместите своих клиентов на виртуальных машинах, которые не позволяют им обращаться к остальной физической машине, на которой работает ваша защищенная служба.
Если ваша защищенная служба не так ценна, чтобы иметь возможность командовать такими мерами, используйте любое хранилище зашифрованных ключей, которое предоставляет ОС: и Windows, Linux, и OSX имеют реализации ключей.
источник
На мой взгляд, единственный способ сохранить это в полной безопасности - это зашифровать ключ / пароль парольной фразой для разблокировки. Таким образом, парольная фраза должна указываться для каждого запуска или использования секрета. Не слишком полезна.
Другой способ может заключаться в том, чтобы система безопасности была самостоятельной учетной записью базы данных. Не очень масштабируемый ...
Если у каждого пользователя в системе есть своя учетная запись в БД, и эти учетные записи были предварительно созданы, так что приложение не имеет прав на создание учетных записей в БД от имени пользователя, хотя вы можете подойти довольно близко. Также это не очень хорошее решение, поэтому я полагаю, что вы должны иметь очень ограниченный доступ для чтения к файлам конфигурации и доверять своим суперпользователям.
источник