Pull to refresh

Сертификация доступа: уменьшаем риски, вооружившись актуальными данными

Reading time6 min
Views3.5K
Внутренняя политика и правила предприятия требуют от менеджеров постоянно следить за актуальностью уровня доступа сотрудников. Для организаций сферы здравоохранения, государственных ведомств, финансовых учреждений, любых акционерных обществ и предприятий, принимающих к оплате кредитные карты, это задача ключевой важности. Некорректная организация процесса сертификации прав доступа может очень дорого обойтись компании. Последствия могут быть разными: от «всего лишь» ухудшения имиджа до падения акций, штрафов, или даже гражданских и уголовных исков. Давайте рассмотрим сложности, связанные с сертификацией доступа, и пути их решения.

Аттестация
В большинстве организаций сертификация доступа – это скучная механическая работа. Чтобы определить, работает ли по-прежнему сотрудник в компании и необходимы ли ему те права доступа, которые у него имеются, IT-менеджерам приходится просматривать длинные списки в электронных таблицах. Чаще всего они понятия не имеют, какая информация доступна каждому конкретному работнику, и могут только строить предположения: раз человек все еще работает в компании, то доступ можно подтверждать. Ситуацию ухудшает наличие в подобных списках чек-бокса «отметить все», который экономит менеджерам время: достаточно просто выбрать эту опцию, и дело сделано.

Но представляет ли какую-то угрозу «слепая аттестация», когда менеджеры раздают права доступа, не зная их актуальности? Ну, правда, что плохого может случиться? В действительности же такой подход чреват серьезными неприятностями. Приведем пример: в октябре 2010 года бывший трейдер Societe Generale Жером Кервье (Jerome Kerviel) был приговорен к трем годам лишения свободы и выплате 4,9 миллиарда евро. Как выяснилось, Кервье совершал рискованные биржевые операции без контроля руководства и использовал для этого пароли, которые у него сохранились с предыдущих должностных позиций в компании.

Что-нибудь подобное может произойти в любой организации, если менеджеры будут слепо оставлять за сотрудниками права доступа на том основании, что они все еще работают в компании. Как, например, быть с сотрудником, которого недавно перевели из другого отдела? Оставлять ему доступ к файлам, которые были необходимы для его предыдущей работы, или так делать все же не стоит?

Источник проблемы
Зачастую у проблем, связанных с аттестацией, есть три причины:
  • Недостаток информации.
  • Непонимание информации, с которой приходится иметь дело.
  • Отсутствие четко установленного процесса сертификации доступа.


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

Некоторые организации делегируют проведение аттестации разработчикам приложений, но они обычно также не располагают информацией о текущей роли сотрудников и актуальности уровней доступа. К примеру, если разработчик несколько лет назад предоставил доступ сотруднику в ответ за запрос по электронной почте, теперь он может только найти имя этого сотрудника в списке отдела кадров компании и убедиться, что человек все еще работает в этой организации. Вероятнее всего, у него нет данных о текущих обязанностях этого сотрудника, равно как нет информации, нужен ли тот же самый уровень доступа для выполнения этих обязанностей. А вдруг человека недавно повысили или перевели в другой отдел?


Рис. 1. Обычно руководитель проекта видит, что сотрудник входит в его команду и выполняет определенные обязанности, но не знает, какие именно у него права доступа. С другой стороны, IT-менеджер видит, какие системы и приложения доступны сотруднику, но ему не известны ни обязанности сотрудника, ни необходимость доступа к тем или иным приложениям.


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

Недопонимание
В других организациях руководителям предоставляют списки всех прав доступа каждого конкретного сотрудника (вполне вероятно, сгенерированные самодельной программой). Но далеко не всегда в этих списках легко разобраться. Вот пример: проект-менеджер видит, что у Василия Пупкина есть доступ к \\DС7\С$\, но поймет ли он, что это означает? Вероятнее всего, он не будет знать, о каком сервере или общей папке речь, ко всем ли данным этого сервера есть у Василия доступ и так далее. Согласитесь, ситуация неоднозначная.


Рис. 3. Панель управления менеджера отображает количество работников и их обязанности. О наличии нерешенных задач или возникших проблемах сообщают графики в виде светофоров.


Рис. 4. Вкладка Entitlements отображает все сетевые элементы, к которым есть доступ у сотрудника.

Со стороны IT-менеджера тоже возникает недопонимание, но с точностью до наоборот. Ему как раз вполне ясно, что такое \\DC7\C$\, но он не знает, чем конкретно занимается Василий Пупкин, и действительно ли ему нужен доступ к \\DC7\C$\.

Отсутствие четко установленного процесса сертификации
Во многих организациях трудности сертификации доступа перекладывают на автоматизированные системы. Считается, что при наличии хорошо отлаженного алгоритма, который автоматически выдает права доступа и аннулирует их при увольнении сотрудника, пропадает необходимость в проведении регулярной сертификации. Но на практике это не срабатывает. Пользователям постоянно предоставляется доступ к новым программам и приложениям, и при этом он далеко не всегда вовремя отменяется. Классический пример – перевод сотрудника внутри компании, как в случае с трейдером Societe Generale. Часто после изменения должности или обязанностей у работника остается старый доступ просто потому, что никто не позаботился его закрыть. Человек ведь все еще работает в компании, в чем проблема?


Рис. 5. Детали о доступе сотрудника Скотта Харриса: он входит в группу IT, является администратором SharePoint, администратором и пользователем домена.


Рис. 6а. На этом примере показано, как менеджер Кэндис Кларк исключает из команды подрядчика Элейн Харпер.

Здесь не хватает четкого взаимодействия между IT-менеджерами, которые видят, какие права доступа имеет каждый конкретный работник, и проект-менеджерами, которые понимают текущие обязанности своих сотрудников.

Оптимальный подход к вопросу сертификации доступа
У каждой проблемы найдется решение, если разбить ее на небольшие части, и сертификация доступа не является исключением. Процесс можно разделить на такие составляющие:


Рис. 6б. Как только Кэндис Кларк исключила Элейн Харпер из списка сотрудников, администратор Скотт Харрис получает уведомление об этом с опцией «подтвердить». Как только Скотт подтверждает исключение, запускается процесс немедленной отмены прав доступа Элейн.


Рис. 7. Можно установить график регулярной аттестации прав доступа сотрудников.

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


Рис. 8. С помощью подходящих инструментов и руководители проектов, и IT-менеджеры могут отчетливо видеть, к каким сетевым ресурсам есть доступ у каждого из сотрудников. Это позволит им принимать обоснованные решения насчет сертификации доступа.

Что: определите, к чему требуется доступ
Следующим шагом будет определение всех потенциальных уровней допуска и детальное рассмотрение, которые из них уже имеются у каждого конкретного сотрудника. Для многих этот пункт может оказаться самым затратным по времени, поскольку придется добиваться списка пользователей у администраторов, отвечающих за каждое приложение, «расшаренную» папку и т.д. Если у вас уже есть подобный список, отсортированный по отделам или служебным обязанностям, его тоже нужно принимать во внимание.

Интерпретация: «переведите» названия всех элементов сети на понятный язык
Для предотвращения «слепой аттестации» этот шаг критически важен. Как уже было сказано, проект-менеджер может видеть, что у сотрудника есть доступ к серверу, но не понимать код, которым он обозначен. Руководитель проекта должен четко понимать, к чему именно он предоставляет доступ, а не «слепо» предполагать, что все и так в порядке.

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

Заключение
Сертификация доступа во многих организациях создает трудности из-за недостатка информации, недопонимания и отсутствия хорошо налаженного процесса. Руководители проектов понимают обязанности своей команды, но не их права доступа, а IT-менеджеры, наоборот, видят права доступа сотрудников, но не знают их текущих обязанностей. Кроме того, заменить взаимодействие между IT- и проект-менеджерами автоматизированным процессом просто невозможно. Поскольку «слепая» аттестация обычно подвергает организацию серьезным рискам, необходим новый взгляд на трудности, связанные с сертификацией доступа.

Решение Dell One Identity предоставляет четкий, всесторонний взгляд на сотрудников и их уровень доступа в простом для понимания формате. Четкая организация процесса и подходящие инструменты сертификации позволяют компаниям экономить время и обеспечивают лучшую защиту сети и ее соответствие потребностям организации.

Детальную информацию о Dell One Identity можно найти здесь.
Tags:
Hubs:
Total votes 2: ↑2 and ↓0+2
Comments0

Articles

Information

Website
www.delltechnologies.com
Registered
Founded
1979
Employees
over 10,000 employees
Location
США