Role-Based Identity Management at Mazda Motor Europe
•Transferir como PPT, PDF•
4 gostaram•2,270 visualizações
Experience Mazda Zoom Zoom Lifestyle and Culture by Visiting and joining the Official Mazda Community at http://www.MazdaCommunity.org for additional insight into the Zoom Zoom Lifestyle and special offers for Mazda Community Members. If you live in Arizona, check out CardinaleWay Mazda's eCommerce website at http://www.Cardinale-Way-Mazda.com
![Role-Based Identity Management at Mazda Motor Europe Dr. Horst Walther [email_address] Presented at the Cyprus Infosec - 4th International Conference on Information Security at October 21 st , 2004 in Nicosia / Cyprus.](https://image.slidesharecdn.com/2004-10-21rbacatmazdahorstwalther-091227233923-phpapp01/85/2004-10-21-Rbac-At-Mazda-Horst-Walther-1-320.jpg)
![The Focus - Mazda Motor Europe ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (17)
Semelhante a Role-Based Identity Management at Mazda Motor Europe
Semelhante a Role-Based Identity Management at Mazda Motor Europe (20)
Mais de CardinaleWay Mazda
Mais de CardinaleWay Mazda (20)
Último
Último (20)
Role-Based Identity Management at Mazda Motor Europe
- 1. Role-Based Identity Management at Mazda Motor Europe Dr. Horst Walther [email_address] Presented at the Cyprus Infosec - 4th International Conference on Information Security at October 21 st , 2004 in Nicosia / Cyprus.
- 34. S top, A ppendix From here on the back-up-slides follow ...
Notas do Editor
- First let’s give some characterising basic key data: MME (Mazda Motors Europe) is the headquarters, based in Leverkusen / Germany not far from Cologne and Düsseldorf at the banks of the river Rhine. Most of the European logistics and Information processing is done in Mazda Logistics Europe (MLE) in Willebroek / Belgium near Antwerpen. As sales are local business, it’s the responsibility of national sales companies (NSC) in the major European markets and Distributors in emerging or smaller markets. The NSC’s basically service their connected authorised dealers (AR) and authorised repairers (AR). In the most prominent market, Germany, several central marketing areas (CMA) are defined in order to enable common activities among the local dealers. Gently forced by the European commission through it’s so called ‘group exemption regulation’ we need to support independent motor traders (IMT) and independent distributors (ID) as well. The dealers and their employees by far outnumber the ~ 500 employees of Mazda in Europe. We assume, that the actual number of dealers is about 2,500 and that each dealer has delegated access to the system to 2 – 3 of his employees, resulting in 5,000 – 7,500 users at present and an estimated number of ~ 10.000 over the next 3 years.
- 1.1 Why roles? So why did we come across with role engineering? Well, we simply need some categorisation of our users as the B2B-Portal requires a basis for personalisation and access control, the proposed workflow-systems demands for similar information and the Indentity Management Software from Netegrity can do it’s job more smoothly and transparently by using roles. Nevertheless, we have been warned. In-house our administrators reported, that they couldn’t recognise any clear privilege pattern for most of the in-house users and predicted as much roles as we do have users – if not more. Additionally the role engineering related literature is full of hidden or even direct hints that those few brave and noble fighters, who would successfully complete a project to introduce role based access control (RBAC) would be guaranteed a seat in the hall of fame. Well that’s not what we are aiming for. Instead, we are deeply convinced that roles represent a very natural way to describe organisational structures. It is obvious, that in existing organisations entitlements and restrictions are determined by several different dimensions … This list is far from being complete, but only few of these determining dimensions lead to own roles (e.g. Hierarchy and Function). The others have to be dealt with differently.
- The idea of cross-platform user administration goes back to the late eighties when software companies first saw the need to develop tools, which allowed maintaining users and their privileges on corporate level across all of their production systems in one step. At about the same time researchers in the US worked on methods for access control based on roles (RBAC), an ordering scheme, which originates from the organization theory. When the first tools for cross-platform security administration appeared on the market around the middle of the nineties, it became apparent that the abstraction of the access control concept using role semantics was necessary to exploit the full potential of these administration tool. At the same time, research provided the first formal role models.
- The central idea behind roles is to simplify authorisation management by associating permissions with a role and then assigning this role to a user. Roles are often used in applications to enforce policy. For example, an application might impose limits on the size of the transaction being processed depending on whether the user making the request is a member of a specified role. A bank teller might have permission to process transactions only less than a specified threshold, supervisors might have a higher limit, and managers might have a higher limit, etc. In other words, roles can be related to various job positions and the permissions associated with them. A way to look at Roles is the collection of resources and permissions associated with a class of user(s). The class will be granted a consistent set of services based upon their Role. Roles are often equal to job functions in many organisations. Currently, different administrators or application vendors have different definitions of roles. As this situation may serve as a source for confusion, we therefore henceforth will refer to the deserving research of the National Institute of Standards and Technology (NIST).
- First let’s give some characterising basic key data: MME (Mazda Motors Europe) is the headquarters, based in Leverkusen / Germany not far from Cologne and Düsseldorf at the banks of the river Rhine. Most of the European logistics and Information processing is done in Mazda Logistics Europe (MLE) in Willebroek / Belgium near Antwerpen. As sales are local business, it’s the responsibility of national sales companies (NSC) in the major European markets and Distributors in emerging or smaller markets. The NSC’s basically service their connected authorised dealers (AR) and authorised repairers (AR). In the most prominent market, Germany, several central marketing areas (CMA) are defined in order to enable common activities among the local dealers. Gently forced by the European commission through it’s so called ‘group exemption regulation’ we need to support independent motor traders (IMT) and independent distributors (ID) as well. The dealers and their employees by far outnumber the ~ 500 employees of Mazda in Europe. We assume, that the actual number of dealers is about 2,500 and that each dealer has delegated access to the system to 2 – 3 of his employees, resulting in 5,000 – 7,500 users at present and an estimated number of ~ 10.000 over the next 3 years.
- There are three concepts, which are frequently confused: roles, rules and groups. The confusion originated very much from inaccurate use of the terms isolated from their original context and from reluctant abbreviation of their accurate form. As proposed by the NIST roles can be understood as groupings of cross system privileges on enterprise level. Although rarely defined explicitly, when “groups” are mentioned, they are used as groupings of users. Hence, the general term “group” cannot be used for discrimination with sufficient clarity. To add to this confusion some implementers implement roles through dynamic groups while at the same time maintaining user groups - without being able to clearly state the inherent differences. Rules in contrast to these both statically usable grouping constructs only unfold their power when interpreted at runtime. Rules are generally understood as general expressions using symbolic variables and Boolean or even arithmetic operators. They might be nested using brackets as commonly used delimiters. All three concepts may be used independently but it is recommended to combine them in balanced way in order to achieve optimal modelling results. While dealing with the semantics of user management terms it should be mentioned, that throughout this conference paper the terms entitlement, privilege, access right and permission are used synonymously.
- RBAC is now an American National Standard - ANSI INCITS 359-2004 (approved 19 Feb 04). The NIST RBAC Models offer four increasingly powerful yet increasingly demanding variations with respect to implementation. These fine-grained variants allow less sophisticated implementing systems to realise a subset of the full-blown RBAC set rather than failing completely by not complying with the maximum requirements. RBAC0 The minimum requirement for an RBAC system, comparatively easy to implement, but limited in modeling power. RBAC1 Is based on RBAC0 and adds role hierarchies for expressing inheritance relationships. RBAC2 Is based on RBAC0 and adds constraints for expressing restrictions imposed by the enforcement of corporate policies.. RBAC3 Is a combination of both enhancements from RBAC1 and from RBAC2 .
- Separation of duties (SoD) is determined from organizational policy. RBAC facilitates splitting administration of the role-user relationship from that of the role-permission relationship . Since many users in an organization typically perform similar functions and have similar access rights, user functions are separated by role. Separation of duties requires that for particular sets of transactions, no single role be allowed to execute all transactions within the set. As an example, there are separate transactions needed to initiate a payment and to authorize a payment. No single role should be capable of executing both transactions. Separation of duties by role is valuable in deterring fraud since fraud can occur if an opportunity exists for collaboration between various job-related capabilities. A role can be further qualified with affiliation. A person’s access could be limited to a geographic or departmental boundary. For example, a role of branch manager could be qualified by an affiliation to a particular branch thereby conferring branch manager permission only within that branch. Both static and dynamic forms of separation exist. Static separation (SSD) means that roles which have been specified as mutually exclusive cannot be included together in a user's set of authorized roles. Dynamic separation (DSD) means that while users may be authorized for roles that are mutually exclusive, those exclusive roles cannot be active at the same time. In other words, static separation of duty enforces the mutual exclusion rule at the time of role definition while dynamic separation of duty enforces the rule at the time roles are selected for execution by a user.
- One step, that cannot be done mechanically is the detection of candidates and the subsequent design of roles. As this information is not available explicitly, it must be generated in a non-deterministic reverse engineering process. This step requires good knowledge of the business domain, some experience at least in related business modelling areas and a sound portion of intuition. Watch out for … User categories – List each type of user that requires access to corporate online resources. For example: employees, partners, suppliers, customers, and investors. Jobs – List jobs within each user category. For example in the Employees group, there are several jobs (Director, Manager, Supervisor, Accountant, Sales Representative, Researcher, Designer, and so on) whereas in the Customer group there might be only two (Registered Customer and Guest). Job functions – List business operations within each user and job category. For example, the Sales Representative submits orders, views orders for the district, manages customer complaints, and accesses the company intranet. Registered Customers submit orders, check account status, and check a web site for special incentives for current customers. Aggregate job functions – Identify job functions that everyone, or large numbers of users, perform. Whenever possible, job functions should be consolidated. For example, all Employees use the company intranet; all sales personnel can view order status. Job tasks – List each task in each job function. For example, for using the company intranet, there might be two tasks in that role: view intranet and print intranet pages. When to use groups – Determine when groups are preferable to roles. Groups are best used when there are a low number of users working in a static environment for a specified period. For this situation, groups can be an excellent organization unit that can be easily created and then deleted. Groups are also best suited to support self-subscribing interest areas. Users can easily join and remove themselves from the group requiring minimal, if any, administrator support.
- Aus unser Sicht muss sich die Auswahl der Identity Management- Lösungen an den Geschäftsprozessen orientieren. Diese Betrachtungsweise identifiziert die Bereiche, in denen Identity Management vordringlich ist und erlaubt auch eine gezielte Auswahl der erforderlichen Technologien. In dieser Methodik geht es darum, die Rolle von Lieferanten, Mitarbeitern und Kunden in den Geschäftsprozessen zu analysieren und zu gewichten. Daraus lässt sich ableiten, welche Rolle die jeweiligen Gruppen und ihre Identitäten für die Gestaltung von Geschäftsprozessen spielen. Auf dieser Basis lassen sich dann wiederum die erforderlichen Funktionen des Identity Management ermitteln.
- Roles are static constructs relying on a minimum stability of the defining business environment. For some cases they turn out to be too static, i.e. too difficult to keep current. This objection is specifically true for dynamic business functions and dynamic industries. For cases like this augmentation of roles by executable business rules may help. Rules can m odify or restrict role-based entitlements e.g. only modify sales data in your territory. They can create additional entitlements not based on roles e.g. anyone in “corporate” gets HQ building access. Thus, they can be used to complement roles. Obviously the effects of role based entitlement assignment can be misunderstood and simply done wrong. From early lessons learned the advice can be given: Don’t try to represent all user entitlement requirements in Roles. Role proliferation is a serious management problem anyway and a security issue too, as security is truly a direct function of transparency and simplicity. Easily situations can be constructed, where role inflation occurs, resulting in more roles than users. Not surprisingly inappropriate design may adversely affect transparency and, even worse, let the situation deteriorate, it was intended to improve. If on the other hand a radically dynamic approach is followed, data requirements for rules may be difficult to meet, especially with respect to availability and reliability.
- Frequently occurring business functions with low or medium complexity obviously promise best result to effort ratios. Those functions are most commonly found at the lower end of the traditional enterprise pyramid, where operational functions are located. Here is clearly a good starting point for role engineering. The nearer the role engineer comes to the headquarters and the more he moves up the corporate hierarchy the more difficult his task becomes. The portfolio diagram may serve as a guideline while looking for a good starting point for role engineering.