Semaine 13 Flashcards
Quels sont les concepts de fondements de sécurité?
L’authentification : elle consiste à s’assurer de l’identité d’un utilisateur avant de lui donner l’accès à un système ou à une application
La confidentialité : elle consiste à empêcher la lecture d’informations par des personnes non habitilitées ou mal intentionnées
L’intégrité : elle désigne la capacité à s’assurer de la non-altération des informations d’origine, qu’elle soit accidentelle ou malveillante
La disponibilité : elle concerne la garantie sur le bon fonctionnement d’une application, sa résistance vis-à-vis des pannes accidentelles et des attaques incapacitantes
La traçabilité : elle consiste à stocker des traces de toutes les interactions des utilisateurs avec les applications afin de pouvoir détecter des attaques ou des dysfonctionnements
Que peut-on dire de la sécurité de base avec HTTP?
Le protocole HTTP propose nativement deux modes d’authentification :
- L’authentification BASIC utilise un identifiant et un mot de passe transmis dans les en-têtes HTTP. Dans ce cas, si SSL n’est pas utilisé, le mot de passe circule en clair sur le réseau
- L’authentification HMAC repose sur un mot de passe envoyé dans les en-têtes HTTP sous forme hachée, donc chiffrée via un algorithme comme SHA256. Dans ce cas, le mot de passe ne circule pas en clair.
Qu’est-ce que la norme WS-S?
La norme WS-S : utilisée pour sécuriser les messages SOAP pour les services web décrits en WSDL
- Inclure des jetons de sécurité (tokens) dans les messages SOAP
WS-S utilise les normes de “XML Encryption” et “XML Signature”
- Capacité de transmettre des parties de messages avec protection contre modifications (intégrité) et contre l’usurpation d’identité
WS-S permet de spécifier dans un élément d’en-tête <!wsse:Security>:
1. Jeton (token) de nom d’usager et mot de passe
2. Jeton en format binaire comme certificats (ex.: certificats X.509, ticket Kerberos)
3. XML jeton comme des assertions SAML
4. EncryptedData
5. Références à d’autres éléments
À quoi ressemble un jeton de nom d’usager et mot de passe WS-S?
<!wsse:Security>
<!wsse:UsernameToken>
<!wsse:Username>John<!/wsse:Username>
<!wsse:Password>John123!<!/wsse:Password>
<!/wsse:UsernameToken>
<!/wsse:Security>
À quoi ressemble un jeton en format binaire WS-S?
Jeton en format binaire selon la norme X.509 ou en tickets Kerberos. Ex. utilisant certificat X.509
<!wsse:BinarySecurityTokenId=”my_token” ValueType=”wsse:X509v3” EncodingType=”wsse:Base64Binary”/>
À quoi ressemble un jeton XML Assertion de sécurité WS-S?
Jeton XML : exemple assertions SAML
<!saml:Assertion>
<!AssertionID=”1280234798038” IssueInstant=”2016-01-01T14:23:45.755z” Issuer=”www.mysite.com” MajorVersion=”1” MinorVersion=”2” xmlns:saml=”urn:oasis:names:tc:SAML:1.1:assertion”>
<!/saml:Assertion>
À quoi ressemble un élément EncryptedData WS-S?
Élément EncryptedData : le contenu de cet élément XML sera encrypté, exemple inclus dans l’élément d’en-tête <!wsse:Security>
<!EncryptedData>
<!CipherData>
<!CipherValue>E14Y3…2o38<!/cipherValue>
<!/CipherData>
<!/EncryptedData>
À quoi ressemble les références à d’autres éléments WS-S?
Les éléments référencés sont des éléments comme : jetons de sécurité, des parties de messages encryptées
Exemple :
<!wsse:SecurityTokenReferencewsu:Id>
<!wsse:KeyIdentifierValueType=”” wsu:Id=””>
2347830347
<!/wsse:KeyIdentifier>
<!/wsse:SecurityTokenReference>
Quel est le lien entre WS-S et WS-Policy?
Une politique de sécurité est à inclure dans le fichier WSDL ou dans un fichier attaché à un ensemble d’endpoints selon le standard WS-PolicyAttachement
Une spécification selon WS-S dans un message SOAP sera interprétée en cohérence avec les politiques applicables spécifiées selon WS-Policy.
Voir exemple semaine 13 à la fin
Qu’est-ce que la services restful authentification?
Pour les services Restful, la norme OpenApi version 3.0 propose des balises de sécurité
OpenAPI uses the term security scheme for authentication and authorization schemes. OpenAPI 3.0 lets you describe APIs protected using the following security schemes:
- HTTP authentication schemes (they use the Authorization header) :
– Basic
– Bearer
– Other HTTP schemes as defined by RFC 7235 and HTTP Authentication Scheme Registry
- API keys in headers, query strings or cookies
– Cookie authentication
- OAuth 2
- OpenID Connect Discovery
Qu’est-ce que la gestion d’API?
Éléments de gestion d’API :
- Publier des API vers des clients avec la monétisation, connaissance des utilisateurs, en plus d’autres aspects techniques
- Supervision des utilisations des API par des clients externes et internes à l’organisation. Exemple : suivi du bon fonctionnement de nouvelle version d’un API
- Assurée généralement à travers des outils
*Le terme API ici désigne un service disponible
Une API gérée doit disposer :
- D’un responsable métier
- D’une surveillance fonctionnelle et technique
- De mesures des usages avec une potentielle monétisation
- D’une visibilité qui permet sa découverte et sa souscription par les futurs utilisateurs
- D’un niveau de sécurité adéquat
Qu’est-ce qu’un gestionnaire d’API?
Permet d’exposer un service asynchrone à un consommateur synchrone
Exposer des API avec une license ouverte pour partage, réutilisation ou amélioration
Tester et superviser les versions des API
Quels sont les composants de la gestion d’API?
1- La centrale de gestion d’API : Console d’administration des API
La centrale de gestion couvre tout le cycle de vie d’une API, notamment sur les phases de conception, développement, gestion transverse puis exécution et suivi. Cette composante permet de publier des API et des règles d’usage vers le comptoir d’API où elles seront disponibles à l’usage ou au test.
Elle est réservée aux acteurs gestionnaires des API. Ces acteurs sont les responsables des API, les responsales sécurité et les responsables infrastructure
2- Le comptoir d’API : portail de clients d’API
Le comptoir d’API est destiné aux développeurs (externes ou internes) consommateurs des API. C’est le pendant des AppStore dans le domaine des applications mobiles. Il expose l’offre d’API.
Les processus outillés dans le comptoir d’API sont les suivants:
- Créer une application cliente (consommatrices d’API)
- Créer un utilisateur client (pour le responsable d’une organisation)
- S’inscrire (nouveau développeur d’une application consommatrice d’API)
- Découvrir les API disponibles (et les tester)
- Souscrire à une API
- Noter ou commenter une API
- Consulter les statistiques d’usage, selon ses applications, ses API et ses utilisateurs. On peut voir les indicateurs publiés, généralement le nombre d’appel d’erreurs, les temps de réponses, etc.
3- La passerelle d’API
Quel que soit le socle de sécurité, le gestionnaire d’API utilise des informations utilisateurs dans un référentiel (UserStore) interne ou existant, ainsi que les informations de sécurité comme les jetons d’accès. Les fonctions de la passerelle sont destinée à des acteurs automatiques :
- Recevoir des appels
- Valider les informations de sécurité associées à l’appel
- Appliquer les règles disponibles
- Alimenter les statistiques
Qu’est-ce que l’outillage de gestion d’API avec WebLogic?
WebLogic offre une console de gestion sur l’adresse : http://<!host>:<!port>/em où host désigne la machine roulant le serveur WebLogic
Qu’est-ce que les conteneurs?
Les architectures de services déploient leurs services et les applications composites au travers de conteneur(s). Par définition, un conteneur contient (au moins) une application ou un service. Le conteneur offre un environnement d’exécution aussi indépendant que possible de la machine hôte. Autrement dit, une fois “mis en boîte” dans un conteneur, l’application ou le serviee est prêt à l’emploi quel que soit l’environnement de déploiement (hardware, OS, système de gestion de fichiers) de cette application ou de ce services
Le conteneur est une unité de paquetage qui accompagne l’organisation des développements : une équipe = un service (métier ou technique) = un conteneur (ou un petit nombre de conteneur), indépendamment des technologies utilisées
Le conteneur est une unité de test : il doit être possible de tester un conteneur indépendamment des autres conteneurs
Le conteneur est une unité de déploiement : chaque conteneur peut donc faire l’objet d’une mise à jour indépendamment des autres conteneurs et il peut faire l’objet d’un rollback (remplacement de la version N par la version N-1) instantané.
Le conteneur est une unité de management et d’exploration qui respecte un cycle de vie défini une seule fois, ce qui permet aux équipes Ops ou DevOps de démarrer, gérer et arrêter chaque conteneur individuellement, mais de façon homogène
