ರಹಸ್ಯಗಳ ಹರಡುವಿಕೆ (Secrets Sprawl): ನಾವು 412 ಸೋರಿಕೆಯಾದ ಟೋಕನ್‌ಗಳನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸಿದೆವು

ಮಾರ್ಚ್ 3 ರಂದು ಬೆಳಿಗ್ಗೆ 2:13 ಕ್ಕೆ ಒಂದು CI ಪೈಪ್‌ಲೈನ್ ವಿಫಲವಾಯಿತು. ನಾವು 37 ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ 412 ಸೋರಿಕೆಯಾದ API ಟೋಕನ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿದೆವು. ಈ ತಪ್ಪಿನಿಂದಾಗಿ $1.2 ಮಿಲಿಯನ್ ಮೊತ್ತದ ಸಂಭಾವ್ಯ ಭದ್ರತಾ ಉಲ್ಲಂಘನೆಯ ವೆಚ್ಚದ ಅಪಾಯ ಎದುರಾಯಿತು.

ಹೆಚ್ಚಿನ ತಂಡಗಳು Vault ಎಲ್ಲವನ್ನೂ ಪರಿಹರಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸುತ್ತವೆ. ವಾಸ್ತವದಲ್ಲಿ, latency ಗೆ Vault ಏಕೈಕ ವೈಫಲ್ಯದ ಬಿಂದುವಾಗಿ (single point of failure) ಪರಿಣಮಿಸಬಹುದು. ಟೋಕನ್‌ಗಳು Vault ಹೊರಗೆ ಇದ್ದಾಗ, ಅವು hard-coded ಮೌಲ್ಯಗಳನ್ನು ಅಥವಾ environment variables ಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಈ ಪರ್ಯಾಯ ವಿಧಾನಗಳು (fallbacks) audit logs ನಲ್ಲಿ ಕಂಡುಬರುವುದಿಲ್ಲ.

ಈ ಹರಡುವಿಕೆಯ ವೆಚ್ಚವನ್ನು ನಮ್ಮ ಮೆಟ್ರಿಕ್ಸ್‌ಗಳು ತೋರಿಸಿವೆ:

  • ಸಾಮಾನ್ಯ ರಹಸ್ಯ ಮರುಪಡೆಯುವಿಕೆ (secret retrieval): ಪ್ರತಿ ವಿನಂತಿಗೆ 48 ms.
  • ಸೋರಿಕೆಯ ಸಮಯದಲ್ಲಿ: ಪ್ರತಿ ವಿನಂತಿಗೆ 187 ms.

Build agents ಗಳು ದೂರದ Vault cluster ನಿಂದ ಪ್ರತಿ ಕೆಲಸಕ್ಕೆ (job) 12 ಟೋಕನ್‌ಗಳನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತಿದ್ದವು. ಇದು timeouts ಗೆ ಕಾರಣವಾಯಿತು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳು ಬದಲಾವಣೆಗಳನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ roll back ಮಾಡಲು ಒತ್ತಾಯಿಸಿತು. Latency ಎನ್ನುವುದು ಕೇವಲ ನಿಧಾನಗತಿಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲ. ಇದು cloud bills ಅನ್ನು ಹೆಚ್ಚಿಸುವ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳ ಕೆಲಸವನ್ನು ನಿಧಾನಗೊಳಿಸುವ ಒಂದು ವೆಚ್ಚದ ಕೇಂದ್ರವಾಗಿದೆ.

Staging repo ನಲ್ಲಿ ಸೋರಿಕೆಯಾದ ಒಂದು AWS key ಅನ್ನು ದಾಳಿಕೋರರು ಬಳಸಿದರೆ, ಅದು ಗಂಟೆಗೆ $120 ವೆಚ್ಚವಾಗಬಹುದು. ಕೇವಲ ಒಂದು ಗಂಟೆಯ ದುರುಪಯೋಗವು ತ್ರೈಮಾಸಿಕ ಭದ್ರತಾ ಆಡಿಟ್‌ನಿಂದಲೂ ಹೆಚ್ಚಿನ ವೆಚ್ಚವನ್ನು ಉಂಟುಮಾಡಬಹುದು.

Static scanners ನಮಗೆ ವಿಫಲವಾದವು. ಅವು ನಮ್ಮ ಟೋಕನ್‌ಗಳಲ್ಲಿ ಶೇಕಡಾ 78 ರಷ್ಟನ್ನು ಕಳೆದುಹಾಕಿದವು. ಏಕೆ? ಏಕೆಂದರೆ ಆ ಟೋಕನ್‌ಗಳನ್ನು ತಕ್ಷಣವೇ (on the fly) ಸೃಷ್ಟಿಸಲಾಗುತ್ತಿತ್ತು ಮತ್ತು ಅವು source code ನಲ್ಲಿ ಅಲ್ಲದೆ, build artifacts ಗಳಲ್ಲಿ ಇದ್ದವು. ಒಂದು GitHub Actions ಹಂತವು ಟೋಕನ್ ಅನ್ನು Docker layer ಗೆ ಬರೆಯಿತು. ಸ್ಕ್ಯಾನರ್‌ಗೆ ಏನೂ ಕಾಣಿಸಲಿಲ್ಲ, ಆದರೆ ಆ ಟೋಕನ್ ವಾರಗಟ್ಟಲೆ ನಮ್ಮ registry ನಲ್ಲಿ ಉಳಿದುಕೊಂಡಿತು.

ನಿಮಗೆ ಕೇವಲ static inspection ಮಾತ್ರವಲ್ಲದೆ, runtime visibility ಅಗತ್ಯವಿದೆ.

ಇದನ್ನು ಸರಿಪಡಿಸಲು ನಾವು ಒಂದು Lambda engine ಅನ್ನು ನಿರ್ಮಿಸಿದೆವು. ಇದು ಹೊಸ ರಹಸ್ಯಗಳಿಗಾಗಿ CloudTrail ಅನ್ನು ಗಮನಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ನಮ್ಮ Vault ನೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ. ಹೊಸ workflow ಇಲ್ಲಿದೆ:

  • Webhook ಮೂಲಕ ರಹಸ್ಯವನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು.
  • Metadata ಗಾಗಿ Vault ಅನ್ನು ಪ್ರಶ್ನಿಸುವುದು (Query).
  • Provider API ಮೂಲಕ ಟೋಕನ್ ಅನ್ನು ಅಮಾನ್ಯಗೊಳಿಸುವುದು (Invalidate).
  • ಫೈಲ್‌ನಿಂದ ರಹಸ್ಯವನ್ನು ತೆಗೆದುಹಾಕಲು PR ಅನ್ನು ತೆರೆಯುವುದು.
  • ಅದು CI ಅನ್ನು ಪಾಸಾಗುವಲ್ಲಿ, PR ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ merge ಮಾಡುವುದು.

ಈ engine 27 ನಿಮಿಷಗಳಲ್ಲಿ 99.97% ಯಶಸ್ಸಿನ ದರದಲ್ಲಿ 412 ಟೋಕನ್‌ಗಳನ್ನು rotate ಮಾಡಿತು.

ನಾವು ಈಗ secret age ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತೇವೆ. ಒಂದು ಟೋಕನ್ 30 ದಿನಗಳಿಗಿಂತ ಹಳೆಯದಾಗಿದ್ದರೆ, build ವಿಫಲವಾಗುತ್ತದೆ. ಈ ಸರಳ ನಿಯಮವು ಒಂದು ತ್ರೈಮಾಸಿಕದಲ್ಲಿ ಹೊಸ ಸೋರಿಕೆಗಳನ್ನು 62% ರಷ್ಟು ಕಡಿಮೆ ಮಾಡಿದೆ. ವಿಚಿತ್ರ ಬಳಕೆಯ ಮಾದರಿಗಳನ್ನು (weird usage patterns) ಗುರುತಿಸಲು ನಾವು isolation-forest model ಅನ್ನು ಸಹ ಬಳಸುತ್ತೇವೆ. ಒಂದು ಟೋಕನ್ ಹೊಸ IP ಇಂದ ಕಂಡುಬಂದರೆ, ಸಿಸ್ಟಮ್ ಅದನ್ನು ತಕ್ಷಣವೇ rotate ಮಾಡುತ್ತದೆ.

ಟೋಕನ್‌ಗಳನ್ನು ಫೈಲ್‌ಗಳಂತೆ ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. Secret age ಮತ್ತು retrieval latency ಅನ್ನು ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್ಸ್‌ಗಳಾಗಿ ಪರಿಗಣಿಸಿ. ನೀವು ಇದನ್ನು ಮಾಡಿದರೆ, ರಹಸ್ಯಗಳ ಹರಡುವಿಕೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ.

Source: https://dev.to/isabelle_dubuis_d858453d7/secrets-sprawl-how-we-cleaned-up-412-leaked-tokens-and-stopped-the-latency-bleed-k71

Optional learning community: https://t.me/GyaanSetuAi