Сегодня я менял свой сертификат AWS X.509 и закрытый ключ (не путать с парой закрытый / открытый ключ ssh) и решил, что хочу установить парольную фразу для моего закрытого ключа, чтобы лучше защитить его. Итак, я провел небольшое исследование и сказал:
openssl rsa -in awsprivatekey.pem -des3 -out awsprivatekey.pem.new
и ввел парольную фразу для закрытого ключа. После попытки использовать инструменты api ec2 я получил сообщение об ошибке:
java.io.IOException: DER length more than 4 bytes
Это стало очевидно, когда я исследовал тему и нашел эту ссылку Инструменты api ec2 не поддерживают закрытый ключ с паролем
Меня беспокоит отсутствие информации об этом и статус-кво незащищенных закрытых ключей с чем-то столь же важным, как Amazon EC2.
Есть предложения, как лучше защитить мой закрытый ключ?
Я проводил такую же комплексную проверку, и меня тоже беспокоит, что все клиентские инструменты и документация, похоже, продвигают плохие методы безопасности. Я отвечаю на вопрос: «Вы действительно хотите повторно вводить парольную фразу для каждой вводимой вами команды?» - да, или, по крайней мере, я счастлив, что для меня в него вошел такой инструмент, как ssh-agent. Я никогда не хочу находить какие-либо свои личные ключи или передаваемые фразы, лежащие в виде простого текста в моей файловой системе. Я удивлен, что стандартный ответ - это просто «зашифровать всю файловую систему».
Даже если я смонтирую и зашифрую только каталог .ec2 и спрячу все в нем, мне все равно придется быть осторожным, чтобы не следовать документации, которая предлагает установить мой секретный ключ в качестве переменной среды в моем сценарии bash_profile. Так что, возможно, я просто поместил его в скрипт в моем каталоге .ec2 и передал его в командной строке - о, подождите, теперь мой пароль находится в моей истории (я все еще не могу поверить, что os x недостаточно хорош, чтобы пропустить сохранение строк, которые я префикс пробелом). Так что мне действительно нужно зашифровать весь мой пользовательский каталог, чтобы быть в безопасности. И почему именно асимметричный процесс использования сертификатов x.509 устарел и заменен процессом аутентификации по «секретному ключу»? По крайней мере, первое позволяет мне хранить закрытый ключ в файле - второе требует, чтобы я передал его в качестве аргумента (значение которого наклеивается на всю мою историю и сценарии).
Проблема в том, что есть все эти отличные протоколы безопасности, но никто не хочет тратить время на их понимание. Вместо этого они просто хотят, чтобы все работало - в результате они слепо следуют какой-то пошаговой документации, написанной кем-то, кто слепо следовал чьей-то пошаговой документации. Никто не ставит под сомнение все это, потому что они этого не понимают и просто хотят, чтобы это работало. Результатом является распространение действительно плохих методов обеспечения безопасности.
Храните их на зашифрованном диске TrueCrypt. Они будут надежно храниться, пока они вам не понадобятся, и вы сможете установить их только тогда, когда они действительно понадобятся. TrueCrypt создает файл, который затем монтируется как виртуальный диск.
Редактировать: Если вам нужно защитить его с помощью кода, который не является интерактивным, вы, очевидно, можете зашифровать закрытый ключ и расшифровать его своим кодом приложения. Есть много примеры как расшифровать файл с помощью Java.