Es ist wie: "Stellen Sie die Schmuckschatulle vor das Haus, damit sich Räuber nicht um den Fernseher kümmern?"

Ja, genau so ist es.

Wenn Sie sich relativ gesehen nicht um den Wert der Datenbank kümmern, ist es sicher sinnvoll, sie draußen zu lassen - wenn die Annahme besteht, dass die Anwendung schrecklich unsicher ist, Sie sie aber stellen müssen Wenn Sie es aus irgendeinem Grund trotzdem nicht sichern möchten, ist dies sinnvoll, um dieses schreckliche unsichere System von allen anderen internen Systemen zu isolieren.

Andererseits gibt es wirklich keine Entschuldigung dafür, eine solche unsichere Anwendung zu erwarten, die eine vollständige Übernahme des Datenbankservers ermöglicht. Es gibt auch keinen wirklichen Grund, "Belichtung" als Alternative zu "Isolation" zu verwenden - es gibt einfache Lösungen, um dies auch richtig zu machen.

Wenn es darauf ankommt, klingt dies wie eine von zwei möglichen Situationen:

1. Diese sogenannten "Experten" sind wirklich ahnungslos.
2. Es gibt andere Geschäftsanforderungen, die hier abgewogen werden.
ol>

Ich denke, Ihre Analogie funktioniert perfekt. Wenn sie Ihnen dann das Äquivalent von "Eigentlich sind diese Schmuckstücke gefälscht, oh und übrigens, der Fernseher ist wirklich ein 60" 5K Custom Job mit Goldfelgen "sagen, dann könnte das ein vernünftiger Kompromiss sein (noch besser, es richtig zu machen ).
Andernfalls ist es wahrscheinlich nicht möglich, dies zu erklären, da sie aufgrund mangelnden Wissens arbeiten.

SANS '"Machen Sie Ihr Netzwerk sicher für Datenbanken" ( http://www.sans.org/reading-room/whitepapers/application/making-network-safe-databases-24) lautet In einigen Abschnitten etwas veraltet, bietet aber eine anständige Anleitung für "Dummies" in die Richtung, nach der Sie suchen.

Sie könnten sich auch erschöpfen, wenn Sie im Ressourcenzentrum des US NIST stöbern ( http://csrc.nist.gov/). Ich denke, ISO ISO / IEC 27033-2: 2012 wäre ebenfalls ein Thema, habe aber sicher keine Kopie zur Hand.

Sie versuchen, die sensibelsten Server (die Datenbankserver) von den am stärksten gefährdeten (und daher anfälligen) Servern zu trennen / zu isolieren.

Sie schlagen eine "Tiefenverteidigung" vor "Ansatz, der darauf abzielt, a) Angriffe nach Möglichkeit zu verhindern und b) ihren Fortschritt (und den Zugang zu wichtigen Dingen) zu verzögern, wenn dies nicht der Fall ist.

Im Idealfall ist immer alles gehärtet und gepatcht, Server warten nur auf den Datenverkehr an den erforderlichen Ports und nur von zulässigen Geräten aus ist der gesamte Datenverkehr "im Flug" für nicht autorisierte Listener nicht zugänglich (durch Verschlüsselung und / oder Isolation). und alles wird auf Eindringen und Integrität überwacht.

Wenn all das mit 100% iger Sicherheit vorhanden ist, dann hat Ihre "Opposition" Punkt a) oben angesprochen, so viel wie möglich . Toller Start, aber was ist mit Punkt b)?

Wenn ein Webserver kompromittiert wird, befindet sich Ihre vorgeschlagene Architektur an einem viel besseren Ort. Ihr potenzieller Angriffsfußabdruck und Vektor ist viel größer als nötig.

Die Begründung für die Trennung von Datenbank und Webservern unterscheidet sich nicht von der Begründung für die Trennung von Webservern vom LAN. Noch klarer: Wenn sie so überzeugt sind, dass ein kompromittierter Webserver keine Gefahr für andere Systeme in derselben Sicherheitszone darstellt, warum denken sie dann, dass überhaupt eine DMZ erforderlich ist?

Es ist furchtbar frustrierend, in Ihrer Situation zu sein. Zumindest würde ich in Ihrer Position ein Risikomemo erstellen, in dem Ihre Bedenken und Vorschläge dargelegt werden, und sicherstellen, dass sie dies anerkennen. CYA jedenfalls.

Wenn die Datenbank Kartendetails enthält, kann sehr leicht argumentiert werden, dass Sie die PCI-DSS-Anforderung für einen angemessenen Schutz nicht erfüllen.

Außerdem werden die Überprüfungen der einzelnen Fehlerquellen und der Schutz Ihrer Kernressourcen nicht bestanden.

Wenn die Daten Milliarden wert sind, warum sollten Sie nicht ein paar Tausend mehr für das Hinzufügen ausgeben? Schutzschichten? In der Industrie empfiehlt es sich, mehrschichtige Sicherheitszonen zu haben.

Sie können sie auf PCI, den Good Practice Guide von ISF und viele andere verweisen.

Wenn Sie vorschlagen, dass der Datenbankserver von derselben Sicherheitszone wie der Webserver in dieselbe Sicherheitszone wie einige interne Systeme verschoben wird, kann man vernünftigerweise den Schluss ziehen, dass Sie die Sicherheit verringern.

Wenn der Status Quo lautet, dass sich sowohl der Webserver als auch der Datenbankserver in der DMZ befinden und keine Verbindungen von der DMZ zum internen Netzwerk zulässig sind, müssen für das Verschieben des Datenbankservers von der DMZ zum internen Netzwerk Verbindungen von der DMZ zum internen Netzwerk zugelassen werden . Dies würde bedeuten, dass Sie die Sicherheit des internen Netzwerks verringern, ohne einen wesentlich besseren Schutz für die Datenbank zu erhalten.

Wenn Sie wirklich glauben, dass die Datenbank sensibler ist als das interne Netzwerk (was durchaus zutreffen kann) Dann möchten Sie keine Kompromisse im internen Netzwerk eingehen, um direkten Zugriff auf die Datenbank zu erhalten.

Sie müssen also darauf hinweisen, dass Sie den Datenbankserver nicht von einer Sicherheit verschieben möchten Zone zu einer anderen, stattdessen möchten Sie eine völlig neue Sicherheitszone erstellen. Um dies wirklich umzusetzen, müssten Sie tatsächlich eine zusätzliche Firewall kaufen und diese zwischen die DMZ und das extra gesicherte Netzwerk stellen.

Dann läuft es darauf hinaus, die Kosten für den Kauf und die Wartung dieser zusätzlichen Firewall zu bewerten die zusätzliche Sicherheit, die es bietet.

AvID hat die Hauptfrage bereits behandelt, aber wenn Sie dies aus einem etwas anderen Blickwinkel betrachten, unterstützen die meisten Firewalls mehrere Schnittstellen und können die Steuerung des Datenverkehrs zwischen den Schnittstellen ermöglichen.

Konfigurieren der mehreren Schnittstellen zum Hosten der einzelnen Schnittstellen Die Aspekte der Lösung (Frontend, Middleware, Backend) würden das Risiko einer weiteren Gefährdung der Datenbank durch den Webserver verringern, ohne dass mehrere physische Firewalls erforderlich wären (wenn die anderen Teams sich darüber Sorgen machen ... sind dies Kosten? Problem?) und ohne eine Route zum internen Netzwerk einzuführen.

Ich frage mich nur, ob dies Ihnen einen praktischen „Hebel“ geben würde, um das Argument für die Implementierung einer Trennung zu unterstützen, dh es bringt etwas anderes in die Diskussion, dass sie Müssen Sie dagegen vorgehen?

Wenn dies nicht der Fall ist, was ist mit einem Was-wäre-wenn-Szenario, das auf einer historischen Sicherheitsanfälligkeit auf einem Webserver basiert und zu einer weiteren Gefährdung aller anderen Server im selben Netzwerksegment (einschließlich der Datenbank) geführt hätte ase) und wie eine geschichtete DMZ den weiteren Kompromiss verhindern würde, vermutlich würde es monetäre Kosten geben, so dass es „einfach“ wäre, den Kosten-Aufwand-Nutzen zu veranschaulichen?

Angenommen, Sie versuchen, sie davon zu überzeugen, anstatt sie (notwendigerweise) davon zu überzeugen, dass es richtig ist:

Erklären Sie, dass ihre großen Kunden und potenziellen Kunden eine Sicherheitsüberprüfung durchführen werden scheitern.

Wenn das Hindernis das Geschäft ist, ist dies der einzig ausreichende und nur notwendige Grund.

Ein gutes Argument ist, dass die Messlatte für die Trennung von Webservern und Datenbankservern in separate DMZs wirklich nicht so hoch ist.

Verwenden Sie einen echten Router / eine echte Firewall und setzen Sie die Webserver und Datenbankserver ein in separaten VLANs, beide außerhalb des internen sicheren LAN, mit Firewall-Regeln, die den Zugriff auf die minimal erforderlichen Ports vom Internet zu den Webservern, von den Webservern zu den Datenbankservern und überhaupt keinen Zugriff aus dem Web steuern Server auf das sichere LAN.

Die Firewall würde auch jeglichen direkten Zugriff aus dem Internet auf die Datenbankserver verhindern und den Zugriff von den Datenbankservern nach innen auf das sichere LAN streng kontrollieren (zu Authentifizierungszwecken oder was auch immer).

Auf diese Weise kann der Angreifer nicht einmal direkt in das Netzwerk mit den Datenbankservern gelangen.

Wenn er auf einem Ihrer Webserver einen Brückenkopf bekommt, wird er Sie befinden sich immer noch nicht im selben Netzwerk mit uneingeschränktem Zugriff, um Ihre Datenbankserver anzugreifen, und wenn Wenn Sie über eine Protokollüberwachung verfügen, sollten Sie Benachrichtigungen über die Verletzung der Webserver erhalten, bevor die Angreifer viel Zeit hatten, um etwas anderes anzugreifen.

Selbst wenn sie es dann schaffen, Ihre Datenbankserver danach zu verletzen Einige Zeit über den einen offenen Port, über den der Webserver mit der Datenbank kommunizieren kann, haben sie die ganze Zeit damit verschwendet, relativ wenig zu erreichen. Während dieser Zeit waren Sie sich ihres Angriffs bewusst, anstatt all das auszugeben Zeit, um in Ihr sicheres LAN zu gelangen.

Sie können das LAN nicht einmal von der DMZ aus erreichen, in der sich die Webserver befinden. Daher besteht ihr einziger Weg in das LAN in irgendeiner Form darin, auf die Datenbankserver zu springen , geschützt in der anderen DMZ. Möglicherweise sind oder werden Ihre Datenbankserver an eine Art Unternehmensauthentifizierungssystem (Active Directory oder was auch immer) gebunden. Möchten Sie diese Funktion in derselben DMZ wie Ihre öffentlichen Webserver?

Wenn ich mir genug Sorgen um Sicherheitsprobleme machen kann, um Gast- und DMZ-Subnetze in meinem Zuhause zu erstellen, um einen Ort zu haben, an dem "Dinge" ("Internet der Dinge") abgelegt werden können, ohne sie direkt zu haben In meinem LAN kann sich ein milliardenschweres Unternehmen mit Sicherheit den Mindshare und die Zeit leisten, um dasselbe mit wichtigen Webservern und Datenbankservern zu tun. Ich mache das im Büro mit einer Kombination aus einem Stapel von Procurve-verwalteten L2 / L3-Switches für mehrere tausend Dollar, einem SonicWall UTM und einem Ubiquiti EdgeMax-Router. Zu zu Hause habe ich einen Ubiquiti EdgeRouter Lite für 100 US-Dollar, einen verwalteten 8-Port-HP-Switch für 100 US-Dollar und einen Ubiquiti Unifi-AP, der mehrere VLANs unterstützt, und mein Setup ist absolut in der Lage, das zu tun, worüber wir sprechen

Und ich kann mir keine Sorgen machen, dass mein netzwerkverbundener DVR, Drucker, Blu-Ray-Player, Thermostat und was auch immer mit wem die wer-weiß-was-Buggy-Firmware läuft - weiß, welche unentdeckten Exploits gehackt werden und über das Netzwerk auf meinen Computer und meine persönlichen Dateien zugreifen können.

Für Sicherheitsexperten ist es nicht besonders schwierig, solche Dinge zu konfigurieren, und das ist sicherlich nicht der Fall Es muss keine separate physische Hardware für jede Firewall erforderlich sein. SDN (Software Defined Networking) ist heutzutage der letzte Schrei, oder?

Selbst der EdgeRouter Lite für 100 US-Dollar kann fast 1 Gbit / s über den Router weiterleiten und unterstützt mehrere virtuelle Schnittstellen und Firewall-Regeln zwischen all diesen Schnittstellen

Eine winzige Box ist wirklich ein ganzer Korb voller Firewalls.

Wenn Sie also echtes Geld für einen High-End-Router ausgeben, erhalten Sie all diese Funktionen und einige mehr mit einer besseren Routing-Leistung.

Selbst so etwas wie der Ubiquiti EdgeRouter Pro 8 bietet Ihnen 2 Millionen Pakete pro Sekunde für nur 375 US-Dollar mit 8 physischen Schnittstellen und VLAN-Subschnittstellen auf jeder dieser Schnittstellen, falls erforderlich. Wenn Sie eine höhere Leistung benötigen, wenden Sie sich an Brocade (Vyatta), Cisco, Juniper usw., um größere Hardware zu erhalten. Oder so etwas wie die SuperMassive-Serie von Dell / Sonicwall. Oder führen Sie den virtuellen Vyatta-Router auf einem leistungsstarken Multi-Core-Xeon-Server aus.

Ich versuche nicht, Router zu verkaufen, sondern nur darauf hinzuweisen, dass die Messlatte nicht so hoch ist, um diese Art von Router zu erhalten Sicherheitstrennung, die Sie wahrscheinlich hier haben sollten und offensichtlich wollen.

Teilen Sie Ihrem direkten Vorgesetzten mit, dass Sie nicht berechtigt sind, dieses Risiko im Namen des Unternehmens zu übernehmen. Weisen Sie darauf hin, dass der Wert der Daten in der Datenbank $ xxx beträgt und dass dieser Grad der Risikoakzeptanz von jemandem stammen muss, der dazu berechtigt ist, und bitten Sie ihn, sich dafür einzusetzen, dass ein Mitglied der Geschäftsleitung die Risikoakzeptanz unterzeichnet.

Um den Wert der Daten zu schätzen, bestimmen Sie, ob es sich um Daten handelt, die an PCI DSS gebunden sind (wenn ja, sehen Sie sich die Kosten pro Kunde an, die Target / Home Depot bei Umsatzverlusten, Kreditüberwachung und Betrug) oder wenn es sich um personenbezogene Daten handelt (wenn ja, prüfen Sie den finanziellen Schaden pro Patient, den die medizinischen Systeme durch Vertrauensverlust, Überwachung von Identitätsdiebstahl und Reputationsverlust erlitten haben) oder wenn es sich um einen Wettbewerbsvorteil Ihres Unternehmens handelt (Geschäftsgeheimnisse, noch nicht freigegebene Finanzdaten, geistiges Eigentum), dann könnte der Wert der Daten die aktuelle Bewertung des Unternehmens sein.

Wenn Sie den direkten Auftrag erhalten, das Risiko im Namen des Unternehmens zu übernehmen, werden Sie möglicherweise gebeten, als leitender Angestellter des Unternehmens zu handeln, und als solcher haben Sie eine Verpflichtung (möglicherweise a rechtliche Verpflichtung) darauf hinzuweisen, dass Sie eine nicht ernannte Person sind, die gebeten wird, als eine Person aufzutreten, und dies die Verwaltungskette dem Verwaltungsrat des Unternehmens mitzuteilen. Seien Sie auf einen erheblichen Rückschlag vorbereitet und geben Sie erhebliches politisches Kapital aus, um dies bekannt zu machen.

Viel Glück!