Protezione del livello dell'applicazione
Per proteggere il livello dell'applicazione, è bene prendere in considerazione strumenti come l'autenticazione dell'utente e del database, i certificati digitali e la crittografia.
Autenticazione utente incorporata
Con l'autenticazione incorporata di Server, gli utenti vengono autenticati tramite JavaScript lato client che richiama una funzione SHA256 locale per eseguire l'hash e il salting della password prima di inviare l'hash a Server per confrontarlo con quello della password nel database utente (memorizzato in MongoDB). Server memorizza solo il valore con hash e non vede mai il testo non crittografato della password di un utente.
Nota
È stato aggiornato l'algoritmo utilizzato per l'hash delle password per l'autenticazione incorporata. Nelle versioni precedenti alla 22.1, il client richiamava una libreria bcrypt locale per eseguire l'hash e il salting della password prima di inviare l'hash a Server.
Per ulteriori informazioni sugli altri metodi di autenticazione disponibili con Server, consulta la sezione Autenticazione del presente documento.
Autenticazione del database
Alteryx Server salva in modo permanente la maggior parte delle informazioni sulle applicazioni in un database Mongo integrato. Durante l'installazione, vengono generati un ID utente e una password dell'applicazione per accedere alle informazioni all'interno del database. Consulta la pagina dell'Aiuto Controller per altre opzioni del database, tra cui Mongo gestito dall'utente e MongoDB Atlas.
Crittografia del trasporto
La crittografia impedisce l'esposizione e la modifica di dati sensibili, quali password, informazioni sulle sessioni utente e transazioni, durante il trasporto. Si consiglia di crittografare le connessioni a Server utilizzando HTTPS con TLS 1.2+ per impedire l'intercettazione da parte di utenti non autorizzati. È possibile configurare HTTPS in Impostazioni di sistema; per garantire la negoziazione di TLS alla versione 1.2 o successiva, potrebbe essere necessario modificare le impostazioni di channel , come indicato nella sezione Protezione del livello del sistema operativo del presente documento.
Per ulteriori informazioni, consulta la pagina Configurazione di SSL/TLS per Server .
Sicurezza dei dati inattivi
Durante l'esecuzione del processo, Server crea evidenze durevoli sotto forma di file temporanei, meta informazioni e file di log. Questi dati inattivi vengono memorizzati fisicamente nell'archivio locale di Mongo DB e di Server. Di seguito sono riportate alcuni dubbi comuni riguardo ai dati inattivi, insieme alle tecniche che possono essere implementate per risolverli.
Nota
Le istanze di MongoDB Enterprise o MongoDB Atlas gestite dall'utente supportano la crittografia per i dati inattivi. Per ulteriori informazioni, consulta la documentazione relativa a Mongo DB .
I file temporanei in formato YXDB sono utilizzati per memorizzare i dati durante l'esecuzione dei processi Alteryx. Questi file possono contenere dati effettivi che vengono trasmessi attraverso il flusso di lavoro in fase di esecuzione.
I file temporanei sono definiti per ambito nelle chiamate all'engine ed eliminati non appena non sono più necessari dai processi a valle o al termine dell'esecuzione del flusso di lavoro di Alteryx. Questi file a volte possono rimanere indietro se il processo Alteryx subisce un arresto anomalo. Anche in questo caso, i file temporanei verranno comunque eliminati automaticamente al riavvio del servizio.
La directory di primo livello in cui sono memorizzati i file temporanei è impostata in Impostazioni di sistema > Impostazioni dell'engine > Directory temporanea in Alteryx Server. Ogni chiamata all'engine memorizza i singoli file temporanei in una sottodirectory separata in questo percorso.
Protezione avanzata dell'archiviazione dei file temporanei
Segui questi suggerimenti per migliorare ulteriormente la protezione dei file temporanei.
Accertati che la RAM (memoria) sia adeguata, in modo che Alteryx utilizzi meno spazio su disco (swap).
Deseleziona l'opzione Consenti agli utenti di ignorare queste impostazioni in Impostazioni di sistema > Impostazioni dell'engine per impedire agli utenti di scrivere in altre posizioni. Per maggiori informazioni, vai alla pagina Engine della guida.
Deseleziona l'opzione Sfoglia ovunque nelle impostazioni in Impostazioni di sistema > Impostazioni dell'engine per impedire la creazione del file Sfoglia ovunque (YXBE) di Alteryx.
Individua la directory dei file temporanei su un'unità crittografata (ad esempio, utilizzando BitLocker).
Escludi la directory dei file temporanei dai backup automatici.
Quando l'autenticazione è configurata per SSO o IWA, Server non possiede né memorizza le credenziali utilizzate per l'accesso. Quando si utilizza l'autenticazione incorporata di Server, vengono memorizzati solo gli hash delle password con salt.
Le password utilizzate da Server per l'autenticazione al MongoDB di supporto sono crittografate con dati inattivi utilizzando le funzioni crittografiche fornite dal sistema operativo.
I log di Server consentono di tenere traccia di errori, avvisi, informazioni e messaggi di debug. I file di log contengono informazioni sugli eventi di Server, i flussi di lavoro, i file di dati utilizzati e il numero di record elaborati in un determinato processo. Non includono i dati effettivi che vengono utilizzati, elaborati o inviati. I log vengono raccolti per l'engine, il nodo dell'interfaccia utente di Server e il servizio Alteryx.
Se i flussi di lavoro non vengono caricati, contatta l'assistenza clienti.
I log vengono salvati su Server nelle seguenti posizioni:
I log dei nodi dell'interfaccia utente di Server sono memorizzati in
C:\ProgramData\Alteryx\Gallery\Logse hanno un nome simile a: alteryx-2017-09-13.csv.I log di Server/del servizio sono memorizzati in
C:\ProgramData\Alteryx\Servicee presentano nomi come: AlteryxServiceLog_2017-06-04_00-46-07.log, con l'ultimo log nominato: AlteryxServiceLog.logI log dell'engine sono disattivati per impostazione predefinita, ma possono essere attivati in Impostazioni di sistema.
Nota
I log dell'engine possono contenere analisi dello stack o messaggi di errore restituiti da altri processi che l'engine chiama o richiama durante l'esecuzione del flusso di lavoro e tali messaggi possono esporre potenzialmente i dati o i metadati passati al processo esterno. Per questo motivo, si consiglia di abilitare i log dell'engine solo durante la risoluzione dei problemi attiva da parte di personale autorizzato.
I log a livello di sistema sono disponibili nel visualizzatore eventi di Windows.
Sicurezza dei dati in movimento
I componenti di Alteryx Server trasferiscono dati e flussi di lavoro. In diversi punti del processo di trasferimento, i dati in movimento vengono crittografati o esposti, a seconda della configurazione.
Per l'interfaccia utente front-end di Server l'impostazione predefinita è HTTP (testo non crittografato sulla porta TCP 80). Si consiglia di configurare Server per HTTPS (SSL/TLS sulla porta 443).
Anche la comunicazione tra nodi all'interno di un cluster distribuito di Server (consulta Tipi di distribuzione nel presente documento) utilizza la porta 80, ma con crittografia AES-256 utilizzando il token del controller, il salt e le informazioni su data e ora. Ciò garantisce un payload sicuro e con rigidi requisiti temporali.
MongoDB integrato in esecuzione sul controller è in ascolto su un socket TCP/IP non crittografato (porta TCP 27018). In un'istanza di Server all-in-one il listener del socket è solo localhost e non deve essere esposto alla rete. Se esegui un Server distribuito (consulta Tipi di distribuzione nel presente documento) con MongoDB integrato, le connessioni da altri nodi del cluster al MongoDB del controller non saranno crittografate. Per crittografare le comunicazioni del database con TLS/SSL, è necessario passare a una versione di MongoDB gestita dall'utente (o MongoDB Atlas).
I metodi di crittografia per le origini dati (Oracle e SQL Server) e le piattaforme di report (Tableau e PowerBI) sono definiti da un connettore o un driver ODBC di terze parti.
I dati in esecuzione sono protetti tramite hash e salting delle password, nonché attraverso la generazione di token API per il client in esecuzione. Queste procedure sono documentate nella sezione Protezione avanzata di Server del presente documento. Per una protezione completa dei dati in esecuzione, si consiglia di crittografare le connessioni a Server con HTTPS utilizzando TLS 1.2 o versioni successive.
Archiviazione delle credenziali
A seconda della configurazione e dell'utilizzo, Server può memorizzare diverse credenziali. Verifica come vengono gestite queste informazioni sensibili.
Un flusso di lavoro in esecuzione può collegarsi a più origini dati esterne utilizzando credenziali che possono essere
incorporate in linea nel flusso di lavoro e protette tramite crittografia Hide o User/Machine (DPAPI) (metodo legacy, non consigliato)
ottenute dall'archiviazione crittografata DCMe al momento dell'esecuzione
memorizzate in una connessione dati gestita o in un alias della Gallery.
Per le connessioni dati gestite, apparirà " __ENCPWD__ " nell'XML del flusso di lavoro e la credenziale corrispondente verrà memorizzata in forma crittografata in uno dei seguenti file XML, a seconda della modalità di configurazione della connessione dati:
%UserProfile%\AppData\Roaming\Alteryx\Engine\GalleryAlias.xml%ProgramData%\Alteryx\Engine\SystemAlias.xml%ProgramData%\Alteryx\Engine\SystemConnections.xml
Con l'autenticazione Windows integrata o SAML, le credenziali utente di Server non sono di proprietà di Server o memorizzate al suo interno.
Per l'autenticazione incorporata, le credenziali utente di Server vengono sottoposte ad hashing e salting, quindi nuovamente ad hashing.
I segreti interni, come il token del controller e la password Mongo DB, vengono crittografati per computer utilizzando l'API Crypto di Windows con le chiavi nel percorso:
%ProgramData%\Microsoft\Crypto\RSA\MachineKeys
. Per uteriori informazioni, consulta la pagina dell'Aiuto
Controller
.
Certificati digitali
Un certificato digitale è la prova dell'identità di Server firmata da un'autorità di certificazione attendibile. Per supportare correttamente le connessioni crittografate dal browser client a Server, è necessario creare un certificato digitale per Server e farlo firmare da un'autorità di certificazione di fiducia dell'organizzazione prima dell'installazione sugli host di Server. Per ulteriori informazioni, consulta la pagina Configurazione di SSL/TLS per Server .