Jede auf dieser Seite beschriebene Kontrolle existiert heute im laufenden System.
Wo eine Kontrolle einen Teil der Plattform abdeckt und einen anderen nicht, sagt
diese Seite, welchen. Wo wir nichts vorweisen können, steht auch das hier.
Was vorhanden ist
Kontrollen, und was sie genau abdecken
Authentifizierung
Passwörter werden mit Argon2 gehasht und niemals im Klartext gespeichert. Die primäre Authentifizierung ist an Stytch delegiert, das die Zugangsdaten hält. Zwei-Faktor-Authentifizierung ist für jedes Konto verfügbar, per zeitbasiertem Einmalcode oder WebAuthn-Passkey.
Rollen, die aus dem Token durchgesetzt werden
Vier Dashboard-Rollen (Owner, Admin, Member, Viewer) plus eine separate Auditor-Rolle. Die Durchsetzung liest die Rollen aus dem verifizierten Session-Token statt aus einer Spalte in unserer Datenbank, und eine Ablehnung erfolgt auf der Request-Ebene, statt von der Oberfläche nur verborgen zu werden. Die Auditor-Rolle wird bei jeder verändernden HTTP-Methode ohne Ausnahme abgelehnt. Die Viewer-Rolle wird bei jeder verändernden Methode abgelehnt, außer beim Bestätigen und Schließen eines Incidents, was ihr bewusst erlaubt ist. Rollen gelten für interaktive Sessions: Ein API-Schlüssel oder ein Machine-to-Machine-Token trägt keine Rolle und wird stattdessen über seine Scopes geregelt.
API-Schlüssel, die wir nicht zurücklesen können
Ein Schlüssel besteht aus 96 hexadezimalen Zeichen kryptografisch zufälliger Ausgabe. Wir speichern seinen SHA-256-Digest auf einem eindeutigen Index sowie die ersten acht und die letzten vier Zeichen, damit Sie ihn in einer Liste wiedererkennen. Das Geheimnis selbst wird nie in unsere Datenbank geschrieben. Ein verlorener Schlüssel kann daher widerrufen und neu ausgestellt, aber niemals wiederhergestellt werden, weder von uns noch von jemandem, der an die Zeile gelangt.
Mandantentrennung, und ihre zwei Ausnahmen
Jeder Lesezugriff auf der Datenebene wird auf eine Konto-Kennung eingegrenzt, bevor er den Speicher erreicht, als typisierte UUID. Bei einem gewöhnlichen Request stammt diese Kennung aus der verifizierten Session und kann vom Aufrufer nicht mitgegeben werden. Es gibt zwei bewusste Ausnahmen, beide werden vor der Verwendung auf Eigentümerschaft geprüft: Ein Partner darf eines seiner eigenen verwalteten Kundenkonten in einem X-SQ-Account-Header benennen, was abgelehnt wird, sofern dieses Konto kein aktives Unterkonto genau dieses Partners ist; und unsere interne Mitarbeiteroberfläche adressiert ein Konto per ID in der URL, hinter den unten beschriebenen Schranken.
Wie unsere Abfragen gebaut werden
Der PostgreSQL-Zugriff nutzt parametrisierte Statements mit Bind-Parametern. Auf diesem Pfad gibt es nirgends per String-Verkettung zusammengesetztes SQL. Nahezu alles davon wird zusätzlich zur Compile-Zeit von unseren Query-Makros gegen das Live-Schema geprüft; eine kleine Zahl von Statements nutzt die Laufzeitform, die weiterhin jeden Parameter bindet, aber beim Build nicht gegen das Schema geprüft wird.
Verschlüsselung im Transit, bei jeder Verbindung, die Sie aufbauen
Jede Verbindung zwischen Ihnen und Site Qwality läuft über HTTPS. Alle acht öffentlichen API-Hostnamen erzwingen TLS 1.2 als Minimum, ebenso diese Marketing-Website. Fünf unserer sechs Content-Delivery-Distributionen erzwingen die TLS-1.2-Richtlinie (2021) und leiten HTTP auf HTTPS um. Die sechste liefert Status-Page-Logos und -Bilder von einer CloudFront-Adresse statt von einem eigenen Hostnamen aus und lässt weiterhin TLS 1.0 zu. Sie anzuheben ist eingeplante Arbeit, und wir benennen das lieber, als es hinter einer Einschränkung zu verstecken.
Verschlüsselung im Ruhezustand, in den Speichern, die wir benennen
Alle zehn unserer Objektspeicher-Buckets sind serverseitig mit AES-256 verschlüsselt und tragen die vollständige Public-Access-Sperre in allen vier Einstellungen. Nichts darin kann also durch eine versehentliche Zugriffskontrollliste oder eine öffentliche Bucket-Policy weltweit lesbar gemacht werden. Zwei dieser Buckets enthalten Inhalte, die bewusst öffentlich sind und über unser CDN statt direkt aus dem Bucket ausgeliefert werden: das RUM-Skript sowie die Logos und Bilder, die Sie für eine öffentliche Status-Page hochladen. Das Volume mit den Logs, Metriken, Traces, RUM-Daten und dem Session-Replay-Index jedes Kontos ist im Ruhezustand verschlüsselt. Verschlüsselung im Ruhezustand ist noch nicht über jeden von uns betriebenen Speicher hinweg universell; siehe „Was wir nicht behaupten" weiter unten.
Antwort-Bodies nur bei Fehlschlag gespeichert
Eine erfolgreiche HTTP-Prüfung speichert überhaupt keinen Antwort-Body. Wenn eine Prüfung fehlschlägt, behalten wir einen 8 KB-Ausschnitt inline, damit die Ergebnisliste ohne zweiten Request rendert, und den vollständigen Body in verschlüsseltem Objektspeicher. Ein Fehlschlag bleibt diagnostizierbar, ohne dass wir eine Kopie jeder Seite einer funktionierenden Website halten.
Ein Audit-Log, das Sie lesen können
Jeder authentifizierte Request, den Sie oder Ihre Nutzer stellen und der etwas in Ihrem Konto verändert, wird mit dem Akteur, der Aktion, der HTTP-Methode und dem Pfad, dem Antwortstatus, der Request-IP und dem User-Agent aufgezeichnet. Ein abgelehnter Request wird ebenfalls aufgezeichnet, mit seinem 403. Zwei Endpunkte, die eine verändernde Methode nur zum Transport einer Leseabfrage verwenden, sind ausgenommen. Der Schreibvorgang ist bewusst „best effort", damit ein Fehler beim Protokollieren niemals Ihren Request scheitern lässt. Das bedeutet zugleich, dass ein Ausfall des Log-Speichers eine Lücke hinterlassen kann. Die letzten 90 Tage sind im Dashboard für einen Konto-Admin, die Auditor-Rolle oder den Hauptnutzer des Kontos lesbar.
Was Ihr Audit-Log nicht enthält
Administrative Aktionen von Site-Qwality-Mitarbeitern gehen in ein separates internes Mitarbeiter-Log, nicht in Ihres. Das umfasst Änderungen an Tarif und Limits, die Vergabe von SMS-Guthaben, Sperrung, Reaktivierung und Löschung sowie das Auslösen eines Passwort-Resets für ein Mitglied. Es gibt eine Ausnahme, und sie ist beabsichtigt: Ein Mitarbeiter, der als einer Ihrer Nutzer per Impersonation handelt, erscheint in Ihrem eigenen Log, zugeordnet zu dem Mitarbeiter, der es getan hat.
Wie unsere eigenen Mitarbeiter an die Produktion kommen
Die interne Admin-Oberfläche sitzt hinter vier Schranken, die alle vor jedem Handler laufen. Drei können wir im Code nachweisen: eine IP-Allowlist, die am CDN-Rand durchgesetzt wird, ein Origin-Token, das dieser Rand einfügt und das serverseitig mit einem konstantzeitigen Vergleich geprüft wird, und eine Prüfung der Mitarbeiterrolle im Session-Token. Jeder dieser Requests wird in ein separates Mitarbeiter-Audit-Log geschrieben. Die vierte ist verpflichtende Mehr-Faktor-Authentifizierung in unserer Mitarbeiter-Identitätsorganisation, und sie ist aktiviert. Sie ist eine Richtlinie bei unserem Identitätsanbieter ohne Entsprechung in irgendeinem Repository, wird also beim Anmelden durchgesetzt und nicht von unserem Code. Sie ist die einzige der vier, die wir Ihnen nicht in einer Datei zeigen können.
Impersonation ist ausdrücklich und begrenzt
Ein Mitarbeiter kann Ihr Konto nur über einen Endpunkt als einer Ihrer Nutzer öffnen, der festhält, wer es getan hat, welcher Nutzer betroffen war und eine schriftliche Begründung. Die Session kann schreibgeschützt ausgestellt werden; dann wird jede verändernde Methode abgelehnt. Sie läuft nach 60 Minuten ab und kann nicht verlängert werden.
Kartendaten erreichen uns nie
Kartendaten werden in ein Zahlungselement eingegeben, das von Stripes eigener Origin ausgeliefert wird. Eine Kartennummer berührt niemals einen Server, eine Datenbank oder ein Log von Site Qwality. Was wir speichern, ist eine Stripe-Kundenkennung und Abonnement-Kennungen.
Alert-E-Mails, die nicht umgeschrieben werden
Ausgehende Alert-E-Mails laufen über Amazon SES mit DKIM-Signatur, einer dedizierten MAIL-FROM-Domain, SPF und DMARC. Engagement-Tracking ist bewusst abgeschaltet, sodass ein Link in einem Ausfall-Alert nie auf einen Weiterleiter eines Dritten umgeschrieben wird. Bounce- und Beschwerde-Rückmeldungen werden verarbeitet und festgehalten, sodass eine Alert-Adresse, die ein Anbieter still unterdrückt hat, sichtbar wird, statt lautlos zu scheitern.
Offen gesagt
Was wir nicht behaupten
Eine Vertrauensseite ist nichts wert, wenn Sie nicht erkennen können, welche Sätze geprüft
wurden. Das hier sind die Dinge, nach denen ein Sicherheitsfragebogen üblicherweise fragt und
die wir nicht mit Ja beantworten können.
Keine eigene Zertifizierung. Amazon Web Services hält SOC 2,
ISO 27001 und weitere Zertifizierungen für die Infrastruktur, auf der wir laufen.
Site Qwality hält keine. Eine frühere Fassung dieser Seite war so formuliert, dass sie
beides verwischte, und das war unser Fehler.
Kein Penetrationstest durch Dritte und kein Schwachstellen-Scanning-Programm.
Wir betreiben heute weder das eine noch das andere. Die Adresse für verantwortungsvolle
Offenlegung weiter unten ist der Weg, den es gibt, und wir lesen dort mit.
Verschlüsselung im Ruhezustand ist nicht universell. Die oben benannten
Speicher sind verschlüsselt. Nicht jeder von uns betriebene Speicher ist es, und die
übrigen nachzuziehen ist eingeplante, nicht erledigte Arbeit.
Nicht alles, was wir halten, verfällt nach Plan. Session-Replay-Aufzeichnungen
und die durchsuchbare Kopie Ihrer Logs, Metriken und Traces werden am Ende ihres Fensters
automatisch gelöscht. Eine zweite Archivkopie der aufgenommenen Log-Zeilen wird in
Objektspeicher geschrieben und unterliegt heute keinem Löschplan, sie überlebt also das
Fenster, das für die durchsuchbare Kopie gilt. Auch mehrere Betriebsdatensätze haben kein
durchgesetztes Löschfenster. Das sagen wir lieber, als eine einheitliche Regel anzudeuten.
Unsere Seite Datenaufbewahrung nennt für jede Kategorie
entweder das Fenster, das unsere Systeme durchsetzen, oder die klare Feststellung, dass
bislang nichts sie löscht.
Unsere eigene Infrastruktur steht in den Vereinigten Staaten.
Die gesamte Speicherung und die gesamte Rechenleistung finden in der AWS-Region
us-east-1 statt. Jeder Server, jede Datenbank und jeder Objektspeicher, der
Ihre Daten hält, läuft dort, und auch die Monitoring-Prüfungen werden von dort ausgeführt.
Wir bieten keine Datenresidenz-Option für die EU oder das Vereinigte Königreich an. Dieser
Satz ist bewusst auf unsere eigene Infrastruktur beschränkt: Einige der Anbieter, von
denen wir abhängen, betreiben globale Netze. Unsere Seite
Unterauftragsverarbeiter nennt für jeden davon den
Verarbeitungsort und sagt klar, welche davon noch ungeklärt sind.
Unser Content-Delivery-Netzwerk terminiert Verbindungen außerhalb der Region,
und es geht dabei nicht nur um öffentliche Assets. Wir betreiben sechs
Distributionen, und alle sechs nutzen eine Preisklasse, die europäische Edge-Standorte
einschließt. Eine Anfrage aus Europa wird also in Europa terminiert und nicht in Virginia.
Zwei der sechs liefern ausschließlich öffentliche Dateien aus: das RUM-Skript und
Status-Page-Logos. Zwei liefern Status-Pages aus, eine von uns und eine unter der eigenen
Domain eines Kunden. Zwei stehen vor unserem internen Mitarbeiterportal, und eine davon
leitet Mitarbeiter-Requests an unsere API weiter, sodass auch Mitarbeiterverkehr mit
Kontodaten von Kunden an einem Edge terminiert wird. Keine der sechs hat
Zugriffs-Logging aktiviert, wir führen am Edge also keine Aufzeichnung darüber, wer was
angefragt hat. Eine frühere Fassung dieser Seite nannte das CDN „das Einzige, was die
Region verlässt" und beschrieb es als Cache für öffentliche Assets. Das benannte zwei von
sechs und war falsch.
Wenn Sie eine Lieferantenbewertung ausfüllen und eine Antwort hier nicht detailliert genug
ist, schreiben Sie an die Adresse unten und fragen Sie nach. Wir schicken Ihnen lieber eine
konkrete Antwort, als dass Sie eine großzügige daraus ableiten.
Verantwortungsvolle Offenlegung
Eine Schwachstelle gefunden?
Wir nehmen jeden Sicherheitsbericht ernst. Es gibt kein Bug-Bounty-Programm und keine
formale Zusage zur Reaktionszeit, aber das Postfach wird von einem Engineer gelesen, und wir
arbeiten mit Ihnen an einer verantwortungsvollen Lösung.