The Workplace and its Collaboration Tools

It’s great to be able to work from anywhere, any device and having the technology work when you need it. More than a luxury, it’s a necessity in the current intensified remote working situation, or for international organisations with very mobile, distributed, fluid users. While so many changes happen during the crisis, your workplace should support your business reconfiguration through enabling staff, partners, suppliers to work with different applications, different teams, etc.

The word “Workplace” used in this context refers to more than the workstations and collaboration tools. It extends to wider areas such as enterprise architecture, application security & identity and access management. Arguably, we’re talking about the wider IT foundation/digital capabilities, to support and enable business needs – the workplace might just be the tip of the iceberg.

Legacy upon Legacy adds Complexity

On the user side, as soon as you go through multiple use-cases, e.g. accessing a legacy system on premise or a Software as a Service application, you are likely to require multiple accounts and therefore a cumbersome user experience.

On the IT operation side, it is equally a burden to make it work: workstations are still most of the time a physical device bound to a rigid corporate domain; they need to be configured, then shipped to remote staff or external parties, and accounts still need to be provisioned in target environments, with access rights set appropriately. All the above usually being different processes which are repeated for each supplier or partner, leading to as many devices and set ups.

More importantly, how secure is this disorganised and overlapping situation? Having visibility and control on who has access to what, end to end and for all environments, is a challenge because of the siloed use-cases. And as users join and leave, applications evolve, the security level likely decreases by lack of keeping accounts and rights accurate.

In our experience at Wavestone, all these challenges stem from the accumulation of new use-cases and technology, implemented in silo, for their own use or limited group of use-cases. The platform, which was first designed with one primary use, has now altered into a manifold use platform with an ill-fitting model and processes. Many organisations today can be proud to rely on a federated platform and modern access experience for cloud applications on one side – and a different, yet reasonably good, experience on internal applications side. However, often both are not integrated and therefore don’t get the benefits we described in the introduction. We believe this comes from the lack of a truly shared model/architecture to support a modern experience, across all use-cases.

.

Figure 1 – Example of a corporate model in which each entity manages identities and their access separately: duplicating processes

One Model for a streamline experience

For this reason and for the future of user experience, at Wavestone we believe in a model based on Identity Control Tower(s).

An Identity Control Tower is a platform to enforce your access policies. Its purpose is to verify access requests coming from trusted sources of identity and determine if that identity is allowed to access a target digital resource. For the metaphor, a pilot willing to get clearance for take-off will submit their flight plan using a trusted channel, and after its approval and other verification by controllers, the pilot can proceed to take-off. If we were to transpose this metaphor digitally, we would talk about a user: in order for said user to access X platform, (s)he would need to use a corporate process which itself is trusted by an Identity Control Tower. Said user would provide their “access plan” (e.g. session token) to the Identity Control Tower. After the Identity Control Tower has verified the authenticity of the “access plan” against its access policies it will perform other checks of context, such as: time of the request, location of origin of the access, trust level of the device etc, the user can then proceed to access the resources. Should these verifications highlight anything unusual or inconsistent in authenticating the user, additional requests can be made to allow the user in (re-authentication or step up).

The Identity Control Tower is under your control and holds the conditions of access i.e. access policies and accepts users from specific sources thanks to a pre-established trust relationship between organisations.

For instance, in the diagram below, imagine a situation in which a supplier is developing a new service in your cloud environment. Users from the supplier would keep their device and authentication process they use within their corporate environment, while the Identity Control Tower (ICT) would enforce access control to the cloud environment – without having to use and manage a different account and re-authenticate. For environments with very granular privileges like AWS, building a decoupled ICT is maybe not a realistic approach and the ICT is then probably the identity platform from Amazon that is managed by your organisation and linked to the identity provider of the supplier. The Identity Control Tower model is basically an extension of federation, implemented to cover all use-cases.

Figure 2 – Access of a Partner user to a Cloud Provider resource through an Identity Control Tower

In another scenario, as seen in this diagram, let’s consider an applicant applying for a job in your organisation, thanks to a recruitment portal you offer. They would initiate an application in your portal using their government-backed digital identity, and once they provide their consent to access their LinkedIn profile, you could obtain a digital CV. For the applicant, it is as simple as showing their ID and giving a copy of their CV, rather than filling-in registration form(s) asking once again for the same standard identity information and risking a typo in their contact details – or even having to send copies of sensitive documents like their passport.

Figure 3 – An alternative scenario presenting the trust relationship between a government ID platform and the corporate

One Model, Three Key Pillars

Using our knowledge and experience, we believe that this model should be built upon three key pillars: a unique identity across all systems, a common and flexible model to access information and, the establishment of a 360° trust relationship.

A Unique Identity Architecture: this is achieved by following a simple rule: don’t duplicate identity data. The less identity records you create for the same physical person, the more streamline the digital experience will be – as cumbersome steps start to appear when an additional account, device or authentication action is required for the user to access the target resource. The key behind a unique identity data is to try reusing the data from its (authoritative) source instead of duplicating/copying it in your own systems. For instance, the suppliers or partners working with your organisation likely already have professional digital identities for their own IT use – what would be the conditions to leverage them instead of re-creating them?[1] The next two pillars contribute to answering this question.

A Common and Flexible Model: The second pillar is to use a common and flexible model to allow/restrict access to information. To provide flexibility, an attribute-based access control (ABAC) model enables granular rules and is well suited to a risk-based and adaptive approach. To make it work though, it is essential to define the “grammar” of the authorisation model: what are the actual attributes used to provide accesses that make sense at the enterprise level? How do they translate into “privileges”? What are their formats/values? When the Identity Control Tower is provided by a cloud provider (e.g. from a Cloud provider as Azure or AWS), the grammar is often determined by the said service. Furthermore, to make this model as widespread as possible across use-cases, both on the identity source side and on providing access on the target service side, we recommend implementing your platform following market standards to maximise inter-operability (SAML, OpenID Connect, OAuth, FIDO, etc.).

360° Trust Relationship: Finally, the last pillar is to ensure the establishment of a 360° Trust Relationship. In other words, perform due diligence and establish confidence thresholds to accept interconnection (“technical trust”) of identity platforms. The due diligence should extend to all upstream processes leading to feeding the platform with identities, for instance the HR/procurement processes to vet identities, up to the IT on-boarding process itself – because trusting an identity platform is a first step for these identities to access your digital resources, you need to be within tolerance of the risk it comes with. This trust relationship should then be implemented through security level expectations, auditability in contractual clauses, and enforced via the supplier service management governance. With such strong requirements, one organisation must be prepared to temporarily on-board suppliers or partners within the organisation’s own platform, while suppliers or partners remediate their processes and platforms to be compliant.

Two key success factors

In order to implement these three key pillars, Wavestone has identified two key success factors: being sponsored by appropriate level of management and building resilience and privacy by design. A transformation programme to establish this model would have implications and requirements in several of your organisation’s departments (HR, sourcing, legal, IT, risk, security etc.), hence should be sponsored by top-management and driven with a pan-organisation approach.
Additionally, as it should always be, the supporting platform should be designed and built with security, privacy and resilience considerations from the beginning.

Final Thoughts

As you have been able to understand throughout this article, looking at the user experience end to end and across use-cases is key to really streamline digital services. This can be achieved with a pan-organisation shift to enforce a unique identity across all systems, a common and flexible model to access information and, the establishment of a 360° trust relationship with third parties.

To go further in your reflection on the subject and understand the current state of your organisation, think about these questions and try to answer them: picking users from different departments, what does the typical day to day digital experience look like? How long does my organisation take to on-board contractors and third parties? How does my organisation actually give access to its data and resources for external users? How many duplicate identities exist across my IT estate?

[1] A technical entry might still exist within your systems, for reference purposes – but from the user perspective there is no new account, no duplicate, if they don’t have to register a new login, credentials etc.

Cet article Key Enablers in Creating a Seamless and Secure User Experience est apparu en premier sur RiskInsight.

Le lieu de travail et ses outils de collaboration

C’est formidable de pouvoir travailler de n’importe où, avec n’importe quel appareil et de disposer de la technologie nécessaire quand on en a besoin. Plus qu’un luxe, c’est une nécessité dans la situation actuelle de travail à distance intensifié, ou pour les organisations internationales dont les utilisateurs sont très mobiles, répartis et fluides. Alors que tant de changements se produisent pendant la crise, votre lieu de travail devrait soutenir la reconfiguration de votre entreprise en permettant au personnel, aux partenaires, aux fournisseurs de travailler avec différentes applications, différentes équipes, etc.

Le mot “lieu de travail” utilisé dans ce contexte ne se limite pas aux postes de travail et aux outils de collaboration. Il s’étend à des domaines plus larges tels que l’architecture d’entreprise, la sécurité des applications et la gestion des identités et des accès. On peut dire que nous parlons de la base informatique plus large et des capacités numériques, pour soutenir et répondre aux besoins des entreprises – le lieu de travail n’est peut-être que la partie visible de l’iceberg.

L’héritage sur l’héritage ajoute de la complexité

Du côté de l’utilisateur, dès que vous passez par plusieurs cas d’utilisation, par exemple l’accès à un système existant sur place ou à une application Software as a Service, vous êtes susceptible d’avoir besoin de plusieurs comptes et donc d’une expérience utilisateur lourde.

Du côté de l’exploitation informatique, c’est également un fardeau de la faire fonctionner : les postes de travail sont encore la plupart du temps un dispositif physique lié à un domaine rigide de l’entreprise ; ils doivent être configurés, puis expédiés au personnel distant ou à des parties externes, et les comptes doivent encore être approvisionnés dans des environnements cibles, avec des droits d’accès définis de manière appropriée. Tous les éléments ci-dessus sont généralement des processus différents qui se répètent pour chaque fournisseur ou partenaire, ce qui entraîne autant de dispositifs et de configurations.

Plus important encore, dans quelle mesure cette situation désorganisée et chevauchante est-elle sûre ? Avoir une visibilité et un contrôle sur qui a accès à quoi, de bout en bout et pour tous les environnements, est un défi en raison des cas d’utilisation cloisonnés. Et à mesure que les utilisateurs rejoignent et quittent l’entreprise, que les applications évoluent, le niveau de sécurité diminue probablement en raison du manque de précision des comptes et des droits.

D’après notre expérience chez Wavestone, tous ces défis découlent de l’accumulation de nouveaux cas d’utilisation et de nouvelles technologies, mis en œuvre en silo, pour leur propre usage ou pour un groupe limité de cas d’utilisation. La plateforme, qui a d’abord été conçue pour une utilisation principale, s’est maintenant transformée en une plateforme à utilisations multiples avec un modèle et des processus mal adaptés. De nombreuses organisations peuvent aujourd’hui être fières de pouvoir compter sur une plate-forme fédérée et une expérience d’accès moderne pour les applications en nuage d’un côté – et sur une expérience différente, mais raisonnablement bonne, du côté des applications internes. Cependant, souvent, les deux ne sont pas intégrés et ne bénéficient donc pas des avantages que nous avons décrits dans l’introduction. Nous pensons que cela est dû à l’absence d’un modèle/architecture véritablement partagé pour soutenir une expérience moderne, dans tous les cas d’utilisation.

Figure 1 – Exemple de modèle d’entreprise dans lequel chaque entité gère séparément les identités et leur accès : duplication des processus

Un modèle pour une expérience de rationalisation

Pour cette raison et pour l’avenir de l’expérience utilisateur, chez Wavestone, nous croyons en un modèle basé sur la ou les Tours de Contrôle d’Identité.

Une tour de contrôle d’identité est une plate-forme permettant de faire respecter vos politiques d’accès. Son but est de vérifier les demandes d’accès provenant de sources d’identité fiables et de déterminer si cette identité est autorisée à accéder à une ressource numérique cible. Pour reprendre la métaphore, un pilote désireux d’obtenir une autorisation de décollage soumettra son plan de vol en utilisant un canal de confiance, et après son approbation et d’autres vérifications par les contrôleurs, le pilote pourra procéder au décollage. Si nous devions transposer cette métaphore en numérique, nous parlerions d’un utilisateur : pour que ledit utilisateur puisse accéder à la plate-forme X, il devrait utiliser un processus d’entreprise qui est lui-même fiable par une tour de contrôle d’identité. Cet utilisateur fournit son “plan d’accès” (par exemple, un jeton de session) à la tour de contrôle d’identité. Après que la tour de contrôle d’identité a vérifié l’authenticité du “plan d’accès” par rapport à ses politiques d’accès, elle effectuera d’autres vérifications de contexte, telles que : l’heure de la demande, le lieu d’origine de l’accès, le niveau de confiance du dispositif, etc. Si ces vérifications mettent en évidence quelque chose d’inhabituel ou d’incohérent dans l’authentification de l’utilisateur, des demandes supplémentaires peuvent être faites pour permettre à l’utilisateur d’entrer (ré-authentification ou renforcement).

La tour de contrôle d’identité est sous votre contrôle et détient les conditions d’accès, c’est-à-dire les politiques d’accès et accepte les utilisateurs de sources spécifiques grâce à une relation de confiance préétablie entre les organisations.

Par exemple, dans le schéma ci-dessous, imaginez une situation dans laquelle un fournisseur développe un nouveau service dans votre environnement en nuage. Les utilisateurs du fournisseur conserveraient leur dispositif et le processus d’authentification qu’ils utilisent dans leur environnement d’entreprise, tandis que la tour de contrôle d’identité (TIC) imposerait un contrôle d’accès à l’environnement en nuage – sans avoir à utiliser et à gérer un compte différent et à se ré-authentifier. Pour les environnements avec des privilèges très granulaires comme AWS, construire une TIC découplée n’est peut-être pas une approche réaliste et la TIC est alors probablement la plateforme d’identité d’Amazon qui est gérée par votre organisation et liée au fournisseur d’identité du fournisseur. Le modèle de la tour de contrôle d’identité est essentiellement une extension de la fédération, mise en œuvre pour couvrir tous les cas d’utilisation.

Figure 2 – Accès d’un utilisateur partenaire à une ressource du fournisseur de services dans le nuage via une tour de contrôle d’identité

Dans un autre scénario, comme le montre ce schéma, considérons un candidat qui postule à un emploi dans votre organisation, grâce à un portail de recrutement que vous proposez. Il déposerait une candidature sur votre portail en utilisant son identité numérique soutenue par le gouvernement, et une fois qu’il aurait donné son accord pour accéder à son profil LinkedIn, vous pourriez obtenir un CV numérique. Pour le candidat, il suffit de montrer sa pièce d’identité et de donner une copie de son CV, plutôt que de remplir le(s) formulaire(s) d’inscription en demandant une nouvelle fois les mêmes informations d’identité standard et en risquant de faire une faute de frappe dans ses coordonnées – ou même de devoir envoyer des copies de documents sensibles comme son passeport.

Figure 3 – Un scénario alternatif présentant la relation de confiance entre une plateforme d’identification gouvernementale et l’entreprise

Un modèle, trois piliers clés

Forts de nos connaissances et de notre expérience, nous pensons que ce modèle devrait reposer sur trois piliers clés : une identité unique dans tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360°.

Une Architecture d’Identité Unique : elle est réalisée en suivant une règle simple : ne pas dupliquer les données d’identité. Moins vous créez de fiches d’identité pour une même personne physique, plus l’expérience numérique sera simplifiée – car des étapes lourdes commencent à apparaître lorsqu’un compte, un dispositif ou une action d’authentification supplémentaire est nécessaire pour que l’utilisateur accède à la ressource cible. La clé d’une donnée d’identité unique est d’essayer de réutiliser les données de sa source (qui fait autorité) au lieu de les dupliquer/copier dans vos propres systèmes. Par exemple, les fournisseurs ou partenaires travaillant avec votre organisation ont probablement déjà des identités numériques professionnelles pour leur propre usage informatique – quelles seraient les conditions pour les exploiter au lieu de les recréer ?  Les deux piliers suivants contribuent à répondre à cette question.

Un modèle commun et flexible : Le deuxième pilier consiste à utiliser un modèle commun et flexible pour permettre/restreindre l’accès à l’information. Pour assurer la flexibilité, un modèle de contrôle d’accès basé sur les attributs (ABAC) permet des règles granulaires et est bien adapté à une approche adaptative et basée sur les risques. Pour que cela fonctionne, il est toutefois essentiel de définir la “grammaire” du modèle d’autorisation : quels sont les attributs réels utilisés pour fournir des accès qui ont un sens au niveau de l’entreprise ? Comment se traduisent-ils en “privilèges” ? Quels sont leurs formats/valeurs ? Lorsque la tour de contrôle d’identité est fournie par un fournisseur de cloud (par exemple, par un fournisseur de cloud comme Azure ou AWS), la grammaire est souvent déterminée par ledit service. En outre, pour que ce modèle soit le plus répandu possible dans les cas d’utilisation, tant du côté de la source d’identité que de la fourniture d’accès du côté du service cible, nous recommandons de mettre en œuvre votre plate-forme en suivant les normes du marché afin de maximiser l’interopérabilité (SAML, OpenID Connect, OAuth, FIDO, etc.).

Une relation de confiance à 360° : Enfin, le dernier pilier consiste à assurer l’établissement d’une relation de confiance à 360°. En d’autres termes, il faut faire preuve de diligence raisonnable et établir des seuils de confiance pour accepter l’interconnexion (“confiance technique”) des plateformes d’identité. La diligence raisonnable doit s’étendre à tous les processus en amont qui permettent d’alimenter la plateforme en identités, par exemple les processus RH/achats pour vérifier les identités, jusqu’au processus d’intégration informatique lui-même – parce que la confiance dans une plateforme d’identité est une première étape pour que ces identités puissent accéder à vos ressources numériques, vous devez être dans la tolérance du risque qu’elle comporte. Cette relation de confiance doit ensuite être mise en œuvre par le biais des attentes en matière de niveau de sécurité, de l’auditabilité des clauses contractuelles, et être appliquée par le biais de la gouvernance de la gestion des services des fournisseurs. Avec des exigences aussi strictes, une organisation doit être prête à intégrer temporairement des fournisseurs ou des partenaires au sein de sa propre plate-forme, pendant que les fournisseurs ou partenaires remettent leurs processus et plates-formes en conformité.

Deux facteurs clés de succès

Afin de mettre en œuvre ces trois piliers clés, Wavestone a identifié deux facteurs clés de succès : être parrainé par un niveau de gestion approprié et renforcer la résilience et la protection de la vie privée dès la conception. Un programme de transformation visant à établir ce modèle aurait des implications et des exigences dans plusieurs départements de votre organisation (RH, approvisionnement, juridique, informatique, risques, sécurité, etc.), et devrait donc être parrainé par la direction générale et mené avec une approche panorganisationnelle.

En outre, comme toujours, la plateforme de support doit être conçue et construite en tenant compte dès le départ des questions de sécurité, de confidentialité et de résilience.

Réflexions finales

Comme vous avez pu le comprendre tout au long de cet article, il est essentiel d’examiner l’expérience de l’utilisateur de bout en bout et d’un cas d’utilisation à l’autre pour vraiment rationaliser les services numériques. Cela peut être réalisé grâce à un changement d’organisation pour imposer une identité unique à tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360° avec les tiers.

Pour aller plus loin dans votre réflexion sur le sujet et comprendre l’état actuel de votre organisation, réfléchissez à ces questions et essayez d’y répondre : en choisissant des utilisateurs de différents services, à quoi ressemble l’expérience numérique quotidienne typique ? Combien de temps faut-il à mon organisation pour embarquer des sous-traitants et des tiers ? Comment mon organisation donne-t-elle effectivement accès à ses données et ressources aux utilisateurs externes ? Combien d’identités doubles existe-t-il dans mon parc informatique ? 

Cet article Les facteurs clés pour créer une expérience utilisateur transparente et sécurisée est apparu en premier sur RiskInsight.