Hoe werkt het Alumio integratieplatform?
Alumio is een cloudgebaseerd, low-code "integration Platform as a Service"iPaaS). Alumio is een API-gebaseerde oplossing die helpt om meerdere systemen, software, applicaties en gegevensbronnen met elkaar te verbinden, zowel op locatie als in de cloud.
Als low-code oplossing biedt Alumio een gebruiksvriendelijke interface voor zowel ontwikkelaars als zakelijke gebruikers om alle integraties te creëren, monitoren en beheren op één visuele interface: zonder aangepaste code en met eenvoudige klik-en-configuratie opties. Alumio biedt ook ontwikkelaarsvriendelijke functies om gegevens flexibel in kaart te brengen en te transformeren, complexe workflows te automatiseren, edge cases aan te pakken en connectorpakketten te implementeren (of zelfs te bouwen) om snellere verbindingen en integraties op maat te maken.
Door alle integratie en gegevens te centraliseren op één speciale cloudruimte en single-tenant infrastructuur te bieden, is het Alumio integratieplatform gebouwd om bedrijven te helpen bij het ontwikkelen, beheren en orkestreren van veilige IT op een schaalbare manier. It helpt gegevens te synchroniseren tussen alle geïntegreerde systemen, voorkomt datasilo's en vermindert fouten door duplicatie. Alumio biedt gegevensbeveiliging die voortdurend wordt verbeterd en bijgewerkt, garandeert minimale uitvaltijd en is uitgerust met reactiveringsprocedures, gegevenscaching en buffermogelijkheden om de bedrijfscontinuïteit te allen tijde te garanderen.
Hoewel al het bovenstaande voldoende kan zijn om Alumio vanuit zakelijk oogpunt uit te leggen, is it voor technische professionals belangrijk om de architectuur waarop Alumio is gebouwd te onderzoeken om te begrijpen hoe it echt werkt.
Wat omvat de architectuur en beveiligingsinfrastructuur Alumio ?
Om een diepgaand begrip te bieden van wat het Alumio low-code integratieplatform tot een flexibele, schaalbare en toekomstbestendige oplossing maakt, biedt deze whitepaper een technische verdieping:
De architectuur van Alumio
De beveiliging van het Alumio
De prestatiekenmerken van Alumio
1. De architectuur van Alumio
Ontdek de innerlijke werking van ons toekomstbestendige integratieplatform
Alumio is ontworpen als een next-gen, API-gedreven iPaaS (integration Platform as a Service) dat helpt bij het creëren, bewaken en beheren van toekomstbestendige integraties en IT . Om deze visie te bereiken en te belichamen, volgt de architecturale benadering achter het Alumio platform de volgende ontwerpprincipes:
1.1 De integratie-interface
De gebruiksvriendelijke webinterface van Alumio is ontwikkeld in React en is losgekoppeld van de backend. Hierdoor is de front-end ontwikkeling grotendeels onafhankelijk van de back-end ontwikkeling binnen het platform. De gebruikersinterface draait lokaal in de browser van de gebruiker en communiceert rechtstreeks met de backend via OpenAPI over HTTPS. De gebruikersinterface implementeert de authenticatie die door de backend wordt aangeboden en leest configuratie, (UI) schema's, enz. uit de backend.
Bedrijfslogica van de gebruikersinterface en de backend scheiden".
De gebruikersinterface Alumio interpreteert de gegevens die door de backend worden verzonden en formatteert it in weergaven, formulieren, validaties, enz. Alle gegevens die worden uitgewisseld tussen de gebruikersinterface en de backend worden geformatteerd met JSON.
1.2 Afhankelijkheidsinjectie (DI)
In traditionele softwareontwikkeling wordt afhankelijkheidsinjectie gebruikt om zorgen en het gebruik van objecten te scheiden. Alumio past de afhankelijkheidsinjectie aanpak toe op de ontwikkeling en/of configuratie van platform-specifieke componenten (SOAP clients, subscribers, transformers, publishers, etc.). Hierdoor kan configuratie worden hergebruikt zonder belemmeringen in de software te veroorzaken.
De Alumio Dependency Injection zorgt ervoor dat de configuratie kan worden geoptimaliseerd".
In de praktijk betekent dit dat bijvoorbeeld één HTTP-client kan worden geconfigureerd voor veel verschillende verbindingen, onafhankelijk van het feit of ze gegevens ophalen of versturen. De afhankelijkheidsinjectie helpt de configuratie en het onderhoud die nodig zijn voor een Alumio te verminderen.
1.3 Aspectgeoriënteerd programmeren (AOP)
Alumio implementeert AOP (Aspect-Oriented Programming), wat betekent dat it verschillende soorten bedrijfslogica van elkaar scheidt. Logging van applicatieverwerking wordt automatisch geïmplementeerd vanwege AOP, wat betekent dat elke client, transformer en andere objecten logging kunnen hebben ingeschakeld zonder dat het nodig is om een loggingfunctionaliteit binnen deze objecten te ontwikkelen.De AOP pointcuts zijn ook beschikbaar voor eindgebruikers vanAlumio , die DI plugins kunnen toevoegen aan de geleverde pointcuts.
1.4 Configuratie van integraties
Alumio heeft verschillende configuratietypen die hieronder worden beschreven, namelijk:
Integratie-specifieke configuratie
Configuratie voor algemene doeleinden
1.5 Configuratie voor koppeling met remote systemen
Alumio biedt verschillende generieke client-configuratie opties om te interfacen met systemenremote .
Remote configuratie
Communicatie tussen servers in een netwerk en digitale software kan plaatsvinden via HTTP, waarbij HTTP-aanvragen worden verzonden en HTTP-reacties worden ontvangen.
Configureer HTTP-clients en gebruik ze om te interfacen met HTTP-eindpunten met behulp van HTTP-conforme methoden. Verzoeken kunnen worden uitgebreid om post-data te bevatten.Authenticatiemethoden zoals OAuth 2.0 kunnen worden geconfigureerd op een HTTP-client met behulp van DI.
PDO
PDO is een lichtgewicht abstractielaag voor toegang tot databases.
Configureer databaseclients van MySQL tot Oracle om databasegegevens op te halen en te posten, opgeslagen procedures uit te voeren, enzovoort.
SOAP
SOAP ondersteuning is een uitbreiding van de Alumio HTTP elementen en bevat authenticatie. Dit protocol is misschien niet altijd het leidende protocol, maar it wordt nog steeds veel gebruikt.
Configureer clients om verbinding te maken met een SOAP service om gegevens op te halen en te posten met behulp van algemeen beschikbare aanvraagmethoden. Alumio biedt een oplossing om de inherente verschillen tussen SOAP services aan te passen, zoals het toevoegen van een aangepaste authenticatie envelop of wijzigingen in de berichtstructuur.
Bestandssystemen
Bestandssystemen worden gekoppeld door gebruik te maken van 'Bestandssysteem', wat een abstractielaag is om interacties tussen bestandssystemen agnostisch te standaardiseren.
Configureer bestandssystemen om bestanden te lezen en te schrijven op services zoals FTP, SFTP, AWS S3, HTTP, enz. Bestandssysteem interacties worden stateless uitgevoerd.
1.6 Configuratie om integraties te onderhouden
Integraties tussen systemen remote worden onderhouden met behulp van ten minste één route, bestaande uit een inkomende configuratie en een uitgaande configuratie. Integraties kunnen verder worden uitgebreid met transformers, die kunnen worden toegepast op routes, inkomende configuraties en uitgaande configuraties. De elementen worden hieronder in detail beschreven:
Remote configuratie
Routes verbinden systemen remote met behulp van een inkomende verbinding en een uitgaande verbinding en eventueel een lijst met transformer .
Inkomende configuratie
Inkomende configuraties vergemakkelijken het ophalen of ontvangen van gegevens voor de Alumio wachtrij.
Een inkomende configuratie maakt gebruik van de configuratie remoteSOAP, REST, FTP, enz.) om gegevens te produceren voor het volgende deel of de volgende delen van de route(s) waarvoor ze zijn geconfigureerd. Aan een inkomende configuratie kunnen transformers worden gekoppeld om de geproduceerde gegevens te manipuleren voordat de gegevens worden doorgegeven.
Opmerking: in dit stadium kunnen alle buitenlandse bestandsformaten (XML, CSV, EDI) worden geconverteerd naar JSON, aangezien Alumio werkt met het JSON .
It mogelijk om een enkele inkomende configuratie in meerdere routes te gebruiken, waardoor een efficiënter IT mogelijk wordt door gegevens één keer te ontvangen en it daarna naar meerdere remote systemen te sturen.
Uitgaande configuratie
Uitgaande configuraties vergemakkelijken het verzenden van gegevens uit de wachtrij Alumio . Een uitgaande configuratie maakt gebruik van de remoteSOAP, REST, FTP, enz.) om gegevens die ze ontvangen van de route(s) waarvoor ze zijn geconfigureerd, naar de remote systemen te sturen.
Aan uitgaande configuraties kunnen transformers worden gekoppeld om de ontvangen gegevens te manipuleren voordat de gegevens naar remote systemen worden gestuurd.
Opmerking: in dit stadium kunnen de JSON opnieuw worden geconverteerd naar andere bestandsindelingen (XML, CSV, EDI enz.).
Transformer
Transformer vergemakkelijken de transformatie van de gegevens die op elk punt in de routes beschikbaar zijn.
Transformatie maakt dataselectie/reductie, vertaling/mapping, codering, berekening, sorteren/ordenen, samenvoegen/samenvoegen/opzoeken vanuit andere bronnen, aggregatie, genereren van surrogaatsleutels, transponeren/pivoteren van array/objectsleutels en waarden, en validatie mogelijk.
Transformers kunnen ook gebruikt worden om volledige gegevenspunten uit te filteren die geproduceerd worden door binnenkomende configuraties, waardoor onnodige wachtrij-items voorkomen worden.
De meeste transformers staan het gebruik van bedrijfslogica toe om te beslissen of de transformer zal worden toegepast op de gegeven gegevens.
1.7 Configuratie voor algemene doeleinden
Integraties tussen systemen remote worden onderhouden met behulp van ten minste één route, bestaande uit een inkomende configuratie en een uitgaande configuratie. Integraties kunnen verder worden uitgebreid met transformers, die kunnen worden toegepast op routes, inkomende configuraties en uitgaande configuraties. De elementen worden hieronder in detail beschreven:
Omgevingsvariabelen
Sla herbruikbare waarden op en versleutel gevoelige waarden met omgevingsvariabelen (zoals wachtwoorden, API-sleutels, enz.) platformbreed. Gevoelige gegevens worden automatisch verwijderd uit logs, zoals de logs van wachtrijitems, zodat eindgebruikers of andere ongeautoriseerde gebruikers geen toegang hebben tot de beveiligde waarden die in het platform worden gebruikt.
Opslag
Sla gegevens op voor optimalisatie van routes, waarbij alleen de meest recente items worden opgehaald. Voer een differentieel uit om het aantal wachtrijitems dat verwerkt wordt te verminderen. Bijhouden om te controleren of de identifier van het laatste item, geaggregeerde route , enz. door het platform worden ondersteund en kunnen worden toegepast om routes te optimaliseren.Opslag kan ook gebruikt worden om je eigen caching mechanisme te maken en te implementeren of om ook lookup tabellen te maken.
Configureer database clients vanMySQL tot Oracle om database data op te halen en te posten, stored procedures uit te voeren, etc.
1.8 Wachtrij
Alle gegevens die het platform binnenkomen en voorbereid zijn om verwerkt te worden door een uitgaande configuratie worden beschikbaar in de wachtrij. Deze wachtrij-items zorgen ervoor dat geconfigureerde routes inspecteerbaar zijn en geven de task weer om te laten zien wat er gedaan is en wat niet.
Er zijn meerdere manieren waarop een wachtrij-item kan verschijnen: geplande inkomende configuraties, webhook oproepen naar het platform en proxying verzoeken via het platform. Veel van deze zijn real-time of kunnen als dusdanig geconfigureerd worden.Elk wachtrij-item bevat configuratiegegevens: waar de gegevens vandaan komen en waar it naartoe gaan.
De wachtrij-items tonen ook de gegevens die ermee verbonden zijn.Tenslotte tonen de wachtrij-items welke logging er gebeurd is aan de inkomende kant en aan de uitgaande kant. Deze logs kunnen fouten bevatten en toegang geven tot debug informatie zoals HTTP fouten.
1.9 Loggen
Alumio logs alle gegevens en gebeurtenissen tijdens de verwerking van inkomende en uitgaande gegevens.Gevoelige gegevens zoals API-wachtwoorden worden automatisch uit de loggegevens en versleutelde omgevingsvariabelen gefilterd. Loggegevens worden verzameld en gesynchroniseerd naar een Elastic Stack.De loggegevens worden weergegeven voor elke task die wordt aangemaakt en voor elke subscribe/publish actie inAlumio.
Triggers kunnen worden aangemaakt binnen de Elastic Stack op basis van de loggegevens. Dit kan worden gebruikt als monitoring. Er kan bijvoorbeeld een waarschuwing worden verstuurd als een aantal taken binnen een uur mislukken.
1.10 Bewaking
Configureer triggers om beheerders op de hoogte te houden van de gezondheid van integraties, of taken (wachtrij-items) vastlopen, niet publiceren, enzovoort.Itis mogelijk om Alumio monitoring meldingen via e-mail te krijgen.
1.11 Processor
De meeste integraties draaien in twee aparte processen, een voor inkomende gegevens en een ander om de gegevens te verwerken. De verwerking wordt meestal gestart met behulp van een scheduler, anders wordt it gestart als onderdeel van een realtime actie vanwege configuratie-instellingen, die dan samen met het proces voor inkomende gegevens wordt uitgevoerd.
De processor is een configureerbaar element waarmee het platform het maximum aantal taken (wachtrijitems) kan instellen dat voor een bepaalde route moet worden verwerkt. Door een maximum aantal taken in te stellen kan het platform voorkomen dat de ontvangende systemen remote overbelast raken. Dit zorgt ervoor dat de belangrijkste integraties blijven werken terwijl andere integraties wachten.
1.12 Opslag van toepassingen
Alumio gebruikt Elastic Stack en MySQL om applicatiegegevens en logs op te slaan.De logs die tijdens de uitvoering vanAlumio worden geproduceerd, worden naar Elastic Stack gestuurd en daar geïndexeerd, zodat logs snel toegankelijk zijn vanuit de interface van Alumio . Dankzij AOP zijn deze logs zeer granulair en kunnen ze worden aangepast als het platform evolueert.
Configuratie, omgevingsvariabelen, taken en gebruikers worden opgeslagen in MySQL.TerwijlAlumio evolueert, worden de MySQL datastructuren onderhouden met migraties om bestaande projecten te kunnen upgraden naar de laatste versie van het platform.
1.13 Verwerkingsverbinding
Getriggerde inkomende verbindingenWebhooks)
Alumio kan triggers ontvangen om routes te starten van externe eindpunten.
Webhooks laten systemen toe om geautomatiseerde berichten of informatie naarAlumio te sturen.Itis een krachtige manier om automatisch gegevens van de ene app naar de andere te pushen.
Transparante realtime verbindingen (HTTP-proxy)
Alumio kan functioneren als een HTTP-proxy tussen twee eindpunten voor HTTP-verzoeken. In plaats van HTTP berichten rechtstreeks naar een eindpunt te sturen, kunnen berichten viaAlumio gestuurd worden. It zal de verzoeken doorsturen naar het eindpunt en het antwoord dat it ontvangt terugsturen alsof het eindpunt rechtstreeks werd aangeroepen. Dit geeft elke bestaande verbinding die de Alumio HTTP Proxy gebruikt de logging mogelijkheden die Alumio biedt.
Geplande inkomende verbindingen
Inkomende verbindingen worden getriggerd door het schema (tenzij getriggerd door webhooks). Inkomende verbindingen maken verbinding met eindpunten met behulp van hun configuratie om gegevens op te halen voor verbonden routes.
Geplande/Real-time uitgaande verbindingen
Uitgaande verbindingen worden getriggerd door hun schema of door de inkomende kant wanneer de gerelateerde route is geconfigureerd als een real-time route, met behulp van de optie "Realtime verwerking inschakelen".Uitgaande verbindingen maken verbinding met eindpunten met behulp van hun configuratie om gegevens van de gerelateerde route naar het eindpunt te sturen.
1.14 Authenticatie
Authenticatie met deAlumio API is beveiligd met Google OAuth. Zodra gebruikers zijn aangemaakt inAlumio kunnen ze inloggen in Alumo via verschillende methoden:
1. Google account Google account Microsoft
2. Social account (zakelijke accounts worden niet ondersteund)
3. Azure AD, SAML, Okta, ADFS, OpenID, LDAP, Google Workspace (alleen Enterprise licenties)
4. Registreren van een nieuwe Alumio account
Voor extra veiligheid is Multi-Factor Authenticatie (MFA) vereist om in te loggen op de Alumio omgeving.
Standaard wordt een klantdomein toegevoegd aan de Alumio instantie van de klant. Gebruikers met een Google account worden automatisch toegevoegd aan het platform. De configuratie bepaalt of de gebruiker alleen view-only of ook create en/of edit rechten heeft.
1.15 JSON
Alumio gebruikt JSON 's om een duidelijk gegevensformaat te bieden waarmee kan worden gecommuniceerd. De schema's worden gebruikt om te bepalen hoe gebruikersinvoer eruit moet zien, hoe configuratieobjecten moeten worden gedefinieerd, hoe formulieren moeten worden weergegeven, enz. Deze schema's zorgen voor een duidelijke en consistente applicatie-interface.
1.16 Typen gegevensentiteiten
Gegevensentiteiten voor voorgedefinieerde elementen zijn zoveel mogelijk gestandaardiseerd. Dit betekent datAlumio een tussenstandaard heeft voor veel typen gegevensentiteiten (bijv. orders, producten, creditnota's, mensen, enz.). Het hebben van deze tussenstandaarden vermindert de complexiteit van interfacing met (gedeeltelijk) bekende systemen, vermindert de benodigde mutaties op de gegeven gegevens en de algehele complexiteit van het configureren van gegevensstromen.
1.17 Symfony - Het Alumio ontwikkelingsraamwerk
Het Alumio framework is ontwikkeld op Symfony, dat veel out-of-the-box en generieke functies biedt die zijn geïmplementeerd inAlumio. De afhankelijkheidsinjectie van Symfony verbindt alle belangrijke componenten vanAlumio met elkaar.
BelangrijkeAlumio zijn in wezen de functies die kunnen worden uitgebreid met behulp van ons modulaire systeem. Dit omvat componenten zoals authenticatie, de Alumio dependency injection, OpenAPI, logging, inkomend, uitgaand en nog veel meer. Symfony biedt ook meer algemene componenten die kunnen worden geïmplementeerd, zoals Doctrine.
Vind het wiel niet opnieuw uit:Alumio gebruikt Symfony-bibliotheken voor generieke functies"
Over Symfony: Itis 's werelds toonaangevende framework met een grote set ontkoppelde en herbruikbare componenten waarop enkele van de beste applicaties zijn gebouwd. De Symfony Community bestaat uit meer dan 600.000 ontwikkelaars uit meer dan 120 landen die best practices, standaardisatie en interoperabiliteit van applicaties omarmen en promoten. Symfony is alles wat je van een framework mag verwachten: snelheid, flexibiliteit, herbruikbare componenten, enz.
1.18 OpenAPI/Swagger
Alumio stelt zijn functies beschikbaar via OpenAPI, de moderne open standaard API-definitie. Elke actie wordt gedefinieerd en beschikbaar gemaakt via deze API met duidelijke schema's voor het verzenden en ophalen van gegevens. Alle elementen die in de gebruikersinterface Alumio worden weergegeven/bewerkt, worden via deze API verwerkt. Zelfs het verwerken van routes kan worden uitgevoerd via de API, zoals het uitvoeren van een binnenkomende configuratie en het exporteren van gegevens van een bepaalde route.
2. De beveiliging van het Alumio
Ontdek de hoge beveiligingsstandaarden van ons integratieplatform
Ons integratieplatform verplaatst gegevens van het ene systeem naar het andere, die kritieke informatie over uw bedrijf, financiële gegevens en de persoonlijke en identificeerbare informatie (PII) van uw klanten kunnen bevatten. De veiligheid van uw gegevens moet worden gewaarborgd.
Beveiliging zit in ons DNA en is op technisch niveau ingebed in elk Alumio . De beveiliging van ons product, onze infrastructuur en onze gegevens is onze topprioriteit. Ons beveiligings- en risicobeheerteam werkt volgens de industrienormen om ervoor te zorgen dat uw gegevens veilig zijn. Om ervoor te zorgen dat onze compliance en beveiliging aan de hoogste normen voldoen, houden we ons platform uitgebreid in de gaten. Ons productteam werkt voortdurend aan het verbeteren en bijwerken van het platform om te voldoen aan de nieuwste beveiligingsstandaarden, zodat onze klantgegevens optimaal beveiligd zijn.
2.1 Veiligheid door ontwerp
Het Alumio integratieplatform is gebouwd met behulp van de beste technologische raamwerken en veilige software ontwikkelingspraktijken. Alle fixes, nieuwe functies en verbeteringen worden pas vrijgegeven na een aantal strenge tests en een strikt reviewproces. Ons testprogramma bestaat uit geautomatiseerde codetests met betrekking tot de kwaliteit van de code, maar ook uit handmatige tests waarbij elke coderegel wordt gecontroleerd en getest door ten minste twee senior ontwikkelaars.
Alumio engineers ontwikkelen de kernapplicatie op basis van het concept 'Security-by-Design':
Onze Secure SDLC-processen (Software Development Lifecycle) omvatten gedocumenteerde beveiligingseisen, beoordelingen van het beveiligingsontwerp, beveiligingstests van toepassingen en volledige penetratietests.
Productie- en testomgevingen zijn volledig van elkaar gescheiden. De gegevens van klanten of andere privacygevoelige informatie worden nooit overgedragen naar testomgevingen of testomgevingen voor ontwikkelaars.
Beveiligingstests worden uitgevoerd na elke release in de OWASP top 10. Ten minste jaarlijks worden uitgebreide kwetsbaarheids- en penetratietests uitgevoerd.
We gebruiken geautomatiseerde DevOps-beveiligingstools zoals OWASP Zap en Sensiolabs om tijdens de hele ontwikkelingsfase te testen op zwakke plekken in de beveiliging.
Gerelateerde bugs krijgen altijd de hoogste prioriteit en er wordt een oorzakenanalyse uitgevoerd voor alle grote bugs it in productie komen. Elke pull-aanvraag tot releasable werk vereist een code review waar minstens twee andere (senior) ontwikkelaars aan worden toegevoegd.
Het team dat aan de kern van Alumio werkt, is zeer betrokken bij beveiligingsprocedures en is in staat om geschreven code goed te beoordelen en er feedback over te geven. We automatiseren beveiligingstests met Sensiolabs Security Checker.
Ontwikkelaars worden getraind in veilige coderingspraktijken.
2.2 Voldoen aan beveiligingsstandaarden
Alumio is trots op haar inzet om gevoelige informatie te beschermen. Als bewijs hiervan heeft Alumio een rigoureus implementatieproces ondergaan en overeenstemming bereikt met ISO 27001, een internationaal erkende norm voor beheersystemen voor informatiebeveiliging. Deze norm beschrijft de beste praktijken en richtlijnen voor het opzetten, implementeren, onderhouden en continu verbeteren van beheersystemen voor informatiebeveiliging om de vertrouwelijkheid, integriteit en beschikbaarheid van informatie te garanderen.
2.3 Toegang tot het Alumio integratieplatform
De toegang legde uit:
Rolgebaseerde toegangscontrole (RBAC)
Onze medewerkers hebben toegang op basis van gebruikersrollen met het concept van 'least privilege', dus er wordt geen toegang verleend tot een niveau dat niet is beschreven als nodig in de 'rol'.
Beveiliging Remote toegang
Toegang Remote tot de Alumio en -infrastructuur is alleen mogelijk na inloggen op het VPN van het bedrijf. Inloggen op de Alumio kan door middel van een inlogprocedure met twee-factor authenticatie.
IP-whitelisting
Toegang tot de Alumio codebase en infrastructuur is alleen mogelijk na inloggen op het VPN van het bedrijf. Deze IP-adressen zijn statisch en staan op een witte lijst van onze systeembeheerders.
Toegang tot leveranciersondersteuning
De toegang voor leveranciers is gebaseerd op de beveiligingsmaatregelen Amazon Web Services.
Volgen van gebruikers
Alle aanmeldingsacties van gebruikers worden vastgelegd, zoals aanmeldings-ID's (gebruikersnaam Fan ID), datum/tijd van laatste aanmelding, locatie van aanmelding (bijv.: IP-adres), apparaatidentificatie (bijv.: MAC-adres). De logs worden voor een periode van 8 weken naar een locatie met een speciale toegangsvereiste geduwd.
Regelmatige toegangsbeoordelingen
Alumio heeft een proces dat ervoor zorgt dat er regelmatig toegangsbeoordelingen worden gehouden. Deze stellen managers op de hoogte van problemen met offboarding, zodat Alumio onze processen kan bijwerken en de nodige wijzigingen kan doorvoeren.
Versleuteling harde schijf
Werknemers van Alumio zijn verplicht om harde schijf encryptie toe te passen op hun lokale machines, zoals vermeld in het onboarding beleid voor werknemers.
Firewall configureren
Werknemers van Alumio zijn verplicht om een firewallconfiguratie toe te passen op hun lokale machines, zoals vermeld in het inwerkbeleid voor werknemers.
Werknemers in engineering, services, support en operations (in principe iedereen met toegang tot alles wat als gevoelig voor beveiliging wordt beschouwd) zijn verplicht om het VPN van het bedrijf te gebruiken met multifactorauthenticatie ingeschakeld, om alle referenties op te slaan en te genereren die worden gebruikt om hun werk uit te voeren.
Engineering-werknemers met toegang tot productiesystemen zijn ook verplicht om ten minste jaarlijks verschillende niveaus van beveiligingstraining te volgen. Al onze werknemers krijgen altijd alleen toegang tot het minimale aantal applicaties of systemen dat nodig is om hun taken uit te voeren.
2.4 Beveiliging van netwerk en infrastructuur
Verantwoordelijkheden:
Amazon Web Services is verantwoordelijk voor:
Elastic is verantwoordelijk voor:
Loggen via Elastic ELK stack (Elasticsearch, Logstash, Kibana)
Amazon Web Services is verantwoordelijk voor:
Alumio volgt de richtlijnen en best practices van de volgende beveiligingsstandaarden:
ISO 9001 | 27001 | 27002 | 27017 | 27018 | 22301 | 31000
2.5 Netwerk: gegevensopslag en -verwerking
Alle communicatie van en naar het datacenter van Amazon Web Services en Alumio gebruikt minimaal SSL 256-bit encryptie en verloopt via HTTPS, poort 443.
Standaardinstellingen:
Gegevens in rest:
Er wordt geen versleuteling toegepast en de toegang tot gegevens in rest is beperkt tot bevoegde gebruikers.
Gegevens onderweg:
Beveiligd afhankelijk van de situatie, meestal door HTTPS, SSH-tunneling, VPN, enz.
2.6 Opslag en verwerking van gegevens
De Alumio heeft drie manieren om gegevens op te slaan:
In sommige gevallen bewaart of verwerkt Alumio persoonlijke gevoelige gegevens zoals vermeld in de DPA of GDPR. De soorten gegevens die worden verwerkt of opgeslagen, worden vermeld in de dataroutes. Een rapport is beschikbaar of kan worden aangemaakt voordat het mappingproces wordt gestart.
2.7 Geautomatiseerde communicatie van gegevens
Alumio stuurt automatisch de volgende informatie naar het Amazon Web Services datacenter:
Online status:
De Alumio monitoring service weet in bijna real-time wanneer de integratiediensten offline gaan.
Mailings:
Alumio verstuurt wel gezondheidse-mails, maar nooit uit naam van een klant.
Traceerinformatie:
Het Alumio platform communiceert de bestandsnaam en map van de verwerkte bestanden, evenals succes/mislukking tellingen en procesuitvoeringen.
Integratieproces updates:
Het Alumio platform controleert periodiek of er statusupdates zijn van de taken die worden uitgevoerd binnen hun configuraties.
2.8 Door de gebruiker geïnitieerde gegevenscommunicatie
Op verzoek van een geautoriseerde gebruiker communiceert het Alumio platform het volgende naar het Alumio datacenter:
Registratie-en bewakingsinformatie
Informatie over de uitvoering van een integratieproces, inclusief de totale uitvoeringstijd, logging voor elke stap van het proces en foutmeldingen over de uitvoering. API-gegevens of task logs (berichten via routes = taken) worden 2 weken bewaard. Server-gerelateerde logs worden een maand bewaard. Beide zijn naar behoefte te configureren op basis van de gekochte Alumio .
logs exporteren:
Alumio biedt de mogelijkheid om logs te exporteren. Elke geautoriseerde gebruiker kan task logs exporteren.
Alumio off-site maakt back-ups van het volgende:
Databases - dagelijks tot een week lang
Details fout - een gedetailleerde foutmelding die uitlegt welke fout de mislukte uitvoering van een integratieproces heeft veroorzaakt.
Bij het bouwen van processen voor specifieke connectors kan databaseschema-informatie worden verzonden om regels voor de toewijzing van velden te definiëren. Er worden geen eigenlijke gegevens verzonden.
2.9 Beveiliging van datacommunicatie op locatie
Er hoeven geen inkomende firewall poorten open te staan voor het Alumio integratieplatform om te communiceren met het datacenter. De Alumio integratie interface initieert altijd de verbinding; het datacenter van Amazon Web Services pusht nooit automatisch data naar het Alumio integratieplatform (of privaat gehoste oplossing). Wanneer de Alumio functie een verbinding initieert, gebruikt it een SSL handshake om het datacenter te authenticeren voordat gegevens worden verzonden. Alumio gebruikt het digitale certificaat dat automatisch wordt aangemaakt tijdens de registratie en verificatie.
3. De Alumio
Ontdek wat ons integratieplatform schaalbaar, veilig en toekomstbestendig maakt
Het Alumio integratieplatform is een cloud-gebaseerde oplossing, geleverd in een single tenant infrastructuur in de regio van onze klant. Of itnu Europa, Azië of de VS is, Alumio biedt een snelle, veilige en compliant implementatie van ons integratieplatform. Het Alumio licentiemodel omvat hosting/applicatie (beheer) en updates. Alumio levert de netwerken, servers, opslag, besturingssysteem (OS), database en andere diensten om de door de klant gekochte Alumio te hosten.
Hosting infrastructuur is een vitaal aspect dat de schaalbaarheid van het platform beïnvloedt. Alumio levert high-performance hosting infrastructuren die klaar zijn voor wereldwijde uitrol naar SMB's en internationale Enterprises.
3.1 Monitoring
In vergelijking met ESB's is iPaaS een cloudgebaseerd platform dat een relatief lichte architectuur gebruikt en geen installatie op locatie nodig heeft. Terwijl zowel ESB's als iPaaS gespecialiseerd zijn in het integreren van legacy systems, kan iPaaS flexibel verbinding maken met veel meer grote of kleine SaaS, cloud-apps en gegevensbronnen, zowel in on-premises als cloud-omgevingen.
Terwijl ESB's een complexe messaging-architectuur implementeren om applicaties te verbinden, hanteert iPaaS een API-first benadering. Dit helpt de iPaaS om snellere en flexibelere integraties te bouwen, die gemakkelijk kunnen worden gewijzigd of gegevenstransformatie ondergaan, zonder verlies van gegevensintegriteit of bedrijfscontinuïteit.
Bovendien moet een ESB , zoals eerder aangegeven, worden bediend door ervaren IT dat zorgvuldig is opgeleid en getraind in het implementeren it. iPaaS daarentegen biedt een cloudgebaseerde webinterface waar zowel ontwikkelaars als burgergebruikers (CTO's, projectmanagers, junior ontwikkelaars) op afstand op kunnen samenwerken om integraties te ontwikkelen, beheren en orkestreren.
3.2 Back-ups
Om gegevensverlies te voorkomen, is it noodzakelijk om regelmatig back-ups te maken. In tegenstelling tot veel aanbieders kiest Alumio voor back-ups op basis van bestandsgebaseerde back-uptechnologie. Dit geeft Alumio de mogelijkheid om zelfs een enkel bestand terug te zetten. It kan de hersteltijd aanzienlijk verkorten en biedt meer gemak voor ontwikkelaars die op zoek zijn naar specifieke bestanden.
Alumio gebruikt R1Soft, de marktleider in de high-end back-up softwaremarkt. Standaard gaat de back-up uit van 1 herstelpunt, dat wordt aangevuld met de 'wijzigingen' vanaf het herstelmoment. Deze back-ups worden buiten je cloudomgeving gemaakt en zijn vooral bedoeld om bij calamiteiten snel over een volledige kopie van je omgeving te kunnen beschikken. De back-up is een volledige back-up en wordt elke nacht weggeschreven naar een NAS (Network Attached Storage) server in het netwerk, maar buiten je cloudomgeving. Deze back-up kan gebruikt worden als uw server onverhoopt uitvalt. Binnen de standaard serviceniveaus Alumio wordt de back-up 1 keer per dag gemaakt en 7 dagen bewaard.
Alumio kan binnen deze periode elke dag terugzetten. Daarnaast is it mogelijk om het back-upschema uit te breiden en te intensiveren, de back-ups naar uw fysieke locatie te sturen en meerdere herstelpunten aan te maken.
3.3 Herstel na rampen
Alumio zorgt ervoor dat er altijd herstel kan plaatsvinden in het geval van ernstige storingen. Disaster recovery kost tijd. Daarom verschilt de tijd die wordt ingepland per SLA-variant. In de standaard SLA staat dat Alumio tijdens kantooruren tussen de 1 - 2 uur nodig heeft om te beginnen met het herstellen van je gegevens. De tijd die nodig is om de applicatie in zijn geheel te herstellen is afhankelijk van de grootte van je applicatie (aantal GB) maar bedraagt +/- 1 uur per 10 GB aan te herstellen data. Het infrastructuurbeheer van Alumio vertrouwt ook op het beleid en de procedures voor Amazon Disaster Recovery en Elastic Disaster Recovery. behoeften.
3.4 Inzetregio's en strategie
Wanneer uw instantie van het Alumio wordt ingezet, kiest it een primaire inzetregio voor uw bedrijf op basis van uw keuze. Uw primaire regio bevat al uw Alumio en is de plaats waar uw belangrijkste organisatieprocessen plaatsvinden. Dit heeft betrekking op de hostinginfrastructuur die wordt geleverd door Amazon Web Services en Elastic Stack.
3.5 Inzet in meerdere regio's
Alumio beveelt Enterprise businesses aan als geclusterde oplossing voor een krachtige infrastructuur die klaar is voor wereldwijde uitrol.
De krachtige infrastructuur is een op Kubernetes gebaseerd systeem voor het automatiseren van de inzet, het schalen en het beheer van gecontaineriseerde applicaties binnen meerdere regio's.
3.6 Schaalbaarheid
wise is it net zo schaalbaar als Amazon Web Services kan bieden. De functies die in Alumio zijn ontwikkeld, zijn ontworpen met schaalbaarheid in gedachten. Alle logica kan echter worden vervangen door aangepaste logica om de prestaties te verbeteren en dus op te schalen.
Er kan geschaald worden volgens de instellingen, en die kunnen per regio (bijv. een land) ingesteld worden. Dit is echter waarschijnlijk niet nodig.
Schaalbaarheid brengt enige complexiteit met zich mee wat betreft de configuratie van de Alumio setup. Verder zijn de enige beperkingen de beperkingen van de hosting.
4. De prestaties Alumio
Zorgen voor bedrijfscontinuïteit en een hoge uptime voor softwareconnectiviteit
Er zijn nog een aantal essentiële aspecten van het Alumio integratieplatform die de prestaties, veiligheid en betrouwbaarheid sterk verbeteren:
4.1 Robuust opslag- en wachtrijsysteem
Gegevenspakketten als 'in-process data' worden tijdelijk opgeslagen in ons robuuste wachtrijsysteem, afhankelijk van het type transformatie en het gekozen Alumio , in MySQL, Elastic, Apache spark, Google GCP of Amazon's Redshift.
Ze worden gebruikt om verwerking op schaal te garanderen voor alle afzonderlijke pagina's met gegevens die onderweg zijn. Als een systeem offline gaat, maakt de bovenstaande architectuur het mogelijk om op een elegante manier flowverwerkingsactiviteiten te pauzeren en te hervatten zonder verlies van gegevens.
4.2 Big Data
Alumio is gebouwd als een krachtig integratieplatform om externe toepassingen te koppelen en big data te verwerken. Gegevens worden omgezet in kleinere pakketten dieAlumio ' worden genoemd. Deze kunnen op een schaalbare manier door ons systeem stromen naar extern aangesloten applicaties via onze API, ondersteund door ons robuuste wachtrijmechanisme.
4.3 DevOps
Alumio heeft een volledig DevOps-team dat het Alumio 24/7 bewaakt. Het DevOps-team heeft mensen op meerdere locaties en elk teamlid is volledig uitgerust om op afstand of vanuit een Alumio te werken.
4.4. Gebruik van codenormen
Het kernteam van Alumio heeft een softwareontwikkelingsproces gedefinieerd om ervoor te zorgen dat Alumio schaalbaar en betrouwbaar blijft en 100% beschikbaar is. De SDLC is het proces dat wordt gevolgd voor elk Alumio software(component)project. Elk project bestaat uit een gedetailleerd plan dat beschrijft hoe specifieke software wordt ontwikkeld, onderhouden, vervangen en gewijzigd of verbeterd. Deze methodologie verzekert de kwaliteit van het Alumio integratieplatform.
Alumio ontwikkelt en verbetert zijn toepassingen door gebruik te maken van goede software-development lifecycle (SDLC) praktijken zoals:
Identificeren van kwetsbaarheden van externe bronnen om veranderingen en codeverbetering te stimuleren.
Veilige authenticatie en logboekmogelijkheden.
Het verwijderen van ontwikkelaccounts, ID's en wachtwoorden uit productieomgevingen.
Strikte veranderingsbeheerpraktijken naleven voor zowel code-updates als patches.
Test- en ontwikkelomgevingen scheiden van productie.
Handhaving van de scheiding van taken tussen ontwikkelings- en ondersteunend personeel.
Ervoor zorgen dat persoonlijk identificeerbare informatie (PII) niet wordt gebruikt in testomgevingen.
Test- en ontwikkelings-ID's verwijderen voordat code naar productie wordt gemigreerd.
Inbreng en goedkeuring van senior ontwikkelaars voor alle codewijzigingen.
Functionaliteit en regressietests afronden voordat ze worden vrijgegeven voor productie.
Een prestatietest uitvoeren voor elke codecomponent.
Back-outprocedures onderhouden om hoge beschikbaarheid en integriteit te behouden.
Beoordeling van kwetsbaarheden bij elke release.
Jaarlijkse penetratietests uitvoeren.
Regelmatige codebeoordelingen uitvoeren.
Documenteren van codewijzigingen.
Controleren op veiligheidslekken zoals voorgeschreven door het Open Web Application Security Project (OWASP), zoals injectiefouten, bufferoverflows, cryptografische fouten, foutafhandeling, enz.
Het toepassen van hardware- en softwarepatches, waarbijAlumio verantwoordelijk is voor codewijzigingen en Amazon Web Services (AWS) verantwoordelijk is voor het leveren van hardwarepatches; onze virtuele omgeving stelt ons in staat om wijzigingen toe te passen zonder enige downtime.
Het volgen van veilige codeerpraktijken volgens een SDLC-beleid en het voorzien in de behoefte aan beveiligingstraining voor het ontwikkelteam.
De bedrijfsresultaten van de Alumio architectuur & beveiliging
Een next-gen integratieplatform voor snelle, flexibele en toekomstbestendige integraties
Nu we de architectuur, het beveiligingsontwerp, de schaalbare infrastructuur en de prestatievoordelen Alumio diepgaand hebben onderzocht, vatten we samen hoe dit alles samenkomt om de kracht te vormen van wat het Alumio integratieplatform biedt. Hier zijn enkele van de belangrijkste business use cases en voordelen die het Alumio iPaaS (integration Platform as a Service) moet bieden:
1. Volledige zichtbaarheid van integratie
Alle gegevensstromen van geïntegreerde systemen worden zichtbaar en toegankelijk gemaakt op een gebruikersvriendelijke interface, waardoor black box problemen worden voorkomen en eenvoudige configuraties mogelijk zijn.
Zorg ervoor dat gegevens in realtime worden gesynchroniseerd en verwerkt, transformeer gegevens flexibel en maak gebruik van datamapping en -routering om dubbel werk te verminderen en de nauwkeurigheid te verbeteren.
3. Geautomatiseerde foutdetectie
Een robuust monitoring- en loggingsysteem helpt bij het snel opsporen en melden van integratiefouten en API-conflicten, waardoor kosten en tijd worden bespaard bij het oplossen van problemen.
4. Automatisering van bedrijfsprocessen
Verminder handmatig werk en gegevensinvoer door processen te automatiseren zoals productoptimalisatie, werving, facturering & facturatie, voorraadbeheer, marketing, klantenondersteuning en meer.
5. legacy systems en gegevens migreren
Verplaats en verenig gegevens uit legacy systems met ETL, migreer aangepaste velden en aangepaste objecten en implementeer vooraf geconfigureerde connectors om legacy systems integreren met cloud-apps.
6. Een schaalbaar IT bouwen
Organiseer alle integraties en gegevens vanaf één intuïtief dashboard. Voeg op een flexibele manier software-integraties toe of vervang ze. Ontgrendel datasilo's en verhoog de platformresources naarmate uw integraties groeien.
7. Alle B2B-gegevens verbinden
Verbind de gegevens en systemen van alle partners, leveranciers en klanten met behulp van standaard aangepaste protocollen en formaten zoals JSON, Edifact, X12, CSV, XML, cXML.
8. Inzichten in gegevens creëren voor BI, ML & AI
Creëer datameren of verzamel gewoon alle gegevens van verschillende verbonden systemen om een hyperlerende, "digital-first en datagestuurde" onderneming te worden.
9. Gegevensbeveiliging en bedrijfscontinuïteit
Voorkom systeemuitval en zorg voor bedrijfscontinuïteit met cachingmogelijkheden, gegevensbuffering en reactiveringsprocedures voor je integraties en IT .
10. Naleving van de privacy
Centraliseer al je gegevens en verbonden systemen op één veilige cloudruimte, krijg volledige gegevenscontrole en voldoe aan belangrijke privacywetgeving zoals GDPR, SOC2, CCPA, FERPA, HIPAA en meer.