Технічна документація. Пояснювальна записка до технічного проекту Пояснювальна записка до технічного завдання приклад
Основною метою документа Пояснювальна записка є надання загальних відомостей про систему та обґрунтування для технічних рішень прийнятих у процесі її розробки. Тому основою розробки Пояснювальної записки буде в основному Технічне завдання.
Пояснювальна записка одна із найважливіших документів технічного проекту. Технічний проект розробляють з метою виявлення остаточних технічних рішень, що дають повне уявлення про конструкцію виробу.
При розробці програми для створення пояснювальної записки рекомендується використовувати ДЕРЖСТАНДАРТ 19.404-79 «Пояснювальна записка. Вимоги до змісту та оформлення».
Для створення пояснювальної записки до технічного проекту, що описує автоматизовану систему (АС), рекомендується використовувати стандарт РД 50-34.698-90 «Автоматизовані системи. Вимоги до змісту документів».
Багато розділів, наведених документів, перегукуються, тому ми для прикладу розглянемо документ Пояснювальна записка, створена на підставі РД 50-34.698-90
1. Загальні положення
1.1 Найменування проектованої АС
Цей розділ документа Пояснювальна записка містить повну та коротку назву АС.
Наприклад: «У даному документі створювана система називається Корпоративний інформаційний портал. Також допускається використання скороченого найменування КВП чи Система».
1.2 Документи, на підставі яких ведеться проектування системи
У цьому розділі документа Пояснювальна записка слід зазначити посилання на договір та Технічне завдання на розробку автоматизованої системи.
1.3 Організації, які беруть участь у розробці системи
У цьому розділі документа Пояснювальна записка вказуються найменування організацій замовника та розробника.
1.4 Цілі розробки АС
У цьому розділі документа Пояснювальна записка слід вказати технічну, економічну та виробничу користь, яку отримає замовник після впровадження системи, що розробляється.
Наприклад: «Метою створюваної системи є:
- оптимізація документообігу підприємства;
- підтримка корпоративної культури компанії;
- оптимізація комунікацій між працівниками компанії. »
1.5 Призначення та область використання АС, що розробляється
Цей розділ документа Пояснювальна записка повинна включати опис виду діяльності, що автоматизується, і перерахування процесів, для автоматизації яких призначена система.
Наприклад: «КВП призначений для забезпечення повною та оперативною інформацією, а також ефективної організації роботи співробітників. Система має забезпечувати організацію спільної роботи працівників за допомогою таких можливостей:
- створення конференцій для обговорення питань;
- Надсилання/Отримання електронних поштових повідомлень;
- Забезпечення спільної роботи з документами;
- Узгодження документів;
- Ведення обліку вхідної та вихідної документації.»
1.6 Відомості про використані під час проектування нормативно-технічні документи
У цьому розділі слід вказати стандарти, які використовувалися під час створення документа Пояснювальна записка.
Наприклад: «Під час проектування використовувалися такі нормативно-технічні документи:
- ГОСТ 34.201-89 Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Види, комплектність та позначення документів при створенні автоматизованих систем»;
- ГОСТ 34.602-89 Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання створення автоматизованої системи»;
- ДЕРЖСТАНДАРТ 34.003-90 «Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Терміни та визначення";
- ДЕРЖСТАНДАРТ 34.601-90 «Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Стадії створення»;
- РД 50-682-89 «Методичні вказівки. Інформаційна технологія. Комплекс стандартів та керівних документів на автоматизовані системи. Загальні положення";
- РД 50-680-88 «Методичні вказівки. Автоматизовані системи. Основні положення";
- РД 50-34.698-90 «Методичні вказівки. Інформаційна технологія. Комплекс стандартів та керівних документів на автоматизовані системи. Автоматизовані системи. Вимоги до змісту документів».
1.7. Черговість створення системи
Для систем, що створюються в кілька ітерацій у пояснювальній записці, слід вказати обсяг робіт для кожної ітерації. Окремо необхідно виділити роботи, які плануються для даної ітерації.
Наприклад: «Реалізація проекту Корпоративного інформаційного Порталу планується у дві черги.
Перша черга КВП включає організації спільної роботи співробітників компанії завдяки введенню таких можливостей як:
- обмін миттєвими повідомленнями;
- Організація конференції;
- Передача/прийом електронної пошти;
- Узгодження документів засобами Системи.
2 Опис процесу діяльності
Даний розділ документа Пояснювальна записка має відображати процеси та функції, що автоматизуються системою, у межах усього бізнес-процесу.
Для ілюстрації матеріалу в записці пояснення допускається використовувати нотації UML , ARIS або IDF0, а також схематичні зображення, створені за допомогою стандартних додатків (Visio).
Для розуміння ставлення автоматизованих функцій до неавтоматизованих у документі Пояснювальна записка необхідно чітко розділяти дії користувача та дії системи.
Наприклад: «1. Користувач формує документ
- Користувач ініціює процес передачі документа на погодження
- Система змінює статус документа на «узгодженні». »
- Основні технічні рішення
2.1. Рішення щодо структури системи та підсистем.
У цьому розділі документа Пояснювальна записка наводяться рішення щодо функціональної структури системи та її підсистем.
2.2. Засоби та способи взаємодії між компонентами системи. Взаємозв'язок із зовнішніми системами
У цьому розділі документа Пояснювальна записка необхідно вказати перелік систем, з якими повинен взаємодіяти продукт, що створюється. При описі взаємодії компонентів системи у пояснювальній записці необхідно вказати формат обміну даними.
Наприклад: «У рамках взаємодії КВП із зовнішніми системами використовуються такі технології:
- «Бухгалтерія підприємства» - файловий обмін у встановленому XML/Excel форматі.»
2.3. Рішення щодо режимів функціонування
Цей розділ документа Пояснювальна записка включає перелік та опис режимів функціонування системи. Зазвичай виділяються такі режими: штатний режим, режим тестової експлуатації, сервісний режим. У записці пояснення необхідно надати опис як самого режиму так і випадків в яких він вводиться.
2.4. Рішення щодо чисельності, кваліфікації та функцій персоналу АС
Цей розділ документа Пояснювальна записка регламентує діяльність обслуговуючого та функціонального персоналу. У пояснювальній записці необхідно вказати категорію співробітників, яка відноситься до того чи іншого типу персоналу та описати їх функції у рамках роботи системи.
Наприклад: «Адміністратор порталу відповідальний за:
- цілісність бази даних та програмного забезпечення;
- профілактичні заходи щодо забезпечення збереження даних;
- розподіл прав доступу та реєстрацію користувачів у системі. »
2.5. Забезпечення заданих у технічному завданні споживчих характеристик системи
Цей розділ документа Пояснювальна записка створюється на основі вимог до якості продукту, зазначених у технічному завданні. Тут необхідно описати параметр, яким визначається якість системи. Також у пояснювальній записці вказуються рішення, за допомогою яких дана характеристика була досягнута в системі.
Наприклад: "Відмову стійкості та працездатності програмних модулів КВП забезпечується за рахунок застосування промислових програмних платформ IBM WebSphere Portal, Enterprise Oracle 10g."
2.6. Склад функцій та комплекс завдань, що реалізуються системою
Цей розділ документа Пояснювальна записка містить перелік завдань, які вирішує система. У пояснювальній записці функції та комплекс завдань можна подати у вигляді ненумерованого списку.
2.7. Рішення щодо комплексу технічних засобів, його розміщення на об'єкті
Цей розділ документа Пояснювальна записка містить рішення щодо технічної архітектури системи та вимоги до комплексу технічних засобів, необхідних для забезпечення її коректного функціонування.
Вимоги до комплексу технічних засобів у записці пояснення рекомендується розміщувати у вигляді таблиці.
Наприклад: «
|
Устаткування |
Технічна характеристика |
|
Сервер Бази даних |
|
|
Виконання для монтажу у стійку |
Не більше 4U |
|
Архітектура процесорів |
RISC (64-розрядна) |
|
Частота процесора |
не менше 1,5 ГГц |
|
Кеш процесора |
Не менше 1Мб |
|
Операційні системи |
Windows 2003 SP2 |
|
Можлива кількість встановлюваних процесорів |
Не менше 4 |
|
Число встановлених процесорів |
|
|
Об'єм можливої оперативної пам'яті |
32 ГБ з ЄСС |
|
Об'єм оперативної пам'яті |
Мінімум 8 ГБ |
|
Наявність інтерфейсів |
10/100/1000 Base-T Ethernet інтерфейси 2 шт.; |
|
Відео карта: |
Щонайменше 8Мб. |
|
Можлива кількість встановлюваних жорстких дисків |
Не менше 4 |
|
Число встановлених дисків |
|
|
Пристрій для зчитування |
|
|
Електричне харчування |
Вхідні параметри: |
»
При описі розміщення об'єктів комплексу технічних засобів у записці пояснення необхідно керуватися вимогами СНиП 11-2-80 для будівель категорії "В".
2.8. Обсяг, склад, способи організації, послідовність обробки інформації
Інформаційне забезпечення включає внутрішньомашинне і позамашинне інформаційне забезпечення. Як внутрішньомашинне інформаційне забезпечення виступають База даних (БД), вхідні та вихідні документи, що надходять із зовнішніх систем.
Немашинну інформаційну базу утворюють дані, що містяться в паперових документах. Найчастіше під час розробки автоматизованих систем використовується лише внутрішньомашинна інформаційна база, тому основний упор у документі Пояснювальна записка необхідно зробити зміст даного розділу.
При описі внутрішньомашинної інформаційної бази у документі Пояснювальна записка необхідно вказати вхідні та вихідні документи та повідомлення для всіх підсистем та зовнішніх систем.
Наприклад: «Вхідною інформацією для підсистеми електронного документообігу є:
- електронні версії документів виробничого документообігу;
- електронний цифровий підпис;
Вихідною інформацією для підсистеми електронного документообігу є:
- журнал історії життєвого циклу документа;
- журнал історії погодження документа;
- файл електронної версії документа RTF. »
2.9. Склад програмних продуктів, мови діяльності, алгоритми процедур та операцій та методи їх реалізації
У цьому розділі документа Пояснювальна записка слід навести технології та засоби розробки системи.
Наприклад:
«
- Сервер бази даних: Oracle 10g
- Портал Websphere Portal Extend v6.0.
- Бізнес-моделювання: ARIS
»
3 Заходи щодо підготовки об'єкта автоматизації до введення системи в дію
У цьому розділі документа Пояснювальна записка описує такі заходи:
- заходи щодо приведення інформації до виду, придатного для обробки на ЕОМ;
- заходи щодо навчання та перевірки кваліфікації персоналу;
- заходи щодо створення необхідних підрозділів та робочих місць;
- заходи щодо зміни об'єкта автоматизації;
- інші заходи, що виходять із специфічних особливостей створюваних АС
27.10.2016 09:57:23
У цій статті розглядається стадія технічного проекту, що відноситься до одного з етапів життєвого циклу системи інформаційної безпеки (СІБ) - етапу "проектування", який відповідно до вітчизняного стандарту ГОСТ 34.601-90 слідує відразу за розробкою Технічного завдання на систему інформаційної безпеки.
1. Розробка документації технічного проекту на СІБ
Життєвий цикл системи інформаційної безпеки (далі - СІБ) у загальному вигляді складається з наступних етапів:
- аналіз вимог до СІБ;
- проектування;
- реалізація;
- використання;
- експлуатація.
У цій статті розглядається стадія технічного проекту, що відноситься до етапу «проектування» і відповідно до вітчизняного стандарту ГОСТ 34.601-90 слідує відразу за розробкою Технічного завдання на систему інформаційної безпеки.
1.1. Навіщо взагалі розробляти документацію на СІБ
Відповідь на це питання слід розглядати у двох площинах: у площині власника інформаційних ресурсів (для захисту яких і створюється СІБ) та у площині безпосереднього розробника СІБ.
Для власника інформаційних ресурсів важливо отримати результат у вигляді функціонуючої системи інформаційної безпеки, що знижує ризик компрометації інформації обмеженого доступу в організації. Технічний проект в даному випадку служить для розробки фундаментальних основ майбутньої системи, а саме включає опис того, яким чином СІБ будуватиметься і функціонуватиме, якими заходами та засобами забезпечуватиметься захист інформації, які можливості розвитку та вдосконалення системи. Після завершення розробки технічного проекту на систему інформаційної безпеки Замовник отримує вичерпний комплект документації на СІБ, що описує всі технічні нюанси майбутньої системи.
Для безпосереднього виконавця на етапі технічного проекту необхідно закласти найбільш підходящу архітектуру СІБ, а також зробити правильний вибір заходів та засобів захисту інформації в організації. Також важливо забезпечити відповідність характеристик та властивостей системи технічному завданню, або обґрунтувати за участю та згодою Замовника коригування вимог, зазначених у ТЗ, для підвищення ефективності створюваної системи.
Таким чином, у результаті розробки документації технічного проекту у Замовника з'являться відповіді на такі запитання:
- яка загальна архітектура СІБ;
- які заходи та засоби будуть використовуватися для реалізації вимог щодо захисту інформації;
- яким чином СІБ функціонуватиме;
- які зміни в організації, необхідні для підвищення рівня захищеності інформації, відбудуться внаслідок впровадження СІБ;
- чи будуть враховані вимоги Замовника (бізнес-вимоги) та вимоги нормативно-правових актів у сфері інформаційної безпеки при розробці та впровадженні СІБ та, якщо так, то яким чином.
Виконавець у процесі розробки документації технічного проекту отримає такі результати:
- основу для переходу до наступних етапів побудови СІБ, а саме стадій робочої документації та впровадження;
- розуміння архітектури, використовуваних технологій та засобів, порядку побудови системи;
- яким чином реалізуються вимоги Замовника (бізнес-вимоги) та нормативних документів у сфері інформаційної безпеки до системи.
1.2. Огляд підходів до розробки документації технічного проекту
Розробка технічного проекту для системи інформаційної безпеки найчастіше здійснюється на основі відповідних стандартів та керівних документів. Причому державних установ їх застосування обов'язково, а комерційних рекомендується. На практиці комерційні організації також використовують державні стандарти для розробки документації технічного проекту з наступних причин:
- багаторазово апробований підхід до створення інформаційних систем;
- продумана структура та наповнення документів;
- склад документів, достатній розробки і описи практично будь-якої системи.
Для розробки документації стадії технічного проекту (ТП) на СІБ використовуються державні стандарти та керівні документи серії 34:
- ГОСТ 34.201-89 «Види, комплектність та позначення документів при створенні автоматизованих систем». У цьому стандарті вказано:
- види та найменування документів стадії ТП;
- комплектність документації;
- прийняті позначення документів;
- правила позначення СІБ та їх частин.
- ГОСТ 34.003-90 «Терміни та визначення»;
- ГОСТ 34.601-90 «Автоматизовані системи. Стадії створення». У стандарті вказано:
- перелік етапів робіт, які проводяться на стадії ТП;
- докладний опис робіт, які проводяться на стадії ТП;
- перелік організацій, що у створенні СИБ;
- РД 50-34.698-90 «Автоматизовані системи. Вимоги щодо змісту документів». У цьому керівному документі зазначено вимоги до змісту документів на стадії ТП.
Важливо розуміти, що згідно зі стандартами серії 34, технічний проект – це стадія створення системи, а не просто набір документів. Ця стадія на практиці часто поєднується зі стадією ескізного проекту, що служить для розробки кількох попередніх рішень та обґрунтування найбільш відповідного. Таке об'єднання допускається стандартом, але слід враховувати, що це скасовує необхідності реалізації цілей стадії ескізного проекту.
Найчастіше стадію ескізного проекту розробляють у тому випадку, коли вимоги технічного завдання на систему можна реалізувати кількома способами, що принципово розрізняються, а також у разі, якщо серед цих способів немає однозначно кращих.
Однак варто зазначити, що вищезазначені стандарти є надто загальними та в основному реалізують оформлювальну та загальноструктурну функцію. Для розробки сутевої частини документів на стадії технічного проекту проектувальниками використовуються відомості з таких джерел:
Чинні нормативні документи (НПА), які регламентують вимоги до захисту тієї чи іншої інформації обмеженого доступу. У даних НПА представлені вимоги до заходів захисту інформації в інформаційних системах, описані нюанси реалізації цих заходів та додаткові заходи посилення. Серед актуальних НПА можна виділити такі:
- наказ ФСТЕК Росії від 18 лютого 2013 р. № 21 «Про затвердження складу та змісту організаційних та технічних заходів щодо забезпечення безпеки персональних даних при їх обробці в інформаційних системах персональних даних»;
- наказ ФСТЕК Росії від 11 лютого 2013 р. № 17 «Про затвердження вимог щодо захисту інформації, яка не становить державної таємниці, що міститься в державних інформаційних системах»
- наказ ФСТЕК Росії від 14 березня 2014 р. № 31 «Про затвердження вимог до забезпечення захисту інформації в автоматизованих системах управління виробничими та технологічними процесами на критично важливих об'єктах, потенційно небезпечних об'єктах, а також об'єктах, що становлять підвищену небезпеку для життя та здоров'я людей та навколишнього природного середовища;
- методичний документ «Заходи захисту інформації у державних інформаційних системах», затверджений ФСТЕК Росії 11 лютого 2014 р.
Вимоги до захисту інформації обмеженого доступу та переліки захисних заходів відрізняються для ІС різних рівнів/класів захищеності. У разі, якщо інформація в організації не відноситься до захисту відповідно до федеральних законів РФ (наприклад, службова таємниця), то власник даної інформації може скористатися підходами, пропонованими в даних НПА для побудови корпоративної СІБ.
Російські та зарубіжні стандарти, що описують різні підходи до способів реалізації стадій життєвого циклу побудови СІБ, у тому числі стадії технічного проекту:
- серія державних стандартів ГОСТ Р ІСО/МЕК 2700X, ідентичні міжнародним стандартам ISO/IEC 2700X. Дані стандарти описують процесний підхід PDCA (Plan, Do, Check, Act) до реалізації життєвого циклу системи управління інформаційної безпеки, яка є невід'ємною частиною СІБ;
- NIST SP 800-64 – стандарт Національного Інституту Стандартів та Технологій США, який описує життєвий цикл розробки інформаційних систем;
- NIST SP 800-37 – стандарт Національного Інституту Стандартів та Технологій США, який є посібником з інтеграції управління ризиками до життєвого циклу розробки інформаційних систем.
Експлуатаційна документація виробника на засоби захисту інформації та допоміжні засоби. У цих документах міститься вичерпна технічна інформація про засоби, що застосовуються при побудові СІБ, у тому числі безпосередньо до реалізації заходів ІБ, що не відносяться, наприклад, серверах, системах зберігання даних, засобах віртуалізації та інших. Загальний набір таких документів у різних виробників різний і залежить від виконання того чи іншого засобу (апаратне/програмне). Нижче наведено стандартний набір експлуатаційної документації на засоби захисту інформації, що використовується для розробки документів стадії технічного проекту:
- загальний опис (datasheet);
- керівництво адміністратора (може входити керівництво з локального та централізованого управління);
- Інструкція користувача;
- посібник із швидкої установки та розгортання (для апаратного СЗІ);
- керівництво оператора;
- посібник із розгортання у віртуальній інфраструктурі (для програмного СЗІ);
Загальна інформація про наявні архітектури СІБ, найкращі практики в частині побудови СІБ, посібники з безпеки та інтеграції СЗІ один з одним, відомості про проблеми при взаємодії тих чи інших СЗІ. Прикладами таких відомостей можуть бути такі документи:
- посібники з архітектур систем інформаційної безпеки, наприклад: Defense-in-Depth, Cisco SAFE, Check Point SDP та інші;
- найкращі практики в галузі інформаційної безпеки, наприклад, доступні за даними посиланням (https://www.sans.org/reading-room/whitepapers/bestprac/ , http://csrc.nist.gov/publications/nistpubs/800-14 /800-14.pdf). Дані документи найчастіше представлені англійською мовою, проте свої найкращі практики впровадження засобів захисту є у будь-якого російського виробника СЗІ і на запит їх можуть надати;
- посібники з безпеки для СЗІ та середовищ функціонування. Як приклад можна навести розділ «Безпека» на офіційному порталі компанії Microsoft (https://technet.microsoft.com/ru-ua/library/dd637672.aspx).
1.3. Розробка технічного проекту на СІБ відповідно до ГОСТ 34
Розробка документів стадії технічного проекту на СІБ здійснюється найчастіше інтеграторами даних послуг та реалізується переважно відповідно до наступного плану:
Визначення переліку документів, що розробляються - дані відомості вказуються в технічному завданні на СІБ. У деяких випадках розробник документів за погодженням із Замовником може розширити або скоротити цей перелік, якщо можливість цього передбачено у ТЗ;
Розробка шаблонів документів стадії ТП – використовується структура відповідно до РД 50-34.698-90 та ГОСТ 2.106 (для деяких документів), оформлення відповідно до ГОСТ 2.105-95;
Розробка сутевої частини документів. Вимоги до системи встановлюються у технічному завданні на СІБ. Відповідно до цих вимог визначається перелік захисних технічних та організаційних заходів, необхідних для реалізації в системі. Заходи захисту можуть бути визначені у відповідних НПА (залежно від типу інформації, що захищається), корпоративних стандартах та політиках інформаційної безпеки, а також виходячи з наявності актуальних загроз безпеки, виявлених на етапі розробки моделі загроз організації. Ґрунтуючись на переліку заходів захисту, розробник СІБ здійснює вибір відповідних засобів захисту інформації та розробляє функціональну структуру системи інформаційної безпеки (підсистеми, компоненти). Далі у документах технічного проекту описується практична реалізація заходів захисту на основі вибраних СЗІ чи організаційних заходів в інфраструктурі організації.
Узгодження розробленої документації та представлених у ній рішень із Замовником системи.
При розробці документації технічного проекту найчастіше не потрібно розробляти повний перелік документів, зазначений у ГОСТ 34.201-89, оскільки цей стандарт морально застарів і частина документів не враховує тенденції розробки та технології сучасних інформаційних систем. Мінімальний комплект документів, необхідний для опису системи інформаційної безпеки, є наступним:
- відомість технічного проекту;
- пояснювальна записка до технічного проекту;
- схема функціональної структури;
- схема структурного комплексу технічних засобів;
- схема організаційної структури;
- відомість покупних виробів.
На вимогу Замовника або в тому випадку, якщо СІБ є складною багатокомпонентною системою, додатково можуть також розроблятися такі документи:
- схема автоматизації;
- опис функцій, що автоматизуються;
- опис інформаційного забезпечення системи;
- опис комплексу технічних засобів;
- опис програмного забезпечення;
- Опис організаційної структури.
Слід зазначити, що ГОСТ 34.201-89 допускає розширення номенклатури документів стадії ТП, проте практично зазначених документів вистачає з надлишком.
Відомість технічного проекту
Позначення: ТП.
Цей документ призначений для опису переліку документів, що розробляються на етапі технічного проекту. Також вказується кількість сторінок кожного із розроблених документів.
Пояснювальна записка до технічного проекту
Позначення: П2.
Даний документ є основним для стадії ТП і включає опис архітектури СІБ, технічних і організаційних заходів, функцій СІБ, комплексів програмних і технічних засобів та іншого. Відповідно до стандарту складається з чотирьох основних розділів:
- загальні положення;
- опис процесу діяльності;
- основні технічні рішення;
- заходи щодо підготовки об'єкта автоматизації до введення системи в дію.
Схема функціональної структури
Позначення: С2.
Цей документ описує логічну структуру СІБ, а саме:
- логічні підсистеми та компоненти, що входять до складу СІБ;
- функції, що реалізуються засобами підсистем та компонентів;
- інформаційні зв'язки між логічними елементами СІБ та типи повідомлень під час обміну.
Схема структурного комплексу технічних засобів
Позначення: С1.
Цей документ включає опис наступних елементів СІБ:
- технічних засобів у складі логічних підсистем та компонентів СІБ;
- каналів зв'язку та обміну між технічними засобами із зазначенням транспортних протоколів.
Схема організаційної структури
Позначення: С0.
Цей документ описує організаційну структуру організації в частині управління СІБ, а саме:
- підрозділи та відповідальних осіб організації, які беруть участь у функціонуванні СІБ;
- виконувані функції та зв'язки між підрозділами та відповідальними особами.
Відомість покупних виробів
Позначення: ВП.
Цей документ включає перелік всіх програмних і технічних засобів, а також ліцензій, що використовуються при створенні СІБ. Розробляється відповідно до ГОСТ 2.106.
Примітка.Тут також слід зазначити, що керівний документ РД 50-34.698-90 допускає доповнення будь-якого документа стадії ТП (включення розділів та відомостей, відмінних від запропонованих), об'єднання розділів, а також виключення окремих розділів. Рішення про це приймаються розробником документів стадії ТП та ґрунтуються на особливостях створюваної СІБ.
1.4. Правила розробки документації
- структурна відповідність державним стандартам;
- чітку відповідність вимогам технічного завдання на систему;
- застосування шаблонів документів (застосування єдиних стилів, розмітки, полів та іншого);
- індивідуальний підхід та одночасне використання існуючих розробок при наповненні розділів документів.
Пояснювальна записка до технічного проекту:
- розробка документа здійснюється серед Microsoft Word, після закінчення розробки рекомендується для зручності конвертувати документ у формат PDF;
- терміни та скорочення мають бути єдиними в межах усіх розділів документа;
- рекомендується уникати явних повторень та непотрібного збільшення обсягу документа;
- технічні рішення необхідно описувати якомога докладніше із зазначенням:
- архітектури та використовуваних технологій;
- місць розміщення програмних та технічних засобів в інфраструктурі організації;
- використовуваних засобів захисту інформації з описом їх характеристик, функцій, що реалізуються, відомостей про сертифікацію;
- основних налаштувань засобів захисту інформації в частині механізмів захисту, адресації, маршрутизації, взаємодії із суміжними системами та засобами тощо;
- засобів управління, методів доступу до них та місцях їх встановлення;
- схеми (структурна, функціональна, організаційна):
- розробляти схеми серед Microsoft Visio;
- після розробки вставляти схеми до документа за допомогою діалогу «Спеціальна вставка» у форматі EMF (метафайл Windows);
- розробляти окремі схеми на систему, підсистеми та компоненти підсистем;
- оформлення схем робити однотипним, з використанням однакових елементів, скорочень, ікон, стилів тексту та іншого.
1.5. Ресурси, що допомагають під час розробки документації
В інтернеті розміщується величезна кількість інформації, яка в тій чи іншій мірі здатна допомогти при розробці документації технічного проекту. Основні ресурси представлені у таблиці нижче.
Таблиця. Ресурси з технічного проектування СІБ
| Тип ресурсу | Інформація | Приклади ресурсів |
|---|---|---|
| Інтернет-портали федеральних органів виконавчої влади | Нормативні документи, методичні рекомендації, реєстри (у тому числі сертифікованих СЗІ), бази даних (у тому числі БД уразливостей та загроз) | fstec.ru clsz.fsb.ru minsvyaz.ru/ru/ |
| Інтернет-портали виробників СЗІ, дистриб'юторів рішень в галузі ІБ | Опис рішень з ІБ, експлуатаційна документація з СЗІ, аналітичні матеріали та статті | securitycode.ru kaspersky.ru/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ua/index.html checkpoint.com altx-soft.ru |
| Спеціалізовані ресурси з ІБ | Порівняння рішень з ІБ, оглядові статті з рішень ІБ, тести рішень з ІБ, глибокі технічні відомості про технології ІБ | anti-malware.ru bis-expert.ru safe.cnews.ru securitylab.ru/ vulners.com/ csrc.nist.gov itsecurity.com owasp.org sans.org |
1.6. Приклади документів на стадії технічного проекту
Для розуміння вимог до змісту документації стадії ТП наведено приклади наповнення основних документів (розділів документів).
1.6.1. Пояснювальна записка до технічного проекту
Пояснювальна записка - досить об'ємний документ, тому наводиться приклад змісту розділу «Основні технічні рішення» в частині однієї з підсистем СІБ - підсистеми аналізу захищеності.
Підсистема аналізу захищеності СІБ
Структура та склад підсистеми
Підсистема аналізу захищеності (ПАЗ) призначена щодо систематичного контролю стану захищеності автоматизованих робочих місць (АРМ) персоналу і серверів організації. Основою ПАЗ є програмний засіб "Test" виробництва компанії ТОВ "Інформаційна безпека". СЗІ Test має сертифікат ФСТЕК Росії на відповідність технічним умовам (ТУ) з безпеки інформації та за 4-м рівнем контролю відсутності недекларованих можливостей.
До складу ПАЗ входять такі компоненти:
- сервер керування Test Server;
- консоль керування Test Console.
Опис компонентів підсистеми наведено в таблиці нижче.
Таблиця. Компоненти ПАЗ
| Компонент | Опис |
|---|---|
| Сервер керування Test Server | Забезпечує керування завданнями сканування, виконує функції контролю стану захищеності АРМ та серверів організації. Параметри сканування задаються адміністратором ІБ на сервері керування Test Server. Вся зібрана інформація про результати сканування зберігається у сховищі сервера Test Server на базі системи керування базами даних Microsoft SQL Server 2008 |
| Консоль керування Test Console | Дозволяє адміністратору ІБ підключатися до сервера Test Server, переглядати та змінювати його конфігурацію, створювати та модифікувати завдання на проведення сканувань, переглядати інформацію про хід виконання завдань та результати їх виконання. Консоль управління встановлюється на АРМ адміністратора ІБ |
Забезпечення функцій
ПАЗ забезпечує виконання наступних функцій:
- реалізація проактивного захисту АРМ та серверів організації за допомогою моніторингу стану ІБ;
- автоматизація процесів контролю відповідності внутрішнім політикам та певним стандартам безпеки;
- зниження витрат на аудит та контроль захищеності, підготовку звітів за станом;
- автоматизація процесів інвентаризації ресурсів, управління вразливістю, контролю відповідності політикам безпеки та контролю змін.
Рішення щодо комплексу технічних та програмних засобів
Перелік програмно-технічного забезпечення ПАЗ, що використовується, наведено в таблиці нижче.
Таблиця. Програмно-технічні засоби ПАЗ
Сервер управління ПАЗ
Технічні засоби
Фізичний сервер, що використовується як сервер управління ПАЗ, повинен задовольняти технічним вимогам до встановлених на нього ПЗ та ОС, наведених у таблиці нижче.
Таблиця. Вимоги до ОС та ПЗ сервера управління ПАЗ
| Програмне забезпечення | Технічні вимоги | |
|---|---|---|
| CPU | RAM, МБ | |
| Microsoft Windows Server 2008 R2 | 3000 МГц, 4 ядра | 8192 |
| Microsoft SQL Server 2008 R2 | ||
| ПЗ Test Server | ||
Програмні засоби
ОС сервера керування
Встановлення ОС Windows 2008 R2 на сервер управління здійснюється штатним чином із завантажувального дистрибутива.
Управління ОС сервера управління здійснюється як локально з консолі, і за протоколом RDP.
СУБД сервера керування
Встановлення БД Microsoft SQL Server 2008 R2 здійснюється під обліковим записом з правами локального адміністратора за допомогою стандартного майстра установки з дистрибутива, що постачається розробником продукту.
ПЗ Test Server
Встановлення програмного забезпечення Test Server на сервер управління здійснюється за допомогою стандартного майстра установки.
Початкове налаштування та подальше керування ПЗ Test Server у штатному режимі здійснюються за допомогою консолі керування Test Console, встановленої на АРМ адміністратора ІБ.
АРМ адміністратора ІБ
Технічні засоби
Як платформу використовується існуючий АРМ співробітника підрозділу організації, відповідального забезпечення ІБ, під керівництвом ОС сімейства Microsoft Windows.
Технічні засоби АРМ адміністратора ІБ повинні мати наступні характеристики апаратної конфігурації (рекомендується не менше):
- CPU 2 ГГц;
- RAM 4 ГБ;
- HDD 80 ГБ.
Програмні засоби
ПО Test Console
АРМ адміністратора ІБ, на яке виконується установка ПЗ Test Console, має функціонувати під керуванням однієї з наступних ОС:
- Microsoft Windows 7, 32- та 64-бітні;
- Microsoft Windows 8/8.1, 32- та 64-бітні.
Крім того, для коректної роботи програмного забезпечення консолі керування Test Console на АРМ адміністратора ІБ повинно бути встановлено програмне забезпечення Microsoft .NET Framework версії 3.5 SP1 або вище, а налаштування безпеки використовуваної ОС повинні дозволяти доступ до сервера Test Server.
Встановлення програмного забезпечення Test Console на АРМ адміністратора ПАЗ здійснюється за допомогою стандартного майстра установки програмного забезпечення Test Server з обраною опцією установки консолі управління Test Console та іншими налаштуваннями за замовчуванням.
Взаємодія із суміжними системами
Для ПАЗ суміжними є:
- засоби підсистеми міжмережевого екранування;
- служби каталогу Active Directory;
- АРМ та сервери організації.
Для забезпечення мережевої взаємодії із суміжними системами та безпосередньо між самими компонентами ПАЗ має бути організовано проходження необхідного мережевого трафіку.
Для забезпечення можливості отримання оновлень бази знань та модулів ПЗ Test для сканера Test Server необхідно забезпечити доступ до веб-сервера оновлень компанії ТОВ «Інформаційна безпека» update.com по порту 443/tcp.
При скануванні в режимі PenTest взаємодія сканера Test Server та АРМ та серверів організації здійснюється за протоколом IP. Під час сканування в режимі Audit та Compliance використовуються протоколи віддаленого керування WMI, RPC тощо. Для сканування вузлів на пристроях з функціями міжмережевого екрана необхідно дозволити з'єднання від сервера Test Server до сканованих вузлів за протоколом IP. Відповідно, для сервера Test Server необхідно забезпечити доступ до мережних портів сканованих вузлів за відповідними протоколами віддаленого керування.
Оскільки ПАЗ при скануванні в режимах Audit і Compliance використовує для аналізу протоколи віддаленого керування, то засоби сканування ПЗ Test повинні проходити аутентифікацію та авторизацію на вузлі, що сканується. У ПАЗ для сканування вузлів у режимах Audit та Compliance у кожному з типів вузлів (АРМ, сервер, прикладні системи, СУБД тощо) використовуються облікові записи з адміністративними привілеями.
Усі реєстровані події інформаційної безпеки зберігаються у СУБД Microsoft SQL. Дані події за допомогою спеціальних конекторів можуть вирушати до підсистеми моніторингу подій ІБ.
Експлуатація та обслуговування ПАЗ
Користувачі підсистеми
Експлуатація та обслуговування коштів ПАЗ здійснюється співробітниками організації з функціональною роллю «адміністратор ІБ».
Під адміністратором ІБ розуміється спеціаліст, до завдань якого входить:
- визначення параметрів сканування вузлів організації;
- налаштування та запуск завдань на сканування;
- аналіз результатів сканування щодо наявності в інформаційних системах уразливостей, помилок конфігурації чи невідповідностей вимогам технічних стандартів;
- контроль усунення уразливостей;
- формування стандартів та вимог, які пред'являються до забезпечення безпеки АРМ та серверів організації.
Режими експлуатації системи
Штатний режим експлуатації
У штатному режимі експлуатації ПАЗ функціонує 24 години на добу 7 днів на тиждень.
У штатному режимі роботи адміністратор ІБ виконує:
- планове та позапланове сканування вузлів;
- генерацію звітів;
- оновлення баз знань та модулів ПЗ Test.
Аварійний режим експлуатації
За порушення працездатності коштів ПАЗ функціонування підсистеми порушується. Порушення працездатності коштів ПАЗ не впливає на функціонування АРМ та серверів організації.
1.6.2. Схема функціональної структури
Функціональні схеми можуть розроблятися для всієї СІБ або її частини, наприклад, підсистеми або компонента.
Приклад загальної функціональної схеми СІБ представлений малюнку нижче.
1.6.3. Схема структурного комплексу технічних засобів
Структурна схема комплексу технічних засобів може розроблятися як для всієї СІБ, так і для її частин – підсистем та компонентів. Доцільність розробки схем частин СИБ визначається масштабом системи та необхідної деталізацією.
Приклад структурної схеми комплексу технічних засобів СІБ представлений малюнку нижче.
Міністерство економічного розвитку та торгівлі Російської Федерації
ЗАТВЕРДЖУЮ |
||||||||||||||||||||||||||||||||||||||
|
Державний контракт № 000-05-07 від «29» жовтня 2007 р., укладений між Міністерством економічного розвитку та торгівлі Російської Федерації та ЗАТ «ПРОГНОЗ», на виконання робіт на тему «Розробка автоматизованого модуля федерального моніторингу соціально-економічного розвитку суб'єктів Російської Федерації у рамках створення єдиної інформаційної системи моніторингу ключових показників соціально-економічного розвитку Російської Федерації та контролю результативності діяльності органів державної влади щодо їх досягнення». При розробці цього документа використовувався Керівний документ стандартизації ГОСТ РД 50-34.698-90. 1. Загальні положення. 1.1. Повне найменування системи... 5 1.2. Документи, на підставі яких ведеться проектування. 1.3. Стадії та терміни виконання. 1.4. Цілі та призначення. 1.5. Відповідність проектних рішень вимогам безпеки .. 8 1.6. Нормативно-технічні документи... 9 2. Опис процесу діяльності. 2.1. Перелік завдань. 10 2.2. Основні функції, що виконуються Модулем... 11 3. Основні технічні рішення. 3.1. Структура Модуля, перелік підсистем... 13 3.1.1. Підсистема централізованого сховища даних. 14 3.1.2. Інтерфейсний компонент. 15 3.1.3. Адаптерні програмні компоненти. 16 3.6.3. Ступінь пристосовності до відхилень параметрів об'єкта автоматизації. 26 3.6.4. Допустимі межі модернізації та розвитку системи. 3.6.5. Вимоги до надійності. 27 3.6.6. Вимога безпеки. 27 3.6.7. Вимоги до ергономіки та технічної естетики. 28
|
- загальні положення;
- опис діяльності;
- основні технічні рішення;
- заходи щодо.
[із п. 2.2.1 РД 50-34.698-90]
загальні положення
У розділі "Загальні положення" наводять:
- проектованої та найменування документів, їх номери та дату, на підставі яких ведуть проектування АС;
- перелік, що у системі, терміни виконання;
- цілі, призначення та АС;
- підтвердження відповідності проектних рішень чинним нормам та, пожежо- та вибухобезпеці тощо;
- відомості про використані під час проектування;
- відомості про, передове, використані при розробці проекту;
- черговість створення системи та обсяг кожної.
[із п. 2.2.2 РД 50-34.698-90]
Опис процесу діяльності
У розділі «Опис процесу діяльності» відображають склад процедур () з урахуванням забезпечення взаємозв'язку та сумісності процесів та діяльності, формують для організації робіт в АС [з п. 2.2.3 РД 50-34.698-90]
Основні технічні рішення
У розділі «Основні технічні рішення» наводять:
- рішення щодо структури системи, засобів та способів зв'язку для інформаційного обміну між, підсистем;
- рішення щодо взаємозв'язків АС із суміжними системами, забезпечення її;
- рішення щодо роботи системи;
- рішення щодо чисельності, кваліфікації та функцій, режимів його роботи, порядку взаємодії;
- відомості про забезпечення заданих у споживчих характеристик системи (підсистем), що визначають її;
- склад, комплексів завдань (), що реалізуються системою (підсистемою);
- рішення щодо комплексу, його розміщення;
- рішення щодо складу інформації, обсягу, способів її, видів машинних та документів і, послідовності та інших компонентів;
- рішення щодо складу, мов діяльності, процедур та операцій та методів їх реалізації.
У розділі наводять у вигляді ілюстрацій інші документи, які допускається включати за ГОСТ 34.201 [п. 2.2.4 РД 50-34.698-90]
Заходи щодо підготовки об'єкта автоматизації до введення системи в дію
У розділі «Заходи щодо підготовки до введення системи в дію» наводять:
- заходи щодо приведення інформації до виду, придатного для;
- заходи щодо навчання та перевірки кваліфікації персоналу;
- заходи щодо створення необхідних підрозділів та робочих місць;
- заходи щодо зміни об'єкта автоматизації;
- інші заходи, що виходять із специфічних особливостей створюваних АС.
Завантаження...
