Cara Berkongsi Kunci SSH dan Sijil Dengan Pasukan Anda Secara Selamat

"Hantarkan saja kunci SSH tu kat Slack." Setiap pasukan pembangunan pernah dengar ini. Akses pelayan diperlukan segera, ahli pasukan baru perlu menyediakan persekitaran mereka, deployment tinggal beberapa minit lagi dan seseorang tiada kunci.

Tetapi permintaan ini boleh menjadi permulaan insiden keselamatan yang serius.

Mengapa Perkongsian Kunci SSH Sangat Berbahaya

Kunci SSH bukan seperti kata laluan biasa. Ia memberikan akses penuh ke pelayan.

Faktor	Kata Laluan	Kunci SSH
Skop	Akaun tertentu	Keseluruhan pelayan
Impak jika bocor	Akaun tersebut	Semua data di pelayan
Kemudahan putaran	Tukar segera	Jana semula kunci + kemas kini semua pelayan
Sokongan 2FA	Tersedia	Kunci itu sendiri adalah pengesahan

Kunci SSH yang bocor mendedahkan setiap fail, setiap pangkalan data, setiap baris kod di pelayan. Ini berbeza secara asasnya daripada kebocoran kata laluan tunggal.

Bila Pasukan Perlu Berkongsi Kunci SSH

Secara realistik, ada sebab yang sah untuk berkongsi.

• Akses pelayan kongsi: Pelayan staging atau production yang diperlukan seluruh pasukan
• Kunci deploy: Kunci yang digunakan dalam pipeline CI/CD
• Sijil SSL: Pembaharuan sijil apabila tanggungjawab bertukar
• Rahsia API: Kelayakan pengesahan untuk integrasi pihak ketiga
• Kelayakan pangkalan data: Respons insiden kecemasan

Kaedah Perkongsian Berbahaya

1. DM Slack atau Discord

Sejarah perbualan disimpan secara kekal di pelayan. Sesiapa boleh mencari "ssh" atau "key" untuk mencari kunci yang pernah dikongsi.

2. E-mel

Diarkibkan secara kekal di pelayan mel dan tidak terkawal setelah dimajukan.

3. Google Drive atau Notion Kongsi

Kawalan akses terperinci sukar. Apabila fail disegerakkan, salinan tempatan kekal di peranti.

4. Dihantar ke Repositori Git

Kaedah paling berbahaya. Kunci kekal selama-lamanya dalam sejarah Git.

Kaedah Perkongsian Selamat

Kaedah 1: Memo Rahsia LOCK.PUB (Terbaik untuk Pemindahan Sekali)

1. Cipta memo rahsia di LOCK.PUB
2. Tampal kandungan kunci SSH atau sijil
3. Tetapkan kata laluan yang kuat
4. Tetapkan tempoh luput sependek mungkin (1-4 jam)
5. Hantar pautan melalui Slack, kongsi kata laluan melalui telefon
6. Selepas penerima menyimpan kunci secara tempatan, pautan luput

Kaedah 2: Pengurus Rahsia (Untuk Pasukan Lebih Besar)

Gunakan alat khusus seperti HashiCorp Vault, AWS Secrets Manager, atau Google Secret Manager.

Kaedah 3: Pihak Berkuasa Sijil SSH (Penyelesaian Jangka Panjang)

Daripada kunci kongsi, jalankan SSH CA yang mengeluarkan sijil individu kepada setiap pengguna.

Kaedah 4: Kunci Per Pengguna (Paling Disyorkan)

Apabila boleh, keluarkan kunci individu berbanding berkongsi satu kunci dalam pasukan.

Senarai Semak Apabila Anda Perlu Berkongsi

Sebelum Pemindahan

• Adakah anda telah tetapkan skop kebenaran minimum untuk kunci tersebut?
• Adakah kunci baca sahaja mencukupi?
• Bolehkah anda mengenakan sekatan IP?

Semasa Pemindahan

• Adakah anda menghantar kunci dan kata laluan melalui saluran berbeza?
• Adakah anda telah tetapkan tempoh luput sependek yang praktikal?

Selepas Pemindahan

• Sahkan penerima telah menyimpan kunci dengan selamat
• Sahkan pautan/memo yang dikongsi telah luput
• Pantau log penggunaan kunci

Jadual Putaran Kunci

Jenis Kunci	Putaran Disyorkan
Kunci pelayan production	90 hari
Kunci deploy	90 hari
Sijil SSL	Pada setiap pembaharuan
Rahsia API	90 hari
Kunci pembangunan/staging	180 hari

Ringkasan

Kunci SSH dan sijil adalah tulang belakang keselamatan pelayan. Menghantarnya melalui DM Slack atau e-mel adalah seperti menyematkan kunci rumah anda di papan buletin awam. Keluarkan kunci per pengguna apabila boleh. Apabila perkongsian tidak dapat dielakkan, gunakan memo rahsia dengan tempoh luput sependek mungkin.

Cipta memo rahsia sekarang untuk memindahkan kunci SSH dengan selamat.

Cipta Memo Rahsia