సీక్రెట్స్ స్ప్రాల్ (Secrets Sprawl): 412 లీక్ అయిన టోకెన్లను మేము ఎలా సరిదిద్దాము
మార్చి 3వ తేదీ తెల్లవారుజామున 2:13 గంటలకు ఒక CI పైప్లైన్ విఫలమైంది. 37 రిపోజిటరీలలో 412 లీక్ అయిన API టోకెన్లను మేము కనుగొన్నాము. ఈ లోపం వల్ల $1.2 మిలియన్ల సంభావ్య బ్రీచ్ (breach) ఖర్చుల ముప్పు ఏర్పడింది.
చాలా టీమ్లు 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 నుండి 12 టోకెన్లను తీసుకున్నాయి. దీనివల్ల timeouts ఏర్పడి, డెవలపర్లు మార్పులను మాన్యువల్గా roll back చేయాల్సి వచ్చింది. Latency అనేది కేవలం ప్రక్రియ నెమ్మదించడం మాత్రమే కాదు. ఇది క్లౌడ్ బిల్లులను పెంచే మరియు డెవలపర్ల పని వేగాన్ని తగ్గించే ఒక cost center.
ఒక staging repoలో లీక్ అయిన ఒక AWS keyని దాడి చేసే వ్యక్తి ఉపయోగిస్తే, అది గంటకు $120 ఖర్చు చేయవచ్చు. కేవలం ఒక గంట పాటు జరిగే దుర్వినియోగం, త్రైమాసిక సెక్యూరిటీ ఆడిట్ కంటే ఎక్కువ ఖర్చుతో కూడుకున్నది.
Static scanners మాకు విఫలమయ్యాయి. అవి మా టోకెన్లలో 78% ను గుర్తించలేకపోయాయి. ఎందుకు? ఎందుకంటే ఆ టోకెన్లు on the fly జనరేట్ చేయబడ్డాయి మరియు అవి source codeలో కాకుండా build artifactsలో ఉన్నాయి. ఒక GitHub Actions step ఒక టోకెన్ను Docker layerలోకి రాసింది. Scanner ఏమీ చూడలేదు, కానీ ఆ టోకెన్ వారాల తరబడి మా registryలో ఉంది.
మీకు కేవలం static inspection మాత్రమే కాదు, runtime visibility కూడా అవసరం.
దీనిని పరిష్కరించడానికి మేము ఒక Lambda engineను నిర్మించాము. ఇది కొత్త సీక్రెట్ల కోసం CloudTrailని గమనిస్తుంది మరియు వాటిని మా Vaultతో పోల్చి చూస్తుంది. కొత్త workflow ఇక్కడ ఉంది:
- Webhook ద్వారా సీక్రెట్ను గుర్తించడం.
- Metadata కోసం Vaultని క్వెరీ చేయడం.
- Provider API ద్వారా టోకెన్ను invalidate చేయడం.
- ఫైల్ నుండి సీక్రెట్ను తొలగించడానికి ఒక PRని ఓపెన్ చేయడం.
- అది CIని పాస్ అయితే, ఆ PRని ఆటోమేటిక్గా merge చేయడం.
ఈ engine 27 నిమిషాలలో 99.97% success rateతో 412 టోకెన్లను rotate చేసింది.
మేము ఇప్పుడు secret ageను ట్రాక్ చేస్తున్నాము. ఒక టోకెన్ 30 రోజుల కంటే పాతదైతే, build విఫలమవుతుంది. ఈ సరళమైన నియమం ఒక త్రైమాసికంలో కొత్త లీక్లను 62% తగ్గించింది. వింత usage patternsలను గుర్తించడానికి మేము isolation-forest మోడల్ను కూడా ఉపయోగిస్తున్నాము. ఒక టోకెన్ కొత్త IP నుండి కనిపిస్తే, సిస్టమ్ దానిని వెంటనే rotate చేస్తుంది.
టోకెన్లను ఫైల్లలా చూడటం ఆపండి. Secret age మరియు retrieval latencyని కీలక మెట్రిక్లుగా పరిగణించండి. మీరు ఇలా చేస్తే, sprawl తగ్గుతుంది.
Optional learning community: https://t.me/GyaanSetuAi