Архив рубрики: Role Based Administration

Trustworthy Computing. SDL освоили, что дальше?

image

Внимание: мой новый 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.

Реклама

>Докладываю…

>

imageДа. Докладываю. Докладываю каши в тарелку на TechEd Russia. На этот раз это не Платформа вовсе, а больше 3000 участников, 150ти докладов и все такое. В этот раз я, как всегда буду тусоваться в зоне “Спроси эксперта”, но и доклад тоже будет. Докладывать буду о построении ролевой системы управления инфраструктурой в отдельно взятой стране сети. Надеюсь, что Вы посетите если уж не мой замечательный доклад, то хотя бы сам TechEd, потому прошу небольшой помощи.

Несмотря на то, что рассказывать я буду именно то, на что сам потратил достаточно много времени, я прекрасно понимаю, что нет двух абсолютно одинаковых инфраструктур и поэтому задачи, которые могут быть поставлены перед администраторами могут отличать кардинально (это одна из причин, по которым я люблю тусоваться в зоне “Спроси эксперта”: моя жизнь может никогда не задать мне таких интересных вопросов Подмигивающая рожица ). Потому мне нужна Ваша помощь: если у Вас есть какие-то вопросы по моей теме, то я прошу задать их мне. Я не хочу ограничивать кого-то рамками своего мышления и опыта, потому не делаю никакого опроса. Пишите в блоге или на почту. Отвечу и даже постараюсь учесть в презентации. Даже если не включу в доклад, то отвечу на страницах блога или сделаю вебкаст. 

P.S. Да, моё выступление это одна из причин, по которым обновления блога будут не слишком регулярными в ближайший месяц или два.

>Делегирование полномочий на создание GPO в другом домене

>

imageТакая задача неизбежно встает во весь  рост, как только  Вы начинаете пользоваться концепцией ролевого администрирования. Если честно, то пребывая в эйфории от возможностей AGPM, я что оно яйца выеденного не стоит: включили учетную запись в некоторые группы, включая “Group Policy Creator Owners” и вуаля – вот оно. Ага, черта с два!=) Эта чертова группа – глобальная и поэтому не может содержать объекты из других доменов. Более того, мы даже не можем изменить этот факт: такие возможности недоступны:

image

По крайней мере, я пока не знаю, как это сделать (но пометил себе разобраться с этим вопросом в будущем). Таким образом, уделать “по-быстрому” у нас не получится. отступим ли мы? Конечно же нет! Если мы не можем добавить объект в группу, то нужно создать новую группу, выдать ей такие же полномочия и включить объект в нее. Какие разрешения есть у группы “Group Policy Creator Owners”? Насколько я знаю, чтобы создать любой GPO нам нужно иметь права на контейнере Policies в AD и на папке Policies в sysvol. Так что давайте делегируем такие права нашей свежесозданной группе “Role GP Creator Owners”:

1) На контейнер Domain/System/Policies в AD:

image

image

image

image

Причем я полагаю, что “Create All Child Objects” это немного слишком, и можно сделать более тонкую настройку (но я не проверял – просто предположение)однако группа “Group Policy Creator Owners” имеет именно такие полномочия, так что хуже мы точно не сделаем.

2) И на папке Policies:

image

image

Вот теперь все должно работать. У меня, вроде, работает, хотя я еще буду спрашивать об этом ребят из MS, да и Вам рекомендую все тщательно проверить на тестовых стендах. Если выяснятся новые детали, то статью я поправлю, разумеется.

>Секреты %SystemRoot%System32: AzMan

>

Если быть честным, то я очень долго думал, что это какая-то никому не нужная консоль непонятного назначения. Но не так давно я взглянул на нее поближе и понял, что я был абсолютно не прав. Это на самом деле очень мощный инструмент управления разрешениями для приложений, которые его поддерживают. Настолько много возможностей можно открыть с его помощью, что эта статья только затравка: в будущем я планирую сделать еще одну или несколько с описанием конкретных применений. пока же просто представьте, что Ввам нужно предоставить кому-то полный контроль над виртуальной машиной Hyper-V, включая возможность удалить ее, но при этом отобрать возможность создавать снапшоты (вечная головная боль, знаете ли). Можно ли создать такой набор полномочий с помощью AzMan? Легко! Вам нужно создать прямо противоположныю политику? Добро пожаловать. Вы желаете чтобы пользователь был проверен не только на членство в группах, но, скажем, на нахождение Сатурна в созавездии Девы? Создайте для таких нужд скрипт и создайте на его базе правило с помощью AzMan. Еще один факт, который чрезвычайно мне импонирует: этот инструмент очень ориентирован на ролевой доступ. Мышление в терминах ролей просто навязывается им.

image2

Хорошо, скажете Вы мне, в чем ловушка? К сожалению, она есть и не одна. Первое: Ваше приложение должно быть спроектировано и написано с учетом возможностей Authorization Manager. Для многих приложений от MS это так, например, для Hyper-V. Однако, если Вы используете SC VMM, то пользоваться AzMan почти невозможно и VMM дает Вам меньше возможностей по сравнению с AzMan. В DPM возможности этой консоли еще не сломаны никаким “управляющим” ПО, однако возможности настройки чрезвычайно скудны. =(

И все же, если Вам это не мешает, или Вы используете какое-нибудь другое приложение, которое совместимо с AzMan, то я искренне Вам рекомендую посмотреть на него.

>Давайте делегируем полномочия или “Где мои атрибуты?!”

>

Так как я в последнее время занимаюсь различными задачами по делегированию полномочий, то приходится припоминать кое-какие хорошо забытые “базовые” вещи. На самом деле мне пришлось дважды воткнуться в проблему исчезнувших атрибутов, чтобы заняться ей всерьёз и обнаружить повторно, что понятие “filtered attributes” может относиться не только к RODC =)
Итак, ситуация обычно выглядит следующим образом: Вы пытаетесь делегировать полномочия на атрибут объекта в AD с помощью мастера делегирования и обнаруживаете, что это невозможно, поскольку он (атрибут) в мастере не виден. Не виден он так же и во вкладке Безопасность свойств объекта. Например, если я попытаюсь делегировать полномочия на изменение атрибута employeeID для контактов, мастер покажет мне следующее окно:
image
Как видно, здесь нет такого атрибута, как employeeID. Где он? Ну, это достаточно просто: многие атрибуты фильтруются из представления мастера (и не только). Это сделано, чтобы облегчить нам работу, так как существует множество свойств объектов, которые обычно просто не нужны (т.е. нет нужды их редактировать, конечно). “Но… Мне нужно делегировать полномочия на эти свойства!”,- скажете мне Вы. Отлично, никаких проблем: давайте вернем наши атрибуты на подобающее им место. Чтобы осуществить это, нам нужно внести некоторые измениния в файл dssec.dat, расположенный в папке %systemroot%system32 (резервная копия не должна пригодиться, но должна быть сделана Winking smile). Файл имеет вполне очевидную структуру: одна секция на каждый тип объекта, начинающаяся с [<attributename>] и заканчивающаяся с началом следующей секции. Например, секция для контактов будет выглядеть как-то так:
image
Из скриншота видно, что секция состоит из названий отфильтрованных атрибутов, знака “=” и числа. В красном прямоугольнике мы видим тот самый атрибут, который мы не можем видеть в мастере. Почему? Ну очевидно же, что из-за этой мерзкой цифры 7. Что бы нам такого туда поместить вместо нее? Вариантов немного:
  • Чтобы отобразить оба варианта read & write, поставим туда 0
  • Чтобы отобразить вариант write, используйте 1
  • 2 даст доступ к опции read
  • ну и оставьте там 7, чтобы убрать свойство из мастера целиком.
так что давайте поставим строку “employeeID=0”:
image
перезапустим нашу консоль ADUC и снова запустим мастер делегирования:

image
Voilà!
Дополнительное чтиво:
http://support.microsoft.com/kb/296490
http://technet.microsoft.com/en-us/library/cc756087(WS.10).aspx

>Делегирование управления DNS-зоной

>

Я вернулся. Извините за длительное отсутствие: все эти конференции и сборища MVP забирают слишком много сил и времени, хотя, конечно, очень полезны и приятны. Но теперь все пойдет по-старому, и начнем мы с делегирования управления одной зоной DNS, скажем, младшему системному администратору (без предоставления контроля над всем сервером или, упаси боже, AD). Очевидно, что мы можем легко предоставить пользователю право на создание и удаление объектов в зоне:

image_thumb

однако это не даст ему прав соединяться с сервером посредством консоли DNS (мы можем, конечно, работать с dnscmd, скажем, но… GUI есть GUI =) ):

image

Что делать в такой ситуации? Ну мы можем дать нашему младшему администратору административные полномочия на сервере, но:

  1. это немного слишком
  2. он получит права на весь DNS, а не только на зону
  3. обычно DNS-серверы расположены на DC, так что наш младшой получит права администратора домена

Оказывается, достаточно просто дать ему право Read на сам объект сервера в консоли DNS:

image

После чего наш младшой уже будет иметь тот доступ, который мы ему желали выдать:

image

Ну и конечно не забываем, что предоставлять пользователю доступ или полномочия напрямую – моветон. Создаем группу, даем полномочия ей и помещаем пользователя в нее же.