Securitate, Infrastructură & OperațiuniInfrastructurăHeroku (Model Partajat)
Variabile de Mediu și Secretele
Secretele în Heroku config vars — nu în cod sursă; acces limitat per mediu și 2FA obligatoriu
Principiu
Toate secretele și credențialele aplicației SSM.ro sunt stocate exclusiv în Heroku config vars (variabile de mediu gestionate la nivelul aplicației Heroku). Niciun secret nu este integrat în codul sursă sau în repository-ul GitHub.
Ce Se Stochează în Config Vars
| Categorie secret | Conținut |
|---|---|
| Baze de date | URL conexiune Postgres și Redis (per mediu) |
| Servicii email | Token server Postmark |
| Semnătură electronică | Credențiale furnizor semnătură electronică (certificat client mTLS sau API token) |
| Observabilitate | Cheie cont New Relic, DSN Sentry |
| AWS | Credențiale IAM acces S3 și CloudWatch (least-privilege) |
| Sesiune aplicație | Cheie criptografică sesiune (per mediu) |
| Alte integrări | Orice alt token API sau cheie de serviciu |
Separare per Mediu
Producția și staging-ul au seturi complet separate de config vars:
- Credențialele de producție nu sunt niciodată utilizate în staging
- Stagingul utilizează instanțe de servicii distincte (Postgres, Redis, Postmark sandbox etc.)
Acces la Config Vars
Accesul la config vars Heroku este controlat prin:
- 2FA obligatoriu pe contul Heroku administrativ
- Acces limitat la membrii echipei cu rol administrativ pe aplicația Heroku
- Niciun secret nu apare în log-uri sau output de build
Rotație Secrete
La un eveniment de compromitere a credențialelor, procedura include:
- Rotația imediată a tuturor secretelor afectate (Heroku config vars, chei AWS, tokeni Postmark/furnizor semnătură electronică)
- Actualizarea în toate mediile afectate
- Verificarea că vechile credențiale nu mai sunt funcționale
Protecție Accidentală Expunere
- Branch protection pe GitHub: niciun merge direct în main fără PR review — reduce riscul ca un secret să fie commis accidental
- 2FA pe GitHub: obligatoriu pe conturile cu acces la repository
- Secretele nu sunt logate în output-ul aplicației sau al CI/CD
Bune Practici Aplicate
- Principiul least-privilege: credențialele AWS au permisiuni minime necesare (acces S3 restricționat la bucket-ul aplicației, CloudWatch write-only)
- Credențiale separate per furnizor: Postmark, furnizorul de semnătură electronică, New Relic, Sentry au tokeni dedicați, nu credențiale shared
- Scoped tokens per mediu: token-ul de server Postmark pentru producție este diferit de cel de staging