Saugi debesijos ir hibridinė infrastruktūra

Debesijos paslaugos tapo neatsiejama šiuolaikinės IT infrastruktūros dalimi. Organizacijos debesijoje naudoja verslo aplikacijas, saugo duomenis, kuria naujas sistemas ir plečia infrastruktūrą, tačiau kartu atsiranda naujų kibernetinio saugumo rizikų.

Debesijos paslaugų naudojimas savaime neužtikrina organizacijos duomenų ir sistemų saugumo. Atsakomybė už vartotojų prieigas, konfigūracijas, duomenų apsaugą ir dalį infrastruktūros saugumo išlieka organizacijai.

AVEDUS projektuoja ir diegia debesijos saugumo sprendimus, padedančius apsaugoti debesijos, hibridines ir kelių debesijų aplinkas, valdyti vartotojų prieigą, identifikuoti netinkamas konfigūracijas, aptikti kibernetines grėsmes ir centralizuotai stebėti infrastruktūros saugumo būklę.

Debesijos saugumo iššūkiai

Tradicinėje infrastruktūroje organizacija dažniausiai aiškiai žino, kur yra jos serveriai, tinklai ir saugumo perimetras.

Debesijoje infrastruktūra tampa dinamiška.

Nauji resursai gali būti sukurti per kelias minutes, aplikacijos veikia skirtingose platformose, darbuotojai jungiasi iš įvairių vietų, o duomenys gali būti saugomi keliose debesijos paslaugose.

Dažniausios rizikos:

• netinkamos saugumo konfigūracijos;

• per plačios vartotojų teisės;

• silpnai apsaugotos privilegijuotos paskyros;

• viešai prieinami debesijos resursai;

• neapsaugotos aplikacijos ir API;

• duomenų nutekėjimas;

• pažeidžiami virtualūs serveriai ir konteineriai;

• ribotas infrastruktūros matomumas;

• nekontroliuojamas SaaS paslaugų naudojimas.

Todėl debesijos saugumas turi būti projektuojamas kaip bendros organizacijos kibernetinio saugumo architektūros dalis.

Bendros atsakomybės modelis

Vienas svarbiausių debesijos saugumo principų – Shared Responsibility Model.

Debesijos paslaugų teikėjas atsako už savo infrastruktūros ir platformos saugumą, tačiau klientas išlieka atsakingas už jam priklausančias saugumo sritis.

Priklausomai nuo naudojamo IaaS, PaaS ar SaaS modelio organizacija gali būti atsakinga už:

• vartotojų identitetus;

• prieigos teises;

• duomenis;

• saugumo konfigūracijas;

• aplikacijas;

• virtualias sistemas;

• tinklo politiką;

• šifravimo nustatymus;

• saugumo įvykių stebėseną.

Todėl infrastruktūros perkėlimas į debesiją nepanaikina organizacijos atsakomybės už kibernetinę riziką.

Hibridinės infrastruktūros saugumas

Daugelis organizacijų naudoja hibridinį infrastruktūros modelį.

Dalis sistemų veikia organizacijos duomenų centre, dalis – debesijoje, o vartotojai jungiasi prie SaaS ir kitų išorinių paslaugų.

Tokioje aplinkoje svarbu užtikrinti vientisą saugumo politiką:

Duomenų centras → Debesija → SaaS → Vartotojas → Galinis įrenginys.

Saugumo kontrolės neturėtų priklausyti vien nuo to, kur fiziškai ar logiškai veikia aplikacija.

Multi-cloud saugumas

Organizacija gali vienu metu naudoti kelias viešosios debesijos platformas.

Kiekviena platforma turi skirtingus saugumo nustatymus, prieigos modelius ir stebėjimo priemones.

Tai gali apsunkinti centralizuotą saugumo valdymą.

Multi-cloud saugumo sprendimai padeda:

• centralizuotai matyti skirtingas aplinkas;

• taikyti vieningas saugumo politikas;

• identifikuoti konfigūracijų problemas;

• vertinti rizikas;

• centralizuoti saugumo įvykius.

Tikslas – sumažinti saugumo spragas, atsirandančias dėl skirtingų platformų valdymo.

Debesijos identiteto apsauga

Debesijoje identitetas tampa vienu svarbiausių saugumo perimetrų.

Pavogta vartotojo ar administratoriaus paskyra gali suteikti prieigą prie didelio kiekio organizacijos duomenų ir sistemų.

Todėl svarbu taikyti:

• MFA;

• SSO;

• Least Privilege;

• Role-Based Access Control;

• privilegijuotų paskyrų valdymą;

• sąlyginę prieigą;

• vartotojų teisių peržiūrą;

• neaktyvių paskyrų kontrolę.

Vartotojui turi būti suteikiamos tik tos teisės, kurių reikia jo funkcijoms atlikti.

Privilegijuotų paskyrų apsauga

Debesijos administratorių paskyros yra ypač vertingas kibernetinių atakų taikinys.

Jų kompromitavimas gali suteikti galimybę:

• kurti naujus vartotojus;

• keisti saugumo nustatymus;

• pasiekti duomenis;

• išjungti saugumo priemones;

• kurti naujus infrastruktūros resursus;

• pašalinti sistemų žurnalus.

Todėl administratorių prieigai turi būti taikomos griežtesnės saugumo priemonės – MFA, PAM, ribotos privilegijos ir išsami veiksmų registracija.

CSPM – Cloud Security Posture Management

Viena dažniausių debesijos incidentų priežasčių yra netinkama infrastruktūros konfigūracija.

CSPM technologijos padeda nuolat vertinti debesijos aplinkos saugumo būklę.

Jos gali identifikuoti:

• viešai prieinamus resursus;

• netinkamas prieigos teises;

• silpnus saugumo nustatymus;

• nešifruotus duomenis;

• netinkamai sukonfigūruotus tinklus;

• neatitiktis saugumo politikoms.

Tai leidžia aptikti konfigūracijos problemas prieš jomis pasinaudojant užpuolikui.

CNAPP – Cloud-Native Application Protection Platform

CNAPP sujungia kelias debesijos saugumo funkcijas į bendrą platformą.

Priklausomai nuo sprendimo ji gali apjungti:

• CSPM;

• workload apsaugą;

• pažeidžiamumų valdymą;

• identiteto teisių analizę;

• konteinerių saugumą;

• Kubernetes saugumą;

• Infrastructure as Code analizę;

• cloud workload apsaugą.

Tai leidžia vertinti debesijos rizikas ne kaip atskirus įvykius, o kaip tarpusavyje susijusią saugumo situaciją.

Cloud Workload Protection

Debesijoje veikiančios virtualios mašinos, konteineriai ir kitos workload sistemos taip pat gali būti kibernetinių atakų taikiniai.

Jų apsauga gali apimti:

• EDR/XDR;

• workload monitoring;

• pažeidžiamumų vertinimą;

• aplikacijų kontrolę;

• tinklo segmentavimą;

• runtime apsaugą;

• anomalijų aptikimą.

Saugumo politika turi būti taikoma nepriklausomai nuo to, ar serveris veikia organizacijos duomenų centre, ar viešojoje debesijoje.

Konteinerių ir Kubernetes saugumas

Cloud-native aplikacijos vis dažniau kuriamos naudojant konteinerius ir Kubernetes.

Tokiose aplinkose svarbu kontroliuoti:

• konteinerių atvaizdus;

• pažeidžiamumus;

• prieigos teises;

• secrets;

• tinklo komunikaciją;

• konfigūracijas;

• runtime elgseną.

Saugumas turi būti integruojamas ne tik į produkcinę aplinką, bet ir į visą aplikacijos kūrimo procesą.

DevSecOps

Debesijos infrastruktūra dažnai kuriama ir keičiama automatizuotai.

Todėl saugumo kontrolės turi būti integruotos į programinės įrangos kūrimo procesą.

DevSecOps principai leidžia saugumo patikras atlikti dar prieš aplikacijai pasiekiant produkcinę aplinką.

Tai gali apimti:

• kodo saugumo analizę;

• priklausomybių tikrinimą;

• Infrastructure as Code analizę;

• secrets aptikimą;

• konteinerių pažeidžiamumų tikrinimą;

• saugumo politikų automatizavimą.

Kuo anksčiau nustatoma saugumo problema, tuo paprasčiau ir pigiau ją pašalinti.

Debesijos tinklo saugumas

Debesijos infrastruktūroje taip pat reikalingas tinklo segmentavimas ir komunikacijos kontrolė.

Priklausomai nuo architektūros gali būti naudojamos:

• virtualios ugniasienės;

• mikrosegmentacija;

• IDS/IPS;

• VPN;

• ZTNA;

• saugūs ryšiai tarp duomenų centro ir debesijos;

• srauto analizė.

Svarbu riboti ne tik iš interneto į debesiją patenkantį srautą, bet ir komunikaciją tarp pačių debesijos resursų.

Zero Trust debesijoje

Zero Trust modelis ypač tinkamas hibridinėms ir debesijos infrastruktūroms.

Prieiga neturėtų būti suteikiama vien todėl, kad vartotojas yra organizacijos tinkle.

Prieš suteikiant prieigą gali būti vertinama:

Vartotojo tapatybė → MFA → Įrenginio būklė → Lokacija → Rizika → Reikalingas resursas.

Tai leidžia taikyti vienodus prieigos principus nepriklausomai nuo vartotojo ar aplikacijos buvimo vietos.

SASE ir debesijos saugumas

SASE leidžia dalį tinklo ir saugumo funkcijų perkelti į debesijos pagrindu veikiančią platformą.

SASE architektūra gali apjungti:

• ZTNA;

• Secure Web Gateway;

• CASB;

• Firewall as a Service;

• SD-WAN;

• duomenų apsaugos funkcijas.

Tai ypač aktualu organizacijoms, turinčioms daug padalinių, nuotolinių darbuotojų ir debesijoje veikiančių aplikacijų.

Duomenų apsauga debesijoje

Duomenys yra vienas svarbiausių organizacijos debesijos resursų.

Jų apsauga turi apimti visą gyvavimo ciklą.

Svarbu kontroliuoti:

• kur saugomi duomenys;

• kas gali juos pasiekti;

• kaip jie perduodami;

• ar jie šifruojami;

• ar daromos atsarginės kopijos;

• ar galima aptikti neautorizuotą duomenų perdavimą.

DLP ir duomenų klasifikavimo technologijos gali padėti kontroliuoti jautrios informacijos naudojimą.

Šifravimas ir raktų valdymas

Jautrūs duomenys turi būti apsaugoti tiek juos saugant, tiek perduodant.

Todėl debesijos saugumo architektūroje svarbus:

• duomenų šifravimas;

• TLS;

• šifravimo raktų valdymas;

• sertifikatų valdymas;

• prieigos prie raktų kontrolė.

Kritinėse aplinkose gali būti taikomi papildomi reikalavimai raktų saugojimui ir administravimui.

Aplikacijų ir API apsauga

Debesijoje veikiančios aplikacijos dažnai pasiekiamos tiesiogiai iš interneto.

Todėl jų apsaugai gali būti naudojami:

• WAF;

• API Security;

• Bot Management;

• DDoS apsauga;

• aplikacijų pažeidžiamumų valdymas;

• saugumo testavimas.

Aplikacijų ir API apsauga turi būti bendros debesijos saugumo architektūros dalis.

Debesijos pažeidžiamumų valdymas

Debesijos infrastruktūra keičiasi greitai.

Naujos virtualios sistemos, konteineriai ir aplikacijos gali būti sukuriami automatiškai.

Todėl vienkartinio pažeidžiamumų skenavimo nepakanka.

Svarbus nuolatinis procesas:

Identifikavimas → Rizikos vertinimas → Prioritetizavimas → Šalinimas → Patikrinimas.

Pažeidžiamumų rizika turi būti vertinama kartu su konkretaus resurso prieinamumu, teisėmis ir svarba organizacijai.

Debesijos saugumo stebėsena

Debesijos platformos generuoja daug informacijos apie vartotojų ir sistemų veiklą.

Saugumo stebėsena gali padėti aptikti:

• neįprastus prisijungimus;

• privilegijų pakeitimus;

• naujų administratorių sukūrimą;

• saugumo politikų pakeitimus;

• netipinę duomenų prieigą;

• įtartiną infrastruktūros kūrimą;

• bandymus išjungti saugumo kontrolę.

Ši informacija gali būti perduodama į centralizuotą saugumo stebėjimo sistemą.

Debesijos saugumas ir SIEM

Debesijos infrastruktūra turi būti matoma bendrame organizacijos saugumo kontekste.

SIEM gali rinkti informaciją iš:

• debesijos platformų;

• identiteto sistemų;

• SaaS aplikacijų;

• EDR/XDR;

• ugniasienių;

• WAF;

• kitų saugumo technologijų.

Tai leidžia koreliuoti debesijos įvykius su veikla kitose organizacijos sistemose.

Debesijos saugumas ir SOC/MDR

SOC/MDR specialistai gali analizuoti debesijos saugumo įvykius kartu su kitais organizacijos infrastruktūros signalais.

Pavyzdžiui:

Pavogta paskyra → Neįprastas prisijungimas → Privilegijų pakeitimas → Prieiga prie debesijos resurso → Duomenų perdavimas.

Atskiri įvykiai gali atrodyti nepavojingi, tačiau jų koreliacija gali parodyti vykstančią kibernetinę ataką.

Debesijos saugumas ir NIS2

Organizacijos, kurioms taikomi NIS2 reikalavimai, negali vertinti debesijos infrastruktūros kaip atskiros nuo bendro kibernetinės rizikos valdymo proceso.

Debesijos sistemos turi būti įtrauktos į:

• turto inventorizaciją;

• rizikų vertinimą;

• prieigos valdymą;

• pažeidžiamumų valdymą;

• incidentų aptikimą;

• veiklos tęstinumą;

• tiekimo grandinės rizikos vertinimą.

Jeigu kritinė organizacijos sistema veikia debesijoje, jos saugumas yra tokia pati organizacijos atsakomybės dalis kaip ir vietinės infrastruktūros saugumas.

Daugiasluoksnė debesijos apsauga

Efektyvi debesijos saugumo architektūra apjungia kelis tarpusavyje susijusius sluoksnius:

Identitetas ir MFA → CSPM/CNAPP → Workload apsauga → Tinklo saugumas → Zero Trust/SASE → Aplikacijų ir API apsauga → Duomenų apsauga → SIEM → SOC/MDR.

Vienos technologijos nepakanka visoms debesijos rizikoms valdyti.

Svarbiausia – sukurti vientisą saugumo architektūrą, apimančią vartotojus, infrastruktūrą, aplikacijas ir duomenis.

Kodėl AVEDUS?

Hibridinės infrastruktūros kompetencija

Debesijos saugumą vertiname kartu su organizacijos duomenų centro, tinklo, vartotojų ir galinių įrenginių apsauga.

Zero Trust požiūris

Projektuojame prieigos modelius, kuriuose vartotojo ar įrenginio buvimo vieta savaime nesuteikia pasitikėjimo.

Kompleksinė saugumo architektūra

Apjungiame identiteto, tinklo, endpoint, aplikacijų, duomenų ir debesijos saugumo technologijas.

Integracija su SIEM ir SOC/MDR

Debesijos saugumo įvykius integruojame į bendrą organizacijos grėsmių aptikimo ir reagavimo procesą.

Nuo vertinimo iki įgyvendinimo

Įvertiname esamą debesijos saugumo būklę, identifikuojame rizikas, projektuojame tikslinę architektūrą ir diegiame reikalingas saugumo priemones.

SaaS aplikacijų saugumas

Organizacijos naudoja vis daugiau SaaS paslaugų.

Tai gali būti:

• Microsoft 365;

• CRM;

• dokumentų valdymo sistemos;

• projektų valdymo platformos;

• komunikacijos priemonės;

• kitos verslo aplikacijos.

Svarbu kontroliuoti, kas turi prieigą prie šių sistemų, kokie duomenys jose saugomi ir kaip jie naudojami.

SaaS saugumo priemonės gali padėti identifikuoti rizikingas konfigūracijas, per plačias vartotojų teises ir įtartiną veiklą.

CASB – Cloud Access Security Broker

CASB padeda kontroliuoti organizacijos naudojamas debesijos paslaugas ir duomenų judėjimą.

Sprendimas gali suteikti:

• SaaS aplikacijų matomumą;

• Shadow IT aptikimą;

• vartotojų veiklos kontrolę;

• duomenų apsaugą;

• prieigos politikų taikymą;

• rizikingų aplikacijų identifikavimą.

Tai leidžia organizacijai geriau suprasti, kokios debesijos paslaugos realiai naudojamos.