Дизайн VDC. С чего надо начинать

Введение

Информационная система с точки зрения пользователя хорошо определяется в ГОСТ РВ 51987 - «автоматизированная система, результатом функционирования которой является представление выходной информации для последующего использования». Если рассматривать внутреннюю структуру, то по сути любая ИС является системой реализованных в коде взаимосвязанных алгоритмов. В широком понимании тезиса Тьюринга-Черча алгоритм (а сл-но ИС) осуществляет трансформацию множества входных данных в множество выходных данных.
Можно даже сказать, что в трансформации входных данных и есть смысл существования информационной системы. Соответственно ценность ИС и всего комплекса ИС определяется через ценность входных и выходных данных.
Исходя из этого проектирование должно начинаться и брать за основу данные, подстраивая архитектуру и методы под структуру и значимость данных.

Хранимые данные
Ключевым этапом подготовки к проектированию является получение характеристик всех наборов данных, планируемых к обработке и хранению. Эти характеристики включают в себя:
- Объем данных;
- Информация о жизненном цикле данных (прирост новых данных, срок жизни, обработка устаревших данных);
- Классификация данных с т.з. влияния на основной бизнес компании (то триаде конфиденциальность, целостность, доступность) вместе с финансовыми показателями (напр. стоимость утери данных за последний час);
- География обработки данных (физическое расположение систем обработки);
- Требования регуляторов по каждому классу данных (напр. ФЗ-152, PCI DSS).

Информационные системы

Данные не только хранятся, но и обрабатываются (трансформируются) информационными системами. Следующим шагом после получения характеристик данных является максимально полная инвентаризация информационных систем, их архитектурных особенностей, взаимозависимостей и требований к инфраструктуре в условных единицах к четырем видам ресурсов:
- Процессорная вычислительная мощностьl;
- Объем оперативной памяти;
- Требования к объему и производительности системы хранения данных;
- Требования к сети передачи данных (внешние каналы, каналы между компонентами ИС).
Требования при этом должны быть на каждый сервис/микросервис в составе ИС.
Отдельно необходимо отметить обязательное для корректного проектирования наличие данных по влиянию ИС на основной бизнес компании в виде стоимости простоя ИС (рублей в час).

Модель угроз

В обязательном порядке должна быть в наличии формальная модель угроз, от которых планируется защищать данные / сервисы. При этом модель угроз включает в себя не только аспекты конфиденциальности, но и целостности и доступности. Т.е. например:
- Выход из строя физического сервера;
- Выход из строя коммутатора top-of-the-rack;
- Разрыв оптического канала связи между ЦОД;
- Выход из строя оперативной СХД целиком.
В некоторых случаях модели угроз пишутся не только для инфраструктурных компонентов, но и для конкретных ИС или их компонентов, как например отказ СУБД с логическим разрушением структуры данных.
Все решения в рамках проекта по защите против не описанной угрозы являются излишними.

Требования регуляторов

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

Целевые показатели RPO / RTO

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