Чи хороша ідея синхронізації приватних ключів?

Поширені запитання щодо безпеки Ubuntu One вказують, що Canonical шифрує з'єднання та обмежує доступ до даних користувачів. Це все добре і добре, і я довіряю SSL для інтернет-банкінгу та інших речей, більш цінних, ніж мої приватні ключі.

Це сказало, що я дуже занепокоєний тим, як поставити ~/.ssh/id_dsaсебе в хмару. Очевидно, жодна система не є повністю захищеною. Чи може тоді якась обізнана сторона прагматично кількісно оцінити ризики?

Сховище Ubuntu One не шифрується криптографічним ключем користувача

Як і Dropbox, магазин Ubuntu One не шифрується спеціальною парольною фразою. Тому технічно можливо, щоб хтось отримав доступ до ваших даних, або недобросовісний працівник, або порушення безпеки. Дивіться цей звіт про помилки щодо шифрування даних зберігання UbuntuOne, він все ще є списком бажань.

Тому я б не синхронізував свою папку ~ / .ssh до хмари. Якщо ви не встановите зашифрований контейнер, який потім надсилається до хмари, але тоді для ssh ключів це не завжди зручно. Але я надаю вам ще зручні способи шифрування даних:

• Захист пам’яті на Ubuntu One
• Безпечне використання хмарного сховища

Більше інформації

Ubuntu One використовує шифрування для з’єднання (як це сказано в факті), це означає, що в основному дані передаються через якусь HTTPS. Ви можете використовувати дійсно добре виконану анімацію того, що видно підслуховувачу під час використання HTTPS , люб’язно надавши EFF (Electronic Frontier Foundation) .

Натиснувши кнопку HTTPS на анімації EFF, ви зможете побачити, що видно всім, коли ви кладете свої SSH ключі в контейнер Dropbox або Ubuntu One. Як розповідає анімація, багато людей на сайті.com (наприклад, one.ubuntu.com) зможуть переглядати ваші дані (та багато іншого). Навіть якщо ви використовуєте щось на зразок Tor для маршрутизації всього вашого трафіку, це все одно означає, що люди на сайті.com можуть отримати доступ до даних.

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

Звичайно, якщо банк не зашифровує свої гроші, ви не можете шифрувати свої гроші, оскільки ви платите банку, щоб обробити це за вас. Таким чином, у вас немає іншого вибору, як довіряти банку, щоб зробити їх ІТ-систему настільки ж безпечною, як і їхні фізичні сховища, так що лише невелика група працівників (ті, що керують вашим обліковим записом) можуть переглядати та змінювати ваші дані.

Я дуже занепокоєний тим, як поставити мою ~ / .ssh / id_dsa в хмару.

Ну, одне рішення - це те, що я роблю зі своїми приватними ключами ssh та gpg за допомогою Dropbox: зашифруйте їх в архіві та видаліть "необроблені" оригінали. Коли потрібно, я тимчасово витягую його, а потім видаляю, коли закінчу.

Я використовую p7zip(використовує шифрування AES-256), але ви можете використовувати ряд інших інструментів. Таким чином, все, що синхронізується, - це зашифрований архів, і навіть якщо хмарне сховище порушено, ніхто не може витягнути приватні ключі, якщо не знає парольну фразу для архіву.

Щоб полегшити життя тим, що ви робите часто (скажімо, розшифрування gpg), ви можете мати простий скрипт bash, який обробляє частину тимчасового розшифрування / використання / видалення; він також повинен тимчасово відключити будь-які демони синхронізації, щоб вилучені ключі випадково не синхронізувалися.

Ви можете зберегти свої ключі на U1 через інструмент резервного копіювання Deja-dup. Якщо встановити пароль, файли резервного копіювання автоматично шифруються на U1. Не потрібно робити це вручну.

Існують різні доступні показники для визначення ризику, але вам потрібно враховувати значення даних або систем, до яких ключ може надати доступ. Якщо ключ загублений, і деяка сутність може використовувати його, щоб отримати доступ, що буде порушено? Чи буде страх перед викриттям конфіденційних даних, втратою даних, можливістю компрометувати облікові записи з адміністративного чи облікового рівня тощо? Якщо ви можете відтворити дані, які не є конфіденційними, і якщо у вас надійно зберігаються конфіденційні дані (наприклад, зашифровані), це менше натискання. Я думаю, що перерахування обхідних шляхів для різних слабких місць в системі є частиною визначення вашого ризику над усіма. Прагматично малоймовірно, що зберігання .id_rsa буде проблемою, особливо якщо ви повертаєте клавіші через деякий інтервал. Це спирається на кілька припущень, але, тим не менш,

Просте рішення. Різновид. Якщо ви не можете використовувати щось на зразок флеш-пам’яті USB, введіть пароль вашого ключа SSH. Миттєва двофакторна автентифікація (різновид). Вам навіть не потрібно завантажувати новий відкритий ключ.