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 utvidga samma slags kontroller till molnet som den 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).

Den ökande betydelsen av CASB:er går hand i hand med den bredare användningen av molntjänster och BYOD-policyer ("Bring Your Own Device") som tillåter personliga bärbara datorer, smartphones, surfplattor och andra ohanterade enheter i nätverket. Användningen av CASB:er 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% 2018 till 60% 2022 (Gartner, 2018). Under en liknande period förväntas marknaden för molnsäkerhet som helhet öka till cirka 112 miljarder USD 2023 (Forrester, 2017).

CASBs 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å detta problem pekade mer mot kontrollerad aktivering snarare än borttagning av dessa tjänster, började CASBs erbjuda funktionsuppsättningar över fyra pelare: Datasäkerhet, efterlevnad, Threat skydd och kärnfunktionen synlighet.

Synlighet

Många organisationer håller redan på att påskynda 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 denna erosion av centraliserad identitets- och åtkomsthantering (IAM) och förbättra kontrollen över användningen av dessa tjänster genom att utgöra en lämplig barriär utan att hindra den naturliga affärsverksamheten för anställda både på plats och ute på fältet.

Denna konsolidering av åtkomstkontrollerna för molntjänster är till hjälp när det är känt vilka molntjänster som används, men den är inte till hjälp när det gäller 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. Snarare än 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 ligger 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 molntjänster, bland annat de som erbjuds av Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) och det stora utbudet av onlineapplikationer som finns på SaaS-marknaden. Anställda delar redan känsliga data via dessa tjänster - Office 365, Salesforce, Amazon S3, Workday, m.fl. - varav 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 på att identifiera nödvändiga kontroller som inte finns tillgängliga. En nyligen publicerad rapport visade 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 väntas minst 99% av säkerhetsbristerna i molnet bero på misstag som begås av molntjänstkonsumenter snarare än av CSP:er (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äkring så att känsliga data inte kan äventyras, även om det finns felkonfigurationer. En sådan försäkring visar sig vara särskilt nödvändig när adekvat dataskydd inte erbjuds av en viss molntjänst, eller när sådant skydd krävs mot CSP:n själv.

De flesta CASB:er utvecklades från en av två utgångspositioner 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ångslägen 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 kan bara gå så långt i miljöer som gör datadelning inom och mellan molntjänster allt enklare 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 ska till molnet, tenderar dessa funktioner nu att vara begränsade till endast ett litet antal vanliga tjänster, som Salesforce och ServiceNow. CASB:er 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 ämneskompetens för att implementera och underhålla kryptografiska system, och denna expertis 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 allmänna påståenden om "datasäkerhet" som endast behandlar DLP, adaptiv åtkomstkontroll (AAC) och liknande.

Även om antagandet av Clarifying Lawful Overseas Use of Data (CLOUD) Act i USA och den växande förståelsen av 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 införa dem, eftersom kryptering och tokenisering som tillämpas utanför en SaaS-applikation kan påverka dess funktionalitet samt funktionaliteten hos integrerade tredjepartstjänster. Fortsatta innovationer inom tillämpad kryptografi som är tillgängliga via vissa leverantörer, t.ex. OpenText Voltage , har dock minimerat dessa effekter på funktionaliteten så att det nu är värt att utvärdera eventuella kvarvarande effekter i förhållande till kostnaden och risken för att delegera dataskydd på fält- och filnivå till CSP:n, eller att inte tillämpa det alls.

Efterlevnad

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, var de än 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.

Threat upptäckt och förebyggande

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 proxy och/eller som API-broker. 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 man kontrollerar molntjänster.

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) genom att undvika behovet av 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:n och därmed kringgår inspektionen.

CASB:er som distribueras 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 oadministrerade 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 som enbart använder API:er 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 täppa till denna lucka, men under tiden ger CASB:er som endast har API:er inte tillräckligt robusta funktioner för att uppfylla kraven på skalbarhet och tillgänglighet. När CSP:er 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 dessutom ohanterliga prestandaförsämringar. Proxy-läget förblir därför en kritisk kapacitet.

CASB:er kan köras i ett företags datacenter, i en hybriddistribution 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. Dessutom kan den delegering av ansvar och det krav på tredjepartsförtroende som CASB:er som enbart använder molnlösningar 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. Det är därför inte en traditionell CASB eftersom den inte försöker 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 inom flera olika branscher litar på SecureData för att skydda världens mest känsliga data.

Formatbevarande kryptering (FPE), som säkerställer att skyddet 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 administrativa kostnader eller prestandakostnader 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 datareferensintegritet för analys och andra användningsfall samtidigt som det följer regleringar som GDPR:s rätt till radering. Genom ytterligare innovationer, t.ex. säkra lokala index som stöder partiella söktermer och söktermer med jokertecken, och säker formatering av e-postadresser för SMTP-reläer, bevarar Sentry dessutom applikationsfunktioner som påverkas av konkurrerande lösningar.

Organisationer kan distribuera Sentry lokalt och/eller i molnet. Sentry kommunicerar med ICAP (Internet Content Adaptation Protocol) -kompatibel nätverksinfrastruktur, t.ex. HTTP-proxyer och lastbalanserare, för att tillämpa säkerhetspolicyer på data som skickas till och från molnet, och det fångar upp 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.