Таким образом, админы делятся на тех, кому пофиг (сценарии 1 и 2), и тех, кто уже и так всё знает (сценарий 3). Последние, вероятно, черпают знания прямым подключением в ноосферу. Отсюда делаем вывод, что писать что-либо бессмысленно в принципе. :)
А если серьезно, жизнь немного сложнее. Хотя бы в том же SMB секторе обычно специалистов по ИБ, да ещё и скилованных, не густо, а работать надо. И, думается мне, собственную работу лучше стараться выполнять добросовестно. Тем более, что «всем до одного места» ровно до тех пор, пока таки не случается факап и админ не огребает по полной программе. Да и в крупных структурах очень разные по уровню подготовки люди работают.
так была изобретена технология снепшотирования COW. Отличие этой технологии заключается в основном в том, что все другие файловые системы, как правило, не обладали встроенным механизмом записи «в новое место»,
О каких именно файловых системах в контексте СХД идет речь? Обычно СХД в своей основе — блочные устройства, и снэпшоты делаются на уровне блоков.
Чем больше таких снепшотов тем больше дополнительных паразитических операций
Можете пояснить этот момент? Насколько я понимаю, при CoW делается копия блока, в который ведется запись, в количестве одной штуки, сколько бы там снэпшотов ни было. Какие дополнительные операции будут при большом числе снэпшотов (при условии, что работаем мы, как правило, все же с последней копией, а не со всем деревом)?
Ещё вопрос — на томе кончилось место, что будет происходить со снэпшотами в WAFL?
Я не столько что-то опровергаю, сколько предлагаю людям задуматься над тем, что они делают и что советуют. В частности, описываю последствия бездумного применения того, что многими считается «простым» и «общепринятым». По сути, люди сами дают в руки злоумышленнику дополнительный инструмент для создания проблем. Не очень хорошо так делать, и вдвойне нехорошо советовать, не описывая возможные последствия. Лично мое мнение — блокировку надо применять в исключтельных случаях, и как минимум предприняв какие-то меры против потенциальной полной блокировки AD.
Про стандарты и сертификацию по ним отчасти ответил выше — меры по ИБ, в том числе описанные в разных стандартах, включают в себя не только защиту учеток, но и обеспечение доступности информационной системы. И в ситуации, когда реально стоит выбор между борьбой с перебором паролей и доступностью, этот выбор должен делаться осознанно, а не просто потому, что в какой-то бумажке так написано.
В виде отдельной статьи я в данном случае писал исключительно потому, что единственным доступным мне вариантом был пост в песочницу. Иначе я бы ответил развернутым комментарием. Что до систематизированных рекомендаций… Во-первых, я сам не безопасник, во-вторых, рекомендации могут сильно отличаться в зависимости от конкретных требований бизнеса и/или государства. Увидеть явные косяки в предлагаемых решениях я, как правило, могу. Дать конкретные советы в конкретной ситуации — когда как. Писать общие систематизированные рекомендации «как надо» — для меня пока слишком. Но я подумаю. :)
Попутно отвечая на нижний комментарии о требованиях государственных и ведомственных нормативных актов — если мы откроем методический документ ФСТЭК, который указан в ваших ссылках, то прочитаем там на стр. 10 буквально следующее:
«При невозможности реализации в информационной системе в рамках ее
системы защиты информации отдельных выбранных мер защиты информации
на этапах адаптации базового набора мер защиты информации или уточнения
адаптированного базового набора мер защиты информации могут
разрабатываться иные (компенсирующие) меры защиты информации,
обеспечивающие адекватное блокирование (нейтрализацию) угроз
безопасности информации.»
Иными словами, будь я системным администратором, ответственным за функционирование IT-инфраструктуры в госструктуре, то для меня было бы два варианта действий:
1. Мне пофиг. Беру под козырек и тупо следую инструкции.
2. Мне не пофиг. Пишу служебку (или инициирую совещание, в зависимости от ранга), где подробно описываю возможные последствия (в том числе можно сослаться на положения тех же нормативных актов в части, где они регламентируют доступность информационной системы, ибо тут будет очевидное противоречие), и предлагаю компенсирующие меры.
Конкретика, ясное дело, будет зависеть от местных условий.
Я не очень понимаю суть ваших комментариев. Вы считаете, что онлайн-сервисы по какой-то причине должны обязательно каждый иметь отдельную базу данных пользователей для аутентификации, причем этой базой не должна являться AD?
А если серьезно, жизнь немного сложнее. Хотя бы в том же SMB секторе обычно специалистов по ИБ, да ещё и скилованных, не густо, а работать надо. И, думается мне, собственную работу лучше стараться выполнять добросовестно. Тем более, что «всем до одного места» ровно до тех пор, пока таки не случается факап и админ не огребает по полной программе. Да и в крупных структурах очень разные по уровню подготовки люди работают.
О каких именно файловых системах в контексте СХД идет речь? Обычно СХД в своей основе — блочные устройства, и снэпшоты делаются на уровне блоков.
Можете пояснить этот момент? Насколько я понимаю, при CoW делается копия блока, в который ведется запись, в количестве одной штуки, сколько бы там снэпшотов ни было. Какие дополнительные операции будут при большом числе снэпшотов (при условии, что работаем мы, как правило, все же с последней копией, а не со всем деревом)?
Ещё вопрос — на томе кончилось место, что будет происходить со снэпшотами в WAFL?
Про стандарты и сертификацию по ним отчасти ответил выше — меры по ИБ, в том числе описанные в разных стандартах, включают в себя не только защиту учеток, но и обеспечение доступности информационной системы. И в ситуации, когда реально стоит выбор между борьбой с перебором паролей и доступностью, этот выбор должен делаться осознанно, а не просто потому, что в какой-то бумажке так написано.
Попутно отвечая на нижний комментарии о требованиях государственных и ведомственных нормативных актов — если мы откроем методический документ ФСТЭК, который указан в ваших ссылках, то прочитаем там на стр. 10 буквально следующее:
«При невозможности реализации в информационной системе в рамках ее
системы защиты информации отдельных выбранных мер защиты информации
на этапах адаптации базового набора мер защиты информации или уточнения
адаптированного базового набора мер защиты информации могут
разрабатываться иные (компенсирующие) меры защиты информации,
обеспечивающие адекватное блокирование (нейтрализацию) угроз
безопасности информации.»
Иными словами, будь я системным администратором, ответственным за функционирование IT-инфраструктуры в госструктуре, то для меня было бы два варианта действий:
1. Мне пофиг. Беру под козырек и тупо следую инструкции.
2. Мне не пофиг. Пишу служебку (или инициирую совещание, в зависимости от ранга), где подробно описываю возможные последствия (в том числе можно сослаться на положения тех же нормативных актов в части, где они регламентируют доступность информационной системы, ибо тут будет очевидное противоречие), и предлагаю компенсирующие меры.
Конкретика, ясное дело, будет зависеть от местных условий.
И даже если этого нет, в общем случае защита на периметре — не повод оставлять дырки внутри.