Özel anahtarları senkronize etmek iyi bir fikir mi?

Ubuntu One'ın Güvenlik SSS'si , Canonical'in bağlantıları şifrelediğini ve kullanıcı verilerine erişimi kısıtladığını gösterir. Bu iyi ve güzel, ve çevrimiçi bankacılık ve özel anahtarlarımdan daha değerli diğer şeyler için SSL'ye güveniyorum.

Bununla ~/.ssh/id_dsabirlikte, buluta yerleştirmekten oldukça endişeliyim . Açıkçası, hiçbir sistem tamamen güvenli değildir. Öyleyse, bilgili bir parti riskleri pragmatik olarak ölçebilir mi?

Ubuntu One depolama alanı bir kullanıcı şifreleme anahtarıyla şifrelenmemiş

Dropbox gibi, Ubuntu One mağazası da özel bir parola ile şifrelenmez. Bu nedenle, birisinin güvenilir olmayan bir çalışan veya bir güvenlik ihlali ile verilerinize erişmesi teknik olarak mümkün olacaktır. Hala bir istek listesi olan UbuntuOne depolama veri şifreleme hakkındaki bu hata raporuna bakın .

Bu yüzden ~ / .ssh klasörümü buluta senkronize etmem. Daha sonra buluta gönderilecek şifreli bir kap ayarlamadıysanız, ancak ssh anahtarları için her zaman kullanışlı değildir. Ancak verilerinizi şifrelemenin yine de kullanışlı yollarını veriyorum:

• Ubuntu One'da depolama alanınızı koruma
• Cloud Storage'ı güvenle kullanma

Daha fazla bilgi

Ubuntu One bağlantı için şifreleme kullanıyor (aslında söylendiği gibi), temel olarak verilerin bir tür HTTPS üzerinden iletildiği anlamına gelir. EFF'nin (Electronic Frontier Foundation) izniyle HTTPS kullanırken kulak misafiri tarafından görülebilecek şeylerin gerçekten iyi yapılmış bir animasyonunu kullanabilirsiniz .

EFF animasyonundaki HTTPS düğmesine tıklayarak SSH anahtarlarınızı bir Dropbox veya Ubuntu One kapsayıcısına koyduğunuzda herkes için nelerin göründüğünü görebilirsiniz. Animasyonun söylediği gibi, site.com'daki (ör. One.ubuntu.com) birçok kişi verilerinizi (ve daha fazlasını) görüntüleyebilir. Tüm trafiğinizi yönlendirmek için Tor gibi bir şey kullansanız bile, site.com'daki kişilerin verilere erişebileceği anlamına gelir.

Bu yüzden verileri bilgisayarınızdan çıkmadan önce şifrelemeniz gerekir. Bu yüzden site.com'da bilmedikleri kimlik bilgileriyle şifrelenmiş olarak gelir. Tabii ki, güçlü bir şifreleme mekanizması kullanmanız gerekir, böylece site.com'daki kişilerin onu kırmasını son derece yavaşlatır.

Tabii ki bir banka durumunda, bankaya sizin için işlemesi için ödeme yaptığınız için paranızı şifreleyemezsiniz. Bu nedenle, bankanın BT sistemlerini fiziksel kasaları kadar güvenli hale getirmesine güvenmekten başka seçeneğiniz yoktur, böylece yalnızca küçük bir çalışan alt kümesi (hesabınızı yönetenler) verilerinizi görüntüleyebilir ve değiştirebilir.

~ / .Ssh / id_dsa'mı buluta yerleştirme konusunda oldukça endişeliyim.

Bir çözüm, Dropbox ile ssh ve gpg özel anahtarlarımla yaptığım şey: bunları bir arşive şifreleyin ve "ham" orijinalleri silin. Gerektiğinde, geçici olarak çıkarırım ve bittiğinde silerim.

Ben kullanım p7zip(AES-256 şifreleme kullanır), ancak diğer birçok araç kullanabilirsiniz. Bu şekilde, senkronize edilen tek şey şifreli arşivdir ve bulut depolama biriminden ödün verilmiş olsa bile, hiç kimse arşivin parolasını bilmedikçe özel anahtarları çıkaramaz.

Sık yaptığınız şeyler için hayatı kolaylaştırmak için (örneğin, gpg şifre çözme), geçici şifre çözme / kullanım / silme bölümünü işlemek için basit bir bash betiğine sahip olabilirsiniz; ayıklanan anahtarların yanlışlıkla senkronize edilmemesi için senkronizasyon cinlerini geçici olarak devre dışı bırakması gerekir.

Anahtarlarınızı Deja-dup yedekleme aracıyla U1'e kaydedebilirsiniz. Bir şifre ayarlarsanız, yedek dosyalar U1'de otomatik olarak şifrelenir. Bunu manuel olarak yapmanıza gerek yok.

Riski tanımlamak için farklı metrikler vardır, ancak anahtarın erişebileceği veri veya sistemlerin değerini dikkate almanız gerekir. Anahtar kaybolursa ve bazı varlıklar onu kullanabilirse erişim kazanılabilir mi? Korku gizli verilere maruz kalmak mı, veri kaybı mı, hesapların idari veya hesap düzeyinden ödün verilmesi olasılığı mı olacak? Gizli olmayan verileri yeniden oluşturabilirseniz ve gizli verilerinizin güvenli bir şekilde saklanması (örn. Şifrelenmiş) varsa, bu daha az baskı gerektirir. Sistemdeki farklı zayıflıklar için geçici çözümlerin numaralandırılmasının, genel riskinizi tanımlamanın bir parçası olduğunu düşünüyorum. Pragmatik olarak, özellikle anahtarları belirli aralıklarla döndürürseniz, .id_rsa'nızı depolamanın bir sorun olması pek olası değildir. Bu çeşitli varsayımlara dayanır, ancak yine de,

Basit çözüm. Bir çeşit. USB flash sürücü gibi bir şey kullanamıyorsanız, SSH anahtarınıza bir parola koyun. Anında iki faktörlü kimlik doğrulama (bir çeşit). Yeni bir ortak anahtar yüklemeniz bile gerekmez.