Vad är en CASB (Cloud Access Security Broker)?

En Cloud Access Security Broker (CASB, uttalas KAZ-bee) är en lokal eller molnbaserad policyhanteringspunkt som placeras mellan molntjänstkonsumenter och molntjänstleverantörer (CSP) för att övervaka molnrelaterad aktivitet och tillämpa säkerhets-, efterlevnads- och styrningsregler relaterade till användningen av molnbaserade resurser. En CASB gör det möjligt för en organisation att utöka samma slags kontroller till molnet som de skulle tillämpa på lokal infrastruktur, och kan kombinera olika typer av policygenomförande, t.ex:

• Autentisering av användaruppgifter så att åtkomst endast ges till godkända molntjänster.
• Dataskydd genom kryptering, tokenisering eller andra metoder så att känslig information inte exponeras i molntjänster eller för CSP:er.
• Aktivitetsövervakning av molntjänster så att användares och enheters beteende kan loggas, flaggas och analyseras för avvikande användningsmönster eller komprometterade inloggningsuppgifter.
• Skydd mot dataförlust (DLP) så att känslig information inte kan lämna organisationens nätverk, samt upptäckt och åtgärdande av skadlig programvara så att känslig information inte kan komma in i organisationens nätverk.

Syftet med en CASB är således att förbättra en organisations förmåga att dra nytta av molntjänster på ett tryggt och säkert sätt. En CASB kan ses som en "säkerhetsnod" genom vilken åtkomsten till en organisations molntjänster kontrolleras. Som en del av en organisations säkerhetsinfrastruktur kompletterar den, snarare än ersätter, tekniker som brandväggar för företag och webbapplikationer, IDaaS (IDentity as a Service) och säkra webbgateways (SWG).

CASB:ernas ökande betydelse går hand i hand med det bredare införandet av molntjänster och BYOD-policyer ("Bring Your Own Device") som tillåter personliga bärbara datorer, smartphones, surfplattor och andra icke-hanterade enheter i nätverket. Användningen av CASB för att kontrollera vissa eller alla av en organisations molntjänster ökar och det förväntas att större företags användning kommer att tredubblas, från 20% år 2018 till 60% år 2022 (Gartner, 2018). Under en liknande period förutspås marknaden för molnsäkerhet som helhet öka till cirka 112 miljarder dollar 2023 (Forrester, 2017).

CASB:er fokuserade ursprungligen på att upptäcka okända tjänster som användes av individer eller affärsenheter utanför de som var tillåtna av IT-avdelningen - men när organisationer insåg att lösningen på det här problemet snarare pekade mot kontrollerad aktivering än borttagning av dessa tjänster började CASB:er erbjuda funktioner inom fyra pelare: Datasäkerhet, efterlevnad, hotskydd och kärnfunktionen synlighet.

Synlighet

Många organisationer har redan påskyndat det formella införandet av cloud computing inom en rad olika affärsenheter. Detta kan leda till att allt fler anställda hanterar sina egna säkerhetsuppgifter för IaaS-resurser (Infrastructure as a Service), PaaS-resurser (Platform as a Service), SaaS-resurser (Software as a Service) och nu även FaaS-resurser (Functions as a Service). I den här miljön kan CASB:er hjälpa till att överbrygga de säkerhetsluckor som skapats genom att den centraliserade identitets- och åtkomsthanteringen (IAM) har urholkats och förbättra kontrollen över användningen av dessa tjänster genom att utgöra en lämplig barriär utan att hindra anställda från att bedriva sin verksamhet, både på plats och ute på fältet.

Denna konsolidering av åtkomstkontrollerna för molntjänster hjälper när det är känt vilka molntjänster som används, men det hjälper inte mot skugg-IT. Sådana tjänster kan användas för att kringgå upplevda eller faktiska brister i en organisations officiella IT-stack, eller så kan de bara vara en enkel återspegling av användarnas preferenser. I stället för att vara en aktivitet som måste stoppas kan användningen av dem faktiskt vara avgörande för produktivitet, effektivitet, medarbetarnöjdhet och till och med som en källa till innovation, men det är osannolikt att den är i linje med organisationens säkerhetspolicy eller andra IT-krav på support, tillförlitlighet, tillgänglighet etc. och kan också vara en källa till skadlig kod som kan leda till ett katastrofalt dataintrång.

En CASB kan hjälpa till att lyfta fram en organisations skugg-IT i ljuset, vilket inte bara möjliggör stöd för nödvändiga arbetsmetoder samtidigt som det säkerställs att de inte äventyrar uppdraget, utan också belyser verkliga molnutgifter som möjliggör förbättringar i kostnadskontrollen.

Datasäkerhet

Många organisationer håller redan på att flytta IT-resurser från sina egna datacenter till flera olika moln, inklusive de som erbjuds av Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) och de många onlineapplikationer som finns tillgängliga på SaaS-marknaden. Anställda delar redan känsliga uppgifter via dessa tjänster - Office 365, Salesforce, Amazon S3, Workday m.fl. - av vilka många tillämpar någon form av delat ansvarsmodell som innebär att ansvaret för datasäkerheten läggs på kunden.

Oron för säkerheten i själva molnet är dock till stor del missriktad. Infrastrukturen hos de flesta CSP:er, särskilt de som erbjuder tjänster som har blivit vanliga, är onekligen mycket säker. Istället bör man fokusera på korrekt konfiguration av de säkerhetskontroller som CSP:n erbjuder, samt identifiering av nödvändiga kontroller som inte är tillgängliga. I en nyligen publicerad rapport upptäcktes att över 1,5 miljarder filer exponerades i molntjänster och molnrelaterade tjänster som S3, rsync, SMB, FTP, NAS-enheter och webbservrar, enbart på grund av sådana felaktiga eller saknade konfigurationer (Digital Shadows, 2018). Fram till 2023 förväntas minst 99% av säkerhetsbristerna i molnet bero på misstag som begås av molntjänstkonsumenterna snarare än av CSP:erna (Gartner, 2018). Även om vissa CASB:er nu erbjuder CSPM-funktioner (Cloud Security Posture Management) för att bedöma och minska konfigurationsrisken i IaaS-, PaaS- och SaaS-erbjudanden genom ytterligare kontroller som kryptering, kan en CASB ge en organisation ytterligare försäkringar så att känsliga data inte kan äventyras, även om det finns felkonfigurationer. En sådan försäkring är särskilt nödvändig när en viss molntjänst inte erbjuder tillräckligt dataskydd, eller när sådant skydd krävs mot CSP:n själv.

De flesta CASB:er har utvecklats från en av två utgångslägen när det gäller datasäkerhet: fokus på förebyggande av dataförlust (DLP) och upptäckt av hot, eller kryptering eller tokenisering för att hantera integritet och datalagring. Även om dessa utgångspositioner senare har utökats till att omfatta alla dessa funktioner, har det skett en förskjutning bort från att erbjuda robust datacentrerad säkerhet och nyckelhantering. För de flesta CASB:er innebär datasäkerhet idag främst DLP, som använder en mängd olika mekanismer för att upptäcka känsliga data i sanktionerade molntjänster eller när de laddas upp till molntjänster - sanktionerade eller skuggade - och sedan blockera, radera, placera i juridisk väntan eller sätta i karantän innehåll som flaggas som ett potentiellt policybrott. Detta stöder vanligtvis både lokala användare och fjärranvändare av molntjänster, oavsett om det är från mobila applikationer, webbläsare eller synkroniseringsklienter för skrivbord. Men DLP räcker inte långt i miljöer där det blir allt enklare att dela data inom och mellan molntjänster innan ett intrång inträffar. Alla organisationer som använder molnet för att lagra data bör inse att en CASB kanske inte kan upptäcka hur eller med vem dessa data delas från molnet, eller ens vem som delade dem.

Starka datacentrerade skyddsmekanismer kan hantera denna risk för intrång, men även om många CASB:er annonserar möjligheten att kryptera eller tokenisera data som är avsedda för molnet, tenderar dessa funktioner nu att vara begränsade till endast ett litet antal vanliga tjänster, till exempel Salesforce och ServiceNow. CASB-företag som började lägga till dessa funktioner - lika mycket för att tillfredsställa analytikernas betyg som för att uppnå eller bibehålla konkurrensparitet - upptäckte att kryptografi är en utmanande teknisk domän. Det krävs betydande sakkunskap för att implementera och underhålla kryptografiska system, och denna sakkunskap faller vanligtvis inte inom ramen för CASB:s kärnkompetenser. Som ett resultat av detta har vissa CASB:er dragit tillbaka eller marknadsför inte längre dessa funktioner aktivt, och vissa döljer deras bristande kapacitet eller begränsade tillämplighet genom generella påståenden om "datasäkerhet" som endast tar upp DLP, adaptiv åtkomstkontroll (AAC) och liknande.

Även om antagandet av Clarifying Lawful Overseas Use of Data (CLOUD) Act i USA och den ökande förståelsen för EU:s allmänna dataskyddsförordning (GDPR) starkt tyder på att kryptering och nyckelhantering håller på att bli kritiska funktioner (Gartner, 2019), har det funnits en viss tvekan när det gäller att anta dem, eftersom kryptering och tokenisering som tillämpas utanför en SaaS-applikation kan påverka dess funktionalitet samt integrerade tjänster från tredje part. Fortsatta innovationer inom tillämpad kryptografi som är tillgängliga via vissa leverantörer som OpenText Voltage har dock minimerat dessa effekter på funktionaliteten så att det nu är värt att bedöma eventuella kvarvarande effekter i förhållande till kostnaden och risken med att delegera dataskydd på fält- och filnivå till CSP, eller att inte tillämpa det alls.

Efterlevnad

Tillkomsten av strängare integritetslagar i många branscher och regioner kan också påverka verksamheten. Regionala bestämmelser som GDPR, California Consumer Privacy Act (CCPA), Brazilian General Data Protection Law (LGPD) och India Personal Data Protection Bill, samt branschbestämmelser som de som införs av PCI DSS, SOX, HIPAA, HITECH, FINRA och FFIEC skapar en rad efterlevnadskrav vars komplexitet driver många organisationer mot den mest konservativa globala positionen: att säkerställa att företagets och dess kunders känsliga data alltid skyddas, oavsett var de befinner sig, och i högsta möjliga grad.

En CASB med starka dataintegritetskontroller i flera applikationer kan hjälpa till att uppnå detta; och genom policymedvetenhet och dataklassificeringsfunktioner kan CASB hjälpa till att säkerställa efterlevnad av lagar om dataresidens och att jämföra säkerhetskonfigurationer med ständigt uppdaterade lagkrav.

Upptäckt och förebyggande av hot

En CASB kan försvara organisationen mot den ständigt växande arsenalen av skadlig kod, inklusive introduktion och spridning via molnlagringstjänster och deras tillhörande synkroniseringsklienter och applikationer. En CASB kan använda avancerade hotinformationskällor för att skanna och åtgärda hot i realtid över interna och externa resurser; identifiera komprometterade användarkonton genom att upptäcka och förhindra obehörig åtkomst till molntjänster och data; och kombinera statiska och dynamiska analyser med maskininlärning och UEBA (User Entity Behavior Analytics) för att identifiera avvikande aktiviteter, ransomware, dataexfiltrering, etc.

Hur fungerar en CASB?

CASB kan distribueras som proxies och/eller som API-brokers. Eftersom vissa CASB-funktioner beror på driftsättningsmodellen ger "multimodala" CASB:er - de som stöder både proxy- och API-lägen - ett bredare utbud av valmöjligheter för hur molntjänster ska kontrolleras.

CASB:er som används i proxyläge är vanligtvis inriktade på säkerhet och kan konfigureras som omvända eller framåtriktade proxyer i dataåtkomstvägen, mellan molntjänstkonsumenten och CSP:n. CASB:er med omvänd proxy kräver inte att agenter installeras på slutpunkter och kan därför fungera bättre för ohanterade enheter (t.ex. BYOD) eftersom de inte kräver konfigurationsändringar, certifikatinstallationer och så vidare. De kontrollerar dock inte osanktionerad molnanvändning lika bra som forward-proxy CASB:er gör, genom vilka all trafik från hanterade slutpunkter dirigeras, inklusive trafik till osanktionerade molntjänster: detta innebär att vissa ohanterade enheter kan slinka igenom nätet. Forward-proxy CASB:er kräver därför ofta installation av agenter eller VPN-klienter på slutpunkterna. Om agenter och VPN-klienter är felkonfigurerade eller av misstag avstängda kan det hända att känslig trafik inte vidarebefordras till CASB och därmed kringgår inspektionen.

CASB:er som används i API-läge fokuserar på administration av SaaS-applikationer (och i allt högre grad IaaS- och PaaS-applikationer) via API:er som tillhandahålls av dessa tjänster, inklusive inspektion av data i vila, loggtelemetri, policykontroll och andra hanteringsfunktioner. De fungerar bra med ohanterade enheter, men eftersom det bara är de vanliga molntjänsterna som erbjuder API-stöd - och det i varierande grad - är det osannolikt att CASB:er med enbart API-stöd täcker alla nödvändiga säkerhetsfunktioner. Det är möjligt att SaaS-leverantörer och andra CSP:er kan förbättra sina API:er för att överbrygga detta gap, men under tiden erbjuder CASB:er som endast använder API:er inte tillräckligt robusta funktioner för att uppfylla kraven på skalbarhet och tillgänglighet. När CSP:er dessutom stryper svaren på API-förfrågningar på grund av den ökande volymen data som utbyts mellan användare och molntjänster, upplever CASB:er i API-läge ohanterliga prestandaförsämringar. Proxy-läget är därför fortfarande en kritisk funktion.

CASB:er kan köras i ett företags datacenter, i en hybridinstallation som omfattar både datacenter och molnet, eller uteslutande i molnet. Organisationer som fokuserar på datacentrerat skydd, eller som är föremål för sekretessbestämmelser eller datasuveränitetsöverväganden, tenderar att kräva lokala lösningar för att behålla fullständig kontroll över säkerhetsinfrastrukturen. Vidare kan den delegering av ansvar och det krav på tredjepartsförtroende som CASB:er som endast tillhandahåller molnbaserade tjänster inför genom BYOK-modellen (Bring Your Own Key) strida mot interna eller externa policyer, och denna problematiska position sträcker sig naturligtvis till säkerhetstjänster som erbjuds av CSP:erna själva, som också kan kräva att CASB:ens IP-adresser vitlistas.

Är Voltage Secure Data Sentry en CASB?

Voltage SecureData Sentry är en Security Broker som specialiserar sig på dataskydd, inte bara för molntjänster utan även för lokala applikationer. Den är därför inte en traditionell CASB eftersom den inte strävar efter att tillhandahålla andra funktioner inom de fyra pelarna. Istället samexisterar Sentry med CASB:er som specialiserar sig på att tillhandahålla dessa kompletterande funktioner, samtidigt som de gör det kryptografiska grovjobbet för att lägga till starka datacentrerade skyddsmekanismer som kan tillämpas på SaaS och andra molntjänster samt på kommersiella och egenutvecklade applikationer i interna nätverk.

Voltage SecureData är innovativt och standardbaserat och har varit föremål för oberoende verifieringar av säkerhetsstyrkan av internationellt erkända, oberoende kryptografiska organ. Många ledande globala organisationer inom den offentliga och privata sektorn och i flera olika branscher litar på att den skyddar världens mest känsliga data.

Formatbevarande kryptering (FPE), som säkerställer att skydd tillämpas på fältnivå på ett sätt som inte bryter mot befintliga databasscheman eller SaaS-fälttyp- eller storleksbegränsningar, kombineras med ett statslöst nyckelhanteringssystem som undviker ytterligare bördor för säkerhetsadministratörer. Secure Stateless Tokenization (SST) säkerställer att numeriska fält som innehåller kreditkortsnummer eller SSN skyddas utan de kostnader för hantering eller prestanda som en token-databas medför, samtidigt som utvalda delar av fältet kan förbli oskyddade, t.ex. de sex första eller fyra sista siffrorna, för att stödja routing eller kundverifiering. Format-Preserving Hash (FPH) säkerställer referensintegritet för data för analys och andra användningsfall samtidigt som det följer bestämmelser som GDPR:s rätt till radering. Genom ytterligare innovationer, som t.ex. säkra lokala index som stöder partiella söktermer och söktermer med jokertecken samt säker formatering av e-postadresser för SMTP-vidarebefordran, bevarar Sentry applikationsfunktioner som påverkas av konkurrerande lösningar.

Organisationer kan driftsätta Sentry lokalt och/eller i molnet. Sentry kommunicerar med nätverksinfrastruktur som klarar ICAP (Internet Content Adaptation Protocol), t.ex. HTTP-proxyservrar och lastbalanserare, för att tillämpa säkerhetspolicyer på data som skickas till och från molnet och avlyssnar JDBC- (Java Database Connectivity) och ODBC- (Open Database Connectivity) API-anrop för att tillämpa säkerhetspolicyer på data som skickas till och från databasen. Oavsett var den distribueras behåller företaget fullständig kontroll över infrastrukturen, utan att behöva dela krypteringsnycklar eller tokenvalv med någon annan part, och Sentrys inspektionsläge säkerställer att säkerhetspolicyer kan riktas mot de specifika datafält och filbilagor som innehåller känslig information.