Provider di dati per sicurezza e protezione di DB2
È possibile usare i provider di dati per DB2 (provider di dati) per connettere le applicazioni consumer di dati Windows ai server di gestione di database relazionali IBM DB2 remoti. Il provider di dati funge da client DRDA (Distributed Relational Database Architecture) che supporta il protocollo DRDA e i formati compatibili con i prodotti server SERVER IBM DB2 che funzionano come server applicazioni DRDA.
È possibile usare il provider di dati eseguendo istruzioni del linguaggio di query strutturate. Queste istruzioni includono istruzioni del linguaggio di definizione dei dati per l'amministrazione e le istruzioni di gestione della manipolazione dei dati per le operazioni di lettura e scrittura. Il provider di dati connette le applicazioni client Windows ai database del server DB2 attraverso un protocollo di controllo di trasmissione tramite una rete TCP/IP (Internet Protocol) o SNA (Systems Network Architecture) a prestazioni elevate tramite il protocollo Internet (HPR/IP) che usano una o più delle funzionalità di sicurezza facoltative descritte più avanti in questo argomento.
Sicurezza
Account utente
Gli strumenti del provider di dati, lo strumento di accesso ai dati e i collegamenti dati, vengono eseguiti nel contesto di un account utente. L'account utente deve essere membro dei gruppi locali HIS Administrators e HIS Runtime Users.
Elenco Controllo di accesso cartelle
L'account utente richiede le impostazioni elenco Controllo di accesso cartelle associate al gruppo locale amministratori HIS e al gruppo locale utenti di runtime HIS.
Programmi\Microsoft Host Integration Server 2020
Programmi\Microsoft Host Integration Server 2020\system
Programmi\Microsoft Host Integration Server 2020\ SysWOW64
Programmi\Microsoft Host Integration Server 2020\traces
Documenti\Host Integration Server\Origini dati
Protezione
Le concessioni del provider di dati vengono eseguite nei pacchetti DB2 al gruppo pubblico DB2
Quando si creano pacchetti DB2, lo strumento di accesso ai dati e il provider di dati impostano le autorizzazioni di esecuzione per i pacchetti DB2 su PUBLIC, che include tutti gli utenti DB2. Per aumentare la sicurezza nel server DB2, è consigliabile revocare le autorizzazioni di esecuzione a PUBLIC per questi pacchetti e concedere autorizzazioni di esecuzione solo a utenti o gruppi DB2 selezionati.
Data Tools archivia le credenziali di autenticazione in testo normale nel file UDL (Universal Data Link) o stringa di connessione (TXT)
Creazione guidata origine dati e collegamenti dati archivia le credenziali di autenticazione (nome utente e password) in testo normale nel file UDL (Universal Data Link) o stringa di connessione (TXT). È consigliabile configurare i provider di dati per l'uso di Enterprise Single Sign-On (ESSO), che archivia in modo sicuro i mapping dagli account di Windows Active Directory alle credenziali IBM DB2. I provider di dati recuperano questi mapping in fase di esecuzione per autenticare in modo sicuro gli utenti di Windows nei server di database IBM DB2 remoti. È consigliabile eseguire il provider di dati in-process con i consumer di dati e gli strumenti di dati.
DRDA supporta la crittografia predefinita debole basata su DES
DRDA supporta l'autenticazione predefinita e la crittografia dei dati usando tecnologie des (Data Encryption Standard) a 56 bit deboli. È consigliabile configurare il provider di dati per l'uso della crittografia avanzata dei dati usando Secure Sockets Layer (SSL) V3.0 o Transport Layer Security (TLS) V2.0. Per crittografare soltanto l'autenticazione, è possibile usare Advanced Encryption Standard (AES) per supportare la crittografia a 256 bit.
Il provider di dati si connette usando testo non crittografato, testo normale, nome utente e password
Il provider di dati si connette a computer server DB2 remoti tramite una rete TCP/IP o SNA usando l'autenticazione di base, in cui il nome utente e la password non vengono crittografati e inviati in testo normale. È consigliabile configurare il provider di dati per l'uso della crittografia di autenticazione tramite Kerberos, SSL (Secure Sockets Layer) V3.0 o TLS (Transport Layer Security) V1.0 o la crittografia di autenticazione tramite AES.
Il provider di dati invia e riceve dati non crittografati
Il provider di dati invia e riceve dati non crittografati. Si consiglia di configurare il provider di dati per l'utilizzo della crittografia dei dati tramite il protocollo Secure Sockets Layer (SSL) V3.0 o Transport Layer Security (TLS) V1.0.
Standard di crittografia per DB2
Nella tabella seguente sono descritti gli standard di crittografia supportati da DB2.
| Crittografia | Authentication | Dati |
|---|---|---|
| Kerberos | Sì | No |
| SSL V3 | Sì | Sì |
| TLS V2 | Sì | Sì |
| AES | Sì | No |
Gli strumenti e i consumer di dati leggono e scrivono i file delle connessioni in cartelle non sicure
I consumer di dati e Data Tools possono leggere e scrivere file di connessione da e verso cartelle non sicure. È consigliabile archiviare file UDL (Universal Data Link) o stringa di connessione (TXT) nella directory Host Integration Server\Data Sources o in una directory del programma e quindi proteggere la cartella con diritti di amministratore locale. Rendere persistenti le informazioni relative alle connessioni negli archivi sicuri degli strumenti e dei consumer di dati e quindi eseguire il provider di dati in-process con gli strumenti e i consumer di dati.
Gli strumenti e i consumer di dati possono richiedere connessioni con proprietà non valide
I consumer di dati e Data Tools possono richiedere connessioni con valori di proprietà di connessione non validi. Usare i consumer di dati che creano connessioni con gli oggetti connessione del provider di dati anziché passare coppie nome-valore non verificate degli argomenti della stringa di connessione. Impostare un valore di timeout della connessione per annullare i tentativi di connessione non validi.
Consumer di dati e Strumenti dati possono richiedere comandi con dati non validi
I consumer di dati e Data Tools possono richiedere comandi con dati non validi. Per convalidare i tipi di parametro, usare i consumer di dati che creano comandi con il comando del provider di dati con oggetti parametro anziché passare stringhe di comando non verificate con valori di dati inline. Impostare un valore di timeout dei comandi per annullare i tentativi di comando non validi. Usare l'unità di lavoro distribuita (DUW, Distributed Unit of Work) DRDA, anziché l'unità di lavoro remota (RUW, Remote Unit of Work), per proteggere i consumer di dati usando transazioni di protocollo 2PC.