Slut dig til at udforske Cloud Cryptography, dens typer og Google Cloud-implementeringen.
En delmængde af IaaS, cloud computing, er langt foran buzzword-fasen. Det er en dominerende kraft med enkeltpersoner, virksomheder og regeringer, der bruger cloud-tjenester til at afkorte besværet med en teknisk stak på stedet.
Cloud er indbegrebet af bekvemmelighed, økonomi og skalerbarhed.
Forenklet sagt er cloud computing, når du låner computerressourcer som lager, RAM, CPU osv. over internettet uden fysisk at være vært for noget.
Et dagligt eksempel er Google Drive eller Yahoo Mail. Vi stoler på disse virksomheder med data – nogle gange følsomme personlige eller forretningsrelaterede oplysninger.
Generelt bekymrer en gennemsnitlig bruger sig ikke om privatlivets fred eller sikkerhed ved cloud computing. Men enhver, der er anstændigt informeret om overvågningens historie eller aktuelle sofistikerede cyberangreb, skal hæve deres vagt eller i det mindste blive informeret om den aktuelle situation.
Indholdsfortegnelse
Hvad er Cloud Kryptografi?
Cloud-kryptografi adresserer denne følelse af usikkerhed ved at kryptere data gemt i skyen for at forhindre uautoriseret adgang.
Kryptering er en teknik til at bruge en chiffer (algoritme) til at konvertere standardoplysninger til en kodet version. I så fald vil angriberen ikke forstå detaljerne, selvom den bliver afsløret.
Der findes forskellige typer krypteringer baseret på use case. Så det er vigtigt at bruge en kvalitetskryptering til cloud-datakryptering.
Kan du for eksempel forstå følgende tekst:
Iggmhnctg rtqfwegu jkij-swcnkva vgejpqnqia & hkpcpeg ctvkengu, ocmgu vqqnu, cpf CRKu vq jgnr dwukpguugu cpf rgqrng itqy.
Ingen!
Det kan være et puslespil for en menneskelig hjerne, men brug en hvilken som helst Caesar-dekoder, og de vil bryde den fra hinanden på få sekunder:
Selv en person, der er velbevandret med Cæsar-chiffer, kan se, at alle bogstaver i chifferteksten er to alfabeter foran deres almindelige tekst-modstykker.
Så pointen er at bruge en stærk chiffer, som den i AES-256.
Hvordan fungerer Cloud Kryptografi?
De sidste par linjer i det foregående afsnit kunne have givet et indtryk af, at du vil vælge en chiffer til at kryptere dataene.
Teknisk set kan det fungere sådan. Men normalt aktiverer cloud-tjenesteudbyderen native kryptering, eller du benytter kryptering-som-en-tjeneste fra en 3.-part.
Så vi deler dette op i to kategorier og ser implementeringen.
#1. Kryptering på Cloud platform
Dette er den mest forenklede metode, hvor den anerkendte cloud-tjenesteudbyder tager sig af krypteringen.
Ideelt set gælder dette for:
Data i hvile
Dette er, når dataene gemmes i krypteret form, før de overføres til lagerbeholderne eller efterfølgende.
Da skykryptografi er en ny tilgang, er der ingen foruddefineret måde at gøre tingene på. Der er mange forskningspublikationer, der tester forskellige metoder, men det, der er afgørende, er anvendelse i det virkelige liv.
Så hvordan beskytter en top-notch cloud-infrastrukturvirksomhed som Google Cloud data i hvile?
Som pr Googles optegnelser, opdeler de dataene i små grupper på nogle få gigabyte spredt ud over deres lagerbeholdere på forskellige maskiner. Enhver specifik container kan indeholde data fra samme eller forskellige brugere.
Desuden er hver pakke krypteret individuelt, selvom de sidder i samme container og tilhører en enkelt bruger. Dette betyder, at hvis krypteringsnøglen, der er relateret til én pakke, bliver kompromitteret, vil andre filer forblive sikre.
Kilde: Google Cloud
Desuden ændres krypteringsnøglen med hver dataopdatering.
Data på dette lagerniveau er krypteret med AES-256, bortset fra nogle få vedvarende diske oprettet før 2015 ved hjælp af AES-128 bit kryptering.
Så dette er det første krypteringslag – på det individuelle pakkeniveau.
Dernæst krypteres de harddiske (HDD) eller solid-state-drev (SSD), der hoster disse datastykker, med et andet lag af AES-256 bit-kryptering, hvor nogle ældre HHD’er stadig bruger AES-128. Bemærk venligst, at krypteringsnøglerne på enhedsniveau er forskellige fra kryptering på lagerniveau.
Nu er alle disse datakrypteringsnøgler (DEK’er) yderligere krypteret med nøglekrypteringsnøgler (KEK’er), som derefter administreres centralt af Googles Key Management Service (KMS). Navnlig bruger alle KEK’er AES-256/AES-128 bit-kryptering, og mindst én KEK er tilknyttet hver Google-skytjeneste.
Disse KEK’er roteres mindst én gang hvert 90-dages interval ved hjælp af Googles fælles kryptografiske bibliotek.
Hver KEK sikkerhedskopieres, spores hver gang nogen bruger den og kan kun tilgås af autoriseret personale.
Dernæst krypteres alle KEK’er igen med AES-256 bit-kryptering, der genererer KMS-hovednøglen gemt i en anden nøgleadministrationsfacilitet, kaldet Root KMS, der gemmer en håndfuld sådanne nøgler.
Dette Root KMS administreres på dedikerede maskiner i hvert Google Cloud-datacenter.
Nu er denne rod-KMS krypteret med AES-256, hvilket skaber en enkelt rod-KMS-hovednøgle, der er gemt i peer-to-peer-infrastrukturen.
Én Root KMS-instans kører på hver rod KMS-hovednøgledistributør, der holder nøglen i hukommelsen med tilfældig adgang.
Hver ny forekomst af root KMS-hovednøgledistributør er godkendt af allerede kørende forekomster for at undgå fejlspil.
For at håndtere den tilstand, hvor alle distributørforekomster skal starte samtidigt, er rod-KMS-hovednøglen også sikkerhedskopieret på kun to fysiske placeringer.
Og endelig har mindre end 20 Google-medarbejdere adgang til disse højt klassificerede lokationer.
Så det er sådan, Google praktiserer cloud-kryptografi for data i hvile.
Men vil du tage sagen i egen hånd, kan du også selv styre nøglerne. Alternativt kan man tilføje endnu et lag af kryptering over dette og selv administrere nøglerne. Man skal dog huske, at tab af disse nøgler også betyder, at man bliver låst ude af sit eget webprojekt.
Alligevel bør vi ikke forvente dette detaljeringsniveau fra alle andre cloud-udbydere. Da Google opkræver en præmie for sine tjenester, kan du drage fordel af en anden udbyder, der koster mindre, men alligevel passer til din specifikke trusselmodel.
Data i transit
Det er her, dataene bevæger sig inden for cloud-udbyderens datacenter eller uden for dets grænser, som når du uploader det fra din egen maskine.
Igen, der er ingen hård linje til at beskytte dataene i transit, så vi vil se Google Cloud-implementeringen.
Whitepaper i denne henseende, kryptering under transportangiver tre foranstaltninger til at sikre ikke-stationære data: autentificering, kryptering og integritetskontrol.
Inden for sit datacenter sikrer Google data i transit ved slutpunktsgodkendelse og integritetsbekræftelse med valgfri kryptering.
Mens en bruger kan vælge yderligere foranstaltninger, bekræfter Google topsikkerhed på sine lokaler med ekstremt overvåget adgang givet til nogle få af sine medarbejdere.
Uden for dets fysiske grænser vedtager Google en differentieret politik for sine egne cloud-tjenester (som Google Drive) og enhver kundeapplikation, der er hostet på dens sky (som enhver hjemmeside, der kører på dens computer).
I det første tilfælde går al trafik først til kontrolpunktet kendt som Google Front End (GFE) ved hjælp af Transport Layer Security (TLS). Efterfølgende får trafikken DDoS-dæmpning, belastningsbalancering på tværs af serverne og ledes til sidst mod den tiltænkte Google Cloud Service.
For det andet tilfælde påhviler ansvaret for at sikre data i transitsikkerhed for det meste ejeren af infrastrukturen, medmindre de ikke bruger en anden Google-tjeneste (som dens Cloud VPN) til dataoverførsel.
Generelt er TLS vedtaget for at sikre, at der ikke er blevet manipuleret med data undervejs. Dette er den samme protokol, der bruges som standard, når du opretter forbindelse til ethvert websted ved hjælp af HTTPS, symboliseret med et hængelåsikon i URL-linjen.
Selvom det er almindeligt brugt i alle webbrowsere, kan du også anvende det til andre applikationer såsom e-mail, lyd-/videoopkald, instant messaging osv.
Men for de ultimative krypteringsstandarder er der virtuelle private netværk, som igen giver flere sikkerhedslag med avancerede krypteringskoder såsom AES-256.
Men det er svært at implementere cloud-kryptografi på egen hånd, hvilket bringer os til…
#2. Kryptering-som-en-tjeneste
Det er her, standardsikkerhedsprotokollerne på din cloudplatform er svage eller fraværende til specifikke brugstilfælde.
En af de åbenlyst bedste løsninger er at overskue alt selv og sikre datasikkerhed i virksomhedskvalitet. Men det er lettere sagt end gjort og fjerner den problemfri tilgang, som nogen vælger cloud computing.
Så det overlader os til at bruge Encryption-as-a-service (EAAS) såsom CloudHesive. I lighed med at bruge cloud computing, denne gang ‘låner’ du kryptering og ikke CPU, RAM, lager osv.
Baseret på EAAS-udbyderen kan du benytte kryptering af data i hvile og under transport.
Fordele og ulemper ved Cloud Kryptografi
Den mest udtalte fordel er sikkerhed. At praktisere cloud-kryptografi sikrer, at dine brugeres data holder sig væk fra cyberkriminelle.
Selvom cloud-kryptografi ikke kan stoppe ethvert hack, handler det om at yde dit bidrag og have en ordentlig begrundelse, hvis tingene går galt.
Når det kommer til ulemper, er den første omkostning og tid det tager at opgradere den eksisterende sikkerhedsramme. Desuden er der ikke meget, der kan hjælpe, hvis du mister adgangen til krypteringsnøglerne, mens du selv administrerer.
Og da dette er en ny teknologi, er det heller ikke let at finde en tidstestet EAAS.
Afslutningsvis er det bedste bud at bruge en velrenommeret cloud-tjenesteudbyder og bank på native kryptografiske mekanismer.
Afslutter
Vi håber, at dette kunne give dig et glimt af cloud-kryptografi. For at opsummere, så handler det om datasikkerhed relateret til skyen, også når den rejser udenfor.
De fleste top-vurderede cloud-infrastrukturvirksomheder som Google Cloud, Amazon Web Services osv., har tilstrækkelig sikkerhed til den maksimale brug. Alligevel er der ingen skade i at gå gennem den tekniske jargon, før du hoster dine missionskritiske applikationer hos nogen.
PS: Tjek nogle cloud-omkostningsoptimeringsløsninger til AWS, Google Cloud, Azure osv.