Триада CIA

Материал опубликован.

НовичокФундамент ~28 мин

Границы темы

Scope: три свойства, через которые описывают ожидаемую защиту информации и последствия инцидента: конфиденциальность, целостность и доступность.

Не рассматриваем: формальную сертификацию, отраслевое регулирование и полный каталог мер защиты. Здесь CIA — инструмент инженерного мышления, а не чек-лист соответствия требованиям.

Что нужно знать заранее

Специальные знания по безопасности не требуются. Достаточно представлять обычный путь серверного запроса: клиент отправляет запрос, сервис проверяет его, читает или изменяет данные и возвращает ответ.

Результаты обучения

После статьи читатель сможет:

1. различать три свойства на конкретных серверных сценариях;
2. описывать не только техническое событие, но и его влияние;
3. превращать абстрактное свойство в проверяемое требование;
4. замечать инциденты, которые затрагивают сразу несколько свойств;
5. объяснять пределы отдельной меры, например шифрования или резервной копии.

Основная модель

Сохранение установленных ограничений на доступ к информации и её раскрытие,Защита информации от неправомерного изменения или уничтожения

и Своевременный и надёжный доступ к информации и возможность её использовать описывают что должно сохраниться, а не какой продукт нужно установить.

Название CIA образовано первыми буквами английских терминов: confidentiality, integrity и availability. В определении NIST целостность шире неизменности байтов: она также включает подлинность информации и подтверждаемость её происхождения.

Диаграмма

FIPS 199 использует эти три свойства для категоризации информации и систем по потенциальному влиянию их компрометации. Для серверного инженера важна та же причинная цепочка: актив → нарушенное свойство → ущерб → требование → мера защиты.

Основные термины

Термин	Рабочее определение	Пример
Актив	То, что имеет ценность и требует защиты	Заказ, токен, ключ, возможность оформить платёж
Субъект	Пользователь, сервис или процесс, выполняющий действие	Клиент, фоновый обработчик, администратор
Инцидент	Событие, которое нарушило или реально угрожает ожидаемой защите	Утечка экспорта, подмена цены, длительный отказ
Влияние	Наблюдаемый ущерб людям, операциям или организации	Раскрытие данных, неверное списание, остановка продаж
Мера защиты	Организационный или технический механизм снижения риска	Авторизация, ограничение БД, лимит, резервная копия

Три свойства на одном backend-сценарии

Рассмотрим API заказов GET /orders/:id и PATCH /orders/:id.

Событие	Конфиденциальность	Целостность	Доступность
Клиент читает чужой заказ	Нарушена	Обычно не затронута	Не затронута
Ошибка округления меняет итоговую сумму	Не обязательно затронута	Нарушена	Сервис может отвечать
База недоступна 40 минут	Не обязательно затронута	Возможна, если потеряны записи	Нарушена
Украденный аккаунт отменяет заказ и выгружает адрес	Нарушена	Нарушена	Может быть затронута для владельца

Одна строка не обязана попадать ровно в одну колонку. CIA — три независимых вопроса, которые нужно задать одному событию.

End-to-end сценарий

Пользователь запрашивает экспорт заказов:

Диаграмма

• Конфиденциальность зависит от идентификации, авторизации, фильтра по организации и защиты ссылки на файл.
• Целостность зависит от корректного запроса, неизменности результата при передаче и достоверности журнала аудита.
• Доступность зависит от базы, очереди экспорта, хранилища, лимитов и плана восстановления.

Что происходит под капотом

Свойство становится инженерным только после появления наблюдаемого условия.

Свойство	Слабая формулировка	Проверяемая формулировка
Конфиденциальность	«Данные защищены»	Пользователь организации 42 не получает строки другой организации ни через API, ни через экспорт
Целостность	«Заказ корректный»	Итог равен сумме позиций по утверждённым правилам; изменение связано с автором и версией записи
Доступность	«Сервис всегда работает»	За 30 дней успешно завершено не менее 99,9% чтений заказа; восстановление записи проверено учебным тестом

Свойство не равно механизму

TLS — механизм защиты транспортного канала. Он может поддерживать конфиденциальность и целостность данных при передаче, но не исправит ошибку авторизации, неверный SQL UPDATE или исчерпанный пул соединений.

Минимальный воспроизводимый пример

Исходный сценарий:

В 10:05 API начал возвращать 503 для чтения заказов.
В 10:11 система автоматически переключила трафик на реплику.
После переключения 27 заказов показывали предыдущий статус.
Признаков доступа к данным других клиентов пока не найдено.

Заполните матрицу фактами, не предположениями:

Свойство	Статус	Доказательство	Открытый вопрос
Конфиденциальность	Не подтверждено нарушение	Признаков межклиентского доступа нет	Полны ли журналы и охвачены ли все пути чтения?
Целостность	Требует проверки	27 ответов содержали предыдущую версию	Изменена или потеряна запись либо нарушено требование свежести?
Доступность	Нарушена	API возвращал 503 шесть минут	Допустимы ли шесть минут по требованию доступности?

Ожидаемый результат

У разбора есть отдельные выводы по каждому свойству, наблюдаемое влияние и вопросы, для которых пока недостаточно данных. Устаревший ответ сам по себе ещё не доказывает неправомерное изменение или уничтожение записи: сначала нужно проверить источник истины и заявленное требование к свежести. Фраза «безопасность нарушена» заменена проверяемыми утверждениями.

Как диагностировать ошибку классификации

• Если вывод описывает продукт («у нас есть WAF»), вернитесь к активу и влиянию.
• Если событие помещено только в одну колонку, задайте два оставшихся вопроса.
• Если «не нарушено» основано на отсутствии оповещения, запишите «нет доказательств» и проверьте полноту телеметрии.

Ограничения и trade-offs

Три свойства могут конфликтовать на уровне реализации:

Решение	Выигрыш	Цена или риск
Строгая повторная аутентификация	Конфиденциальность и целостность	Дополнительная задержка и риск недоступности провайдера учётных данных
Синхронная запись в несколько регионов	Целостность и восстановление	Выше задержка и больше сценариев частичного отказа
Подробный аудит	Обнаружение нарушений целостности	Стоимость хранения и риск утечки через сами логи
Агрессивное кеширование	Доступность и низкая задержка	Устаревшие данные и сложность сброса кеша

Компромисс не означает, что одним свойством можно пренебречь. Он означает, что требования и остаточный риск должны быть явными.

Failure modes и типичные ошибки

1. Считать CIA списком технологий. Шифрование, резервные копии и мониторинг ничего не гарантируют без конкретного сценария и проверки.
2. Сводить целостность к контрольной сумме. Хеш помогает обнаружить изменение байтов, но не доказывает корректность бизнес-операции или полномочия автора.
3. Считать доступность только временем работы процесса. Живой процесс, возвращающий неверные данные или не завершающий запрос, не предоставляет полезную услугу.
4. Игнорировать людей и операции. Ошибка администратора, истёкший сертификат и непроверенное восстановление из резервной копии затрагивают те же свойства.
5. Объявлять отсутствие инцидента по отсутствию логов. Ненаблюдаемость — не доказательство безопасности.

Практическое задание

Задача: выберите одну операцию своего сервиса — регистрацию, оплату, загрузку файла или восстановление пароля — и составьте CIA-карточку.

Для каждого свойства укажите:

1. защищаемый актив;
2. нежелательное событие;
3. влияние на пользователя;
4. одно проверяемое требование;
5. способ получить доказательство выполнения.

Критерии готовности: требования можно проверить тестом, метрикой, журналом или процедурой восстановления; механизмы не подменяют формулировку свойства.

Подсказка

Для токена восстановления пароля спросите: кто может его увидеть, кто может изменить состояние аккаунта и что произойдёт, если почтовый сервис недоступен.

Проверка знаний

ИНТЕРАКТИВНАЯ ПРОВЕРКА

Проверка знаний

0 / 4

01Пользователь получил экспорт заказов другого клиента. Какое свойство нарушено в первую очередь?

КонфиденциальностьЦелостностьДоступность

02Какие меры непосредственно поддерживают целостность заказа?

Ограничения и транзакции в базе данныхПроверка права изменять этот заказЖурнал значимых изменений с защитой от незаметной подменыОбщедоступная копия всех заказов только для чтения

03Если база данных зашифрована, три свойства CIA обеспечены автоматически.

ВерноНеверно

04Восстановите порядок первичного разбора инцидента.

1. Определить затронутые свойства CIA
2. Зафиксировать наблюдаемое событие
3. Описать влияние на пользователя и процесс
4. Проверить сработавшие и отказавшие меры

Проверено: 0 из 4

Самопроверка

1. Почему утечка резервной копии может не затронуть рабочий API, но всё равно нарушает CIA?
2. Чем целостность бизнес-операции отличается от целостности файла?
3. Когда недоступность защитной меры сама становится риском?

Ответы и критерии

1. Конфиденциальность относится к информации независимо от места хранения; копия остаётся активом.
2. Совпадение байтов не доказывает допустимость перехода состояния, полномочия субъекта и соблюдение инвариантов.
3. Когда отказ меры блокирует легитимную операцию или провоцирует небезопасный обход; поэтому для критичных мер проектируют поведение при отказе и восстановление.

Краткое резюме

• CIA классифицирует защищаемые свойства, а не продукты безопасности.
• Начинать нужно с актива и влияния, затем формулировать проверяемое требование.
• Один инцидент может одновременно нарушить конфиденциальность, целостность и доступность.
• Мера защиты полезна только вместе с доказательством, границами и сценарием отказа.

Следующие шаги

В статье «Моделирование угроз» CIA-требования превращаются в конкретные сценарии: кто атакует, через какую границу, какое свойство нарушает и что система делает в ответ.

Источники

• FIPS 199 — определения трёх свойств и связь между их нарушением и потенциальным влиянием.
• NIST SP 800-53 Rev. 5, Release 5.2.0 — актуальный каталог семейств организационных и технических мер безопасности.
• NIST Glossary: integrity — расширенное определение целостности и ссылки на первичные публикации NIST.