У меня есть пара закрытых ключей, которые я использую для администрирования инстансов Amazon EC2.
Я недавно потерял эти ключи, когда переустанавливал свой компьютер и обнаружил, что диск CD-RW, на который я сделал их резервную копию, не читается. Итак, я ищу немного более надежное решение для резервного копирования, и я думаю об использовании чего-то вроде Dropbox, потому что он использует SSL для конфиденциальности транспорта, а затем мои данные надежно хранятся.
Рискую ли я, создавая резервную копию своих ключей в такой службе, просто облажаться или быть поврежденным поставщиком, или я что-то еще пропустил?
Обновление: закрытые ключи имеют парольную фразу.
Также существует целая проблема «Dropbox может читать ваши вещи».
Что вам нужно сделать, так это зашифровать все, прежде чем помещать в Dropbox. Используйте что-то вроде KeePass в качестве хранилища секретов. Поставьте на него надежный пароль. KeePass выполняет шифрование локально, прежде чем поместить ваши данные в Dropbox. Затем вы будете использовать KeePass на других компьютерах для доступа к этим секретам.
Взгляни на:
https://superuser.com/questions/351525/is-keeping-a-keepass-file-in-dropbox-safe
Итак, шифрование локально. Используйте Dropbox для синхронизации этих зашифрованных файлов.
Если у вас есть закрытый ключ, который вы хотите сохранить в безопасности (я назову его ключ A, который также может быть набором закрытых ключей, зарезервированных вместе в один файл для обеспечения безопасности), создайте еще одну пару открытого / закрытого ключей (ключ B). .
Надежно скопируйте ключ B на несколько компьютеров, которым вы доверяете. Это можно сделать, создав временную пару открытого / закрытого ключей (ключ C) на конечном компьютере, перенеся открытый ключ C на исходный компьютер, зашифруя закрытый ключ B открытым ключом C и передав зашифрованный файл обратно в место назначения. компьютер, на котором закрытый ключ C может его расшифровать.
Используя закрытый ключ B на нескольких машинах, которым вы доверяете, зашифруйте закрытый ключ A открытым ключом B и поместите этот файл в безопасное хранилище (может быть в месте, которому вы не доверяете, например Dropbox).
Итак, если когда-либо Key A будет утерян / поврежден на вашей локальной рабочей станции, вы можете легко / быстро восстановить файл Key-B-encrypted-Key-A из Dropbox и расшифровать его для восстановления.
Если ключ B потерян / поврежден, у вас все еще есть ключ A, поэтому вы можете просто создать новый ключ D, чтобы заменить ключ B и снова выполнить настройку, или взять копию ключа B с одного из других компьютеров, которым вы доверяете сделал копии с него.
Если весь ваш компьютер потерян (вы потеряете ключ A и ключ B одновременно), вам нужно будет перейти на один из других компьютеров с ключом B на нем и взять файл Key-B-encrypted-Key-A из Dropbox и расшифруйте его, чтобы восстановить Ключ A.
Таким образом, этот план позволяет сохранить ключ A в безопасности с использованием традиционных вариантов резервного копирования, копирующих файл для многих (возможно, ненадежный) локаций, которые открывают возможности за пределами площадки, на суше и за пределами планеты. Это также означает, что ключ A можно быстро восстановить в случае необходимости, поскольку файл Key-B-encrypted-Key-A может передаваться без доверия, поэтому его можно прикреплять к электронным письмам и тому подобное.
Он сохраняет ключ B в безопасности, находясь на нескольких доверенный локации. Это ServerFault, а не SuperUser, мы, вероятно, говорим в корпоративной среде, поэтому мы надеемся, что у корпорации есть локальные и совместные серверы, которым они доверяют, которые могут размещать такие вещи. В дополнение к действующим, работающим серверам, копии ключа B могут быть помещены в автономное хранилище (резервные копии на магнитной ленте, архивные компакт-диски и т. Д.) В банковском хранилище или аналогичном. Восстановление ключа B становится более медленным процессом, так как вам, возможно, придется посетить хранилище банка, чтобы получить копию, и вы должны периодически проверять эти автономные резервные копии, чтобы вы могли поймать ситуацию, как исходный пост, где CD испортился.