Зашифрованные автономные резервные копии - где хранить ключ шифрования?

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

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

Вопрос: Какова наилучшая политика для хранения ключа шифрования вне сайта?

Какой бы метод мы ни выбрали, он должен пройти аудит безопасности, поэтому «хранить копию дома» не достаточно, а «хранить ее с внешними лентами», очевидно, в первую очередь не позволяет зашифровать их! Мы рассматриваем несколько вариантов:

• Сейф в банке
• Хранится в облаке или в географически отдельной сети в защищенной паролем форме (например, с использованием таких программ, как Keepass или Password Safe)

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

Это будет ужасно субъективно. Я думаю, что нам нужно больше знать о вашей отрасли и любых конкретных нормативных требованиях, чтобы дать хороший совет. То, что может быть достаточно для малого бизнеса в нерегулируемой отрасли, вероятно, не будет работать для крупного бизнеса в регулируемой отрасли.

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

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

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

Редактировать:

Быстрый поиск обнаружил sharesecret , реализацию схемы порогов GPL.

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

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

Практическое решение:

Создайте 4096-битный закрытый ключ ssh на USB-накопителе. затем создайте сильно зашифрованный файловый контейнер с использованием truecrypt и используйте ключ ssh в качестве «ключевого файла», т. е. зашифрованный диск разблокируется с помощью ключевого файла ssh. Смонтируйте контейнер файлов как раздел и создайте на нем файловую систему (т.е. mkfs.ext4.) Смонтируйте раздел и напишите файл паролей, который вы хотите заархивировать. Размонтируйте все и отправьте ваш USB-ключ вместе с вашими архивными лентами. Контейнер файлов, который вы создали, вы можете (довольно безопасно) поместить в учетную запись Dropbox операций, на дискету (кто бы на ней серьезно посмотрел?) И т. Д. По сути, без ключевого файла было бы невозможно получить доступ к резервной копии. и ключевой файл, хранящийся вне сайта, бесполезен без зашифрованного раздела, который вы храните ... где угодно.

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

https://www.ironkey.com/

http://www.pcworld.com/article/254816/the_best_encrypted_flash_drives.html

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

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

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

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

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

Wow сейфы, адвокаты и другие запутанные методы в этой теме. Все совершенно ненужно.

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

SpiderOak хорош, потому что вам нужны только имя пользователя и пароль для доступа к данным. Это также сильно зашифровано. Это также более безопасно, чем DropBox, потому что они не хранят ключи шифрования / дешифрования и не знают, что такое ваши данные, и не имеют доступа к вашим данным в вашей учетной записи. Однако DropBox открыт для своих сотрудников или правительства США для доступа к данным с ордером. Если вы работали с DropBox, вам нужно было бы поместить ключ в файл KeyPass и запомнить пароль для доступа к нему.

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