Techninio projekto pavyzdžio aiškinamasis raštas. Techninio projekto aiškinamasis raštas pagal GOST. Sistemos veikimo režimai

„Aiškinamojo rašto“ (P2 on), sukurto komercinės elektros energijos apskaitos automatizuotai matavimo ir informacinei sistemai (AIIS KUE) pavyzdys pagal k ir dokumentas. pagal i. Leidimas 2018-06-20.

Komercinės elektros apskaitos automatizuotos matavimo ir informacijos sistemos (AIIS KUE) aiškinamasis raštas (P2 pagal GOST 34.201-89) (pavyzdys)

Sukurta 2014-03-25 11:48:18

Dėmesio! Techniniai reikalavimai Didmeninės elektros energijos rinkos (DEM), kurių nuorodos yra komercinės elektros apskaitos automatizuotų matavimo ir informacinių sistemų (AIIS KUE) dokumentų pavyzdžiuose, keičiasi gana dažnai, tačiau ne mes, o administratorius. prekybos sistemos (ATS). Prašau traktuoti tai supratingai.

Visi dokumentai kovoti, kurie išlaikė daugybę, įskaitant egzaminus ROSSTANDART federalinėje valstybinėje vieningoje įmonėje „Visos Rusijos mechanikos inžinerijos standartizacijos ir sertifikavimo institutas“ (VNIIMASH), todėl nėra jokių abejonių.

Gauti Laisvas bet kurio *.pdf sutrumpintos versijos pakanka spustelėti titulinį puslapį. Dokumentas bus atidarytas naršyklėje su parinktimi. Pilnos versijos dokumentai – apmokėti, juos galima gauti formatu už tam tikrą sumą, naudojant. Bet kuris dokumentas tam tikrą laiką gali būti baigtas pagal konkrečius kliento reikalavimus. Sąlygos aptariamos.

27.10.2016 09:57:23

Šiame straipsnyje aptariamas techninio projektavimo etapas, susijęs su vienu iš sistemos gyvavimo ciklo etapų informacijos saugumas(NIB) – „projektavimo“ stadija, kuri pagal vidaus standartas GOST 34.601-90 iš karto seka informacijos apsaugos sistemos techninės užduoties rengimo.

1. NIB techninio projekto dokumentacijos rengimas

Informacijos apsaugos sistemos (toliau – SIS) gyvavimo ciklas in bendras vaizdas susideda iš šių žingsnių:

• ISS reikalavimų analizė;
• dizainas;
• įgyvendinimas;
• įgyvendinimas;
• išnaudojimą.

Šiame straipsnyje aptariamas techninio projekto etapas, susijęs su „projektavimo“ etapu, ir, remiantis vidaus standartu GOST 34.601-90, iš karto seka informacijos saugos sistemos techninės užduoties rengimas.

1.1. Kam iš viso kurti NIB dokumentus?

Atsakymas į šį klausimą turėtų būti svarstomas dviejose plokštumose: savininko plokštumoje informacijos šaltiniai(kurios apsaugai sukurtas NIS) ir tiesioginio NIS kūrėjo plokštumoje.

Informacinių išteklių savininkui svarbu gauti rezultatą kaip veikiančią informacijos saugos sistemą, kuri sumažina riziką pakenkti ribotos prieigos informacijai organizacijoje. Techninis projektas šiuo atveju padeda sukurti esminius būsimos sistemos pagrindus, būtent, jame aprašoma, kaip bus statoma ir veiks TKS, kokiomis priemonėmis ir priemonėmis bus užtikrinta informacijos apsauga, kokios yra plėtros galimybės. ir sistemos tobulinimas. Pabaigus informacinės apsaugos sistemos techninio projekto kūrimą, Klientas gauna išsamų NIS dokumentacijos rinkinį, kuriame aprašomi visi būsimos sistemos techniniai niuansai.

Tiesioginiam vykdytojui techninio projekto etape būtina nustatyti tinkamiausią NIS architektūrą, taip pat padaryti teisingas pasirinkimas informacijos apsaugos organizacijoje priemones ir priemones. Taip pat svarbu užtikrinti, kad sistemos charakteristikos ir savybės atitiktų techninę užduotį, arba, Klientui dalyvaujant ir sutikus, pagrįsti TĮ nurodytų reikalavimų koregavimą, siekiant padidinti veiklos efektyvumą. kuriama sistema.

Taigi, rengiant techninio projekto dokumentaciją, Klientas turės atsakymus į šiuos klausimus:

• kokia yra bendra NIB architektūra;
• kokiomis priemonėmis ir priemonėmis bus įgyvendinti informacijos apsaugos reikalavimai;
• kaip veiks NIS;
• kokie pokyčiai organizacijoje, būtini siekiant padidinti informacijos saugumo lygį, įvyks dėl TKS įdiegimo;
• ar kuriant ir diegiant TKS bus atsižvelgta į Užsakovo reikalavimus (verslo reikalavimus) ir norminių teisės aktų reikalavimus informacijos saugumo srityje ir, jei taip, kaip.

Rangovas, rengdamas techninio projekto dokumentaciją, gaus šiuos rezultatus:

• pagrindas pereiti prie kitų NIS kūrimo etapų, būtent darbo dokumentacijos ir įgyvendinimo etapų;
• architektūros, technologijų ir naudojamų priemonių supratimas, sistemos kūrimo tvarka;
• kaip yra įgyvendinami Užsakovo reikalavimai (verslo reikalavimai) ir norminiai dokumentai informacijos saugumo srityje sistemai.

1.2. Techninio projekto dokumentacijos rengimo metodų apžvalga

Informacijos apsaugos sistemos techninio projekto rengimas dažniausiai atliekamas remiantis atitinkamais standartais ir rekomendaciniais dokumentais. Ir už viešosios institucijos jų naudojimas yra privalomas, o komerciniais tikslais rekomenduojamas. Apie praktiką komercinės organizacijos Taip pat naudokite valstybinius standartus rengdami techninio projekto dokumentaciją dėl šių priežasčių:

• ne kartą patikrintas požiūris į informacinių sistemų kūrimą;
• apgalvota dokumentų struktūra ir turinys;
• dokumentų rinkinys, pakankamas beveik bet kuriai sistemai sukurti ir aprašyti.

Kuriant NIB techninio projekto (TP) etapo dokumentus, naudojami 34 serijos valstybiniai standartai ir rekomendaciniai dokumentai:

• GOST 34.201-89 "Dokumentų tipai, išsamumas ir žymėjimas kuriant automatizuotas sistemas". Šis standartas nurodo:
  • TP etapo dokumentų rūšys ir pavadinimai;
  • dokumentacijos išsamumas;
  • priimtas dokumentų žymėjimas;
  • NIB ir jų dalių paskyrimo taisyklės.
• GOST 34.003-90 "Terminos ir apibrėžimai";
• GOST 34.601-90 „Automatinės sistemos. Kūrimo etapai. Standartas nurodo:
  • TP etape atliktų darbų etapų sąrašas;
  • Išsamus aprašymas TP etape atlikti darbai;
  • organizacijų, dalyvaujančių kuriant NIS, sąrašas;
• RD 50-34.698-90 „Automatizuotos sistemos. Reikalavimai dokumentų turiniui. Šiame rekomendaciniame dokumente nurodyti TA etapo dokumentų turinio reikalavimai.

Svarbu suprasti, kad pagal 34 serijų standartus techninis projektas yra sistemos kūrimo etapas, o ne tik dokumentų rinkinys. Šis etapas praktikoje dažnai derinamas su etapu projekto projektas, kuris padeda parengti kelis preliminarius sprendimus ir pagrįsti tinkamiausią. Toks derinys leidžiamas pagal standartą, tačiau reikia turėti omenyje, kad tai nepaneigia būtinybės pasiekti preliminaraus projektavimo etapo tikslus.

Dažniausiai projektavimo etapas rengiamas tada, kai sistemos techninių specifikacijų reikalavimus galima įgyvendinti keliais iš esmės skirtingais būdais, taip pat jei tarp šių būdų nėra vienareikšmiškai pageidaujamų metodų.

Tačiau reikia pažymėti, kad pirmiau minėti standartai yra pernelyg bendri ir daugiausia įgyvendina projektavimo ir bendrosios konstrukcijos funkciją. Kurdami esminę techninio projekto etapo dokumentų dalį, projektuotojai naudoja informaciją iš šių šaltinių:

Galiojantys norminiai dokumentai (NLA), reglamentuojantys vienos ar kitos ribotos prieigos informacijos apsaugos reikalavimus. Šiose RLA pateikiami reikalavimai informacijos apsaugos informacinėse sistemose priemonėms, aprašomi šių priemonių įgyvendinimo niuansai ir papildomos stiprinimo priemonės. Tarp dabartinių NPA galima išskirti:

• Rusijos FSTEC 2013 m. vasario 18 d. įsakymas Nr. 21 „Dėl organizacinių ir techninių priemonių, užtikrinančių asmens duomenų saugumą, kai jie tvarkomi asmens duomenų informacinėse sistemose, sudėties ir turinio patvirtinimo“;
• Rusijos FSTEC 2013 m. vasario 11 d. įsakymas Nr. 17 „Dėl informacijos, kuri nėra valstybės paslaptis, valstybės informacinėse sistemose, apsaugos reikalavimų patvirtinimo“
• Rusijos FSTEC 2014 m. kovo 14 d. įsakymas Nr. 31 „Dėl informacijos apsaugos užtikrinimo reikalavimų patvirtinimo 2014 m. automatizuotos sistemos gamyba ir technologiniai procesai ant kritinio svarbius objektus, potencialiai pavojingus objektus, taip pat objektus, keliančius padidintą pavojų žmonių gyvybei ir sveikatai bei aplinkai natūrali aplinka;
• metodinis dokumentas „Informacijos apsaugos priemonės valstybės informacinėse sistemose“, patvirtintas Rusijos FSTEC 2014 m. vasario 11 d.

Ribotos prieigos informacijos apsaugos reikalavimai ir apsaugos priemonių sąrašai skiriasi skirtingų saugumo lygių/klasių IS. Jei informacija organizacijoje nepriklauso saugomiems pagal federaliniai įstatymai RF (pavyzdžiui, tarnybinė paslaptis), tada šios informacijos savininkas gali naudoti šiuose teisės aktuose siūlomus metodus, kurdamas įmonės ISS.

Rusijos ir užsienio standartai, apibūdinantys skirtingus požiūriusį NIS statybos gyvavimo ciklo etapų, įskaitant techninio projekto etapus, įgyvendinimo metodus:

• valstybinių standartų serija GOST R ISO / IEC 2700X, identiška tarptautinius standartus ISO/IEC 2700X. Šie standartai aprašo proceso požiūris PDCA (Plan, Do, Check, Act) – informacijos saugumo valdymo sistemos, kuri yra neatsiejama ISS dalis, gyvavimo ciklo įgyvendinimui;
• NIST SP 800-64 yra JAV nacionalinio standartų ir technologijų instituto standartas, kuriame aprašoma gyvenimo ciklas informacinių sistemų kūrimas;
• NIST SP 800-37 yra JAV nacionalinio standartų ir technologijų instituto standartas, kuriame pateikiamos gairės, kaip integruoti rizikos valdymą į informacinių sistemų kūrimo gyvavimo ciklą.

Informacijos apsaugos įrangos ir pagalbinės įrangos gamintojo eksploatacinė dokumentacija. Šiuose dokumentuose pateikiama išsami techninė informacija apie ISS statyboje naudojamas priemones, įskaitant tuos, kurie nėra tiesiogiai susiję su IS priemonių įgyvendinimu, pavyzdžiui, serveriai, duomenų saugojimo sistemos, virtualizacijos įrankiai ir kt. Bendras tokių dokumentų rinkinys skirtingiems gamintojams yra skirtingas ir, be kita ko, priklauso nuo konkretaus įrankio (aparatinės/programinės įrangos) vykdymo. Žemiau pateikiamas standartinis informacijos saugos įrankių, naudojamų kuriant techninio projekto etapo dokumentus, operatyvinės dokumentacijos rinkinys:

• bendras aprašymas (duomenų lapas);
• administratoriaus vadovas (gali būti vietinis ir centralizuotas valdymas);
• naudotojo gidas;
• greito diegimo ir diegimo vadovas (aparatinės įrangos GIS);
• operatoriaus vadovas;
• virtualios infrastruktūros diegimo vadovas (programinės įrangos GIS);

Bendra informacija apie turimas NIS architektūras, geroji NIS kūrimo praktika, informacijos saugumo ir informacijos saugumo sistemų tarpusavio integravimo gairės, informacija apie įvairių informacijos saugumo sistemų sąveikos problemas. Tokios informacijos pavyzdžiai gali būti šie dokumentai:

• informacijos saugos sistemų architektūros vadovai, pavyzdžiui: Defence-in-Depth, Cisco SAFE, Check Point SDP ir kiti;
• geriausios informacijos saugumo praktikos, pvz., pateiktos šiose nuorodose (https://www.sans.org/reading-room/whitepapers/bestprac/ , http://csrc.nist.gov/publications/nistpubs/800-14/ 800-14.pdf). Šie dokumentai dažniausiai pateikiami Anglų kalba tačiau bet kuris Rusijos informacijos saugos įrangos gamintojas turi savo geriausią apsaugos priemonių diegimo praktiką ir gali jas pateikti paprašius;
• IPS ir darbo aplinkos saugos vadovai. Pavyzdys yra skiltis „Sauga“ oficialiame „Microsoft“ portale (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).

1.3. NIB techninio projekto parengimas pagal GOST 34

Dokumentų rengimą techninio projekto etapui NIS dažniausiai vykdo šių paslaugų integratoriai ir jis įgyvendinamas daugiausia pagal šį planą:

Rengiamų dokumentų sąrašo nustatymas – ši informacija nurodyta įgaliojimai ant NIB. Tam tikrais atvejais dokumentų rengėjas, susitaręs su Užsakovu, gali išplėsti arba sumažinti šį sąrašą, jeigu to galimybė yra numatyta TĮ;

TP etapo dokumentų šablonų kūrimas - struktūra naudojama pagal RD 50-34.698-90 ir GOST 2.106 (kai kuriems dokumentams), vykdymas pagal GOST 2.105-95;

Esminės dokumentų dalies rengimas. Reikalavimai sistemai nustatyti NIB techninėje užduotyje. Pagal šiuos reikalavimus nustatomas apsaugos techninių ir organizacinių priemonių, būtinų diegti sistemoje, sąrašas. Apsaugos priemonės gali būti apibrėžtos atitinkamuose teisės aktuose (priklausomai nuo saugomos informacijos tipo), įmonės standartuose ir informacijos saugumo politikoje, taip pat remiantis esamomis saugumo grėsmėmis, nustatytomis organizacijos grėsmės modelio kūrimo etape. Remdamasis apsaugos priemonių sąrašu, TKS kūrėjas parenka tinkamas informacijos apsaugos priemones ir sukuria informacijos apsaugos sistemos funkcinę struktūrą (posistemes, komponentus). Toliau techninio projekto dokumentuose aprašoma praktinis įgyvendinimas apsaugos priemonės, pagrįstos pasirinktomis GIS arba organizacinėmis priemonėmis organizacijos infrastruktūroje.

Sukurtos dokumentacijos ir joje pateiktų sprendimų derinimas su sistemos užsakovu.

Rengiant techninio projekto dokumentaciją, dažniausiai nereikalaujama sudaryti viso GOST 34.201-89 nurodytų dokumentų sąrašo, nes šis standartas yra pasenęs, o kai kuriuose dokumentuose neatsižvelgiama į šiuolaikinių informacinių sistemų plėtros tendencijas ir technologijas. . Minimalus dokumentų rinkinys, reikalingas informacijos apsaugos sistemai apibūdinti, yra toks:

• techninio projekto pareiškimas;
• aiškinamasis raštasį techninis projektas;
• schema funkcinė struktūra;
• techninių priemonių komplekso struktūrinė schema;
• organizacinė diagrama;
• įsigytų prekių sąrašas.

Kliento pageidavimu arba jei NIS yra sudėtinga daugiakomponentė sistema, gali būti papildomai rengiami šie dokumentai:

• automatizavimo schema;
• automatizuotų funkcijų aprašymas;
• apibūdinimas informacinė pagalba sistemos;
• techninių priemonių komplekso aprašymas;
• programinės įrangos aprašymas;
• organizacinės struktūros aprašymas.

Reikėtų pažymėti, kad GOST 34.201-89 leidžia išplėsti dokumentų asortimentą TP etape, tačiau praktiškai šių dokumentų yra daugiau nei pakankamai.

Techninio projekto lapas

Pavadinimas: TP.

Šis dokumentas skirtas aprašyti techninio projekto etape parengtų dokumentų sąrašą. Taip pat nurodomas kiekvieno parengto dokumento puslapių skaičius.

Techninio projekto aiškinamasis raštas

Pavadinimas: P2.

Šis dokumentas yra pagrindinis TP etapui ir apima TKS architektūros aprašymą, technines ir organizacines priemones, TKS funkcijas, programinės ir techninės įrangos kompleksus ir kt. Pagal standartą jis susideda iš keturių pagrindinių skyrių:

• Bendrosios nuostatos;
• veiklos proceso aprašymas;
• pagrindiniai techniniai sprendimai;
• priemonės automatikos objektui paruošti sistemos paleidimui.

Funkcinės struktūros diagrama

Pavadinimas: C2.

Šiame dokumente aprašoma loginė NIS struktūra, būtent:

• loginės posistemės ir komponentai, įtraukti į NIS;
• posistemių ir komponentų pagalba įgyvendinamos funkcijos;
• informacijos sąsajos tarp loginių NIS elementų ir pranešimų tipų mainuose.

Techninių priemonių komplekso struktūrinė schema

Pavadinimas: C1.

Šiame dokumente aprašomi šie NIS elementai:

• techninės priemonės kaip NIS loginių posistemių ir komponentų dalis;
• ryšio kanalai ir mainai tarp techninių priemonių, nurodant transportavimo protokolus.

Organizacinė schema

Pavadinimas: C0.

Šiame dokumente aprašoma organizacinė struktūra organizacijos, kalbant apie NIS valdymą, būtent:

• skyriai ir atsakingi asmenys organizacijos, dalyvaujančios NVS veikloje;
• atliekamos funkcijos ir ryšių tarp skyrių bei atsakingų asmenų.

Pirktų prekių sąrašas

Pavadinimas: VP.

Šiame dokumente pateikiamas visos programinės ir techninės įrangos, taip pat licencijų, naudotų kuriant NIS, sąrašas. Sukurta pagal GOST 2.106.

Pastaba.Čia taip pat verta paminėti, kad vadovaujantis dokumentas RD 50-34.698-90 leidžia pridėti bet kokį TP etapo dokumentą (įtraukti skyrius ir informaciją, išskyrus siūlomą), sujungti skyrius, taip pat neįtraukti kai kurių atskiri skyriai. Sprendimus dėl to priima TP etapo dokumentų rengėjas ir jie remiasi sukurto NIS ypatumais.

1.4. Dokumentacijos rengimo taisyklės

• konstrukcijos atitiktis valstybiniai standartai;
• griežtas sistemos techninių specifikacijų reikalavimų laikymasis;
• dokumentų šablonų taikymas (vienodų stilių taikymas, žymėjimas, laukeliai ir kt.);
• individualus požiūris ir tuo pat metu esamų pokyčių naudojimas pildant dokumentų skyrius.

Techninio projekto aiškinamasis raštas:

• dokumentų kūrimas vykdomas aplinkoje Microsoft word, baigus kurti, patogumui rekomenduojama konvertuoti dokumentą į PDF formatą;
• terminai ir santrumpos turi būti vienodos visose dokumento dalyse;
• rekomenduojama vengti akivaizdžių pasikartojimų ir nereikalingo dokumento apimties didinimo;
• techniniai sprendimai turėtų būti aprašyti kuo išsamiau, nurodant:
  • architektūra ir naudojamos technologijos;
  • programinės ir techninės įrangos vietos organizacijos infrastruktūroje;
  • naudotas informacijos saugos priemones su jų charakteristikų aprašymu, įdiegtomis funkcijomis, sertifikavimo informacija;
  • pagrindiniai informacijos saugos priemonių nustatymai, susiję su apsaugos mechanizmais, adresais, maršrutais, sąveika su susijusiomis sistemomis ir įrankiais ir kitais dalykais;
  • valdikliai, prieigos prie jų būdai ir jų įrengimo vietos;
  • schemos (struktūrinės, funkcinės, organizacinės):
    • kurti diagramas Microsoft Visio aplinkoje;
    • po kūrimo įterpkite diagramas į dokumentą naudodami dialogo langą Paste Special EMF formatu (Windows metafailas);
    • parengti atskiras sistemos, posistemių ir posistemių komponentų schemas;
    • padaryti schemų dizainą tokio paties tipo, naudojant tuos pačius elementus, santrumpas, piktogramas, teksto stilius ir pan.

1.5. Ištekliai, padėsiantys kurti dokumentus

Internete yra patalpintas didžiulis kiekis informacijos, kuri vienu ar kitu laipsniu gali padėti rengiant techninio projekto dokumentaciją. Pagrindiniai ištekliai pateikti toliau esančioje lentelėje.

Lentelė. NIS inžinerinio projektavimo ištekliai

išteklių tipas	Informacija	Išteklių pavyzdžiai
Federalinės vykdomosios valdžios institucijų interneto portalai	Reglamentas, Gairės, registrai (įskaitant sertifikuotas informacijos saugos priemones), duomenų bazės (įskaitant pažeidžiamumų ir grėsmių duomenų bazes)	fstec.ru clsz.fsb.ru minsvyaz.ru/ru/
IS gamintojų, informacijos saugumo sprendimų platintojų internetiniai portalai	Informacijos saugumo sprendimų aprašymas, informacinės saugos operatyvinė dokumentacija, analitinė medžiaga ir straipsniai	securitycode.ru kaspersky.com/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html checkpoint.com altx-soft.ru
Specializuoti informacijos saugos ištekliai	Informacijos saugumo sprendimų palyginimas, apžvalginiai straipsniai apie informacijos saugos sprendimus, informacijos saugos sprendimų testai, išsami techninė informacija apie informacijos saugos technologijas	anti-malware.ru bis-expert.ru safe.cnews.ru securitylab.ru/ www.vulners.com/ csrc.nist.gov itsecurity.com owasp.org sans.org

1.6. Techninio projekto etapo dokumentų pavyzdžiai

Norint suprasti TP etapo dokumentacijos turinio reikalavimus, žemiau pateikiami pagrindinių dokumentų (dokumentų skilčių) pildymo pavyzdžiai.

1.6.1. Techninio projekto aiškinamasis raštas

Aiškinamasis raštas yra gana didelės apimties dokumentas, todėl čia pateikiamas skyriaus „Pagrindiniai techniniai sprendimai“ turinio pavyzdys, kalbant apie vieną iš TKS posistemių – saugumo analizės posistemį.

NIS saugumo analizės posistemis

Posistemio struktūra ir sudėtis

Saugumo analizės posistemis (SAS) skirtas sistemingai stebėti personalo ir organizacijos serverių automatizuotų darbo vietų (AWP) saugos būseną. PAZ pagrindas yra bendrovės LLC „Informacijos sauga“ sukurta programinė įranga „Test“. SZI Test turi atitikties Rusijos FSTEC sertifikatą specifikacijas(TU) dėl informacijos saugumo ir dėl 4-ojo nedeklaruotų pajėgumų nebuvimo kontrolės lygio.

PAZ sudėtis apima šiuos komponentus:

• Test Server valdymo serveris;
• testavimo pulto valdymo pultas.

Posistemio komponentų aprašymas pateiktas žemiau esančioje lentelėje.

Lentelė. PAZ komponentai

Komponentas	apibūdinimas
Testo serverio valdymo serveris	Teikia skenavimo užduočių valdymą, atlieka organizacijos darbo vietos ir serverių saugos būklės stebėjimo funkcijas. Nuskaitymo parametrus nustato IS administratorius Test Server valdymo serveryje. Visi surinkta informacija nuskaitymo rezultatai saugomi „Test Server“ saugykloje, pagrįsta „Microsoft SQL Server 2008“ duomenų bazių valdymo sistema
Bandymo pulto valdymo pultas	Leidžia IS administratoriui prisijungti prie testavimo serverio, peržiūrėti ir keisti jo konfigūraciją, kurti ir keisti nuskaitymo užduotis, peržiūrėti informaciją apie užduočių eigą ir jų rezultatus. Valdymo konsolė įdiegta informacijos saugos administratoriaus darbo vietoje

Funkcijos teikimas

PAZ teikia šias funkcijas:

• aktyvios organizacijos darbo vietų ir serverių apsaugos įgyvendinimas, stebint informacijos saugumo būklę;
• vidaus politikos ir tam tikrų saugumo standartų laikymosi stebėjimo procesų automatizavimas;
• audito ir saugumo kontrolės išlaidų mažinimas, būklės ataskaitų rengimas;
• išteklių inventorizavimo automatizavimas, pažeidžiamumo valdymas, saugos politikos atitikties ir pakeitimų kontrolės procesai.

Techninės ir programinės įrangos įrankių komplekso sprendimas

ESD naudojamos programinės ir techninės įrangos sąrašas pateiktas toliau esančioje lentelėje.

Lentelė. programinė įranga- techninėmis priemonėmis GROOVE

PAZ valdymo serveris

Techninės priemonės

Fizinis serveris, naudojamas kaip SIS valdymo serveris, turi atitikti jame įdiegtos programinės įrangos ir OS techninius reikalavimus, pateiktus žemiau esančioje lentelėje.

Lentelė. Reikalavimai PAZ valdymo serverio OS ir programinei įrangai

Programinė įranga	Techniniai reikalavimai
	CPU	RAM, MB
Microsoft Windows Server 2008 R2	3000 MHz, 4 branduoliai	8192
Microsoft SQL Server 2008 R2
Išbandyti serverio programinę įrangą

Programinė įranga

Valdymo serverio OS

„Windows 2008 R2“ OS yra įdiegta valdymo serveryje įprastu būdu iš įkrovos paskirstymo.

Valdymo serverio OS valdoma tiek lokaliai iš konsolės, tiek per KPP protokolą.

Valdymo serveris DBVS

„Microsoft SQL Server 2008 R2“ duomenų bazės diegimas vykdomas naudojant vietinio administratoriaus teises, naudojant standartinį diegimo vedlį iš platinimo paketo, kurį pateikia produkto kūrėjas.

Testuoti serverio programinę įrangą

„Test Server“ programinė įranga įdiegiama valdymo serveryje naudojant standartinį diegimo vedlį.

Pradinė „Test Server“ programinės įrangos konfigūracija ir tolesnis valdymas įprastu režimu atliekamas naudojant „Test Console“ valdymo pultą, įdiegtą IS administratoriaus darbo vietoje.

IS administratoriaus darbo vieta

Techninės priemonės

Kaip platforma naudojama esama už informacijos saugumo užtikrinimą atsakingo organizacinio padalinio darbuotojo darbo vieta, kurioje veikia Microsoft Windows šeimos OS.

IS administratoriaus darbo vietos techninės priemonės turi turėti tokias techninės įrangos konfigūracijos charakteristikas (rekomenduojama bent):

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

Programinė įranga

Testavimo pulto programinė įranga

IS administratoriaus darbo vieta, kurioje diegiama Test Console programinė įranga, turi veikti viena iš šių operacinių sistemų:

• Microsoft Windows 7, 32 ir 64 bitų;
• Microsoft Windows 8/8.1, 32 ir 64 bitų.

Be to, kad Test Console valdymo pulto programinė įranga tinkamai veiktų, IS administratoriaus darbo vietoje turi būti įdiegta Microsoft .NET Framework 3.5 SP1 ar naujesnė versija, o naudojamos OS saugos parametrai turi leisti prieigą prie Test Server.

„Test Console“ programinės įrangos diegimas PAZ administratoriaus darbo vietoje atliekamas naudojant standartinį „Test Server“ programinės įrangos diegimo vedlį su galimybe įdiegti „Test Console“ valdymo pultą ir kitus numatytuosius nustatymus.

Sąveika su susijusiomis sistemomis

PAZ atveju greta yra:

• ugniasienės posistemio priemonės;
• katalogų paslaugos Active Directory;
• Organizacijos darbo vieta ir serveriai.

Norint užtikrinti tinklo sąveiką su gretimomis sistemomis ir tiesiogiai tarp pačių ESD komponentų, reikia organizuoti reikiamo tinklo srauto praėjimą.

Norint suteikti galimybę gauti testavimo programinės įrangos, skirtos Test Server skaitytuvui, žinių bazės ir modulių naujinimus, būtina suteikti prieigą prie Information Security LLC update.com žiniatinklio serverio update.com per prievadą 443/tcp.

Nuskaitant „PenTest“ režimu, „Test Server“ skaitytuvo ir darbo vietos bei organizacijos serverių sąveika vykdoma per IP protokolą. Nuskaitant audito ir atitikties režimu, naudojami nuotolinio valdymo protokolai WMI, RPC ir t.t.. Norėdami nuskaityti pagrindinius kompiuterius įrenginiuose su ugniasienės funkcijomis, turite leisti prisijungti iš Testo serverio prie nuskaitytų kompiuterių per IP protokolą. Atitinkamai, bandomajam serveriui būtina suteikti prieigą prie nuskaitytų mazgų tinklo prievadų naudojant atitinkamus nuotolinio valdymo protokolus.

Kadangi PAZ, nuskaitydamas audito ir atitikties režimais, analizei naudoja nuotolinio valdymo protokolus, Testavimo programinės įrangos nuskaitymo įrankiai turi būti autentifikuoti ir įgalioti nuskaitytame mazge. PAZ, norint nuskaityti mazgus audito ir atitikties režimais kiekviename mazgų tipe (darbo stotis, serveris, taikomųjų programų sistemos, DBVS ir kt.) Sąskaitos su administracinėmis privilegijomis.

Visi registruoti informacijos saugos įvykiai yra saugomi Microsoft SQL DBVS. Šiuos įvykius specialiomis jungtimis galima siųsti į IS įvykių stebėjimo posistemį.

PAZ eksploatavimas ir priežiūra

Posistemio vartotojai

PAZ įrankių eksploatavimą ir priežiūrą atlieka organizacijos darbuotojai, turintys funkcinį „IS administratoriaus“ vaidmenį.

IS administratorius yra specialistas, kurio užduotys apima:

• nuskaitymo organizacijos mazgų parametrų apibrėžimas;
• nuskaitymo užduočių nustatymas ir paleidimas;
• skenavimo rezultatų analizė dėl informacinių sistemų pažeidžiamumo, konfigūracijos klaidų ar techninių standartų reikalavimų neatitikimo;
• pažeidžiamumų pašalinimo kontrolė;
• standartų ir reikalavimų, taikomų organizacijos darbo vietų ir serverių saugumui užtikrinti, formavimas.

Sistemos veikimo režimai

Reguliarus veikimo režimas

Įprastu režimu PAZ veikia 24 valandas per parą, 7 dienas per savaitę.

Įprastai veikiant IS administratorius atlieka:

• suplanuotas ir neplanuotas mazgų nuskaitymas;
• ataskaitų generavimas;
• testavimo programinės įrangos žinių bazių ir modulių atnaujinimas.

Avarinė operacija

Sugedus PAZ priemonėms, sutrinka posistemio veikimas. PAZ priemonių veikimo pažeidimas neturi įtakos organizacijos darbo vietos ir serverių veikimui.

1.6.2. Funkcinės struktūros diagrama

Funkcinės diagramos gali būti sukurtos visam NIS arba jo daliai, pavyzdžiui, posistemiui ar komponentui.

NIB bendrosios funkcinės diagramos pavyzdys parodytas toliau pateiktame paveikslėlyje.

1.6.3. Techninių priemonių komplekso struktūrinė schema

Techninių priemonių komplekso blokinė schema gali būti sukurta tiek visam NIS, tiek jo dalims - posistemiams ir komponentams. NIS dalių schemų kūrimo tikslingumą lemia sistemos mastas ir reikalinga detalė.

Pavyzdys blokinė schema NIS techninių priemonių kompleksas parodytas paveikslėlyje žemiau.

Techninio projekto aiškinamasis raštas yra vienas iš pagrindinių dokumentų, įtrauktų į etape parengtą dokumentaciją techninis projektas. Aiškinamajame rašte yra Bendra informacija apie projektuojamą sistemą, jos sukūrimo pasirinktų techninių sprendimų pagrindimą, taip pat veiksmų planą, kurio dėka planuojama sistemą pradėti eksploatuoti.

Struktūra ir apdaila

Aiškinamasis raštas surašytas pagal tarpvalstybinį standartą GOST 2.106-96, kuriame aprašoma Bendrieji reikalavimai teksto sudarymui ir projektinė dokumentacija, jo skyrių turinys aprašytas reglamentuojančiame dokumente RD 50-34.698-90, kuris reglamentuoja automatizuotų valdymo sistemų dokumentų turinio reikalavimus.

Šis dokumentas, remiantis standartais ir gairėmis, turėtų būti sudarytas iš kelių skyrių:

"Bendrosios nuostatos"
Nurodant kuriamos automatizuotos valdymo sistemos pavadinimą, dokumentus, kuriais remiantis kuriama sistema – techninę užduotį, sutartis – organizacijas, kurios dalyvauja projektuojant, darbų etapus ir įgyvendinimo terminus, tikslus. kuriant sistemą, jos paskirtį ir apimtį, techninius ir normatyvinė dokumentacija, taip pat projektavimo darbų tvarka.

„Veiklos proceso aprašymas“
Techninio projekto aiškinamajame rašte pateikiama bendra informacija apie sukurtos sistemos funkcionavimą.

„Pagrindiniai techniniai sprendimai“
Pateikiama sistemos struktūra su posistemių sąrašu, sistemos komponentų keitimosi duomenimis metodai ir priemonės, AU santykis su kitomis sistemomis, veikimo režimai. Taip pat turėtų būti nurodyta darbuotojų kvalifikacija ir skaičius, sistemos funkcijos, jos veikimą užtikrinančios techninės priemonės, informacijos ir programinės įrangos poreikiai.

„Sistemos paruošimo darbui žingsniai“
Pateikiamas personalo mokymo darbų sąrašas, sistemos išvesties duomenų suvedimas į tinkamą tolimesniam naudojimui formą, darbo vietų organizavimas ir kitos veiklos, atitinkančios konkrečios sistemos paleidimo specifiką.

Žemiau pateikiamas projekto dokumento pavyzdys (pavyzdys) Automatizuotos sistemos sukūrimo techninio projekto aiškinamasis raštas“, remiantis metodinėmis gairėmis RD 50-34.698-90. Šį dokumentą rengia IT specialistas informacinės sistemos techninis projektas.

Kaip informacinės sistemos kūrimo pavyzdys panaudotas informacinės ir analitinės sistemos diegimo projektas. „Įmonės duomenų saugykla“.

Žemiau esančiame puslapyje yra techninio projekto aiškinamojo rašto turinys pagal GOST, trumpai kiekviename skyriuje pateikiami pildymo pavyzdžio turiniui ir tekstui keliami reikalavimai(paryškinta vertikalia linija).

Aiškinamojo rašto skyriai:

Bendrosios nuostatos

Pagrindiniai techniniai sprendimai

Sprendimai dėl sistemos struktūros, posistemių, komunikacijos priemonių ir metodų informacijos mainams tarp sistemos komponentų

AS sujungimo su gretimomis sistemomis sprendimai, užtikrinantys jo suderinamumą

Darbo režimų sprendimai, sistemos veikimo diagnostika

Sprendimai dėl personalo ir jo darbo būdų

Informacija apie techninėje užduotyje nurodytų sistemos vartotojų savybių, lemiančių jos kokybę, užtikrinimą

Sistemos įgyvendinamų funkcijų, užduočių kompleksų sudėtis

Techninių priemonių kompleksų sudarymas ir išdėstymas

Techninio projekto aiškinamasis raštas.

Pagrindinis IS kūrimo tikslas – pagreitinti „pardavimo procesą“, taip pat padidinti darbuotojų efektyvumą. Norint užtikrinti sistemos veikimą, kompiuteriuose, kuriuose ji naudojama, turi būti įdiegta ši programinė įranga:

• - Windows šeimos OS;
• - 1C: įmonė 8;

Nauji duomenys įvedami į sistemą prieš pradedant darbą, tai būtina norint įvesti pradinius likučius. Siekiant apriboti neteisėtus pakeitimus, įeinant į programą naudojamas autorizavimas. Jei slaptažodis bus įvestas neteisingai, sistema parodys pranešimą ir neleis prisijungti prie duomenų bazės.

Sistema turi tris pagrindines užduotis:

• - žinynų priežiūra;
• - sandėlių priežiūra;
• - pardavimų registravimas;
• - ataskaitų išvedimas.

DB programa IP kuriama naudojant programinės įrangos aplinką 1C: Enterprise 8. Sistemai priglobti naudojami asmeniniai kompiuteriai, kurie yra prieinami individualiam verslininkui, kuriam sistema kuriama.

Schema funkcinis struktūros

Bendrieji projektuojamos sistemos funkcionalumo reikalavimai parodyti naudojant VI diagramą 1 paveiksle

-2 lentelė Pagrindinė VI vykdymo scenarijaus dalis "Pridėti katalogo duomenis"

	Redaguoti katalogo duomenis
	Sandėlininkas, IP
	Naujausios informacijos apie dalykinės srities objektus palaikymas
Trumpas aprašymas	Vartotojas prideda naują katalogo elementą ir jį užrašo. Sistema išsaugo pakeistus duomenis duomenų bazėje
Išankstinė sąlyga	1. Vartotojas yra įgaliotas sistemoje. 2. Vartotojas turi teisę įtraukti duomenis į katalogą
pobūdis	1. Katalogo elementas įrašomas į duomenų bazę. 2. Katalogo elementas rodomas katalogų sąrašo forma

-3 lentelė Tipinė VI vykdymo scenarijaus „Pridėti katalogo duomenis“ įvykių eiga

-4 lentelė VI vykdymo scenarijaus „Pridėti katalogo duomenis“ išimtys

-5 lentelė VI vykdymo scenarijaus pagrindinė skiltis "Nustatyti prekių kainas"

Lentelė - 6 Tipinė VI vykdymo scenarijaus įvykių eiga "Nustatyti prekių kainas"

-7 lentelė VI vykdymo scenarijaus „Nustatyti prekių kainas“ išimtys

-8 lentelė VI vykdymo scenarijaus pagrindinė skiltis „Įregistruoti prekių gavimą“

-9 lentelė VI vykdymo scenarijaus "Prekių gavimo registracija" tipinė įvykių eiga

Aktoriaus veiksmai	Sistemos atsakas
1. Sandėlininkas vykdo komandą sukurti naują dokumentą „Prekių gavimas“	2. Sistema rodo dokumento formą
3. Sandėlio savininkas užpildo antraštės duomenis 1 išimtis: sandėlininkas rankiniu būdu užpildo lauką Skaičius
4. Prekės puslapyje esančioje lentelės skiltyje sandėlininkas prideda naują eilutę	5. Sistema parodo naują eilutę
6. Sandėlininkas užpildo stulpelį Nomenklatūra	7. Sistema pakeičia stulpelių reikšmę
8. Sandėlininkas užpildo stulpelį Kiekis	9. Sistema apskaičiuoja stulpelių Kiekis reikšmę,
10. Sistema lentelės dalies poraštėje rodo bendras stulpelių reikšmes Total
11. Įeina sandėlininkas naujas produktas(grįžkite į 4 veiksmą) arba vykdykite komandą Write 2 išimtis: Lauko Skaičius reikšmė nėra unikali	12. Sistema įrašo naujas dokumentas„Prekių gavimas“ duomenų bazėje
13. Sandėlininkas vykdo komandą Spausdinti -	14. Sistema rodo baigtą spausdinta forma kvito orderis
15. Sandėlininkas vykdo komandą Spausdinti	16. Sistema išspausdina kvito užsakymą
17. Sandėlininkas vykdo komandą Uždaryti spausdinimo formą	18. Sistema uždaro spausdinimo plokštę
19. Sandėlininkas vykdo komandą Uždaryti dokumentą "Prekių gavimas"	20. Sistema uždaro dokumento formą „Prekių gavimas“

-10 lentelė VI „Prekių gavimo registravimo“ vykdymo scenarijaus išimtys

Sumos ir bendros stulpelių reikšmės apskaičiuojamos pagal formulę:

Kiekis = Kiekis * Kaina

VI „Parduoti“ scenarijaus dalis -11 lentelė.

-12 lentelė Tipinė VI „Parduoti“ scenarijaus įvykių eiga

Aktoriaus veiksmai	Sistemos atsakas
Apmokėjimas už vieną „pardavimo“ dokumentą
1. Vadovas vykdo komandą sukurti naują pardavimo dokumentą	2. Sistema rodo "pardavimo" dokumentų formą
4. Dokumentą patalpinantis vadovas
5. Sistema saugo dokumentą
9. Sistema spausdina

Lentelė - 13 VI vykdymo scenarijaus "Regitro dokumentas" išimtys

VI "Rezervacija" vykdymo scenarijaus -14 lentelė.

-15 lentelė VI „Pardavimas“ vykdymo scenarijaus tipinė įvykių eiga

Aktoriaus veiksmai	Sistemos atsakas
Prekės rezervacija
1. Vadovas vykdo komandą sukurti naują rezervavimo dokumentą	2. Sistema rodo „rezervavimo“ dokumentų formą
3. Vadovas įveda duomenis apie klientą, perkamą prekę ir įsigytas paslaugas
4. Dokumentą patalpinantis vadovas Išimtis Nr. 1 ne visi laukai užpildyti	5. Sistema saugo dokumentą
6. Vadovas vykdo komandą Spausdinti	7. Sistema rodo baigtą spausdinimą
8. Vadovas vykdo komandą Spausdinti	9. Sistema spausdina
10. Vadovas vykdo komandą Uždaryti spausdinimo formą	11. Sistema uždaro spausdinimo plokštę
11. Vadovas vykdo komandą Uždaryti dokumentą "paslaugų teikimas"	12. Sistema uždaro dokumento formą

Lentelė - 16 VI vykdymo scenarijaus "Regitro dokumentas" išimtys

-17 VI lentelė "Sukurti ataskaitą"

Katalogų struktūros kūrimas

Katalogas "Rangovai" skirta informacijai apie klientus, tiekėjus saugoti.

Lentelė -15 Informacija apie žinyną Klientai

Teisinis statusas yra enum tipo. Tai reiškia, kad pasirinkus šį lauką atsiras trijų būsenų sąrašas: IP, Fizinis. Asmuo, Organizacija.

Kūrimas katalogas "Darbuotojai". Skirta informacijai apie organizacijos darbuotojus saugoti. Leidžia susieti pardavimą su konkrečiu darbuotoju.

Lentelė -16 Informacija apie katalogą Darbuotojai

Kūrimas katalogas "Sandėliai". Skirta prekių saugojimo vietai nustatyti. IP turės du sandėlius – 1 prekybos tašką ir 2 prekybos tašką.

Kūrimas katalogai "Variantas Prekės » ir "Papildomas Savybės". Šios nuorodos skirtos tam tikros nomenklatūros papildomoms charakteristikoms apibrėžti, ty monitoriai gali būti identiški, tačiau skiriasi spalvos. Šie katalogai bus vadinami nomenklatūros katalogo forma. Šių laukų reikšmė rodoma „Pardavimų“ dokumente.

Kūrimas katalogas "Nomenklatūra". Iš tiekėjo įsigytų prekių apskaitai sudarysime žinyną „Nomenklatūra“.

Nomenklatūros katalogo elementai bus jungiami į grupes pagal jų funkcinę paskirtį, todėl katalogas turės hierarchijos formą „grupių ir elementų hierarchija“.

-17 lentelė Žinyno Nomenklatūra rekvizitai

Informacinio registro „Nomenklatūros kainos“ struktūros plėtra

Nomenklatūros vienetų savikainai saugoti sukursime informacijos registrą pavadinimu „Kainos“. Registro dažnis yra per sekundę (ty kainas galima sekti bet kuriuo momentu), įrašymo režimas nepriklausomas.

-18 lentelė Informacinio registro struktūra Kainos

Ypatybė „Leading“ nurodo, kad informacijos registro įrašas domina tol, kol egzistuoja objektas, kurio nuoroda pasirinkta kaip šio įrašo šio dimensijos reikšmė. Ištrynus objektą, visi šio objekto informacijos registro įrašai bus automatiškai ištrinti.

Dokumento „Prekių gavimas“ struktūros sukūrimas

Dokumentas „Prekių gavimas“ skirtas atspindėti įsigytų prekių gavimo organizacijoje faktą.

19 lentelė dokumento „Prekių gavimas (kvitavimo sąskaita)“ rekvizitai

-19 lentelė Dokumento lentelinės dalies „Prekių gavimas“ duomenys

Buvo parašytas kodas, skirtas automatiškai apskaičiuoti stulpelių Kiekis reikšmes, keičiant stulpelių Kiekis, Kaina reikšmes.

Dokumento forma atrodys taip, kaip parodyta 2 paveiksle




2 pav. Dokumento forma Prekių gavimas

Dokumento „Pardavimai“ struktūros sukūrimas

Paslaugų teikimo dokumentas skirtas individualaus verslininko veiklai fiksuoti. Jis kontroliuoja atliktų prekių, paslaugų nurašymą, taip pat leidžia peržiūrėti darbuotojų darbo ataskaitą.

Lentelė -20 Dokumento "Pardavimai" detalės

Lentelė -21 Informacija apie pardavimo dokumento lentelę

Dokumento „Rezervacija“ struktūros sukūrimas

Dokumentas „Rezervacija“ skirtas rezervacijai esamą produktą sandėlyje, o pritrūkus nuvežti klientui trūkstamą prekių dalį. Taip pat būtina rezervuoti prekes, kol klientas apmokės užsakymo kainą. Šis dokumentas skirtas atsargų likučiams kontroliuoti, siekiant išvengti nesusipratimų su klientu.

Lentelė -20 Dokumento "Rezervacija" detalės

Lentelė -21 Lentelinės dokumento dalies informacija Rezervacija

Vystymas struktūros dokumentas "Įvestis pirminis likučiai"

Šis dokumentas reikalingas pradiniams likučiams įvesti į duomenų bazę.

Jo rekvizitai yra panašūs į dokumentą „Kvito sąskaita faktūra“.

Kūrimas ataskaita "Produktai"

Prekių ataskaita skirta greitai peržiūrėti prekių nurašymą ir gavimą. Tai yra, tai leidžia vartotojui peržiūrėti, kiek prekių šiuo metu yra, kiek jų parduota.

1C Enterprise 8 aplinkoje yra ataskaitų kūrimo priemonė, leidžianti greitai sukurti ataskaitą generuojant užklausas ir pagal lenteles kuriant dizainą.

Kūrimas ataskaita „Pardavimo dokumentų registras“

Ši ataskaita skirta „pardavimo“ dokumentų registrui generuoti. Taip pat sistemoje bus įdiegtos įvairios ataskaitos, kurios kūrimo struktūra bus panašios.

Kūrimas vaidmenis ir paskyrimas juos vartotojų

1C:Enterprise vartotojų sąrašo administravimas ir vaidmenų priskyrimas jiems pagal jų tarnybinės pareigos- labai svarbius punktus už taikomo sprendimo sąsajos kaip visumos organizavimą ir atskirų jo vartotojų teisių ir veiksmų atribojimą.

Vartotojams turėtų būti uždrausta atlikti veiksmus su duomenų bazės objektais. Pavyzdžiui, sandėlininkas gali sudaryti Prekių gavimo dokumentus ir fiksuoti dokumentus, nes jis yra atsakingas už prekių gavimo registravimą. Vadybininkas savo ruožtu turėtų turėti prieigą prie klientų katalogų papildymo, „pardavimo“ dokumento surašymo, „rezervavimo“, tačiau tuo pačiu jis neturėtų turėti prieigos prie prekių gavimo.

Tokiems leidimams apibūdinti naudojami vaidmenų konfigūracijos objektai. Kiekvienam sistemos vartotojui priskiriamas vienas ar keli vaidmenys.

Vaidmenys kuriami atsižvelgiant į tai, kokių leidimų reikia skirtingoms vartotojų grupėms norint pasiekti informaciją. Mūsų sistemoje bus įgyvendinti šie vaidmenys:

• - administratorius - sistemoje 1C:Enterprise turi būti vaidmuo, apimantis visas teises dirbti su IS duomenimis;
• - sandėlininkas;
• - vadovas;
• - IP.

Vaidmenų priskyrimas vartotojams atliekamas per pagrindinio meniu punktą Administravimas -> Vartotojai.



3 pav. „Administratoriaus“ vartotojo su „Administratoriaus“ vaidmeniu sukūrimas



4 paveikslas – sistemos vartotojų sąrašas

Interaktyvioji trynimo teisė yra išjungta visiems duomenų bazės objektams visiems vaidmenims.

Redagavimas komandą sąsaja skyriuose ir dirbantys stalo

Patobulinus programos komandų sąsają, nustatant komandų matomumą pagal vaidmenis ir darbalaukį, programa tampa patogesnė vartotojui ir suteikia jai pilną išvaizdą.

Suskirstykime komandas pagal prioritetą ir naudojimo dažnumą į šias grupes:

• - naršymo juosta.Svarbu;
• - naršymo juosta Normalus;
• - Naršymo juosta. taip pat;
• - veiksmų juosta. Sukurkite ir
• - veiksmų juosta Ataskaitos



5 pav. Vartotojo, turinčio „Sandėlininko“ vaidmenį, skyriaus „Medžiagų apskaita“ komandų sąsaja



6 pav. Vartotojo, turinčio „Valdytojo“ vaidmenį, skyriaus „Paslaugų teikimas“ komandų sąsaja




7 pav. Vartotojo, turinčio „Direktoriaus“ vaidmenį, skyriaus „Įmonė“ komandų sąsaja



8 pav. Vartotojo, turinčio „Administratoriaus“ vaidmenį, skyriaus „Mažmeninė prekyba.Elektronika“ komandų sąsaja

Darbalaukis sukurtas taip, kad tilptų dažniausiai vartotojo naudojami dokumentai, ataskaitos, katalogai ir pan. Paleidus 1C:Enterprise, darbalaukio skyrius tampa aktyvus pagal numatytuosius nustatymus, o reikalingos formos iškart atidaromos programos darbo srityje.




9 pav. „Sandėlininko“ vaidmenį atliekančio vartotojo darbalaukis




10 pav. Darbalaukis, skirtas vartotojui, turinčiam „Valdytojo“ vaidmenį

automatizavimas didmeninė prekyba programinės įrangos dokumentacija