Что происходило до внедрения
Сервисы и сотрудники обращались к внешним провайдерам напрямую. Никто не проверял, что именно уходит наружу.
Решение и его эффект
Поставили обязательный шлюз: весь внешний трафик идёт через одну точку. Шлюз классифицирует данные, вырезает секреты, применяет правила минимизации и журналирует запросы. В единицу времени используется один провайдер, автоматических подмен нет.
Как встроили в ИТ-контур
Шлюз стоит между внутренними сервисами и внешним выходом. Политики, классификация и журнал запросов находятся внутри контура.
Схема упрощена. Полную архитектуру и состав интеграций показываем на встрече по NDA.
Что получил заказчик
- внешний выход один и контролируется
- секреты и лишние персональные данные не уходят наружу
- по журналу видно, кто и что отправлял
- смена провайдера выполняется осознанно, а не автоматически
Показатели проекта раскрываем в согласованном диапазоне. Точные данные, имена и архитектуру покажем на встрече по NDA.
Что учли по требованиям заказчика
Секреты и лишние персональные данные вырезаются до отправки. Журнал показывает, кто и что отправлял.
Страж внешнего выхода
проверяет каждый запрос к внешней модели
Как работает
- Принимает запрос от сервиса или сотрудника.
- Классифицирует данные и вырезает секреты и лишние персональные данные.
- Применяет политику и отправляет запрос через одну точку.
- Пишет журнал: кто, что, какой профиль, что вырезано.
Границы
- Один провайдер в единицу времени, без автоматических подмен.
- Запрещённые данные блокируются до отправки.
- Каждый запрос и решение видны в аудите.
Что использовали
У нас похожая задача
Разберём процесс, определим метрику и скажем, подходит ли здесь пилот. Покажем архитектуру этого кейса на встрече по NDA.