Skip to main content
Resources

Demandes de dérogation pour incident de sécurité (SRW) des registres

Veuillez noter que seule la version anglaise des contenus et des documents traduits a un caractère officiel. Les traductions dans d'autres langues sont fournies uniquement à titre informatif.

Le service de dérogation pour incident de sécurité (SRW) a été mis au point afin de permettre aux registres gTLD de faire une demande de dérogation contractuelle pour les mesures qu'ils pourraient prendre ou ont prises afin de réduire les conséquences d'un incident de sécurité actuel ou imminent ou de résoudre un incident de sécurité actuel ou imminent affectant un gTLD et/ou le DNS. Une dérogation contractuelle est une exemption de l'obligation de se conformer à une ou plusieurs dispositions spécifiques du contrat de registre pendant le délai nécessaire pour répondre à l'incident signalé. Le SRW a été conçu afin de préserver la sécurité opérationnelle suite à un incident, tout en tenant informées les parties prenantes concernées (par exemple l'ICANN, d'autres fournisseurs affectés, etc.).

En août 2021, l'organisation ICANN a étendu le processus accéléré de demande de dérogation pour incident de sécurité des registres (ERSR) afin de permettre aux bureaux d'enregistrement de déposer des demandes de dérogation. Suite à quoi, l'ERSR a été rebaptisé « service de dérogation pour incident de sécurité (SRW) ».

Un registre peut bénéficier de ce service lorsqu'un ou plusieurs des incidents suivants surviennent :

  • Une activité malveillante ayant pour cible le DNS dont la portée et la gravité sont de nature à menacer systématiquement la sécurité, la stabilité et la résilience d'un gTLD ou du DNS ;
  • Une occurrence susceptible de provoquer une défaillance temporaire ou à long terme d'une ou de plusieurs fonctions critiques d'un registre gTLD, tel que défini dans le processus de transition entre opérateurs de registre [PDF, 96K] ;
  • La publication, la modification, l'insertion ou la destruction non autorisée de données de registre, ou l'accès non autorisé à des informations ou des ressources sur Internet ou leur publication non autorisée par des systèmes fonctionnant en conformité avec toutes les normes applicables ;
  • Une décision judiciaire d'un organisme chargé de l'application de la loi compétent à l'égard du registre qui impose au registre de prendre des mesures en raison d'une menace à la sécurité spécifique.

Le service SRW s'applique exclusivement aux incidents de sécurité nécessitant des mesures immédiates de la part du registre. Ce service n'a pas vocation à remplacer le mécanisme de dépôt de demandes au titre de la politique d'évaluation des services de registre (RSEP).

Processus SRW des registres

L'organisation ICANN reconnaît que les registres peuvent être tenus, dans certains cas, de prendre des mesures immédiates visant à éviter ou à résoudre un incident en raison de circonstances extraordinaires. Dans de tels cas, les registres doivent soumettre dès que possible une demande SRW afin que l'organisation ICANN puisse accorder, le cas échéant, une dérogation rétroactive.

Le processus SRW comporte trois phases.

  1. Soumission d'une demande SRW : Les registres peuvent lancer une demande SRW en soumettant un cas de dérogation pour incident de sécurité via le portail des services de nommage. Dans sa demande, le registre doit :

    1. Indiquer si des mesures ont déjà été prises.
    2. Indiquer si les mesures doivent être prises de toute urgence et si la dérogation est requise avant de prendre des mesures.
    3. Fournir une description de l'incident et des informations précisant comment le registre envisage de répondre ou a répondu à l'incident.
    4. Indiquer la ou les dispositions du contrat de registre auxquelles le registre souhaite déroger.
  2. Examen de la demande SRW : L'organisation ICANN examinera la demande SRW et donnera une réponse. L'organisation ICANN peut demander des informations supplémentaires, si besoin est, afin de procéder à une évaluation et un examen complets de la demande SRW. Le demandeur devra alors fournir au plus vite ces informations. Au cas par cas, l'organisation ICANN peut contacter le registre et/ou une autorité externe (par exemple un organisme chargé de l'application de la loi, un expert en sécurité, etc.) afin que l'incident lui soit confirmé.
  3. Décision et réponse : L'organisation ICANN fournira, dans un délai de 15 jours calendaires à compter de la réception de l'ensemble des informations requises, une réponse écrite prenant l'une des formes suivantes : (i) une dérogation ou dérogation rétroactive, s'il y a lieu, (ii) une mise à jour d'une dérogation existante, (iii) une décision indiquant que la demande relève d'une dérogation existante, ou (iv) une décision de refus de dérogation, précisant les fondements d'un tel refus. S'il est précisé dans la demande que des mesures doivent être prises de toute urgence et que la dérogation est requise avant de prendre des mesures, les registres recevront une réponse rapide de l'organisation ICANN.

Suite à la réponse apportée à une demande SRW, l'organisation ICANN, en collaboration avec le registre concerné, peut rédiger un rapport postintervention qui pourra être rendu public. Si un rapport postintervention doit être publié, l'organisation ICANN et le registre concerné détermineront ensemble quelles sections de la demande SRW et du rapport postintervention devront être expurgées afin de garantir la protection des informations exclusives et confidentielles.

Analyse sommaire des demandes SRW : 2019-2020

La présente section fournit des informations relatives aux suites données aux demandes de dérogation pour incident de sécurité (SRW), y compris celles déposées dans le cadre de l'ancien processus accéléré de demande de dérogation pour incident de sécurité des registres (ERSR). L'organisation ICANN souhaite mettre à jour tous les ans les données ci-dessous.

Nombre annuel des demandes traités

Dérogations accordées 2019 2020
Nombre total de demandes reçues 4 4
Nombre de domaines génériques de premier niveau (gTLD) concernés par les demandes 8 6
Nombre de nouvelles dérogations accordées 1 4
Nombre de refus de dérogation 0 0
Nombre de demandes jugées comme relevant d'une dérogation existante 3 0
Nombre de demandes débouchant sur la mise à jour d'une dérogation existante 0 0

Informations relatives aux demandes

Indicateurs 2019 2020
Nombre approximatif de noms de domaine faisant l'objet d'une demande* 5600 noms de domaine 1600 noms de domaine
Nombre de demandes adressées avant que des mesures relatives aux noms de domaines n'aient été prises 4 3
Nombre de demandes adressées après que des mesures relatives aux noms de domaines ont été prises 0 1

* Remarque : Ces chiffres ne comprennent pas les mesures en cours telles que celles prises par les registres, les organismes chargés de l'application de la loi ainsi que les décisions judiciaires définitives.

Durée moyenne du traitement

Les indicateurs ci-dessous montrent la durée moyenne de traitement par l'organisation ICANN d'une demande, de la soumission d'un questionnaire dûment rempli à la réception par le registre d'une réponse de l'organisation ICANN.

Réponse accordant dérogation 2019 2020
Octroi de la dérogation 2 jours ouvrables 4 jours ouvrables
Notification de refus de dérogation N/D N/D
Notification informant que la demande relève d'une dérogation existante 1 jour ouvrable N/D
Octroi d'une renonciation existante mise à jour N/D N/D

Archives

Cette page web a été mise à jour en mai 2022 dans le cadre des améliorations apportées au service. La page web relative au processus accéléré de demande de dérogation pour incident de sécurité des registres est disponible ici.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."