Термин «безопасность через маскировку» часто подвергается остракизму со стороны работников сферы безопасности, особенно тех, что считают себя специалистами Почти являющаяся ругательством в некоторых кругах, безопасность через маскировку, как отмечено в англоязычной Википедии (en.wikipedia.org/wiki/Security_through_obscurity), представляет один из действительно противоречивых аспектов безопасности. Часто можно увидеть насмешливые упоминания о людях, чьи усилия игнорируются как «просто безопасность через маскировку».
Безопасность через маскировку является по сути нарушением принципа Керкхофа, утверждающего, что система должна быть защищенной благодаря своим проектным решениям, а не тому, что эти решения неизвестны оппоненту. Принцип Керкхофа основан на том, что секреты быстро выплывают наружу.
В качестве отличного примера возьмем протокол проверки подлинности Windows NT® LAN Manager (NTLM), изначально считавшийся секретным. Чтобы создать программный продукт Samba для взаимодействия с операционными системами на основе UNIX, разработчикам Samba пришлось вскрыть и проанализировать протокол. Результатом стала наиболее полная существующая документация по NTLM (monyo.com/technical/samba/translation/ntlm.en.html), а также обнаружение ряда ошибок. Поскольку криптография является истоком безопасности в столь значительной степени и столь многие секретные решения разработчиков были раскрыты, многие специалисты считают, что информационная безопасность должна всегда следовать принципу Керкхофа.
Но всегда ли плоха безопасность через маскировку? В этой статье мы разберем, что из себя представляет безопасность через маскировку, почему многие считают ее потерей времени (а многие нет) и покажем, почему ответ, как и всегда, гораздо сложнее, чем кажется на первый взгляд.
Введение в безопасность через маскировку
«Не изменяйте имена по умолчанию» – автор Стив Райли (Steve Riley)
В вопросе переименования я придерживаюсь подхода «не менять ничего». Это даже не проблема безопасности – это вопрос управления системой. И по мере того, как я трачу все больше времени на размышления в пространстве управления системой (поскольку управление и безопасность становятся одним целым), мне все больше нравится идея не делать ничего, что потенциально может повысить хрупкость системы. А один из гарантированных путей ее повысить – сменить что либо, установленное по умолчанию. Пользователи делают это по двум (ладно, трем) причинам:
- Это известное требование для функции, предоставляемой изменением.
- Предполагается, что это улучшит безопасность.
- (Осторожно: впереди глупость.) Кто-то прочел об этом в журнальной статье.
Если необходимо изменить имя по умолчанию по причине номер один, смело делайте это. Изменения такого рода редко ведут к нестабильности системы, часто потому, что они тестировались заранее.
Если же изменение вносится по причине номер 2, я бы советовал остановиться и хорошо подумать. Изменения такого рода практически никогда не тестируются производителями программного обеспечения и, следовательно, производитель не может предсказать, как будет вести себя система после их внесения. Вдобавок существуют альтернативы и как правило гораздо лучшие, способные предоставить истинную безопасность.
Если какой-нибудь негодяй и узнает имя учетной записи, что с того? Реально преграждает ему путь в систему все равно пароль и стойкость этого пароля. Стремление изменять имена учетных записей по умолчанию, такие как «Администратор» и «Гость», на что-нибудь не столь легко угадываемое часто указывает на желание избежать сложных паролей или кодовых фраз. Исправьте настоящую проблему (скверные секреты), и это позволит избежать хрупкости (изменения имен по умолчанию).
Безопасность через маскировку не включает мер, которые совершенно не смягчают проблемы. Например, организация, блокирующая протокол NNTP на пограничных маршрутизаторах, чтобы не дать сотрудникам читать группы новостей, но допускающая исходящие подключения по SSH, не применяет безопасность через маскировку. Поскольку по протоколу SSH может туннелировать любой протокол, проблема не маскируется, глупая мера по ее устранению не годится ни на что, кроме как на принуждение законных пользователей к нарушению политик безопасности ради выполнения своих законных задач. Подобные меры – не безопасность через маскировку; они просто глупы и бессмысленны.
Как предполагает первое слово термина «безопасность через маскировку», меры такого рода предоставляют некоторую защиту. Однако также предполагается (в чем и состоит проблема), что для реальной остановки атаки на одном или нескольких направлениях не делается ничего. (Направление атаки – это по сути средство, которым злоумышленник может получить доступ к системе.)
Предположим, что имеется уязвимый веб-сервер, который можно атаковать через порт 80 TCP, используя широко известный способ вторжения. Чтобы закрыть это конкретное направление, можно внести исправление в веб-сервер или отключить его – в обоих случаях направление будет полностью перекрыто. Можно также частично перекрыть его, используя брандмауэр или IPsec для закрытия порта 80 на всех компьютерах, кроме нескольких избранных. Это не перекроет направление атаки полностью, но существенно смягчит проблему.
Безопасность через маскировку, с другой стороны, включает принятие мер, которые не перекрывают направление атаки, а только скрывают его. Например, можно решить переместить веб-сервер с порта 81 на порт 80, так что лишь те, кто знают, где его найти, смогут сделать это. Во всяком случае, так предполагается. В реальности перемещение веб-сервера на порт 81 останавливает лишь некоторые атаки, а в основном просто создает неудобства конечному пользователю. Компетентный злоумышленник просто проведет сканирование портов и применит уловитель веб-заголовков по большому числу портов, чтобы обнаружить веб-серверы на нестандартных портах. Найдя один из них, он сможет применить вышеупомянутый способ вторжения против сервера, поскольку направление атаки не было удалено, а только (временно) замаскировано.
Значит ли это, что не стоит и пытаться? Ответ зависит от разных факторов. Как и всегда в области информационной безопасности, все сводится к управлению рисками. Чтобы понять ключевые факторы, которые следует рассмотреть, стоит бросить быстрый взгляд на ряд других мер безопасности через маскировку и затем обсудить одну из них – переименование учетной записи администратора – более подробно.
Оценка мер безопасности
Примеров безопасности через маскировку существует множество. Это могут быть действия, предпринимаемые диспетчерами систем и сетей либо разработчиками программного обеспечения. Но все они имеют общую черту – предназначение для смягчения уязвимости, путем сокрытия ее от потенциальных взломщиков.
Не могут ли некоторые из этих процедур иметь хотя бы некоторый положительный эффект? Будет ли справедливым утверждение, что безопасность через маскировку плоха в целом? По крайней мере часть из этих мер определенно имеет своих защитников. Например, в Windows® возможно скрыть буквы дисков в проводнике Windows. Многие среды, в первую очередь школьные компьютерные классы, используют эту методику, чтобы предотвратить сохранение пользователями данных на жесткий диск. Само собой, большинство приложений по-прежнему могут сохранять данные на жесткий диск, так что в итоге ценность такой меры безопасности невелика. Но применившие ее учреждения часто заявляют, что она уменьшает объем данных на жестком диске.
Метод безопасности через маскировку иного рода часто реализуется в Windows – отключение административных общих сетевых ресурсов (таких как C$, Admin$, и т.д.). Предполагается, что это должно лишить злоумышленника возможности удаленно подключиться к компьютеру. В действительности, это не просто не так – злоумышленник с учетной записью, которая может использовать административные общие ресурсы, может удаленно включить эти самые ресурсы вновь. И все же многие организации клянутся, что отключение этих ресурсов уменьшает число вредоносных программ в их сетях.
Один из моих любимых примеров бессмысленных усилий – это параметр «Разрешать отстыковку без входа в систему» в Windows. Если он отключен, то кнопка «отстыковать компьютер» убирается с экрана входа в систему. Идея состоит в том, что благодаря этому злоумышленник не сможет корректно отстыковать компьютер. Само собой, любой взломщик может просто запихать и компьютер и станцию расширения в сумку и уйти с ними независимо от того, видна эта кнопка или нет. Такая вероятность едва ли тянет даже на безопасность через маскировку.
Другой четкий пример – это параметр «Разрешить операторам сервера планировать выполнение заданий по расписанию», которая, в точном соответствии с названием, позволяет пользователям, входящим в группу операторов сервера, создавать расписание заданий. Этот вопрос щекотлив потому, что такие задачи могут выполняться как локальная система, и только администраторы должны иметь возможность планировать выполнение заданий, выполняющихся как локальная система. Само собой, операторы серверов потенциально могут сделать себя администраторами множеством различных способов, так что запрещение им планировать выполнение заданий по расписанию не имеет большого значения.
Однако многие организации предпочитают этот параметр, поскольку он позволяет их специалистам быть операторами, а не администраторами, что означает меньшую вероятность случайного уничтожения ими сервера. Это уже само по себе может дать некоторые выгоды.
Так каково же заключение? Очевидно, что некоторые из этих проблем могут быть весьма сложны. Мы с пользой провели немало времени, споря об этих типах мер Роджер твердо на стороне, считающей подобные практические приемы ценными. Йеспер, с другой стороны, верит, что они в лучшем случае, как правило, являются потерей времени. Давайте изучим один из наиболее часто приводящихся (и спорных) примеров в пользу безопасности через маскировку: переименование учетной записи администратора. Роджер приведет аргументы в пользу этой меры, Йеспер – против нее. Известные специалисты по безопасности Аарон Маргосис (Aaron Margosis) и Стив Райли (Steve Riley) также вступят в спор во врезках «Переименование учетной записи администратора» и «Не изменяйте имена по умолчанию» соответственно.
Сокрытие учетной записи администратора.
Переименование учетной записи администратора с относительным идентификатором (RID) 500 на нечто неизвестное часто рекомендуется специалистами по безопасности, а также несколькими руководствами Майкрософт по укреплению безопасности системы. В групповой политике даже имеется параметр для переименования учетной записи администратора, как показано на рис. 1. Идея состоит в том, что если учетная запись администратора переименована, взломщику будет сложнее войти в систему в качестве настоящего администратора. Само собой, очевидная проблема с использованием групповой политики для этой операции состоит в том, что переименованная учетная запись администратора будет иметь одинаковое имя на всех компьютерах, к которым применен объект групповой политики. Это понижает ценность данной конкретной меры безопасности для маскировки.
Рис. 1 Переименование учетной записи администратора
В данном контексте также важно понимать, что любой пользователь с законной учетной записью может извлечь имя учетной записи администратора, была ли она переименована или нет. Учетная запись администратора всегда имеет RID 500. Просто спросив имя учетной записи с RID 500, любой пользователь с учетной записью может увидеть, как она называется, что показано на рис. 2.
Рис. 2 Поиск переименованной учетной записи администратора
Мнение Роджера
Основной известный мне аргумент против переименования учетной записи администратора состоит в том, что не составляет труда преобразовать имя учетной записи любого участника безопасности в ее зависимый идентификатор безопасности (SID) и найти ее относительный идентификатор (RID). К тому же истинная учетная запись администратора всегда имеет RID 500. Так что, если взломщик всегда может преобразовать имена учетных записей в сочетания SID/RID и найти RID 500, какой в этом смысл?
Но тут все не так просто, как кажется. Чтобы перевести имя учетной записи пользователя в SID/RID, необходим доступ к портам NetBIOS либо LDAP. Большинство брандмауэров периметра не допускают подобный тип доступа через Интернет, так что если взломщик не обойдет брандмауэр полностью, ничего ему перевести не удастся. Кроме того, анонимные переводы SID не работают на Windows XP и более поздних версиях Windows, кроме как на контроллерах домена (DC). В случае большинства открытых сети компьютеров (наиболее подверженных риску) взломщику для выполнения переводов имен в SID потребуются учетные данные, подлинность которых проверена.
Так что для начала атаки с переводом при настоящей глубокой защите необходимо преодолеть изрядное число препятствий. И даже если взломщик проникнет настолько далеко, он окажется там же, где он бы был, если б имя учетной записи осталось стандартным. Переименование учетной записи может только улучшить безопасность. И определено не может повредить ей.
Это еще один секрет Если злоумышленник не знает имени учетной записи администратора, оно становится еще одной «секретной» меткой, подобной паролю, которую ему надо узнать. Конечно, имена учетных записей пользователей вряд ли могут оказаться такими же сложными, как пароль администратора, но это еще одно препятствие, которое может экспоненциально усложнить проблему угадывания/взлома паролей. Те, кто когда-либо выполнял тестирование уязвимости паролей, уже знают, насколько увеличивает работу необходимость угадывать и имя и пароль пользователя. Это усложняет и без того трудную задачу, делая ее намного более трудной.
Отражает автоматизированные вредоносные программы и дилетантов с чужими сценариями Я выполняю практическую работу по обеспечению безопасности Windows уже 22 года, и мне довелось вести восемь приманок на Windows, открытых Интернету, в течении последних пяти лет. За все это время мне ни разу не приходилось видеть, чтобы автоматизированные вредоносные программы (производящие подавляющее большинство атак) использовали любую другую метку учебной записи, кроме «Администратор» (или root в случае систем *NIX). Переименование учетной записи администратора немедленно побеждает все вредоносные программы, полагающиеся на имя администратора. А это означает уменьшение угрозы безопасности.
То же касается подростков, пользующихся готовыми сценариями взлома. Все «крутейшие» руководства по взлому Windows, которые я только знаю, упоминают о методиках перевода имени в SID, но по какой-то причине я ни разу не сталкивался с этим на одной из моих приманок, если там имелась также «фальшивая» учетная запись администратора для увода их со следа. Хорошим взломщикам следует всегда проверять, является ли найденная ими учетная запись администратора реальной записью администратора (RID 500), но они этого не делают. Я не знаю почему. Вероятно, виноваты ленивые взломщики и обычное человеческое поведение.
Останавливает и большинство профессионалов Это удивляет большинство людей. После работы с приманками в течение нескольких лет быстро различаешь автоматические атаки, деток со сценариями и профессионалов. За последние пять лет при миллионах обнаруженных атак против моих приманок я никогда не видел, чтобы профессионалы выполняли перевод SID при наличии фальшивой учетной записи администратора.
Я уверен, что некоторые из профессиональных преступников выполняют перевод SID, но готов поспорить, что это ничтожное меньшинство, которое мне ни разу не удалось зафиксировать. Почему профессионалы не делают этого? Предполагаю, что они не видят причины пробовать что-то, чего не практикуют все остальные.
Упрощает предупреждения Теперь оппоненты могут возразить, что если переименование учетной записи администратора станет обычной практикой, оно утратит свое значение как прием маскировки. Аргумент состоит в том, что вредоносные программы, подростки со сценариями и профессионалы изменят свою тактику по умолчанию на поиск иных имен, чем только «Администратор». Это обоснованное предположение. К счастью, оно не меняет одного важного условия. Во-первых, если учетная запись Windows с суперполномочиями не называется «Администратор», взломщикам прибавляется работы. Это просто факт. А если взломщику надо работать больше, чуть понижается вероятность выбора им этого направления для атаки, позволяя другим уменьшающим воздействие мерам глубокой защиты обнаруживать вредоносную деятельность быстрее.
И это ведет меня к последнему аргументу в пользу переименования. Если учетная запись администратора никогда не называется «Администратор», а вместо этого создается другая учетная запись с таким именем, как показано на рис. 3, то получится хороший механизм предупреждения. Если отслеживание событий обнаруживает попытку входа в систему с использованием имени по умолчанию, это событие следует немедленно исследовать.
Рис. 3 Попытки входа в систему через учетную запись-приманку, именуемую «Администратор», могут служить ранним предупреждением
Наши журналы событий полны «неверных» входов в систему, которые ничего не значат. Обычно это просто попытка пользователя (или Windows) войти в систему, используя неверный пароль, или что-нибудь в таком духе. Но как же можно легко отличить нормальные попытки входа от вредоносных, если учетная запись администратора именуется «Администратор»? Если учетной записи с таким именем никогда не было, и обнаруживается попытка входа в систему с использованием имени этой учетной записи, то ясно, что это вряд ли делается с хорошими намерениями. Ранее предупреждение с низким отношением шума к сигналу весьма ценно в современной защите.
Очередь Йеспера
«Переименование учетной записи администратора» - автор Аарон Маргосис (Aaron Margosis)
Йеспер, в идеальном мире вы были бы абсолютно правы. Пароли будут всегда достаточно стойки, чтобы сделать тупой перебор нереальным, а учетные записи локального администратора -500 всегда будут использоваться только для аварийного восстановления. В реально мире неверно ни то, ни другое.
Несмотря на вашу замечательную проповедь безопасности и, в частности, великолепную серию о кодовых фразах, написанную вами ("The Great Debates: Pass Phrases vs. Passwords" («Великие Дебаты: парольные фразы против паролей») части 1, 2 и 3 на go.microsoft.com/fwlink/?LinkId=113157; go.microsoft.com/fwlink/?LinkId=113159; и go.microsoft.com/fwlink/?LinkId=113160), многие системные администраторы не обладают современным пониманием того, что представляет из себя стойкий пароль.
Не так давно пароль, состоящий из 8 случайных знаков, выбранных из разных наборов знаков, считался стойким, закон Мура сделал это неверным. Обучение пользователей (и системных администраторов) является слабым звеном и, вероятно, останется им, пока тема надежности паролей не станет модной на кабельных каналах новостей.
Так что, учитывая, что реальный подбор паролей в наши дни не требует 600 миллиардов лет, а, вместо этого, зачастую может быть сделано за время, уходящее на завтрак, добавление множителя х1000 может иметь реальную ценность. К тому же переименование учетной записи делает ее неуязвимой для множества автоматических атак, бьющих по учетной записи, именуемой «Администратор».
Время и усилия, уходящие на переименование учетной записи администратора, обычно невелики, как вы заметили, чаще всего это простой параметр GPO. Между прочим, стандартная настройка для настольных компьютеров федеральных служб правительства США (csrc.nist.gov/fdcc), требует переименования учетной записи -500. Переименование является лишь одним из многих требуемых параметров и не относится к тем, что требуют из ряда вон выходящего количества времени или внимания. Не приходилось мне видеть и того, чтобы благодаря ему у кого-то создалось ложное чувство защищенности – я никогда не слышал слов: «Нам не нужно управление обновлениями, поскольку мы переименовали свои учетные записи администраторов.»
Приносит ли переименование пользу, когда новое имя учетной записи одинаково для всей организации? Польза не особенно велика, но она есть: во-первых, это блокирует автоматизированные атаки, ожидающие имя «Администратор», и, во вторых, потенциальные злоумышленники не обязательно входят в число лиц, знающих новое имя. (Гораздо больший риск возникает, когда локальные учетные записи администраторов, переименованы они или нет, используют общий пароль внутри организации. Управление паролями остается большей и более важной проблемой. Отключение учетной записи -500 – один из способов ее решения, но это блокирует важный способ восстановления, когда доменные учетные записи не могут быть использованы.) Я также могу указать, что наши руководства по безопасности давно рекомендуют переименовывать учетные записи по умолчанию, так что такое действие хорошо протестировано и полностью поддерживается.
Я думаю, мы все знаем теперь, что меры маскировки (сами по себе) не являются адекватной защитой. Но они могут дополнять другие меры безопасности, как ясно демонстрируют данные Роджера. Так как стоимость реализации невысока, организациям не следует отбрасывать их.
Помимо аргументов в пользу переименования учетной записи администратора, существуют и веские аргументы против. Но перед тем, как углубляться в них, я должен признать, что последний довод Роджера довольно весок. Однако в хорошо управляемой среде следует проверять любой вход в систему через учетную запись администратора, поскольку эту запись не следует использовать иначе как в ситуациях аварийного восстановления.
Это избыточно Основной риск, который (предположительно) должно уменьшать переименование учетной записи администратора, – это удаленный подбор пароля кем-либо. Но только пользователь, не имеющей другой уполномоченной учетной записи на компьютере, будет остановлен переименованием учетной записи администратора. Такой злоумышленник обычно опробует серию случайных паролей, чтобы войти в систему через учетную запись администратора. Однако при этом он получит одинаковое сообщение об ошибке вне зависимости от того, угадал ли он неверно имя учетной записи или пароль.
Это указывает на то, что один из основных аргументов в пользу переименования учетной записи администратора (то, что это отпугнет подростков) – порочен. Это отпугнет их ничуть не в большей мере, чем сохранение имени по умолчанию, поскольку разница им не видна! Что ни делай, они переберут тот же набор случайных паролей и перейдут к следующей потенциальной жертве.
Это значит, что пока пароль на учетной записи администратора достаточно стоек для отражения атак, переименование учетной записи не предоставляет дополнительных выгод. Допустим, что эта учетная запись защищена 15-символьным паролем, состоящим из букв верхнего и нижнего регистра, чисел и знаков, выбранных со всей клавиатуры. Угадывание такого пароля через сеть займет примерно 591,310,404,907 лет. В порядке сравнения можно сказать, что это примерно в 43 раза больше времени существования вселенной.
Допустим, мы переименуем учетную запись администратора, выбирая одно из 1000 возможных значений. Время на угадывание пароля растянется до 591,310,404,906,787 (в 43,161 раз больше, чем время существования вселенной). Повысили ли мы безопасность? Конечно, на три порядка. Понизили ли мы вероятность, что злоумышленник угадает наш пароль? Ну, она бесконечно мала в обеих случаях. Другими словами, в реальности мы ничуть не улучшили ситуацию по сравнению с использованием изначального имени учетной записи администратора. То, что переименование учетной записи позволяет разделаться с вредоносными программами, которые используют ее, еще не значит, что эти программы преуспели бы, не будь она переименована. Если используется стойкий пароль, как это и следует делать, можно практически гарантировать, что они будут отражены вне зависимости от имени учетной записи.
Известно, что многие руководства по безопасности требуют переименования учетной записи администратора, но это еще не делает такую меру полезной или даже допустимой. Это просто лишает пользователя принять нормальное решение по управлению риском насчет нее. Руководства по безопасности часто требуют установки параметров, которые ничего не меняют и во многих случаях даже не существуют. Чтобы продвинуться в области безопасности, мы рань или поздно должны подняться над требованиями, реально проанализировать проблемы и оценить, имеет ли смысл их устранять или нет. Здесь важно помнить один ключевой момент – тот факт, что злоумышленник нацеливается на тот или иной компонент, не является сам по себе достаточной причиной для изменения этого компонента. Изменения следует вносить только в том случае, если можно ожидать, что без их внесения атака будет успешной.
Если предположить наличие стойкого пароля, вероятность успеха атаки практически равняется нулю независимо от того, переименована учетная запись или нет. Следовательно, при наличии стойкого пароля безопасность не требует переименования учетной записи. Вдобавок, если вы, подобно мне, основываетесь на предположении, что компьютер, вероятно, будет тем более стабилен, чем меньше поправок и изменений в него вносить (твердо установленный факт, между прочим), то это добавляет еще одну причину не переименовывать учетную запись администратора.
Отвлекает внимание на малозначимые улучшения Одна из проблем с малозначимыми улучшениями безопасности через маскировку состоит в том, что они угрожают отвлечь внимание организации от действительно значимых улучшений. Например, время и усилия, уходящие на переименование учетной записи администратора, можно использовать на что-нибудь еще. Если это что-то имеет большее значение, чем переименование учетной записи администратора, то организация упустила шанс. Это может и не показаться значительной ценой, но представьте себе переименование 50 000 учетных записей администратора, и моя мысль станет понятна.
Что еще хуже, вполне реальна возможность того, что руководство организации успокоится после введения малозначимого улучшения. Руководители не всегда понимают минимальную полезность улучшений безопасности через маскировку и могут отказаться от дальнейших шагов. Это действительно может создать значительный риск для организации, хотя его и можно избежать, если руководство просто посвятит некоторое время и усилия ознакомлению со значением применяемых улучшений.
Управление им затратно Наконец, в зависимости от того, насколько умело реализовано улучшение, управление им может стать довольно дорогостоящим. Если просто установить объект групповой политики на переименование учетной записи администратора, затраты очень малы. Все будут знать имя, и стоимость развертывания будет практически равна нулю. Однако предоставляемая им полезность также минимальна, поскольку, как я уже сказал, все обладатели учетной записи будут знать это имя. То есть, чтобы реально выиграть от этого улучшения, необходимо использовать различные имена на различных узлах, и такая система становится довольно дорогой в управлении.
Гораздо лучше вместо этого использовать средство вроде passgen (protectyourwindowsnetwork.com/tools.htm), чтобы установить полностью случайный 100-значный пароль на всех учетных записях администратора в сети и использовать другие учетные записи для повседневного управления. Учитывая, что учетная запись администратора предназначена исключительно для целей аварийного восстановления (кроме как на Windows Small Business Server 2003), это не должно никак повлиять на систему управления сетью. Вдобавок, у злоумышленника будет больше шансов найти иголку на дне Тихого Океана, чем верно угадать пароль для любой из учетных записей администратора. Достаточно сосредоточиться на стойких, уникальных паролях и пусть хакеры-подростки подбирают, пока не надоест.
Все сводится к управлению риском
Практически любую меру безопасности через маскировку можно проанализировать таким способом. Свои «за» и «против» есть у любой схемы, а правильный подход для одной организации не обязательно годится другой организации. В итоге это становится проблемой управления риском. Перевешивает ли риск стоимость реализации решения? Каждое решение, принимаемое при защите информационных ресурсов, должно быть основанным на имеющейся информации решением по управлению рисками, и выбирать здесь редко приходится между черным и белым.
Действительно, некоторые решения уже приняты за вас. Например, хотя безусловно можно решить не шифровать информацию о банковской карте или не хранить коды проверки банковской карты, и то, и другое, вероятно, приведет к утрате возможности использовать банковские карты как форму платежей. Вероятный удар по бизнесу при этом таков, что выбора на практике нет. Другими словами, хоть это и решение по управлению риском, но такое, что его несложно принять.
Аналогично, также верно, что никто в здравом уме не подключит открытую беспроводную сеть к серверной части внутрихранилищной сети в физическом хранилище. Однако это не значит, что такое решение не является решением по управлению риском. Оно является. Это можно сделать и навлечь на себя последствия (которые, увы, кажутся крайне маловероятными).
Ключевым действием здесь является четкая формулировка проблемы, которую нужно решить, предлагаемых решений для этой проблемы и их достоинств с недостатками. Имея это, имеешь достаточно информации, чтобы принять решение по управлению риском на основе реальной информации. Без такой информации решения принимаются по наитию, а такие решения редко являются хорошими.
