1c Richiesta troppo complessa, possibile stack overflow. Stack overflow. Crittografia dei dati durante la trasmissione tra il server delle applicazioni e MS SQL Server

Questo articolo dimostra ancora una volta che qualsiasi insieme di misure di sicurezza dovrebbe coprire tutte le fasi dell'implementazione: sviluppo, distribuzione, amministrazione del sistema e, naturalmente, misure organizzative. Nei sistemi informativi, è il "fattore umano" (inclusi gli utenti) la principale minaccia alla sicurezza. Questo insieme di misure deve essere ragionevole ed equilibrato: non ha senso ed è improbabile che vengano stanziati fondi sufficienti per l'organizzazione della protezione, che supera il costo dei dati stessi.

introduzione

1C: Enterprise è il sistema di contabilità più diffuso in Russia, ma nonostante ciò, fino alla versione 8.0 i suoi sviluppatori prestavano pochissima attenzione ai problemi di sicurezza. Fondamentalmente, ovviamente, questo è stato dettato dalla nicchia di prezzo del prodotto e dall'attenzione per le piccole imprese dove non ci sono specialisti IT qualificati, e il possibile costo di implementazione e mantenimento di un sistema sicuro sarebbe proibitivo per l'azienda. Con il rilascio della versione 8.0, l'attenzione dovrebbe essere cambiata: il costo delle soluzioni è aumentato in modo significativo, il sistema è diventato molto più scalabile e flessibile - i requisiti sono cambiati in modo significativo. Se il sistema è diventato sufficientemente affidabile e sicuro è una questione molto individuale. Il sistema informativo principale di un'impresa moderna deve soddisfare almeno i seguenti requisiti di sicurezza:

Una probabilità piuttosto bassa di guasto del sistema a causa di motivi interni.
Autorizzazione utente affidabile e protezione dei dati da azioni errate.
Sistema efficace per l'assegnazione dei diritti utente.
Sistema di backup e ripristino online in caso di guasto.

Le soluzioni basate su 1C: Enterprise 8.0 soddisfano tali requisiti? Non c'è una risposta unica. Nonostante i cambiamenti significativi nel sistema di controllo degli accessi, ci sono ancora molti problemi irrisolti. A seconda di come il sistema è sviluppato e configurato, tutti questi requisiti potrebbero non essere soddisfatti o sono soddisfatti in misura sufficiente per questa implementazione, tuttavia, vale la pena prestare attenzione (e questa è una conseguenza significativa della "giovinezza" della piattaforma ) che per soddisfare pienamente le condizioni elencate è necessario compiere sforzi veramente titanici.

Questo articolo è destinato agli sviluppatori e agli implementatori di soluzioni sulla piattaforma 1C: Enterprise, nonché agli amministratori di sistema delle organizzazioni in cui viene utilizzato 1C: Enterprise e descrive alcuni aspetti dello sviluppo e della configurazione della versione client-server del sistema da punto di vista dell'organizzazione. informazioni di sicurezza... Questo articolo non può essere utilizzato in sostituzione della documentazione, ma indica solo alcuni punti che non sono ancora stati riflessi in esso. E, naturalmente, né questo articolo né tutta la documentazione saranno in grado di riflettere la complessità del problema della costruzione di un sistema informativo sicuro, che deve soddisfare contemporaneamente i requisiti contrastanti di sicurezza, prestazioni, praticità e funzionalità.

Classificazione e terminologia

L'argomento chiave di questo articolo sono le minacce informatiche.

Minaccia di informazioni- la possibilità che i dati vengano letti, copiati, modificati o bloccati senza autorizzazione.

E, in base a questa definizione, l'articolo classifica le minacce informatiche come segue:

Distruzione non autorizzata dei dati
Modifica non autorizzata dei dati
Copia non autorizzata dei dati
Lettura non autorizzata dei dati
Inaccessibilità dei dati

Tutte le minacce sono divise in intenzionali e non intenzionali. La minaccia alle informazioni implementata sarà chiamata incidente... Le caratteristiche del sistema sono:

Vulnerabilità- caratteristiche che portano a incidenti Misure protettive- caratteristiche che bloccano la possibilità di un incidente

In sostanza vengono considerati solo quei casi la cui probabilità è dovuta all'utilizzo della piattaforma tecnologica 1C: Enterprise 8.0 nella versione client-server (di seguito, nei casi in cui ciò non contraddica il significato di solo 1C o 1C 8.0 ). Definiamo i seguenti ruoli principali in relazione all'utilizzo del sistema:

operatori- utenti che hanno diritti di visualizzazione e modifica dei dati limitati al ruolo dell'applicazione, ma non hanno funzioni amministrative
Amministratori di sistema- utenti che dispongono di diritti amministrativi nel sistema, inclusi diritti amministrativi nei sistemi operativi dell'application server e del server MS SQL, diritti amministrativi su MS SQL, ecc.
Amministratori della sicurezza delle informazioni- utenti a cui sono delegate determinate funzioni amministrative nell'infobase 1C (come aggiunta di utenti, test e correzione, backup, impostazione di una soluzione applicata, ecc.)
Sviluppatori di sistemi- utenti che sviluppano una soluzione applicata. In generale, potrebbero non avere accesso al sistema di lavoro.
Persone senza accesso diretto al sistema- utenti a cui non sono delegati i diritti di accesso 1C, ma che, in un modo o nell'altro, possono influenzare il funzionamento del sistema (di solito si tratta di tutti gli utenti dello stesso dominio Active Directory in cui è installato il sistema). Questa categoria è considerata principalmente per identificare i soggetti potenzialmente pericolosi nel sistema.
Script amministrativi automatizzati- programmi a cui sono delegate alcune funzioni, progettati per eseguire automaticamente determinate azioni (ad esempio, import-export di dati)

È opportuno notare qui due punti: in primo luogo, questa classificazione è molto approssimativa e non tiene conto delle divisioni all'interno di ciascun gruppo - tale divisione verrà creata per alcuni casi specifici e, in secondo luogo, si presume che altre persone non possano influenzare il funzionamento del sistema, che deve essere dotato di mezzi esterni a 1C.

Qualsiasi sistema di sicurezza deve essere progettato tenendo conto della fattibilità e del costo di proprietà. In generale, nello sviluppo e nell'implementazione di un sistema informativo, è necessario che il prezzo della protezione del sistema corrisponda a:

il valore delle informazioni da proteggere;
il costo della creazione di un incidente (in caso di minaccia deliberata);
rischi finanziari in caso di incidente

È insensato e dannoso organizzare una protezione molto più costosa che valutarne l'efficacia finanziaria. Esistono diversi metodi per valutare i rischi di perdita di informazioni, ma non sono considerati in questo articolo. Un altro aspetto importante è mantenere un equilibrio tra requisiti spesso contrastanti per la sicurezza delle informazioni, le prestazioni del sistema, la praticità e la semplicità di utilizzo del sistema, la velocità di sviluppo e implementazione e altri requisiti per i sistemi informativi delle imprese.

Le principali caratteristiche del meccanismo di sicurezza delle informazioni del sistema

1C: Enterprise 8.0 è disponibile in due versioni: file e client-server. La versione del file non può essere considerata una garanzia di sicurezza delle informazioni del sistema per i seguenti motivi:

I dati e la configurazione sono memorizzati in un file che può essere letto e scritto da tutti gli utenti del sistema.
Come verrà mostrato di seguito, l'autorizzazione del sistema è molto facile da aggirare.
L'integrità del sistema è assicurata solo dal cuore del lato client.

Nella versione client-server, MS SQL Server viene utilizzato per memorizzare le informazioni, che fornisce:

Archiviazione dei dati più affidabile.
Isolamento dei file dall'accesso diretto.
Migliori meccanismi di transazione e blocco.

Nonostante le differenze significative tra le versioni file e client-server del sistema, hanno un unico schema di controllo degli accessi a livello di soluzione applicativa, che fornisce le seguenti funzionalità:

Autorizzazione dell'utente tramite la password specificata in 1C.
Autorizzazione dell'utente da parte dell'attuale utente di Windows.
Assegnazione di ruoli agli utenti del sistema.
Limitazione dell'esecuzione delle funzioni amministrative per ruolo.
Assegnazione delle interfacce disponibili per ruolo.
Limitazione dell'accesso agli oggetti dei metadati per ruolo.
Limitazione dell'accesso agli attributi degli oggetti in base al ruolo.
Limitazione dell'accesso agli oggetti dati per ruoli e parametri di sessione.
Limitazione dell'accesso interattivo ai dati e ai moduli eseguibili.
Alcune restrizioni sull'esecuzione del codice.

In generale, lo schema di accesso ai dati utilizzato è abbastanza tipico per i sistemi informativi di questo livello. Tuttavia, in relazione a questa implementazione dell'architettura client-server a tre livelli, esistono diversi aspetti fondamentali che portano a un numero relativamente elevato di vulnerabilità:

Un gran numero di fasi di elaborazione dei dati e, in ogni fase, possono essere applicate regole diverse per l'accesso agli oggetti.

Un diagramma un po' semplificato delle fasi di elaborazione dei dati che sono significative dal punto di vista della sicurezza è mostrato in Fig. 1. La regola generale per 1C è ridurre le restrizioni man mano che ci si sposta verso il basso lungo questo schema, quindi, sfruttando una vulnerabilità su uno dei livelli superiori può interrompere il funzionamento del sistema a tutti i livelli.
Procedure insufficientemente debuggate per il controllo dei dati trasmessi quando si passa da un livello all'altro.

Sfortunatamente, non tutti i meccanismi interni del sistema sono perfettamente debugcati, specialmente per i meccanismi non interattivi, il cui debug è sempre più lungo da un lato, ma dall'altro più responsabile. Questa "malattia" non è un problema esclusivamente per 1C, si trova in molti prodotti server della maggior parte dei fornitori. Solo negli ultimi anni l'attenzione a questi problemi è aumentata in modo significativo.
Qualifiche medie di sviluppatori e amministratori di sistema non sufficientemente elevate ereditate dalla versione precedente.

I prodotti della linea 1C: Enterprise erano inizialmente focalizzati sulla facilità di sviluppo e supporto e per lavorare in piccole organizzazioni, quindi non sorprende che storicamente una parte significativa degli "sviluppatori" di soluzioni applicative e degli "amministratori" di sistemi non avere conoscenze e competenze sufficienti per lavorare con un prodotto molto più complesso, che è la versione 8.0. Il problema è aggravato dalla pratica adottata nelle società in franchising di allenarsi "in battaglia" a spese dei clienti, senza affrontare questo tema in modo sistematico. È necessario rendere omaggio a 1C che negli ultimi anni questa situazione è andata gradualmente migliorando: le società in franchising serie sono diventate un approccio più responsabile al problema del reclutamento e della formazione del personale, il livello di supporto informatico di 1C è aumentato in modo significativo, sono apparsi programmi di certificazione incentrati su un alto livello di servizio; tuttavia, la situazione non può essere immediatamente corretta, quindi questo fattore dovrebbe essere preso in considerazione quando si analizza la sicurezza del sistema.
Età relativamente piccola della piattaforma.

Tra i prodotti con un focus e uno scopo di utilizzo simili, questa è una delle soluzioni più giovani. La funzionalità della piattaforma è stata più o meno risolta meno di un anno fa. Allo stesso tempo, ogni versione della piattaforma, a partire dalla 8.0.10 (è in questa versione che sono state implementate quasi tutte le funzionalità attuali del sistema) è diventata molto più stabile delle precedenti. La funzionalità delle tipiche soluzioni applicative sta ancora crescendo a passi da gigante, sebbene venga utilizzata al massimo la metà delle capacità della piattaforma. Naturalmente, in tali condizioni, possiamo parlare di stabilità in modo piuttosto provvisorio, ma nel complesso, bisogna ammettere che per molti aspetti le soluzioni sulla piattaforma 1C 8.0 superano in modo significativo soluzioni simili sulla piattaforma 1C 7.7 in termini di funzionalità e prestazioni ( e spesso anche in termini di stabilità).

Quindi, il sistema (e, possibilmente, una tipica soluzione applicativa) viene distribuito nell'azienda e installato sui computer. Prima di tutto, è necessario creare un ambiente in cui ha senso configurare la sicurezza 1C, e per questo deve essere configurato in modo tale che sia soddisfatta l'ipotesi che le impostazioni di sistema siano significativamente influenzate dalle impostazioni di sistema.

Segui le regole generali per impostare la sicurezza.

Non si può parlare di sicurezza delle informazioni del sistema se non vengono seguiti i principi di base della creazione di sistemi sicuri. Assicurati che siano soddisfatte almeno le seguenti condizioni:

L'accesso ai server è fisicamente limitato e il loro funzionamento ininterrotto è assicurato:
- le apparecchiature server soddisfano i requisiti di affidabilità, viene messa a punto la sostituzione delle apparecchiature server difettose, per aree particolarmente critiche vengono utilizzati circuiti ridondanti hardware(RAID, alimentazione da più fonti, più canali di comunicazione, ecc.);
- i server si trovano in una stanza chiusa a chiave e questa stanza viene aperta solo per la durata del lavoro che non può essere eseguito da remoto;
- solo una o due persone hanno il diritto di aprire la sala server, in caso di emergenza è stato sviluppato un sistema di notifica per le persone responsabili;
- viene fornita un'alimentazione ininterrotta dei server
- sia assicurata la normale modalità climatica di funzionamento dell'apparecchiatura;
- c'è un allarme antincendio nella sala server, non c'è possibilità di allagamento (soprattutto per il primo e l'ultimo piano);
Le impostazioni della rete e dell'infrastruttura informativa dell'impresa sono corrette:
- tutti i server hanno firewall installati e configurati;
- tutti gli utenti ei computer sono autorizzati sulla rete, le password sono abbastanza complesse da essere impossibili da indovinare;
- gli operatori di sistema hanno diritti sufficienti per lavorare normalmente con esso, ma non hanno i diritti per azioni amministrative;
- gli strumenti antivirus sono installati e abilitati su tutti i computer della rete;
- è auspicabile che gli utenti (ad eccezione degli amministratori di rete) non dispongano di diritti amministrativi sulle postazioni client;
- l'accesso a Internet e ai supporti rimovibili dovrebbe essere regolamentato e limitato;
- deve essere configurato l'audit di sistema degli eventi di sicurezza;
I principali problemi organizzativi sono stati risolti:
- gli utenti hanno qualifiche sufficienti per lavorare con 1C e hardware;
- gli utenti sono informati della responsabilità per violazione delle regole operative;
- nominato finanziariamente responsabile di ogni elemento materiale del sistema informativo;
- Tutti blocchi di sistema sigillato e chiuso;
- Prestare particolare attenzione all'istruzione e alla supervisione di addetti alle pulizie, costruttori ed elettricisti. Tali soggetti possono, per negligenza, arrecare un danno non assimilabile a quello del danno doloso causato da un utilizzatore senza scrupoli del sistema.

Attenzione! Questo elenco non è esaustivo, ma descrive solo ciò che spesso viene trascurato quando si implementa un sistema informativo abbastanza complesso e costoso!

MS SQL Server, server applicazioni e lato client funzionano su computer diversi, le applicazioni server funzionano con i diritti di appositamente creati Utenti Windows;
Per MS SQL Server
- è impostata la modalità di autorizzazione mista
- Gli utenti MS SQL inclusi nel ruolo serveradmin non partecipano a 1C,
- per ogni IS 1C è stato creato un utente MS SQL separato che non ha accesso privilegiato al server,
- L'utente MS SQL di una sicurezza delle informazioni non ha accesso a un'altra sicurezza delle informazioni;
Gli utenti non hanno accesso diretto ai file di Application Server e MS SQL Server
Le postazioni di lavoro degli operatori sono dotate di Windows 2000/XP (non Windows 95/98/Me)

Non trascurare le raccomandazioni degli sviluppatori di sistema e la lettura della documentazione. Sui dischi dell'ITS nella sezione "Raccomandazioni metodologiche" sono pubblicati importanti materiali sulla configurazione del sistema. Presta particolare attenzione ai seguenti articoli:

Le funzionalità dell'applicazione funzionano con il server 1C: Enterprise
Posizionamento dati 1C: Enterprise 8.0
Aggiornamento di 1C: Enterprise 8.0 da parte degli utenti Microsoft Windows senza diritti di amministratore
Modifica dell'elenco degli utenti per conto di un utente che non dispone di diritti amministrativi
Configurazione delle impostazioni del firewall di Windows XP SP2 per eseguire SQL Server 2000 e SQL Server Desktop Engine (MSDE)
Configurazione dei parametri COM + Windows XP SP2 per 1C: funzionamento del server Enterprise 8.0
Configurazione dei parametri del firewall di Windows XP SP2 per 1C: funzionamento del server Enterprise 8.0
Configurazione delle impostazioni del firewall di Windows XP SP2 per HASP License Manager
Creazione di una copia di backup di un'infobase utilizzando SQL Server 2000
Domande di installazione e configurazione di 1C: Enterprise 8.0 nell'opzione "client-server"(uno degli articoli più importanti)
Peculiarità Impostazioni di Windows Server 2003 durante l'installazione di 1C: server Enterprise 8.0
Regolazione dell'accesso degli utenti all'infobase nella versione client-server(uno degli articoli più importanti)
Server 1C: Enterprise e SQL Server
Procedura dettagliata per l'installazione di 1C: Enterprise 8.0 nella versione "client-server"(uno degli articoli più importanti)
Utilizzo della lingua incorporata sul server 1C: Enterprise

Ma, leggendo la documentazione, sii critico nei confronti delle informazioni ricevute, ad esempio, nell'articolo "Domande sull'installazione e la configurazione di 1C: Enterprise 8.0 nella versione" client-server "", i diritti richiesti per l'utente USER1CV8SERVER non sono descritto in modo abbastanza accurato. Ci saranno collegamenti all'elenco sottostante, ad esempio [ITS1] significa l'articolo "Peculiarità del lavoro con 1C: Enterprise server". Tutti i collegamenti agli articoli sono forniti a partire dall'ultimo numero di ITS al momento della stesura (gennaio 2006)

Utilizzare le funzionalità di autorizzazione per gli utenti combinate con l'autorizzazione di Windows

Delle due possibili modalità di autorizzazione dell'utente: 1C integrata e combinata con l'autorizzazione del sistema operativo Windows - se possibile, dovresti scegliere l'autorizzazione combinata. Ciò consentirà agli utenti di non essere confusi con più password mentre lavorano, ma non ridurrà il livello di sicurezza del sistema. Tuttavia, anche per gli utenti che utilizzano solo l'autorizzazione di Windows, è altamente desiderabile impostare una password durante la creazione e solo dopo disabilitare l'autorizzazione 1C per dato utente... Per garantire il ripristino del sistema in caso di distruzione della struttura di Active Directory, è necessario lasciare almeno un utente che possa accedere al sistema utilizzando l'autorizzazione 1C.

Quando si creano ruoli di soluzione applicativa, non aggiungere diritti "di riserva"

Ciascun ruolo della soluzione applicativa deve riflettere il set minimo di diritti richiesto per eseguire le azioni definite da questo ruolo. Tuttavia, alcuni ruoli potrebbero non essere utilizzati da soli. Ad esempio, per il lancio interattivo trattamenti esterni puoi creare un ruolo separato e aggiungerlo a tutti gli utenti che devono utilizzare l'elaborazione esterna.

Rivedere regolarmente i registri e i registri di sistema

Quando possibile, regola e automatizza la revisione dei log e dei protocolli di funzionamento del sistema. Con una corretta configurazione e una revisione regolare dei log (filtrando solo gli eventi importanti), le azioni non autorizzate possono essere rilevate in anticipo o addirittura prevenute durante la fase di preparazione.

Alcune caratteristiche della versione client-server

Questa sezione descrive alcune delle caratteristiche della versione client-server e il loro impatto sulla sicurezza. Per una migliore leggibilità, sono accettate le seguenti designazioni:

Attenzione! descrizione della vulnerabilità

Memorizzazione delle informazioni che controllano l'accesso al sistema

Memorizzazione di un elenco di utenti della sicurezza delle informazioni

Tutte le informazioni sull'elenco degli utenti di questo IS e sui ruoli disponibili in esso sono archiviate nella tabella Params nel database MS SQL (vedi [ITS2]). Guardando la struttura e il contenuto di questa tabella, diventa ovvio che tutte le informazioni sull'utente sono memorizzate in un record, con il valore del campo FileName "users.usr".

Poiché assumiamo che gli utenti non abbiano accesso al database MS SQL, questo fatto di per sé non può essere utilizzato da un utente malintenzionato, tuttavia, se è possibile eseguire il codice in MS SQL, questo "apre la porta" per ottenere qualsiasi ( !) Accesso da 1C ... Lo stesso meccanismo (con piccole modifiche) può essere utilizzato per la versione file del sistema, che, date le peculiarità della versione file, esclude completamente la sua applicabilità nella costruzione di sistemi sicuri.

Raccomandazione: Attualmente, non esiste alcun modo per proteggere completamente l'applicazione da tale modifica, ad eccezione dell'uso di trigger a livello di MS SQL Server, che, d'altra parte, può causare problemi durante l'aggiornamento della versione della piattaforma o la modifica dell'elenco degli utenti . Per tenere traccia di tali modifiche è possibile utilizzare i log 1C (facendo attenzione agli accessi "sospetti" in modalità configuratore senza specificare un utente) oppure mantenere costantemente in esecuzione SQL Profiler (che avrà un effetto estremamente negativo sulle prestazioni del sistema) oppure configurare gli Alert meccanismo (molto probabilmente, insieme usando i trigger)

Memorizzazione delle informazioni sull'elenco IS sul server

Per ogni server applicativo 1C vengono memorizzate le informazioni sull'elenco dei database MS SQL ad esso collegati. Ogni infobase utilizza la propria stringa di connessione tra il server delle applicazioni e il server MS SQL. Le informazioni sulle infobase registrate sul server delle applicazioni insieme alle stringhe di connessione sono memorizzate nel file srvrib.lst, che si trova sul server nella directory<Общие данные приложений>/ 1C / 1Cv8 (ad esempio, C: / Documenti e impostazioni / Tutti gli utenti / Dati applicazione / 1C / 1Cv8 / srvrib.lst). Per ogni IB, viene memorizzata una stringa di connessione completa, inclusa la password utente MS SQL quando si utilizza il modello di autorizzazione misto MS SQL. È la presenza di questo file che consente di temere accessi non autorizzati al database MS SQL e se, contrariamente alle raccomandazioni, viene utilizzato un utente privilegiato (ad esempio "sa") per accedere ad almeno un database, allora oltre alla minaccia di un IS, è minacciato l'intero sistema che utilizza MS SQL.

È interessante notare che l'uso dell'autorizzazione mista e dell'autorizzazione Windows sul server MS SQL porta a diversi tipi di problemi durante l'accesso a questo file. Quindi le principali proprietà negative dell'autorizzazione di Windows saranno:

Il funzionamento di tutta la sicurezza delle informazioni sul server delle applicazioni e sul server MS SQL con un unico insieme di diritti (molto probabilmente ridondante)
Dal processo dell'application server 1C (o, in generale, dall'utente USER1CV8SERVER o suo equivalente) senza specificare una password, è possibile connettersi facilmente a qualsiasi sicurezza delle informazioni senza specificare una password

D'altra parte, potrebbe essere più difficile per un utente malintenzionato eseguire codice arbitrario dal contesto dell'utente USER1CV8SERVER piuttosto che recuperare il file specificato. A proposito, la presenza di un tale file è un altro argomento per la separazione delle funzioni del server su computer diversi.

Raccomandazione: Il file srvrib.lst dovrebbe essere accessibile solo al processo del server. Assicurati di impostare un controllo per modificare questo file.

Sfortunatamente, per impostazione predefinita questo file è quasi completamente illeggibile, il che deve essere preso in considerazione durante la distribuzione del sistema. L'opzione ideale sarebbe se il server delle applicazioni impedisse la lettura e la scrittura di questo file durante l'operazione (inclusa la lettura e la scrittura da parte delle connessioni utente in esecuzione su questo server).

Mancanza di autorizzazione durante la creazione della sicurezza delle informazioni sul server

Attenzione! L'errore di autorizzazione è stato corretto nella versione 8.0.14 della piattaforma 1C: Enterprise. Questa versione introduce il concetto di "1C: Enterprise Server Administrator", ma mentre l'elenco degli amministratori è specificato sul server, il sistema funziona come descritto di seguito, quindi non dimenticare questa possibile funzionalità.

Probabilmente la più grande vulnerabilità di questa sezione è la capacità di aggiungere una sicurezza delle informazioni quasi illimitata al server delle applicazioni, in conseguenza della quale qualsiasi utente che ha accesso alla connessione al server delle applicazioni ha automaticamente l'opportunità di eseguire codice arbitrario sul server delle applicazioni . Diamo un'occhiata a un esempio.

Il sistema deve essere installato nella seguente variante

MS SQL Server 2000 (ad es. nome di rete SRV1)
Server 1C: Enterprise 8.0 (nome di rete SRV2)
Parte client di 1C: Enterprise 8.0 (nome rete WS)

Si presume che l'utente (di seguito USER) che lavora su WS abbia almeno un accesso minimo a uno degli IB registrati su SRV2, ma non abbia accesso privilegiato a SRV1 e SRV2. In generale, la combinazione di funzioni da parte dei computer elencati non influisce sulla situazione. Il sistema è stato configurato tenendo conto delle raccomandazioni nella documentazione e sui dischi ITS. La situazione è riflessa in Fig. 2.

configurare la sicurezza COM + sul server delle applicazioni in modo che solo gli utenti 1C abbiano il diritto di connettersi al processo del server delle applicazioni (per maggiori dettagli [ITS12]);

il file srvrib.lst deve essere di sola lettura per l'utente USER1CV8SERVER (abilitare temporaneamente la scrittura per aggiungere un nuovo IB al server);

per connetterti a MS SQL, usa solo il protocollo TCP/IP, in questo caso puoi:
limitare le connessioni utilizzando un firewall;

configurare l'uso di una porta TCP non standard, che complicherà la connessione di "estranei" IS 1C;

utilizzare la crittografia dei dati trasmessi tra il server delle applicazioni e il server SQL;

configurare il firewall del server in modo che sia impossibile utilizzare server MS SQL di terze parti;

utilizzare strumenti di sicurezza intranet per escludere la possibilità che un computer non autorizzato appaia in rete locale(IPSec, criteri di sicurezza di gruppo, firewall, ecc.);

in nessun caso concedere a USER1CV8SERVER diritti amministrativi sul server delle applicazioni.

Utilizzo del codice in esecuzione sul server

Quando si utilizza la versione client-server di 1C, lo sviluppatore può distribuire l'esecuzione del codice tra il client e il server delle applicazioni. Affinché il codice (procedura o funzione) venga eseguito solo sul server, è necessario inserirlo nel modulo generale per il quale è impostata la proprietà "Server" e, nel caso in cui l'esecuzione del modulo sia consentita non solo sul server, inserisci il codice nella sezione limitata "# If Server":

# Se server allora
Funzione OnServer (Param1, Param2 = 0) Export // Questa funzione, nonostante la sua semplicità, viene eseguita sul server
Param1 = Param1 + 12;
Ritorno di Param1;
EndFunction
# Finisci se

Quando si utilizza il codice eseguito sul server, tenere presente che:

il codice viene eseguito con i diritti USER1CV8SERVER sul server delle applicazioni (sono disponibili oggetti COM e file del server);
tutte le sessioni utente sono eseguite da un'istanza del servizio, quindi, ad esempio, un overflow dello stack sul server provocherà la disconnessione di tutti gli utenti attivi;
il debug dei moduli del server è difficile (ad esempio, non è possibile impostare un punto di interruzione nel debugger), ma deve essere eseguito;
il trasferimento del controllo dal client all'application server e viceversa può richiedere risorse significative con grandi volumi di parametri trasmessi;
utilizzo di strumenti interattivi (moduli, documenti del foglio di calcolo, finestre di dialogo), report esterni ed elaborazione del codice sul server delle applicazioni non è possibile;
non è consentito l'utilizzo di variabili globali (variabili del modulo applicativo dichiarate con l'indicazione “Esporta”);

Per maggiori dettagli vedere [ITS15] e altri articoli di ITS.

Il server delle applicazioni deve avere requisiti di affidabilità speciali. In un sistema client-server correttamente costruito, devono essere soddisfatte le seguenti condizioni:

nessuna azione dell'applicazione client deve interrompere il server (salvo casi amministrativi);
il server non può essere eseguito codice programma ricevuto dal cliente;
le risorse devono essere "equamente" distribuite tra le connessioni client, garantendo la disponibilità del server indipendentemente dal carico corrente;
in assenza di blocchi dei dati, le connessioni dei client non dovrebbero influire sul lavoro dell'altro;
non esiste un'interfaccia utente sul server, ma dovrebbero essere sviluppati strumenti di monitoraggio e registrazione;

In generale, il sistema 1C è costruito in modo tale da avvicinarsi a questi requisiti (ad esempio, è impossibile forzare l'esecuzione di elaborazioni esterne sul server), ma ci sono ancora diverse caratteristiche spiacevoli, quindi:

Raccomandazione: Quando si sviluppa il lato server dell'esecuzione, si consiglia di aderire al principio di un'interfaccia minima. Quelli. il numero di voci ai moduli server dall'applicazione client dovrebbe essere molto limitato ei parametri dovrebbero essere rigorosamente regolati. Raccomandazione: Quando si ricevono i parametri di procedure e funzioni sul server, è necessario convalidare i parametri (verificare se i parametri corrispondono al tipo e all'intervallo di valori previsti). Questo non viene fatto nelle soluzioni standard, ma è molto desiderabile introdurre la convalida obbligatoria nei propri progetti. Raccomandazione: Quando si genera il testo della richiesta (e ancor di più il parametro Run command) sul lato server, non utilizzare le stringhe ricevute dall'applicazione client.

La raccomandazione generale sarebbe quella di familiarizzare con i principi della costruzione sicura ragnatela- applicazioni di database e lavori su principi simili. La somiglianza è davvero notevole: in primo luogo, come un'applicazione web, l'application server è uno strato intermedio tra il database e l'interfaccia utente (la differenza principale è che il server web costituisce l'interfaccia utente); in secondo luogo, dal punto di vista della sicurezza, i dati ricevuti dal cliente non possono essere attendibili, poiché è possibile lanciare report ed elaborazioni esterne.

Passando i parametri

Il passaggio dei parametri a una funzione (procedura) eseguita sul server è una questione piuttosto delicata. Ciò è dovuto principalmente alla necessità di trasferirli tra il processo del server delle applicazioni e il client. Quando il controllo viene trasferito dal lato client al lato server, tutti i parametri trasmessi vengono serializzati, trasferiti al server, dove vengono "decompressi" e utilizzati. Quando si passa dal lato server al lato client, il processo viene invertito. Va notato qui che questo schema gestisce correttamente il passaggio dei parametri per riferimento e per valore. Quando si trasferiscono i parametri, si applicano le seguenti restrizioni:

Solo i valori non modificabili (ovvero i cui valori non possono essere modificati) possono essere trasferiti tra il client e il server (in entrambe le direzioni): tipi primitivi, riferimenti, collezioni universali, valori di enumerazione di sistema, memorizzazione dei valori . Se si tenta di trasferire qualcos'altro, l'applicazione client va in crash (anche se il server tenta di trasferire un parametro errato).
Non è consigliabile trasferire grandi quantità di dati durante il passaggio di parametri (ad esempio, stringhe di oltre 1 milione di caratteri), ciò potrebbe influire negativamente sulle prestazioni del server.
Non è possibile passare parametri contenenti un riferimento circolare, sia dal server al client, sia viceversa. Quando si tenta di passare tale parametro, l'applicazione client si arresta in modo anomalo (anche se il server tenta di passare un parametro errato).
Non è consigliabile trasferire raccolte di dati molto complesse. Quando si tenta di passare un parametro con un livello di annidamento molto grande, il server va in crash (!).

Attenzione! La caratteristica più spiacevole al momento è probabilmente l'errore di passare complesse raccolte di valori. Quindi, ad esempio, il codice: Nesting Level = 1250;
M = Nuovo array;
Parametro Trasmesso = M;
Per MF = 1 per ciclo di livelli di annidamento
MVint = Nuova matrice;
M. Aggiungi (MVintr);
M = MVintr;
Fine del ciclo;
ServerFunction (PassedParameter);

Causa l'arresto anomalo del server con tutti gli utenti disconnessi e ciò accade prima che il controllo venga trasferito al codice della lingua incorporata.

Utilizzo di funzioni non sicure sul lato server.

Non tutte le funzionalità del linguaggio incorporato possono essere utilizzate nel codice in esecuzione sul server delle applicazioni, ma anche tra gli strumenti disponibili ci sono molti costrutti "problematici" che possono essere approssimativamente classificati come segue:

in grado di fornire la possibilità di eseguire codice non contenuto nella configurazione (gruppo "Code Execution")
in grado di fornire all'applicazione client informazioni sul file e sul sistema operativo dell'utente o eseguire azioni non correlate all'utilizzo dei dati ("Violazione dei diritti")
in grado di provocare un arresto di emergenza del server o di utilizzare risorse molto grandi (gruppo "Server Failure")
in grado di causare un fallimento nel lavoro del cliente (il gruppo "Client Failure") - questo tipo non viene considerato. Esempio: passare un valore mutabile al server.
errori degli algoritmi di programmazione (loop infiniti, ricorsione illimitata, ecc.) ("Errori di programmazione")

I principali costrutti di problemi a me noti (con esempi) sono elencati di seguito:

Procedura Esegui (<Строка>)

Esecuzione del codice. Esegue una parte di codice che gli viene passata come valore stringa. Quando viene utilizzato sul server, è necessario assicurarsi che i dati ricevuti dal client non vengano utilizzati come parametro. Ad esempio, il seguente utilizzo non è valido:
# Se server allora
Procedura sul server (Param1) Esporta
Esegui (Param1);
Fine della procedura
# Finisci se

Digitare "COMObject" (costruttore Nuovo COMObject (<Имя>, <Имя сервера>))

Crea un oggetto COM dell'applicazione esterna con privilegi USER1CV8SERVER sul server delle applicazioni (o su un altro computer specificato). Quando viene utilizzato su un server, assicurarsi che nessun parametro venga passato dall'applicazione client. Tuttavia, lato server, è efficace utilizzare questa funzione durante l'importazione/esportazione, l'invio di dati su Internet, l'implementazione di funzioni non standard, ecc.

Funzione GetCOMObject (<Имя файла>, <Имя класса COM>)

Violazione dei diritti ed esecuzione del codice. Simile al precedente, ottenendo solo l'oggetto COM corrispondente al file.

Procedure e funzioni ComputerName (), TempFilesDirectory () ,ProgramsDirectory (), Utenti Windows ()

Violazione dei diritti. Consentire, dopo averli eseguiti sul server, di scoprire i dettagli dell'organizzazione del sottosistema del server. Quando vengono utilizzati su un server, assicurarsi che i dati non vengano trasmessi al client o non siano disponibili per gli operatori senza l'apposita autorizzazione. Prestare particolare attenzione al fatto che i dati possono essere restituiti in un parametro passato per riferimento.

Procedure e funzioni per lavorare con i file (CopyFile, FindFiles, CombineFiles e molti altri), così come i tipi "File".

Violazione dei diritti. Consentire, eseguendoli sul server, di ottenere l'accesso generale ai file locali (e situati sulla rete) accessibili con i diritti utente USER1CV8SERVER. Se utilizzato deliberatamente, è possibile implementare efficacemente attività come l'importazione/esportazione di dati sul server.

Assicurati di controllare i diritti utente 1C prima di utilizzare queste funzioni. Per verificare i diritti utente, è possibile utilizzare la seguente costruzione nel modulo server:
# Se server allora
Procedura ExecuteWork with File() Export
RoleAdministrator = Metadata.Role.Administrator;
Utente = SessionParameters.CurrentUser;
Se User.Roles.Contains (RoleAdministrator) Allora
// Qui è dove viene eseguito il codice per lavorare con i file
Finisci se;
# Finisci se
Assicurati di controllare i parametri se utilizzi queste procedure e funzioni, altrimenti c'è il rischio di causare danni irreparabili accidentalmente o deliberatamente al server delle applicazioni 1C, ad esempio, durante l'esecuzione del codice sul server:
Percorso = "C:\Documenti e impostazioni\Tutti gli utenti\Dati applicazione\1C\1Cv8\";
MoveFile (Path + "srvrib.lst", Path + "HereWhereFile");
Dopo aver eseguito tale codice sul server, se l'utente USER1CV8SERVER ha il permesso di modificarlo, come descritto sopra, e dopo aver riavviato il processo del server (per impostazione predefinita, 3 minuti dopo il logout di tutti gli utenti), sorgerà una GRANDE domanda sull'avvio del server . Ma è possibile e rimozione completa File ...

I tipi "XBase", "BinaryData", "Read XML", "Write XML", "Transform XSL", "Write ZipFile", "ReadZipFile", "ReadText", "WriteText"

Violazione dei diritti. Consentono, eseguendoli sul server, di accedere a file locali (e ubicati in rete) di determinati tipi e di leggerli/scriverli sotto i diritti utente USER1CV8SERVER. Se utilizzato deliberatamente, è possibile implementare efficacemente attività come l'importazione/esportazione di dati sul server, la registrazione di alcune funzioni e la soluzione di attività amministrative. In generale, le raccomandazioni sono le stesse del paragrafo precedente, ma dovresti prendere in considerazione la possibilità di trasferire i dati di questi file (ma non oggetti di tutti questi tipi) tra le parti client e server.

Tipo di informazioni di sistema

Violazione dei diritti. Consente, se i dati vengono utilizzati in modo errato e trasferiti alla parte client dell'applicazione, è possibile ottenere dati sul server delle applicazioni. Si consiglia di limitare il diritto di utilizzo durante l'utilizzo.

I tipi "InternetConnection", "InternetMail", "InternetProxy", "HTTPConnection", "FTPConnection"

Violazione dei diritti. Quando utilizzato sul server, si connette a un PC remoto dal server delle applicazioni con i diritti USER1CV8SERVER. Raccomandazioni:

Controllo dei parametri durante la chiamata dei metodi.

Controllo dei diritti degli utenti 1C.

Restrizioni severe sui diritti dell'utente USER1CV8SERVER di accedere alla rete.

Corretta configurazione del firewall sull'application server 1C.

Se utilizzato correttamente, è conveniente organizzare, ad esempio, l'invio di posta elettronica da un server delle applicazioni.

Tipi "InformationBaseUserManager", "InformationBaseUser"

Violazione dei diritti. In caso di utilizzo errato (in un modulo privilegiato), è possibile aggiungere utenti o modificare i parametri di autorizzazione degli utenti esistenti.

Formato funzione

Crash del server. Sì! Questa funzione apparentemente innocua, se non si controllano i suoi parametri e non la si esegue sul server, può causare una chiusura anomala dell'applicazione server. L'errore si manifesta durante la formattazione dei numeri e l'utilizzo della modalità di output per gli zeri iniziali e un numero elevato di caratteri, ad esempio
Formato (1, "CHT = 999; CHVN =");
Spero che questo errore venga corretto nelle prossime versioni della piattaforma, ma per ora, in tutte le chiamate a questa funzione che possono essere eseguite sul server, controlla i parametri di chiamata.

Procedure e funzioni per l'archiviazione dei valori (ValueInStringInternally, ValueInFile)

Crash del server. Queste funzioni non gestiscono riferimenti circolari nelle raccolte e annidamenti molto profondi, quindi possono bloccarsi in alcuni casi molto speciali.

Errori di confine e valori speciali dei parametri nelle funzioni. Controllo dell'esecuzione.

Uno dei problemi che si possono incontrare quando si utilizza il server è la grande "responsabilità" delle funzioni del server (la possibilità di una chiusura anomala dell'intera applicazione del server a causa di un errore in una connessione e l'utilizzo di uno "spazio risorse" per tutti i collegamenti). Da qui la necessità di controllare i principali parametri del tempo di esecuzione:

Per le funzioni del linguaggio integrate, controlla i loro parametri di avvio (un primo esempio è la funzione "Formato")
Quando si utilizzano i loop, assicurarsi che la condizione di uscita dal loop sia attivata. Se il ciclo è potenzialmente infinito, limita artificialmente il numero di iterazioni: MaximumIterationCount = 1.000.000;
Conteggio iterazioni = 1;
Ciao
Una funzione che non può restituire un valore falso ()
AND (contatore iterazioni)<МаксимальноеЗначениеСчетчикаИтераций) Цикл
// .... corpo del ciclo
Contatore iterazioni = Contatore iterazioni + 1;
Fine del ciclo;
IfIterationCount> MaximumIterationCounterValue Then
// .... gestire l'evento di esecuzione del ciclo eccessivamente lungo
Finisci se;
Quando si utilizza la ricorsione, limitare il livello di annidamento massimo.
Durante la formazione e l'esecuzione di query, cercare di evitare selezioni molto lunghe e selezioni di una grande quantità di informazioni (ad esempio, quando si utilizza la condizione "IN HIERARCHY", non utilizzare un valore vuoto)
Quando si progetta un'infobase, fornire un margine sufficientemente ampio di capacità di cifre per i numeri (altrimenti l'aggiunta e la moltiplicazione diventano non commutative e non associative, il che rende difficile il debug)
Nelle richieste eseguibili, controllare la logica di lavoro per la presenza Valori NULL e lavoro corretto condizioni ed espressioni di query utilizzando NULL.
Quando si utilizzano le raccolte, controllare la capacità di trasferirle tra il server delle applicazioni e il client.

Utilizzo dell'accesso terminale al lato client per limitare l'accesso

Non è raro trovare consigli per utilizzare l'accesso terminale per limitare l'accesso ai dati e migliorare le prestazioni eseguendo il codice lato client su un server terminal. Sì, se correttamente configurato, l'uso dell'accesso al terminale può effettivamente aumentare il livello generale di sicurezza del sistema, ma, purtroppo, spesso è possibile incontrare il fatto che nell'uso pratico la sicurezza del sistema diminuisce solo. Proviamo a capire a cosa è collegato. Ora ci sono due mezzi comuni per organizzare l'accesso al terminale, questi sono Microsoft Terminal Services (protocollo RDP) e Citrix Metaframe Server (protocollo ICA). In generale, gli strumenti Citrix forniscono opzioni di amministrazione degli accessi molto più flessibili, ma il costo di queste soluzioni è notevolmente più elevato. Prenderemo in considerazione solo le caratteristiche di base comuni ad entrambi i protocolli che possono abbassare il livello generale di sicurezza. Ci sono solo tre pericoli principali quando si utilizza l'accesso al terminale:

La possibilità di bloccare il lavoro di altri utenti sequestrando una quantità eccessiva di risorse
Accesso ai dati di altri utenti.
Copia non autorizzata di dati da un terminal server al computer di un utente

In ogni caso, i servizi terminalistici consentono di:

Aumentare l'affidabilità del lavoro (in caso di guasto al computer terminale, l'utente può successivamente continuare a lavorare dallo stesso luogo)
Limitare l'accesso all'applicazione client e ai file in essa archiviati.
Trasferire il carico di elaborazione dal posto di lavoro dell'utente al server di accesso al terminale
Gestisci le impostazioni di sistema in modo più centralizzato. Per gli utenti, le impostazioni salvate saranno valide indipendentemente dal computer da cui hanno effettuato l'accesso al sistema.
In alcuni casi è possibile utilizzare una soluzione terminale per l'accesso remoto al sistema.

È necessario limitare il numero di possibili connessioni al server terminal di un utente

A causa della "ghiottoneria" dell'applicazione client 1C per quanto riguarda le risorse, è imperativo limitare il numero massimo di connessioni simultanee di un utente (operatore) al server terminal. Una connessione utilizzata attivamente può utilizzare fino a 300 MB di memoria con una sola istanza dell'applicazione. Oltre alla memoria, viene utilizzato attivamente il tempo del processore, il che non contribuisce alla stabilità degli utenti di questo server. Oltre a prevenire l'uso eccessivo delle risorse del server, questa limitazione può impedire l'utilizzo dell'account di qualcun altro. Implementato dalle impostazioni standard del server terminal.

Non devi consentire l'esecuzione simultanea di più di una o due applicazioni client 1C in una connessione

Dettato dalle stesse motivazioni del paragrafo precedente, ma tecnicamente più difficili da attuare. Il problema è che è quasi impossibile impedire il riavvio di 1C tramite un server terminal (verrà spiegato di seguito il motivo), quindi è necessario implementare questa funzionalità a livello di una soluzione applicata (che non è anche una buona soluzione, poiché potrebbero esserci alcune sessioni "sospese" in caso di chiusura errata dell'applicazione, diventa necessario perfezionare la soluzione applicata nel modulo dell'applicazione e alcuni libri di riferimento, il che complicherà l'uso degli aggiornamenti da 1C). È altamente auspicabile lasciare all'utente la possibilità di eseguire 2 applicazioni per poter avviare alcune azioni (ad esempio, la generazione di report) in sfondo- l'applicazione client, purtroppo, è in realtà a thread singolo.

Non è consigliabile concedere diritti di accesso al server terminal agli utenti che hanno il diritto di avviare attività di elaborazione ad alta intensità di risorse in 1C o di impedire tale avvio mentre altri utenti stanno lavorando attivamente.

Naturalmente, è meglio lasciare l'accesso al server terminal solo agli utenti che non utilizzano attività come data mining, schemi geografici, importazione / esportazione e altre attività che caricano seriamente il lato client dell'applicazione. Se, tuttavia, è necessario risolvere tali attività, è necessario: notificare all'utente che queste attività possono influire sulle prestazioni di altri utenti, registrare l'evento dell'inizio e della fine di tale processo nel registro , consentire l'esecuzione solo a un'ora pianificata, ecc.

È necessario assicurarsi che ogni utente possa scrivere solo su directory strettamente definite del terminal server e che altri utenti non vi abbiano accesso.

Innanzitutto, se non si limita la possibilità di scrivere in directory condivise (come la directory in cui è installato 1C), un utente malintenzionato può modificare il comportamento del programma per tutti gli utenti. In secondo luogo, i dati di un utente (file temporanei, file per il salvataggio delle impostazioni dei report, ecc.) non dovrebbero in nessun caso essere disponibili per un altro utente del terminal server - in generale, questa regola è soddisfatta durante le normali impostazioni. In terzo luogo, l'attaccante ha ancora l'opportunità di "sporcare" la partizione in modo che non rimanga spazio sul disco rigido. Lo so, mi obietteranno che nel sistema operativo Windows, a partire da Windows 2000, c'è un meccanismo di quota, ma questo è un meccanismo piuttosto costoso, e non ho visto quasi nessun uso reale di esso.

Se le precedenti domande sulla configurazione dell'accesso erano generalmente abbastanza facili da implementare, allora già un compito (apparentemente) semplice come regolare l'accesso degli utenti ai file è implementato in modo non banale. Innanzitutto, se non viene utilizzato il meccanismo delle quote, è possibile salvare file di grandi dimensioni. In secondo luogo, il sistema è costruito in modo tale che sarà quasi sempre possibile salvare il file in modo che sia disponibile per un altro utente.

Considerando che l'attività è completamente difficile da risolvere, si consiglia di controllare la maggior parte degli eventi dei file

È necessario disabilitare la mappatura dei dispositivi disco, delle stampanti e degli appunti della workstation client.

In RDP e ICA è possibile organizzare la connessione automatica di dischi, stampanti, com-port appunti del computer terminale al server. Se esiste questa possibilità, è quasi impossibile vietare il lancio di codice estraneo sul server terminal e il salvataggio dei dati da 1C sul client di accesso al terminale. Consenti queste funzionalità solo per le persone con diritti amministrativi.

L'accesso ai file di rete dal server terminal deve essere limitato.

In caso contrario, l'utente può eseguire nuovamente il codice indesiderato o salvare i dati. Poiché il registro regolare non tiene traccia degli eventi dei file (a proposito, è una buona idea per l'implementazione da parte degli sviluppatori della piattaforma) ed è quasi impossibile configurare l'audit del sistema in tutta la rete (non ci saranno risorse sufficienti per servirlo) , è meglio che l'utente possa inviare dati o stampare, oppure tramite email. Prestare particolare attenzione che il terminal server non funzioni direttamente con i supporti rimovibili degli utenti.

In nessun caso lasciare il server delle applicazioni sul server terminal durante la creazione di un sistema sicuro.

Se il server delle applicazioni viene avviato sullo stesso computer delle applicazioni client, ci sono molte opportunità per interromperne il normale funzionamento. Se per qualche motivo è impossibile separare le funzioni del server terminal e del server delle applicazioni, prestare particolare attenzione all'accesso dell'utente ai file utilizzati dal server delle applicazioni.

È necessario escludere la possibilità di avviare tutte le applicazioni tranne 1C: Enterprise sul terminal server.

Questo è uno degli elementi dei desideri più difficili da realizzare. Per cominciare, è necessario configurare correttamente i Criteri di sicurezza di gruppo per il dominio. Tutti i modelli amministrativi e i criteri di restrizione software devono essere configurati correttamente. Per metterti alla prova, assicurati che almeno le seguenti funzionalità siano bloccate:

La complessità dell'implementazione di questo requisito porta spesso alla possibilità di avviare una sessione 1C "extra" sul terminal server (anche se altre applicazioni sono limitate, è impossibile in linea di principio vietare l'avvio di 1C tramite Windows).

Considerare le limitazioni del normale registro (tutti gli utenti utilizzano il programma da un computer)

Ovviamente, poiché gli utenti aprono 1C in modalità terminale, sarà il terminal server che verrà registrato nel registro di registrazione. Da quale computer si è connesso l'utente, il registro non riporta.

Terminal Server: sicurezza o vulnerabilità?

Quindi, dopo aver considerato le caratteristiche principali del terminal nord, possiamo dire che potenzialmente il terminal nord può aiutare nell'automazione per la distribuzione del carico di calcolo, ma costruire un sistema sicuro è abbastanza difficile. Uno dei casi in cui l'utilizzo di un terminal server è più efficace è avviare 1C senza Windows Explorer in modalità a schermo intero per utenti con funzionalità limitate e un'interfaccia specializzata.

Lavoro lato cliente

Utilizzo di Internet Explorer (IE)

Una delle condizioni per il normale funzionamento della parte client 1C è l'uso dei componenti di Internet Explorer. Devi stare molto attento con questi componenti.

Attenzione! In primo luogo, se un modulo spyware o adware è collegato a IE, verrà caricato se visualizzi file HTML in 1C. Finora non ho visto un uso consapevole di questa funzione, ma ho incontrato in una delle organizzazioni un modulo "spia" caricato di una delle reti pornografiche quando era in esecuzione 1C (il programma antivirus non è stato aggiornato, i cui sintomi sono stati trovati: durante la configurazione del firewall, era chiaro che 1C stava cercando di utilizzare la porta 80 per connettersi a un sito porno). In realtà, questo è un altro argomento a favore del fatto che la protezione dovrebbe essere globale.

Attenzione! In secondo luogo, il sistema 1C consente l'utilizzo di filmati flash, oggetti ActiveX, VBScript nei documenti HTML visualizzati, l'invio di dati a Internet, persino l'apertura di file PDF (!), sebbene in quest'ultimo caso chieda "aprire o salvare". .. in generale, qualunque cosa il tuo cuore desideri. Un esempio di un uso non del tutto ragionevole delle capacità di visualizzazione e modifica HTML integrate:

Crea un nuovo documento HTML (File -> Nuovo -> Documento HTML).
Vai alla scheda "Testo" del documento vuoto.
Elimina il testo (completamente).
Vai alla scheda "Visualizza" di questo documento
Usando il trascinamento della selezione, sposta il file con l'estensione SWF (questi sono file di filmati flash) dall'esploratore aperto alla finestra del documento, ad esempio dalla cache del browser, sebbene sia possibile con un giocattolo FLASH per divertimento.
Che bello! Puoi eseguire un giocattolo su 1C!

Dal punto di vista della sicurezza del sistema, questo è completamente sbagliato. Finora, non ho visto attacchi speciali su 1C attraverso questa vulnerabilità, ma molto probabilmente si rivelerà essere una questione di tempo e il valore delle tue informazioni.

Ci sono altri punti minori che appaiono quando si lavora con un campo di documento HTML, ma sono elencati i due principali. Tuttavia, se ti avvicini a queste funzionalità in modo creativo, puoi organizzare capacità di interfaccia davvero sorprendenti per lavorare con 1C.

Utilizzo di report ed elaborazioni esterne.

Attenzione! Report ed elaborazione esterni: da un lato, è un modo conveniente per implementare moduli stampabili aggiuntivi, report di routine, report specializzati, dall'altro è un modo potenziale per aggirare molte restrizioni di sicurezza del sistema e interrompere il funzionamento del server delle applicazioni (per un esempio, vedere sopra in "Passare parametri"). Nel sistema 1C esiste un parametro speciale nell'insieme dei diritti per il ruolo "Apertura interattiva dell'elaborazione esterna", ma ciò non risolve completamente il problema: per una soluzione completa, è necessario restringere significativamente la cerchia degli utenti che possono gestire moduli di stampa esterni, report di routine e altre funzionalità standard di soluzioni standard implementate utilizzando trattamenti esterni. Ad esempio, per impostazione predefinita in SCP, tutti i ruoli utente di base hanno la capacità di lavorare con il libro di riferimento di moduli stampabili aggiuntivi e questa è, di fatto, la possibilità di utilizzare qualsiasi elaborazione esterna.

Utilizzo di meccanismi standard di soluzioni e piattaforme tipiche (scambio dati)

Alcuni dei meccanismi standard sono potenzialmente pericolosi e in modi del tutto inaspettati.

Liste di stampa

Qualsiasi elenco (ad esempio, una directory o un registro di informazioni) nel sistema può essere stampato o salvato su un file. Per fare ciò è sufficiente utilizzare la funzionalità standard disponibile dal menu contestuale e dal menu "Azioni":

Tieni presente che praticamente tutto ciò che l'utente vede negli elenchi può essere inviato a file esterni. L'unica cosa che può essere consigliata è mantenere un protocollo per la stampa dei documenti sui server di stampa. Per moduli particolarmente critici, è necessario configurare il pannello azioni associato al campo tabella protetto in modo che l'opzione per visualizzare l'elenco non sia disponibile da questo pannello e disabilitare il menu contestuale (vedi Fig. 6).

Scambio dati in un database distribuito

Il formato di scambio dei dati è abbastanza semplice ed è descritto nella documentazione. Se un utente ha la possibilità di sovrascrivere diversi file, può apportare modifiche non autorizzate al sistema (sebbene ciò richieda molto tempo). La possibilità di creare una base periferica utilizzando piani di scambio di database distribuiti non dovrebbe essere disponibile per gli operatori ordinari.

Scambio dati standard XML

Nello scambio dati standard, che viene utilizzato per lo scambio tra configurazioni tipiche (ad esempio, "Gestione commerciale" e "Contabilità aziendale"), è possibile specificare gestori di eventi per il carico e lo scarico degli oggetti nelle regole di scambio. Ciò si ottiene ottenendo un gestore da un file e la procedura "Esegui ()" per l'elaborazione standard di caricamento e scaricamento di un file (la procedura "Esegui ()" viene avviata sul lato client). Ovviamente, non è difficile creare un file di scambio così falso che eseguirà azioni dannose. Per la maggior parte dei ruoli utente per soluzioni generiche, lo scambio è abilitato per impostazione predefinita.

Raccomandazione: limitare l'accesso allo scambio XML per la maggior parte degli utenti (lasciarlo solo agli amministratori IS). Mantenere i log delle esecuzioni di questa elaborazione, salvando il file di scambio, ad esempio, inviandolo per e-mail all'amministratore IB prima del caricamento.

Utilizzo di report generici, in particolare la console dei report

Un altro problema è l'accesso degli utenti per impostazione predefinita ai report generici, in particolare al report Report Console. Questo rapporto è caratterizzato dal fatto che consente di soddisfare quasi tutte le richieste alla sicurezza delle informazioni e, anche se il sistema di diritti 1C (incluso RLS) è configurato in modo abbastanza rigido, consente all'utente di ottenere molte informazioni "extra" e forzare il server a eseguire tale richiesta che richiederà tutte le risorse dei sistemi.

Utilizzo della modalità a schermo intero (modalità desktop)

Uno dei modi efficaci per organizzare interfacce specializzate con accesso limitato alle funzionalità del programma è la modalità a schermo intero della forma principale (e, forse, l'unica) dell'interfaccia utilizzata. In questo caso, non ci sono domande sull'accessibilità, ad esempio il menu "File" e tutte le azioni dell'utente sono limitate dalle capacità del modulo utilizzato. Per maggiori dettagli vedere "Caratteristiche dell'implementazione della modalità desktop" sul disco ITS.

Backup

Il backup per la versione client-server di 1C può essere eseguito in due modi: caricando i dati in un file con estensione dt e creando backup utilizzando SQL. Il primo metodo presenta molti svantaggi: è richiesto l'accesso esclusivo, la creazione di una copia stessa richiede molto più tempo, in alcuni casi (se la struttura IB viene violata) la creazione di un archivio è impossibile, ma c'è un vantaggio: il minimo dimensione dell'archivio. Per il backup SQL, è vero il contrario: una copia viene creata in background tramite il server SQL, a causa della sua struttura semplice e della mancanza di compressione - questo è un processo molto veloce e finché l'integrità fisica dell'SQL database non viene violato, viene eseguito il backup, ma la dimensione della copia coincide con quella vera la dimensione dell'IB nello stato espanso (non viene eseguita alcuna compressione). A causa degli ulteriori vantaggi del sistema di backup MS SQL, è più conveniente utilizzarlo (sono consentiti 3 tipi di backup: completo, differenziale, copia del registro delle transazioni; è possibile creare attività eseguite regolarmente; rapidamente implementato copia di backup e un sistema di backup; implementata la capacità di prevedere la dimensione dello spazio su disco richiesto, ecc.). I punti principali dell'organizzazione del backup dal punto di vista della sicurezza del sistema sono:

La necessità di scegliere una posizione di archiviazione per i backup in modo che non siano disponibili per gli utenti.
La necessità di archiviare i backup a distanza fisica dal server MS SQL (in caso di calamità naturali, incendi, attacchi, ecc.)
Possibilità di concedere i diritti per avviare i backup a un utente che non ha accesso ai backup.

Per informazioni più dettagliate, fare riferimento alla documentazione MS SQL.

Crittografia dei dati

Per proteggere i dati da accessi non autorizzati, vengono spesso utilizzati vari mezzi crittografici (sia software che hardware), ma la loro fattibilità dipende in gran parte dalla correttezza di utilizzo e dalla sicurezza complessiva del sistema. Prenderemo in considerazione la crittografia dei dati nelle varie fasi della trasmissione e dell'archiviazione dei dati utilizzando i mezzi più comuni e i principali errori nella progettazione del sistema utilizzando mezzi crittografici.

Esistono diverse fasi principali del trattamento delle informazioni che possono essere protette:

Trasferimento dati tra la parte client del sistema e l'application server
Trasferimento dati tra server applicazioni e MS SQL Server
Dati archiviati su MS SQL Server (file dati su disco fisico)
Crittografia dei dati archiviati nella sicurezza delle informazioni
Dati esterni (in relazione alla sicurezza delle informazioni)

Per i dati archiviati sul lato client e sull'application server (impostazioni utente salvate, elenco di sicurezza delle informazioni, ecc.), la crittografia è giustificata solo in casi molto rari e quindi non è considerata qui. Quando si utilizzano strumenti crittografici, non bisogna dimenticare che il loro utilizzo può ridurre significativamente le prestazioni del sistema nel suo insieme.

Informazioni generali sulla protezione crittografica delle connessioni di rete quando si utilizza il protocollo TCP/IP.

Senza protezione tutto le connessioni di rete vulnerabili alla sorveglianza e all'accesso non autorizzati. Per proteggerli, puoi utilizzare la crittografia dei dati a livello di protocollo di rete. Per crittografare i dati trasmessi in una rete locale, vengono utilizzati più spesso gli strumenti IPSec forniti dal sistema operativo.

Gli strumenti IPSec forniscono la crittografia dei dati trasmessi utilizzando algoritmi DES e 3DES, nonché il controllo dell'integrità utilizzando le funzioni hash MD5 o SHA1. IPSec può funzionare in due modalità: modalità di trasporto e modalità tunnel. La modalità di trasporto è più adatta per proteggere le connessioni LAN. La modalità tunnel può essere utilizzata per organizzare connessioni VPN tra singoli segmenti di rete o per proteggere una connessione remota a una rete locale su canali dati aperti.

I principali vantaggi di questo approccio sono:

La capacità di gestire centralmente la sicurezza utilizzando gli strumenti di Active Directory.
Possibilità di escludere connessioni non autorizzate al server delle applicazioni e al server MS SQL (ad esempio, è possibile proteggersi dall'aggiunta non autorizzata di informazioni di sicurezza sul server delle applicazioni).
Eliminazione dell'"ascolto" del traffico di rete.
Non è necessario modificare il comportamento dei programmi applicativi (in questo caso, 1C).
Lo standard di una tale soluzione.

Tuttavia, questo approccio presenta limiti e svantaggi:

IPSec non protegge i dati da manomissioni e intercettazioni direttamente sui computer di origine e di destinazione.
La quantità di dati trasmessi in rete è leggermente maggiore rispetto a quella senza l'utilizzo di IPSec.
Quando si utilizza IPSec, diversi più carico al processore centrale.

Una descrizione dettagliata dell'implementazione delle strutture IPSec esula dallo scopo di questo articolo e richiede la comprensione dei principi di base del protocollo IP. Per configurare correttamente la protezione della connessione, leggere la documentazione corrispondente.

Separatamente, è necessario menzionare diversi aspetti del contratto di licenza con 1C quando si organizzano le connessioni VPN. Il fatto è che, nonostante l'assenza di restrizioni tecniche, quando si collegano più segmenti di una rete locale o l'accesso remoto di un computer separato a una rete locale, sono generalmente necessarie diverse forniture di base.

Crittografia dei dati durante la trasmissione tra la parte client del sistema e il server delle applicazioni.

Oltre alla crittografia al protocollo di rete, è possibile crittografare i dati a livello del protocollo COM +, menzionato nell'articolo "Regolazione dell'accesso degli utenti all'infobase nella versione client-server" dell'ITS. Per l'implementazione, è necessario impostare il livello di autenticazione "Packet Privacy" per le chiamate per l'applicazione 1CV8 in Servizi componenti. Quando è impostata su questa modalità, il pacchetto viene autenticato e crittografato, inclusi i dati, l'identità e la firma del mittente.

Crittografia dei dati durante la trasmissione tra il server delle applicazioni e MS SQL Server

MS SQL Server fornisce i seguenti strumenti di crittografia dei dati:

È possibile utilizzare Secure Sockets Layer (SSL) durante il trasferimento di dati tra il server delle applicazioni e MS SQL Server.
Quando si utilizza la libreria di rete Multiprotocol, viene utilizzata la crittografia dei dati a livello di RPC. Questa è una crittografia potenzialmente più debole di SSL.
Se viene utilizzato il protocollo Shared Memory (questo accade se il server delle applicazioni e MS SQL Server si trovano sullo stesso computer), la crittografia non viene utilizzata in nessun caso.

Per stabilire la necessità di crittografare tutti i dati trasmessi per un server MS SQL specifico, utilizzare l'utilità "Server Network Utility". Eseguilo e nella scheda "Generale" seleziona la casella "Forza crittografia del protocollo". Il metodo di crittografia viene selezionato in base a quello utilizzato dall'applicazione client (ovvero dall'application server 1C). Per utilizzare SSL, è necessario configurare correttamente l'emittente del certificato sulla rete.

Per stabilire la necessità di crittografare tutti i dati trasmessi per un server applicativo specifico, è necessario utilizzare l'utilità "Client Network Utility" (solitamente situata in "C: \ WINNT \ system32 \ cliconfg.exe"). Come nel caso precedente, nella scheda "Generale", seleziona la casella di controllo "Forza la crittografia del protocollo".

Va tenuto presente che l'uso della crittografia in questo caso può influire in modo significativo sulle prestazioni del sistema, soprattutto quando si utilizzano query che restituiscono grandi quantità di informazioni.

Al fine di proteggere in modo più completo la connessione tra il server delle applicazioni e MS SQL Server quando si utilizza il protocollo TCP/IP, possiamo consigliare diverse modifiche alle impostazioni predefinite.

Innanzitutto, è possibile impostare una porta diversa da quella standard (la porta 1433 viene utilizzata per impostazione predefinita). Se decidi di utilizzare una porta TCP non standard per la comunicazione, tieni presente che:

MS SQL Server e Application Server devono utilizzare la stessa porta.
Quando si utilizzano i firewall, questa porta deve essere consentita.
Non è possibile impostare una porta che può essere utilizzata da altre applicazioni su MS SQL Server. Per riferimento, vedere http://www.ise.edu/in-notes/iana/assignments/port-numbers (URL tratto dalla documentazione in linea di SQL Server).
Quando si utilizzano più istanze di MS SQL Server, assicurarsi di leggere la documentazione di MS SQL per la configurazione (sezione "Configurazione delle connessioni di rete").

In secondo luogo, nelle impostazioni del protocollo TCP/IP sul server MS SQL, è possibile selezionare la casella di controllo "Nascondi server", che vieta le risposte alle richieste di trasmissione per questa istanza del servizio MS SQL Server.

Crittografia dei dati MS SQL archiviati su disco

Esiste una selezione abbastanza ampia di software e hardware per la crittografia dei dati situati su un disco locale (questa è la capacità standard di Windows di utilizzare EFS e l'uso di chiavi eToken e programmi di terze parti come Jetico Bestcrypt o PGPDisk). Uno dei compiti principali svolti da questi strumenti è quello di proteggere i dati in caso di perdita di supporti (ad esempio, in caso di furto del server). Va notato in particolare che Microsoft non consiglia di archiviare database MS SQL su supporti crittografati, e questo è abbastanza ragionevole. Il problema principale in questo caso è un calo significativo della produttività e possibili problemi affidabilità dai guasti. Il secondo fattore che complica la vita dell'amministratore di sistema è la necessità di garantire che tutti i file del database siano disponibili nel momento in cui il servizio MS SQL vi accede per la prima volta (cioè è auspicabile che le azioni interattive vengano escluse quando si collegano i supporti crittografati ).

Per evitare un notevole calo delle prestazioni del sistema, è possibile utilizzare la capacità di MS SQL per creare database in più file. Ovviamente, in questo caso, il database MS SQL non dovrebbe essere creato dal server 1C durante la creazione di un'infobase, ma dovrebbe essere creato separatamente. Di seguito è mostrato uno script TSQL di esempio con commenti:

USE master
ANDARE
- Crea database SomeData,
CREA DATABASE SomeData
- i cui dati si trovano interamente nel filegroup PRIMARY.
SU PRIMARIA
- Il file di dati principale si trova su un supporto crittografato ( unità logica E :)
- e ha una dimensione iniziale di 100 MB, può essere espansa automaticamente a 200 MB con
- Step di 20 Mb
(NOME = AlcuniDati1,
FILENAME = "E: \ SomeData1.mdf",
DIMENSIONE = 100 MB,
DIMENSIONE MAX = 200,
CRESCITA FILE = 2),
- Il secondo file di dati si trova su un supporto non crittografato (unità logica C :)
- e ha una dimensione iniziale di 100 MB, può essere aumentata automaticamente fino al limite
- spazio su disco con un passo del 5% della dimensione del file corrente (arrotondato a 64 Kb)
(NOME = AlcuniDati2,
FILENAME = "c:\programmi\microsoft sql server\mssql\data\SomeData2.ndf",
DIMENSIONE = 100 MB,
MAXSIZE = ILLIMITATO,
CRESCITA FILE = 5%)
ACCEDERE
- Sebbene il registro delle transazioni possa anche essere diviso in parti, ciò non dovrebbe essere fatto,
- da questo file cambia molto più spesso e viene ripulito regolarmente (ad esempio, quando
- creazione di una copia di backup del database).
(NOME = SomeDatalog,
FILENAME = "c: \ file di programma \ microsoft sql server \ mssql \ data \ SomeData.ldf",
DIMENSIONE = 10MB,
MAXSIZE = ILLIMITATO,
CRESCITA FILE = 10)
ANDARE
- È meglio dare immediatamente la proprietà del database all'utente per conto del quale
- 1C sarà collegato. Per fare ciò, dobbiamo dichiarare la base corrente
- appena creato,
UTILIZZARE Alcuni Dati
ANDARE
- ed eseguire la procedura sp_changedbowner
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

Una piccola digressione sulla crescita automatica della dimensione del file di dati. Per impostazione predefinita, per i database appena creati, le dimensioni dei file vengono aumentate con incrementi del 10% rispetto alle dimensioni del file corrente. Questa è una soluzione perfettamente accettabile per database piccoli, ma non molto buona per quelli grandi: con una dimensione del database, ad esempio, di 20 GB, il file dovrebbe crescere di 2 GB in una volta. Sebbene questo evento si verifichi abbastanza raramente, può durare diverse decine di secondi (tutte le altre transazioni sono effettivamente inattive in questo momento), il che, se si verifica mentre si lavora attivamente con il database, può causare alcuni errori. La seconda conseguenza negativa del guadagno proporzionale, che si verifica quando lo spazio su disco è quasi completamente pieno, è la probabilità di un guasto prematuro per insufficiente spazio libero... Ad esempio, se una partizione del disco da 40 GB è completamente allocata per un database (più precisamente, per un file di questo database), allora la dimensione critica del file del database a cui è necessario urgentemente (molto urgente, fino all'interruzione del normale lavoro degli utenti) per riorganizzare l'archiviazione delle informazioni è la dimensione del file di dati 35 GB. Con un set di incrementi di 10-20 MB, puoi continuare a lavorare fino al raggiungimento di 39 GB.

Pertanto, sebbene l'elenco fornito specifichi un aumento della dimensione di uno dei file di database con incrementi del 5%, per database di grandi dimensioni è meglio impostare un incremento fisso di 10-20 MB. Quando si impostano i valori dell'incremento per la crescita della dimensione dei file del database, è necessario tenere conto che prima che uno dei file nel filegroup raggiunga la dimensione massima, si applica la regola: i file di un filegroup crescono tutti allo stesso tempo, quando sono tutti pieni. Pertanto, nell'esempio precedente, quando il file SomeData1.mdf raggiunge la dimensione massima di 200 MB, il file SomeData2.ndf avrà una dimensione di circa 1,1 GB.

Dopo aver creato un database di questo tipo, anche se i suoi file SomeData2.ndf e SomeData.ldf diventano disponibili per un utente malintenzionato, sarà estremamente difficile ripristinare il vero stato del database: i dati (comprese le informazioni sulla struttura logica del database ) sarà sparso su più file, inoltre le informazioni chiave (riguardo, ad esempio, quali file compongono questo database) saranno nel file crittografato.

Naturalmente, se viene utilizzata l'archiviazione di file di database utilizzando mezzi crittografici, il backup (almeno questi file) non deve essere eseguito su un supporto non crittografato. Utilizzare la sintassi del comando "BACKUP DATABASE" appropriata per eseguire il backup di singoli file di database. Si noti che nonostante la possibilità di proteggere il backup del database con una password (le opzioni "PASSWORD =" e "MEDIAPASSWORD =" del comando "BACKUP DATABASE"), tale backup non viene crittografato!

Crittografia del server delle applicazioni e dei dati del client archiviati su dischi

Nella maggior parte dei casi, non può essere considerato giustificato archiviare i file utilizzati da 1C: Enterprise (parte client e server applicazioni) su un supporto crittografato a causa di costi irragionevolmente elevati, tuttavia, se tale necessità esiste, si prega di notare che il server delle applicazioni e il La parte client dell'applicazione crea molto spesso file temporanei. Spesso, questi file possono rimanere dopo che l'applicazione è terminata ed è quasi impossibile garantire la loro rimozione tramite 1C. Pertanto, sembra crittografare la directory utilizzata per i file temporanei in 1C o non memorizzarla su disco utilizzando l'unità RAM (quest'ultima opzione non è sempre possibile a causa delle dimensioni dei file generati e dei requisiti per la quantità di RAM del 1C: applicazione aziendale stessa).

Crittografia dei dati con strumenti 1C integrati.

Le possibilità standard per l'utilizzo della crittografia in 1C sono ridotte all'utilizzo di oggetti per lavorare con file Zip con parametri di crittografia. Sono disponibili le seguenti modalità di crittografia: Algoritmo AES con una chiave di 128, 192 o 256 bit e un algoritmo obsoleto originariamente utilizzato nell'archiviatore Zip. I file zip crittografati con AES non sono leggibili da molti archivi (WinRAR, 7zip). Per generare un file contenente dati crittografati, è necessario specificare una password e un algoritmo di crittografia. L'esempio più semplice le funzioni di crittografia-decrittografia basate su questa capacità sono fornite di seguito:

Funzione EncryptData (dati, password, metodo di crittografia = non definito) Esporta

// Scrive i dati in un file temporaneo. In effetti, non tutti i dati possono essere salvati in questo modo.
ValueInFile (TempFileName, Dati);

// Scrive i dati temporanei nell'archivio
Zip = Nuovo record ZipFile (nome file archivio temporaneo, password, metodo di crittografia);
Zip.Add (TemporaryFileName);
Zip.Scrivi ();

// Legge i dati dall'archivio ricevuto in RAM
EncryptedData = NewValueStore (New BinaryData (TemporaryArchiveFileName));

// File temporanei - elimina

Funzione EndFunction DecryptData (EncryptedData, Password) Export

// Attenzione! La correttezza dei parametri passati non viene monitorata

// Scrive il valore passato in un file
TempFileName = GetTempFileName ("zip");
BinaryArchiveData = EncryptedData.Get ();
BinaryArchiveData.Write (TemporaryArchiveFileName);

// Estrai il primo file dell'archivio appena scritto
TempFileName = GetTempFileName ();
Zip = Nuovo ReadZipFile (TemporaryArchiveFileName, Password);
Zip.Extract (Zip.Elements, TemporaryFileName, ZipFilePath RecoveryMode.NotRecover);

// Leggi il file scritto
Data = ValueFromFile (TemporaryFileName + "\" + Zip.Elements.Name);

// Elimina i file temporanei
DeleteFiles (TemporaryFileName);
DeleteFiles (TempArchiveFileName);

Dati di ritorno;

EndFunction

Naturalmente, questo metodo non può essere definito ideale: i dati vengono scritti in una cartella temporanea in testo non crittografato, le prestazioni del metodo, francamente, non sono da nessuna parte peggiori, l'archiviazione in un database richiede una quantità estremamente grande di spazio, ma questo è l'unico modo che si basa solo sui meccanismi integrati della piattaforma. Inoltre, ha un vantaggio rispetto a molti altri metodi: questo metodo impacchetta simultaneamente i dati con la crittografia. Se si desidera implementare la crittografia senza gli svantaggi di questo metodo, è necessario implementarli in un componente esterno o fare riferimento a librerie esistenti tramite la creazione di oggetti COM, ad esempio utilizzando Microsoft CryptoAPI. Ad esempio, daremo le funzioni per crittografare/decrittografare una stringa in base alla password ricevuta.

Funzione EncryptStringDES (UnencryptedString, Password)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Questa costante proviene da CryptoAPI

Encryption Engine.Content = UnencryptedString;
Encryption Engine.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = Encryption Engine.Encrypt ();

Restituisci StringaCrittografata;

EndFunction // EncryptStringDES ()

Funzione DecryptStringDES (EncryptedString, Password)

//Attenzione! I parametri non sono controllati!

Encryption Engine = New COMObject ("CAPICOM.EncryptedData");
Meccanismo di crittografia.SetSecret (Password);
Tentativo
Encryption Engine.Decrypt (EncryptedString);
Eccezione
// Password errata!;
Rimborso Indefinito;
Fine dei tentativi;

Motore di crittografia di ritorno.Contenuto;

EndFunction // DecryptStringDES ()

Nota che il passaggio di un valore vuoto come stringa o password a queste funzioni genererà un messaggio di errore. La stringa ottenuta utilizzando questa procedura di crittografia è leggermente più lunga dell'originale. La specificità di questa crittografia è tale che se si crittografa una stringa due volte, le stringhe risultanti NON saranno identiche.

Gli errori principali quando si utilizzano strumenti crittografici.

Quando si utilizzano strumenti crittografici, molto spesso vengono commessi gli stessi errori:

Sottovalutare il degrado delle prestazioni quando si utilizza la crittografia.

La crittografia è un'attività che richiede una quantità di calcolo abbastanza grande (specialmente per algoritmi come DES, 3DES, GOST, PGP). E anche nel caso dell'utilizzo di algoritmi efficienti e ottimizzati (RC5, RC6, AES), non c'è modo di evitare il trasferimento di dati non necessario in memoria e l'elaborazione computazionale. E questo annulla quasi le capacità di molti componenti del server (array RAID, adattatori di rete). Quando si utilizza la crittografia hardware o l'acquisizione della chiave hardware per la crittografia, esiste un ulteriore possibile collo di bottiglia delle prestazioni: la velocità di trasferimento dei dati tra il dispositivo aggiuntivo e la memoria (e le prestazioni di tale dispositivo potrebbero non svolgere un ruolo decisivo). Quando si utilizza la crittografia di piccole quantità di dati (ad esempio i messaggi di posta), l'aumento del carico computazionale sul sistema non è così evidente, ma nel caso della crittografia totale di tutto e tutto ciò può influire notevolmente sulle prestazioni del sistema nel complesso.

sottovalutazione opportunità moderne sulla selezione di password e chiavi.

Al momento, le capacità della tecnologia sono tali che una chiave con una lunghezza di 40-48 bit può essere prelevata da una piccola organizzazione e una chiave con una lunghezza di 56-64 bit da una grande organizzazione. Quelli. devono essere utilizzati algoritmi che utilizzino una chiave di almeno 96 o 128 bit. Ma la maggior parte delle chiavi viene generata utilizzando algoritmi di hash (SHA-1, ecc.) In base alle password immesse dall'utente. In questo caso, anche una chiave a 1024 bit potrebbe non essere d'aiuto. Innanzitutto, viene spesso utilizzata una password facile da indovinare. I fattori che facilitano la selezione sono: uso di un solo caso di lettere; l'uso di parole, nomi ed espressioni nelle password; utilizzando date note, compleanni, ecc .; utilizzando "modelli" durante la generazione di password (ad esempio, 3 lettere, quindi 2 numeri, quindi 3 lettere in tutta l'organizzazione). Una buona password dovrebbe essere una sequenza abbastanza casuale di lettere maiuscole, numeri e segni di punteggiatura. Le password inserite da tastiera lunghe fino a 7-8 caratteri, anche se si seguono queste regole, possono essere selezionate in un tempo ragionevole, quindi è meglio che la password sia lunga almeno 11-13 caratteri. La soluzione ideale è rifiutarsi di generare una chiave utilizzando una password, ad esempio utilizzando varie smart card, ecc., ma in questo caso è necessario prevedere la possibilità di proteggersi dalla perdita del vettore della chiave di crittografia.

Archiviazione non sicura di chiavi e password.

Esempi tipici di questo errore sono:

password lunghe e complesse scritte su adesivi incollati al monitor dell'utente.
memorizzare tutte le password in un file non protetto (o protetto molto più debole del sistema stesso)
conservazione di chiavi elettroniche di pubblico dominio.
frequente trasferimento di chiavi elettroniche tra utenti.

Perché fare una porta blindata se la chiave è sotto il tappeto vicino alla porta?

Trasferimento di dati inizialmente crittografati in un ambiente non sicuro.

Quando organizzi un sistema di sicurezza, assicurati che soddisfi il suo scopo. Ad esempio, mi sono imbattuto in una situazione (non correlata a 1C), in cui il file inizialmente crittografato, quando il programma era in esecuzione in forma aperta, è stato inserito in una cartella temporanea, da dove poteva essere facilmente letto. Non è raro che i backup di dati crittografati in forma chiara si trovino da qualche parte "non lontano" da questi dati.

Uso improprio di strumenti crittografici

Con la crittografia dei dati trasmessi, non ci si può aspettare che i dati non siano disponibili dove vengono utilizzati. Ad esempio, i servizi IPSec non impediscono in alcun modo al server delle applicazioni di ascoltare il traffico di rete a livello di applicazione.

Pertanto, per evitare errori nell'implementazione di sistemi crittografici, prima di distribuirlo, dovresti (almeno) fare quanto segue.

Scoprire:
- Cosa devi proteggere?
- Quale metodo di protezione dovresti usare?
- Per quali parti del sistema è necessario fornire sicurezza?
- Chi controllerà l'accesso?
- La crittografia funzionerà in tutti i posti giusti?
Determinare dove vengono archiviate le informazioni, come vengono inviate sulla rete e i computer da cui si accederà alle informazioni. Ciò fornirà informazioni sulla velocità, la capacità e l'utilizzo della rete prima della distribuzione del sistema, utile per ottimizzare le prestazioni.
Valutare la vulnerabilità del sistema per tipi diversi attacchi.
Sviluppare e documentare un piano di sicurezza del sistema.
Valutare l'efficienza economica (giustificazione) dell'utilizzo del sistema.

Conclusione

Certo, in una rapida rassegna è impossibile indicare tutti gli aspetti legati alla sicurezza in 1C, ma traiamo alcune conclusioni preliminari. Naturalmente, questa piattaforma non può essere definita ideale: come molte altre, ha i suoi problemi nell'organizzazione di un sistema sicuro. Ma questo non significa in alcun modo che questi problemi non possano essere aggirati, al contrario, quasi tutte le carenze possono essere eliminate con il corretto sviluppo, implementazione e utilizzo del sistema. La maggior parte dei problemi deriva da un'elaborazione insufficiente di una specifica soluzione applicativa e del suo ambiente di esecuzione. Ad esempio, le soluzioni tipiche senza modifiche significative semplicemente non implicano la creazione di un sistema sufficientemente sicuro.

Società È un servizio unico per acquirenti, sviluppatori, rivenditori e partner affiliati. Inoltre, è uno dei migliori negozi di software online in Russia, Ucraina, Kazakistan, che offre ai clienti un vasto assortimento, molti metodi di pagamento, elaborazione degli ordini rapida (spesso istantanea), monitoraggio del processo di evasione degli ordini nella sezione personale.

La Guida del programmatore API Informix® DataBlade ™ è disponibile per il download all'indirizzo. La sezione Gestione dello spazio dello stack descrive come creare funzioni personalizzate (UDR). Questo articolo fornisce ulteriori informazioni e suggerimenti per il debug.

Le informazioni seguenti sono valide se l'UDR è in esecuzione su un processore virtuale (VP) definito dall'utente o su una CPU VP. Lo stack di thread può essere spostato su un processore virtuale definito dall'utente appena prima dell'esecuzione dell'UDR.

Quale stack di dimensioni è allocato per gli UDR?

La dimensione dello stack disponibile per un UDR dipende da come è stato creato l'UDR:

utilizzando il modificatore STACK, che consente all'UDR di utilizzare il proprio stack dedicato,

senza il modificatore STACK, il che significa che l'UDR condividerà lo stack allocato dal server con il thread che effettua la richiesta. La dimensione dello stack in questo caso sarà determinata dal valore del parametro STACKSIZE nel file di configurazione onconfig.

Modificatore STACK

Le espressioni CREATE PROCEDURE o CREATE FUNCTION hanno un modificatore STACK opzionale che consente di specificare la quantità di spazio dello stack, in byte, che l'UDR deve eseguire.

Se utilizzi il modificatore STACK durante la creazione di un UDR, il server allocherà e deallocarà lo spazio dello stack ogni volta che l'UDR viene eseguito. La dimensione effettiva disponibile è il valore STACK in byte meno un sovraccarico a seconda del numero di argomenti della funzione.

Se il valore STACK è inferiore al valore STACKSIZE nel file onconfig (vedere la sezione successiva), lo stack allocato per l'UDR verrà automaticamente arrotondato al valore STACKSIZE.

Parametro di configurazione STACKSIZE

Il file di configurazione onconfig include un parametro STACKSIZE che definisce la dimensione dello stack predefinita per i thread utente.

Se non si specifica STACK durante la creazione di un UDR, il server non alloca spazio aggiuntivo nello stack per eseguire tale UDR. Invece, l'UDR utilizza lo spazio dello stack allocato per soddisfare la richiesta. La dimensione dello stack disponibile dipenderà dal sovraccarico dell'esecuzione della funzione a livello SQL.

Lo stack di un thread viene allocato una volta per un thread specifico che effettua una richiesta. Le prestazioni sono migliori quando l'UDR condivide un thread con uno stack, poiché il server non spreca risorse nell'allocare uno stack aggiuntivo per ogni chiamata UDR. D'altra parte, se la dimensione dell'UDR dello stack utilizzato si avvicina al valore STACKSIZE, può causare un overflow dello stack quando si chiama la funzione come parte di una richiesta complessa (in questo caso, è disponibile meno spazio nello stack per eseguire l'UDR).

Ricorda di non impostare STACKSIZE troppo alto, poiché ciò influenzerà tutti i thread dell'utente.

Quando è necessario gestire la dimensione dello stack?

Y È necessario gestire lo spazio dello stack se l'UDR effettua chiamate ricorsive o se l'UDR richiede più spazio nello stack di quello disponibile per impostazione predefinita nello stack del thread di richiesta (STACKSIZE).

Esistono due modi per aumentare lo stack per eseguire gli UDR:

Specificare il modificatore STACK durante la creazione di un UDR.

Utilizzare mi_call() per effettuare chiamate ricorsive (vedere la Guida del programmatore dell'API Informix DataBlade per un esempio).

Se non si specifica la dimensione con STACK e se non si utilizza mi_call() per aumentare lo stack corrente e se l'UDR fa qualcosa che richiede molto spazio nello stack, causerà un overflow dello stack.

Nota che alcune funzioni come mi_ * aggiungono un nuovo segmento di stack per la propria esecuzione. Questi segmenti vengono liberati al ritorno al chiamante dell'UDR.

E se qualcosa va storto?

Monitoraggio dell'utilizzo dello stack

Lo scopo del monitoraggio è identificare un UDR specifico che sta causando un overflow dello stack in modo da poter modificare il valore STACK in modo specifico per un UDR specifico.

Osservazione dell'utilizzo dello stack con "onstat -g sts"

Osserva la sessione che esegue la query SQL con "onstat -g ses session_id"

Dopo l'identificazione Query SQL che si traduce in un overflow dello stack, è necessario determinare l'utilizzo dello stack eseguendo separatamente gli UDR che fanno parte della richiesta originale.

Puoi impostare dinamicamente il valore STACK per l'UDR. Per esempio:

altera la funzione MyFoo (lvarchar, lvarchar) con (aggiungi stack = 131072);

Dopo aver modificato il valore STACK, dovresti testare la query originale per assicurarti che ora funzioni stabilmente.

Aumenta DIMENSIONI STACK

In alternativa, prova ad aumentare il valore STACKSIZE. Controlla se questo ha risolto il problema. (Non dimenticare di restituire il vecchio valore in seguito).

Se l'aumento di STACKSIZE non funziona, il problema è molto probabilmente un danneggiamento della memoria. Ecco alcuni suggerimenti:

Abilita lo scarabocchio di memoria e il controllo del pool di memoria. La sezione "Problemi di debug" dell'articolo Allocazione di memoria per UDR spiega come eseguire questa operazione.

Riconsiderare l'utilizzo di mi_lvarchar. Presta particolare attenzione ai punti in cui mi_lvarchar viene passato a una funzione che si aspetta di ricevere una stringa con terminazione null come argomento.

Ridurre il numero di VP CPU (o utente) a uno per riprodurre il problema più velocemente.

mi_print_stack() - Solaris

Informix Dynamic Server per Solaris OC include una funzione mi_print_stack() che può essere chiamata nell'UDR. Per impostazione predefinita, questa funzione salva lo stack frame nel seguente file:

/tmp/default.stack

Non è possibile modificare il nome del file di output, ma è possibile modificarne la posizione modificando il valore della variabile di ambiente DBTEMP. Assicurati che l'utente informix possa scrivere nella directory $ DBTEMP. Tutti gli errori che si verificano durante l'esecuzione di mi_print_stack() vengono stampati su $ MSGPATH.

Questa funzione è disponibile solo per Solaris OC.

Glossario

Termini e abbreviazioni utilizzati in questo articolo:

UDR	Routine definita dall'utente
VP	Processore virtuale

14/04/2016 Versione 3.22 Modificata interfaccia, corretti errori durante il trasferimento dei registri, modificata la procedura per il trasferimento delle organizzazioni e delle politiche contabili. Piattaforma 8.3.7.2027 BP 3.0.43.174
17/03/2016 Versione 3.24 Bug corretti. Piattaforma 8.3.8.1747 BP 3.0.43.241
16/06/2016 Versione 3.26 Bug corretti. Piattaforma 8.3.8.2088 BP 3.0.44.123
16/10/2016 Versione 4.0.1.2 Risolto trasferimento del negozio di valore, modificato il trasferimento del criterio contabile per le versioni 3.44. *. Piattaforma 8.3.9.1818 BP 3.0.44.164.
19/04/2017 Versione 4.0.2.7 L'algoritmo per il trasferimento dei registri associati alle directory è stato modificato, sono stati corretti gli errori rilevati, è stato corretto il trasferimento con riscrittura dei collegamenti.
29/05/2017 Versione 4.0.4.5 Modificato trasferimento dei movimenti, aggiunta visualizzazione dei movimenti dei documenti trasferiti, qualcos'altro...
30/05/2017 Versione 4.0.4.6 Corretto un bug durante la compilazione dell'elenco delle directory esistenti nel sorgente (grazie a shoy)
17/06/2017 Versione 4.0.5.1 L'algoritmo per il trasferimento dei movimenti è stato modificato.
19/07/2017 Versione 4.0.5.4 Il trasferimento di CI da BP 2.0 è stato modificato. Inaspettatamente, il trasferimento da UT 10.3 è stato effettuato da Smilegm, in questa versione il trasferimento è leggermente corretto per una situazione del genere)))
08/10/2017 Versione 4.0.5.5 Risolti errori durante il trasferimento da BP 2.0
19/09/2017 Versione 4.4.5.7 Verifica connessione fissa per 3.0.52 *
28/11/2017 Versione 4.4.5.9 Bug corretti
12/06/2017 Versione 5.2.0.4 L'algoritmo di ricerca dei link è stato riprogettato. Aggiunte procedure di trasferimento da BP 1.6, non esiste un legame più rigido con BP: è possibile utilizzare in sicurezza configurazioni "quasi" identiche per trasferire i dati. Cercherò di correggere prontamente tutti i commenti.
12/08/2017 Versione 5.2.1.3 Aggiunto un algoritmo per il trasferimento delle buste paga da BP.2.0 a BP 3.0. Le modifiche sono incluse per la condivisione tra le stesse configurazioni.
19/12/2017 Versione 5.2.2.2 Corretto il trasferimento di registri indipendenti di informazioni per le directory, che sono nelle dimensioni di questi registri.

12/06/2017 Nuova versione di elaborazione 5.2.0.4. Tra i cambiamenti significativi c'è la possibilità di passare da BP 1.6 a BP 3.0. La principale novità è la gestione della ricerca dei link referenziati - nelle versioni precedenti la ricerca era per GUID, e in questa versione è possibile abilitare la ricerca "Per requisiti":

17/01/2018 Versione 5.2.2.3 Risolti errori rilevati di elenchi subordinati e registri periodici di informazioni.

19/07/2018 Versione 5.2.2.8 Bug corretti.

dove è possibile impostare i dettagli di ricerca per qualsiasi libro di riferimento. Questo stesso regime "è sorto" su numerose richieste dei lavoratori, nel caso in cui sia necessario uno scambio in un database già esistente, che contiene già dati (ad esempio, per unire la contabilità di due organizzazioni in un unico database).

21/12/2015 Rilasciate rispettivamente la piattaforma 8.3.7.1805 e BP 3.0.43.29 una nuova versione elaborazione 3.1 :-) (descrizione sotto). Nuova funzionalità- la possibilità di confrontare saldi e fatturati tra due basi BP (per tutti i conti, se i piani dei conti coincidono, o per conti abbinati separati, con o senza analitica).
01/03/2016 Versione 3.5 - modificato il meccanismo di connessione al database sorgente - allineato al BSP 2.3.2.43. Risolti bug minori. Piattaforma 8.3.7.1845, BP 3.0.43.50
16/02/2016 Versione 3.6 - Aggiunto il flag "Imposta correzione manuale" per i documenti trasferiti con movimenti. Trasferimento fisso di movimenti - i documenti con una data inferiore all'inizio del periodo vengono trasferiti senza movimenti. Piattaforma 8.3.7.1917, BP 3.0.43.116
22/03/2016 Versione 3.10 - Aggiunto il flag "Sovrascrivi sempre i collegamenti" per la sovrascrittura obbligatoria degli oggetti referenziati (la velocità di trasferimento è notevolmente ridotta, ma a volte è necessaria). Aggiunto il tab "Preparazione", dove è possibile configurare la corrispondenza dei piani dei conti di origine e di destinazione (a livello dei codici conto) e il trasferimento delle costanti. Piattaforma 8.3.7.1970, BP 3.0.43.148

04/03/2016 Versione 3.11 La compilazione dell'elenco dei documenti esistenti nella fonte è stata modificata: la compilazione è stata effettuata per movimenti secondo il piano dei conti, è stata effettuata semplicemente tramite i link per il periodo, così come in il // sito / pubblico / 509628 /

L'elaborazione è destinata al trasferimento di dati per qualsiasi periodo in modo simile a "Scaricare e caricare MXL" da ITS, solo senza utilizzare XML, JSON e altri file intermedi - scambio da database a database tramite COM. In una versione precedente alla 3.10, viene utilizzata una connessione che utilizza un algoritmo del BSP, in cui viene fornita la registrazione di comcntr.dll (se il sistema operativo "consente"), nonché vari messaggi quando è impossibile stabilire una connessione , Per esempio - " Base informativaè in fase di aggiornamento ", ecc. Aggiunto controllo della scelta del ricevitore come sorgente IS - viene emesso un avviso.

Può essere utilizzato per:

1. Trasferimento di informazioni normative e di riferimento (NSI) dalla sorgente IS al destinatario IS (il trasferimento dell'intero NSI viene eseguito su richiesta dell'utente, i libri di riferimento necessari, ecc. vengono trasferiti tramite link per eventuali trasferimenti) .

2. Trasferimento di documenti per qualsiasi periodo selezionato.

3. Il trasferimento di tutte le informazioni dall'IB "rotto", se avviato in 1C: modalità Enterprise, e il caricamento dei dati o l'avvio del Configuratore è impossibile.

Funzionalità di elaborazione - la sicurezza delle informazioni del destinatario e della fonte può essere diversa trasferimento da 2.0 a 3.0 - le edizioni sono diverse, ma il trasferimento funziona !!! Gli attributi non corrispondenti vengono ignorati oppure è necessario specificare algoritmi di trasferimento per essi.

Commento: La conversione dei dati NON è UTILIZZATA! E non chiedere perché!!! Per i più corrosivi - BP 3.0 cambia quasi ogni giorno, non c'è più alcuna forza per mantenere aggiornate le regole di trasferimento - qui è tutto più facile :-).

Un'altra caratteristica di elaborazione è che viene lanciato nell'IS del ricevitore (gli analoghi più vicini in termini di funzionalità funzionano al contrario, dalla sorgente al ricevitore).

Inizio del lavoro: è necessario specificare il periodo di elaborazione, indicare l'organizzazione dalla fonte, sarà trasferito al destinatario.

Quando l'organizzazione viene trasferita, vengono trasferiti la politica contabile e i registri delle informazioni "accompagnanti". Pertanto, quando selezioni per la prima volta un'organizzazione nella fonte, ci vorrà del tempo prima che appaia nel ricevitore.

I piani dei conti di origine e di destinazione devono essere gli stessi, nessun account diverso nelle versioni 2. * vengono trasferiti al destinatario, l'impostazione della corrispondenza dei conti e delle analisi è prevista per essere inclusa in futuro. Gli account vengono trasferiti da codici che non si trovano nel ricevitore NON CREARE !!!

Il resto degli oggetti viene trasferito tramite identificatori interni (GUID), quindi dovresti prestare attenzione ad alcuni libri di riferimento chiave, ad esempio - Valute.

Se prevedi di scambiare con una base "pulita", è meglio eliminare i libri di riferimento compilati al primo avvio prima dello scambio. Per questo, viene fornita una pagina nell'elaborazione, dove è possibile ottenere questi elementi delle directory e cancellarli. Per lo meno, devi rimuovere la valuta "RUB". - da la duplicazione è quasi inevitabile (in linea di principio, questo può essere facilmente corretto dopo aver scambiato la ricerca e la sostituzione dei duplicati incorporati in BP 3.0).

In elaborazione si è ipotizzata una chiamata alla pagina per la cancellazione delle rubriche, all'apertura del form di prima compilazione:

All'apertura dell'elaborazione verrà visualizzata la pagina per la cancellazione delle directory che erano state compilate durante il riempimento iniziale:

Dalla versione 3.22, l'interfaccia è stata modificata, ora tutte le operazioni preparatorie sono contrassegnate da un segnalibro e sono sempre disponibili

È importante verificare la corrispondenza del piano dei conti della fonte e del destinatario e assicurarsi di indicare la corrispondenza dei conti.

Non è necessario eliminare elementi di directory predefiniti: vengono trasferiti tramite identificatori di configurazione (non GUID).

È possibile selezionare gli oggetti per il trasferimento utilizzando il modulo di selezione da directory e documenti (I registri delle informazioni associati a questo oggetto verranno migrati automaticamente, quindi non è necessario selezionarli separatamente).Il trasferimento dei registri è temporaneamente disabilitato - è necessario elaborare un elenco di registri per il trasferimento - qualcosa deve essere trasferito, qualcosa no, in questa fase, ciò che viene trasferito negli elenchi è sufficiente, l'elenco dei registri per il trasferimento sarà nel modello, nelle versioni future.

Quando si scambia con 2.0, alcuni dettagli (ad esempio, Informazioni sui contatti) viene riportato secondo l'algoritmo integrato nell'elaborazione, poiché sono memorizzati in modo diverso per 2.0 e 3.0. La situazione è simile con una serie di documenti (ad esempio, Rettifica del debito).

L'elenco dei tipi di oggetti può essere compilato diversamente nella versione 3.22 è posizionato nel sottomenu, le modifiche sono scritte nell'immagine:

C'è una semplificazione dell'uso dell'elaborazione: non è necessario selezionare le directory per lo scambio, ma semplicemente riempire l'elenco dei tipi nel ricevitore solo con quei tipi di directory che hanno almeno un record nella fonte.

L'elaborazione ha un layout integrato, che elenca le directory che non devono essere trasferite dalla sorgente alla destinazione (layout "Escludi dal trasferimento"). Puoi aggiungere (eliminare) qualsiasi riferimento a questo layout. Se non è necessario trasferire tutti i dati di riferimento, è sufficiente trasferire i documenti, il cui elenco è ottenibile anche senza selezionare le tipologie, basta compilare tutti i documenti di origine per i quali ci sono transazioni.

Viene fornito il trasferimento di documenti con movimenti, per cambi da 3.0 a 3.0 e la conformità dei piani dei conti funziona uno a uno, quando si scambiano da 2.0 a 3.0, sono possibili errori, quindi si consiglia di trasferire documenti senza movimenti, e quindi semplicemente ripubblicarli nel ricevitore. Quando si trasferiscono documenti con movimenti, il flag "Correzione manuale" è impostato.

L'attributo "Registrato" è impostato nei documenti del destinatario allo stesso modo dell'origine, ma i movimenti (se non sono stati trasferiti) verranno visualizzati solo dopo che i documenti sono stati registrati, ad esempio, utilizzando l'elaborazione integrata nell'elaborazione dei documenti del Gruppo BP 3.0 ( opzione consigliata), o da questa elaborazione (c'è un pulsante "Invia documenti" qui).

Se l'elaborazione è prevista per essere utilizzata per uno scambio permanente, può essere registrata nell'IS del destinatario (il pulsante "Registrati"). Per i trasferimenti "una tantum", puoi semplicemente utilizzarlo tramite File - Apri.

21/12/2015 - Versione 3.1 piattaforma 8.3.7.1805 e BP 3.0.43.29 (versione 2.15 per 3.0.43. * Non funziona - la configurazione è stata cambiata molto).

Cambiato:

Dialogo per la scelta dell'opzione di connessione, il flag Client-server è sempre disponibile, a seconda della sua installazione, è disponibile la scelta della cartella di base del file o il campo con il nome della base sul server e il nome del server stesso (corretto l'errore della versione di dialogo 2.15)

- NUOVO FUNZIONALE: Il meccanismo per la riconciliazione di residui e rivoluzioni tra le basi della sorgente e del ricevitore in vari gradi di dettaglio:

Penso che la scelta delle opzioni di riconciliazione sia chiara dalla figura:

Ci sono differenze nell'uso nel thin e thick client: in thick, viene immediatamente visualizzata la finestra di confronto dei file:

Nel thin client, non ho pervertito con la pressione dei pulsanti programmatica, propongo una semplice opzione per visualizzare la finestra di confronto:

Il confronto in un thin client, IMHO, è più conveniente, dal momento che ha pulsanti di navigazione per le differenze, che è più conveniente per grandi volumi di tabelle rispetto allo scorrimento con il mouse:

22/03/2016 Versione 3.10 - Aggiunto il flag "Sovrascrivi sempre i collegamenti" per la sovrascrittura obbligatoria degli oggetti referenziati (la velocità di trasferimento è notevolmente ridotta, ma a volte è necessaria). Aggiunto il tab "Preparazione", dove è possibile configurare la corrispondenza dei piani dei conti di origine e di destinazione (a livello dei codici conto) e il trasferimento delle costanti. Piattaforma 8.3.7.1970, BP 3.0.43.148

- NUOVO FUNZIONALE: Prima di trasferire i documenti, si consiglia di controllare il piano dei conti per la coerenza nella fonte e nella destinazione, nonché la coerenza delle costanti stabilite.

Per fare ciò, è stata aggiunta la scheda "Preparazione" in cui è possibile impostare queste corrispondenze:

L'algoritmo per la compilazione della tabella di corrispondenza dei conti è semplice: vengono analizzati i fatturati esistenti nella fonte e ogni conto trovato viene ricercato per una corrispondenza dal codice nel destinatario, se non viene trovata alcuna corrispondenza, una riga con il il codice del conto viene visualizzato nella tabella, con cui è necessario selezionare l'account del destinatario, verrà utilizzato al momento del trasferimento. La corrispondenza della scienza è stabilita a livello di codici.

Per verificare e trasferire la corrispondenza delle costanti impostate si utilizza la tabella corrispondente:

Compiliamo, se necessario, trasferiamo. Vengono trasferite solo le costanti contrassegnate da un flag...

Lo stack del programma è un'area speciale di memoria organizzata sulla base di una coda LIFO (Last in, first out - last in, first out). Il nome "stack" deriva dall'analogia del principio della sua costruzione con una pila di piatti: puoi mettere i piatti uno sopra l'altro (il metodo di aggiunta alla pila, "spingere", "spingere"), e quindi raccogliendoli, partendo dall'alto (metodo per ottenere valore dallo stack, "pop", "pop"). Lo stack del programma è anche chiamato stack di chiamate, stack di esecuzione, stack della macchina (per non essere confuso con lo "stack" - una struttura di dati astratta).

A cosa serve una pila? Consente di organizzare comodamente la chiamata dei sottoprogrammi. Quando viene chiamata, la funzione riceve alcuni argomenti; deve anche memorizzare le sue variabili locali da qualche parte. Inoltre, si dovrebbe tenere in considerazione che una funzione può chiamare un'altra funzione, che deve anche passare parametri e memorizzare le sue variabili. Usando lo stack, quando passi i parametri, devi solo metterli nello stack, quindi la funzione chiamata sarà in grado di "spingerli" fuori da lì e usarli. Le variabili locali possono anche essere archiviate nello stesso posto: all'inizio del suo codice, la funzione alloca parte della memoria dello stack, quando il controllo ritorna, la cancella e la libera. I programmatori in linguaggi di alto livello di solito non pensano a queste cose: il compilatore genera tutto il codice di routine necessario per loro.

Conseguenze di un errore

Ora siamo molto vicini al problema. Nella sua forma astratta, una pila è un deposito infinito a cui possono essere aggiunti all'infinito nuovi elementi. Sfortunatamente, nel nostro mondo, tutto è finito e la memoria sotto lo stack non fa eccezione. Cosa succede se termina quando gli argomenti della funzione vengono inseriti nello stack? Oppure la funzione alloca memoria per le sue variabili?

Si verificherà un errore chiamato stack overflow. Poiché lo stack è necessario per organizzare la chiamata di funzioni definite dall'utente (e quasi tutti i programmi su lingue moderne, compresi quelli orientati agli oggetti, sono in qualche modo costruiti sulla base di funzioni), non potranno più essere chiamati. Pertanto, il sistema operativo assume il controllo, cancella lo stack e termina il programma. Qui puoi enfatizzare la differenza tra e stack overflow: nel primo caso, si verifica un errore quando si accede all'area di memoria sbagliata e, se non c'è protezione in questa fase, non si manifesta in quel momento - con una coincidenza riuscita di circostanze, il programma può funzionare normalmente. Se solo la memoria a cui si accedeva era protetta, succede. Nel caso di uno stack, il programma termina senza fallo.

Per essere precisi, va notato che questa descrizione degli eventi è vera solo per i compilatori che compilano in codice nativo. Nei linguaggi gestiti, la macchina virtuale ha il proprio stack per i programmi gestiti, il cui stato è molto più semplice da monitorare e puoi persino permetterti di lanciare un'eccezione al programma quando si verifica un overflow. Nei linguaggi C e C++ non si può contare su un simile "lusso".

Motivi dell'errore

Cosa può portare a una situazione così spiacevole? In base al meccanismo sopra descritto, un'opzione è troppe chiamate di funzione nidificate. Questo scenario è particolarmente probabile quando si utilizza la ricorsione. In questo modo si interrompe la ricorsione infinita (in assenza di un meccanismo di valutazione "pigro"), a differenza che a volte trova un'utile applicazione. Tuttavia, con una piccola quantità di memoria allocata per lo stack (che, ad esempio, è tipica dei microcontrollori), può essere sufficiente una semplice sequenza di chiamate.

Un'altra opzione sono le variabili locali che richiedono molta memoria. Avere un array locale di un milione di elementi o un milione di variabili locali (non si sa mai cosa succede) non è l'idea migliore. Anche una singola chiamata a una funzione così avida può facilmente causare un overflow dello stack. Per ottenere grandi quantità di dati, è meglio utilizzare i meccanismi di memoria heap, che ti permetteranno di gestire l'errore della sua carenza.

Tuttavia, la memoria heap è piuttosto lenta in termini di allocazione e deallocazione (poiché il sistema operativo lo fa) e quando accesso diretto devi assegnarlo manualmente e rilasciarlo. La memoria nello stack viene allocata molto rapidamente (infatti, è sufficiente modificare il valore di un registro), inoltre, i distruttori vengono chiamati automaticamente per gli oggetti allocati sullo stack quando la funzione ritorna e lo stack viene azzerato. Naturalmente, sorge immediatamente il desiderio di ottenere memoria dallo stack. Pertanto, il terzo modo per l'overflow è l'autoallocazione del programmatore nello stack. La libreria C fornisce la funzione alloca appositamente per questo scopo. È interessante notare che se la funzione per allocare la memoria dinamica malloc ha il suo "gemello" per liberarla, allora la funzione alloca non ce l'ha - la memoria viene liberata automaticamente dopo il ritorno del controllo della funzione. Forse questo complica solo la situazione: dopotutto, non sarà possibile liberare memoria prima di uscire dalla funzione. Anche se, secondo la pagina man, "alloca dipende dalla macchina e dal compilatore; su molti sistemi la sua implementazione è problematica e contiene molti bug; il suo uso è molto frivolo e disapprovato" - è ancora usato.

Esempi di

Ad esempio, considera il codice per la ricerca di file ricorsiva che si trova su MSDN:

Void DirSearch (String * sDir) (try (// Trova le sottocartelle nella cartella passata. String * d = Directory :: GetDirectories (sDir); int numDirs = d-> get_Length (); for (int i = 0; io< numDirs; i++) { // Find all the files in the subfolder. String* f = Directory::GetFiles(d[i],textBox1->Testo); int numFiles = f-> get_Length (); per (int j = 0; j< numFiles; j++) { listBox1->Elementi-> Aggiungi (f [j]); ) DirSearch (d [i]); )) catch (Sistema :: Eccezione * e) (MessageBox :: Mostra (e-> Messaggio);))

Questa funzione ottiene un elenco di file nella directory specificata e quindi richiama se stessa per quegli elementi dell'elenco che si sono rivelati directory. Di conseguenza, con un albero del file system sufficientemente profondo, otterremo un risultato naturale.

Un esempio del secondo approccio, tratto dalla domanda "Perché si verifica un overflow dello stack?" da un sito chiamato Stack Overflow (il sito è una raccolta di domande e risposte a qualsiasi argomento di programmazione, non solo stack overflow, come potrebbe sembrare):

#define L 1000 #define H 1000 #define MAX 100000 // ... int main() (int image; float dtr; initImg (image, dtr); return 0;)

Come puoi vedere, nella funzione principale, la memoria è allocata sullo stack per array di tipi int e float con un milione di elementi ciascuno, che in totale danno poco meno di 8 megabyte. Considerando che per impostazione predefinita Visual C++ riserva solo 1 megabyte per lo stack, la risposta diventa ovvia.

Ed ecco un esempio tratto dal repository GitHub del progetto Lightspark Flash player:

DefineSoundTag :: DefineSoundTag (/ * ... * /) (// ... unsigned int soundDataLength = h.getLength () - 7; unsigned char * tmp = (unsigned char *) alloca (soundDataLength); // .. .)

Si spera che h.getLength () - 7 non sia troppo grande per evitare l'overflow sulla riga successiva. Ma il tempo risparmiato sull'allocazione della memoria vale il "potenziale" crash del programma?

Risultato

L'overflow dello stack è un errore fatale che colpisce più comunemente i programmi che contengono funzioni ricorsive. Tuttavia, anche se il programma non contiene tali funzioni, è comunque possibile l'overflow a causa del grande volume di variabili locali o di un errore nell'allocazione manuale della memoria sullo stack. Tutte le regole classiche rimangono in vigore: se c'è una scelta, è meglio preferire l'iterazione invece della ricorsione, e anche non fare lavori manuali al posto del compilatore.

Elenco bibliografico

E. Tanenbaum. Architettura del computer.
Wikipedia. Stack overflow.
Stack Overflow. Stack overflow C++.

Lo stack, in questo contesto, è l'ultimo nel primo buffer che allochi durante l'esecuzione del programma. Last, first (LIFO) significa che l'ultima cosa che metti è sempre la prima cosa che restituisci - se ottieni 2 elementi in pila, "A" e poi "B", la prima cosa che esci dalla pila sarà "B" e la prossima cosa sarà "A".

Quando si chiama una funzione nel codice, il comando successivo alla chiamata di funzione viene archiviato nello stack e in qualsiasi spazio di memoria che può essere sovrascritto dalla chiamata di funzione. La funzione selezionata può utilizzare più stack per le proprie variabili locali. Al termine, libererà lo spazio variabile locale che stava utilizzando e quindi tornerà alla funzione precedente.

Stack overflow

L'overflow dello stack è quando hai utilizzato più memoria per lo stack rispetto a quella che il tuo programma intendeva utilizzare. Nei sistemi embedded, puoi avere solo 256 byte per lo stack e se ogni funzione è 32 byte, puoi avere solo 8 chiamate di funzione alla funzione 2 con la funzione profonda 1, che chiama la funzione 3, che chiama la funzione 4 ... who chiama la funzione 8, che chiama la funzione 9, ma la funzione 9 sovrascrive la memoria all'esterno dello stack. Questo può sovrascrivere memoria, codice, ecc.

Molti programmatori commettono questo errore chiamando la funzione A, che quindi chiama la funzione B, che quindi chiama la funzione C, che quindi chiama la funzione A. Può funzionare la maggior parte delle volte, ma solo un input sbagliato lo farà girare per sempre fino a quando il computer apprende che lo stack è pieno.

Anche le funzioni ricorsive causano questo, ma se stai scrivendo in modo ricorsivo (cioè la tua funzione chiama se stessa) allora devi esserne consapevole e usare variabili statiche / globali per prevenire la ricorsione infinita.

In genere, il sistema operativo e il linguaggio di programmazione che stai utilizzando gestiscono lo stack e questo è fuori dalle tue mani. Dovresti guardare il tuo grafico delle chiamate (una struttura ad albero che mostra dal tuo punto principale ciò che ogni funzione chiama) per vedere quanto sono profonde le tue chiamate di funzione e identificare i cicli e la ricorsione che non sono previsti. I cicli intenzionali e la ricorsione devono essere controllati artificialmente per errori se si chiamano a vicenda troppe volte.

A parte buone pratiche di programmazione, test statici e dinamici, non c'è molto che puoi fare su questi sistemi. alto livello.

Sistemi integrati

Nel mondo embedded, in particolare nel codice ad alta affidabilità (automotive, aviazione, spazio), esegui controlli e convalide approfondite del codice, ma fai anche quanto segue:

Non consentire ricorsione e loop - Conformità con criteri e test
Mantieni il codice e lo stack distanti (codice in flash, stack in RAM e non corrisponderà mai)
Posiziona le strisce di protezione attorno allo stack: un'area vuota di memoria che riempi con un numero magico (di solito un programma di interruzione, ma qui ci sono molte opzioni) e centinaia o migliaia di volte al secondo guardi le strisce di guardia per assicurati che non siano stati sovrascritti.
Utilizzare la protezione della memoria (ovvero, non eseguire sullo stack, non leggere o scrivere direttamente sullo stack)
Gli interrupt non chiamano funzioni secondarie: impostano flag, copiano dati e lasciano che l'applicazione si occupi di gestirli (altrimenti, potresti ottenere 8 in profondità nell'albero delle chiamate di funzione, avere un interrupt e quindi alcune altre funzioni all'interno dell'interrupt in uscita, provocando uno scoppio). Hai più alberi di chiamata, uno per i processi principali e uno per ogni interrupt. Se le tue interruzioni possono interrompersi a vicenda... beh, ci sono i draghi...

Linguaggi e sistemi di alto livello

Ma in linguaggi di alto livello in esecuzione su sistemi operativi:

Ridurre memoria locale variabili (le variabili locali sono memorizzate nello stack), sebbene i compilatori siano piuttosto intelligenti su questo e a volte inseriranno grandi blocchi nell'heap se l'albero delle chiamate è piccolo)
Evitare o limitare severamente la ricorsione
Non interrompere troppo i tuoi programmi in funzioni sempre più piccole - anche ignorando le variabili locali, ogni chiamata di funzione consuma fino a 64 byte nello stack (processore a 32 bit, mantenendo metà dei registri del processore, flag, ecc.).
Mantieni l'albero dei richiami poco profondo (simile a sopra)

Server web

Dipende dalla sandbox che hai, se puoi controllare o anche vedere lo stack. È probabile che tu possa gestire i server web come qualsiasi altro linguaggio di alto livello e sistema operativo, è praticamente fuori dalle tue mani, ma controlla la lingua utilizzata e lo stack del server. Ad esempio, è possibile dividere lo stack sul server SQL.