Intro

Door projecten bij Dojo4 te begeleiden, ben ik vaak verrast door de manier waarop schijnbaar kleine toenames in technische complexiteit samenvallen in significante aandacht en middelenverlies. Daarom kiezen we, wanneer projecten opstarten, vaak voor een vereenvoudigd hosting en applicatiestack die veel eigenschappen deelt die vaak worden gezien in gedeelde hostingservices. Dit omvat keuzes zoals het hosten van de app en db samen, het gebruiken van een enkele implementatiegebruiker op het hostsysteem, en eenvoudige uptimemonitoring.

Onze langjarige klant, Inspire Commerce, ontwikkelde onlangs een nieuw bedrijfsplan dat vereist dat hun applicatie voldoet aan de strenge Payment Card Industry (PCI) Level 1 beveiligingseisen voor het verwerken, verzenden en opslaan van creditcardinformatie. Veel van de beveiligingseisen die in detail staan in de PCI Data Security Standard (DSS) motiveren een significante verandering in denken van de gestroomlijnde gefocuste stack die hierboven wordt genoemd. Deze post zal enkele van deze details opsommen en onze oplossingen uitleggen.

De PCI DSS is verdeeld in 12 secties die alles bestrijken van firewallconfiguratie tot personeelsbeveiligingsbeleid. Ik zal een aantal secties doorlopen die relevant zijn voor de hostingstack.

1. Installeer en onderhoud een firewallconfiguratie om kaarthoudersgegevens te beschermen

Dit is een gedetailleerde sectie van de DSS die de installatie en configuratie van firewall services vereist op alle netwerkapparaten, van werkstations tot routers tot servers. Door Amazon Web Services (AWS) Elastic Compute Cloud (EC2) als basis van onze hostingstack te gebruiken, worden veel van deze netwerkapparaten geabstraheerd van ons zicht of controle. Handig genoeg, AWS is zelf PCI Level 1 conform en laat veel van deze details aan de ingenieurs van Amazon.

Echter, firewalls voor de EC2-knooppunten vereisen wel enige overweging. EC2-knooppunten worden beschermd door een firewall die is geïmplementeerd op de hypervizor laag en geconfigureerd door AWS Security Groups. Onze basis Security Group heeft alle poorten die pakketten weigeren met uitzondering van 22, 80, & 443 die accepteren van alle bronnen. We draaien Ubuntu Linux op onze knooppunten en standaard hebben we de IP Tables firewall geconfigureerd met een open beleid.

De PCI DSS richt zich op het gebruik van firewalls om veilige privénetwerken of De-Militarized-Zones (DMZ) te creëren voor systemen die apps hosten die betalingskaartgegevens verwerken. AWS Security Groups bieden een nuttig mechanisme voor het creëren van veilige privénetwerken tussen de diverse componenten van de applicatiestack. Bijvoorbeeld, door een WEB-beveiligingsgroep en een DB-beveiligingsgroep te creëren en de databasepoort in de DB-beveiligingsgroep te openen alleen voor WEB-beveiligingsgroepbronnen, zal de EC2-hypervisor firewall die op een databaseserver draait alleen toegang tot de database toestaan van webservers die verbinding maken op de interne privénetwerkinterface.

Voor redundantie, spiegelen we de AWS Security Group-configuratie voor de EC2-hypervisor firewall met de CloudPassage service die de IP Tables firewall kan beheren op het besturingssysteemlaag van systemen die componenten van de kaartverwerkingsapplicatie hosten. CloudPassage organiseert firewallbeleidsregels in Server Groups die enigszins analogisch zijn aan AWS Security Groups. Een andere geweldige functie van CloudPassage is de GhostPorts service. We configureren het ssh-poortbeleid in CloudPassage om verbindingen te accepteren van GhostPort-bronnen. Om een clientmachine een GhostPort-bron te laten worden, moet een gebruiker op die machine zich authenticeren bij het CloudPassage-portaal, geautoriseerd zijn om GhostPorts te openen voor een servergroep, en zich authenticeren met een geregistreerde Yubikey-dongle, of reageren op een SMS-uitdaging met een geregistreerde mobiele telefoon. Bij succesvolle authenticatie en autorisatie configureert CloudPassage IP Tables om verbindingen te accepteren van de bron-ip van de clientmachine. Dit is een handige, veilige, tijdelijke en controleerbare manier om toegang tot gevoelige hosts te beheren.

2. Gebruik nooit standaardinstellingen van de leverancier voor systeemwachtwoorden en andere beveiligingsparameters

Deze sectie lijkt vrij duidelijk. Een goed voorbeeld van het belang van het wijzigen van door de leverancier geleverde standaardwachtwoorden is het Splunk Universele Forwarder standaardwachtwoord changeme.

Echter, verborgen in deze sectie is een belangrijke hostingvereiste die enigszins niet gerelateerd is aan de sectietitel. “2.2.1 Implementeer slechts één primaire functie per server om te voorkomen dat functies die verschillende beveiligingsniveaus vereisen samen bestaan op dezelfde server. (Bijvoorbeeld moeten webservers, databaseservers en DNS op aparte servers worden geïmplementeerd)”.

Zoals hierboven vermeld, maken AWS-beveiligingsgroepen de taak om services zoals web- en databaseservers veilig te scheiden op aparte hosts vrij eenvoudig.

5. Gebruik en werk regelmatig antivirussoftware of programma's bij

ClamAV maakt snel werk van deze eis op Ubuntu Linux.

8. Wijs een unieke id toe aan elke persoon met computertoegang

Het doel van deze sectie is om controleerbaarheid en verantwoordelijkheid te bevorderen door gedeelde gebruikersaccounts te verwijderen. Aangezien we een sleutelgebaseerd authenticatiemechanisme gebruiken voor secure shell toegang, zijn er drie primaire zorgen om te weten wie wat heeft gedaan. Ten eerste is het noodzakelijk om te voorkomen dat gebruikers kunnen overschakelen naar een andere gebruikersaccount met de su-opdracht. Dit is eenvoudig te realiseren door de uitvoertoestemming op het su-binair bestand te verwijderen en /etc/pam.d te wijzigen om alle su-autorisatie te voorkomen. Ten tweede, zorg ervoor dat de authorized_keys bestanden voor alle gebruikersaccounts slechts één enkele invoer bevatten. Ten slotte, zorg ervoor dat alle sleutels die worden gebruikt voor secure shell toegang worden beveiligd met een wachtwoord en dat er een beleid is om het delen van sleutels tussen gebruikers te verbieden.

Nu kan de Linux Audit Daemon (AuditD) worden gebruikt om systeemactiviteit te traceren naar specifieke gebruikers.

9. Beperk fysieke toegang tot kaarthoudersgegevens

De titel van deze sectie is vrij zelfverklarend. In wezen, behandelt deze sectie de onderwerpen van het beperken van fysieke toegang tot datacenters tot geautoriseerd personeel. Vergelijkbaar met de bespreking van de firewallconfiguratie van netwerkapparaten hierboven, wordt dit bedekt door de AWS PCI Level 1-certificering en kunnen de details aan Amazon worden overgelaten.

10. volg en bewaak alle toegang tot netwerkbronnen en kaarthoudersgegevens

De motivatie van deze sectie is “het voorkomen, detecteren of minimaliseren van de impact van een datalek”. Dit betekent onderwerpen als logboekregistratie, bestandsintegriteitsbeheer en intrusiedetectie. Onze strategie begint met de inzet van een logboekregistratieservice om de aggregatie van logboeken, de bewaarperiode van logboeken, evenals het doorzoeken van logboekrecords te ondersteunen. We gebruiken de Splunk applicatie voor deze functionaliteit. We hebben een EC2-instantie ingesteld voor een logboekserver en Splunk geïnstalleerd. We hebben AWS Security Groups en CloudPassage ServerGroups ingesteld voor de nieuwe server die de Splunk-listenerpoort accepteert verbindingen van webserver- en db-serverbronnen op de privénetwerkinterface. Vervolgens hebben we de Splunk Universele Forwarder op web- en db-servers ingesteld en de forwarders geconfigureerd om applicatie-, apache-, mongodb-, sys-, audit- en auth-logboeken te bewaken.

Voor bestandsintegriteitsbewaking en intrusiedetectie hebben we de OSSEC applicatie geïnstalleerd op al onze servers en alle logboeken die OSSEC schrijft aan de Splunk forwarders toegevoegd.