Почему CIA — это юридический императив, а не учебная модель
К 2026 году ландшафт информационной безопасности Республики Беларусь окончательно сформировался как жестко регулируемая инженерная дисциплина. Времена, когда безопасность строилась «по наитию», прошли. Сегодня классическая триада CIA (Confidentiality, Integrity, Availability) — это не просто слайд из университетской лекции, а фундамент, на котором базируются требования Оперативно-аналитического центра (ОАЦ) и Национального центра кибербезопасности (НЦКБ).
Для ИТ-директоров, владельцев бизнеса и системных архитекторов понимание этой триады критично. В РБ конфиденциальность, целостность и доступность прямо проецируются на обязанности по защите информации в Законе №455-З, Законе №99-З, Указах №196 и №40. Более того, именно эти свойства лежат в основе классификации типовых информационных систем (ИС), утвержденной в приложении к Положению о порядке технической и криптографической защиты информации (Приказ ОАЦ №66 в актуальной редакции).
В этом руководстве мы отойдем от абстракций и разберем, как требования регулятора трансформируются в конкретные настройки серверов (nginx, iptables), политики аудита и архитектурные решения для конкретных классов систем (от 3-ин до 4-дсп).
2. Нормативный базис: Связь законов и свойств безопасности
Прежде чем переходить к настройке, необходимо понимать, "откуда растут ноги" у требований. Аудиторы при аттестации проверяют не "безопасность вообще", а выполнение конкретных пунктов законодательства.
2.1. Закон №455-З «Об информации, информатизации и защите информации»
Это конституция цифрового пространства РБ.
- Конфиденциальность: Закон вводит понятие информации ограниченного распространения (ИРиПКО) и требует исключения неправомерного доступа к ней.
- Целостность и Доступность: Закреплена обязанность владельца ИС обеспечить достоверность данных, их сохранность и возможность использования уполномоченными лицами.
- Императив: Государственные информационные системы (ГИС) не могут эксплуатироваться без аттестата соответствия системы защиты информации (СЗИ).
2.2. Указ Президента №40 «О кибербезопасности»
Документ, изменивший правила игры для критической инфраструктуры.
- Фокус: Мониторинг и реагирование. CIA-триада здесь рассматривается через призму инцидентов.
- Требование: Если целостность нарушена (взлом) или доступность потеряна (DDoS), субъект обязан уведомить НЦКБ. Это требует внедрения средств обнаружения (EDR, SIEM).
2.3. Закон №99-З «О защите персональных данных»
- Оператор ПД обязан обеспечить техническую и криптографическую защиту.
- Нарушение конфиденциальности ПД (утечка) — это прямой штраф и ответственность.
3. Классификация информационных систем: Фундамент ТКЗИ
Самая частая ошибка при внедрении СЗИ — неверное определение класса системы. В соответствии с Приложением 1 к Положению о порядке ТКЗИ, классы типовых ИС жестко регламентированы. От класса зависит объем требований (профиль защиты).
Определяющих факторов всего два: Тип обрабатываемой информации и Наличие подключения к открытым каналам (Интернет).
3.1. Системы без выхода в Интернет (Локальный контур / Интранет)
Эти системы считаются более защищенными за счет физической изоляции от глобальной сети.
КлассТип информацииПример4-инПерсональные данные (кроме специальных)Локальная база пропусков сотрудников (ФИО, должность).4-спецСпециальные ПД (кроме биометрии/генетики)Внутренний архив медицинских карт в больнице (без интернета).4-бгБиометрические и генетические ПДЛокальная система дактилоскопии или СКУД по лицу (изолированная).4-юлКоммерческая тайна, охраняемая тайна юрлицаВнутренняя система R&D, ноу-хау предприятия.4-дспСлужебная информация ограниченного распространенияВнутренний документооборот госоргана с грифом "ДСП".
3.2. Системы с подключением к Интернету (Публичные / Сетевые)
Самая распространенная категория в 2026 году. Подключение к открытым каналам автоматически повышает класс до 3-го, требуя более серьезных мер защиты (МЭ, IDS/IPS, VPN).
КлассТип информацииПример3-инПерсональные данные (кроме специальных)Интернет-магазин, CRM-система, сайт услуг.3-спецСпециальные ПД (кроме биометрии/генетики)Телемедицина, онлайн-запись в поликлинику с диагнозами.3-бгБиометрические и генетические ПДОблачная система идентификации, банковская биометрия.3-юлКоммерческая тайна, охраняемая тайна юрлицаB2B-портал для партнеров, облачная бухгалтерия.3-дспСлужебная информация ограниченного распространенияСистема межведомственного взаимодействия (СМДО) через защищенные каналы.
Важно: Если ваша система обрабатывает ПД клиентов и имеет выход в интернет (даже просто для обновлений сервера), она автоматически попадает в класс 3-ин (или выше), а не 4-ин.
4. Конфиденциальность (Confidentiality): Реализация и Контроль
Для классов 3-ин, 3-спец, 3-дсп обеспечение конфиденциальности — задача №1.
4.1. Технические меры защиты
Согласно Перечню требований (Приложение 3 к Приказу №66), необходимо реализовать:
- Управление доступом (Identification & Authentication):Запрет на использование общих учетных записей (root, admin).
Принудительная смена паролей (политика сложности).
Мультифакторная аутентификация (MFA) для удаленного доступа (обязательно для классов 3-й группы). - Криптографическая защита:Использование протоколов TLS 1.2 или 1.3.
Для передачи служебной информации (классы 3-дсп, 3-юл) часто требуется применение средств, имеющих сертификат соответствия РБ (например, BelVPN Gate, клиенты AvPass/AvToken). - Защита периметра:Межсетевое экранирование (Firewall) с блокировкой всего, что не разрешено явно (Default Deny).
4.2. Практика: Настройка безопасного веб-сервера (для класса 3-ин)
Для системы класса 3-ин (интернет-магазин с ПД) критически важно правильно настроить шифрование канала.
Пример конфигурации Nginx (Hardening):
server {
listen 443 ssl http2;
server_name portal.example.by;
# Сертификаты (для ГИС - от республиканского УЦ, для коммерции - GlobalSign/Let's Encrypt)
ssl_certificate /etc/ssl/certs/portal.crt;
ssl_certificate_key /etc/ssl/private/portal.key;
# Отключаем устаревшие протоколы (TLS 1.0/1.1 запрещены)
ssl_protocols TLSv1.2 TLSv1.3;
# Приоритет серверных шифров
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
# HSTS (HTTP Strict Transport Security) - заставляет браузеры использовать только HTTPS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
# Защита от clickjacking (X-Frame-Options)
add_header X-Frame-Options DENY;
}
4.3. Риски и угрозы конфиденциальности
- SQL-инъекции: Выгрузка базы данных 3-спец через уязвимость в веб-форме.
- IDOR (Insecure Direct Object Reference): Перебор ID в URL (/user/1001, /user/1002) для доступа к чужим анкетам.
- Инсайд: Сотрудник с правами администратора копирует базу на флешку (решается DLP-системой и организационными мерами).
5. Целостность (Integrity): Доверие к данным
Для классов 3-юл (финансовые данные) и 3-дсп (документы) целостность важнее всего. Изменение одной цифры в платежке или реестре прав может нанести ущерб больше, чем простое чтение.
5.1. Технические меры защиты
- Контроль целостности файлов (FIM - File Integrity Monitoring):Регулярная проверка хэш-сумм исполняемых файлов и конфигураций.
Инструменты: AIDE, Tripwire, OSSEC (Wazuh), модули Kaspersky Endpoint Security. - Электронная цифровая подпись (ЭЦП):Юридически значимые действия в системе должны подписываться личным ключом пользователя (ГосСУОК).
- Журналирование (Logging):Логи действий не должны храниться там же, где они генерируются. Злоумышленник первым делом чистит /var/log/auth.log.
Требуется централизованный сбор логов (SIEM или Log Server).
Продолжение на сайте redsec.by >>>