Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
federation:technique:sirtfi [2018/04/25 14:14] – [3. Déclarer la conformité SIRTFI d'une entité SAML : guide étape-par-étape] herve.bourgault@renater.frfederation:technique:sirtfi [2020/12/01 15:06] (Version actuelle) geoffroy.arnoud@renater.fr
Ligne 1: Ligne 1:
-[[:federation:en:sirtfi|Click here for the English version]] +Cette page a été déplacée ici [[federation:documentation:engagement-conformite:sirtfi]]
- +
-====== SIRTFI : Un cadre de sécurité pour les fédérations ====== +
- +
-===== 1. Pourquoi SIRTFI ===== +
- +
-Le développement et l’inter-connexion des fédérations via eduGain a créé un nouveau vecteur d’attaque. Un compte compromis peut aujourd’hui potentiellement donner accès à une multitude de services au sein de la communauté. +
- +
-Ce nouveau vecteur d'attaque s'inscrit dans un contexte où la prise en compte de la sécurité opérationnelle est variable selon les organisations et n’est souvent pas connue des autres participants. Un niveau de sécurité minimal n’est par exemple pas requis pour rejoindre une fédération.  Dans le cas d’un incident de sécurité lié à la fédération, il n’y a donc aucune garantie d’une collaboration efficace entre les organisations concernées.  +
- +
-Le framework SIRTFI (//Security Incident Response Trust Framework for Federated Identity//) se veut une réponse à ce problème. Il vise à fournir un cadre permettant d’une part, d’identifier les participants de confiance de la fédération et d’autre part, de garantir une collaboration efficace entre les entités lors d’une réponse à un incident de sécurité lié à la fédération. +
- +
-SIRTFI est une initiative du groupe REFEDS (//Research and Education FEDerations group//[[https://refeds.org/sirtfi]] +
-\\ \\  +
- +
-===== 2. Le framework SIRTFI en bref ===== +
- +
-<note>Document original: [[https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf]]</note> +
- +
-Le framework SIRTFI définit un ensemble de règles et bonnes pratiques sécurité articulées autour des quatre domaines suivants : sécurité opérationnelle, réponse sur incident, traçabilité et responsabilité des participants.  +
- +
-Le tableau suivant dresse une description synthétique du contenu de chacune des thématiques: +
- +
-^ Domaine                                   ^ Description                                                                                                                                                                                                                                                                                                                                                                                 ^ +
-| **Sécurité Opérationnelle [OS]**          | - Application régulière des patchs de sécurité \\ - Processus de gestion des vulnérabilités \\ - Détection d’intrusion et protection des systèmes \\ - Possibilité d’intervention sur les droits d’accès utilisateur \\ - Possibilité de contacter les propriétaires et utilisateurs d’un service au sein de l’organisation \\ - Capacité de réponse sur incident                           | +
-| **Réponse sur incident [IR]**             | - Identification des contacts sécurité référents pour l’organisation \\ - Réponse rapide aux demandes d’assistance des autres membres SIRTFI \\ - Collaboration pour la résolution d’incidents de sécurité \\ - Respect des procédures de réponse sur incident de l’organisation \\ - Respect de la vie privée des utilisateurs \\ - Utilisation du protocole TLP (//Traffic Light Protocol//+
-| **Traçabilité [TR]**                      | - Politique de gestion des logs appropriée au sein de l’organisation permettant leur exploitation pour la résolution d’incidents de sécurité                                                                                                                                                                                                                                                | +
-| **Responsabilité des Participants [PR]**  | - Politique d’utilisation acceptable du service (//Acceptable Use Policy//) en vigueur au sein de l’organisation et connue et acceptée des utilisateurs finaux                                                                                                                                                                                                                                  | +
- +
-\\ \\  +
- +
- +
-===== 3. Déclarer la conformité SIRTFI d'une entité SAML : guide étape-par-étape ===== +
- +
-Le chapitre qui suit décrit les étapes à suivre par une organisation afin de pouvoir déclarer une entité SAML conforme à SIRTFI +
- +
-=== Etape 1 - Auto-évaluation de l'organisation === +
- +
-La première étape pour une organisation consiste à s'auto-évaluer en prenant le framework SIRTFI comme cadre de référence (cf. chapitre précédent). +
-  +
-<note important>Une organisation sera dite conforme SIRTFI si elle est en mesure d'accepter et de respecter chacune des assertions énoncées dans le framework</note>  +
- +
-Dans le cas où l'évaluation est positive, l'organisation peut alors déclarer cette conformité SIRTFI pour chacune des ressources fédérées (IdP ou SP) dont elle est responsable. Cette opération est réalisée au travers du guichet de la fédération. +
- +
-=== Etape 2 - Déclaration de conformité SIRTFI d'une entité SAML (Guichet de la fédération) === +
- +
-La déclaration de conformité SIRTFI pour une ressource (IdP ou SP) s'effectue via le guichet de la fédération, depuis la page d'édition de la ressource concernée. +
- +
-Au niveau de l'onglet "contacts" de la ressource, il suffit simplement de cocher la case prévue à cet effet, afin d'attester que cette ressource est bien conforme. +
- +
-<note warning>**Attention :** le fait de cocher la case "//J'atteste que cette entité SAML est conforme aux règles SIRTFI//" vous engage à respecter chacune des assertions du framework SIRTFI. </note>  +
- +
-Après avoir coché la case, il est alors obligatoire de renseigner un contact sécurité pour cette ressource (les champs nom et adresse email du contact sécurité, grisés jusqu'alors, deviennent saisissables). +
- +
- +
-=== Etape 3 - Choix d'un contact Sécurité pour l'entité SAML (Guichet de la fédération) === +
- +
-Le contact sécurité d'une ressource sera le point de contact de référence dans le cas d’un incident de sécurité lié à la fédération impliquant cette ressource. +
- +
-En tant qu’organisation appartenant à la Fédération Education-recherche, 2 possibilités s’offrent à vous pour le choix du contact sécurité : +
-  * **Option 1 :** RENATER fournissant déjà un support centralisé pour les incidents de sécurité touchant la Fédération Education-Recherche, vous avez la possibilité d'utiliser l'adresse mail RENATER dédiée renseignée par défaut (**fed-sirtfi@support.renater.fr**) comme adresse de contact sécurité.  +
- +
-  * **Option 2 :** Si votre organisation possède déjà une équipe ou un service sécurité sensibilisé aux problématiques liées à la fédération, vous pouvez également choisir cette équipe/service comme contact sécurité et fournir vos propres informations de contact +
- +
-<note important>Le contact sécurité d’une ressource doit être une personne ou un groupe de personnes (équipe, service) ayant accepté de respecter les obligations de réponse sur incident définies dans le framework SIRTFI. +
-</note> +
- +
-=== Etape 4 - Soumission des modifications (Guichet de la fédération) === +
- +
-La soumission de ces modifications (attestation conformité + contact sécurité) sur le guichet entraîne l’ajout de deux balises spécifiques SIRTFI (//SIRTFI entity attribute// et //Security Contact//) dans les méta-données associées à la ressource. +
- +
-Un exemple de ces deux balises est présenté en annexe au chapitre 6. +
- +
-\\  +
- +
-===== 4. SIRTFI en utilisation courante ===== +
- +
-Pour une organisation conforme, l’utilisation de SIRTFI au quotidien pourra prendre les formes suivantes :  +
- +
-1. Une collaboration au processus de réponse sur incident lié à la fédération : +
-  * Si vous constatez un incident de sécurité impliquant une ressource de la fédération, vous devez contacter le contact sécurité correspondant listé dans les méta-données associées à cette ressource ; +
-  * Inversement, si vous êtes sollicités pour aider à la résolution d’un incident de sécurité, vous devez répondre et activement collaborer avec les autres organisations/entités conformes SIRTFI. +
- +
-2. La possibilité pour un gestionnaire de SP de restreindre l’authentification uniquement aux IdPs attestant également d’une conformité SIRTFI, via la mise en œuvre d’un filtrage spécifique (voir chapitre 5 ci-dessous pour plus de détails). +
- +
-\\  +
- +
-===== 5. Mise en œuvre d’un filtrage SIRTFI côté SP ===== +
- +
-Côté Service Provider, il est possible de mettre en place un filtrage des utilisateurs basé sur SIRTFI. L’idée ici est de restreindre l’accès à une ressource uniquement aux utilisateurs authentifiés auprès d’un IdP conforme SIRTFI. +
- +
-D’un point de vue technique, ce filtrage pourra être réalisé de deux manières différentes : +
-  - Soit par l’application directement (en utilisant la logique de contrôle d’accès de l’application) ; +
-  - Soit via l’utilisation de la fonctionnalité de filtre offerte par le SP Shibboleth +
-   +
-Dans les deux cas, il faudra au préalable récupérer //l’Entity Attribute SIRTFI// côté SP. +
- +
-=== Récupération de l’Entity Attribute SIRTFI côté SP === +
- +
-Les attributs de type « //Entity Attribute// » sont listés dans les métadonnées de la fédération.  +
-Ils peuvent être mappés au niveau du SP de manière identique à ce qu’il est possible de faire pour les attributs utilisateur délivrés par un IdP.  +
- +
-Pour pouvoir utiliser les attributs présents dans les métadonnées, il est d’abord nécessaire de définir un préfixe spécifique dans la balise //ApplicationDefaults// (ou //ApplicationOverride//) du fichier de configuration //shibboleth2.xml//, comme illustré ci-dessous :  +
- +
-<code xml shibboleth2.xml> +
-<ApplicationDefaults entityID=https://example.org/shibboleth/ +
-metadataAttributePrefix="md_"> +
-</code> +
- +
-Supposons qu’un //entity attribute// SIRTFI soit renseigné pour un IdP dans les métadonnées :  +
-<code xml> +
-<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"> +
-  <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" +
-                  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" +
-                  Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"> +
-           <saml:AttributeValue>https://refeds.org/sirtfi</saml:AttributeValue> +
-  </saml:Attribute> +
-</mdattr:EntityAttributes> +
-</code> +
- +
-Il est alors possible de définir un mapping de cet attribut au niveau du SP,  dans le fichier// attribute-map.xml//, de la manière suivante : +
- +
-<code xml attribute-map.xml> +
-<Attribute name="urn:oasis:names:tc:SAML:attribute:assurance-certification" id="sirtfi" /> +
-</code> +
- +
-Ce qui permet à la valeur de l’attribut défini ci-dessus d’être disponible au travers de la variable **md_sirtfi**. +
-\\ \\  +
- +
-=== Contrôle d’accès réalisé directement par l’application === +
- +
-Une fois la variable **md_sirtfi** récupérée au niveau du SP, la valeur associée peut être passée à l’application.  +
- +
-Si vous avez la possibilité de modifier le code source  de l’application, il est alors envisageable d’implémenter un contrôle d’accès se basant sur la vérification de cette valeur.   +
-\\ \\  +
- +
-=== Contrôle d’accès basé sur l’utilisation de la fonctionnalité de filtre du SP Shibboleth  === +
- +
-Comme solution alternative, il est également possible d’utiliser la fonctionnalité de filtre offerte par le SP Shibboleth. +
- +
-Au niveau d’Apache, cela requiert de définir un élément directory (/limit/access) sur lequel on souhaite appliquer un contrôle d’accès et où sont positionnées les règles d’autorisations (path/to/ac.xml)   +
- +
-<file> +
-<Directory /limit/access> +
-    AuthType shibboleth +
-    ShibRequestSetting requireSession 1 +
-    ShibAccessControl /path/to/ac.xml  +
-</Directory> +
-</file> +
- +
-La configuration du filtre du SP Shibboleth est défini au travers du fichier /path/to/ac.xml, dont un exemple est fourni ci-dessous  :   +
- +
-__Exemple de filtre simple vérifiant que l’utilisateur est un étudiant authentifié sur un IdP Sirtfi :__ +
- +
-<file> +
-<AccessControl type="edu.internet2.middleware.shibboleth.sp.provider.XMLAccessControl"> +
-   <AND> +
-      <Rule require="md_sirtfi"> https://refeds.org/sirtfi </Rule> +
-      <RuleRegex require="affiliation">^student@.+\.cz$</RuleRegex>     +
-   </AND> +
-</AccessControl> +
-</file> +
- +
-L’exemple ci-dessus reste assez basique mais il est possible d’implémenter des règles de contrôle d’accès plus complexes. Plus de détails dans la documentation Shibboleth: \\ https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPXMLAccessControl  +
- +
-\\  +
- +
-===== 6. Annexe : Balises SIRTFI ===== +
- +
-=== 6.1 SIRTFI Entity Attribute === +
- +
-La conformité SIRTFI est exprimée via l’utilisation de l’//entity attribute// “urn:oasis:names:tc:SAML:attribute:assurance-certification” renseignée avec la valeur “https://refeds.org/sirtfi” dans les métadonnées d’une entité SAML, comme illustré ci-dessous : +
- +
-<file> +
-<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ...> +
-  <md:Extensions> +
-    <mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"> +
-      <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" +
-            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" +
-            Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"> +
-        <saml:AttributeValue>https://refeds.org/sirtfi</saml:AttributeValue> +
-      </saml:Attribute> +
-    </mdattr:EntityAttributes> +
-  </md:Extensions> +
-  ... +
-</md:EntityDescriptor> +
-</file> +
- +
- +
-=== 6.2 SIRTFI Security Contact === +
- +
-Un contact de sécurité est ajouté pour chaque entité attestant d’une conformité SIRTFI, comme illustré ci-dessous :  +
- +
-<file> +
-<md:ContactPerson xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" +
-      contactType="other" +
-      remd:contactType="http://refeds.org/metadata/contactType/security" +
-      xmlns:remd="http://refeds.org/metadata"> +
-  <md:GivenName>Security Response Team</md:GivenName> +
-  <md:EmailAddress>mailto:security@xxxxxxxxxxxxxxx</md:EmailAddress> +
-</md:ContactPerson> +
-</file> +
- +
- +
  • federation/technique/sirtfi.1524658469.txt.gz
  • Dernière modification : 2018/04/25 14:14
  • de herve.bourgault@renater.fr