Bendrinis srauto valdymas: paradigmos poslinkis link saugaus srauto optimizavimo pagal tipą

Paskirstytų sistemų pasaulyje srauto valdymas yra pagrindinis iššūkis. Dešimtmečius kūrėme vis sudėtingesnes sistemas, kad maršrutizuotume, subalansuotume ir apsaugotume tinklo paketus. Nuo paprastų aparatinės įrangos apkrovos balansavimo įrenginių iki modernių, funkcijų gausių paslaugų tinklelių, tikslas išliko nuoseklus: užtikrinti, kad užklausa A patikimai ir efektyviai pasiektų paslaugą B. Tačiau daugumoje šių sistemų išliko subtilus, bet didelis apribojimas: jos iš esmės yra agnostiškos tipui. Jos traktuoja programos duomenis kaip nepermatomą naudingąją apkrovą, priimdamos sprendimus, pagrįstus L3/L4 metaduomenimis, tokiais kaip IP adresai ir prievadai, arba geriausiu atveju, negiliais L7 duomenimis, tokiais kaip HTTP antraštės. Tai netrukus pasikeis.

Mes esame ant paradigmos poslinkio srauto valdyme slenksčio – pereiname nuo agnostiško tipo prie tipo informuoto pasaulio. Ši evoliucija, kurią mes vadiname Saugiu srauto optimizavimu pagal tipą, yra apie duomenų sutarčių ir schemų įterpimą tiesiai į pačią tinklo infrastruktūrą. Tai apie mūsų API šliuzų, paslaugų tinklelių ir krašto tarpinių serverių įgalinimą suprasti pačią duomenų, kuriuos jie maršrutizuoja, struktūrą ir prasmę. Tai nėra tik akademinis pratimas; tai praktinis būtinumas kuriant naujos kartos atsparias, saugias ir keičiamo dydžio pasaulines programas. Šiame įraše nagrinėjama, kodėl saugumas pagal tipą srauto sluoksnyje yra nauja riba, kaip suprojektuoti tokias sistemas ir kokią transformuojančią naudą tai suteikia.

Kelionė nuo paketų stūmimo iki L7 sąmoningumo

Norint įvertinti saugumo pagal tipą svarbą, naudinga pažvelgti į srauto valdymo evoliuciją. Kelionė buvo progresyviai gilesnio patikrinimo ir intelekto.

1 etapas: L3/L4 apkrovos balansavimo era

Interneto aušroje srauto valdymas buvo paprastas. Aparatinės įrangos apkrovos balansavimo įrenginys stovėjo priešais monolitinį žiniatinklio serverių telkinį. Jo užduotis buvo paskirstyti gaunamus TCP ryšius pagal paprastus algoritmus, tokius kaip apvalus arba mažiausiai ryšių. Jis veikė daugiausia OSI modelio 3 (IP) ir 4 (TCP/UDP) sluoksniuose. Apkrovos balansavimo įrenginys neturėjo HTTP, JSON arba gRPC sąvokos; jis tiesiog matė ryšius ir paketus. Tai buvo veiksminga savo laiku, tačiau programoms tapus sudėtingesnėms, jo apribojimai tapo akivaizdūs.

2 etapas: L7 intelekto iškilimas

Atsiradus mikroservisams ir sudėtingoms API, paprasto ryšio lygio balansavimo nebepakako. Turėjome priimti maršrutizavimo sprendimus, pagrįstus programos lygio duomenimis. Tai paskatino L7 tarpinių serverių ir programų pristatymo valdiklių (ADC) atsiradimą. Šios sistemos galėjo patikrinti HTTP antraštes, URL ir slapukus.

Tai leido sukurti galingas naujas galimybes:

• Maršrutizavimas pagal kelią: Maršrutizavimas /api/users į vartotojų paslaugą ir /api/orders į užsakymų paslaugą.
• Maršrutizavimas pagal pagrindinį kompiuterį: Srauto nukreipimas į emea.mycompany.com ir apac.mycompany.com į skirtingus serverių telkinius.
• Lipniosios sesijos: Slapukų naudojimas siekiant užtikrinti, kad vartotojas visada būtų siunčiamas į tą patį galinį serverį.

Tokios priemonės kaip NGINX, HAProxy, o vėliau ir debesų gimtosios tarpinės stotys, tokios kaip Envoy, tapo šiuolaikinių architektūrų kertiniais akmenimis. Paslaugų tinklelis, palaikomas šių L7 tarpinių serverių, žengė žingsnį toliau dislokuodamas juos kaip kiekvienos paslaugos šalutinius automobilius, sukuriant visur esantį, programoms sąmoningą tinklo audinį.

Ilgalaikė aklina dėmė: nepermatoma naudingoji apkrova

Nepaisant šios pažangos, išlieka kritinė aklina dėmė. Nors mūsų infrastruktūra supranta HTTP metodus ir antraštes, ji paprastai traktuoja užklausos turinį – faktinę duomenų naudingąją apkrovą – kaip nepermatomą baitų dėmę. Tarpinis serveris gali žinoti, kad jis maršrutizuoja POST užklausą į /api/v1/users su Content-Type: application/json antrašte, tačiau jis neturi jokio supratimo, kokia turėtų būti to JSON struktūra. Ar trūksta reikalingo `email` lauko? Ar `user_id` yra sveikasis skaičius, kai turėtų būti eilutė? Ar klientas siunčia v1 naudingąją apkrovą į v2 galinį punktą, kuris tikisi kitokios struktūros?

Šiandien ši patvirtinimo našta beveik visiškai tenka programos kodui. Kiekvienas mikroservisas turi patvirtinti, deserializuoti ir apdoroti neteisingai suformuotas užklausas. Tai sukelia daugybę problemų:

• Perteklinis kodas: Kiekviena paslauga rašo tą pačią standartinę patvirtinimo logiką.
• Nenuoseklus vykdymas: Skirtingos paslaugos, kurias galbūt parašė skirtingos komandos skirtingomis kalbomis, gali nenuosekliai vykdyti patvirtinimo taisykles.
• Vykdymo laiko klaidos: Neteisingai suformuotos užklausos prasiskverbia giliai į tinklą, sukeldamos paslaugų gedimus arba grąžindamos paslaptingas 500 klaidų, todėl sunku derinti.
• Saugumo pažeidžiamumai: Griežto įvesties patvirtinimo trūkumas krašte yra pagrindinis vektorius atakoms, tokioms kaip NoSQL injekcija, masinio priskyrimo pažeidžiamumai ir kiti naudingąja apkrova pagrįsti išnaudojimai.
• Švaistomi ištekliai: Galinė paslauga praleidžia CPU ciklus apdorodama užklausą tik tam, kad nustatytų, jog ji yra neteisinga ir turi būti atmesta.

Tipo saugumo apibrėžimas tinklo srautuose

Kai kūrėjai girdi „tipo saugumas“, jie dažnai galvoja apie programavimo kalbas, tokias kaip TypeScript, Rust arba Java, kurios pagauna su tipu susijusias klaidas kompiliavimo metu. Analogiška situacija yra neįtikėtinai tinkama srauto valdymui. Saugus srauto optimizavimas pagal tipą siekia pagauti duomenų sutarčių pažeidimus infrastruktūros krašte – tinklo „kompiliavimo laiko“ forma – prieš tai, kai jie gali sukelti vykdymo laiko klaidų jūsų paslaugose.

Tipo saugumas šiame kontekste yra pastatytas ant kelių pagrindinių ramsčių:

1. Schema pagrįstos duomenų sutartys

Tipo saugumo pagrindas yra oficialus duomenų struktūrų apibrėžimas. Užuot pasikliovus ad-hoc susitarimais ar dokumentacija, komandos naudoja kompiuteriu nuskaitomą schemos apibrėžimo kalbą (SDL), kad sukurtų nedviprasmišką API sutartį.

Populiarūs pasirinkimai yra:

• OpenAPI (anksčiau Swagger): RESTful API aprašymo standartas, apibrėžiantis galinius punktus, metodus, parametrus ir JSON/YAML schemas užklausos ir atsakymo turiniams.
• Protocol Buffers (Protobuf): Dvejetainis serializavimo formatas, sukurtas Google, dažnai naudojamas su gRPC. Jis yra agnostiškas kalbai ir labai efektyvus.
• JSON Schema: Žodynas, leidžiantis jums anotuoti ir patvirtinti JSON dokumentus.
• Apache Avro: Duomenų serializavimo sistema, populiari daug duomenų naudojančiose programose, ypač Apache Kafka ekosistemoje.

Ši schema tampa vieninteliu paslaugos duomenų modelio tiesos šaltiniu.

2. Infrastruktūros lygio patvirtinimas

Pagrindinis poslinkis yra patvirtinimo perkėlimas iš programos į infrastruktūrą. Duomenų plokštuma – jūsų API šliuzas arba paslaugų tinklelio tarpinės stotys – yra sukonfigūruota su schemomis, skirtomis paslaugoms, kurias ji saugo. Kai gaunama užklausa, tarpinis serveris atlieka dviejų etapų procesą prieš persiunčiant jį:

1. Deserializavimas: Jis analizuoja neapdorotą užklausos turinį (pvz., JSON eilutę arba Protobuf dvejetainius duomenis) į struktūrizuotą vaizdą.
2. Patvirtinimas: Jis patikrina šiuos struktūrizuotus duomenis pagal registruotą schemą. Ar jame yra visi reikiami laukai? Ar duomenų tipai yra teisingi (pvz., ar `age` yra skaičius)? Ar jis atitinka kokius nors apribojimus (pvz., ar `country_code` yra dviejų raidžių eilutė, atitinkanti iš anksto apibrėžtą sąrašą)?

Jei patvirtinimas nepavyksta, tarpinis serveris nedelsdamas atmeta užklausą su aprašomąja 4xx klaida (pvz., `400 Bloga užklausa`), įskaitant informaciją apie patvirtinimo nepavykimą. Neteisinga užklausa net nepasiekia programos paslaugos. Tai žinoma kaip Greito gedimo principas.

3. Tipo informuotas maršrutizavimas ir politikos vykdymas

Kai infrastruktūra supranta duomenų struktūrą, ji gali priimti daug protingesnius sprendimus. Tai gerokai viršija paprastą URL atitikimą.

• Turiniu pagrįstas maršrutizavimas: Galite sukurti maršrutizavimo taisykles, pagrįstas konkrečių laukų reikšmėmis naudingojoje apkrovoje. Pavyzdžiui: „Jei `request.body.user.tier == 'premium'`, maršrutizuokite į didelio našumo `premium-cluster`. Kitu atveju maršrutizuokite į `standard-cluster`." Tai yra daug patikimiau nei pasikliauti antrašte, kurią galima lengvai praleisti arba suklastoti.
• Granuliuotas politikos vykdymas: Saugumo ir verslo politika gali būti taikoma chirurginiu tikslumu. Pavyzdžiui, žiniatinklio programų užkardos (WAF) taisyklę galima sukonfigūruoti taip: „Blokuoti bet kokią `update_user_profile` užklausą, kurioje laukas `role` keičiamas į `admin`, nebent užklausa gaunama iš vidinio IP diapazono."
• Schemos versijų valdymas srauto perstūmimui: Migracijos metu galite maršrutizuoti srautą pagal schemos versiją. „Užklausos, atitinkančios `OrderSchema v1`, eina į senąjį monolitą, o užklausos, atitinkančios `OrderSchema v2`, siunčiamos į naują mikroservisą." Tai leidžia saugesnius, labiau kontroliuojamus diegimus.

Tipo saugios srauto valdymo sistemos projektavimas

Tokios sistemos įgyvendinimas reikalauja darnios architektūros su trimis pagrindiniais komponentais: schemos registru, sudėtinga valdymo plokštuma ir intelektualia duomenų plokštuma.

1. Schemos registras: tiesos šaltinis

Schemos registras yra centralizuota saugykla, kurioje saugomos ir versijuojamos visos jūsų organizacijos paslaugų duomenų sutartys (schemos). Jis veikia kaip neginčijamas paslaugų bendravimo tiesos šaltinis.

• Centralizavimas: Pateikia vieną vietą visoms komandoms atrasti ir atgauti schemas, užkertant kelią schemos fragmentacijai.
• Versijų valdymas: Valdo schemų evoliuciją laikui bėgant (pvz., v1, v2, v2.1). Tai labai svarbu tvarkant atgalinį ir pirmyninį suderinamumą.
• Suderinamumo patikrinimai: Geras schemos registras gali vykdyti suderinamumo taisykles. Pavyzdžiui, jis gali neleisti kūrėjui įkelti naujos schemos versijos, kuri sugadintų esamus klientus (pvz., ištrinant reikiamą lauką). Confluent's Schema Registry for Avro yra gerai žinomas pavyzdys duomenų srautinio perdavimo pasaulyje, kuris suteikia šias galimybes.

2. Valdymo plokštuma: operacijos smegenys

Valdymo plokštuma yra konfigūracijos ir valdymo centras. Čia operatoriai ir kūrėjai apibrėžia politiką ir maršrutizavimo taisykles. Tipo saugioje sistemoje valdymo plokštumos vaidmuo yra padidintas.

• Politikos apibrėžimas: Ji suteikia API arba vartotojo sąsają aukšto lygio ketinimų apibrėžimui, tokių kaip „Patvirtinti visą srautą į `payment-service` pagal `PaymentRequestSchema v3`."
• Schemos integravimas: Ji integruojama su schemos registru, kad gautų reikiamas schemas.
• Konfigūracijos kompiliavimas: Ji paima aukšto lygio ketinimą ir atitinkamas schemas ir kompiliuoja jas į žemo lygio, konkrečias konfigūracijas, kurias gali suprasti duomenų plokštumos tarpinės stotys. Tai yra „tinklo kompiliavimo laiko“ žingsnis. Jei operatorius bando sukurti taisyklę, nurodančią neegzistuojantį lauką (pvz., `request.body.user.t_ier` su klaida), valdymo plokštuma gali atmesti ją konfigūravimo metu.
• Konfigūracijos paskirstymas: Ji saugiai nustumia sukauptą konfigūraciją į visas atitinkamas tarpines stotis duomenų plokštumoje. Istio ir Open Policy Agent (OPA) yra galingų valdymo plokštumos technologijų pavyzdžiai.

3. Duomenų plokštuma: vykdytojai

Duomenų plokštumą sudaro tinklo tarpinės stotys (pvz., Envoy, NGINX), kurios yra kiekvienos užklausos kelyje. Jie gauna savo konfigūraciją iš valdymo plokštumos ir vykdo taisykles tiesioginiam srautui.

• Dinaminė konfigūracija: Tarpinės stotys turi sugebėti atnaujinti savo konfigūraciją dinamiškai, nenutraukiant ryšių. Envoy xDS API yra aukso standartas šiuo atžvilgiu.
• Didelio našumo patvirtinimas: Patvirtinimas prideda pridėtinės apkrovos. Tarpinės stotys turi būti labai efektyvios deserializuojant ir patvirtinant naudingąsias apkrovas, kad sumažėtų latentinis periodas. Tai dažnai pasiekiama naudojant didelio našumo bibliotekas, parašytas tokiomis kalbomis kaip C++ arba Rust, kartais integruojamas per WebAssembly (Wasm).
• Turtinga telemetrija: Kai užklausa atmetama dėl patvirtinimo nepavykimo, tarpinis serveris turėtų išspausdinti išsamius žurnalus ir metriką. Ši telemetrija yra neįkainojama derinimui ir stebėjimui, leidžianti komandoms greitai nustatyti netinkamai veikiančius klientus ar integravimo problemas.

Transformuojanti saugaus srauto optimizavimo pagal tipą nauda

Tipo saugaus požiūrio į srauto valdymą priėmimas nėra tik dar vieno patvirtinimo sluoksnio pridėjimas; tai iš esmės gerina tai, kaip kuriame ir valdome paskirstytas sistemas.

Patobulintas patikimumas ir atsparumas

Perkėlus sutarčių vykdymą į tinklo kraštą, sukuriate galingą gynybinį perimetrą. Neteisingi duomenys sustabdomi, kol jie negali sukelti kaskadinių gedimų. Šis „perkelti į kairę“ požiūris į duomenų patvirtinimą reiškia, kad klaidos pagaunamos anksčiau, jas lengviau diagnozuoti ir jos turi mažiau įtakos. Paslaugos tampa atsparesnės, nes jos gali pasitikėti, kad bet kuri gauta užklausa yra gerai suformuota, todėl jos gali sutelkti dėmesį tik į verslo logiką.

Drastiškai pagerinta saugumo padėtis

Ženkli dalis žiniatinklio pažeidžiamumų kyla dėl netinkamo įvesties patvirtinimo. Vykdydami griežtą schemą krašte, pagal numatytuosius nustatymus neutralizuojate visas atakų klases.

• Injekcijos atakos: Jei laukas schemoje apibrėžtas kaip boolean, neįmanoma įterpti eilutės, kurioje yra kenkėjiško kodo.
• Atsisakymo aptarnauti (DoS): Schemos gali vykdyti apribojimus masyvo ilgiams arba eilučių dydžiams, užkertant kelią atakoms, kuriose naudojamos per didelės naudingosios apkrovos atminties išsekimui.
• Duomenų atskleidimas: Galite apibrėžti ir atsakymo schemas, užtikrindami, kad paslaugos netyčia neatskleistų slaptų laukų. Tarpinis serveris gali filtruoti visus neatitinkančius laukus prieš atsakymą išsiunčiant klientui.

Pagreitintas kūrimas ir įtraukimas

Kai duomenų sutartys yra aiškios ir vykdomos infrastruktūros, kūrėjų produktyvumas smarkiai išauga.

• Aiškios sutartys: Priekinės ir galinės pusės komandos arba paslauga-paslaugai komandos turi nedviprasmišką sutartį, su kuria dirbti. Tai sumažina integravimo trintį ir nesusipratimus.
• Automatiškai generuojamas kodas: Schemas galima naudoti automatiškai generuoti kliento bibliotekas, serverio ruošinius ir dokumentaciją keliomis kalbomis, sutaupant daug kūrimo laiko.
• Greitesnis derinimas: Kai integravimas nepavyksta, kūrėjai gauna tiesioginį, tikslų atsiliepimą iš tinklo sluoksnio („Trūksta lauko 'productId'“), o ne bendrą 500 klaidą iš paslaugos.

Efektyvios ir optimizuotos sistemos

Patvirtinimo perkėlimas į bendrą infrastruktūros sluoksnį, kuris dažnai yra labai optimizuotas šalutinis automobilis, parašytas C++, yra daug efektyvesnis nei tai, kad kiekviena paslauga, galbūt parašyta lėtesne, aiškinamąja kalba, tokia kaip Python arba Ruby, atliktų tą pačią užduotį. Tai atlaisvina programos CPU ciklus tam, kas svarbu: verslo logika. Be to, naudojant efektyvius dvejetainius formatus, tokius kaip Protobuf, vykdomus tinklo, galima žymiai sumažinti tinklo pralaidumą ir latentinį periodą, palyginti su išsamiu JSON.

Iššūkiai ir realaus pasaulio aspektai

Nors vizija yra įtikinama, kelias į įgyvendinimą turi savo iššūkių. Organizacijos, svarstančios šią architektūrą, turi planuoti jiems.

1. Našumo pridėtinė apkrova

Naudingosios apkrovos deserializavimas ir patvirtinimas nėra nemokami. Jie prideda latentinio periodo prie kiekvienos užklausos. Poveikis priklauso nuo naudingosios apkrovos dydžio, schemos sudėtingumo ir tarpinio serverio patvirtinimo variklio efektyvumo. Itin mažo latentinio periodo programoms ši pridėtinė apkrova gali būti susijusi. Švelninimo strategijos apima:

• Naudojant efektyvius dvejetainius formatus (Protobuf).
• Įgyvendinant patvirtinimo logiką didelio našumo Wasm moduliuose.
• Patvirtinimo taikymas pasirinktinai tik svarbiems galiniams punktams arba pavyzdiniu pagrindu.

2. Operacinis sudėtingumas

Schemos registro ir sudėtingesnės valdymo plokštumos įvedimas prideda naujų komponentų, kuriuos reikia valdyti, stebėti ir prižiūrėti. Tam reikia investuoti į infrastruktūros automatizavimą ir komandos patirtį. Pradinis operatorių mokymosi kreivė gali būti stati.

3. Schemos evoliucija ir valdymas

Tai, be abejo, yra didžiausias socialinis ir techninis iššūkis. Kas valdo schemas? Kaip siūlomi, peržiūrimi ir diegiami pakeitimai? Kaip valdyti schemos versijų valdymą nepažeidžiant klientų? Tvirto valdymo modelis yra būtinas. Komandos turi būti apmokytos geriausios praktikos atžvilgiu dėl atgalinių ir pirmyninių suderinamų schemos pakeitimų. Schemos registras turi pateikti priemones šioms valdymo taisyklėms vykdyti.

4. Įrankių ekosistema

Nors visi atskiri komponentai egzistuoja (Envoy duomenų plokštumai, OpenAPI/Protobuf schemoms, OPA politikai), visiškai integruoti, raktai į saugų srauto valdymą vis dar atsiranda. Daugelis organizacijų, tokių kaip didžiosios pasaulinės technologijų įmonės, turėjo pasistatyti dideles šio įrankio dalis įmonės viduje. Tačiau atvirojo kodo bendruomenė sparčiai juda šia kryptimi, o paslaugų tinklelio projektai vis dažniau prideda sudėtingesnių patvirtinimo galimybių.

Ateitis yra sąmoninga tipui

Perėjimas nuo tipo agnostiško prie tipo saugaus srauto valdymo nėra klausimas, ar, bet kada. Tai reiškia loginį mūsų tinklo infrastruktūros subrendimą, paverčiant ją iš paprasto paketų stūmėjo į intelektualų, kontekstą suprantantį mūsų paskirstytų sistemų sargą. Įterpdami duomenų sutartis tiesiai į tinklo audinį, kuriame kuriame sistemas, kurios yra patikimesnės pagal projektą, saugesnės pagal numatytuosius nustatymus ir efektyvesnės savo veikloje.

Kelionė reikalauja strateginių investicijų į įrankius, architektūrą ir kultūrą. Tai reikalauja, kad mes traktuotume savo duomenų schemas ne kaip paprastą dokumentaciją, o kaip pirmos klasės, vykdytinus mūsų infrastruktūros piliečius. Bet kuriai pasaulinei organizacijai, rimtai nusiteikusiai keisti savo mikroservisų architektūros mastą, optimizuoti kūrėjų greitį ir kurti tikrai atsparias sistemas, laikas pradėti tyrinėti saugų srauto optimizavimą pagal tipą yra dabar. Ateities srauto valdymas ne tik maršrutizuoja jūsų duomenis; jis juos supranta.