Vides mainīgo un noslēpumu droša pārvaldība Node.js

Noslēpumu noplūde ir viens no biežākajiem un postošākajiem drošības incidentiem — vidēji 6 miljoni noslēpumu tiek atklāti publiskos GitHub repozitorijos katru gadu. Vienīgais risinājums — sistematizēta pārvaldība no pirmās koda rindiņas.

.env failu pamati — lokālā izstrāde

Failu hierarhija un prioritātes

Node.js un Next.js ekosistēmā .env faili tiek ielādēti secīgi:

• `.env` — bāzes mainīgie (visām vidēm kopīgie)
• `.env.local` — lokālie override (vienmēr .gitignore)
• `.env.development` — izstrādes vides specifiski
• `.env.production` — produkcijas vides specifiski
• `.env.development.local` — personīgie izstrādes override

Next.js: `NEXT_PUBLIC_` prefikss padara mainīgo pieejamu klienta pusē. NEKAD nelieciet sensitīvus noslēpumus ar šo prefiksu — tie ir redzami pārlūka pirmkodā.

.env.example — dokumentācija

Versiju kontrolē glabājiet `.env.example` ar mainīgo nosaukumiem, aprakstiem un piemēru formātu (bez reālām vērtībām): `DATABASE_URL=postgresql://user:password@host:5432/dbname` `SUPABASE_ANON_KEY=your-anon-key-here` Šis fails kalpo kā dokumentācija jauniem komandas biedriem.

Tipēšana un validācija

`t3-env` vai `zod` validācija startēšanas laikā — ja trūkst obligāta mainīgā, aplikācija nepalaiž ar skaidru kļūdu, nevis crash producijā. TypeScript tipu drošība vides mainīgajiem.

Vides separācija — strikta izolācija

Nekad nepārkopēt starp vidēm

• Development — lokāla datubāze, test API atslēgas, mock servisi
• Staging — staging datubāze, staging API atslēgas, reāliem līdzīgi dati (anonimizēti)
• Production — produkcijas noslēpumi pieejami TIKAI CI/CD un production videi

Problēma: izstrādātājs kopē production `.env` uz lokālo mašīnu "lai debugotu". Risinājums: staging vide ar reālam līdzīgiem datiem, debug rīki, kas neprasa production piekļuvi.

Multi-tenant separācija

Ja apkalpo vairākus klientus — atsevišķas noslēpumu grupas katram klientam. Vault namespaces vai AWS Secrets Manager ar IAM politikām.

Noslēpumu glabātuves — ārpus koda

Platformu risinājumi (vienkāršākie)

• GitHub Secrets — šifrēti ar libsodium, pieejami tikai workflow izpildes laikā. Organization un repository līmeņa noslēpumi. Environment-specifisks ar required reviewers
• Vercel Environment Variables — preview/development/production separācija. Sensitive flag slēpj vērtību Dashboard
• Render Secret Files — fails tiek injicēts konteinerā boot laikā
• Netlify Environment Variables — līdzīgi Vercel, ar context-specific vērtībām

Uzlaboti risinājumi (uzņēmumiem)

• HashiCorp Vault — noslēpumu pārvaldības standarts. Dinamiska noslēpumu ģenerēšana (datubāzes paroles, kas mainās katru stundu), detalizētas audita liecības, granulāra piekļuves kontrole ar politikām, automātiska rotācija, PKI sertifikātu izsniegšana
• AWS Secrets Manager — natīva AWS integrācija, automātiska rotācija ar Lambda, IAM piekļuves kontrole, cena $0.40/noslēpums/mēn
• GCP Secret Manager — līdzīga funkcionalitāte GCP ekosistēmā ar IAM un versiju historiju
• Azure Key Vault — Microsoft ekosistēma, HSM backing, RBAC
• Doppler — moderna SaaS platforma: viena vieta visiem noslēpumiem visām vidēm. Automātiska sincronizācija ar Vercel, AWS, GCP. CLI rīks lokālai izstrādei: `doppler run -- npm start` injicē noslēpumus bez .env faila

Kuru izvēlēties?

• Solo/mazā komanda — platformas risinājumi (Vercel env vars, GitHub Secrets). Bezmaksas, pietiekami drošs
• Vidēja komanda — Doppler vai 1Password Secrets Automation. Centralizēts, SaaS
• Uzņēmums — Vault vai mākoņa sniedzēja Secret Manager. Pilna kontrole, compliance, audits

Rotācija un dzīves cikls

Rotācijas grafiks

• Datubāzes paroles — ik 30 dienas (ideāli automātiski ar Vault dynamic secrets)
• API atslēgas — ik 90 dienas. Daudzi SaaS (Stripe, Twilio) atbalsta vairākas aktīvas atslēgas pārejas periodam
• JWT signing keys — ik 90 dienas. Vecā atslēga verificē, jaunā paraksta (key rotation)
• Deploy tokeni — īslaicīgi, ideāli ģenerēti katram deployment (GitHub OIDC)
• Kompromitēti noslēpumi — NEKAVĒJOTIES. Nevis "rīt", nevis "pēc meeting"

Rotācijas process

1. Ģenerēt jaunu noslēpumu
2. Atjaunināt visās sistēmās, kas to lieto (CI/CD, serveri, trešo pušu servisi)
3. Pārbaudīt, ka jaunais darbojas (automātiski testi)
4. Anulēt veco (deaktivēt, dzēst)
5. Verificēt, ka vecā atslēga vairs nedarbojas

Grace period

Daudziem noslēpumiem — paritējas perioda atslēgas: vecā un jaunā darbojas vienlaicīgi 1–24h, lai izvairītos no dīkstāves. Pēc tam vecā tiek anulēta.

CI/CD integrācija — drošas prakses

Noslēpumu injicēšana

• GitHub Actions: `${{ secrets.DATABASE_URL }}` — injicēts kā vides mainīgais
• Vercel: automātiski pieejami deployment laikā pēc vides (preview/production)
• Docker: `--env-file` vai Docker Secrets (Swarm/Kubernetes)

Žurnālu maskēšana

Nekad nedrukājiet noslēpumus logos — GitHub Actions automātiski maskē reģistrētos secrets. Bet: `echo $SECRET | base64` apiet maskēšanu — uzmanīgi ar transformācijām. Custom logging: maskēšanas middleware, kas aizvietojiet noslēpumu vērtības ar ***.

Build laikā vs Runtime

• Build laikā — NEXT_PUBLIC_ mainīgie tiek iekompilēti JavaScript bundle. Mainīt tos prasa jaunu build
• Runtime — server-side mainīgie nolasāmi izpildes laikā. Var mainīt bez rebuild (Vercel env vars, Docker env)
• Labākā prakse — sensitīvi noslēpumi tikai runtime, nekad build-laikā

Koda skenēšana — automātiska aizsardzība

Pre-commit hooks

• git-secrets — AWS Secrets scanner kā pre-commit hook. Bloķē commit, ja atrod AWS atslēgas, tokenu patterns
• detect-secrets (Yelp) — plašāks detektors: generic API keys, high entropy strings, private keys. Baseline fails ļauj ignorēt zināmās viltus pozitīvas

CI pipeline skenēšana

• TruffleHog — skenē visu git vēsturi (ne tikai pēdējo commit) un atrod noplūdušus noslēpumus pagātnē. Git entropy pārbaude + regex patterns
• GitGuardian — reāllaika GitHub/GitLab monitorings. Brīdina sekundēs pēc noslēpuma push. Bezmaksas personīgiem repo
• Gitleaks — ātrs, CI-friendly, regulāru izteiksmju un entropijas bāzēts skeneris

Incident response — ja noslēpums noplūda

1. Nekavējoties anulēt — nevis tēmēt, cik ilgi ir bijis publisks
2. Rotēt — jauns noslēpums visur
3. Pārbaudīt piekļuves žurnālus — vai noslēpums tika izmantots neautorizēti
4. Novērtēt ietekmi — kādiem datiem/sistēmām bija piekļuve
5. Dokumentēt — post-incident review ar atrastajiem uzlabojumiem
6. Uzlabot procesus — kāpēc pre-commit hook nenostrādāja?