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