Захист даних за ISO 27001: технічні та фізичні контролі без води

Те, що в пошуку набирають як «ISO безпека даних», у стандарті розкладено на два блоки Додатка A: технологічний і фізичний. Разом це майже половина всіх пунктів. Розберемо їх по суті, з номерами — щоб кожен пункт можна було знайти в самому документі, а не вгадувати. Загальний устрій переліку описано окремо — у матеріалі про контролі Додатка A.

ISO 27001: захист даних — це не одна кнопка

Безпека даних ISO 27001 тримається на двох опорах:

• розділ 8, технологічний — 34 пункти: доступ, криптографія, копії, журнали, мережі, шкідливе ПЗ;
• розділ 7, фізичний — 14 пунктів: приміщення, обладнання, носії, інженерні системи.

Заходи зі створення ПЗ теж лежать у восьмому розділі, але це окрема історія — про них у матеріалі про безпечну розробку.

Логіка розділення проста. Технічний бар'єр без матеріального — це двері з бронею й вибитим вікном поруч. Найдорожче шифрування не рятує, якщо диск можна винести з приміщення в сумці.

Технологічні контролі: що саме входить

Зручно тримати їх у голові групами:

Найнедооціненіший рядок у цій таблиці — 8.17, синхронізація годинників. Виглядає як дрібниця, поки не доводиться зіставляти журнали трьох систем під час розслідування: якщо час у них розходиться на хвилини, послідовність подій відновити неможливо, і розслідування розсипається.

ISO 27001: управління вразливостями (пункт 8.8)

Саме сюди веде запит «ISO управління вразливостями» — до одного з найпрактичніших пунктів усього переліку. У редакції 2013 року він був вужчим і зводився до реакції: знайшли дірку — залатали. Тепер це безперервний процес.

Головне непорозуміння: стандарт не вимагає нуля вразливостей. Їх у будь-якій живій системі десятки. Він вимагає керованості — щоб ви знали, що у вас є, наскільки це небезпечно і коли буде виправлено.

Процес складається з чотирьох частин:

1. Інвентаризація. Шукати нема де, поки немає переліку активів із версіями ПЗ. Невідомий сервер — це невідома дірка.
2. Виявлення. Сканери, бюлетені постачальників, тестування на проникнення, повідомлення від дослідників.
3. Оцінювання. Пріоритет ставлять за ризиком для вашого бізнесу, а не за цифрою в загальному рейтингу. Критична хиба на ізольованому стенді може зачекати; середня на публічному сервісі — ні.
4. Усунення. Термін, відповідальний, доказ. Без цих трьох елементів пункт не закритий.

Класична пастка: сканер видає чотири тисячі знахідок, команда дивиться на екран і не робить нічого. Ліки — заздалегідь узгоджені терміни за рівнями критичності та власник, з якого можна запитати.

Терміни варто зафіксувати заздалегідь і письмово: критичні знахідки закривають, скажімо, за добу, високі — за тиждень, середні — за місяць. Конкретних цифр стандарт не диктує; важливо, щоб вони були узгоджені з керівництвом, реалістичні й дотримувані. Термін, який систематично зривають, гірший за його відсутність — він просто збирає теку доказів проти вас самих.

Окремо стандарт очікує, що ви домовилися з постачальниками й хмарним провайдером: як саме вони повідомляють про власні хиби і як швидко закривають їх на своєму боці. Мовчазний провайдер — це ваш ризик, а не його.

ISO 27001: фізична безпека — 14 пунктів, про які забувають

Фізична безпека ISO 27001 не зводиться до охоронця на вході. Ось повний блок:

• 7.1–7.3 — периметр, контроль входу, захищені приміщення й кабінети.
• 7.4 — моніторинг приміщень. Пункт з'явився лише в редакції 2022 року.
• 7.5 — протидія довкіллю: пожежа, підтоплення, перегрів.
• 7.6 — правила роботи в захищених зонах.
• 7.7 — чистий стіл і чистий екран.
• 7.8 — розміщення обладнання: щоб екран не читався з коридору, а сервер не стояв під трубою.
• 7.9 — активи поза офісом: ноутбуки, телефони, техніка вдома в людей.
• 7.10 — носії: облік, зберігання, винесення за межі офісу, передавання.
• 7.11 — інженерні системи: живлення, охолодження, зв'язок.
• 7.12 — кабелі.
• 7.13 — обслуговування обладнання.
• 7.14 — утилізація або повторне використання техніки.

Три пункти з цього списку варті окремої уваги.

7.14. Диск, який «відформатували», не знищений: інформацію з нього відновлюють за півгодини. Потрібне або безповоротне стирання, або фізичне руйнування носія. І ще одна деталь, яку зазвичай проґавлюють: перед списанням знімають наліпки з назвою компанії, мережевим іменем і позначкою рівня доступу — вони самі по собі є підказкою для нападника.

7.12. Так, у стандарті справді є пункт про кабелі, і він не смішний. Найдешевший спосіб послухати чужу мережу — дістатися до кабелю в спільному коридорі бізнес-центру.

7.11. Генератор і безперебійник — теж про інформаційну безпеку, бо доступність входить у визначення нарівні з конфіденційністю.

І окремо про поширене заперечення: «ми повністю віддалені, фізичний блок нам не потрібен». Не зовсім. Ноутбуки, домашні робочі місця, зовнішні диски й списання старої техніки нікуди не поділися — пункт 7.9 написаний саме про вас.

Хмара нічого не скасовує

Переїзд у хмару прибирає серверну, але не прибирає обов'язків. Провайдер відповідає за своє обладнання й приміщення; за налаштування, права доступу, резервні копії та журнали у вашому обліковому записі відповідаєте ви.

У Заяві про застосовність такі контролі не виключають — їх перерозподіляють, і в договорі має бути чорним по білому написано, хто що робить. Найпоширеніша ілюзія: «копії робить провайдер». Часто не робить. Або робить, але зберігає їх рівно стільки, скільки потрібно йому, а не вам, — і в момент, коли архів справді знадобиться, з'ясовується, що глибина зберігання менша за час, за який ви помітили проблему.

Окремої згадки вартий 8.12, запобігання витоку. Це не обов'язково дорога система: у невеликій компанії роль такого контролю часто виконують прості речі — заборона пересилати вкладення на особисту пошту, обмеження зовнішніх накопичувачів, попередження перед надсиланням листа за межі домену. І навпаки: дорогий інструмент без правил класифікації не спрацює, бо він просто не знає, що саме у вас вважається цінним.

Що вмикати першим, якщо ресурс обмежений

Порядок, який на практиці рятує найчастіше:

1. Резервні копії — і перевірка відновлення. Це єдиний контроль, який працює вже після того, як усе інше не спрацювало.
2. Обмеження прав і багатофакторна автентифікація. Більшість реальних інцидентів починається з чужого облікового запису, а не з витонченого злому.
3. Оновлення й журнали. Перше закриває відомі діри, друге дає змогу зрозуміти, що взагалі сталося.

Решта — важлива, але вона добудовується поверх цих трьох. Компанія, у якої є дорогий міжмережевий екран і немає перевіреного архіву, захищена гірше за ту, у якої все навпаки.

Докази, які попросить аудитор

Правило те саме, що й скрізь у стандарті: немає сліду — немає контролю.

Як обирають, що впроваджувати

Набір заходів не універсальний. Його визначає оцінювання ризиків: спершу з'ясовують, що найцінніше й найвразливіше, і лише потім вмикають контролі. Методику дає ISO 27005, а підсумковий вибір фіксують у Заяві про застосовність. Уся ця конструкція, своєю чергою, живе всередині СУІБ.

Три помилки, які видно одразу

Копії є, відновлення ніхто не пробував. Пункт 8.13 — не про наявність архіву, а про здатність повернути систему до життя. Копія, з якої жодного разу не відновлювалися, — це припущення, а не резервна копія.

Журнали пишуться, ніхто їх не читає. Пункт 8.15 без 8.16 марний: записи накопичуються, аномалії ніхто не помічає. Питання «хто дивиться на ці журнали і як часто» на аудиті ставлять завжди.

Шифрування є, ключ поруч. Пункт 8.24 стосується не лише алгоритму, а й керування ключами. Ключ, який лежить на тому самому диску, що й зашифрований том, не захищає ні від чого.