Leestijd 7 min

Jan Eerdekens

In deze technische blogpost wil ik het hebben over hoe je eenvoudige en flexibele ETL-gebaseerde anonimisering kunt opzetten. Waarom? Wel, ik had onlangs de gelegenheid om een klein proof of concept uit te voeren voor een klant. De klant wilde weten welke opties beschikbaar waren om interne gegevens te nemen, alle persoonlijk identificeerbare informatie (PII) te verwijderen of anonimiseren en deze op een eenvoudige manier en vorm beschikbaar te maken voor externe partijen. Na het verzamelen van verdere vereisten werd de context voor dit proof of concept als volgt gedefinieerd: Welke oplossing dan ook, het moet in staat zijn om gegevens te extraheren uit een on premise Oracle database . Het eindresultaat moet een set CSV-bestanden zijn in een Amazon S3-bucket . Tussen het ophalen van de Oracle-gegevens en het dumpen ervan in CSV-vorm op S3, moet er iets zijn dat PII-gegevens verwijdert/anonimiseert. Indien mogelijk moet de gekozen oplossing cloud native zijn. In deze 3-delige blogreeks leg ik uit hoe je eenvoudige en flexibele ETL-gebaseerde anonimisering opzet: Het onderzoek naar producten die gebruikt zouden kunnen worden om het probleem op te lossen. Controleer ook hoe geschikt ze zijn voor wat de proof of concept moet bereiken. Hoe het gekozen product gebruikt kan worden om een ETL pipeline te maken die aan de eisen voldoet. Daarnaast, hoe je een lokale Oracle database opzet in Docker die gebruikt kan worden als databron voor het data ingestion deel van het proof of concept (gewoon omdat dit zo'n PITA was om te doen). En of dit op een cloud native manier kan worden gedaan. Onderzoek Het onderzoeksdeel van het proof of concept bestaat uit 2 delen: Hoe haal je data uit een Oracle database, anonimiseer je het op de een of andere manier en sla je het op als een stel CSV bestanden in een S3 bucket aka het ETL gedeelte. Uitzoeken wat de beste manier is om de anonimisering uit te voeren. De gegevens extraheren, transformeren en opslaan Het probleem van de klant klonk meteen al opmerkelijk als iets dat je zou kunnen oplossen met een ETL-product: Extract Transform Load . Het onderzoeksgedeelte voor dit deel van het proof of concept zou zich dus concentreren op dit type product. Ik kreeg ook wat input van iemand in mijn team om eens te kijken naar singer.io , omdat dat iets was dat ze in het verleden met succes hadden gebruikt voor dit soort problemen. Als je naar de homepage van Singer kijkt, vallen een aantal dingen meteen op: Singer maakt gegevensextractie en -consolidatie mogelijk voor alle tools van je organisatie. De open-source standaard voor het schrijven van scripts die gegevens verplaatsen. Unix-geïnspireerd: Singer taps en targets zijn eenvoudige applicaties samengesteld met pipes. JSON-gebaseerd: Singer-toepassingen communiceren met JSON, waardoor ze eenvoudig te gebruiken en te implementeren zijn in elke programmeertaal. Singer is dus gewoon een specificatie, zij het geen officiële. Het is een eenvoudig, op JSON gebaseerd dataformaat en je kunt iets in dit formaat produceren (een tap in Singer terminologie) of het formaat consumeren (een target ). Je kunt deze taps en targets aan elkaar koppelen om gegevens van de ene locatie te halen en op een andere locatie op te slaan. Singer wordt standaard geleverd met een heleboel taps (meer dan 100) en targets (10). Deze taps en targets zijn geschreven in Python. Omdat het centrale punt van het systeem slechts een gegevensformaat is, is het vrij eenvoudig om er zelf een te schrijven of een bestaand formaat aan te passen. Bij het controleren van de taps zou de standaard Oracle-tap het Extract-gedeelte van ons proof of concept moeten dekken. Hetzelfde lijkt echter niet het geval te zijn voor het Load gedeelte als we kijken naar de standaard targets. Er is een CSV target , maar deze slaat de resultaten lokaal op, niet in een S3 bucket. Er is een optie om gewoon dit doel te gebruiken en de S3 upload zelf te doen nadat de ETL pijplijn is voltooid. Een andere optie zou zijn om het bestaande CSV target aan te passen en de bestandsopslag te veranderen naar S3. Even Googelen levert een door de gemeenschap gemaakt S3 CSV Singer doel op. Volgens de documentatie zou dit target precies moeten doen wat we willen. Oeps, Singer transformeert niet Met de Extract en Load delen gedekt, blijft alleen het Transform deel van de ETL pijplijn over om uit te zoeken... en dit is waar het een beetje vreemd wordt. Ook al is Singer geclassificeerd als een ETL tool, het lijkt geen ondersteuning te hebben voor het transformatie gedeelte? Toen ik hier verder naar keek, kwam ik deze onheilspellend getitelde post tegen: Why our ETL tool does not do transformations . Als ik dit lees, lijkt het erop dat ze hun JSON specificatie/gegevensformaat beschouwen als het transformatiegedeelte. Dus ze ondersteunen transformatie naar ruwe gegevens en het opslaan ervan, maar ondersteunen geen andere soorten transformaties. Dat deel mag je zelf doen nadat het ergens is opgeslagen door een Singer-doel. Het blijkt dus dat Singer meer lijkt op het EL deel van een ELT product dan op een "old school" ETL product . Op dit punt zou Singer in ieder geval voldoende moeten zijn om de gegevens uit een Oracle database te halen en in CSV-formaat in een S3 bucket te zetten. En omdat Singer vrij eenvoudig, open en uitbreidbaar is, laat ik het hier voorlopig bij. Laten we verder kijken naar de anonimiseringsopties die in deze Singer-context zouden kunnen passen. Gegevens anonimiseren Net als bij het ETL-gedeelte, kreeg ik ook voor dit gedeelte wat input die me wees op Microsoft Presidio . Op de homepage kunnen we het volgende lezen: Het biedt snelle identificatie- en anonimiseringsmodules voor privé-entiteiten in tekst en afbeeldingen , zoals creditcardnummers, namen en meer. Het faciliteert zowel volledig geautomatiseerde als semi-geautomatiseerde PII de-identificatiestromen op meerdere platforms. Aanpasbaarheid in PII-identificatie en -anonimisering. Er staan dus veel veelbelovende dingen in die me zouden kunnen helpen bij het oplossen van mijn anonimiseringsbehoeften. Bij nader onderzoek lijkt het erop dat ik dit product evalueer tijdens een grote transformatie (snap je? 😉 ) van V1 naar V2. V1 bevatte wat ETL-achtige dingen zoals het ophalen van gegevens uit bronnen (hoewel Oracle-ondersteuning in de roadmap nooit lijkt te zijn gerealiseerd ) en het opslaan van geanonimiseerde resultaten in een aantal vormen/locaties. V2 heeft deze aanpak echter volledig losgelaten en concentreert zich puur op het detecteren en vervangen van PII-gegevens. In de kern is Presidio V2 een op Python gebaseerd systeem dat bovenop een AI-model is gebouwd. Dit stelt het in staat om automatisch PII-gegevens te ontdekken in tekst en afbeeldingen en deze te vervangen volgens de regels die je definieert. Ik heb wat tests gedaan met behulp van hun online testtool en het werkt min of meer, maar voor onze specifieke context moet het zeker worden aangepast. Als we kijken naar de meegeleverde testgegevens, lijkt het erop dat het vooral eenvoudige en korte gegevens zijn, maar geen grote tekstblokken of afbeeldingen. Dit roept de vraag op: zelfs als we Presidio kunnen configureren om te doen wat we willen, slaan we misschien kleine spijkers met een grote hamer? Is Presidio te veel? Laten we hier nog eens over nadenken. Als we gemakkelijk kunnen weten en definiëren welke eenvoudige kolommen in welke tabellen moeten worden geanonimiseerd en wanneer gewoon nulling of hashing van de kolomwaarden voldoende is, dan hebben we het autodetectie deel van Presidio niet nodig. We hebben ook geen Presidio-ondersteuning nodig voor volledige tekst of afbeeldingen en we hebben ook geen fancy substitutie-ondersteuning nodig. Presidio zou een krachtige bibliotheek kunnen zijn om een automatische anonimiseringsstap te maken voor onze Singer-gebaseerde pijplijn. Het helpt ook dat Presidio gebaseerd is op Python. Maar mijn gevoel zegt dat ik misschien eerst moet proberen om een iets eenvoudigere oplossing te vinden. Ik begon te zoeken naar iets dat een eenvoudige PII-vervanging kan doen en dat werkt in een Singer tap/target context. Ik vond deze Github repository: pipelinewise-transform-field . In de documentatie staat "Transformatiecomponent tussen Singer taps en targets". Klinkt verdacht veel als het " T " deel dat Singer als een ETL miste! Verderop in de configuratiesectie lezen we zelfs: "Je moet definiëren welke kolommen door welke methode moeten worden getransformeerd en in welke conditie de transformatie moet worden toegepast." en de mogelijke transformatietypes zijn: SET-NULL : transformeert elke invoer naar NULL HASH : transformeert stringinvoer naar hash HASH-SKIP-FIRST-n : Transformeert stringinvoer naar hash waarbij de eerste n tekens worden overgeslagen, bijv. HASH-SKIP-FIRST-2 MASK-DATE : Vervangt de maand- en dagdelen van datumkolommen door 1 jan. MASK-NUMBER : Zet elke numerieke waarde om in nul. MASK-HIDDEN : verandert een willekeurige tekenreeks in 'verborgen'. Dit lijkt volledig te voldoen aan onze eenvoudige anonimiseringseisen! We kunnen zelfs zien hoe we het moeten gebruiken in de context van Singer: some-singer-tap | transform-field --config [config.json] | some-singer-target Standaard Conclusie We hebben nu alle stukjes van de puzzel voor het opzetten van eenvoudige en flexibele ETL-gebaseerde anonimisering. In de volgende blogpost laten we zien hoe ze in elkaar passen en of ze de resultaten opleveren die de klant zoekt.

Leestijd 3 min

Simon Vercruysse

We zijn als ACA Group officieel ISO 27001 compliant! Onze Information Security Manager Simon Vercruysse legt uit wat die certificatie precies inhoudt en wat de voordelen zijn voor jouw (toekomstige) project.

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 15 min

Jan Eerdekens

In de eerste reeks van deze serie over op ETL gebaseerd anonimisatie is het onderzoeksgedeelte van het probleem dat ik probeerde op te lossen, behandeld in een proof of concept. Ik besloot Sin g er te gebruiken als softwareoplossing om een ETL-pijplijn te ontwikkelen. In het tweede gedeelte komen de configuratie van Singer aan bod, de geselecteerde taps en targets en de verbinding daartussen. Als een kleine nevenzoektocht zal ik ook behandelen hoe je een Oracle database lokaal kunt draaien als de database waarmee de Singer Oracle Tap verbinding kan maken en de problemen die ik daarmee had. Singer instellen Het eerste wat we moeten doen om te beginnen met het maken van de ETL pijplijn is Singer installeren. Singer is eigenlijk gewoon een verzameling taps en targets. Dit is niets meer dan eenvoudige Python code die datastromen produceert in het Singer JSON spec formaat die in elkaar gepiped kunnen worden. De enige installatievereiste is dus een werkende Python 3 installatie op je systeem. Voer het onderstaande commando uit om te zien of Python 3 al correct is geïnstalleerd: python --versie Python Als dit werkt en een 3.x versie oplevert, dan ben je al klaar. Als dit niet werkt of een 2.x versie oplevert, dan moet je eerst Python 3 installeren. Instructies over hoe dit te doen voor jouw besturingssysteem kun je gemakkelijk vinden door te Googlen. Oracle instellen We gebruiken een Oracle database die we draaien als een Docker container. Ik heb heel wat tests moeten doorstaan om dit voor elkaar te krijgen, waarover je aan het einde van deze post kunt lezen. Voorlopig gaan we ervan uit dat er een Oracle database draait op localhost:1521 met een SID genaamd OraDoc . In deze database is er een schema genaamd ETL en een gebruiker genaamd etl . In dit schema hebben we een heel eenvoudige testtabel genaamd TEST met de structuur die je hieronder ziet en een paar rijen met daadwerkelijke testgegevens: VOORNAAM , ACHTERNAAM , PERSOON_ID , TELEFOON Python De "Tap" instellen Met een werkende Python 3 installatie kunnen we nu verder met de eerste stap van onze ETL pijplijn: de invoer van Oracle database gegevens door de Singer Oracle Tap . Hoewel de taps en targets gewoon Python code zijn, gebruikt de Oracle Tap de cx_Oracle bibliotheek als database driver. Deze bibliotheek heeft een native Oracle database client nodig, genaamd Oracle Instant Client , om verbinding te kunnen maken met de database. Volg deze installatie-instructies om de client te installeren. Als deze client geïnstalleerd is, kunnen we verder gaan met het opzetten van de eigenlijke Oracle Tap. Het installeren ervan houdt niets meer in dan het aanmaken van een Python Virtuele Omgeving , deze activeren en vervolgens de tap-afhankelijkheid installeren via pip . Voor de Oracle Tap kan dat met deze commando's: python3 -m venv ~/ . virtualenvs/tap-oracle source ~/ . virtualenvs/tap-oracle/bin/activate pip3 install tap-oracle Python Zodra de tap is geïnstalleerd en de virtuele omgeving is geactiveerd, is het commando tap-oracle beschikbaar: ( tap-oracle ) developer@laptop . virtualenvs % tap-oracle gebruik : tap-oracle [ -h ] -c CONFIG [ -s STATE ] [ -p PROPERTIES ] [ --catalog CATALOG ] [ -d ] tap-oracle : error : de volgende argumenten zijn vereist : -c/--config Python Uit het bericht dat we krijgen als we de tap gewoon proberen te draaien, kunnen we zien dat de tap wat configuratie nodig heeft voordat hij echt kan werken. Deze configuratie is niets meer dan een eenvoudig JSON-bestand dat de informatie bevat over de databaseverbinding en enkele andere parameters om te definiëren hoe de database zal worden gesynchroniseerd. Om het eenvoudig te houden, maken we dit bestand, config.json genaamd, aan in de bin directory van onze tap-oracle virtuele omgeving met de onderstaande inhoud: { " host" : "localhost" , " port" : 1521 , " user" : "etl" , " password" : "admin123" , " sid" : "OraDoc" , " filter_schemas" : "ETL" , " default_replication_method" : "FULL_TABLE" } Python De eerste 5 configuratieparameters zijn verplicht en spreken voor zich, behalve misschien de laatste twee: filter_schemas : een optionele parameter die een door komma's gescheiden lijst met schemanamen bevat waarmee je alleen de tabelgegevens van specifieke schema's kunt repliceren in plaats van alle schema's. default_replication_method : dit definieert hoe de geselecteerde schema's zullen worden gerepliceerd. Er zijn 3 mogelijke waarden: LOG_BASED , FULL_TABLE INCREMENTAL . Voor deze POC gebruiken we FULL_TABLE omdat we de dingen eenvoudig willen houden en alleen met een kleine testdatabase zullen werken. Voor de LOG_BASED modus moet je er ook voor zorgen dat je Oracle database dienovereenkomstig is geconfigureerd , wat buiten het bereik valt van deze POC en zijn Docker-gebaseerde Oracle database . Met deze configuratie zijn we klaar om de tap in discovery mode te draaien. In deze modus gebruikt de tap het configuratiebestand om verbinding te maken met de database en de geselecteerde schema's te bevragen over de beschikbare tabellen en hun structuur. We moeten deze gegevens, genaamd de catalogus, opslaan in een ander JSON-bestand. Om dit bestand, catalog.json , aan te maken, voer je het onderstaande commando uit vanuit de bin directory van de tap-oracle virtuele omgeving: ( tap-oracle ) developer@laptop bin % tap-oracle -c config . json -d catalog . json INFO start discovery INFO dsn : ( DESCRIPTION= ( ADDRESS= ( PROTOCOL=TCP ) ( HOST=localhost ) ( PORT=1521 ) ) ( CONNECT_DATA= ( SID=OraDoc ) ) INFO haalt rijtellingen op INFO haalt tabellen op : SELECT owner , table_name FROM all_tables WHERE owner != 'SYS' AND owner IN ( : 0 ) [ 'ETL' ] INFO ophalen views INFO ophalen kolom info INFO ophalen pk constraints Python Als je de tap uitvoert met de configuratie en de catalogus, zul je zien dat er niets wordt gesynchroniseerd: ( tap-oracle ) developer@laptop bin % tap-oracle -c config . json --catalog catalog . json INFO Geselecteerde streams : [ ] INFO Geen huidige_synchronisatie gevonden Python Om de tap daadwerkelijk iets te laten synchroniseren, bewerk je het catalogusbestand een beetje door de streams te selecteren die je wilt synchroniseren: { " streams" : [ "tap_stream_id" : "ETL-TEST" , " table_name" : "TEST" , " schema" : { "properties" : { "VOORNAAM" : { "type" : [ "null" , "string" ] } , "type" : "object" } , " stream" : "TEST" , " metadata" : [ { "breadcrumb" : [ ] , " metagegevens" : { "table-key-properties" : [ "PERSON_ID" ] , "schema-naam" : "ETL" , " database-naam" : "ORADOC" , "is-view" : false , "row-count" : 0 , "selected" : true } } } , { "breadcrumb" : [ "properties" , "FIRST_NAME" ] , "metadata" : { "sql-datatype" : "VARCHAR2" , " inclusie" : "available" , "selected-by-default" : true } }, { "breadcrumb" : [ "properties" , "LAST_NAME" ] , "metadata" : { "sql-datatype" : "VARCHAR2" , " inclusie" : "available" , "selected-by-default" : true } }, { "breadcrumb" : [ "properties" , "PERSON_ID" ] , "metadata" : { "sql-datatype" : "NUMBER" , " inclusion" : "automatic" , "selected-by-default" : true } }, { "breadcrumb" : [ "properties" , "PHONE" ] , "metadata" : { "sql-datatype" : "VARCHAR2" , " inclusion" : "available" , "selected-by-default" : true } } Python Als je nu hetzelfde commando opnieuw uitvoert, zie je de tap sync inhoud van de geselecteerde stream: ( tap-oracle ) developer@laptop bin % tap-oracle -c config . json --catalog catalog . json INFO Geselecteerde streams : [ 'ETL-TEST' ] INFO Geen huidige_synchronisatie gevonden INFO Beginnen met synchronisatie van stream ( ETL-TEST ) met synchronisatiemethode ( full ) INFO Stream ETL-TEST gebruikt full_table replicatie { "type" : "SCHEMA" , "stream" : " TEST" , "schema" : { "properties" : { "FIRST_NAME" : { "type" : [ "null" , "string" ] } , "LAST_NAME" : { "type" : [ "null" , "string" ] } , "PERSON_ID" : { "format" : "singer.decimal" , "type" : [ "string" ] } , "PHONE" : { "type" : [ "null" , "string" ] }} , "type" : "object" } , "key_properties" : [ "PERSON_ID" ] } INFO dsn : ( DESCRIPTION= ( ADDRESS= ( PROTOCOL=TCP ) ( HOST=localhost ) ( PORT=1521 ) ) ( CONNECT_DATA= ( SID=OraDoc ) ) { "type" : "STATE" , "value" : { "bladwijzers" : { "ETL-TEST" : { "last_replication_method" : "FULL_TABLE" , "version" : 1618344226757}} , "currently_syncing" : "ETL-TEST" }} { "type" : "ACTIVATE_VERSION" , "stream" : "TEST" , "versie" : 1618344226757} INFO select SELECT "FIRST_NAME" , "LAST_NAME" , "PERSON_ID" , "PHONE" , ORA_ROWSCN FROM ETL . TEST ORDER BY ORA_ROWSCN ASC { "type" : "RECORD" , "stream" : " TEST" , "record" : { "FIRST_NAME" : "John" , "LAST_NAME" : "Doe" , "PERSON_ID" : "1" , "PHONE" : "0499010203" } , "version" : 1618344226757, "time_extracted" : "2021-04-13T20:03:46.757794Z" } { "type" : "RECORD" , "stream" : "TEST" , "record" : { "FIRST_NAME" : "Jane" , "LAST_NAME" : "Doe" , "PERSON_ID" : "1" , "PHONE" : "0499040506" } , "version" : 1618344226757, "time_extracted" : "2021-04-13T20:03:46.757794Z" } , INFO METRIC : { "type" : "teller" , "metric" : "record_count" , "value" : 2 , "tags" : {}} { "type" : "ACTIVATE_VERSION" , "stream" : " TEST" , "version" : 1618344226757} { "type" : "STATE" , "value" : { "bladwijzers" : { "ETL-TEST" : { "last_replication_method" : "FULL_TABLE" , "version" : 1618344226757, "ORA_ROWSCN" : null}} , "currently_syncing" : null}} Python Dat was al een hoop werk, maar gelukkig is het moeilijkste deel achter de rug! Het "doel" instellen Nu we een tap hebben ingesteld om databasegegevens op te halen in het Singer spec-formaat, slaan we de transformatiestap voorlopig over en stellen we eerst een doel in waarnaar we het kunnen leiden. Op deze manier kunnen we snel de Extract en Load delen van de ETL pipeline controleren en al een leesbaar CSV resultaat zien in plaats van Singer spec JSON bestanden. We gebruiken de Pipelinewise S3 CSV Target . De opzet van dit doel lijkt erg op hoe de tap eerder was opgezet. Nogmaals, je moet er een virtuele omgeving voor maken, deze activeren en de target-afhankelijkheid installeren met pip: python3 -m venv ~/ . virtualenvs/target-s3-csv source ~/ . virtualenvs/target-s3-csv/bin/activate pip3 install pipelinewise-target-s3-csv Python Deze target heeft ook een klein configuratiebestand nodig in de vorm van een config.json bestand dat de naam van de emmer bevat waar we de CSV-bestanden naartoe willen sturen en de referenties die nodig zijn om toegang te krijgen tot de emmer: { " s3_bucket" : "anonymized-data-bucket" , " aws_access_key_id" : "your_own_aws_access_key_id_value" , "aws_secret_access_key" : "your_own_aws_secret_access_key_value" } Python Deze eenvoudige configuratie is alles wat we nodig hebben om het doel te laten werken. Het stelt ons in staat om het resultaat van de Oracle Tap naar dit doel te leiden en, afhankelijk van de geselecteerde streams, een of meer momenteel niet-geanonimiseerde CSV-bestanden in onze S3-bucket te krijgen. Als we het onderstaande commando uitvoeren vanuit de bin directory van de geactiveerde tap-oracle virtuele omgeving, zal er een volledige tabelsynchronisatie plaatsvinden: ( tap-oracle ) developer@laptop bin % tap-oracle --config config . json --catalog catalog . json | ~/ . virtualenvs/target-s3-csv/bin/target-s3-csv --config ~/ . virtualenvs/target-s3-csv/bin/config . json INFO Geselecteerde streams : [ 'ETL-TEST' ] INFO Geen huidige_synchronisatie gevonden INFO Begint synchronisatie van stream ( ETL-TEST ) met synchronisatiemethode ( full ) INFO Stream ETL-TEST gebruikt full_table replicatie INFO dsn : ( DESCRIPTION= ( ADDRESS= ( PROTOCOL=TCP ) ( HOST=localhost ) ( PORT=1521 ) ) ( CONNECT_DATA= ( SID=OraDoc ) ) time=2021-04-13 22 : 23 : 29 name=target_s3_csv level=INFO message=Attempting to create AWS session INFO select SELECT "FIRST_NAME" , "LAST_NAME" , "PERSON_ID" , "PHONE" , ORA_ROWSCN FROM ETL . TEST ORDER BY ORA_ROWSCN ASC INFO METRIC : { "type" : "teller" , "metric" : "record_count" , "value" : 2 , "tags" : {} time=2021-04-13 22 : 23 : 29 name=target_s3_csv level=INFO message=Uploading /var/folders/5k/86hrfqsd60b8pnh_81fqfy8h0000gn/TEST-20210413T222329 . csv to bucket anonymized-data-bucket at TEST-20210413T222329 . csv { "bookmarks" : { "ETL-TEST" : { "laatste_replicatie_methode" : "FULL_TABLE" , "version" : 1618345409645, "ORA_ROWSCN" : null}} , "currently_syncing" : null} Python U kunt het resultaat controleren in de S3-webinterface of met de AWS-opdrachtregelclient. Voer de onderstaande commando's uit om te zien of de emmer CSV-bestanden bevat en om ze op te halen: aws s3 ls s3 : //anonymized-data-bucket/ --profile your_aws_profile_name aws s3 cp s3 : //anonymized-data-bucket/ lt ; een bestandsnaam uitgevoerd door het vorige commando gt ; . csv test . csv --profile your_aws_profile_name Python Of je kunt een katachtig ding doen: aws s3 cp s3 : //anonymized-data-bucket/TEST-20210413T223846 . csv --profile your_aws_profile_name - | cat FIRST_NAME , LAST_NAME , PERSON_ID , PHONE John , Doe , 1 ,0499010203 Jane , Doe , 2 ,0499040506 Python De "transformatie" / anonimisering instellen Nu we in staat zijn om gegevens op te halen uit onze Oracle database, selecteren we de stromen die we willen en slaan we ze op als CSV-bestanden in S3. We missen nog één kleine, maar zeer belangrijke stap: het anonimiseren van de gegevens tijdens het transport tussen de tap en het doel. We gebruiken Pipelinewise Transform Field om de transformatie / anonimisering te bereiken. Dit stukje software vertegenwoordigt in feite de T die Singer als EL tool mist om er een echte ETL tool van te maken. Om het transformatiedeel op te zetten, blijven we in een bekend thema. Zet gewoon een andere virtuele omgeving op, activeer die, installeer een afhankelijkheid via pip en maak een configuratiebestand. python3 -m venv ~/ . virtualenvs/transform-field source ~/ . virtualenvs/transform-field/bin/activate pip install pipelinewise-transform-field Python Maak een config.json bestand aan in de bin directory van deze virtuele omgeving. Dit bestand bevat een eenvoudige lijst met transformaties. Zo'n transformatie definieert eenvoudig het type transformatie dat moet worden toegepast op een specifiek veld in een specifieke stroom. De configuratie in het onderstaande voorbeeld heeft als resultaat dat het veld FIRST_NAME in de TEST stream wordt gehasht : { " transformaties" : [ "field_id" : "FIRST_NAME" , " tap_stream_name" : "TEST" , " type" : "HASH" } } Python De lijst met beschikbare transformaties in de Pipelinewise Transform Field stap zijn: SET-NULL : transformeert elke invoer naar NULL HASH : transformeert tekenreeksinvoer naar hash HASH-SKIP-FIRST-n : transformeert tekenreeksinvoer naar hash waarbij de eerste n tekens worden overgeslagen, bijvoorbeeld HASH-SKIP-FIRST-2 MASK-DATE : vervangt de maand- en dagdelen van datumkolommen zodat ze altijd 1st of Jan zijn MASK-NUMBER : transformeert elke numerieke waarde naar nul MASK-HIDDEN : transformeert elke tekenreeks naar 'verborgen'. Hoewel deze transformaties voldoende zijn voor de anonimiseringsbehoeften van ons POC-geval, kunnen ze gemakkelijk worden gewijzigd. Je kunt zelfs aangepaste transformaties toevoegen. Bewerk hiervoor het bestand transform.py in de map lib/python3.9/site-packages/transform_field van de huidige virtuele omgeving. Alles samenvoegen Met deze 3 virtuele omgevingen op hun plaats kunnen we ze allemaal samenvoegen om het eindresultaat te produceren waar we naar op zoek zijn. Als we het onderstaande commando uitvoeren, zouden we moeten zien dat de ETL pipeline het geselecteerde schema synchroniseert, specifieke delen anonimiseert en het eindresultaat als een CSV-bestand opslaat in onze S3 bucket: ( tap-oracle ) developer@laptop bin % tap-oracle --config config . json --catalog catalog . json | ~/ . virtualenvs/transform-field/bin/transform-field --config ~/ . virtualenvs/transform-field/bin/config . json | ~/ . virtualenvs/target-s3-csv/bin/target-s3-csv --config ~/ . virtualenvs/target-s3-csv/bin/config . json INFO Geselecteerde streams : [ 'ETL-TEST' ] INFO Geen huidige_synchronisatie gevonden INFO Beginnen met synchronisatie van stream ( ETL-TEST ) met synchronisatiemethode ( full ) INFO Stream ETL-TEST gebruikt full_table replicatie INFO dsn : ( DESCRIPTION= ( ADDRESS= ( PROTOCOL=TCP ) ( HOST=localhost ) ( PORT=1521 ) ) ( CONNECT_DATA= ( SID=OraDoc ) ) time=2021-04-13 22 : 38 : 46 name=target_s3_csv level=INFO message=Attempting to create AWS session INFO select SELECT "FIRST_NAME" , "LAST_NAME" , "PERSON_ID" , "PHONE" , ORA_ROWSCN FROM ETL . TEST ORDER BY ORA_ROWSCN ASC INFO METRIC : { "type" : "teller" , "metric" : "record_count" , "value" : 2 , "tags" : {} time=2021-04-13 22 : 38 : 46 name=transform_field level=INFO message=Exiting normally time=2021-04-13 22 : 38 : 46 name=target_s3_csv level=INFO message=Uploading /var/folders/5k/86hrfqsd60b8pnh_81fqfy8h0000gn/T/TEST-20210413T223846 . csv naar emmer cjm-sandbox-anonymized-data at TEST-20210413T223846 . csv { "bladwijzers" : { "ETL-TEST" : { "laatste_replicatie_methode" : "FULL_TABLE" , "versie" : 1618346326464, "ORA_ROWSCN" : null}} , "currently_syncing" : null} Python Als we nu de CSV in onze emmer controleren: aws s3 cp s3 : //anonymized-data-bucket/TEST-20210413T224646 . csv --profile your_aws_profile_name - | cat FIRST_NAME , LAST_NAME , PERSON_ID , PHONE fd53ef835b15485572a6e82cf470dcb41fd218ae5751ab7531c956a2a6bcd3c7 , Doe , 1 ,0499010203 500501150a08713128839ca1465bfdc8a426268d6d0a576a16a80c13929f3faa , Doe , 2 ,0499040506 Python Conclusie In deze blogpost heb je gezien dat we Singer eenvoudig kunnen gebruiken om de doelen van de POC beschreven in de vorige blogpost te bereiken. Omdat er alleen wat eenvoudige dingen zoals Python en een Oracle client voor nodig zijn, kan het op de meeste systemen en in de meeste omgevingen geïnstalleerd en gebruikt worden. Het maakt ook gebruik van enkele eenvoudige JSON-gebaseerde configuratiebestanden die gemakkelijk kunnen worden aangepast aan een heleboel gebruikssituaties. De broncode van de taps en targets is ook beschikbaar en is meestal eenvoudig te begrijpen en aan te passen waar nodig. Als je geen tap of target kunt vinden die bij je past, moet het niet al te moeilijk zijn om er zelf een te schrijven . In de laatste aflevering van deze serie zal ik een manier laten zien om het hele systeem wat meer te vereenvoudigen en het te verpakken op een manier die meer geschikt is voor cloud native gebruik/deployment. Zij-zoektocht: Oracle in Docker Omdat ik geen toegang had tot een bestaande Oracle database, moest ik er zelf een draaien. Je zou denken dat dat makkelijk en snel zou zijn, maar het bleek iets ingewikkelder en behoorlijk frustrerend. Vooral vergeleken met het draaien van een PostgreSQL of MySQL/MariaDB container met Docker. Oracle XE werd lang geleden beschikbaar gemaakt. Het is een gratis versie van een Oracle database met enkele beperkingen , maar geen daarvan was problematisch voor mijn gebruik. Oracle XE kan worden geïnstalleerd op Windows en Linux, maar omdat ik op een Mac werk en mijn andere databases via Docker draai, wilde ik het draaien via een Docker image . Om dit te doen, moest ik zelf een Oracle docker image bouwen. Er is een Github repository die veel Dockerfiles en scripts van Oracle bevat . In deze repository is er ook een sectie voor Oracle databases: Oracle Database container images . Je kunt deze repository bekijken, naar de OracleDatabase/SingleInstance/dockerfiles directory gaan en het buildContainerImage.sh script uitvoeren om een echte Oracle Docker database container te bouwen. Ik wilde een Oracle 12 opzetten die overeenkomt met de installatie van de klant, maar daarvoor moest ik eerst wat database installatiebestanden downloaden. Het lijkt er echter op dat die niet meer publiekelijk beschikbaar zijn (je kunt ze krijgen via een Oracle contract). Dus nam ik genoegen met Oracle 18.4.0 XE: . /buildContainerImage . sh -v 18.4 .0 -x . . . duurt ongeveer 5 minuten . . . docker run -p 1521 : 1521 -p 5500 : 5500 -e ORACLE_PWD=admin123 oracle/database : 18.4 . 0-xe . .. duurt 30+ minuten . .. Python Op mijn MacBook Pro duurt het opstarten van deze Docker-container meer dan 30 minuten. Bovendien stopt het meestal na een paar uur met werken, waardoor een herstart nodig is die weer zoveel tijd in beslag neemt. Ik heb een aantal dingen geprobeerd, zoals volumes toevoegen om alle gegevens op te slaan die tijdens de eerste start worden gegenereerd, maar dat leek niet te helpen. Het gebruikt ook veel bronnen op mijn machine. Zelfs nadat de container draaide, was het verbinden met de database ook niet echt eenvoudig vanwege het pluggable database gedoe. Zelfs toen we verbonden waren, was het maken van een gebruiker en database specifiek voor onze POC en daarmee verbinden weer een hoop gedoe: service naam vs. SID en geen ondersteuning voor service naam in de Oracle Python bibliotheek die gebruikt wordt door de kraan. Dus uiteindelijk, na wat meer Googlen, vond ik een Docker repository van Oracle die een oude Oracle 12 docker container bevat . Je hebt er een gratis Oracle account voor nodig om de docker login te kunnen doen . Er is geen volume ondersteuning dus je zult in veel gevallen je data verliezen, maar het is eenvoudig op te zetten, start consistent in een paar minuten en je kunt er verbinding mee maken via een SID. Ook het toevoegen van een gebruiker en database was niet al te moeilijk en daarom heb ik dit uiteindelijk gebruikt in plaats van het nieuwere Github repository spul. docker login container-registry . oracle . com docker pull container-registry . oracle . com/database/standard : 12.1 .0 .2 docker run -d --env-file . /env -p 1521 : 1521 -p 5500 : 5500 -it --name dockerDB --shm-size= "4g" container-registry . oracle . com/database/standard : 12.1 .0 .2 Python

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 %}