27.10.2016 09:57:23

Tento článok sa zaoberá fázou technického návrhu súvisiacou s jednou z fáz životného cyklu systému informačná bezpečnosť(NIB) - fáza „návrhu“, ktorá v súlade s domáci štandard GOST 34.601-90 bezprostredne nadväzuje na vývoj referenčných podmienok pre systém informačnej bezpečnosti.

1. Vypracovanie technickej projektovej dokumentácie pre NIB

Životný cyklus informačného bezpečnostného systému (ďalej len SIS) vo všeobecnosti pozostáva z nasledujúcich etáp:

• analýza požiadaviek na ISS;
• dizajn;
• implementácia;
• implementácia;
• vykorisťovanie.

Tento článok pojednáva o štádiu technického projektu súvisiaceho s fázou „návrhu“ a v súlade s domácou normou GOST 34.601-90 bezprostredne nadväzuje na vývoj zadávacích podmienok pre systém informačnej bezpečnosti.

1.1. Prečo vôbec vyvíjať dokumentáciu pre NIB?

Odpoveď na túto otázku treba posudzovať v dvoch rovinách: v rovine vlastníka informačných zdrojov (na ochranu ktorých je ISS vytvorená) a v rovine priameho vývojára ISS.

Pre vlastníka informačných zdrojov je dôležité získať výsledok v podobe fungujúceho systému informačnej bezpečnosti, ktorý znižuje riziká ohrozenia informácií s obmedzeným prístupom v organizácii. Technický projekt v tomto prípade slúži na rozvoj základných základov budúceho systému, konkrétne zahŕňa popis toho, ako sa bude ISS budovať a fungovať, aké opatrenia a prostriedky zabezpečia ochranu informácií, aké sú možnosti rozvoja a zlepšovanie systému. Po dokončení vývoja technického projektu systému informačnej bezpečnosti dostane Zákazník komplexnú dokumentáciu pre NIS, ktorá popisuje všetky technické nuansy budúceho systému.

Pre priameho realizátora v štádiu technického projektu je potrebné stanoviť najvhodnejšiu architektúru NIS, ako aj vytvoriť správna voľba opatrenia a prostriedky na ochranu informácií v organizácii. Dôležité je tiež zabezpečiť, aby charakteristika a vlastnosti systému zodpovedali zadávacím podmienkam, prípadne odôvodniť za účasti a súhlasu Zákazníka úpravu požiadaviek uvedených v TOR za účelom zvýšenia efektívnosti systém, ktorý sa vytvára.

V dôsledku vypracovania technickej projektovej dokumentácie bude mať zákazník odpovede na nasledujúce otázky:

• aká je všeobecná architektúra NIB;
• aké opatrenia a prostriedky sa použijú na implementáciu požiadaviek na ochranu informácií;
• ako bude NIS fungovať;
• aké zmeny v organizácii, potrebné na zvýšenie úrovne informačnej bezpečnosti, budú nasledovať v dôsledku zavedenia ISS;
• či budú pri vývoji a implementácii ISS zohľadnené požiadavky Objednávateľa (obchodné požiadavky) a požiadavky regulačných právnych aktov v oblasti informačnej bezpečnosti a ak áno, akým spôsobom.

Dodávateľ v procese vypracovania technickej projektovej dokumentácie získa tieto výsledky:

• základ pre prechod na ďalšie etapy budovania NIS, a to etapy pracovnej dokumentácie a realizácie;
• pochopenie architektúry, technológií a použitých nástrojov, poradie budovania systému;
• ako sú implementované požiadavky Zákazníka (obchodné požiadavky) a regulačné dokumenty v oblasti informačnej bezpečnosti pre systém.

1.2. Prehľad prístupov k vypracovaniu technickej projektovej dokumentácie

Vypracovanie technického projektu pre systém informačnej bezpečnosti sa najčastejšie vykonáva na základe príslušných noriem a usmerňujúcich dokumentov. A pre verejné inštitúcie ich používanie je povinné a na komerčné účely sa odporúča. Na praxi komerčné organizácie pri vypracovaní technickej projektovej dokumentácie použiť aj štátne normy z nasledujúcich dôvodov:

• opakovane overený prístup k tvorbe informačných systémov;
• premyslená štruktúra a obsah dokumentov;
• súbor dokumentov postačujúci na vývoj a popis takmer každého systému.

Na vypracovanie dokumentácie pre etapu technického projektu (TP) na NIB sa používajú štátne normy a usmernenia série 34:

• GOST 34.201-89 "Typy, úplnosť a označovanie dokumentov pri vytváraní automatizovaných systémov." Táto norma špecifikuje:
  • druhy a názvy dokumentov etapy TP;
  • úplnosť dokumentácie;
  • akceptované označenia dokumentov;
  • pravidlá pre označovanie VRO a ich častí.
• GOST 34.003-90 "Termíny a definície";
• GOST 34.601-90 „Automatizované systémy. Etapy tvorby. Norma špecifikuje:
  • zoznam etáp prác vykonaných v štádiu TP;
  • Detailný popis práce vykonávané v štádiu TP;
  • zoznam organizácií podieľajúcich sa na tvorbe NIS;
• RD 50-34.698-90 „Automatizované systémy. Požiadavky na obsah dokumentov. Toto usmernenie špecifikuje požiadavky na obsah dokumentov fázy TA.

Je dôležité pochopiť, že podľa noriem série 34 je technický projekt etapou vytvárania systému, a nie iba súborom dokumentov. Táto fáza sa v praxi často kombinuje s fázou predbežného návrhu, ktorá slúži na vypracovanie niekoľkých predbežných riešení a zdôvodnenie toho najvhodnejšieho. Takáto kombinácia je povolená normou, ale treba mať na pamäti, že to nepopiera potrebu dosiahnuť ciele predbežnej fázy návrhu.

Štádium návrhu sa najčastejšie vypracúva, keď požiadavky technických špecifikácií na systém možno implementovať niekoľkými zásadne odlišnými spôsobmi, a tiež vtedy, ak medzi týmito metódami neexistujú jednoznačne preferované metódy.

Treba však poznamenať, že vyššie uvedené normy sú príliš všeobecné a realizujú najmä dizajnovú a všeobecnú konštrukčnú funkciu. Na vypracovanie podstatnej časti dokumentov etapy technického návrhu používajú dizajnéri informácie z nasledujúcich zdrojov:

Aktuálne regulačné dokumenty (NLA), ktoré upravujú požiadavky na ochranu tej či onej informácie s obmedzeným prístupom. Tieto RLA predstavujú požiadavky na opatrenia na ochranu informácií v informačných systémoch, popisujú nuansy implementácie týchto opatrení a dodatočné posilňujúce opatrenia. Medzi súčasnými NPA možno rozlíšiť tieto:

• príkaz FSTEC Ruska zo dňa 18. februára 2013 č. 21 „O schválení zloženia a obsahu organizačných a technických opatrení na zaistenie bezpečnosti osobných údajov pri ich spracúvaní v informačných systémoch osobných údajov“;
• nariadenie FSTEC Ruska zo dňa 11.02.2013 č. 17 "O schválení požiadaviek na ochranu informácií, ktoré nie sú štátnym tajomstvom obsiahnutých v štátnych informačných systémoch"
• vyhláška FSTEC Ruska zo 14. marca 2014 č. 31 „O schválení požiadaviek na zabezpečenie ochrany informácií v automatizovaných riadiacich systémoch pre výrobu a technologických procesov v kriticky dôležitých zariadeniach, potenciálne nebezpečných zariadeniach, ako aj zariadeniach, ktoré predstavujú zvýšené nebezpečenstvo pre život a zdravie ľudí a pre životné prostredie;
• metodický dokument "Opatrenia na ochranu informácií v štátnych informačných systémoch", schválený FSTEC Ruska dňa 11.02.2014

Požiadavky na ochranu informácií s obmedzeným prístupom a zoznamy ochranných opatrení sa líšia pre IS rôznych úrovní/tried bezpečnosti. Ak informácie v organizácii nepatria medzi chránené v súlade s federálne zákony RF (napríklad oficiálne tajomstvo), potom vlastník týchto informácií môže použiť prístupy navrhované v týchto právnych aktoch na vybudovanie podnikovej ISS.

ruský a zahraničné normy, ktorý popisuje rôzne prístupy k spôsobom implementácie etáp životného cyklu budovania ISS, vrátane etáp technického projektu:

• rad štátnych noriem GOST R ISO/IEC 2700X, identických s medzinárodnými normami ISO/IEC 2700X. Tieto štandardy popisujú procesný prístup PDCA (Plan, Do, Check, Act) k implementácii životného cyklu systému riadenia informačnej bezpečnosti, ktorý je neoddeliteľnou súčasťou ISS;
• NIST SP 800-64 je štandard amerického Národného inštitútu pre štandardy a technológie, ktorý popisuje životný cyklus vývoj informačných systémov;
• NIST SP 800-37 je štandard amerického Národného inštitútu pre štandardy a technológie, ktorý poskytuje návod na integráciu riadenia rizík do životného cyklu vývoja informačných systémov.

Prevádzková dokumentácia výrobcu pre informačnú bezpečnosť a pomôcok. Tieto dokumenty obsahujú komplexné technické informácie o nástrojoch použitých pri výstavbe ISS, vrátane tých, ktoré priamo nesúvisia s implementáciou opatrení IS, napríklad servery, systémy na ukladanie dát, virtualizačné nástroje a iné. Všeobecná sada takýchto dokumentov pre rôznych výrobcov je rôzna a závisí okrem iného od vykonania konkrétneho nástroja (hardvéru/softvéru). Nižšie je uvedený štandardný súbor prevádzkovej dokumentácie pre nástroje informačnej bezpečnosti používané na vývoj dokumentov pre štádium technického projektu:

• všeobecný popis (datasheet);
• príručka správcu (môže zahŕňať príručku pre miestne a centralizované riadenie);
• užívateľská príručka;
• rýchla príručka inštalácie a nasadenia (pre hardvérový GIS);
• návod na obsluhu;
• príručka nasadenia virtuálnej infraštruktúry (pre softvérový GIS);

Všeobecné informácie o dostupných architektúrach NIS, osvedčené postupy z hľadiska budovania ISS, usmernenia o bezpečnosti a integrácii zariadení informačnej bezpečnosti navzájom, informácie o problémoch pri interakcii určitých zariadení informačnej bezpečnosti. Príklady takýchto informácií môžu zahŕňať nasledujúce dokumenty:

• návody na architektúru systému informačnej bezpečnosti, napríklad: Defense-in-Depth, Cisco SAFE, Check Point SDP a iné;
• osvedčené postupy v oblasti bezpečnosti informácií, napríklad tie, ktoré sú k dispozícii na týchto odkazoch (https://www.sans.org/reading-room/whitepapers/bestprac/ , http://csrc.nist.gov/publications/nistpubs/800-14 / 800-14.pdf). Tieto dokumenty sú najčastejšie prezentované na anglický jazyk, však akýkoľvek Ruský výrobca SZI a na požiadanie môžu byť poskytnuté;
• bezpečnostné príručky pre IPS a prevádzkové prostredia. Príkladom je sekcia „Zabezpečenie“ na oficiálnom portáli spoločnosti Microsoft (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).

1.3. Vypracovanie technického návrhu pre NIB v súlade s GOST 34

Vypracovanie podkladov pre štádium technického projektu na NIS najčastejšie realizujú integrátori týchto služieb a realizuje sa najmä v súlade s nasledovným plánom:

Stanovenie zoznamu dokumentov, ktoré sa majú vypracovať - ​​tieto informácie sú uvedené v podmienkach NIS. V niektorých prípadoch môže spracovateľ dokumentov po dohode so zákazníkom tento zoznam rozšíriť alebo zredukovať, ak je to možné v TOR;

Vývoj šablón dokumentov pre štádium TP - štruktúra sa používa v súlade s RD 50-34.698-90 a GOST 2.106 (pre niektoré dokumenty), vyhotovenie v súlade s GOST 2.105-95;

Vypracovanie vecnej časti dokumentov. Požiadavky na systém sú stanovené v podmienkach pôsobnosti NIB. V súlade s týmito požiadavkami sa určuje zoznam ochranných technických a organizačných opatrení potrebných na implementáciu do systému. Ochranné opatrenia môžu byť definované v príslušných regulačných právnych aktoch (v závislosti od typu chránených informácií), firemné štandardy a politiky informačnej bezpečnosti, ako aj na základe prítomnosti aktuálnych bezpečnostných hrozieb identifikovaných počas vývoja modelu hrozieb organizácie. Na základe zoznamu ochranných opatrení vývojár ISS vyberie vhodné nástroje ochrany informácií a vypracuje funkčnú štruktúru systému informačnej bezpečnosti (subsystémy, komponenty). Ďalej je to popísané v dokumentoch technického dizajnu praktickú realizáciu ochranné opatrenia na základe zvoleného GIS alebo organizačné opatrenia v infraštruktúre organizácie.

Koordinácia vypracovanej dokumentácie a riešení v nej prezentovaných so Zákazníkom systému.

Pri príprave technickej projektovej dokumentácie sa najčastejšie nevyžaduje vypracovanie úplného zoznamu dokumentov špecifikovaných v GOST 34.201-89, pretože táto norma je zastaraná a niektoré dokumenty nezohľadňujú vývojové trendy a technológie moderných informačných systémov. . Minimálny súbor dokumentov požadovaných na popis systému informačnej bezpečnosti je nasledovný:

• vyhlásenie o technickom projekte;
• vysvetľujúca poznámka k technický projekt;
• schémy funkčná štruktúra;
• štrukturálny diagram komplexu technické prostriedky;
• organizačná schéma;
• zoznam zakúpených položiek.

Na žiadosť zákazníka, alebo ak je NIS komplexný viaczložkový systém, je možné dodatočne vypracovať nasledujúce dokumenty:

• automatizačná schéma;
• popis automatizovaných funkcií;
• popis informačnú podporu systémy;
• popis komplexu technických prostriedkov;
• popis softvér;
• popis organizačnej štruktúry.

Je potrebné poznamenať, že GOST 34.201-89 umožňuje rozšírenie rozsahu dokumentov v štádiu TP, avšak v praxi sú tieto dokumenty viac než dosť.

Technický návrhový list

Označenie: TP.

Tento dokument je určený na opis zoznamu dokumentov vypracovaných v štádiu technického projektu. Uvedený je aj počet strán každého z vypracovaných dokumentov.

Vysvetľujúca poznámka k technickému projektu

Označenie: P2.

Tento dokument je hlavný pre etapu TP a obsahuje popis architektúry ISS, technických a organizačných opatrení, funkcií ISS, softvérových a hardvérových komplexov a iné. Podľa normy sa skladá zo štyroch hlavných častí:

• všeobecné ustanovenia;
• opis procesu činnosti;
• hlavné technické riešenia;
• opatrenia na prípravu objektu automatizácie na uvedenie systému do prevádzky.

Schéma funkčnej štruktúry

Označenie: C2.

Tento dokument popisuje logickú štruktúru NIS, konkrétne:

• logické subsystémy a komponenty zahrnuté v NIS;
• funkcie implementované prostredníctvom subsystémov a komponentov;
• informačné prepojenia medzi logickými prvkami NIS a typmi správ pri výmene.

Schéma štruktúry komplexu technických prostriedkov

Označenie: C1.

Tento dokument obsahuje popis nasledujúcich prvkov NIS:

• technické prostriedky ako súčasť logických subsystémov a komponentov NIS;
• komunikačné kanály a výmena medzi technickými prostriedkami s uvedením transportných protokolov.

Organizačná tabuľka

Označenie: C0.

Tento dokument popisuje Organizačná štruktúra organizácie z hľadiska riadenia NIS, a to:

• pododdelenia a zodpovedné osoby organizácie zapojené do fungovania ISS;
• vykonávané funkcie a komunikácia medzi oddeleniami a zodpovednými osobami.

Zoznam zakúpených produktov

Označenie: VP.

Tento dokument obsahuje zoznam všetkého softvéru a hardvéru, ako aj licencií použitých pri vytváraní NIS. Vyvinuté v súlade s GOST 2.106.

Poznámka. Tu stojí za zmienku aj to, že riadiaci dokument RD 50-34.698-90 umožňuje doplnenie ľubovoľného dokumentu etapy TP (zahrnutie sekcií a informácií iných ako navrhovaných), zlúčenie sekcií, ako aj vyradenie niektorých jednotlivé sekcie. Rozhodnutia o tom prijíma vývojár dokumentov etapy TP a sú založené na vlastnostiach vytvoreného NIS.

1.4. Pravidlá vývoja dokumentácie

• konštrukčná zhoda štátne normy;
• prísne dodržiavanie požiadaviek technických špecifikácií systému;
• aplikácia šablón dokumentov (aplikácia jednotných štýlov, značiek, polí atď.);
• individuálny prístup a súčasné využitie existujúceho vývoja pri vypĺňaní sekcií dokumentov.

Vysvetlivka k technickému projektu:

• vývoj dokumentu sa vykonáva v prostredí Microsoft Word, po dokončení vývoja sa odporúča pre pohodlie previesť dokument do formátu PDF;
• výrazy a skratky by mali byť rovnaké vo všetkých častiach dokumentu;
• odporúča sa vyhnúť sa explicitnému opakovaniu a zbytočnému zvyšovaniu objemu dokumentu;
• technické riešenia by sa mali opísať čo najpodrobnejšie, pričom treba uviesť:
  • architektúra a použité technológie;
  • umiestnenie softvéru a hardvéru v infraštruktúre organizácie;
  • použité nástroje informačnej bezpečnosti s popisom ich charakteristík, implementovaných funkcií, certifikačných informácií;
  • základné nastavenia nástrojov informačnej bezpečnosti z hľadiska mechanizmov ochrany, adresovania, smerovania, interakcie so súvisiacimi systémami a nástrojmi a iných vecí;
  • ovládacie prvky, spôsoby prístupu k nim a miesta ich inštalácie;
  • schémy (štrukturálne, funkčné, organizačné):
    • vývoj diagramov v prostredí Microsoft Visio;
    • po vývoji vložte diagramy do dokumentu pomocou dialógového okna Prilepiť špeciálne vo formáte EMF (metasúbor Windows);
    • vypracovať samostatné schémy pre systém, subsystémy a komponenty subsystémov;
    • urobte dizajn schém rovnakého typu s použitím rovnakých prvkov, skratiek, ikon, štýlov textu atď.

1.5. Zdroje, ktoré vám pomôžu vytvoriť dokumentáciu

Na internete je zverejnené obrovské množstvo informácií, ktoré do istej miery môžu pomôcť pri vývoji technickej projektovej dokumentácie. Hlavné zdroje sú uvedené v tabuľke nižšie.

Tabuľka. Zdroje pre technické prevedenie NIB

1.6. Príklady dokumentov etapy technického projektu

Na pochopenie požiadaviek na obsah dokumentácie etapy TP sú nižšie uvedené príklady vyplnenia hlavných dokumentov (časti dokumentov).

1.6.1. Vysvetlivka k technickému projektu

Vysvetlivka je pomerne rozsiahly dokument, preto uvádzame príklad obsahu časti „Základné technické riešenia“ z hľadiska jedného zo subsystémov ISS – subsystému bezpečnostnej analýzy.

Podsystém analýzy bezpečnosti NIS

Štruktúra a zloženie subsystému

Podsystém bezpečnostnej analýzy (SAS) je navrhnutý tak, aby systematicky monitoroval bezpečnostný stav automatizovaných pracovných staníc (AWP) zamestnancov a organizačných serverov. Základom PAZ je softvérový nástroj "Test" vyrobený spoločnosťou LLC "Information Security". Zariadenie informačnej bezpečnosti Test má certifikát FSTEC Ruska na zhodu s technickými špecifikáciami (TU) pre informačnú bezpečnosť a na 4. úroveň kontroly absencie nedeklarovaných spôsobilostí.

Zloženie PAZ zahŕňa tieto komponenty:

• Server správy testovacieho servera;
• test konzoly na správu konzoly.

Opis komponentov podsystému je uvedený v tabuľke nižšie.

Tabuľka. komponenty PAZ

Poskytovanie funkcií

PAZ poskytuje nasledujúce funkcie:

• implementácia proaktívnej ochrany pracovných staníc a serverov organizácie monitorovaním stavu informačnej bezpečnosti;
• automatizácia procesov kontroly súladu domáci politici a určité bezpečnostné normy;
• zníženie nákladov na audit a kontrolu bezpečnosti, príprava správ o stave;
• automatizácia inventarizácie zdrojov, riadenie zraniteľnosti, dodržiavanie bezpečnostnej politiky a procesy kontroly zmien.

Riešenie pre komplex hardvérových a softvérových nástrojov

Zoznam softvéru a hardvéru používaného ESD je uvedený v tabuľke nižšie.

Tabuľka. Softvér a hardvér PAZ

riadiaci server PAZ

Technické prostriedky

Fyzický server používaný ako server správy SIS musí spĺňať technické požiadavky na softvér a operačný systém, ktorý je na ňom nainštalovaný, uvedené v tabuľke nižšie.

Tabuľka. Požiadavky na OS a softvér riadiaceho servera PAZ

softvér

OS servera na správu

Operačný systém Windows 2008 R2 je nainštalovaný na správcovskom serveri obvyklým spôsobom zo zavádzacej distribúcie.

OS riadiaceho servera je riadený lokálne z konzoly aj prostredníctvom protokolu RDP.

Riadiaci server DBMS

Inštalácia databázy Microsoft SQL Server 2008 R2 sa vykonáva pod účtom s právami lokálneho správcu pomocou štandardného sprievodcu inštaláciou z distribučného balíka dodaného vývojárom produktu.

Testovací serverový softvér

Softvér Test Server sa inštaluje na server správy pomocou štandardného sprievodcu inštaláciou.

Úvodná konfigurácia a následná správa softvéru Test Server v normálnom režime sa vykonáva pomocou riadiacej konzoly Test Console nainštalovanej na pracovnej stanici správcu IS.

Pracovná stanica správcu IS

Technické prostriedky

Ako platforma je použitá existujúca pracovná stanica zamestnanca organizačnej zložky zodpovednej za zabezpečenie informačnej bezpečnosti, na ktorej beží OS rodiny Microsoft Windows.

Technické prostriedky pracovnej stanice správcu IS musia mať nasledovné charakteristiky hardvérovej konfigurácie (minimálne odporúčané):

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

softvér

Testovací softvér konzoly

Pracovná stanica správcu IS, na ktorej sa inštaluje softvér Test Console, musí fungovať pod jedným z nasledujúcich operačných systémov:

• Microsoft Windows 7, 32- a 64-bitový;
• Microsoft Windows 8/8.1, 32- a 64-bitový.

Okrem toho pre správnu činnosť softvéru riadiacej konzoly Test Console musí mať pracovná stanica správcu IS nainštalovaný Microsoft .NET Framework verzie 3.5 SP1 alebo vyššej a bezpečnostné nastavenia použitého OS musia umožňovať prístup k Testovaciemu serveru.

Inštalácia softvéru Test Console na pracovnú stanicu správcu PAZ sa vykonáva pomocou štandardného sprievodcu inštaláciou softvéru Test Server s možnosťou inštalácie riadiacej konzoly Test Console a ďalších predvolených nastavení.

Interakcia so súvisiacimi systémami

Pre PAZ susedia:

• prostriedky podsystému firewall;
• adresárové služby Active Directory;
• Pracovná stanica a servery organizácie.

Aby sa zabezpečila sieťová interakcia so susednými systémami a priamo medzi ESD komponentmi samotnými, musí byť zorganizovaný prechod potrebnej sieťovej prevádzky.

Na poskytnutie možnosti prijímať aktualizácie databázy znalostí a modulov testovacieho softvéru pre skener Test Server je potrebné poskytnúť prístup k webovému serveru update.com spoločnosti Information Security LLC update.com na porte 443/tcp.

Pri skenovaní v režime PenTest sa interakcia medzi skenerom Test Server a pracovnou stanicou a servermi organizácie uskutočňuje prostredníctvom protokolu IP. Pri skenovaní v režime Audit a Compliance sa používajú protokoly diaľkového ovládania WMI, RPC atď.. Na skenovanie uzlov na zariadeniach s funkciami firewallu musíte povoliť spojenia z testovacieho servera na skenované uzly cez protokol IP. V súlade s tým je pre testovací server potrebné poskytnúť prístup k sieťovým portom skenovaných uzlov pomocou vhodných protokolov diaľkového ovládania.

Keďže PAZ pri skenovaní v režimoch Audit a Compliance používa na analýzu protokoly diaľkového ovládania, skenovacie nástroje testovacieho softvéru musia byť overené a autorizované na skenovanom uzle. V PAZ na skenovanie uzlov v režimoch Audit a Compliance v každom z typov uzlov (pracovná stanica, server, aplikačné systémy, DBMS atď.) účty s administrátorskými oprávneniami.

Všetky registrované udalosti informačnej bezpečnosti sú uložené v Microsoft SQL DBMS. Tieto udalosti je možné posielať cez špeciálne konektory do subsystému sledovania udalostí IS.

Prevádzka a údržba PAZ

Používatelia subsystému

Obsluhu a údržbu nástrojov PAZ vykonávajú pracovníci organizácie s funkčnou úlohou „správca IS“.

Správca IS je špecialista, medzi ktorého úlohy patrí:

• definovanie parametrov pre skenovanie organizačných uzlov;
• nastavenie a spustenie úloh skenovania;
• analýza výsledkov skenovania na slabé miesta, chyby konfigurácie alebo nesúlad v informačných systémoch technické normy;
• kontrola eliminácie zraniteľných miest;
• tvorba noriem a požiadaviek, ktoré sa vzťahujú na zabezpečenie bezpečnosti pracovných staníc a serverov organizácie.

Prevádzkové režimy systému

Pravidelný režim prevádzky

V bežnej prevádzke PAZ funguje 24 hodín denne, 7 dní v týždni.

V bežnej prevádzke správca IS vykonáva:

• plánované a neplánované skenovanie uzlov;
• generovanie správ;
• aktualizácia znalostných báz a modulov testovacieho softvéru.

Núdzová prevádzka

V prípade poruchy prostriedkov PAZ dochádza k narušeniu fungovania subsystému. Porušenie prevádzkyschopnosti prostriedkov PAZ nemá vplyv na fungovanie pracovnej stanice a serverov organizácie.

1.6.2. Schéma funkčnej štruktúry

Funkčné diagramy môžu byť vyvinuté pre celý NIS alebo pre jeho časť, ako je subsystém alebo komponent.

Príklad generála funkčný diagram NIB je znázornený na obrázku nižšie.

1.6.3. Schéma štruktúry komplexu technických prostriedkov

Blokovú schému komplexu technických prostriedkov je možné vypracovať ako pre celý NIS, tak aj pre jeho časti - subsystémy a komponenty. Vhodnosť vypracovania schém pre časti NIS je určená rozsahom systému a požadovanou podrobnosťou.

Príklad Bloková schéma komplexu technických prostriedkov NIS je znázornená na obrázku nižšie.

Vysvetlivka je spravidla najkomplexnejším softvérovým dokumentom, ktorý niekedy spôsobuje veľa kontroverzií a diskusií o svojom obsahu. Prečo sa to deje?

Vymenovanie vysvetľujúcej poznámky

Už sme povedali, že pri vývoji softvéru ide o jednu z dôležitých etáp. Mal by obsahovať popis vášho systému s prihliadnutím na zvolené technológie, ako to vyžaduje GOST 34. A dokument Vysvetlivka k technickému projektu, alebo skrátka PZ, je jedným z hlavných dokumentov tejto fáze. A musím povedať, že najčastejšie je to Vysvetľujúca poznámka, ktorá je najkomplexnejším dokumentom o softvéri, ktorý niekedy spôsobuje veľa kontroverzií a diskusií okolo svojho obsahu.

Zloženie typickej vysvetľovacej poznámky

Vysvetlivka k technickému projektu obsahuje tieto časti:

– Úvod. Táto časť obsahuje celý názov systému a tému vývoja, ako aj zoznam dokumentov, ktoré slúžili ako základ pre prácu na projekte.

– Účel a rozsah. Popisuje ciele a zámery, ktoré sa budú pomocou systému riešiť, ako aj rozsah jeho použitia.

– technické údaje. Táto časť je zvyčajne rozdelená na podsekcie, ktoré popisujú: nastavenie úlohy vytvorenia programu; použitý matematický aparát; Algoritmus prevádzky softvéru; štruktúra vstupných a výstupných údajov; zloženie hardvéru a softvéru. Je tiež potrebné poskytnúť výpočty a výsledky analýz, aby sa odôvodnil výber práve tých rozhodnutí, ktoré sú uvedené v dokumente.

– Očakávané technické ekonomické ukazovatele . Sekcia predpokladá ekonomické opodstatnenie vývoja s prihliadnutím na jeho technické ukazovatele.

– Zdroje použité pri vývoji. Sekcia je zoznam dokumentov, článkov a publikácií, na ktoré sa v texte odkazuje.

Normy pre vysvetľujúcu poznámku

Zloženie sekcií je určené GOST 19.404, norma však umožňuje tieto sekcie v prípade potreby kombinovať a tiež pridávať nové. V prípade použitia GOST série 34 by mal byť vypracovaný dokument v súlade s RD 50-34.698. Dokument však musí zostať v rámci požiadaviek spoločné normy, ako je napríklad GOST 19.105.

Náklady na vypracovanie vysvetľujúcej poznámky

Čo tak s najnižšie náklady vytvorte programový dokument, ktorý je pre váš projekt najužitočnejší, ktorý:

- na jednej strane jasne a zrozumiteľne prezentuje všetky potrebné (a niekedy aj nudné) informácie vrátane zložitých technických detailov;

GOST 19.404-79

Skupina T55

MEDZIŠTÁTNY ŠTANDARD

Jednotný systém programovej dokumentácie

VYSVETLIVKA

Požiadavky na obsah a dizajn

Jednotný systém pre dokumentáciu programu. Vysvetľujúca poznámka. Požiadavky na obsah a formu prezentácie

Dátum uvedenia 1981-01-01

vyhláška Štátny výbor CCSR podľa noriem z 11.12.1979 N 4753, dátum zavedenia je stanovený na 01.01.81.

REPUBLIKÁCIA. januára 2010


Táto norma stanovuje požiadavky na obsah a dizajn programového dokumentu „Vysvetlivka“, definovaný GOST 19.101-77, ktorý je súčasťou dokumentov vo fázach vývoja návrhu a technických návrhov programu.

1. VŠEOBECNÉ USTANOVENIA

1. VŠEOBECNÉ USTANOVENIA

1.1. Štruktúra a dizajn dokumentu sú stanovené v súlade s GOST 19.105-78.

Zostavenie informačnej časti (súhrn a obsah) je nepovinné.

1.2. Vysvetlivka by mala obsahovať tieto časti:

úvod;

Účel a rozsah;

technické údaje;

očakávané technické a ekonomické ukazovatele;

zdrojov používaných pri vývoji.

V závislosti od vlastností dokumentu sa môžu jednotlivé sekcie (podsekcie) kombinovať, ako aj zavádzať nové sekcie (podsekcie).

2.1. V časti „Úvod“ uveďte názov programu a (alebo) symbol témy vývoja, ako aj dokumenty, na základe ktorých sa vývoj uskutočňuje, s uvedením organizácie a dátumu schválenia.

2.2. V časti „Účel a rozsah“ uveďte účel programu, stručný popis rozsah programu.

2.3. Časť „Špecifikácie“ by mala obsahovať nasledujúce podsekcie:

stanovenie úlohy na vývoj programu, popis aplikovaných matematických metód a v prípade potreby popis predpokladov a obmedzení spojených so zvoleným matematickým aparátom;

popis algoritmu a (alebo) fungovania programu s odôvodnením výberu schémy algoritmu na riešenie problému, možné interakcie programu s inými programami;

opis a zdôvodnenie výberu metódy organizácie vstupných a výstupných údajov;

popis a zdôvodnenie voľby zloženia hardvéru a softvéru na základe výpočtov a (alebo) analýz, distribúcie dátových nosičov používaných programom.

2.4. V časti „Predpokladané technicko-ekonomické ukazovatele“ uveďte technicko-ekonomické ukazovatele, ktoré odôvodňujú výhodnosť zvoleného variantu technického riešenia, prípadne aj predpokladané prevádzkové ukazovatele.

2.5. V časti „Zdroje použité pri vývoji“ uveďte zoznam vedeckých a technických publikácií, regulačných dokumentov a iných vedeckých a technických materiálov, na ktoré sa odkazuje v hlavnom texte.

2.6. Príloha k dokumentu môže obsahovať tabuľky, zdôvodnenia, metódy, výpočty a iné dokumenty použité pri vývoji.



Elektronický text dokumentu
pripravil CJSC "Kodeks" a porovnal s:
oficiálna publikácia
Jednotný systém programovej dokumentácie:
So. GOST. -
M.: Standartinform, 2010

ministerstvo ekonomický vývoj a obchodu Ruská federácia

od 01.01.74

Táto norma stanovuje požiadavky na realizáciu technického návrhu výrobkov vo všetkých priemyselných odvetviach.

1. VŠEOBECNÉ USTANOVENIA

2. POŽIADAVKY NA VYKONÁVANIE DOKUMENTOV

DODATOK

ZOZNAM PRÁC VYKONANÝCH POČAS VÝVOJA TECHNICKÉHO NÁVRHU

Vo všeobecnosti sa pri vypracovaní technického projektu vykonávajú tieto práce: a) vývoj konštrukčných riešení produktu a jeho hlavných komponentov; b) vykonávanie potrebných výpočtov vrátane výpočtov potvrdzujúcich technické a ekonomické ukazovatele stanovené zadávacie podmienky, c) vykonanie kompletizácie potrebných schém zapojenia, schém zapojenia atď.; d) vývoj a zdôvodnenie technických riešení, ktoré poskytujú ukazovatele spoľahlivosti stanovené zadávacími podmienkami a predchádzajúcimi štádiami vývoja (ak boli tieto štádiá vyvinuté); e) analýza návrhu výrobku na vyrobiteľnosť s prihliadnutím na spätnú väzbu od priemyselných výrobcov z hľadiska zabezpečenia vyrobiteľnosti v podmienkach tejto konkrétnej výroby, vrátane využitia zariadení dostupných v podniku, ako aj zohľadnenia v tento projekt spĺňa požiadavky regulačnej a technickej dokumentácie platnej u podniku – výrobcu; identifikácia nového zariadenia potrebného na výrobu produktov (zdôvodnenie vývoja alebo akvizície); rozvoj metrologickej podpory (výber metód a prostriedkov merania); f) výroba a testovanie materiálových návrhov a (alebo) vývoj a analýza elektronických návrhov.“ g) posudzovanie výrobku z hľadiska jeho zhody s požiadavkami ekonomiky, technickej estetiky; h) posúdenie možnosti prepravy, skladovania a inštalácie výrobku v mieste jeho použitia, i) posúdenie prevádzkových údajov výrobku (zameniteľnosť, jednoduchosť údržby, udržiavateľnosť, odolnosť voči vplyvom prostredia, schopnosť rýchle odstránenie porúch, kontrola kvality produktu, dostupnosť kontrolných nástrojov technický stav a pod.); j) finalizácia žiadostí o vývoj a výrobu nových produktov (vrátane meradiel) a materiálov použitých vo vývoji produktu, k) prijímanie opatrení na zabezpečenie úrovne štandardizácie a zjednotenia produktu špecifikovaného v podmienkach referenčné; l) kontrola patentovej čistoty a konkurencieschopnosti produktu, podávanie prihlášok na vynálezy; m) identifikácia sortimentu nakupovaných produktov, koordinácia použitia nakupovaných produktov, o) koordinácia celkových, montážnych a spojovacích rozmerov so zákazníkom alebo hlavným spotrebiteľom; o) posúdenie technickej úrovne a kvality výrobku; p) vypracovanie výkresov montážnych celkov a dielov, ak je to spôsobené potrebou urýchliť zadanie úlohy na vývoj špecializovaných zariadení na ich výrobu, c) overenie súladu prijatých rozhodnutí s požiadavkami bezpečnosti a priemyselná sanitácia, vývojová a pracovná dokumentácia, okrem toho a (alebo) objasnenie práce podľa zadávacích podmienok, technického návrhu a návrhu dizajnu, dodatočne Rev. t) príprava návrhov na použitie programového vybavenia a informačnej podpory pre automatizované systémy pri tvorbe pracovnej projektovej dokumentácie (dodatočne vložené novela č. 5).