Notă explicativă a exemplului de proiect tehnic. Notă explicativă la proiectul tehnic conform GOST. Moduri de operare a sistemului

Un exemplu de „Notă explicativă” (P2 on) dezvoltată pentru un sistem automat de măsurare și informare pentru contorizarea comercială a energiei electrice (AIIS KUE) în conformitate cu k și document. de i. Ediție din data de 20.06.2018.

Notă explicativă (P2 conform GOST 34.201-89) a sistemului automat de măsurare și informare pentru măsurarea energiei electrice comerciale (AIIS KUE) (exemplu)

Creat la 25.03.2014 11:48:18

Atenţie! Cerinte tehnice al Pieței cu ridicata a energiei electrice (WEM), referiri la ale căror puncte sunt cuprinse în exemplele de documente pentru sisteme automate de măsurare și informare pentru contorizarea energiei electrice comerciale (AIIS KUE), se modifică destul de des, dar nu de către noi, ci de către administrator. a sistemului de tranzacționare (ATS). Vă rugăm să tratați asta cu înțelegere.

Toate documentele luptă, care au promovat multe, inclusiv examene la Întreprinderea Unitară Federală de Stat „Institutul de Cercetare All-Rusian pentru Standardizare și Certificare în Inginerie Mecanică” (VNIIMASH) de la ROSSTANDART, prin urmare, nu există nicio îndoială.

Pentru obtinerea gratuit este suficientă o versiune prescurtată a oricărui *.pdf pentru a da clic pe pagina de titlu. Documentul se va deschide în browser cu opțiunea de a. Versiuni complete documente - plătite, pot fi obținute în format pentru o anumită sumă, folosind. Orice document poate fi finalizat pentru anumite cerințe ale clienților pentru o perioadă de timp. Se discută termenii.

27.10.2016 09:57:23

Acest articol discută etapa de proiectare tehnică legată de una dintre etapele ciclului de viață al sistemului securitatea informatiei(NIB) - etapa de „proiectare”, care, în conformitate cu standard intern GOST 34.601-90 urmează imediat dezvoltarea Termenilor de referință pentru un sistem de securitate a informațiilor.

1. Elaborarea documentației tehnice a proiectului pentru BNI

Ciclul de viață al unui sistem de securitate a informațiilor (denumit în continuare - SIS) în vedere generala constă din următorii pași:

• analiza cerințelor pentru ISS;
• proiecta;
• implementare;
• implementare;
• exploatare.

Acest articol discută stadiul proiectului tehnic legat de etapa „proiectare” și, în conformitate cu standardul intern GOST 34.601-90, urmează imediat dezvoltarea Termenilor de referință pentru sistemul de securitate a informațiilor.

1.1. De ce să dezvoltați documentația pentru NIB?

Răspunsul la această întrebare ar trebui luat în considerare în două planuri: în planul proprietarului resurse informaționale(pentru protecția căruia este creat NIS) și în planul dezvoltatorului direct al NIS.

Pentru proprietarul resurselor informaționale, este important să obțină rezultatul sub forma unui sistem de securitate a informațiilor funcțional, care să reducă riscurile de a compromite informații cu acces restricționat în organizație. Proiectul tehnic în acest caz servește la dezvoltarea bazelor fundamentale ale viitorului sistem, și anume, include o descriere a modului în care va fi construit și funcționa ISS, ce măsuri și mijloace vor asigura protecția informațiilor, care sunt posibilitățile de dezvoltare si imbunatatirea sistemului. La finalizarea dezvoltării unui proiect tehnic pentru un sistem de securitate a informațiilor, Clientul primește un set cuprinzător de documentație pentru NIS, care descrie toate nuanțele tehnice ale viitorului sistem.

Pentru executantul direct din etapa proiectului tehnic, este necesar să se stabilească cea mai adecvată arhitectură a NIS, precum și să se realizeze alegerea potrivita măsuri şi mijloace de protecţie a informaţiilor din organizaţie. De asemenea, este important să se asigure că caracteristicile și proprietățile sistemului respectă termenii de referință sau să se justifice, cu participarea și acordul Clientului, ajustarea cerințelor specificate în TOR pentru a crește eficiența sistemul care se creează.

Astfel, ca urmare a elaborării documentației tehnice a proiectului, Clientul va avea răspunsuri la următoarele întrebări:

• care este arhitectura generală a BNI;
• ce măsuri și mijloace vor fi utilizate pentru implementarea cerințelor de protecție a informațiilor;
• cum va funcționa NIS;
• ce schimbări în organizație, necesare creșterii nivelului de securitate a informațiilor, vor urma ca urmare a introducerii ISS;
• dacă cerințele Clientului (cerințe de afaceri) și cerințele actelor juridice de reglementare în domeniul securității informațiilor vor fi luate în considerare la elaborarea și implementarea ISS și, dacă da, cum.

Antreprenorul aflat în curs de elaborare a documentației tehnice a proiectului va primi următoarele rezultate:

• baza pentru trecerea la etapele următoare de construire a INS, și anume etapele de documentare de lucru și implementare;
• înțelegerea arhitecturii, tehnologiilor și instrumentelor utilizate, ordinea de construire a sistemului;
• modul în care sunt implementate cerințele Clientului (cerințe de afaceri) și documentele de reglementare în domeniul securității informațiilor pentru sistem.

1.2. Prezentare generală a abordărilor pentru dezvoltarea documentației tehnice a proiectului

Elaborarea unui proiect tehnic pentru un sistem de securitate a informațiilor se realizează cel mai adesea pe baza standardelor relevante și a documentelor de orientare. Si pentru institutii publice utilizarea lor este obligatorie, iar in scopuri comerciale este recomandata. La practică organizatii comerciale De asemenea, utilizați standardele de stat atunci când elaborați documentația tehnică a proiectului din următoarele motive:

• abordare dovedită în mod repetat a creării de sisteme informaționale;
• structura și conținutul atent al documentelor;
• un set de documente suficient pentru dezvoltarea și descrierea aproape a oricărui sistem.

Pentru elaborarea documentației pentru etapa proiectului tehnic (TP) pe BNI se folosesc standarde de stat și documente de orientare din seria 34:

• GOST 34.201-89 „Tipurile, completitudinea și desemnarea documentelor atunci când se creează sisteme automate”. Acest standard specifică:
  • tipuri și denumiri de documente ale etapei TP;
  • caracterul complet al documentației;
  • denumiri acceptate ale documentelor;
  • reguli pentru desemnarea NIB-urilor și a părților acestora.
• GOST 34.003-90 „Termeni și definiții”;
• GOST 34.601-90 „Sisteme automatizate. Etapele creației. Standardul specifică:
  • lista etapelor de lucru efectuate la etapa TP;
  • descriere detaliata lucrari efectuate in etapa TP;
  • lista organizațiilor care participă la crearea INS;
• RD 50-34.698-90 „Sisteme automatizate. Cerințe pentru conținutul documentelor. Acest document de orientare specifică cerințele pentru conținutul documentelor de etapă AT.

Este important de înțeles că, conform standardelor din seria 34, un proiect tehnic este o etapă în crearea unui sistem, și nu doar un set de documente. Această etapă în practică este adesea combinată cu etapa proiect de proiect, care servește la elaborarea mai multor soluții preliminare și la fundamentarea celei mai potrivite. O astfel de combinație este permisă de standard, dar trebuie avut în vedere că aceasta nu anulează necesitatea atingerii obiectivelor etapei preliminare de proiectare.

Cel mai adesea, etapa de proiectare a proiectului este dezvoltată atunci când cerințele specificațiilor tehnice pentru sistem pot fi implementate în mai multe moduri fundamental diferite și, de asemenea, dacă nu există metode preferate fără ambiguitate printre aceste metode.

Cu toate acestea, trebuie remarcat faptul că standardele de mai sus sunt prea generale și implementează în principal o funcție de proiectare și structurală generală. Pentru a dezvolta partea de fond a documentelor etapei de proiectare tehnică, proiectanții folosesc informații din următoarele surse:

Documente de reglementare actuale (NLA) care reglementează cerințele de protecție a uneia sau aceleia informații cu acces limitat. Aceste RLA prezintă cerințele pentru măsurile de protecție a informațiilor din sistemele informaționale, descriu nuanțele implementării acestor măsuri și măsuri suplimentare de consolidare. Dintre NPA-urile actuale se pot distinge următoarele:

• Ordinul FSTEC al Rusiei din 18 februarie 2013 nr. 21 „Cu privire la aprobarea compoziției și conținutului măsurilor organizatorice și tehnice pentru asigurarea securității datelor cu caracter personal atunci când acestea sunt prelucrate în sistemele de informații cu date cu caracter personal”;
• Ordinul FSTEC al Rusiei din 11 februarie 2013 nr. 17 „Cu privire la aprobarea cerințelor de protecție a informațiilor care nu sunt secrete de stat conținute în sistemele informaționale de stat”
• Ordinul FSTEC al Rusiei din 14 martie 2014 nr. 31 „Cu privire la aprobarea cerințelor pentru asigurarea protecției informațiilor în sisteme automatizate producție și procese tehnologice pe critic obiecte importante, obiecte potențial periculoase, precum și obiecte care prezintă un pericol crescut pentru viața și sănătatea oamenilor și pentru mediu mediul natural;
• document metodologic „Măsuri de protecție a informațiilor în sistemele informaționale de stat”, aprobat de FSTEC din Rusia la 11 februarie 2014

Cerințele pentru protecția informațiilor de acces restricționat și listele de măsuri de protecție variază pentru IS de diferite niveluri/clase de securitate. Dacă informațiile din organizație nu aparțin celor protejați în conformitate cu legi federale RF (de exemplu, un secret oficial), atunci proprietarul acestor informații poate folosi abordările propuse în aceste acte juridice pentru a construi un ISS corporativ.

Descrierea standardelor ruse și străine abordări diferite la metodele de implementare a etapelor ciclului de viață al construcției NIS, inclusiv etapele proiectului tehnic:

• o serie de standarde de stat GOST R ISO / IEC 2700X, identice standarde internaționale ISO/IEC 2700X. Aceste standarde descriu abordare procesuala PDCA (Planificați, faceți, verificați, acționați) la implementarea ciclului de viață al sistemului de management al securității informațiilor, care este parte integrantă a ISS;
• NIST SP 800-64 este un standard al Institutului Național de Standarde și Tehnologie din SUA care descrie ciclu de viață dezvoltarea sistemelor informatice;
• NIST SP 800-37 este un standard al Institutului Național de Standarde și Tehnologie din SUA, care oferă îndrumări privind integrarea managementului riscurilor în ciclul de viață al dezvoltării sistemelor informatice.

Documentația operațională a producătorului pentru echipamentele de securitate a informațiilor și echipamentele auxiliare. Aceste documente conțin informații tehnice cuprinzătoare despre instrumentele utilizate în construcția ISS, inclusiv cele care nu au legătură directă cu implementarea măsurilor IS, de exemplu, servere, sisteme de stocare a datelor, instrumente de virtualizare și altele. Setul general de astfel de documente pentru diferiți producători este diferit și depinde, printre altele, de execuția unui anumit instrument (hardware/software). Mai jos este un set standard de documentație operațională pentru instrumentele de securitate a informațiilor utilizate pentru elaborarea documentelor pentru etapa de proiect tehnic:

• descriere generală (fișă de date);
• ghidul administratorului (poate include local și management centralizat);
• manualul utilizatorului;
• ghid rapid de instalare și implementare (pentru GIS hardware);
• manual de utilizare;
• ghid de implementare a infrastructurii virtuale (pentru software GIS);

Informații generale despre arhitecturile NIS disponibile, cele mai bune practici în ceea ce privește construirea NIS, îndrumări privind securitatea și integrarea sistemelor de securitate a informațiilor între ele, informații despre problemele în interacțiunea anumitor sisteme de securitate a informațiilor. Exemple de astfel de informații pot include următoarele documente:

• ghiduri de arhitectură a sistemului de securitate a informațiilor, de exemplu: Defense-in-Depth, Cisco SAFE, Check Point SDP și altele;
• cele mai bune practici de securitate a informațiilor, cum ar fi cele disponibile la aceste link-uri (https://www.sans.org/reading-room/whitepapers/bestprac/ , http://csrc.nist.gov/publications/nistpubs/800-14/ 800-14.pdf). Aceste documente sunt cel mai adesea prezentate pe Limba engleză, cu toate acestea, orice producător rus de echipamente de securitate a informațiilor are propriile bune practici pentru implementarea echipamentelor de protecție și le poate furniza la cerere;
• ghiduri de siguranță pentru IPS și medii de operare. Un exemplu este secțiunea „Securitate” de pe portalul oficial Microsoft (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).

1.3. Dezvoltarea unui proiect tehnic pentru NIB în conformitate cu GOST 34

Elaborarea documentelor pentru etapa de proiect tehnic la INS este realizată cel mai adesea de integratori ai acestor servicii și este implementată în principal în conformitate cu următorul plan:

Stabilirea listei de documente în curs de elaborare - această informație este indicată în termeni de referinta pe NIB. În unele cazuri, elaboratorul documentelor, de comun acord cu Clientul, poate extinde sau reduce această listă, dacă posibilitatea acestui lucru este prevăzută în TOR;

Dezvoltarea șabloanelor de documente pentru etapa TP - structura este utilizată în conformitate cu RD 50-34.698-90 și GOST 2.106 (pentru unele documente), execuție în conformitate cu GOST 2.105-95;

Dezvoltarea părții de fond a documentelor. Cerințele pentru sistem sunt stabilite în termenii de referință pentru NIB. În conformitate cu aceste cerințe, se stabilește o listă a măsurilor tehnice și organizatorice de protecție necesare implementării în sistem. Măsurile de protecție pot fi definite în actele juridice relevante (în funcție de tipul de informații care se protejează), standardele corporative și politicile de securitate a informațiilor, precum și pe baza prezenței amenințărilor de securitate curente identificate în etapa de dezvoltare a modelului de amenințare al organizației. Pe baza listei de măsuri de protecție, dezvoltatorul ISS selectează instrumentele adecvate de protecție a informațiilor și dezvoltă structura funcțională a sistemului de securitate a informațiilor (subsisteme, componente). În continuare, în documentele tehnice de proiectare este descris implementare practică măsuri de protecție bazate pe GIS-ul selectat sau măsuri organizatorice în infrastructura organizației.

Coordonarea documentatiei elaborate si a solutiilor prezentate in aceasta cu Clientul sistemului.

La elaborarea documentației tehnice a proiectului, cel mai adesea nu este necesară elaborarea unei liste complete de documente specificate în GOST 34.201-89, deoarece acest standard este învechit și unele dintre documente nu iau în considerare tendințele de dezvoltare și tehnologiile sistemelor informaționale moderne. . Setul minim de documente necesare pentru a descrie un sistem de securitate a informațiilor este următorul:

• descrierea proiectului tehnic;
• notă explicativă la proiect tehnic;
• sistem structură funcțională;
• diagrama structurală a unui complex de mijloace tehnice;
• Organigrama;
• lista de articole achizitionate.

La cererea Clientului sau dacă NIS este un sistem complex multicomponent, pot fi elaborate suplimentar următoarele documente:

• schema de automatizare;
• descrierea funcțiilor automate;
• Descriere suport informativ sisteme;
• descrierea complexului de mijloace tehnice;
• descrierea software-ului;
• descrierea structurii organizatorice.

Trebuie remarcat faptul că GOST 34.201-89 permite extinderea gamei de documente în etapa TP, cu toate acestea, în practică, aceste documente sunt mai mult decât suficiente.

Fisa de proiect tehnic

Denumire: TP.

Acest document are scopul de a descrie lista documentelor elaborate la etapa proiectului tehnic. De asemenea, este indicat numărul de pagini ale fiecărui document elaborat.

Notă explicativă la proiectul tehnic

Denumire: P2.

Acest document este principalul pentru etapa TP și include o descriere a arhitecturii ISS, măsuri tehnice și organizatorice, funcții ISS, complexe software și hardware și altele. Conform standardului, acesta constă din patru secțiuni principale:

• Dispoziții generale;
• descrierea procesului de activitate;
• principalele soluții tehnice;
• măsuri de pregătire a obiectului de automatizare pentru punerea în funcţiune a sistemului.

Diagrama structurii funcționale

Denumire: C2.

Acest document descrie structura logică a NIS, și anume:

• subsisteme și componente logice incluse în NIS;
• funcții implementate prin intermediul subsistemelor și componentelor;
• legături de informații între elementele logice ale NIS și tipurile de mesaje din schimb.

Diagrama structurală a unui complex de mijloace tehnice

Denumire: C1.

Acest document include o descriere a următoarelor elemente ale NIS:

• mijloace tehnice ca parte a subsistemelor și componentelor logice ale NIS;
• canale de comunicare şi schimb între mijloace tehnice cu indicarea protocoalelor de transport.

Schema de organizare

Denumire: C0.

Acest document descrie structura organizationala organizații în ceea ce privește managementul NIS și anume:

• diviziuni și persoane responsabile organizațiile implicate în funcționarea INS;
• funcțiile îndeplinite și comunicările între departamente și persoanele responsabile.

Lista produselor achizitionate

Denumire: VP.

Acest document include o listă a tuturor software-ului și hardware-ului, precum și a licențelor utilizate la crearea NIS. Dezvoltat în conformitate cu GOST 2.106.

Notă. De asemenea, este de remarcat aici că actul de guvernare RD 50-34.698-90 permite adăugarea oricărui document al etapei TP (includerea de secțiuni și informații altele decât cele propuse), comasarea secțiunilor, precum și excluderea unor secțiuni individuale. Deciziile în acest sens sunt luate de dezvoltatorul documentelor din etapa TP și se bazează pe caracteristicile NIS-ului creat.

1.4. Reguli de elaborare a documentației

• conformitatea structurală standardele de stat;
• respectarea strictă a cerințelor specificațiilor tehnice pentru sistem;
• aplicarea șabloanelor de documente (aplicarea de stiluri uniforme, marcare, câmpuri etc.);
• abordarea individuală și utilizarea simultană a dezvoltărilor existente la completarea secțiunilor de documente.

Notă explicativă la proiectul tehnic:

• elaborarea documentelor se realizează în mediu Microsoft Word, după finalizarea dezvoltării, se recomandă convertirea documentului în format PDF pentru comoditate;
• termenii și abrevierile ar trebui să fie aceleași în toate secțiunile documentului;
• se recomandă evitarea repetărilor explicite și a creșterii inutile a volumului documentului;
• soluțiile tehnice trebuie descrise cât mai detaliat posibil, indicând:
  • arhitectura si tehnologiile utilizate;
  • locațiile software și hardware în infrastructura organizației;
  • instrumente de securitate a informațiilor utilizate cu o descriere a caracteristicilor acestora, funcții implementate, informații de certificare;
  • setările de bază ale instrumentelor de securitate a informațiilor în ceea ce privește mecanismele de protecție, adresare, rutare, interacțiune cu sisteme și instrumente aferente și alte lucruri;
  • comenzile, metodele de acces la acestea și locațiile de instalare ale acestora;
  • scheme (structurale, funcționale, organizaționale):
    • dezvolta diagrame în mediul Microsoft Visio;
    • după dezvoltare, inserați diagrame într-un document utilizând dialogul Paste Special în format EMF (metafișier Windows);
    • dezvoltarea schemelor separate pentru sistem, subsisteme și componente ale subsistemelor;
    • faceți designul schemelor de același tip, folosind aceleași elemente, abrevieri, pictograme, stiluri de text și așa mai departe.

1.5. Resurse pentru a vă ajuta să dezvoltați documentația

Pe Internet este postată o cantitate imensă de informații care, într-o măsură sau alta, pot ajuta la elaborarea documentației tehnice a proiectului. Principalele resurse sunt prezentate în tabelul de mai jos.

Masa. Resurse de proiectare de inginerie NIS

tipul de resursă	informație	Exemple de resurse
Portaluri de internet ale autorităților executive federale	Reguli, instrucțiuni, registre (inclusiv facilități de securitate a informațiilor certificate), baze de date (inclusiv baze de date cu vulnerabilități și amenințări)	fstec.ru clsz.fsb.ru minsvyaz.ru/ru/
Portaluri de internet ale producătorilor de IS, distribuitorilor de soluții de securitate a informațiilor	Descrierea soluțiilor de securitate a informațiilor, documentație operațională pentru securitatea informațiilor, materiale și articole analitice	securitycode.ru kaspersky.com/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html checkpoint.com altx-soft.ru
Resurse specializate de securitate a informațiilor	Comparație de soluții de securitate a informațiilor, articole de recenzie despre soluțiile de securitate a informațiilor, teste de soluții de securitate a informațiilor, informații tehnice aprofundate despre tehnologiile de securitate a informațiilor	anti-malware.ru bis-expert.ru safe.cnews.ru securitylab.ru/ www.vulners.com/ csrc.nist.gov itssecurity.com owasp.org sans.org

1.6. Exemple de documente ale etapei proiectului tehnic

Pentru a înțelege cerințele pentru conținutul documentației etapei TP, mai jos sunt prezentate exemple de completare a documentelor principale (secțiuni de documente).

1.6.1. Notă explicativă la proiectul tehnic

Nota explicativă este un document destul de voluminos, prin urmare, iată un exemplu de conținut al secțiunii „Soluții tehnice de bază” în ceea ce privește unul dintre subsistemele ISS - subsistemul de analiză a securității.

Subsistemul de analiză de securitate NIS

Structura și componența subsistemului

Subsistemul de analiză a securității (SAS) este conceput pentru a monitoriza sistematic starea de securitate a stațiilor de lucru automate (AWP) ale personalului și serverelor organizației. Baza PAZ este instrumentul software „Test” produs de compania LLC „Securitate informațională”. SZI Test are un certificat de conformitate FSTEC din Rusia specificații(TU) privind securitatea informațiilor și pe al 4-lea nivel de control al absenței capacităților nedeclarate.

Compoziția PAZ include următoarele componente:

• Server de administrare Test Server;
• consola de testare a consolei de management.

Descrierea componentelor subsistemului este prezentată în tabelul de mai jos.

Masa. Componentele PAZ

Componentă	Descriere
Server de gestionare a serverului de testare	Oferă gestionarea sarcinilor de scanare, îndeplinește funcțiile de monitorizare a stării de securitate a stației de lucru și a serverelor organizației. Parametrii de scanare sunt stabiliți de administratorul IS pe serverul de management Test Server. Toate informațiile colectate rezultatele scanării sunt stocate în stocarea Test Server bazată pe sistemul de gestionare a bazelor de date Microsoft SQL Server 2008
Test Console Management Console	Permite administratorului IS să se conecteze la Test Server, să vizualizeze și să modifice configurația acestuia, să creeze și să modifice sarcini pentru efectuarea scanărilor, să vadă informații despre progresul sarcinilor și rezultatele acestora. Consola de management este instalată pe stația de lucru a administratorului de securitate a informațiilor

Furnizare de caracteristici

PAZ oferă următoarele funcții:

• implementarea protecției proactive a stațiilor de lucru și serverelor organizației prin monitorizarea stării de securitate a informațiilor;
• automatizarea proceselor de monitorizare a conformității cu politicile interne și anumite standarde de securitate;
• reducerea costurilor de audit și control de securitate, pregătirea rapoartelor de stare;
• automatizarea inventarului de resurse, managementul vulnerabilităților, conformitatea cu politicile de securitate și procesele de control al schimbărilor.

Soluție pentru un complex de instrumente hardware și software

Lista de software și hardware utilizate de ESD este prezentată în tabelul de mai jos.

Masa. software- mijloace tehnice CANELURĂ

Server de control PAZ

Mijloace tehnice

Serverul fizic utilizat ca server de management SIS trebuie să îndeplinească cerințele tehnice pentru software-ul și OS instalat pe acesta, prezentate în tabelul de mai jos.

Masa. Cerințe pentru sistemul de operare și software-ul serverului de management PAZ

Software	Cerinte tehnice
	CPU	RAM, MB
Microsoft Windows Server 2008 R2	3000 MHz, 4 nuclee	8192
Microsoft SQL Server 2008 R2
Testați software-ul serverului

Software

Management Server OS

Sistemul de operare Windows 2008 R2 este instalat pe serverul de management în mod standard dintr-o distribuție bootabilă.

Sistemul de operare al serverului de management este gestionat atât local din consolă, cât și prin protocolul RDP.

Server de management DBMS

Instalarea bazei de date Microsoft SQL Server 2008 R2 se realizează sub un cont cu drepturi de administrator local utilizând vrăjitorul de instalare standard din pachetul de distribuție furnizat de dezvoltatorul produsului.

Testați software-ul serverului

Software-ul Test Server este instalat pe serverul de management folosind asistentul standard de instalare.

Configurarea inițială și gestionarea ulterioară a software-ului Test Server în modul normal se realizează utilizând consola de management Test Console instalată pe stația de lucru a administratorului IS.

Stație de lucru administrator IS

Mijloace tehnice

Ca platformă, este utilizată o stație de lucru existentă a unui angajat al unității organizaționale responsabilă cu asigurarea securității informațiilor, care rulează sistemul de operare al familiei Microsoft Windows.

Mijloacele tehnice ale stației de lucru administrator IS trebuie să aibă următoarele caracteristici ale configurației hardware (cel puțin recomandate):

• CPU 2 GHz;
• RAM 4 GB;
• HDD 80 GB.

Software

Software-ul consolei de testare

Stația de lucru a administratorului IS, pe care este instalat software-ul Test Console, trebuie să funcționeze sub unul dintre următoarele sisteme de operare:

• Microsoft Windows 7, 32 și 64 de biți;
• Microsoft Windows 8/8.1, 32 și 64 de biți.

În plus, pentru funcționarea corectă a software-ului consolei de management Test Console, stația de lucru a administratorului IS trebuie să aibă instalată Microsoft .NET Framework versiunea 3.5 SP1 sau o versiune ulterioară, iar setările de securitate ale SO utilizat trebuie să permită accesul la Test Server.

Instalarea software-ului Test Console pe stația de lucru a administratorului PAZ se realizează utilizând asistentul standard de instalare a software-ului Test Server, cu opțiunea de a instala consola de management Test Console și alte setări implicite.

Interacțiunea cu sistemele conexe

Pentru PAZ, adiacente sunt:

• mijloacele subsistemului firewall;
• servicii de directoare Active Directory;
• Stația de lucru și serverele organizației.

Pentru a asigura interacțiunea rețelei cu sistemele adiacente și direct între componentele ESD în sine, trebuie organizat trecerea traficului de rețea necesar.

Pentru a oferi posibilitatea de a primi actualizări ale bazei de cunoștințe și modulelor software-ului Test pentru scanerul Test Server, este necesar să oferiți acces la serverul web update.com al Information Security LLC update.com pe portul 443/tcp.

La scanarea în modul PenTest, interacțiunea dintre scanerul Test Server și stația de lucru și serverele organizației se realizează prin protocolul IP. La scanarea în modul Audit și Conformitate, sunt utilizate protocoalele de control de la distanță WMI, RPC etc.. Pentru a scana gazde pe dispozitive cu funcții de firewall, trebuie să permiteți conexiuni de la Serverul de testare la gazdele scanate prin protocolul IP. În consecință, pentru serverul de testare, este necesar să se ofere acces la porturile de rețea ale nodurilor scanate folosind protocoalele adecvate de control de la distanță.

Deoarece PAZ, atunci când scanează în modurile Audit și Conformitate, utilizează protocoale de control de la distanță pentru analiză, instrumentele de scanare ale software-ului Test trebuie să fie autentificate și autorizate pe nodul scanat. În PAZ, pentru a scana noduri în modurile Audit și Conformitate în fiecare dintre tipurile de noduri (stație de lucru, server, sisteme de aplicații, DBMS etc.) Conturi cu privilegii administrative.

Toate evenimentele de securitate a informațiilor înregistrate sunt stocate în Microsoft SQL DBMS. Aceste evenimente pot fi trimise prin conectori speciali la subsistemul de monitorizare a evenimentelor IS.

Exploatarea și întreținerea PAZ

Utilizatorii subsistemului

Operarea și întreținerea instrumentelor PAZ este efectuată de angajați ai organizației cu rolul funcțional de „administrator IS”.

Un administrator IS este un specialist ale cărui sarcini includ:

• definirea parametrilor pentru scanarea nodurilor organizației;
• configurarea și lansarea sarcinilor de scanare;
• analiza rezultatelor scanării pentru vulnerabilități, erori de configurare sau nerespectarea cerințelor standardelor tehnice în sistemele informaționale;
• controlul eliminării vulnerabilităților;
• formarea standardelor și cerințelor care se aplică pentru asigurarea securității stațiilor de lucru și serverelor organizației.

Moduri de operare a sistemului

Modul obișnuit de funcționare

În funcționare normală, PAZ funcționează 24 de ore pe zi, 7 zile pe săptămână.

În funcționare normală, administratorul IS efectuează:

• scanarea programată și neprogramată a nodurilor;
• generarea de rapoarte;
• actualizarea bazelor de cunoștințe și modulelor software-ului Test.

Operare de urgență

În cazul unei defecțiuni a mijloacelor PAZ, funcționarea subsistemului este întreruptă. Încălcarea operabilității mijloacelor PAZ nu afectează funcționarea stației de lucru și a serverelor organizației.

1.6.2. Diagrama structurii funcționale

Diagramele funcționale pot fi dezvoltate pentru întregul NIS sau pentru o parte a acestuia, cum ar fi un subsistem sau o componentă.

Un exemplu de diagramă funcțională generală a NIB este prezentat în figura de mai jos.

1.6.3. Diagrama structurală a unui complex de mijloace tehnice

O diagramă bloc a unui complex de mijloace tehnice poate fi dezvoltată atât pentru întregul NIS, cât și pentru părțile sale - subsisteme și componente. Actualitatea dezvoltării schemelor pentru părți ale NIS este determinată de amploarea sistemului și de detaliul necesar.

Exemplu diagramă bloc a complexului de mijloace tehnice ale NIS este prezentată în figura de mai jos.

O notă explicativă la proiectul tehnic este unul dintre principalele documente cuprinse în documentația întocmită la etapă proiectare tehnică. Nota explicativă conține informatii generale despre sistemul proiectat, rațiunea soluțiilor tehnice care au fost alese pentru crearea acestuia, precum și planul de acțiune, datorită căruia este planificată punerea în funcțiune a sistemului.

Structură și decor

O notă explicativă este întocmită în conformitate cu standardul interstatal GOST 2.106-96, care descrie Cerințe generale la compilarea textului și documentatia de proiectare, conținutul secțiunilor sale este descris în documentul de guvernare RD 50-34.698-90, care reglementează cerințele privind conținutul documentelor pentru sistemele automatizate de control.

Acest document, conform standardelor și liniilor directoare, ar trebui să conțină mai multe secțiuni:

"Dispoziții generale"
Indicarea denumirii sistemului de control automatizat în curs de dezvoltare, a documentelor pe baza cărora este dezvoltat sistemul - termeni de referință, contracte - organizații care sunt implicate în proiectare, etapele și termenele de realizare a lucrărilor, obiectivele dezvoltarea sistemului, scopul și domeniul de aplicare al acestuia, tehnic și documentatii normative, precum și ordinea lucrărilor de proiectare.

„Descrierea procesului de activitate”
Nota explicativă a proiectului tehnic conține informații generale despre funcționarea sistemului dezvoltat.

„Soluții tehnice de bază”
Este prezentată structura sistemului cu o listă de subsisteme, metode și mijloace de schimb de componente ale sistemului cu date, relația UA cu alte sisteme și moduri de operare. De asemenea, ar trebui să enumere calificările și numărul de angajați, funcțiile sistemului, mijloacele tehnice care asigură funcționarea acestuia, nevoile de informații și software.

„Pași pentru pregătirea sistemului pentru funcționare”
Este oferită o listă de lucrări privind instruirea personalului, aducerea datelor de ieșire ale sistemului într-o formă adecvată pentru utilizare ulterioară, organizarea locurilor de muncă, precum și alte activități care îndeplinesc specificul punerii în funcțiune a unui anumit sistem.

Mai jos este un exemplu (eșantion) de document de proiect " Notă explicativă la proiectul tehnic de realizare a unui sistem automatizat„pe baza ghidurilor metodologice RD 50-34.698-90. Acest document este format de un specialist IT la faza proiectarea tehnică a sistemului informaţional.

Ca exemplu de dezvoltare a unui sistem informatic a fost folosit proiectul de implementare a unui sistem informatic si analitic. „Depozitul de date corporative”.

Pe pagina de mai jos este continutul notei explicative a proiectului tehnicîn conformitate cu GOST, în cadrul fiecărei secțiuni pe scurt sunt date cerințele pentru conținutul și textul exemplului de completare(evidențiat printr-o linie verticală).

Secțiuni ale notei explicative:

Dispoziții generale

Principalele soluții tehnice

Deciziile privind structura sistemului, subsistemelor, mijloacelor și metodelor de comunicare pentru schimbul de informații între componentele sistemului

Soluții pentru interconectarea UA cu sistemele adiacente, asigurând compatibilitatea acesteia

Soluții pentru moduri de funcționare, diagnosticare funcționare a sistemului

Deciziile privind personalul și modurile de lucru ale acestuia

Informații privind asigurarea caracteristicilor de consum ale sistemului specificate în caietul de sarcini, care determină calitatea acestuia

Compoziția funcțiilor, complexe de sarcini implementate de sistem

Compoziția și amplasarea complexelor de mijloace tehnice

Notă explicativă la proiectul tehnic.

Scopul principal al creării unui IS este accelerarea „procesului de vânzare”, precum și creșterea eficienței angajaților. Pentru a asigura operabilitatea sistemului, pe computerele în care este utilizat trebuie să fie instalat următorul software:

• - OS din familia Windows;
• - 1C: Enterprise 8;

Date noi sunt introduse în sistem înainte de începerea lucrului, acest lucru este necesar pentru a introduce soldurile inițiale. Pentru a limita modificările neautorizate, se utilizează autorizarea la intrarea în program. Dacă parola este introdusă incorect, sistemul va afișa un mesaj și nu vă va permite să vă conectați la baza de date.

Sistemul are trei sarcini principale:

• - intretinerea directoarelor;
• - intretinerea depozitelor;
• - inregistrarea vanzarilor;
• - iesirea de rapoarte.

Aplicația DB pentru IP este dezvoltată folosind mediul software 1C: Enterprise 8. Pentru a găzdui sistemul, sunt utilizate computere personale care sunt disponibile pentru antreprenorul individual pentru care este dezvoltat sistemul.

Sistem funcţional structurilor

Cerințele generale pentru funcționalitatea sistemului proiectat sunt prezentate folosind diagrama VI din Figura 1

Tabelul -2 Secțiunea principală a scriptului de execuție VI „Adăugați date director”

	Editați datele directorului
	Depozitar, IP
	Menținerea la zi a informațiilor despre obiectele domeniului subiect
Scurta descriere	Utilizatorul adaugă un nou element de director și îl notează. Sistemul salvează datele modificate în baza de date
Condiție prealabilă	1. Utilizatorul este autorizat în sistem. 2. Utilizatorul are drepturi de a adăuga date în director
postcondiție	1. Elementul director este scris în baza de date. 2. Elementul director este afișat sub forma unei liste de directoare

Tabelul -3 Cursul tipic al evenimentelor din scenariul de execuție VI „Adăugați date director”

Tabelul -4 Excluderile scenariului de execuție VI „Adăugați date director”

Tabelul -5 Secțiunea principală a scriptului de execuție VI „Setați prețurile articolelor”

Tabelul - 6 Cursul tipic al evenimentelor din scenariul de execuție VI „Setați prețurile articolelor”

Tabelul -7 Excluderile scenariului de execuție VI „Setați prețuri articole”

Tabelul -8 Secțiunea principală a scenariului de execuție VI „Înregistrarea primirii mărfurilor”

Tabelul -9 Cursul obișnuit al evenimentelor din scenariul de execuție VI „Înregistrare primire mărfuri”

Acțiuni ale actorului	Răspunsul sistemului
1. Depozitarul execută comanda de creare a unui nou document „Recepție de mărfuri”	2. Sistemul afișează formularul de document
3. Depozitarul completează detaliile antetului Excepția #1: Depozitarul completează manual câmpul Număr
4. Depozitarul adaugă un nou rând în secțiunea tabelară din pagina Produse	5. Sistemul afișează o nouă linie
6. Depozitarul completează rubrica Nomenclatură	7. Sistemul înlocuiește valoarea coloanelor
8. Depozitarul completează coloana Cantitate	9. Sistemul calculează valoarea coloanelor Sumă,
10. Sistemul afișează în subsolul părții tabelului valorile totale ale coloanelor Total
11. Intră magazinul produs nou(reveniți la pasul 4) sau executați comanda Write Excepția #2: valoarea câmpului Număr nu este unică	12. Sistemul înregistrează document nou„Recepția mărfurilor” în baza de date
13. Depozitarul execută comanda Print -	14. Sistemul afișează finalizarea formă tipărită comanda de primire
15. Depozitarul execută comanda Print	16. Sistemul imprimă comanda de primire
17. Depozitarul execută comanda Închide formularul de tipărire	18. Sistemul închide placa de imprimare
19. Depozitarul execută comanda Închide documentul „Recepție mărfuri”	20. Sistemul închide forma documentului „Recepția mărfurilor”

Tabelul -10 Excepții pentru scenariul de execuție al VI-ului „Înregistrarea recepției mărfurilor”

Valorile coloanelor sumei și totale sunt calculate prin formula:

Sumă = Cantitate * Preț

Tabelul -11 secțiunea scenariului pentru execuția VI-ului „Efectuați vânzări”

Tabelul -12 Cursul tipic al evenimentelor din scenariul de execuție a VI-ului „Efectuați vânzări”

Acțiuni ale actorului	Răspunsul sistemului
Plata pentru un document de „vânzare”.
1. Managerul execută comanda pentru a crea un nou document de vânzare	2. Sistemul afișează forma documentelor „vânzări”.
4. Managerul care postează documentul
5. Sistemul deține documentul
9. Sistemul imprimă

Tabel - 13 Excepții ale scenariului de execuție VI „Înregistrare document”

Tabelul -14 secțiunea scriptului pentru execuția VI „Rezervare”

Tabelul -15 Cursul tipic al evenimentelor din scenariul de execuție a VI-ului „Efectuarea vânzărilor”

Acțiuni ale actorului	Răspunsul sistemului
Rezervare produs
1. Managerul execută comanda de creare a unui nou document de rezervare	2. Sistemul afișează forma documentelor de „rezervare”.
3. Managerul introduce date despre client, produsul achiziționat și serviciile achiziționate
4. Managerul care postează documentul Excepția #1 nu toate câmpurile sunt completate	5. Sistemul deține documentul
6. Managerul execută comanda Print	7. Sistemul afișează imprimabilul finalizat
8. Managerul execută comanda Print	9. Sistemul imprimă
10. Managerul execută comanda Închide formularul de tipărire	11. Sistemul închide placa de imprimare
11. Managerul execută comanda Închide documentul „prestare servicii”	12. Sistemul închide formularul de document

Tabel - 16 Excepții ale scenariului de execuție VI „Înregistrare document”

Tabelul -17 VI „Creați un raport”

Dezvoltarea structurii directoarelor

Director "Contractanti" conceput pentru a stoca informații despre clienți, furnizori.

Tabelul -15 Detalii despre cartea de referință Clienți

Statutul juridic este de tip enum. Aceasta înseamnă că atunci când acest câmp este selectat, va apărea o listă cu trei stări: IP, Fizic. Persoană, Organizație.

Creare director „Angajați”. Conceput pentru a stoca informații despre angajații organizației. Vă permite să legați o vânzare la un anumit angajat.

Tabelul -16 Detalii despre directorul Angajații

Creare director "Depozite". Conceput pentru a determina locul de depozitare a mărfurilor. IP-ul va avea două depozite - Trading Point 1 și Trading Point 2.

Creare directoare "Opțiune Articole» și "Adiţional Proprietăți". Aceste referințe sunt menite să definească caracteristici suplimentare pentru o anumită gamă de produse, adică monitoarele pot fi identice, dar culorile vor diferi. Aceste directoare vor fi numite sub forma directorului de nomenclatură. Valoarea acestor câmpuri este afișată în documentul „Vânzări”.

Creare director "Nomenclatură". Pentru a contabiliza bunurile achiziționate de la un furnizor, vom crea o carte de referință „Nomenclatură”.

Elementele din căutarea Nomenclaturii vor fi combinate în grupuri în funcție de scopul lor funcțional, astfel încât căutarea va arăta ca o ierarhie „ierarhie de grupuri și elemente”.

Tabelul -17 Cerințe ale cărții de referință Nomenclator

Elaborarea structurii registrului informativ „Nomenclatura prețurilor”

Pentru a stoca costul unităților de nomenclatură, vom crea un registru de informații cu denumirea „Prețuri”. Frecvența registrului este într-o secundă (adică prețurile pot fi urmărite în orice moment), modul de înregistrare este independent.

Tabel -18 Structura registrului informativ Preturi

Proprietatea Leading indică faptul că intrarea din registrul de informații este de interes atâta timp cât obiectul a cărui referință este selectată ca valoare a acestei dimensiuni în această intrare există. Când un obiect este șters, toate intrările din registrul de informații pentru acest obiect vor fi șterse automat.

Dezvoltarea structurii documentului „Recepția mărfurilor”

Documentul „Recepția mărfurilor” este destinat să reflecte faptul primirii bunurilor achiziționate de către organizație.

Tabelul-19 detalii ale documentului „Recepția mărfurilor (Factura de primire)”

Tabelul -19 Detalii ale părții tabelare a documentului „Recepția mărfurilor”

A fost scris un cod pentru a calcula automat valorile coloanelor Sumă, la modificarea valorilor coloanelor Cantitate, Preț.

Forma documentului va arăta ca în figura 2




Figura 2- Formular document Recepția mărfurilor

Dezvoltarea structurii documentului „Vânzări”

Documentul de prestare a serviciilor are scopul de a înregistra activitățile unui antreprenor individual. Acesta controlează anularea bunurilor, a serviciilor care au fost finalizate și, de asemenea, vă permite să vizualizați un raport despre munca angajaților.

Tabelul -20 Detalii ale documentului „Vânzări”

Tabelul -21 Detalii ale secțiunii tabelare a documentului de vânzări

Dezvoltarea structurii documentului „Rezervare”

Documentul „Rezervare” este destinat rezervării produs existent in depozit, iar in caz de lipsa, preluati clientului partea lipsa din marfa. De asemenea, este necesară rezervarea bunurilor până când clientul achită costul comenzii. Acest document este conceput pentru a controla soldurile stocurilor pentru a evita neintelegerile cu clientul.

Tabelul -20 Detalii ale documentului „Rezervare”

Tabelul -21 Detalii partea tabelară a documentului Rezervare

Dezvoltare structurilor document "Intrare primar rămășițe"

Acest document este necesar pentru a introduce soldurile inițiale în baza de date.

Detaliile acestuia sunt similare cu documentul „Chitanță factura”.

Creare raport "Produse"

Raportul Bunuri este conceput pentru a vizualiza rapid anularea și primirea mărfurilor. Adică, permite utilizatorului să vadă câte articole se află în prezent, câte au fost vândute.

În mediul 1C Enterprise 8, există un generator de rapoarte care vă permite să dezvoltați rapid un raport prin generarea de interogări și design bazat pe tabele.

Creare raport „Registrul documentelor de vânzare”

Acest raport este conceput pentru a genera un registru al documentelor de „vânzări”. De asemenea, în sistem vor fi implementate diverse rapoarte, care vor fi similare din punct de vedere al structurii de creație.

Creare roluri și programare lor utilizatorii

Administrarea listei de utilizatori 1C:Enterprise și atribuirea de roluri acestora în conformitate cu acestea atributii oficiale- foarte Puncte importante pentru organizarea interfeței soluției aplicate în ansamblu și delimitarea drepturilor și acțiunilor utilizatorilor individuali ai acesteia.

Utilizatorii ar trebui să fie restricționați să efectueze acțiuni asupra obiectelor bazei de date. De exemplu, depozitarul poate crea documente de primire a mărfurilor și documente de înregistrare, deoarece el este responsabil pentru înregistrarea primirii mărfurilor. Managerul, la rândul său, ar trebui să aibă acces la adăugarea directoarelor clienților, întocmirea unui document de „vânzare”, „rezervare”, dar în același timp să nu aibă acces la primirea mărfurilor.

Obiectele de configurare a rolului sunt folosite pentru a descrie astfel de permisiuni. Fiecărui utilizator al sistemului i se atribuie unul sau mai multe roluri.

Rolurile sunt create în funcție de permisiunile necesare pentru diferite grupuri de utilizatori pentru a accesa informații. Următoarele roluri vor fi implementate în sistemul nostru:

• - administrator - în sistemul 1C:Enterprise trebuie să existe un rol care să includă drepturi depline pentru a lucra cu datele IS;
• - depozitar;
• - administrator;
• - IP.

Atribuirea rolurilor utilizatorilor se realizează prin elementul principal din meniul Administrare -> Utilizatori.



Figura 3 - Crearea unui utilizator „Administrator” cu rolul „Administrator”.



Figura 4 - Lista utilizatorilor sistemului

Dreptul de ștergere interactiv este dezactivat pentru toate obiectele bazei de date pentru toate rolurile.

Editare comanda interfata secțiuni și lucru masa

Îmbunătățirea interfeței de comandă a aplicației, setarea vizibilității comenzilor în funcție de roluri și desktop face aplicația mai ușor de utilizat și îi oferă un aspect complet.

Să sortăm comenzile în funcție de prioritatea și frecvența de utilizare în următoarele grupuri:

• - bara de navigare.Important;
• - bara de navigare.Normal;
• - bară de navigare. de asemenea;
• - bară de acțiuni.Creează și
• - bara de acțiuni.Rapoarte



Figura 5 - Interfața de comandă a secțiunii „Contabilitatea materialelor” a unui utilizator cu rolul „Depozitar”



Figura 6 - Interfața de comandă a secțiunii „Furnizare de servicii” a unui utilizator cu rolul „Manager”.




Figura 7 - Interfața de comandă a secțiunii „Enterprise” a unui utilizator cu rolul „Director”.



Figura 8 - Interfața de comandă a secțiunii „Retail.Electronics” a unui utilizator cu rolul „Administrator”

Desktop-ul este conceput pentru a găzdui cele mai frecvent utilizate documente, rapoarte, directoare etc. de către utilizator. Când se lansează 1C:Enterprise, secțiunea Desktop devine activă implicit și formularele necesare se deschid imediat în spațiul de lucru al aplicației.




Figura 9 - Desktop pentru un utilizator cu rolul de „Magazin”




Figura 10 - Desktop pentru un utilizator cu rolul „Manager”.

automatizare angro documentația software