Помимо регулярного резервного копирования на месте (хранящегося в огнестойком сейфе), раз в месяц мы также отправляем бэкапы за пределы сайта, зашифрованные с помощью AES. Так что, если наш сайт однажды будет разрушен, у нас, по крайней мере, будет одна из последних резервных копий для восстановления.
Только вот 128-битный ключ шифрования хранится только на месте, поэтому в случае настоящей катастрофы у нас фактически останется одна зашифрованная резервная копия и мы не сможем ее расшифровать.
Вопрос: какова наилучшая политика хранения ключа шифрования вне помещения?
Какой бы метод мы ни выбрали, он должен пройти аудит безопасности, так что «хранить копию дома» не подходит, а «хранить ее вместе с файлами бэкапа вне офиса», очевидно, противоречит цели их шифрования в первую очередь! Мы рассматриваем следующие варианты:
Банковская ячейка в банке.
Хранение в облаке или в географически отдельной сети в защищенной паролем форме (например, с помощью программ типа Keepass или Password Safe).
Конечно, при втором варианте возникает другой вопрос: как сохранить этот пароль в безопасности.
Ответ 1
Это будет очень субъективно. Думаю, нам нужно больше знать о вашей отрасли и специфических нормативных требованиях, чтобы дать хороший совет. То, что может быть достаточно для малого бизнеса в нерегулируемой отрасли, вероятно, не подойдет для крупного бизнеса в регулируемой отрасли.
Хранение ключа в сейфе может быть достаточным, учитывая, что банк должен проверять подлинность сторон, имеющих доступ к ячейке (обычно с помощью удостоверения личности с фотографией против списка уполномоченных сторон). Существует также физический ключ, необходимый для открытия ячейки. Если объединить эти атрибуты с тем, что ящик хранится в физически защищенном месте, то, на мой взгляд, это больше похоже на хорошее место для хранения ключа. Лично я больше беспокоюсь о том, что данные потеряются или будут украдены при доступе к сейфу. В качестве альтернативы вы можете приобрести сейф в другом банке с разными уполномоченными лицами, назначенными просто для хранения ключевого материала. Если у вас нет штатных юристов, вы можете обратиться к корпоративному юристу для хранения ключей.
Если говорить о технических аспектах, то существуют различные алгоритмы, позволяющие разбить секретный ключ на несколько частей так, что для восстановления секрета необходимо сотрудничество некоторого требуемого числа сторон (известные как пороговые схемы). Мне не известны практические реализации этих схем, но я уверен, что они существуют, если хорошо поискать. Вы можете распространить ключевой материал среди нескольких сторон так, что некоторая часть из них, собравшись вместе, сможет восстановить ключ. Компрометация любой отдельной части ключа (или любого меньшего числа частей, чем требует порог) не приведет к компрометации всего ключа.
Быстрый поиск обнаружил sharesecret, реализацию пороговой схемы под лицензией GPL.
Ответ 2
Практическое решение:
Создайте 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
Достаточно простого пакета «на случай катастрофы», который прилагается к резервным копиям.
Ответ 3
Я работаю в крупной организации, и у нас есть аналогичная система для шифрования резервных копий серверов сертификатов. У нас есть отдельная собственная система, которая защищает ключевые фразы для используемых нами ключей, общие идентификаторы и т. д.
Система требует «проверить» пароль ключа с нашим идентификатором пользователя, номером инцидента, причиной и т. д. Когда мы завершаем использование ключа, мы должны зарегистрировать его обратно. Если мы не проверим его заново через 24 часа, система автоматически проверит его и отправит по электронной почте менеджерам и т. д. сообщение о том, что мы не проверили его. Никто другой не может получить парольную фразу и т. д., пока мы проверяем его, и есть дополнительный вызов/ответ, когда мы проверяем его. Система размещена в совершенно другом месте. Для крупной организации это были оправданные затраты, но, возможно, существуют продукты, которые могут выполнять аналогичную работу значительно проще.
Ответ 4
Закрытый ключ может содержаться в небольшом текстовом файле, верно? Так что создайте учетную запись SpiderOak и синхронизируйте файл с облаком. Затем, в случае потери всего сайта из-за пожара и прочего, вы извлекаете резервные данные из другого удаленного места, потом входите на сайт SpiderOak и загружаете файл закрытого ключа. Все, что вам нужно для входа на сайт SpiderOak, – это имя пользователя и пароль. Так что, возможно, вы и кто-то еще в организации сможете запомнить это в голове. Выберите названия двух ваших любимых фильмов или что-то в этом роде. Запомнить несложно.
SpiderOak хорош тем, что для доступа к данным вам нужны только имя пользователя и пароль. Кроме того, он надежно зашифрован. Он также более безопасен, чем DropBox, потому что они не хранят ключи шифрования/дешифрования, не знают, что у вас за данные, и не имеют возможности получить доступ к данным в вашем аккаунте. Однако DropBox открыт для доступа к данным своих сотрудников или правительства США при наличии ордера. Если бы вы выбрали DropBox, вам пришлось бы поместить ключ в файл KeyPass и помнить пароль для доступа к нему.
В конце концов, это простой текстовый файл с ключом. Если кто-то другой получит доступ к этому ключу в SpiderOak или DropBox, он не будет иметь ни малейшего представления о том, для чего нужен ключ, что он открывает, или даже о местонахождении ваших физических резервных копий. Поэтому он практически бесполезен для них, даже если они его получат.
Security
