КБП

Краткое описание назначения и применения продукта

Продукт – шлюз, который отправляет данные от некоторых устройств в облако для пользователя.

Ценности продукта и негативные события в их отношении

Роли пользователей

Контекст

Базовый сценарий

Основные блоки шлюза

Архитектура (HLA) v.0.01

Базовый сценарий + HLA

ЦПБ-v1

Цели безопасности

1. В облако попадают данные только от аутентичных девайсов
2. В облако передаются только валидные данные
3. Данные передаются только в аутентичное и авторизованное облако

4. Шлюз обрабатывает только аутентичные запросы от авторизованных клиентов

   Предположения безопасности

5. Девайсы благонадёжны

Негативные сценарии

Негативный сценарий 1. В облако передаются данные от неаутентичных девайсов.

Результат: недостижение цели безопасности 1 - в облаке присутствуют данные от неаутентичных девайсов

Негативный сценарий 2. В облако передаются невалидные данные.

Результат: недостижение цели безопасности 2 - в облаке присутствуют невалидные данные.

Негативный сценарий 3. Данные передаются в неаутентичное и неавторизованное облако

Результат: недостижение цели безопасности 3 - данные передаются в неаутентичное и неавторизованное облако, клиент может получить неверные данные или не получить их вовсе.

Негативный сценарий 4. Шлюз обрабатывает неаутентичные запросы от неавторизованных клиентов

Результат: недостижение цели безопасности 4 - будут выполнены неаутентичные запросы от неавторизованных клиентов, данные могут быть скомпрометированны.

Политика архитектуры

| Компонент |Описание | Сложность |Размер| |———–|——————————–|–|–| |Auth|Выполняет аутентификацию устройств| C | XL | |Gateway|Получает запросы от клиента, получает данные от HUB,отправляет данные в облако, аутентифицирует клиента| C | XL | |HUB|Получает данные от девайса, валидирует данные, кэширует данные до запроса клиента| S | S |

| Компонент | Статус |Комментарий | |———–|——————————–|–| |Auth|Доверенный| Нарушает цб 1 | |Gateway|Повышает доверие| Нарушает цб 1, 3, 4 | |HUB|Повышает доверие| Нарушает цб 2|

Новая архитектура v.0.02

| Компонент |Описание | Сложность |Размер| |———–|——————————–|–|–| |DeviceAuth|Выполняет аутентификацию устройств| C | XL | |HUB|Получает данные от девайсов и передаёт в storage| S | S | |Storage|Хранит последние данные девайсов| C | XL | |ManagerOutput|Валидирует данные, отправляет данные в облако| M | M | |ClientAuth|Аутентификация клиентов| C | XL | |ManagerInput|Получает запрос от клиентов, валидирует полученные данные| M | M |

| Компонент | Статус |Комментарий | |———–|——————————–|–| |DeviceAuth|Доверенный| Нарушает цб 1 | |ClientAuth|Доверенный| Нарушает цб 4 | |ManagerInput|Повышает доверие| Нарушает цб 3, 4 | |ManagerOutput|Повышает доверие| Нарушает цб 1, 2, 3| |Hub|Недоверенный| | |Storage|Недоверенный| |

Базовый сценарий

Политика архитектуры

ЦБП-v2

Цели безопасности

1. Данные ключевых девайсов попадают в облако только после аутентификации
2. От ключевых девайсов в облако передаются только аутентичные данные
3. Ключевые данные передаются только в аутентичное и авторизованное облако

4. Шлюз обрабатывает только аутентичные запросы от авторизованных клиентов

   Предположения безопасности

5. Девайсы предприятия благонадёжны
6. Ключевые девайсы передают зашифрованные данные

Новая архитектура v.0.03

| Компонент |Описание | Сложность |Размер| |———–|——————————–|–|–| |Verifier|Выполняет аутентификацию критических устройств, проверяет подпись переданных данных| M | L | |MainHub|Получает данные от критических девайсов и передаёт в MainStorage| S | S | |MainStorage|Хранит последние данные критических девайсов| С | XL | |MainManagerOutput|Отправляет данные в облако после аутентификации через Verifier| S | L | |ClientAuth|Аутентификация клиентов| M | L | |ClientStorage|Хранит данные клиентов|C|XL| |ManagerInput|Получает запрос от клиентов и передаёт их в ManagerOutput и MainManagerOutput| S | L | |Hub|Получает данные от девайсов и передаёт в Storage| S | S | |Storage|Хранит последние данные девайсов| L | XL | |ManagerOutput|Отправляет данные в облако| S | S | |DeviceStorage|Хранит данные ключевых девайсов|C|XL|

Негативные сценарии

• Взлом MainManagerOutput – передача данных бог знает куда ЦБ3
• Взлом ManagerInput, ClientAuth – левые клиенты ЦБ4
• Взлом Verifier – не будет валидации, левые ключевые девайсы передадут данные ЦБ2, ЦБ1

Архитектура

Базовый сценарий

Мысли про киберимунную разработку

В рамках курса было полезно осознать, что переизбыток библиотек и фреймворков на проектах влечёт
за собой серьёзную нагрузку и ответственность. К сожалению, иногда можно встретить проекты,
в которые добавляют внешние зависимости просто из-за хайпа оных или по другим причинам.
Если учесть, что там могут быть закладки, или банально баги в новых версия, то разработка может
серьёзно дорожать, так как подобное нужно покрывать различными тестами. Кажется, что пока security
architectory больше актуально для сильно чувствительного и важного софта, по типу государственных структур.
Всё-таки в других сферах, когда встаёт вопрос о реализации монитора с потерей rps, кажется, что скорее просто откажутся
от реализации монитора. Банально, если где-то rps потеряли, то его надо как-то дополучить, а это приведёт
к использованию какой-нибудь реактивщины, например, что значительно удорожает производство.