Sicherheit

Diese Seite beschreibt die Sicherheitsmaßnahmen, die heute tatsächlich bei Astrina.io vorhanden sind. Sie ist absichtlich spezifisch und absichtlich unvollständig: Wo wir etwas nicht haben, sagen wir das, anstatt etwas anderes zu implizieren. Wenn eine Sicherheitskontrolle auf dieser Seite nicht aufgeführt ist, gehen Sie davon aus, dass wir sie nicht haben.

Wo Ihre Daten gespeichert sind

Astrina läuft auf einem einzelnen Server, der bei OVH in der EU gehostet wird. Der Server wird mit dem Hestia-Kontrollpanel verwaltet, und die Datenbank (MariaDB/MySQL) läuft auf demselben Server. Cloudflare sitzt davor für DNS, CDN, TLS-Beendigung und WAF.

Die vollständige Liste der Dritten, die Daten in unserem Auftrag verarbeiten, finden Sie auf der Subprocessors-Seite. Was wir sammeln und wie lange wir es aufbewahren, ist in der Datenschutzrichtlinie und der Datenaufbewahrung-Seite festgelegt.

Verschlüsselung während der Übertragung

Der gesamte Datenverkehr zu und von Astrina.io wird über TLS bereitgestellt. Cloudflare ist im Voll (streng) Modus konfiguriert, was bedeutet, dass die Verbindung zwischen Cloudflare und unserem Ursprungsserver ebenfalls verschlüsselt ist und das Ursprungszertifikat validiert wird. Das Ursprungszertifikat wird von Let's Encrypt ausgestellt.

Passwörter

Passwörter werden nur als Hash gespeichert, der von PHP password_hash() unter Verwendung von bcrypt (PASSWORD_DEFAULT) erzeugt und mit password_verify() überprüft wird.
Wir speichern Ihr Passwort niemals im Klartext und schreiben es niemals in ein Protokoll. Niemand bei Astrina kann Ihr Passwort lesen oder Ihnen sagen, was es ist.
E-Mail-Verifizierungs- und Passwortzurücksetzungstoken werden als SHA-256-Hash des Tokens gespeichert, sind einmalig und laufen ab.
Wenn ein Passwort gegen bekannte Datenpannenlisten überprüft wird, verwenden wir die Pwned Passwords k-Anonymitätsmethode: Nur die ersten fünf Zeichen des SHA-1-Hashes des Passworts werden gesendet. Das Passwort selbst verlässt niemals den Browser oder unseren Server.

Es gibt keine Zwei-Faktor-Authentifizierung für Astrina-Konten. Siehe "Was wir noch nicht haben" unten.

Sitzungen und Formulare

Das Sitzungscookie heißt astrsess. Es ist als HttpOnly (JavaScript kann es nicht lesen), Secure (es wird nur über HTTPS gesendet) und SameSite=Lax gesetzt.
Zustandsändernde Formularübermittlungen tragen ein CSRF-Token, sodass eine andere Seite Ihren Browser nicht dazu bringen kann, eine Aktion in Ihrem Konto auszuführen.

API-Schlüssel

Ihr API-Schlüssel wird nur in einem Anfrage-Header akzeptiert — X-Api-Key oder Authorization: Bearer. Wir akzeptieren absichtlich keine Schlüssel in der URL-Abfragezeichenfolge.
Diese Wahl ist wichtig: Ein Schlüssel, der in einer URL platziert ist, landet oft in Serverzugriffsprotokollen, Proxyprotokollen, dem Browserverlauf und Referer-Headern, die an andere Seiten gesendet werden. Ein Schlüssel in einem Header nicht.
Sie können Ihren Schlüssel jederzeit von /my/api.php regenerieren. Die Regeneration widerruft den alten Schlüssel sofort.
Jeder Plan hat ein tägliches Anrufkontingent. Sobald es aufgebraucht ist, gibt die API HTTP 429 zurück, anstatt weiterhin Anfragen zu bedienen.

Cross-Origin-Zugriff (CORS)

Unsere öffentlichen API-Methoden sind absichtlich für jede Herkunft offen (Access-Control-Allow-Origin: *), da sie öffentliche Katalogdaten bereitstellen. Die private Analytikmethode, /api/v1/stats, sendet überhaupt keinen Allow-Origin-Header — sodass eine Webseite auf einer anderen Seite den Browser eines Besuchers nicht verwenden kann, um Ihre Statistiken zu lesen, selbst wenn sie irgendwie Ihren Schlüssel hätte.

Härtung des SEO-Crawlers

Unser SEO-Crawler ruft URLs ab, die von Kunden bereitgestellt werden, was genau die Art von Funktion ist, die missbraucht wird, um auf interne Systeme zuzugreifen (SSRF). Es ist dagegen gehärtet:

Nur http- und https-URLs werden akzeptiert.
Private, Loopback- und Link-Local-IP-Bereiche werden abgelehnt.
Die aufgelöste IP-Adresse ist festgelegt, sodass der Hostname zwischen der Überprüfung und der Anfrage nicht auf etwas anderes aufgelöst werden kann.
Jeder Weiterleitungs-Hops wird gegen dieselben Regeln erneut validiert, nicht nur die erste URL.
Die Größe des Antwortkörpers ist begrenzt.

Die Sitzungsaufzeichnung ist standardmäßig maskiert

Wenn Sie den optionalen Sitzungsrekorder aktivieren, ist die Maskierung standardmäßig aktiviert und wird im Browser des Besuchers durchgesetzt — bevor irgendetwas an uns gesendet wird:

Passwort-, E-Mail- und Telefon-Eingabefelder übertragen niemals einen Wert. Weder den Text, noch eine maskierte Version davon, noch sogar dessen Länge.
Zahlungskartenfelder werden auf die gleiche Weise behandelt.
Text, der in ein anderes Eingabefeld eingegeben wird, wird in Punkte maskiert.
Jeder Teil Ihrer Seite, den Sie mit dem Attribut [data-astr-mask] markieren, wird redigiert, bevor er den Browser verlässt.

Aufzeichnungen werden standardmäßig 30 Tage lang aufbewahrt. Der Aufbewahrungszeitraum ist konfigurierbar.

Beweisdateien zu Bewertungen

Bilder und Videos, die als Beweis für einige Bewertungsarten angehängt sind, werden außerhalb des Web-Stammverzeichnisses gespeichert, sodass sie nicht durch Raten einer URL abgerufen werden können. Sie werden nur über einen geschützten Endpunkt bereitgestellt, der 403 zurückgibt, es sei denn, die Bewertung wurde genehmigt, oder Sie sind der Autor der Bewertung, oder Sie sind ein Administrator.

Missbrauchs- und Bot-Kontrollen

Bewertungen werden pro IP-Adresse limitiert und moderiert. Bewertungen von Gästen werden nur nach der Moderation veröffentlicht; Bewertungen von angemeldeten Mitgliedern werden sofort veröffentlicht.
Der Analyseverkehr wird für Bots gefiltert, indem Benutzeragentenregeln zusammen mit der Klassifizierung von Rechenzentren und Hosting-IP-Adressen über Reverse-DNS verwendet werden.

Admin-Zugang

Der Admin-Bereich ist durch eine Rollenüberprüfung des Kontos gesperrt. Administrativen Konten verwenden denselben Anmelde-Mechanismus wie alle anderen, was bedeutet, dass sie auch nicht durch eine Zwei-Faktor-Authentifizierung geschützt sind.

E-Mail, die wir senden

Ausgehende E-Mails (von noreply@astrina.io) werden von unserem eigenen Exim-Mail-Server mit konfiguriertem DKIM gesendet, sodass die Empfänger überprüfen können, dass eine Nachricht tatsächlich von uns stammt. Wir geben Ihre Adresse nicht an einen Drittanbieter-Mail-Anbieter weiter.

Backups und Wiederherstellung des Dienstes

Hestia erstellt täglich ein Backup von Dateien und der Datenbank, ungefähr um 05:12 UTC.

Backups werden auf demselben Server gespeichert, der den Dienst ausführt. Es gibt keine Offsite-Kopie und keine geo-redundante Replikation. Dies ist eine echte Einschränkung, die Sie in Ihre eigene Planung einbeziehen sollten: Ein Ereignis, das den Server zerstört, würde auch die darauf gespeicherten Backups zerstören. In der Praxis existiert zu jedem Zeitpunkt ungefähr eine tägliche Kopie.

Wenn der Dienst wiederhergestellt werden muss, stellen wir ihn aus dem aktuellsten täglichen Backup wieder her. Wir garantieren kein Wiederherstellungszeit-Ziel (RTO) oder ein Wiederherstellungspunkt-Ziel (RPO) und bieten kein öffentliches Service-Level-Agreement an. Ein SLA existiert nur, wenn es in einem individuellen Vertrag separat vereinbart wurde.

Was wir noch nicht haben

Wir möchten Ihnen dies lieber klar sagen, als eine Sicherheitsseite mehr zu implizieren, als sie sollte. Astrina hat derzeit nicht:

Keine Zwei-Faktor-Authentifizierung (2FA) und kein SSO für das Astrina-Panel selbst.
Keine Sicherheitsprüfung durch Dritte und kein Penetrationstest. Es wurde nichts durchgeführt, daher gibt es keine Ergebnisse zu veröffentlichen.
Keine ISO 27001, SOC 2 oder andere Zertifizierung. Wir sind nicht zertifiziert oder nach einem Standard geprüft.
Kein Offsite-Backup. Siehe den Abschnitt über Backups oben.
Kein Bug-Bounty-Programm. Wir akzeptieren Berichte, können aber nicht dafür bezahlen.
Kein formelles Service-Level-Agreement und keine veröffentlichte Verfügbarkeitsgarantie.

Wenn eines davon für Sie erforderlich ist, sind sie heute nicht vorhanden, und Sie sollten entsprechend entscheiden.

Meldung eines Sicherheitsproblems

Wenn Sie eine Schwachstelle finden, melden Sie diese bitte an support@astrina.io. Dies ist die einzige Kontaktadresse für Sicherheitsberichte.

Es hilft, wenn Sie die betroffene URL oder den Endpunkt, die Schritte zur Reproduktion und was ein Angreifer erreichen könnte, angeben. Bitte geben Sie uns eine angemessene Gelegenheit, ein Problem zu beheben, bevor Sie es öffentlich bekannt geben, und bitte greifen Sie nicht auf Daten anderer Personen zu, ändern Sie diese nicht oder löschen Sie sie während des Tests.

Wir betreiben kein Bug-Bounty-Programm und können keine Zahlung oder Belohnung für Berichte anbieten. Wir versprechen auch keine Reaktionszeit, da wir kein öffentliches SLA anbieten — aber Berichte, die an diese Adresse gesendet werden, erreichen uns und wir handeln entsprechend.

Ihre Daten und Ihre Kontrolle darüber

Sie können eine einzelne verfolgte Website jederzeit aus Ihrem Panel löschen, wodurch deren Daten entfernt werden.
Sie können Ihren API-Schlüssel jederzeit von /my/api.php regenerieren oder widerrufen.
Es gibt heute keinen Selbstbedienungs-Button zur Kontolöschung im Panel. Um Ihr Konto und Ihre Daten löschen zu lassen, senden Sie eine E-Mail an support@astrina.io und wir werden dies auf Anfrage tun.