Comments 6
оч странный текст, почему вы считаете работу руками бесплатной? такие же деньги, в тч на поддержке, простой пример - обновили железо/ПО и вкл-выкл snmpv3 уже по-другому. или система мониторинга при обновлении отрыгнула работать с v3.
это полностью эквивалентно лицензированию - тоже работы длящиеся по времени.
Видимо, "0 рублей" подразумевается как "0 рублей сверх зарплаты".
Меня больше смутил момент про "бесплатные" резервные копии - место стоит денег, и зачастую бОльших, чем отдельное АРМ для администрирования
Справедливо. Пометка «0 ₽» отвечала ровно на один вопрос: надо ли идти в бюджет за новой закупкой. Труд администратора в неё не заложен, хотя именно он и есть основная стоимость.
Про snmpv3 согласен: после каждого обновления железа настраивать заново, разовой такую работу не назовёшь.
«Ноль рублей сверх зарплаты» сформулировано точнее, чем у меня. Я исходил из того, что администраторы в организации уже есть, а рост задач конвертируется в деньги косвенно, через нагрузку и зарплаты, минуя счёт от вендора. В тексте этого не было, претензия честная.
Про резервные копии тут прямая ошибка. Пункт 4.2 требует три копии на двух типах носителей, одну из них обособленно, это место и железо. «0 ₽» там стоять не должно.
Поправил: у 4.2 теперь «зависит», в легенде оговорка про «ноль сверх зарплаты», в конце деление на капитальные затраты и операционные. Капитальных четыре, остальное операционные, и нулевыми они не бывают. Про капасити принимаю тоже: когда специалист один на всю инфраструктуру, разница между «не нужна закупка» и «некому делать» исчезает. Спасибо за ваши комменты, теперь стало точнее!
Кейс - инфраструктура в ДЦ. Как исключить удаленное администрирование? (Сейчас выделенный АРМ есть, но он ВМ де-факто, с доступным RDP через танцы с бубном. Аудит есть, публикаций эндпойнтов на периферии таки нет)
Документ - реально - описывает то, что надо сделать для географически локализованного на уровне здания юнита {компании, подразделения, etc}. Там эти требования реально (а не на бумажке) выполнимы. Есть чёткий периметр, разделяющий "снаружи" и "внутри", есть возможность контролировать сеть до уровня проводов и иметь чёткую карту сети, с разделением сетей без костылей с VLAN, а физически, на разных проводах, есть возможность контролировать физический доступ до критичных устройств.
Особенно абсолютно правильные требования к контролирующему устройству - которых, по хорошему вообще должно быть 2-3 и располагаться они должны вообще в разных комнатах с разным уровнем физического допуска (контроль устройств ядра сети; контроль mission-critical сервисов; обычное АРМ админа, с которого доступно все остальное и интернет, но без любого доступа на устройства из п.1 и 2).
Однако стоит вступить в постковидную эпоху и распределённые формы организации юнита, то документ разъезжается по швам: облака иначе чем удалённо в принципе не администрируются (никто не прописывает штатного админа в ДЦ, который может быть далековато от места работы юнита) - кроме случаев коллока, когда арендуется лишь место и сеть, но и то, только при установке и выезде из него. Гибридный / удалённый формат работы администратора, если следовать документу, тогда тоже исключается. Нет намёка на аварийные сценарии работы, кроме "сидим в здании и по памяти со смартфона чиним".
Плюс не прописано: с заканчивающейся поддержкой - чьей? - вендора или сообщества? Переход на community-каналы обновления при наличии достаточных оснований для доверия - это продление поддержки или компенсаторные меры? Самоподдержка (внутри юнита), когда прошивка и пакеты аудируются, правятся, собираются и деплоятся самостоятельно - это поддержка или компенсаторные меры? Туда же вопрос про внутренние форки.
Короче, да. Правильно, полезно, вот только отражает реальность до массовых удалёнок и применимо (для части мер) только для больших, локализованных на конкретной территории юнитов, потому что...правильно, компромиссы.
ФСТЭК описала периметр в 35 пунктах. 26 из них не стоят ни рубля