Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Providing rights




Verification

Requesting access

Process activities, methods and techniques

Access (or restriction) can be requested using one of any number of mechanisms, including:

  • A standard request generated by the Human Resource system. This is generally done whenever a person is hired, promoted, transferred or when they leave the company
  • A Request for Change
  • A Service Request submitted via the Request Fulfilment system
  • By executing a pre-authorized script or option (e.g. downloading an application from a staging server as and when it is needed).

Rules for requesting access are normally documented as part of the Service Catalogue.

Access Management needs to verify every request for access to an IT service from two perspectives:

  • That the user requesting access is who they say they are
  • That they have a legitimate requirement for that service.

The first category is usually achieved by the user providing their username and password. Depending on the organization’s security policies, the use of the username and password are usually accepted as proof that the person is a legitimate user. However, for more sensitive services further identification may be required (biometric, use of an electronic access key or encryption device, etc.).

The second category will require some independent verification, other than the user’s request. For example:

  • Notification from Human Resources that the person is a new employee and requires both a username and access to a standard set of services
  • Notification from Human Resources that the user has been promoted and requires access to additional resource s
  • Authorization from an appropriate (defined in the process) manager
  • Submission of a Service Request (with supporting evidence) through the Service Desk
  • Submission of an RFC (with supporting evidence) through Change Management, or execution of a pre-defined Standard Change
  • A policy stating that the user may have access to an optional service if they need it.

For new services the Change Record should specify which users or groups of users will have access to the Service. Access Management will then check to see that all the users are still valid and automatically provide access as specified in the RFC.

Access Management does not decide who has access to which IT service s. Rather, Access Management executes the policies and regulations defined during Service Strategy and Service Design. Access Management enforces decisions to restrict or provide access, rather than making the decision.

As soon as a user has been verified, Access Management will provide that user with rights to use the requested service. In most cases this will result in a request to every team or department involved in supporting that service to take the necessary action. If possible, these tasks should be automated.

The more role s and groups that exist, the more likely that Role Conflict will arise. Role Conflict in this context refers to a situation where two specific roles or groups, if assigned to a single user, will create issues with separation of duties or conflict of interest. Examples of this include:

  • One role requires detailed access, while another role prevents that access
  • Two roles allow a user to perform two tasks that should not be combined (e.g. a contractor can log their time sheet for a project and then approve all payment on work for the same project).

Role Conflict can be avoided by careful creation of roles and groups, but more often they are caused by policies and decisions made outside of Service Operation – either by the business or by different project teams working during Service Design. In each case the conflict must be documented and escalated to the stakeholder s to resolve.

Whenever roles and groups are defined, it is possible that they could be defined too broadly or too narrowly. There will always be users who need something slightly different from the pre-defined roles. In these cases, it is possible to use standard roles and then add or subtract specific rights as required – similar to the concept of Baselines and Variants in Configuration Management (see Service Transition publication). However, the decision to do this is not in the hands of individual operational staff members. Each exception should be coordinated by Access Management and approved through the originating process.

Access Management should perform a regular review of the role s and groups that it has created and manage to ensure that they are appropriate for the services that IT delivers and supports – and obsolete or unwanted roles/groups should be removed.




Поделиться с друзьями:


Дата добавления: 2014-12-23; Просмотров: 379; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.009 сек.