Pilveturvalisuse näpunäited on kasulikud ainult siis, kui need käsitlevad ründajate tegelikke ärakasutatavaid lünki: avalik S3-ämber, mida keegi ei märganud, CI-jooksja metamärgiga AWS õigused, lekkinud saladus ehituslogis või pahatahtlik sõltuvus, mis installiti vaikselt a-i ajal pipeline Enamikku pilveturbeintsidente ei põhjusta tundmatud ohud. Need on põhjustatud teadaolevatest nõrkustest, mida pole kunagi jõustatud, prioriseeritud ega parandatud.
See juhend hõlmab 20 praktilist pilveturbenõuannet, mis on jaotatud kihtide kaupa: identiteet, andmed, infrastruktuur, tarkvara tarneahel, CI/CD pipelines, tuvastamine ja intsidentidele reageerimine. Olenemata sellest, kas tugevdate ühte pilvekontot või turvate mitme meeskonna DevSecOps pipeline, aitavad need kontrollid ära hoida rikkumisi, mis tegelikult aset leiavad.
Miks pilveturvalisus ikka ja jälle ebaõnnestub vaatamata nii paljudele pilveturvalisuse näpunäidetele
Pilveturvalisus on meetmete, poliitikate ja tööriistade kogum, mis kaitseb pilvekeskkondades töötavaid andmeid, rakendusi ja infrastruktuuri. See hõlmab identiteeti, võrku, andmeid, rakenduse koodi, sõltuvusi, infrastruktuuri konfiguratsiooni ja ehitust. pipelines.
Põhjus, miks see isegi küpsetes meeskondades ebaõnnestub, ei ole teadmiste puudus. See on kolm struktuurilist probleemi:
- Kiirus vs turvalisus. Pipelineliiguvad kiiresti. Hõõrdumist lisavad kontrollid keelatakse. Meeskonnad, kes pilveturvalisuse õigesti lahendavad, ei lisa väravaid, vaid automatiseerivad jõustamise otse töövoogu.
- Tööriistade killustatus. Saladuste skannimine ühes tööriistas, SCA teises, IaC kolmandikus. Ühtse vaate puudumine tähendab, et katvuskihtide vahel on lüngad ja leiud ei seostu kunagi tegeliku riskiga.
- Valvsusväsimus. Skannerid, mis päevas tuvastavad sadu CVE-sid, õpetavad insenere leide, sealhulgas kriitilisi, ignoreerima. Prioriseerimine ei ole valikuline; see määrab, kas turvalisus tegelikult toimib.
Allolevad pilveturvalisuse näpunäited on loodud nende lünkade praktiliseks täitmiseks. Pilveturvalisust ei käsitleta ainult käitusaja probleemina, vaid need hõlmavad kogu koodi edastamise teed pilve.
20 pilveturvalisuse nippi:
Identiteedi- ja juurdepääsuhalduse pilveturbe näpunäited
1. Luba mitmefaktoriline autentimine kõikjal
MFA on endiselt pilveturbe valdkonnas kõige suurema investeeringutasuvusega kontroll. See peatab volituste varguse rünnakud kohe ja ründajad teavad seda. Iga konto ilma MFA-ta on õrn sihtmärk.
Rakendage MFA-d iga inimese identiteedi jaoks oma pilvekeskkondades: arendajakontodel, administraatori konsoolidel, pilveteenuse pakkujate portaalides, CI/CD dashboards. Kasutage privileegidega kontode puhul andmepüügikindlat mitmefaktorilist autentimist (riistvaravõtmed, pääsukoodid). Autentimisrakenduse kaudu sisestatud ajapõhised koodid on minimaalne nõue.
2. Rakendage vähimat privileegi, eriti mitte-inimlikele identiteetidele
Vähima privileegi põhimõte on inimeste puhul hästi mõistetav. See osa, mida meeskonnad pidevalt ei märka, on mitte-inimlikud identiteedid: CI/CD teenusekontod, Lambda funktsioonid, konteineri töökoormused, GitHubi toimingute käivitajad.
Need identiteedid koguvad metamärgiõigusi, kuna need konfigureeritakse üks kord ja neid ei kasutata enam kunagi uuesti. Just neid sihtivad ründajad tarneahela rünnakutes, kuna neil on juurdepääs saladustele, andmehoidlatele, tootmisressurssidele ja allavoolu süsteemidele.
Auditeeri teenusekonto õigusi kord kvartalis. Eemalda kõik, mida pole 90 päeva jooksul kasutatud.
3. Asendage pikaajalised volitused lühiajaliste tokenite vastu
Staatilised API-võtmed ja pika elueaga märgid on pilverikkumiste ühed levinumad algpõhjused. Nad saavad... commitrepositooriumidesse viidud, CI logidesse lekkinud, Slacki kopeeritud ja unustatud .env failid ja kehtivad seejärel kuid või aastaid.
Asendage need võimaluse korral lühiajaliste volitustega: AWS STS-i rolli eeldus, GCP töökoormuse identiteedi föderatsioon, GitHubi toimingud OIDC-sKui staatilisi volitusi on võimatu vältida, salvestage need salasõnade haldurisse (Vault, AWS Secrets Manager, Azure Key Vault) ja vahetage neid automaatselt.
4. Rakendage kõrgendatud õiguste jaoks just-in-time juurdepääsu
Püsiv administraatori juurdepääs on püsiv risk. Püsivad kõrgendatud õigused tähendavad, et ühest ohustatud identiteedist piisab tootmiskeskkonda pääsemiseks.
JIT-juurdepääsusüsteemid (AWS IAM Identity Center, GCP Privileged Access Manager, Okta Access Requests) pakuvad nõudmisel kõrgendatud juurdepääsu, ajaliselt piiratud ja täielike auditilogidega. Arendajad saavad vajaliku teabe siis, kui seda vajavad. Ründajad ei leia püsivat sihtmärki.
5. Rakenda nullusaldust teenustevahelises suhtluses
Traditsioonilised perimeetrimudelid eeldavad, et kõik võrgus olev on usaldusväärne. Pilvepõhised keskkonnad mikroteenuste, konteinerite ja dünaamiliste töökoormustega muudavad selle eelduse ohtlikuks.
Null usaldus tähendab, et iga päring autentitakse ja autoriseeritakse, olenemata selle päritolukohast. Rakenda teenustevaheline autentimine (mTLS, teenusevõrgu identiteet), jõusta võrgupoliitikad töökoormuse tasandil ja käsitle sisemist liiklust vaikimisi ebausaldusväärsena.
Andmekaitse pilveturvalisuse näpunäited
6. Krüpteeri kõik, sealhulgas sisemine liiklus
Krüptimine puhkeolekus (AES-256, hallatud KMS) on nüüd standard harjutamine. Enamiku meeskondade vahel on vahe sisemise liikluse krüptimine edastamise ajal.
Mikroteenuste ja konteineritevahelise suhtlusega VPC-s ei ole "sees" püsiv liiklus loomupäraselt ohutu. Rakendage teenuste sisemise suhtluse jaoks vastastikust TLS-i (mTLS). Selle automaatseks jõustamiseks kasutage teenusevõrku (Istio, Linkerd) või nullusaldusvõrgu kihti, selle asemel, et loota iga meeskonna korrektsele konfigureerimisele.
7. Avastage ja parandage avalikuks tulnud saladused enne nende levikut
Saladus commitRepositooriumisse paigutamine ei jää saladuseks. GitHub indekseerib avalikud repositooriumid sekunditega. Sisemised repositooriumid pole immuunsed – kui saladus on Giti ajalukku kantud, on see kättesaadav kõigile, kellel on repositooriumile juurdepääs, nii praegu kui ka tulevikus.
Ennetavad kihid on olulised (pre-commit hooks, IDE pluginad), kuid neist ei piisa. Teil on vaja pidevat skannimist kõigis repositooriumides, sealhulgas ajaloolistes commits, CI/CD palgid IaC failid ja konteineri kujutised. Salajase teabe tuvastamisel tuleb reageerida viivitamatult: see tühistada, vahetada ja hinnata, kas sellele pääseti juurde avalikustamise ja tuvastamise vahel.
8. Andmete klassifitseerimine ja kontrollide rakendamine tundlikkuse põhjal
Kõik teie pilvekeskkonnas olevad andmed ei ole avalikustamise korral sama riskiga. Kõigi andmete ühtemoodi käsitlemine tähendab üleinvesteerimist madala riskiga andmete kontrollimehhanismidesse ja tegelikult oluliste andmete alakaitset.
Liigitage andmed tundlikkuse järgi (avalik, sisemine, konfidentsiaalne, piiratud). Rakendage juurdepääsu kontrolle ja krüptimist. standardja iga taseme auditilogi nõuded. Automatiseerige klassifitseerimine võimaluse korral, käsitsi sildistamine ei skaleeru.
Infrastruktuuri ja konfiguratsiooni turvalisus
9. Skaneerimine IaC iga Commit, Mitte ainult enne lähetamist
Taristu kui kood on koht, kus luuakse valekonfiguratsioone, mitte tootmises. Avalik S3-ämber, avatud turberühm või IAM-roll koos *:* „õigused” ei ilmu kogemata. See algab Terraformi failis või Kubernetesi manifestis reana, mida keegi pole märgistanud.
IaC skannimine peab toimuma iga pull request, kusjuures leiud ilmnesid koodi ülevaatuse töövoos. Skannige Terraformi, Kubernetesi manifeste, CloudFormationit, Helmi diagramme, Dockerfilesi ja CI/CD konfiguratsioonid.
Xygeni IaC Security skannib iga toetatud vormingut igal commit, seob leiud konkreetsete ressurssidega ja integreerub teie PR-töövooga, et arendajad saaksid tagasisidet seal, kus nad töötavad, mitte eraldi. dashboard nad ei avane kunagi. Alusta tasuta prooviperioodi →
10. Käsitle turvapoliitikat koodina
Manuaalsed turvaülevaated ei skaleeru. Poliitika koodina küll.
Kasutage turvareeglite versioonitud ja testitava koodina väljendamiseks selliseid tööriistu nagu OPA (Open Policy Agent) või Kyverno. Jõustage need aadressil pipeline tasemel, seega Kubernetes'i juurutus koos privilegeeritud: tõene Või root'ina töötav konteiner nurjub automaatselt iga kord. Kui poliitikad on koodis, vaadatakse need üle ja täiustatakse nagu iga inseneriartefakti. Kui need on dokumentatsioonis, siis nad triivivad.
11. Turvalise konfiguratsiooni alusjoonte jõustamine ja triivi jälgimine
Vaikimisi konfiguratsioonid on optimeeritud mugavuse, mitte turvalisuse huvides. Pilveteenused, konteinerite käituskeskkonnad ja hallatud Kubernetes klastrid on varustatud seadetega, mida on lihtne kasutada ja ära kasutada.
Alusta CIS Pilveteenuse pakkuja, konteineri käituskeskkonna ja operatsioonisüsteemi võrdlusnäitajad. Kodeeri need koodina poliitikana, et neid automaatselt jõustataks. Jälgi pidevalt triivi, sest eelmisel nädalal nõuetele vastav konfiguratsioon ei pruugi täna nõuetele vastata pärast surve all tehtud kiiret muudatust.
12. Segmenteerige võrgustikke ja piirake külgmist liikumist
Lameda võrguarhitektuur tähendab, et kui ründaja on ühe töökoormuse ohtu seadnud, pääseb ta ligi kõigile teistele. Võrgu segmenteerimine hõlmab plahvatusraadiust.
Kasutage VPC-sid, alamvõrke ja turberühmi, et luua funktsiooni ja tundlikkuse järgi isolatsioonitsoone. Piirake teenuste vahelist ida-lääne suunalist liiklust ainult vajalikule tasemele. Rakendage väljundfiltreerimist, kuna enamik ohustatud töökoormusi peab jõudma ründaja kontrollitava serverini ja väljundkontroll on üks teie parimaid võimalusi selle avastamiseks või ennetamiseks.
Tarkvara tarneahela pilveturbe näpunäited
Mõned kõige olulisemad pilveturvalisuse näpunäited ei alga enam pilveteenuse pakkuja konsoolis, vaid varem, tarkvara tarneahelas. Sõltuvused, CI/CD Töövood, saladused, ehitusskriptid ja artefaktid võivad kõik enne juurutamist pilveriske tekitada.
13. Skannige iga sõltuvust enne, kui see teie ehitusse siseneb
Avatud lähtekoodiga paketid on tänapäevastes tarneahelarünnakutes kõige levinum esmase juurdepääsu vektor. 2024. aasta Shai-Huludi kampaania rikkus üle 830 npm paketi. XZ Utilsi tagauks rikkus peaaegu SSH autentimise miljonites Linuxi süsteemides. Mõlemal juhul saabus pahatahtlik kood tavapärase sõltuvuste installiprotsessi kaudu.
Põhi- SCA (Tarkvara koostise analüüs), töötlemata CVE-loenditest ei piisa. Tegelikult on vaja järgmist:
- Saavutatavuse analüüsKas haavatavat funktsiooni kutsutakse teie koodis tegelikult välja?
- Pahavara tuvastamine: kas see pakett käitub pahatahtlikult, esineb hägustatud skripte, ootamatuid võrgukõnesid, elutsüklit hooks mis installivad väliseid käituskeskkondi?
- EPSS-i punktiarvestusKui suur on tõenäosus, et seda CVE-d praegu aktiivselt ära kasutatakse, mitte ainult teoreetiliselt?
14. Lukusta CI/CD Pipelines
CI/CD süsteemidel on juurdepääs saladustele, pilvepõhistele volitustele ja tootmiskeskkondadele. Tavaliselt on need ka vähem kaitstud kui tootmissüsteemid, kuhu nad juurutatakse.
Järgimismeetmete rakendamine:
- Nõua koodi ülevaatamist mis tahes muudatuste korral pipeline konfiguratsioonifailid (.github/tööprotsessid/, Jenkinsfile, Jne)
- Piira ise hostitud käivitajate juurdepääsu heakskiidetud repositooriumidele, kontrollimata käivitajate juurdepääs on otsene tee volituste varguseni.
- Ärge kunagi edastage saladusi lihtteksti keskkonnamuutujatena; kasutage saladuste halduri integratsiooni
- Audit pipeline ootamatute käskude, ebatavaliste võrgukõnede või ootamatutel kellaaegadel tehtud täitmiste logid
Xygeni CI/CD TURVALISUS sunnib guardrails otse sinu sees pipeline , blokeerides ohtlikke versioone, tuvastades sisestatud töövooge ja tagades pipeline terviklikkus igal etapil. Broneeri demo →
15. Kontrolli ehituse terviklikkust ja allkirjasta artefaktid
Kui ründaja suudab koodi ehitusskripti sisestada, pärast kompileerimist artefakti muuta või CI-jooksurit ohtu seada, kuulub talle teie tarkvara tarneahel, olenemata sellest, kui puhas teie lähtekood on.
Rakenda ehituse terviklikkuse kontrolle:
- Kinnitage kõik sõltuvusversioonid ja baaspildid täpsete kokkuvõtete, mitte siltide külge
- Allkirjastage ehitusartefaktid ja kontrollige allkirju enne juurutamist
- Jälgige ootamatuid muutusi CI/CD töövoo failid, süstitud töövood olid Shai-Huludi sarnaste rünnakute peamine näitaja
- Rakendage SLSA atesteerimisi, et krüptograafiliselt tõestada, mis on ehitatud, millisest allikast ja kelle poolt. pipeline
Ohu tuvastamine ja intsidentidele reageerimine
16. Tsentraliseerige logimine ja suurendage nähtavust kogu virnas
Sa ei saa tuvastada seda, mida sa ei näe. Enamik pilveturbe jälgimisest keskendub käitusajale, CloudTrailile, VPC voo logidele ja GuardDutyle. See on vajalik, aga mitte piisav.
Rünnakud nagu Shai-Hulud ja SolarWinds õnnestusid osaliselt seetõttu, et rünnak toimus juba ehituse ajal. pipeline, ammu enne, kui midagi jõudis tootmismonitooringuni. Täieliku nähtavuse saavutamiseks on vaja katta lähtekoodi muudatused, ehitus- ja artefaktikihid, pilvepõhine käituskeskkond ja API tegevus.
17. Prioriseerige leide ärakasutatavuse, mitte ainult raskusastme järgi
Skänner, mis toodab nädalas 500 leidu, õpetab meeskondi leide, sealhulgas kriitilisi, ignoreerima. Prioriseerimine on see, mis eristab toimivaid turvaprogramme paberil eksisteerivatest.
Tõhus prioriseerimine ühendab endas: ligipääsetavuse (kas haavatav kood on tegelikult käivitatud?), nähtavuse (kas teenus on internetiga ühendatud?), EPSS-skoori (aktiivse ärakasutamise tõenäosus) ja ärikonteksti (tootmiskeskkond vs. arenduskeskkond).
Xygeni ASPM toob kõik leiud üle SAST, SCA, IaC, saladusi ja pipeline security ühtseks riskivaateks koos kontekstipõhise prioriseerimisega, mis ütleb teie meeskonnale täpselt, mida kõigepealt parandada. Broneeri demo →
18. Käitumuslike lähtetasemete kehtestamine ja kõrvalekallete korral hoiatamine
Teadaolevad halvad signatuurid tuvastavad teadaolevaid ohte. Käitumuslike anomaaliate tuvastamine tabab tundmatuid ohte, nullpäevaohtusid, uusi rünnakumustreid ja sisemisi ohte.
Sinu CI/CD keskkonnas, määrake kindlaks tüüpilise ehituse kestuse, tavapäraste pakettide installimismustrite, ehituse ajal eeldatavate võrgusihtkohtade ja standard saladustele ligipääsu mustrid. Kõrvalekalded nendest lähtejoontest on teie varaseim hoiatussignaal ja kiht, millesse enamikul meeskondadel pole mingit nähtavust.
19. Määrake pilvepõhiste intsidentide stsenaariumide jaoks käitusraamatud
Üldised intsidentidele reageerimise plaanid ei arvesta pilvespetsiifilisi stsenaariume: ohustatud pakett, mis on juba 40 teenusesse installitud; CI-käivitaja, mille volikirjad on pahatahtliku eelinstalli skripti poolt varastatud; ehitusartefakt, mida võidi viimase 72 tunni jooksul manipuleerida.
Looge spetsiifilised käitusraamatud järgmiste ohtudega seotud sõltuvuste jaoks: pipeline volituste vargus, vale konfiguratsiooni põhjustatud andmete avalikustamine ja pahatahtlik CI-töövoo süstimine. Iga käitusraamat peaks määratlema, kellele vastus kuulub, mis tühistatakse koheselt ja millist kohtuekspertiisi on vaja plahvatusraadiuse kindlaksmääramiseks.
20. Jookse lauamängucises, vähemalt kaks korda aastas
Testimata käitusraamat on hüpotees. Lauaharjutuscispaljastavad teie reageerimisplaani lüngad enne, kui ründaja neid teeb. Eesmärk ei ole täpselt järgida plaani, vaid avastada, mis puudu on.
Jookse vähemalt kaks harjutustcises aastas, simuleerides erinevaid stsenaariumitüüpe: tarneahela kompromiteerimine, vale konfiguratsiooni tõttu tekkinud andmete rikkumine, kompromiteeritud CI-käivitaja. Kaasake meeskonnad, kes tegelikult reageerivad, turvalisus, DevOps ja valvekorras arendajad.
Pilveturvalisuse näpunäidete kontroll-leht: kiirjuhend
| kiht | Klahvide juhtnupud |
|---|---|
| Identity | MFA kõikjal, vähimad privileegid, lühiajalised volitused, JIT-juurdepääs |
| kuupäev | Krüptimine nii puhkeolekus kui ka edastamisel, saladuste skannimine ja automaatne tühistamine, andmete klassifitseerimine |
| Infrastruktuur | IaC skaneerimine sisse lülitatud commit, poliitika kui kood, CIS baasjoone jõustamine, võrgu segmenteerimine |
| Tarneahel | SCA ligipääsetavuse ja pahavara tuvastamisega, CI/CD karastamine, konstruktsiooni terviklikkus ja SLSA |
| Detection | Tsentraliseeritud logimine, EPSS-põhine prioriseerimine, käitumuslike anomaaliate tuvastamine |
| Vastus | Pilvepõhised käitusraamatud, lauaarvutipõhised harjutusedcisdokumenteeritud plahvatusraadiuse hindamine |
Kuidas Xygeni aitab pilveturbe näpunäiteid rakendada kogu virnas
Pilveturbe näpunäited toimivad ainult siis, kui meeskonnad saavad neid kogu tarkvara tarnimise elutsükli jooksul järjepidevalt jõustada. Enamik tööriistu hõlmab ühte kihti: käitusaja, koodi, sõltuvused, saladused või CI/CDKuid tõelised rünnakud liiguvad kihtide vahel.
Xygeni ühendab need kihid integreeritud tuvastamise, prioriseerimise ja parandamisega alates esimesest giti käivitamisest kuni tootmiskeskkonnani.
| kiht | Xygeni võimekus | Mida see takistab |
|---|---|---|
| Lähtekood | SAST + Tehisintellekti parandusmeetmed | Süstimine, autentimisvead, ebaturvaline disain |
| Sõltuvad | SCA + Pahavara tuvastamine + EPSS | Tarneahela ohud, haavatavad pakendid |
| saladused | Saladuste turvalisus + automaatne tühistamine | Volikirjaga kokkupuude, pikaajaline tokenirisk |
| IaC & Konfiguratsioon | IaC Security | Valed konfiguratsioonid enne tootmisse jõudmist |
| CI/CD Pipeline | CI/CD Turvalisus + anomaaliate tuvastamine | Pipeline süstimine, jooksja kompromiss |
| Ehita esemeid | Build Security + SLSA provenance | Vääristatud esemed, allkirjastamata väljaanded |
| Riskipositsioon | ASPM | Ühtne vaade, kihtideülene prioriseerimine |
Tulemus: turvameeskonnad saavad signaali, mitte müra. Arendajad saavad tagasisidet seal, kus nad töötavad, mitte eraldi tööriistas, mida nad kunagi ei ava. Ja turvalisusest saab osa edastusprotsessist, mitte värav, mis seda aeglustab.
Final Thoughts
Pilveturvalisuse näpunäiteid on lihtne loetleda, kuid raskem jõustada. Meeskonnad, kes vähendavad tegelikku pilveriski, ei tugine käsitsi ülevaatamisele, hajutatud tööriistadele ega ainult raskusastme järgi prioriseerimisele. Selle asemel automatiseerivad nad turvakontrollid seespool. pipelines, prioriseerige ärakasutatavuse järgi ja käsitlege kogu tarkvara tarneahelat pilverünnaku pinna osana.
See tähendab enamat kui lihtsalt käitusaja infrastruktuuri turvamist. See tähendab lähtekoodi, sõltuvuste, saladuste kaitsmist. IaC, CI/CD töövooge, ehitusartefakte ja rakenduse riskipositsiooni koos.
Kui teie praegused tööriistad jätavad nende kihtide vahele lünki, aitab Xygeni need integreeritud tuvastamise, prioriseerimise ja parandamise abil täita kogu koodist pilve jõudmise protsessi vältel.
👉 Alustage oma 7-päevast tasuta prooviperioodi krediitkaarti pole vaja, skannimise tulemused minutitega
👉 Kontakt ja vaadake, kuidas Xygeni teie konkreetse pilvega seostub ja pipeline seade
Teave Autor
Kaasasutaja ja CTO
Fatima Said spetsialiseerub arendajatele suunatud sisule rakenduste turvalisuse, DevSecOpsi ja muude valdkondade jaoks. software supply chain securityTa muudab keerulised turvasignaalid selgeteks ja tegutsemiskõlblikeks juhisteks, mis aitavad meeskondadel kiiremini prioriteete seada, müra vähendada ja turvalisemat koodi edastada.
