Dies ist der zweite Beitrag in einer Reihe darüber, wie wir die Sicherheit bei PagerDuty managen. Um von Anfang an dabei zu sein, schau dir Folgendes an: Wie wir die Sicherheit von PagerDuty für unsere Kunden gewährleisten Die

Hohe Verfügbarkeit und Zuverlässigkeit sind bei PagerDuty von größter Bedeutung. Wir haben enorm viel Zeit in die Konzeption und Architektur unseres Dienstes investiert, um Ausfälle auf Servern, in Rechenzentren, Regionen, bei Providern, externen Abhängigkeiten und vielen anderen Faktoren zu überstehen. Doch wie lässt sich Fehlertoleranz in unser Sicherheitssystem integrieren, wenn Ausfälle unvermeidbar sind?

Zwei Dinge sind zu beachten: Erstens birgt dedizierte Netzwerk- oder Sicherheitshardware das Problem von Single Points of Failure. Fällt beispielsweise ein VPN-Gerät aus, kann dies ein ganzes Rechenzentrum lahmlegen. Zweitens: In einem Sicherheitsmodell, das nur den Netzwerkrand schützt, erhält ein Angreifer, der diese einzelne Schicht durchdringen kann, Zugriff auf das gesamte Netzwerk.

Um diese Probleme zu vermeiden, haben wir uns für die zentrale Verwaltung unserer Sicherheitsrichtlinien und deren Durchsetzung an alle Knotenpunkte entschieden. Jeder Knotenpunkt ist dafür verantwortlich, die Richtliniendefinitionen abzurufen sowie ein maßgeschneidertes Regelwerk abzuleiten und durchzusetzen.

Dynamisch berechnete lokale Firewalls

Die erste Strategie, die wir in unserem zentralisierten Management-/dezentralen Durchsetzungsmodell implementiert haben, waren unsere dynamischen Firewalls.

Wir haben PagerDuty in den letzten zwei Jahren auf eine serviceorientierte Architektur (SOA) umgestellt. Dadurch können wir die einzelnen Dienste besser isolieren und laterale Angriffe eindämmen. Wenn wir in Chef einen neuen Servercluster definieren, richten wir auch die Firewall-Regeln ein. Diese legen fest, zu welcher Gruppe der Server gehört und welche Gruppen mit ihm kommunizieren dürfen. So kann jeder Server automatisch vollständige IPTables-Ketten erstellen, Service-Ports für die entsprechenden Quellen öffnen und den übrigen Datenverkehr blockieren. Das bedeutet, dass wir bei jedem Hinzufügen oder Entfernen eines Servers keine Richtlinien aktualisieren müssen. Die Knoten erkennen die Änderung und berechnen die Regeln automatisch neu.

Wir haben durch diesen Ansatz eine Reihe von Vorteilen festgestellt:

• Wir können bei Bedarf problemlos Netzwerkpartitionen erstellen. (So stellen wir sicher, dass unsere Entwicklungs-, Test- und Produktionsumgebungen nicht miteinander kommunizieren können.)

• Wir können einzelne Server isolieren, wenn wir Angriffe auf diese üben müssen.

• Wir können leicht herausfinden, welche Server miteinander kommunizieren, da alle eingehenden Regeln im Voraus definiert werden müssen.

• Wir verwenden einfache und unkomplizierte Linux IPTables. Bei Firewall-Problemen weiß jeder Techniker, wie er die Firewall anpassen und eine Lösung implementieren kann.

• Es gibt kein Netzwerkgerät, das einen zentralen Ausfallpunkt darstellt. Sollte ein einzelner Server ausfallen oder ein schwerwiegenderes Problem auftreten, arbeitet das restliche System weiterhin sicher.

Verteilte Datenverschlüsselung

Für die Verschlüsselung des Netzwerkverkehrs gibt es zwei vorherrschende Methoden, die am häufigsten verwendet werden: Virtuelle private Netzwerke (VPN) und die Verschlüsselung pro Anwendung/Dienst. Wir haben jedoch bei beiden Methoden Probleme festgestellt.

Eine typische VPN-Implementierung mit dedizierten Gateways in jeder unserer AWS- und Linode-Regionen hätte eine Reihe von Problemen mit sich gebracht:

• Nahezu ein einziger Ausfallpunkt. Selbst wenn Sie in jeder Region mehrere Gateways einsetzen, führt der Ausfall eines Gateway-Servers entweder zu einem Failover oder zu einer Kapazitätsreduzierung. Dies hat Verbindungsprobleme zur Folge.

• Kosten und Skalierbarkeit. Da wir Standard-VMs und keine dedizierte Netzwerkhardware verwenden, wären sehr große Instanzgrößen erforderlich, um den Datenverkehr für die dahinterliegenden Server zu verschlüsseln und zu entschlüsseln. Wir waren besorgt, ob herkömmliche VPN-Gateways mit unseren Datenverkehrsspitzen zurechtkommen würden.

• Latenz. Da bereits regionsübergreifende Anrufe getätigt werden, möchten wir bei der Verbindung zu nicht-lokalen Servern so wenige Zwischenstationen wie möglich.

Anwendungs- bzw. dienstspezifische Verschlüsselungsmethoden – wie beispielsweise die Erzwingung von SSL-Verbindungen in MySQL oder die Sicherstellung der internen Knotenverschlüsselung in Cassandra – haben durchaus ihren Platz in unserem Sicherheitsframework. Die alleinige Verwendung dieses Ansatzes birgt jedoch Probleme:

• Das vergisst man leicht. Obwohl Sicherheit zum Aufgabenbereich jedes Mitarbeiters in einem Unternehmen gehört, vergessen viele, die entsprechenden Sicherheitseinstellungen zu aktivieren.

• Jede Anwendung/jeder Dienst verschlüsselt Daten auf etwas andere Weise. Obwohl die meisten Verbindungsbibliotheken SSL unterstützen, kann die Implementierung variieren. Das bedeutet, dass wir bei jedem neuen Dienst die Verschlüsselung neu überdenken müssen.

Um die oben genannten Probleme zu lösen, implementierten wir ein Punkt-zu-Punkt-Verschlüsselungsmodell auf Basis von IPSec im Transportmodus. Dadurch wird der gesamte Datenverkehr zwischen festgelegten Knoten im Netzwerk verschlüsselt, unabhängig vom Standort des Knotens und den anderen Knoten, mit denen er kommuniziert. Auch hier folgten wir unserer Vorgehensweise für die zentrale Richtlinienverwaltung, indem wir die Beziehungen auf einem Chef-Server berechneten und sie anschließend an jeden Knoten verteilten.

Die Verwendung von Punkt-zu-Punkt-Verschlüsselung anstelle des herkömmlichen VPN-Modells bietet mehrere Vorteile:

• Dezentrale Verschlüsselung. Anstatt sich auf kritische VPN-Gateways zu verlassen, kann jeder Knoten seine eigene Verschlüsselung verwalten (wodurch Single Points of Failure beseitigt werden).

• Skalierbarkeit. Da Beziehungen nur für die Knoten berechnet werden, mit denen ein einzelner Knoten kommunizieren muss (und nicht für jeden Knoten), ist der Verschlüsselungsaufwand sehr gering. In unseren ersten Benchmarks stellten wir fest, dass die Leistung beeinträchtigt wurde, wenn ein Knoten mit Tausenden von Knoten kommunizieren musste. Solange unsere Dienste jedoch isoliert und abgeschlossen bleiben, sollte dieses Modell für unsere Anforderungen skalierbar sein.

• Effizienz. Wir können die dedizierte AES-Hardware nutzen, die in den meisten modernen Chipsätzen enthalten ist. Da der Datenverkehr sowohl verschlüsselt als auch komprimiert wird, haben wir zudem nur eine Beeinträchtigung unseres Netzwerkdurchsatzes von 2–3 % festgestellt.

• Verschlüsselung innerhalb von Rechenzentren. Die Übertragung von Daten über dedizierte Verbindungen innerhalb oder zwischen Rechenzentren ist im Allgemeinen sicher, doch jüngste Ereignisse haben die Befürchtung von Sicherheitslücken bei solchen Verbindungen verstärkt. Punkt-zu-Punkt-Verschlüsselung bietet eine bessere Alternative.

• Eine Abhängigkeit von NAT weniger. Da immer mehr Netzwerke IPv6 und einen globalen Adressraum unterstützen, muss der von VPNs bereitgestellte private Adressraum neu konfiguriert werden. Unser Punkt-zu-Punkt-Modell unterstützt problemlos einen globalen Adressraum.

• Vollständige Ende-zu-Ende-Verschlüsselung. Switches, Router, Glasfaserverteiler, benachbarte Rechner, die Hosting-Anbieter selbst – all dies sind Beispiele für potenzielle Einfallstore. Durch die durchgängige Verschlüsselung des Datenverkehrs kann ein Angreifer, selbst wenn er unsere Daten abfangen sollte, diese nicht lesen.

Rollenbasierte Zugriffskontrolle

PagerDuty verwendet ein Least-Privilege-Berechtigungsmodell. Das bedeutet, dass unsere Techniker nur Zugriff auf die Server haben, die sie für ihre Arbeit benötigen. Wir nutzen Chef in Kombination mit einfachen Linux-Benutzern und -Gruppen, um unsere Zugriffskontrollen zu realisieren.

Immer wenn wir einen neuen Benutzer zu unserer Infrastruktur hinzufügen, müssen wir die Gruppen hinzufügen, denen dieser Benutzer angehört. Wenn wir eine neue Servergruppe hinzufügen, müssen wir festlegen, welche Benutzergruppen Zugriff auf diese Server haben. Mit diesen Informationen können wir die Passwort- und Gruppendateien auf jedem Host erstellen. Da dies alles in JSON-Konfigurationsdateien gespeichert und versioniert wird, lassen sich Zugriffsanfragen und -genehmigungen problemlos in unseren Code-Review-Prozess integrieren.