Fujitsu: Een cloud access security broker; wanneer en waarom?

We werken tegenwoordig overal. Grenzen vervagen en bedrijfsdata staat niet meer op één locatie maar ook in Microsoft Office365, Salesforce, Dropbox of andere cloudapplicaties. Desondanks dien je je databeveiligingsbeleid toe te blijven passen en te verantwoorden. Door die veelheid aan locaties en plaatsen waar bedrijfsdata zich kan bevinden, zoeken veel organisaties naar een manier om hier controle op te krijgen. Veelal wordt dan naar een Cloud Access Security Broker (CASB) gekeken. Maar wat is een CASB-oplossing, wanneer en waarom heb je dat nodig en hoe begin je?

 

Een CASB wordt tussen het bedrijfsnetwerk en de cloudapplicaties gepositioneerd. Hierdoor wordt er inzicht in het gebruik van cloudapplicaties verkregen, de bedrijfsdata van en naar cloudapplicaties wordt beschermd en onder andere door de centrale policies (beveiligingsbeleid) wordt er controle verkregen vanuit één interface.

Het klinkt ingewikkeld

Veelal is een CASB-oplossing een combinatie van een forward en een reverse proxy (gateway) met API-koppelingen. Dat klinkt ingewikkeld maar is eigenlijk eenvoudig. De forward proxy zorgt voor een controle op de data die onderweg is naar de cloudapplicatie: de ‘data-in-transit’. Op basis van de ingestelde policy en verificatie kunnen dan acties worden ondernomen, zoals toegangscontrole op de cloudapplicatie en vanaf welk apparaat, locatie, tijd of andere factoren zoals Data Loss Prevention (DLP). Ook kunnen veel CASB-oplossingen de loggegevens van proxies en firewalls analyseren. Met deze functie wordt de zogenaamde schaduw-IT van een bedrijf inzichtelijk gemaakt.

De reverse proxy is vooral voor de toepassing bij niet beheerde apparaten. Hierbij maakt de gebruiker direct verbinding met de cloudapplicatie; hierin wordt de CASB tijdens het authenticatieproces tussen de gebruiker en de cloudapplicatie geplaatst en wordt het verkeer via de CASB afgehandeld. Alle CASB-oplossingen hebben API-koppelingen met de cloudapplicatie voor de controle over de data die in de cloudapplicatie is opgeslagen (‘data-in-rest’). Een API-koppeling is in de verschillende CASB-oplossingen voor de meest gangbare cloudapplicaties beschikbaar; denk dan aan Microsoft Office365, Google apps/suite, Dropbox, Box, Salesforce, ServiceNow, Microsoft Azure of AWS. Door middel van de API-koppeling worden de data in de cloudapplicatie en de activiteiten met de data gecontroleerd en kunnen acties worden toegepast.

Wanneer en waarom een CASB

Wanneer heeft een bedrijf een dergelijke oplossing nodig? Om hier antwoord op te geven beginnen we met het eind- resultaat. Welk probleem dient er te worden opgelost? Vaak wordt er dan over de zogenaamde ‘use cases’ gesproken.

Een use case is feitelijk niets anders dan een functionele beschrijving van een situatie, zoals vanaf je privé-werkplek inloggen op Office365 om een dossier te downloaden en te bewerken. Daar is niets mis mee, behalve wanneer het bedrijfsbeleid niet toestaat om (vertrouwelijke) documenten op een privé-werkplek op te slaan. Deze situatie wil het bedrijf dus voorkomen of detecteren zodat er actie kan worden ondernomen. Door het opstellen van dergelijke use cases kan er worden beoordeeld of de huidige maat- regelen voldoende zijn of dat er aanvullende maatregelen nodig zijn zoals een CASB.

Mogelijke situaties

Het eindresultaat bestaat uit een aantal situaties:

1) Gebruikers op beheerde apparaten (werkplek/laptop/tablet/smartphone) maken verbinding met een toegestane cloudapplicatie zoals Microsoft Office365, Salesforce, et cetera;

2) Gebruikers op beheerde apparaten maken verbinding met ongewenste cloudapplicaties;

3) Gebruikers op onbeheerde apparaten, maken verbinding met toegestane cloudapplicaties;

4) Overig.

Iedere genoemde situatie bevat use cases waar een bedrijf controle over wil verkrijgen. Dit betekent niet direct het verbieden van de situatie maar eerder het inzicht en grip krijgen op de situatie waardoor de juiste maatregelen c.q. acties kunnen worden genomen.

Situatie 1
Een gebruiker die op een beheerd apparaat werkt en vervolgens verbinding maakt met een toegestane cloudapplicatie is relatief eenvoudig. Er is immers controle over wie (gebruiker) met wat (beheerd apparaat) waar naartoe (toegestane cloudapplicatie) gaat. Wat de gebruiker vervolgens in de cloudapplicatie doet, is de volgende stap. De gebruiker kan besluiten om een document vanuit de cloudapplicatie te kopiëren of te downloaden richting een niet toegestane cloudapplicatie. Dit kan een situatie (use case) zijn waar een bedrijf controle over wilt verkrijgen.

Situatie 2
Een gebruiker die vanaf een beheerd apparaat verbinding maakt met een ongewenste cloudapplicatie is een situatie die veel voor komt. Zo kan een gebruiker bijvoorbeeld een e-mail ontvangen met een link naar een bestand op een ongewenste cloudapplicatie, bijvoorbeeld Dropbox. De gebruiker willen we hier niet beperken om het document op te halen, alleen willen we wellicht voorkomen dat er documenten kunnen worden geüpload naar de ongewenste cloudapplicatie.

Een andere situatie is bijvoorbeeld dat een bedrijf inzicht wilt verkrijgen of er ongewenste cloudapplicaties worden gebruikt door zijn gebruikers. Dit inzicht kan het bedrijf gebruiken om een cloudapplicatie wel toe te staan of om veiligere alternatieven aan de gebruiker te bieden.

Situatie 3
Of het is toegestaan dat een gebruiker verbinding maakt met een cloudapplicatie vanaf een onbeheerd apparaat zoals een privé-werkplek of een smartphone verschilt per bedrijf. Wellicht is het werken aan documenten in de cloudapplicatie toegestaan, maar het downloaden of uploaden van documenten juist niet. Of misschien is er ‘alleen lezen’ toegestaan en het editen niet of dient daarvoor een tweede vorm van authenticatie plaats te vinden.

Situatie 4
Overige situaties kunnen bijvoorbeeld zijn dat een gebruiker (of hacker) een aantal keren verkeerd inlogt of binnen een bepaald tijdsbestek vanaf meerdere locaties tracht in te loggen. Maar het kan ook gaan om het zoeken naar shares of bestanden die met niet toegestane personen of bedrijven wordt gedeeld.

Functionele eisen

Naast de genoemde situaties zijn er ook nog de functionele eisen en niet-functionele eisen. Hieronder is een aantal functionele eisen opgesomd:
– Er dienen ‘Data Loss Prevention’capaciteiten aanwezig te zijn zoals het zoeken op keywords, regular expressions en hier kunnen acties op worden toegepast;
– Er dienen acties te kunnen worden ingesteld zoals het blokkeren, toestaan, versleutelen, classificeren en labelen, of bijvoorbeeld het controleren en beschermen tegen malware ‘in transit’ en ‘at rest’;
– Meldingen uit de oplossing dienen via een standaardkoppeling naar een SIEM-systeem (Security Information & Event Management) van het bedrijf te kunnen worden verstuurd;
– Er dient een simulatie van de datapolicy mogelijk te zijn;
– De oplossing draait in het eigen datacenter (on premise) of dient cloudgebaseerd te zijn;
– Indien het cloud-gebaseerd is, dan kan de geografische regio worden gekozen waardoor de data in de EU blijft in relatie tot AVG/GDPR-regelgeving.

Op basis van de use cases, de functionele en niet-functionele eisen kan er worden bepaald welke oplossing nodig is en het beste integreert met de reeds aanwezige security-oplossingen bij de klant. Fujitsu werkt samen met een aantal leveranciers om op die manier – op basis van de use cases die relevant zijn voor de klant – een keuze te maken met welke leverancier de vraag van de klant het beste kan worden ingevuld.

* Johan Pater is Senior Pre-sales Security Consultant Enterprise and Cyber Security bij Fujitsu.

[Dit artikel is eerder gepubliceerd in ChannelConnect magazine 2019, nummer 2]

Lees het artikel hier in PDF