Uw cyberbeveiliging optimaliseren - Hoe belangrijk is IT-architectuur?

Uw cyberbeveiliging optimaliseren - Hoe belangrijk is IT-architectuur?

In de sterk verbonden wereld van vandaag is het zeldzaam dat een enkel platform, systeem of apparaat alles doet. In dit moderne landschap leven we echter in een bloeiend ecosysteem van "best-in-class" applicaties waarvan wordt verwacht dat ze gegevens delen en overal, altijd en op elk apparaat toegankelijk zijn. De alomtegenwoordige eisen aan de huidige bedrijfssystemen en de noodzaak om "het nu te hebben" hebben beveiliging en architectuur naar hun breekpunten geduwd. Architectuur wordt vaak over het hoofd gezien als een cruciaal onderdeel van de algehele beveiligingspositie, gericht op het bereiken van schijnbaar onmogelijke tijdlijnen. Of het valt ten prooi aan compromissen over tijd of kosten.

In de begindagen van IT-ontwikkeling was het noodzakelijk om bestaande leidingen te gebruiken om informatie tussen systemen te leveren. EDI-achtige drop-bestanden kwamen veel voor via "Omnibus" -communicatiepaden zoals een FTP-server of netwerkbestandslocatie. Hoewel deze paden eenvoudig en snel in te stellen waren, creëerden ze paden, niet alleen voor uw gegevens, maar ook voor slechte actoren om te gebruiken om kwaadaardige code te verspreiden.

Een kleine verbetering kwam van SQL-naar-SQL-verbindingen waardoor databases rechtstreeks verbinding konden maken en informatie konden delen. Helaas was dit soort "Omnibus" -verbinding ook gemakkelijk voor kwaadwillenden om kwaadaardige paden naar uw gegevens en systemen te misbruiken en te manifesteren.

Dageraad van RESTful API's

Ongeveer 22 jaar geleden vond een wetenschapper genaamd Roy Fielding RESTful API's uit, en sinds die vonk van intuïtie hebben we niet meer achterom gekeken. Je kunt een API zien als een bemiddelaar tussen de gebruikers of klanten en de resources of webservices die ze willen krijgen. Het is ook een manier voor een organisatie om bronnen en informatie te delen met behoud van beveiliging, controle en verificatie, om te bepalen wie toegang krijgt tot wat. Nu heeft het enige tijd geduurd om de impact van deze standaard in de technologische ruimte te begrijpen. Alles wat dicht bij de "wolk" lag, was in wezen nog steeds iets dat leefde in de verbeelding van "futuristen". Maar in de wereld van vandaag is deze technologie noodzakelijk geworden.

Zoals elke technologie kunt u deze onveilig ontwerpen, dus er is zorg nodig om REST API's te ontwikkelen op basis van beveiligingsprincipes. Dit is waar architectuur een belangrijke rol speelt. Architectuur stelt best practices vast en biedt een forum voor de samenleving om betere normen te leren en te ontwikkelen naarmate slechte actoren tegenmaatregelen en steeds fantasierijkere manieren ontwikkelen om uw goed doordachte architectuur te doorbreken. Tegenwoordig is de "Purpose Built" -architectuur een pijler van beveiliging die de tand des tijds heeft doorstaan.

Door integratiepaden tussen systemen te ontwikkelen die specifiek en doelgericht zijn, zorgt u ervoor dat ze niet kunnen worden gebruikt voor kwaadwillende bedoelingen.

Omnibusverbindingen moeten koste wat het kost worden vermeden. Als u van plan bent om klantinformatie te delen, dan is dat alles wat mogelijk moet zijn door die integratie. Een pad dat het klantnummer kan delen via een file-drop stelt u in staat om "bestanden te delen".  Een bestand kan uitvoerbaar zijn en worden gebruikt om andere systemen aan te vallen. Maar met een REST API kunt u een opzettelijke verbinding delen die alleen een 8-cijferig klantnummer kan delen, als dat alles is wat nodig is. Het enige kwaadaardige misbruik van dit pad zou zijn om betekenisloze stromen van 8-cijferige nummers te delen. Waardoor het onmogelijk is om andere systemen aan te vallen.

Principe van het minste privilege

Het delen van de minimale hoeveelheid gegevens en het sterk beperken van de interface of integratie tot de specifieke bedrijfsparameters creëert een bijna ondoordringbare barrière voor misbruik. Ervoor zorgen dat de API alleen toegankelijk is via HTTPS (Secure Encrypted Connection) en afdwingbare governance heeft bij gebruik, voltooit de beveiligingsdriehoek (zie onderstaand diagram over Principle of Least Privilege, waarin staat dat een onderwerp alleen die bevoegdheden mag krijgen die nodig zijn om zijn taak te voltooien. Verder moet de functie van het onderwerp (in tegenstelling tot zijn identiteit) de toewijzing van rechten bepalen.*). 

Als het niet nodig is om een API-eindpunt meer dan één keer per dag uit te voeren, beperk het gebruik ervan dan tot één keer per dag. Dit voorkomt DDOS-aanvallen of soortgelijke acties die middelen verspillen. Probeer niet "Vooruit te plannen" en meer gegevens te verstrekken dan nodig is. Wees specifiek over uw integraties en geef alleen door wat nodig is. Dit zorgt ervoor dat de verzonden gegevens bedrijfswaarde hebben en dat redundante gegevens niet kunnen worden misbruikt als onbedoelde blootstelling optreedt. Onderneem stappen om de integratie te beveiligen en de toegang tot het beoogde gebruik te beperken via IP-beveiliging, whitelisting, gecodeerde certificaten, autorisatietokens of vergelijkbaar toegangsbeheer.

Speciaal gebouwde integratiepunten en Architecture by Design-principes vereisen dat elke verbinding en elk datapunt bedrijfswaarde en doel heeft. Het samenstellen van een best-in-class bedrijfsoplossing volgens deze eenvoudige richtlijnen definieert het risiconiveau waarop u zich bevindt en geeft u een solide basis om te beschermen met behulp van in de branche bewezen maatregelen.

De architectuurervaring in AMCS

Een cruciale eerste stap van AMCS om het AMCS-platform voor onze klanten in te zetten, is het ontwerpen van de Global Architecture AS-IS- en TO-BE-diagrammen. Deze diagrammen schetsen nauwkeurig de reis van de klant van hun huidige architectuur naar hun uiteindelijke architectuur met het AMCS SaaS Cloud Platform. Zoals bij elke enterprise-oplossing zijn integraties een noodzaak voor succes en positieve bedrijfsresultaten. Gemeenschappelijke integratietrajecten van het AMCS-platform omvatten interfaces met boekhoud- en grootboeksystemen. De meeste klanten verwachten een standaardsjabloon, een kant-en-klare connector die in staat is om met hun boekhoudsysteem te praten. Hoewel dit in principe beschikbaar is, ondergaat elke implementatie een afzonderlijke architectuurbeoordeling waardoor we onze connector kunnen configureren om te voldoen aan de vereisten van de beveiligingsdriehoek. We zorgen ervoor dat alleen noodzakelijke informatie wordt opgenomen in de integratie, deze is beperkt tot geautoriseerde systemen en personeel en is alleen uitvoerbaar voor zover nodig. Elk integratiepunt ondergaat dezelfde architectuurbeoordeling om ervoor te zorgen dat de wereldwijde architectuur voor onze klanten doelgericht is gebouwd en potentiële risico's beperkt.

Kortom, de voordelen van het optimaliseren van uw cyberbeveiliging door middel van een verbeterd architectonisch ontwerp zijn verreikend: het verminderen van uw beveiligingsrisicoprofiel - de verspreiding van malware en cyberaanvallen; het stimuleren van betere compliance en gedrag in de hele organisatie, het ondersteunen van een hogere gebruikersproductiviteit en betere gegevensbeveiliging en auditclassificatie.

Lees voor meer informatie over AMCS en onze benadering van cloudarchitectuur en -beveiliging deze relevante blogs:

• AMCS Security Infographic door Brian Hayden, AMCS VP Information Systems
• IT Security Checklist for Waste and Recycling Companies door Carlos Silva, AMCS IT Principal Security Engineer
• Is de cloud veilig? door Brian Hayden, AMCS VP Information Systems
• API Accelerator Program – Hoe AMCS Platform een onderling verbonden ecosysteem mogelijk maakt door Evan Schwartz, AMCS Chief Enterprise Architect
• Beveiligingsbedreigingen groeien door Brian Hayden, AMCS VP Information Systems

*Referentie link