सिक्रेट्स स्प्रावल (Secrets Sprawl): आम्ही ४१२ लीक झालेले टोकन्स कसे दुरुस्त केले
३ मार्च रोजी पहाटे २:१३ वाजता एक CI पाइपलाइन फेल झाली. आम्हाला ३७ रिपॉझिटरीजमध्ये ४१२ लीक झालेले API टोकन्स आढळले. या त्रुटीमुळे $१.२ दशलक्ष इतक्या संभाव्य डेटा ब्रीचच्या खर्चाचा धोका निर्माण झाला होता.
बहुतेक टीम्सना वाटते की Vault सर्व समस्या सोडवते. प्रत्यक्षात, लॅटन्सीच्या (latency) बाबतीत Vault हे 'सिंगल पॉइंट ऑफ फेल्युअर' ठरू शकते. जेव्हा टोकन्स Vault च्या बाहेर असतात, तेव्हा ते हार्ड-कोडेड व्हॅल्यूज किंवा एन्व्हायरनमेंट व्हेरिएबल्सचा वापर करतात. हे फॉलबॅक ऑडिट लॉग्समध्ये दिसत नाहीत.
आमच्या मेट्रिक्सनी या स्प्रावलचा खर्च दर्शवला:
- सामान्य सिक्रेट रिट्रिव्हल: प्रति रिक्वेस्ट ४८ ms.
- लीक दरम्यान: प्रति रिक्वेस्ट १८७ ms.
बिल्ड एजंट्सने प्रत्येक जॉबसाठी एका दूरच्या Vault क्लस्टरमधून १२ टोकन्स खेचले. यामुळे टाइमआउट्स झाले आणि डेव्हलपर्सना मॅन्युअली बदल रोल बॅक करण्यास भाग पाडले. लॅटन्सी म्हणजे केवळ संथ प्रक्रिया नाही. तो एक 'कॉस्ट सेंटर' आहे जो क्लाउड बिले वाढवतो आणि डेव्हलपर्सचा वेग कमी करतो.
जर एखाद्या अटॅकरने स्टेजिंग रिपॉझिटरीमधील एक लीक झालेली AWS की वापरली, तर त्याचा खर्च तासाला $१२० असू शकतो. एका तासाचा गैरवापर हा त्रैमासिक सुरक्षा ऑडिटपेक्षाही जास्त महाग पडू शकतो.
स्टॅटिक स्कॅनर्स आम्हाला अपयशी ठरवून गेले. त्यांनी आमच्या ७८% टोकन्स मिस केले. का? कारण ते टोकन्स 'ऑन द फ्लाय' (on the fly) तयार केले गेले होते आणि ते सोर्स कोडमध्ये नसून बिल्ड आर्टिफॅक्ट्समध्ये होते. GitHub Actions च्या एका स्टेपने Docker लेयरमध्ये टोकन लिहिले होते. स्कॅनरला काहीही दिसले नाही, परंतु ते टोकन आठवडे आमच्या रजिस्ट्रीमध्ये राहिले.
तुम्हाला केवळ स्टॅटिक इन्स्पेक्शनची नाही, तर रनटाइम व्हिजिबिलिटीची गरज आहे.
हे दुरुस्त करण्यासाठी आम्ही एक Lambda इंजिन तयार केले. ते नवीन सिक्रेट्ससाठी CloudTrail वर लक्ष ठेवते आणि त्यांची तुलना आमच्या Vault शी करते. नवीन वर्कफ्लो खालीलप्रमाणे आहे:
- वेबहुकद्वारे (webhook) सिक्रेट शोधणे.
- मेटाडेटासाठी Vault ला क्वेरी करणे.
- प्रोव्हायडर API द्वारे टोकन इनव्हॅलिडेट करणे.
- फाईलमधून सिक्रेट काढण्यासाठी PR ओपन करणे.
- जर ते CI पास झाले, तर PR आपोआप मर्ज करणे.
या इंजिनने २७ मिनिटांत ९९.९७% यश दरासह ४१२ टोकन्स रोटेट केले.
आम्ही आता सिक्रेटच्या वयाचा (age) मागोवा घेतो. जर एखादे टोकन ३० दिवसांपेक्षा जुने असेल, तर बिल्ड फेल होते. या साध्या नियमामुळे एका तिमाहीत नवीन लीक ६२% ने कमी झाले. आम्ही विचित्र वापराचे पॅटर्न ओळखण्यासाठी 'आयसोलेशन-फॉरेस्ट' (isolation-forest) मॉडेल देखील वापरतो. जर एखादे टोकन नवीन IP वरून आले, तर सिस्टम ते त्वरित रोटेट करते.
टोकन्सना फाईल्सप्रमाणे वागवणे थांबवा. सिक्रेटचे वय आणि रिट्रिव्हल लॅटन्सी यांसारख्या गोष्टींना महत्त्वाचे मेट्रिक्स माना. जर तुम्ही असे केले, तर स्प्रावल कमी होईल.
Optional learning community: https://t.me/GyaanSetuAi