Het eerste voor de hand liggende voordeel is dat als iemand de doos breekt waarin uw applicatieserver zich bevindt, ze niet gegarandeerd toegang hebben tot dezelfde server die de database bevat. Door deze functionaliteit te scheiden, maakt u het ook gemakkelijker voor de IT (softwareontwikkelaars, beheerders, enz.) Om de impact van codewijzigingen / beleidsupdates op verschillende aspecten van de omgeving te minimaliseren. Dit lost op geen enkele manier slechte codering of zwakke beveiliging op (SQL-injectie, standaard gebruikersnaam / wachtwoorden). maar het zorgt in het algemeen voor een betere beveiligingshouding.

• Een internetgerichte webserver heeft geen enkele reden om enige toegang te hebben tot het LAN / domein, en daarom zou het volledig verboden moeten worden om dit te doen. Idealiter zou het op een DMZ moeten staan.

  • Dit biedt aanzienlijke bescherming tegen een aanvaller die de op internet gerichte webserver 'bezit' heeft en de rest van uw netwerk aanvalt.
  • U kunt er natuurlijk zoveel van hebben als u nodig heeft voor HA (hoge beschikbaarheid), DR (disaster recovery) en prestatieredenen.
  • Medium: met strikte regels voor de WAN / DMZ-grens en volledig verbod op "Naar LAN" DMZ / LAN-verkeer, en strikte regels voor "Naar DMZ" DMZ / LAN-verkeer of iets dergelijks.
  • Geavanceerd: een "buitenste" DMZ met strikte regels voor zowel het WAN / OuterDMZ en OuterDMZ / InnerDMZ-grenzen, of iets dergelijks.

• Een intern gerichte webservicehost heeft waarschijnlijk beperkte toegang tot het LAN / domein nodig (voornamelijk tot uw database (s )

  • Als het geen authenticatie van het domeintype voor de database gebruikt, hoeft het nog steeds niet op het domein te staan ​​
  • U kunt er zoveel hebben als u nodig heeft , uiteraard voor HA (hoge beschikbaarheid), DR (disaster recovery) en prestatierea zonen. Als je echt goede wachtwoordhashing (PBKDF2, bcrypt, scrypt) gebruikt met hoge iteratietellingen, heb je hier meer verwerking en / of RAM nodig.
  • Hoewel dit een beter platform is om je LAN mee aan te vallen dan de internetgerichte webserver (tenzij ze dezelfde box zijn, of erger nog, dezelfde site), zou deze nog steeds zeer beperkte toegang moeten hebben - tot de databasebox alleen via een databasepoort, de mogelijkheid om antivirusupdates op te halen en antiviruswaarschuwingen te pushen , etc.
  • Basis: dit is dezelfde OS-instantie die de internetgerichte webserver host, of iets dergelijks.
  • Medium: dit is ook op de DMZ met volledige bescherming van inkomend verkeer van de WAM, en strikte regels voor zowel de uitgaande naar WAN WAN / DMZ-grens, als strikte regels voor de DMZ / LAN-grenzen, of iets dergelijks.
  • Geavanceerd: dit is op een "innerlijke" DMZ met strikte regels voor zowel de OuterDMZ / InnerDMZ- als de InnerDMZ / LAN-grenzen of iets dergelijks.

• A databaseserver bevindt zich waarschijnlijk op uw LAN, waardoor het een veel waardevoller doelwit wordt voor een aanvaller; er moet waarschijnlijk een back-up van worden gemaakt, het moet worden geopend door een verscheidenheid aan programma's naast het web, enzovoort.

  • Zoals altijd komt SQL Injection rechtstreeks van internet naar uw database; parametriseer uw SQL!
  • Het hebben van meerdere goed gedefinieerde, minimale machtigingslagen tussen deze en andere servers op uw LAN en internet, met een goed ontwerp en goede implementatie, helpt de hoeveelheid inspanning die nodig is om de database aan te vallen te vergroten server, veel minder slagen bij de aanval.

In wezen:

• Internet -> Website + services + DB betekent dat met één compromis van het besturingssysteem de aanvaller alles kan controleren, inclusief het exfiltreren of direct vernietigen van al uw gegevens in de database (of back-ups) - u hoeft hiervoor niet via de webinterface te gaan.

• Internet -> Website + services -> DB betekent dat de aanvaller uw database moet binnendringen via het sleutelgat van uw webservices, of dat hij meer dan één machine moet compromitteren die slechts enkele gedeelde beveiligingslekken heeft.

• Internet -> Website -> Webservices -> DB is nog beter - de aanvaller moet uw database binnendringen via het sleutelgat van uw webservices, zoals te zien is n door het sleutelgat van uw website, of u moet meer dan één (of twee!) machine (s) compromitteren die enkele maar niet alle gedeelde veiligheidslekken hebben.

Het spreekt voor zich dat u op elk niveau zo veilig moet zijn als u mag zijn - up-to-date patches en antivirusprogramma's, geparametriseerde SQL om SQL-injectie te voorkomen, vermeldingen op de witte lijst, lange cryptografisch willekeurige wachtwoorden, gecodeerde gegevens, gecodeerd verbindingen, sterk gehashte wachtwoorden (PBKDF2, bcrypt, scrypt), goede algoritme-keuzes voor codering en hashing, alleen de minimale poorten open tussen elke laag, logboeken controleren op sporen van aanvallen, IDS / IPS-software / -applicaties, enzovoort, enzovoort .

Het vergt wat planning of wat spel (of beide).

Welnu, door de webserver van de databaseserver te scheiden, kan een gebruiker, als hij de webtoepassing kan exploiteren en zijn eigen privileges verhogen, met uw gegevens knoeien, maar alleen zoveel als het beveiligingsmodel op de databaseserver hem toestaat . Hoewel ze bijvoorbeeld klantgegevens kunnen lezen en schrijven - als ze kunnen reverse-engineeren hoe de web-app het doet - kunnen ze de hele database niet in bulk downloaden of volledig verwijderen, of deze corrumperen / compromitteren / anderszins degraderen door de schema. Bovendien kunnen applicatiespecifieke firewalls en IDS-systemen van de nieuwe generatie die zijn ontworpen om uw databaseserver te beschermen, ongebruikelijke toegang detecteren en blokkeren op basis van bekende aanvalshandtekeningen en heuristieken, waardoor uw gegevens worden beschermd tegen gecompromitteerde clienttoegang.

Dit komt in reeeeeal handig als de databaseserver een aantal webservers voedt.