Все это, безусловно имеющие право на жизнь ситуации, но в нашем случае они не применимы. Я кстати отношусь не к СБ, а к ИТ и СБ у нас к информационной безопасности вообще никакого отношения не имеет. Поэтому ниже, везде, где под "СБ" я подписываюсь "мы" я имею ввиду "ИТ".
FDS>Например, FDS>1. СБ предоставляет не все полномочия, хотя ей кажется, что все. Пример: когда была ОС MS Windows 98 доходило до того, что запрет на работу с дискетами человек вынужден был ломать BIOS путём программного сброса и последующей CMOS. Причём часть данных в системе действительно он не имел права уносить на дискете, а часть — имел право и имел такую необходимость.
Мы не обладаем эксклюзивным правом определять полномочия сотрудников. В этом процессе, наравне с нами участвуют, как минимум непосредственный руководитель сотрудника и бизнес-владельцы той системы или информации к которой сотрудник просит доступ. Если их решение не будет совпадать с нашим, то далеко не факт, что оно будет принято с учетом наших интересов. Другое дело, что руководителям очень часто удобнее сказать сотруднику, что доступ зарубили злые ИБшники, нежели объяснять реальные причины отказа.
В том примере с админом (реальном, кстати) доступ был зарублен всеми тремя сторонами одновременно. А негатив пошел только на ИБ
FDS>2. СБ задерживает создание нового аккаунта по неизвестным причинам. В итоге запрошенный аккаунт создаётся только через несколько месяцев после соотв. запроса: естественно ведётся работа под чужими аккаунтами.
Мы вообще не участвуем в процессе создания аккаунтов, этот процесс полностью автоматизирован и зависит только от того, как быстро HR оформит карточку сотрудника в ERP. Под чужими аккаунтами же чаще всего работают, замещая болеющих сотрудников, либо сотрудников в отпусках. Это при том, что у нас есть и работает механизм замещения (предоставления прав замещамого аккаунту замещающего на период отсутствия сотрудника), о котором все знают, но не все используют, т.к. там сотруднику надо совершить несколько неизбежных действий руками, чтобы один раз настроить замещение по всем системам на конкретного замещающего. Разумеется, сотрудники откладывают это на потом (хотя там дел — на 10-15 минут) и когда они внезапно уходят на больничный, настроить свое замещение уже не могут (ну, только если у них нет удаленного доступа в сетку).
FDS>3. Система безопасности не позволяет давать полномочия другим пользователям, в то время как это необходимо и обоснованно, а выдача полномочий через СБ практически невозможна (выдаётся с существенной задержкой и слишком много запросов приходится отправлять). В итоге администратор требует себе дополнительных прав, но СБ считает, что они ему не нужны (в то время, как ему таких запросов может потребоваться удовлетворить по десятку в день на пике активности)
Предоставление прав у нас тоже автоматизировано в большей части систем и исполнение таких заявок идет мимо как нас, так и администраторов В том случае, админ хотел собирать логи с DC, но их можно было тогда получать только с правами домен-админа. Он хотел получать информацию о логонах/логоффах пользователей и на базе этой информации определять одновременную работу под одной учеткой на разных компах. Но это совершенно не входило в его обязанности, поэтому ему и отказали давать столь широкие права на пустом месте.
FDS>пункт 3 — это параноидальность. Первый и второй пункты — это бестолковость, причём не интерфейса СЗИ, а бестолковость СБ, которая препятствует нормальной работе пользователей с обеспечением всех требований безопасности
Мы (ИТ) имеем SLA (соглашения об уровне сервиса) подписанные со всеми основными департаментами компании. В частности, там прописаны и критерии "нормальной работы пользователей", причем весьма подробно. Нарушение SLA ведет к крайне негативным последствиям на очередной этапе оценки персонала (есть у нас такой процесс), поэтому его соблюдение является у ИТшников одной из первоочередных целей. Все, что выходит за рамки SLA — идет либо сразу лесом, либо на усмотрение ИТшников.
Ладно, я прошу прощения, что чуть-чуть поморочил голову... Тем админом был я сам около 6 лет назад, еще до перевода в департамент ИБ Но негатив в сторону ИБшников у меня тогда был конкретный, хотя сейчас я и понимаю, что был неправ
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, FDSC, Вы писали:
KV>Все это, безусловно имеющие право на жизнь ситуации, но в нашем случае они не применимы. Я кстати отношусь не к СБ, а к ИТ и СБ у нас к информационной безопасности вообще никакого отношения не имеет. Поэтому ниже, везде, где под "СБ" я подписываюсь "мы" я имею ввиду "ИТ".
Я просто привёл пример того, что может быть. Ты, как сотрудник ИБ, просто не знаешь, почему именно пользователи что-то делают. Видимо, 10-15 минут работы по настройке — это для них много и муторно (да и знают ли они, как настраивать?) и так далее. Все нарушения режима всегда имеют причину.
KV>Ладно, я прошу прощения, что чуть-чуть поморочил голову... Тем админом был я сам около 6 лет назад, еще до перевода в департамент ИБ Но негатив в сторону ИБшников у меня тогда был конкретный, хотя сейчас я и понимаю, что был неправ
Ты как раз был прав в некотором смысле — со своей точки зрения. Проблема как раз в том, что как только такие админы уходят на ИБ, они сразу же забывают свои проблемы. В итоге специалист по ИБ думает, что пользователи — это одно и работают так-то, а пользователи на самом деле совершенно другое и работают по другому.
Короче говоря, как всегда забывают про людей: конечно, в этом виноваты не специалисты по ИБ (точнее, не только они). Если бы вы сделали скрипт автоматической настройки замещения пользователя — не было бы у вас проблемы работы под чужими аккаунтами. Если пользователи делают так, значит вы им на голову сыплите проблемы, которые они решать не хотят.
Опять же, это пример зашоренности (а может быть, и недостатка средств), которая сейчас очень распространена: как всегда во всём обвиняют стрелочника, будь то конкретный пользователь или специалист по ИБ.
Re[5]: О том, как плохо понимать термин безопасность по учеб
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>В исходном сообщении я привел ссылку на одну из моих старых тем, там я описываю этот же процесс но на модели STRIDE, которая по сути практически та же CIA, только с аутентификацией, авторизацией и аутентичностью, т.е. тем, о чем ты сейчас и говорил, как о недостающих звеньях.
Я там не только о аутентификации говорил. Я бы даже сказал, о ней я как раз промолчал .
С исходном, это в каком?
KV>Но ведь суть сказанного мной от этого не меняется, просто мне показалось, что на CIA это объяснить легче и писать нужно меньше, но не более того
Да нет, надо просто писать, что это модель и она имеет свои ограничения. Я почему так взъелся: видно, что ты говоришь о каком-то конкретном случае (конкретной модели угроз), но есть и другие. А говоришь так, как будто эта система вообще общая для всех ИС.
Если наши разногласия только в этом, то дальнейший спор, конечно, бессмыслен.
Здравствуйте, MozgC, Вы писали:
MC>Юзер зачастую не способен правильно оценить опасность и может считать предлагаемые для повышения безопасности действия — излишней параноидальностью. Некоторые даже приклеивают sticky notes с паролями на монитор, а когда им запрещаешь это делать — они считают это параноидальностью
Не способен понять — это имхо редкие-редкие исключения.
Гораздо чаще, это всё осознанно. Вторжение — не их проблема, защита от него — не их обязанности. Они не понимают, зачем им прилагать усилия для решения не их проблем. Поэтому по принципу K.I.S.S., делают простые пароли, одинаковые ко всем аккаунтам и записывают их туда, где их легко достать. Управлять простым способом или сложным — для них выбор очевиден, а как оно для тебя — о тебе они заботиться не собираются.
Здравствуйте, kochetkov.vladimir, Вы писали:
IT>>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
KV>В идеале — да. Но у нас юзеры не любят, к примеру, что им предоставляют только те полномочия во внутренних системах, которые им необходимы для исполнения их служебных обязанностей. Например админ, у которого в обязанности входит администрирование лишь одного куста в иерархии AD, почему-то требует права домен-админа и не получив их, клянет именно безопасность в том, что ему вставляют палки в колеса. Или вот еще, юзеры очень не любят, что у нас запрещено работать под чужой учеткой и также клянут нас за это при любом удобном случае. Где тут что-то из перечисленного тобой?
Мой пример: для обмена файлами есть папки проектов, куда имеют доступ только участники проектов. Но все продолжают пользоваться общедоступной шарой. Если ее закрыть, открывают свою.
Почему?
Потому что дизайнер не может эскиз положить, у него прав не оказалось, надо ждать до завтра, пока откроют.
Потому что пришел новенький, ему еще не завели, и что его теперь, домой отправлять?
Потому что баг пересекся с другим отделом, надо выцеплять кого-то, чтобы тебе дали инсталлер их софтины.
Потому что четкое разграничение прав — это как идеальная женщина, не может существовать и ее характеристики противоречат сами себе. Всегда, постоянно надо сделать что-то, на что прав быть не должно, но в этот конкретный раз — очень надо.
И т.д. И т.п. Общедоступная шара — это простой интерфейс, я кладу, они берут, мне надо, я беру. Запросы через кого-то — это интерфейс, который 5-минутное дело рястягивает на сутки (это если никто не в отпуске и не с ненормированным графиком). Какой человек в своем уме захочет его использовать?
Самое главное, эта бюрократия тормозит самых ценных, увлеченных людей, которые могут сделать все и сразу, если не вставлять им палки в колеса. А лодырям дает оправдания: не сделал, прав не было, все еще не сделал, ответа жду, через три дня родил.
И, таки-да, это можно доказать строго и математически (я хз как математически, но логически — легко)
Если интересно про математически, то советую погуглить "Basic Secuity Theorem" и главное работы с ее комментариями.
KV>Всех, кого данный посыл заинтересовал, прошу под кат.
Поехали
KV>1. Выявления рисков информационной безопасности, существующих в этой системе KV>2. Рекомендаций по их устранению, или минимизации ущерба в случае их реализации
s/риск/угроза
Риск реализовать нельзя, правда угрозу устранить тоже (кстати, это просто-таки ключевой момент, который упорно не понимают наши регуляторы: можно хоть их кожи вон лезть, но объективная угроза, например, ограбления квартиры будет существовать всегда и повлиять на ее существование невозможно, а вот затруднить реализацию — всегда пожалуйста).
KV>Если же говорить о математической строгости, то можно математически строго доказать небезопасность любой реализованной информационной системы и разговаривать, в общем-то, будет больше не о чем. Но жить тогда станет совсем скучно
С другой стороны можно доказать безопасность нереализованной. Между прочим знаменитая оранжевая книга писалась не вдруг, а было очень много исследований на тему и постулаты TCSEC'а во многом переплетаются с базовыми аксиомами теоретических моделей защищенных компьютерных систем.
И еще по поводу точных оценок — рассчитать надежность, например, отдельно взятого самолета тоже невозможно... Но мы же считаем эту технику надежной и никто не говорит, что это баззворд. Потому что есть оценка этой самой надежности. И этим занимается теория функциональной безопасности (правда тут безопасность — safety, а не security). Есть даже международные стандарты в этой области (например, ISO 61508).
Здравствуйте, IT, Вы писали:
IT>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
Прям-таки любых?
Обобщать-то не надо. Идеальная система должна работать незаметно для пользователя, иначе может сработать:
— отторжение самой системы (ну с этим еще можно справится)
— эффект компенсации риска (а вот с этим хуже).
Примером последнего могут служить такие интересные факты, что повышение безопасности автомобиля слабо влияет на общее число жертв ДТП — поставили ABS, стали хуже соблюдать дистанцию, понаставили ремней, подушек и т.п. — стали гонять под 200 и так далее.
MC>Юзер зачастую не способен правильно оценить опасность
Вот это правильные слова.
MC>Некоторые даже приклеивают sticky notes с паролями на монитор
А это следствие, но не причина. Знание пароля пользователем накладывает на него обязанности по защите этой информации, а "Юзер зачастую не способен правильно оценить опасность" (с) — собственно, что же вы хотели?
Вывод — создаешь нормальную систему защиты, сделай так, чтобы не пользователь должен был принимать решения, связанные с безопасностью.
KV>Или вот еще, юзеры очень не любят, что у нас запрещено работать под чужой учеткой
А это не должно быть запрещено.
Надо:
1. Понять почему возникает такая необходимость (наверное нужен доступ к информации сотрудника, который сейчас на обеде/в отпуске и т.п.)
2. Сделать так, чтобы использовать чужую учетку было невозможно в принципе (например, сильная аутентификация на токенах, которые по совместительству ключи для СКУДов, чтоб даже из комнаты без него выйти нельзя было)
3. Сделать в вашем IDM'е (а я таки узнал, что вы используете ) процесс замещения, который не будет отличаться от своего "некомпьютерного" собрата.
Здравствуйте, IT, Вы писали:
IT>Давай добавим сюда недостаточный уровень обучения ваших юзеров.
Обучение тут не поможет. Вот ты дорогу вообще всегда на зеленый переходишь? Или все-таки нет? Научили что ли плохо?
IT>Но опять же вопрос — ваших юзеров вообще кто-нубудь когда-нибудь чему-нибудь из области безопасности учил? Хотя бы какие-нибудь элементарные азы?
У них — думаю да
IT>В моей конторе я обязан прослушать ряд курсов по безопасности и внутренним правилам компании, после чего должен ответить на ряд вопросов или поставить галку acknowledge. Естественно, есть вводная при поступлении на работу и ежегодные повторялки напоминалки. А если я это всё буду игнорировать, то мною серьёзно займётся Compliance Department. Всё это, кстати, сделано опять же без паранойки, а в максимально удобной и ненавязчивой для юзера форме. Итого, я знаю про безопасность, она знает про меня, мы друг друга уважаем и стараемся лишний раз не докучать друг другу.
Это хорошо, но тоже не идеально. В идеале все решения, связанные с безопасностью, должны приниматься профессионалами, а не пользователями.
Здравствуйте, FDSC, Вы писали:
FDS>1. СБ предоставляет не все полномочия, хотя ей кажется, что все.
Сразу возникает ряд вопросов:
1. Почему "все" или "не все" определяет СБ, а не непосредственный руководитель, которому явно виднее, чем тебе заниматься?
2. Почему СБ предоставляет? Это вообще не их работа...
FDS>Пример: когда была ОС MS Windows 98 доходило до того, что запрет на работу с дискетами человек вынужден был ломать BIOS путём программного сброса и последующей CMOS. Причём часть данных в системе действительно он не имел права уносить на дискете, а часть — имел право и имел такую необходимость.
Что тут сказать. Были способы сделать это все адекватнее — но не стали.
FDS>То же касалось, если не ошибаюсь, Windows 2000, в которой нельзя было пользоваться флэш-памятью из-под обычного аккаунта пользователя, так как это считалось установкой нового устройства и было запрещено.
Вопрос можно было решить более тонкой настройкой прав, чем тупо давать админа.
FDS>2. СБ задерживает создание нового аккаунта по неизвестным причинам. В итоге запрошенный аккаунт создаётся только через несколько месяцев после соотв. запроса: естественно ведётся работа под чужими аккаунтами.
Ну а если бы эти же несколько месяцев человека не знала бы бухгалтерия? Пришлось бы естественно работать за чужую зарплату?
Вообще неправильно эти процессы разделять — если человек появился в компании, то он должен появится одновременно и в кадровой системе, и в службе каталога, и в телефонном справочнике и картотеке медицинского кабинета и много где еще.
FDS>3. Система безопасности не позволяет давать полномочия другим пользователям, в то время как это необходимо и обоснованно, а выдача полномочий через СБ практически невозможна (выдаётся с существенной задержкой и слишком много запросов приходится отправлять). В итоге администратор требует себе дополнительных прав, но СБ считает, что они ему не нужны (в то время, как ему таких запросов может потребоваться удовлетворить по десятку в день на пике активности).
Еще раз. Есть бизнес процессы. Есть безопасность этих процессов.
Если такой бардак — значит никто не анализировал ни сами процессы, ни требования к их безопасности. Просто тупо взяли какой-нибудь идиотский документ типа СТР-К и реализовали.
FDS>пункт 3 — это параноидальность. Первый и второй пункты — это бестолковость, причём не интерфейса СЗИ, а бестолковость СБ, которая препятствует нормальной работе пользователей с обеспечением всех требований безопасности
Все три пункта это бестолковость. Причем не только (не столько) СБ, а сколько руководства.
И вообще — найти нормального безопасника гораздо сложнее чем, например, нормального админа.
Я вот вообще каждый раз удивляюсь — почему Владимир работает в эксплуатации, а не в каком-нибудь консалтинге по вопросам ИБ.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Это при том, что у нас есть и работает механизм замещения (предоставления прав замещамого аккаунту замещающего на период отсутствия сотрудника), о котором все знают, но не все используют, т.к. там сотруднику надо совершить несколько неизбежных действий руками, чтобы один раз настроить замещение по всем системам на конкретного замещающего. Разумеется, сотрудники откладывают это на потом (хотя там дел — на 10-15 минут) и когда они внезапно уходят на больничный, настроить свое замещение уже не могут (ну, только если у них нет удаленного доступа в сетку).
Это кто ж вам так криво сделал процедуру замещения? Конечно ей не пользуются — она же нежизненная ни фига. В какой реальной ситуации может потребоваться больному сотруднику предоставлять доступ на свой компьютер? Инициатором будет не он, это же очевидно. И решение принимать должен не он.
А дальше все просто — в вашем IDM'е должен быть определен процесс замещения, который может инициировать тот, кто должен его инициировать в жизни (сам замещающий сотрудник, начальник и т.п.) и согласовать предоставление должен тот, кто в жизни это делает (например, непосредственный руководитель).
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>7. Разработчики: С чем? Вы нам напишите четко, что вас не устраивает и как должно быть,
Ты им SDL и Threat Modelling Tool в зубы выдай и скажи — вот, написал
Здравствуйте, Andir, Вы писали:
A>Слово "безопасность" (подразумевается информационная безопасность) — это определённо базворд. Примерно как и XML. Никакого реального смысла ни за тем, ни за другим не стоит. A>Правильным термином является скорее "защита информации" — та самая, которая процесс направленный на ... (целостность, конфиденциальность, доступность).
Карл Маркс и Фридрих Энгельс — это 4 разных человека. В том смысле, что безопасность информации, информационная безопасность и защита информации — это разные вещи. Причем очень разные.
Про информационную безопасность в этой ветке вообще ни слова не прозвучало, если что. Только про безопасность информации.
И безопасность информации это вовсе не "баззворд". Как правильно написал Владимир — это состояние, а защита информации — это процесс, усиленно пытающийся это состояние обеспечить.
Если мы говорим о каких-то измерениях, то оценивать надо, очевидно, состояние, а не процесс.
A>Защита информации является процессом достижения этих определённых целей какими либо своими методами, но как и любой реальный процесс никогда своих целей не достигает и не может достигнуть в принципе. Свои цели достигаются всегда. Не достижимы идеальные. Например, проектируя высоконадежную систему никто не станет закладывать доступность 100% — это недостижимо.
A>Хороший пример — это криптографические протоколы, которые математически уже столь сложны, что проверить их принципиальную "безопасность" могут лишь единицы криптографов.
Все симметричные протоколы построены на идее гаммирования с обратной связью или без нее (обычно задается режимом). 99% использует конструкцию Фейстеля. Так что не надо — все там изучено вдоль и поперек. Шифры замечательно оцениваются по параметру криптостойкости (иначе к чему был этот долгий процесс выбора реализации AES?).
A>Но даже и при этом, все эти протоколы состоят из примитивов, которые математически опираются на "достаточно долгий процесс взлома простым перебором".
Э-э-э-э-э... А ты точно хорошо ориентируешься в теме?
A>Тут как говорится: Атаки всегда становятся только лучше. И рано или поздно, но любой алгоритм и/или протокол будет взломан, а на его базе уже были построены тысячи систем и протоколов.
Ну и дальше что? Почему до сих пор много где применяют DES, хотя он давно уже не является криптостойким?
Хинт: если ты ломаешь криптографическое сообщение за 2 минуты, а оно живет 1 минуту и дальше оно уже бесполезно, то грош цена твоему взлому.
A>P.S. Пример из реальной жизни криптографов: процесс взлома алгоритмов семейства MD (MD5, SHA-1). Cуть взлома заключается в примитивном компьютерном переборе и поиске неподвижных "точек" алгоритма хеширования, которые затем объединяются в неподвижный путь. Алгоритм хеширования сам по себе настолько сложный (хоть и примитивный внутри), что существование и/или несуществование неподвижных путей внутри алгоритма доказать вычислительно невозможно. И вся "безопасность" алгоритма держалась на вычислительной трудности выполнения этой задачи. Но вначале нашлась одна почти случайная коллизия, а затем все быстро пробежали путь от нахождения новых коллизий до создания поддельных сертификатов X.500 ... Вся история улучшения этой примитивной атаки подробно описана: MD5 considered harmful today.
Хэш функции это какбе не шифры. С ними ситуация другая, но и там математики хватает, просто у нас иной раз не любят заморачиваться "по мелочам"
Здравствуйте, Кодёнок, Вы писали:
Кё>И т.д. И т.п. Общедоступная шара — это простой интерфейс, я кладу, они берут, мне надо, я беру. Запросы через кого-то — это интерфейс, который 5-минутное дело рястягивает на сутки (это если никто не в отпуске и не с ненормированным графиком). Какой человек в своем уме захочет его использовать?
Угу. А потом начнется:
Какой "?№!№ удалил мой файл?
Кто написал эту чушь?
Почему мне дали не последнюю версию файла??
и т.д. и т.п.
Хорошее сравнение — системы контроля версий. Тоже блин, сложности какие-то лишние — только работать мешают, заразы. Ату их!
Re[4]: О том, как плохо понимать термин безопасность по учеб
Здравствуйте, FDSC, Вы писали:
FDS>А настоящая безопасность всегда оперирует различными уровнями абстракций, а так же вообще неабстрактными понятиями. Например, ты оперировал двумя: просто говорил о потоках информации, и говорил о информационной системе.
Настоящая безопасность всегда оперирует очень четкими почти математическими определениями. Именно это создает трудности при прочтении твоего сообщения — ты используешь термины иначе.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Контрмера — заворачиваем трафик в https. Защитили? Нет, ибо угроза — все то же нарушение конфиденциальности учетных данных при передаче, но с новым фактором — пользователь прошляпил сообщение о фальшивом сертификате. Контрмера — на данном уровне абстракции и/или этапе workflow невозможна, т.к. фактор человеческий.
Это еще можно пытаться лечить повышая образованность пользователей, объясняя смысл "зелёной полоски" в браузере. Реальной технической урозой является атака man in the browser, что делает куча троянов, например Zeus.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Некоторые участники форума с завидным постоянством употребляют термин "безопасный язык" уязвимость и т.п. в контексте использования например языка С в линуксе.
Без указания опасностей, угроз или конкретных проблем слово "безопастность" превращается в чистейший бессмысленный базворд.
Здравствуйте, DOOM, Вы писали:
DOO>Хорошее сравнение — системы контроля версий. Тоже блин, сложности какие-то лишние — только работать мешают, заразы. Ату их!
Некоторые системы контроля версий тоже мешают работать.
Кодёнок правильно перечислил кучу основных моментов, которые мешают не потому что так надо, а потому что так есть (бестолковость организации защиты)
), только теперь вместо ответа, что это бестолковость руководства, ты отвечаешь, что так и должно быть, хотя Кодёнок просто сказал всё то же самое в более абстрактных словах: и всё, оказывается, что так и должно быть.
В том случае, админ хотел собирать логи с DC, но их можно было тогда получать только с правами домен-админа. Он хотел получать информацию о логонах/логоффах пользователей и на базе этой информации определять одновременную работу под одной учеткой на разных компах. Но это совершенно не входило в его обязанности, поэтому ему и отказали давать столь широкие права на пустом месте.
Но негатив в сторону ИБшников у меня тогда был конкретный, хотя сейчас я и понимаю, что был неправ 
) процесс замещения, который не будет отличаться от своего "некомпьютерного" собрата.
Это кто ж вам так криво сделал процедуру замещения? Конечно ей не пользуются — она же нежизненная ни фига. В какой реальной ситуации может потребоваться больному сотруднику предоставлять доступ на свой компьютер? Инициатором будет не он, это же очевидно. И решение принимать должен не он.
