Мережева бюрократія: розробка положення про комерційну таємницю

Після створення (нехай хоча б на папері) служби безпеки, фахівці із захисту інформації повинні виконати наступний крок - розробити, погодити та затвердити положення про комерційну таємницю. Це найважливіший документ, що описує, яка інформація конкретної організації є комерційною таємницею. Типовий варіант положення містить кілька розділів:

• Загальні положення. Це обов`язковий розділ, що містить опис призначення документа, а також посилання на закони РФ, на яких засновано дане положення;
• Розшифровка термінів і понять, що використовуються в документі. Цей розділ готується в розрахунку на те, що вивчати документ будуть рядові користувачі, які не знайомі з термінологією. В даному розділі обов`язково необхідно розкрити зміст термінів «режим комерційної таємниці», «носій комерційної таємниці», «інформація, що становить комерційну таємницю», «ноу-хау»;
• Перелік відомостей, що становлять комерційну таємницю. У даному переліку обов`язково прописується порядок роботи з персональними даними співробітників, так як їх розголошення заборонено законом. Крім того, вкрай бажано внести в перелік інформацію про структуру мережі, застосовуваних технологіях захисту, параметрах доступу до серверів і баз даних - для цієї інформації можна ввести гриф «строго конфіденційно»;
• Звід методик і заходів, спрямованих на захист комерційної таємниці. Зокрема, в даному розділі може даватися посилання на положення про захист інформації, мова про який піде далі;
• Порядок отримання доступу до таємної інформації;
• Спеціальні обов`язки осіб, які мають допуск до комерційної таємниці і відповідають за захист комерційної таємниці;
• Покарання за порушення правил роботи з інформацією, що становить комерційну таємницю.

Відео: 13.11.2007 Закон РФ про Державну таємницю

З практичної точки зору в перелік відомостей, що становлять комерційну таємницю, бажано включити пункт «інформація, що зберігається на файлових і поштових серверах, а так само на серверах без даних». За рахунок включення даного пункту в положення будь-яке посягання на сервери і бази даних з боку співробітників фірми або атака ззовні може розглядатися як атака з метою спотворення і викрадення конфіденційної інформації. Інший практичний аспект - це забезпечення доступу до відомостей, що становлять комерційну таємницю. В ідеалі він повинен забезпечуватися за уніфікованими заявками, які підшиваються і зберігаються досить тривалий час. У Смоленськенерго, наприклад, це реалізовано в такий спосіб - існують уніфіковані заявки, які заповнюються співробітником або фахівцем IT-відділу. Далі заявка підписується її фахівцем, директором філії, начальником служби безпеки, директором IT-підрозділу, і, нарешті, виконав заявку адміністратором. Дані заявки зберігаються в базі даних, і в разі витоку інформації або несанкціонованого доступу дуже легко встановити, які права має вказаний користувач, коли і ким складені заявки на доступ і коли цей доступ був наданий. Важливість такого підходу зростає пропорційно кількості користувачів і адміністраторів.

Після погодження та затвердження положення про комерційну таємницю воно вводиться в дію наказом генерального директора фірми.

Розглянемо кілька типових прикладів з практики, що виникають при відсутності положення про комерційну таємницю:

• Співробітник Х отримує несанкціонований доступ до бази даних. Адміністратори фіксують цей факт, але в ході службового розслідування співробітник заявляє, що робив це з цікавості і не знав, що ці дані є конфіденційними. В даному випадку офіційно покарати співробітника неможливо, так як він не підписував жодних документів щодо білоруського режиму комерційної таємниці. Крім того, досить спірним є питання про ступінь конфіденційності тієї інформації, до якої співробітник встиг отримати доступ.
• Звільняється адміністратор фірми Х. прийшов йому на зміну новий адміністратор стикається з проблемою - відсутня інформація про те, яким користувачам і на підставі чого було надано доступ до баз даних і серверів. Подібна проблема легко вирішується хіба що в невеликої мережі (10-20 користувачів).
• Адміністратор бази отримує усне прохання про підключення співробітника До до бази даних від начальника одного з відділів. Через деякий час відбувається витік інформації з вини співробітника К, і в ході службового розслідування з`ясовується, що ніяких документальних підстав (якщо не брати до уваги усне прохання) на надання доступу до інформації у адміністратора не було.