ECUE.3.

22

Section 2. Solutions de sécurité dans le

Cloud

Leçon1. Cloud Identification & Access Management

Authentification - Autorisation
La gestion des identités et des accès (Identification & Access Management –
abv. “ IAM”) implique deux concepts distincts:

L’authentification (Authentication – abv. “Authn”) est le processus de vérification

de l'identité.
L’autorisation (Authorization – abv. “Authz”) est le processus de vérification de
l'accès à une entité.

NB: N'oubliez pas les identités pour les entités « non humaines » telles que les
applications., les objets connectés, … celles-ci doivent également être gérées, tout
comme les identités humaines.
Cycle de vie du processus IAM
Exemples de services IAM des fournisseurs Cloud

Exemples de services de gestion d’identité pour authentifier vos

administrateurs Cloud avec les services de fournisseur Cloud.

Fournisseur Système de Gestion d’identités

Amazon Web Services Amazon IAM

Microsoft Azure Azure Active Directory B2C

Google Compute Cloud Cloud Identity

IBM Cloud Cloud IAM

Exemples de services IAM des fournisseurs Cloud (2)
Systèmes de gestion d’identités de vos utilisateurs finaux – end system users - qu'il s'agisse
de clients externes ou de vos propres employés:
o Utiliser un système d’authentification interne pour identifier les employés
o Utiliser un système d’authentification externe (Gmail, LinkedIn, Facebook,…)
o Utiliser un service Cloud pour la gestion des identité des utilisateurs finaux (Identity-
as-a-Service (IDaaS))
Fournisseur Système de Gestion d’identités des clients

Amazon Web Services Amazon Cognito

Microsoft Azure Azure Active Directory B2C

Google Compute Cloud Firebase

IBM Cloud Cloud Identity

Auth0 Customer Identity Management

Ping Customer Identity and Access Management

Okta Customer Identity Management

Oracle Oracle Identity Cloud Service

Authentification multi-facteurs

L'implémentation la plus courante est l’authentification à deux facteurs (2FA), qui

utilise quelque chose que vous connaissez (comme un mot de passe) et quelque
chose que vous avez (comme votre téléphone mobile).
Une authentification 2FA et fortement recommandée pour tout accès privilégié,
l'accès pour lire ou modifier des données sensibles, ou l'accès à des systèmes tels que
les e-mails qui peuvent être utilisés pour réinitialiser d'autres mots de passe.
Dans un environnement Cloud, un accès administrateur non autorisé aux services ou
API Cloud représente un risque très élevé (un attaquant disposant de cet accès peut
en tirer parti pour compromettre toutes vos données) . Vous devez impérativement
activer la 2FA.
La plupart des fournisseurs Cloud supportent nativement la 2FA. Sinon, si vous
utilisez l'authentification unique (SSO: Single Sign On) le fournisseur d'authentification
effectue une 2FA.
Google utilise le terme plus convivial de « 2-Step Verification ».
Authentification multi-facteurs (2)

Source: How to Build SMS 2FA That Won’t

Scare Away Your Users, Hugh Hopkins 2015
Authentification multi-facteurs (3)
Les méthodes les plus courantes pour vérifier «quelque chose que vous avez» sont :
o SMS – Facilement compromise en cas de vol de mobile ou de clonage de SIM
o Time-based One Time Passwords (TOTP): cette méthode nécessite de fournir à un appareil
mobile un «secret» initial (généralement transféré par un code-barres 2D). Le secret est
une formule pour calculer un mot de passe à usage unique toutes les minutes environ. Le
mot de passe à usage unique ne doit être conservé en sécurité que pendant une minute
ou deux, mais le secret initial peut permettre à n'importe quel appareil de générer des
mots de passe valides et doit donc être oublié ou placé dans un endroit physiquement sûr
après utilisation.
o Notifications push: avec cette méthode, une application cliente déjà authentifiée sur un
appareil mobile établit une connexion avec un serveur, ce qui «repousse» un code à usage
unique selon les besoins.
o Un périphérique matériel (clé usb, microship, NFC, BLE,…) conforme à la norme FIDO
U2F (Cf https://fidoalliance.org/).
o Pour une liste plus exhaustive : Yevseiev, Serhii & Hryhorii, Kots & Liekariev, Yehor. (2016).
Developing of multi-factor authentication method based on Niederreiter Mceliece modified
crypto-code system. Eastern-European Journal of Enterprise Technologies. 6. 11-23.
10.15587/1729-4061.2016.86175.
API Keys

Les API Keys sont très similaires aux mots de passe sauf qu’ils sont conçues pour être
utilisées par du code applicatif. Pour cette raison, l'authentification multi-facteurs
n’est pas plausible avec des API keys.
Il s'agit de longues chaînes aléatoires
On peut disposer de différentes API keys privées qui fournissent à la fois l'identité et
l'authentification, selon un protocole ou une opération définie : Read/ Write HTTP API
Key – Read/Write MQTT API KEY, …
Identités partagées / Fédérées

Les ID partagés sont des identités pour lesquelles plus d'une personne possède le
mot de passe ou d'autres informations d'identification, telles que les comptes root ou
administrateur. Cela suppose que vous devriez être en mesure de dire exactement
quelle personne utilisait l'ID pour tout accès (processus check-in/ check-out).

L'identité fédérée est un concept qui signifie que vous pouvez avoir des identités sur
deux systèmes différents, et les administrateurs de ces systèmes acceptent tous deux
d'utiliser des technologies qui lient ces identités ensemble afin que vous n'ayez pas à
créer manuellement des comptes distincts sur chaque système. De votre point de
vue en tant qu'utilisateur, vous n'avez qu'une seule identité.
Single Sign On (SSO)

L'authentification unique est un ensemble d'implémentations qui se basent sur le

concept d'identité fédérée.

le site Web redirige l'utilisateur vers un fournisseur d'identité centralisé (IdP) auquel
il fait confiance.
Exemples de technologies SSO :
o SAML (Security Assertion Markup Language),
la réponse est sous la forme d’une cookie
cryptée en format XML

o OIDC (OpenID Connect), utilise Json

Web Token (JWT) au lieu de XML.
Vue d’ensemble
Les six étapes

1. L'utilisateur final tente d'accéder à l'application et son accès est automatiquement

approuvé selon une identité valide. L'utilisateur final se connecte avec SSO. L'identité
est donc fédérée avec le IdP externe et l'application n'a pas à valider les mots de
passe. L'utilisateur utilise la même identité.
2. L'administrateur demande l'accès pour administrer l'application, ce qui est approuvé.
L'administrateur est alors autorisé dans un système d'autorisation centralisé.
L'autorisation peut avoir lieu dans le système IAM du cloud, ou le système IAM du
cloud peut être configuré pour demander au propre système d'autorisation interne
de l'organisation d'exécuter l'autorisation.
3. L'administrateur s'authentifie auprès du service cloud IAM à l'aide d'un mot de passe
fort et d'une authentification multifacteur et obtient un jeton d'accès à attribuer à
tout autre service. Encore une fois, facultativement, le service cloud IAM peut être
configuré pour envoyer l'utilisateur au système d'authentification interne de
l'organisation
Les six étapes (2)

4. L'administrateur envoie des demandes aux services du fournisseur de cloud, par

exemple pour créer une nouvelle machine virtuelle ou un nouveau conteneur. (En
arrière-plan, le service cloud VM demande au service cloud IAM si l'administrateur
est autorisé.)
5. L'administrateur utilise un service de fournisseur de cloud pour exécuter des
commandes sur les machines virtuelles ou les conteneurs selon les besoins. (En
arrière-plan, le service «exécuter la commande» du cloud demande au service IAM
du cloud si l'administrateur est autorisé à exécuter cette commande sur cette
machine virtuelle ou ce conteneur.) Si cette fonctionnalité n'est pas disponible
auprès d'un fournisseur de cloud particulier, l'administrateur peut utiliser une
méthode plus traditionnelle, telle que SSH, avec la machine virtuelle utilisant le
protocole LDAP pour authentifier et autoriser les administrateurs par rapport à un
annuaire d'identités.
6. Un service de gestion de « secrets » est utilisé pour conserver le mot de passe ou
la clé API permettant au serveur d'applications d'accéder au système de base de
données.
Le même processus pourrait se produire pour l'authentification entre le serveur
Web et le serveur d'applications,