Notă explicativă. Documentație tehnică Exemplu de notă explicativă la specificațiile tehnice

Mai jos este un exemplu (eșantion) de document de proiect " Notă explicativă la proiect tehnic pentru a crea un sistem automatizat", pe baza liniilor directoare RD 50-34.698-90. Acest document este generat de un specialist IT la faza proiectarea tehnica a sistemului informatic.

Ca exemplu de dezvoltare a unui sistem informatic a fost utilizat un proiect de introducere a unui sistem informatic si analitic „Depozitul de date corporative”.

Pagina de mai jos arată cuprinsul notei explicative a proiectului tehnicîn conformitate cu GOST, în cadrul fiecărei secțiuni pe scurt Sunt date cerințele de conținut și textul exemplului de umplere.(distins printr-o linie verticală).

Secțiuni ale notei explicative:

Prevederi 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 sistemului de difuzoare cu sistemele aferente și asigurarea compatibilității acestuia

Deciziile privind modurile de funcționare, diagnosticarea funcționării sistemului

Deciziile privind personalul și modurile de lucru ale acestora

Informații privind asigurarea caracteristicilor de consum ale sistemului specificate în specificațiile tehnice, care determină calitatea acestuia

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

Compoziția și amplasarea complexelor de echipamente tehnice

Exemplu de „Notă explicativă” (P2), dezvoltat pentru un sistem automat de măsurare și informare contabilitate comercială electricitate (AIIS KUE) conform documentului. de i. Revizuire din 20 iunie 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 25.03.2014 11:48:18

Atenţie! Cerințe tehnice piața angro de energie electrică (WEM), link-uri către punctele cărora sunt conținute în exemple de documente pentru măsurarea automată și sistemele informatice pentru contorizarea electrică comercială (AIIS KUE), se schimbă destul de des, dar nu de către noi, ci de către administrator sistem comercial(PBX). Vă rog să fiți înțelegător în privința asta

Toate documentele luptă, care au trecut multe teste, inclusiv examinări la Întreprinderea Unitară Federală de Stat „Institutul de Cercetare Științifică de Standardizare și Certificare în Inginerie Mecanică” (VNIIMASH) de la ROSSTANDART, prin urmare nu există nicio îndoială.

A primi gratuit este suficientă o versiune prescurtată a oricăror sub formă de *.pdf pentru a da clic pe pagina de titlu. Documentul se va deschide în browser cu opțiunea de a. Versiuni complete documentele sunt platite, se pot obtine in format pentru o anumita suma prin folosire. Orice document poate fi modificat într-o perioadă de timp pentru a satisface cerințele specifice ale clientului. Se discută condiții.

De regulă, Nota explicativă este cel mai complex document despre software, provocând uneori multe controverse și discuții în jurul conținutului acestuia. De ce se întâmplă asta?

Scopul notei explicative

Am spus deja că în dezvoltarea de software acesta este unul dintre etape importante. Ar trebui să conțină o descriere a sistemului dvs. ținând cont de tehnologiile selectate, așa cum ne cere GOST 34 Iar documentul Nota explicativă a proiectului tehnic sau, pe scurt, PZ, este unul dintre principalele documente ale acestei etape. Și, trebuie să spun, de cele mai multe ori Nota explicativă este cel mai complex document de pe software, provocând uneori multe controverse și discuții în jurul conținutului acestuia.

Componența unei note explicative standard

Nota explicativă a proiectului tehnic include secțiuni precum:

– Introducere. Această secțiune oferă numele complet al sistemului și subiectul dezvoltării, precum și o listă de documente care au servit ca bază pentru lucrul la proiect.

– Scopul și domeniul de aplicare. Descrie scopurile și obiectivele care vor fi rezolvate folosind sistemul, precum și domeniul de aplicare al acestuia.

– Specificații . Această secțiune este de obicei împărțită în subsecțiuni care descriu: stabilirea sarcinii pentru crearea unui program; aparatul matematic folosit; algoritm de operare software; structura datelor de intrare și de ieșire; compoziția hardware și software. De asemenea, este necesar să se furnizeze calcule și rezultate ale analizelor pentru a justifica alegerea exact a acelor soluții menționate în document.

– Indicatori tehnici și economici așteptați. Secțiunea presupune cazul de afaceri dezvoltare ținând cont de indicatorii săi tehnici.

– Surse utilizate în dezvoltare. Secțiunea este o listă de documente, articole și publicații care au fost menționate în text.

Standarde pentru note explicative

Compoziția secțiunilor este determinată de GOST 19.404, cu toate acestea, standardul permite combinarea acestor secțiuni, dacă este necesar, și, de asemenea, adăugarea altora noi. În cazul utilizării GOST seria 34, un document trebuie elaborat în conformitate cu RD 50-34.698. Cu toate acestea, documentul trebuie să rămână în cerințele standarde comune, cum ar fi, de exemplu, GOST 19.105.

Costul elaborării unei note explicative

Cum puteți crea un document de program la cel mai mic cost care este cel mai util pentru proiectul dvs., care:

– pe de o parte, prezintă clar și inteligibil toate informațiile necesare (și uneori plictisitoare), inclusiv detalii tehnice complexe;

1. prevederi generale;
2. descrierea activității;
3. soluții tehnice de bază;
4. evenimente pe

[din clauza 2.2.1 RD 50-34.698-90]

Prevederi generale

În secțiunea „Dispoziții generale” acestea furnizează:

1. proiectarea și denumirea documentelor, numărul și data acestora, pe baza cărora se realizează proiectarea CNE;
2. lista celor implicați în sistem, termene limită;
3. scopuri, scop și AS;
4. confirmarea conformității soluțiilor de proiectare cu standardele în vigoare și siguranța la incendiu și explozie etc.;
5. informații despre cele utilizate în proiectare;
6. informații despre cele mai bune practici utilizate în dezvoltarea proiectului;
7. ordinea creării sistemului și volumul fiecăruia.

[din clauza 2.2.2 RD 50-34.698-90]

Descrierea procesului de activitate

În secțiunea „Descrierea procesului de activitate” acestea reflectă componența procedurilor (), ținând cont de interrelația și compatibilitatea proceselor și activităților, formează organizarea muncii în fabrică [din clauza 2.2.3 RD 50-34.698 -90]

Principalele soluții tehnice

În secțiunea „Principalele soluții tehnice” acestea oferă:

1. decizii privind structura sistemului, mijloace și metode de comunicare pentru schimbul de informații între subsisteme;
2. decizii privind interconectarea sistemului cu sistemele aferente și suportul acestuia;
3. soluții pentru funcționarea sistemului;
4. decizii privind numărul, calificările și funcțiile, modurile de funcționare a acestuia, ordinea interacțiunii;
5. informații privind asigurarea caracteristicilor specificate de consumator ale sistemului (subsistemelor) care îl definesc;
6. alcătuirea complexelor de sarcini () implementate de sistem (subsistem);
7. decizii asupra complexului, amplasarea acestuia pe;
8. decizii privind compoziția informațiilor, volumul, metodele, tipurile de computer și documentele, secvența și alte componente;
9. decizii privind componența, limbile activităților, procedurile și operațiunile și metodele de implementare a acestora.

Secțiunea oferă ilustrații ale altor documente care pot fi incluse în conformitate cu GOST 34.201 [din clauza 2.2.4 din RD 50-34.698-90]

Măsuri de pregătire a obiectului de automatizare pentru punerea în funcțiune a sistemului

În secțiunea „Măsuri pregătitoare pentru punerea în funcțiune a sistemului” se prezintă următoarele:

1. măsuri de aducere a informațiilor într-o formă adecvată pentru;
2. activități de instruire și testare a calificărilor personalului;
3. măsuri pentru crearea unităților și locurilor de muncă necesare;
4. măsuri de schimbare a obiectului automatizării;
5. alte măsuri bazate pe caracteristicile specifice ale sistemelor create.

27.10.2016 09:57:23

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

1. Elaborarea documentației de proiectare tehnică pentru NIB

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

• analiza cerințelor pentru sistemele de securitate a informațiilor;
• proiecta;
• implementare;
• implementare;
• exploatare

Acest articol discută stadiul proiectului tehnic, care aparține etapei de „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 NIB) și în planul dezvoltatorului imediat al NIB.

Pentru proprietarul resurselor informaționale, este important să se 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 principiilor 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 și îmbunătățire. sistemul. La finalizarea elaborării unui proiect tehnic pentru un sistem de securitate a informațiilor, Clientul primește un set cuprinzător de documentație pentru sistemul de securitate a informațiilor, care descrie toate nuanțe tehnice viitorul sistem.

Pentru executantul direct, în stadiul proiectului tehnic, este necesar să se stabilească cea mai potrivită arhitectură SIS și, de asemenea, să se realizeze alegere corectă măsuri şi mijloace de protecţie a informaţiilor din organizaţie. De asemenea, este important să vă asigurați că caracteristicile și proprietățile sistemului se potrivesc specificatii tehnice, sau justifică, cu participarea și acordul Clientului, ajustarea cerințelor specificate în specificațiile tehnice în scopul creșterii eficienței sistemului creat.

Astfel, ca urmare a elaborării documentației tehnice de proiectare, 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 BNI-ul;
• ce schimbări în organizație necesare creșterii nivelului de securitate a informațiilor vor urma ca urmare a implementării ISS;
• vor fi luate în considerare cerințele Clientului (cerințele de business) și cerințele actelor juridice de reglementare în domeniul securității informațiilor la dezvoltarea și implementarea sistemului de securitate a informațiilor și, dacă da, cum.

În procesul de elaborare a documentației tehnice a proiectului, antreprenorul va primi următoarele rezultate:

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

1.2. Revizuirea abordărilor pentru elaborarea 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. Și pentru agentii guvernamentale utilizarea lor este obligatorie, dar recomandată pentru cele comerciale. În practică organizatii comerciale De asemenea, utilizați standardele de stat atunci când elaborați documentația tehnică a proiectului din următoarele motive:

• o abordare testată în mod repetat pentru crearea sistemelor 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 de proiect tehnic (TP) a BNI, sunt utilizate standardele de stat și documentele 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 la etapa TP;
  • completitudinea documentației;
  • denumirile documentelor acceptate;
  • reguli pentru desemnarea NIB ș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 stadiul tehnic;
  • descrierea detaliată a lucrărilor efectuate în stadiul tehnic;
  • lista organizațiilor care participă la crearea ISS;
• RD 50-34.698-90 „Sisteme automatizate. Cerințe privind conținutul documentelor.” Acest document de orientare specifică cerințele pentru conținutul documentelor în etapa TP.

Este important să înțelegem că, conform seriei 34 de standarde, proiectarea tehnică este o etapă a creării unui sistem, și nu doar un set de documente. Această etapă în practică este adesea combinată cu etapa de proiectare preliminară, care servește la elaborarea mai multor soluții preliminare și la justificarea celei mai potrivite. O astfel de combinație este permisă de standard, dar trebuie luat în considerare faptul că acest lucru nu anulează necesitatea atingerii obiectivelor etapei preliminare de proiectare.

Cel mai adesea, etapa de proiectare preliminară este dezvoltată în cazul în care cerințele specificațiilor tehnice pentru sistem pot fi implementate în mai multe moduri fundamental diferite și, de asemenea, atunci când printre aceste metode nu există unele în mod clar preferate.

Cu toate acestea, este de remarcat faptul că standardele de mai sus sunt prea generale și implementează în principal funcții de proiectare și structurale generale. Pentru a elabora partea de fond a documentelor de etapă a proiectului tehnic, proiectanții folosesc informații din următoarele surse:

Documente de reglementare actuale (RLA) care reglementează cerințele pentru protecția anumitor informații cu acces restricționat. Aceste acte juridice de reglementare prevăd cerințe pentru măsurile de protecție a informațiilor în sisteme informatice, sunt descrise nuanțele implementării acestor măsuri și măsuri suplimentare de consolidare. Printre actele juridice actuale se numără 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 a asigura securitatea datelor cu caracter personal în timpul prelucrării acestora î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 constituie secret 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 la unitățile critice, eventual obiecte periculoase, precum și obiectele care prezintă un pericol sporit pentru viața și sănătatea oamenilor și pentru mediu;
• 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 cu acces restricționat și listele de măsuri de protecție variază pentru sistemele de informații de diferite niveluri/clase de securitate. Dacă informațiile din organizație nu sunt protejate în conformitate cu legi federale RF (de exemplu, secret oficial), atunci proprietarul acestor informații poate folosi abordările propuse în aceste acte juridice de reglementare pentru construirea unui ISS corporativ.

Standarde rusești și străine care descriu diferite abordări ale modalităților de implementare a etapelor ciclului de viață al construirii unui ISS, inclusiv etapa de proiectare tehnică:

• serie de standarde de stat GOST R ISO/IEC 2700X, identice standarde internaționale ISO/IEC 2700X. Aceste standarde descriu abordarea procesuala PDCA (Plan, Do, Check, Act) pentru 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 ciclul de viață al dezvoltării sistemelor informaționale;
• NIST SP 800-37 este un standard al Institutului Național de Standarde și Tehnologie din SUA, care oferă îndrumări pentru 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 sistemelor de securitate a informațiilor, inclusiv cele legate direct de implementarea măsurilor de securitate a informațiilor care nu sunt legate, de exemplu, de servere, sisteme de stocare a datelor, instrumente de virtualizare și altele. Setul general de astfel de documente variază de la producător la producător și depinde, printre altele, de implementarea unui anumit instrument (hardware/software). Mai jos este set standard documentație operațională pentru instrumentele de securitate a informațiilor, utilizată pentru elaborarea documentelor la etapa de proiect tehnic:

• descriere generală (fișă de date);
• ghidul administratorului (poate include ghid de management local și centralizat);
• manual de utilizare;
• Ghid de instalare și implementare rapidă (pentru sistemele de protecție a informațiilor hardware);
• manual de utilizare;
• Ghid pentru implementarea în infrastructura virtuală (pentru sisteme de protecție a informațiilor software);

Informații generale despre arhitecturile SIS existente, cele mai bune practici în ceea ce privește construirea ISS, linii directoare pentru securitate ș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 privind arhitecturile sistemelor de securitate a informațiilor, de exemplu: Defense-in-Depth, Cisco SAFE, Check Point SDP și altele;
• bune practici în domeniul securității informațiilor, de exemplu, 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 engleză, totuși, fiecare are propriile bune practici pentru implementarea măsurilor de securitate producator rus Informațiile privind securitatea informațiilor pot fi furnizate la cerere;
• linii directoare de securitate pentru securitatea informațiilor și mediile 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 în etapa de proiect tehnic pentru ISS 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 care urmează să fie elaborate - această informație este indicată în specificațiile tehnice pentru ISS. În unele cazuri, elaboratorul documentului, de comun acord cu Clientul, poate extinde sau reduce această listă, dacă această posibilitate este prevăzută în specificațiile tehnice;

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), formatată în conformitate cu GOST 2.105-95;

Dezvoltarea părții de fond a documentelor. Cerințele pentru sistem sunt stabilite în specificațiile tehnice pentru NIB. În conformitate cu aceste cerințe, se stabilește o listă de măsuri tehnice și organizatorice de protecție necesare implementării în sistem. Măsurile de protecție pot fi determinate în reglementările 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 timpul dezvoltării modelului de amenințare al organizației. Pe baza listei de măsuri de protecție, dezvoltatorul SI selectează instrumentele adecvate de securitate a informațiilor și dezvoltă structura funcțională a sistemului de securitate a informațiilor (subsisteme, componente). În plus, documentele de proiectare tehnică descriu implementarea practică a măsurilor de protecție pe baza măsurilor de protecție de securitate selectate sau a măsurilor organizaționale î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 depășit ș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 sistemul de securitate a informațiilor este următorul:

• declarație tehnică de proiectare;
• nota explicativă la proiectul tehnic;
• diagrama structurii functionale;
• diagrama structurală a complexului mijloace tehnice;
• diagrama structurii organizatorice;
• lista de articole achizitionate.

La cererea Clientului sau în cazul în care ISS este un sistem complex multicomponent, pot fi dezvoltate suplimentar următoarele documente:

• schema de automatizare;
• descrierea funcțiilor automate;
• descrierea suportului informatic al sistemului;
• descrierea complexului de mijloace tehnice;
• descrierea software-ului;
• descrierea structurii organizatorice.

Trebuie remarcat faptul că GOST 34.201-89 permite o extindere a gamei de documente în stadiul TP, dar în practică există mai mult decât suficiente dintre aceste documente.

Fisa de proiect tehnic

Denumire: TP.

Acest document are scopul de a descrie lista documentelor elaborate în etapa de proiect 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, sisteme software și hardware și alte lucruri. Conform standardului, acesta constă din patru secțiuni principale:

• prevederi generale;
• descrierea procesului de activitate;
• soluții tehnice de bază;
• 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 ISS, și anume:

• subsisteme și componente logice incluse în ISS;
• funcții implementate prin intermediul subsistemelor și componentelor;
• conexiuni de informații între elementele logice ale SIS și tipurile de mesaje în timpul schimbului.

Diagrama structurală a unui complex de mijloace tehnice

Denumire: C1.

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

• mijloace tehnice ca parte a subsistemelor logice și componente ale sistemelor de securitate a informațiilor;
• canale de comunicaţie şi schimb între mijloace tehnice indicând protocoale de transport.

Organigrama

Denumire: C0.

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

• diviziile și persoanele responsabile ale organizației implicate în funcționarea ISS;
• funcţiile îndeplinite şi legăturile dintre departamente şi persoanele responsabile.

Lista articolelor achiziționate

Denumire: VP.

Acest document include o listă a tuturor software-ului și hardware-ului, precum și licențele utilizate pentru a crea un sistem de securitate a informațiilor. Dezvoltat în conformitate cu GOST 2.106.

Nota. De asemenea, este de remarcat aici că ghidul RD 50-34.698-90 permite adăugarea oricărui document în stadiul de TP (includerea de secțiuni și informații diferite de cele propuse), comasarea secțiunilor, precum și excluderea. a unor secţiuni individuale. Deciziile în acest sens sunt luate de dezvoltatorul documentelor în etapa TP și se bazează pe caracteristicile NIB-ului creat.

1.4. Reguli pentru elaborarea documentației

• conformitatea structurală standardele de stat;
• respectarea strictă a cerințelor specificațiilor tehnice pentru sistem;
• aplicarea șabloanelor de documente (utilizarea stilurilor uniforme, marcaj, câmpuri etc.);
• o abordare 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 trebuie să fie consecvenți în toate secțiunile documentului;
• Se recomandă evitarea repetărilor evidente și creșterea inutilă a lungimii 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 despre 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 sistemele și instrumentele aferente etc.;
  • controale, metode de acces la acestea și locuri de instalare a acestora;
  • diagrame (structurale, funcționale, organizaționale):
    • dezvolta diagrame în Microsoft Visio;
    • după dezvoltare, inserați diagrame în document utilizând dialogul „Lipire specială” în format EMF (metafișier Windows);
    • elaborați diagrame separate pentru sistemul, subsistemele și componentele subsistemelor;
    • uniformizați designul diagramelor, folosind aceleași elemente, abrevieri, pictograme, stiluri de text etc.

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

Internetul conține o cantitate imensă de informații care, într-o măsură sau alta, pot ajuta la elaborarea documentației tehnice a proiectului. Resursele cheie sunt prezentate în tabelul de mai jos.

Masă. Resurse de proiectare tehnică SIS

Tipul de resursă	Informaţii	Exemple de resurse
Portaluri de internet ale autorităților executive federale	Documente de reglementare, recomandări metodologice, registre (inclusiv informații certificate de securitate a informațiilor), 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 securitate a informațiilor, distribuitori 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.ru/ 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/ vulners.com/ csrc.nist.gov itssecurity.com owasp.org sans.org


1.6. Exemple de documente tehnice pentru faza proiectului

Pentru a înțelege cerințele pentru conținutul documentației la etapa TP, mai jos sunt 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, așa că iată un exemplu de conținut al secțiunii „Soluții tehnice de bază” în parte a unuia dintre subsistemele SIS - subsistemul de analiză a securității.

Subsistemul de analiză a securității ISS

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 (AWS) ale personalului și serverelor organizației. Baza ESD este instrumentul software „Test” produs de Information Security LLC. SZI Test are un certificat de conformitate al FSTEC din Rusia specificatii tehnice(TU) privind securitatea informațiilor și al 4-lea nivel de control asupra absenței capacităților nedeclarate.

ESD include următoarele componente:

• Server de administrare Test Server;
• Consola de gestionare a consolei de testare.

O descriere a componentelor subsistemului este prezentată în tabelul de mai jos.

Masă. Componente ESD

Componentă	Descriere
Test Server Management Server	Oferă managementul sarcinilor de scanare, realizează funcții 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 de securitate a informațiilor pe serverul de gestionare Test Server. Toate informațiile colectate despre rezultatele scanării sunt stocate în stocarea serverului de testare bazat pe sistemul de gestionare a bazelor de date Microsoft SQL Server 2008
Consola de testare	Permite administratorului de securitate a informațiilor să se conecteze la Test Server, să vizualizeze și să modifice configurația acestuia, să creeze și să modifice sarcini de scanare, să vadă informații despre progresul sarcinilor și rezultatele executării acestora. Consola de management este instalată pe stația de lucru a administratorului de securitate a informațiilor

Furnizarea de funcții

ESD oferă următoarele funcții:

• implementarea protecției proactive a stațiilor de lucru și serverelor organizației prin monitorizarea stării securității informațiilor;
• automatizarea proceselor de monitorizare a conformității cu politicile interne și anumite standarde de securitate;
• reducerea costurilor pentru audit și control de securitate, întocmirea rapoartelor de stare;
• automatizarea proceselor de inventariere a resurselor, managementul vulnerabilităților, monitorizarea conformității cu politicile de securitate și controlul schimbărilor.

Soluție pentru un complex de hardware și software

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


Masă. Software și hardware ESD

Server de control ESD

Mijloace tehnice

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

Masă. Cerințe de SO și software pentru serverul de control ESD

Software	Cerințe tehnice
	CPU	RAM, MB
Microsoft Windows Server 2008 R2	3000 MHz, 4 nuclee	8192
Microsoft SQL Server 2008 R2
Software Test Server

Instrumente software

OS server de management

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

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

Server de management DBMS

Baza de date Microsoft SQL Server 2008 R2 este instalată sub un cont cu drepturi de administrator local utilizând expertul de instalare standard din kitul de distribuție furnizat de dezvoltatorul produsului.

Software Test Server

Software-ul Test Server este instalat pe serverul de management utilizând asistentul standard de instalare.

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

Stația de lucru a administratorului IS

Mijloace tehnice

Stația de lucru existentă a unui angajat al unității organizaționale responsabilă cu asigurarea securității informațiilor, care rulează familia de sisteme de operare Microsoft Windows, este utilizată ca platformă.

Mijloacele tehnice ale stației de lucru ale administratorului de securitate a informațiilor trebuie să aibă următoarele caracteristici de configurare hardware (cel puțin recomandate):

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

Instrumente software

Software-ul Consolei de testare

Stația de lucru a administratorului de securitate a informațiilor 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 ca software-ul consolei de administrare Test Console să funcționeze corect, Microsoft .NET Framework versiunea 3.5 SP1 sau o versiune superioară trebuie să fie instalat pe stația de lucru a administratorului de securitate a informațiilor, iar setările de securitate ale sistemului de operare utilizat trebuie să permită accesul la Test Server.

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

Interacțiunea cu sistemele adiacente

Pentru ESD, adiacente sunt:

• instrumente de subsistem 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 înseși, trecerea traficului de rețea necesar trebuie organizată.

Pentru a asigura capacitatea de a primi actualizări ale bazei de cunoștințe și modulelor software de testare pentru scanerul Test Server, este necesar să oferiți acces la serverul web update.com al companiei Information Security LLC prin 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. Când scanați în modurile Audit și Conformitate, sunt utilizate protocoale de gestionare 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. În consecință, Serverul de testare trebuie să aibă acces la porturile de rețea ale nodurilor scanate folosind protocoalele de control de la distanță adecvate.

Deoarece ESD, atunci când scanează în modurile Audit și Conformitate, utilizează protocoale de control de la distanță pentru analiză, instrumentele de scanare a software-ului de testare trebuie să fie supuse autentificării și autorizării pe nodul scanat. În ESD, pentru a scana nodurile în modurile Audit și Conformitate, se folosesc conturi cu privilegii administrative în fiecare tip de nod (stație de lucru, server, sisteme de aplicații, DBMS etc.).

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

Operarea și întreținerea ESD

Utilizatorii subsistemului

Operarea și întreținerea instrumentelor ESD sunt efectuate de angajați ai organizației cu rolul funcțional de „administrator IS”.

Un administrator de securitate a informațiilor este definit ca un specialist ale cărui sarcini includ:

• determinarea parametrilor de scanare ai nodurilor organizației;
• configurarea și lansarea sarcinilor de scanare;
• analiza rezultatelor scanării pentru vulnerabilități, erori de configurare sau nerespectarea cerințelor în sistemele informaționale standardele tehnice;
• controlul eliminării vulnerabilităților;
• formarea standardelor și cerințelor care se aplică pentru asigurarea securității locurilor de muncă și serverelor automatizate ale organizației.

Moduri de operare a sistemului

Mod de funcționare normal

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

În funcționare normală, administratorul de securitate a informațiilor efectuează:

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

Operare de urgență

Dacă performanța echipamentului de siguranță este perturbată, funcționarea subsistemului este perturbată. Neutilizarea echipamentelor ESD nu afectează funcționarea stațiilor de lucru și serverelor automate ale organizației.

1.6.2. Diagrama structurii funcționale

Diagramele funcționale pot fi dezvoltate pentru întregul sistem de securitate a informațiilor sau pentru o parte a acestuia, de exemplu, un subsistem sau componentă.

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

1.6.3. Diagrama structurală a unui complex de mijloace tehnice

Schema bloc a unui complex de mijloace tehnice poate fi dezvoltată atât pentru întreaga ISS, cât și pentru părțile sale - subsisteme și componente. Fezabilitatea dezvoltării diagramelor pentru părți ale sistemului de securitate a informațiilor este determinată de dimensiunea sistemului și de detaliul necesar.

Exemplu schema bloc Complexul de mijloace tehnice ale NIB este prezentat în figura de mai jos.