Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 11
оч странный текст, почему вы считаете работу руками бесплатной? такие же деньги, в тч на поддержке, простой пример - обновили железо/ПО и вкл-выкл snmpv3 уже по-другому. или система мониторинга при обновлении отрыгнула работать с v3.
это полностью эквивалентно лицензированию - тоже работы длящиеся по времени.
Видимо, "0 рублей" подразумевается как "0 рублей сверх зарплаты".
Меня больше смутил момент про "бесплатные" резервные копии - место стоит денег, и зачастую бОльших, чем отдельное АРМ для администрирования
Справедливо. Пометка «0 ₽» отвечала ровно на один вопрос: надо ли идти в бюджет за новой закупкой. Труд администратора в неё не заложен, хотя именно он и есть основная стоимость.
Про snmpv3 согласен: после каждого обновления железа настраивать заново, разовой такую работу не назовёшь.
«Ноль рублей сверх зарплаты» сформулировано точнее, чем у меня. Я исходил из того, что администраторы в организации уже есть, а рост задач конвертируется в деньги косвенно, через нагрузку и зарплаты, минуя счёт от вендора. В тексте этого не было, претензия честная.
Про резервные копии тут прямая ошибка. Пункт 4.2 требует три копии на двух типах носителей, одну из них обособленно, это место и железо. «0 ₽» там стоять не должно.
Поправил: у 4.2 теперь «зависит», в легенде оговорка про «ноль сверх зарплаты», в конце деление на капитальные затраты и операционные. Капитальных четыре, остальное операционные, и нулевыми они не бывают. Про капасити принимаю тоже: когда специалист один на всю инфраструктуру, разница между «не нужна закупка» и «некому делать» исчезает. Спасибо за ваши комменты, теперь стало точнее!
Кейс - инфраструктура в ДЦ. Как исключить удаленное администрирование? (Сейчас выделенный АРМ есть, но он ВМ де-факто, с доступным RDP через танцы с бубном. Аудит есть, публикаций эндпойнтов на периферии таки нет)
Пункт 1.8 строже, чем кажется: там «исключить удалённое администрирование», а публикация SSH, RDP и VNC идёт через «в том числе», то есть частным случаем. По букве ваш доступ под него подпадает и без публикации наружу.
Но пункт 6.2 говорит другое. Он требует MFA при административном доступе к инфраструктуре, с которой идёт доступ к пограничным устройствам. Если бы администратор сидел за АРМ физически, эта MFA была бы не нужна.
Выходит, удалённый доступ к самому АРМ документ допускает, запрещая удалённое администрирование устройств напрямую. Это ваш случай. Плюс пункт 1.4 называет PAM средством разграничения такого доступа.
Документ - реально - описывает то, что надо сделать для географически локализованного на уровне здания юнита {компании, подразделения, etc}. Там эти требования реально (а не на бумажке) выполнимы. Есть чёткий периметр, разделяющий "снаружи" и "внутри", есть возможность контролировать сеть до уровня проводов и иметь чёткую карту сети, с разделением сетей без костылей с VLAN, а физически, на разных проводах, есть возможность контролировать физический доступ до критичных устройств.
Особенно абсолютно правильные требования к контролирующему устройству - которых, по хорошему вообще должно быть 2-3 и располагаться они должны вообще в разных комнатах с разным уровнем физического допуска (контроль устройств ядра сети; контроль mission-critical сервисов; обычное АРМ админа, с которого доступно все остальное и интернет, но без любого доступа на устройства из п.1 и 2).
Однако стоит вступить в постковидную эпоху и распределённые формы организации юнита, то документ разъезжается по швам: облака иначе чем удалённо в принципе не администрируются (никто не прописывает штатного админа в ДЦ, который может быть далековато от места работы юнита) - кроме случаев коллока, когда арендуется лишь место и сеть, но и то, только при установке и выезде из него. Гибридный / удалённый формат работы администратора, если следовать документу, тогда тоже исключается. Нет намёка на аварийные сценарии работы, кроме "сидим в здании и по памяти со смартфона чиним".
Плюс не прописано: с заканчивающейся поддержкой - чьей? - вендора или сообщества? Переход на community-каналы обновления при наличии достаточных оснований для доверия - это продление поддержки или компенсаторные меры? Самоподдержка (внутри юнита), когда прошивка и пакеты аудируются, правятся, собираются и деплоятся самостоятельно - это поддержка или компенсаторные меры? Туда же вопрос про внутренние форки.
Короче, да. Правильно, полезно, вот только отражает реальность до массовых удалёнок и применимо (для части мер) только для больших, локализованных на конкретной территории юнитов, потому что...правильно, компромиссы.
Не совсем так, мне кажется. Просто в распределенной среде нужно предусматривать защиту канала, например, шифрованием. Т.е. схема примерно такая - админ по защищенному каналу доходит до АРМ внутри периметра, там авторизуется через MFA и работает с него. А дальше - все по рекомендациям...
Про это в документе рекомендаций нет.
Нет, понятно, что это организуется через доверенное MDM-устройство (ноутбук, нетбук, у админа на нём нет прав админа и жёсткий контроль за evil maid-сценариями: вскрытие устройства, загрузка через что-то кроме доверенного накопителя) + шифрованный канал до АРМ в периметре (п. 1.1 с устройством за воздушным зазором уже отвалился, т.к. для самого поднятия шифрованного канала нужен интернет, если это не какой-нибудь приватный радиомост, п.3.4 тоже практически - админ уже лишен экстренного канала доступа до сбойного оборудования внутри периметра) + доступ в сеть с него. ЕСЛИ оно - это АРМ - есть. По-сути мы обошли п.1.8 и частично, 3.5 - приняв, что устройство с туннелем уже является доверенным.
Если инфраструктура целиком и частично расположена в облаке, а не в серверной, то херится п. 1.1 (особенное, если в облаке крутится критичный сервис, а для облака нужно устройство с выходом в интернет), 3.1 (терпимо херится, но) и 3.4 (совсем херится, особенно если приять абзац выше с удалённой работой).
Ровно то, что я говорю: документ начинает расползаться по швам.
В контексте этого документа "изолировано от Интернет" не означает "отключено физически", я полагаю. Все таки это рекомендации не для систем с гостайной...
Изолировать от Интернета можно межсетевым экраном, который, собственно DMZ и организует. АРМ администрирования выйти в Сеть не может, но к нему можно подключиться через туннель (VipNet, Континент и т.д. OpenVPN, в крайнем случае).
Насчет DMZ есть оговорка "... кроме регламентированного взаимодействия..." - это вот как раз про описанный, обложенный регламентами и пр., удаленный доступ. Можно сказать, что мы обошли 1.8, но по сути - туннель это часть ЛВС ;-)
Вы правы, и на два вопроса из трёх ответ в документе всё же есть.
Про то чья поддержка: пункт 1.6 требует учитывать «сроки технической поддержки со стороны производителей». Думаю, и в 1.7 речь про вендорскую.
Про community-каналы прямого ответа нет, но есть критерий. Пункт 7.3 требует оповещать ИБ об обновлениях «из непредусмотренных источников», а пункт 7.2 велит писать в журнал источник обновления, вплоть до URL или репозитория, и подтверждённые подписи либо контрольные суммы. Выходит, источник может быть любым, если он заранее предусмотрен и проверяем. Поддержкой в смысле пункта 1.7 это не становится, компенсирующие меры всё равно нужны.
А про облака да, возразить нечем. Про облако, VPN туннель и удалённую работу - ноль вхождений. Аварийного доступа тоже нет, пункт 3.4 обрывается на оговорке «при сохранении основных функций ядра сети».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ФСТЭК описала периметр в 35 пунктах. 26 из них не стоят ни рубля