SaaS-applicaties: URL, gebruikersnaam en wachtwoord: Klaar?

Deel 5: e-mail

Inleiding

In het eerste blogartikel uit deze serie heb ik aandachtspunten beschreven voor de architectuur van een hybride applicatielandschap met meerdere SaaS-applicaties van verschillende leveranciers, applicaties in het eigen rekencentrum (‘on premise’) en applicaties in de ‘eigen’ cloud van de organisatie. 

Dit artikel beschrijft het vraagstuk van e-mail in een applicatielandschap met verschillende ‘on premise’ en SaaS-applicaties.

SaaS-applicaties en e-mail

Veel SaaS-applicaties beschikken over voorzieningen voor verzenden en ontvangen van e-mail, bijvoorbeeld:

• Als herinnering aan een toegewezen taak of actie in een proces (‘Er staat een declaratie klaar om goed te keuren’).
• Informatie over een uitgevoerde actie, bijvoorbeeld een inschrijving voor een training of cursus in een online leeromgeving.

Het gebruik van e-mail van/door SaaS-applicaties heeft gevolgen voor een aantal aspecten:

• Informatiebeveiliging: het gebruik van e-mail moet veilig zijn, zowel de (technische) voorzieningen van de SaaS-applicatie als voor de ontvangers van de e-mail.
• Inzicht en overzicht: een organisatie heeft inzicht en overzicht nodig over het e-mailverkeer van de organisatie.
• Informatiebeheer: Informatiebeheer van e-mail wordt (nog) complexer.
  E-mail wordt opgeslagen op de e-mailvoorziening van de SaaS-applicatie. De e-mail van de organisatie staat op meerdere e-mailservers, met verschillende bewaartermijnen, contracttermijnen etc.
  Informatiebeheer is voor overheidsorganisaties extra belangrijk omdat zij moeten voldoen aan verplichtingen uit o.a. de archiefwet en de wet open overheid (WOO).
• Inrichting en beheer: De activiteiten voor de technische inrichting en technisch beheer van de e-mail voorziening.

De volgende paragrafen beschrijven varianten voor het omgaan met e-mail door SaaS-applicaties en de consequenties daarvan op de hierboven genoemde aspecten.

De e-mailvoorzieningen van de SaaS-applicaties gebruiken

De SaaS-applicaties verzenden e-mail met een eigen e-mailadres van de SaaS-applicatie. De e-mailvoorziening van de SaaS-applicatie is geheel onafhankelijk van de e-mailvoorziening van de organisatie.

Dit is weergegeven in figuur 1. 

De consequenties voor de genoemde aspecten zijn:

• Informatiebeveiliging: Als iedere SaaS-applicatie mail met e-mailadres van de SaaS-applicatie verstuurd, dan vergroot het risico op ‘phishing’.
  Gebruikers zijn/ raken gewend aan e-mails – vaak met link naar de SaaS-applicatie – met verschillende ‘afzenders’.  De kans neemt toe dat gebruikers ‘phishing’ e-mails niet als zodanig herkennen en de ‘phishing’ e-mail als een ‘echte’ e-mail “verwerken”.
• Inzicht en overzicht: De organisatie heeft geen direct zicht op, en directe controle over, het e-mailverkeer van de SaaS-applicaties. Voor inzicht en overzicht moet de organisatie de gegevens van de verschillende SaaS-applicaties combineren. De organisatie is hierbij afhankelijk van de mate waarin de leveranciers van de SaaS-applicaties inzicht het e -mail verkeer van de organisatie kunnen (en willen) verschaffen.
• Informatiebeheer: De e-mails van de SaaS-applicatie worden opgeslagen op de e-mailserver van de SaaS-applicaties. De e-mail van de organisatie staat dus op meerdere verschillende e-mailservers, met verschillende bewaartermijnen etc.
  De organisatie moet maatregelen nemen om de e-mail van de SaaS-applicatie ‘veilig te stellen’ als het gebruik van de SaaS-applicatie beëindigd wordt.
• Inrichting en beheer: Dit is voor de organisatie de eenvoudigste variant om e-mail in te richten.

De SaaS-applicatie verstuurt e-mail namens de organisatie

De SaaS-applicatie wordt ‘gemachtigd’ om e-mail te versturen met e-mailadres(sen) van de organisatie. De e-mailvoorziening van de SaaS-applicatie is geheel onafhankelijk van de e-mailvoorziening van de organisatie.

De organisatie (domeinnaamhouder) gebruikt het ‘Sender Policy Framework’ (SPF) om aan te geven dat de e-mailserver van de SaaS-applicatie namens de domeinnaam van de organisatie e-mail mag versturen. Ontvangende e-mailservers kunnen met behulp van SPF controleren of een e-mail is verzonden door een geautoriseerde e-mailserver[1].

Dit is schematisch weergegeven in figuur 2.

De consequenties voor de genoemde aspecten zijn:

• Informatiebeveiliging: De kans op ‘phishing’ is lager dan de voorafgaande variant: gebruikers ontvangen alleen e-mail van SaaS- applicaties met een e-mailadres van de organisatie. De kans dat ‘phishing’ mails door gebruikers herkend worden is groter.
  Misbruik van de e-mail van de SaaS-applicaties kan grote impact hebben: reputatieschade voor de organisatie en/of twijfels aan de betrouwbaarheid van e-mail van de organisatie.
• Inzicht en overzicht: De organisatie heeft geen zicht op, en controle over, het e-mailverkeer van de SaaS-applicaties.
• Informatiebeheer: De e-mails van de SaaS-applicatie worden opgeslagen op de e-mailserver van de SaaS-applicaties. De e-mail van de organisatie staat dus op meerdere verschillende e-mailservers, met verschillende bewaartermijnen etc.
  De organisatie moet maatregelen nemen om de e-mail van de SaaS-applicatie ‘veilig te stellen’ als het gebruik van de SaaS-applicatie beëindigd wordt.
• Inrichting en beheer: SPF-records moeten beheerd worden. Bij grotere aantallen kan dit onoverzichtelijk worden.

SaaS-applicaties versturen e-mail via de e-mailvoorziening van de organisatie

Bij deze variant gebruikt de SaaS-applicatie de e-mailvoorziening van de organisatie voor het versturen van de e-mail. Voor iedere SaaS-applicatie wordt een mailbox ingericht op de e-mailserver van de organisatie. De e-mailvoorziening van de SaaS-applicatie verstuurt de e-mail niet zelf naar de gebruikers, maar biedt de e-mail aan de e-mailvoorziening van de organisatie aan. E-mail wordt verstuurd door, en opgeslagen op, de e-mailvoorziening van de organisatie.

Dit is schematisch weergegeven in figuur 3:

NB: De e-mailvoorziening van de organisatie kan ‘on premise’, in ‘de cloud’ of een SaaS-dienst zijn.

De consequenties voor de genoemde aspecten zijn:

• Informatiebeveiliging: De kans op ‘phishing’ is vergelijkbaar met de ‘SPF variant’.
  De kans op misbruik van de e-mail van de SaaS-applicaties is lager: de organisatie heeft zelf controle over de eigen e-mailvoorziening.
• Inzicht en overzicht: De organisatie heeft zicht op, en controle over, het e-mailverkeer van de SaaS-applicaties omdat dit via de eigen e-mailserver verloopt.
• Informatiebeheer: De e-mails worden opgeslagen op de e-mailserver van de eigen organisatie. E-mails van SaaS-applicaties ‘lopen mee’ in het bewaar en archiefbeleid van de organisatie.
  Bij het beëindigen van het gebruik van de SaaS-applicatie hoeven geen aanvullende maatregelen getroffen worden om e-mail ‘veilig te stellen’.
• Inrichting en beheer: Deze variant vereist inrichting van een mailbox voor iedere SaaS-applicatie en beveiligde ‘connectoren’ tussen SaaS-applicaties en de e-mailserver van de organisatie.
  De SaaS-applicatie moet deze variant ondersteunen.

Conclusie

Het gebruik van e-mailvoorzieningen door SaaS-applicaties kan aanzienlijke consequenties hebben op onder meer de informatiebeveiliging en het informatiebeheer van een organisatie.

Aanbevolen wordt dat organisaties een afweging van de risico’s opstelt en de eisen en wensen, bijvoorbeeld voor maatregelen om de risico’s te beheersen, bepaalt. De organisatie kan vervolgens een keuze maken voor een van de varianten. De eisen en wensen kunnen worden vastgelegd in ‘aansluitvoorwaarden’ voor SaaS-applicaties. Deze aansluitvoorwaarden zijn onderdeel van het programma van eisen bij de verwerving – aanbesteding voor SaaS-applicaties.

Wordt vervolgd.

[1] Het NCSC beveelt aan om SPF met aanvullende maatregelen te beveiligen.