Is jouw cloudplatform veilig én flexibel?

Introductie

Veiligheid is van cruciaal belang bij het uitrollen van een cloudplatform. De noodzaak is overduidelijk, zoek ter inspiratie eens op datalek of hack en je krijgt voorbeelden te over van hoe het mis kan gaan. Organisaties onderkennen het belang en stellen daardoor hoge eisen aan de veiligheid van platform, applicaties en gebruikte data. Het is ook belangrijk om oog te houden voor de flexibiliteit van je platform.

Tussen veiligheid en flexibiliteit zit een zeker spanningsveld. Denk bij ‘veilig’ eens aan een fort en bij ‘flexibel’ aan een elastiek. Het fort biedt een stevige verdediging en bescherming. Het elastiek is flexibel en wil zich juist uitrekken en aanpassen aan veelzijdige behoeften. Het spanningsveld ontstaat, doordat je moet afwegen hoeveel nadruk je legt op het versterken van de veiligheidsmaatregelen ten opzichte van het behouden van de flexibiliteit van het platform.

In deze blog leggen we uit hoe je het spanningsveld kunt overwinnen. Je platform kan heel goed veilig én flexibel zijn, zolang je beide aspecten in ogenschouw houdt. Te weinig aandacht voor flexibiliteit kan leiden tot een omgeving die veilig is, maar waarmee moeizaam te werken is, met alle gevolgen van dien. We bespreken een aantal indicatoren die hierop kunnen duiden en tonen daarna praktijkvoorbeelden van implementaties die flexibel zijn, zonder concessies te doen op het gebied van veiligheid.

Misschien heb je al een ‘veilig’ platform dat in de loop der tijd zijn flexibiliteit heeft verloren, of sta je momenteel voor de uitdaging om nieuwe veiligheidseisen te implementeren. We delen waardevolle inzichten om je hiermee te helpen, zodat je jouw platform kunt beveiligen en tegelijkertijd flexibel kunt houden.

Flexibiliteit in combinatie met veiligheid

Vaak is de urgentie om diverse veiligheidsvereisten te implementeren hoog. Bij een bestaande omgeving kan er sprake zijn van strakke planningen om te voldoen aan (nieuwe) standaarden. Bij een nieuw platform stellen organisaties vaak vooraf al eisen om überhaupt (gevoelige) data te mogen gebruiken. De vereisten worden veelal bepaald op basis van de meest gevoelige data die aanwezig is op het platform. Als je als organisatie data gaat verwerken, dan is een deel van je data waarschijnlijk gevoelig, zoals gegevens van klanten en medewerkers, of financiële data over het bedrijf. Je hebt dan te maken met allerlei veiligheidseisen, bijvoorbeeld over netwerkverkeer, toegang tot productiedata, of zichtbaarheid van zeer gevoelige gegevens (bijvoorbeeld van creditcards).

Het uiteindelijke doel is het behalen van het stempel ‘veilig’. Je kunt het zien als een tweekleurig stoplicht. Je bent onveilig (rood) of veilig (groen). Als je stoplicht op rood staat is er maar één doel: zo snel mogelijk (weer) veilig worden. Dat doel is valide, want uiteraard is het geen optie om een onveilige operatie te hebben. Echter de tendens kan ontstaan dat dit ten koste gaat van flexibiliteit. Het is beter om uit te gaan van een driekleurig stoplicht: onveilig (rood); veilig, maar inflexibel (oranje); veilig en flexibel (groen). Je wilt zeker niet op rood staan, echter een langere periode oranje is ook niet wenselijk.

Wel veilig, niet flexibel?

Organisaties hebben veel handvatten om het veiligheidsniveau te kennen van hun platform en applicaties. Hiervan op de hoogte zijn is ook vaak verplicht in het kader van compliance. Er is veelal een securityafdeling die zich met dit soort zaken bezighoudt, zij kunnen op basis van functionele standaarden uitspraken doen over het veiligheidsniveau van een platform. Bijvoorbeeld door te toetsen op basis van een set algemene veiligheidsmaatregelen. Er kunnen op basis hiervan audits worden gedaan om het veiligheidsniveau exact te bepalen.

Het wordt lastiger om signalen te detecteren die kunnen duiden op inflexibiliteit. Dit heeft voornamelijk te maken met gebruikerservaring. Er zijn wel KPI’s die als indicator kunnen worden gebruikt, bijvoorbeeld productiviteit of de doorlooptijd van incidenten, maar indien deze ondermaats scoren kunnen er ook andere dingen aan de hand zijn. Een aantal kenmerken die kunnen duiden op een inflexibel platform zijn:

• Herhaaldelijke klachten rondom autorisaties, bijvoorbeeld om bepaalde data (tijdelijk) te kunnen zien. Gebruikers kunnen aangeven dat ze het gevoel hebben dat ze te weinig rechten hebben om effectief hun werk te kunnen doen, of ze moeten lang op deze rechten wachten bij een aanvraag.
• Een groep beheerders klaagt over een grote stroom aan ad-hoc verzoeken. Het gaat om werkzaamheden die blijkbaar alleen door die groep kan worden gedaan. Dit heeft negatieve impact op de eigen geplande werkzaamheden.
• Klachten over een gebrek aan connectiviteit, om dit te regelen zijn tickets nodig, de doorlooptijd is lang.
• Er zijn incidenten met een lange oplostijd, die uiteindelijk blijken te gaan om verlopen credentials. Teams zijn hier veel tijd aan kwijt en het leidt tot downtime.

Of bovenstaande punten inderdaad het gevolg zijn van een inflexibel platform is natuurlijk de vraag. Gooi zeker niet op basis van één of twee klachten je hele beleid om. Kijk wel kritisch of er bij klachten en opmerkingen sprake lijkt te zijn van een patroon. Belangrijke risico’s die je loopt zijn: verlaagde productiviteit waardoor je minder businesswaarde kunt leveren, verlaagde moraal onder gebruikers, wat op lange termijn kan leiden tot meer verzuim of zelfs verlies van personeel, verhoogde overhead en dus meer kosten.

Samengevat

Vergeet bij het implementeren van een veilig cloudplatform niet om oog te houden voor flexibiliteit. Bedenk je dat je meer flexibel kunt worden zonder in te leveren op veiligheid. Heb oog voor signalen die kunnen duiden op inflexibiliteit en maak dit bespreekbaar. Betrek medewerkers en teamleden hier ook bij. Vanuit OneDNA hebben we veel ervaring met het bouwen en onderhouden van verschillende (data)platforms. Ons eigen product OneBase is ook gebouwd met het ook op veiligheid en flexibiliteit. We gaan graag met je in gesprek om te kijken waar verbeteringen mogelijk zijn voor jouw situatie. In de volgende sectie bespreken vanuit de techniek enkele voorbeelden van een flexibele implementatie van veiligheidsmaatregelen.

Technische implementatie

Het klinkt misschien abstract wat we nou bedoelen met ‘inflexibel’. Daarom geven we onderstaand drie concrete voorbeelden. Deze hebben betrekking op dataplatforms in Azure, omdat daar de specialiteit ligt van OneDNA. De algemene inhoud van dit blog kan echter breder worden getrokken en geldt voor alle cloudplatforms. In de voorbeelden maken we gebruik van de Azure Portal omdat die het meest inzichtelijk is, in een productiesituatie zouden we aanraden om zoveel mogelijk te automatiseren via pipelines en om gebruik te maken van Infrastructure As Code. Voor meer informatie daarover zie de blog van collega Sander op ’t Hof.

Veilige netwerktoegang tot je resources

Om veilige netwerktoegang te krijgen tot je resources bevelen wij private endpoints aan. Wij zien dat veel organisaties bij het onderwerp connectiviteit de botte bijl ter hand nemen en “alles dichtzetten”. Voor alle benodigde verbindingen is (firewall) whitelisting nodig. Veilig, maar gebruikers moeten dan zelf steeds verzoeken indienen. Denk aan connectiviteit tussen Azure-componenten of toegang voor eindgebruikers. Het is ook inflexibel als gebruikers speciale werkplekken nodig hebben om bij resources te komen. Het kan leiden tot frustratie, lange doorlooptijd en verlaagde productiviteit.

Private endpoints kunnen op een eenvoudige manier privaat verkeer tussen verschillende Azure-componenten mogelijk maken. Dit bespaart allerlei configuraties die je anders handmatig zou moeten doen (en waar gebruikers op moeten wachten). Voorbeelden zijn firewall whitelisting, managen van IP-ranges, en configuratie van VPN en DNS. Private endpoints integreren met diverse Azure-componenten, zoals SQL server, synapse, Azure databricks, data factory, storage accounts, VMs, etc. Al deze componenten kunnen via private endpoints privaat met elkaar communiceren binnen hetzelfde virtual network. Indien virtual network peering wordt ingezet dan werkt dit ook tussen virtual networks.

Hoe zet je het op?

Laten we als voorbeeld op deze manier toegang verkrijgen tot een SQL database, in een eigen Azure subscription:

• We maken de volgende resources aan, overal zijn default settings gebruikt, tenzij anders aangegeven
  • SQL server met SQL database – hier willen we naartoe verbinden. Public network access is uitgeschakeld.
  • Virtual network met default subnet – benodigd om connectiviteit te realiseren met private endpoints. In dit voorbeeld hebben we geen eigen lokaal netwerk, dus vinken we bij het aanmaken van het virtual network “enable Azure bastion” aan.
  • Private endpoint – via de Azure portal doorloop je een aantal menu’s. In het resource menu geef je aan voor welke resource in Azure deze managed identity is. In dit geval kies je bij type voor “Microsoft.Sql/servers”, vervolgens kun je via de resource dropdown de eerder aangemaakte SQL server kiezen. In het virtual network menu kies je het eerder aangemaakte virtual network en subnet.
  • Na aanmaak kun je de private endpoint zien als je kijkt bij de SQL server:

De aangemaakte SQL database is na aanmaak alleen bereikbaar via privaat verkeer. Stel dat we de database willen benaderen met SQL Server Management Studio, dan kan dat daarom niet via je lokale computer. Als je dit lokaal aan het testen bent, dan zou je een virtual machine in het virtual network kunnen uitrollen. Als je instelt dat deze ook alleen bereikbaar is via privaat verkeer, dan kun je erbij via Azure Bastion. Op die VM kun je SQL Server Management Studio installeren en vervolgens inloggen op de server. Vanuit het oogpunt van een organisatie is dit alleen niet ideaal: je wilt geen onnodige resources en inloglocaties hebben (zoals een VM). Gelukkig kun je de noodzaak van deze extra VM voorkomen door het lokale bedrijfsnetwerk (via privaat verkeer) te verbinden met je cloudnetwerk. Hier zijn meerdere opties voor, Microsoft zelf adviseert ExpressRoute.

Met behulp van deze implementatie heb je een werkbare oplossing. Je hebt weinig administratieve overhead aan het inregelen van je connectiviteit. Je medewerkers die toegang nodig hebben tot resources kunnen hiervoor machines gebruiken uit het lokale bedrijfsnetwerk, dit kunnen heel goed dezelfde machines zijn die ze al dagelijks gebruiken.

Veilige toegang tussen Azure resources

Om veilige toegang tussen resources op te zetten gebruik je managed Identities. Wij zien bij veel organisaties dat er nog wordt gebruikgemaakt van usernames-password combinaties. Een applicatie kan bijvoorbeeld inloggen via SQL-authenticatie, waarbij het wachtwoord uit Azure key vault wordt gehaald. Dat zorgt voor overhead, want je moet al die wachtwoorden bijhouden en tijdig vernieuwen. Dat laatste kan misgaan en dan is je applicatie down. Het is ook minder veilig omdat de wachtwoorden misbruikt kunnen worden.

Managed identities maken het mogelijk voor applicaties om met elkaar te verbinden, zonder dat daar wachtwoorden voor worden gebruikt. De identity krijgt bij aanmaak een unieke identeit in het Azure AD en kan van daaruit direct worden geassocieerd met diverse Azure services. Je kunt hiervoor kiezen tussen een system-assigned managed identity die direct is verbonden met de resource waarmee je wilt verbinden, of voor een user-assigned managed identity die losstaand en herbruikbaar is.

Hoe zet je het op?

Stel dat we met Azure data factory iets willen wegschrijven naar een tabel in onze SQL-database met een system-assigned managed identity:

Zodra de system-assigned managed identity is geactiveerd dan is deze gelijk zichtbaar in het Azure AD. Deze kan met het standaard create user commando worden toegevoegd aan de SQL-database en bijvoorbeeld de db_datawriter rol krijgen.

Vanaf je data factory kun je de SQL-database nu als sink (target) kiezen en schrijven naar de database. Er zijn geen wachtwoorden nodig.

Recent is het ook mogelijk om via Azure Devops te authenticeren via managed identities, dat betekent dat er minder of zelfs geen wachtwoorden meer benodigd zijn bij het draaien van pipelines.

Afhandelen van incidenten

Organisaties gaan verschillend om met het oplossen van incidenten. In sommige gevallen werken teams vergevorderd DevOps en zijn ontwikkelteams direct verantwoordelijk voor de eigen producten. In andere gevallen is er bijvoorbeeld een beheerafdeling die zich hiermee bezighoudt, veelal is dan alsnog hulp van ontwikkelteams nodig: alleen zij hebben de diepgaande kennis die nodig is om sommige productspecifieke incidenten op te lossen. Wat we veel zien is dat toegang tot productiedata niet standaard is, maar soms toch benodigd is. In die gevallen adviseren wij Azure Priviliged Identity Management (PIM).

Als alleen een beperkte groep beheerders toegang heeft tot productie, dan kan dit als bottleneck werken. Beheerders kunnen meestal niet zelf alle incidenten oplossen en hebben de hulp van ontwikkelaars nodig. Als ontwikkelaars dan zelf geen manier hebben om bij productiedata te komen, dan wordt beheer een soort doorgeefluik. Dit zorgt voor frustratie en een langere doorlooptijd. Indien ontwikkelaars wel mogelijkheden hebben om bij productie te komen, dan is de implementatie hiervan belangrijk. Een voorbeeld van inflexibiliteit is het opwerpen van veel horden om bij de data te komen en/of via een arbeidsintensieve procedure rechten uit te delen. De achterliggende bedoeling van een hoge drempel is in beginsel wel goed, want je wilt niet dat mensen zomaar bij productie kunnen, echter in een geval van een overduidelijk incident kan het hinderlijk werken. Een voorbeeld van een arbeidsintensieve procedure zou zijn het moeten indienen van tickets met een lange doorlooptijd voor goedkeuring. Wat ook kan is dat het uitdelen van rechten naar aanleiding van een ticket veel tijd en moeite kost, bijvoorbeeld omdat er te veel wordt geleund op procedures en te weinig op techniek.

Hoe zet je het op?

Azure PIM is een Azure dienst die kan worden ingezet om tijdelijke toegang (zoals tot productiedata) te verschaffen. Dit kan op basis van Azure resources, Azure AD-rollen en met AD-groepen die je bijvoorbeeld kunt gebruiken bij een SQL-database. Er is een ingebouwd goedkeuringssysteem. Om de component te kunnen gebruiken is een Azure AD Premium P2 licentie benodigd. Je kunt PIM openen via de Azure Portal en vandaar kun je ook AD-groepen of azure resources opnemen in PIM:

Als we bijvoorbeeld toegang willen tot specifieke Azure resources, kunnen we deze via het hierboven omkaderde menu selecteren. Vervolgens kunnen we kiezen welke rollen hierbij horen en welke personen dit mogen aanvragen. Een gebruiker kan dan tijdelijk leesrechten aanvragen op bepaalde Azure-resources:

Dit verzoek kan optioneel nog worden goedgekeurd door een ander persoon, of direct worden verwerkt. Vervolgens wordt de rol actief:

Conclusie

Bij het implementeren van een veilig cloudplatform is het cruciaal om rekening te houden met flexibiliteit. Het vinden van een goed evenwicht tussen veiligheid en flexibiliteit is essentieel om zowel productiviteit als de gebruikerservaring te optimaliseren. Het is belangrijk om aandacht te besteden aan mogelijke inflexibiliteit en hier serieus naar te kijken. Ons doel is om een platform te bieden dat zowel veilig als flexibel is, zonder de focus op veiligheid uit het oog te verliezen. Door middel van onze expertise kunnen wij organisaties helpen het optimale evenwicht te vinden tussen veiligheid en flexibiliteit in hun cloudplatforms.