Wir bei PagerDuty nehmen Sicherheit sehr ernst. Für uns bedeutet Sicherheit, Kundendaten zu schützen und sicherzustellen, dass Kunden sicher mit PagerDuty kommunizieren können. Da wir uns auf hohe Verfügbarkeit konzentrieren, legen wir großen Wert darauf, wie wir unsere Sicherheitsinfrastruktur gestalten und überwachen.

In einer dynamischen Umgebung wie der von PagerDuty ist es nicht einfach, eine robuste Sicherheit auf Host- und Netzwerkebene bereitzustellen. Dies auf eine verteilte, fehlertolerante und vom Hosting-Anbieter unabhängige Weise zu tun, bringt noch mehr Herausforderungen mit sich. In dieser Reihe von Blogbeiträgen wollten wir einige der Strategien und Techniken hervorheben, die das Operations Engineering-Team von PagerDuty verwendet, um die PagerDuty Plattform zu sichern und Kundendaten zu schützen.

Hier sind einige der Best Practices, die wir im Bereich Sicherheit befolgen:

Etablierung interner Standards

Alle unsere internen Entscheidungen zur Sicherheit unterliegen einer Liste von Philosophien und Konventionen, die wir pflegen. Diese Liste ist nicht in Stein gemeißelt, da wir sie aktualisieren, wenn wir Probleme finden, aber sie zwingt uns zu verstehen, wo wir Kompromisse eingehen, und hilft uns bei unserer Entscheidungsfindung. Außerdem erleichtert sie es neuen Ingenieuren, schnell zu verstehen, warum die Dinge so eingerichtet sind, wie sie sind.

Standardmäßig sicher

Wir folgen der Konvention, standardmäßig alles zu sichern. Das bedeutet, dass das Deaktivieren eines Sicherheitsdienstes über eine Überschreibungs- oder Ausnahmeregel erfolgen muss. Dies dient dazu, Konsistenz in unseren Entwicklungs-, Test- und Produktionsumgebungen zu erzwingen.

So verlockend es auch ist, ein Loch in die lokale Firewall zu bohren oder SSL bei der Verbindung mit MySQL zu deaktivieren, wir möchten diese Art von Sicherheitsänderungen nicht in unseren Produktions- oder Testumgebungen vornehmen. Wenn wir unsere Tools so einstellen, dass sie automatisch „das Richtige tun“, bleiben alle unsere Ingenieure ehrlich. Durch diese Art der Konsistenz können wir außerdem sicherheitsrelevante Probleme früher im Entwicklungszyklus beheben.

Gehen Sie von einem feindlichen und instabilen Netzwerk aus

Unsere gesamte Infrastruktur wird bei Cloud-Hosting-Anbietern bereitgestellt, deren Netzwerke wir nicht kontrollieren können. Darüber hinaus sind wir in mehreren Regionen verteilt, sodass ein großer Teil unseres Datenverkehrs über das WAN läuft. Dies bringt die Herausforderungen von Paketverlusten und hohen Latenzen mit sich – sowie die Möglichkeit, dass Eindringlinge versuchen, unseren Datenverkehr abzuhören.

In diesem Sinne verschlüsseln wir alle Daten während der Übertragung und gehen immer davon aus, dass unsere Daten durch Netzwerke fließen, in die wir wenig Einblick haben.

Seien Sie anbieterunabhängig

Sicherheitsgruppen, VPC, Rescue-Konsolen usw. Dies sind alles Beispiele für anbieterspezifische Tools, die wir nicht verwenden können, da wir auf mehrere Hosting-Anbieter verteilt sind und eine Abhängigkeit von einem Anbieter vermeiden müssen. Alle unsere Sicherheitstools müssen auf allgemein verfügbaren Linux-Tools oder installierbaren Paketen basieren, wodurch wir nicht mehr von anbieterspezifischen Sicherheitstools abhängig sind und die Stabilität verbessert wird. Wir nutzen Chef, um den Großteil dieser Arbeit für uns zu erledigen, und haben fast alle unsere Tools darauf aufgebaut.

Zentralisieren Sie die Richtlinienverwaltung und verteilen Sie die Richtliniendurchsetzung

Die meisten Unternehmen verfolgen AAA (Authentifizierung, Autorisierung, Zugriff), indem sie für die Zugriffskontrolle einzelne Wahrheitsquellen verwenden und diese dann auch als Autorisierungsmechanismus nutzen. Beispiele hierfür sind: die Verwendung eines LDAP-Servers, eines RADIUS-Servers oder einer Perimeter-Firewall zum Speichern von Netzwerkrichtlinien. Anstatt uns sowohl bei der Richtlinienverwaltung als auch bei der Durchsetzung auf diese einzelnen Wahrheitsquellen zu verlassen, teilen wir die Durchsetzungsteile auf und verteilen sie an die einzelnen Knoten im Netzwerk. Unser typisches Muster ist, dass bei einer Änderung im Netzwerk die einzelne Wahrheitsquelle die Richtlinie aktualisiert und sie dann an alle Knoten weiterleitet.

Kontinuierlich validieren

Während all die oben genannten Punkte dazu dienen, eine robuste Sicherheitsarchitektur bereitzustellen, ist es wichtig, dass wir unsere Sicherheitsmaßnahmen validieren, um sicherzustellen, dass sie das tun, was wir tatsächlich von ihnen erwarten.

Einige Unternehmen führen vierteljährlich Penetrationstests durch, aber in unserer dynamischen Umgebung ist das zu langsam. Wir scannen, überwachen und melden Änderungen aktiv (mit PagerDuty), wenn etwas Unerwartetes passiert. Wir erkennen Probleme schnell, wenn ein Fehler passiert (z. B. öffnet ein Techniker versehentlich den falschen Netzwerkport auf einem Server) oder wenn tatsächlich böswilliges Verhalten vorliegt (z. B. wenn jemand versucht, einen Endpunkt mit Brute Force zu attackieren). Wir werden sofort auf das Problem aufmerksam gemacht.

Dies ist der erste Beitrag in einer Reihe darüber, wie wir bei PagerDuty die Sicherheit verwalten. Um diese Reihe weiterzulesen, schauen Sie sich an: Definieren und Verteilen von Sicherheitsprotokollen zur Fehlertoleranz