Пояснення класифікації даних: публічна, внутрішня, конфіденційна та обмежена

Чому класифікація даних важлива

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

Не існує єдиної універсальної схеми найменувань. Деякі рамки використовують мітки, такі як Public, General, Confidential, та Вкрай конфіденційна. Урядові моделі можуть використовувати зовсім інші мітки. Назви можуть змінюватися, але мета лишається тією ж: зрозуміти, яка шкода може статися, якщо інформацію буде розкрито, змінено, втрачено або надіслано невірній аудиторії.

Чотирирівнева модель

Для багатьох команд приватного сектору проста чотирирівнева модель добре працює, бо її легко викладати і практично застосовувати:

• Public
• Internal
• Confidential
• Restricted

Ця модель не є єдино правильною, але вона створює чітку драбину чутливості. Людям не потрібно запам’ятовувати десятки міток. Їм потрібна робоча модель, яку вони дійсно можуть використовувати при відправленні файлу, обміні нотаткою або вирішенні, чи повинен чат-бот бачити вміст взагалі.

1. Публічна

Public інформацію можна поширювати за межі організації без значної шкоди для конфіденційності. Прикладами часто є публічні дописи в блозі, пресрелізи, опублікована документація, затверджені маркетингові матеріали та публічні сторінки продукту.

Публічна не означає неважлива. Вона все ще потребує цілісності та огляду. Але з погляду конфіденційності це найменш ризиковий клас.

2. Внутрішня

Internal інформація призначена для звичайного використання всередині організації. Якщо вона витече, збитки зазвичай обмежені, але вона все ж не призначена для публічного поширення. Внутрішні політики, нотатки зустрічей, матеріали для адаптації, скриншоти лише для внутрішнього використання та звичайна проектна документація часто підпадають під цю категорію.

Тут багато команд стають недбалими. «Не дуже чутливо» не означає «можна ділитися де завгодно». Внутрішні дані все ще мають належати до погоджених систем і потребують певного контролю доступу.

3. Конфіденційна

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

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

4. Обмежена

Restricted інформація є категорією з найвищою чутливістю у типовій чотирирівневій моделі приватного сектору. Розголошення може спричинити серйозну бізнесову, юридичну, фінансову, операційну або безпекову шкоду.

Прикладами можуть бути секрети виробництва, облікові дані root, ключі шифрування, вкрай чутлива архітектура безпеки, матеріали з поглинань, комерційні таємниці та найчутливіші регульовані набори даних. Це інформація за принципом «потрібно знати» з найсуворішими контролями.

Класифікація — це про вплив

Одна з найкорисніших звичок у класифікації даних — припинити запитувати, «Чи це здається чутливим?» і натомість запитати: «Що станеться, якщо це буде розкрито, змінено або надіслано не туди?»

Документ може виглядати нудно і все одно бути чутливим. Таблиця з електронними адресами клієнтів, скриншот з внутрішніми URL або простий текстовий файл з секретами API можуть не виглядати драматично, але вплив розкриття може бути великим. Контекст важливіший за емоції.

Якщо ви вже знаєте, що вашим головним ризиком є надмірне розповсюдження в інтерфейсах чату, поєднайте цю модель з Чого ніколи не слід ділитися з AI‑чатботами щоб мітка класифікації і конкретні приклади підсилювали одне одного.

Класифікація має визначати правила обробки

Система класифікації працює лише якщо кожна мітка змінює поведінку. Мітки без правил обробки — це прикраса.

Як мінімум кожен рівень має відповідати на кілька практичних питань:

• Хто може мати доступ?
• Де це можна зберігати?
• Чи можна надсилати це електронною поштою зовні?
• Чи можна копіювати це в AI‑інструменти?
• Чи потребує це шифрування, погодження або моніторингу?

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

Як це допомагає з AI‑інструментами

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

• Якщо дані Public, спільний доступ до нього через AI‑інструмент зазвичай є низькоризиковим з точки зору конфіденційності.
• Якщо дані Internal, це може бути прийнятним лише в погоджених корпоративних AI‑середовищах, а не автоматично в персональних або публічно доступних інструментах.
• Якщо дані Confidential, зазвичай їх не слід поміщати у споживчі AI‑інструменти за замовчуванням і може знадобитися редагування або затверджений корпоративний робочий процес.
• Якщо дані Restricted, найбезпечнішим припущенням є те, що їх слід тримати поза загальним доступом AI‑інструментів, якщо немає суворо контрольованого і явно погодженого процесу.

Якщо вам потрібна частина рішення щодо контролю приватності, прочитайте Налаштування конфіденційності чату AI . Якщо вас турбують зовнішні дії, інструменти або інтеграції, керівництво з безпеки щодо GPTs, agents, and MCP connectors додає сторону меж довіри в загальну картину.

Практичний спосіб класифікувати інформацію

Коли ви не впевнені, як класифікувати щось, короткий тест на основі впливу зазвичай достатній:

1. Чи призначено це для публічності? Якщо так — швидше за все Публічна.
2. Чи спричинить публічне розкриття невелику або обмежену шкоду? Якщо так, може бути «Внутрішня».
3. Чи завдасть розкриття шкоди клієнтам, працівникам, юридичним зобов’язанням, операціям або довірі? Якщо так — ймовірно, Конфіденційна.
4. Чи спричинить розкриття серйозну шкоду або вимагатиме найвищого рівня захисту? Якщо так — ймовірно, Обмежена.

Цей потік не ідеальний, але він набагато кращий за здогадки. Головна мета — змусити людей зупинитися перед тим, як вони поділяться інформацією у невідповідній системі.

Поширені помилки

Частою помилкою є ставитись до всієї непублічної інформації як до однаково чутливої. Ще одна — надмірне використання найвищої мітки, доки вона не втратить значення. Обидві проблеми послаблюють класифікацію.

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

Офіційні посилання та подальше читання

• Microsoft Learn: Data classification and sensitivity label taxonomy
• Microsoft Learn: Learn about sensitivity labels
• Microsoft Learn: Classification label concepts
• Cyera: What are the Four Levels of Data Classification?
• National Archives: Controlled Unclassified Information
• GOV.UK: Government Security Classifications Policy
• OWASP: Top 10 for LLM Applications

Поширені питання