Teknisk dokumentation. Förklarande anmärkning till det tekniska projektet Förklarande anmärkning till exemplet med teknisk specifikation
Huvudsyftet med den förklarande anmärkningen är att tillhandahålla allmän information om systemet och motivering för tekniska beslut som fattats under dess utveckling. Därför kommer grunden för utvecklingen av den förklarande anmärkningen huvudsakligen att vara uppdragsbeskrivningen.
Den förklarande anteckningen är ett av de viktigaste dokumenten i det tekniska projektet. Den tekniska designen är framtagen med syfte att identifiera slutgiltiga tekniska lösningar som ger en helhetsbild av produktdesignen.
När du utvecklar ett program för att skapa en förklarande anteckning, rekommenderas att du använder GOST 19.404-79 "Förklarande anteckning. Krav på innehåll och design."
För att skapa en förklarande notering för ett tekniskt projekt som beskriver ett automatiserat system (AS), rekommenderas att använda standarden RD 50-34.698-90 "Automatiserade system. Krav på innehållet i dokument".
Många delar av ovanstående dokument överlappar varandra, så som ett exempel kommer vi att betrakta dokumentet förklarande anmärkning skapad på grundval av RD 50-34.698-90
1. Allmänna bestämmelser
1.1 Namn på den designade högtalaren
Detta avsnitt av den förklarande anmärkningen innehåller det fullständiga och korta namnet på AS.
Till exempel: ”I det här dokumentet kallas systemet som skapas Corporate Information Portal. Det är också tillåtet att använda det förkortade namnet "KIP" eller "System."
1.2 Dokument på grundval av vilka systemet är utformat
Detta avsnitt av den förklarande anmärkningen bör innehålla hänvisningar till kontraktet och villkoren för utveckling av ett automatiserat system.
1.3 Organisationer involverade i systemutveckling
Det här avsnittet i dokumentet med förklarande anmärkningar anger namnen på kund- och utvecklarorganisationer.
1.4 Mål för AS-utveckling
I detta avsnitt av det förklarande anmärkningsdokumentet bör de tekniska, ekonomiska och produktionsfördelar som kunden kommer att få efter att ha implementerat det utvecklade systemet anges.
Till exempel: "Syftet med systemet som skapas är:
- optimering av företagets dokumentflöde;
- stöd för företagets företagskultur;
- optimering av kommunikationen mellan företagets anställda. »
1.5 Syfte och användningsområde för det utvecklade högtalarsystemet
Detta avsnitt av den förklarande anmärkningen måste innehålla en beskrivning av typen av aktivitet som automatiseras och en lista över de processer för vilka systemet är avsett att automatiseras.
Till exempel: ”KIP är utformat för att tillhandahålla fullständig och aktuell information, samt effektiv organisation av medarbetarnas arbete. Systemet bör säkerställa organisationen av de anställdas gemensamma arbete med hjälp av följande förmågor:
- Skapande av konferenser för att diskutera frågor;
- Skicka/ta emot elektroniska postmeddelanden;
- Säkerställa samarbete kring dokument;
- Samordning av dokument;
- Upprätthålla register över inkommande och utgående dokumentation."
1.6 Information om de reglerande och tekniska dokument som används i konstruktionen
Detta avsnitt bör ange de standarder som användes för att skapa dokumentet med förklarande anmärkningar.
Till exempel: "Följande reglerande och tekniska dokument användes under konstruktionen:
- GOST 34.201-89 "Informationsteknik. Uppsättning standarder för automatiserade system. Typer, fullständighet och beteckningar av dokument när man skapar automatiserade system";
- GOST 34.602-89 "Informationsteknik. Uppsättning standarder för automatiserade system. Tekniska specifikationer för skapandet av ett automatiserat system";
- GOST 34.003-90 "Informationsteknik. Uppsättning standarder för automatiserade system. Automatiserade system. Termer och definitioner";
- GOST 34.601-90 "Informationsteknik. Uppsättning standarder för automatiserade system. Automatiserade system. Stadier av skapandet";
- RD 50-682-89 ”Metodologiska instruktioner. Informationsteknologi. En uppsättning standarder och riktlinjer för automatiserade system. Allmänna bestämmelser";
- RD 50-680-88 ”Metodologiska instruktioner. Automatiserade system. Grundläggande bestämmelser";
- RD 50-34.698-90 ”Metodologiska instruktioner. Informationsteknologi. En uppsättning standarder och riktlinjer för automatiserade system. Automatiserade system. Krav på innehållet i dokument."
1.7. Systemskapande sekvens
För system som skapats i flera iterationer bör den förklarande anmärkningen ange mängden arbete för varje iteration. Separat är det nödvändigt att lyfta fram det planerade arbetet för denna iteration.
Till exempel: ”Genomförandet av Corporate Information Portal-projektet planeras i två steg.
Det första steget av instrumenteringen inkluderar organisationen av gemensamt arbete för företagsanställda på grund av införandet av sådana förmågor som:
- Direktmeddelande;
- Organisation av konferensen;
- Skicka/ta emot e-post;
- Samordning av dokument med hjälp av systemet.”
2 Beskrivning av aktivitetsprocessen
Detta avsnitt av den förklarande anmärkningen bör återspegla de processer och funktioner som automatiseras av systemet genom hela affärsprocessen.
För att illustrera materialet i den förklarande noten är det tillåtet att använda UML, ARIS eller IDF0 notationer, samt schematiska bilder skapade med standardapplikationer (Visio).
För att förstå sambandet mellan automatiserade och icke-automatiserade funktioner i det förklarande anmärkningsdokumentet är det nödvändigt att tydligt skilja mellan användaråtgärder och systemåtgärder.
Till exempel: "1. Användaren skapar ett dokument
- Användaren initierar processen för att skicka in ett dokument för godkännande
- Systemet ändrar dokumentets status till "för godkännande". »
- Huvudsakliga tekniska lösningar
2.1. Beslut om strukturen på systemet och delsystemen.
Detta avsnitt av dokumentet förklarande anmärkning ger lösningar på den funktionella strukturen för systemet och dess delsystem.
2.2. Medel och metoder för interaktion mellan systemkomponenter. Sammankoppling med externa system
I det här avsnittet av det förklarande anmärkningsdokumentet är det nödvändigt att ange en lista över system som den skapade produkten måste interagera med. När man beskriver samverkan mellan systemkomponenter i den förklarande anmärkningen är det nödvändigt att ange formatet för datautbyte.
Till exempel: "Som en del av samspelet mellan instrumentering och externa system används följande tekniker:
- "Företagsredovisning" - filutbyte i det etablerade XML / Excel-formatet."
2.3. Beslut om driftsätt
Det här avsnittet av den förklarande anmärkningen innehåller en lista och beskrivning av systemets driftslägen. Vanligtvis särskiljs följande lägen: normalläge, testdriftläge, serviceläge. Den förklarande noten ska ge en beskrivning av både själva ordningen och de fall då den införs.
2.4. Beslut om antal, kvalifikationer och funktioner för NPP-personal
Detta avsnitt av dokumentet förklarande anmärkning reglerar verksamheten för underhåll och funktionell personal. Den förklarande noten ska ange vilken kategori av anställda som tillhör en viss typ av personal och beskriva deras funktioner inom ramen för systemet.
Till exempel: "Portaladministratören ansvarar för:
- databas- och mjukvaruintegritet;
- förebyggande åtgärder för att säkerställa datasäkerhet;
- fördelning av åtkomsträttigheter och registrering av användare i systemet. »
2.5. Säkerställande av konsumentegenskaperna hos systemet som anges i de tekniska specifikationerna
Detta avsnitt av den förklarande anmärkningen är skapad på grundval av de produktkvalitetskrav som anges i de tekniska specifikationerna. Här är det nödvändigt att beskriva parametern genom vilken systemets kvalitet bestäms. Den förklarande noten anger också de lösningar med vilka denna egenskap uppnåddes i systemet.
Till exempel: "Feltolerans och funktionalitet för insäkerställs genom användning av industriella programvaruplattformar IBM WebSphere Portal, Enterprise Oracle 10g."
2.6. Sammansättning av funktioner och uppsättning av uppgifter som implementeras av systemet
Det här avsnittet i det förklarande anmärkningsdokumentet innehåller en lista över uppgifter som systemet löser. I den förklarande noten kan funktioner och en uppsättning uppgifter presenteras i form av en onumrerad lista.
2.7. Beslut om en uppsättning teknisk utrustning och dess placering på platsen
Detta avsnitt av den förklarande anmärkningen innehåller beslut om systemets tekniska arkitektur och krav på den uppsättning tekniska hjälpmedel som är nödvändiga för att säkerställa att det fungerar korrekt.
Det rekommenderas att ställa kraven på en uppsättning tekniska medel i den förklarande anmärkningen i form av en tabell.
Till exempel: "
|
Utrustning |
Tekniska specifikationer |
|
Databasserver |
|
|
Rackmonterad version |
Inte mer än 4U |
|
Processorarkitektur |
RISC (64-bitars) |
|
CPU-frekvens |
minst 1,5 GHz |
|
CPU-cache |
Minst 1MB |
|
OS |
Windows 2003 SP2 |
|
Möjligt antal installerade processorer |
Minst 4 |
|
Antal installerade processorer |
|
|
Möjlig RAM-kapacitet |
32 GB med ECC |
|
RAM-kapacitet |
Minst 8 GB |
|
Tillgänglighet av gränssnitt |
10/100/1000 Base-T Ethernet-gränssnitt 2 st.; |
|
Grafikkort: |
Minst 8MB. |
|
Möjligt antal installerade hårddiskar |
Minst 4 |
|
Antal installerade diskar |
|
|
Läsare |
|
|
Strömförsörjning |
Inmatningsparametrar: |
»
När du beskriver placeringen av objekt av ett komplex av tekniska medel i den förklarande anmärkningen, är det nödvändigt att vägledas av kraven i SNiP 11-2-80 för byggnader i kategori "B".
2.8. Volym, sammansättning, organisationsmetoder, sekvens av informationsbehandling
Informationsstöd inkluderar informationsstöd i maskin och extramaskin. Det interna informationsstödet tillhandahålls av databasen (DB), in- och utdokument som kommer från externa system.
Informationsbasen utanför maskinen bildas av data som finns i pappersdokument. När man utvecklar automatiserade system används ofta endast en informationsbas i maskinen, så huvudvikten i dokumentet med förklarande anmärkning bör ligga på innehållet i detta avsnitt.
När den interna informationsbasen beskrivs i den förklarande anmärkningen är det nödvändigt att ange in- och utdatadokument och meddelanden för alla delsystem och externa system.
Till exempel: "Inmatningsinformationen för det elektroniska dokumenthanteringsundersystemet är:
- elektroniska versioner av produktionsarbetsflödesdokument;
- elektronisk digital signatur;
Utdatainformationen för det elektroniska dokumenthanteringsundersystemet är:
- dokumentera livscykelhistoriklogg;
- logg för dokumentgodkännandehistorik;
- fil av den elektroniska versionen av dokumentet i RTF-format. »
2.9. Sammansättning av mjukvaruprodukter, driftsspråk, algoritmer för procedurer och operationer och metoder för deras implementering
Det här avsnittet av den förklarande anmärkningen bör tillhandahålla teknik och medel för att utveckla systemet.
Till exempel:
«
- Databasserver: Oracle 10g
- Portal: Websphere Portal Extend v6.0.
- Affärsmodellering: ARIS
»
3 Åtgärder för att förbereda automationsobjektet för driftsättning av systemet
Detta avsnitt av den förklarande anmärkningen beskriver följande aktiviteter:
- åtgärder för att bringa information i en form som är lämplig för datorbehandling;
- aktiviteter för utbildning och testning av personalens kvalifikationer;
- åtgärder för att skapa nödvändiga enheter och arbetstillfällen;
- åtgärder för att ändra automationsobjektet;
- andra aktiviteter baserade på de specifika egenskaperna hos de system som skapas
27.10.2016 09:57:23
Den här artikeln diskuterar det tekniska projektstadiet, som relaterar till ett av stegen i informationssäkerhetssystemets (ISS) livscykel - "designstadiet", som, i enlighet med den inhemska standarden GOST 34.601-90, omedelbart följer utvecklingen av villkoren för informationssäkerhetssystemet.
1. Utveckling av teknisk designdokumentation för NIB
Livscykeln för ett informationssäkerhetssystem (nedan kallat ISS) består i allmänhet av följande steg:
- analys av krav på informationssäkerhetssystem;
- design;
- genomförande;
- genomförande;
- utnyttjande.
Den här artikeln diskuterar skedet av det tekniska projektet, som hör till "design" -stadiet och, i enlighet med den inhemska standarden GOST 34.601-90, följer omedelbart utvecklingen av villkoren för informationssäkerhetssystemet.
1.1. Varför utveckla dokumentation för NIB överhuvudtaget?
Svaret på denna fråga bör övervägas i två plan: i planet för ägaren av informationsresurser (för vars skydd ett informationssäkerhetssystem skapas) och i planet för den direkta utvecklaren av informationssäkerhetssystemet.
För ägaren av informationsresurser är det viktigt att få resultatet i form av ett fungerande informationssäkerhetssystem som minskar riskerna för att äventyra begränsad åtkomstinformation i organisationen. Det tekniska projektet i detta fall tjänar till att utveckla de grundläggande principerna för det framtida systemet, nämligen, det inkluderar en beskrivning av hur ISS kommer att byggas och fungera, vilka åtgärder och medel som säkerställer informationsskydd, vilka möjligheter finns att utveckla och förbättra systemet. Efter avslutad utveckling av ett tekniskt projekt för ett informationssäkerhetssystem får kunden en omfattande uppsättning dokumentation för informationssäkerhetssystemet, som beskriver alla tekniska nyanser av det framtida systemet.
För den direkta utföraren, på det tekniska projektstadiet, är det nödvändigt att fastställa den mest lämpliga ISS-arkitekturen, samt göra rätt val av åtgärder och medel för att skydda information i organisationen. Det är också viktigt att säkerställa att systemets egenskaper och egenskaper överensstämmer med de tekniska specifikationerna, eller att motivera, med kundens medverkan och samtycke, justeringen av de krav som anges i de tekniska specifikationerna för att öka effektiviteten av systemet som skapas.
Således, som ett resultat av utvecklingen av teknisk designdokumentation, kommer kunden att ha svar på följande frågor:
- vad är den allmänna arkitekturen för NIB;
- vilka åtgärder och medel kommer att användas för att genomföra krav på informationsskydd;
- hur NIB kommer att fungera;
- vilka förändringar i organisationen som är nödvändiga för att öka informationssäkerhetsnivån kommer att följa som ett resultat av implementeringen av ISS;
- kommer Kundens krav (affärskrav) och kraven i regulatoriska rättsakter på informationssäkerhetsområdet att beaktas vid utveckling och implementering av informationssäkerhetssystemet och i så fall hur.
I processen med att utveckla teknisk projektdokumentation kommer entreprenören att få följande resultat:
- en grund för övergången till nästa steg för att bygga en ISS, nämligen stadierna för arbetsdokumentation och implementering;
- förståelse för arkitekturen, teknologierna och verktygen som används, ordningen för att bygga systemet;
- hur Kundens krav (affärskrav) och regulatoriska dokument inom området informationssäkerhet implementeras för systemet.
1.2. Genomgång av tillvägagångssätt för att utveckla teknisk projektdokumentation
Utvecklingen av ett tekniskt projekt för ett informationssäkerhetssystem sker oftast utifrån relevanta standarder och vägledande dokument. Dessutom är deras användning obligatorisk för statliga institutioner, men rekommenderas för kommersiella. I praktiken använder kommersiella organisationer också statliga standarder när de utvecklar teknisk projektdokumentation av följande skäl:
- ett upprepat testat tillvägagångssätt för att skapa informationssystem;
- genomtänkt struktur och innehåll i dokument;
- en uppsättning dokument tillräckliga för utveckling och beskrivning av nästan alla system.
För att utveckla dokumentation för den tekniska projektfasen (TP) av NIB, används statliga standarder och vägledningsdokument för 34-serien:
- GOST 34.201-89 "Typer, fullständighet och beteckning av dokument när du skapar automatiserade system." Denna standard specificerar:
- typer och namn på dokument på TP-stadiet;
- fullständighet av dokumentation;
- accepterade dokumentbeteckningar;
- regler för att utse informationssystem och deras delar.
- GOST 34.003-90 "Villkor och definitioner";
- GOST 34.601-90 "Automatiska system. Stadier av skapandet." Standarden specificerar:
- förteckning över stadier av arbete som utförts på det tekniska stadiet;
- detaljerad beskrivning av det arbete som utförts på det tekniska stadiet;
- förteckning över organisationer som deltar i skapandet av ISS;
- RD 50-34.698-90 "Automatiska system. Krav på innehållet i dokument." Detta vägledningsdokument anger kraven på innehållet i dokument på TP-stadiet.
Det är viktigt att förstå att enligt 34-serien av standarder är teknisk design ett steg för att skapa ett system, och inte bara en uppsättning dokument. I praktiken kombineras detta steg ofta med det preliminära designskedet, vilket tjänar till att utveckla flera preliminära lösningar och motivera den mest lämpliga. En sådan kombination tillåts av standarden, men det måste beaktas att detta inte förnekar behovet av att uppnå målen för det preliminära konstruktionsstadiet.
Oftast utvecklas det preliminära konstruktionsstadiet i det fall då kraven i de tekniska specifikationerna för systemet kan implementeras på flera fundamentalt olika sätt, och även när det bland dessa metoder inte finns några klart föredragna.
Det är dock värt att notera att ovanstående standarder är för generella och implementerar huvudsakligen design och allmänna strukturella funktioner. För att utveckla den materiella delen av de tekniska projektstadiets dokument använder designers information från följande källor:
Aktuella regulatoriska dokument (RLA) som reglerar kraven på skydd av viss information med begränsad åtkomst. Dessa föreskrifter ställer krav på åtgärder för att skydda information i informationssystem, beskriver nyanserna av att genomföra dessa åtgärder och ytterligare förstärkningsåtgärder. Bland de nuvarande rättsakterna finns följande:
- Beslut från FSTEC i Ryssland av den 18 februari 2013 nr 21 "Om godkännande av sammansättningen och innehållet av organisatoriska och tekniska åtgärder för att säkerställa säkerheten för personuppgifter under deras behandling i informationssystem för personuppgifter";
- Order från Rysslands FSTEC av den 11 februari 2013 nr 17 "Om godkännande av krav för skydd av information som inte utgör en statshemlighet som finns i statliga informationssystem"
- Order från FSTEC i Ryssland av den 14 mars 2014 nr 31 ”Om godkännande av krav för att säkerställa informationssäkerhet i automatiserade styrsystem för produktion och tekniska processer vid kritiska anläggningar, potentiellt farliga anläggningar, samt anläggningar som utgör en ökad fara för människors liv och hälsa och för den naturliga miljön;
- metoddokument "Åtgärder för att skydda information i statliga informationssystem", godkänd av Rysslands FSTEC den 11 februari 2014.
Kraven på skydd av begränsad åtkomstinformation och listor över skyddsåtgärder varierar för informationssystem av olika säkerhetsnivåer/klasser. Om informationen i en organisation inte är skyddad i enlighet med Ryska federationens federala lagar (till exempel officiella hemligheter), kan ägaren av denna information använda de metoder som föreslås i dessa lagar för att bygga ett företagsinformationssäkerhetssystem .
Ryska och utländska standarder som beskriver olika tillvägagångssätt för sätt att implementera stadierna i livscykeln för att bygga en ISS, inklusive det tekniska designstadiet:
- en serie statliga standarder GOST R ISO/IEC 2700X, identiska med internationella standarder ISO/IEC 2700X. Dessa standarder beskriver PDCA-processen (Plan, Do, Check, Act) för implementeringen av livscykeln för ett ledningssystem för informationssäkerhet, som är en integrerad del av informationssäkerhetssystemet;
- NIST SP 800-64 är en US National Institute of Standards and Technology-standard som beskriver livscykeln för informationssystemutveckling;
- NIST SP 800-37 är en US National Institute of Standards and Technology-standard som ger vägledning för att integrera riskhantering i informationssystemens utvecklingslivscykel.
Tillverkarens driftdokumentation för informationssäkerhetsutrustning och hjälputrustning. Dessa dokument innehåller omfattande teknisk information om de verktyg som används vid konstruktionen av informationssäkerhetssystem, inklusive de som är direkt relaterade till implementeringen av informationssäkerhetsåtgärder som inte är relaterade till till exempel servrar, datalagringssystem, virtualiseringsverktyg och andra. Den allmänna uppsättningen av sådana dokument varierar från tillverkare till tillverkare och beror bland annat på implementeringen av ett visst verktyg (hårdvara/mjukvara). Nedan finns en standarduppsättning operativ dokumentation för informationssäkerhetsverktyg som används för att utveckla dokument i det tekniska projektstadiet:
- allmän beskrivning (datablad);
- administratörsguide (kan inkludera lokal och centraliserad hanteringsguide);
- Användarguide;
- Snabbinstallations- och distributionsguide (för skyddssystem för hårdvaruinformation);
- bruksanvisning;
- Vägledning för utplacering i virtuell infrastruktur (förtem);
Allmän information om befintliga SIS-arkitekturer, bästa praxis när det gäller att bygga ISS, riktlinjer för säkerhet och integration av informationssäkerhetssystem med varandra, information om problem i samspelet mellan vissa informationssäkerhetssystem. Exempel på sådan information kan inkludera följande dokument:
- guider om arkitekturer för informationssäkerhetssystem, till exempel: Defence-in-Deepth, Cisco SAFE, Check Point SDP och andra;
- bästa praxis inom området informationssäkerhet, till exempel, tillgängliga på dessa länkar (https://www.sans.org/reading-room/whitepapers/bestprac/, http://csrc.nist.gov/publications/nistpubs/ 800-14 /800-14.pdf). Dessa dokument presenteras oftast på engelska, men alla ryska tillverkare av skyddsutrustning har sina egna bästa praxis för att implementera säkerhetsåtgärder och kan tillhandahålla dem på begäran;
- säkerhetsriktlinjer för informationssäkerhet och driftmiljöer. Ett exempel är avsnittet "Säkerhet" på den officiella Microsoft-portalen (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).
1.3. Utveckling av ett tekniskt projekt för NIB i enlighet med GOST 34
Utvecklingen av dokument på det tekniska projektstadiet för ISS utförs oftast av integratörer av dessa tjänster och implementeras huvudsakligen i enlighet med följande plan:
Fastställande av listan över dokument som ska utvecklas - denna information anges i de tekniska specifikationerna för ISS. I vissa fall kan dokumentutvecklaren, i samförstånd med kunden, utöka eller minska denna lista, om denna möjlighet finns med i de tekniska specifikationerna;
Utveckling av dokumentmallar för TP-stadiet - strukturen används i enlighet med RD 50-34.698-90 och GOST 2.106 (för vissa dokument), formaterad i enlighet med GOST 2.105-95;
Utveckling av den materiella delen av dokument. Krav på systemet fastställs i tekniska specifikationer för NIB. I enlighet med dessa krav fastställs en lista över tekniska och organisatoriska skyddsåtgärder som krävs för implementering i systemet. Skyddsåtgärder kan fastställas i relevanta regelverk (beroende på vilken typ av information som skyddas), företagsstandarder och informationssäkerhetspolicyer, samt baserat på förekomsten av aktuella säkerhetshot som identifierats under utvecklingen av organisationens hotmodell. Baserat på listan över skyddsåtgärder väljer IS-utvecklaren lämpliga informationssäkerhetsverktyg och utvecklar informationssäkerhetssystemets funktionella struktur (undersystem, komponenter). Vidare beskriver de tekniska designdokumenten det praktiska genomförandet av skyddsåtgärder utifrån valt säkerhetsskydd eller organisatoriska åtgärder i organisationens infrastruktur.
Samordning av den utvecklade dokumentationen och de lösningar som presenteras i den med kunden av systemet.
När man utvecklar teknisk projektdokumentation är det oftast inte nödvändigt att utveckla en komplett lista över dokument som specificeras i GOST 34.201-89, eftersom denna standard är föråldrad och vissa av dokumenten inte tar hänsyn till utvecklingstrender och teknologier för moderna informationssystem . Den minsta uppsättning dokument som krävs för att beskriva informationssäkerhetssystemet är följande:
- teknisk designförklaring;
- förklarande not till det tekniska projektet;
- funktionell strukturdiagram;
- strukturdiagram av ett komplex av tekniska medel;
- organisationsstrukturdiagram;
- lista över köpta varor.
På kundens begäran eller i det fall att ISS är ett komplext flerkomponentsystem, kan följande dokument också utvecklas ytterligare:
- automatiseringsschema;
- beskrivning av automatiserade funktioner;
- beskrivning av systemets informationsstöd;
- beskrivning av komplexet av tekniska medel;
- mjukvarubeskrivning;
- beskrivning av organisationsstrukturen.
Det bör noteras att GOST 34.201-89 möjliggör en utökning av dokumentutbudet på TP-stadiet, men i praktiken finns det mer än tillräckligt med dessa dokument.
Tekniskt designblad
Beteckning: TP.
Detta dokument är avsett att beskriva listan över dokument som utvecklats i det tekniska projektstadiet. Antalet sidor i vart och ett av de utvecklade dokumenten anges också.
Förklarande notering till det tekniska projektet
Beteckning: P2.
Detta dokument är det viktigaste för TP-stadiet och innehåller en beskrivning av ISS-arkitekturen, tekniska och organisatoriska åtgärder, ISS-funktioner, mjuk- och hårdvarusystem och annat. Enligt standarden består den av fyra huvudsektioner:
- allmänna bestämmelser;
- beskrivning av aktivitetsprocessen;
- grundläggande tekniska lösningar;
- åtgärder för att förbereda automationsobjektet för att ta systemet i drift.
Funktionsstrukturdiagram
Beteckning: C2.
Detta dokument beskriver den logiska strukturen hos ISS, nämligen:
- logiska delsystem och komponenter som ingår i ISS;
- funktioner implementerade med hjälp av delsystem och komponenter;
- informationskopplingar mellan logiska delar av SIS och typer av meddelanden under utbyte.
Strukturdiagram av ett komplex av tekniska medel
Beteckning: C1.
Detta dokument innehåller en beskrivning av följande delar av ISS:
- tekniska medel som en del av logiska delsystem och komponenter i informationssäkerhetssystem;
- kommunikationskanaler och utbyte mellan tekniska medel som indikerar transportprotokoll.
Organisationsschema
Beteckning: C0.
Detta dokument beskriver organisationens organisationsstruktur i termer av ISS-ledning, nämligen:
- avdelningar och ansvariga personer i organisationen som är involverade i driften av ISS;
- utförda funktioner och kopplingar mellan avdelningar och ansvariga personer.
Lista över köpta varor
Benämning: VP.
Detta dokument innehåller en lista över all mjukvara och hårdvara, samt licenser som används för att skapa ett informationssäkerhetssystem. Utvecklad i enlighet med GOST 2.106.
Notera. Det är också värt att notera här att vägledningsdokumentet RD 50-34.698-90 tillåter tillägg av vilket dokument som helst på TP-stadiet (inkluderandet av avsnitt och information som skiljer sig från de föreslagna), sammanslagning av avsnitt, såväl som uteslutning av vissa enskilda avsnitt. Beslut om detta fattas av utvecklaren av dokument på TP-stadiet och baseras på funktionerna i den skapade NIB.
1.4. Regler för dokumentationsutveckling
- strukturell överensstämmelse med statliga standarder;
- strikt överensstämmelse med kraven i de tekniska specifikationerna för systemet;
- tillämpning av dokumentmallar (användning av enhetliga stilar, uppmärkning, fält, etc.);
- ett individuellt förhållningssätt och samtidig användning av befintliga utvecklingar när du fyller i delar av dokument.
Förklarande notering till det tekniska projektet:
- dokumentutveckling utförs i Microsoft Word efter att utvecklingen är klar, det rekommenderas att konvertera dokumentet till PDF-format för bekvämlighet;
- termer och förkortningar måste vara konsekventa i alla delar av dokumentet;
- Det rekommenderas att undvika uppenbara upprepningar och onödig ökning av dokumentets längd;
- tekniska lösningar måste beskrivas så detaljerat som möjligt, med angivande av:
- arkitektur och teknik som används;
- plats för mjukvara och hårdvara i organisationens infrastruktur;
- informationssäkerhetsverktyg som används med en beskrivning av deras egenskaper, implementerade funktioner, information om certifiering;
- grundläggande inställningar för informationssäkerhetsverktyg i form av skyddsmekanismer, adressering, routing, interaktion med relaterade system och verktyg, etc.;
- kontroller, metoder för åtkomst till dem och platser för deras installation;
- diagram (strukturella, funktionella, organisatoriska):
- utveckla diagram i Microsoft Visio;
- efter utveckling, infoga diagram i dokumentet med hjälp av dialogrutan "Klistra in special" i EMF-format (Windows-metafil);
- utveckla separata diagram för systemet, delsystemen och komponenterna i delsystemen;
- göra utformningen av diagrammen enhetlig, med samma element, förkortningar, ikoner, textstilar etc.
1.5. Resurser som hjälper dig att utveckla dokumentation
Internet innehåller en enorm mängd information som i en eller annan grad kan hjälpa till vid utvecklingen av teknisk projektdokumentation. Viktiga resurser presenteras i tabellen nedan.
Tabell. SIS tekniska designresurser
| Resurstyp | Information | Exempel på resurser |
|---|---|---|
| Internetportaler för federala verkställande myndigheter | Reglerande dokument, metodologiska rekommendationer, register (inklusive certifierade informationssäkerhetssystem), databaser (inklusive databaser över sårbarheter och hot) | fstec.ru clsz.fsb.ru minsvyaz.ru/ru/ |
| Internetportaler för tillverkare av informationssäkerhet, distributörer av lösningar för informationssäkerhet | Beskrivning av informationssäkerhetslösningar, driftdokumentation för informationssäkerhet, analysmaterial och artiklar | securitycode.ru kaspersky.ru/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html checkpoint.com altx-soft.ru |
| Specialiserade informationssäkerhetsresurser | Jämförelse av informationssäkerhetslösningar, recensionsartiklar om informationssäkerhetslösningar, tester av informationssäkerhetslösningar, djupgående teknisk information om informationssäkerhetsteknologier | anti-malware.ru bis-expert.ru safe.cnews.ru securitylab.ru/ vulners.com/ csrc.nist.gov itsecurity.com owasp.org sans.org |
1.6. Exempel på tekniska projektstadsdokument
För att förstå kraven på innehållet i dokumentationen på TP-stadiet finns nedan exempel på att fylla i huvuddokumenten (dokumentavsnitt).
1.6.1. Förklarande notering till det tekniska projektet
Den förklarande anteckningen är ett ganska omfattande dokument, så här är ett exempel på innehållet i avsnittet "Grundläggande tekniska lösningar" i en del av ett av SIS-delsystemen - delsystemet för säkerhetsanalys.
ISS delsystem för säkerhetsanalys
Delsystemets struktur och sammansättning
Undersystemet för säkerhetsanalys (SAS) är utformat för att systematiskt övervaka säkerhetsstatusen för automatiserade arbetsstationer (AWS) för personal och organisationsservrar. Grunden för ESD är mjukvaruverktyget "Test" som produceras av Information Security LLC. SZI Test är certifierat av FSTEC i Ryssland för överensstämmelse med tekniska specifikationer (TU) för informationssäkerhet och för den fjärde nivån av kontroll över frånvaron av odeklarerade förmågor.
ESD innehåller följande komponenter:
- Testserverhanteringsserver;
- Testa konsolens hanteringskonsol.
En beskrivning av delsystemets komponenter presenteras i tabellen nedan.
Tabell. ESD-komponenter
| Komponent | Beskrivning |
|---|---|
| Testa Server Management Server | Tillhandahåller hantering av skanningsuppgifter, utför funktioner för att övervaka säkerhetsstatusen för arbetsstationen och organisationens servrar. Skanningsparametrar ställs in av informationssäkerhetsadministratören på testserverns hanteringsserver. All insamlad information om skanningsresultat lagras i testserverns serverlagring baserat på Microsoft SQL Server 2008 databashanteringssystem |
| Testa konsolen | Tillåter informationssäkerhetsadministratören att ansluta till testservern, visa och ändra dess konfiguration, skapa och ändra skanningsuppgifter, se information om uppgifternas framsteg och resultaten av deras exekvering. Hanteringskonsolen är installerad på informationssäkerhetsadministratörens arbetsstation |
Tillhandahålla funktioner
ESD tillhandahåller följande funktioner:
- implementering av proaktivt skydd av organisationens arbetsstationer och servrar genom att övervaka informationssäkerhetens status;
- automatisering av processer för att övervaka efterlevnaden av interna policyer och vissa säkerhetsstandarder;
- minskning av kostnader för revision och säkerhetskontroll, utarbetande av statusrapporter;
- automatisering av resursinventeringsprocesser, sårbarhetshantering, övervakning av efterlevnad av säkerhetspolicyer och förändringskontroll.
Lösning för ett komplex av hårdvara och mjukvara
Listan över använd ESD-mjukvara och hårdvara finns i tabellen nedan.
Tabell. ESD mjukvara och hårdvara
ESD-kontrollserver
Tekniska medel
Den fysiska servern som används som ESD-hanteringsserver måste uppfylla de tekniska kraven för programvaran och operativsystemet som är installerat på den, som anges i tabellen nedan.
Tabell. OS- och mjukvarukrav för ESD-kontrollservern
| programvara | Tekniska krav | |
|---|---|---|
| CPU | RAM, MB | |
| Microsoft Windows Server 2008 R2 | 3000 MHz, 4 kärnor | 8192 |
| Microsoft SQL Server 2008 R2 | ||
| Testa serverprogramvara | ||
programvara
Hanteringsserver OS
Windows 2008 R2 OS installeras på hanteringsservern på normalt sätt från en startdistribution.
Hanteringsserverns OS hanteras både lokalt från konsolen och via RDP-protokollet.
Management server DBMS
Microsoft SQL Server 2008 R2-databasen installeras under ett konto med lokala administratörsrättigheter med hjälp av standardinstallationsguiden från distributionspaketet som tillhandahålls av produktutvecklaren.
Testa serverprogramvara
Testserverprogramvaran installeras på hanteringsservern med hjälp av standardinstallationsguiden.
Den första installationen och efterföljande hanteringen av Test Server-programvaran i normalt läge utförs med hjälp av testkonsolens hanteringskonsol som är installerad på IS-administratörens arbetsstation.
IS-administratörens arbetsstation
Tekniska medel
Den befintliga arbetsstationen för en anställd på organisationens avdelning som ansvarar för att tillhandahålla informationssäkerhet, som kör Microsoft Windows-familjen av operativsystem, används som en plattform.
De tekniska medlen för informationssäkerhetsadministratörens arbetsstation måste ha följande hårdvarukonfigurationsegenskaper (åtminstone rekommenderas):
- CPU 2 GHz;
- RAM 4 GB;
- Hårddisk 80 GB.
programvara
Testa konsolprogramvara
Informationssäkerhetsadministratörens arbetsstation på vilken programvaran Test Console är installerad måste fungera under något av följande operativsystem:
- Microsoft Windows 7, 32- och 64-bitars;
- Microsoft Windows 8/8.1, 32- och 64-bitars.
Dessutom måste Microsoft .NET Framework version 3.5 SP1 eller högre installeras på informationssäkerhetsadministratörens arbetsstation för att programvaran för hanteringskonsolen för Test Console ska fungera korrekt, och säkerhetsinställningarna för det använda operativsystemet måste tillåta åtkomst till testservern.
Installation av Test Console-programvara på ESD-administratörens arbetsstation utförs med hjälp av standardinstallationsguiden för Test Server-programvaran med det valda alternativet för att installera Test Console-hanteringskonsolen och andra standardinställningar.
Interaktion med angränsande system
För ESD, angränsande är:
- brandväggsundersystemverktyg;
- Active Directory-katalogtjänster;
- Arbetsstation och servrar i organisationen.
För att säkerställa nätverksinteraktion med angränsande system och direkt mellan ESD-komponenterna själva måste passagen av nödvändig nätverkstrafik organiseras.
För att säkerställa möjligheten att ta emot uppdateringar av kunskapsbasen och testprogramvarumoduler för testserverskannern, är det nödvändigt att ge åtkomst till update.com-webbservern för företaget Information Security LLC via port 443/tcp.
Vid skanning i PenTest-läge sker interaktionen mellan testserverns scanner och arbetsstationen och organisationens servrar via IP-protokollet. Vid skanning i gransknings- och efterlevnadslägen används fjärrhanteringsprotokoll WMI, RPC, etc. För att skanna värdar på enheter med brandväggsfunktioner måste du tillåta anslutningar från testservern till de skannade värdarna via IP. Följaktligen måste testservern förses med åtkomst till nätverksportarna för de skannade värdarna med hjälp av lämpliga fjärrkontrollprotokoll.
Eftersom ESD, vid skanning i revisions- och efterlevnadslägen, använder fjärrkontrollprotokoll för analys, måste skanningsverktyg för testprogram genomgå autentisering och auktorisering på den skannade noden. I ESD, för att skanna noder i revisions- och efterlevnadslägena, används konton med administrativa privilegier i varje typ av nod (arbetsstation, server, applikationssystem, DBMS, etc.).
Alla registrerade informationssäkerhetshändelser lagras i Microsoft SQL DBMS. Dessa händelser kan skickas till undersystemet för övervakning av informationssäkerhetshändelser med hjälp av speciella kontakter.
Drift och underhåll av ESD
Subsystemanvändare
Drift och underhåll av ESD-verktyg utförs av anställda i organisationen med den funktionella rollen som "IS-administratör".
En informationssäkerhetsadministratör definieras som en specialist vars uppgifter inkluderar:
- bestämma skanningsparametrarna för organisationens noder;
- ställa in och starta skanningsuppgifter;
- analys av skanningsresultat för närvaron av sårbarheter i informationssystem, konfigurationsfel eller bristande överensstämmelse med tekniska standarder;
- kontroll över eliminering av sårbarheter;
- bildande av standarder och krav som gäller för att säkerställa säkerheten för organisationens arbetsstationer och servrar.
Systemdriftlägen
Normalt driftläge
I normal drift fungerar ESD 24 timmar om dygnet, 7 dagar i veckan.
Vid normal drift utför informationssäkerhetsadministratören:
- schemalagd och oplanerad skanning av noder;
- generera rapporter;
- uppdatering av kunskapsbaser och testprogramvarumoduler.
Akut operation
Om säkerhetsutrustningens funktion störs, störs delsystemets funktion. Underlåtenhet att använda ESD-utrustning påverkar inte funktionen hos organisationens automatiserade arbetsstationer och servrar.
1.6.2. Funktionsstrukturdiagram
Funktionsdiagram kan utvecklas för hela informationssäkerhetssystemet eller för en del av det, till exempel ett delsystem eller en komponent.
Ett exempel på ett allmänt funktionsdiagram för en ISS visas i figuren nedan.
1.6.3. Strukturdiagram av ett komplex av tekniska medel
Blockschemat för ett komplex av tekniska medel kan utvecklas både för hela ISS och för dess delar - delsystem och komponenter. Möjligheten att utveckla diagram för delar av informationssäkerhetssystemet bestäms av systemets skala och den nödvändiga detaljen.
Ett exempel på ett blockschema över ett komplex av tekniska informations- och säkerhetssystem presenteras i figuren nedan.
Ryska federationens ministerium för ekonomisk utveckling och handel
JAG GODKÄNDE |
||||||||||||||||||||||||||||||||||||||
|
Statligt kontrakt nr 000-05-07 daterat den 29 oktober 2007, ingåtts mellan Ryska federationens ministerium för ekonomisk utveckling och handel och CJSC PROGNOZ, för att utföra arbete på ämnet "Utveckling av en automatiserad modul för federal övervakning av socioekonomin - Ekonomisk utveckling av ryska federationens ingående enheter inom ramen för att skapa ett enhetligt informationssystem för att övervaka nyckelindikatorer för den socioekonomiska utvecklingen i Ryska federationen och övervaka hur statliga organ presterar för att uppnå dem." Vid utvecklingen av detta dokument användes vägledande dokument om standardisering GOST RD 50-34.698-90. 1. Allmänna bestämmelser.. 5 1.1. Systemets fullständiga namn... 5 1.2. Dokument på grundval av vilka konstruktionen utförs.. 5 1.3. Etapper och deadlines.. 5 1.4. Mål och syfte.. 7 1.5. Överensstämmelse med designlösningar med säkerhetskrav .. 8 1.6. Reglerande och tekniska dokument... 9 2. Beskrivning av aktivitetsprocessen.. 10 2.1. Lista över uppgifter... 10 2.2. Huvudfunktioner som utförs av modulen... 11 3. Grundläggande tekniska lösningar.. 13 3.1. Modulstruktur, lista över delsystem... 13 3.1.1. Delsystem för centraliserad datalagring. 14 3.1.2. Gränssnittskomponent. 15 3.1.3. Adapterprogramvarukomponenter. 16 3.6.3. Graden av anpassningsförmåga till avvikelser i parametrarna för automationsobjektet. 26 3.6.4. Acceptabla gränser för modernisering och utveckling av systemet.. 26 3.6.5. Tillförlitlighetskrav. 27 3.6.6. Säkerhetskrav. 27 3.6.7. Krav på ergonomi och teknisk estetik. 28
|
- allmänna bestämmelser;
- beskrivning av verksamheten;
- grundläggande tekniska lösningar;
- händelser på
[från klausul 2.2.1 RD 50-34.698-90]
Allmänna bestämmelser
I avsnittet "Allmänna bestämmelser" tillhandahåller de:
- design och namn på dokument, deras nummer och datum, på grundval av vilka NPP-konstruktionen utförs;
- förteckning över de som är involverade i systemet, tidsfrister;
- mål, syfte och AS;
- bekräftelse på överensstämmelse med designlösningar med nuvarande standarder och brand- och explosionssäkerhet, etc.;
- information om de som används i designen;
- information om bästa praxis som används vid utvecklingen av projektet;
- ordningen för skapandet av systemet och volymen för varje.
[från klausul 2.2.2 RD 50-34.698-90]
Beskrivning av aktivitetsprocessen
I avsnittet "Beskrivning av aktivitetsprocessen" återspeglar de sammansättningen av procedurerna (), med hänsyn till kopplingen och kompatibiliteten mellan processer och aktiviteter, bildar organisationen av arbetet i anläggningen [från klausul 2.2.3 RD 50-34.698 -90]
Huvudsakliga tekniska lösningar
I avsnittet "Huvudsakliga tekniska lösningar" ger de:
- beslut om systemets struktur, medel och metoder för kommunikation för informationsutbyte mellan delsystem;
- beslut om sammankoppling av systemet med relaterade system och dess stöd;
- lösningar för systemdrift;
- beslut om antal, kvalifikationer och funktioner, funktionssätt, interaktionsordning;
- information om att säkerställa de specificerade konsumentegenskaperna hos systemet (delsystemen) som definierar det;
- sammansättning av uppgiftskomplex () implementerade av systemet (delsystem);
- beslut om komplexet, dess placering på;
- beslut om sammansättning av information, volym, metoder, typer av datorer och dokument, sekvens och andra komponenter;
- beslut om sammansättning, språk för aktiviteter, förfaranden och operationer och metoder för deras genomförande.
Avsnittet tillhandahåller illustrationer av andra dokument som kan inkluderas i enlighet med GOST 34.201 [från klausul 2.2.4 i RD 50-34.698-90]
Åtgärder för att förbereda automationsobjektet för driftsättning av systemet
I avsnittet "Förberedande åtgärder för att ta systemet i drift" anges följande:
- åtgärder för att bringa information i en form som lämpar sig för;
- aktiviteter för utbildning och testning av personalens kvalifikationer;
- åtgärder för att skapa nödvändiga enheter och arbetstillfällen;
- åtgärder för att ändra automationsobjektet;
- andra åtgärder baserade på de specifika egenskaperna hos de system som skapas.
Läser in...
