ரகசியத் தரவுகளின் பரவல் (Secrets Sprawl): 412 கசிந்த டோக்கன்களை நாங்கள் எவ்வாறு சரி செய்தோம்

மார்ச் 3 அன்று அதிகாலை 2:13 மணிக்கு ஒரு CI pipeline தோல்வியடைந்தது. 37 repositories-களில் 412 கசிந்த API டோக்கன்களை நாங்கள் கண்டறிந்தோம். இந்தத் தவறு $1.2 மில்லியன் மதிப்பிலான சாத்தியமான பாதுகாப்பு மீறல் செலவுகளை ஆபத்தில் தள்ளியது.

பெரும்பாலான குழுக்கள் ஒரு Vault அனைத்தையும் சரிசெய்துவிடும் என்று நினைக்கிறார்கள். உண்மையில், ஒரு Vault தாமதத்திற்கான (latency) ஒற்றைப் புள்ளித் தோல்வியாக (single point of failure) மாறக்கூடும். டோக்கன்கள் Vault-க்கு வெளியே இருக்கும்போது, அவை hard-coded மதிப்புகள் அல்லது environment variables-களைப் பயன்படுத்துகின்றன. இந்த மாற்று வழிகள் (fallbacks) audit logs-களில் தெரிவதில்லை.

இந்தத் தரவுப் பரவலின் பாதிப்பை எங்கள் அளவீடுகள் (metrics) காட்டின:

  • சாதாரண ரகசியத் தரவு மீட்டெடுப்பு (secret retrieval): ஒரு கோரிக்கைக்கு 48 ms.
  • கசிவின் போது: ஒரு கோரிக்கைக்கு 187 ms.

Build agents ஒவ்வொரு வேலையிலும் (job) தொலைவில் உள்ள ஒரு Vault cluster-லிருந்து 12 டோக்கன்களைப் பெற்றன. இது timeouts-களை ஏற்படுத்தியதுடன், டெவலப்பர்களை மாற்றங்களை கைமுறையாகத் திரும்பப் பெற (roll back) கட்டாயப்படுத்தியது. Latency என்பது வெறும் மெதுவான செயல்முறை மட்டுமல்ல. இது கிளவுட் கட்டணங்களை (cloud bills) அதிகப்படுத்தும் மற்றும் டெவலப்பர்களின் வேகத்தைக் குறைக்கும் ஒரு செலவு மையமாகும் (cost center).

ஒரு staging repo-வில் கசிந்த ஒரு AWS key-யை ஒரு தாக்குதல்தாரர் பயன்படுத்தினால், அது ஒரு மணி நேரத்திற்கு $120 செலவை ஏற்படுத்தக்கூடும். ஒரு மணி நேரத் தவறான பயன்பாடு, ஒரு காலாண்டு பாதுகாப்புத் தணிக்கையை (quarterly security audit) விட அதிகச் செலவை ஏற்படுத்தும்.

Static scanners எங்களை ஏமாற்றிவிட்டன. அவை எங்களது டோக்கன்களில் 78%-ஐக் கண்டறியத் தவறிவிட்டன. ஏன்? ஏனெனில் அந்த டோக்கன்கள் தேவைப்படும்போது உடனடியாக (on the fly) உருவாக்கப்பட்டன மற்றும் build artifacts-களில் இருந்தன, மூலக் குறியீட்டில் (source code) அல்ல. ஒரு GitHub Actions படி (step) ஒரு டோக்கனை Docker layer-க்குள் எழுதியது. Scanner எதையும் காணவில்லை, ஆனால் அந்த டோக்கன் வாரக்கணக்கில் எங்களது registry-யில் இருந்தது.

உங்களுக்குத் தேவைப்படுவது runtime visibility மட்டுமே, வெறும் static inspection அல்ல.

இதைச் சரிசெய்ய நாங்கள் ஒரு Lambda engine-ஐ உருவாக்கினோம். இது புதிய ரகசியங்களுக்காக CloudTrail-ஐக் கண்காணித்து, அவற்றை எங்களது Vault உடன் ஒப்பிடுகிறது. இதோ புதிய பணிப்பாய்வு (workflow):

  • ஒரு webhook மூலம் ரகசியத்தைக் கண்டறிதல்.
  • metadata-க்காக Vault-ஐக் கேட்டல் (query).
  • provider API மூலம் டோக்கனை செல்லாததாக்குதல் (invalidate).
  • கோப்பிலிருந்து ரகசியத்தை நீக்க ஒரு PR-ஐத் தொடங்குதல்.
  • CI-இல் தேர்ச்சி பெற்றால் PR-ஐத் தானாகவே இணைத்தல் (merge).

இந்த engine 27 நிமிடங்களில் 99.97% வெற்றி விகிதத்துடன் 412 டோக்கன்களை மாற்றியமைத்தது (rotated).

நாங்கள் இப்போது ரகசியத்தின் வயதைக் (secret age) கண்காணிக்கிறோம். ஒரு டோக்கன் 30 நாட்களுக்கு மேல் பழமையானதாக இருந்தால், build தோல்வியடையும். இந்த எளிய விதி, ஒரு காலாண்டில் புதிய கசிவுகளை 62% குறைத்தது. விசித்திரமான பயன்பாட்டு முறைகளைக் (usage patterns) கண்டறிய நாங்கள் an isolation-forest model-ஐயும் பயன்படுத்துகிறோம். ஒரு புதிய IP-யிலிருந்து டோக்கன் தோன்றினால், சிஸ்டம் அதை உடனடியாக மாற்றியமைக்கும்.

டோக்கன்களை கோப்புகளைப் போலக் கையாளுவதை நிறுத்துங்கள். ரகசியத்தின் வயது மற்றும் மீட்டெடுப்பு தாமதத்தை (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