Mākoņpakalpojumi ir kļuvuši par Latvijas uzņēmumu IT infrastruktūras pamatu — Microsoft 365, AWS, Azure, Google Workspace un desmitiem citu SaaS risinājumu. Tomēr pāreja uz mākoni nenozīmē, ka drošība ir automātiski nodrošināta. Viens no bīstamākajiem mītiem ir uzskats, ka “mākoņa pakalpojumu sniedzējs rūpējas par drošību” — realitātē drošības atbildība ir dalīta, un ievērojama tās daļa gulstas uz klientu.
Šajā rakstā apskatīsim mākoņpakalpojumu drošības principus, biežākās kļūdas un labākās prakses Latvijas uzņēmumu kontekstā.
Dalītās atbildības modelis
Mākoņpakalpojumu drošība balstās uz dalītās atbildības (shared responsibility) modeli. Atbildības sadalījums atšķiras atkarībā no pakalpojuma veida:
IaaS (Infrastructure as a Service) — AWS EC2, Azure VM
- Sniedzējs atbild par: fizisko infrastruktūru, virtualizācijas slāni, datu centru drošību
- Klients atbild par: operētājsistēmu, lietotņu, datu, piekļuves kontroli, tīkla konfigurāciju, šifrēšanu
PaaS (Platform as a Service) — Azure App Service, AWS Elastic Beanstalk
- Sniedzējs atbild par: infrastruktūru + operētājsistēmu + platformu
- Klients atbild par: lietotnēm, datiem, piekļuves kontroli
SaaS (Software as a Service) — Microsoft 365, Salesforce
- Sniedzējs atbild par: visu tehnoloģisko steku
- Klients atbild par: datu klasifikāciju, piekļuves kontroli, lietotāju pārvaldību, konfigurāciju
Galvenā atziņa: neatkarīgi no pakalpojuma veida, klients vienmēr atbild par saviem datiem un piekļuves kontroli. Microsoft neapturēs darbinieku, kas kopīgo konfidenciālus failus publiskā saitē, un AWS nebloķēs S3 bucket, ko administrators ir atstājis publiski pieejamu.
Biežākās mākoņa drošības kļūdas
Lielākā daļa mākoņa drošības incidentu ir nevis sarežģītu uzbrukumu rezultāts, bet gan konfigurācijas kļūdas:
Publiski pieejami datu glabātavas konteineri. AWS S3 bucket vai Azure Blob Storage, kas kļūdaini konfigurēti kā publiski pieejami. Rezultātā sensitīvi dati — klientu datu bāzes, rezerves kopijas, iekšējie dokumenti — kļūst pieejami jebkuram internetā.
Pārāk plašas piekļuves tiesības. Lietotājiem vai pakalpojuma kontiem piešķirtas administratora tiesības “ērtības dēļ”, nevis pēc mazāko tiesību principa. Viens kompromitēts konts var dot piekļuvi visai infrastruktūrai.
MFA nav ieslēgta. Mākoņa administratora konti bez MFA ir atvērtas durvis uzbrucējiem. Pat regulāru lietotāju konti bez MFA ir nopietns risks — īpaši Microsoft 365 vidē.
Novecojuši un neizmantotie konti. Bijušo darbinieku konti, kas nav deaktivizēti. Testa konti ar vājām parolēm. Pakalpojuma konti, kas vairs netiek izmantoti, bet joprojām ir aktīvi.
Žurnālu trūkums. Mākoņa audita žurnāli nav ieslēgti vai tiek glabāti pārāk īsu laiku. Bez žurnāliem nav iespējams izmeklēt incidentu vai pamanīt aizdomīgu aktivitāti.
Nešifrēti dati. Dati mākonī netiek šifrēti “miera stāvoklī” (at rest) vai pārraidē. Mākoņa sniedzēji piedāvā šifrēšanas iespējas — tās jākonfigurē un jāizmanto.
Mākoņa drošības labākās prakses
Identitātes un piekļuves pārvaldība (IAM)
- Mazāko tiesību princips — katram lietotājam un pakalpojuma kontam tikai minimāli nepieciešamās tiesības
- MFA visiem kontiem — bez izņēmumiem, īpaši administratoriem. Skatiet mūsu paroļu politikas ceļvedi
- Nosacījumu piekļuve (Conditional Access) — piekļuves ierobežojumi balstoties uz iekārtas stāvokli, atrašanās vietu, risku
- Regulāra piekļuves tiesību pārskatīšana — vismaz reizi ceturksnī
- Privilegēto kontu pārvaldība (PAM) — atsevišķi kontrolēti un auditēti administratīvie konti
Datu aizsardzība
- Klasificējiet datus — ziniet, kur atrodas jūsu sensitīvākie dati
- Šifrēšana — gan miera stāvoklī, gan pārraidē. Apsveriet klienta pārvaldītas šifrēšanas atslēgas (BYOK)
- Datu zaudēšanas novēršana (DLP) — politikas, kas neļauj sensitīviem datiem nokļūt ārpus uzņēmuma
- Rezerves kopēšana — nepaļaujieties tikai uz mākoņa sniedzēja iekšējo redundanci. Veidojiet neatkarīgas rezerves kopijas
Tīkla drošība mākonī
- Tīkla segmentēšana — izmantojiet VPC/VNet, lai nodalītu darba slodzes
- Drošības grupas un tīkla ACL — minimizējiet atļauto trafiku
- WAF (Web Application Firewall) — aizsargājiet tīmekļa lietotnes
- Privātie galapunkti — izmantojiet privātos savienojumus ar mākoņa pakalpojumiem, lai izvairītos no publiskā interneta
Uzraudzība un audits
- Ieslēdziet visus pieejamos audita žurnālus — CloudTrail (AWS), Azure Monitor, GCP Cloud Audit Logs
- Centralizējiet žurnālus — nosūtiet tos uz SIEM platformu, kur SOC komanda var tos analizēt
- Konfigurācijas uzraudzība — izmantojiet rīkus kā AWS Config, Azure Policy vai trešās puses CSPM risinājumus, lai automātiski identificētu nedrošas konfigurācijas
CASB — mākoņa piekļuves drošības starpnieks
CASB (Cloud Access Security Broker) ir drošības risinājums, kas darbojas starp lietotājiem un mākoņpakalpojumiem, nodrošinot:
- Redzamību — kādus mākoņpakalpojumus darbinieki izmanto (arī ēnu IT — nesankcionētos pakalpojumus)
- Atbilstību — vai mākoņa lietošana atbilst uzņēmuma politikām un regulējumam (GDPR, NIS2)
- Draudu aizsardzību — ļaunprogrammatūras detektēšana failos, kas tiek augšupielādēti mākonī
- Datu aizsardzību — DLP politiku piemērošana mākoņa kontekstā
Populāri CASB risinājumi: Microsoft Defender for Cloud Apps, Netskope, Zscaler.
Mākoņa SOC uzraudzība
Tradicionālā SOC uzraudzība, kas fokusējas tikai uz lokālo infrastruktūru, mūsdienās ir nepietiekama. Mākoņa SOC uzraudzība ietver:
- Microsoft 365 audita žurnālu monitoringu — aizdomīgi pierakstīšanās mēģinājumi, e-pasta pāradresēšanas noteikumi, failu koplietošanas anomālijas
- AWS/Azure/GCP drošības notikumu monitoringu — nesankcionētas konfigurācijas izmaiņas, jaunu administratora kontu izveide, neparasta API aktivitāte
- SaaS lietotņu monitoringu — aizdomīga lietotāju uzvedība trešo pušu SaaS lietotnēs
securIT SOC pakalpojums ietver mākoņpakalpojumu uzraudzību kā standarta daļu, nodrošinot vienotu draudu redzamību gan lokālajai, gan mākoņa infrastruktūrai.
Biežāk uzdotie jautājumi (BUJ)
Vai mākoņpakalpojumi ir drošāki nekā lokālā infrastruktūra? Tas ir atkarīgs no ieviešanas. Lieli mākoņa sniedzēji (AWS, Azure, GCP) investē miljardus drošībā un piedāvā drošības iespējas, kas pārsniedz vairuma uzņēmumu iekšējos resursus. Tomēr mākoņa drošība ir tik stipra, cik stipra ir tā konfigurācija — nepareizi konfigurēts mākonis var būt mazāk drošs nekā labi pārvaldīta lokālā infrastruktūra.
Vai Microsoft 365 ir drošs pēc noklusējuma? Microsoft 365 pamata konfigurācija ir pieņemama, bet ne optimāla. Pēc noklusējuma nav ieslēgta MFA, nav konfigurēta nosacījumu piekļuve, nav DLP politiku, un audita žurnāli tiek glabāti ierobežotu laiku. Drošības konfigurācija ir jāpielāgo uzņēmuma vajadzībām — Microsoft piedāvā rīkus, bet uzņēmumam tie ir jāieslēdz un jākonfigurē.
Kā nodrošināt GDPR atbilstību mākonī? Pārliecinieties, ka mākoņa sniedzējs piedāvā datu rezidenci ES/EEZ. Noslēdziet datu apstrādes līgumu. Šifrējiet personas datus. Konfigurējiet piekļuves kontroli un DLP. Monitorējiet piekļuvi personas datiem. Un pārliecinieties, ka varat izpildīt datu subjektu tiesības (piekļuve, dzēšana, pārnesamība). Skatiet detalizētu ceļvedi mūsu rakstā GDPR un kiberdrošība Latvijā.
Vai man vajag CASB, ja jau ir SOC? SOC un CASB veic dažādas funkcijas. SOC uzrauga drošības notikumus un reaģē uz incidentiem. CASB kontrolē mākoņa piekļuvi un datu plūsmu reāllaikā. Ideāli tie darbojas kopā — CASB ģenerē brīdinājumus, ko SOC analizē un uz kuriem reaģē. Maziem uzņēmumiem SOC ar mākoņa monitoringu var būt pietiekams; lielākiem uzņēmumiem ar daudz SaaS lietotnēm CASB sniedz papildu vērtību.
Vai vēlaties uzlabot sava uzņēmuma kiberdrošību? Sazinieties ar securIT — [email protected] vai +371 27555221.