Gabay para sa Developer
5 min

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.

LOCK.PUB
Paano Ligtas na Mag-share ng SSH Keys at Certificates sa Iyong Team

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

Gumawa ng Memo

Gumawa ng Memo

Mga keyword

pag-share ng SSH key
seguridad ng SSH key
pag-share ng SSL certificate
pamamahala ng deploy key
secret memo para sa developer
seguridad ng DevOps
Paano Ligtas na Mag-share ng SSH Keys at Certificates sa Iyong Team | LOCK.PUB Blog