Līdz Kopīga atbildības modelis (SRM) ir galvenā loma, nosakot, kā tiek sadalīti drošības un darbības pienākumi starp mākoņu pakalpojumu sniedzējiem un viņu klientiem. Tomēr, kad šis modelis krustojas ar Pakalpojumu līmeņa līgumi (SLA), tas ievieš sarežģītības slāņus.
SLA parasti aptver metriku, piemēram, UPTIME, atbalsta reakcijas laiku un pakalpojumu sniegumu, bet bieži vien aizmirst kritiskos elementus, piemēram, datu aizsardzību, pārkāpumu reakciju un normatīvo aktu ievērošanu. Tas rada atbildības atšķirības, ja pieņēmumi par to, kurš ir atbildīgs, var izraisīt nopietnas neredzīgas vietas. Piemēram, klients varētu pieņemt, ka mākoņu pakalpojumu sniedzēja SLA garantē datu aizsardzību, tikai lai saprastu, ka viņu pašu nepareizas konfigurācijas vai vāja identitātes pārvaldības prakse ir izraisījusi datu pārkāpumu.
Organizācijas var kļūdaini uzskatīt, ka viņu pakalpojumu sniedzējs apstrādā vairāk nekā tā, palielinot neatbilstības, drošības incidentu un darbības traucējumu risku. SLA saistību un kopīgu drošības pienākumu izpratne ir ļoti svarīgi, lai droši izmantotu mākoņu pakalpojumus, nemazinot noturību vai normatīvās saistības.
SRM un SLA realitāte
SRM fundamentāli veido SLA darbības jomu un ietekmi mākoņu vidē. Ātri sapratīsim mākoņu pakalpojumu sniedzēju SRM realitāti.
- Mākoņu pakalpojumu sniedzēji nodrošina infrastruktūru viņi pārvaldīt; jūs nodrošināt ko tu izvietot.
- Klienti ir atbildīgi par datiem, konfigurācijām, identitāti un lietojumprogrammām.
- Mākoņu pakalpojumu sniedzēji bieži citē modeli, lai novirzītu vainas pārkāpumu laikā.
- Klientiem pašiem ir jānodrošina kaudze, jo mākonis nav vienāds ar drošu pēc noklusējuma vizītes, politika un vadības ierīces joprojām ir uz jums.
Kamēr SLA garantē mākoņu pakalpojumu sniedzēja apņemšanos “drošību no mākonis ”, nodrošinot pamatā esošās infrastruktūras darbības laiku, izturību un pamatdrošību, tas skaidri neaptver klienta pienākumus par” drošību iekšā Mākonis. “Tas nozīmē, ka pat tad, ja pakalpojumu sniedzēja SLA sola 99,99% darbības laiku viņu infrastruktūrai, klienta nepareizas konfigurācijas, vāja identitātes pārvaldība vai nepiespiestas lietojumprogrammas (visas viņu atbildības daļa) joprojām var izraisīt datu pārkāpumus vai pakalpojumu pārtraukumus, efektīvi NULLIFIFIKĀT PIETEIKUMA DROŠĪBU UN UPTIME pabalstus, tāpēc SRM, kas tieši ietekmē Provident’s SLA. adekvāts Drošība un pieejamība, ko pieredzējis uzņēmums, padarot rūpīgu klientu puses drošības praksi, kas ir būtiska, lai realizētu jebkura mākoņa SLA vērtību.
Vairākām vadības ierīcēm vajadzētu būt daļai no visaptverošas pieejas, lai iegūtu piekļuvi novatoriskām mākoņu tehnoloģijām, vienlaikus aizsargājot savu uzņēmumu:
- Pienācīga pārbaude, plaisu analīze un riska kvantitatīva noteikšana: Veiciet izsmeļošu mākoņu pakalpojumu sniedzēja drošības pozas pārskatīšanu ārpus tikai SLA. Pieprasīt un pārbaudīt drošības lappuses, neatkarīgus revīzijas ziņojumus (piemēram, FedRAMP, Soc 2 2. tips, ISO 27001) un iespiešanās testa kopsavilkumus. Veiciet detalizētu riska novērtējumu, kas nosaka jebkura SLA deficīta iespējamo ietekmi uz jūsu biznesa darbībām, datu privātumu un normatīvajām saistībām. Precīzi saprast, kur pakalpojumu sniedzēja “drošība no Mākonis “beidzas un jūsu” drošība iekšā Sākas mākoņa “pienākumi, jo īpaši attiecībā uz datu šifrēšanu, piekļuves kontroli un reakciju uz negadījumiem.
- Stratēģiskas sarunas par līgumu un pielāgotās klauzulas: Iesaistieties tiešās sarunās ar mākoņa pakalpojumu sniedzēju, lai pielāgotu SLA jūsu infrastruktūras prasībām. Nozīmīgiem līgumiem mākoņu pakalpojumu sniedzējiem vajadzētu būt gataviem iekļaut pielāgotos klauzulas, kas risina kritiskas drošības saistības, datu apstrādes procedūras, negadījumu paziņošanas termiņus un revīzijas tiesības, kas pārsniedz viņu standarta piedāvājumus. Pārliecinieties, ka līgumā ir iekļauti atlīdzināšanas klauzulas par datu pārkāpumiem vai pakalpojumu traucējumiem, kas tieši attiecināmi uz pakalpojumu sniedzēja drošības kļūmēm, un skaidri definējiet datu pārnesamības un iznīcināšanas protokolus efektīvai izejas stratēģijai.
- Īstenojiet spēcīgu slāņainu drošību (dziļš aizsardzības): Atzīstiet, ka dalītās atbildības modelis prasa jūsu aktīvo līdzdalību. Esn papildinājums Pakalpojumu sniedzēja vietējiem piedāvājumiem ieviesiet papildu drošības kontroli, kas cita starpā aptver identitātes un piekļuves pārvaldību (IAM), mākoņu drošības pozas pārvaldību (CSPM), mākoņu darba slodzes aizsardzību (CWP), datu zudumu profilaksi (DLP) un nulles trasta tīkla piekļuvi (ZTNA).
- Uzlabota drošības uzraudzība un integrācija: Integrējiet Cloud Service žurnālus un drošības telemetriju sava uzņēmuma drošības informācijas un notikumu pārvaldības (SIEM) un drošības orķestrācijas, automatizācijas un reaģēšanas (SOAR) platformās. Šī centralizētā redzamība un korelācijas spēja ļauj jūsu drošības operāciju centram (SOC) atklāt, analizēt un reaģēt uz draudiem gan uz jūsu lokālo, gan mākoņa vidi, pārvarot jebkādas iespējamās nepilnības, ko atstājuši pakalpojumu sniedzēja noklusējuma uzraudzība.
- Proaktīva pārvaldība, risks un atbilstība (GRC): Atjauniniet savas iekšējās drošības politikas un procedūras, lai skaidri ņemtu vērā jauno mākoņa pakalpojumu un tā īpašo riska profilu. Kartējiet pakalpojumu sniedzēja drošības kontroli un jūsu kompensējošo kontroli tieši atbilstošajām normatīvajām prasībām (piemēram, GDPR, HIPAA, PCI DSS). Uzturiet rūpīgu dokumentāciju par jūsu riska novērtējumiem, mazināšanas stratēģijām un visiem oficiālajiem lēmumiem par risku.
Pieņemot šīs stratēģijas, IT un IT drošības vadītāji var droši izmantot novatoriskas mākoņa tehnoloģijas, samazinot raksturīgos riskus un nodrošinot spēcīgu atbilstības pozu, pat ja saskaras ar SLA, kas sākotnēji neatbilst katram vēlamajam kritērijam.
Apakšējā līnija
Pārliecinieties, ka ievērojat principu “pieder jūsu drošības poza”, ieviešot pielāgotu drošības politiku un nepaļaujoties tikai uz mākoņa pakalpojumu sniedzēju. Drošību uzskatiet par savas infrastruktūras galveno sastāvdaļu, nevis papildinājumu. Pieņemt un izvietot vienotu kontroli, lai saskaņotu drošības stratēģijas visās vidēs, lai stiprinātu aizsardzību pret paplašinošo draudu ainavu, tādējādi samazinot risku un palielinot noturību. Kopīga atbildība nenozīmē kopīgu vainu, tas nozīmē kopīgu rūpību.
Aditya K Sood ir drošības inženierijas viceprezidents un AI stratēģija plkst AryakaApvidū
