Paano Ligtas na Mag-share ng SSH Keys at Certificates sa Iyong Team
Buong server access ang ibinibigay ng SSH key. Alamin kung bakit delikado itong ipadala sa Slack o email, at paano gumamit ng nag-e-expire na secret memo.

Paano Ligtas na Mag-share ng SSH Keys at Certificates sa Iyong Team
"Paki-send na lang sa Slack yung SSH key." Lahat ng development team nakarinig na nito. Kailangan agad ng server access, may bagong team member na kailangang mag-setup ng environment, ilang minuto na lang ang deployment at may kulang pang key.
Pero ang isang simpleng request na ito ay maaaring maging simula ng malubhang security incident.
Bakit Sobrang Delikado ang SSH Key Sharing
Ang SSH keys ay hindi katulad ng ordinaryong passwords. Nagbibigay ito ng kumpletong access sa isang server.
| Salik | Password | SSH Key |
|---|---|---|
| Saklaw | Isang account lang | Buong server |
| Epekto kung ma-leak | Ang account na iyon lang | Lahat ng data sa server |
| Bilis ng pagpapalit | Mabilis palitan | Kailangang mag-regenerate ng key + i-update lahat ng servers |
| Suporta sa 2FA | Mayroon | Ang key mismo ang authentication |
Kapag na-leak ang SSH key, nakalantad ang bawat file, bawat database, bawat code sa server. Malaki ang pagkakaiba nito sa isang simpleng password leak.
Kailan Kailangan Mag-share ng SSH Keys ang mga Team
Sa totoo lang, may mga lehitimong dahilan para mag-share.
- Pinagsasaluhang server access: Staging o production servers na kailangan ng buong team
- Deploy keys: Mga key na ginagamit sa CI/CD pipelines
- SSL certificates: Pag-renew ng certificate kapag nagpalit ng responsibilidad
- API secrets: Authentication credentials para sa third-party integrations
- Database credentials: Emergency incident response
Mga Delikadong Paraan ng Pag-share
1. Slack o Discord DMs
Walang end-to-end encryption ang alinmang serbisyo, at bilang default ay matagal na naka-store ang chat history sa kanilang mga server. Kahit sinong kasali sa usapan ay pwedeng mag-search ng "ssh" o "key" para mahanap ang mga dating na-share na keys. Kapag umalis ang isang empleyado, pwedeng i-deactivate ang account niya, pero nananatili sa workspace history ang mga key na natanggap at ipinadala niya.
2. Email
Permanenteng naka-archive sa mail servers at hindi na makokontrol kapag na-forward na. Isang mail server breach lang at mabubunyag lahat ng key na na-send doon.
3. Shared Google Drive o Notion
Mahirap ang granular access control. Kapag nag-sync ang mga files, nananatili ang mga local copies sa mga device. Halos imposibleng makuha lahat ng copies kapag umalis na ang isang tao sa team.
4. Na-commit sa Git Repository
Ang pinaka-delikadong paraan. Permanenteng nananatili ang mga key sa Git history. Kahit ang mga deleted files ay maaaring ma-recover mula sa history. Kung public ang repo, nakalantad ang key sa buong mundo.
Mga Ligtas na Paraan ng Pag-share
Paraan 1: LOCK.PUB Secret Memo (Pinakamabuti para sa Isang Beses na Paglilipat)
Ang pinaka-praktikal na solusyon kapag kailangan mong mag-transfer ng key nang isang beses lang.
1. Gumawa ng secret memo sa LOCK.PUB
2. I-paste ang SSH key o certificate content
3. Mag-set ng malakas na password
4. I-set ang pinakamaikling expiration na posible (1-4 na oras)
5. I-send ang link sa Slack, i-share ang password sa pamamagitan ng tawag
6. Pagkatapos ma-save ng recipient ang key, mag-e-expire na ang link
Mga benepisyo:
- Hindi naka-store ang key sa plaintext sa kahit anong persistent server
- Hindi na accessible pagkatapos mag-expire
- Walang key plaintext sa chat history
Paraan 2: Secrets Managers (Para sa Mas Malalaking Team)
Gumamit ng dedicated tools tulad ng HashiCorp Vault, AWS Secrets Manager, o Google Secret Manager.
- Kasama ang access control at audit logs
- Posible ang automated key rotation (built-in sa Vault at AWS; notification lang ng rotation ang ipinapadala ng Google Secret Manager, kaya ikaw ang gagawa ng mismong rotation)
- Ang gastos at setup complexity ang mga downside
Paraan 3: SSH Certificate Authority (Pangmatagalang Solusyon)
Sa halip na shared keys, mag-run ng SSH CA na nag-i-issue ng individual certificates sa bawat user.
- Inaalis ang pangangailangan ng key sharing
- Pamamahala ng access kada user
- Mas mataas ang paunang gastos sa setup
Paraan 4: Hiwalay na Key sa Bawat User (Pinaka-rekomendado)
Kapag posible, mag-issue ng individual keys sa halip na mag-share ng isang key sa buong team.
Prinsipyo: Pinagsasaluhang key < Hiwalay na key bawat user
Na-leak ang shared key → Apektado ang buong team
Na-leak ang individual key → Ang user na iyon lang ang apektado
Checklist Kapag Kailangan Talagang Mag-share
Kung hindi posible ang per-user keys at hindi maiiwasan ang pag-share, sundin ang checklist na ito.
Bago ang Transfer
- Naka-set ba ang minimum permission scope para sa key?
- Sapat na ba ang read-only key?
- Maaari bang mag-apply ng IP restrictions?
Habang Nagta-transfer
- Magkaiba ba ang channel ng pagpapadala ng key at password?
- Naka-set ba ang pinakamaikling praktikal na expiration?
- Maaari bang i-delete ng sender ang original pagkatapos ma-confirm ng recipient?
Pagkatapos ng Transfer
- I-confirm na ligtas na naka-store ng recipient ang key
- I-verify na nag-expire na ang shared link/memo
- I-monitor ang key usage logs
Iskedyul ng Key Rotation
Nililimitahan ng regular na key rotation ang validity window ng kahit anong na-compromise na key.
| Uri ng Key | Inirerekomendang Rotation |
|---|---|
| Mga key ng production server | 90 araw |
| Deploy keys | 90 araw |
| SSL certificates | Sa bawat renewal |
| API secrets | 90 araw |
| Mga key ng development/staging | 180 araw |
Checklist sa Seguridad para sa mga DevOps Team
- Gumagamit ba ng individual SSH keys para sa lahat ng servers?
- Kung may shared keys, naka-configure ba ang IP restrictions?
- Agad bang dine-deactivate ang keys ng mga umaalis na empleyado?
- May key rotation schedule ba?
- Na-commit ba kailanman ang SSH keys sa isang Git repo?
- May mga key ba na naka-store sa plaintext sa chat history?
- Gumagamit ba ng expiring channel para sa secret transfers?
Buod
Ang SSH keys at certificates ang pundasyon ng server security. Ang pagpapadala nito sa Slack DM o email ay parang pag-pin ng susi ng bahay mo sa public bulletin board. Mag-issue ng per-user keys kapag posible. Kapag hindi maiiwasan ang pag-share, gumamit ng secret memo na may pinakamaikling posibleng expiration.
Gumawa na ng secret memo ngayon para ligtas na mag-transfer ng SSH keys.
Gumawa ng Memo
Gumawa ng MemoMga keyword
Baka magustuhan mo rin
Mag-share ng secret online gamit ang password-protected link
Alamin kung paano mag-share ng secret, password, private note, file, image, audio, o request gamit ang secure link, expiration, access limits, at read receipts.
Secure request links: tumanggap ng files, photos, notes, at audio nang walang email attachments
Tumanggap ng dokumento, larawan, notes, at voice messages mula sa clients sa iisang link — naka-encrypt sa browser ng nagpapadala gamit ang key na ikaw lang ang makakapagbukas.
Paano Magpadala ng Files na Higit sa 25MB sa Email: 5 Paraan
Talunin ang 25MB attachment limit ng Gmail at Outlook. 5 libre at ligtas na paraan upang magpadala ng malalaking files sa email nang walang sign-up.