Как защитить закрытый ключ Вашего CA?
Вы ищете 'долю' только для чтения не 'зеркало'.
Переместите санированные фотографии в их собственную папку и затем совместно используйте это как только для чтения соответствующим пользователям.
Затем удалите их доступ из файлов/папок, Вы не хотите их достигание.
I worked at a company where the security of the CA key was critical to the continued success of the business. To this end the key was encrypted using a custom protocol that required at least 2 people to be present with physical tokens plugged into terminals to decrypt it(there were at least 5 of these tokens, any 2 combined would work). The terminals were physically separated from the actual machine with the CA key. The interface that the users had who decrypted it was a VT220 terminal that allowed them to input the decryption tokens and then select what they wanted to 'sign' with the key (never giving them access to the decrypted key). This system meant at least 4 people would have to work together to compromise the key, two token holders, the guy who had access to the data center, and another person who had root access on the server (because the decrypted key was never stored on the server only in memory you couldn't just steal the box, and the people with root to this specific server were not allowed DC access).
If you are interested in more details on this sort of setup Bruce Schneier has a great site covering computer security design and implementation:
He has also published a really good book Applied Cryptography that I found helped me understand the fundamentals of systems like this and how to architect more secure infrastructures (readable by people who don't wear pocket protectors):
Одно большое преимущество заключается в том, чтобы закрытый ключ CA на выделенном компьютере был полностью отключен от сети. Затем вы подписываете и, возможно, также генерируете новые сертификаты на этом компьютере, а затем использовать физический носитель для передачи новых сертификатов с машины CA.
Такая установка, конечно, также будет включать соображения относительно физической доступности машины, а также ограничения на разрешенные носители. USB-накопитель с большим количеством поездок, вероятно, не лучший выбор ...
(Это, кстати, очень наглядный пример компромисса между безопасностью и удобством.)
Я поддержал два других ответа и прокомментировал их, потому что я считаю, что оба они превосходны. Если вы решите использовать оба из них, и это вполне может быть подходящим, я настоятельно советую проявлять осторожность при первоначальной генерации ключа, поскольку лучшее время для взлома ключа - не используется (где могут быть применены многие стандартные повторяемые меры предосторожности), но во время генерации, которую гораздо легче подорвать, будучи разовым.
Это отличное руководство по проведению церемонии генерации ключей описывает некоторые из них. стандартные протоколы, которые могут помочь в обеспечении безопасности генерации ключей, хотя в основном они сводятся к (а) тому, чтобы все было засвидетельствовано несколькими компетентными аудиторами,
В зависимости от того, насколько серьезно вы настроены, вам следует рассмотреть возможность использования оборудования FIPS 140-2 ( http://en.wikipedia.org/wiki/FIPS_140#Security_levels ) для хранить ключи CA и резервные копии этих ключей. У вас должен быть один корневой ЦС и один промежуточный ЦС, чтобы корневой ЦС оставался автономным и физически защищенным. Корень необходим только для обновления или подписания новых промежуточных центров сертификации, тогда как промежуточные центры сертификации остаются в сети для повседневных операций. Как предлагали другие, важна генерация безопасных ключей и управление ключами с помощью n из m .
VeriSign (теперь Symantec) CPS является хорошим эталоном того, как коммерческий центр сертификации генерирует и защищает свои ключи. Посмотрите, в частности, главы 5 и 6: http://www.verisign.com/repository/cps/ . (Я работал в VeriSign несколько лет)
Кроме того, у NIST есть несколько хороших публикаций по управлению ключами ( http://csrc.nist.gov/publications/drafts/800-57/Draft_SP800-57 -Part1-Rev3_May2011.pdf ) и генерации, и ваша компания также должна иметь CPS, определяющий политики и методы, которые вы используете для управления своим центром сертификации. IETF предоставляет хороший шаблон: http://www.ietf.org/rfc/rfc2527.txt
Отличный вопрос и несколько отличных ответов.
Имейте в виду, что вы примерно на 90% опережаете большинство других людей, просто рассматривая этот вопрос, а не слепо забегая вперед.
Помня об этом и следуя другим советам, я бы просто добавил: don Не останавливайтесь на достигнутом; следите за новостями в области безопасности и криптографии как по общим вопросам, связанным с выпуском, отзывом, взломом сертификатов и т. д., так и, в первую очередь, по уязвимостям и проблемам с конкретными продуктами, которые вы используете для генерации ключей и управления ими.
Наконец: физическая безопасность . Сделать что-то «хакерское» не поможет, если я смогу просто устроиться на работу уборщиком по контракту в вашем здании, а затем однажды положить диск, содержащий ваш корневой сертификат, в свой карман. Вы удивитесь, сколько людей упускают это из виду.