В связи с моей болезнью заранее прошу прощения, если мои посты будут содержать некоторые неточности.
В предыдущей публикации я обещал кратко рассказать о том, чем системы, ориентированные на безопасность, отличаются от «обычных». Тема вызвала живой интерес, и в комментариях быстро сформировались две противоположные точки зрения:
- полная защита персональных данных невозможна;
- полная безопасность персональных данных достижима.
Я являюсь сторонником второй позиции. В этой статье я подробно объясню, как можно построить систему, гарантирующую абсолютную защиту информации.
Основополагающая аксиома
Начну с ключевого принципа информационной безопасности: единственным реальным показателем её эффективности для ИТ-инфраструктуры является полная или почти полная безуспешность попыток её взлома.
Пять шагов к абсолютной безопасности
Построение защищённой системы — это комплексный процесс, который можно разбить на несколько фундаментальных этапов.
Шаг 1: Организация и управление
Безопасность должна быть приоритетом номер один. Сотрудники, отвечающие за информационную безопасность (ИБ), должны обладать высшими полномочиями в компании. Часто правила ИБ воспринимаются как обременительные ограничения, мешающие бизнес-процессам, что вызывает недовольство как у руководства, так и у рядовых сотрудников. Преодолеть это сопротивление — первостепенная задача.
Шаг 2: Психологическая подготовка
Информационная безопасность — это война в киберпространстве. Ключевое отличие солдата от гражданского — психология и дисциплина. Солдат действует исходя из принципа «должен», а не «хочу». Броня может быть неудобной, а камуфляж — некрасивым, но они необходимы. Точно так же в ИБ: расслабленность и пренебрежение правилами ради удобства неминуемо ведут к поражению. Слово «надо» должно стать главным в лексиконе каждого сотрудника.
Шаг 3: Стратегическое планирование
Безопасность строится сверху вниз, как пирамида. На вершине находятся стратегические решения:
- Классификация данных: определение, какую именно информацию необходимо защищать.
- Оценка стоимости: какой ценой компания готова обеспечить эту защиту.
- Расстановка приоритетов: какие данные или процессы можно в крайнем случае «пожертвовать».
- Определение защищаемых бизнес-процессов.
- Установка требуемого уровня защиты для каждого типа данных и процесса.
Всё начинается с полной инвентаризации данных компании, описания инфраструктуры, бизнес-процессов и матриц доступа. Главный стратегический принцип — минимализм:
- Хранить минимально необходимый объём данных. То, что можно не хранить, хранить не нужно.
- Предоставлять доступ к каждой категории данных (кроме публичных) как можно меньшему кругу лиц. Доступ «на всякий случай» недопустим.
- Минимизировать количество программ и оборудования, обрабатывающих данные. Любой неиспользуемый компонент должен быть исключён.
Шаг 4: Тактическая проработка
Каждый стратегический пункт необходимо детализировать. Для этого составляется матрица возможных угроз и мер противодействия по каждому типу данных, каналу связи и бизнес-процессу. Эффективный инструмент для этого — матрица DCRUD (развитие концепции CRUD):
- D — Denial (Отказ в обслуживании): Услуги и данные должны быть доступны только авторизованным пользователям и надёжно заблокированы для всех остальных.
- C — Create (Создание): Возможность создавать новые данные должна быть строго регламентирована и предоставлена только пользователям с соответствующими правами.
- R — Read (Чтение): Чтение данных разрешено исключительно пользователям с необходимыми привилегиями.
- U — Update (Обновление): Все изменения данных должны быть безопасными (с возможностью полного аудита и отката) и выполняться только уполномоченными лицами.
- D — Delete (Удаление): Прямое удаление данных недопустимо. Информацию можно помечать как устаревшую или архивировать, но физическое удаление исключено.
Шаг 5: Дисциплина и ответственность
Самая совершенная инфраструктура и прописанные процессы бесполезны без строгого соблюдения правил. Часто именно руководители становятся слабым звеном: пароли на стикерах, токены, оставленные без присмотра. Типичная реакция на замечание специалиста по ИБ: «Не мешай работать». Нарушения остаются без последствий, что сводит на нет все усилия. Культура безопасности должна внедряться сверху, а за нарушения необходимо нести реальную ответственность.
Практический пример: Защищённое медицинское хранилище
С 2015 по 2016 год я участвовал в качестве эксперта в разработке системы для медицинской компании с нулевой терпимостью к утечкам. Вот её ключевые принципы:
- Инвентаризация: Были определены защищаемые данные — персональные данные пациентов (ФИО, паспорт) и медицинские записи.
- Два контура: Созданы публичное и защищённое хранилища. В публичное попало всё, кроме строго конфиденциальной информации.
- Физическая защита: Защищённое хранилище располагалось в двух зданиях. Серверная — в подвале за железной дверью, постом охраны и дополнительной решёткой. Доступ — только по предварительному распоряжению в строго отведённое время с использованием личного ключа сотрудника.
- Шифрование: Весь обмен данными шифровался как минимум тремя разными ключами.
- Минимальный доступ: Сотрудники видели только необходимую для работы информацию. Например, после первичной регистрации пациент идентифицировался только по имени, отчеству и UUID.
- Анонимизация направлений: Направления на анализы и их результаты привязывались только к UUID, без указания ФИО.
- Контроль оборудования: У сотрудников была униформа без карманов. Запрещалось проносить любое личное электронное оборудование, кроме механических часов. Нарушение вело к немедленному увольнению.
- Рабочие станции: Урезанный Linux, браузер в режиме киоска и отечественный СКЗИ. Минимум информации на экране.
- Сетевая изоляция: Отсутствие Wi-Fi. Все кабели — в защищённых экранированных каналах.
- Запрет удалённого доступа: Полный запрет на любой удалённый доступ к системе.
- Белые списки: Весь обмен данными вёлся строго по предопределённым «белым спискам» с обязательным логированием.
Техническая архитектура
Защищённое хранилище состояло из шести серверов:
- Станция управления: Единственная точка доступа к серверам. У каждого сервера было две сетевые карты: для публичной сети и для закрытого сегмента управления. SSH — только с определённых MAC/IP-адресов.
- Резервный сервер: Хранил зашифрованные бэкапы.
- Сервер ключей: Генерировал и хранил все ключи шифрования.
- Сервер БД: На нём были запрещены стандартные SQL-операции (SELECT, INSERT и т.д.). Работа велась только через хранимые процедуры (DDL), которые логировали каждое действие. Разрешалось только добавление записей; изменение и удаление — нет. Каждая запись подписывалась ЭЦП.
- Сервер приложений: Микросервисы для работы с БД, АТС и SMS. Одна задача — одно приложение (не более 1000 строк кода). Номера телефонов для связи динамически менялись.
- Сервер управления: Оркестрировал работу всей системы.
Каждый сервер загружался только с уникальной флешки, за которую отвечал отдельный сотрудник.
Как это работало на практике
- Регистрация пациента: Данные с бумажного бланка шифровались на рабочей станции (разные типы данных — разными ключами) и отправлялись в БД. Бумажный оригимент сразу архивировался. В публичном доступе оставался только хеш номера телефона.
- Запись на приём: Пациент звонил, оператор вводил номер. Система по хешу находила UUID пациента и шифровала его для дальнейших операций.
- Приём у врача: Врач видел на своём экране только имя, отчество, историю посещений и результаты анализов конкретного пациента, данные для которого были зашифрованы ключами именно этого врача и его компьютера.
- Лаборатория: Получала и вносила результаты только по UUID, без ФИО.
Ключевые принципы системы
- Все передачи данных — строго поштучные (пакетная передача исключена).
- Многослойное шифрование: ключ оборудования + ключ сотрудника + сервисный ключ. Расшифровать можно только на целевом оборудовании и только целевым сотрудником.
- Ключи оборудования хранятся на нём, ключи сотрудников — на токенах, которые выдаются и сдаются в начале и конце дня.
- Защищённые данные нигде и никогда не хранятся в открытом виде.
- Массовая выгрузка данных технически невозможна.
- Любое нарушение процедуры вызывает немедленную сигнализацию и фиксируется в логах.
Почему эту систему сложно взломать?
Предположим, злоумышленник хочет получить данные. Ему потребуется:
- Физически похитить одну из серверных (но система спроектирована так, что отсутствие любого компонента делает её неработоспособной).
- Украсть все загрузочные флешки у ответственных сотрудников.
- Похитить всех семерых разработчиков, каждый из которых знал только свою часть системы.
- Проанализировать весь код, восстановить матрицу шифрования и только тогда попытаться извлечь данные.
Обычные методы не работают:
- Инсайдер: Нет «точки слива». Чтобы получить данные человека X, нужно знать его номер, записать его на приём и оплатить его. Это вызовет SMS-уведомление у реального пациента и оставит чёткий след в логах.
- Подкуп врача: Врач видел только имя и отчество пациента в конкретный момент времени. Сфотографировать экран бесполезно — нет полной картины, а без UUID и других ключей эти данные не связать с другими записями.
- Доступ к регистратуре или лаборатории: Эти точки видят только UUID и связанные с ними ограниченные действия, но не полные персональные данные.
Печальный эпилог
Эта система успешно работала несколько лет и прошла проверки по 152-ФЗ. Однако после смены руководства клиники её заменили на «более современную и менее сложную систему от одного из лидеров рынка защиты персональных данных». Чтобы передать данные в новую систему, нам потребовалось «взломать» собственную разработку. Это заняло 15 минут и потребовало участия всех разработчиков и администраторов. Новая система имела открытый текст логина и пароля к центральной БД, разрешала удалённые подключения и не имела внутренних ограничений доступа. Это наглядный пример того, как погоня за мнимой простотой и удобством уничтожает реальную безопасность.
Обратите внимание: Как банки проверяют кредитную историю.
Больше интересных статей здесь: Банки.
Источник статьи: Продолжение поста «Банки выступили против нового закона о штрафах за утечки данных».