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

Dorien Jorissen

Er zijn nog maar een paar dagen te gaan tot de GDPR van kracht wordt en een alarmerend aantal mensen is in paniek en vraagt zich af hoe ze hun marketing en sales kunnen redden. Maar waarom denkt iedereen er zo over, terwijl de GDPR hen juist redt? GDPR zal je marketing- en verkoopdromen niet verpletteren Het belangrijkste wat we bij ACA IT-Solutions hebben gedaan met betrekking tot de GPDR was het vinden van die broodnodige duidelijkheid. We hebben het geluk gehad om samen te werken met een geweldige externe GDPR-consultant (als je dit leest Jean-Pierre, bedankt voor alle hulp!), die het ons allemaal heel duidelijk heeft gemaakt en waardoor ik me het volgende realiseerde: GDPR zal niet je hele marketing en sales dromen verpletteren als je bedrijf klantgericht is en zich richt op het leveren van waarde. Ik zeg niet dat het niet moeilijk voor ons was. Compliant zijn betekende veel werk en zal ook in de toekomst veel werk betekenen. Maar we moesten veranderingen doorvoeren, die eigenlijk heel logisch waren. Dit is waarom ik denk dat GDPR eigenlijk een superheld is voor marketing en sales. Waarom de GDPR goed is voor marketing sales De nieuwe regels richten zich op een paar belangrijke aspecten die marketing en sales naar een hoger niveau zullen tillen. 1. Klantgerichtheid Customer Centricity en GDPR gaan hand in hand. GDPR is er niet om alle marketinginitiatieven te saboteren of om ons leven een beetje moeilijker te maken. Het zorgt ervoor dat we ons concentreren op waarden zoals transparantie, gegevenskwaliteit en respect voor de mensen met wie we contact opnemen. De contacten in onze databases zullen echt geïnteresseerd zijn in wat een onderneming te zeggen heeft. De CTR van je volgende e-mailing zal waarschijnlijk door het dak gaan! Misschien moet je in de beginfase de pijn verwerken van het verlies van een groot deel van je database, maar na een tijdje zul je meer dan tevreden zijn met de resultaten. En de kans om de superheld te zijn van echt nuttige en interessante content. 😉 2. Privacy GDPR-compliant bedrijven zijn in staat om mensen een gevoel van vertrouwen te garanderen als het gaat om hun privacy. Het is voor hen een enorm pluspunt als je niet alleen bezig bent met hun privacy, maar ook kunt overbrengen hoe je daar precies mee omgaat en welke maatregelen je neemt. Denk aan alle verhitte privacyschandalen van de afgelopen maanden, zoals het Facebook-dataschandaal . Het is het perfecte voorbeeld om aan te tonen dat privacy niemand onberoerd laat. Er is een nieuw tijdperk aangebroken als het gaat om het openbaar maken van persoonlijke gegevens! 3. Vertrouwen opbouwen en behouden De eerlijkheid en transparantie die vereist is in GDPR-conforme communicatie stelt marketeers in staat om opnieuw een vertrouwensrelatie op te bouwen en te onderhouden met prospects en klanten. Bedrijven zullen de wensen van individuen moeten respecteren en moeten nadenken over wanneer, waarom en hoe mensen gecontacteerd kunnen worden. In plaats van dat consumenten achterdochtig staan tegenover marketing- en verkoopinspanningen, kunnen we nu garanderen en mensen daadwerkelijk onze ware bedoelingen laten zien. 4. Kwaliteit van gegevens De dialoogmarketing die voortvloeit uit deze nieuwe wetgeving geeft individuen meer dan ooit een stem en maakt het makkelijker voor hen om contact op te nemen met een bedrijf. De GDPR verhoogt ook de kwaliteit van je gegevens. Bedrijven zullen niet alleen kijken of gegevens correct zijn, maar ook naar de manier waarop ze deze verzamelen en verwerken. Dit is onmiskenbaar een groot voordeel voor de kwaliteit van het CRM dat je hebt opgebouwd. Kwalitatieve en GDPR-conforme gegevens brengen je immers naar een hoger niveau als het gaat om het gebruik en onderhoud van gegevens binnen de verschillende afdelingen van het bedrijf. Kortom, het zorgt ervoor dat we 'verantwoord ondernemen' in een heel ander licht gaan zien. 5. Beveiliging De nieuwe wetgeving en haar vereisten voor gegevensbeveiliging hebben gezorgd voor een wereldwijd bewustzijn over het belang van investeringen in beveiliging en privacy. Bedrijven over de hele wereld zijn: IT-governances aan het integreren, onderzoeken de beveiliging van hun gegevens, denken na over Privacy by Design , datalekken voorkomen, maken risicobeoordelingen van gegevens, ... In plaats van de overtreder te zijn, hebben organisaties nu de kans om de beschermer van persoonlijke gegevens en privacy te zijn. Een belangrijke stap die er al lang had moeten zijn. De GDPR heeft het potentieel om ons in alle opzichten beter te maken Naar mijn eerlijke mening is de enige echte conclusie die ik kan trekken dat de GDPR bedrijven niet alleen heeft laten nadenken over hun verantwoordelijkheid op het gebied van gegevensprivacy en -beveiliging, maar er ook toe heeft geleid dat bedrijven echt actie ondernemen. GDPR is simpelweg een evolutie die elke organisatie sterker, slimmer en zelfbewuster kan maken. ACA's betrokkenheid bij de GDPR Ik zei al dat we bij ACA eerst duidelijkheid zochten over de GDPR. Nadat we de wetgeving hadden begrepen, moesten we ons er volledig aan committeren. Natuurlijk zijn marketing en sales niet de enige domeinen binnen ACA die zich committeren aan de nieuwe wetgeving en onze kijk op privacy en veiligheid. Daarom hebben we een interne GDPR-missieverklaring opgesteld, die we hoog in het vaandel dragen bij alle activiteiten van ons bedrijf. "Trouw aan zijn kernwaarden streeft ACA Group er voortdurend naar om een eerlijke en discrete leider te zijn in de bescherming van de privacy van gegevens, door alle persoonlijke gegevens in ons ecosysteem op een ethische, respectvolle en pragmatische manier te behandelen." - Ronny Ruyters , CEO bij ACA Group Geïnteresseerd in ons GDPR-beleid? Neem een kijkje op onze vernieuwde juridische pagina en aarzel niet om contact met me op te nemen als je opmerkingen of vragen hebt of gewoon wilt chatten.

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!

Leestijd 6 min

Kamen Zhekov

Het starten van een nieuw webproject kan een ontmoedigende taak zijn met veel verschillende onderdelen om rekening mee te houden en te configureren. Voor ontwikkelaars kan het zeker handig zijn om toegang te hebben tot een startpunt voor het bouwen van webapps, met alle benodigde bestanden en configuraties al ingesteld. Het bespaart niet alleen veel tijd en moeite in vergelijking met wanneer je alles vanaf nul moet opbouwen, het verhoogt ook de productiviteit en maakt klanten blij omdat ze veel sneller tastbare resultaten kunnen zien. Bij ACA Group doen we veel van dergelijke implementaties en de volgende vereisten zijn gemeenschappelijk voor de meeste webapplicatieprojecten: Een geweldige gebruikerservaring: een snelle, responsieve en vlotte frontend die flexibel genoeg is om elk soort gebruikersinteractie te implementeren Betrouwbare en performante verwerking: een solide database en backend oplossing die gemakkelijk uitbreidbaar, testbaar, onderhoudbaar en begrijpbaar is voor elke ingenieur Gebruikersauthenticatie en -beveiliging: een robuuste en volwassen authenticatieserver die ook SSO en gebruikersfederatie heeft en integreert met veel verschillende providers Eenvoudige en veilige implementatie: toch eenvoudig te ontwikkelen zonder al te veel overhead Ons antwoord op deze terugkerende eisen is een flexibele softwarebasis die out of the box werkt. Met een paar regels in de terminal kun je een nieuw project opstarten dat alle bovenstaande functionaliteiten in een basistoestand heeft, wachtend om uitgebreid en uitgebouwd te worden. De figuur hieronder illustreert de basis van de architectuur die we vaak gebruiken voor kleine en middelgrote webapplicaties, en de verschillende services die een rol spelen. Natuurlijk zijn er nog andere componenten in het spel, maar die worden vaker per geval geïmplementeerd. Backend Laten we beginnen met het brein van de webapplicatie - de backend. Voor ons Python-team is het niet meer dan logisch om deze taal te gebruiken om de ruggengraat van de applicatie te bouwen. FastAPI biedt veel flexibiliteit in termen van hoe je bedrijfslogica en ontwerppatronen implementeert. Het is ook een van de best presterende backend-oplossingen die je kunt kiezen in Python; het heeft geweldige documentatie en wordt ondersteund door een solide community. Een populaire keuze voor projecten met data-analyse, machine learning of AI, een Python backend maakt het gemakkelijker om geavanceerde technologieën dichter bij de gebruiker te brengen. Frontend Voor het ontwerpen van de gebruikerservaring - of de frontend - geven we de voorkeur aan Angular , een volwassen en goed onderzocht JavaScript-framework dat overal in de industrie wordt gebruikt. Het is ontworpen om eenvoudig interactieve webapplicaties van één pagina te maken die in elke moderne webbrowser kunnen draaien. Angular heeft ook een gevestigde reputatie op het gebied van goede prestaties en schaalbaarheid, waardoor het risico op schaalbaarheidsproblemen bij grotere projecten afneemt. Een ander voordeel is dat Angular gestructureerd is en veel lijkt op backend code, waardoor het makkelijker te begrijpen is voor niet-frontend ontwikkelaars. Database en opslag Voor gegevensopslag is PostgreSQL een veelgebruikt en betrouwbaar databasemanagementsysteem (DBMS) dat zeer geschikt is voor verschillende toepassingen, waaronder webontwikkeling. Het staat bekend om zijn prestaties, vooral als het gaat om het verwerken van grote hoeveelheden gegevens. Het kan complexe query's efficiënt verwerken en heeft de reputatie goed te kunnen schalen naarmate de grootte van de database toeneemt. Het is ook rijk aan functies en heeft verschillende opties voor indexering en query optimalisatie. Beveiliging en verificatie Onze beveiligde authenticatieserver is gebouwd op Keycloak , een volwassen IAM-oplossing die organisaties helpt hun applicaties en diensten te beveiligen. Het is niet alleen open-source, maar ook gesponsord door 's werelds leider op het gebied van open source voor bedrijven, RedHat. Het biedt een enkel toegangspunt voor gebruikers om zichzelf te authenticeren en toegang te autoriseren tot verschillende bronnen; en het ondersteunt een breed scala aan authenticatiemechanismen, zoals gebruikersnaam en wachtwoord, twee-factor authenticatie en social login. Infrastructuur Het volgende stukje van de puzzel is NGinx , dat al het inkomende verkeer orkestreert en verdeelt over de services. Het is een krachtige en flexibele webserver en reverse proxy die vaak wordt gebruikt om inkomende klantverzoeken veilig en met hoge prestaties af te handelen. Het staat bekend om zijn vermogen om een groot aantal gelijktijdige verbindingen af te handelen met een laag gebruik van bronnen, en is vooral efficiënt bij het serveren van statische inhoud zoals afbeeldingen, CSS en JavaScript-bestanden. Nginx kan verzoeken van clients doorsturen naar een of meer services, waarbij het verkeer eenvoudig naar de juiste component van de webapplicatie wordt geleid en de belasting over meerdere servers of services wordt verdeeld, zelfs als ze dezelfde rol vervullen. Dit betekent ook dat alle verschillende services uitsluitend via NGinx communiceren met SSL/TLS protocollen, waardoor al het verkeer wordt versleuteld en gevoelige gegevens worden beveiligd. Implementatie Tot slot vergemakkelijkt Docker de implementatie en ontwikkeling. Door de verschillende onderdelen van de app te containeriseren, zoals de backend of de database, wordt het veel eenvoudiger om de app op verschillende hostingomgevingen te implementeren. Dit is vooral belangrijk als klanten verschillende eisen hebben op het gebied van hostingmachines, infrastructuur, enzovoort. Met Docker kunnen de services van de app op een gestandaardiseerde manier worden verpakt en vervolgens consistent worden ingezet in verschillende omgevingen. Docker heeft ook voordelen voor het beheren van de app in productie. Door componenten in containers te plaatsen, kun je eenvoudig op- of afschalen, updates en rollbacks uitrollen en de gezondheid van de app bewaken. Dit kan helpen om de betrouwbaarheid en onderhoudbaarheid van de app te verbeteren. Voor ontwikkelaars maakt Docker het ook makkelijker om de app in verschillende omgevingen te testen, samen te werken met teamleden en taken zoals het bouwen, testen en uitrollen van de app te automatiseren. Kickstart een nieuw project 👊 Het doel van deze architectuur is om een startpunt te bieden voor het bouwen van een webapplicatie met alle benodigde componenten al geconfigureerd. We hebben het verpakt in een sjabloon dat alles bevat wat je nodig hebt om te beginnen, zodat je niet vanaf nul een startarchitectuur hoeft te bouwen. In plaats daarvan kunt u de sjabloon gebruiken als basis en deze vervolgens aanpassen aan uw specifieke behoeften. Om deze template te gebruiken, hebben we gekozen voor een tool genaamd Cookiecutter. Het hoeft maar één keer geïnstalleerd te worden door de persoon die de initiële repository opzet om een nieuw project te maken op basis van een sjabloon van de bovenstaande architectuur. Als onderdeel van dit proces worden een paar waarden gevraagd om het sjabloon aan te passen, zoals de naam van het project, het e-mailadres van de beheerder, welke functies je wilt inschakelen, enzovoort. Zodra je Cookiecutter hebt gebruikt om de projectmap aan te maken, bevat deze alles wat je nodig hebt om de webapplicatie te bouwen en uit te voeren. Om met de app aan de slag te gaan, kun je een eenvoudig Docker-commando uitvoeren en de webapplicatie is in een mum van tijd klaar voor gebruik. Dit maakt live ontwikkeling op elk deel van de applicatie mogelijk met hot reload, en maakt de implementatie zo eenvoudig als een paar klikken. Conclusie Al met al kan een kant-en-klare webapplicatie-architectuur zoals beschreven in deze blog een waardevol hulpmiddel zijn om tijd en moeite te besparen op elk nieuw project. Door een solide basis te bieden voor het bouwen van een webapplicatie, kan het teams helpen om snel een MVP op te starten, zonder vanaf nul te hoeven beginnen. De combinatie van de bovenstaande technologieën bespaart niet alleen tijd en moeite, maar geeft je ook het vertrouwen dat je app goed is uitgerust voor een breed scala aan behoeften.

Leestijd 6 min

Peter Jans

AWS Config is een service waarmee u de configuraties van uw AWS-bronnen kunt beoordelen, controleren en evalueren. Dit kan worden gebruikt voor: beveiliging: valideer best practices voor beveiliging op uw AWS-account compliance: rapporteer over afwijkingen in de configuratie van AWS-resources op basis van best practices of architectuurprincipes en -richtlijnen efficiëntie: rapporteer over verloren of ongebruikte bronnen in uw AWS-account In deze blogpost wil ik gedetailleerd uiteenzetten hoe u uw cloudresources kunt bewaken met deze tool. Dit eerste deel bespreekt het instellen van een AWS Config-account, het inschakelen van meldingen wanneer resources niet voldoen en de implementatie. Waarom AWS Config gebruiken? AWS is het belangrijkste cloudplatform dat we bij ACA gebruiken. We beheren meerdere accounts in AWS om allerlei applicaties te hosten voor onszelf en voor onze klanten. In de loop der jaren hebben we steeds meer projecten opgezet in AWS. Dit heeft geleid tot het aanmaken van veel accounts, die op hun beurt veel cloudresources gebruiken. Dit betekent natuurlijk dat het bijhouden van al deze resources ook steeds uitdagender wordt. AWS Config heeft ons geholpen om met deze uitdaging om te gaan. We gebruiken het om alle resources in onze hele AWS-organisatie te inventariseren en te bewaken . Het stelt ons ook in staat om compliance-regels in te stellen voor onze resources die in elk account moeten worden nageleefd. Bijvoorbeeld: een Elastic IP mag niet ongebruikt blijven of een EC2-beveiligingsgroep mag niet al het inkomende verkeer zonder beperkingen toestaan. Op deze manier kunnen we een standaard creëren voor al onze AWS-accounts. Het inschakelen van AWS Config in je organisatie geeft ons een aantal voordelen. We hebben altijd een up-to-date inventaris van alle resources in onze accounts. We kunnen 24/7 de wijzigingsgeschiedenis van al onze resources bekijken. Het geeft ons de mogelijkheid om organisatieregels aan te maken en continu te controleren of onze resources voldoen aan de regels. Als dat niet het geval is, krijgen we direct een melding. AWS Config instellen voor één account In dit eerste deel van mijn AWS Config blog wil ik laten zien hoe je AWS Config instelt voor een enkel account. In een toekomstige blogpost zal ik meer uitleggen over hoe je dit voor een hele AWS organisatie kunt doen. De afbeelding hieronder toont een overzicht van de setup in een enkel account, met daarin de AWS Config recorder, de AWS Config-regels, en de S3 emmer. De AWS Config recorder is het belangrijkste onderdeel van de set-up. Je kunt de standaardrecorder inschakelen in de AWS-console. Standaard neemt deze alle resource types op. Meer informatie over alle beschikbare resourcetypes vind je op deze pagina . Wanneer je begint met opnemen, worden alle AWS-resources opgeslagen in de S3-bucket als configuratie-items. Het opnemen van deze configuratie-items is niet gratis. Op het moment van schrijven kost het $0,003 per opgenomen configuratie-item. Deze kosten worden gegenereerd wanneer het configuratie-item voor het eerst wordt opgenomen of wanneer er iets verandert aan het configuratie-item of een van zijn relaties . In de instellingen van de AWS Config recorder kun je ook aangeven hoe lang deze configuratie-items moeten worden opgeslagen in de S3 bucket. De AWS Config regels zijn het belangrijkste onderdeel van je setup. Deze regels kunnen worden gebruikt als compliancy controles om ervoor te zorgen dat de bronnen in je account zijn geconfigureerd zoals bedoeld. Het is mogelijk om aangepaste regels te maken of te kiezen uit een grote set van AWS beheerde regels . In onze setup bij ACA hebben we ervoor gekozen om alleen AWS managed rules te gebruiken, omdat deze aan al onze behoeften voldeden. In de afbeelding hieronder zie je een van de regels die we hebben ingezet. Net als het vastleggen van configuratie-items, kost het uitvoeren van regelevaluaties geld. Op het moment van schrijven is dit $0,001 voor de eerste 100.000 regelevaluaties per regio, $.0008 van 100.000 - 500.000 en daarna $.0005. Er zijn veel regels beschikbaar met verschillende voordelen voor je AWS account. Dit zijn enkele van de AWS beheerde regels die we hebben geconfigureerd: Regels die de beveiliging verbeteren AccessKeysRotated: controleert of de toegangssleutels van een IAM-gebruiker binnen een bepaald aantal dagen worden geroteerd. IamRootAccessKeyCheck: controleert of aan een root account toegangssleutels zijn toegewezen, wat niet wordt aanbevolen S3BucketServerSideEncryptionEnabled: controleert of standaard encryptie voor een S3 bucket is ingeschakeld Regels die ongebruikte bronnen detecteren (kostenreductie) Ec2VolumeInuseCheck: controleert of een EBS volume wordt gebruikt EipAttached: controleert of een Elastic IP wordt gebruikt Regels die optimalisatie van bronnen detecteren VpcVpn2TunnelsUp: controleert of een VPN-verbinding twee tunnels beschikbaar heeft Meldingen instellen wanneer resources niet voldoen AWS Config-regels controleren configuratie-items. Als een configuratie-item niet voldoet aan de eisen van de regel, wordt het gemarkeerd als 'niet-conform'. Wanneer dit gebeurt, wil je hiervan op de hoogte worden gebracht zodat je de juiste acties kunt ondernemen om het probleem op te lossen. In de afbeelding hieronder zie je hoe we de notificaties voor onze AWS Config-regels hebben geïmplementeerd. Om te beginnen met meldingen, moet CloudTrail zijn ingeschakeld en moet er een spoor zijn dat alle activiteit in het account logt. Nu kan CloudWatch de CloudTrail-gebeurtenissen oppikken. In onze setup hebben we 5 CloudWatch-eventregels gemaakt die meldingen versturen op basis van prioriteit. Dit maakt het voor ons mogelijk om te beslissen wat het prioriteitsniveau van de melding voor elke AWS Config-regel moet zijn. De afbeelding hieronder laat hier een voorbeeld van zien. In de sectie 'Targets' zie je het SNS topic dat de meldingen van de CloudWatch event rule ontvangt. Opsgenie heeft een apart abonnement voor elk van de SNS topics (P1, P2, P3, P4 P5). Op deze manier ontvangen we meldingen wanneer er wijzigingen in de compliance plaatsvinden en zien we ook de ernst ervan door naar het prioriteitsniveau van onze Opsgenie-melding te kijken. Uw AWS-configuratie implementeren Bij ACA proberen we onze AWS-infrastructuur altijd te beheren met Terraform. Dit is niet anders voor AWS Config. Dit is onze implementatieworkflow: We beheren alles wat met AWS Config te maken heeft in Terraform. Hier is een voorbeeld van een van de AWS Config regels in Terraform, waarbij de waarde van het rule_identifier attribuut kan worden gevonden in de documentatie van de AWS Config beheerde regels: resource "aws_config_config_rule" "mfa_enabled_for_iam_console_access" { name = "MfaEnabledForIamConsoleAccess" description = "Controleert of AWS Multi-Factor Authentication (MFA) is ingeschakeld voor alle AWS Identity and Access Management (IAM) gebruikers die een consolewachtwoord gebruiken. De regel voldoet als MFA is ingeschakeld." rule_identifier = "MFA_ENABLED_FOR_IAM_CONSOLE_ACCESS" maximum_execution_frequency = "One_Hour" excluded_accounts = "${var.aws_config_organization_rules_excluded_accounts}" } De Terraform code wordt versiebeheer met Git. Als de code moet worden ingezet, doet Jenkins een checkout van de Git repository en zet het uit op AWS met Terraform. Takeaway Met AWS Config krijgen we meer inzicht in onze AWS-cloudbronnen. AWS Config verbetert onze beveiliging , voorkomt dat we resources in gebruik houden die niet worden gebruikt en zorgt ervoor dat onze resources optimaal worden geconfigureerd. Naast deze voordelen biedt het ons ook een inventaris van al onze resources en hun configuratiegeschiedenis, die we op elk moment kunnen inzien. Tot zover deze blogpost over AWS Config. In een toekomstig deel wil ik uitleggen hoe je het instelt voor een AWS-organisatie. Als je dit onderwerp interessant vond en je hebt een vraag of je wilt meer weten over onze AWS Config setup, neem dan contact met ons op via cloud@aca-it.be {% module_block module "widget_1f2727bf-c08a-40a0-9306-0cb030d1f763" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"I want to automatically secure my cloud"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":217528923385,"href":"https://25145356.hs-sites-eu1.com/en/services/cloud","href_with_scheme":null,"type":"CONTENT"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}