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
2FA support	Available	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.

• Shared 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

Permanenteng naka-store ang chat history sa mga server. Kahit sino pwedeng mag-search ng "ssh" o "key" para mahanap ang mga dating na-share na keys. Kahit ang mga accounts ng dating empleyado ay may naka-save pa ring history.

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 One-Time Transfers)

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
• 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
• Per-user access management
• Mas mataas ang initial setup cost

Paraan 4: Per-User Keys (Pinaka-rekomendado)

Kapag posible, mag-issue ng individual keys sa halip na mag-share ng isang key sa buong team.

Prinsipyo: Shared key < Individual keys
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

Key Rotation Schedule

Nililimitahan ng regular na key rotation ang validity window ng kahit anong na-compromise na key.

Uri ng Key	Inirerekomendang Rotation
Production server keys	90 araw
Deploy keys	90 araw
SSL certificates	Sa bawat renewal
API secrets	90 araw
Development/staging keys	180 araw

Security Checklist para sa DevOps Teams

• 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 Secret Memo