IDM для замкадышей

Сакральным смыслом данного поста является телепортация знаний из сердца нашей Родины.

Итак, некоторое время над мы рассуждали  об IDM и даже получили ответ .
Сделаем второй шаг и выложим свои идеи бюджетной системы управления учетными записями для небольшой компании, размером в несколько тысяч сотрудников.
Начальные условия следующие:
1. Все пользователи хранятся в Active Directory.
2. Права в системах (всех, любых) даются на основании членства в группах Active Directory.
3. Вновь внедряемые или модернизируемые системы перестраиваются с учетом условий 1 и 2.

Термины и определения:
Базовые права – доступ к внутренней электронной почте и доменная учетная запись.
Шаблон должности – набор прав, характерный для данной должности.
Информационный ресурс - сущность, к которой осуществляется доступ на основании заявки.

Варианты работы с заявками.
1. Прием на работу
При приеме на работу Система, на основании информации из кадровой базы, оформляет и согласует для пользователя автоматически (здесь и далее, действие инициируется сотрудником кадровой службы) заявку на создание почтового ящика для пересылки внутри ИС.
Первый пароль пользователя передается системотехнику, который выходит на настройку компьютера. В свойствах учетной записи должен быть установлен параметр «Обязательная смена пароля при следующем входе в систему».
Система автоматически оформляет заявки в соответствии с шаблоном должности.
2. Увольнение
На основании заявления, кадровая служба обязана в момент получения заявления на увольнение установить параметр пользователя «Подготовка к увольнению». В результате Системой автоматически должны быть оформлены и согласованы заявки на блокировку доступа к следующим информационным ресурсам:
- внешняя электронная почта;
- доступ в Интернет;
- доступ к сменным носителям.
Так же после отъема этих прав, должна быть возможность передать их (автоматически оформить и согласовать заявки) на замещающего сотрудника в момент блокировки старого или позже. Эти заявки так же согласуются автоматически.
Передача прав не может быть осуществлена от одного сотрудника более одного раза.
В начале дня увольнения, в соответствии с заявкой, учетная запись блокируется в 00:01.
3. Увольнение и прием в дочернее предприятие (ДП).
При переводе в ДП в рамках головного предприятия и ДП, действуем аналогично п.2, кроме блокировки в день увольнения.
В начале дня увольнения, на основании информации из кадровой базы, автоматически оформляются и согласуются заявки на блокировку доступа ко всем информационным ресурсам, кроме электронной почты. При этом старым руководителем сотрудника и подразделением безопасности должно быть согласовано сохранение электронного адреса, либо его замена. Эта заявка должна быть подана автоматически не позднее чем за 3 дня до перевода. Если заявка не подана вовремя (заявление поступило в кадровую службу позднее), доступ пользователя блокируется полностью до оформления заявки на перевод с сохранением адреса или оформление в соответствии с п.1. При этом система должна проконтролировать несовпадение электронных адресов.
4. Перевод в другой, независимый отдел в рамках предприятия
При переводе в другое подразделение, в рамках одного предприятия, действуем аналогично п.3
5. Перевод на вышестоящую должность, Перевод на нижестоящую должность, Перевод в рамках отдела
Система автоматически, на основании информации из кадровой базы, оформляет и согласует заявку на блокировку учетной записи в связи с переводом, с указанием вида перевода. У сотрудника отбираются все права, кроме базовых.
Система автоматически оформляет и согласует заявки на предоставление прав в соответствии с шаблоном новой должности.
6. Смена фамилии.
При смене фамилии оформляется заявка (или 2 заявки) которая видна, если поиск осуществляется по старой или новой фамилии. При этом в заявке указывается что на что поменялось.
7. Отпуск, больничный, декретный отпуск, командировка.
При оформлении отпуска, больничного, декретного отпуска и командировки, на основании информации из кадровой базы, автоматически оформляется и согласуется заявка на блокировку учетной записи. По окончании периода блокировки, если это не противоречит информации из кадровой базы, системой автоматически оформляется и согласуется заявка на разблокировку пользователя.
8. Создание удаление инфрмационных ресурсов.
После подачи и согласования заявки, информация о ресурсе добавляется в базу, для оформления заявок на доступ. Бизнес администратор информационного ресурса назначается из числа сотрудников имеющих доступ к ИС. При увольнении сотрудника являющегося бизнес-администратором системы, система должна уведомить руководителя сотрудника, о необходимости назначить нового администратора.


Вот такие мысли. Жду комментариев.

От Мухи до Слона

Мой старший сын в этом году пошел в школу. К моему величайшему сожалению, я не могу ему уделять столько времени, сколько следовало бы прилежному отцу. Но современной школьной программой я стараюсь интересоваться, постоянно сравнивая то, что проходил когда-то я с тем, что проходят нынче.
Изучая прописи, я с ужасом заметил, что теперь детей в школе учат писать с отрывом. Странно, я помню, что меня даже ругали, когда я отрывал руку при написании слова, а теперь почему-то следует писать каждую букву с отрывом от предыдущих. Возможна даже ситуация, когда одна буква пишется в несколько подходов. Что еще более странно, - окончательно написанный текст выглядит как будто написанным без отрыва, т.е. практического смысла в отрыве ровным счетом никакого!
Для меня очевидно, что в письме без отрыва есть тайный смысл - увеличивается скорость письма от руки. Действительно, отрываясь каждый раз после написания буквы тратится время, банально, на отрыв ручки от страницы и на опускание на новое место (а иногда и на то же самое! поскольку окончательно написанное выглядит написанным без отрыва) в странице.
Так что же получается?! Наших детей в школе специально учат писать с отрывом. Зачем? Тут я усматриваю явный заговор. Пишущий с отрывом проигрывает в скорости письма тому, кто пишет без отрыва. Вспомним институт. Необходимо обладать достаточно высокой скоростью письма, чтобы конспектировать лекции. При этом, преподаватель ориентируется на большинство: если большинство успевает конспектировать, темп лекции сохраняется... Представим себе на мгновение, что все резко стали писать с отрывом => медленнее, чем ранее. Это приведет к необходимости снижения скорости лекций, что, в свою очередь приведет к снижению скорости преподавания. Снижение скорости преподавания в современных условиях крайне недопустимо, следует напротив, разрабатывать методы ускорения преподавания, а здесь - напротив, явная мера, направленная на снижение скорости обработки информации, в данном случае - конспектирования.
Уж не знаю, кто так поменял программу, но тяжело допустить, что он был настолько глуп, чтобы не догадаться до столь очевидных последствий. Считаю это заговором против России, тайным злым умыслом, который следует разоблачить и исправить как можно скорее, пока это не дало своих пагубных последствий!

На IDM or not IDM

Игорь, несмотря на то, что я буду стараться быть кратким, все-таки я решил воспользоваться своей возможностью писать постом, а не комментом :-)

1. Разные оргдокументы, требующие живых подписей, полагаю писались до нового закона о ЭП, откуда читаем в Статье 4:

"3) недопустимость признания электронной подписи и (или) подписанного ею электронного документа не имеющими юридической силы только на основании того, что такая электронная подпись создана не собственноручно, а с использованием средств электронной подписи для автоматического создания и (или) автоматической проверки электронных подписей в информационной системе."

+ по новому закону не обязательно использовать ГОСТовый.

Т.е., в целом, ничего не мешает двигаться в сторону электронного согласования.

Далее по рискам.

2.То, что Администратор царь и Бог - согласен. Но можно это компенсировать аудитом на отчуждаемое хранилище. Никто не собирается играть с админом в кошки-мышки, и риск его нелояльности не стоит пытаться компенсировать исключительно техническими мерами. Но можно:
а) Построить отчет соответствия фактических доступов в системе согласованным. Здесь уже многое зависит от реализации отчета, но технически практически все можно предусмотреть: предоставление доступа непосредственно аккаунтам, а не через согласованные группы, предоставление доступа через несогласованные группы, нелегитимное включение групп в группы, и т.п. б) вести аудит использования административных прав и критичных операций и забирать лог "к себе" (в SIEM) в, практически, реальном времени.
3. Фильтр твой - ужасен: "Если человеку действительно надо - он упорствует и получает доступ".
4. "Риски, связанные с использованием Избирательной модели управления доступом" - вообще, я тут о том, что есть принципиальная проблема в том, что некоторая сущность, Владелец ресурса, на свое усмотрение принимает решение о присвоении\неприсвоении доступа. Вообще-то такое доверие Владельцу небезопасно: он может ошибаться как по доброте душевной, так и по злому умыслу. Ролевая модель в этом плане предпочтительнее, поскольку ее можно привязать к штатке или каким-либо другим функциональным образованиям, тогда присвоение роли будет происходить при назначении пользователя на позицию (штатную или функциональную, например, роль в проекте), что уже выполняется более или менее коллегиально, а не по решению какого-то там Владельца ресурса.
5. С устареванием прав можно бороться:
- принудительной инициализацией пересмотра прав пользователей при его движении по штатке,
- предоставление доступа на время Проекта или просто на время (в случае необходимости, пользователи будут продливать - тоже сродни твоему "фильтру", но менее цинично :-)).
6. Про SOD-ы. Не все так просто: "есть доступ" и "нет доступа". Есть роли, которые нельзя совмещать и тебе это известно: Разработчик и Тестировщих, Разработчик и Пользователь, Бухгалтер и Казначей, пр. При проектировании бизнес-процесса необходимо выделять критичные операции, которые недопустимо совершить кому-то единолично. Тут и наши любимые админы: да они могут все, но от их действий должен остаться аудиторский след, причем в месте, где они не смогут "потереть логи" => администратор системы и администратор безопасности должны быть разными людьми. Аудит, традиционно, должен быть независим. В общем, роли, которые недопустимо совмещать, найдутся. Так вот, при присвоении ролей, следует проверять SOD-ы, т.е. есть пользователю присваивается Роль2, а у него, скажем, уже есть Роль1, дающая с Ролью2 конфликт высокого риска, такое присвоение не должно свершиться. Очевидно, что недопустимость совмещения Роли1 с Ролью2, разумнее проверять автоматически. Это сможет сделать IDM.
7. Избыточность полномочий частично компенсируется мерами изложенными в 5. Но твой пост на эту тему крайне интересен - пиши.

Далее пост твой сводится к извечному выбору между разработкой и коробочным решением. Тебе же известно, что я тоже наколеночник со стажем :-) и со времен работы в РосНИИРОС свято верю, что gcc и perl достаточно для реализации чего угодно :-) Но, я на личном опыте знаю чего стоит разобраться в коде талантливого программиста (а вы часто делаете комментарии? Вот я с тех пор часто, хотя не уверен, что это поможет тем, кому достанутся мои труды), поэтому все эти скрипты и "программки" имеют достаточно высокую вероятность умереть с уходом разработчика. Попробую систематизировать выбор тезисами (не буду их расшифровывать, если будут спорные моменты, лучше напрягусь и сделаю отдельный пост):
1. надо стараться выбирать коробочное решение. Стоимость его поддержки в будущем - ниже.
2. надо стараться настройку выполнять силами будущей поддержки. Либо, если уж настройка выполняется в проекте, будущая поддержка должна плотно участвовать в настройке.
3. если коробочное решение в своей типовой\рекомендуемой конфигурации не удовлетворяет потребностям, следует посмотреть в сторону изменения бизнес-процессов в соответствие с тем, что запрограммировано в коробочном решении.
4. должно быть нормальное описание конфигурации и Configuration Management.
5. если коробочное решение не удовлетворяет и требуется более 30% доработки - выбираем разработку. Тут поясню. Коробочные решения предлагают некие встроенные языки: Sun Java IDM - x-press, SAP - ABAP, у 1С - свой, русскоязычный, и т.п. Все эти языки создают иллюзию бесконечной гибкости (иллюзию? Я вас уверяю, что писать на C# куда приятнее, чем на X-Press + практически никаких ограничений!). Так вот, если предстоит "допиливать" более 30% коробочной бизнес-логики, и обойти это никак - берите Visual Studio, Java NetBeans, perl+vi или что вы там любите - это будет лучше.
6. если вы уж взялись за разработку, то тут уже надо хорошенько подумать о том, как потом не похоронить творение с уходом разработчика, чтобы "человечек с хорошими штанами" мог как-то поддерживать, а еще лучше и развивать, эту разработку. Тут можно предложить - документировать код по формальным правилам (ох, только правила надо придумать....).

Linux - не все так плохо

Читал книжку, Linux глазами хакера, 3-е издание. Прочитал странную вещь:

Прошу прощения, что криво, но хотелось именно процитировать.

Еще с дремучего издания Андрея Робачевского известно, что символьная ссылка ссылается на имя файла (у нее даже размер равен имени файла с путем :-)), т.е. несмотря на то, что символьная ссылка имеет права 0777, это не значит, что будет полный доступ к файлу. Тем не менее, не поленился проверить. Думаю, комментарии излишни:

root@daczcsvst60pde:/# ln -s /etc/shadow /etc/shadow.lnk

root@daczcsvst60pde:/# ll /etc/shadow*

-rw-r----- 1 root shadow 1218 Feb 6 17:50 /etc/shadow

-rw------- 1 root root 1218 Feb 6 17:50 /etc/shadow-

lrwxrwxrwx 1 root root 11 Mar 14 22:04 /etc/shadow.lnk -> /etc/shadow

svsoldatov@daczcsvst60pde:/$ cat /etc/shadow

cannot read /etc/shadow: Permission denied

svsoldatov@daczcsvst60pde:/$ cat /etc/shadow.lnk

cannot read /etc/shadow.lnk : Permission denied

Может, я что неправильно понял?

IDM or not IDM

Не говорите, что эфир не существует! Только начал упорядочивать на бумаге порядок оформления заявок на доступ к информационным ресурсам, как Сергей затрагивает тему IDM!

Когда пришел на нынешнее рабочее место 3 года назад, здесь для согласования доступа к информационным ресурсам во всю использовались бумажные заявки. Заявки согласовывались около недели, терялись и не поддавались учету.

На первом этапе, в пику разным оргдокументам, требующим живых подписей и печатей, сделали учет и ввод заявок в табличку шарепоинта. Процесс ускорился.

Следующим этапом перестали согласовывать заявки для ресурсов, которые не прошли процедуру регистрации (на которые не оформлена заявка на создание ресурса и не определен бизнесадминистратор).

Затем попытались категорировать ресурсы. Пара недель работы с администраторами толку не дали - результаты валяются в виде файла и не находят применения в реальной жизни (об этом нужно писать отдельно).

Потом появились заявки на блокировку учетных записей. Сделали их для борьбы с мертвыми душами. Но такой способ блокировки не был принят пользователями.

Тогда перешли к этапу, на котором при создании учетных записей требуем от пользователей указывать, кто работал до них на этом рабочем месте. Ох и тяжело, порой объяснить человеку, что от него хотят и что нужно сделать...

Что имеем сейчас:

• почти 20000 заявок собранных за 3 года.
• категорированный перечень из более чем 150 информационных ресурсов
• дикие трудозатраты на оформление и сопровождение заявок
• историю доступа пользователей к ресурсам
• некое подобие шаблона прав для пользователей, когда вновь принятому сотруднику высылается список заявок оформленных его предшественником
• випов, получающих доступ куда хочется посредством движения бровью

А теперь давайте посмотрим, как мы подвержены рискам указанным тут:

• Предоставление группой эксплуатации (ИТ) доступа, отличного от согласованного - какая ни была бы ИС - с IDM или без него, администратор всегда сможет дать доступ по высшему повелению или внутреннему позыву.
• Предоставление доступа на основании «некорректного» согласования (доступ не согласован в установленном порядке) - ну для этого мы имеем историю заявок для определенной позиции. Кстати говоря, нельзя не упомнить здесь следующее - 90% сотрудников пишут заявку на доступ в Интернет, к внешней электронной почте и сменным носителям. Рассматривать все эти заявки - долго, поэтому на первую заявку мы с вероятностью 98% отвечаем отказом. Если человеку действительно надо - он упорствует и получает доступ. Вот такой фильтр.
• Риски, связанные с использованием Избирательной модели управления доступом - решаем на коленке, через просмотр истории заявок для новых сотрудников
• невозможность выявления некорректных прав пользователей - центральный сервер syslog собирает и хранит записи об изменениях в структуре АД, планируем делать ежедневный diff для АД и максимально автоматизировано сравнивать его с табличкой в шарепоинте
• устаревание прав ввиду изменения бизнес-процессов Компании - почему мне не верится, что IDM может помочь "бороться" с любовью людей "переставлять мебель" спонтанно и быстро
• некорректное совмещение критичных полномочий в информационных системах - но ведь мы не военное ведомство. У нас по сути групп доступа 2 - сотрудники имеющие доступ к коммерческой тайне и сотрудники не имеющие к тайне доступа... Неужели без IDM-ма не справимся с этими 2-мя группами?
• избыточные полномочия пользователей в случае изменения их статуса в бизнес-процессах Компании - а вот этому посвятим следующий пост.

Что мы видим? Наняв человечка с минимальной квалификацией и хорошими штанами, выплачивая ему 7-15 т.р. в месяц мы можем получить естественно-интеллектуальную систему управления учетными записями. С больничными и отпуском есть проблема, но размер зарплаты позволяет нам организовать холодный или даже горячий резерв!

IDM для Информационной безопасности

Возможно, очевидные вещи будут здесь написаны, но, надеюсь, кому-то будет полезно.

Преимущества от внедрения IDM получат все: ИТ, так как повысят свою efficiency - многие работы будут автоматизированы, Бизнес, так как использование бизнес-ролей и ролевой модели доступа с привязкой к корпоративной оргструктуре и/или бизнес-процессам Компании позволят им понимать к чему сотрудники имеют доступ, Безопасность, так как будут адресованы ряд ключевых рисков, связанных с контролем доступа.

На безопасности хочется остановиться подробнее, отметив основное, что на мой взгляд должно объективно стимулировать движение в сторону подобных решений. Все-таки 21ый век на дворе и ручно-бумажно-пешконосный контроль доступа выглядит несовременно :-)

Риск: Предоставление группой эксплуатации (ИТ) доступа, отличного от согласованного.

Контроль: IDM автоматизирует процесс наделения учетных записей техническими правами, доступ предоставляется без участия администратора.

Риск: Предоставление доступа на основании «некорректного» согласования (доступ не согласован в установленном порядке).

Контроль: Процесс согласования доступа жестко запрограммирован в IDM: правильность маршрута согласования обеспечена конфигурацией IDM.

Риск: Риски, связанные с использованием Избирательной модели управления доступом (discretionary access control, DAC)

Контроль: IDM позволяет построить Ролевую модель управления доступом, при которой успешность предоставления доступа не будет полностью основываться на решении согласующих (Владельце ресурса, например), а будет зависеть от позиции пользователя в бизнес-процессах компании (должности, подразделении, функциональных обязанностях).

Риск: невозможность выявления некорректных прав пользователей (некорректно присвоенных ранее или устаревших ввиду различного рода изменений в компании).

Контроль: IDM позволяет проводить сравнение своей базы доступов (корректно согласованных) с фактическим состоянием технических прав в обслуживаемых информационных системах. Таким образом, обеспечивается проведение периодического технического аудита полномочий пользователей, что позволит выявлять ошибки и злоупотребления.

Риск: устаревание прав ввиду изменения бизнес-процессов Компании.

Контроль: IDM предоставляет ответственным от бизнеса удобный интерфейс просмотра и корректирования бизнес-ролей пользователей. IDM позволяет этот процесс инициировать принудительно по расписанию, что позволит обеспечить выполнение требований безопасности. Подобный аудит безнес-ролей пользователей позволит в большей степени соблюдать принцип Минимума полномочий (Least Privilege) – не нужные, устаревшие права будут отобраны по инициативе бизнеса.

Риск: некорректное совмещение критичных полномочий в информационных системах.

Контроль: IDM позволяет автоматизировать соблюдение принципа Разделения ответственности (Segregation of Duties, SOD): Роли которые нельзя совмещать у одного пользователя не смогут быть запрошены и/или присвоены.

Риск: избыточные полномочия пользователей в случае изменения их статуса в бизнес-процессах Компании.

Контроль: IDM интегрируется с системами кадрового учета, таким образом, любое кадровое изменение пользователя будет инициировать процесс пересмотра прав пользователя в информационных системах.

Перечисленное - первое, что пришло в голову. Если что забыл - комментарии приветствуются.

Все в аутсорсинг!

Есть какой-то показатель - количество персонала на баррель добытой нефти (даже не смог быстро найти в Гугле как он называется). Смысл, в целом, понятен - чем меньше персонала, непрофильного, на баррель добытой нефти, тем нефтяная компания эффективнее. Говорят, это влияет на готовность банков давать кредиты, т.е. на размер заемного капитала. Ключевое слово здесь - "непрофильного". Отчасти от этого наблюдается тренд - функциональные подразделения ранее, теперь становятся подрядчиками. Не будем говорить , насколько аутсорсинг выгоден в условиях конкурентного рынка - вопрос сильно зависит от конкурентности среды (в РФ с конкуренцией ситуация особенная), также не будем говорить о том, что мерить фактическое количество персонала тоже достаточно глупо, - правильнее мерить себестоимость...

Тем не менее, предприятия активно выводят непрофильный бизнес на рынок отчасти из-за желания улучшить указанный показатель.

Поскольку все читали модные книжки про ITIL, CobIT и т.п., аутсорсинг ИТ - распространенное явление. Всем понятны процессы, метрики, услуги, компоненты, SLA-и и прочие атрибуты качественного аутсорсинга.

Почему-то иногда (или зачастую), тем не менее, ИТ-аутсорсинговая компания остается дочерней компанией Заказчика. Это позволяет Заказчику влиять на различные внутренние процессы Подрядчика, что, очевидно, перекашивает аутсорсинг.

В частности, Зказачик может потребовать от Подрядчика сокращения численности. Может, по причине необходимости улучшения показателя о чем писалось ранее в этом посте (действительно, компания-то дочерняя!), может, еще по каким причинам. При этом, сокращая численность, никто не говорит о том, что следует сокращать объемы или снижать качество! Какое-то время Подрядчик крутится, оказывая прежний объем услуг уже сокращенной численностью (при этом, кстати, наблюдается нереальная рентабельность, правда, ценой "перегрева" ресурсов), но потом вынужден что-то придумывать... Мультисорсинг! Вот решение!

В целом, нормальное решение - часть услуг, которые по каким-то критериям отобраны (отчасти этим критериям и посвящен пост, см ниже) передаются на рынок. При этом Подрядчик становится генподрядчиком, а фактические исполнители этих, отобранных, услуг - на субподряде. Нормально. Только подход с замораживанием\сокращением штата - абсолютно неправильный, ибо штат - функция объемов, и стимулировать переход некоторых услуг на рынок штатом - неправильно. Это приводит к "шоковому" аутсорсингу, который в итоге приводит (тут сильна зависимость от менеджмента: при талантливом руководстве, очевидно, "шоковость" может и не сказаться, но где его взять талантливого :-(....) к снижению качества услуг (построить непрерывный сервис из дырявой штатки - надо уметь!).

Но, вернемся к тому, что мультисорсинг неплох и попробуем сформулировать критерии вывода услуг на рынок. Я бы предложил следующие критерии:
1. Критичность. Как бы мы не верили в эффективный (== способный предоставить достойное качество сервиса) рынок, не все можно распродавать. Сюда относятся услуги, которые критичны по качеству, по доступности, по безопасности и т.п. Вопрос спорный, - идеалист может возразить, что теоретически можно все предусмотреть SLA-ем, но на практике создать идеальный SLA крайне сложно, а есть случаи, когда ошибаться нельзя. Тут еще такой момент: в высокотехнологичном сервисе, квалификация приемщика услуг должна быть не ниже Подрядчика, банально, чтобы понять и оценить. Да, мы придумываем метрики, пытаемся все померить и посчитать, чтобы численно выразить что такое плохо и что такое хорошо, но на практике не все так просто :-( Скажу даже больше, высококвалифицированный ИТшник, как и Безопасник должен постоянно быть "в бою", - и потому что для обладания экспертизой нужно иметь постоянную практику, и потому что в мире ИТ все крайне динамично меняется. В общем, как минимум, экспертиза какая-то быть должна надежная (== своя).
2. Наличие предложения на рынке. Нам нужна конкуренция, как единственный механизм обеспечения качества. Если на рынке нет\мало поставщиков, удовлетворяющих всем необходимым требованиям, очевидно это нельзя зааутсорсить.
3. Внутренние компетенции по услуге. Если мы обладаем высоким уровнем внутренней компетенции, бенчмаркинг показывает высокую эффективность (effectiveness & efficiency) нашего сервиса, это не надо продавать. Отсюда, кстати небольшое следствие: если что-то мы делать не умеем или делаем плохо, давайте попробуем это зааутсорсить. Но тут надо учесть то, что для приемки также нужна экспертиза (см. 1).
4. Степень соответствия стратегии. Да, у Подрядчика тоже должна быть Стратегия и, как следует из ISACAиных книжек про Governance, она должна тесно коррелировать со стратегией Заказчика\Компании. Стратегически важные сервисы не надо продавать.
5. Степень формализации требований Заказчика к услуге. Тут все понятно: не надо продавать то, что неформализовано, - тяжело оценить степень соответствия ожиданиям. Тоже, вроде как, все понятно, но если мы аутсорсимся потому что сами делаем плохо (п 3), очевидно оно у нас не формализовано, надо с этим что-то делать :-(
6. Себестоимость. Критерий сильно коррелирует с 3, ибо полностью про efficiency, но, думаю его стоит выделить отдельно. Смысл прост: если что-то мы делаем дороже, чем можно это купить на рынке, это стоит вывести на рынок. Если услуга на рынке стоит дороже, чем мы сами это делаем, лучше делать самому.
7. Стоимость управления и контроля. Нельзя аутсорсить ответственность! А раз ответственность от Заказчика никуда не девается, Подрядчика надо контролировать. Контроль должен быть осуществим, он должен быть дешевле, собственно, стоимости работ.

Критерии спорные, но в любом случае, какие-то должны быть, чтобы процесс вывода сервисов был продуманным, тут очень важно не ошибаться.

В заключение о правильном подходе:
1. придумать критерии,
2. пропустить через них все услуги Подрядчика
3. Вывести то, что по критериям надо выводить.
Идем от услуг и критериев, не от штата на баррель :-)