Kaip duomenų šifravimas gali supaprastinti infrastruktūros architektūrą
Produktų ir infrastruktūros inžinierių komandos ne visada suderinamos su saugumo inžinierių komandų interesais. Produktai ir infrastruktūra sutelkia dėmesį į verslo vertės didinimą ir praktinių sprendimų teikimą, o saugumas daugiausia dėmesio skiria aptikimui, prevencijai ir ištaisymui, kurie gali pasirodyti ne tokie vertingi iš karto. Kaip ir draudimo polisas, nėra visiškai aišku, kodėl verta pinigų ar pastangų, kai incidento dar nebuvo. Vietoj tradicinio pažeidžiamumų nustatymo, taisymo ir tolesnio atvejo valdymo ciklo, man pasirodė daug veiksmingiau propaguoti saugumo sprendimus, kurie taip pat teikia vertę verslui. Pavyzdžiui, naudojant OAuth ir IAM pagrįstą prieigą vietoj statinių raktų ir šifravimą vietoj išsamesnės prieigos kontrolės, galima žymiai supaprastinti infrastruktūrą, sumažinti sudėtingumą ir sumažinti veiklos naštą, todėl jie yra labai patrauklūs tiek produktų, tiek platformų inžinierių komandoms.
Pavyzdys: pakeiskite statinius raktus į IAM pagrįstą OAuth
Tradiciškai prieiga tarp sistemų įgyvendinama per statines raktų ir paslapčių poras. Nors šis metodas yra įprastas, jis dažnai sukelia patikimumo problemų dėl sudėtingo raktų generavimo, sukimosi ir programos gyvavimo ciklo valdymo. Platformos komandos taip pat turi investuoti daug pastangų stebėdamos ir aptikdamos anomalijas, kad išvengtų netikėtų slaptų raktų kompromisų, pvz., atsitiktinio poveikio per „Slack“ ar „GitHub“. Net kai kūrėjai praneša apie nutekėjimą ir juos pašalina, sukimosi procesas gali būti sunkus. Dar blogiau, kūrėjai tai gali laikyti mažos rizikos nutekėjimu, o apie nutekėjimą gali būti nepranešta.
Pagal ISO/IEC 27001:2022, A.9.1
Organizacijos turi įgyvendinti politiką ir procedūras, skirtas kontroliuoti prieigą prie informacijos, užtikrindamos, kad ji būtų prieinama tik tiems, kurie turi teisėtą poreikį
Platformos komandos turi du pasirinkimus:
- Pridėkite sudėtingesnių prieigos kontrolės ir patvirtinimo procesų.
- Pakeiskite statines rakto ir slaptumo poras IAM pagrįsta OAuth.
Pirmoji parinktis gali būti viliojanti, nes tiesiog reikia pridėti tokį pardavėją kaip „ServiceNow“ be daug papildomo darbo. Tačiau antrasis variantas, nors ir reikalauja daugiau diegimo pakeitimų, yra saugesnis ir sumažina taikomųjų programų komandų darbo naštą atnaujinti paslaptis, iš naujo paleisti blokus ir užtikrinti, kad paslaptys būtų paimtos. Tiesą sakant, neseniai atsirado keletas įmonių, kurios daugiausia dėmesio skiria ne žmogaus tapatybės autentifikavimui, pvz., P0 ir Clutch, o tai pabrėžia augančią saugesnių ir efektyvesnių autentifikavimo metodų tendenciją.
Šis pavyzdys parodo, kaip kitoks požiūris į saugos įgyvendinimą gali pagerinti saugumo standartus, supaprastinti infrastruktūros architektūrą ir padidinti bendrą kūrėjo greitį.
Duomenų šifravimo atvejis
Duomenų šifravimas yra dar vienas pavyzdys, kai, nors saugos komandos negali tiesiog „pridėti pardavėjo“ (norėtume vieną dieną būti tuo pardavėju), jis žymiai sumažina sudėtingumą ir sumažina diegimo pastangas visose platformose tiek saugos, tiek architektūros projektavimo požiūriu.
Įprastas duomenų srautas apima:
- Šaltinio programa skelbia duomenis
- Duomenys siunčiami į transportavimo sluoksnį (pvz., Kafka, Kinesis)
- Duomenys saugomi duomenų bazėje (MySQL, Postgres), duomenų saugykloje (Redshift, Snowflake) arba duomenų ežere (S3, Databricks)
Skirtingi sprendimai turi skirtingą „prieigos kontrolės“ interpretaciją ir įgyvendinimą, todėl platformų komandos gali įdiegti savo versijas. Tai dažnai lemia fragmentišką diegimą visoje įmonėje. Saugumo inžinieriams kuo labiau fragmentiški diegimai, tuo sunkiau įgyvendinti standartizuotą valdymą, kontrolę ir stebėjimą, todėl sistema tampa mažiau saugi.
Infrastruktūros / tiekėjo autentifikavimo ir leidimų palyginimas
Platforma |
IAM pagrįstas autentifikavimas |
Eilučių / stulpelių leidimai |
---|---|---|
Duomenų blokai |
Palaiko IAM pagrįstus leidimus |
Palaiko eilučių ir stulpelių lygio saugumą |
Snaigė |
Iš esmės nepalaiko IAM pagrįstų leidimų |
Palaiko eilučių ir stulpelių lygio saugumą |
MySQL |
Nepalaiko IAM pagrįstų leidimų |
Palaiko eilučių ir stulpelių lygio saugumą per dotacijas ir politiką |
PostgreSQL |
Nepalaiko IAM pagrįstų leidimų |
Palaiko eilučių ir stulpelių lygio saugumą |
Naudojant duomenų šifravimą, prieiga sukonfigūruojama vieną kartą naudojant šifravimo raktą ir gali būti priskirta atskiriems darbo krūviams skirtinguose duomenų srauto etapuose. Tai žymiai sumažina sudėtingumą, susijusį su leidimų politikos diegimu ir derinimu įvairiose platformose. Šifravimas užtikrina, kad duomenys būtų nuosekliai apsaugoti visose platformose, supaprastindamas valdymą ir valdymą, kartu padidindamas bendrą saugumą.
Leiskite Keyper patobulinti jūsų duomenų šifravimo žaidimą
„Keyper by Jarrid“ įgalina inžinierių komandas įtraukti duomenų šifravimą į bet kokį duomenų tvarkymo procesą, kad būtų supaprastintas saugos įgyvendinimas. Keyper siūlo šifravimo raktų valdymo API rinkinį, skirtą supaprastinti rakto kūrimą, valdymą, diegimą ir šifravimą / iššifravimą. Integruodamas su debesų KMS paslaugomis, tokiomis kaip AWS KMS ir GCP KMS, „Keyper“ įgalina valdomų kriptovaliutų raktų generavimą ir sumažina infrastruktūros priežiūrą. Tai leidžia organizacijoms vieną kartą sukonfigūruoti šifravimą ir nuosekliai jį taikyti visuose duomenų srauto etapuose, užtikrinant tvirtą saugumą ir supaprastinant valdymo ir veiklos procesus.