Hoe u robuuste beveiligingsmaatregelen bouwt om uw servers te beschermen

Inleiding

Wanneer u aan cloudinfrastructuur werkt, is uw primaire zorg ervoor te zorgen dat uw applicaties volledig operationeel zijn. Een belangrijk onderdeel van uw installatie- en implementatieproces is het inbouwen van effectieve, grondige en robuuste beveiligingsmaatregelen in uw apps of systemen voordat ze aan het publiek worden aangeboden. In plaats van achteraf beveiligingsmaatregelen te implementeren na de implementatie, is het belangrijk om ervoor te zorgen dat er een veilige basisconfiguratie in uw infrastructuur is ingebouwd.

Deze handleiding zal u hierbij helpen. Het zal bepaalde praktische beveiligingsmaatregelen belichten die kunnen worden geïmplementeerd terwijl de infrastructuur van uw server wordt opgezet en geconfigureerd. Hoewel dit geen uitputtende lijst van serverbeveiligingsprotocollen is, is het een nuttig startpunt. Naarmate u werkt met en een beter begrip krijgt van de specifieke behoeften van uw omgeving en applicaties, kunt u aanvullende beveiligingsmaatregelen ontwikkelen om op uw basis voort te bouwen.

SSH (Secure Shell)-sleutels

Terwijl u met uw server werkt, zult u het overgrote deel van uw tijd besteden aan het werken in een SSH-verbinding met uw server in een terminal-sessie. Security shell (SSH)-sleutels bieden een veiligere inlogmethode voor de server dan inlogs die afhankelijk zijn van wachtwoorden. Voor authenticatiedoeleinden worden, met het gebruik van SSH-sleutels, twee toegangssleutels voorbereid. De eerste is een geheime (privé)sleutel, terwijl de andere een deelbare, openbare sleutel is.

De SSH-sleutelauthenticatie moet eerst worden geconfigureerd. Dit wordt bereikt door de openbare SSH-sleutel in de juiste map op de server op te slaan. Wanneer uw client in eerste instantie verbinding maakt met de server, wordt u gevraagd om bewijs van bezit van de privésleutel. Dit gebeurt door het genereren van een willekeurige waarde die vervolgens naar uw SSH-client wordt verzonden. De SSH-client zal op zijn beurt de privésleutel gebruiken bij de versleuteling van een antwoord. Dit antwoord wordt naar de server verzonden. Vervolgens zal de server het bericht van de client ontsleutelen met behulp van uw openbare sleutel. Als de willekeurige waarde door de server wordt ontsleuteld, geeft dit aan dat de client de privésleutel heeft. In dat geval is de authenticatie bevestigd en kan er een verbinding met de server zonder wachtwoord tot stand worden gebracht.

Beveiliging verbeteren met SSH-sleutels

Hoewel wachtwoordautorisatie of elke authenticatie met SSH volledig is versleuteld, kunnen kwaadwillende gebruikers proberen toegang te krijgen tot de server. Vooral als ze in het bezit zijn gekomen van het openbare IP-adres van de server. Door elke mogelijke sleutelcombinatie te proberen, maakt moderne computertechnologie inloggen op basis van wachtwoorden mogelijk en dit wordt vaak geprobeerd door kwaadwillende gebruikers. Als men deze toegangspogingen zou automatiseren, is het mogelijk om door systematisch verschillende combinaties te proberen uiteindelijk toegang te krijgen tot het juiste wachtwoord.

Door gebruik te maken van met SSH versleutelde authenticatie, is het niet nodig om wachtwoorden in te schakelen om in te loggen. SSH-sleutels bevatten doorgaans een aanzienlijk aantal mogelijke combinaties die door een aanvaller zouden moeten worden uitgeprobeerd. Het toegenomen aantal bits vermenigvuldigt het potentieel voor verschillende combinaties die nodig zijn om de versleuteling te kraken. Het doorlopen van zoveel mogelijk combinaties van het SSH-sleutelalgoritme zou daarom enorm tijdrovend zijn. Hierdoor wordt het een onderneming die de tijd van een kwaadwillende aanvaller niet waard is. Dit is de reden waarom SSH-versleuteling doorgaans als 'onkraakbaar' wordt beschouwd.

SSH-sleutels implementeren

Inloggen op een externe Linux-server moet SSH-sleutels gebruiken. Een lokale machine kan aan de kant van de lokale machine worden gegenereerd, waarbij de openbare sleutel binnen enkele minuten naar de server wordt overgedragen. Met deze handleiding krijgt u een basisidee over hoe u SSH gebruikt om verbinding te maken met een externe server in Ubuntu.  U kunt ook onze diepgaande handleiding volgen over hoe u uw Linux-server configureert om op SSH-sleutels gebaseerde authenticatie te gebruiken.

Over het algemeen is het niet toestaan dat de root-gebruiker rechtstreeks inlogt via SSH een veelgebruikte best practice, terwijl inloggen als een onbevoorrechte gebruiker en het gebruik van een tool zoals sudo om privileges te escaleren indien nodig de voorkeur heeft. Dit staat bekend als het principe van de minste privileges: een methode om toegangsrechten te beperken. Zodra het inloggen met een onbevoorrecht account is geverifieerd met SSH, kunnen root-logins worden uitgeschakeld door de richtlijn PermitRootLogin no in te stellen in /etc/ssh/sshd_config op uw server. Vervolgens kan de server opnieuw worden opgestart met een SSH-procescommando sudo systemctl restart sshd.

Firewalls

Software (of een hardwareapparaat) die de blootstelling van diensten aan het netwerk reguleert, staat bekend als een firewall. Een optimaal geconfigureerde firewall zorgt ervoor dat alleen toegestane diensten openbaar beschikbaar zijn en in en uit de specifieke server worden toegelaten.

Er kunnen standaard verschillende diensten op een server draaien en deze kunnen in de volgende groepen worden ingedeeld:

• Interne diensten: Deze mogen alleen intern vanaf de server zelf worden benaderd. Dit voorkomt blootstelling van de diensten aan openbaar beschikbare internettoegang (bijv. een database die alleen via lokale verbindingen bereikbaar is).
• Openbare diensten: Diensten die door iedereen, vaak anoniem, op internet kunnen worden bezocht. Dit omvat webservers die ervoor zorgen dat uw site door bezoekers kan worden bezocht.
• Privédiensten: Alleen geautoriseerde accounts vanaf een exclusieve set locaties hebben toegang tot deze diensten (bijv. phpMyAdmin database-controlepaneel).

Hoewel openbare diensten beschikbaar kunnen blijven voor toegang vanaf het internet, kunnen privédiensten worden beperkt op basis van toegangsparameters (zoals verbindingstypen), en worden interne diensten volledig afgesloten van elke op internet gebaseerde toegang. De toegang tot deze diensten, samen met de granulariteit waarmee dit is toegestaan, wordt allemaal beheerd door de firewall. Ongebruikte poorten worden doorgaans zo geconfigureerd dat de toegang ertoe volledig wordt geblokkeerd.

Beveiligingsverbetering met firewallgebruik

Een firewall is een basislijn voor serverbeveiliging. Het dient om verbindingen van en naar diensten te beperken voordat de applicatie het verkeer afhandelt. Uiteraard kunt u aanvullende beveiligingsfuncties voor uw diensten implementeren en deze beperken tot de gewenste interfaces.

Alleen de diensten waarvan u kiest dat ze open blijven, worden niet beperkt door een correct geconfigureerde firewall. Dit beperkt de elementen die kwetsbaar zijn voor misbruik, aangezien de beschikbare softwareonderdelen veel beperkter zijn en daardoor minder snel een aanval zullen ervaren.

Firewalls implementeren

Er zijn veel firewalls beschikbaar voor Linux-systemen. Sommige hiervan zijn vrij complex. De typische installatie van een firewall hoeft echter alleen te worden uitgevoerd op het moment van de initiële installatie van de server wanneer wijzigingen in de diensten van de server worden doorgevoerd. Dit zou slechts een paar minuten van uw tijd moeten kosten. Hieronder volgen enkele opties die u kunt overwegen om de firewall in te stellen en te activeren:

• Voor CentOS kunt u onze handleiding Een firewall instellen met FirewallD op CentOS 7 volgen.
• Onze Iptables-handleiding kan u loodsen door het weergeven en verwijderen van Iptables-firewallregels.

Het belangrijkste is, ongeacht de handleiding, dat u ervoor zorgt dat de gekozen firewall onbekend verkeer van uw servers blokkeert om te voorkomen dat nieuw beschikbare diensten onbedoeld op internet worden blootgesteld. Door expliciet toegang te moeten autoriseren, wordt u gevraagd om volledig te evalueren hoe een dienst wordt benaderd, uitgevoerd en door wie deze mag worden benaderd.

Virtual Private Cloud (VPC)-netwerken

De resources van uw infrastructuur’s moeten functioneren binnen een privénetwerk dat bekend staat als de VPC. Deze netwerken zijn veiliger omdat ze toegang vanaf andere cloudgebaseerde VPC-netwerken voorkomen. Hierdoor maken ze de interfaces van het netwerk ontoegankelijk vanaf het openbare internet.

Beveiliging verbeteren met VPC-netwerken

Privénetwerken hebben de voorkeur boven de openbare tegenhanger voor interne communicatie. VPC maakt de isolatie van brongroepen in specifieke privénetwerken mogelijk. Omdat VPC-netwerken alleen via privéverbindingen communiceren, is het verkeer van het netwerk beschermd tegen blootstelling aan het openbare internet, waar die informatie kwetsbaar zou kunnen zijn voor onderschepping of blootstelling. VPC-netwerken kunnen ook worden gebruikt om uitvoeringsomgevingen en tenants te isoleren. Internetgateways kunnen ook worden ingesteld als een enkel toegangspunt tussen het openbare internet en de bronnen op uw VPC-netwerk.

Daarnaast bestaat een groot deel van de beveiliging uit het analyseren van onze systemen en het zo goed mogelijk beveiligen van alle componenten. Service-auditing stelt ons in staat om de acceptabele protocollen van de systemen, de actieve services en de poorten die voor communicatie worden gebruikt te kennen. Het kennen van deze informatie kan helpen bij het nemen van de beste beslissingen met betrekking tot de configuratie. Dergelijke beslissingen kunnen firewallinstellingen, systeemmonitoring en -waarschuwingen zijn, en welke services openbaar toegankelijk moeten zijn.

Auditing benutten om de beveiliging te verbeteren

Elke service kan worden gebruikt voor het afhandelen van externe clients of voor interne doeleinden. Ongeacht de bedoeling zijn deze services allemaal kwetsbaarheidspunten voor kwaadwillende gebruikers. Naarmate het aantal actieve services toeneemt, neemt ook het potentieel voor misbruik van kwetsbaarheden toe.

U kunt beginnen met het analyseren van services zodra u een goed beeld hebt van welke services op een machine draaien. Bij het uitvoeren van een service-audit is het nuttig om de volgende vragen te stellen:

• Moet de specifieke service actief draaien?
• Draait het op de optimale netwerkinterfaces?
• Is de service het meest geschikt voor een openbare of een privé-netwerkinterface?
• Zijn de firewallregels correct geconfigureerd om legitiem verkeer naar deze service toe te staan?
• Wordt ongewenst verkeer geblokkeerd met mijn firewallregels?
• Is er een waarschuwingssysteem voor beveiligingskwetsbaarheden ingeschakeld?

Bij het toevoegen van een nieuwe server aan de infrastructuur moeten de bovenstaande punten standaardpraktijken zijn in het configuratieproces. Een bijkomend voordeel van service-audits is dat hiermee eventuele onbedoeld gewijzigde configuraties kunnen worden geïdentificeerd.

Service-audits uitvoeren

Om de actieve services te auditen, gebruikt u het ss-commando om een lijst weer te geven van alle UDP- en TCP-poorten die actief worden gebruikt op een server. Hier is een voorbeeld van het gebruik van het ss-commando met een programmanaam PID, waarbij wordt gecontroleerd op luisterende TCP- en UDP-poorten:

Er zal iets vergelijkbaars met het volgende worden geretourneerd:

Uw belangrijkste focus moet liggen op de kolommen Netid, Local Address:Port en Process:

• Als de waarde van Local Address:Port 0.0.0.0 is, betekent dit dat de service actief alle verbindingen accepteert via alle IPv4-netwerkinterfaces. Als het adres [::] is, accepteren alle IPv6-verbindingen verkeer.
• In het bovenstaande voorbeeld luisteren zowel Nginx als SSH op alle openbare interfaces op beide netwerkstacks (IPv4 en IPv6).

Met het bovenstaande voorbeeld kunt u kiezen of u SSH en Nginx op beide interfaces wilt laten luisteren, of slechts op één van beide. Over het algemeen wilt u ongebruikte services uitschakelen om te voorkomen dat ze draaien. Als uw site bijvoorbeeld alleen via IPv4 bereikbaar hoeft te zijn, helpt het om de IPv6-interfaces uit te schakelen om de blootstelling te beperken.

Up-to-date blijven met onbeheerde updates

Onbeheerde updates verminderen de inspanning die nodig is om uw servers veilig te houden en helpen de tijd dat ze blootgesteld blijven aan bekende bugs te verkorten. Hoe langer het duurt voordat u updates op uw server uitvoert, hoe langer deze blootgesteld blijft aan bekende kwetsbaarheden. Onbeheerde updates zorgen ervoor dat zodra er herstelpakketten beschikbaar zijn, deze automatisch op de server kunnen worden geïnstalleerd om de duur van de kwetsbaarheid te beperken.

Naast server-auditing kunnen onbeheerde updates de blootstelling aan aanvallen aanzienlijk verminderen. Ze zullen ook de tijd die aan serveronderhoud wordt besteed aanzienlijk verminderen.

Hoe onbeheerde updates worden geactiveerd

Onbeheerde updates zijn nu een optionele functie op de meeste serverdistributies. Op Ubuntu kan de beheerder bijvoorbeeld de volgende opdracht uitvoeren:

Voor meer informatie over het implementeren van onbeheerde updates, bekijk de sectie Automatische updates hier. Voor Fedora zijn de instructies hier te vinden. Houd er rekening mee dat de automatische updates alleen de software installeren die in eerste instantie via het pakketbeheersysteem van uw systeem is geïnstalleerd. Eventuele aanvullende applicaties, zoals webgebaseerde applicaties, moeten handmatig apart op updates worden gecontroleerd of afzonderlijk worden geconfigureerd voor automatische updates.

Directory-indexen

Wanneer een directory geen indexbestand heeft, zijn de meeste servers standaard geconfigureerd om directory-indexen weer te geven. Met andere woorden, als er een directory genaamd 'downloads' op uw webserver is gemaakt, kan iedereen die door die directory bladert alle bestanden erin zien. Hoewel dit niet altijd een beveiligingsrisico is, maakt het vertrouwelijke informatie wel zichtbaar voor onbevoegden. Denk bijvoorbeeld aan het feit dat uw webserver een bestand kan bevatten met de inloggegevens voor de startpagina van uw website en een bestand met alle configuraties voor de back-end van de database van de site. Als directory-indexen niet zijn uitgeschakeld, zijn deze bestanden zichtbaar voor iedereen die door die directory bladert.

Beveiliging verhogen door het uitschakelen van directory-indexen

Hoewel directory-indexen nuttig zijn, kunnen ze bestanden onbedoeld blootstellen. Om dergelijke onbedoelde blootstelling en de bijbehorende risico's te beperken, moeten de directory-indexen op de server standaard worden uitgeschakeld. Hoewel de bestanden nog steeds door bezoekers kunnen worden bereikt, wordt de blootstelling aan onbedoelde gegevensweergave aanzienlijk beperkt.

Directory-indexen uitschakelen

In de meeste gevallen is het toevoegen van slechts één extra regel aan de configuratie van uw webserver voldoende om directory-indexen uit te schakelen.

• Volg deze stappen om deze directory-lijsten uit te schakelen op de Apache Wiki. Zorg ervoor dat Options -Indexes worden vermeld in de configuratieblokken van de Apache Directory.
• Indexen zijn standaard uitgeschakeld op Nginx, dus in dit opzicht is geen verdere actie vereist.

Regelmatige back-ups

Hoewel back-ups geen beveiligingsmaatregel zijn, zijn ze absoluut noodzakelijk voor het veiligstellen van gegevens en volledige systemen in het geval dat het systeem wordt gecompromitteerd. Het helpt ook om te analyseren hoe het systeem onder vuur kan zijn komen te liggen. Denk aan een ongelukkig scenario waarin uw systeem wordt aangevallen door ransomware (een virus of malwaretool die de bestanden op uw systeem versleutelt en ze pas ontsleutelt als u de hacker geld betaalt). Als er geen back-ups van gegevens zijn, is uw enige keuze om het geld te betalen om weer toegang te krijgen tot uw gegevens. Als er veilig back-ups van gegevens zijn gemaakt, hebt u er nog steeds toegang toe en kunt u de gegevens herstellen zonder dat u toegang hoeft te krijgen tot het gecompromitteerde systeem.

Beveiligingsverbetering door regelmatige back-ups

Regelmatige back-ups helpen om informatie terug te krijgen na een aanval, corruptie of zelfs onbedoeld verlies (verwijdering). Ongeacht welk type negatieve gebeurtenis tot gegevensverlies leidt, het risico wordt verkleind door het bewaren van kopieën van servergegevens.

Naast ransomware-aanvallen kunnen regelmatige back-ups helpen bij het meetbare onderzoek naar langdurige systeemaanvallen. Als u uw gegevens niet veilig opslaat in de vorm van een back-up, kan het bepalen van de bron van de aanval en welke gegevens zijn gecompromitteerd een uitdaging of zelfs onmogelijk zijn.

Regelmatige back-ups implementeren

Het beschouwen van het verifieerbare herstel van corrupte, gecompromitteerde of verwijderde gegevens als het doel van uw herstelinspanningen bij het maken van back-ups van uw systemen is van cruciaal belang. Om het zo goed mogelijk te formuleren: bedenk welke acties de minste hoeveelheid werk zouden vereisen om u weer up and running te krijgen als uw server morgen zou verdwijnen.

Hier zijn enkele andere punten om te overwegen bij het nadenken over een disaster recovery-plan:

• Als u met dynamisch veranderende gegevens werkt, moeten uw back-ups waarschijnlijk frequenter zijn. In het geval van gegevensverlies, als uw laatste back-up te lang geleden is, kunt u gedwongen worden om terug te vallen op verouderde gegevens.
• Denk na over het daadwerkelijke herstelproces van de back-up. Moet er een nieuwe server voor worden toegevoegd of kan de bestaande worden hersteld?
• Wat is de langste periode dat de server niet operationeel kan zijn?
• Is een offsite back-up een noodzakelijke oplossing?

Voor meer informatie over de Disaster Recovery-oplossingen van CloudSigma kunt u onze blogpost bekijken met details over waarom onze Disaster-Recovery-as-a-Service de perfecte metgezel is voor de cloud. En hier kunt u meer informatie vinden over de beveiligings- & bedrijfscontinuïteitsfuncties van CloudSigma. We hebben ook een gedetailleerde handleiding over hoe u eenvoudig de back-upfunctionaliteit van CloudSigma instelt.

Privénetwerken en VPN's

Een privénetwerk is een netwerk dat alleen beschikbaar is voor toegang en gebruik door specifieke gebruikers of servers. Een veilige verbinding tussen externe apparaten waarmee de verbinding kan functioneren alsof deze zich in een privénetwerk bevindt, is een VPN (een virtueel privénetwerk). Het biedt u de mogelijkheid om verbindingen in een privénetwerk te beveiligen en externe servers te verbinden.

Hoe verbeteren privénetwerken de beveiliging?

Wanneer er een keuze is tussen het gebruik van openbare versus privénetwerken for interne communicatie, heeft de laatste altijd de voorkeur. Houd er echter rekening mee dat andere gebruikers binnen het datacenter nog steeds toegang hebben tot hetzelfde netwerk. Dat betekent dat er nog steeds aanvullende beveiligingsmaatregelen moeten worden toegepast om ervoor te zorgen dat de communicatie tussen servers veilig is.

In wezen is het gebruik van een VPN een methode om af te bakenen wat de werknemers van uw organisatie kunnen zien. Correspondentie is volledig veilig en privé. Applicatieconfiguraties zouden toestaan dat virtueel interfaceverkeer via de VPN wordt geleid. Hierdoor worden alleen die diensten die bedoeld zijn voor interactie met klanten via internet blootgesteld aan een openbaar netwerk.

Hoe moeilijk is het om een VPN te implementeren?

Het gebruik van privénetwerken is voor uw datacenter net zo eenvoudig als het configureren van uw applicaties en firewall om een privénetwerk te gebruiken en het inschakelen van de VPN tijdens de creatie van uw server. Het is belangrijk om te onthouden dat andere servers dezelfde netwerkruimte delen als datacenter-brede privénetwerken.

De initiële installatie van een VPN is iets complexer. De extra beveiliging die dit biedt is echter de moeite waard voor de meeste use cases. De configuratiegegevens en gedeelde beveiliging moeten op elke server in het netwerk worden geïnstalleerd en geconfigureerd. Voor meer diepgaande informatie over hoe een VPN werkt en een overzicht van het instellen van OpenVPN op Ubuntu volgt u deze handleiding. U kunt ook deze handleiding volgen die u door de stappen leidt om een VPN-netwerk te verbinden met de infrastructuur van CloudSigma.

SSL/TLS-versleuteling en Public Key Infrastructure

Het genereren, beheren en valideren van certificaten om individuen te identificeren en communicatie te versleutelen, wordt Public Key Infrastructure (PKI) genoemd. Verschillende entiteiten kunnen bij elkaar worden geverifieerd met het gebruik van SSL of TLS-certificaten. Daarna kunnen ze ook worden gebruikt voor het opzetten van versleutelde communicatie.

Hoe certificaten de beveiliging verbeteren

Om verkeer te versleutelen en de identiteit van leden op een server te valideren, is het essentieel om een certificeringsinstantie (CA) op te zetten en alle certificaten van uw netwerk te kunnen inzien. Dit kan 'man-in-the-middle'-aanvallen helpen voorkomen, waarbij de server wordt geïmiteerd door een hacker en het verkeer wordt omgeleid.

De configuratie van elke server kan zo worden ingesteld dat ze een gecentraliseerde CA vertrouwen. Eventuele daaropvolgende certificaathandtekeningen kunnen dan impliciet worden vertrouwd. Als SSL/TLS-versleuteling wordt ondersteund door de protocollen en apps die uw server gebruikt, kunt u uw systeem beveiligen zonder de overhead van een VPN-tunnel. Volg voor meer informatie onze handleiding over het automatiseren van LetsEncrypt SSL-certificaatverlengingen voor Nginx.

Moeilijkheidsgraad van implementatie

Het configureren van een certificaatautoriteit en het vervolgens opzetten van de resterende PKI kan in het begin veel inspanning vergen. Bovendien is er extra administratieve inspanning vereist wanneer er nieuwe certificaten moeten worden aangemaakt, ingetrokken of ondertekend.

Omdat de meeste infrastructuren moeten groeien, is het implementeren van een volwaardige PKO de meest verstandige aanpak. Totdat u een punt bereikt waarop PKI de extra administratiekosten waard is, kan het gebruik van een VPN om de componenten van het systeem te beveiligen dienen als een adequate tussenoplossing.

Systeeminbraak detecteren en bestandscontrole gebruiken

Bestandscontrole is een proces dat wordt gebruikt om de bestanden en hun kenmerken van uw systeem in een volledig veilige, goede staat te vergelijken met die van uw huidige systeem. Dit is een goede methode om ongeoorloofde systeemwijzigingen te vinden en te isoleren.

Een IDS, intrusion detection system, verwijst naar bewakingssoftware die alle ongeoorloofde activiteiten op het systeem in de gaten houdt. Over het algemeen maakt het gebruik van bestandscontrolemethoden om te zoeken naar onverwachte systeemwijzigingen.

Beveiligingsverbetering door IDS/bestandscontrole

Naast audits op serviceniveau is het uitvoeren van audits op bestandsniveau essentieel om de beveiliging van uw systeem te garanderen. Dit kan worden gedaan door een geautomatiseerd IDS-proces of periodiek worden uitgevoerd door de systeembeheerder.

Bestandsaudits en IDS zijn de enige echte processen om er zeker van te zijn dat het systeem geen onvoorziene wijzigingen heeft ondergaan. De meeste indringers willen servers die ze binnendringen gedurende langere tijd misbruiken, en om dat te doen, moeten ze ervoor zorgen dat hun acties onopgemerkt blijven. Ze zouden binaire bestanden kunnen vervangen door kwetsbare of gecompromitteerde versies. Alle bestanden die in het systeem zijn gewijzigd, worden gedetecteerd door een audit van het bestandssysteem. Dit geeft u de geruststelling dat u zeer snel weet of de integriteit van het systeem is aangetast.

Moeilijkheidsgraad van implementatie

De implementatie van IDS en bestandscontrole kan een zeer intensief proces zijn. In het begin moet het systeem worden geconfigureerd om uit te sluiten paden te definiëren en niet-standaard wijzigingen vast te leggen die aan het systeem zijn aangebracht, om zo een nulmeting van het systeem te maken.

De dagelijkse werkzaamheden worden ook omslachtiger, omdat procedures het systeem opnieuw moeten controleren voordat er updates worden uitgevoerd. De nulmeting van de systeemmetingen moet ook opnieuw worden gemaakt of vastgesteld om wijzigingen in softwareversies op te nemen als onderdeel van de nieuwe nulmeting van het systeem. De auditrapporten moeten ook naar een andere locatie worden overgebracht. Dat’s omdat u moet voorkomen dat een systeeminbreker de audit wijzigt om verborgen te blijven door zijn sporen uit te wissen.

Hoewel dit de administratieve belasting van uw systeem zeker verhoogt, is het een van de weinige trefzekere manieren om te garanderen dat er geen bestanden buiten uw medeweten zijn gewijzigd. Enkele van de meest populaire inbraakdetectie- en bestandscontrolesystemen zijn Aide en Tripwire.

Geïsoleerde omgevingen

Elke methode waarbij individuele componenten in hun eigen dedicated ruimte worden uitgevoerd, wordt aangeduid als geïsoleerde uitvoeringsomgevingen.

Dit kan betekenen dat specifieke applicatiecomponenten op hun eigen dedicated servers worden ondergebracht, of dat uw diensten zo zijn geconfigureerd dat ze in chroot-omgevingen (of containers) werken. Hoe geïsoleerd de omgeving is, hangt grotendeels af van de realiteit van uw infrastructuur en de vereisten van uw applicatie.

Beveiliging verbeteren met geïsoleerde omgevingen

Door uw processen in afzonderlijke omgevingen te isoleren, isoleert u ook welke processen kunnen worden beïnvloed door beveiligingslekken. Net zoals compartimenten en schotten helpen om scheepsbreuken te beperken, zorgt het scheiden van de afzonderlijke onderdelen en componenten van uw systeem ervoor dat als een indringer toegang krijgt tot een daarvan, hij niet het hele onderling verbonden netwerksysteem kan bereiken.

Moeilijkheidsgraad van implementatie

De complexiteit van het isoleren van uw applicaties varieert afhankelijk van de containment-types die u besluit te gebruiken. Docker beschouwt isolatie niet als een beveiligingsfunctie. Wanneer uw componenten echter over verschillende containers zijn verdeeld, wordt de isolatie veel gemakkelijker bereikt. U kunt deze handleiding volgen om Docker op onze infrastructuur te installeren.

Wanneer chroot-omgevingen worden opgezet, wordt er ook een zekere mate van isolatie geboden. Dit is echter geen volledig ondoordringbare methode, aangezien er manieren zijn om uit een dergelijke omgeving te ontsnappen. Dedicated machines voor verschillende componenten zijn doorgaans de beste en eenvoudigste manier om isolatie te bereiken. Het is echter kostbaarder vanwege de noodzaak van extra machines.

Laatste overwegingen

De geboden strategieën zijn slechts enkele van de stappen die u kunt nemen om de beveiliging van uw systeem te verbeteren. Het is vermeldenswaard dat hoe langer u wacht met het implementeren van de beveiligingsfuncties, hoe lager de effectiviteit ervan wordt. Met dat in gedachten is het belangrijk om ervoor te zorgen dat er niet met beveiliging wordt gewacht. In plaats daarvan moet het worden geïmplementeerd als een van de eerste voorzieningen bij het bouwen van de infrastructuur. Zodra uw systeem voldoende is beveiligd met basisbescherming, kunt u beginnen met het activeren van services en het toevoegen van applicaties, wetende dat ze standaard in een veilige omgeving worden uitgevoerd.

Beveiliging is echter geen statisch proces, maar een fluïde proces. Het moet worden bijgehouden en herhaald. Het moet worden benaderd met een mentaliteit van constante alertheid en aanhoudende waakzaamheid. Vraag u altijd af wat de gevolgen voor de beveiliging zijn van eventuele systeemwijzigingen.  Zorg ervoor dat besturingsomgevingen en standaardconfiguraties de beveiliging altijd optimaliseren en werken met voldoende defensieve software.

Veel computerplezier!