आप secrets और credentials को सुरक्षित रूप से कैसे प्रबंधित करते हैं?

Question

Accepted Answer

**Secrets** (API keys, passwords, tokens, encryption keys) को सुरक्षित रूप से प्रबंधित किया जाना चाहिए — कभी कोड में hardcode नहीं किया जाना चाहिए या version control में commit नहीं किया जाना चाहिए, बल्कि सुरक्षित रूप से संग्रहीत और एक्सेस किया जाना चाहिए। खराब secrets management उल्लंघनों का एक सामान्य, गंभीर स्रोत है।

## मुख्य नियम: secrets को कभी hardcode या commit न करें

```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)
```

## secrets को ठीक से कैसे प्रबंधित करें

```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)
```

## यह क्यों महत्वपूर्ण है

secrets को सुरक्षित रूप से कैसे प्रबंधित करें यह समझना महत्वपूर्ण है क्योंकि **खराब secrets management उल्लंघनों का एक सामान्य, गंभीर स्रोत है**, इसलिए यह मूल्यवान, व्यावहारिक रूप से महत्वपूर्ण सुरक्षा ज्ञान है।

**मुख्य नियम** — **secrets को कभी कोड में hardcode न करें या version control में commit न करें** — आवश्यक है क्योंकि commit किए गए secrets रिपॉज़िटरी history में होते हैं (बाद में "हटाए जाने" पर भी उजागर), public repos और leaks उन्हें हमलावरों के सामने उजागर करते हैं (जो लगातार GitHub को keys के लिए scan करते हैं), जिससे लीक हुए secrets (AWS keys, database passwords, API tokens) **वास्तविक उल्लंघनों का एक शीर्ष कारण** बन जाते हैं।

इसे समझना, और कि **लीक हुए secrets को तुरंत rotate किया जाना चाहिए** (उजागर होने पर वे compromised होते हैं), महत्वपूर्ण ज्ञान है।

**secrets को ठीक से प्रबंधित** करने का तरीका समझना — **environment variables** (runtime पर secrets inject करना, `.env` फ़ाइलों को Git से बाहर रखना — बुनियादी दृष्टिकोण), **secrets managers** (Vault, AWS Secrets Manager, आदि जो केंद्रीकृत, एन्क्रिप्टेड, access-controlled, audited, rotatable storage प्रदान करते हैं — मज़बूत production दृष्टिकोण, runtime पर secrets fetch करना), और platform/CI secret stores — secrets को सही ढंग से संभालने के लिए आवश्यक है।

**सर्वोत्तम प्रथाओं** को समझना — least privilege (secrets जो न्यूनतम एक्सेस देते हैं), **secrets को rotate करना** नियमित रूप से और लीक होने पर तुरंत, long-lived static keys के बजाय **short-lived credentials** को प्राथमिकता देना (एक आधुनिक सर्वोत्तम प्रथा), एक्सेस का audit करना, secrets को log न करना, **committed secrets के लिए scan करना** (leaks को जल्दी पकड़ना), और प्रति environment secrets अलग करना — व्यापक secrets management को दर्शाता है।

secrets management एक ऊँचे दाँव वाला क्षेत्र है जहाँ सामान्य गलती (secrets को hardcode/commit करना) बड़े उल्लंघनों का कारण बनती है, जबकि उचित प्रबंधन महत्वपूर्ण credentials की रक्षा करता है।

चूँकि खराब secrets management एक सामान्य, गंभीर उल्लंघन स्रोत है और उचित प्रबंधन (कभी hardcode/commit न करना, env vars या secrets managers का उपयोग, rotating, short-lived credentials, scanning) महत्वपूर्ण credentials की रक्षा करता है, और चूँकि इसे समझना सुरक्षा के लिए आवश्यक है, secrets को सुरक्षित रूप से कैसे प्रबंधित करें यह समझना मूल्यवान, व्यावहारिक रूप से महत्वपूर्ण सुरक्षा ज्ञान है — एक बार-बार होने वाली, हानिकारक कमज़ोरी (लीक हुए secrets) को संबोधित करना, जहाँ उचित हैंडलिंग (secrets को कभी commit न करना, उचित storage का उपयोग, rotating, scanning) उन credential leaks को रोकने के लिए आवश्यक ज्ञान है जो कई वास्तविक उल्लंघनों का कारण बनते हैं।