Leestijd 5 min

Stijn Van den Enden

Of we nu onze telefoons ontgrendelen met gezichtsherkenning, stemcommando's roepen naar onze slimme apparaten vanaf de andere kant van de kamer of een lijst krijgen voorgeschoteld met films die we misschien leuk vinden... machine learning heeft in veel gevallen ons leven ten goede veranderd. Maar zoals met veel geweldige technologieën, heeft het ook een schaduwzijde. Een belangrijke is de massale, vaak ongereguleerde, verzameling en verwerking van persoonlijke gegevens. Soms lijkt het wel alsof er voor elk positief verhaal een negatief verhaal is over onze privacy die in gevaar is . Het is duidelijk dat we gedwongen zijn om privacy de aandacht te geven die het verdient. Vandaag wil ik het hebben over hoe we toepassingen voor machine learning kunnen gebruiken zonder dat we ons zorgen hoeven te maken over privacy en ons zorgen hoeven te maken dat privégegevens openbaar worden . Machine learning met randapparaten Door de intelligentie op randapparaten op locatie te plaatsen, kunnen we ervoor zorgen dat bepaalde informatie de sensor die deze vastlegt niet verlaat. Een randapparaat is een stuk hardware dat wordt gebruikt om gegevens dicht bij de bron te verwerken. In plaats van video's of geluid naar een gecentraliseerde processor te sturen, worden ze op de machine zelf verwerkt. Met andere woorden, je vermijdt dat al deze gegevens worden doorgestuurd naar een externe applicatie of een cloud-gebaseerde service. Edge-apparaten worden vaak gebruikt om latentie te verminderen. In plaats van te wachten tot de gegevens over een netwerk reizen, krijg je een onmiddellijk resultaat. Een andere reden om een edge device te gebruiken is om de kosten van bandbreedte te verlagen. Apparaten die gebruik maken van een mobiel netwerk werken mogelijk niet goed in landelijke gebieden. Zelfrijdende auto's maken bijvoorbeeld optimaal gebruik van beide redenen. Elke video-opname naar een centrale server sturen zou te tijdrovend zijn en de totale latentie zou de snelle reacties die we van een autonoom voertuig verwachten in de weg staan. Hoewel dit belangrijke aspecten zijn om te overwegen, ligt de focus van deze blogpost op privacy. Met de General Data Protection Regulation (GDPR) die in 2018 door het Europees Parlement van kracht werd, zijn mensen zich meer bewust geworden van hoe hun persoonlijke informatie wordt gebruikt . Bedrijven moeten toestemming vragen om deze informatie op te slaan en te verwerken. Sterker nog, overtredingen van deze verordening, bijvoorbeeld door geen adequate beveiligingsmaatregelen te nemen om persoonlijke gegevens te beschermen, kunnen leiden tot hoge boetes. Dit is waar edge devices in uitblinken. Ze kunnen een afbeelding of geluidsfragment onmiddellijk verwerken zonder dat er externe opslag of verwerking nodig is. Omdat ze de ruwe gegevens niet opslaan, wordt deze informatie vluchtig. Een randapparaat kan bijvoorbeeld camerabeelden gebruiken om het aantal mensen in een kamer te tellen. Als het camerabeeld op het apparaat zelf wordt verwerkt en alleen de grootte van de menigte wordt doorgestuurd, blijft ieders privacy gewaarborgd. Prototyping met Edge TPU Coral, een submerk van Google, is een platform dat software en hardware tools biedt om machine learning te gebruiken. Een van de hardwarecomponenten die ze aanbieden is het Coral Dev Board . Het is aangekondigd als " Google's antwoord op de Raspberry Pi ". Het Coral Dev Board draait een Linux-distributie gebaseerd op Debian en heeft alles aan boord om prototypes van machine learning-producten te maken. Centraal op het bord staat een Tensor Processing Unit (TPU) die is gemaakt om Tensorflow (Lite) bewerkingen uit te voeren op een energiezuinige manier. Je kunt meer lezen over Tensorflow en hoe het helpt om snel machinaal leren mogelijk te maken in een van onze eerdere blogposts . Als je goed naar een proces van machinaal leren kijkt, kun je twee fasen onderscheiden. De eerste fase is het trainen van een model op basis van voorbeelden, zodat het bepaalde patronen kan leren. De tweede fase is het toepassen van de mogelijkheden van het model op nieuwe gegevens. Bij het dev board hierboven is het de bedoeling dat je je model traint op cloudinfrastructuur. Dat is logisch, want voor deze stap is meestal veel rekenkracht nodig. Zodra alle elementen van je model zijn geleerd, kunnen ze naar het apparaat worden gedownload met behulp van een speciale compiler. Het resultaat is een kleine machine die een krachtig algoritme voor kunstmatige intelligentie kan uitvoeren terwijl hij niet is aangesloten op de cloud . Gegevens lokaal houden met Federated Learning Het bovenstaande proces doet je misschien afvragen welke gegevens worden gebruikt om het model voor machinaal leren te trainen. Er zijn veel openbaar beschikbare datasets die je kunt gebruiken voor deze stap. Over het algemeen worden deze datasets opgeslagen op een centrale server. Om dit te vermijden, kun je een techniek gebruiken die Federated Learning heet. In plaats van de centrale server het volledige model te laten trainen, doen verschillende nodes of edge devices dit individueel. Elk knooppunt stuurt updates over de parameters die ze hebben geleerd, ofwel naar een centrale server (Single Party) of naar elkaar in een peer-to-peer opstelling (Multi Party). Al deze wijzigingen worden vervolgens gecombineerd tot één globaal model. Het grootste voordeel van deze opzet is dat de opgenomen (gevoelige) gegevens nooit de lokale node verlaten . Dit is bijvoorbeeld gebruikt in Apple's QuickType toetsenbord voor het voorspellen van emoji's , op basis van het gebruik van een groot aantal gebruikers. Eerder dit jaar bracht Google TensorFlow Federated uit om applicaties te maken die leren van gedecentraliseerde data. Takeaway Bij ACA hechten we veel waarde aan privacy, net als onze klanten. Het privé houden van uw persoonlijke gegevens en gevoelige informatie is (y)onze prioriteit. Met technieken zoals federated learning kunnen we u helpen uw AI-potentieel te ontketenen zonder dat dit ten koste gaat van de gegevensbeveiliging. Benieuwd hoe dat precies in jouw organisatie zou werken? Stuur ons een e-mail via ons contactformulier en we nemen snel contact met je op.

Leestijd 9 min

Davy Steegen

In deze blogpost wil ik je een overzicht geven van de OAuth 2 specificatie. Toen ik me hierin begon te verdiepen, verdwaalde ik al snel in alle verschillende aspecten. Om ervoor te zorgen dat jij niet hetzelfde hoeft te doen, zal ik OAuth 2 uitleggen alsof je niet eens een technische achtergrond hebt. Omdat er veel te behandelen valt, laten we er meteen in springen! De kernconcepten van beveiliging Als het gaat om het beveiligen van een applicatie, zijn er 2 kernconcepten die je in gedachten moet houden: authenticatie en autorisatie . Authenticatie Met authenticatie probeer je de vraag "Wie is iemand?" of "Wie is deze gebruiker?" te beantwoorden. Je moet het bekijken vanuit het perspectief van je applicatie of je server. Ze hebben in principe vreemdelingengevaar. Ze weten niet wie je bent en er is geen manier voor hen om dat te weten tenzij je je identiteit aan hen bewijst. Authenticatie is dus het proces om aan de applicatie te bewijzen dat je bent wie je beweert te zijn . In een voorbeeld uit de echte wereld is dit het verstrekken van je ID of paspoort aan de politie wanneer ze je aan de kant zetten om jezelf te identificeren. Authenticatie is geen onderdeel van de standaard OAuth 2 specificatie. Er is echter een uitbreiding op de specificatie genaamd Open ID Connect die dit onderwerp behandelt. Autorisatie Autorisatie is de keerzijde van authenticatie. Zodra een gebruiker heeft bewezen wie hij is, moet de applicatie uitzoeken wat een gebruiker mag doen . Dat is in wezen wat het autorisatieproces doet. Een eenvoudige manier om hierover na te denken is het volgende voorbeeld. Als je een leraar bent op een school, heb je toegang tot informatie over de leerlingen in je klas. Als je echter de directeur van de school bent, heb je waarschijnlijk toegang tot de gegevens van alle leerlingen van de school. Je hebt een grotere toegang vanwege je functie. OAuth 2 Rollen Om OAuth 2 volledig te begrijpen, moet je je bewust zijn van de volgende 4 actoren die de specificatie vormen: Eigenaar van de bron Bronnen server Machtigingsserver Client / Toepassing Zoals eerder leggen we het uit met een heel eenvoudig voorbeeld om te zien hoe het echt werkt. Laten we zeggen dat je een jas hebt. Omdat je de eigenaar bent van die jas, ben je de eigenaar van de bron en de jas is de bron die je wilt beschermen. Je wilt het jasje opbergen in een kluisje om het veilig te bewaren. Het kastje zal fungeren als de Resource Server . Je bent geen eigenaar van de Resource Server, maar hij bewaart je spullen voor je. Omdat je wilt voorkomen dat het jasje door iemand anders wordt gestolen, moet je een slot op het kastje zetten. Dat slot is de autorisatieserver . Deze regelt de beveiligingsaspecten en zorgt ervoor dat alleen jij toegang hebt tot de jas of mogelijk iemand anders die jij toestemming geeft. Als je wilt dat je vriend je jasje uit het kastje haalt, dan kan die vriend gezien worden als de Client of Applicatie actor in de OAuth flow. De Client handelt altijd namens de gebruiker. Tokens Het volgende concept waar je veel over zult horen is tokens. Er zijn verschillende soorten tokens, maar ze zijn allemaal heel eenvoudig te begrijpen. De 2 soorten tokens die je het meest tegenkomt zijn access tokens en refresh tokens . Als het gaat om toegangsmunten, heb je misschien wel eens gehoord van JWT-tokens, tokens aan toonder of opake tokens. Dat zijn eigenlijk alleen maar implementatiedetails die ik in dit artikel niet ga behandelen. In essentie is een toegangstoken iets dat je aan de resource server geeft om toegang te krijgen tot de items die hij voor je bewaart. Je kunt toegangsmunten bijvoorbeeld zien als papieren kaartjes die je op de kermis koopt. Als je in een attractie wilt stappen, laat je je ticket zien aan de persoon in het hokje en die laat je instappen. Je maakt een ritje en na afloop verloopt je ticket. Belangrijk om te weten is dat wie het token heeft, eigenaar is van het token . Wees er dus heel voorzichtig mee. Als iemand anders je token in handen krijgt, kan hij of zij namens jou toegang krijgen tot je items! Refresh tokens lijken erg op access tokens. In wezen gebruik je ze om meer toegangsmunten te krijgen. Toegangsmunten hebben meestal een korte levensduur, maar verversingsmunten hebben vaak een langere vervaldatum. Om terug te komen op ons kermisvoorbeeld, een verversingstoken zou de creditcard van je ouders kunnen zijn die kan worden gebruikt om meer kermiskaartjes te kopen die je kunt uitgeven aan attracties. Scopes Het volgende concept dat we behandelen zijn scopes. Een scope is in feite een beschrijving van dingen die een persoon kan doen in een applicatie. Je kunt het zien als een functie in het echte leven (bijvoorbeeld een directeur of leraar op een middelbare school). Bepaalde scopes geven je meer rechten dan andere. Ik weet dat ik zei dat ik niet in technische details zou treden, maar als je bekend bent met Spring Security, dan kun je scopes vergelijken met wat Spring Security rollen noemt. Een scope komt één op één overeen met het concept van een rol. De OAuth specificatie specificeert niet hoe een scope eruit moet zien, maar vaak zijn het punt-gescheiden Strings zoals blog.write . Google daarentegen gebruikt URL's als scope. Als voorbeeld: om alleen-lezen toegang tot iemands agenda toe te staan, geven ze de scope https://www.googleapis.com/auth/calendar.readonly. Toelage types Types van toekenningen zijn typisch waar dingen verwarrend beginnen te worden voor mensen. Laten we beginnen met het tonen van de meest gebruikte grant types: Clientgegevens Machtigingscode Apparaatcode Vernieuwen Wachtwoord impliciet Client Credentials is een type toekenning dat vaak wordt gebruikt als 2 back-end diensten op een veilige manier met elkaar moeten communiceren. De volgende is het grant type Authorization Code , wat waarschijnlijk het moeilijkste grant type is om volledig te begrijpen. Je gebruikt dit type grant wanneer je gebruikers wilt laten inloggen via een browsergebaseerd aanmeldformulier. Als je ooit de knop 'Log in met Facebook ' of 'Log in met Google' op een website hebt gebruikt, dan heb je zonder het te weten al een autorisatiecodestroom ervaren! De volgende is het toestemmingscodetype , dat vrij nieuw is in de OAuth 2-scene. Het wordt meestal gebruikt op apparaten met beperkte invoermogelijkheden, zoals een TV. Als je bijvoorbeeld wilt inloggen op Netflix, in plaats van je gebruikersnaam en wachtwoord op te geven, verschijnt er een link met een code die je moet invullen met de mobiele app. Het Refresh grant type gaat meestal hand in hand met de Authorization Code flow. Omdat toegangstokens een korte levensduur hebben, wil je niet dat je gebruikers telkens moeten inloggen als het toegangstoken verloopt. Dus is er deze refresh flow die refresh tokens gebruikt om nieuwe access tokens te verkrijgen wanneer ze bijna verlopen zijn. De laatste 2 toekenningsvormen zijn Wachtwoord en Impliciet . Deze toekenningsvormen zijn minder veilige opties die niet worden aanbevolen bij het bouwen van nieuwe applicaties. We zullen ze kort behandelen in de volgende sectie, waarin de bovenstaande toekenningsvormen in meer detail worden uitgelegd. Autorisatie stromen Een autorisatiestroom bevat een of meer stappen die moeten worden uitgevoerd om een gebruiker te autoriseren door het systeem. Er zijn 4 autorisatiestromen die we zullen bespreken: Client Credentials stroom Wachtwoord stroom Autorisatie Code stroom Impliciete stroom Client Credentials stroom De Client Credentials stroom is de eenvoudigste stroom om te implementeren. Het werkt ongeveer hetzelfde als hoe een traditionele gebruikersnaam/wachtwoord login werkt. Gebruik deze flow alleen als je de client/applicatie kunt vertrouwen, omdat de client credentials worden opgeslagen binnen de applicatie. Gebruik dit niet voor single page apps (SPA's) of mobiele apps, omdat kwaadwillende gebruikers de app kunnen deconstrueren om de credentials te bemachtigen en deze te gebruiken om toegang te krijgen tot beveiligde bronnen. In de meeste use cases wordt deze flow gebruikt om veilig te communiceren tussen 2 back-end systemen. Hoe werkt de Client Credentials stroom? Elke applicatie heeft een client ID en secret die geregistreerd zijn op de autorisatieserver. De applicatie presenteert deze aan de autorisatieserver om een toegangstoken te krijgen en gebruikt het om de beveiligde bron van de resource server te krijgen. Als op een bepaald moment het toegangstoken verloopt, herhaalt hetzelfde proces zich om een nieuw token te krijgen. Wachtwoord stroom De Password flow lijkt erg op de Client Credentials flow, maar is erg onveilig omdat er een 3e actor bij betrokken is, namelijk een daadwerkelijke eindgebruiker. In plaats van een veilige client die we vertrouwen die een ID en geheim aan de autorisatie provider presenteert, hebben we nu een gebruiker die met een client 'praat'. In een Password flow geeft de gebruiker zijn persoonlijke gegevens aan de client. De client gebruikt deze gegevens om toegangstokens te krijgen van de autorisatieserver. Dit is de reden waarom een Password flow niet veilig is, omdat we er absoluut zeker van moeten zijn dat we kunnen vertrouwen dat de client de credentials niet misbruikt voor kwaadaardige redenen. Uitzonderingen waarbij deze flow nog steeds gebruikt zou kunnen worden zijn commandoregelapplicaties of bedrijfswebsites waarbij de eindgebruiker de client-apps moet vertrouwen die hij dagelijks gebruikt. Maar afgezien hiervan wordt het niet aanbevolen om deze flow te implementeren. Autorisatie Code Stroom Dit is de stroom die je zeker wilt begrijpen, omdat het de stroom is die het meest wordt gebruikt bij het beveiligen van applicaties met OAuth 2. Deze stroom is iets gecompliceerder dan de eerder besproken stromen. Het is belangrijk om te begrijpen dat deze flow vertrouwelijk, veilig en browsergebaseerd is . De flow werkt door veel HTTP redirects te maken, daarom is een browser een belangrijke speler in deze flow. Er is ook een back-channel verzoek (zo genoemd omdat de gebruiker niet betrokken is bij dit deel van de stroom) waarbij de client of applicatie rechtstreeks met de autorisatieserver praat. In deze flow moet de gebruiker meestal de scopes of rechten goedkeuren die aan de applicatie worden toegekend. Een voorbeeld hiervan is een applicatie van derden die vraagt of je toegang mag krijgen tot je Facebook-profielfoto nadat je bent ingelogd met de knop 'Aanmelden met Facebook'. Laten we de Autorisatiecode-flow toepassen op ons voorbeeld 'jas in de kast' om een beter begrip te krijgen. Onze jas ligt in de kast en we willen hem uitlenen aan een vriend. Onze vriend gaat naar het (hightech) kluisje. Het kastje belt ons, want wij zijn de Resource Owner. Deze oproep is een van die redirects waar we het eerder over hadden. Op dit punt maken we een beveiligde verbinding met het kastje, dat fungeert als een autorisatieserver. We kunnen nu veilig onze referenties geven om toestemming te geven om het slot te ontgrendelen. De autorisatieserver verstrekt vervolgens een tijdelijke code, de OAuth-code, aan onze vriend. De vriend gebruikt vervolgens die OAuth-code om een toegangscode te verkrijgen om het kastje te openen en mijn jas te pakken. Impliciete stroom De impliciete flow is in principe hetzelfde als de autorisatiecode flow, maar dan zonder de tijdelijke OAuth code. Dus na het inloggen stuurt de autorisatieserver direct een toegangstoken terug zonder dat er een back-channelverzoek nodig is. Dit is minder veilig, omdat het token onderschept kan worden via een man-in-the-middle aanval. Conclusie OAuth 2 kan er in eerste instantie ontmoedigend uitzien vanwege alle verschillende actoren die erbij betrokken zijn. Hopelijk begrijp je nu beter hoe ze met elkaar samenwerken. Met deze kennis in je achterhoofd is het veel gemakkelijker om de technische details te begrijpen als je je er eenmaal in begint te verdiepen.

Leestijd 4 min

Jean-Pierre Bernaerts

In onze laatste blogpost over GDPR hebben we gekeken naar de stand van zaken van GDPR 8 maanden nadat deze van kracht werd. Vandaag bekijken we wat de functie van een Data Protection Officer precies inhoudt. Wat kan een Data Protection Officer (DPO) nog meer doen behalve kijken naar implementatiemethoden voor een Europese verordening, of vragen beantwoorden van zijn klanten over hetzelfde onderwerp? Een dag uit het leven van een DPO, hoe ziet dat eruit? Effectbeoordeling gegevensbescherming Een typische dag begint om 8:30 in de kantoren van een klant waar vergaderingen (de een na de ander) de hele ochtend in beslag nemen. Voorbereiding voor deze vergaderingen is essentieel. Er zitten professionals voor je: CFO's, juristen, CIO's, CEO's, ICT-ontwikkelings- ICT-infrastructuurbeheerders, GDPR-coördinatoren, ... Deze mensen kennen hun vak, dus je kunt maar beter goed voorbereid komen! Een recent voorbeeld van zo'n ochtend is met een klant waar we een data protection impact assessment (DPIA) moeten afronden. Een DPIA is een manier om vooraf de privacyrisico's van gegevensverwerking te beoordelen. De methodologie die we gebruiken is de CNIL-toepassingsaanpak. Die dag bespreken we de gevolgen van de 'DPO-validatiestap' die ik de dag ervoor heb voorbereid. De deelnemers aan de vergadering zijn de COO, de HR-directeur en ikzelf en hoewel de DPIA geen 'hoog of zeer hoog risico' opleverde voor de beoordeelde verwerkingsactiviteit, kwamen we erachter dat we bepaalde acties of mitigaties moesten definiëren voor enkele kleinere risico's die verband hielden met enkele fouten die we in het proces hadden gevonden. Als functionaris voor gegevensbescherming had ik de vereiste acties gedefinieerd om elk van de gedocumenteerde risico's die we hebben gevonden te beperken en deze moeten nu worden besproken, goedgekeurd en toegevoegd aan de actielijst met deadlines en verantwoordelijkheden. Compromissen sluiten is de sleutel... Het is goed om op te merken dat een DPO alleen een adviserende functie heeft en niet het mandaat om beslissingen te nemen. Maar als, in dit geval, de COO of HR-directeur het niet eens is met een of meer van mijn voorgestelde to-dos en we het niet eens kunnen worden over een alternatief met hetzelfde resultaat, moet het bedrijf de reden(en) waarom ze het advies van de DPO niet hebben opgevolgd, documenteren en motiveren. Gelukkig hadden we een goede vergadering met een zeer goede discussie over een van de verzachtende maatregelen met een interessant compromis als resultaat. Daarom is de discussie zo belangrijk: een externe functionaris voor gegevensbescherming moet begrijpen dat de kennis van de bedrijfsprocessen, de bedrijfsrisico's, de bedrijfswaarde en de commerciële propositie veel beter bekend zijn bij het bedrijf dan bij henzelf en het is verplicht om naar de klant te luisteren. Maar, en dit is een heel belangrijke maar, het betekent niet dat we de regels kunnen ombuigen! In dit geval kwamen we met een geldig compromis, maar in andere gevallen (met een andere klant) niet, wat betekende dat mijn advies niet werd geaccepteerd en de vereiste gedocumenteerde motivatie werd geschreven. Omdat de vergadering eerder afgelopen was dan ik had verwacht, had ik nog wat tijd over. De marketingmanager maakte van deze gelegenheid gebruik om de mogelijke impact van de GDPR te bespreken op de volgende marketingcampagne die nog in ontwikkeling was. De campagne zelf was erg leuk en creatief, maar aangezien interactiviteit met de (potentiële) klant er een belangrijk onderdeel van was, had de GDPR inderdaad een bepaalde impact. Dit gesprek duurde wat langer dan "even snel een vraag stellen" 😊 ... en context ook! Die dag ging ik 's middags naar kantoor. Als ik op kantoor ben, bereid ik vooral vergaderingen met klanten voor, bekijk ik gegevensbeschermingsovereenkomsten, bereid ik beleid, presentaties en trainingen voor (bijv. Privacy by design voor IT-ontwikkeling) en DSAR-concepten (Data Subject Access Request). Daarnaast beantwoord ik vragen van onze klanten: "Mij is gevraagd om... Kan ik dit doen?" "Ik wil graag deze functionaliteit toevoegen aan onze website. Heeft de GDPR hier invloed op?" "We willen graag een MDM-tool implementeren. Mag dat?" "Een ex-werknemer heeft een DSAR gestuurd en wil graag deze specifieke informatie ontvangen. Moeten we die aan hen geven?" Dit zijn natuurlijk maar een paar voorbeelden. In werkelijkheid zijn er veel meer vragen van allerlei aard, allemaal van verschillende bedrijven met verschillende processen, verschillende culturen en beleidsregels. Dezelfde vraag kan verschillende antwoorden hebben, afhankelijk van de situatie of het bedrijf. De wetgeving kennen (en dit betekent meer dan alleen de GDPR) is een basisvereiste, maar helaas is dat niet genoeg. De interpretatie voor specifieke situaties en weten hoe deze uit te leggen binnen verschillende soorten bedrijven op zo'n manier dat mensen het accepteren, is een van de meer uitdagende aspecten. Niet iedereen is immers dol op de GDPR... 💔 Functionaris voor gegevensbescherming: een afwisselende en uitdagende baan Een Data Protection Officer is een zeer interessante, uitdagende baan als je geïnteresseerd bent in bedrijfsprocessen, gegevensbeveiliging, levenslang leren, levendige discussies en het delen van juridische standpunten of interpretaties. Hoewel veel van de baan draait om de GDPR, is het veel gevarieerder dan dat. Ik hoop dat ik je wat inzicht heb kunnen geven in wat een DPO van dag tot dag doet!