Comments 9
Из вахтера человека перешли к боту-вахтеру, а что если подумать о реальных причинах напиливания дыр и дальнейшей проблемы управления большим числом записей и о каком-то удобным для пользователя способе организации связности с общими сервисами (как у вас в пример KMS)? Подглядеть как делают взрослые https://cloud.google.com/vpc/docs/configure-private-service-connect-apis#supported-apis или https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview
Ведь по сути цель таких вот правил не создать записи вида IP->IP Port->Port Proto->Proto, а получать связность с каким-то сервисом (как у вас в примере Windows KMS)?
К слову, промежуточной вехой в развитии у вас точно будут какие-то глобальные (универсальные) правила открывающие на все сети самые популярных/всегде нужные сервисов (ведь не может быть что у вас нет общих "shared" сервисов?)
То есть должно быть что я как пользователь в интерфейсе выбирают сервис из списка доступных? Мы шли иным путем, идеи свернуть в эту сторону есть. Но суть сетевых доступов у нас как раз в том, что сетевой админ получает четко сформулированное правило которое ему просто нужно перенести на межсетевой экран. С автоматизацией переноса сетевых доступов у нас пока туго. Возможно то о чем вы пишете будет через год-два.
Перечитал свой комментарий, как-то он недобро заучит, видимо я немного в свой реальности.
касаемо подхода, как сама автоматизация это конечно хорошее лучшего, которое решает, экономит время сетевого администратора.
Моя реальность видимо более динамичная и скажем так разнообразная и тот же пользователь подсети порой не знает как сформулировать правило или группу правил чтобы открыть доступ. Яркий пример это сервис в автомасштабируемом кластере, который хочет доступ к другому сервису в такой же сложной конфигурации кластера и как результат - сложное расследование почему иногда где-то что-то не соединяется, потом дописывание правил. А ещё когда владелец второго сервиса расширяет свою подсеть новым блоком, он рискует сделать для клиентов работающий сервис после этого частично доступным.
… а еще есть угроза исчерпания квоты записей в firewall сервисе.
Сложно натянуть динамические сервисы и и очень статичные сетевые правила.
Если согласование и прорубание новых доступов занимает у ответственных сотрудников столько времени, что автоматизация даёт ощутимую пользу - имхо, что-то пошло не так в плане архитектуры сети.
У нас такая сетевая политика: кто-то указал твой IP в сетевом доступе, будь добр поучаствуй в согласовании. Ну а я как безопасник рассматриваю все доступы на последнем этапе, мало ли что там открывают - жесткий "текущий контроль" исполнения политики сетевой безопасности и регламента внесения изменений в правила межсетевого экрана. И да у нас сотни информационных систем.
По срокам как раз нормально в части согласования с безопасником - 1 день максимум если по доступу нет вопросов при ручном согласовании, но бот его не смог согласовать, и минуты если бот смог обработать доступ.
Расскажите, пожалуйста, с каких пор слово "доступ" имеет множественное число? Из какого жаргона это пришло?
Плюс-минус с момента появления, наверное - а что, есть противоречащие этому факты?
Автоматизация согласования сетевых доступов