Die Anwendungsebene sichern
Um die Anwendungsebene zu sichern, sollten Sie die Benutzer- und Datenbank-Authentifizierung, digitale Zertifikate und Verschlüsselung berücksichtigen.
Integrierte Benutzerauthentifizierung
Mit der integrierten Authentifizierung des Servers werden Benutzer über clientseitiges JavaScript authentifiziert. Dieses ruft eine lokale SHA256-Funktion auf, um das Kennwort zu hashen und mit Salts zu versehen. Anschließend wird der Hash zum Vergleich mit dem Kennwort-Hash in der (in der MongoDB gespeicherten) Benutzerdatenbank an den Server gesendet. Der Server speichert nur den Hash-Wert; der Klartext des Benutzerkennworts gelangt nie an den Server.
Anmerkung
Wir haben den Algorithmus aktualisiert, mit dem Kennwörter für die integrierte Authentifizierung gehasht werden. In Versionen vor 22.1 rief der Client eine lokale bcrypt-Bibliothek auf, um das Kennwort zu hashen und mit Salts zu versehen, bevor der Hash an den Server gesendet wird.
Weitere Informationen zu den anderen Authentifizierungsmethoden, die für den Server verfügbar sind, finden Sie im Abschnitt Authentifizierung dieses Handbuchs.
Datenbank-Authentifizierung
Alteryx Server speichert die meisten Anwendungsinformationen in einer eingebetteten Mongo-Datenbank. Während der Installation werden eine Anwendungsbenutzer-ID und ein Kennwort generiert, um auf Informationen in der Datenbank zuzugreifen. Auf der Hilfeseite für den Controller finden Sie weitere Datenbankoptionen, einschließlich des benutzerverwalteten Mongo und MongoDB Atlas.
Transport-Verschlüsselung
Die Verschlüsselung verhindert die Offenlegung und Änderung sensibler Daten während des Transports. Dazu gehören Kennwörter, Informationen zu Benutzersitzungen und Transaktionen. Wir empfehlen, Verbindungen zum Server über HTTPS mit TLS 1.2 oder höher zu verschlüsseln, um das Abfangen durch unbefugte Personen zu verhindern. Der HTTPS-Betrieb kann in den Systemeinstellungen konfiguriert werden. Um sicherzustellen, dass TLS mit Version 1.2 oder höher ausgehandelt wird, müssen Sie möglicherweise die Channel -Einstellungen ändern, wie im Abschnitt Die Betriebssystemebene sichern in diesem Handbuch beschrieben.
Weitere Informationen finden Sie unter SSL/TLS für Server konfigurieren .
Sicherheit ruhender Daten
Während der Prozessausführung erstellt der Server dauerhafte Belege in Form von temporären Dateien, Metainformationen und Protokolldateien. Diese ruhenden Daten werden physisch in der Mongo-Datenbank und im lokalen Speicher des Servers gespeichert. Im Folgenden finden Sie einige gängige Probleme im Zusammenhang mit ruhenden Daten sowie Techniken, mit denen diese behoben werden können.
Anmerkung
Benutzerverwaltete MongoDB Enterprise- oder MongoDB Atlas-Instanzen unterstützen die Verschlüsselung im Ruhezustand. Weitere Informationen finden Sie unter Dokumentation zur MongoDB .
Zum Speichern von Daten während der Alteryx-Prozessausführung werden temporäre Dateien im YXDB-Format verwendet. Diese Dateien können tatsächliche Daten enthalten, die zur Laufzeit durch den Workflow gestreamt werden.
Temporäre Dateien werden für Engine-Aufrufe ausgelegt und gelöscht, sobald sie nicht mehr von nachgelagerten Prozessen benötigt werden oder nachdem der Alteryx-Workflow fertig ausgeführt wurde. Wenn der Alteryx-Prozess abgestürzt ist, können diese Dateien manchmal zurückbleiben. Temporäre Dateien werden auch in so einem Fall nach wie vor automatisch gelöscht, wenn der Dienst neu gestartet wird.
Das Hauptverzeichnis, in dem temporäre Dateien gespeichert werden, wird in Alteryx Server festgelegt unter System Settings > Engine Settings > Temporary Directory . Jeder Engine-Aufruf speichert seine einzelnen temporären Dateien in einem separaten Unterverzeichnis unter diesem Speicherort.
Härtung des Speichers für temporäre Dateien
Befolgen Sie diese Empfehlungen, um temporäre Dateien weiter zu sichern.
Sie müssen über ausreichend RAM (Arbeitsspeicher) verfügen, damit Alteryx weniger Plattenspeicher (Swapping) benötigt.
Deaktivieren Sie die Option Allow Users to Override option in System Settings > Engine Settings , um Benutzern das Schreiben an andere Speicherorte zu verweigern. Weitere Informationen finden Sie auf der Hilfeseite Engine .
Deaktivieren Sie die Option Browse Everywhere Settings unter System Settings > Engine Settings , um die Erstellung der Alteryx Browse Everywhere Datei (YXBE) zu verhindern.
Suchen Sie das temporäre Dateiverzeichnis auf einem verschlüsselten Laufwerk (z. B. mit BitLocker).
Schließen Sie das temporäre Dateiverzeichnis aus automatischen Backups aus.
Wenn die Authentifizierung für SSO oder IWA konfiguriert ist, besitzt oder speichert der Server die für die Anmeldung verwendeten Anmeldedaten nicht. Bei Verwendung der integrierten Authentifizierung des Servers werden nur mit Salts versehene Kennwort-Hashes gespeichert.
Die Kennwörter, die der Server zur Authentifizierung bei der zugrunde liegenden MongoDB verwendet, werden im Ruhezustand mit kryptografischen Funktionen vom Betriebssystem verschlüsselt.
Mit Server-Protokollen können Sie Fehler, Warnungen, Informationen und Debugging-Meldungen verfolgen. Protokoll-Dateien enthalten Informationen über Server-Ereignisse, Workflows, aufgerufene Datendateien und die Anzahl der Datensätze, die in einem bestimmten Job verarbeitet werden. Sie enthalten keine tatsächlich verbrauchten, verarbeiteten oder ausgegebenen Daten. Protokolle werden für die Engine, den Server-UI-Knoten und den Alteryx-Dienst gesammelt.
Wenn Ihre Workflows nicht geladen werden können, wenden Sie sich an den Kundensupport.
Die Protokolle werden auf dem Server an den folgenden Speicherorten gespeichert:
Server-UI-Knoten-Protokolle werden unter
C:\ProgramData\Alteryx\Gallery\Logsgespeichert und haben einen Namen nach folgendem Muster: alteryx-2017-09-13.csvServer-/Dienst-Protokolle werden unter
C:\ProgramData\Alteryx\Servicegespeichert und haben einen Namen nach folgendem Muster: AlteryxServiceLog_2017-06-04_00-46-07.log, wobei das jeweils neueste Protokoll den Namen AlteryxServiceLog.log trägtEngine-Protokolle sind standardmäßig deaktiviert, können aber in den Systemeinstellungen aktiviert werden.
Anmerkung
Engine-Logs können von anderen Prozessen zurückgegebene Stack Traces oder Fehlermeldungen enthalten, die die Engine während der Workflow-Ausführung abruft oder aufruft. Diese Meldungen können potenziell Daten oder Metadaten enthalten, die an den externen Prozess übergeben wurden. Aus diesem Grund empfehlen wir, die Engine-Protokolle nur während der aktiven Fehlerbehebung durch autorisiertes Personal zu aktivieren.
Protokolle auf Systemebene sind in der Windows-Ereignisanzeige verfügbar.
Datensicherheit bei der Übertragung
Die Komponenten des Alteryx Servers übertragen Daten und Workflows. An verschiedenen Punkten des Übertragungsprozesses werden die übertragenen Daten je nach Konfiguration entweder verschlüsselt oder zugänglich gemacht.
Die Frontend-Benutzeroberfläche von Server ist standardmäßig HTTP (Klartext am TCP-Port 80). Wir empfehlen, den Server für HTTPS (SSL/TLS an Port 443) zu konfigurieren.
Die Kommunikation zwischen Knoten innerhalb eines verteilten Server-Clusters (siehe „Bereitstellungstypen“ in diesem Handbuch) verwendet auch Port 80, wird jedoch mit AES-256-Verschlüsselung und mithilfe von Informationen zu Controller-Token, Salt und Zeit verschlüsselt. Dadurch wird eine sichere, zeitkritische Payload gewährleistet.
Die eingebettete MongoDB, die auf dem Controller ausgeführt wird, überwacht auf einem unverschlüsselten TCP/IP-Socket (TCP-Port 27018). Auf einer All-in-One-Serverinstanz ist der Socket-Listener ausschließlich localhost und darf nicht für das Netzwerk zugänglich sein. Wenn Sie einen verteilten Server (siehe Bereitstellungstypen in diesem Handbuch) mit der integrierten MongoDB ausführen, werden Verbindungen von anderen Cluster-Knoten zur MongoDB des Controllers unverschlüsselt. Um die Datenbank-Kommunikation mit TLS/SSL zu verschlüsseln, müssen Sie zu einer benutzerverwalteten MongoDB (oder MongoDB Atlas) wechseln.
Verschlüsselungsmethoden für Datenquellen (Oracle und SQL-Server) und Berichtsplattformen (Tableau und PowerBI) werden durch Drittanbieter-ODBC-Treiber oder -Konnektoren definiert.
Die In-Flight-Daten werden durch Kennwort-Hashing und das Versehen mit Salts sowie durch die Generierung von Laufzeit-Client-API-Tokens gesichert. Diese sind im Abschnitt Server-Härtung dieses Handbuchs dokumentiert. Für einen vollständigen Schutz der In-Flight-Daten empfehlen wir, Verbindungen zum Server mit HTTPS über TLS 1.2 oder höher zu verschlüsseln.
Anmeldedaten-Speicherung
Je nach Server-Konfiguration und -Nutzung kann Server verschiedene Anmeldeinformationen speichern. Prüfen Sie, wie mit diesen sensiblen Informationen umgegangen wird.
Ein laufender Workflow kann während der Ausführung eine Verbindung zu mehreren externen Datenquellen herstellen. Dabei können Anmeldedaten verwendet werden, die
in den Workflow eingebettet und durch Verstecken oder Benutzer/Rechner-(DPAPI)-Verschlüsselung (Legacy-Methode, nicht empfohlen) geschützt sein können.
zur Zeit der Ausführung vom DCMe-verschlüsseltem Speicher abgerufen werden können.
in einer verwalteten Datenverbindung oder Gallery Alias gespeichert sein können.
Bei verwalteten Datenverbindungen wird „ __ENCPWD__ “ in der Workflow-XML angezeigt. Die entsprechenden Anmeldedaten werden, je nachdem, wie die Datenverbindung konfiguriert wurde, in verschlüsselter Form in einer der folgenden XML-Dateien gespeichert:
%UserProfile%\AppData\Roaming\Alteryx\Engine\GalleryAlias.xml%ProgramData%\Alteryx\Engine\SystemAlias.xml%ProgramData%\Alteryx\Engine\SystemConnections.xml
Mit der integrierten Windows-Authentifizierung oder SAML ist Server nicht der Besitzer der Server-Benutzer-Anmeldedaten. Sie werden auch von ihm nicht gespeichert.
Für die integrierte Authentifizierung werden die Server-Benutzer-Anmeldedaten gehasht, mit Salts versehen und erneut gehasht.
Interne vertrauliche Daten, wie das Controller-Token und das MongoDB-Kennwort, werden auf jedem Computer mithilfe der Windows Crypto-API verschlüsselt. Die Schlüssel befinden sich an diesem Speicherort:
%Programme\Microsoft\Crypto\\RSA\MachineKeys
. Weitere Informationen finden Sie auf der Hilfeseite
Controller
.
Digitale Zertifikate
Ein digitales Zertifikat ist ein Nachweis für die Identität Ihres Servers, der von einer vertrauenswürdigen Zertifizierungsstelle signiert wird. Um verschlüsselte Verbindungen vom Client-Browser zum Server ordnungsgemäß zu unterstützen, müssen Sie ein digitales Zertifikat für den Server erstellen und es von einer Zertifizierungsstelle signieren lassen, der Ihr Unternehmen vertraut, bevor Sie es auf dem/den Server-Host(s) installieren. Weitere Informationen finden Sie unter SSL/TLS für Server konfigurieren .