Внимание: мой новый RSS-Feed: http://feed.feedcat.net/815939
Измените свою подписку, пожалуйста.
Наконец-то, наступила и моя очередь ругать Microsoft. Я не особый поклонник такого способа раскрутки, однако, я полагаю, что единственный путь двигаться вперед, это воспринимать, обрабатывать конструктивную критику и отвечать на нее. Так что приступим (Многа букав):
Несколько лет назад MS огласило свою широко известную инициативу Trustworthy Computing (совсем недавно они отмечали 10тилетие этой инициативы). Думаю, что мне не нужно напоминать Вам ни цели этой программы, ни средства, которые предполагалось использовать для их достижения. Интересующиеся вполне могут найти эту информацию самостоятельно. Ну и всяко, это «открытое письмо» не задумывалось, как тщательный анализ, после которого я должен был бы воскликнуть «люди, MS нам лжет!». Скорее, наоборот, просто легкая попытка показать, что, по моему скромному мнению, можно было достичь еще большего.
Я IT Pro с более, чем десятилетним стажем и этот факт, безусловно, влияет на то, как я вижу наш мир, ИТ безопасность и корпорацию Microsoft в аспектах, касающихся и того и другого. При этом моё видение Trustworthy Computing выглядит как-то так:
«SDL! SDL это! SDL то! SDL всё и повсюду!!!».
Не поймите меня неправильно, SDL это прекрасно даже с точки зрения системного администратора, который почти не умеет кодить. Нет, правда, лично у меня есть ощущение, что код от MS стал более безопасным. Большая часть актуальных уязвимостей для их реализации требует от меня либо отключения включенных по умолчанию средств защиты (DEP, UAC) или выставления совершенно незащищенного сервера в открытый интернет. Как следствие, я чувствую себя много лучше защищенным, чем, скажем, десять лет назад (впрочем, это может быть промывка мозгов, не так ли? =) ).
И все же в текущей ситуации есть приметы, которые заставляют меня полагать, что текущему SDL недостает чего-то жизненно важного. Чего же, спросите вы? Ну хотя бы тестирования продуктов в среде, соответствующей Best Practices от безопасности. То есть не только создание как можно менее уязвимого кода, но и предоставить возможность внедрить стандартные контролы для повышения безопасности решений. Хотя бы просто внедрить, если уж не без плясок с бубном. Я говорю о таких вещах, как работа с многофакторной аутентификацией, разделение ролей или делегирование полномочий. Все это должно быть включено в «Trustworthy» продукт из коробки, чтобы обеспечить сколько-нибудь безопасное окружение. Грош цена абсолютно не ломаемому (ну фантастика, ну и что) с точки зрения кода приложению, если пароли от него можно прослушать в сети банальным анализатором сетевого трафика или если любой имеет в этом приложении одинаковые полномочия. Или если для банальнейших операций с с базой данных нужно предоставить дежурному администратору права SA.
На протяжении последних нескольких лет я наблюдал различные ситуации, которые заставили меня думать, что эти материи не были в фокусе продуктовых групп в последнее время. Чтобы не быть голословным, я приведу несколько наиболее ярких примеров.
1) Когда мы только приступили к работе с MOSS 2007, тогда еще только RTM, мы наткнулись на невозможность индексировать порталы, доступ к которым предоставлялся с помощью CKD и HTTPS. Проблема, вроде бы решалась расширением таких порталов на HTTP, тогда индексация проходила, но поиск не выдавал результатов. Обходным маневром этой «by design» ситуации было создание сначала HTTP-приложения и расширения его с помощью HTTPS. Ерунда, казалось бы, и в последующих SP ситуация была исправлена, однако, это могло быть выявлено стандартным тестированием в соответствующем окружении.
2) Во втором случае мы никак не могли заставить работать определенные функции MOSS, связанные с WebDAV при использовании смарт-карт. Классная технология, но попробуйте безопасно опубликовать WebDAV-сайт через ISA и потребуйте аутентификации через смарт-карты… И вот она – Ваша проблема.
3) Вообще говоря, поддержка смарт-карт кажется слабым местом ребят из Рэдмонда. Я обожаю UC-продукты от MS, но попробуйте подружить со смарт-картой некоторые режимы работы Outlook или использовать их при работе с Lync/Communicator… Будет работать? Черта с два! Устанавливайте VPN-соединение или настраивайте DA, а потом используйте свои ненаглядные объединенные коммуникации.
4) Data Protection Manager. Я очень люблю этот продукт. Его чрезвычайная простота в эксплуатации в сочетании с вполне приличной мощью очень привлекательны. И все-таки первые три релиза у нас не было практически ни намека на разделение полномочий (за исключением нескольких немаловажных, но все-таки частных случаев). Все или ничего. Полный доступ или никакого доступа. Самый последний релиз наконец предоставил нам RBAC, но предыдущие пять лет без него малообъяснимы.
5) SQL сервер. Мы проверяли на 2005-2008R2. Может выстрелить в случае использования SQL Mirroring. Попробуйте с правами, меньшими, чем sysadmin выполнить операцию ALTER DATABASE на базе в режиме recovery. Мало того, что ничего не получится, так еще и дамп сгенерится по умолчанию, чем, при определенной настойчивости, можно и сервер положить =) А это, между прочим, стандартная операция для баз в зеркале.
Все, указанные выше проблемы (разрешенные и нет) вполне могли бы быть найдены при тестировании, если бы кто-то ставил перед собой задачу тестировать продукты в средах, построенных с применением основных принципов безопасности. Те возможности, которые просто отсутствовали, когда они были так нужны, так же могли бы быть предоставлены продуктами значительно раньше, если бы «там» задумывались не только о качестве самого кода.
К сожалению, мой опыт приводит к мысли, что об этом задумывался мало кто из имеющих влияние на ситуацию. Я бы мог подумать, что это лишь случайные недоразумения, однако если всего один человек встрял в такое количество ситуаций за несколько лет (а это, поверьте мне, не все), то, я скорее склонюсь к выводу, что это просто результат подхода в PG к разработке и концепции Trustworthy Computing.
В общем, короткий ответ: нет. CA не имеет ни малейшей возможности заставить клиента вести себя таким образом, как предполагает название этой настройки. В шаблоне содержатся лишь рекомендации клиентской части не экспортировать закрытый ключ.
Что ж, для меня очевидно, что Google наконец-то официально 
)