CIA-триада, AAA и архитектура Zero Trust
Безопасность начинается не с продукта, а с понятной цели. На экзамене Security+ такой целью служит CIA-триада: конфиденциальность (Confidentiality), целостность (Integrity) и доступность (Availability). Это не три взаимоисключающих режима, а критерии, которые нужно сбалансировать для конкретной системы.
CIA-триада
Конфиденциальность означает, что данные видят только разрешённые субъекты. Шифрование диска, разграничение прав, маскирование персональных данных и сетевые ACL снижают риск раскрытия. При этом шифрование не отменяет проблему лишних прав: пользователь с легальным ключом всё равно может прочитать то, что ему доступно.
Целостность — уверенность, что данные и конфигурация не изменены незаметно. Хэши помогают обнаружить подмену файла, цифровая подпись подтверждает автора и неизменность, а контроль версий и журналы дают историю изменений. Целостность важна не только для документов: повреждённая таблица маршрутизации или изменённое правило firewall также опасны.
Доступность означает получение услуги в требуемое время. Резервирование, UPS, балансировка, мониторинг и защита от DDoS поддерживают доступность. Иногда усиление конфиденциальности снижает её: строгая проверка каждого запроса добавляет задержку, а шифрование может усложнить восстановление. Решения принимают по бизнес-критичности и допустимому простою.
AAA и неотказуемость
AAA — это аутентификация, авторизация и учёт действий (Accounting). Аутентификация отвечает на вопрос «кто ты?»; авторизация — «что тебе разрешено?»; учёт — «что произошло и кто это сделал?». Не путайте идентификацию (предъявление имени или идентификатора) с доказательством личности.
Пример: сотрудник вводит логин и подтверждает вход ключом FIDO2 — это аутентификация. После входа система проверяет роль и разрешает чтение, но не удаление — авторизация. SIEM получает запись о чтении файла и результате операции — учёт. Централизованные логи должны иметь синхронизированное время, защиту от изменения и понятный срок хранения.
Неотказуемость (non-repudiation) связывает действие с субъектом так, чтобы тот не мог правдоподобно отрицать его совершение. Цифровая подпись, сертификат, защищённый журнал и корректное управление ключами помогают доказательству. Обычная запись «пользователь вошёл» слабее: общий пароль или общий аккаунт не позволяют надёжно установить автора.
Zero Trust
Zero Trust — не «запретить всё», а принцип «никогда не доверяй автоматически, всегда проверяй». Наличие в корпоративной сети не считается достаточным доказательством. Решение о доступе учитывает личность, устройство, состояние обновлений, риск сессии, ресурс и контекст. Доступ выдают по принципу наименьших привилегий и по возможности ограничивают временем.
Практическая последовательность: инвентаризировать ресурсы и личности; включить MFA; разделить сеть и роли; проверять устройство до выдачи токена; вести телеметрию; регулярно пересматривать права. Zero Trust не равен только микросегментации и не заменяет резервное копирование.
Как применять
Для нового сервиса составьте таблицу угроз: что будет с конфиденциальностью при утечке, с целостностью при подмене, с доступностью при отказе. Затем свяжите контроль с результатом: шифрование защищает конфиденциальность, подпись — целостность и авторство, кластер — доступность. Для AAA задайте уникальные аккаунты, сильную аутентификацию, RBAC и неизменяемые журналы.
Небольшая проверка журналов в Linux:
sudo journalctl --since today -u ssh --no-pager
last -F | head
Ищите аномальные входы, действия вне роли и расхождение времени. Если инцидент затрагивает сразу несколько целей CIA, приоритет определяется риском для людей и бизнеса, а не удобством команды.
Мини-чеклист архитектора
Перед запуском сервиса ответьте, какие данные он обрабатывает, кто владелец и какой ущерб принесёт утечка, подмена или простой. Определите минимально необходимую роль каждого интеграционного аккаунта. Для привилегированных операций используйте отдельное подтверждение и запись причины. Это связывает AAA с управлением риском, а не превращает его в набор галочек.
Zero Trust также требует наблюдаемости. Событие доступа должно содержать субъект, ресурс, действие, устройство, результат и время. Полезно сопоставлять такие события с изменениями прав и обращениями в поддержку. Если политика требует повторной проверки, система должна корректно обрабатывать истёкшую сессию, не оставляя действующий токен в браузере.
При проектировании не обещайте абсолютную безопасность. Цель — сделать несанкционированный путь дорогим, обнаруживаемым и ограниченным по последствиям. Именно так CIA, AAA, неотказуемость и Zero Trust образуют единую модель.
Практическое задание
Закрепите тему на собственной тестовой схеме, не затрагивая рабочие системы. Сначала опишите активы и доверенные границы простыми словами, затем укажите владельца каждого решения. Для каждого риска запишите вероятность, последствия, существующий контроль и остаточный риск. Такой короткий реестр полезнее списка модных продуктов: он показывает, какую именно задачу решает мера и где остаётся пробел.
Проведите проверку в безопасной лаборатории и сохраните результат: время, команду или действие, ожидаемый результат и фактическое наблюдение. Если проверка не удалась, сначала проверьте разрешение, область теста и журналирование, а не усиливайте настройки вслепую. Любое исключение оформите с причиной, сроком и ответственным.
При разборе инцидента отделяйте факт от гипотезы. Факт подтверждается журналом, конфигурацией или воспроизводимым тестом; гипотеза требует дополнительной проверки. Это снижает риск неправильной атрибуции и помогает команде выбрать пропорциональную реакцию. После изменения контроля повторите тест и убедитесь, что доступность бизнеса не пострадала.
Полезный результат обучения — не запомнить термин, а уметь объяснить его на сценарии: какая угроза действует, какой актив затронут, какой контроль сработает первым, что обнаружит событие и как восстановиться. Именно такую цепочку проверяйте при подготовке к Security+. Дисклеймер: материал учебный и не заменяет официальные exam objectives CompTIA.
Комментарии