SaaS (Software as a Service) is al geruime tijd in opkomst, wat niet verwonderlijk is, gezien SaaS zeker de nodige voordelen met zich meebrengt. Steeds vaker ontstaat dan ook de vraag: moet ik deze applicaties beveiligen en hoe doe ik dit?
Het voordeel van SaaS is dat de SaaS leverancier alle rompslomp voor zijn rekening neemt en dat de gebruiker de applicatie voorgeschoteld krijgt. Echter, een deel van deze ‘rompslomp’ bevat ook het onderdeel security. Dit betekent dat, of het nou links- of rechtsom gaat, de leverancier een grote invloed heeft op de mate waarin SaaS applicaties te beveiligen zijn. Belangrijk hierbij is om niet te vergeten dat je altijd zelf verantwoordelijk blijft voor de data!
Waar moet ik op letten?
Het is belangrijk om vooraf te bepalen aan welke eisen een SaaS leverancier moet voldoen, of beter gezegd, wat zijn de beveiligingsmaatregelen die minimaal ingeregeld moeten worden, bijv. MFA, Data at rest encryption, etc.
Het helder hebben van deze eisen voorkomt dat je een leverancier kiest waarbij je deze maatregelen niet kunt inregelen. Een belangrijk verschil tussen SaaS en een ‘doe-het-zelf’ omgeving is dat je ‘vergeten’ maatregelen vaak achteraf nog kunt realiseren.*
Jij blijft verantwoordelijk voor de data in SaaS
Besef ook dat de ‘data’ verantwoordelijkheid nog steeds bij de organisatie ligt en dat deze verantwoordelijkheid nooit bij de SaaS leverancier komt te liggen. Als je eenmaal een SaaS applicatie hebt afgenomen, is het lastig te bepalen welke security maatregelen er wel en niet ingeregeld kunnen worden.
Hier geldt een grote afhankelijkheid van wat de SaaS leverancier kan en wil bieden. Daarbij komt nog eens dat vertrekken een lastige optie kan zijn, want is er überhaupt een alternatief? En hoe garandeer ik dat mijn data daadwerkelijk weg is?
Kortom: Maak van te voren een goede inventarisatie van de eigen eisen en risico’s. Dit kan achteraf veel moeite en problemen besparen.
* Hierbij laten we even achterwege dat achteraf security maatregelen implementeren (bolted-on security) nooit de gewenste aanpak is.
Wat kan ik zelf doen?
Naast het zorgvuldig opstellen van de eisen zijn er een aantal zaken die je zelf kunt aanpakken:
Allereerst is het belangrijk dat de gewenste beveiligingsmaatregelen ook daadwerkelijk actief zijn binnen de SaaS omgeving. De grotere leveranciers zoals bijv. Office365 en G Suite bieden veel security instellingen. Het is echter wel belangrijk dat deze ingesteld worden naar behoefte.
Daarnaast is het belangrijk om met enige regelmaat te controleren of deze instelling nog steeds naar wens staan en functioneren. Het controleren van deze instellingen kan uiteraard handmatig, er zijn echter ook tools beschikbaar die dit werk uit handen nemen en zelfs voor automatische remediatie kunnen zorgen. Let wel, deze tools werken vaak alleen voor de grotere SaaS diensten.
Logging en alerting
Ook bieden grotere SaaS diensten een keur aan logging en alerting om na te gaan wat er gebeurt. Zeker voor alerting geldt, zorg dat deze tijdig opgepikt wordt. Zelfs als het een ‘informatief’ alert is, was er blijkbaar een reden om er een alert van te maken.
Meestal kunnen deze alerts eenvoudig aan een ticketsystem gekoppeld worden, waardoor deze alerts netjes als tickets verschijnen in het al in gebruik zijnde ticketingsysteem.
Helaas bieden niet alle SaaS leveranciers een keur aan beveiligingsmaatregelen om in te regelen. Mocht het aantal maatregelen beperkt zijn, dan kan het lonen om in ieder geval te controleren of ‘IP whitelisting’ ondersteund wordt.
IP whitelisting
Deze functionaliteit beperkt vanaf welke locaties (IP adressen) er ingelogd kan worden op de SaaS applicatie. Door deze locaties te beperken, bijv. tot de on-premises datacenters, wordt de ‘attack vector’ drastisch verkleind. Hierbij is het belangrijk dat gebruikers altijd via deze locaties (IP adressen) bij de SaaS applicatie komen, bijvoorbeeld. met behulp van een VPN. Er wordt wellicht flexibiliteit ingeleverd (overal altijd inloggen), maar de controle en het verkleinen van de ‘attack vector’ die er voor terugkomt is het vaak meer dan waard.
Het sturen van het netwerkverkeer heeft als bijkomend voordeel dat er eventueel extra maatregelen genomen kunnen worden op de datastroom; denk hierbij aan aanvullende authenticatie of met welke bestanden er gewerkt mag worden. Tevens zijn er extra rapportagemogelijkheden, bijv. welke SaaS applicaties er door welke gebruikers worden gebruikt.
Conclusie
SaaS applicaties brengen vele voordelen, maar nemen niet de verantwoordelijkheid over voor de data die er verwerkt wordt.
Het is dan ook belangrijk om vooraf goed te bepalen:
- welke data breng ik onder bij de SaaS leverancier
- welke risico’s gaan hiermee gepaard
- hoe wil ik deze data beschermen?
Hoewel er een grote afhankelijkheid is van de maatregelen die de SaaS leverancier biedt, zijn er een aantal zaken die je zelf kunt regelen, waar het controleren van het netwerkverkeer de eenvoudigste is. Vanuit Zero Trust gedachten kun je een SaaS applicatie vaak het beste zien als een segment, met zijn eigen classificatie en maatregelen.
