మీరు రహస్యాలు మరియు ప్రవేశపत్రాలను సురక్షితంగా ఎలా నిర్వహిస్తారు?

Question

Accepted Answer

**రహస్యాలు** (API కీలు, పాస్‌వర్డ్‌లు, టోకన్‌లు, ఎన్‌క్రిప్షన్ కీలు) సురక్షితంగా నిర్వహించాలి — కోడ్‌లో ఎన్నటికీ హార్డ్‌కోడ్ చేయవద్దు లేదా సంస్కరణ నియంత్రణకు కమిట్ చేయవద్దు, కానీ సురక్షితంగా నిల్వ చేయాలి మరియు ప్రాప్యమూ చేయాలి. పేలవమైన రహస్యాల నిర్వహణ చాలా సాధారణ, తీవ్రమైన ఉల్లంఘనల వనరు.

## ఎల్లప్పుడూ హార్డ్‌కోడ్ చేయవద్దు లేదా రహస్యాలను కమిట్ చేయవద్దు

```text
❌ NEVER hardcode secrets in source code or commit them to Git:
  → committed secrets are in the repo HISTORY (exposed even if "removed" later)
  → public repos / leaks expose them to attackers (bots scan GitHub for keys constantly)
  → a TOP cause of breaches (leaked AWS keys, database passwords, API tokens)
⚠️ If a secret IS committed/leaked → ROTATE it immediately (it's compromised)
```

## రహస్యాలను సరిగ్గా ఎలా నిర్వహించాలి

```text
✓ ENVIRONMENT VARIABLES → inject secrets at runtime (not in code); keep .env OUT of Git
  (.gitignore) — basic approach
✓ SECRETS MANAGERS → HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.:
  → centralized, encrypted, access-controlled, audited, rotatable secret storage
  → the robust approach for production (fetch secrets at runtime)
✓ Cloud/platform secret stores; CI/CD secret stores (for pipeline secrets)
```

## ఉత్తమ అభ్యాసాలు

```text
✓ LEAST PRIVILEGE — secrets grant only the access needed
✓ ROTATE secrets regularly (and immediately if leaked); prefer SHORT-LIVED credentials
  (e.g. temporary tokens, OIDC) over long-lived static keys
✓ Audit secret access; encrypt secrets at rest; don't LOG secrets
✓ SCAN for committed secrets (git-secrets, scanners in CI) to catch leaks early
✓ Separate secrets per environment (dev/staging/prod)
```

## ఇది ఎందుకు ముఖ్యమైనది

రహస్యాలను సురక్షితంగా నిర్వహించడానికి ఎలా చేయాలో అర్థం చేసుకోవడం ముఖ్యమైనది ఎందుకంటే **పేలవమైన రహస్యాల నిర్వహణ అనేది సాధారణ, తీవ్రమైన ఉల్లంఘనల వనరు**, కాబట్టి ఇది విలువైన, ఆచరణాత్మకంగా-కీలకమైన భద్రతా జ్ఞానం.

**ప్రధాన నియమం** — **కోడ్‌లో రహస్యాలను హార్డ్‌కోడ్ చేయవద్దు లేదా సంస్కరణ నియంత్రణకు కమిట్ చేయవద్దు** — అవసరమైనది ఎందుకంటే కమిట్ చేయబడిన రహస్యాలు రిపోజిటరీ చరిత్రలో ఉన్నాయి (తరువాత