Uenezaji wa Siri: Jinsi Tulivyorekebisha Tokeni 412 Zilizovuja

Mchakato wa CI ulishindwa saa 2:13 usiku wa kuamkia Machi 3. Tuligundua tokeni 412 za API zilizovuja katika repositories 37. Hitilafu hii iliweka hatarini dola milioni 1.2 za gharama zinazoweza kutokana na uvunjifu wa usalama.

Timu nyingi hudhani kuwa Vault inatatua kila kitu. Kwa uhalisia, Vault inaweza kuwa kituo kimoja cha hitilafu kwa ajili ya ucheleweshaji (latency). Wakati tokeni zinapokuwa nje ya Vault, hutumia thamani zilizowekwa moja kwa moja (hard-coded values) au vigezo vya mazingira (environment variables). Mifumo hii mbadala haionekani kwenye logi za ukaguzi (audit logs).

Vipimo vyetu vilionyesha gharama ya uenezaji huu:

  • Upatikanaji wa siri wa kawaida: ms 48 kwa kila ombi.
  • Wakati wa uvujaji: ms 187 kwa kila ombi.

Wakala wa ujenzi (Build agents) walivuta tokeni 12 kwa kila kazi kutoka kwenye kikundi cha Vault (Vault cluster) kilichokuwa mbali. Hii ilisababisha muda wa kuisha (timeouts) na kuwalazimisha watengenezaji kurudisha nyuma mabadiliko (roll back changes) kwa mkono. Ucheleweshaji (latency) si mchakato wa polepole tu. Ni kituo cha gharama kinachoongeza bili za wingu (cloud bills) na kuwachelewesha watengenezaji.

Funguo moja ya AWS iliyovuja kwenye repository ya staging ingeweza kugharimu dola 120 kwa saa ikiwa mshambuliaji angeitumia. Saa moja tu ya matumizi mabaya inagharimu zaidi ya ukaguzi wa usalama wa robo mwaka.

Vichanganuzi tuli (Static scanners) vilitushindwa. Vilikosa 78% ya tokeni zetu. Kwa nini? Kwa sababu tokeni hizo zilikuwa zimetengenezwa papo hapo na zilikuwa katika bidhaa za ujenzi (build artifacts), si kwenye msimbo chanzo (source code). Hatua moja ya GitHub Actions iliandika tokeni kwenye tabaka la Docker (Docker layer). Kichanganuzi hakikuona kitu, lakini tokeni hiyo ilikaa kwenye rejista (registry) yetu kwa wiki kadhaa.

Unahitaji uoni wa wakati wa utendaji (runtime visibility), si ukaguzi tuli (static inspection) pekee.

Tulijenga injini ya Lambda ili kurekebisha hili. Inafuatilia CloudTrail kwa ajili ya siri mpya na kuzilinganisha na Vault yetu. Hapa kuna mtiririko mpya wa kazi (workflow):

  • Tambua siri kupitia webhook.
  • Uliza Vault kwa ajili ya metadata.
  • Batilisha tokeni kupitia API ya mtoa huduma.
  • Fungua PR ili kuondoa siri kwenye faili.
  • Unganisha PR kiotomatiki ikiwa itapita CI.

Injini hii ilibadilisha (rotated) tokeni 412 ndani ya dakika 27 ikiwa na kiwango cha mafanikio cha 99.97%.

Sasa tunafuatilia umri wa siri. Ikiwa tokeni ina umri zaidi ya siku 30, ujenzi unashindwa. Kanuni hii rahisi ilipunguza uvujaji mpya kwa 62% katika robo moja. Pia tunatumia mfano wa isolation-forest kuashiria mifumo isiyo ya kawaida ya matumizi. Ikiwa tokeni itaonekana kutoka kwenye IP mpya, mfumo unabadilisha (rotates) mara moja.

Acha kutendea tokeni kama faili. Chukulia umri wa siri na ucheleweshaji wa upatikanaji (retrieval latency) kama vipimo muhimu. Ukifanya hivi, uenezaji utapungua.

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

Jumuiya ya kujifunza ya hiari: https://t.me/GyaanSetuAi