ACL и наткнулся на такие правила:130 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 80
140 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 443
....
290 permit tcp 192.0.2.0 0.0.0.255 198.51.100.0 0.0.0.31
....
410 permit tcp host 192.0.2.15 host 198.51.100.10 eq 443
...
470 permit object-group WEB_SERVICES 192.0.2.0 0.0.0.255 198.51.100.0 0.0.0.31
И это типичная ситуация в больших проектах, когда изменения принимаются ситуативно. К такому приходишь почти всегда, даже тогда когда первоначально есть идеально проработанный план, а исполнителем и архитектором является всего один человек. Вопрос только в степени.
Это не решается автоматизацией, автоматизация поможет держать в одинаковом состоянии 1000 устройств, но это можно сделать и вручную, если изменения происходят не так часто. Это не решается и централизованным управлением a'la Cisco ISE или SD-Access, наличием source of truth. Как только груз накопившегося переваливает за возможность одному человеку охватить это за приемлемое время, изменения будут вноситься по факту, чтобы заработало здесь и сейчас без анализа всего предыдущего.
Чем больше людей вовлечено в этот процесс, тем система быстрее придёт к этому состоянию, потому что это не вопрос архитектуры и возможности вносить изменения, даже если всё это заложено изначально, то почти невозможно донести это понимание до каждого кто что-то меняет. С одним человеком степень этого будет меньше, но тут вопрос времени и частоты изменений тоже важен. Через год даже сам автор системы с трудом вспомнит заложенную в неё концепцию, не потратив на это достаточное время, но это надо захотеть сделать и потратить.
Добавим сюда фактор наименьшего необходимого в ИБ, когда каждому даётся ровно минимум требуемых для работы прав и линейный исполнитель может вообще не видеть конфигурацию целиком. Ведущий специалист не видеть то что делается в соседней команде и команды в целом не знать замыслов архитектуры, оставаясь только в рамках своих обязанностей. В этом случае мы буквально своими руками убиваем возможность не повторятся.
Рано или поздно, всё скатывается к мгновенным изменениям здесь и сейчас, чтобы работало, без оглядки на фундамент. Можно было бы вспомнить про Waterfall и Аgile и мир основанный на правилах "чистого кода" без запаха. Но не забываем, что даже в этом мире, нужен регулярный рефакторинг, включённый в эту концепцию. Но как и регулярный аудит, он мало помогает, фактически каждый раз приходится осознавать, считай проектировать, систему заново, что тоже в итоге приходит к ситуативным исправлениям.
Выход, заморозить систему и наслаждаться красотой построенного ничего не меняя, так мы сейчас смотрим на код первого Doom. Представьте, что все последующие версии были бы изменениями, а не новыми системами. Ещё можно жёстко ограничить вариативность, т.е. не давать внести изменения если что-то похожее уже было раньше, реализуемо, но тут у нас качество основанное на форме контроля, мы запрещаем себе помимо прочего делать улучшения вне заданных рамках, фактически заморозив систему.
Можно исключить человека, совсем, в некоторой степени это в том числе и разные графические интерфейсы того же SD-Access, когда накидываются высокоуровневые условия, реализуемые потом конфигурациями устройств, но тут уже мы имеем ситуативность в этих высокоуровневых правилах. Шаг который все хотят думать что заработает, как минимум, на него переключились маркетологи это ИИ, который сменил собой предыдущую маркетинговую штуку - автоматизацию. Делегируем и больше не смотрим что получается, своего рода страусиный подход, но вполне рабочий, думать о системе как о чёрном ящике с ИИ командной строкой. Признание того что все предыдущие методы не возымели успех.